Today we had a good presentation at the Oklahoma City Red Earth QA SIG. Carey Schwaber of Forrester Research discussed the value and approaches for establishing a Software Testing Center of Excellence (COE). Thanks to Carey, as well as David Vance of Forrester, who facilitated the presentation.
I enjoyed the presentation because the Testing COE is an effective way to deal with opposite poles of how software testing is organized.
There has been a debate in the software testing community for many years now (dating back to the early 90's) about which is better - independent, centralized testing or decentralized, distributed testing. Really, there are pros and cons to each approach.
In my book, Surviving the Top Ten Challenges of Software Testing, two of the challenges are strongly rooted in centralized testing groups. One challenge is "Testing What's Thrown Over the Wall". Another challenge is the "Lose/Lose Situation", where testers are seen as solely responsible for high quality. On one hand, testers are paid to find defects. However, if they find too many defects, then they are the problem.
In both of these challenges, the isolated nature of the test team often contributes to the problem. It is important to understand that the challenges can be overcome, but there's a gravity that keeps pulling toward the problems.
Then there's the other ditch I often see in performing test assessments. That is, there's a lot of testing activities being performed throughout the organization, but they typically aren't co-ordinated very well. In fact, it's common in this situation for the activities to be in conflict with each other. The value for the investment in testing is reduced to a very low level. I often say that "there's a lot of stuff laying on the floor", meaning that the testing "process" (and I use that term lightly) is in pieces and in ineffective.
The great thing about a testing COE is that it can be a balance between these opposite poles. A Testing COE, as I often define it is "a facilitation team that supports the efforts of software testing across the orgination and promotes effective software testing approaches for all projects."
The big takeaway for me from Carey's presentation was how the scope of the testing COE can span four levels, from establishing the guidelines and standards for testing through the fourth level, which actually performs testing except for developer testing. I think it's a good idea to have a growth path for a testing COE.
By the way, the four levels of COE scope presented by Carey are:
1) establishing the guidelines and standards for testing
2) level 1 activites, and also provides a common infrastructure for testing (such as test environments, test data, test tools, documentation templates, etc.)
3) level 1 and 2, plus performs independent verification and validation to supplement the testing performed by the project teams
4) levels 1, 2 and 3, plus performing all testing except for developer testing (such as unit testing)
Just like a true QA team (one that manages quality - not a test team), a testing COE can be marginalized because of the perception that it doesn't contribute materially to projects. Although the support role of QA is hugely important, when push comes to shove, people choose testing over QA because testers find defects which can be reported and fixed.
So, a testing COE needs to add tangible value by actively engaging in projects.
Establishing a testing COE requires high-level management leadership and investment. It also requires organizational buy-in so that people will actually accept the leadership of the testing COE.
If you are feeling the pain of the extremes in software test organization, you may want to consider proposing and establishing a testing COE. If you need help in doing that, call or e-mail me!
I enjoyed the presentation because the Testing COE is an effective way to deal with opposite poles of how software testing is organized.
There has been a debate in the software testing community for many years now (dating back to the early 90's) about which is better - independent, centralized testing or decentralized, distributed testing. Really, there are pros and cons to each approach.
In my book, Surviving the Top Ten Challenges of Software Testing, two of the challenges are strongly rooted in centralized testing groups. One challenge is "Testing What's Thrown Over the Wall". Another challenge is the "Lose/Lose Situation", where testers are seen as solely responsible for high quality. On one hand, testers are paid to find defects. However, if they find too many defects, then they are the problem.
In both of these challenges, the isolated nature of the test team often contributes to the problem. It is important to understand that the challenges can be overcome, but there's a gravity that keeps pulling toward the problems.
Then there's the other ditch I often see in performing test assessments. That is, there's a lot of testing activities being performed throughout the organization, but they typically aren't co-ordinated very well. In fact, it's common in this situation for the activities to be in conflict with each other. The value for the investment in testing is reduced to a very low level. I often say that "there's a lot of stuff laying on the floor", meaning that the testing "process" (and I use that term lightly) is in pieces and in ineffective.
The great thing about a testing COE is that it can be a balance between these opposite poles. A Testing COE, as I often define it is "a facilitation team that supports the efforts of software testing across the orgination and promotes effective software testing approaches for all projects."
The big takeaway for me from Carey's presentation was how the scope of the testing COE can span four levels, from establishing the guidelines and standards for testing through the fourth level, which actually performs testing except for developer testing. I think it's a good idea to have a growth path for a testing COE.
By the way, the four levels of COE scope presented by Carey are:
1) establishing the guidelines and standards for testing
2) level 1 activites, and also provides a common infrastructure for testing (such as test environments, test data, test tools, documentation templates, etc.)
3) level 1 and 2, plus performs independent verification and validation to supplement the testing performed by the project teams
4) levels 1, 2 and 3, plus performing all testing except for developer testing (such as unit testing)
Just like a true QA team (one that manages quality - not a test team), a testing COE can be marginalized because of the perception that it doesn't contribute materially to projects. Although the support role of QA is hugely important, when push comes to shove, people choose testing over QA because testers find defects which can be reported and fixed.
So, a testing COE needs to add tangible value by actively engaging in projects.
Establishing a testing COE requires high-level management leadership and investment. It also requires organizational buy-in so that people will actually accept the leadership of the testing COE.
If you are feeling the pain of the extremes in software test organization, you may want to consider proposing and establishing a testing COE. If you need help in doing that, call or e-mail me!
On a personal note, today is my grandson's fourth birthday. Braeden Scott Rice was brought into this wild and crazy world 4 years ago today and our lives have never been the same. Happy birthday, Braeden!
No comments:
Post a Comment