什么是敏捷測(cè)試
首先敏捷測(cè)試(Agile testing)是測(cè)試的一種，原有測(cè)試中執(zhí)行被測(cè)系統(tǒng)發(fā)現(xiàn)問題，通過測(cè)試這種活動(dòng)能夠?qū)Ρ粶y(cè)系統(tǒng)提供度量等概念。
敏捷測(cè)試是遵循敏捷宣言的一種測(cè)試實(shí)踐：
1、強(qiáng)調(diào)從客戶的角度，即是從使用系統(tǒng)的用戶的角度，來測(cè)試系統(tǒng)。
2、重點(diǎn)關(guān)注持續(xù)迭代的測(cè)試新開發(fā)的功能，而不再?gòu)?qiáng)調(diào)傳統(tǒng)測(cè)試過程中嚴(yán)格的測(cè)試階段。
3、建議盡早開始測(cè)試，一旦系統(tǒng)某個(gè)層面可測(cè)，比如提供了模塊功能，要開始模塊層面的單元測(cè)試，同時(shí)隨著測(cè)試深入，持續(xù)進(jìn)行回歸測(cè)試保證之前測(cè)試過內(nèi)容的正確性。
敏捷團(tuán)隊(duì)的管理其實(shí)的確面臨著很多的挑戰(zhàn)。蔡老師分別從敏捷管理的挑戰(zhàn)、接受敏捷、敏捷下面的組織結(jié)構(gòu)、敏捷架構(gòu)下的溝通、敏捷下的KPI考核、以及機(jī)會(huì)和發(fā)展幾個(gè)方面進(jìn)行深入的討論。
其實(shí)我覺得各個(gè)公司施行敏捷的時(shí)候都會(huì)遇見這次講師所分享的一些問題，基本上都是有共同點(diǎn)的。比如專業(yè)點(diǎn)，每個(gè)Scrum Team都會(huì)有自己的一個(gè)基調(diào)。每個(gè)測(cè)試你所跟隨的人不同，跟隨的team也不同，然后所接觸的項(xiàng)目也不同，碰見的問題也不同，甚至作息時(shí)間也會(huì)有所不 同。這樣的情況下，管理其實(shí)是麻煩的。我自己之前也一直煩惱一個(gè)問題是，在這樣的情況下，我應(yīng)該如何進(jìn)行test team這樣一個(gè)團(tuán)隊(duì)的橫向分享，比如好的case，好的bug，又或者要push某個(gè)process的時(shí)候怎么辦。我表示真的很煩惱，如有人有好的解 法，還希望在我blog下面留言。
第二個(gè)問題點(diǎn)，如何在做好管理的同時(shí)，又避免Scrum Master和Test Leader同時(shí)給測(cè)試發(fā)號(hào)施令。這個(gè)問題其實(shí)也很常見。Master和Leader橫向交流不同，每個(gè)人安排任務(wù)的切入點(diǎn)也不同，往往會(huì)導(dǎo)致測(cè)試們很 辛苦。一會(huì)兒要處理這個(gè)，一會(huì)兒要處理那個(gè)。終會(huì)導(dǎo)致加班，情緒也不穩(wěn)定�！ 〉谌齻�(gè)問題點(diǎn)，一旦敏捷了，會(huì)造成很多的“不規(guī)范”，那么在這種情況下面應(yīng)該怎么進(jìn)行KPI的考評(píng)呢？
第四個(gè)問題點(diǎn)，當(dāng)你的團(tuán)隊(duì)每個(gè)成員都被分派到了各個(gè)Scrum Team之后，如何保持test team一個(gè)高漲的氛圍，如何去維持一個(gè)很好的氣氛，是否能夠一直保證大家一條心呢？
更多>>
在敏捷項(xiàng)目管理中應(yīng)用“孫子兵法”
簡(jiǎn)介：《孫子兵法》中的論述雖然是關(guān)于戰(zhàn)爭(zhēng)的，但是其思想在項(xiàng)目管理領(lǐng)域?qū)ξ覀円彩怯薪梃b意義的。本文以筆者的實(shí)際項(xiàng)目管理經(jīng)驗(yàn)為基礎(chǔ)，分享了《孫子兵法》在敏捷項(xiàng)目管理中的應(yīng)用。希望能夠?qū)ψx者的實(shí)際項(xiàng)目管理工作有所啟發(fā)。
成為“敏捷”，而不是做“敏捷”
談到“敏捷”首先容易讓人想到的是各種實(shí)踐。這些實(shí)踐固然有可以借鑒的地方。但是在具體實(shí)施的時(shí)候往往要根據(jù)項(xiàng)目的實(shí)際情況進(jìn)行調(diào)整，而不是生搬硬套。
故兵無常勢(shì)，水無常形。能因敵變化而取勝者，謂之神。
——《孫子兵法?虛實(shí)》
作戰(zhàn)沒有固定的方式方法，像水流沒有固定的形狀一樣。能夠根據(jù)敵情的發(fā)展變化而采取靈活措施取勝的人，才可以稱得上是用兵如神。
敏捷軟件測(cè)試的技術(shù)特點(diǎn)
1、敏捷測(cè)試的定義
敏捷測(cè)試是敏捷的一種，敏捷測(cè)試是遵循敏捷宣言進(jìn)行，把開發(fā)作為顧客看待，測(cè)試中采用的是敏捷方法論。
敏捷測(cè)試是遵循敏捷宣言的一種測(cè)試實(shí)踐：
●強(qiáng)調(diào)從客戶的角度，即使用系統(tǒng)的用戶的角度，來測(cè)試系統(tǒng)；
●重點(diǎn)關(guān)注持續(xù)迭代的測(cè)試新開發(fā)的功能，而不再?gòu)?qiáng)調(diào)傳統(tǒng)測(cè)試過程中嚴(yán)格的測(cè)試階段；
●提倡盡早的開始測(cè)試，一旦系統(tǒng)某個(gè)層面可測(cè)，比如提供了模塊功能，要開始模塊層面的單元測(cè)試，同時(shí)隨著測(cè)試深入，持續(xù)進(jìn)行回歸測(cè)試保證之前測(cè)試過內(nèi)容的正確性。
2、敏捷測(cè)試中測(cè)試人員扮演的角色
程序員敏捷之路秘笈：降龍十八掌
在公司做了三次相關(guān)敏捷的主題：現(xiàn)有項(xiàng)目的敏捷之路，SCRUM，敏捷軟件測(cè)試。
但是，有朋友說這幾次都是站在管理的角度，程序員自己如何才能做做到敏捷呢?回來想想再結(jié)合之前看過的書總結(jié)出了如下18條，于是起名“降龍十八掌”吧。到底哪一條對(duì)哪一掌，大家自己對(duì)吧。
1. 態(tài)度積極。做事時(shí)專注，有問題積極找人幫忙同時(shí)也樂于幫助別人，勇于承認(rèn)錯(cuò)誤，如果你從沒犯過錯(cuò)誤，說明你可能沒努力去工作。
2. 深入理解需求。對(duì)一個(gè)需求要盡可能多的理解，不要急于著手編碼。
3. 不做世外高人。不要一個(gè)人默默無聞的編碼，多閱讀同事的代碼，也請(qǐng)同事閱讀自己的代碼，保證代碼易讀，易理解。
成功的自動(dòng)化測(cè)試：敏捷測(cè)試員與程序員之間的合作
認(rèn)為對(duì)敏捷測(cè)試員來說，什么樣的自動(dòng)化技能是重要的？
我的經(jīng)驗(yàn)而言，對(duì)于想在自動(dòng)化測(cè)試中成功的敏捷測(cè)試員，重要的技能是合作與溝通兩項(xiàng)技能。如果你正工作在這樣一個(gè)軟件開發(fā)組織，那里有程序員精心編寫的產(chǎn)品代碼，那么這些程序員是編寫自動(dòng)化測(cè)試代碼的佳人選。測(cè)試人員知道什么是正確的測(cè)試事情。對(duì)于一個(gè)測(cè)試員與程序員的組合，他們可以共同決定哪一個(gè)測(cè)試應(yīng)該自動(dòng)測(cè)試或怎樣自動(dòng)測(cè)試。但至少應(yīng)該在編碼之前啟動(dòng)這個(gè)過程，這樣程序員在設(shè)計(jì)代碼時(shí)可以使其更容易做自動(dòng)化測(cè)試。
有很多可以幫助提升敏捷測(cè)試員與程序員合作的測(cè)試框架。例如，我的團(tuán)隊(duì)在GUI后面的API層面， 利用FitNess作了多次測(cè)試。對(duì)于每一次測(cè)試，在這個(gè)階段都可以測(cè)試出這樣的事情?敏捷測(cè)試員與程序員一起合作完成某件事情，并探討出測(cè)試的設(shè)計(jì) 并能做出專業(yè)次的簡(jiǎn)單測(cè)試。程序員編寫夾具，用來進(jìn)行測(cè)試輸入，并把夾具傳送給產(chǎn)品代碼，做出相應(yīng)的操作，然后返還結(jié)果與預(yù)想結(jié)果做比較。測(cè)試人員會(huì)寫出 多樣的測(cè)試用例，用例中包含不同的輸入與預(yù)想的輸出。同樣，我們用Selenium 2.0和Webdriver跟蹤了一個(gè)類似的GUI自動(dòng)化測(cè)試。在Geb框架中使用Groovy語(yǔ)言，程序員給不同的GUI頁(yè)面編輯不同的頁(yè)面對(duì)象，這樣測(cè)試人員通過頁(yè)面對(duì)象可以編寫出多樣的用例。這樣的合作有助于確定設(shè)計(jì)的測(cè)試代碼是否合適，這也能做到長(zhǎng)期的維護(hù)，并提供了一個(gè)良好的投資回報(bào)。
更多>>