How to sell (communicate) testing and QA

Communication

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.

• Do I know what testing and QA mean to me and what is the difference?
• Do I feel (know) that my work presents a contribution to the company? Can I quantify the contribution?
• Do I feel purpose of my current job?

It may sound like a cliché, but still – if we can’t “sell” something to ourselves, we definitely can’t persuade others about it.

Arouse interest

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.

Developers are nuts

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

• Being proud of what they have created – developers are egoists (in a good way), and if we aim in this direction (including questions asked), we have a good chance that they will really think about the quality of their work.
• Gamification and healthy rivalry – developers (not just them) love playing/gaming. And not only them, it is general characteristic of people working in software industry. What about introducing achievements, leveling, skills, etc. instead of boring traditional metrics?
• Time for more interesting stuff than bug fixing
• Less stress
• Realizing value that the solution brings to the customer, based on the knowledge of the customer’s needs
• Good and friendly relations with others
• … think further

Negative motivation for developers

• It may sound strange, but negative motivation is more frequent than positive motivation. The general way of thinking is that we do something, because of some reward, action, expectation, etc.or, even worse, we do something to avoid situation or consequence we do not like.. The worst kind of negative motivation is the one when the driving force is the fear.
• Situations when negative motivation is the most effective of all approaches is sometimes unavoidable, but careful approach has to be taken so that it does not become a long-term standard.
• A few examples from our world
  • Deadline – if it is not ready by a certain time then…
  • Rewards linked to unreasonable targets
  • Harsh and wrongly set metrics – number of bugs, coverage, etc.
  • Fear that if the customer finds “something”, it will be a problem
  • Various unreasonable internal rules, etc.
• An extreme case of negative motivation is the salary. Sure, people go to work to earn money and gain resources. Still, if this is the only kind of motivation for going to work, something is wrong – this is particularly the case in IT. However, it is necessary to realize that people need to get such a salary/reward so that they don’t think about money, but about work at the first place.

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.

I am the Boss

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.

• Risk management – each and every manager knows this kind of analysis so why not to use it from our angle of view? The major principle is identifying the risk, its probability and impact. If we show the risk with high probability and huge impact to the management, there is higher chance that the managers will agree that something needs to be done. And this is the other side of the coin. Yelling and pointing the finger that something is wrong is not enough. A solution needs to be presented. Nobody says that we have to solve everything ourselves, but pointing the finger is definitely not enough. Here are the most typical examples
  • Correcting errors later on is more costly – this graph is widely known and there is no need to explain it. In general, the following is true
  • Technical debt in the form of a number of uncorrected error will always catches up with us.
  • Customer satisfaction can be measured. Involve the customer as much as possible.
  • Let’s divide testing into “has to be tested”, “should be tested”, and “can be tested”. Price up each of the approaches, and if someone wants to make cuts, explain the impact – the most debatable approach is invariably the “should be tested” one.
  • Exploratory testing and other interesting approaches – the management usually knows nothing about them so there is a very good chance to “sell” these them.
  • Automation is standalone and tricky topic – its benefits need to be communicated in an understandable way.
  • The most difficult mission is, once again, that all of us are responsible for the quality and transfer from testing to QA. If there are many errors, let’s suggest a change and we will clearly prove that it is improving (Defect trend chart).
  • Everything can be measured indeed – I recommend the “How to measure anything” book.

Customer perspective

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.

• Something has not been delivered – the customer has to know about it.
• Something has not been tested – we have to tell the customer, and we definitely cannot deliver it.
• There are lots of errors and therefore we spend long hours on corrections and fixing – why should the customer not be informed about it? And be sure – he/she will definitely ask what we are planning to do about it…

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.

Conclusion

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!