執行Stand-up Meeting的小秘訣

Daily Stand-Up Meetings
http://www.scrumlabs.com/2008/07/daily-stand-up-meetings/


我想很多人都知道standup meeting是scrum的招牌practice, 知道每次meeting要回答三個問題, 可是更近一步的運作細節, 卻不是很了解. 因此導致會是有開, 但是效果不是很好.

作者這裡介紹一些執行的的小秘訣, 大家可以參考一下
1. Start as early as possible, on time without waiting for people – sets the agenda for the day.

2. Time-box the duration of the meeting to 15 minutes- use a time-out buzzer if needs be.

3. Stand-up - this encourages brevity(簡潔) amongst the participants and keeps them awake

4. Location – same place and time each day – publicised - preferably the team room.

5. Stand in a u-shape next to the task board to provide speaker context.

6. Flip a coin for asking status – heads go clockwise around the team, tails go anti-clockwise!

kojenchieh 發表在 痞客邦 留言(0) 人氣()

切割User Story


User Story Splitting
http://www.scrumlabs.com/2008/11/user-story-splitting/


理想狀況下, 每個user story需要在一個sprint內做完. 因為Scrum強調working software, 他希望在每次sprint完後, 可以看到一個可以運作的軟體出現. 若是user story太大或是因為某種原因無法在一個sprint內完成, 就會失去working software的精神.

但是事實上, 在很多狀況下, 有些user story是無法在一個sprint中完成. 那要怎麼辦呢?

首先, 作者認為分割 user story是其中一種方法. 而哪些user story要被分割呢? 以下狀況的user story, 作者認為是不錯的選擇

* When the user story is an Epic -  and therefore too large to fit within a Sprint
* When part of the user story cannot  be estimated,  or is too difficult to estimate
* When part of the user story has a higher priority than the remainder
* When part of the user story is riskier than the remainder

找到要分割的user story之後, 那要怎麼切割呢? 作者認為, 若是像他技術背景出身的人, 很容易考量以Architecture or Component Centric來做切割. 但是作者也明白指出, 這樣做並不一定是最佳的方法, 因為從使用者的角度來看, 這樣並沒有提供出好的business value

所以作者提供以下幾種角度, 去考量如何切割user story

1. Roles
- Sometimes a user story is written with a single role shown
- But on further investigation it appears that the user story can be split up into multiple roles and therefore multiple user stories.
- I have seen this on multiple occasions so it is often a quick win to identify user stories exhibiting this characteristic and to break them down according to roles.

2 Transactional
- E.g. a user story that combines all activities together might be able to broken down on a transaction basis
    * e.g. Transactions to Create Customer Details, then Read Customer Details,
    then Amend Customer Details,
    then Delete Customer Details.
- Having written the Create transaction before you write the Read Transaction etc is not always the most desired way but often is.

3. Understood verses Non Understood
- When the team has a tough time trying to understand one part of the User Story
- But you need to see progress, then one option is to split out what you understand as one user story from the less understood element as a second user story
- Have a task associated with the less understood element to understand it!

kojenchieh 發表在 痞客邦 留言(0) 人氣()

免費的Software Testing Magazine

之前有介紹一些Software Testing Magazine, 現在又找到6個. 好好享用!!

1. What is testing
http://www.whatistesting.com

2. Quality Matters
http://www.quality-matters.org

3. SASQAQ
http://www.sasqag.org/pastmeetings.htm

4. CrossTalk
http://www.stsc.hill.af.mil/crosstalk/2009/02/index.html

5. (IN)SECURE magazine
http://www.net-security.org/insecuremag.php

6. Methods and tools
http://www.methodsandtools.com/

Reference
http://www.eviltester.com/index.php/2009/02/03/a-quick-round-up-of-free-software-testing-related-pdf-magazines/

上一篇: Software Testing Magazine ...


kojenchieh 發表在 痞客邦 留言(0) 人氣()

Stand up meeting 的經驗談

Scrum Meetings for Test
http://blogs.msdn.com/steverowe/archive/2007/08/13/scrum-meetings-for-test.aspx


當第一次retrospective meeting時, 整個team 同意stand up meeting帶來許多好處. 就像這篇文章的作者所說的, stnad up meeting 可以幫助
1. Doing this helps me keep the pulse of the team and--more importantly--helps the team keep its own pulse.

kojenchieh 發表在 痞客邦 留言(2) 人氣()

Scrum + Manual Testing methodology

Scrum + Manual Testing methodology (for WEB apps.)
http://www.testingreflections.com/node/view/7378

作者認為在run Scrum時, 對於testing經常會有以下兩種錯誤的作法
- to give up manual testing skills and learn automation or
- give up agile principle of quick feedback and test one iteration behind.

他認為應該在Scrum中加入一個role叫做Tester (而不是只有team, scrum master和project owner). 這樣才會讓Scrum更完整. 可是目前他並沒有看到任何研究, 是有關這方面的. 因此他會致力於這方面的研究, 如何有興趣的人可以和他一起討論.(作者的mail: ojnjars@inbox.lv)

以下是他方法的一些前提假設(Context – Assumptions)
1. Development Scrum consists of 2 week sprints

2. The software is a web based with certain data in database.
- The role of tester will include testing software in “QA environment”, while developers are still doing unit tests in their environment which is not as close to production one.

3. It is decided that software deployment in “QA environment” should follow the manual installation process the same as it will take place in production environment.
- It optionally needs smart decision if to redeploy data into database.
- The process may take up to 30 minutes and is never done this way by developers in their environment

4. The process of creating installation package (build process) may also take up to 30 minutes, so will be executed once per night (nightly build)

接下來, 他描述在一個2 weeks 的sprint中, QA的活動在做些什麼:
Day 1. Sprint Planning
During the first day of a spring – sprint planning meeting – tester participates in order to help to define acceptance criteria (by asking what if questions to product owner) and estimating testing effort for stories.
- It may appear that there are stories requiring a little development effort but a lot of testing effort.
- Story selection may be changed to disallow too much stories of such type into one sprint.
- Alternatively part of testing activities may be postponed, creating a separate story (adding what I would call “quality debt”) and adding to backlog.

Day 2. Test Case Drafting
- A tester works: one day behind” the team.
- The second day of a sprint is dedicated by tester to draft initial set of test cases for each features included in the sprint.

Day 3-8. Normal days
(1) 基本作法
- Each day starting day 3 of sprint in the morning tester installs latest nightly build (manually using installation procedure/instructions supplied by development team) to QA environment, do fast smoke tests if they fail and emergency fixes are applied by the team.
- Features developed yesterday shall be tested today by tester.
- As required tester communicates with each developer to transition the knowledge of the feature functionality.
- Tester must also update (complete) Test Cases in the process of testing as more test ideas may come out during Exploratory Testing.

(2) 如果測試無法進行
- If a feature testing requires too much effort or tester discovers too much ideas and can’t accomplish testing within the day he create new story ticket for further feature investigation.
- If the ticket is not closed by the end of a sprint it appears to be “Quality Debt” and must be announced to product owner for prioritization.
- Because developers do unit testing most of the features should pass acceptance criteria.
- However if for any reason they do not pass them in QA environment, QA may return ticket to the team.
- If acceptance criteria are met but there are more bugs around, tester reports them separately, sending the initial story to End-To-End testing.

(3) 如果bug無法處理時
- Tester also has to do wider investigation (based on project quality goals) and report any usability suggestions, performance, security or other potential treats.
- Such bugs must be assigned to Product Owner if they don’t directly break the acceptance criteria of a story.
- Bugs that (developer) team disagrees with or appears to require too much effort also get assigned to Product Owner.
- They have to be addressed during sprint retrospective meeting.
- So it appears that during sprint retrospective no feature could be demonstrated if it has an open bug against it assigned to anyone but product owner.

Day 9 – The QA day
- Because tester works one day behind, the day 8 of the sprint shall be the last day of a new feature development.
- That is the reason why day 9 can be dedicated by team to bug fixing, re-factoring and analysis of new features which might be included into next sprint i.e. next sprint preparation.

Day 10 - retrospective meeting
- In order to demonstrate a feature in retrospective meeting it should be implemented; tested and all bugs either fixed or assigned to Product Owner for clarification (otherwise feature is postponed to next sprint).
- Tester should demonstrate that features meet acceptance criteria and demonstrate the issues assigned to product owner if any.
- Product Owner should decide and prioritize those features/defects.
- The team participates in the meeting to qualify their performance and probably counter tester’s negative opinion.
- Tester also describes “Quality Debt” changes – what was not tested due to lack of time.
- Product owner may prioritize the postponed tests or even allow skipping them.

在Sprint結束後, QA還有很多事要做
- Test Cases created during sprint shall be peer-reviewed by another tester at any time later. For example by End-To-End tester if there are any.
- Ideally review should be done during or by end of the day 10 so that tester has the feedback by next planning meeting, but it may be impossible.
- In any case tester is not forced to respond to review feedback (fix test cases and run additional test if identified) until the end of sprint (so that tester commitment during sprint planning is not compromised).
- If more tests are identified during review they must be executed later and any defects discovered should be assigned to product owner (added to backlog).


不包含在Sprint中的測試
(1) Non-function的測試
- Still there are types of tests that are not directly related to functionality implemented by sprints.
- For example non-functional tests: to validate that given architecture satisfies high availability requirements.
- Actually the tester may not have enough skills to do performance tests and a separate team or person may be assigned to do performance testing based on agreed schedule.

(2) Regression Testing
- More over it is highly welcome to develop system-level automated regression tests (based on, but not necessarily repeating manual test cases) along with developer created unit tests.
- Those tests will aim for different type of regression bugs.
- This activity may also take place with a significant delay to feature implementation.
- The tester should make a smart decision to nominate the build that was especially successful (without critical bugs) to be installed to the special environment such as for performance test or test automation environment.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Close

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼