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.
From 2006 to 2010 I worked for a company that consisted of distinct testing and development groups. Each group had their own hierarchy, including staff contributors, leads, a manager and maybe an architect. Our Test Manager was the Battle Master general. Every new sprint started with contention. The development groups would have meetings to prepare for the sprint. The testing group I worked in would hear about these meetings a day or two later. When we found out, our Test Manager would jump into action. He spent hours in each sprint listening to the development managers claim that having testers in pre-sprint meetings would slow progress down. He would spend more time trying to explain why having the test group involved in the meetings would save time over the course of the release.
During feature development, our Software Test Manager took on a different role; he became the principle bug advocate. Developers saw new bugs as a distraction from finishing new features. Bugs would accumulate like a trash heap, and then at the end of each day a few Development Managers, the Product Owner, and our Test Manager went to a triage meeting. That meeting was a negotiation. Every software project worked under a limited time scale. One way to work within the time limit is to re-categorize bugs as feature requests and trivial things that don’t need to be fixed. Another way to deal with the problem is to say the bugs couldn’t be reproduced. Our Test Manager was there to advocate the customer, and convince other managers that the problems we reported were problems that should be fixed.
Towards the end of a release cycle, our Test Manager became an umbrella, shielding us from a storm of pressure. He was required to produce daily metrics on bugs reported, regression test velocity, and projections of when we would be done. As a testing group, we were often performing pre-release testing and driving toward releases while features were still being finished. This large amount of shuffle and change created failure demand. For example a feature that works today might not work tomorrow. The question of “why is testing taking so long” never stopped. The question that should have been asked is “why is this code so hard to test”.
It took our Test Manager a lot of time to defend our team. He spent his remaining time encouraging skill development, facilitating a smooth work flow and completing typical administrative managerial duties like hiring and performance reviews.
A lot of the Test Manager’s value was in shielding our team from organizational dysfunction. Our manager had to work as an intermediary because of divisiveness between teams. He had to fight for bug fixes because no one could agree upon what quality and completion meant.
Why Test Managers are Disappearing
The teams I have worked with recently do not have a Test Manager.
I am working on a full time UI automation project right now. My days begin by inspecting the automated tests that failed in the overnight run. I start this process by rerunning the test so I can observe what is happening in the browser. Once this is completed, I abandon the automation tool and perform follow up testing. I will examine what happens if a value is different, what happens if we use Chrome instead of Internet Explorer, and what happens if we approach the feature from a different place in the software. When I discover something interesting I start a conversation with the developer. That problem might turn out to be an important bug. It might be a component that is still under development, or it might be something that the customer doesn’t care about. If it is a bug, then the developer fixes the problem, or puts the problem in his work queue.
Rather than a death march, we coast into pre-release testing. The test suites discover most of the bugs created during feature development, which means they can be fixed relatively quickly. Before a release, the project lead merges all of the new code changes from the development branch into customer configuration branches. Over the next few days we watch the test results carefully for surprises. Usually we will find one or two problems exposed by different product configurations. When we do, I demo those problems to the development team, and they get fixed.
There is no intermediary between myself and the development team. No one that acts as a communication barrier. When problems are found, we talk about them. When big product changes are approaching, we talk about them. No one needs to protect the testing group from Development Managers, and no one has to take time away from testing to generate reports.
This team isn’t agile, but we have a lot of the fundamentals down. Rather than having distinct technical teams, we are blended. Programmers work closely with testers and product owners to drive toward production. There are no identifiable hand-offs between skill sets; there is more of a flow. Removing organizational dysfunction removes much of the traditional role of a Test Manager. On this project ancillary Test Manager roles like facilitation; skill development and performance reviews are a matter of personal responsibility. If we want to go to a conference or take a training course, we do. There are no performance reviews to be administered.
Agile has developed into a framework that helps people chop dysfunction out of their teams. One team might have a series of hand-offs between roles. For example, product owners manage the requirements and user stories, programmers take those and turn them into software, and testers take new code and discover problems. Blended teams simply communicate with each other. Over the course of a day, a product owner, programmer, and tester might sit down together to work on a feature. As the product owner explains their vision, the programmer turns that into code. As soon as the new code can be run, the tester can ask questions, build test automation, and investigate the software. In the highest functioning teams, new features are ready to ship when the programmer checks new code and triggers the Continuous Integration system.
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.
What is Next
The future I am seeing is one with fewer, if any Test Managers.
Teams that were once separate and distinct are now small and blended. Walk into the development room at a software company, and you might find small groups of developers and testers sitting together. They are working on the same projects, reporting in the same status meetings, and they work under the same managers. Instead of taking explicit instructions from a manager, these teams are mostly self-directed. They pull their work from the top of an organized queue. When the programmers have implementation questions, they ask the product owner directly.
The organizational hierarchy gets flattened when technical staff can direct their own work. The middleman between the testers and the rest of the team, the Test Manager, is no longer required. The need for a person to keep a pulse on testing status disappears. At this point, there is one thing to keep track of and report on; how close to completion and shipping are we. This can be done by the technical staff.
Some of the larger organizations will have a practice lead or “coach” role. This person works with development teams on test design and teaches skills that would normally live in the Test Manager. However, most people in the Test Manager role now have a choice to make. They can linger in the shrinking number of companies that still require this role, hoping to eek out a few more years, or they can move on to other roles. That might mean moving back to a technical contributor role like programmer or tester. It could also result in moving into a non-technical role like product and account management.
The industry can be slow to embrace new ideas and ways of working in software development. It takes even longer for a critical mass of companies to adopt these ideas. Watching the trends can help us prepare for the future. For those in the role, it is important to consider what your future as a Test Manager will look like. A good question to ask is: “Where do you want to go from here?”
