Importance of Diverse Testing Approaches

So, what is the best software testing technique for my project? Hmmm, tricky one to answer without looking more closely at your project. There are many factors that determine the software testing techniques you’ll need to employ.

You have both internal and external factors that will influence the way you test, from understanding the test objectives to regulatory requirements, so before you pick a model that you think will work, look a little closer at all the conditions. There are so many examples floating around that define techniques that the overall technique will need to be determined by the way in which you have developed your system. Since the testing techniques are largely based on the way a system has been developed, this will ultimately decide the way in which you should deploy testing.

To start with, I suggest looking at the project methodology; Waterfall, Agile and DevOps seems the popular top three, once you understand the delivery model then you can start to look at the level of documentation available. Poor documentation means you’ll either have to revert back to any original business requirements or rely purely on knowledge and experience of the system to see you through. If the project is well documented, then you can look to take a risk based approached, prioritising types of tests by likelihood of system impact if they fail, if within an acceptable amount of risk, then you may decide that a light touch of testing is all that is needed in this instance.

Regulatory and contractual requirements are unavoidable and must be tested to keep you within the legal boundaries set by the authorities and clients/partners. We would suggest that a good level of documentation is kept, being able to prove the rigorous and thorough testing you have performed with results and outcomes all recorded and correctly referenced back to the original requirements.

The other important factors are time and cost; how long have you got to test, how many testers have you got available and how much budget has been set aside for you to prove the application performs as desired? These all might sound obvious, but testing being one of the last activities in the life-cycle will always get affected by project/development over-run, scope creep and moving deadlines, so even with the best planning in the world, you still need to remain flexible to cope with any change in project circumstances. Being able to flex up and down during the test phase will be key to delivering a successful product.

Finally, and this may seem glaring obvious, but the system under test ultimately determines the test technique and the level of testing required. Imagine you’re an online retailer, or a parcel distributor, having any sort of site outage or being unable to process transactions will not only cost you money, but reputational damage that ultimately could lose you customers and land you with a fine, so understanding the importance of the system you are testing will drive the type of testing you will need to perform.

Once you have a good understanding of the requirements, the budget, the system and what you are expected to test then you can choice a testing technique, whether that’ll be Black Box or White Box.

This article is part 1 of 2. The second article will outline the differences between Black and White Box testing.