敏捷測試（3）--基於story的敏捷基礎知識
阿新 • • 發佈：2018-12-24
基於story的敏捷基礎知識----story編寫
為什麼使用Story？
軟體行業40年多來，需求分析技術已經很成熟了，但是MRD驅動的過程不堪重負。因為往往MRD編寫會佔去很多時間，MRD評審又會佔去大量時間，編碼完成過後提測，壓力又全部傾注在QA身上，往往臨計劃上線時間，或者體驗還差，或者bug還太多，或者專案延期。
使用story，專案完成時間會大大縮短，上市時間大大縮短。主要原因：
A． 採用story模式，將大需求拆為可獨立交付的小story，需求清晰明瞭，節省了大量的需求評審時間。
B． story足夠小，設計難度較低，並且改之前的書面詳細設計及其評審為“口頭溝通為主，文件為輔”，詳設環節的時間也大量節省。
C． story足夠小，驗收標準更明確，測試設計環節簡化，評審環節改為口頭溝通，節約了大量設計時間。
D． story間並行，不是之前的所有需求評審完成，才開始詳設，詳設沒問題之後才開始編碼和測試，因此將需求階段PM的瓶頸，開發階段RD的瓶頸、測試階段QA的瓶頸都被打破。
E． 將RD從文件和評審中解放出來，RD更有時間也更願意去自測和寫單測，bug量減少。
什麼是Story?
整個專案:
story:
story 包括三部分：使用者故事卡片、詳細描述、驗收標準。
（1）使用者故事卡片
三要素：使用者、任務和活動、目標
框架：
| 作為 |
xxx |
| 我想要 | xxxxx |
| 以便 | xxxx |
例項：
| 作為 | 一個書店管理員 |
|---|---|
| 我想要 | 新增新書到書庫 |
| 以便 | 購書者能查閱到這本書 |
（2）詳細描述
對如何實現“我想要”的詳細描述。
（3）驗收標準
Q1:如何確定Story已經完成？
通過驗證驗收標準裡的一系列內容，就能驗證實現符合story的需求。
Q2:驗收條件通常包括哪些？
a.具體屬性
b.功能性驗收條件
c.非功能性驗收條件
好的Story有哪些特點？
- Independent 可以獨立開發
- Negotiable 可以協商
- Valuable 有價值
- Estimable 大小可評估
- Sized appropriately 合適粒度（1~5天驗收完成）
- Testable 可測試驗證
