DEV Community

Cover image for How to "serve" portfolio for test engineer
Oleksii Lytvynov
Oleksii Lytvynov

Posted on

How to "serve" portfolio for test engineer

Introduction

Open to work, open to work, open to work...
Some people search for a job for a long time, while others are luckier. But luck alone won’t help much. According to statistics of Djinni service, there are 83,629 candidates and only 7,357 open positions. It's time for despair, right?

Common advice for increasing your chances includes crafting a solid CV and a well-organized LinkedIn profile. Another tip is to create a portfolio.

Will it be reviewed? When I hired employees, I checked GitHub links in CVs when there was one. In a large pool of candidates, a portfolio can be that "spark" that makes you stand out. Even if it doesn’t get reviewed, building a portfolio gives you valuable experience that will be useful in your work.
However, if you’re showing a portfolio, it’s worth preparing it well.

One candidate had a GitHub link in his CV. When I followed it, I found a couple of projects with several files containing "Hello, world!". It didn’t leave a good impression.

Portfolio for a Manual QA Specialist

I don’t really support the strict division between manual testers and automation specialists. While some companies have separate team of manual testers who write test cases and automation team to automate them, in my experience, such companies are rare. If a QA chooses only one stack, they limit their job options. I often worked on projects from requirements analysis to the final release.

The outcome of a manual tester’s work is a set of testing artifacts. They should be clear, have enough coverage, and be prioritized (don't forget to start with the happy path).

As a manual QA, you can create:

  • requirements to product (SRS) (keeping in mind quality criteria like completeness, clarity, consistency, necessity, feasibility, and testability)
  • test plan (you could follow IEEE 829, but concise documentation – one page – is better for a portfolio. In your day-to-day work include only necessary sections as well. Focus on a couple of features rather than trying to cover the entire product. Be sure to state what you’re testing and what you’re not).
  • checklists
  • test cases
  • test execution report and, if you’re lucky, a bug report
  • test report

What to test? For simplicity, you could choose well-known programs, like Notepad, MS Word, or Google Spreadsheets. If you’re applying to a company focused on mobile app development, it’s worth choosing a mobile app since mobile testing has its own peculiarities. You can also prepare testing documentation for different types of products (desktop, web, mobile).

You can also include examples of your work created during a hackathons or competitions (e.g., Dev Challenge).

Portfolio for a Test Automation Specialist

I’d recommend starting the same way as a manual tester. Decide what you will test – web, mobile, or API – or create automated tests for different types of projects. Your code quality as much important as quality for manual testing artifacts. A few automated scripts in a "blanket" style won’t reflect well on you. Instead, think about building a basic framework that’s well-structured, easy to expand, and follows code conventions. Potential employers may want to know your coding process – whether you pushed all changes to main or followed GitHub Flow. Don’t forget to write a good README – that’s likely to be the first file someone checks. Describe your framework’s structure and provide instructions for running tests.

In addition to automating different types of projects, you can try various approaches (examples for Python in parentheses):

  • Modular framework (pytest)
  • BDD (pytest-bdd, behave)
  • KDT (RobotFramework)

For writing automated tests, you can use the following resources:

Web UI

REST API

Where to Publish Your Portfolio

You can store your manual testing documentation on Google Drive (just remember to set view permissions). But it’s better to upload your work to GitHub. Even if you’re applying for a manual testing role, knowing Git will be an advantage.

Open Source

Some sources suggest asking a project manager for permission to share work samples from your previous projects. I doubt this is common practice due to NDAs. However, you don't need such permission if you write open-source code. Open-source projects also require tests, and you might fix a bug as well.

For example, one candidate showcased code she had written for open-source during working tasks.
While not many companies contribute to open-source projects, you can contribute personally and show examples of your code that were accepted in an open-source project. This is potentially more impressive than personal projects because it shows you worked with someone else’s code, followed code conventions, wrote tests, etc.

It’s best to focus on a single project and make several contributions to understand it better. Constantly switching between projects can reduce efficiency. For a given project, you can link to your accepted pull requests. For example, here are my accepted pull requests for the Faker library.


I wish you success in your job search if you’re currently looking. Try not to waste time. If you’re in between jobs, use this time wisely.

Top comments (0)