dev(developer) :開發
te(test engineer) ：測試
pm(product manager) ：產品
敏捷：快速的響應客戶（需求），高效的完成開發，不斷的追求完善。
te在敏捷中應該做些什麼呢？
流程1-故事分析
角色：dev、
te內容：
需求交接前夕，pm將需求上傳到文件管理區並郵件通知，
dev、
te分析需求
初步制定測試策略與測試計畫
初步安排測試任務
輸出：測試策略、測試計畫
測試工作量初步評估
流程2-故事計畫
角色：整個team(pm、
dev、
te)內容：
確定測試工作量
更新測試策略各測試計畫
考慮環境和並著手準備
輸出：測試策略、測試計畫
測試工作量評估
流程3-story kickoff
角色：dev、
te內容：
te與dev
一起理解分析故事
列表疑慮點
dev拆分
task
，並思考設計思路
te列出測試要點
te各dev
一起就以上各點對pm和
dev進行反串講（用例與設計評審）
輸出：測試用例
流程4 -故事開發
角色：te、
dev內容：
te與dev
結對、實現自動化測試
輸出：自動化測試
ps:關於這點，沒有自然語言自動化體系支撐，無法達到實行標準
流程5-desk check
角色：te、
dev、
pm內容：
dev本地執行系統，準備資料自主
utte對此環境做快速測試，檢查各流程功能是否開發完成，並反饋問題
pm 全程評價是反饋問題
輸出：desk check 問題記錄
ps：desk check
尚處於developing
階段，發現問題或者開發方向錯誤，
dev能快速修復，這樣才能保證功能進入下乙個階段。
流程6-探索性測試、
sit
角色：te
內容：執行測試用例
執行探索性測試
提交缺陷並及時驗證修復問題
不能解決問題及時與pm溝通
每日進度反饋，並思考介面安全與效能測試
輸出：測試報告
流程7-uat和產品驗證
角色：pm、
te內容：
te輔助
pm驗證功能
pm反饋問題
輸出：問題清單
流程8-上線
角色：整個team
內容：te上線線前回歸驗證
te、dev
上線生產環境部署
te、pm
生產功能驗證
驗證反饋
輸出：上線驗證報告
敏捷源於理論、而高於理論：
1、敏捷團隊應該是怎麼樣的呢？
團隊拆成小組作戰方式，小組共6~10人，其中
te 1~2
人，具體人數按實際情況擬定，選出組長。
組長需要分配工作，組織每天的晨會，收集問題，解決問題，總結反饋。
需求按照模組、共性、特性分配給小組，各組負責一部分需求，全組員協作、交接需求、分析需求、拆分任務、評估時間、制定計畫、完成開發測試。
晨會（重要），所有人都必需講真話、講短話、講實話。講話內容應該是昨天的完成進度、問題、阻塞、風險、建議和今天需要做的事情；整個過程應該控制在5~15分鐘內完成（更快、更精準、更高效）
版本週期中小組之間可以交叉協作，此點看重組員的綜合實力。敏捷很考驗綜合實力，也是能更快的提公升綜合實力的。
能力強的dev與
te可實現結對開發，完成**ut。
分析需求：
需求管理是以特性、故事、任務為框架管理。以故事為單位來評估時間彙總到特性。所以pm的需求文件，應盡量以特性為一級標題、故事為二級標題、內容須包含所有需要的
ui、資料字段、功能邏輯、許可權控制、三方對接等。以便在交接（宣講）需求時，
dev與
te第一時間響應需求，折分故事。
te評估時間。由對應
dev與
te馬上完成這個工作，然後小組長分析統計反饋。評估時間盡量在一小時內需要完成，半小時達到敏捷。
2、用例與功能：
敏捷的要求在需交接（求宣）後，評估時間前，te應該在紙上將所有需求測試點都邏輯出來。須簡潔明瞭，即省而優，方便後面用例開展。
1、週期較快、需求較小、功能不重要的，寫測試點
2、週期適中、需求適中、功能適中的，寫測試點，測試場景
3、測試場景週期較長、需求很大、功能很重要的，寫測試點、測試場景、介面效能安全，設計測試資料
測試：1、desk check：敏捷沒有三到四輪測試，僅僅一至兩輪測試，所以要更早的介入測試，越早發現問題成本越小。
2、探索性測試：精準快速的熟悉陌生的新功能，新軟體，方便後續用例測試。
3、使用工具：熟練使用
f12、抓包、
sql、
postmen
等工具與手段快速分解功能與測試用例。
dev精準定位問題所在。
5、日清日結：決不遺留缺陷到第二天，
dev改完第一時間驗證。
針對第5點舉個例子：
上線前一天發現了缺陷，卡了部分流程，dev需要晚上加班解決，
然而te
很早撤退了，
dev解決完提交驗證，缺陷只能等到明天來驗證。
te第二天缺陷驗證不過，吐槽
dev不行。但那部分流程還在卡著，任務無法完成。堅難的上線。
如果te當晚跟進
dev驗證這個問題，發現不通過，
dev及時解決。隔天一來，流程順暢，測試通過，任務完成。舒服的上線。
4、每日總結：
每日總結：文字記錄當天的進度、缺陷、難題、完成了什麼、是否正常。明天需要做什麼，建議性想法等。當為第二天的晨會準備。
5、冒煙與回歸自動化：
好的自動化用例，可以重複利用、減少相容問題、節約成本、解放人力、提高團隊的能力。
自動化測試啟動，測試組必須有乙個經驗豐富的ate去做下面的事情
:1、首先需要確認專案自動化的可行性，通過歷史版本觀察，前端變更頻繁不適合做ui自動化，後台變更頻繁不適合做介面自動化，前端與後台都變更頻繁的專案可以放棄自動化。不過並不絕對，分析各模組，穩定的可先實現自動化。
2、設計自動化策略，制定冒煙計畫、回歸計畫：
策略：選擇框架、工具、語言
自動化用例具有健壯性、重用性、獨立性、維護性等特點，所以需要制定自動化計畫。
冒煙計畫優先制定，乙個系統的冒煙用例不會多，保證主流程的通暢，用例檢查點（斷言）不用多、乙個用例乙個即可。
回歸計畫在冒煙用例完成後可以制定，回歸用例與冒煙用例的比率應該在1：
50~100
。乙個用例的檢查點（斷言）在
3~5個，重點：回歸用例
ate乙個人難做的。需要測試組一起做。
自動化程度越高的專案te越舒服。
建議：自動化測試的建設在專案穩定的情況下，越早越好，絕不能拖到敏捷開發時候。
6、持續整合：
ci：continuous integration 持續整合
敏捷不可或缺的一項技術。
自由工具： jenkins
可持續整合每日按定時任務自動部署，並郵件通知結果。減少了人功的操作，減少了錯誤率，使流程規範。
1、**自動檢查
ut2、自動編譯
3、自動構建
4、自動部署
5、定時執行自動化用例
te須知道如何搭建，並實戰
7、管理工具使用
alm：
te須深入了此類工具
任何工具，被te拿到，一段時間都應該玩的爐火純青。故略
~8、版本資料監控：
tl技能，故略
~
敏捷轉型 團隊如何變敏捷？
敏捷的原則傾向於一些常識和一系列艱苦的工作，通常，我們會聽到很多關於敏捷的資訊，比如敏捷轉型是團隊嘗試成為敏捷的一種流行方式。很多團隊會聘請敏捷顧問，花幾個月的時間幫助團隊進行敏捷轉型，這個過程只需要支付一筆錢。最後整個團隊真的就轉型成敏捷了嗎？像這樣的轉變有意義嗎？其實，實現敏捷的方法不僅是轉型，...
敏捷測試團隊的測試流程
一 接到專案後，ba明確客戶的需求，必要時可以帶上測試經理 開發經理 測試員 開發員，出乙份書面需求說明 二 測試人員初步學習 ba串講 測試人員提問題 ba給出回答 重新整理學習 測試人員反串講 評審 出乙個需求規格說明書 模組思維導圖 三 測試經理根據需求規格說明書制定測試計畫 此spirit共...
敏捷團隊如何在測試中增加價值？
敏捷測試是遵循敏捷軟體開發原理的軟體測試過程。與傳統的測試模型不同，敏捷測試方法遵循開發方法，在該開發方法中，客戶和測試團隊會逐步提出需求。因此，敏捷的測試團隊都在關注需求的變化。敏捷開發團隊的主要目標是提供高質量的新功能。當團隊邁向敏捷時，他們通常必須找出以敏捷速度整合測試時間的最佳方法，這可能是...