敏捷實踐報告：用于系統測試的模型

 如我在本文中提到的，系統測試是在將軟件產品交付給客戶使用之前完成的最終產品測試。此測試一般在完成開發和功能驗證測試之后進行。某些入口標準用來確定對于系統測試的代碼準備狀態（舉例來說 ， 回歸狀態，缺陷后備，等等）。必須達到這些標準，從而正式地開始系統測試并要求結果。

        在一般的系統測試中，目標是用類似客戶的配置在高壓下對系統進行類似客戶的工作量（舉例來說，多平臺、多軟件版本，等等）。 正式的系統測試執行包含壓力、壽命期運行、內存泄漏分析、多應用程序、復雜且各種各樣的拓撲、高可用性及中斷測試、混合的版本測試、全平臺測試、產品集成測試，及文檔測試。

        本文介紹了團隊所采用的將一組系統測試子集作為敏捷開發環境的一部分，并與代碼開發活動并行的方法。我們將展示出我們的方法可以交付更好的系統測試應用程序，讓實驗方法將包含與代碼開發并行的系統測試子集的價值和效率最大化，并提高團隊的溝通和技能。這些成功 導致 （led） 了在完整的系統測試開始時改進了的完整的 軟件驗證團隊（ SVT ） 的加速的時間，以及改進了的產品質量的預期好處。

        在六個迭代中，系統測試核心團隊與開發團隊并行工作。這能夠讓傳統的系統測試應用程序的子集的開發和執行在每個迭代的過程中執行。該并行導致了此處描述的各個方面的成功。

敏捷的過程實現模型

        在開發的一年之后，使用現有的瀑布實踐并交付開放的 alpha 和 beta，我們的項目轉換了工具，并實現敏捷的開發模型。整個團隊需要將敏捷的開發原則作為“現場實驗”，從而滿足特定客戶的需求。第一個迭代是過渡的，通常著重于交付在瀑布開發模型下開發了幾個月的代碼。當第一個迭代開始時，整個團隊包括大約五十五個人，包括設計人員、開發人員、測試人員、信息開發人員和客戶交付團隊。

        迭代 1 用作過渡的迭代，用于完成已經處于開發中的可交付件。敏捷開發過渡適當地啟動，并且帶有對前一或兩個迭代的適度的開發承諾。主要的焦點在于在團隊和集成的過程之間構建并交流新的項目和人與人之間的文化，例如，并行的早期系統測試，這將會用于在新的環境中令團隊成功。

        九個系統測試人員（整個系統測試團隊的子集）在先前的瀑布開發周期中兼職參與。在開發代碼的過程中，他們關注構建技術技能、計劃、測試案例開發，和應用程序單元測試。這樣做，他們練就了項目所用的技術中的技能，但沒有獲得內行的經驗。

        當轉變為敏捷開發時，九個系統測試人員中的五個全職參與項目。因此，在第一個迭代之前，系統測試團隊已經了解了新技術，創建了測試應用程序，并且像團隊一樣一起工作。這些早期的測試及開發活動令敏捷周期的開始有更高的生產率。

系統測試團隊參與的目的

        五個系統測試人員面臨的挑戰是確保代碼質量足以達到在任一已知的迭代中開發的功能的 beta 級交付。為了迎接這個挑戰，他們決定在每個迭代中運行傳統的系統測試應用程序開發和執行的子集，預期最終的迭代進行一組更復雜的具體客戶的，基于場景的測試。系統測試團隊與項目的高級架構師會面，并一起為了增強和執行選擇一個現有的系統測試應用程序。然后，該應用程序將用于在迭代過程中的壓力和壽命期運行，并且在最終的迭代里大量地使用。目的是在項目最終在世界范圍內交付時，系統測試人員有限且同時的參與會為最終的完全的系統測試迭代建立起堅固的基礎。

項目和迭代的時間線

        迭代有六個星期之久。表 1 顯示了一般的迭代規劃，以及為每個星期計劃的具體的系統測試活動。在迭代的第 1 周中，高級架構師提出建議的候選功能列表。該列表主要基于具體客戶的需求，并且通過用例進行描述。該列表可在線訪問，以便在迭代進行中，所有的團隊成員都可以改進用例。每個團隊成員都會審查候選的列表，并與團隊成員和高級架構師一起討論設計及問題，并且在周末提交在迭代結束時（是否）要交付的功能。每天舉行一個小會。高級架構師每天都出席大部分小會議，并且在所有迭代過程中都與全部團隊成員在一起。

        如前面所提到的，最后的迭代計劃著重于在開發迭代中不能實現的最終的缺陷清理和復雜的測試。為了提高穩定性，最后的迭代沒有新的功能。六個迭代完成了。同時，在最后的迭代中，大量的開發人員需要加入系統測試團隊成員中，通過提供對測試執行和調試的輔助來完成最終的迭代。其余的開發人員會處理缺陷。這意味著在較早的迭代中的開發階段里，一些開發人員需要為了最后的迭代而培訓系統測試的知識。

原文轉自：http://www.anti-gravitydesign.com