Job hunting and domain-shifting

I was responding to a posting on usenet on the trials of transitioning from a hardware and device testing role to a software testing role.  To me, this breaks down to creating a resume which focuses on the critical, non-domain related skills of testing.  I think this advice is applicable to anyone seeking to move into a different testing field, or simply struggling to find a job.  In both cases, we need to focus on the skills of testing that cross over domains.

Finding a job consists of two parts (once you’ve found a job that looks interesting) ?

– Getting to interview
– Succeeding at interview

Getting to interview should be reasonably straightforward, as long as there is no cause for an agent to reject you when they hear you speak on the phone.  If speaking English is a problem, I can’t imagine a quick fix, although others have advised the use of voice coaches to improve pronunciation.

Here’s the trick to getting an interview.

To find suitable candidates, most agencies simply match keywords in resumes.  You should troll through all of the jobs on Seek, MyCareer, CareerOne and Jobserve and look at the keywords that agents and companies are using in their advertisements.  I am not advising that you falsely add keywords to your resume.  I am advising that you look to see which of those keywords apply to you, then make sure that they appear in your resume, preferably on the front page, in a list.  This is about making sure that you are using the same language as your customer, who in this case is a recruiter and an HR person at the prospective employer’s office. 

Keep in mind though that there are two audiences – The HR person/Recruiter who is not a tester, and the test manager or team lead at the end who is a tester.  You will need a mix of concrete descriptions for the first party (the skill sumary) and more abstract skills for the technical audience.

Succeeding in the interview, and making the descriptive parts of your resume compelling both rely on your understanding of testing.

For the descriptive parts of the resume, make sure that you have some descriptions of your experience in terms of abstract skills, and not the activities you performed.

In the company I am currently working at, I’ve hired testers primarily for their thinking ability.  If you are able to capture this ability in your resume, you can greatly increase your chances of finding a role and crossing over to software testing.

When I receive resumes from hardware/device testers, they commonly imply a tester who simply reads a specification, then implements some automated test to verify that the specification was met.  It is rare that I see language which describes the interactions with people.  So try to think about the reasons someone might have for not hiring you for a software tester role.  Try to address these in your resume.  Try not to express your abilities in terms of the physical things you have done, but in terms of the less tangible skills of a tester.

For example –

– What have been the inputs to your decisions on what it is that you should test?
– What have you done to understand the needs of the various stakeholders?  How have you worked with the business?  With beta-testers?  With analysts?
– What approaches have you applied when designing tests or modelling the system?

Lastly, read about testing. Improve your knowledge of what we actually do when we say we are “testing”.  If you can get to interview and talk clearly and persuasively about the craft, many previously closed doors will be opened.

Hope this is of some help.