在Agile中如何進行測試的工作 (1)
QA and Testing in an Agile Environment
Chris, 05Nov
http://edgehopper.com/qatesting-in-an-agile-environment/
當作者要adopt 2 weeks的iteration時, 他問了很多人對於這樣的事, 有怎樣的concern. 以下是他得到的主要考量:
(1) QA’s and testers on an agile team have nothing to do at the start of an iteration.
(2) We can’t keep writing new code up until the last minute of an iteration if QA is to adequately test the code. So, what do the developers do at the end of the iteration?
因此作者提出它的作法, 希望能mitigate這些問題, 並且能讓QA在agile iteration中融入的很好.
1. 第一週
Day 1
Dev: Coding
QA: Write Tests
Day 2
Dev: Coding
QA: Write Tests
Day 3
Dev: Coding/Defect Fixes
QA: QA/Testing
Day 4
Dev: Coding/Defect Fixes
QA: QA/Testing
Day 5
Dev: Coding/Defect Fixes
QA: QA/Testing
2. 第二週
Day 1
Dev: Coding/Defect Fixes
QA: QA/Testing
Day 2
Dev: Coding/Defect Fixes
QA: QA/Testing
Day 3
Dev: Defect Fixes/Design/Story Development
QA: QA/Testing
Day 4
Dev: Defect Fixes/Design/Story Development
QA: QA/Testing
Day 5
Dev: Defect Fixes
QA: Acceptance Testing
細部說明:
前兩天
Dev:
- Get busy coding the stories in their backlog while the QA’s start writing test cases/acceptance tests.
QA:
- Start writing test cases/acceptance tests.
- Should also be running these tests against the existing code base.
- This validates that the test harness is working correctly and that the new tests do not mistakenly pass without requiring any new code.
- Obviously, the new tests should also fail for the expected reason.
- This tests the tests themselves, in the negative: it rules out the possibility that the new tests will always pass, and therefore be worthless.
接下來五天
Dev
- Continue coding and also start working on fixing any defects picked up in the testing.
- Pretty standard days. Code-test-fix.
QA
- Begin testing any testable code that has been completed.
第 8 天開始
Dev
- Effectively stop writing “new” code and focus their energy on fixing all defects identified in testing.
- If has no defect work or find themselves with down-time while waiting for testing results, they can and should be helping the product owner develop and refine the user stories that are likely to be played in the next iteration.
- Start considering the design aspects of the immediate upcoming stories and coordinating design decisions with the project architect.
QA
- Continue to test all of the remaining code written during the iteration.
最後一天上午
Dev
- Focus on bashing any remaining defects and making the code bombproof.
QA
- Spend most of their time doing some final acceptance testing
最後一天下午
- It’s time for your review and demo.
- You’ve tested and fixed everything so you and your team can demo with total confidence.
- No surprises for your team, you’ve built serious quality into your software!
作者在post完他的做法之後, 精采的來了, 一共有54 篇response. 一起來討論他們自己怎麼做agile testing. 讓各位看倌繼續欣賞下去吧, 很精采ㄡ!!
===============================================
* Dave Rooney Says:
定義了何謂一個user story是已經done了:
- A story is “done and tested by development, tested by QA and accepted by the business”.
主要想法
- You need sufficient QA capacity to handle the pipeline of completed stories coming from the developers.
- After all 2 stories completed to 100% in an iteration delivers more business value than 8 stories completed to 75%.
對於defect的處理態度
- I have the developers, QA and the business triage them -
- 確認 Is it a technical issue or an unclear, misunderstood or missing requirement?
- Does it affect the done state of a story? If so, fix it immediately. If not, confer with the business about its priority and schedule it accordingly.
===============================================
* Basim Baassiri Says:
Agile對testing所帶來的優點
- To start early and to shorten the feedback loop
Agile對testing上所造成的難處
- From a QA perspective, code complete has a different meaning then when development code is complete.
- What if the code completed by dev is a dependency for another set of features?
- What if the code completed by dev is not testable from an acceptance test perspective?
- Testing a moving target or code base causes unnecessary churn. Here is the scenario:
Dev completes story 1 –> QA tests it and marks as DONE
Dev completes story 2 that affects story 1 –> QA tests it and marks as DONE
==> The result here is that story 1 now has to be re-tested as a result of the changes done to story 2. Story 1 is at a state of quality unknown
解法
- We tried the approach where by QA is an iteration behind.
- What I mean by behind, the build candidate at the end of the iteration is taken and testing starts.
所採取的測試流程
1. test cases definition done early in the iteration
2. Test case review (not being done but ideally solicit feedback from dev and story owners)
3. We use keyword and domain based automation techniques so test cases are written once and can be used with the automation framework
4. Once dev signals the story is complete, start testing manually
5. Code supporting features in the automation framework if required. This obviously can’t be done until the code is complete
6. Verify defects and run regression testing activity
7. Release
QA and Testing in an Agile Environment
Chris, 05Nov
http://edgehopper.com/qatesting-in-an-agile-environment/
當作者要adopt 2 weeks的iteration時, 他問了很多人對於這樣的事, 有怎樣的concern. 以下是他得到的主要考量:
(1) QA’s and testers on an agile team have nothing to do at the start of an iteration.
(2) We can’t keep writing new code up until the last minute of an iteration if QA is to adequately test the code. So, what do the developers do at the end of the iteration?
因此作者提出它的作法, 希望能mitigate這些問題, 並且能讓QA在agile iteration中融入的很好.
1. 第一週
Day 1
Dev: Coding
QA: Write Tests
Day 2
Dev: Coding
QA: Write Tests
Day 3
Dev: Coding/Defect Fixes
QA: QA/Testing
Day 4
Dev: Coding/Defect Fixes
QA: QA/Testing
Day 5
Dev: Coding/Defect Fixes
QA: QA/Testing
2. 第二週
Day 1
Dev: Coding/Defect Fixes
QA: QA/Testing
Day 2
Dev: Coding/Defect Fixes
QA: QA/Testing
Day 3
Dev: Defect Fixes/Design/Story Development
QA: QA/Testing
Day 4
Dev: Defect Fixes/Design/Story Development
QA: QA/Testing
Day 5
Dev: Defect Fixes
QA: Acceptance Testing
細部說明:
前兩天
Dev:
- Get busy coding the stories in their backlog while the QA’s start writing test cases/acceptance tests.
QA:
- Start writing test cases/acceptance tests.
- Should also be running these tests against the existing code base.
- This validates that the test harness is working correctly and that the new tests do not mistakenly pass without requiring any new code.
- Obviously, the new tests should also fail for the expected reason.
- This tests the tests themselves, in the negative: it rules out the possibility that the new tests will always pass, and therefore be worthless.
接下來五天
Dev
- Continue coding and also start working on fixing any defects picked up in the testing.
- Pretty standard days. Code-test-fix.
QA
- Begin testing any testable code that has been completed.
第 8 天開始
Dev
- Effectively stop writing “new” code and focus their energy on fixing all defects identified in testing.
- If has no defect work or find themselves with down-time while waiting for testing results, they can and should be helping the product owner develop and refine the user stories that are likely to be played in the next iteration.
- Start considering the design aspects of the immediate upcoming stories and coordinating design decisions with the project architect.
QA
- Continue to test all of the remaining code written during the iteration.
最後一天上午
Dev
- Focus on bashing any remaining defects and making the code bombproof.
QA
- Spend most of their time doing some final acceptance testing
最後一天下午
- It’s time for your review and demo.
- You’ve tested and fixed everything so you and your team can demo with total confidence.
- No surprises for your team, you’ve built serious quality into your software!
作者在post完他的做法之後, 精采的來了, 一共有54 篇response. 一起來討論他們自己怎麼做agile testing. 讓各位看倌繼續欣賞下去吧, 很精采ㄡ!!
===============================================
* Dave Rooney Says:
定義了何謂一個user story是已經done了:
- A story is “done and tested by development, tested by QA and accepted by the business”.
主要想法
- You need sufficient QA capacity to handle the pipeline of completed stories coming from the developers.
- After all 2 stories completed to 100% in an iteration delivers more business value than 8 stories completed to 75%.
對於defect的處理態度
- I have the developers, QA and the business triage them -
- 確認 Is it a technical issue or an unclear, misunderstood or missing requirement?
- Does it affect the done state of a story? If so, fix it immediately. If not, confer with the business about its priority and schedule it accordingly.
===============================================
* Basim Baassiri Says:
Agile對testing所帶來的優點
- To start early and to shorten the feedback loop
Agile對testing上所造成的難處
- From a QA perspective, code complete has a different meaning then when development code is complete.
- What if the code completed by dev is a dependency for another set of features?
- What if the code completed by dev is not testable from an acceptance test perspective?
- Testing a moving target or code base causes unnecessary churn. Here is the scenario:
Dev completes story 1 –> QA tests it and marks as DONE
Dev completes story 2 that affects story 1 –> QA tests it and marks as DONE
==> The result here is that story 1 now has to be re-tested as a result of the changes done to story 2. Story 1 is at a state of quality unknown
解法
- We tried the approach where by QA is an iteration behind.
- What I mean by behind, the build candidate at the end of the iteration is taken and testing starts.
所採取的測試流程
1. test cases definition done early in the iteration
2. Test case review (not being done but ideally solicit feedback from dev and story owners)
3. We use keyword and domain based automation techniques so test cases are written once and can be used with the automation framework
4. Once dev signals the story is complete, start testing manually
5. Code supporting features in the automation framework if required. This obviously can’t be done until the code is complete
6. Verify defects and run regression testing activity
7. Release
全站熱搜
留言列表
