看ASP .NET 團隊如何進行測試(2)
Evolution of the ASP.NET Test Process (Part 2)
http://testertales.blogspot.com/2009/08/evolution-of-aspnet-test-process-part-2.html
Friday, July 31, 2009
Posted by Federico Silva Armas
The Feature Crew Model
在.NET 2.0 release之後, 開發團隊對開發軟體的方法, 做了一個很大的轉變. 這個改變是從上到下, 作者稱它為"Feature Crew Model". 整個開發部門為了這個方法做了很多準備, 花了幾個月的時間去開發許多工具以及infrastructure. 這個model主要概念如下:
1. 在開發部門中, 每個Product Unit(PU)會把要relase的系統切分成一堆features. "feaures" 是產品的一個logical sub component, 理論上他們可以單獨被開發
2. 會從PM, Dev, QA 的resources, 找出適當的人來建立feature crew. 他們會有一定程度的自主權, 來管理他們的milestone, 以完成他們feature
3. Feature crew會在一個獨立的code branch中開發他們的東西
4. 他們會訂定一連串的Quality gates, 唯有通過這些規定, 這個feature才算完成. 這些程式才允許整合到main product branch
這種作法的關鍵是, 要求每個個別的feature要做到完美, 才能整合進來. 和以前比較起來, 這是很大的改進. 以前是很多程式開發都放在main branch, 因此必須不斷的做regression test, 來確保整個系統的品質.
第二個好處是, 鼓勵Dev和QA必須要有更好的溝通, 並且讓他們可以嘗試Scrum或是其他任何agile的 methodolgies.
Our First Feature Crews (ASP.NET Ajax 1.0 Release)
作者第一次用feature crew, 是在做ASP .NET Ajax 1.0(Atlas)的時候. 那時候沒有人知道要怎麼做, 因此他們必須做一些實驗並且適當的客制化, 來符合他們的狀況:
Atlas把團隊分成以下feature crews(這些crews也是依以下順序kick off, 因為後面的會依賴前面的)
- Core: which included the type system and BCL.
- Networking: everything under Sys.Net
- Partial Rendering: UpdatePanel (this is the feature crew that I worked on, along side Eilon Lipton)
- UpdateProgress/Timer: targeted crews for only these 2 controls.
- Services: script callable Membership, Profile and Roles services.
ASP.NET QA Process in a Feature Crew
相對舊的流程, ASP NET 的 QA團隊並沒有太多實質上的改變, 我們還是忙於準備測試那些要發行的不同版本, 所以我門要做的事情如下:
1. QA 的resource被分配到一個feature crew
2. Deve/PM/Test同時在獨立的code branch上, 開始處理這個feature
3. Dev 負責撰寫unit test
4. 每週至少三次desgin feature 會議, 或是提供status updates
5. 當在desing再進行的時候, PM負責spec, Dev負責prototypes, QA負責test plan
6. QA同樣也有test plan review
7. 每當Dev有check in code時, QA會盡快去測試它, 並且開始撰寫 automation
8. 利用autoamtion complete numbers來追蹤目前的進度
9. QA負責確認是否Quality gates check list上的東西已經完成. 更重要的是, 是否這些quality gate上的東西是被自動化完成, 並且在大量的configuration上被執行過.
10. 等到所有quality gates被滿足後, 這個feature將會被整合到main branch
How did it Work?
Benefits
- 在不同rile之間會有較好的合作發生
- QA在測試階段就加入
- Code整合到main branch時已經有很高的品質
- Dev的unit test可以幫忙在早期找到問題
Disadvantages
- 最大的問題是, 過去在2-3年內要做的事情, 現在要在3-4 月內做完. QA並沒有改變做事的流程, 所以QA變成是bottle neck. QA仍然需要建立完整且全面性的feature test plan, 並且還是很著重於automation. 即使現在feature改變的很頻繁, 我們還是這樣做.
- Dev的unit test和QA的functional test, 之間有些重複, 以前的舊思維"test everuthing"仍然存在.
- Crew 之間的關連性造成一些問題, 使得crews會進行的不順利或停頓
這個model, 使得團隊在開發流程的初期, 就開始注意quality. 但是QA團隊卻因此而遭遇很多問題, 有些問題是之前遇到, 可是後來還是一再發生, 像是 finding bugs to late. 所以作者認為他們還需要再作調整, 來解決這些問題
Note:
我在之前曾有一篇描述類似的作法: Agile at Microsoft. 看起來微軟似乎已經是全面採用這樣的作法, 大家可以參考一下
http://www.wretch.cc/blog/kojenchieh/15331734
留言列表
