Five mistakes Test Engineers must avoid making on their CV

I am regularly left amazed and disappointed by the poor quality of Test Engineer CVs. I accept that some mistakes can slip through the net, particularly if you've spent many hours staring at Word trying to think of the most elegant and exciting way of communicating your experience, but for any job where attention to detail is paramount - and I think that applies to almost any job to do with Software Development - I would expect a CV to have been carefully reviewed and for only the most indistinct mistakes to remain.

It should be a billboard for its author's meticulous ability to spot things that aren't right.

Few documents are perfect, but here's five things that I spot instantly which make me question the candidate's suitability.

1. Inconsistent date formats.

Choose a date format, and stick with it throughout your CV and definitely don't change within a single entry; Mar 2013 - October 2014 for example looks awful.

2. Inconsistent bullet points and indentation.

It seems obvious, but if you're using bullet points or other lists then make sure that your indentation is consistent, not just in a single list but throughout the document.

Don't vary your bullet point style unless there is an obvious reason for it.

3. Listing every type of testing.

White box, black box, regression, system, user acceptance, exploratory, functional, end-to-end, sanity, smoke, load, usability...

Some companies might use scanning tools to pick up keywords in CVs, but most probably don't and when it reaches a human they won't be impressed by your ability to copy & paste from Wikipedia.

4. Keep it short.

Being able to summarise and report effectively is a key attribute for most jobs and for Test Engineers in particular. If you ramble on for page after page then you don't paint a good picture; keep it to a couple of pages maximum, and don't be afraid to drop things that don't bring value. Two pages of key skills will impress more than 6 pages of waffle.

5. Don't lie or stretch the truth too much.

If somebody claims to have a skill or have experience with a tool, then I expect them to possess the knowledge and ability to talk about it. So when it becomes apparent that they can't it leaves me disappointed and questioning the truth of the rest of their CV, even if the skill was just a 'nice to have'.

Having a CV that makes you out to be a lot better than you are might help you get an interview (most likely a short phone screen) but in all likelihood you won't get any further than that. Ultimately, you end up wasting time being interviewed for a job you're probably not going to get, and if you do, you'll probably hate it if you don't know what you're doing.

Finally, keep in mind that your interviewers and those who read your CV are probably experienced Test Engineers themselves; these people earn a living from their critical thinking and attention to detail.

Job titles in Agile, and why they are bad

95% of teams/companies that claim to be Agile, aren't actually practicing Agile.

I don't know how true that statistic is, but I could easily believe it from conversations that I've had.

There are a lot of things that teams and companies struggle with when it comes to Agile, but one that stands out above the rest is that teams get caught up with particular people having particular jobs to do. At the most basic level, this means that developers develop, testers test, designers design and managers manage.

But then, why should anybody be surprised by that - almost everybody has a job title, which pretty much draws a box around what work is theirs, and what work is somebody else's. It's one of the most fundamental differences between a truly agile start up and a lethargic mid-size company.

In Agile it is skill-sets rather than job tiles that matter. Anybody with the right skills should be able to pick up a task, and job titles create a significant barrier to that.

The two friends who are fresh out of Uni' and are each working sixteen hours a day to try to make it big with their startup do anything that they can, whether that is developing, designing, testing or sales, etc.

It doesn't take a genius to work out why companies continue to assign job titles - it makes a lot of things, not least recruitment and HR a lot easier. But do the advantages outweigh the disadvantages? It's a difficult question to answer, but I'd be inclined to say that they probably don't.

There's a lot of cultural challenges around Agile which makes recruiting the right people critical, yet many have inadvertently stopped people from becoming truly performant before they've even started.

The Scrum Guide makes reference to the 'Development Team', which encompasses everybody who isn't Product Owner or Scrum Master. It's one of the less subtle parts of Scrum that people get wrong, sacrificing a big benefit.