What Are the Next Three Signs That Strike Us Most That There Is Something Not “Quite Enough"?
Sign 6: Listen to The Testers’ NO
Always listen to your employees if they are raising legitimate issues or notice problems that you were unable to see. The value of a good tester partially lies in comprehending the project they are working on and their understanding of the values of a well – tested application, etc. So, when you are considering releasing your software and your testers tell you that the time for testing was not quite enough, then you should consider devoting more time and/ or resources and continue with it.
What is usually met, despite the ideal situation above – when the consideration of the testers are taken into account and more time for testing is given, is the lose – lose situation – you report the software is not ready for production – you are blamed for the delays; you certify it is OK, instead, the software goes live, many bugs are found by the end – users – you are blamed again.
Avoiding this situation is not easy, but when your considerations are well – structured, supported by clear evidence and presented in a good manner, it will be clear that you did your best not to release a lousy product. In this case, having legitimate considerations, it will be more difficult your proposal for delay to be turned down.
Accept that having to say “NO” is not an easy task and it is usually the testers who bring the bad news. So, they become the enemy of the project, at least for the time of the “NO”. To avoid that, set clear roles, responsibilities and procedures.
Sign 7: Early PreventionNever skip involving the team in some of the most crucial activities for every software project:
Because, preventing bugs now saves money later and it is clear that it is 4 to 5 times more expensive to fix a software bug after release, rather than during design. Not only releasing a product with many bugs is a disaster for the reputation, it can also cost the loss of lives.
Time Taken To Fix Bugs
Sign 8: No Development InvolvementDo not consider that unit testing is not worth your time. We, at Quality House also believe that unit tests should be written and executed by the developers, not the testers in the team. Unit testing is natural to developers and quality of the software is a team responsibility, not only of the Developers or the Testers, or the Managers.
By engaging the developers in the Unit testing, you may rest assured that some bugs will be found earlier in the development cycle and will not hinder the further development of the software product.
Our topic comes to its end. Only one article left devoted to the remaining two very important signs: “Time problems” & “Testers keep quitting “.Keep an eye on our Knowledge Hub so you don't miss it.
Quality House Team
Quality House Team