The Role of the Test Manager in an Agile Organization

Summary: If you’re a test manager–or any sort of manager, for that matter–in a company that’s transitioning to agile, you might be curious about where you stand in the new environment. Many of the traditional management roles are gone, but managers still have their place. As Johanna Rothman explains, it’s time to think about coaching, removing obstacles, providing career development, and building relationships and organizational capacity. What do test managers do? In traditional organizations, they assign people to projects, oversee the testers’ progress, provide feedback, and maybe offer some coaching to people who want it. They are the go-to people when you don’t know how to do something—not because they know, but because they should know who does know. Test managers build trusting relationships with their staff and build the capacity of the testing group. Building capacity in the testing organization has two components: hiring more people when appropriate and providing a forum for education and training. Sometimes that training is cross-training in the group, and sometimes it is a form of expert-led training. How does that change with a transition to agile? Do we still need test managers? Or development managers? Or any kind of functional manager? Yes. The problem is that we need test managers and any other functional manager to do different work. We still need them to build trusting relationships with people and to build capacity in the organization, but which people and what kind of capacity? How Agile Changes the Organization As organizations move to agile approaches, the project team members learn from each other and take a more generalist approach to product development....

Sunny Skies or Storms

Summary: Long-time advocate of status reports, Johanna Rothman has come across a new way of reporting the movement of a project using something we experience everyday–the weather. In this week’s column, she sheds a little sunshine on this new technique, which demonstrates the status of a project a lot like meteorologists announce current weather conditions. I’ve long advocated test managers having a mission of assessing the state of the project and reporting on it. This assessment compares where the project is to where it should be—not including audits of the project or the process. To be honest, I don’t care whether the project manager or the test manager assesses the project on a regular basis—only that someone does it. A project dashboard explains all the details about the project state . And, in most organizations, people need to understand what the data means. What better way to lift the fog of confusion than to present your information in a concise way everyone will understand? And everyone knows weather. Weather reporting is great technique to explain the project state assessment. Some may use the traffic light model–red, yellow, and green–to denote the project’s state. This model shows today’s state, but it’s hard to see where the project is headed. I haven’t found the traffic light useful, due to the static nature of the assessment and the limit of three levels to denote project state. And unlike traffic lights that automatically change, projects don’t change unless the project manager and the team act to change them. Projects tend to continue in the direction the team is heading. Most senior managers want to see a weekly...

An Incremental Technique to Pay Off Testing Technical Debt

Technical debt is the unfinished work the product development team accumulated from previous releases. This debt includes: design debt, where the design is insufficiently robust in some areas; development debt, where pieces of the code are missing; and testing debt, where tests were not developed or run against the code. Technical debt is common, but the practices in this article may help you reduce the amount in your project. Let’s assume your current project has substantial testing debt — the state of the software could be better understood if you could run more tests, automated or not, in several areas of the product. But the amount of debt is so large that it seems like an overwhelming problem to write, or even plan, a lot of tests, never mind trying to determine which ones to automate. If that’s the case on your project, consider trying these practices: Decompose each area into several use cases or scenarios. If you don’t define requirements with use cases or scenarios, use your own technique to break the big area into smaller pieces. You don’t have to have perfect requirements, but you do need to have a specific idea of what you need to test. Rank the areas according to risk. Develop tests in timeboxes, starting with the highest risk areas, until this release is complete. Once you’ve finished the work for this release, you’ll want to reevaluate the risky areas (in case the product has changed direction) and follow these steps again. Decompose Each Area into Scenarios Let’s assume you have a store application on the Web. The only part of the product...

An Incremental Technique to Pay Off Testing Technical Debt

Technical debt is the unfinished work the product development team accumulated from previous releases. This debt includes: design debt, where the design is insufficiently robust in some areas; development debt, where pieces of the code are missing; and testing debt, where tests were not developed or run against the code. Technical debt is common, but the practices in this article may help you reduce the amount in your project. Let’s assume your current project has substantial testing debt — the state of the software could be better understood if you could run more tests, automated or not, in several areas of the product. But the amount of debt is so large that it seems like an overwhelming problem to write, or even plan, a lot of tests, never mind trying to determine which ones to automate. If that’s the case on your project, consider trying these practices: Decompose each area into several use cases or scenarios. If you don’t define requirements with use cases or scenarios, use your own technique to break the big area into smaller pieces. You don’t have to have perfect requirements, but you do need to have a specific idea of what you need to test. Rank the areas according to risk. Develop tests in timeboxes, starting with the highest risk areas, until this release is complete. Once you’ve finished the work for this release, you’ll want to reevaluate the risky areas (in case the product has changed direction) and follow these steps again. Decompose Each Area into Scenarios Let’s assume you have a store application on the Web. The only part of the product...

The Influential Test Manager

© 2000 Johanna Rothman. This article was originally published in Software Testing and Quality Engineering, March/April 2000. Many of us have worked in test groups in which we felt as if we didn’t have enough time, hardware, or staff to do the work. In those situations it’s hard to escape the feeling that while somebody might be in control, we are certainly not. As a test manager you don’t have to work this way. There are other, more effective ways to develop and use your influence within your organization to help your test group–and project–succeed. Influence is not about control, nor is it about taking away other peoples’ choices. Influence is about coming to a mutually valuable decision about a problem–redirecting your organization’s power and focus. As a test manager, you may want to influence others in the organization when: Your management wants to release a product you know is full of defects, and you’re sure the customers will be disappointed with the release. Other managers ask you to give up equipment your test group needs to do their jobs, or you can’t get the equipment you need. Schedule slips shorten your test schedule, and your only alternative seems to be to test less. Your budget isn’t large enough to hire the people you need. These are examples of tactical problems in obtaining specific objectives. You can also exercise influence more broadly–strategically–to change how the organization perceives itself, or to change how it does business. As test managers we can be valuable agents of change. We have a different perspective on these problems than other managers in our organizations, because of our role in...