There seems to be demand for technical skill everywhere I go. Conferences that used to draw talks on how testing is influenced by the social sciences and philosophy are slowly getting stacked with talks on how to work as part of a developer pair. Companies that used to have test specialists to explore the product after development now want test specialists who can read code fluently and write small bits here and there.
Whether technical testers are the right solution to today’s testing problems is an interesting question. But regardless of the answer, technical skill is a quality highly sought after in testers these days. Spending nights and weekends studying code is a privilege few can afford. I don’t see many companies offering money for training, either.
So, how is a tester supposed to develop this new skill set? Here are three areas testers can focus on to grow their technical skills.
Get TestRail FREE for 30 days!
1. Find a Real Problem You Want to Solve
My first experiments with technical skills were driven by the fact that my co-workers were talking about automation—nothing more. We were working in a mostly waterfall environment, and like in all waterfall development flows, regression testing was taking too long. The solution that our manager eventually decided on was using UI automation to run tests every day so testers didn’t have to at the end of the release.
In practice, what this means is we took a bunch of non-programmers and thrust them into a software development project, without much guidance or direction. This project didn’t end up working out very well. Slow regression testing was a symptom of several other problems that were upstream from testing work. UI automation is a solution, but maybe not the ideal one for the situation we were dealing with.
One actual problem we had was the amount of time it took from when a build started to when it was usable on a test environment. A few times each day a developer or test specialist would kick off a build in our continuous integration system. That involved making sure all the code that needed to be in the build was checked in, then clicking a button to get things started. The CI tool handled running unit tests, reporting and creating the installation file for our product. Our build took a couple of hours because tests were integration tests masquerading as unit tests. After the build completed, someone had to FTP the installation file to the right server, run any database migrations, run the installer, then pray to the gods of software that all the services started up correctly on the first shot. During that time, most of the team was “writing documentation”—a polite way of saying “waiting around for something to test.”
I wanted to remove the amount of hand-holding involved in this process. My very first technical project was writing a batch script that polled the build system for a green build, moving the file to the right server, and then running a small smoke test built in WebDriver that took about five minutes to complete. Once the smoke tests were green, the Bash script would send out an email to the test team letting them know a new build was available. If the smoke test failed, the Bash script sent an email to a few developers to let them know something was wrong with basic functionality. This script took me several Google searches and a few days to write, but it potentially saved an hour or more of time dealing with deployment every day.
There is a lot of technical work like this that is peripheral to the work of testing software. Understanding continuous integration, source code repositories, containerization, build and deploy pipelines, shell scripting and even basic programming knowledge will make much of your testing work easier, faster or better. If you want to develop technical skill, find a meaningful problem to solve.
2. Pair with Developers
Has anyone ever asked you why testing is taking so long? The reason is usually not the actual testing work. There are a lot of activities—talking with developers, environment maintenance, building test data, reading and research, and isolating and reporting problems—that all add time to the process. Each time you switch from designing and performing experiments on software to one of these other activities, you insert a small pause in your test process.
I like pairing with developers most of my day partly because it removes the need to pause while testing. The other part is because of the natural skill transfer that happens during long-term pairing.
A normal day looks something like this for me right now. My project team meets in the morning to take a look at the current work in flight, we pick pairs for the next day or two, and then we start working. Starting work means selecting a new code change and then having a Three Amigos meeting (dev, project manager and test specialist) where we review the change and talk about what it means to be done. After that, the developers and I figure out where to start working on this change by asking how we can test.
That question is more complicated than it sounds. We could build a unit test, a test against the view using a tool like Jasmine, or a test in WebDriver that runs through a behavior-driven development framework. Once we make a decision about the right layer to attack first, we have to talk about what to test and how we want to approach the problem. Sometimes the developers write the test code, or if I feel comfortable with it, I will ask to drive at that point. We move back and forth between test and production code. If anyone on the team, including me, sees something they want to do differently, they can ask to drive and write a little code.
(If you are about to say this is developer-centric and probably shallow testing, OK. There is some truth there. But this flow creates much better quality code than any development process I have had the pleasure of working in.)
Once we are done implementing the code change, the three of us explore the product in the browser in a test environment. As the local test specialist, I take a much stronger role by driving most of the work while they ask questions and make observations.
I started this project completely unfamiliar with the technology stack, a few years out from my last programming project. Today, I am able to write small tests at a few layers in the product, read code fluently enough to see and fix problems, and contribute to code reviews. I am nowhere near close to being comfortable calling myself a programmer or tool builder at this point, but I am very comfortable with making useful additions to the development process while it is happening.
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.
3. Don’t Major in the Minors
One popular question I see on email and chat threads among software testers is, what programming language should I learn? Most of these people are either at a transitional point in their careers and think learning to write code will help them get a job, or they are wondering where they stand with their current employer.
Once this question is asked, there is a blast of answers with near-religious feelings on what the tester should be learning—or, more commonly, what they should not be learning. “Don’t bother with Java, you’ll end up typing too much.” “Don’t waste your time with JavaScript; it is trendy and a new library comes out every 10 minutes, so you’ll never keep up.”
Realistically, none of the very strong opinions matter at all at this time. The point of diving in right now is to get familiar with how programming works and how you can leverage that as a test specialist—and that goes for any new technical skill you want to delve into. Focus on what is important: how the technology works, how it will help you perform testing work, and why you want to use it.
Just Get Started
Becoming a technical tester can be intimidating for people who have not done much more than work with a browser. There are a lot of options, and everyone you ask will have strong opinions on where you should start and why.
Focusing on three basic steps—finding a real problem to solve, collaborating with someone on your team, and learning to ignore details you don’t immediately need—will help you on the path toward becoming a more technical 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
