敏捷測試理論以及實踐 3

2021-08-02 21:46:44 字數 2204 閱讀 9452

**:

【本篇是《敏捷

測試理論以及實踐》第三篇,(第一篇,第二篇,第三篇,第四篇,第五篇,第六篇,第七篇)】

現在先來總結一下到底上面說的模型存在著哪些問題:

1.客戶生氣地說:這個產品好像不是我們想要的吧!早知你們給我這樣子的產品,我才不會下單了,你們也早點跟我說這個產品是這樣子,到現在才給我看,浪費我時間,精力,我不買了!(客戶到交付後來發現產品與當初他們提的需求不一致,所以很生氣,後果很嚴重)

2.設計團隊激動地說:都開發了這麼長時間了,你們還要改功能加功能啊,這樣子會影響到很多其他功能的,會影響最後發布時間的,而且最後的質量如何,我不能保證。(老兄,我出錢買你們產品的好吧,我想加什麼功能改什麼功能當然得給我弄好,不然我不付錢了!)

3.開發人員暴跳如雷地說:你們這幫測試,早不提晚不提,總是在最後要發布前給我們提這麼多bug,是不是存心給我們找茬啊!要是不能準時發布,你們負責啊!(測試人員委屈地說:我們也想能早點發現這個bug,早點修好這個bug啊,但是之前你們也沒我build測啊!)

就這樣,不斷地出現相互的抱怨,也就是所謂的矛盾,哲學上說,矛盾是事物發展的動力,所以這些矛盾的出現,也就是預示著,我們需要有解決這些矛盾的方法,很慶幸,我們的很多前輩已經幫我們解決了這方面的問題,準確地說是從理論上解決了這種問題,且聽我慢慢道來。

首先,對於客戶能否得到自己想要的產品這個問題,以前得不到的原因無非就是兩點,

第乙個就是我們一開始設計的需求點其實跟客戶所想要的需求不一致。這一點,我們可以通過需求設計完成後馬上跟客戶確認就可以解決。

第二點就是客戶只能等到最後時刻才能看到這個產品,也就意味著,即使他們發現自己以前的想法是不對的,想要改一下自己的想法卻來不及了,因為產品已經出來了,再去改可能又要等很長時間了,這個誰也拖不起。這一點,我們可以通過經常給客戶交付乙個可用的build,讓客戶去看已經實現的功能,來研究是否還需要更改。

而對於我們的設計團隊來說,上面的第二點也正好可以解決他們的問題,由於有可用的build,所以我們設計好的功能一做完就可以馬上讓客戶看到,一旦要修改些什麼,就不會再像以前那樣由於所有功能點都做完了,改乙個就牽一髮而動全身了,這點也類似之前說的,乙個bug發現的越早修得成本越低。

而對於咱們的開發人員和測試人員而言,為了幫助客戶得到自己想要的產品,也需要做些改變,不過也很簡單,幾句話而已,開發完成乙個功能以後,測試人員就要測試這個功能,然後開發人員需要把發現的bug馬上修掉,最後測試需要把修復的bug確認修復。這樣子的話,就可以解決以前最後階段才能開展測試,才能發現大量bug,導致發布成本增加、延期等不確定因素的發生。

當然,這裡還有一點必須說一下,即使採用了新方法,成本增加,時間延期這種事情還是有可能發生,但是新的方法可以讓你**到可能發生的成本與時間問題,不會像以前那樣到最後時刻才會發現,這樣子對於領導層做決策還是會有很大幫助的。

講到這裡,大家應該發現,測試流程已經完全與開發流程並行了,之前說的w模型雖然也會有並行,但是只是屬於「偽並行」,因為它需要乙個階段結束才能進行下個階段,比如開發完所有的功能以後才能開始測試,而對於這個模型,測試自始至終一直在參與著測試,不會去管哪個階段是否完成,只在乎哪個功能已經設計好,已經開發好。對於設計好的功能,測試裡也有專門的設計測試工程師(design qa)去專門檢查這個設計是否符合客戶的要求,甚至會去和客戶做溝通;對於開發好的功能,一方面**完成後開發需要馬上進行單元測試,然後專職測試人員拿到daily build以後就要馬上常規測試,看看是否工作,發現嚴重bug馬上提上去讓開發修;最後所有功能都已經確認和測試完畢後,測試人員還要再繼續進行整合測試、系統測試和壓力測試等等;甚至到了後來的維護階段還需要測試人員繼續參與,因為很多技術支援人員對產品沒有測試人員了解地多,所以碰到難的問題,還需要測試人員的幫忙。

所以從一開始的設計到最後的發布,測試人員一直全程參與著,這個跟以前的模式已經有了非常大的改變了,對測試人員的要求和壓力已經是不可同日而語了。這個新的模式也就是敏捷測試模式的雛形了,當然還並非完全的敏捷測試模式,所以我暫時先把它稱之為準敏捷模式

既然有了準敏捷模式,那什麼才是真正的敏捷測試模式呢?呵呵,還是聽下回分解吧。

(未完待續)

敏捷測試理論以及實踐 2

所謂的v模型,其實是對瀑布模型的一種修改,也算乙個change吧,詳見下圖 由於瀑布模型對於軟體的需求分析與設計階段考慮不足,導致可能會出現嚴重的設計問題,最後交付到客戶手裡才會被發現,所以v模型就考慮到這點,針對開發的各個過程都會有相應的測試環節,比如使用者需求會對應驗收測試,需求分析和系統設計會...

敏捷測試理論以及實踐 4

本篇是 敏捷 測試理論以及實踐 第四篇,第一篇,第二篇,第三篇,第四篇,第五篇,第六篇,第七篇 上面已經談到了準敏捷測試模式了,離咱們所說的敏捷測試已經無限接近了,但是要了解真正的敏捷測試,還是需要回到敏捷開發上來講,前面一開始已經說過,敏捷測試嚴格上來說其實是屬於敏捷開發的一部分,所以敏捷開發的價...

敏捷測試理論以及實踐(4)

上面已經談到了準 敏捷測試 模式了,離咱們所說的敏捷測試已經無限接近了,但是要了解真正的敏捷測試,還是需要回到敏捷開發上來講,前面一開始已經說過,敏捷測試嚴格上來說其實是屬於敏捷開發的一部分,所以敏捷開發的價值觀也會同樣適用於敏捷測試,那麼敏捷有哪些價值觀呢?總共是五個,分別是簡單 溝通 反饋 勇氣...