The QA team starts testing a software/product and there are “way too many” defects. Every other scenario is failing, new flows are explored & clarifications sought. What would be the strategy now?
Many a times we face these kind of one-off bugs 🙁 which peep-out and then hide somewhere. “It was a one-off bug and now not reproducible – so what can I do?” Wrong! Though one-off but still it is present somewhere in the software and as a Tester it is our responsibility to investigate it. How?
Adopting technology is important, but blind adoption is different than logical application of Technology. When I see it – looks like everyone wants to fit the tech-term anywhere in the test process and call it tech-driven QA. But how do you measure the ROI from client perspective? Do you compare Super-Tech.QA vs. Functional QA? Or Super-tech-tools are cheaper than the required man power? Nah! Everyone says “All these are long-term benefits, no short-term advantage”, but then eventually forget to measure the ROI in the long run as well 😛 On the other hand, due to all this fuss we have somewhere neglected the original Tester.
The most important yet confused concept – Defect Severity and Priority. Additionally it is one of the most popular Software Testing interview question.
Emails and Excel are not enough to manage defects in a large project. For single source of truth and maintain consistency, we need a Bug Tracking Software.
Everything has a lifecycle – it’s the law of nature, a series of changes in form that an organism undergoes, returning to the starting state. Birth >> Infancy >> Childhood >> Teenage >> Adult >> Mature >> Old age >> Dead end. A ‘Defect’ in Software Testing also follows a pre-defined stage transitions from its identification till its closure. In Software Testing terms, we call it as ‘Defect Status transition’ or a ‘Defect Lifecycle’!