Testers are in charge of QA intelligence. Interview with Joel Montvelisky. Part I
For the past fifteen years, Joel Montvelisky has been a tester, QA manager, and consultant, working with both small and large organizations in the Silicon Valley and worldwide. Joel believes that testers should always strive to provide more QA intelligence value to their organizations and to expand both professionally and technically. As principal solution architect at PractiTest, he works with hundreds of teams worldwide, gathering knowledge and experience on the changing roles and the challenges testers face in today’s dynamic reality. Joel is a blogger, Co-Founder & Editor of Think Testing, the first Testing Magazine for QA Professionals in Israel and collaborator in multiple QA communities and testing medias.
Joel is a cosmopolitan. Being born in Costa Rica he now lives in Israel with his wife, 3 kids and a dog. He is a Testing Professional and that explains a lot. “The main link for all my tasks is the fact they are centered around the world of Testing” – that is how he is describing his life.
a1qa: Joel, when you say «quality», what do you mean by that? Do you actually feel as a good technical specialist but merely a bug-finder or you prefer to be considered as customer`s advocate to some extent? What is your place on this scale?
Joel (J.): I believe QA outsourcing needs to have a purpose, and that purpose cannot be solely detecting the bugs. Let me even go further than that, I strongly believe that finding bugs is mainly the responsibility of developers. They must have the processes and tools (e.g. functional and technical reviews, unit tests, etc) that will allow them to find these bugs by themselves.
Of course we as testers should help developers in this task by guiding and teaching them, but in the most logical way, if a developer wrote (a piece of code that introduced) a bug, then he or she should be responsible for finding and correcting this bug.
Our direct responsibility on the bug-catching front should be to serve as an additional line of defense that will find any final issues left in the product. But in the same sense that you don’t drive carelessly because you are wearing a sit-belt, developers cannot code carelessly because we will test the product after they complete their work.
OK, so if we are not in charge of catching bugs, then what is our purpose within the process?
As testers we are in charge of Project and Product Intelligence, or simply put QA Intelligence.
QA Intelligence is the information and more importantly the “visibility” that allows our stakeholders to make their decisions.
What stakeholders and what decisions? This will vary from project to project. In one project it may be the Product Manager who wants to know if the system will answer the needs of the End User. In another project it can be Marketing and Sales Team that need to know if the project will meet its timelines and so decide when to schedule their marketing campaign and sales accordingly. And in another project it can be the End Users themselves, who want to know if the system has been developed correctly before paying the vendor for it.
Even though we are called testers, we actually are in the process of information. Testing is only one of the means (the most common one maybe) that we use in order to achieve our objectives.
a1qa: Basing on your experience can you name the most common questions asked by customers during your career? Could you share some of your communication tricks helping QA people to communicate with customers? In other words… how to translate from Testing into customer’s language and to be understood?
J.: Tell me who are your customers and I will tell you what they want to learn…
But be very careful, most of the times your customers will not necessarily be your End-Users.
Having said that you need to start by mapping the customers of your testing, or as I explained previously of the information you are gathering as part of your testing.
Still, to answer your question, most customers will want to know two main things:
First of all they will want to know if all is working according to plan. And they are referring to timelines, functionality, performance, etc. So you should not base your answer on features alone, but taking into account all aspects of your project and its timelines.
The second thing they will want to know is, in case “not all is going according to plan” (and this is usually the case), what is it about the project that is not processing according to plan.
This sounds simple, right?
No!
1. Politics and your sense of camaraderie will get in your way.
2. Not all that is going on in your project is actually known to you.
3. Things change all the time.
and
4. YOU might be the part of the problem.
So take that into account, when trying to answer your Customers questions.
Maybe most important, it is not only about what information you provide, but how and when.
As you asked, on what language and on what time should you provide the information in order for this information to be useful and understood by your customers?
When should this information be provided? When it is USEFUL and when it can HELP your customers to make their decisions.
How should this information be transmitted? In the language they are familiar with! Technical people want to hear technical stuff, and business people want to hear business stuff (mainly because they don’t really understand the language of the other side). There is no way around it. It will be not enough to provide the information in the way that you found it. You will also need to provide it in the language they understand.
In the continuation of the interview we`ll talk with Joel about tester skills and tools for use. Reach Joel on Twitter, and subscribe to his blog.
