1. 敏捷開發(fā)測(cè)試背景知識(shí)

敏捷是什么？

一種軟件開發(fā)的實(shí)踐
開始于敏捷宣言

敏捷宣言

個(gè)體與交互勝過過程和工具
可用的軟件勝過完備的文檔
客戶協(xié)作勝過合同談判
響應(yīng)變化勝過遵循計(jì)劃
盡管右邊的同樣有價(jià)值，但是敏捷認(rèn)為左邊的更有價(jià)值。

1.1 Scrum過程

Scrum概覽

- Scrum是一種兼顧計(jì)劃性與靈活性的敏捷開發(fā)過程，原詞來自于橄欖球中的“帶球過人”。在橄欖球比賽的每次沖刺前，都將有一個(gè)計(jì)劃安排的過程，但沖刺開始后則由隊(duì)員在原計(jì)劃的基礎(chǔ)上隨機(jī)應(yīng)變。

敏捷測(cè)試流程圖

- 在日常工作時(shí)，產(chǎn)品負(fù)責(zé)人會(huì)維護(hù)一個(gè)按優(yōu)先級(jí)排序的“產(chǎn)品待開發(fā)項(xiàng)”（Product Backlog），即從客戶價(jià)值理解和描述的產(chǎn)品功能條目。

- 在每次迭代的第一天，召開迭代計(jì)劃會(huì)(Sprint Planning Meeting)。產(chǎn)品負(fù)責(zé)人會(huì)逐一挑選最高優(yōu)先級(jí)的部分進(jìn)行講解。團(tuán)隊(duì)可就需求細(xì)節(jié)、完成標(biāo)準(zhǔn)等進(jìn)行詢問，并逐條估算，放入本次迭代的開發(fā)任務(wù)中，直至任務(wù)量飽和。一旦迭代開始，這些任務(wù)將不會(huì)發(fā)生大的變化。

- 在迭代期內(nèi)，團(tuán)隊(duì)將決定任務(wù)分配、所需的技術(shù)等，逐一完成任務(wù)。每天團(tuán)隊(duì)會(huì)進(jìn)行一個(gè)簡短的站立會(huì)議即每日立會(huì) Daily Stand-up Meeting，溝通當(dāng)前進(jìn)度、下一步任務(wù)和當(dāng)前存在的問題，以借助團(tuán)隊(duì)的力量解決。團(tuán)隊(duì)還維護(hù)一張“燃燒圖”（Burn Down Chart），即所有任務(wù)的累積剩余時(shí)間隨開發(fā)進(jìn)程與日遞減的圖形，以觀察和預(yù)測(cè)所有任務(wù)是否會(huì)按期完成。

- 在每個(gè)迭代的最后一天，團(tuán)隊(duì)會(huì)召集評(píng)審會(huì)(Review Meeting)，邀請(qǐng)產(chǎn)品負(fù)責(zé)人等參加，對(duì)已經(jīng)完成的產(chǎn)品功能條目進(jìn)行評(píng)審，后者做出判斷并給出改進(jìn)反饋。當(dāng)天還會(huì)召開反思會(huì)(Retrospective Meeting)，對(duì)本次迭代的成功與失敗做出總結(jié)，并在以后迭代中進(jìn)行改進(jìn)。

兩個(gè)清單

`Product Backlog`
產(chǎn)品待開發(fā)項(xiàng) Product Backlog是從客戶價(jià)值角度理解的產(chǎn)品功能列表。
功能、缺陷、增強(qiáng)等都可以是待開發(fā)項(xiàng)。
一般以條目化的方式描述。
客戶和用戶必須能夠理解。
描述怎樣使用而非怎樣制造。
整體上從客戶價(jià)值優(yōu)先級(jí)排序。
總工作量一般需要0.5～10人/天。
高優(yōu)先級(jí)的條目應(yīng)有較詳盡的描述，低優(yōu)先級(jí)的條目可只有一個(gè)名稱。

`Sprint Backlog`
沖刺待開發(fā)項(xiàng) Sprint Backlog是從開發(fā)技術(shù)角度理解的迭代開發(fā)任務(wù)。
>在簡單的純軟件環(huán)境中，可以直接把產(chǎn)品待開發(fā)項(xiàng)當(dāng)作沖刺待開發(fā)項(xiàng)分配到迭代中。
在復(fù)雜的開發(fā)環(huán)境中，可以把一個(gè)產(chǎn)品待開發(fā)項(xiàng)分解為Web/后臺(tái)……軟件/硬件……程序/美術(shù)……等開發(fā)任務(wù)。

三個(gè)角色

`Product Owner`
Product Owner（產(chǎn)品負(fù)責(zé)人）負(fù)責(zé)產(chǎn)品需求的提煉、條目化、優(yōu)先級(jí)排序。
// 現(xiàn)實(shí)世界的產(chǎn)品負(fù)責(zé)人：
部門經(jīng)理、產(chǎn)品經(jīng)理、策劃人員等都可能做產(chǎn)品負(fù)責(zé)人。
產(chǎn)品負(fù)責(zé)人是產(chǎn)品的指路人，必須對(duì)產(chǎn)品有長遠(yuǎn)的規(guī)劃和深入了解，因此不能簡單地選擇銷售人員甚至客戶作為產(chǎn)品負(fù)責(zé)人。
大型產(chǎn)品如嵌入式產(chǎn)品和網(wǎng)絡(luò)游戲，常常使用有層級(jí)的產(chǎn)品負(fù)責(zé)人團(tuán)隊(duì)，來解決廣度與深度的矛盾，如產(chǎn)品總監(jiān)-產(chǎn)品經(jīng)理 / 主策劃-策劃團(tuán)隊(duì)。

`Scrum Master`
Scrum Master（Scrum“大師”）負(fù)責(zé)維護(hù)Scrum方法的秩序，并協(xié)助解決非技術(shù)問題。
// 現(xiàn)實(shí)世界的Scrum Master：
Scrum Master的工作方式是靠領(lǐng)導(dǎo)力(leadership)而非權(quán)力工作，因此首先應(yīng)服務(wù)于團(tuán)隊(duì)。
一種人選是原來的項(xiàng)目經(jīng)理轉(zhuǎn)型，保留原有的管理和技術(shù)職能，但弱化指派任務(wù)、下達(dá)時(shí)間點(diǎn)指令等內(nèi)容，而增強(qiáng)其組織協(xié)調(diào)能力。
另一種人選是企業(yè)原有的過程改進(jìn)人員，協(xié)助不太了解Scrum的項(xiàng)目經(jīng)理按照Scrum的方法工作，可以每人負(fù)責(zé)多個(gè)項(xiàng)目，接近全職的Scrum Master。

`The Team`
Team（團(tuán)隊(duì)）以“自組織”的相對(duì)扁平方式進(jìn)行管理，負(fù)責(zé)完成開發(fā)工作。
// 現(xiàn)實(shí)世界的開發(fā)團(tuán)隊(duì)：
實(shí)際團(tuán)隊(duì)常常不是“扁平的”，而是仍有項(xiàng)目經(jīng)理、小組長等職位。
工作中他們以“共同估算”、“跨職能工作”、“共同跟進(jìn)”等方式自組織工作，而不是完全依賴層層指令。
項(xiàng)目經(jīng)理、小組長的領(lǐng)導(dǎo)、指導(dǎo)、協(xié)同職能大于其指令職能。

四個(gè)儀式

`計(jì)劃會(huì)：Sprint Planning Meeting`
// 迭代計(jì)劃會(huì)在每個(gè)迭代第一天召開，目的是選擇和估算本次迭代的工作項(xiàng)。
產(chǎn)品負(fù)責(zé)人逐條講解最重要的產(chǎn)品功能。
開發(fā)團(tuán)隊(duì)共同估算故事所需工作量，直到本迭代工作量達(dá)到飽和。
產(chǎn)品負(fù)責(zé)人參與討論并回答與需求相關(guān)的問題，但不干擾估算結(jié)果。

`每日立會(huì)：Standup Meeting`
// 隊(duì)員認(rèn)領(lǐng)任務(wù)（或由組長協(xié)商分發(fā)），獨(dú)立或與別人一起完成任務(wù)。
團(tuán)隊(duì)內(nèi)部利用每日立會(huì)來溝通進(jìn)度。
開發(fā)團(tuán)隊(duì)利用燃盡圖來展示整體進(jìn)度。
如無特殊原因，迭代期內(nèi)無變更。

`評(píng)審會(huì)：Review Meeting`
// 小組向產(chǎn)品負(fù)責(zé)人展示迭代工作結(jié)果。
產(chǎn)品負(fù)責(zé)人給出評(píng)價(jià)和反饋。
以用戶故事是否能成功交付來評(píng)價(jià)任務(wù)完成情況。

`反思會(huì)：Retrospective Meeting`
// 在每個(gè)迭代后召開簡短的反思會(huì)。
總結(jié)哪些事情做的好，哪些事情做的不好。
制定改進(jìn)計(jì)劃。

1.2 用戶故事

• 用戶故事：描述具體的需求的卡片。
  按作為一個(gè)……，可以……，以便……樣式和思路寫成的用戶需求，就是用戶故事。
  這種樣式是技法層面的東西，它保證了無需太多思考，用戶故事中即可全面包含角色、功能、價(jià)值這三個(gè)要素。

要想寫好用戶故事，要改變那種面向功能而非客戶需求的純技術(shù)觀念。
角色：切記不要總是寫“作為一個(gè)用戶”，而是要把用戶區(qū)別對(duì)待。這樣才能更好地理解他們使用什么功能，如何使用，為何使用。
功能：即用戶能親自執(zhí)行的操作。應(yīng)區(qū)分用戶操作和產(chǎn)品功能之間的關(guān)系，因?yàn)楫a(chǎn)品功能可能也提供了用戶所需的價(jià)值，但卻極可能不便于操作。
價(jià)值：是完成操作后，客戶所得到的好處。價(jià)值里邊，常常要帶有一點(diǎn)褒義詞，或有一些吸引人的內(nèi)容，比如“高效地……”“……可以節(jié)省話費(fèi)”等。

• 需求分解為任務(wù)，由開發(fā)完成，實(shí)現(xiàn)功能。
• 需求費(fèi)解為用例，有測(cè)試完成，驗(yàn)證功能。

1.3 敏捷日常跟進(jìn)

`看板`
看板又叫任務(wù)版，對(duì)于Sprint進(jìn)度的溝通，看板是一種簡單而強(qiáng)大的方式。從形式 上看，看板顯示的是Sprint沖刺待開發(fā)項(xiàng)隨時(shí)間的進(jìn)展?fàn)顟B(tài)。
故事板簡單說就是把所有正在工作的內(nèi)容，張貼到一個(gè)板狀空間中。
看板（Kanban）一詞來自日語，指的是制造業(yè)中的一種可視化方法，有相當(dāng)復(fù)雜的思想和流程。由于兩者看上去很類似，兩個(gè)詞匯經(jīng)?；煊?。

`燃盡圖`
>在Sprint執(zhí)行的每一天，團(tuán)隊(duì)成員都要更新未完成任務(wù)的剩余工作量估算。我們可以創(chuàng)建一個(gè)表來是使數(shù)據(jù)可視化，就是燃盡圖
根據(jù)整個(gè)團(tuán)隊(duì)的剩余工作總量，每天進(jìn)行更新，就可以得到燃盡圖。

2. 計(jì)劃會(huì)

2.1計(jì)劃會(huì)準(zhǔn)備的內(nèi)容

// 每個(gè)人準(zhǔn)備做（測(cè)試）哪幾個(gè)需求？
`手工
自動(dòng)化測(cè)試UI
APP測(cè)試`
// 自動(dòng)化測(cè)試（驗(yàn)收、回歸、批量）方案？
// APP測(cè)試
`Android模擬器
Android真機(jī)（adb） iphone真機(jī)（手工）`

2.2計(jì)劃會(huì)的步驟

PO 產(chǎn)品負(fù)責(zé)人 產(chǎn)品經(jīng)理

// 業(yè)務(wù)背景介紹
1.整體的介紹產(chǎn)品的業(yè)務(wù)
    產(chǎn)品可以做什么事情
    產(chǎn)品有多少種平臺(tái)：Web (B/S)、PC (C/S)、Android、iOS
2.產(chǎn)品有什么樣的版本：免費(fèi)版、PRO版（付費(fèi)）
3.有多少種競(jìng)爭的產(chǎn)品：Worktile、明道、Leangoo、teambition、trello

// 準(zhǔn)備 product backlog （更新產(chǎn)品待開發(fā)項(xiàng)）
產(chǎn)品經(jīng)理登錄禪道
創(chuàng)建產(chǎn)品
提需求，構(gòu)成產(chǎn)品待開發(fā)項(xiàng)

// 挑選 sprint backlog （選擇該迭代要做的 沖刺待開發(fā)項(xiàng)）
項(xiàng)目經(jīng)理登錄禪道
創(chuàng)建迭代（項(xiàng)目）
關(guān)聯(lián)產(chǎn)品
關(guān)聯(lián)需求（從第二步創(chuàng)建的需求中，選擇一部分，構(gòu)成沖刺待開發(fā)項(xiàng)）
團(tuán)隊(duì)設(shè)定

// 講解 sprint backlog 的具體需求（用戶故事）
產(chǎn)品經(jīng)理講解每一個(gè)被關(guān)聯(lián)的需求
確定驗(yàn)收標(biāo)準(zhǔn)

PM 項(xiàng)目經(jīng)理 Scrum Master 敏捷教練

// 確定 sprint 周期長度 1 week？ 2 weeks？
2周/Sprint

// 認(rèn)領(lǐng) sprint backlog，預(yù)估時(shí)間
需求（開發(fā)，xxx，多少時(shí)間；測(cè)試，xxx，多少時(shí)間）
項(xiàng)目經(jīng)理登錄禪道
選擇本次迭代
打開需求
依次選定每一個(gè)需求 | 編輯
編輯備注：開發(fā)：XXX，2h；測(cè)試：YYY，3h

// 確定 評(píng)審會(huì)的 日期
開幾次？
    每次評(píng)審什么需求？
    確定演示會(huì)的次數(shù)
    確定每次評(píng)審會(huì)的需要評(píng)審的需求
確定每次評(píng)審會(huì)的時(shí)間

// 每日立會(huì)開會(huì)時(shí)間
09:05每天

計(jì)劃會(huì)輸出文檔

• sprint 開始日期，結(jié)束日期
• sprint 周期

• 表格【sprint backlog 列表；任務(wù)認(rèn)領(lǐng) + 估算】
• 每日站會(huì)時(shí)間
• 評(píng)審會(huì)表格：日期、評(píng)審需求

3. 每日立會(huì)

3.1匯報(bào)內(nèi)容

1.我昨天做了什么事情（完成什么需求的測(cè)試？開發(fā)？）
2.我今天準(zhǔn)備做什么事情
3.我目前有什么用的困難（挑戰(zhàn)）
4.缺乏數(shù)據(jù)庫權(quán)限
5.缺乏服務(wù)器系統(tǒng)用戶權(quán)限
6.技術(shù)問題
7.業(yè)務(wù)問題
8.時(shí)間問題

3.2燃盡圖
統(tǒng)計(jì)需求：產(chǎn)品本身的需求（或者需求分解的任務(wù)總數(shù)） + 產(chǎn)品級(jí)對(duì)應(yīng)的測(cè)試任務(wù)數(shù)

• 每日站會(huì)中，每個(gè)團(tuán)隊(duì)成員需回答3個(gè)問題。通過這3個(gè)問題，我們可以得到兩個(gè)層面的信息：

團(tuán)隊(duì)內(nèi)信息的透明度，整個(gè)團(tuán)隊(duì)的進(jìn)度以及距離Sprint目標(biāo)還有多遠(yuǎn)；
同時(shí)是否存在障礙
每天團(tuán)隊(duì)都會(huì)得到反饋，并可以根據(jù)得到的反饋?zhàn)龀稣{(diào)整。

• 如果不是每天開站會(huì)，那么就可能：
  1.團(tuán)隊(duì)內(nèi)有些信息會(huì)隱藏。有的團(tuán)隊(duì)反映說團(tuán)隊(duì)?。ū热?-5人）并且大家都坐在一起，隨時(shí)都會(huì)溝通，沒必要每日站會(huì)。而實(shí)際上團(tuán)隊(duì)內(nèi)的溝通在多數(shù)情況下只有相關(guān)2-3人一起，而不是整個(gè)團(tuán)隊(duì)一起。因此每日站會(huì)還是非常有必要的（同步、透明化信息）；
2.團(tuán)隊(duì)錯(cuò)過最佳的調(diào)整機(jī)會(huì)。每日站會(huì)中，團(tuán)隊(duì)可以得知距離Sprint目標(biāo)有多遠(yuǎn)，是否存在障礙或者問題。尤其存在障礙時(shí)，需要整個(gè)團(tuán)隊(duì)共同努力，來想辦法解決。這不是說發(fā)現(xiàn)問題了只有在每日站會(huì)才說出來，而是發(fā)現(xiàn)問題馬上暴露，但每日站會(huì)需要正式得讓整個(gè)團(tuán)隊(duì)得知情況（一般這類信息容易在2-3人之間討論）；
3.團(tuán)隊(duì)沒有儀式感。每日站會(huì)可以讓團(tuán)隊(duì)形成規(guī)律，每天固定時(shí)間、固定地點(diǎn)所有團(tuán)隊(duì)成員湊在一起同步信息和進(jìn)度，很容易團(tuán)隊(duì)成員可以形成儀式感，這是一個(gè)非常重要的事情。

4. 項(xiàng)目迭代

Web手工測(cè)試準(zhǔn)備
自動(dòng)化測(cè)試環(huán)境搭建
APP測(cè)試準(zhǔn)備
SVN配置