Optimal Organizational Structures for Testing Teams

Organization structures for Testing Teams

A number of organizational structures are possible, each having its own positives and negatives. Figure shows a structure often used by small (fewer than 10 or so people) project teams. In this structure, the test group reports into the Development Manager, the person managing the work of the programmers.

The Development Manager's goal is to have his team develop software. Testers reporting bugs just hinder that process. Testers doing their job well on one side make the programmers look bad on the other. If the manager gives more resources and funding to the testers, they'll probably find more bugs, but the more bugs they find, the more they'll crimp the manager's goals of making software.

Despite these negatives, this structure can work well if the development manager is very experienced and realizes that his goal isn't just to create software, but to create quality software. Such a manager would value the testers as equals to the programmers. This is also a very good organization for communications flow. There are minimal layers of management and the testers and programmers can very efficiently work together.

Figure shows another common organizational structure where both the test group and the development group report to the manager of the project. In this arrangement, the test group often has its own lead or manager whose interest and attention is focused on the test team and their work. This independence is a great advantage when critical decisions are made regarding the software's quality. The test team's voice is equal to the voices of the programmers and other groups contributing to the product.

In this structure , the test group that reports to executive management has the most independence, the most authority and the most responsibility. The independence that this group holds allows them to set standards and guidelines, measure the results, and adopt processes that span multiple projects.

A corporate quality standard that works well on database software might not work well when applied to a computer game. To be effective, this independent organization must find ways to work with all the projects they deal with and temper their enthusiasm for quality with the practicality of releasing software. quality

In software development and testing, one size doesn't necessarily fit all, and what works for one team may not work for another. There are, however, some common metrics that can be used to measure, and guidelines that can be followed, that have been proven to work across different projects and teams for improving their quality levels.