The Secret Skill on Your QA Resume

There’s a particular skill that is on full display in your tester, QA, or quality engineer resume that you may not even realize is there: the ability to be concise.

The most common resume structure I saw this year went something like:

• A summary section with bullets describing a person’s experience and skills
• A table of technical skills
• Job experience with each job getting another set of bullet points

It’s not an exaggeration to say that each one of those components was often a full page or more. When that happened, I would notice the same details being repeated multiple times, as if one thought it would emphasize that skill more or make it more likely to get past an automatic filter. Selfishly this is a problem because it means the information density is lower: I have to read more to get the same level of detail. But ok, I can slog through that if I have to. However, in an indirect way, it can also flag problems with your approach to testing.

Since there is always an infinite amount of testing we could do, but a limited time to do it in, an essential skill for a tester is knowing how to avoid repeating themselves. Testing something twice doesn’t tell you anything more than testing it once. I touched on this when describing some bad reasons to test and the importance of each test having a purpose. It’s also a fundamental part of the testing pyramid: the top layers can be smaller because you don’t need to repeat things you’ve tested at lower levels.

This is especially true in test automation, where we have to be economical with which tests we implement and with how much code we write, by using good coding practices like, among others, the “don’t repeat yourself” principle. Code written twice is more than twice as much work to maintain, since there’s overhead in remembering something was done twice in the first place.

Now apply this to your resume: why tell me 4 times that you’ve worked with Selenium when once will do? What value does that add?

Some tips that might help keep things concise:

• If you use a table or sidebar to list a bunch of technology that you’re familiar with, you don’t need to repeat them again in full sentences under each job.
• If you’ve done something similar across many jobs, consider putting in into a summary section rather than repeating the same sentence every time. Use the space you have for each job to highlight what is different or unique about what you did while there.
• Don’t include many variations to describe the same work. Filler phrases like “Test Design”, “Test creation”, “Test Scenarios”, “Test Cases”, “Test Scripts”, and even “writing tests” all effectively mean the same thing (because they all mean something different at every company). Instead of stuffing your resume with all of them, include only the ones the job posting asks for. The same goes for other filler like “Defect Tracking”, “Defect Management”, “Defect Reporting”, “Defect retesting”, “Test Reports”, “Regression Testing”, “Sanity Testing”, “Smoke Testing”, “Functional Testing”, “System Testing”.
• Focus on what differentiates you from anybody else working in the same field. I called those phrases in the previous point “filler” because they mean very little and almost everybody has them. All things equal, I’m not going to make a hiring decision based on one resume including “regression testing” or not. Unless the job description mentions it, or you really do have a depth in one area that is worth highlighting, leave it out.
• Avoid needless detail. A sentence to tell me you “use locators to identify elements on the page” doesn’t add much if you’ve already mentioned working with Selenium. I’ve also seen multiple bullet points dedicated to “creating branches, pulling updates, pushing code, and merging code” in a single resume where just listing “git” as a skill says the same.
• For each bullet point you write, ask what information it adds. If all the information it adds is already found elsewhere in your resume, delete it.

If I notice a lot of waste like this in your resume, I am going to wonder about how efficient you will be when it comes to writing either a test plan or an automated suite. Be concise.

You’re now free to get in the comments to tell me how I could have made the same point in half the space.