Take your typical project.
New code appears in pieces — the front end is ready, but the API that front end makes request on isn’t even on a test server yet. There is a performance optimization project going on the side.
One tester is dealing with a critical support issue, another is supposed to get a new feature any minute now, and the last is completely blocked.
This is normal life in software testing. Work comes in fits and starts, and is often hard to predict.
How do we manage the flow of work and keep testers productive? Here are a few things that have worked for me.
1. Go beyond test cases
In the past when new feature development was just starting, the daily tester scrum was a steady flow of people saying write more test cases!
Test cases dominated the conversation, and it wasn't just during the start of projects. When testing finally started everyone was running test cases, and probably talking about how many were left, how many had failed, and how many needed to be performed again. The test cases didn't tell us about the quality of the product, and they certainly weren't helping me figure out when I was done testing. The test cases were acting as filler, something to do when we didn't know what else to do.
We can do better than test cases.
That period of time between when a release iteration begins, and the first testable thing is ready is certainly shrinking, but there will always be some delay. Instead of 'writing test cases' in that buffer, I'd rather contribute as a team member. Test Driven Development (TDD) is growing but is still something practiced mostly by outliers, the developers that really care about their work. The technology stack can be tricky of course, and the underlying premise of TDD is that the developer is actually good at testing.
Testers are professional test designers; those who have done it for over a year with attention are relative experts. That might be intuitive; we might not be able to explain the how or why we picked a certain combination of events to test, but we still have that hunch that proves useful. When I sit with a developer, I usually ask questions in rapid fire — how do you know what the value is at this point? What happens if the user clicks Submit too soon? If this code is changed will it break this — and at the end leave with a few new automated checks and hopefully a slightly better feature. When there is a build, I go all in, but there is no point when I'm just waiting.
I can already imagine the protests — this will take too long and we’ll get fewer features. Maybe, maybe not. You could get fewer features, but they would also be working better on the first try, while training the programmers to improve first-time quality. I have left a sprint more than once using this method with five working and ready to go features, instead of the usual three done and a fourth in a questionable state. Try it out with one person on one feature, and see how it goes.
2. Fix unnecessary blockers
Serious blockers, things that prevent you from working on the project at this very moment, are one of the big reasons iterations get that herky jerky, start and stop feeling. The worst offender is a new build that falls over the minute you look at it — the dead on arrival (DOA) build. At first glance, this might not feel like a testing problem. Surely the test team didn't cause the build to fail or login to throw exceptions. The problem is up-stream of testing.
On small teams, the hardest part of preventing the DOA build is cultural. I worked on a project once where a good week only had two or three DOA builds. On a bad week we didn't get much work done. Developers were working too many hours under too much pressure and things were falling apart. All it would have taken to move forward was the developer checking out the latest code and spinning up the build to poke around a little bit. Nothing too heavy, but enough to see that basic functionality is there.
If you're on a bigger team that is committing code not just a few times an hour, but more like a few times a minute, then grabbing the latest code probably won't do much good. By the time everything is checked out and running, your up-to-date environment isn't so up-to-date anymore.
Having some amount of automated checks running with every build, even on local development systems, can really help in this type of environment. In addition to being able to see when a new change potentially broke something else, you can easily see areas with no coverage and remember to look there for surprises.
But, what if the blocks are mental?
3. Make use of “down time”
The phrase 'I don't have anything to do' is like nails on a chalk board. There is almost always something that can be done on a project, somewhere I can work in and create value. We testers usually find ourselves in software, but there is a lot more we can do, and people that can be helped, in those rare instances that there is no new software to work on.
- Product Managers: Product managers are experts at talking with customers about their needs, and turning that vision into something the developers can use as a direction forward. In the past when things have been slow, I like to find those product meetings and start asking probing questions about who will be using the feature and what value they want. Maybe those questions help make a better feature. At a minimum, I walked away with a good understanding of software in the pipeline.
- Support: Support always has something time sensitive in the works. Sometimes that is a hard to reproduce bug, sometimes it is getting educated about what is in the latest release. The support call and email logs have always been useful for me. I like to look for patterns in questions to guide my testing and add weight to a report. If five people call that need help with some aspect of the product, I can probably find a bug.
- Documentation: I see documentation less and less. It seems that most companies are moving to SaaS and expect people to just figure it out. When I worked on a heavy weight installed product, the documentation needed to be tested just like the product. Do the new features work the way the docs explain? Are the installer instructions correct, do they actually work? There were always bugs to be found in those pages.
4. Think beyond the short-term flow
A lot of what i have talked about so far — finding waste; getting people past blockers — is geared toward getting people back into the game right now. That is a good strategy when we are worried about the next build, or even the next release, but we have to worry about the months in front of us, too. There are things we can do now that will pay off in the future.
Hopefully you have cross-functional teams, the next step is to develop a culture of pairing.
Two brains are usually better than one, and getting a developer and tester sitting together and working on a feature will have surprising results. I've done this a few times on teams with developers that trusted me.
The general idea was that we happened to both be in the office early when it was quiet and easy to work. I was playing some music and testing a change that made it into the build last night and that developer would ask me if I had a minute. I always did, and that builds trust. I'd roll over to his desk and ask for a demonstration of the change and take some notes about simple things, maybe a button that could be moved or a missing label highlight and then we'd get down to business.
I'd ask questions, like what happens when I add a special character here or forget to populate that field, and then we'd immediately try it out right there in the dev environment.
Sometimes we would find bugs, and I'd go off and do my own thing for a while while he fixed them. Sometimes, we could come up with questions that neither of us knew the answer to and we'd make a note to ask the product manager.
The end result was always knowing more about the feature, and having decent quality before the change made it into the test environment.
The other tool I like to use is strategic automation. This takes time to realize, there are technology stacks to learn, build systems to configure, and then the checks of course have to be written. One team I worked with had a product based on a REST API.
When I joined the team, there was one test against the API that made sure someone could authenticate, but that was it. My first task was to get that running with every build, so if authentication broke in an obvious way, we'd know about it before someone tried to log in.
Over the next few months, I spent time building out API tests in areas the developers were concerned about. I found quite a few problems while building the tests, and one by one they were added to the build system and would throw alarms when something bad happened. Finding out about problems faster helped us get them fixed faster.
Flow is all about smoothing out the ups and downs of software work to find a steady, stable pace to work. There are lots of reasons to work on flow — maybe you want to know how much software can be delivered in the next couple of months, or maybe you just want to not work your team to death.
Pick a place, smooth it out, and let me know how it goes.
Looking to improve the productivity of your testing team?
One of the best ways to improve productivity is to utilize a tool that enables you to easily reuse tests. Download our newest eBook, How to Become an Effective Tester by Reusing Tests.
