Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
There are pros and cons to both approaches. If the test group is expected to perform quality assurance activities -- those activities that monitor the software development processes -- it might be better to have a centralized team.
Centralization allows for the team to set organizational standards, ensure consistency in processes, share tools and best practices and impose some autonomy to the quality efforts. Often when testing and QA are part of the development team, delivery schedules trump quality.
On the other hand, it is very important for the test engineers to have a close relationship with the developers and intimate knowledge of the application under test. When the team is part of the same organization there is often better communication and testers are involved earlier in the development cycle, often working side-by-side with developers, leading to quicker bug detection and a higher quality product.
My opinion would be keep QA activities and personnel centralized, but to pair testers with developers early in the software development cycle. If the QA and test team are the same team, then organizationally I would suggest a centralized QA team, with testers having a dotted-line reporting relationship with the development team. In essence, the tester would have two teams – the QA team and the project team.
Regardless of model, the key is strong communication and collaboration between development and test. If the test team is separated organizationally or geographically from the development team, this will be more of a challenge, but given the appropriate attention, it can definitely be accomplished.
This was first published in February 2010