Software Testing Techniques : Positive vs Negative

Positive Software Testing Techniques

Positive software testing techniques focus on validating a predefined expectation. In other words, these techniques help you verify that what is supposed to happen actually does happen – otherwise you have a bug.

Positive techniques follow the “happy path” that a user or program should take. For instance, a positive test for your browser could be to select the button. You expect your browser to take you to the last page you viewed. That is a positive testing technique.

When testing from a “Positive” perspective, you pretty much leave the program’s variables in a state you would expect to see in the real-world. The program should be within its expected, defined limits so that you can properly test it.

• Acceptance Testing – Testing conducted to determine whether a software build is of acceptable quality to test further. Normally performed to validate the software meets a set of agreed acceptance criteria. Using this software testing technique in a “positive” way means that you are focusing on a user’s “golden path”. Your goal is to validate that if you do exactly what you are supposed to as an end-user, that everything works as it should.

• End-to-End Testing – Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

• End User Testing – Just like it sounds, this software testing technique is geared at mimicking the behavior of the target market; the “end user”. To accurately execute this testing, you need to know who the expected consumer is or will be – otherwise you are wasting your time.

• Functional Testing – Testing the features and operational behavior of a product to ensure they correspond to its specifications.

• Initial Impression Testing – To be executed intermittently across the entire project schedule, this software testing technique helps to ensure you get “new eyes” on the project. Use a tester that is not familiar with the current state of the program, have them look at it for the first time and just try and use it.

• Integration Testing – Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.

• Regression Testing – Testing a previously tested program following modification to ensure that faults have not been introduced as a result of the changes made.

• Smoke Testing – A quick-and-dirty test that the major functions of a piece of software work. The name of this test originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

• Unit Testing – Testing of individual software components. Often this testing is performed at the code level.

“Negative” testing does not mean that you want something to go wrong, simply that you are working outside what the developer expects in terms of end-user behavior. You test the internal rules of the program. You challenge the program by severely changing the external variables.

Contrary to a belief held by so many developers that the end-user will only use the program correctly, and as it was intended, Negative software testing techniques help verify the results when the user behaves otherwise. Although often the question posed to QA is something like, “What made you think to do that?” discovering the real limits of a program and how it handles the violation of those limits is what is important. As a QA Professional, I always wondered of the developers, “Why didn’t you think of that?”

Implement them with happiness and joy, and Negative techniques will bring you a bounty of bugs. To enhance the efficacy of any error-handling techniques, watch your family and friends as they try to use software programs and note to yourself…”that was an odd thing to try.”

• Acceptance Testing – When Acceptance Testing is used as a “negative” testing technique, you are trying to validate that any major testing impediments are not present. In other words, you perform testing that the program was not designed to enjoy, but is able to cope with. If it fails, then the build is not “accepted”.

• Ad Hoc Testing/Exploratory – A testing in which the tester tries to break the system by “randomly” trying the system’s functionality. This software testing technique is not truly random when executed properly – but it may seem like it to the untrained eye. The tester’s curiosity, insight, and experience drive this technique.

• Boundary Testing – This software testing technique explores the limits of a system by altering the internal variables; probing of the program’s own rules, from within. Even if the program does not execute every functional variable thrown at it, the program’s error handling should be thoroughly taxed in these tests.

• Chaos Testing – Like it sounds, this technique seems to have no rhyme or reason. However, like any other type of testing, you should track what you do (preferably planned) so that you have an accurate record for later use. I have actually written tests that instruct the tester to hold the key for 5 minutes – or to simulate a cat walking across or laying on their keyboard.

• Smoke Testing – A quick-and-dirty test that the major functions of a piece of software work. The name of this test originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

• Stress Testing – Testing the limits of a system by altering the external variables. Change the rules that the program assumes are in place controlling its environment. Using this software testing technique can push not only the limits of what the program can handle, but can also help you gain insight into more useful and effective tests to add to your repertoire.

• Unit Testing – Testing of individual software components. Often this testing is performed at the code level.