Finding bugs is the main goal for testers, which primarily involves verifying that the software correctly provides a solution to an end-user’s problem. However, no interface has been designed that can anticipate all the ways users can run amok operating the program. Thus, testers must also verify that the program fails gracefully versus crashing in the face of bad input or incorrect usage.
Both the expected and unexpected ways a program performs is covered by two types of testing: positive and negative testing.
Another common name for positive testing is “testing the happy path.” These types of tests trial program actions and inputs not expected to produce errors. Testers typically begin with positive tests in order to verify that the program works in the most fundamental way.
Most software has alternative paths for accomplishing a single task. For instance, in a hotel booking application, the user starts at point A with a clean slate and attempts to reach point B, which is a room reservation for a specific date.
A flexible, user-friendly booking app may permit alternate paths that traverse from point A to point B. One user might specify a price range first, then select a region and then hotel ratings. Another user may employ a different selection order or use different criteria, but both should reach point B without errors.
Negative test cases seek out the results of misbehavior on the part of the software user or programmer. It is watching to see if the software handles a bad situation in a reasonable way or not.
No programmer, however, can anticipate every way their program might fail. Often, they miss error paths because they make assumptions about user behavior. Their inside-out, intimate view of the application means they forget about hapless first-time user who did not read the user manual and who is probably distracted. Negative tests of this sort that trigger unanticipated errors demand high levels of creativity and intuition from testers to root out such defects.
Compiling Positive and Negative Test Cases
Positive test cases provide a behavioral baseline, so list those first. As these test cases are compiled, obvious negative test cases will naturally arise. For example, if the application has a sign-on page or widget, the positive tests ensure the application handles expected authentication information, such as a user name, a numerical ID or a password. Each of these fields already have a specification as to the input expected, such as letters, numbers and a select set of special characters plus acceptable string lengths.
The corresponding negative test is to input non-printing characters or strings longer than specified. These may have various outcomes such as an error being displayed, a program crash or the program mistakenly logging in the user anyway. Only one of those outcomes is probably acceptable and the others are flagged as defects.
Boundary and Equivalence Analysis
The things that a program shouldn’t do is always a larger set than what it should do. Thus, you need to pare down the negative test cases to a feasible quantity. Two main methods for this are boundary analysis and equivalence partitioning, which are both used in relation to one another.
The software requirements usually determine the range of valid values for input fields. For instance, a numerical ID field may be specified to handle only 5 digits ranging from 0 to 9 with no other extraneous characters. Thus, boundary values are zero and 99999. Any number less than zero falls into one equivalence partition and any number greater than 99999 falls into another.
Thus, you only need test a single number in each partition to validate this negative test. Clearly, many input fields are more complex than this example, which will require more careful analysis of boundary conditions and equivalence partitions and probably some additional exploratory testing as well.
Both positive and negative testing can be applied throughout the product lifecycle starting with unit tests. Positive tests include the straightforward, so-called happy path plus alternate paths that get the user from A to B.
Negative testing includes testing the known error-handling capabilities of the software plus inputs and actions not accounted for by the coder. The scope of negative test cases can be significantly reduced by using boundary and equivalence partition analysis.
Both positive and negative testing are critical to defect detection, which assists in producing the highest quality software product.