I spend a lot of time around good software developers — real craftspeople. They get good by focusing on skill development, and there are lots of options. It seems like there is a tutorial or class available, often for free, for any language, technique or programming concept a person wants to learn.
Test specialists don’t have things so easy. If you do some searching, you can find practitioner blogs, but this isn’t development; it is reading about someone else’s development. You might stumble across a class or two, but it’s tough to tell which are credible and focus on hands-on exercises. And then there are, of course, a litany of classes on programming libraries and frameworks that cover usage but not actual testing application.
If you’re looking to grow your skills as a tester, here are a few options that have been helpful to me.
Get TestRail FREE for 30 days!
Open Source
One of the biggest hurdles to employment for entry-level testers seeking a job, especially those with no formal education, is no opportunity for real project experience. You’re lacking not only the fundamentals of software testing, but also the fundamentals of working at a company releasing software to production every few weeks. Concepts that are everyday for some — sprint, technology stack, continuous integration, test strategy, automation — are tech jargon for new people.
The easiest way to get past this barrier is to get full immersion in a software project, without the trouble of spending months cold-calling and applying to software companies. My favorite companies to do that with are Wikimedia and Mozilla. These companies have a full-time, paid staff that develops and maintains their products, but they also rely heavily on volunteers to help manage both day-to-day and special projects.
A few years ago, when Weekend Testing America was active, I helped run a couple of sessions dedicated to working on the changes for Wikimedia. Each session was two hours long. We spent the first few minutes getting acquainted, introducing ourselves and getting familiar with our testing mission for the day. After this, we spent about an hour and 15 minutes testing the product, reporting bugs and reporting our findings to a product owner. After that, we spent the remaining time talking as a group about lessons learned. Common themes I saw in the debrief were that people learned about usability, how to describe bugs in a meaningful way, and how to effectively perform a testing mission. All of this was in the context of a real-life software project that millions of people around the world use.
What I would recommend today is to do something difficult: set aside an hour of time once a week to focus on working in an open source project. Over the course of a few months, you will get some in-depth experience on software projects you can use to get an interview. When you walk into an office and the interviewer asks whether you have experience, your being able to answer “yes” will set you apart from the applicants who can’t.
Skill Groups
Corporate skill groups are sometimes called centers of excellence, or something along those lines. A group of leads meets once every couple of weeks to talk about some interesting testing topic. Over time, they might develop a fairly deep body of knowledge around that topic.
The simplest way to describe a center of excellence is as a place to train the trainers. The small group of leaders in the room are given the task of sharing their newly discovered knowledge and helping their co-workers develop the same skill. But much like trickle-down economics, this knowledge never actually trickles down. These skills remain in the small group, and then as they lose energy to keep meeting and other things become more important, the skills die off.
I do things a little differently.
As I write this, I am doing a skill group with my coworkers. We all bought a copy of “Foundations of Software Testing” from Context-Driven Press. We are going through the workbook in two-week chunks, like a sprint. One week we work through reading assignments, generally a section in the book and a few supplemental pieces of recommended reading. The second week, we will work through an exercise and quiz and spend time as a group going over our work. We work on a project continuously as a group and then move forward as a group. I have made this group available for anyone that is interested. People will naturally come in and out as we move along, and that is fine. Projects will get busy, and people will lose and then redevelop interest.
You don’t have to use workbooks to do this; any format of exercise and debrief will work. The main point is to make skill development available to anyone who wants to dedicate their time to it.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Games
Most of the software testing conferences I have been to offer some sort of space for games. In the evening after the conference (and usually a few drinks), people will gather in a room with several tables, each of which has a different game. Sometimes it’s the dice game, sometimes it’s Set or Zendo. The games are fun, and people enjoy showing off their prowess, but there are also some very clear testing lessons if you spend time doing a debrief after.
Let’s take the popular dice game. The premise of the game is simple. The person running the game has a secret formula — for example, the smallest even number die times two minus one. Each time you roll the dice, they take a look at the results, run your numbers in the formula and tell you the answer. It is your job to discover that secret formula. This game is usually run as a race, with the person or group that figures out the formula first winning. Add a debrief and you have a skill development activity.
I notice an interesting set of behaviors in people when they play the dice game. For the first few rolls, they take a handful of dice and roll them, then wait for the calculation. After a while, they get confused and slow down. There is too much data to deal with, too many dice and too many numbers flying by, so they start taking notes. Instead of throwing dice and moving on, they throw dice, then write down the results and the calculation. After this, they get frustrated with the number of dice and start adding and removing them one at a time to see what effect that has on the calculation. Finally, they start rolling individual dice intentionally, setting it to a particular value. Embedded in those actions are the testing skills of note-taking, isolating variables, designing experiments and creating classes of data.
Plenty of games have direct lessons to testing software if you start paying attention to your behavior during the game.
Classes
I left taking a class as the last option because it is the hardest sell — and it is the hardest to get skill development out of. The one class I can confidently say is good is the BBST series run either by AST or Altom. These are four weeks long and run entirely online. Each class option takes its students on a deep dive through a combination of hands-on activities, discussion and reading material.
Outside of that, I don’t know what to recommend. What I do have, though, is a way to find a good teacher.
Start searching for software testing blogs and articles. You’ll notice some patterns. A few people will tell you how you should do something. And a few people will describe how they test software, in what situations and how it worked. The people who talk in detail about their work are the ones you want. They have studied their own testing work, as well as the work of others, long enough to be able to talk directly about it and tell a story. That takes more time and skill than you might imagine.
Tomorrow
Many people have become great testers by doing nothing more than showing up to work every day, focused and attentive. Years of this has a cumulative effect, but there is also a ceiling, unless you are willing to change jobs frequently to gain new experiences. You can make that timeline shorter and much more effective by sprinkling in skill development activities.
What are you going to do to become a better tester?
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
