This is a guest post by Nishi Grover Garg.
Are you testing with the sole purpose of finding defects? What if you don’t find any? Your testing should deliver more value than just finding bugs. Let’s examine the true goals of testing and aim at achieving all four of them for the quality benefits of our software.
Gaining knowledge about defects
While there is more to testing than pinpointing bugs, finding defects and problems is the first instinctive goal. Looking for places where the functionality breaks or does not work as expected is key.
Testers can adopt a number of approaches, test techniques and strategies to find these problems before users do. This helps the team keep updated on the status of product quality, fix the problems, and improve the software for the users.
If you have been testing diligently and going through a bunch of test cases and various scenarios but haven’t yet found a defect, it doesn’t mean it was all for nothing! If a test doesn’t fail, that means it passed, and that is useful information, too.
Another major goal of testing is to prove that the functionality works fine, and it is that proof that helps us make decisions about its future. Without this proof, we would never have a clear picture of the software’s quality, its intended functionality or whether it’s fit for use. Many teams would also get into problems with regulations, audits, and compliance without this proof of functionality.
Testing also generates a lot more information than just passing or failing tests. Testers generally have loads of questions occur to them while testing. They may be about the need, implementation or design of the features, their related integrations with existing features, or actual usage scenarios. The answers to these questions are paramount in making the feature assimilate well within the software.
Testers also raise awareness related to risk areas and defect clusters they encounter while testing a feature. This information is very useful in redefining the scope of testing and replanning our focus areas.
Where and how to update our documentation, wrong or ambiguous information in our help and user guides, release notes that need to go out, known issues, issues that users reported and their history are all valuable data that we generate and record during test cycles.
Creating this information holds massive importance in release cycles and is imperative in making informed decisions before release.
Confidence is a subjective measure of quality. We often see project managers go to testers asking for their opinion about the stability of certain features and their “feeling” about the release-readiness of the application. By testing the application overtime throughout its sprints and releases, testers know its ins and outs, its failures and shortcomings, and the facts based on failures and reworks.
They also develop an intuition that can be trusted to predict failures and defect clusters. Project managers and other stakeholders trust this experience to gain confidence in the system and use that as a parameter in making decisions about timelines and releases.
As a tester, you are contributing much more to the project than awareness about a bunch of defects. Keep these four main goals of your test efforts in mind and try to contribute to each in the best ways you can.
Nishi is a corporate trainer, an agile enthusiast and a tester at heart! With 11+ years of industry experience, she currently works with Sahi Pro as an Evangelist and Trainings Head. She is passionate about training, organizing testing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
- TestRail Leads in the Fall 2020 G2 Grid Report
- Announcing TestRail 6.5: New Plugins, Enhanced Integrations & Searchable Drop-downs
- Announcing TestRail 6.6 with Enhanced Administration