By Elizabeth Zagroba
It’s that time again: you’ve discovered that you’ve reached the limit of where you can bend to fit in your current role, and you’re ready to look for a new job. Being good at your job is very different from being good at finding a job. But you can bring the skills you’ve built as a tester to summarize information, ask good questions, and raise any risks or issues early in the recruitment process.
Finding a Job Opening
Part of testing is understanding the needs of an organization. You need to know who to talk to about risk, and how to approach them.You need to present them information in a way they’re used to consuming so they find it valuable. You’d approach the CTO at a large company where you’re on a one-year contract in a different way than you would the UX designer embedded on your team where you’ve worked together for years.
The same approach can be used when approaching possible employers. The best way to find a job opening is through people you already know and using the relationships you already have. One of the biggest advantages of knowing someone on the inside is that it will give you a better picture of what the company is like to work for. It will also help you decide if you’re looking at a position that matches your experience.
When a product owner is proposing a new feature or epic, they may start with a list that looks like requirements, but is actually big dreams. Job postings are like that too. There will be some bullet points in a job description that potentially don’t fit your experience. Don’t let that stop you from applying. Any open job posting means a company is looking for someone, that someone could be you! Not every criterion is a must-have, and it’s the burden of the company hiring you to figure out if you’re a good fit. If you’re not sure if you’re a good fit, throw your resume in and let them decide.
Before You Apply
Part of a tester’s job is to prioritize information, communicate risk, and structure details into categories. A test report on a user story for your developers at standup is going to be different than a test report you’ve given to the people doing user research, or to your customer service representatives who are going to be fielding issues on your behalf.
Your CV is the perfect chance to show off your reporting, summarizing, and description skills. You can certainly include things that you did:
Created test plans for upcoming features
Built automated Python tests to cover risks
Participated in scrum ceremonies
But that’s what I’d expect from any tester, and indeed you’ll be competing with very similar looking CVs that say what you did. Don’t just list those buzzwords from the job description; use your CV to tell the story of your work. What was it like to be on that project every day? What was difficult? What did you do well? Does this give you a better idea about how this person approached and described their work?
Uncovered risks and information about the system through exploratory testing
Captured important feature-level API tests using the Python requests library
Guided lean, iterative development on my team and through the Agile guild I facilitate
In test reporting, we tell the story of our testing (the coverage, the depth, what we’re not going to test) to give our colleagues a complete picture of the quality of our software. Provide information not just about your most recent job description or the meetings you attended, but also the impact you had, the people you interacted with, and what you achieved together. Don’t tell me you were responsible for releases, tell me releases used to take two days to get out and now take two hours. Give readers an indication of how strong a skill is, and put your strongest ones front and center. Consult a list of resume action words (I’m partial to this one) to help tell the story of how you took action.
Do raise the risks about your employment on your resume if you can. If there’s something about you that makes you an obvious hiring decision (languages spoken, relevant industry experience, work permit required), make that clear up front. If there’s a question someone might have about your resume (change in career direction, current location, etc.), explain that in your summary at the top or in an accompanying cover letter. Assume both an automated HR software and a busy human will be scanning your CV.
As we test user stories, we don’t take acceptance criteria as gospel, but as an important jumping-off point for a conversation about what’s needed and what isn’t. As you’re applying, save a copy of the job posting for yourself. Companies take job postings down for all sorts of reasons even if they’re still interviewing for the role. You may want to reference the job description in your interview, or confirm you’re applying for the right position.
Before the Interview
Good testers compare the expected behavior with the actual behavior of the software. Great testers help define what the expected behavior is, referencing heuristics and oracles to inform their work. Before your first interview, do that same expected vs. actual comparison on your CV vs. the job description. Compare the experience you have to what they’re looking for. See if there are things they haven’t listed that you can provide. For things you’ve done before, remember back to projects you’ve worked on or skills you’ve used so you can have a clear story to tell. Look up details in your calendar, email, documents if that would help. For things you haven’t done before, come up with an argument about why you think you could build this skill and do it well.
Testers navigate team and organizational hierarchies to get things done. We figure out who the right person is to ask a question to, or to follow up on a bug. For the interview, understand who you’ll be talking to. Look them up on LinkedIn or confirm with your contact at the company what kind of roles and experience your interviewers have. You’ll have a chance to think about how a conversation might be different depending on if you’re talking to an HR person, your future boss, fellow teammates, or a C-level executive. They’ll expect you to be familiar with the company, but maybe not the exact team you’ll be joining. Read some company propaganda ahead of time so you avoid asking questions that are clearly answered on their website, and get to dig into deeper stuff in the interview.
During the Interviews
You’ve gathered a lot of information so far: about yourself, about the company, about your interviewer(s). Here’s where you get to shine. Put that information to good use, and give a test report on yourself. Identify gaps between your experience and what’s expected, and address them head-on.
An interview is as much for you to find out if you want to spend a good part of your waking life with these people as it is for them to judge you. Come prepared with questions tailored to the person you’ll be talking to. Take notes for things you might forget or want to follow-up on later.
Questions for an HR person or any first interview
What does the interview process look like going forward?
How long has this position been open, and when are you trying to fill it?
What is the salary range for this role?
What kinds of promotions and leadership positions are held by women? (I have all of the privileges in the world except this one, so insert your own concern here.)
Questions for your future boss
How did this role open up? Why are you looking to fill it?
How will my work be evaluated?
What has been a struggle for the team lately?
Who’s had a tough time thriving here?
Should I interrupt you with questions as I think of them, or hold on to them until the end?
Questions for a teammate
What drew you to this job, and what do you like about it?
What kinds of opportunities are there to learn?
What stresses you out at work?
What are you looking for in a tester?
Questions for a C-level executive
How does my team fit into the wider company strategy?
How do you measure success?
What risk are you most worried about?
I saw in <company propaganda> that you’re striving for <unrealistic goal>. What concrete steps are you taking to achieve that?
Keep your tester hat on during the interview. They described a role you haven’t heard of, or an acronym you’re not familiar with. Dig in to make sure you understand what they’re talking about. If they used a euphemism or had trouble describing what sounded like a tricky situation, ask more questions so you know what you’re getting yourself into!
For the Technical Assignment
Did I mention that you should ask questions? Ask as much as you can ahead of time about what the expected output is, and how you’ll be evaluated. Or if you’re struggling to read the tone of the situation, ask how much they’d like you to ask vs. figure out on your own.
As soon as you receive the assignment, read the whole thing through twice. Make sure you know when it’s expected back, who you’re supposed to send it to, what format they want, etc. before you jump in. Asking questions at the beginning shows the kind of curiosity and attention-to-detail every company should be looking for in a tester, and allows the employees as much time as possible to get back to you.
Email back to confirm that you’ve received it (attachments often go unattached or rogue via anti-virus software) and reiterate any crucial details, like the deadline. If there’s something you know you won’t be able to complete, be up-front about it. Many places are willing to adjust to an unexpected time constraint, or let you send in code in the language you’re strongest in.
An interview process is as much for you as it is for the company. You can decide the role isn’t right for you and walk away at any time. It’s nerve-wracking to be on the lookout for a new job.
I hope you find what you’re looking for. I’m sure, like any good tester, you have the skills to discover what that is.
About The Author
Elizabeth is a Team Lead and Senior Test Engineer at Mendix in Rotterdam, but that only captures part of what she does. She reviews and contributes code to a Python test automation repository for 15+ teams building Mendix apps across three units. She builds exploratory testing skills by asking pointed questions throughout the unit, facilitating workshops, and coordinating an ensemble (mob) testing practice. She injects what she learns from conferences, books, and meetups into her daily work, and spreads her knowledge through the company-wide Agile guild she facilitates. She's presented at conferences throughout North America and Europe, and co-organizes the Friends of Good Software conference FroGS conf. She coaches people to success when possible, but isn't afraid to direct when necessary. She's the go-to person for things like supporting new presenters, reviewing documentation, navigating tricky organizational questions, thinking critically about what we're building, and serving as a dissenting voice for hiring throughout the department. Her goal is to guide enough testers, leaders, etc. to make herself redundant so she can take on new and bigger challenges. You can find Elizabeth's big thoughts on her blog elizabethzagroba.com and little thoughts on Twitter.