Sunday, 16 July 2017

Hiring problems emerging from not knowing what a testers responsibilities are.

  • Does it matter to you as a hiring manager to know and share what a tester’s responsibilities are?
  • Does this knowing shape what a tester does in the role of a tester?
  • Does this knowing shape the future of testers and testing?
  • What gets communicated as a tester’s responsibilities does affect what a newbie /clueless tester does at his / her first job. It takes a rebel and an educated tester to question the norms. My education on software testing was that of the traditional sorts — write test cases by looking into the FRS, send it for review, rework on the review comments, execute the tests and log bugs against it. When I did something out of the recorded tests — one of these 3 happened: ‘In awe!’, ‘Why did you do this?’ or ‘Who detected this?’. 1. In awe because a new tester swayed away from test cases (It was unheard off for some that a newbie cannot follow the rules set). 2. Why did you do this was because it is not recorded as one of the test cases (and is not reviewed) and who will now explain the involved that we have a new test :). 3. Who detected this because the bug was disguised as a feature and remained undetected for a while when test cases were followed as is.
  • How often do we witness and/or encourage a tester who questions the norms, professionally?
  • How often are the testers educated in software testing, prior to joining an organization as a tester? Is the syllabus for software testing formed with the consensus from any of the active software testing practitioners?
  • Are we equipped to encourage newness/questions that come our way when we make a hiring (accept/reject) decision? How often do you sum up your energy to ask for the reject reason? In the biased world, it is safe to sometimes not ask for the rejection reason. But when we do ask, know that they may or may not reveal the real reason.
  • Does it matter to you to know that you hired right? Maybe you did hire right, but the system and the processes followed in the organization remain unquestioned and you get a feeling that 'You don't fit in' or someone you hired doesn't fit in. 

An attempt to share a tester's responsibilities (actual versus the expected) is made here. 

A lot of this learning comes from the notes, articles, books I have read, being present at the test-opsy session conducted at StarEAST[2016] by James and Jon Bach and Michael Bolton. And by witnessing tasks I carried out in the role of a tester. In itself, this work is incomplete and there is scope for improvement as I see that contributing to building testing community, one own's credibility is also part of a tester's responsibility. 

Some of the questions that helped me frame the map are below:

  • What does a tester do? 
  • How do I define a tester?
  • What kind of responsibilities suit this tester versus that tester? (Automation / CodeJunkie / Script Kiddie / ET)
  • What else does a tester do? 
  • What matters? What doesn't matter?
  • How can I help? Who can I seek help from? 
  • Does this process versus that matter? What matters to the organization may not matter to a commoner / a user. 
  • How to communicate the good and the bad news about the product's quality? 
  • Is the information shared useful? useful to the relevant?

(Click on each of these images below, to view their enlarged version).

A typical CV would contain keywords such as the above for an automation test engineer and a traditional test engineer. But is that all, what a tester does and defines with everyday learning? 
A tester does more than document tests, prepare the tool to perform the tests and as part of performing testing, a tester also needs to learn, perform, be and become a tester eventually. See below for some of the other skills a tester needs to be educated in and be equipped with.

The process is for the program/project to run smoothly. Do not discard a tester/CV/resume because it lacks domain/process knowledge/information in it. How we design, program, test, the build should reflect the quality of the product that a user operates.

What matters to the business and the user is important. But what matters to a tester is equally important. If you are learning, you are growing.

Does this know-how help you to shape better questions to ask when you meet a tester to hire him/her? 
Does this make you rethink how / whom to hire? Am I asking the right and relevant questions to a tester who's being interviewed?

Add your comments below, how would you define a tester's responsibility differently when you share what a tester's responsibilities are. 

Do this exercise with your testers (already hired). 

Exercise - What tasks a tester is bound to do when they explore the requirements or perform a product walk-through? And take notes.

If there are no questions at the end of this exercise, then the client is not going to be happy with the testers hired. Hire better. Design the tests to test the tester better. Learn a way to solve hiring problems. 

Finally, s
hare an honest feedback of the candidate interviewed, and it's important to do it.


vijayakumar said...

Blogs sounds much to me and it given a detailed gap analysis of my role. Thanks.

In your mind map of tester reponsibility, test cases writing should be listed under skills. Since understanding requirements itself require skills and writing a test cases based on the broad vision of requirements will result in full coverage testing.

Jyothi said...

Thanks Vijayakumar.
I'd rather say test idea generation is a skill, which we can learn in detail and include as a skill.