Using feedback from the tester when defining and designing the product is invaluable to the business. Listening to the needs of the organization, understanding business goals, and personalizing the testing process by incorporating different skills and practices is one way to start testing 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.

We know that testing begins before a single line of code is written, but we are less aware of the extent to which there is no “one size fits all” – every organization has its own people-driven goals. different, Straus explained.

Critical thinking when defining the product can help develop better products, she said. Building a successful product is more than building successful software, as Straus explained:

Successful products are those that solve customer problems and are created by teams of different people, each asking different questions and guided by different emotions and ways of thinking.

For example, product managers will ask themselves what is the most important problem for our customers – because it’s a problem they want to solve, and they want to solve it as soon as possible.

Simultaneously, developers and designers will be looking for an answer on how to solve it, while we testers will come up with “what can go wrong?” At the table and think about ways the product might fail. We research the risks and give suggestions on how to mitigate them.

If we ask these questions while the product is still being defined, it is not expensive to answer them and make changes, Straus said.

Straus explained how we can include critical feedback from testers early in development:

We can always invite a colleague to a meeting or a matchmaking session, chat and find out what risks they see and what are the essential quality characteristics. Then according to this, we can give useful feedback and thus establish step-by-step cooperation. The point is, you shouldn’t wait for information to reach you if we see that we can help and benefit you sooner.

Of course, in reverse, there should be the willingness of colleagues (eg product manager, designer, developer, …) to include a tester and accept feedback. It’s hard to do at first. The tester will likely have to step out of their comfort zone and take the first step. But if we show the value of early collaboration in an example (it can be small projects but important to the business), and if we share the example with the rest of the organization, things will start to starting from a dead point.

The easiest way to ‘get involved’ is to just – to get involved, Straus said:

Of course, I don’t mean to suggest that someone should ‘uninvited’ in the process, but it’s also not good to stay away if we testers see that things have started. and that we can add value.

InfoQ interviewed Irja Straus on the involvement of testers and practices and techniques in the tester toolkit for performing product requirements and design reviews.

InfoQ: You mentioned in your speech that testing can already start in product reviews before the code is written. What would it look like?

Irja Straus: In each company, product creation is different. Therefore, the first challenge is to understand the manufacturing processes of the products and to know the stakeholders and the priorities. As 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 the people who collaborate.

The approach to closing the understanding gap that has proven to be successful is to “listen before you speak”. In practice, this means meeting stakeholders (e.g. product managers, designers), knowing their motivation and goals, building relationships and establishing collaboration – essentially, a feedback loop.

Then it was about exploring customer needs and their user profiles by talking to the product manager (s), reading industry related articles or analyzing customer data, because each user profile has a different purpose and therefore a different task to accomplish in our product. . For me, understanding these differences is essential to knowing what is important to each of them and targeting specific quality characteristics (e.g. data integrity, control, consistency, etc.) when making providing feedback on the design, user experience or requirements of the product. Knowing this information allows me to use stakeholder language when communicating my findings, which makes the comments more relevant to those affected.

In practice, the shorter the feedback loop, the better. To keep it short, I try to be there when the project kicks off and the requirements are set, or when the first prototypes are done, and generally I’m proactive in asking what’s the next big thing, inviting different parties. stakeholders to partner and collaborate closely to discover and share important product information.

InfoQ: What can testers do to get involved in discussing requirements?

Straus: In every company, the business processes and responsibilities are different enough that I cannot answer unequivocally on how to approach this, and I wouldn’t dare to say that this is necessary for every company and every context. But I think the most ordinary conversation with associates, such as product managers or business analysts, about business processes, what is especially important to them and what kind of feedback is most valuable can give a overview of how we can help businesses.

Once we know what those 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 more often than not written 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 the associates – which is also the third challenge, but a little simpler.

InfoQ: How can testers contribute to discussions about design and UX?

Straus: I mentioned at one point the importance of “speaking the language of the speakers”. It is essential to understand their language to contribute to these discussions, i.e. to learn to explain why something is or is not good (enough) and to rise generally above the level of “I like (dislike) but I can’t explain it.” I’m not suggesting that we have to become design or UX experts to do this as testers. Yet knowledge of general practices and heuristics and their adaptation to its context is necessary to contribute to these discussions.

One recommendation where to start is Jakob Nielsen’s 10 General Principles for Interaction Design, and of course – talking to your UX designers and researchers, and asking them to comment on your feedback. 🙂