There are so many different opinions within best practices of testing as far as where the software testing organization should reside within the organization. Here are some of the most common approaches.
1. Independent. Have the software testing organization outside the development organization. This one has several advantages and disadvantages. First, it provides the necessary separation between development. Thus you do not get into a situation where “The Fox is Guarding the Hen house”. It makes sense because testing is separate from development. If there is a discussion around should a piece of software should be deployed into production, the respective organization leadership can sit down and determine if the software should be deployed. From a disadvantage perspective, it often results in an adversarial relationship between development and testing. Typically with an us versus them mindset. It can result in some pretty significant battles between the organizations. The most important thing to remember when these differences arise is what is ultimately best for the customer?
2. Within Development. This is also a common practice. It helps to bring both the development and testing organizations together. While there should be at least a manager that leads both development and testing, at some point within the organization there is a person who is responsible for both development and testing. However, it does have the “Fox is Guarding the Hen house”. Depending on the company and even the person that is responsible for both groups, there will be a tendency to either side with development or testing. For example, if the person responsible has a background in testing, they are usually going to lean towards high quality releases. On the other hand, if the responsible person has a development background, they will lean towards a little less quality and faster software cycles. Regardless, it is extremely important for both groups to work towards the best quality possible.
3. No Department. It is pretty fair to say that this is the least preferred approach. However, it might be the case in organizations that are extremely small. If this is the case, there should be testing done on the software that is deployed and there should be some sort of metrics that are captured to make sure that testing is occurring and that software is getting better over a period of time. Even without a formal organization, testing can occur and it can be done well.
Regardless of the approach, the ultimate objective is to have good testing practices. With good practices, software quality will be higher. Continue to produce great quality software, regardless of the organizational structure of software testing.
If you would like more information on Agile, DevOps or Software Testing, please visit my Software Testing Blog or my Software Testing YouTube Channel.
[…] am currently working to create a TCOE at my current company. Check back for frequent updates on this post as I will be updating it as I […]