This is a guest posting by Justin Rohrman.
I work as a software tester full time, 40 hours a week. I do not spend all this time testing, my energies are split among many activities, including meetings, answering emails, talking with people, sprint reviews, retrospectives, backlog grooming, feature reviews and so on. If I’m lucky, I might spend half of each day doing testing work. I’m sure it’s the same for the majority of software testers.
The testing role consists of several activities other than testing, and these activities contribute to software development in very important ways. Here are five ways skilled software testers contribute to software development outside of testing.
Get TestRail FREE for 30 days!
1. Discovering Scope
I see a list of changes that need to get done every sprint. Every change request or card on the Jira board has gone through a series of reviews. Product managers first talk with customers about what they need. After this we have conversations in the development group about what those requests mean in terms of software and how to turn those into something that can be represented in Jira. When I look at a card, I see the distillation of weeks of work, and sometimes important things are evaporated away in the process.
One team I worked with a few years ago was working on building forms for anesthesiologists. We wanted the ability to lock a form to edits when a nurse or doctor had signed the form. We also had a feature that would auto-populate vitals from a case onto the form. But these two features conflicted with each other, and we didn’t realize it until the card came up for work. Our auto-populate functionality still worked after a form had been signed, so a locked form could potentially be edited.
A tester on the mobile team discovered this missing scope in the feature request. That tester had been working with the mobile team for a while, particularly closely with the product manager. They had the combined product and business domain context to find problems like this before code was written.
2. Giving a New Perspective
In my experience, developers — even very good ones — tend to approach testing problems in a similar way.
Great developers will sometimes test-drive their work. They start with a test, run the test and see it fail, then write a little production code to make that test pass. Once the test is passing, it’s time to refactor and make the code without the risk of unknowingly breaking something. After a series of red, green, refactor, developers will build a container and see how things work in the browser (“work” is the operative word there). After the code is running, the developer might open the browser and go through an ideal workflow to see that their change does what they think it will do.
That is what one person does. But when a room full of people all approach development and testing the same way, what we get is something called inattentional blindness: a failure to notice obvious problems, even when they’re right in front of your eyes.
A few months ago I was working on a change to a part of a product that scans text documents into a piece of software. A person navigates to a scan page, sets a few attributes, like date and owner, loads paper into the scanner and hits the scan button. The workflow is easy, but the code behind it is complicated due to third-party libraries. We test-drove our change and then ran a scenario in the browser to make sure that it really worked.
Being a tester, I had some different questions. What happens if the person trying to scan a document gets impatient and hits the scan button several times in a row, for example? Well, the browser hangs, the scan is lost, and they have to refresh and then start the scan all over.
Getting a different perspective means we ask different but equally important questions so that we can approach testing and development problems from a novel angle.
3. Setting Up Environments
When I first started in software, environment management was not a simple thing. We had an IT team that would build our infrastructure, as well as a build manager who knew our build system in and out and was also responsible for deployment and configuration. Today, most testers I talk with are managing their own build process and environments.
My current project uses feature branches. Before we start working on a change, we create a new branch based on the latest information in our main code repository. Every change we make is in this little corner of the code base. Throughout the development cycle of a change, I build new containers based on this code branch, then deploy that container to a test environment.
This helps me for testing because I always have an isolated place to test a new change where problems won’t affect the rest of the team. It’s no big deal if I end up using up all available server resources and needing to restart.
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.
4. Refining the Backlog
One of the more difficult things to manage in a backlog is the dependency chain. It doesn’t make sense to work on user management before authentication is built, and adding a new element to our form manager can’t start until current work is complete. Just to make that more interesting, there are four cards that all need to touch the same part of the code base.
In my current project, I see testers heavily involved in making the backlog a useful thing. This means refining the queue so that changes with dependencies are worked in the right order, making sure that developers aren’t creating a merge conflict nightmare when working on the same part of the code base, and checking that we don’t have multiple spikes or research cards happening at the same time.
5. Cross-Pollinating Skills
More often than not, we stop testing because we are out of time — not because there are no more problems to discover, or because we performed every possible meaningful test we could think of, or because we’re just that good. At some point, we need to get that new code into production.
There is always more work than time; this is why complete testing is impossible. This is compounded by the fact that people get sick, take vacation, go to training events and conferences, and might be unavailable for other reasons. We can’t depend on one person to do all the testing we need to do.
On my current project, we spend most of our development time in pairs: Two people work on one change until it is ready to go to production. There may or may not be a test specialist there to perform the exploratory testing, but at a minimum, we have someone to talk about test coverage.
Let’s say I am one half of a pair working on a change to the scanning functionality I previously mentioned. We are making progress and have some part of the change ready to look at in an environment. I build a new container and deploy it to a test environment, but then a reminder pops up, and I have to go to a meeting for the next two hours. Life doesn’t stop because I have to go to a meeting; the changes still need to be tested.
In this case, I outline several of the test scenarios I think are important: scan one page, some pages and a lot of pages, perform sequential scans, edit scan attributes, spam the scan button and so on. This gives a person who is not a test specialist a place to begin. When I get back, we debrief on the testing they performed, what they found, and if they have ideas about additional testing that needs to be done.
Over time, this helps grow testing skill in someone who is mostly a developer, in the same way that pairing helps grow development skill in someone who is mostly a test specialist.
Value Your Skill Set
The testing skill set is broad and useful. While our main function in the organization is to test software and shine headlamps on a project, we also contribute heavily to development projects — sometimes in surprising ways.
What work do you do day to day that isn’t software testing? How does that contribute to the larger software development organization?
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
