Finding bugs in any software is the main goal for the testers, which essentially involves verifying that the desired software completely provides a solution to the problem of an end-user. However, no interface has been developed that can predict all the ways users can run amok operating the software. Hence, quality assurance teams must also verify that the software fails gracefully against crashing into the face of incorrect usage or bad input.
Two types of testing are used in software testing: negative and positive testing.
Positive Testing
Another name that is used for positive testing is “testing the happy path.” Positive test trial program actions and inputs not expected to produce bugs and errors. Testers usually start with positive testing in order to confirm that the software works in the most efficient way.
Most programs have some other paths for achieving a single task. For example, in a hotel application for booking, the customer starts at point A with a clean slate and try to reach point B, and the point B is a room reservation process for a specific date.
A versatile, user-friendly booking app may authorize some alternate ways that traverse the user from point A to point B. One user can identify a price range first, then he may select a region where to get a room and then go to the hotel ratings.
Negative Testing
Negative test cases actually seek out the consequence of misbehavior on the part of the programmer or a software user. It is tested to see if the desired program can handle a bad situation in a fundamental way or not.
However, no programmer can expect every path their software might fail. Usually, they skip error paths because they make conclusions about user behavior. Negative tests of this class that precipitate unanticipated bugs and errors demand high levels of intuition and creativity from software testers to root out such defects and deficiency.
Compiling both Test Cases
Positive test cases give a behavioral baseline, so they list those tests first. As the both test cases are compiled, apparent the negative test cases will arise naturally. I.e. if the user application has a widget or sign-on page, the positive tests make sure that the application handles the authentication information that is expected, like a user name, a numerical ID of any user or a password. All of these fields already have an identification as to the expected input, e.g. numbers, letters and a selected set of acceptable string lengths plus some special characters.
Boundary and Equivalence Analysis
The things that a software should not do is usually a larger set than the set of the things what it should do. So, you need to shorten the negative test cases to an achievable quantity. Two main techniques used for this are equivalence partitioning and boundary analysis, and both are usually used in relation to one another.
The program requirements usually define the range of the valid values for the input fields. For example, a field of numerical ID may have to be specified to handle only 5 digits that are from between the digits 0 to 9 with no other irrelevant characters. So, the defined boundary values are zero and 99999. Any number that is less than zero will automatically fall into one equivalence partition and any number that is greater than 99999 will fall into another.
Thus, you only have to test a single number in each block or partition to verify this negative test. Obviously, many input fields you can find that are more complex than the given example, so you will need more careful analysis of equivalence partitions and boundary conditions and maybe some additional exploratory testing as well.
Final thoughts
• Both types of testing can be used throughout the software’s lifecycle starting with unit tests. The positive tests cover the straightforward, so-called happy way and the alternate ways that get the user from point A to point B.
• Negative testing includes testing the capabilities of known error-handling of the software plus actions and inputs not accounted for by the coder. The range of negative test cases can be remarkably decreased by using boundary conditions and equivalence partition analysis.
• Both types of testing are critical to defect detection, which accommodates in developing the highest quality software product.