Practical Software Testing Techniques

There are so many different software testing techniques that you can use on your projects. Whether you decide to automate or just execute manually there is a selection of techniques to choose from. Make sure you select a range of techniques that will help to ensure the most effective test coverage.

If you are a QA Lead looking to improve your testing, I know you will find several useful options below. Look for tools that will help you move to the next level. Pick one and try it to see if it will enhance your work. Add it to your repertoire if it is a good fit.

If, as a QA Manager , you are assembling a complete battery of tests, then hopefully the selections below will give you a place to start. Choose techniques that your team will be able to apply quickly and most effectively so that you have maximum amount of time to make any real-time adjustments.

The techniques you choose to employ will vary depending on many factors:
• What you are testing
• Resources available for testing
• Time allotted for testing
• Available expertise
• Experience

Some techniques are straightforward; others require a little experience to really employ effectively. The beauty of software testing techniques is that the more you use each the greater insight you will gain. You will understand when to use them, how to implement them, how to execute them, and will have a clear knowledge of which ones to use in any given situation.

Most projects will require you to use several software testing techniques to ensure thorough test coverage. Some techniques are quick and some take days. Some techniques require questioning the code logic, others just validating the user’s preferred “golden path”.

I have separated these software testing techniques into three categories for ease of understanding; Positive, Negative, and System-Based. There is definitely overlap, but I hope that my explanations help simplify and clarify what can otherwise become very confusing.

One note regarding terminology: I have chosen the most commonly popular names (as I have experienced them over the years) for each technique. You may have heard these techniques referred to by different names. Please don’t get stuck on which names each technique is given; focus on what it is and whether or not it can be useful to you.

Positive Software Testing Techniques

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.

• Compatibility Testing – Testing how well software performs in a particular hardware/software/operating system/network/etc. environment.

• 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.

• Localization Testing – Testing software specifically designed for a specific locality – this testing focuses on language.

• 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 Software Testing Techniques

“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.

System-Based Software Testing Techniques

Using these techniques as a one-time validation only, truly limits their value. Each of these is most informative when used to measure against previously logged results. This means that you need a baseline to start with (the first test). As you continue to execute each technique, you gather more and more data that can be compared to the baseline as well as to the body of data as a whole.

• Benchmark Testing – Tests that use representative sets of programs and data designed to evaluate the performance of computer hardware and software in a given configuration.

• Endurance Testing – Checks for memory leaks or other problems that may occur with prolonged execution.

• Load Testing – Testing that creates demand on a system to define its limits by measuring the system’s response.

• Performance Testing – Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users.

• Soak Testing – Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.

• System Testing – Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.

If you think that other software testing techniques would serve you better, ask yourself (and answer) “Why?” Ask what was missing; could you have implemented or executed the technique more effectively? Or did the technique not meet your needs.

You must ask the right questions to get the right answer.