4 common Testing Misconceptions

Having spent over 15 years in the testing arena, the QualityTaskForce team know a thing or two about testing and the common mistakes that are made when planning/implementing it. Here are four that occur all too often, sometimes with tangible negative impacts on projects and products alike…

#1 “The developers can test it; they know how all this code works!”

Why hire a completely separate team of testers when the developers who produced the software know the code like the back of their hands? Well, those developers are much more likely to fall victim to cognitive biases such as the ‘Curse of Knowledge’ (where they are unable to view the software in the same way as someone who knows nothing about it would). These biases can result in bugs being overlooked, underestimated, or simply ignored.

On the other hand, testers who have had little or no contact with the product prior to testing will be able to approach the task with an open mind more akin to that which an end user might have. External testers will find bugs that a developer may unconsciously disregard, resulting in a more stable product and a smoother experience for end-users.

With a recent uptake in DevOps implementation, the lines between testing and development have become blurred. Developers are now more likely to be carrying out tests themselves but the previous points still ring true, and dedicated testing should be carried out at the end and at major milestones to ensure quality and prevent bugs slipping through.

#2 Test Automation and Human Testers cannot co-exist

Test Automation covers all bases and should be considered as a replacement for manual testing, right? Wrong; Test Automation should be viewed as a powerful ally or as an invaluable tool in a manual tester’s arsenal.

In the same way that plenty of tests are better completed automatically, there are some that should be conducted manually. Test Automation is a very worthwhile investment in the majority of cases and can be a deciding factor in whether a project stays within its budget. Yet it is often misunderstood; automated testing is not meant to replace testers, it instead allows them to turn their attentions away from repetitive tests towards more unique and experience-related tests.

#3 Testing only needs to be carried out before deployment, not after

When going through the motions of planning a lengthy and/or complex project, testing can often be considered as an afterthought – something that can be done once at the end, when the product is practically finished. This mind-set is encouraged in traditional Software Development Lifecycles, such as the Waterfall model, but isn’t suitable for larger projects.

The reality is that testing is required at various stages, if a large project is going to have any chance of being completed on time and in budget. Not only is it required at before final deployment of the product, but during early development phases, each time changes are made (regression testing), and after the product/service has been publicly launched; just because an online service works perfectly at launch, doesn’t mean it will the next time a major browser receives an update, for example.

#4 Thorough testing is an expensive waste of time

When project costs start getting closer and closer to the budget limit, testing can be one of the first areas to take a hit. Surely some testing can be foregone with time spent on better development practices instead?

Unfortunately, it just does not work that way; thorough testing should be the last thing to lose funding due to the potential expenses that can come as a result of undiscovered product discrepancies. If flaws aren’t found within a project’s testing phase(s) then they will almost certainly be found by end users following deployment – something that can have a devastating impact on user experience.

There are plenty of examples of software gone rogue as a result of incomplete testing; HSBC have suffered through several software related problems over the past two years alone with online-banking outages, failures in the integral BACS system, and more.

Make sure your service or product doesn’t suffer the consequences of poor testing by contacting QualityTaskForce today.