Fundamentals of Software Testing

Software testing covers many domains and industries. Each project brings a new challenge: understand the client’s perspective and the domain before you begin testing. You may also need different testing methods from one project to the next. A solid understanding of the fundamentals is therefore the first prerequisite for success.

Why Is Software Testing Necessary?

Developers can introduce errors, defects or bugs unintentionally. Modern software is complex, so misunderstandings can lead to incorrect logic and code.

Testing identifies faults so that they can be corrected and software quality can improve. The goal is to develop and deliver bug-free applications. When a company agrees to develop software for a client, legal, contractual and industry-specific requirements shape the work. A quality-conscious company includes testing among its best practices.

It is difficult to determine how much testing is enough. Careful planning and well-designed test cases make high-quality delivery possible.

Who Does The Software Testing?

Who should test the software? Developers often check their code several times before handing it over, yet defects can remain because it is difficult to see your own mistakes.

A tester takes an unbiased view from the client’s perspective, focusing on specifications and requirements. This can reveal areas the developer overlooked. Testing should therefore always be carried out by independent testers.

Separating development and testing teams also has disadvantages. Communication gaps can arise. Developers may neglect code review because they see quality as the tester’s responsibility, increasing the testing team’s workload.

Developers sometimes test each other’s work, an approach known as buddy testing. Every development team should have dedicated testers, and a project generally has at least one dedicated testing team. Some companies create separate teams for usability, performance, security and other testing types. Others outsource the work to specialist firms, independent testers or consultants.

What Has To Be Really Tested?

Understand the project requirements and the real-world setting in which the software will be used. This helps you decide what to test and build an appropriate testing strategy.

Open Full-Size Diagram ↗

What Has To Be Really Tested?

When Is The Software Testing Done?

Starting testing early helps developers finish on time and saves time, money and effort. Defects found late in development can be expensive to correct. Divide development into stages and test the work at each stage before proceeding. This supports timely delivery and better results. Integration also becomes easier when each module has already been tested independently against its specifications.

How Often Do We Need To Test?

Test alongside development and look for as many defects as possible in the early phases. How often you test depends on the quality you need. Early findings allow design changes while they are easier and less expensive; major changes become difficult and costly later.

Open Full-Size Diagram ↗

How Often Do We Need To Test?

What Are Software Testing Standards?

Testing standards matter to both customers and producers. Customers invest in software and want confidence that its quality makes it the right purchase.

All reputable companies govern product quality through publicly approved standards. Following those standards provides assurance about the product and its expected behavior. This gives customers confidence that they are buying software of the right standard.

For producers, standards help improve the final product. Once a company chooses its standards, it can reuse that foundation on later projects instead of starting from scratch. Many testing standards help evaluate quality and improve testing effectiveness. No single standard, however, covers every aspect of software testing.

Standards that include testing within a broader set of requirements, as well as standards specifically supporting testing, can guide your work.

What Is Software Testability?

Testability describes how easily a software system can be tested. Assess it early to estimate the resources needed for testing. Testing uncovers defects; testability helps identify areas where defects may remain hidden. High testability makes testing easier, while low testability increases the effort required. Consider these factors:

1. Controllability: You need control over the testing process to optimize it.
2. Observability: The behavior and factors that affect the outcome must be visible so that you can test them.
3. Availability: You need access to the system to test it.
4. Simplicity: A consistent design, straightforward features and simple coding practices reduce testing complexity. More complicated software is harder to test.
5. Stability: Frequent design changes can disrupt testing.
6. Information: Testing efficiency depends heavily on the information available about the software.

Keep these testability relationships in mind:

1. Higher testability supports better tests and fewer defects.
2. Lower testability can reduce test quality and leave more defects in the system.

Software Verification VS Software Validation

Verification and validation describe different kinds of analysis. Validation asks whether you are building the right system: does it meet the customer’s requirements?

Verification asks whether you are building the system correctly. It focuses on engineering quality and compliance with the required standards.

Validation checks that the specifications meet the customer’s needs. Verification checks that development follows the organization’s software quality standards and engineering practices.

Open Full-Size Diagram ↗

Software Verification VS Software Validation

Some approaches place verification in every development phase but concentrate validation at the beginning and end, during requirements analysis and acceptance testing. This is difficult to follow in practice. It is hard to capture every client requirement at the start, and requirements often change after development begins. Development teams themselves may request changes. Carry out both verification and validation throughout development to respond to that reality.

Testers use verification and validation, or V&V, to examine different aspects of software quality.

Software Testing VS Software Debugging

Testing and debugging have different purposes. Testing reveals defects. Debugging follows a defect finding and removes its cause.

After testers report a defect, developers investigate the root cause. They examine the related modules, locate the problem in the code and correct it. Debugging identifies and resolves the cause step by step.

Understand a defect’s possible causes before attempting a fix. Debugging without enough information can introduce another defect in an interconnected module. Avoid unstructured experimentation. After a fix, return the work to the tester for thorough testing of the module.

1. Testing uncovers defects; debugging locates and corrects their causes.
2. Testing is an important part of development. Debugging responds to the defects testing reveals.
3. Testing begins early in development. Debugging begins when defects are reported.
4. Testing includes verification and validation (V&V). Debugging investigates and corrects the cause of a defect.

What Is A Defect?

A defect is a departure from the software requirements specification. Defects can occur in the code or design and cause incorrect output when the program runs.

1. Code with many defects is often called buggy.
2. A bug report describes the nature of a defect.
3. Bug tracking tools track defects in a system.
4. In one testing technique, defects are deliberately introduced into the code. The outcome is monitored to check whether the system responds as expected to those issues.

Open Full-Size Diagram ↗

What Is A Defect?

What Are Severity And Priority?

Severity describes a defect’s impact on the system. The following categories classify that impact:

1. Critical: The application cannot function properly because of system failure or data corruption. The user cannot proceed.
2. Major: The system may fail, but the user has another way to achieve the result without additional training. These defects are less severe than critical defects.
3. Moderate: The system continues to run but produces incorrect or contradictory output.
4. Minor: The defect does not cause system failure or affect usability and can be corrected easily.
5. Cosmetic: The defect affects the system’s appearance.

A defect report records priority as well as severity. Priority tells developers the order in which to resolve defects:

1. Low: Resolve the defect after higher-priority defects; it does not need immediate attention.
2. Medium: Resolve the defect soon after higher-priority defects.
3. High: Give the defect immediate attention and resolve it as soon as possible.

Use the reported severity and priority together to decide how urgently to act:

Open Full-Size Diagram ↗

What Are Severity And Priority?

1. High priority and high severity: A problem in basic functionality prevents the user from using the system. Resolve it immediately.
2. High priority and low severity: A misspelled company name or a logo issue has low functional severity but needs immediate correction.
3. High severity and low priority: A major defect affects a module that the user does not need immediately, so correction can wait.
4. Low priority and low severity: Cosmetic defects that do not affect functionality are generally corrected last.