靈活測試與開發之我見
by:授客 QQ：1033553122
下文本着實用性原則，談談靈活測試與開發相關的一些想法，如有不同意見或想法，歡迎提出~~
1、 團隊優先
個人覺得，不管做啥，應該把“團隊合作”放在第一位。如果團隊本身沒有凝聚力，沒有向心力，那團隊就是一盤散沙，有力無處使。“靈活”也不例外，靈活宣言中第一句就是“個體和互動 勝過 過程和工具”，充分強調了團隊合作的重要性。
如果把“靈活團隊”比作一個木桶，那麼團隊中的每個角色就是組成木桶的木闆，團隊的效率就是桶裡的水。根據木桶原理，團隊中隻要有任何一個角色不夠效率，不夠靈活，那麼整體的效率也就受到影響。
是以，我的觀點是，“靈活”的前提是“團隊優先”，重視團隊，重視團隊中的每個角色，無差别的對待每個合作成員，讓每個角色、成員有動力，有激情的彌補自己的短闆，讓自己更靈活，進而促進整個團隊的靈活。
是以，應該跳出舊的思維，看看到底是自身不靈活，還是其他成員、團隊、組織的不靈活影響了整體的“靈活”。
問題：
産品經理、策劃人員、設計人員(UE、UI)，開發人員，測試人員、營運人員……都做到靈活了麼？
2、 需求為主
所有的一切源于需求。由需求而生，随需求而滅。
是以，我的觀點是，“靈活”從“需求”開始。
自然而然，從産品經理、策劃人員的“短闆”抓起。從需求說起，書上說，他們需要做的第一件事情就是整理需求 --- 編寫使用者故事
3、 編寫故事
書上說使用者故事代表對使用者、客戶有價值的功能，即使用者(客戶)需求，不含過多的需求細節。
不過個人覺得産品經理、策劃等“産品人士”，其專業性一般強于非專業人事，通常有他們自己的想法，是以可以預先以非故事的方式，比如注釋、要點的方式進行簡單記錄。
關于使用者故事的編寫要求，可網上搜尋相關資料，這裡暫時不提供。當然，也不必要完全參照網上說的一定要是某種格式，關鍵是怎麼友善，有效。怎麼樣寫一份好的需求，是合格的産品人士必備的技能
4、 讨論細節
書上說，需求的細節要在“對話”中獲得，并在确認部分得以記錄。
這裡，團隊成員在聚在一起，頭腦風暴，針對3中的每個使用者故事，逐個展開關于需求細節，并記錄讨論結果
特别說明：
很多事情，唯有參與，才有認同.....。
5、 版本規劃
确定目前疊代的版本包含的需求及優先級安排
6、 任務量評估
開發人員評估大緻大緻的工作量。
7、 原型設計
将讨論結果以以實際的原型、界面展現出來，是建構一個真正産品很好的方法，同時把重心從“需求文檔評審”轉移到“原型(Demo)評審” ，以原型評審為中心，輔以必要的文檔說明，作為原型的補充，也是去掉無用的功能定義文檔、需求文檔可行方法。
原型設計好了，共享給相關人員查閱，以便及時獲得回報，及時更正，如果時間來得及，最好是評審下原型
8、 項目開發與用例設計
開發人員根據原型進行項目、産品開發，測試人員根據使用者故事、原型(假定原型已經被認可的情況下)來測試設計用例。
說明：
這裡為了友善，建議用類似xmind工具或excel等來寫編寫需要評審的測試用例，友善評審，同時，建議編寫一份按功能子產品彙總的用例。
這裡有些人可能會覺得寫兩份用例，麻煩，耗費時間，但我認為實際花不了多少時間，因為執行中可在“複制黏貼”的基礎上完成，而且用例某種程度上也代表了産品整體，有一份按子產品展開的用例，讓你很容易看到“大局”，不僅在測試時起到很好的提醒作用，而且還友善優化用例。 再進一步，要是把彙總的用例，寫在管理系統，比如禅道上，是不是容易配置設定任務、跟蹤任務、統計任務執行等情況呢？
備注：用例是需要維護的，需要不斷優化的，試問，做測試的親們，你們能一次性就寫出很完美的用例麼，特别是在很時間短，項目趕的情況？不能吧，，，是以如果每次都在前一次基礎上修改，疊代，效果是否會好點呢？
例子
彙總的用例：
送出評審用例：
說明：從圖上也可看到，這種情況下的用例，會是比較零散的，針對故事點，具體執行時，很多時候需要重複編寫用例，即重複的時間投入。。。。
備注：
很早前我寫過一篇關于精簡測試用例的文章，後面看了下，發現好像執行性不高，删了，沒分享出來。最近今天思考了下，發現用例還是可以精簡的，精簡用例的出發點是“用例主要是起提醒作用”，這個觀點也是隔壁公司某項目負責人交流時，她提到的。當時沒怎麼在意，現在想來，發現還是挺有價值的一句話。結合上面的格式說明，用例名稱，子產品、故事名，驗證點，一般是不能少的，那可不寫的是啥？答案是：步驟、預期結果。當且僅當你一看用例名稱，即測試驗證點，就能想到步驟和結果時(比如翻頁，密碼大小寫驗證等)，那麼可省略，因為這時候，用例名已經起到了足夠的“提醒”，……
9、
開發自測
開發釋出前，根據測試提供的用例進行簡單自測，當然，開發自測環節的可能性是基于規範成熟度、工作任務量等因素的，一開始就讓他們自測，估計會要了他們的命。
備注：開發如果有看下測試給的用例，哪怕是瞄下，說不定就看到沒注意的細節了，，進而可将bug于測試前修複，要是再細看下就更好了……知道大緻做到什麼程度，才不會讓測試抓住辮子，才算完成了開發工作，，，這裡展現的就是靈活的思想。
10、内網測試
QA進行内網測試，這些測試可能包括單元測試，接口測試等等，至于能做到哪種程度，就看各方面的配合了
11、外網釋出與走查
12、下一輪疊代
重複流程3~11
難點說明：
結合實際，流程3~6
要怎麼做？
方案要求：
1）可執行性高
2）效率高
3)
可維護性高
工欲善其事，必先利其器，根據方案要求，選擇一款合适的工具、合作平台，就變得很重要了。
參考方案
方案1）
流程3、用Mindjet
Mindmanager、XMind記錄使用者故事,舉例如下
流程4、相關人員聚在一起讨論需求細節并記錄結果
參考做法：
1）準備好一台電腦，一台投影儀，大家坐成一圈，看着投影儀逐條讨論故事細節
2）專人記錄，讨論期間專人記錄讨論的結果
說明：這裡這裡形式不固定，用筆記本，投影儀啥的，主要是考慮怎麼樣友善大家參與進來讨論，友善快速記錄
流程5、将相同版本的需求打包在一起，安排優先級
到這裡，差不多形成了一份簡單的需求文檔了，，好了，共享吧，電子文檔就是友善，大家不用可以去記憶讨論結果，不用拿相機拍照，每人一份不是神話^^
6.開發人員進行評估工作量
這裡是在讨論會上解決，也可以會後解決，看項目複雜度，難度等因素
備注：用excel會不會好點？待定
作者：授客
QQ：1033553122
全國軟體測試QQ交流群：7156436
Git位址：https://gitee.com/ishouke
友情提示：限于時間倉促，文中可能存在錯誤，歡迎指正、評論！
作者五行缺錢，如果覺得文章對您有幫助，請掃描下邊的二維碼打賞作者，金額随意，您的支援将是我繼續創作的源動力，打賞後如有任何疑問，請聯系我!!!
微信打賞
支付寶打賞 全國軟體測試交流QQ群