The job of a tester is a technical one, requiring special skills. It therefore seems obvious that testers are faced with challenges linked to the technical nature of testing or certain activities.
However, like any other job, testing is not limited to purely technical matters! This is all the more true in testing, where testers are required to communicate on notions of quality, risk management and trust with a wide range of people from different backgrounds.
In this article, we present some of the human challenges that testers frequently encounter.
Agile teams are small, multi-disciplinary teams. They must have all the skills needed to create the product they are working on. This includes all testing skills (analysis, design, communication, automation…), whereas in many teams there is only one tester… who must therefore, on paper, have all these skills… which is rarely the case.
Similarly, an Agile team is, as its name suggests, a “team”. It is a human group, and integration into any group is not necessarily easy.
Finally, an Agile team works on a product that it generally knows very well. Arriving along the way requires an increase in skills.
The combination of these 3 points creates real challenges for a tester, who has to be accepted by the team from a human point of view, but also from an operational one, by being the quality and test referent… on the specifically developed product.
The association of these skills sometimes leads to rejection by the Agile team, who may consider, after a while, that the tester is not contributing as much as expected.
It’s very rare to have all the skills needed by an Agile team as a tester. If you add the ability to understand and know the product well, and have an affinity with all the team members, you’re in the realm of the totally improbable.
We must not forget that, as an Agile tester, you are part of a team. And in a team, whether in Agile, sport or any other field, you help each other out. As a tester, you shouldn’t hesitate to work with other team members (developers, business, ops, etc.), and to get help with certain tasks you haven’t mastered.
Similarly, it’s always a good idea to exchange ideas with your peers through communities or events dedicated to testing, in order to improve your skills in certain aspects of testing.
Finally, it’s equally important not to want to revolutionize everything before having fully understood the team’s context, needs, problems, strengths and, above all, its product. Wanting to change everything without having acquired legitimacy within the team is often synonymous with rejection, but also with inappropriate recommendations.
Finding anomalies is good, but correcting those that need to be corrected is better. The same goes for improvement actions, identifying them is good, but implementing them is better.
You’ve no doubt recognized certain situations. The tester’s job is not limited to identifying defects, assessing quality levels or identifying improvement actions. It is essential that this work leads to progress and improvement. Unfortunately, being convinced of the validity of your actions (or being right) is not enough to convince your interlocutors.
Testing depends on the context, and so does communicating with your various contacts!
It’s important to familiarize yourself with the people you’re working with, as well as the product you’re testing, so as to be able to find the right arguments to correct an issue, initiate improvement actions or warn of an insufficient level of quality.
Similarly, communication with technical people (e.g. team developers) and functional people (e.g. PO, project manager, etc.) needs to be different, as expectations and objectives are not the same.
It’s also important to know when a battle is “lost in advance”, so as not to exhaust yourself. Implementing a test strategy can be valuable… But if you can’t convince your team members, it may be because the team doesn’t feel the need for it yet, or because there are other, higher-priority issues.
It’s normal that we want to reintroduce testing techniques and strategies or approaches that have worked in our previous contexts. It’s typical that you want to use tools that you’ve mastered and that you’re familiar with.
Unfortunately, this approach quickly reaches its limits, because testing depends on context, and that context depends on the software we’re working on, as well as on time. So, even if we continue to work in the same team and on the same product, testing approaches like tests, they wear out (the pesticide paradox).
To avoid a deterioration in quality, it is essential to challenge oneself regularly and to question oneself in order to evolve with the context.
It’s important to know production inside out, to keep your campaigns moving forward, and to exchange ideas with team members and peers to identify potential weaknesses and areas for improvement.
In fact, you have to remain curious and have a constant desire to move forward. Nothing can ever be taken for granted… and that’s what makes the job of a tester so fascinating… and so difficult to automate!
Defining a quality level is a complex matter. To do so, you need to define your testing approach. Unfortunately, being able to define this level is not enough! It’s important for the tester to be able to make his interlocutors understand this quality level.
Indicators are a good way of doing this, but in the final analysis they are not enough. A tester needs to be able to quickly convey the ins and outs of production deployment. What are the risks? What are the known and uncorrected defects? What is their impact?
You’ll see that this is the job of a well-known deliverable: the balance sheet! In practice, you need to work hard on this review, but also practice presenting the facts concisely and clearly orally to ensure that you understand them.
It’s important to define your indicators clearly and to make them transparent. This requires good traceability management. Communication must also be adapted to the audience… which brings us back to the challenge of “convincing your audience”.
Testing is generally seen as a cost center. Even if this view persists, the facts show otherwise. If that wasn’t the case, companies wouldn’t be testing!
Nevertheless, it remains important to invest in testing in order to make it more efficient, and this is not always easy. Indeed, the budget for building software products is limited, and investment in testing comes “at the expense” of potential additional functionality.
It’s important to get people to recognize the “value of testing”, to remind them of the benefits of testing, both from a financial and non-financial point of view.
For the financial point of view, there are frequent indicators such as the cost of detecting bugs in production and in testing. This calculation shows the savings made by testing thanks to bug detection. It is also possible to have indicators on time savings, notably with the percentage of time spent correcting bugs in production.
From a non-financial point of view, testing provides quality information for decision-making. Information is a vital element, and even if it doesn’t directly earn money, it brings confidence. Testing also ensures a level of quality that benefits the brand image of the company and/or the software. This quality builds loyalty and attracts new users!
To learn more about the challenges faced by testers, stay connected. I will soon share with you the technical challenges and some tips associated.