Communication is an interaction between two or among more sides. However, there is one important prerequisite – we have to be fully convinced what testing and QA are for us and we have to believe in it ourself. I would like you to ask these few questions to yourself.
It may sound like a cliché, but still – if we can’t “sell” something to ourselves, we definitely can’t persuade others about it.
Let’s presume that we are committed, enthusiastic and prepared to bring others to the sunny side. The good thing is that if it is really so, we will certainly arouse interest. There are not lots of people of this kind. Still, how to speak about testing and QA, and who should be the audience?
Let’s divide the target group into two major subgroups: internal and external. The internal subgroup comprises suppliers, the external one comprises customers. It sounds weird as all of us should be in the same boat, but it is reality in most cases, and therefore it has to be taken into account.
The internal subgroup can be further subdivided according to roles – we are in touch with developers and managers most often.
The developers are a hard nut to crack, and the group is really specific, a species of its own. Still, it can be an advantage. How to deal with the developers then? Each and every of us needs to be motivated. There are generally two kinds of motivation: positive and negative.
Positive motivation for developers
Negative motivation for developers
The main goal is that developers (and everyone else as well) become aware that quality is not what testers and QAs are responsible for, but that the whole team is responsible for it. In other words – testers are not a kind of safety net for the development (with the exception of safety critical cases) and that errors need to be prevented first of all. However, we have to expect that a helping hand is necessary – and this should be out major mission. Indeed, it is a big change of the way we work and even how we think, and it cannot be implemented overnight. The cliché that all of us are on the same boat – applied to the tester-developer couple – is true. And it is best if the boat is actually pretty small as lots of problems get lost on a steamship, but it cannot happen on a rowboat for a few people.
Management is the second group that we often get in touch (dispute) with, and the new aspect of this area is that there is often a lack of knowledge and understanding on both sides. How many managers are actually experts in testing and quality control? How many testers are actually experts in managements? Common ground needs to be found – figures and metrics can serve the purpose.
It was said at the very beginning that the prerequisite is that we know why we work on projects. And it is necessary to quantify the fact. Testing tends to be under-financed as the management is not aware of all risks, costly repairs and corrections, etc.
Let’s move to the customer’s side now. In the Agile environment, the customer should be a part of the team, and the level of his/her integration predetermines how far he/she will understand the purpose of testing and to what extent he/she will be its part.
If the customer is not involved, he/she sees everything only as costs. Then we cannot blame him/her for the unwillingness to pay for something that he/she does not understand.
The first step to improve such understanding is full transparency. The customer is our partner, and therefore he/she should known the truth. I am not saying that we should share absolutely everything with the customer, but plans and results should not be tabooed and amended in any ways.
Let’s build the relationship with the customer and involve him/her in the testing process. If the customer is aware what and why we are doing, there is a great chance that he/she will support us. If it is still not working well, the risk management has to come into the stage again. And this is something that the customer simply has to understand.
The most important fact remains that our solution has to present real value so that the customer is literally overjoyed about each and every delivery. If this is the case, he/she will even forgive you a lot – not all bug will be critical any more, etc.
How can we help the customer even more? After all, we need him/her to test and accept what we deliver on a regular basis (after each iteration). No customer is an expert in this area. However, we are experts. Let’s show him/her how to test, how to report errors, how to prepare data… The customer will definitely appreciate it and – most importantly – understand that we know what needs to be done. And he/she will trust us.
As a conclusion, I would like to say that compromises are important. They help us keep the down-to-earth approach and find the solution. However, we should never confuse a compromise with resignation. Never ever compromise your goals if you believe in them.
Do you share our view? What is your experience?
Interested in the topic? Come to see us at Impact Hub Ostrava and discuss it over cup of coffee!