之前一直寫的都是敏捷測試要怎樣做，沒有提到要怎樣做敏捷測試。目前大多數(shù)的團隊還是采用傳統(tǒng)的測試過程匣摘，這一點不可否認(rèn)。有人堅持傳統(tǒng)測試裹刮，有人提倡敏捷測試音榜，書中的第五章提到了傳統(tǒng)測試向敏捷測試的過度，這里就把它拿出來捧弃，和想轉(zhuǎn)向敏捷測試的書友們交流一下體會赠叼。
度量的問題
“世界上有三種謊言：謊言，該死的謊言违霞，還有統(tǒng)計數(shù)據(jù)”嘴办。可度量的目標(biāo)是一件好事买鸽。既然是一件好事户辞，又為什么說是謊言。舉個栗子癞谒，單元測試的數(shù)量在增長底燎，但是代碼覆蓋率從75%降低到50%，這不一定是表面看到的這樣弹砚，也許是我們?nèi)サ袅藴y試覆蓋的無用代碼双仍。度量是必要的，但是獨立看待度量是錯誤的桌吃。在傳統(tǒng)的測試過程中朱沃，經(jīng)常使用缺陷數(shù)量來度量測試團隊是否做得好。那在敏捷測試中，首先要考慮所定義的度量代價是否是合理的逗物，并且多使用小目標(biāo)來作為自己的度量搬卒。比如：在產(chǎn)品發(fā)布的六個月內(nèi)，新代碼中的嚴(yán)重缺陷不能超過六個翎卓。
缺陷跟蹤——用卡片還是DTS契邀？？
我的觀點是失暴，都可以坯门，只要適合你的團隊。
因為使用DTS有很多好處：
1.方便：信息填寫的過多逗扒，不太適合記錄在卡片上古戴；
2.知識庫：以史為鑒，可以輕易的找到缺陷矩肩，而不是靠某個人的記憶力现恼；
3.可跟蹤性：它鏈接了缺陷和測試用例。
也有一些特點使得它阻礙了敏捷測試：
1.溝通工具：DTS的使用不會增加開發(fā)和測試人員之間的溝通
2.浪費時間和精力
3.敏捷和精簡思想提供了一些實踐和準(zhǔn)則幫助我們減少對DTS的依賴黍檩，如果過程可靠述暂，所有的成員致力于產(chǎn)品質(zhì)量，缺陷可能很少很少并易于跟蹤建炫。
所以，總的來說疼蛾，DTS還是有必要的肛跌，只是需要找到適合自己團隊的工具，因為工具需要整個團隊使用察郁，選擇時要考慮所有人的看法衍慎。
測試計劃&測試策略
傳統(tǒng)的階段性軟件模式強調(diào)測試計劃的重要性，作為整個文檔需求的組成部分皮钠。在敏捷項目中稳捆，團隊不會依賴沉重的文檔來通知大家該如何做，測試人員會和大家進行溝通麦轰，但并不意味著他不需要計劃乔夯。在這里采用“策略”，關(guān)鍵詞是“長期”款侵，可以記錄在靜態(tài)文檔中末荐，而測試計劃對每個項目都是唯一的。一份測試策略的主題主要包括：
??????測試實踐
?????故事測試
?????解決方案驗證測試
???? 用戶驗收測試
???? 探索性測試
???? 負(fù)載和性能測試
???? 測試自動化
???? 測試結(jié)果
???? 缺陷工作過程
???? 測試工具
???? 測試環(huán)境
現(xiàn)有的過程和模型
質(zhì)量模型有很多新锈，書中主要提到了兩個CMMI以及ITIL甲脏。這兩個模型都可以很好的與敏捷開發(fā)共存。其實這里我沒有太看懂，之后會再學(xué)習(xí)這兩個模型究竟是什么東西块请。還請大家多多指教娜氏。
最后附書中圖片一張，列出了從項目啟動到發(fā)布整個周期的工作墩新，將敏捷的思想貫穿在其中贸弥，我自己也會在我們的團隊中盡力將其落實，推進團隊的敏捷進程~~
“與現(xiàn)有質(zhì)量過程和模型共存是你在轉(zhuǎn)換到敏捷開發(fā)中遇到的最大的文化問題抖棘。所有這些改變都是艱難的茂腥，但只要團隊參與進來，就沒有什么困難不能克服切省∽罡冢”
