Software test design methods

Large numbers of moderately skilled testers can test the application with no knowledge of implementation, programming language, or operating systems. As the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in testing the application effectively. Due to the fact that a skilled tester is needed to perform white-box testing, the costs are increased. Sometimes it is impossible to look into every nook and corner to find out hidden errors that may create problems, as many paths will go untested.

It is difficult to maintain white-box testing, as it requires specialized tools like code analyzers and debugging tools. Due to the tester's knowledge about the code, maximum coverage is attained during test scenario writing.

Since the access to source code is not available, the ability to go over the code and test coverage is limited. Grey box testers don't rely on the source code; instead they rely on interface definition and functional specifications. Based on the limited information available, a grey-box tester can design excellent test scenarios especially around communication protocols and data type handling.

This technique exhaustively tests the developed code. Developers who have complete information of the software code, its internal structure, and design help to design the test cases. This technique is further divided into five categories. This technique involves execution of all the executable statements in the source code at least once.

The percentage of the executable statements is calculated as per the given requirement. This is the least preferred metric for checking test coverage. This technique is also known as branch coverage is a testing method in which each one of the possible branches from each decision point is executed at least once to ensure all reachable code is executed. This helps to validate all the branches in the code.

This helps to ensure that no branch leads to unexpected behavior of the application. All the testing outcomes are at least tested once. The test cases are designed as such that the condition outcomes are easily executed. To ensure complete coverage, two or more test scripts are required which requires more efforts.

In this technique, the source code of a program is leveraged to find every executable path. This helps to determine all the faults within a particular code. The outcomes of these techniques are based on the skills, knowledge, and expertise of the people involved.

The types of experience-based techniques are as follows:. In this technique, the testers anticipate errors based on their experience, availability of data and their knowledge of product failure.

Error guessing is dependent on the skills, intuition, and experience of the testers. This technique is used to test the application without any formal documentation. There is minimum time available for testing and maximum for test execution.

In exploratory testing , the test design and test execution are performed concurrently. Specification-based or Black-box techniques Equivalence Partitioning: The idea of this approach is grouping the inputs with the same attributes to partitions. Code is not visible to testers. Your task is to pick one condition out of each partition, which covers all possible scenarios, to execute test cases.

If a condition of a partition is valid, other conditions are valid too. Likewise, if a condition in a partition is invalid, other conditions are also invalid. This helps reduce the number of test cases. Boundary Value Analysis: This is one of the software testing techniques in which test cases are designed to include values at the boundaries. In other words, the behavior of Negative testing is more likely to be incorrect than the behavior of Positive testing; and boundaries are an area in which testing is more likely to yield defects.

Decision Table Testing: This technique can be used in test design because it helps testers explore the effects of combining different input values when adhering business rules. A Decision Table is a tabular representation of conditions versus test actions. Conditions are considered as inputs, while actions are considered as outputs.

State Transition Diagrams: Using this approach, the tester analyzes the behavior of an application under test AUT for different input conditions in a sequence. You can provide both positive and negative input test values and record the system behavior. Any system in which you get a different output for the same input is a finite state system. Use Case Testing: Use case testing is a functional testing technique, meaning programming skill is not required. It helps the tester determine which test scripts are executed on the entire system from the beginning to the end of each transaction.

Structure-based or White-Box techniques Statement Coverage or Line Coverage: In this technique, every statement in the source code is executed at least once. Thereby, we can check what the source code is and is not expected to do. However, we cannot test the false condition in the source code.

The overall approach stated in the test plan is refined into two parts: specific test methods and the evaluation criteria. Based on these test methods and the criteria, the test cases to test the unit are specified. For each unit being tested, these test case specifications describe the test cases, required inputs for test cases, test conditions, and the expected outputs from the test cases.

Generally, it is required to specify the test cases before using them for testing. This is because the effectiveness of testing depends to a great extent on the nature of test cases. Test case specifications are written in the form of a document.

This is because the quality of test cases is evaluated by performing a test case review, which requires a formal document.