Routes into testing

I’m going to make a guess that you (as a reader of this blog entry) never dreamt of becoming a Software Tester when you were at school or college. You may have had dreams of being a doctor, lawyer, train driver, astronaut or a whole host of other things, but Software Tester was not something you would necessarily have even heard of.

For decades, anyone wanting to get into the field of IT would aspire to a Development (or Programmer) role, as these were the main roles that we heard about. Even today, whilst Computer Science graduates have heard of testing, by virtue of the fact that A levels (in the UK) and degree courses now do something akin to a nod towards the fact that software testing is actually something important, and there are people who choose not to write code but to test it for a living. As an example, Oxford university offer a course on Software Testing as part of a Software Engineering degree, which is something that didnt happen in the 1990’s or 2000’s!

There are many graduate schemes which bring people into IT, but even today primarily this is Development, Security and Operations type roles. There are Testing Services companies that will train testers as graduates, but I wonder what the ratio is of graduate testers compared to other roles in IT?

I fell into a testing role for my second job, moving from one bank to another, from a non IT role into a role that I had never heard of. There were no training courses and I learned on the job. It took me a while to understand what the role actually was, and even now there are many people with differing opinions as to what Testing actually is – but that’s not for this post!

Over the past few weeks there have been some interesting Twitter posts about whether Testing is a role that anyone can get into or not. My view is that we are all testers anyway, without realising it. We test the temperature of bath water before bathing our small children. We test the fastest route from A to B and try different ways. We test boundaries of behaviour and acceptability. We test how much we can eat in a ‘eat all you can’ buffet before we feel full. We test just how much longer we can wear our old trainers before they fall to bits! We test all the time.

It seems to me that just about anyone could in theory become a tester, no matter their career background, but not everyone would be good at it. To be a good tester requires having the right attitude as well as technical ability and the right mindset. Technical skills can be learned, how to approach testing can also be learned, but attitude and the right mindset cannot be learned.

It’s interesting therefore to look at how current Testers (at all levels) actually got into software testing as a career. A common story is where projects have required assistance from business units with User Acceptance Testing, and those who helped out became involved that way, staying in Testing and bringing their business knowledge. I’d love to hear your stories as I’m sure there must be some very unusual routes into Testing out there so please share your story and how you found the transition.

Good testing – luck or judgement?

I get to talk to a lot of testers, not just those in my team, but other teams in my organisation, testers at conferences and those I interview, and it struck me the other day that there is no real way to tell from a person’s background whether they are going to be a good tester or not. Wouldn’t it be great if we could apply a formula – it would make life so much simpler, but I don’t believe it comes down to training or background – it’s either in-built or not. What I mean by that is that in my opinion, good testing cannot be just left to luck (although it can be I suppose if you just happen to find that critical bug without looking for it!), for me it is all about attitude and mindset. Technical ability and the focus on automation seems to be the overriding requirements for many testing roles, and whilst they are important, they are not the ‘be all and end all’.

If we define a good tester as someone who can write automated tests, then we are essentially defining a developer. So why do we need a tester to focus on writing code if developers can do that?

Good testing comes from understanding the application, understanding the requirements (usually from a User Story if we are following Agile), and determining whether the requirement is testable, whether there are any omissions, clashes with other stories, potential impacts on other applications, and what types of testing are needed in order to prove to the Business Owner that the team have delivered what was requested. Good testing is found in how a tester approaches their job, and I know I have mentioned this before, but it is where a tester adds value to a team. Having another individual who can just automate the acceptance criteria that a Business Analyst wrote adds no additional value – and the team have employed a developer essentially.

A good tester needs to think about the application, and consider it as an end user, ask the questions that no-one else thinks of and be inquisitive. A good tester has to exercise good judgement in determining what to test and how to test it, and whilst this can be learned (to a degree), much of this will come from a person’s character.

If you are a good tester, then luck will play second fiddle to judgement, every time.

The danger of words

Ok, so here I am back on the theme of recruitment. Why? because I am trying to fill two roles in my team, and it has been a struggle.

There is a fundamental problem with CV’s. There are many different ways in which a CV can be laid out, many different words used to describe experiences, but no hard and fast industry rules or best practices governing them.

Every CV is a personal statement, therefore should reflect the individuality of the author. Layouts do not need to be the same, although the type of useful information should be uniform. A good example is where candidates will list a job role, and the first bullet point isnt about their experience or responsibility – its about the company or product, lifted from a web page somewhere. I’m interested to a degree what type of application they work on, but I dont need a company history! Or there are many fonts used (refer to previous posts for that one), or messy tables that make it hard to read.

So, what should a candidate cover?

Thats easy – it’s the skills, direct experience and responsibilities that they are doing/have done in each role – e.g.

• Writing a Test Strategy for Project X.
• Working as part of an Agile scrum team, attending Planning, Retrospective and Demo meetings and Daily Stand-Ups.
• Estimating user stories.
• Writing tests based on User Story acceptance criteria.
• Writing automation tests using xyz, in K* language.
• Executing manual and automated tests, and raising defects in ppp.
• Performing non-functional tests – Performance using nnn, load using zzz.

And so on.

One of the biggest issue however is how candidates justify the use of certain words, expecting those reading the CV’s to know what they mean.

I’m referring to ‘Experience in‘ and ‘Knowledge of‘. Both in my opinion are dangerous!

I spoke to a candidate on the phone who had used both of the above all over the CV, including for a tool that I needed the candidate to have used, in order to fit into the team and hit the ground running. Unfortunately we don’t have time to train someone from scratch due to looming deadlines, so I had reviewed a batch of CV’s to narrow down to 3 candidates. This candidate gave me a run through of the skills and tools that they used, but missed out this one. I picked up on this and asked about it – and the reply was that they were aware of the tool but had never used it. I asked why it was on the CV – to which the response was “That’s why I used the phrase Knowledge of”. Wow! Priceless answer……except for the fact that I am in no way a psychic, therefore have no idea what the candidate was thinking when writing the CV! The candidate proceeded to argue with me (never a good idea in a phone interview) until I pointed out that to include it was dishonest and that only skills or tools that they have practical experience should be covered. I also asked how I was supposed to know the difference between their statements! Needless to say the call was ended shortly afterwards.

I then experienced the flip side of this in the next phone interview where someone HAD used the tool on a personal project at home, but decided not to list it. It’s interesting how people’s minds think. My view is that even if you have used something for a short while, or as a home project, it is fine to list it within its context. This shows that although it is not a skill that would be useful if the role requires someone experienced, it could be if there was time to train someone up with basic knowledge already, and it shows initiative and a willingness to learn.

Another issue is repetition. Do candidates realise how many people search through CV’s using the Find function in Word?. If I need a set of technical skills, that’s what I’ll do to see if they are listed in the body of the CV, and not just in the agency cover sheet (believe me, it happens far too often). The problem is that candidates will have performed a number of similar roles, and copied bits and put them under each role. Why? I understand that a candidate will have estimated, tested, attended Agile meetings etc in 3 companies, but surely there is a way of rewording a little in each one – to not do so looks very lazy. If a candidate can’t be bothered to show that each job differed a bit, then a) why move in the first place, and b) does that show a lazy attitude to work, or are they trying to reuse phrases and show me something? Its hard to know, but the decision to phone or face to face interview hangs off the information that is presented in the CV. As a manager, I cant afford to waste time finding out.

Not everyone will agree with me, but I am speaking for myself as a recruiting manager. I want the basics. I have a number of CV’s to review and not a lot of time to do so. Poor layout, waffle or repetition is wearing, annoying and wastes my time, and will not get the candidate through the door.

The best CV’s cut the waffle, tell me what I need to know, don’t contain lies, and are not craftily worded to try to get the CV past me to try to gain an interview. Lies or discrepancies will come out in an interview where everyone will have just wasted a lot of valuable effort, and the candidate will not get the job anyway, so why bother?

My advice to anyone writing a CV is this – read it as someone who has only 5 minutes to screen it. In an ideal world every manager would have longer but that doesn’t happen. What are the standout items that you want them to read? Do you have to put all those bullet points in from a job you did 3, 4, 5 years ago? The most important roles are the most recent 1-2 years, so focus on those. Remove any duplication – the fact that you have used Selenium Webdriver doesn’t need repeating 14 times! And use words carefully! Words can be dangerous – they can mislead and they can give a false or negative impression of you if not used with care. What does ‘Experience in’ really mean. Contextualize it. Help the person reviewing your CV to find the real you. And get someone else to proof read it.

The fact that I mention that I am recruiting is NOT an invitation for recruitment agencies or candidates to make direct contact. You can however find details of roles that we have open in my organisation here: https://reedelsevier.taleo.net/careersection/13/moresearch.ftl – direct candidate applications only.

Thanks for reading.

Oh – before I forget, the above ‘Curriculum Vitae’ image is from a site http://www.ssworkclub.co.uk/ who are a group who have set up a website aimed at helping people on a local estate in the north of England to write good CV’s and help them find work. What a great thing to do – well done guys!

Challenges when recruiting testers – number 6

Moving on to number 6 on my list of recruitment challenges is………….arrogance.

This might seem a strange thing to add, so bear with me whilst I explain.

A problem I find with candidates is to do with attitude, and it can come across just as much on the phone as it does in a face to face interview.

There is a fine line between explaining what someone has been doing in various projects and the contribution they made, and coming across as though they personally ran the whole test team and came up with every innovation ever implemented! A number of candidates I have spoken to think very highly of their abilities – which in itself not an issue, but if they can’t back up their opinion with cold hard facts, then perhaps this opinion is somewhat misplaced.

Luckily I do not come across too many candidates who speak ill of their current or previous employers (it’s a piece of advice that you can find within 5 seconds of searching for Interview Tips on the internet!), but I really do think that having a more humble attitude during interviews would not harm candidates who are over confident.

A side effect of this sort of attitude is the impression that I (as an interviewer) am lucky that they should deign to come to the interview, and quite frankly the questions are boring and beneath them. Some candidates are very easy to read – it’s all in the body language. 

Of course there is always the extreme example – there was a candidate who after every question I asked him, said ‘That’s a good question’, and then replied in a patronising way. That’s not the attitude I need in my team!

My advice to candidates is this: do not to make the interviewer feel like they are pulling teeth because you don’t give enough detail in your answers, and do not make it sound like you can single handedly save the testing world. Be realistic about what you can do/have done, have a little humility – there are times in business when it is needed, and if you can show it in an interview, it shows a depth of character to the interviewer and is a point in your favour.