Given a complex application to test
When have deep knowledge about the application and the domain
Then more high severity issues can be brought to the surface in time
Not every company can afford to let their customers test the application. If customers found high severity issues, that looked bad.
The increase in the tendency of regression issues reported by customers release by release is an indicator.
Something is wrong. It can have many reasons. The cause has to hunt down. It’d better address the phenomenon before the customers leave the company.
It is critical for a tester to have deep product knowledge and domain knowledge in order to be successful in the job. Testers are in the position to see the application as a whole and can give valuable inputs for BAs and devs, technical writers.
When the code is not self-documenting anymore, early requirements are not accessible, no manual test cases exists, intended behaviour becomes a question even though automated tests exists but why are written in that way is no longer known, have many technical debts, then it’s time to spend time on thinking things through and answering some questions.
Let’s start with: why that software exists, what problems want it to solve, what the best way would be for solving the problem? Then you can compare these with the reality.
How to do that?
With a product definition.
Product definition is a high level document about the product, or part of the product, if we are talking about a component. The audience is business people, sales, anyone who wants to get an overview about the key features of the given product or component. Yes, even a component can have its own product definition.
Let’s write one!
Writing itself helps a lot with thinking things through. It’s like observing your thoughts. While putting words on paper our brains read and evaluate what’s written.
Ah, but who wants to have yet another document, that needs maintenance and no one would read!?
You can involve colleagues early on and listen to their feedback, so they are getting engaged too, moreover it helps to create a better product definition.
What outcomes did I see?
During writing the product definition I raised issues that were coming from design, features implemented inconsistently. Have found areas that could be improved to increase the usability.
It also gave ideas on how the product can be improved in the future.
It actually can helped developing a common understanding across teams.
I got responses from technical writers and business analysts of other components that they have learned a lot about this component by reading this document.
It did educate not only me, but others as well. Not only testers.
But it is not a tester’s job!
No. But the initiative can come from testers.
Now the PO owns this document.
But how to write a product definition?
I have never came up with this kind of document before, I had no idea how to write it.
Basically I went through on the features and gave a description about them. Then a Business Analysts came, read through the document, and deleted the half of the document. No implementation detail! Fair point. Visuals also can be used, but forget screenshots.
Is that it? So the product definition solved all the quality problems?
Obviously not. This was still just the beginning. More to come.