上面已經談到了準敏捷測試模式了,離咱們所說的敏捷測試已經無限接近了,但是要了解真正的敏捷測試,還是需要回到敏捷開發上來講,前面一開始已經說過,敏捷測試嚴格上來說其實是屬于敏捷開發的一部分,所以敏捷開發的價值觀也會同樣適用于敏捷測試,那么敏捷有哪些價值觀呢?總共是五個,分別是簡單、溝通、反饋、勇氣、謙遜。
光看這五個詞,我想大部分人可能會暈乎了,不知所云的,難道敏捷就五個詞能概括了?就像電影里出現的武功秘籍一樣,一招就一個圖,我們看了根本就不知道是啥,人家一看就能煉成神功了。
其實呢,這幾個價值觀并不是教你怎么去實現敏捷,而是教你用一種什么樣的態度去對待開發:要時刻想著最簡單的方法去處理需要解決的問題,要經常與和開發/客戶溝通,對于積極對待反饋,要有勇氣去做決策,對團隊各個成員都要尊重。這么幾個價值觀,對于你去初次理解敏捷而言,我相信幾乎沒有用處,甚至會讓你覺得很迷茫,到底敏捷是啥,但是一旦當你已經真正理解了敏捷的時候,你就會發現,誒,的確是這樣子的,說得很好!(哲學上說,事物的發展總是需要經歷否定之否定階段,對知識的理解也是一樣,一開始看一下概念覺得很簡單,覺得自己已經理解了(肯定);深入下去,發現問題越來越多,覺得自己沒辦法去理解(否定);到最后經過不斷地思索與實踐,終于徹底理解后,你就會覺得一開始那些簡單的概念很精辟,就應該那么簡單!(否定之否定=肯定))
不過相對于當初的先行者而言,我們又是幸運的,因為很多前輩已經幫我們理解了這些價值觀,并且研究出了很多實現的方式, 但是我們也不能去奉行拿來主義,畢竟是人家想出來的,是基于人家的實際情況,對于我們的情況不一定會適合,最好的辦法就是取其精華,去其糟粕,結合實際,加以改進。
接下來我就開始講什么是真正的敏捷測試模式和我們公司怎么結合它來取其精華,去其糟粕,結合實際,加以改進。
當然這個所謂的真正的敏捷測試模式也是業內主流的模式,我們公司的實際運用中還是有所區別的,下面都會提到。
跟前面講到的準敏捷測試相比,真正的敏捷測試其實也只是加以改進和豐富,所以與客戶的溝通、積極響應需求的變更、以及開發與測試的同步,這些都還是存在的,當然敏捷測試改進和增加了許多地方,主要有:
1、過程需要實現迭代:每個迭代周期需要完成一定量的功能,沒有完成的功能不能Check In代碼,這些功能需要經過嚴格測試,并且開發需要修復主要的嚴重Bug,這樣子在最后就得到一個可以工作的并且相對穩定的Build,這個迭代周期就算完了,然后開始下一個迭代周期。這樣就類似與我們修路一樣,修路的話需要打好幾層地基,每層地基打嚴實后,再鋪上面一層,這樣子即使最上層破了,只要修一下最上層就好了,不會影響到下面層的質量,如果是最下面那層沒打嚴的話,一出問題每層都會損壞,要修的話,要全部扒掉這么多層地基才能修好。所以迭代對于測試的要求就特別高了,因為只有把這個迭代的主要Bug找到并修好,下面的迭代周期才能不受影響,才能確保以后出現的問題不用“打到最底層”才能被修好,“打到最底層”意味著就是人力,物力,時間以及最重要的產品的質量!
下面是一個迭代的簡單示意圖,應該可以理解的,就不多講了。

2、測試不單單要和客戶溝通,也要跟公司里的人經常進行溝通,因為一個公司的所有人其實都只有一個共同目標,就是把公司發展好,這樣子其他的比如自己的發展,待遇等等才有可能實現。那么體現在實際的工作中就是:
a)測試需要完全理解需求講的知識點,不懂或者有疑慮要及時跟設計溝通,這樣子可以讓你更好地理解需求,甚至幫助設計人員發現錯誤;
b)測試人員需要經常跟開發人員溝通,看看做的功能,修的Bug主要會影響哪些其他模塊,主要出現問題的原因是什么,怎么弄可以最快速度重復出Bug來,這樣子就幫助自己掌握測試的方向以及幫助開發快速修復Bug以及避免以后出現類似Bug。
c)測試也需要跟測試人員之間進行溝通,來探索怎么能發現有質量的Bug,怎么能覆蓋到很多的測試點,怎么解決自己沒辦法解決的問題,幫助他人也幫助自己。(每日立會是其中一個好辦法)
d)測試還需要跟自己溝通,不斷地經常反思自己的優點和缺點,反思團隊的優點和缺點,反思公司的優點和缺點,大膽提出和實施改進意見,為以后更好地開展工作做準備。(反思會是一種辦法)
溝通,只有溝通才能了解雙方的想法,才能及時消除前進中的阻力和困難,讓大家在同一方向上用同一個信念前進。

3、建立有效的監測機制:這里所謂的檢測機制主要有兩點,一個是對測試的監測,另外一個就是對產品的監測。對于測試的監測主要在于檢查測試的覆蓋面是否全面,發現的Bug與測試覆蓋面的一些對比數據,這些有助于提高測試的覆蓋面從而提高Bug發現率;而對于產品的監測就是主要有兩點,一點就是做功能和修Bug的進度是否是可控的,可預判的;另一點就是發現Bug的情況,也就是產品的質量是怎樣的,質量發展的趨勢是怎樣的。
我主要想補充的是這么三點,當然要是我想到其它的,我還是會修改這篇文章的。看過網上也有很多人來寫關于敏捷測試的一些文章,很多都是國外英文解釋的標準中文翻譯,當然也有很多是自己的一些想法,所以遠近高低各不同,不過既然敏捷只是一種思想,也就不會拘泥于何種實現方式,所以各人有不同想法都Ok的。其實說的再過一點,只要你自己認為你的方法是敏捷的,那你就可以認為是敏捷的,不用關心人家怎么想,人家的方法不一定適合你的,你只要有辦法能在正確的時間交付正確的產品,那就Ok了。
所以我接下來就會按照我們公司的流程來實際介紹一下敏捷測試在我們公司的實現,中間可能會有一些地方為主流敏捷測試所不容的,但是我覺得他們比較符合我們公司的實際,如果大家有不同的意見或者更好的方法,我也會悉心接受。
(未完待續)