Speaking About Testing To NonTesters

Definition:

The ability to talk about testing with non-testers is a skill that enables tester to explain his ideas about testing in such a way that they are well received, regardless of what technical, philosophical or professional background the other person possesses.

A context where I used this skill:

1. Stakeholder management

There was a concerned raised by our users/business that defects reported by the QA team are more related to technical details of the build and not related to business use, or functionality related failures etc.

Case analysis:

  1. Interaction gap: In my current project, we are a team of 4 testers which provides its services to 7 development teams. There is no direct interaction between Users/Business and testing team because of location constraint (yes, we are an offshore team) but users work closely with Dev leads from requirement specification to solution implementation phase including the planning for release date.

  2. QA not involved in planning/No early engagement: While planning for release date, QA timelines were getting decided by Users and Dev lead, assuming some regression scope and testing of newly build features (change requests, defect fixes etc.).

  3. Users’ and Dev lead’s incorrect notion of testing: They used to do it naturally because their notion of testing was like “It’s just a matter of running regression scripts and tests recommended by users, capture pass/fail and provide sign off”.

  4. The Impact: The communication gap, late involvement of testing team in development resulted in ’turning testers blind to what users actually want’. Testing team could never get idea of what business problems they were solving through their testing.

  5. The Result: Result was obvious. Since builds for testing were always given with release date (which was hard to be changed), my team was getting compelled to stick with doing risk based regression and functional testing of new features with absolutely no time for focused Exploratory Testing. And because of lack of clarity for business purpose of build under test, testing team focused on “implemented solution” which used to have flaws of its own. Testing team was far away from the notion of finding information that users/business could value and consume.

How I used “speaking about testing” skill to solve this problem:

I wrote one email directly to our business users (with whom we hardly ever interacted) with above analysis above and redirected him to “Testing vs Checking” articles written by James Bach, Michael Bolton as well as Iain McCowatt.

I helped them understand that we too are eager to find information they would value but they must understand how we need to test in order to make it happen. What challenges we were facing and what could be done to solve it.

Technically speaking, below are the supporting skills that helped me in this particular context:

  1. Courage to speak up and taking a stand for testing – One can either become people pleasure or can do good testing. I chose to embrace the latter.

  2. Use of References and Resourcefulness – Sometimes, people won’t listen to your ideas simply because they think they are your ideas. But they would usually consider them if you tell them “Experts say so…” by redirecting them to credible references.

  3. Conviction – It is equally important to show conviction towards craft of testing you practice. If you compromise on your principles of good testing in order to solve problems, you will actually make them worse. You must get respected by your stakeholder if you want them to take you seriously. That respect would get developed if you know how to speak about testing.

So was the problem solved?

Indeed! But it did not just solve the problem but helped me in many more ways. Here they are:

  1. This kind of direct interaction with our users helped them form an opinion about me as a tester who knows and practices his craft well.

  2. They became aware of philosophy of testing which was different than theirs and which made absolute sense.

  3. Users appreciated me for redirecting them to Testing vs checking and that is now going to contribute in our all future strategy preparations and planning.

  4. My email has been shared with high level stakeholders in their meetings and they are glad to have a testing team which understands what real testing is. My one email (rather ability to speak about testing) solved many other problems which were difficult to be solved by mere bargain and typical discussions, otherwise.

2. Interviewing testers and getting interviewed yourself

Another context where tester’s ability to speak about testing helps is when she gets interviewed or interviews some tester for hiring in team.

Usually, project teams who are serious about testing don’t just rely on interviews conducted by testing expert but they also interview those candidates by Dev lead, Business Analysts, Support teams, cross functional teams etc.

Difficult situations occur when even expert testers can’t explain testing to people who are not testers themselves (but need testers to work with them of course). This usually happens because traditionally, tester’s mindset differs from other stakeholders’ mindset and that causes the mismatch between notions of testing all of them share. As a result even very good testers get rejected in their assessment. If you know how to talk about testing you can easily deal with such situations. In fact, if you are interviewing a tester for hiring, you can assess her for same skill. Naturally, an individual who can talk effectively about testing would possess solid understanding of concepts, soft-skills and other desired personality traits.

How I’d recommend someone learn this skill:

Here are couple of things you can practice to improve your communication, especially with non-tester audience:

  1. Practice explaining different testing concept with different number of words. For example, practice explaining Black Box testing concept with 50, 150 and 300 words each. Use word counter while doing it and see how effectively you think you are able to explain it. Take feedback from your colleagues.

  2. Especially if your mode of communication is written, write down your thoughts and read them aloud (at-least in mind). Does anything /sound/ chaotic? Unclear? Irrelevant? Wipe it out and write it again.

  3. Practice explaining testing and concepts by imagining how different stakeholders would take that like? For example, how would technical architect thing of your idea, how would business analyst think about it, what objections Dev lead might raise against your ideas?

  4. Try to dig out more and more context before you pass anything as your opinion or your answer. It’s hard to read peoples’ minds when we are in meetings, interviews etc. Especially in cases where people with different idea about testing speak, chances are high that communication would go hay wire. It is important to understand the context in which /they/ want you think and then share your thoughts, ideas (whatever) so that you will speak the language they will understand. Ask context revealing questions (interview them back).

  5. Read more about testing – Nothing beats learning from others’ experiences. You don’t need to go through all sort of experiences yourself to solve similar kind of problems. Read testing blogs, magazines, watch videos and learn (at-least know) how others solved particular problems. Such references help you build your arguments (know why professional lawyers present past judgements by courts to support their arguments?) and mentioning good articles, discussions, papers at right places (and time) also helps you to build your credibility. You don’t need to be an expert in all things but if you know where to look for help, it does help!

  6. Try to get better at Interactional Expertise

Additional resources:

By: Lalit Bhamare

← Rhetoric