在Agile Team中RD和QA的比例為何?
Tester-Developer Ratios on Agile Teams
http://lisacrispin.blogspot.com/2008/12/tester-developer-ratios-on-agile-teams.html
上次提到微軟對RD:QA比例的看法, 這次我們來看在agile team中, 比例應該又是多少?
作者提到這需要看情況, 那要看什麼情況呢? 以下是他考慮的因素:
1. Are the developers doing a good job of TDD? Does the team use acceptance tests to drive development, also?
2. How good is the automated regression test coverage?
3. How good is the communication between developers and customers?
4. Is the application testing-intensive, or does testing go pretty fast compared to coding?
5. Do the developers help with testing activities such as automating acceptance tests?
作者舉了三個例子
Example 1
(1) Project的背景
- My current team works with a financial services web app that is quite testing-intensive.
- The functionality is complex, and since we are dealing with peoples' money, we have to get it right.
- For some stories, testing takes more time than coding.
(2) RD所做的事情
- Our programmers are quite experienced in TDD and our regression test coverage is excellent.
- While our developers and customers sit close to one another and communicate well, and the developers have a high degree of domain knowledge, our stories are often quite complex.
- The developers take on a lot of testing tasks, including automating FitNesse tests and often writing the FitNesse test cases themselves.
(3) QA所做的事情
- A lot of tester time is devoted to working with customers to get examples of desired behavior and sort out technical challenges and other questions.
(4) RD:QA
- We have five programmers and two testers, and even so, the developers often have to pitch in extra on testing.
Example 2
(1) Project的背景
We were developing a non-critical internal application that would be used by a few expert users, so it wasn't the end of the world if the functionality wasn't perfect.
While the team did a good job of TDD, and we had good communication with customers despite the fact that we were a distributed team, this was clearly not enough.
(2) RD所做的事情
One or two developers or business analysts wore a tester "hat" each iteration and performed testing activities.
(3) QA所做的事情
I worked hard to transfer my testing knowledge to everyone on the team, so that our unit tests covered more test cases, and we could automate at least some of the functional regression tests.
(4) RD:QA
20 more more developers (subdivided into smaller teams but all working on one project) and I was the only official tester.
Example 3
(1) Project的背景
At first, the programmers could not get a handle on TDD or even unit test automation after coding, and I was buried.
I asked our coach for help. He helped us figure out how to get traction on unit testing, by providing training and time to learn.
Once the team mastered TDD, and pitched in on functional test automation, I was able to handle the other testing activities and we all worked well together.
(2) RD:QA
8 programmers and me, the tester.
由這些例子看起來, 如果RD可以大量apply TDD, unit testing, 也就整個開發活動是testing-intensive, 則可以讓QA專注於大量use case, or business scenarios. 這樣QA就不用佔有很高的比例.
我想這個結論, 和上次Microsoft QA manager的想法大致雷同. 若是RD能做更多基礎測試, 則系統會更穩定, regression testing能更快速, 也就是要讓RD確保do the thing right.
這樣QA就會有空確保do the right thing, 確認user想要的scenarios, 或是真正的use cases能夠正確運作. 而不是讓QA把時間大量花在do the thing right的測試上, 這樣就沒有空去照顧到do the right thing的部份, 這地方才是QA真正價值所在.
所以當一個team真正apply agile時, RD會做大量的test automation去確認do the thing right的部份. 這時候, 若是QA無法提升do the right thing這部份的能力, 小心啊, 你到時會被認為是多餘的....
Tester-Developer Ratios on Agile Teams
http://lisacrispin.blogspot.com/2008/12/tester-developer-ratios-on-agile-teams.html
上次提到微軟對RD:QA比例的看法, 這次我們來看在agile team中, 比例應該又是多少?
作者提到這需要看情況, 那要看什麼情況呢? 以下是他考慮的因素:
1. Are the developers doing a good job of TDD? Does the team use acceptance tests to drive development, also?
2. How good is the automated regression test coverage?
3. How good is the communication between developers and customers?
4. Is the application testing-intensive, or does testing go pretty fast compared to coding?
5. Do the developers help with testing activities such as automating acceptance tests?
作者舉了三個例子
Example 1
(1) Project的背景
- My current team works with a financial services web app that is quite testing-intensive.
- The functionality is complex, and since we are dealing with peoples' money, we have to get it right.
- For some stories, testing takes more time than coding.
(2) RD所做的事情
- Our programmers are quite experienced in TDD and our regression test coverage is excellent.
- While our developers and customers sit close to one another and communicate well, and the developers have a high degree of domain knowledge, our stories are often quite complex.
- The developers take on a lot of testing tasks, including automating FitNesse tests and often writing the FitNesse test cases themselves.
(3) QA所做的事情
- A lot of tester time is devoted to working with customers to get examples of desired behavior and sort out technical challenges and other questions.
(4) RD:QA
- We have five programmers and two testers, and even so, the developers often have to pitch in extra on testing.
Example 2
(1) Project的背景
We were developing a non-critical internal application that would be used by a few expert users, so it wasn't the end of the world if the functionality wasn't perfect.
While the team did a good job of TDD, and we had good communication with customers despite the fact that we were a distributed team, this was clearly not enough.
(2) RD所做的事情
One or two developers or business analysts wore a tester "hat" each iteration and performed testing activities.
(3) QA所做的事情
I worked hard to transfer my testing knowledge to everyone on the team, so that our unit tests covered more test cases, and we could automate at least some of the functional regression tests.
(4) RD:QA
20 more more developers (subdivided into smaller teams but all working on one project) and I was the only official tester.
Example 3
(1) Project的背景
At first, the programmers could not get a handle on TDD or even unit test automation after coding, and I was buried.
I asked our coach for help. He helped us figure out how to get traction on unit testing, by providing training and time to learn.
Once the team mastered TDD, and pitched in on functional test automation, I was able to handle the other testing activities and we all worked well together.
(2) RD:QA
8 programmers and me, the tester.
由這些例子看起來, 如果RD可以大量apply TDD, unit testing, 也就整個開發活動是testing-intensive, 則可以讓QA專注於大量use case, or business scenarios. 這樣QA就不用佔有很高的比例.
我想這個結論, 和上次Microsoft QA manager的想法大致雷同. 若是RD能做更多基礎測試, 則系統會更穩定, regression testing能更快速, 也就是要讓RD確保do the thing right.
這樣QA就會有空確保do the right thing, 確認user想要的scenarios, 或是真正的use cases能夠正確運作. 而不是讓QA把時間大量花在do the thing right的測試上, 這樣就沒有空去照顧到do the right thing的部份, 這地方才是QA真正價值所在.
所以當一個team真正apply agile時, RD會做大量的test automation去確認do the thing right的部份. 這時候, 若是QA無法提升do the right thing這部份的能力, 小心啊, 你到時會被認為是多餘的....
