Utilizing the tester’s feedback during product definition and design is valuable for the business. Listening to the organization’s needs, understanding the business goals, and customizing the test process by incorporating different skills and practices is one way testing can begin while the product is still "on paper".
Irja Straus, senior quality control analyst and team leader at Infobip, explored how testers can contribute to product definition at ConTEST 2021.
It’s known that testing begins before a single line of code is written, but it’s less known how exactly as there is no "one recipe for all" - every organization has its own goals driven by different people, Straus argued.
Critical thinking during product definition can help to develop better products, she said. Building a successful product is much more than building successful software, as Straus explained:
Successful products are the ones that solve clients’ problems and are created by teams made up of different people, each asking different questions and guided by different emotions and ways of thinking.
For example, the product managers will ask themselves what’s the most important problem for our customers - because this is a problem they want to solve, and want to solve it as soon as possible.
Simultaneously, the developers and designers will look for an answer on how to solve it, while we, testers, will bring "what can go wrong?" to the table and think of ways the product can fail. We seek out the risks and give suggestions on how to mitigate them.
If we ask these questions while the product is yet being defined, it is not expensive to answer them and make changes, Straus said.
Straus shared how we can include critical feedback from testers early in development:
We can always invite a co-worker to a meeting or pairing session, talk, and find out what risks they see and what are the essential quality characteristics. Then depending on that, we can give useful feedback, and so step by step establish cooperation. The point is that you should not wait for information to come to you if we see that we can help and benefit earlier.
Of course, in the opposite direction, there should be the willingness of the co-workers (e.g., product manager, designer, developer, ...) to include a tester and accept feedback. This is challenging to achieve at first. The tester will likely need to go out of his or her comfort zone and take the first step. But if we show the value of early collaboration in one example (it can be some small but significant projects for the company), and if we share the example with the rest of the organization, things will start from a standstill.
The simplest way to "get involved" is to simply - get involved, Straus stated:
Of course, I don’t want to suggest that someone should "enter uninvited" into the process, but it’s also not good to stand aside if we testers see that things have started and we can give added value.
InfoQ interviewed Irja Straus about involving testers and practices and techniques in the tester’s toolbox to perform product requirements and design reviews.
InfoQ: You mentioned in your talk that testing can already start in product reviews before any code is written. How would that look?
Irja Straus: In each company, creating products is different. Therefore, the first challenge is to understand the processes of building products and know the stakeholders and priorities. Since I was a product manager in the same company, the first step was not difficult, but it can be a challenge if there is no understanding between people who collaborate.
The approach to closing the understanding gap that has proven successful is "listening before talking". In practice, this means meeting the stakeholders (e.g. product managers, designers), learning about their motivation and goals, building relationships and establishing a collaboration – basically, a feedback loop.
Next was to explore the clients’ needs and their user personas by either talking to product manager(s), reading industry-related articles, or analyzing customer data because each user persona has a different goal and therefore a different task to complete in our product. For me, it’s essential to understand these differences to learn what is important to each one of them and aim for the specific quality characteristics (e.g. data integrity, control, consistency, etc.) when providing feedback on design, user experience, or product requirements. Knowing this information enables me to use the stakeholder’s language when reporting my findings which makes the feedback more relevant to whom it concerns.
Practically, the shorter the feedback loop, the better. To make it shorter, I try to be there when the project starts to kick off and requirements are shaped, or when first prototypes are done, and generally be proactive by asking what’s the next important thing, inviting different stakeholders for pairing and collaborating closely to discover and share important information about the product.
InfoQ: What can testers do to get involved when the requirements are being discussed?
Straus: In every company, business processes and responsibilities are different enough that I cannot answer unequivocally how to approach this, nor would I dare say that it is necessary for every company and every context. But I believe that the most ordinary conversation with associates, such as product managers or business analysts, about business processes, what is specifically important to them, and what kind of feedback is most valuable can give insight into how we can help business.
Once we learn what these business goals are, we can help associates by providing feedback on requirements by analyzing the risks that threaten them. The challenge is that these goals are most often not written down in these requirements. The second challenge is that there are no exact specifications of the requirements - and this leads to the need to initiate a discussion (e.g., schedule a meeting) on the requirements with associates - which is also the third but somewhat simpler challenge.
InfoQ: How can testers contribute to design and UX discussions?
Straus: I mentioned at one point the importance of "speaking the language of stakeholders." It is essential to understand their language to contribute to these discussions, that is, to learn to explain why something is or is not good (enough) and to generally rise above the level of "I (don’t) like it but I can’t explain it". I’m not suggesting that we need to become design or UX experts to do this as testers. Still, knowledge of general practices and heuristics and adapting them to one’s context is necessary to contribute to these discussions.
A recommendation of where to start is Jakob Nielsen’s 10 general principles for interaction design, and of course - talking to your designers and user experience researchers, and asking them for feedback on your feedback. :)
