Why did you miss this bug?
Software is kinda like a 1000 piece jigsaw puzzle.
Once it is complete and in the hands of the end-user. It is entirely possible that they will start running into issues. Maybe they cannot find a crucial piece that they need, find that there are pieces that do not fit together, or even discover that the picture on the back of the box does not match the one they are assembling.
We often relate testers roles to the quality of the product we end up delivering to our client’s and ensuring that the quality is the best it can be,
So one metric that we might use to measure quality could be the number of bugs present in a system. You shouldn’t solely use this metric in a real-world scenario. But we’ll use it for this example.
So in the jigsaw’s puzzle case, we could add a test to ensure that we have all the pieces of the puzzle. This could be achieved by doing a count of all the pieces before the puzzle is put together by the customer. That would ensure there are no issues.
But what if something goes wrong that we didn’t test for, is that the complete fault of the tester? And why was it missed?
When a client reports an issue with the software that has been delivered. I would always recommend resisting the initial temptation to point fingers and blame people for their perceived failings.
Much like a house of cards. I find it helpful to think of a software development project in the same manner. If one card which makes up the structure is flawed. The whole thing comes tumbling down.
It is a common misconception that ‘only testers/QA are responsible for the quality’. The reality is that software quality is something that everyone from the project managers to the developers and the testers needs to manage and be responsible for.
Software is complex and as testers, we can’t test everything. So yes, while we can do a mirage of different tests to check the functionality, the documentation, business logic etc. Developers need to be using white-box test techniques to make sure their code is being properly tested and coded correctly.
Instead of thinking about testers as a ‘gatekeeper of quality’. Think of testers as a step in the overall process of delivering high-quality software.
