Q: 之前會有一個階段, 就是一組相關的特性開發完成后, 測試人員接手測試, 幾輪Bug修復過去后, 產品基本穩定就可以發布了. 現在測試人員提前介入到每個迭代中, 針對單個特性進行測試, 那如何保證產品集成起來的質量?
A: 跟以前一樣, 該有那么個集成測試階段還得有那么個集成測試階段, 取決于產品當時的質量狀態. 并不是說有了迭代級別, 單個特性級別的測試就不需要發布級別的集成測試了, 兩者沒有任何矛盾.
Q: 那么測試人員提前進入迭代有什么好處?
A: 盡早發現問題, 降低修復錯誤的成本. 有幾種手段, 一是前面提到與業務人員和開發者一起討論驗收條件, 這樣就能防止理解偏差而導致的返工. 二是開發完成立即測試, 發現問題立即反饋, 這樣開發人員對代碼依然印象深刻,能快速定位和修復錯誤. 這樣流入最后集成測試階段的Bug就會少, 會縮短最后的集成測試時間, 保證產品更平穩的發布.
Q: 有時候后續的特性會影響前面的特性, 那么迭代過程中測試人員只測單個特性, 怎么保證以前的特性依然工作?
A: 幾個手段. 測試盡量自動化, 以便能夠持續集成. 再就是做好依賴管理, 每當一個新特性完成, 就應該能夠發現它影響的其它特性, 看看是否應該補充一些集成測試.
Q: 有時候開發人員完成一個特性時已接近迭代結束, 測試人員沒有時間進行充分測試, 怎么辦?
A: 下個迭代測唄, 并且在計算開發速度時, 只應該計算本迭代通過測試人員驗收的特性, 那些僅僅是開發人員完成, 沒有經過測試人員充分測試的特性不計在內. 這種情況是不可避免的. 但我們能通過一些手段讓測試與開發更加同步, 盡量縮短滯后性, 包括讓測試人員與開發人員更緊密合作, 盡量讓測試用例自動化等.
Q: 我還是覺得在開發迭代過程中, 測試人員的工作量不飽滿.
A: 如果這不是您的感覺, 而是事實, 并且前面測試人員必須要做的工作也都做了, 還是不飽滿, 那么恭喜你, 可以省下一些測試人員, 去做別的事了. 但不推薦的是, 不要讓測試人員同時為兩個團隊工作. 這會大大增加溝通的成本. 你會經常發現, 當你的開發者想找測試人員協助時, 卻找不到人了, 于是你的團隊便被堵塞在那里. 而測試人員本身的Context切換也是痛苦的.
Q: 你們說驗收測試應該由客戶來編寫, 可在我們這里根本不可能.
A: 驗收, 當然是由客戶來驗收, 這在理論上是毫無疑問的, 而且肯定在各行各業發生著. 只是具體到測試用例的編寫和執行, 無論是自動化的還是非自動化的, 都需要掌握一定的技術, 需要周密的思考, 需要專門的時間, 客戶可能無法同時滿足這幾個條件, 我們要盡力爭取, 爭取不到, 便只好通過更充分的交流來彌補越俎代庖的失真. 這時業務分析人員和測試人員要通力合作, 完成驗收測試的編寫.
Q: 你們說你們之前的項目產品代碼和測試代碼的比例大約 1:3, 這不是平白增加了 3 倍的工作量嗎?
A: 是增加了 3 倍的代碼量而不是工作量. 它節省了你幾十人做幾個月龐大的預先設計的工作量, 節省了你詳細設計每個模塊并為之編寫幾百頁詳設文檔的時間, 節省了無數不眠之夜通宵Debug的時間, 它節省了集成階段修復難以計數的Bug的工作量, 甚至它縮減了你產品代碼的數量, 大量的重復代碼被消除了, 大量過度設計的復雜代碼被廢除了, 你的代碼更易理解了, 添加新特性更容易了, 發現的Bug更易定位了, 以致于大大減少了長達數年的生命周期內維護的工作量. 有點夸張了? 可這就是 TDD 和敏捷開發帶給我們的好處(如果你已經實踐了)和vision(如果你還在觀望)
Q: 我們也做單元測試, 但是是先寫產品代碼后寫測試的. 難道非得 TDD, 非得測試先行嗎?
A: 沒什么事是非做不可的. 取決于你要什么. TDD 只是以可驗證的方式迫使你將質量內建在思維中, 長期的測試先行將歷練你思維的質量. 而事后的單元測試只是惶恐的跟隨者.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
