Why don’t testers ask questions any more?

Asking questions is a corner stone of good software testing and asking educated, probing questions throughout the software development lifecycle is an unrivalled tool for both preventing bugs and for learning about the product, technology and business environment.

The challenge I often face as a leader of software testers however, is that the testers I work with sometimes fail to ask the right questions at the right time.  From my years of experience I have come to the conclusion that testers who fail to ask questions are usually suffering from one or more of the following challenges:

  • Inexperience – not knowing where to start due to a lack of testing experience or absence of mentors to learn from
  • Lack of knowledge – particularly when engaging in technical discussions, leaving the tester feeling overwhelmed and unable to think of relevant questions to ask. This problem is not constrained to just technical knowledge, it can also apply when the tester is lacking in product, project or industry knowledge
  • Fear – some testers, particularly juniors, will refrain from asking questions for a fear of looking stupid or exposing their lack of knowledge – in reality, there is rarely such thing as a stupid question and often the safest, unexplored assumptions – that can be overlooked by more experienced team members – are also the ones which often result in the biggest issues down the line
  • Lack of motivation – all too often this is put down to sheer laziness, but from my experience this is often due to an underlying cause of poor leadership and the lack of a well communicated mission. This can result in the tester losing their sense of identity and purpose and causing them to disengage from their work

This is by no means a definitive list, but is what I have experienced in my years as a leader and manager of software testers.

So, the questions is how can we tackle these challenges and empower our testing colleagues to start asking better questions and uncovering more issues earlier in the delivery cycle?

Training

Many software testers do not gain formal training or qualifications in software testing, and instead tend to be self-taught or gain training informally on the job from their co-workers.

As a leader of testers, I take it is my duty not only to provide training to my team but also to encourage them to take ownership of their personal development and regularly seek out new learning opportunities.  This encouragement can come in many forms, from sharing articles, videos and reading recommendations to providing monetary support to attend conferences and training courses.

I’ve never been much of a fan of ISTQB style formal qualifications, as I feel it’s content is dated, irrelevant and does the career of software testing a huge disservice.  However, there are some great conferences like TestBash and meetups like Tester Gathering and Testing at the Tavern (to name just a few) that give testers a great opportunity to meet likeminded people, share ideas and learn.  There are also some more valuable training courses such as BBST which combines online training materials with interactive group study.

All this and more can help grow testers into more fully rounded testing experts and give them the skills, techniques and confidence to begin asking better questions.

Mentoring

Having a mentor can be of huge benefit and can help propel a tester’s career to the next level.  All testers can benefit from finding the right mentor and this can give them the confidence to go outside of their comfort zone and ask questions they would never previously have had the confidence to ask.

Mentors should not be seen as something that only juniors need, and I would recommend that people of all seniority seek out a suitable mentor, but don’t take my word for it, read the words from long time Google CEO Eric Schmidt.

Debating

One of the most effective ways of improving public speaking skills and building confidence in your own ideas is to practice in a safe environment by joining debates and discussions with close friends and colleagues.  The likes of James Bach and Michael Bolton speak regularly about forming a collegial network of likeminded individuals with which you can discuss and formulate ideas and test their validity in a safe environment before opening them up to public scrutiny.

Mission

What is your mission as a tester?  Perhaps this is something you think about often, or maybe you have only a vague notion of a mission to find bugs or help your team deliver quality software.  From my experience, many testers lack a real sense of purpose in their work.  This can lead to a lack of motivation and I sense is often the reason why they choose not to continue working as testers and seek other roles.  However, as a leader I feel it my responsibility to instil my testers with a real sense of purpose and a love for their work.  This can be done by articulating and regularly enforcing the mission of the testing unit, as well as setting clearly defined goals (personally I’m a fan of the OKR model).

In the past I have even gone one step further than this and defined a set of Quality Engineering Values, which dove-tailed with the mission statements and helped to build an even greater sense of identity for my testing colleagues.

Autonomy

I have already discussed how it is possible to assist testers to seek mastery in their craft.  I have also mentioned how giving a tester a real sense of purpose can help improve their confidence and motivation.  It would therefore be remis of me not to discuss the role of autonomy in motivating testers and empowering them to excel (I encourage you to watch Dan Pink’s TED talk on motivation if you still require convincing).

What I mean by autonomy is simple – encoring people use their own mental creativity to go about their work.  By this I mean, not dictating or micromanaging and giving testers the freedom to go about their work in best way they can and to learn from their own mistakes.  All too often in agile teams, the work of a testers is constrained by the relentlessness of moving stories across the scrum board and getting things to Done.  This treadmill of user stories can constrain the minds of your smart, creative testers and deny them the space to think clearly about the task at hand or think clearly enough to formulate the questions they should be asking.

As a test leader, it is there my role to protect my testers by managing the expectations of stakeholders and standing up to senior management and articulating the value of great software testers.