Thinking Positively and Negatively in Software Testing
Think negatively. Not a phrase heard every day, but in the field of software testing this is a very important concept.
What is meant by this is that software testers should not just perform positive testing, i.e. testing whether a function works as expected with valid inputs, but also include negative testing, i.e. testing whether a function works as expected with invalid inputs. Software testers should make sure the system works as it is supposed to, but it is a good practice to try to make the system fail as well.
Positive testing involves performing tasks that the customer, stakeholder, or other end user would do, and verifying the system behaves as expected. The idea is to carry out the actions that would be considered normal use of the system. An example of positive testing is checking whether a login page accepts the input of a valid username and password combination. By inputting a username and its corresponding password, a software tester can determine if the system accepts the combination and grants access to the website.
If software testers only use valid inputs in the course of testing, then there will still be huge risks in releasing the software. Thinking back to our previous example of a login page, what if the system allows access to users who input an invalid username and password combination? Or, what if the system allows users to gain access with blank username and password fields? If these scenarios were never tested, the consequences of these security lapses would be immense and costly to both the company and the consumers who use the software.
How should we determine what inputs and processes to use in negative testing? A good approach is to think about mistakes an end user could potentially make and the ways a user could deliberately misuse the system. There are an endless amount of possible mistakes and misuses, but we know that exhaustive testing is impossible. Instead, software testers need to use the software requirements, system specifications, and logic to define categories of invalid inputs. Testing techniques such as boundary value analysis and equivalence partitioning can then be used to settle on specific values to use in the test cases.
In negative testing, when these invalid inputs are entered, we expect the system to handle the values in the proper way. The software should not crash, nor should it behave as if a positive test had been executed (performing the task successfully). Instead, we should expect indications that the user action is incorrect, or simply prevent the user from proceeding. An example test might consist of typing (or attempting to type) 21 characters into a field designed to have a maximum of 20 characters, and verifying the software blocks the user from typing the 21st character or displays an error message that says too many characters have been entered into the field.
EXAMPLES OF POSITIVE AND NEGATIVE TEST COVERAGE