Large Companies used to have a tall structure with clear team divisions and responsibilities; testing teams and development teams worked separately, with separate managers for each, and often in different rooms or buildings. Today, the organizational structure of a software company looks different: charts are flatter. Test groups are dissolving as testers are embedded into technical teams. This means that test management must also change.
In order to stay relevant, you need to adapt to growing technology trends and the way consumers interact with software. Below are some eye-opening trends that you cannot afford to overlook in the 2nd half of 2016 and early 2017.
Test Managers are Disappearing
Years ago, each role in a development team — programmers, testers, DBAs, and product managers — had its own space in a building, and each role had its own manager. A major trend now is the blending of blended teams, which combine those roles so that one small team has members with every skill they need to complete a feature. These new teams require new types of managers.
Small technical teams tend to be self-directed. In an ideal situation, product managers have created a prioritized backlog. When a group needs a new task, they pull from the top of the backlog and start working. Managers, when they are needed, remove anything blocking a feature from being completed. That might be coordinating dependencies with other development team, gathering information about how a feature should work, or helping a team find someone with a skill set they are currently missing. Test managers are now finding themselves in product management or Agile coaching roles.
Tools are Improving
Ten years ago test management tools were an obstacle: test management systems consumed computer resources that testers needed for other tasks, like running resource intensive websites and using database tools. Five years ago, test management systems became available on the web. A tester could sign into a website and document new test ideas or perform a set of tests that were already in the system. These TCMs were less resource intensive, but often so bloated with features that navigating the tool became too time consuming.
TCM tools have improved now to the point that they are useful for both testers and managers. Testers can reliably document test ideas, then add supplemental information (like videos and screenshots) to share with their teams. Managers can easily run reports on test progress and product coverage to inform decisions about whether or not the product is ready to ship.
Programmers are Testers and Testers are Programmers
Technical testers today work hand in hand with people writing production code. They guide the programmer by asking typical tester questions — what happens when the user enters a long value here, what if this field is null — while the feature is still being developed. By the time new code is ready to check in, it has been reviewed, tested, and has a set of automated tests. This is reality at a handful of software companies now. Expect to see more in the near future.
Meaning programmers are coming to the center as well, developing strong skills by working closely with technical testers. Typical testing strategies for a programmer before collaborative work was popular was mostly based on code design techniques like test driven development. Despite having the name ‘test’ in these techniques, they are mostly focused on confirming the programmers ideas about what they built and building change detection. Test driven development and unit testing are good tools for improving code quality, but are not great at predicting where software will fail. After working collaboratively with testers, programmers develop some testing skills like observation, modeling and critical thinking. They may still not be testing experts, but they develop a stronger skill set than they entered with.
How to Surf the Wave of Change
Ignoring these changes is one option, and it might work. Some organizations are not embedded testers in the teams or changing management. In that case, the problem will be delayed until there is a need to change companies, and the candidate will be unprepared.
Instead of ignoring the changes, consider the embracing and leading them – which Carol Brands did at DNV GL Software and led to her getting a speaking slot at the recent Conference for the Assoc.