This is a guest posting by Justin Rohrman.
Developers and designers usually have a personal portfolio they can reference when they want to hunt for a job. Developers have a GitHub repository, and designers will have a website and some design samples.
Testing work, however, is usually invisible, and the parts that are visible — like bug reports, screenshots and video captures — we can’t take with us. So, how can testers build portfolios to show work we have done and display our skills?
Get TestRail FREE for 30 days!
The public speaking ladder is ordered something like local meetups, small regional conferences, national conferences, international conferences, and then invitations to run daylong tutorials or give a keynote. If your goal is to build a useful portfolio, particularly if it’s for seeking a job, then you will want to climb the first two or three rungs of the speaking ladder.
Meetups are usually the easiest and most approachable option for new speakers, save for a few standout markets like New York. You’ll want to find a local meetup and attend a few times, get to know the people who run the event, and then talk to them about an idea you have for running a session. Local meetups generally have a hard time bringing a new speaker each month, so they will likely be happy to hear from you, even if you have never spoken at an event before. Your goal for this first talk will probably be to prepare your material, deliver it, prove to yourself that you can do it, and maybe have a little fun.
If you are happy with developing a network in the city or region where you live, you can stop here. If you do a few local meetups, the next time you are looking for a job, you probably can skip applying through the company websites and just email the people you know. Going in through the side door is always better. And if you start speaking at national and international conferences, you don’t even need to hunt for jobs. The people I know in these positions are nearly constantly recruited for jobs.
To give a quality talk, think about the benefit to the audience. Maybe you can energize or inspire someone, give listeners a new skill they can take to work tomorrow, or talk about the real highs and lows of a personal experience you had.
Many people don’t like public speaking (me, for example) or get anxious enough that speaking isn’t worth the time. This is fine — not everyone needs to talk at conferences or meetups. There are other options.
A personal blog is the original tester’s portfolio. There are lots of articles floating around that talk through work based on definitions; I usually refer to these as hand-waving. They vaguely talk about an idea, but they never go into context or describe specifically what the person did, how they did it or how things turned out. The personal blog was the opposite of this.
The blog is where I go for authentic stories. The people whose stories I read are working through the same problems I am — effective test design, specialty testing skills such as performance and usability, learning to use metrics programs to their advantage, embarking on a path to leadership — and talking about their day-to-day lives.
If I were to start a new blog today, I’d probably set up an account on Medium. I would let the world know that I have that blog by adding the link to Twitter, my LinkedIn page and my resume. If I were ambitious, I’d buy a domain name, get some hosting, and build a website that can host both my blog and resume. This shows not only your interest in writing, but also your dedication to getting the different systems it takes to make a website integrated and running on various platforms.
If you are worried that someone has already said what you want to write about, don’t be: It’s not possible. You have your own experience and your own voice. Write for yourself.
If you applied for a testing job several years ago, the extent of the technical requirements was probably limited to having heard of a programming language or database technology. A company might have wanted some entry-level experience, but they were usually pretty flexible on what that meant.
Some testing jobs today will require you to write a little code during the interview. If I had to guess, I’d say the field will continue to move in the direction of requiring more technical skill. Developers display this sort of skill through GitHub, and I recommend testers do the same.
Step one for building your technical portfolio is signing up for an account, installing the GitHub command line tools on your computer, and setting up your keys so you can work with your repository, or repo. The next step is picking a language to learn. If your company has a dominant language in their stack, pick that; if it doesn’t, then I usually recommend something easy to get started with, like Ruby.
You can use something like Codewars to learn the basics of the language — object-oriented theory, control structures, classes and methods, variables and so on — and then pick a kata to make. I like the Harry Potter one as a first try because the rules are straightforward, and, well, because I love Harry Potter. As you write your kata, be sure to write tests and hook it up to a CI system such as Travis.
Let me unpack what a GitHub account with a few kata repos communicates. The most obvious skill is being able to put together some lines of code to achieve a goal. But embedded in that is the activity of developer testing by writing unit tests , managing your development environment, understanding the flow of code to a repo, and configuring and using a continuous integration tool and workflow.
Making a GitHub account and adding a link to your resume or LinkedIn page shows that you are keeping up with changes in testing.
Of course, these aren’t the only options for building a portfolio, but I have found them useful. Each one is a project that will take some time to be effective, but once you have a few blog posts, a few meetup talks, and a GitHub repo with some code, the benefits will be more apparent. A portfolio displays skill because it take skill to make one.
This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
Test Automation – Anywhere, Anytime