I started the ‘Read Along’ section on my blog last year with my series on the book ‘Agile Testing’ – a much coveted book for all testers. It was a fun way to learn, get back to my reading and also share it with my readers!
2021 started with me finding myself in a new job, an exciting new role in a brand new domain! So, I am taking the Read Along series forward this year by beginning a new book that not only is relevant to my current role and is a recommended read for the ‘Customers for Life (C4L)’ team that I am a part of, but is also super relevant to every software team working on developing software that not only satisfies but wows their customers!
The book is “The Effortless Experience” by – Mathhew Dixon, Nick Toman and Rick Delsi
I will be reading the book and will post about learnings, things to remember & quotable quotes from each chapter as I progress. This is to hold myself accountable, as well as to help people looking for good reads or learnings. Hope this helps you. Have you read this book? Do share your thoughts & learnings too!
Here is a link to get your own copy if you would like to read along-
Defects tend to cluster in some areas of the software under test. It may happen due to higher complexity, algorithms, or a higher number of integrations in a few constrained segments of the software.
These defect clusters can be tricky, both to find and to deal with. Testers need to be on constant alert for ways to isolate defect clusters and devise ways to overcome them, fight those defects and move on to new clusters.
In my article for Gurock blog, I discussed some ways to fight Defect Clusters in Software Testing:
Locating Defect Clusters
Most defects tend to cluster in certain areas of your software. It is one of the seven testing principles. Many testers intuitively know of these defect-prone areas, but we can still strive to be on the lookout for clusters of defects in a number of ways, like utilizing
Using metrics like defect density charts or module-wise defect counts, we can examine the history of defects that have been found and look for areas, modules, or features with higher defect density. This is where we should begin our search for defect clusters. Spending more time testing these areas may lead us to more defects or more complex use cases to try out.
For example, the chart below shows that Module 4 has the most defects, so it would be smart to continue concentrating on that module in the future.
Use the defect management system and the history of the software to go through older defects, and try to replicate them in the system. You will get to know the system’s history, where it broke and how it works now. You may learn a lot about the software and find many new areas to test.
A tester’s intuition, experience and history with the product is by far the best way to find defect clusters. Lessons learned by experienced teammates should be shared with new coworkers so that the knowledge can be passed on, utilized and improved upon by exercising these defect-prone areas with new perspectives.
Fighting Defect Clusters
Defect clustering follows the Pareto rule that 80% of the defects are caused by 20% of the modules in the software. It’s imperative for a tester to know which 20% of modules have the most defects so that the maximum amount of effort can be spent there. That way, even if you don’t have a lot of time to test, hopefully, you can still find the majority of defects.
Once you know the defect cluster areas, testers can focus on containing the defects in their product in a number of ways. Continue Reading—>