Kavan has worked continuously to further his skillset. In gaining the ISTQB qualification he provides the highest level of testing at Bolser, keeping up to date with best practices and relevant testing knowledge.

Take a look at Kavan’s key takeaways, as he shares what is required to meet the highest level of testing.

As a tester, being involved early in the development process can mitigate code defects later down the line. More than 50% of code defects originate from faulty requirements. Using prior knowledge and experience, a tester can help identify high risk areas and work with the development team to plan out the approach in the most efficient way. Fixing defects at the design stage is likely to cost up to 30 times more than if identified at the planning stage and up to 100 times more if not identified until the production stage.

Ultimately early tester involvement saves time and money, making the best use of the client's budget, as any potential and predictable issues have been addressed from the start.

A common misconception in testing is that after test cases have been run and regression of the work is complete, the software will be completely bug free. While testing is designed to show the presence of defects, it cannot guarantee the elimination of all bugs in existence.

Exhaustive testing requires you to cover all possible combinations and pathways within the software, which is effectively infinite. An infinite number of possibilities makes it impossible for a tester to conduct exhaustive testing.

Practical testing, using partitioning strategies to represent larger sets of paths or inputs, allows a tester to capture a large number of possibilities and then prioritise the corresponding tests in terms of their risk level.

Effectively identifying ‘defect clusters’ can help you predict areas that will require more attention in quality management and testing. The application of the Pareto Principle to software testing highlights that approximately 80% of the problems identified are found in just 20% of the modules. In other words, identify the most common groups of defects and you have covered four-fifths of the issues!  

Any set of test cases, run repeatedly, will eventually run out of bugs. This can give a false impression that the software is bug free, but does not take into account bugs outside of the areas tested. Much like insects repeatedly sprayed with the same pesticide, the software becomes 'immune' to these test cases. To overcome this and get as close to bug free as possible, repeated analysis, review, and revision of the test cases are essential.

As a tester you develop your own way of working, that you can apply across all your testing projects. However, it’s important to be aware that different hardware, software and requirements are likely to call for responsive thinking, taking different approaches to maximise the efficacy for each specific test case. There is no 'one-size-fits-all' testing solution.

Another myth in testing is the assumption that when all test cases are defect free, the software is also defect free. This would require exhaustive testing of an infinite number of test cases, so even the most rigorous testing program cannot guarantee the absence of all errors. This is why a multifaceted testing approach, with an emphasis on high-risk areas is essential to maximise testing coverage and minimise errors in the final product.

The approach used in testing has a fundamental impact on the success rate of defect detection. Early testing involvement to identify and analyse high-risk areas helps to prioritise and resolve issues efficiently. Ultimately, using a responsive multifaceted approach will lead to smoother development and delivery of projects on time and within budget.

I took a lot from my learnings on the ISTQB Qualification, but these 7 principles will stick with me and are ingrained in my daily work as lead tester at Bolser.