Report不只是Report而已
最近同時有好幾個小project同時在進行, 因此需要要求撰寫test status report, 讓相關的stakeholder知道目前的狀況.
可是我發現當我在assign member撰寫這份report時, 他們會問我要寫什麼樣的內容, 我是有給了一份基本制式的範例, 讓他們參考. 不過事後我想了一下, 我應該告訴他們, 這只是其中一種形式. 除了提供目前的狀態讓相關stakeholder知道外, 重點是你要思考一些事情. 思考你目前做的事情是否哪些地方做的不夠, 或是有哪些risk, 或是哪些地方要新增. 希望你能的藉由這些機會, 好好回顧過去, 展望未來.
我想我們花了太多時間, 在做test execution的事情. 可是卻很少花時間, 在討論我們所做的事情的品質. 在每次撰寫test status report, 應該是一個好的時機點, 讓大家坐下來, 一起思考一下, 我們自己表現的如何, 事情處理的好不好. 不要認為這是浪費時間, 需知道 faster is slower. 你一定聽過兩個樵夫砍樹的故事, 若是能經常花些時間磨利一下你的斧頭, 每次砍樹的時候才能更有效率.
以下這篇提供了一些思考方面, 可以參考一下
Planning for reporting
http://www.michaeldkelly.com/blog/archives/234
* How much testing did we plan to do and how much of that have we done?
* What potential tests are remaining and in which areas?
* What is our current test execution velocity and what has it been for the duration of the project? How does that break out across testing area or test case priority?
* What is our current test creation velocity and what has it been for the duration of the project? How does that break out across testing area or test case priority?
* How much of our tests have been focused on basic functionality (basic requirements, major functions, simple data) vs. common cases (users, scenarios, basic data, state, and error coverage)vs. stress testing (strong data, state, and error coverage, load, and constrained environments)?
* How much of our testing has been focused on capability verses other types of quality criteria (performance, security, scalability, testability, maintainability, etc…)?
* How many of the requirements have we covered and how much of the code have we covered?
* If applicable, what platforms and configurations have we covered?
* How many issue have we found, what severity are they, where have we found them, and how did we find them?
* Which of the stakeholders’ questions can we answer? What are the answers?
* Which questions can we not yet answer? What keeps us from answering them?
* To the stakeholders: How well are we answering your questions? What other information would you like from us?
* Did the automated tools employed meet their purpose?
* Did we get enough ROI from those tools to justify their continued usage?
最近同時有好幾個小project同時在進行, 因此需要要求撰寫test status report, 讓相關的stakeholder知道目前的狀況.
可是我發現當我在assign member撰寫這份report時, 他們會問我要寫什麼樣的內容, 我是有給了一份基本制式的範例, 讓他們參考. 不過事後我想了一下, 我應該告訴他們, 這只是其中一種形式. 除了提供目前的狀態讓相關stakeholder知道外, 重點是你要思考一些事情. 思考你目前做的事情是否哪些地方做的不夠, 或是有哪些risk, 或是哪些地方要新增. 希望你能的藉由這些機會, 好好回顧過去, 展望未來.
我想我們花了太多時間, 在做test execution的事情. 可是卻很少花時間, 在討論我們所做的事情的品質. 在每次撰寫test status report, 應該是一個好的時機點, 讓大家坐下來, 一起思考一下, 我們自己表現的如何, 事情處理的好不好. 不要認為這是浪費時間, 需知道 faster is slower. 你一定聽過兩個樵夫砍樹的故事, 若是能經常花些時間磨利一下你的斧頭, 每次砍樹的時候才能更有效率.
以下這篇提供了一些思考方面, 可以參考一下
Planning for reporting
http://www.michaeldkelly.com/blog/archives/234
* How much testing did we plan to do and how much of that have we done?
* What potential tests are remaining and in which areas?
* What is our current test execution velocity and what has it been for the duration of the project? How does that break out across testing area or test case priority?
* What is our current test creation velocity and what has it been for the duration of the project? How does that break out across testing area or test case priority?
* How much of our tests have been focused on basic functionality (basic requirements, major functions, simple data) vs. common cases (users, scenarios, basic data, state, and error coverage)vs. stress testing (strong data, state, and error coverage, load, and constrained environments)?
* How much of our testing has been focused on capability verses other types of quality criteria (performance, security, scalability, testability, maintainability, etc…)?
* How many of the requirements have we covered and how much of the code have we covered?
* If applicable, what platforms and configurations have we covered?
* How many issue have we found, what severity are they, where have we found them, and how did we find them?
* Which of the stakeholders’ questions can we answer? What are the answers?
* Which questions can we not yet answer? What keeps us from answering them?
* To the stakeholders: How well are we answering your questions? What other information would you like from us?
* Did the automated tools employed meet their purpose?
* Did we get enough ROI from those tools to justify their continued usage?
全站熱搜
留言列表
