Software testing teams should have a defined place within a company's structure. Testing expert Mike Kelly and requirements expert Rob Apmann answer a reader's question about where testing fits. Asks the reader, "Where does the testing organization belong in the over all structure of a company? Should the organization be a sister to development or should it be a suborganization within your IT risk group? I am the sole QA person within my organization and I report to the IT risk manager whose focus is the Sarbanes-Oxley Act (SOX) and ITIL.
"Since taking on the role of QA, I've tried to focus on a core problem within the organization, fixing our requirements gathering process or lack thereof. I fear not fixing the requirements gathering process will doom the QA initiative to something else we've tried but failed at."
Mike Kelly's response:
Unfortunately, as much as this question excites me my initial response is that I don't have enough information about your specific situation. There is no universal model for structuring a testing organization (or any organization) and I couldn't provide you with any advice without understanding the other systems that your structure is influenced by.
Last year, as I looked to build my own testing organization, I read several Dean Meyer books on how to structure organizations. Much of Meyer's material is built on the framework of five organizational systems:
- "Culture: The behavioral patterns (habits and conventions) generally adopted within the organization.
- Structure: The definition of jobs and the reporting hierarchy (organization chart), as well as the processes that combine people into teams as workflows across organizational boundaries.
- Internal economy: The budgeting, priority-setting, pricing (chargebacks), project approval, and tracking processes that determine how resources flow through an organization and to its clients.
- Methods and tools: The procedures, methodologies, skills, and tools that people in an organization use.
- Metrics and rewards: The feedback loops that let people know how they are doing so they can adjust their behavior, and the incentives for improving performance."
When you look at where testing should fit in your organization, you'll need to account for all five systems and the impact those systems have on the organization.
There is a lot of free content on the topic available on the NDMA website. If you prefer books to online content, I've read and recommend the following:
Structural Cybernetics: An Overview
RoadMap: How To Understand, Diagnose, and Fix Your Organization
The Building Blocks Approach to Organization Charts
Rob Apmann's response:
In my experience the QA organization is typically one component of the development organization. This generally seems to be a successful approach, since close communication with development is often required to reconcile the requirements versus the working application. If QA and development were part of separate organizations I am not sure that required level of close communication would occur.
Requirements are going to come from two directions. The primary requirements defining what the system does will come from the business analyst or product managers, and some of the requirements should be driven by the IT risk group. A good BA / PM should incorporate the nonfunctional requirements; such as, supported Web servers and version numbers so that the application meets the requirements of the IT risk group. They should also incorporate requirements that will drive the test suite. There might be a requirement that all passwords remain encrypted at all times even when in memory. Development should know about this requirement and QA should be planning to test whether it was met. Determining how to test that example would probably be simplified if QA and development were working closely together and part of the same organization.
