在信息技術外包世界，對一個公司擁有它的應用程序和被其他人開發或者維護的框架是普遍的。當銷售商完成這個生意，一個普通的實驗是把測試過渡活動當成是一個整體。你如何設計一個傳統實驗的可接受標準以至于它可測試并且被清晰溝通？

作為測試，我們通常討論當一個應用程序被創建時如何接近測試并且被在我們自己公司內的團隊維護，但是我們很少討論當從一個外包供應商到另一個變化時發生了什么。

在信息技術外包的世界，對一個公司擁有它的被其他人開發和維護的應用程序和架構是普遍的。當銷售商完成這筆生意，有合同涉及組建管理，實時服務水平，關于發布內容的委員會，等等。一個普通的合同部分是測試交換活動作為一個整體，都為了架構和應用程序。

客戶想要的是將服務和他們需要的解決方案合成文檔的能力便于他們能外包他們流程的一部分，經常是為了更高的價錢或者更好的策略契合，沒有打擾到商業。

近來我是一名在有這個挑戰的應用程序過渡項目的測試經理。被另一個90后公司維護的應用程序并且我們繼續維護和開發這個應用程序。但是在我們能做以前，合同定義了一個我們不得不通過的“傳統實驗”。我的任務是制定關于傳統實驗可測試和可被清晰溝通的可接受標準。

那封郵件是什么呢？

應用程序過度實驗中的測試

在這種測試內容里有一些特殊術語。這個合同把它定義成一個實驗——而不是一個測試或者檢測。

一個實驗在測試和質量保證方面有很多相似性。我們被提供一些高水平可接受標準并被問及確認和整理文檔以使這些事情實際上發生。一些特殊可接受標準能實施一些系統簡易變化，升級文檔，并且創立循環合作會議。

和傳統軟件研發可接受標準工作，我們期待可接受標準能關于應用程序的功能性和業務-支持活動。但是這兒可接受標準被認為測試下的一項目，所以我們不得不相應地搭我們的實驗測試用例架子。

其中一個合同需求是系統文檔的升級。這被以下實驗測試用例捕獲了：“系統描述文檔被升級了嗎？”我們不再深入一步且沒有期待的或者實際結果。它決定測試去評估假如文檔確實被升級并且為客戶改進以至于我們提供一個升級文檔。

注意到我們使用開放問題去允許測試成為一項活動和一個性能，并且測試活動本身可被綱要和檢查列表支持而不是詳細的腳本。它正是一個“每一個公平的事物”和“沒有其他壞事情發生（我們所知的）”的大事。

可接受標準沒有詳細說明關于文檔是否被升級或者其他任一細節。我們能做的是以原先版本為基準然后是升級的版本并且看變化，至少在作者部分里。再次，測試準備是一個在執行不明確需求的實驗并把它們重寫進可測試的活動中。

讀到合同發布了65個活動或者文檔的一個組織，并且沒有附加測試管理工具的要求，我建立了每一個作為在一個電子表格一行的開放問題。然后我以一個看板版建了4列：要做的，進行中，已做的，和已歸檔的。公司的內容和傳統是我們不得不為每一個測試活動提供證據和文檔。

即使有傳統方法去測試分析和測試用例管理，很多團隊成員發現一個測試用例不覆蓋其他的而是對應用程序的功能性代碼是一個挑戰。即使做一個簡單的對系統的改變的活動從來不是一個變化本身的測試——它可以是關于給應用程序刷成粉色，對于所有事物。測試實驗更多的是關于有能力交付一個改變而不是變化自身。

期待看到更多過渡實驗

外包項目的測試實驗正越來越普通，不僅考慮到應用程序，還要為信息技術架構，信息技術支持，和很多其他想法。有一個明顯的趨勢是Linux，Windows，Oracle，和其他技術現在被要求至少一些在使用前發布它們的它們的配置和標準化的測試。

這些技術通?？粗鴾y試為一個確定活動，并且它們趨向于使用軟件開發的V-模型，每一個開發階段有一個相應的測試階段。好消息是測試是一個被要求的事項，并且我們可以開始討論關于這些如何測試，如何測試工作作為一個活動我們能學習到不僅是應用程序而且架構的技術。

傳統可接受標準的實驗將越來越頻繁。作為測試專家，我們需要熟悉測試一個應用程序和工作一個在傳統實驗下的應用程序的區別如此我們才可能恰當地交付一個無縫轉換。

轉載于:https://www.cnblogs.com/fengye151/p/11519212.html

總結

以上是生活随笔為你收集整理的过渡期间的测试：外包软件的测试标准（译）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。