在Agile中如何進行測試的工作 (2)
QA and Testing in an Agile Environment
Chris, 05Nov
http://edgehopper.com/qatesting-in-an-agile-environment/
* Tim Lesher Says:
Tim認為前面那些agile testing 的作法, 在iteration最後階段會造成, QA會很忙, RD會很輕鬆. 因此為了避免學生症候群Parkinson’s Law (where the work expands to fill the remaining iteration time), Tim提出了一些修正:
1. Dev designs and codes; SQA designs tests and pokes holes in the design
2. SQA executes tests; Dev addresses issues and pokes holes in the tests
3. SQA executes acceptance tests and writes defects; Dev automates tests
The acceptance-level and integration-level tests that SQA is running during iteration N get automated by development, and take effect as part of the automated suite beginning in interation N+1.
目前這個作法仍持續在觀察中, 但是看起來還work
===============================================
* Gunther Verheyen Says:
Cunther在每天的工作中, 加入以下四項quality loops: (記住是在每天中做, 而不是到sprint的末期才做)
Loop 1.
- Developers work in pairs upon a test-first basis. By the way, a test-first also includes some GUI-testing
- For example, using Selenium: is a suite of tools to automate web app testing across many platforms.
Loop 2.
- Developers can refactor, i.e. rewrite working code to make it better, simpler, remove duplicate code etc.
- When a test-first no longer fails, the code is checked in and gets picked up by a Continuous Integration system. The CI runs multiple times a day.
- Logs are being checked regularly and rework is inserted into the team using a Kanban board.
Loop 3.
- The guide deploys a stable version from the CI to perform the functional testing.
- Functional feedback is inserted into the team using a Kanban board (items are generally too small to make it a Story).
Loop 4.
- (if applicabel) Overnight performance tests are performed on a deployed version using scripts with ramp-up’s, think time, etc.
Cunther覺得他們這樣做了以後, 基本上系統沒有在production, 或是sprint review中, 被發現大的bugs或是problems
===============================================
* Surendra Lingareddy Says:
Agile 所帶來的好處: The tendency to natural juxtapose QA and Dev.
- The planning meeting serves to select the stories for this iteration as well as to flush their details out.
- QA and Dev both along with the business (Prod Mgr and SCMs at least) walk out with the same understanding of what the story is.
===============================================
* Patrick Curtain Says:
主要做法: QA following one iteration behind
- Focus on black box test automation and maintenance of tests affected by change.
- That puts the focus (and personnel budgeting) on TDD in the dev team, continuous integration and flowing QA effort back into the team.
===============================================
* Bob Galen Says:
對Chirs前面的提作法有疑問
(1) Isn’t setting up some sort of intra-Sprint ’schedule’ sort of defeating the purpose of self-direction?
因為他認為以下事情比較重要
(1) The team buy-into the notion of getting things ‘done’ and
(2) that they need to work efficiently and effectively to maximize how much they deliver and the quality of what they deliver–so the team should be figuring this out–sort of on their own.
(3) Another part of that is significantly blending the individual roles–so that it’s the team working and not developers handing over things to testers.
所以Bob認為前面這些作法只是限制了sprint的精神, 感覺裡面還是存在著waterfall的骨子. 所以他認為是怪怪的.
Bob建議使用 kanban來幫助會比較好一點
- The whole notion seems to be to throttle the work (cards) that a team can take on to try and reinforce blended team behavior to drive work to done.
- So fewer in-process tasks/features, and heavy collaboration to get it done as quickly as possible. It seems that this leads to (the claims) to higher efficiency / effectiveness.
( notes: kanban是源自於Toyota的看板文化, agile中有使用這個觀念. 不過老實說我不是很清楚Bob指的是什麼, 在網路上我還找到他所講的, 下次找到在share給大家)
===============================================
* Chris Says:
@Bob Galen:
這是Chris對 Bob意見的回應
- This is merely a suggestion as a way for teams to think about organizing their work to maximize the effectiveness and utilization of both the QA’s and the devs.
- Teams can self-organize and self-direct, and that is a real key to agile success.
- However, having some guidance or idea of how to attack the work of an iteration isn’t necessarily a bad idea.
@Patrick Curtain:
如果使用one iteration behind的情況要小心. 根據我的經驗, 一個user story 要到被測試完成才較被做完(done), 也就是到那個時候你才算你拿到那個story point , 也就是說你要到下一個iteration才算是completed or done.
這將會嚴重影響你team的velocity. 更重要的是user story為測試完, 這代表它可能是不能shippable, 因此對你的customer來說是沒有value的.
QA and Testing in an Agile Environment
Chris, 05Nov
http://edgehopper.com/qatesting-in-an-agile-environment/
* Tim Lesher Says:
Tim認為前面那些agile testing 的作法, 在iteration最後階段會造成, QA會很忙, RD會很輕鬆. 因此為了避免學生症候群Parkinson’s Law (where the work expands to fill the remaining iteration time), Tim提出了一些修正:
1. Dev designs and codes; SQA designs tests and pokes holes in the design
2. SQA executes tests; Dev addresses issues and pokes holes in the tests
3. SQA executes acceptance tests and writes defects; Dev automates tests
The acceptance-level and integration-level tests that SQA is running during iteration N get automated by development, and take effect as part of the automated suite beginning in interation N+1.
目前這個作法仍持續在觀察中, 但是看起來還work
===============================================
* Gunther Verheyen Says:
Cunther在每天的工作中, 加入以下四項quality loops: (記住是在每天中做, 而不是到sprint的末期才做)
Loop 1.
- Developers work in pairs upon a test-first basis. By the way, a test-first also includes some GUI-testing
- For example, using Selenium: is a suite of tools to automate web app testing across many platforms.
Loop 2.
- Developers can refactor, i.e. rewrite working code to make it better, simpler, remove duplicate code etc.
- When a test-first no longer fails, the code is checked in and gets picked up by a Continuous Integration system. The CI runs multiple times a day.
- Logs are being checked regularly and rework is inserted into the team using a Kanban board.
Loop 3.
- The guide deploys a stable version from the CI to perform the functional testing.
- Functional feedback is inserted into the team using a Kanban board (items are generally too small to make it a Story).
Loop 4.
- (if applicabel) Overnight performance tests are performed on a deployed version using scripts with ramp-up’s, think time, etc.
Cunther覺得他們這樣做了以後, 基本上系統沒有在production, 或是sprint review中, 被發現大的bugs或是problems
===============================================
* Surendra Lingareddy Says:
Agile 所帶來的好處: The tendency to natural juxtapose QA and Dev.
- The planning meeting serves to select the stories for this iteration as well as to flush their details out.
- QA and Dev both along with the business (Prod Mgr and SCMs at least) walk out with the same understanding of what the story is.
===============================================
* Patrick Curtain Says:
主要做法: QA following one iteration behind
- Focus on black box test automation and maintenance of tests affected by change.
- That puts the focus (and personnel budgeting) on TDD in the dev team, continuous integration and flowing QA effort back into the team.
===============================================
* Bob Galen Says:
對Chirs前面的提作法有疑問
(1) Isn’t setting up some sort of intra-Sprint ’schedule’ sort of defeating the purpose of self-direction?
因為他認為以下事情比較重要
(1) The team buy-into the notion of getting things ‘done’ and
(2) that they need to work efficiently and effectively to maximize how much they deliver and the quality of what they deliver–so the team should be figuring this out–sort of on their own.
(3) Another part of that is significantly blending the individual roles–so that it’s the team working and not developers handing over things to testers.
所以Bob認為前面這些作法只是限制了sprint的精神, 感覺裡面還是存在著waterfall的骨子. 所以他認為是怪怪的.
Bob建議使用 kanban來幫助會比較好一點
- The whole notion seems to be to throttle the work (cards) that a team can take on to try and reinforce blended team behavior to drive work to done.
- So fewer in-process tasks/features, and heavy collaboration to get it done as quickly as possible. It seems that this leads to (the claims) to higher efficiency / effectiveness.
( notes: kanban是源自於Toyota的看板文化, agile中有使用這個觀念. 不過老實說我不是很清楚Bob指的是什麼, 在網路上我還找到他所講的, 下次找到在share給大家)
===============================================
* Chris Says:
@Bob Galen:
這是Chris對 Bob意見的回應
- This is merely a suggestion as a way for teams to think about organizing their work to maximize the effectiveness and utilization of both the QA’s and the devs.
- Teams can self-organize and self-direct, and that is a real key to agile success.
- However, having some guidance or idea of how to attack the work of an iteration isn’t necessarily a bad idea.
@Patrick Curtain:
如果使用one iteration behind的情況要小心. 根據我的經驗, 一個user story 要到被測試完成才較被做完(done), 也就是到那個時候你才算你拿到那個story point , 也就是說你要到下一個iteration才算是completed or done.
這將會嚴重影響你team的velocity. 更重要的是user story為測試完, 這代表它可能是不能shippable, 因此對你的customer來說是沒有value的.
