Category: Recruitment

Testing as a career

I am going to join a long list of people I consider thought leaders in our industry in a lament of how many people continue to see testing as a simple job, not a career, not a craft, not really requiring any skill at all.

But, like Lalitkumar Bhamare I felt I needed to talk about this, because …

I recently interviewed a candidate that had had two co-op experiences as a QA, he had been given requirements and design specs and asked to think of tests (purely black box) for these. He believed he was doing well and that the team was working efficiently when he could think of one or two cases in addition to the one obvious one to confirm the requirement was met.

He found bugs, 2 or 3 a day, he said with some pride.

It was obvious he did not think this was hard, required any skill, or was a career that he wanted, but he felt trapped and compelled to apply for a QA role as that was what he had experience in. He really wanted to be a developer.

I explained he could be in a very different environment where instead of being part of a waterfall like cycle like this;

  • customer proxy passes requirements to the tester and developer,
  • the developer develops code to meet the requirements,
  • the tester thinks up a few test cases per requirement (he told us he came up with about 2.5 on average).
  • The developer then hands code to the tester who then takes the code (product) and tests it by following the heavily prescribed test cases he just wrote. (Presumably without thinking much). Finds a bug or two, records that in the bug tracking system and moves onto the next test case.
  • Then the game of ping pong begins as the tester throws the code (product) back to the developer to fix the bugs. The developer fixes the bugs and throws it back …

That instead, he could use his skill, (yes I did say the word skill), to help the customer proxy and the developer understand what he was thinking of testing before the coding started. That this might actually prevent the developer from missing the requirement to meet the other use case the tester had thought of. That the customer proxy may have an opinion on this and say, “no we don’t want that”, or perhaps, “yes we want to meet that need too, and now you have made me think of another one that we need to meet too!” (Catching a completely missing requirement)

He didn’t see it, couldn’t see himself doing that, couldn’t see a way that could work, at least not during the interview. To his credit he was thinking about it and it clearly confused him but he was not able to take this any further.

(I did also suggest that there was no reason for him not to apply for software development roles)

Many, many, others I have interviewed, some who have been ‘testing’, (I would say checking), for years, still have no thought that they could be better, that they could improve and develop their skills, that they could really help their team to avoid making so many costly mistakes and save their companies thousands if not millions in wasted efforts, time lost due to bug interrupts and context switches, re-builds, re-tests, whack-a-mole etc. In other words deliver real value and not just fill a role, warm a seat, expend some effort, etc.

A co-op student I worked with, (believe me I am not picking on co-ops at all, they have very little experience to draw on, but are also often not taught anything good about testing), visibly turned his nose up at doing some testing, saying, “I don’t want to just press buttons all day long”. This was his understanding and belief of what testing was. Not entirely sure what his experience was or where he got that, but I tried to disabuse him of that incorrect understanding of the role, but once again felt myself working against an entrenched idea.

So, I call out to the learning establishments to do a better job of preparing these young minds for the real work of professional software engineering. That good software developers do a lot of thinking and a lot of testing as part of everything they do, and that doing this well takes a lot of skill, experience and learning. And that good software engineering teams and leaders recognize the need for people on their team that think differently and are skilled in the art of helping the team expose issues as early and as quickly as possible, to help them deliver the right solution first time more of the time. Without the need for drama, missed deadlines, long hours, late nights, re-design, context switching to fix bugs found in code developed weeks ago, etc. That this, (software testing), is a career, a valuable role, and an essential part of any high performance team. That it also takes a lot of skill, experience and learning to do it well.

I also call out to all the companies out there that insist on continuing to think of testing as simply, ‘using the product the way a customer will’, and hoping that will catch enough issues. Believing that in doing this they are ‘testing the quality into the product’! They are both wasting and losing a lot of money, as they have to pay the cost of finding defects late in their cycle. They also need large customer support teams, and in some cases teams of developers focused on maintaining, (fixing), their colleagues code.

These companies are responsible for perpetuating the myth that testing is basic, unskilled and a simple role. That it is easy to automate what these testers do or that we can simply outsource this work to countries where peoples’ time is cheaper.
They are also often responsible for poor quality products, that will often miss deadlines, and require expensive maintenance programs or extensive and expensive re-writes every few years.

And finally I call out to all the people in testing or quality related roles out there to learn to do better, be better and thus change the perceptions of everyone around them to see that testing is a skilled role, it is a craft and thus requires craftsmanship, and that it needs to be part of every team and will improve the quality of everything we do.

But it’s not all bad …

I have employed and had the pleasure of working with some fantastically skilled testers, both talented exploratory testers, and test automators. Sometimes a few rare gems that are able to combine great skill in both testing and the development of tools and automation to help check software.

I have also had the great pleasure of working with lots of great software engineers and leaders who really understand and seek the value of testing. Insisting that they have great testers to work with them, that they and their software developer colleagues need to think about and execute testing at all levels and that they encourage all to learn more about and be better at ensuring the quality of everything we do.

I have been inspired, guided and encouraged in my career by many people, but most of this has come from what I think are some of the thought leaders in this area. Here are some links to articles, books and people that can help you too;

I would also highly recommend Rapid Software Testing training, this course will be one of the best investments you can make in your testing career.

QA Recruitment – what do I look for?

I recently got asked what I look for when recruiting for QA/test positions. So I decided I should share my thoughts both with those of my colleagues who are recruiting, and also those who are looking and maybe wondering what they need to be able to share in an interview.

I have broken this out into a small number of attributes or qualities I tend to focus on:

Passion for testing?

Try to understand if they are passionate about what they do
  • ask questions about why/how did they got into a QA role or what keeps them in a QA role
  • looking for someone who cares about quality and recognizes that it takes skill, that they have some of that and they enjoy using it
  • ask them to tell you about an interesting bug they found and why it is interesting (was is challenging to expose, challenging for the team to resolve, an interesting chain of events type issue … is there genuine interest and passion in finding and solving problems here)

Motivations

  • what do they enjoy most about their current role?
  • why do they want to leave?
  • what does this tell me about what motivates them and what they may be looking for?

Testing Basics

  • do they understand the basic test design techniques of equivalence class partitioning and boundary value analysis – keeping in mind they may not know the terms, they may just do this intuitively
  • ask example questions that have clear equivalence classes and boundary values or get them to explain how they would think about the test cases for a situation like this
  • ask why they think of testing with those values to see if they have ever identified that they are applying a technique or a pattern to these types of problems
  • you can also ask other basic questions like what are some of the important points to include in a good defect report, what they do when faced with ambiguous or unclear requirements
  • do they know any test heuristics?
  • do they perform exploratory testing? Can they describe what they do or give you an example? (Are they truly exploring or are they just doing ad-hoc and thinking they are the same?)

Teamwork

How well do they work with others
  • how big is their team – if they are the only QA then they probably don’t have anyone to bounce ideas off or tell them there is another/better way of doing something
  • are they all in the same office? – if yes how often are they talking with others on the team and why
  • if some/all are remote – how do they communicate and what problems do they have communicating
  • do they try to help developers resolve issues – ask them if they attempt to narrow down where, how or why a bug is occurring
  • do they try to help PM/BA define requirements – ask them how the requirements analysis/review happens and how they provide feedback or ask questions to clarify requirements
  • you are watching for any team vs us type attitudes or ‘not my role/job’ type attitudes

Process basics

  • do they understand their current process? Can they describe it briefly and succinctly? – if not then they probably don’t understand it well enough to explain it clearly to a new teammate, or it is too complicated for them to efficiently work with and they don’t know how to improve it
  • do they do regression testing
  • do they get to choose what testing is done and in what order?
  • if yes, what do they do first and why?
  • if not, then do they understand how the decisions on what to test and in what order are made?
  • what happens when they find a bug in something they are testing? Do they stop and wait for a fix or pick up something else?
  • if they could change one thing about their current process in order to improve it, what would they change and why?

Automation – only applicable if they have some automation experience

  • what do they automate and why do they focus on automating that testing? Often get simple answers here varying from I automate what I am given/told to automate through to I automate everything – you are trying to understand if they know that there is judgement required here – choices to be made about what to automate in order to improve the efficiency of the team
  • also common that QA automation is focused on UI – ask them if they have any experience of automating anything other than UI
  • do they run their automation regularly? In a CI system?
  • what problems have they had with automation – digging here to understand if they have built fragile automation or if they have learnt the basic mistakes and are experiencing more advanced problems like how to efficiently manage test data or parallelize tests more effectively

Continuous learning

Lots of people say they do this but do they really? And what are they trying to learn?
  • ask them how they keep their skills current
  • ask them to tell you about something they have learned recently that they found particularly interesting or useful
  • ask them if they follow any QA/test/development folks blogs or twitter feeds and what they learn from that if they do