我們最近調查了很多問題關於使用Jira的測試用例管理。從如何使用Jira測試解決方案最好補充一個Jira的過程,Jira和測試似乎這些天小時的主題。

這個流行未必是令人驚訝的最近Tricentis民意調查中,66%的受訪者表示使用Jira過去幾個月或幾年。

所以你具體需要知道當談到使用Jira測試用例管理?本指南將指導您完成一切從頭到尾,包括:

1. 使用Jira測試的挑戰
2. 如何定製Jira測試嗎
3. 使用嚴格的利弊Jira測試用例管理
4. 集成測試工具與Jira的選項
5. 建議尋找最好的解決方案組合為您的需要

一個快速的乙Jira上背景

對於那些不知道,Jira是一個問題從Atlassian和項目跟蹤軟件。目前,它的數量一個敏捷團隊所使用的軟件開發工具,采用敏捷的持續增長,越來越多的組織正在引入Jira。的最近首次公開募股以及大規模的公司留下遺產ALM提供者隻有推動Jira的廣泛采用。

雖然JIRA設計問題和項目跟蹤,許多團隊都使用它為測試用例管理,開發和測試可以保持在一個係統中。但是JIRA設置用於測試如何?讓我們看一看。

使用Jira測試的挑戰

回到JIRA如何設置測試的問題,簡短的回答是,JIRA不是。現實是要複雜得多,尤其是考慮到許多組織如何使用今天進行測試。

當你開始關注如何構建一個測試過程在Jira,最常見的起點是與一個問題類型。你會發現Jira有幾種不同類型的問題(錯誤、史詩、改進),但沒有專門為測試。這是因為Jira不是一個測試案例管理解決方案。這真的意味著問題跟蹤。

你可以定製Jira在某些方麵使用一些測試用例管理過程,但這些都是臨時定製和他們有局限性。例如,每個工作流構建內部Jira的端點”。”,但在測試中,即使你完成一個測試,這並不一定意味著你實際上完成了測試。

這種設置意味著如果你定製Jira或某些測試用例管理問題,你總是會發現你搬到一個狀態當你可能不是“完成”完成一次測試執行。你真正想要的是能夠使用多種類型的測試的測試用例,無論是回歸測試或各種參數和配置下運行相同的測試用例來驗證一個新特性。然而,由於Jira問題總是要被推到“完成”,你是有限的靈活性的重用問題進行測試。

Atlassian Jira說自己的文檔,它可以為手動測試工作,驗收測試等等,但顯然他警告說,沒有天真的內置Jira策略功能。同樣,如果您正在使用任何類型的自動化,您需要使用另一個解決方案。

即使有手動和驗收測試,有一定的局限性。假設Jira並很好地運行手動測試用例。它可能工作一次或一個全新的功能,但是你把它移動到“完成”狀態,接下來會發生什麼?如果你想做回歸或基於會話的測試?你打算如何跨項目,重用這些對象分配多個票項目和表明覆蓋?由於Jira的方式設置,你不能。

如何定製Jira測試嗎

盡管所帶來的局限性,許多團隊使用JIRA測試用例管理和他們通常這樣做通過定製問題以兩種方式之一:添加一個“測試用例”問題類型,或者使用“用戶故事。“讓我們仔細看看這些選項是如何工作的:

深潛水:添加一個“測試用例”的問題類型

測試用例管理定製Jira通過添加一個“測試用例”的問題類型,你需要以下步驟:

1. 創建一個“測試用例”的問題類型
2. 添加所需的步驟完成一個預期的結果
3. 使測試用例的父母的問題你需要做測試
4. 創建一個子任務的子任務和標簽為“測試運行”來執行測試
5. 結果,影響版本,結果和受讓人的運行測試在“測試運行”的子任務

雖然這種方法在理論工作,實際上,它帶來了一些挑戰:

• 重新運行測試:如果你需要重新運行測試執行和測試新版本,您需要添加更多的測試子任務,你必須添加子任務每一次你想要記錄曆史的測試用例。
• 重用測試:測試用例管理,你經常需要重用測試運行日誌的可見性測試,但是你不能在JIRA重用子任務,因為他們是標記為“完成”。
• 創建覆蓋報告:因為所有的子任務被分配在一個家長的問題,你不能組幾個測試運行到不同的配置和顯示覆蓋報告。

深潛水:使用“用戶故事”

或者,您可以定製Jira的測試用例管理通過調整“用戶故事”。這種方法是如何工作的:

• 創建一個用戶故事(這將作為測試用例以同樣的方式,新的父問題在第一個選項)
• 添加子任務,作為測試用例或測試運行,回指用戶故事
• 如果所有的子任務,然後用戶故事準備投入生產

再一次,這種方法提出了挑戰,因為子任務作為測試用例和測試運行。具體地說,它提出了挑戰:

• 重用測試:如果你想要再次使用子任務,例如在回歸周期或鏈接到另一個用戶故事,它變得複雜,因為用戶故事可能已經被標記為“完成”。
  • 注意:Jira的工作流,所有問題都標記為完成關閉。如果你有重新子任務,然後把它轉換成一個測試用例模板或測試用例類型,你最終得到的大量的維護開銷。
• 調整測試用例:由於這個設置,如果您有多個測試用例鏈接到多個用戶故事,調整測試用例將變得非常困難。

使用嚴格的利弊Jira測試用例管理

正如上麵的例子所演示的,雖然Jira不是設計用來測試你可以定製來滿足特定的測試用例管理需求。但是,你應該這樣做嗎?讓我們考慮使用嚴格的利弊Jira的測試用例管理:

讚成使用Jira進行測試用例的管理:

• 創建自定義問題類型,如測試用例
• 一個工作流QA、開發人員和測試行為
• 能夠使用現有的報告(Jira並提供出色的報告)
• 能夠使用一個已經購買和已知的工具(如果你已經有Jira到位)
• 好一次性手冊執行

反對使用Jira的測試用例管理:

• 沒有測試特定功能(這是Atlassian本身調用)
• 通過CI服務器隻有集成測試框架
• 無法創建一個測試用例覆蓋率報告,包括手動執行,自動化執行身份驗證和基於會話的身份驗證執行
• 沒有問題和測試用例之間的可跟蹤性報告覆蓋率
• 沒有辦法執行不止一次運行,這意味著大量重複的工作
• 限製在測試周期和套件執行,測試步驟執行狀態,版本控製和環境配置

所有這一切意味著,你通常會做的事情與一個測試用例和環境執行工具,如分組測試周期和測試執行,運行測試配置和處理版本控製,不受支持。這讓你覺得:Jira真的是為測試或建造你迫使這個問題嗎(沒有雙關,因為一切JIRA是個問題)?在大多數情況下,你強迫的問題,可能會有更好的方式。

集成測試工具與Jira的選項

因為Jira不是為測試而設計的,它帶來了很多限製用於測試目的。可以說是最大的限製是無法重用和集中測試工作。

如果你已經過渡到Jira,您的開發人員喜歡它,你會做什麼呢?有什麼方法讓您的測試團隊Jira的價值?集成可以提供幫助。

因為Jira不是為測試而設計的,它帶來了很多限製用於測試目的。可以說是最大的限製是無法重用和集中測試工作。

有兩種類型的集成可以使用Jira添加測試功能:

1. 外接程序,內部集成,實時Jira內部應用程序和擴展功能的一些測試用例
2. 外部與一個專用的測試用例管理工具的集成

讓我們仔細看看這些集成選項包括:

Jira軟件或插件呢?

插件可以通過Atlassian市場。幾個常用的插件測試包括:

• Jira的x光和西風,Jira對於手工測試執行(x光也提供了一些功能在BDD測試)
• 表現的專業和Tricentisqt的場景BDD, TDD和ATDD測試(這是最適合小團隊或那些擁抱更多的敏捷2.0空間內JIRA)

這些類型的插件擴展Jira的功能,使其能更好的測試用例管理。例如,x光自動添加一個“測試”的問題類型的問題列表,並允許您添加測試用例步驟測試問題類型。這個設置創建一個自定義問題的緩解問題類型,需要您添加的主要部分包括完成步驟和預期成果(反過來讓你通過大量的測試,你必須做一次和無法逐行步驟失敗了,它是執行和實際執行)。

與此同時,如果你想做BDD測試,很難遵循小黃瓜”,當,那麼“語法僅在JIRA,但附加像Tricentis qt場景成為可能。Tricentis qt場景允許您導入點特性文件連同你的場景的問題類型,您不再需要創建標準問題類型。相反,您可以添加在小黃瓜風格測試腳本語言場景中,你可以創建一個點特性文件。您還可以創建場景文件附加到這些點的特性文件JIRA,它允許您將它們添加到一個用戶故事。

讚成使用插件

一般來說,測試插件試圖召集組測試發生在Jira,這樣你可以把所有的測試用例為周期或套件。他們還讓你看到最新的測試用例的執行結果為每個分組,分組的創建可見性測試執行。

其他優點使用Jira的插件來提高測試的功能包括:

• Jira維護一個相似的外觀和感覺
• 使用Jira的儀表板內
• 簡化采購通過Atlassian處理在線市場
• 接收測試特定的功能的訪問
• 獲得測試對象鏈接到其他問題的能力

反對使用插件

插件做的幫助很多,你還是有點綁上你能做什麼和不能做的文本執行,因為附加的功能是基於Jira基礎設施允許有限。

例如,手動過程的附加組件創建一個更比你會與一個專用的測試用例管理解決方案。另外,你做的每件事都在附加僅限於特定的項目,這意味著你不能把同樣的問題在多個項目。

附件還將展示一些版本限製當你創建一個測試用例。通常情況下,如果您創建一個問題去運行問題,測試用例的運行是一個簡單的重複。假設你有五個步驟的測試用例的運行周期和您添加另一個步驟。Jira會自動推送數據到每個測試用例運行,這意味著你不能保持不同版本。與Tricentis qt和其他一些工具,你可以跟蹤不同版本的測試用例和過去版本運行時執行,但你需要有一個一對一的版本曆史的測試用例的執行順序。

最後,當你使用一個插件,一個測試用例=一個Jira的問題。也許不會出現,但這是它是如何與所有的插件,並且設置提出了限製。

其他缺點使用附件改善Jira的測試功能包括:

• 零個或有限的可用性重用測試周期(你可以克隆一個測試周期或你可能需要測試用例進入一個特別的測試周期不附加到一個版本)
• 沒有邏輯的文件夾結構
• 未知的改變曆史和有限的可見性測試執行測試用例版本曆史
• 無法跨Jira項目共享對象的測試用例,使得擴展困難,創造了很多重複的工作,因為你不能運行相同的測試與不同的變量
• 有限的可伸縮性來存儲大量的測試結果數據,通常會成為一個問題當團隊過渡到自動化測試

深潛水:專用測試案例管理解決方案

大多數測試團隊的鬥爭是非常有效的。往往是因為他們不使用正確的工具。一個專用的測試用例管理工具可以幫助提高效率,還有很多,現在提供某種程度的外部集成JIRA為了帶來更多的策略功能測試過程,同時仍然允許您使用JIRA。

大多數測試團隊努力是有效的。往往是因為他們不使用正確的工具。

測試管理工具做什麼?

測試管理工具:

• 鞏固你所有的自動和手動執行:很多插件專注於手動執行,BDD或TDD,但是如果你在做一個硒自動化或一個自定義的框架,你會想鞏固你所有的執行死刑的方式也與JIRA通信。一個專用的測試用例管理工具可以幫助您完成這一目標。
• 提供增強重用死刑執行設置和能力:插件可以把測試用例分成周期,但是他們不能把測試周期內其他周期或一個周期,測試套件執行。專門的測試用例管理工具,另一方麵,可以這樣做。這些工具還允許可伸縮性通過這樣你沒有回到原始記錄和複製和改變測試用例。
• 顯示的整個曆史執行內部Jira:通過顯示的整個曆史Jira內部執行,一個專用的測試用例管理工具可以幫助您確定如何通過測試階段測試用例執行。該視圖可以幫助您輕鬆地看到一個測試用例失敗的原因。
• 讓你與多個項目共享測試用例:專門的測試用例管理工具還可以消除隔離的測試用例,使其容易與多個項目共享的測試用例。例如,使用Tricentisqt,可以有多個測試運行相同的測試用例,每個測試運行可以有不同的配置,環境設置,結果,權利人,等等,但他們都可以綁定到相同的測試用例。這個設置允許您使用測試用例作為模板而不必重複一遍又一遍地。
• 提供企業可擴展性:不像Jira應用和插件,Tricentis qt並不依賴於Jira數據庫或數據結構房屋數據。想要了解更多關於存儲Jira的局限性,閱讀我們的實驗結果與Jira測試管理服務器和一個共同的應用程序。

使用專用的測試用例管理工具的優點

通過提供上述功能,集成一個專用的測試用例管理工具可以改善Jira內測試。這種方法的優點包括:

• 企業測試等功能配置管理器訪問、CI集成與詹金斯和竹子和自動化測試支持
• 能夠使用定製的基於模板的測試用例庫
• 能夠重用測試用例,並在不同的項目之間共享對象
• 支持多種測試策略

使用一個專用的測試用例管理工具的缺點

盡管價值整合與JIRA可以提供一個專用的測試用例管理工具,它仍有其局限性。這種方法的缺點包括:

• 處理持續數據庫之間的同步工具,Jira(跟隨)
• 管理權限構件映射
• 在瀏覽器的限製(例如惠普需要Internet Explorer)
• 缺少一個完整的與Jira的集成
• 工作在不同程度的開放源碼友好專用的測試用例管理工具之一

考慮到這些缺點,有幾個點需要考慮,以幫助確定是否一個外部集成的優點與一個專用的測試用例管理工具大於缺點:

• 你的團隊有一個廣泛的測試方法嗎?如果你是一個小團隊,隻有做手工測試,沒有推動自動化、附加或獨自Jira可能會奏效。然而,如果你有一個廣泛的測試方法,你可能需要一個專用的測試用例管理工具。
• 你的測試策略保證企業測試工具嗎?如果它是你需要的東西,然後一個外部集成的路要走。如果這僅僅是一個漂亮,一個插件或獨自Jira可能會奏效。

得到兩全其美

而專用的測試用例管理工具提供了最好的體驗測試Jira,它通常還帶來了一些負麵影響。然而,它是可能得到兩全其美企業測試用例管理工具和Jira之間。

實現這一平衡的關鍵是理解,不是所有的集成都是平等和識別類型的解決方案,為您的需求提供最優集成經驗。例如,大多數測試解決方案使用計劃同步,但Tricentis qt經理有一個實時集成,使用的人。

與計劃同步,你必須映射整個測試用例管理工具模式JIRA模式,這意味著你必須持續不斷地把數據和使用資源,保持係統電流。計劃同步也容易延誤,表現不佳是因為api不斷試圖找出是什麼被更新和數據損壞如果任何時間表碰撞發生。所有這一切需要大量的資源來管理集成。與實時同步,與此同時,你會得到一個項目之間的直接映射(及其問題,無論是用戶故事,史詩,子任務,等等)和JIRA,然後您可以顯示測試用例的覆蓋率對這些問題。實時同步提供了一個直接提交為缺陷,JIRA瀏覽器自動化和嵌入式報道,加上它確保數據準確性由於JIRA總是源記錄用戶故事和缺陷。的real-time sync option keeps both developers and testers happy because it allows everyone to keep doing all of their updates inside of Jira and only requires you to pull the issues that you care about into the test case management tool, where you can then create test cases and test runs and map those to the requirements from Jira. Once you’ve executed those runs, you can simply push the defect back out to Jira to interact with it and start working on a resolution. This allows everyone to keep doing all of their updates inside of JIRA and only requires you to pull the issues that you care about.With this type of integration in place, your developers can stay inside of Jira (rather than going to another tool to see everything) and your testers gain access to the enterprise features that are missing from a lot of the add-ons that are available — all without a complicated, time-consuming integration to manage. In other words, you get the best of both worlds.

為你的組織哪個選項是正確的?

最終,混合解決方案——Jira, Jira +一個插件或Jira +外部集成——適合你的團隊的大小很大程度上取決於你的團隊和測試做的類型。

來幫助您確定最適合您的需求的解決方案組合,我們已經給出了我們的建議在以下圖表: