How to Spot a Quality Engineer

Now for something completely different…

Live blogging, immediate thoughts, raw impressions, no reflection. That will come later. Promise.

This is the event: https://www.meetup.com/qababble-online/events/299885490/

Recording of the session can be found here.

Summary

copy & pasted from the meetup link:

traits that make a good Quality Engineer?

And does the industry still have a fit-for-purpose method of assessing all of this required skill and experiences? Does it even need one?

We’ve assembled a group of experienced Quality leaders, who’ll share their view on these fundamental questions

During the session we’ll cover;

1. What components are needed to be an effective Quality Engineer?
2. How can these be accurately assessed?
3. Is the industry lacking a universally recognized accreditation?

+Live Q&A with panel – the events are designed to spark debate and conversation in the Community. Your input in these sessions helps bring them to life!

The Contenders:

  • Paul Gerrard – invovled in Quality for a looong time, techie at heart and into testign for 30years now. QE as critical consideration & function within the SDLC. Debate vital to lead to progress.
  • Seema Prabhu – 18 years in testing and more recently had hiring responsibility. ‘What makes a QE?’ is a continuously evolving question between organisations, technologies, techstacks and over time.
  • Bryan Jones – 35years + in testing in a range of roles from review of assembly code to being a director of practice and everything in between. Key characteristic of any QE can be summarised in one word, mindset. Mix of skills within individuals and teams an interesting area of focus.

Question 1:

What components are needed to be an effective Quality Engineer?

  • Setting the scene – can be bogged-down in skills, but what about mindset, attitude, and personality traits:

  • Paul – plenty of rick points for discussion. Being a quick learner. Able to adapt flexibly to new, unfamiliar domains until you can make progress.
  • Seema – echoing quick learning as key. Top communication skills also very important. ‘We are not just there to raise defects… its about communication in a cross-functional team… an holistic, well-rounded view is key’.
  • Bryan – Focus, Curiousity, Critical Thinking, Systems Thinking, and Communication summarised as the key skills required. Curiousity as the engine for most of these skills, but communication is key, “you have to be able to communicate what you’re finding, and the meaning of what you are finding”.
  • Paul: “…QEs as the glue”
  • Seema: Remote working increasing the importance of communication and collaboration as key competencies. As well as cross-functional teams requiring clear and open comms not only to perform highly, but just to succeed at even a basic level.
  • Matt – ?
  • Seema – differing timezones, varied availability, networked comms tools (Slack), no where near as efficient as IRL contact and communication. Pastoral elements, and body language are lost during remote working.
  • Paul – the availability of networks communication tools and lack of IRL contact has corroded the informal, incidental communication. Instead everything has to be planned, people can be lost…
  • …at this point Matt – the host – disappeared from the call. One might think it was deliberate for commedic effect..
  • Bryan – remote working between people in very different geographic contexts exacerbating the gaps in understanding, in comprehension, in knowledge, and in cultureal context and understanding.
  • Paul – curiousity – not only a key skill for QEs, but also to help maintain and solidify good communication between delivery team members.

Question 2:

Matt – Critical Thinking – what does it mean for a tester to be ‘critically. thinking’

  • Bryan – arch & design decisions often presented as set in stone. Actually:
    • How do we engage with the system risks?
    • how to we quality assumptions?
    • is this the best way?
    • Does the design/arch deliver the solution needed?
    • What are the thoguht processes that have led us to the design?
    • Root cause analysis following defect detection to then support defect prevention.
    • The ability to analyse things in a more forensic way.
  • Seema – exploding and breaking down assumptions is a key component of this trait.
  • Paul – the critical thinking and engagement isn’t a hyper-analytical competency, it is a characteristic that we have at a very human level.
    • What is the agenda of the person delivering the information, the plan, the requirement, the design etc.
    • What perspective(s) is the person or group looking through?
    • Soft, rather than a highly technical skill.
  • Matt – delivering quality at speed, this is always a key consideration for QEs. Giving time to analyse and understand is a challenge when the pressure to deliver and unlock value are compressing the time to refelct & analyse.
  • Paul – this is where brvery is key. The willingness to communicate, clearly the feedback, the meaning of the feedback, and the problems with their impacts.
  • Seema – maintaining a constructive style as key.
  • Matt – style of communication and stakeholder management as key.

Question 3:

Matt – How do you effectively assess a Quality Engineer’s key competencies and characteristics for a role?

  • Paul – with difficulty. Face-to-face. Discussing their experiences, mindsets, strategies for managing during the hiring process. ‘Critical Thinker’ not something that can be quantified readily or in a standardised, quantifiable way, but you can qualitatively assess someone’s capacity for critical thinking.
  • Seema – concurrs with above, suggests scenario-based questions and discussion to gain an understanding as to their mindset. Discussing and reflecting on past-experiences as a useful tool for assessing this capacity.
  • Matt – do you use any psychometric testing tool to help hire people?
  • Seema – no, not a tool that we use.
  • Paul – abotu c.15 years ago discussed psychometric testing and identified some key ‘measures’ that could be used. Some points provoked interesting discussion and were used, but then were ultimately discontinued. Using a ‘test application’ to assess approach and style might be one option, as well as scenario-based tests. That said, a challenging one to measure.
  • Bryan – deep interest in psychology and the value that might be provided by psychometric testing. Value is in ensuring there are a range of different people/personalities/mindsets within a team, but less value in selecting individuals. Psychometric testing and results gained from them are highly contextual and susceptible to variation between contexts and domains. Neuro-linguistic programming approaches to assess and characterise their mindset, areas of focus, blindspots etc as a useful tool. Further question-asking within the interview or scenario is another key indicator.
  • Paul – experience of weakness hunting with software engineers – hardly any interview, instead a pairing exercise with a current engineering team member to assess and measure the person’s skill set.
  • Seema – experience of being interviewed involving a whiteboard, a brief, a design document and then asked the questions:
    • how are yo ugoing to test the whole system?
    • Where are the risks?
    • What needs to be tested?
    • Alongside these questions were further discussion quizzing the mindset and thought processes informing the answers.
  • Seema – second experience was less structured and details, and designed to assess the approach and response to a limited brief.
  • Paul – in first quality role given a document to read, followed by an assessment of that document. Given all of this, our biases and prejudices are probably highly difficult to try and address.
  • Matt – certain things in a CV – like an interview – skew and bias the assessment immediately. Always a challenge to try and mitigate this effect.
  • Matt – Some alternative testing strategies came from other attendees:
    • Scenarios, reports, further question-asking and curiosity to surface a person’s mindset.
    • Belbin Model – personality type mix

Question 4:

  • Matt – industry-standard qualifications/univeristy accreditation/pathways into the industry… is thetesting industry missing this?
    • ISEB highlighted as something that became a standard. Although it has waned in popularity without a clear replacement.
    • Challenges of assessing what ‘makes a good quality engineer’ might militate against a standard test or. qualification.
  • Bryan – feels that there is something missing regarding how we assess and measure an individuals competence. How to avoid elaborate memory tests is key though. What are the core ‘admin tasks and terminology’ is often an inadvertent test/means of quantifying someone’s knowledge. However, there has to be something beyond memory retention and knowing the terminology, instead a portfolio of work better attests to a quality engineer’s skillsets.
  • Bryan – adds an element of evidence to assessing someone’s knowledge. Recognised certifications that demonstrate skills, that are commonly understood in the industry would have value.
  • Seema – certification might be positive, and has clear value in other industries. It might also help to establish a common, solid understanding of foundational techniques and practices. However, once you grow into your career, it has diminishing value to your development, your dayto-day, your skillsets, and your opportunities. Identified as having a useful impact in immature teams and where members are less familiar with the domain and discipline. They help to breed those common understandings before the practitioners then grow beyond the textbook.
  • Paul – observation that certifications & the job are very similar to driving tests & driving on the road for real. Not a passport to success, but a starting point.
    • Critiques of certification:
      • No appraisal of testing ability. Just memory tests.
      • Highly context specific, and artificially structured.
    • If the question is ‘how do you identify a professional…?’
      • Professional institutions
      • Well-defined career pathways that give a means of bench-marking skillsets and abilities
      • Test engineering society?
      • Develop a meaningful way to establish skills – analogous to the ‘UK Spec‘ which gives an overview of core skillsets that a software engineer should demonstrate.
      • Majority of skills are ‘soft’ and human, not overtly technical.
      • Opportunity to make progress and develop this further.
  • Matt – how would individuals gain recognition within these structures?
  • Paul – levels of recognistion not relating to seniority, but rather a measurement of ability and competencies that can be commonly understood. Exactly how you get assessed:
    • Mixture of:
      • Paper exercise & submission.
      • Interview element.
      • In essence, a peer-reviewed process arising from and determined by members of the same professional community.
  • Matt – So the above, a professional qualification, achieved and demonstrated alongside a person’s working life…
  • Paul – not theoretical or abstracted. Based on real-life results, case studies, portfolios, technical as well as personal and professional skills. Scenario and evidence based.
    • By no means perfect, but better than what we have.
  • Matt – how do people get involved in supporting this effort?

Go here for further information: https://testsociety.org/page/4

Question from attendees: proposing a test/qa engineer specifci version of the chartered professional IT scheme offered by the BCS?

  • Paul – in short, no. A Quality focused qualification from an organisation that is also focused on quality engineering in general as opposed to one awarded by an organising that doesn’t have testing and quality at its heart.

Question 4

  • Matt – how can applicants effectively communicate their key QE traits?
  • Seema – include some evidence. Use breadcrumb details to build curiosity in the interviewer/hiring manager. Demonstrate learning and growth with in their career/role. Go beyond a bare, basic list of technical skills or languages that they know.
  • Matt – personality traits and key skills important to bring to life.
  • Bryan – don’t just list technical skills. Highlight what you actually did, how you approached it, what was the impact of what you did.
  • Paul – if hiring, there will be so many CVs that personal, detailed review are very difficult. An initial sift of technical skills is used as a blunt instrument to reduce numbers.

Leave a comment

My name is Chris

Welcome to my blog.

I’m a Senior Quality Engineer at CAVU, and this blog is dedicated to all things Quality.

It is a place to share my thoughts and experiences as I try new things, succeed, fail, and learn.

Hopefully it will also be a means to connect with others who share this interest.

All opinions are my own.

Let’s connect