From Fedora Project Wiki
(Add some items and use table format)
 
Line 4: Line 4:
This proposal analyses our current mediawiki-based system workflow and use cases, list the pro's and con's and compare them with nitrate system. The purpose is to find out what features we Must-Have and Nice-to-have in future TCMS, aka nitrate, and nitrate should be customized bases on these requirements.  
This proposal analyses our current mediawiki-based system workflow and use cases, list the pro's and con's and compare them with nitrate system. The purpose is to find out what features we Must-Have and Nice-to-have in future TCMS, aka nitrate, and nitrate should be customized bases on these requirements.  


== Current wiki-based TCMS ==
== wiki-based TCMS VS Nitrate System ==


=== General Manual Test Use case ===
 
{| class="wikitable sortable"
|-
! width="50%"| Wiki !! width="50%"| Nitrate
|-
! colspan="2"| Use cases 
|-
|
General Manual Test Use case：


For each release:
For each release:
Line 22: Line 30:
* Execute tests and provide test results
* Execute tests and provide test results
* Summarize the report manually  
* Summarize the report manually  
|  
=== Pros{{result|pass}} ===
Manual testing Use Case:
 
* Easy to edit/modify
* Permit anonymous testers
* History roll back, easy recovery
* Multi-testers contribute one case
* Low barriers to entry
* Flexibility
* User can apply for different permission
* Pages with different name space have diff permission. 
* Different name spaces and categories to organize pages.
* Templates designed to fit for different instance.
 
<!-- Details:
* Only one result page for current installation/desktop validation event.-->
 
=== Cons{{result|fail}} ===
 
* Results tracking
* Results querying
* Data statistics
* Simple appearance
* Syntax editing without forms
* Cases without a category existed
* Cases have no 'review' phase
 
 
== Nitrate TCMS ==
 
=== Manual testing Use Case ===


# QE Project/Team Lead assigns feature to be tested
# QE Project/Team Lead assigns feature to be tested
Line 60: Line 39:
# Test Run report available for viewing
# Test Run report available for viewing


=== Writing a Test Plan Use Case===
Writing a Test Plan Use Case:


# QE Project/Team Lead assigns feature to be tested
# QE Project/Team Lead assigns feature to be tested
Line 69: Line 48:
## Add existing Test Case
## Add existing Test Case
## QA Executes Test Run
## QA Executes Test Run
 
|-
=== Pros{{result|pass}} ===
! colspan="2"| {{result|pass|Pros}}
 
|-
| <!-- Pros for wiki-->
* Easy to edit/modify
* Support anonymous feedback
* Integrated with FAS
* Supports a decent API for extracting content and useful for metrics gathering
* History roll back, easy recovery
* Multi-testers contribute one case
* Low barriers to entry
* Flexibility
* User can apply for different permission
* Pages with different name space have diff permission. 
* Different name spaces and categories to organize pages.
* Templates designed to fit for different instance.
<!-- Details:
* Only one result page for current installation/desktop validation event.-->
| <!-- Pros for Nitrate-->
* Tree view showing the current plan, and its parents and children using a tree style layout. It provides the ability to edit both parent and child plans. .
* Tree view showing the current plan, and its parents and children using a tree style layout. It provides the ability to edit both parent and child plans. .
* Email Notification in workflow.
* Email Notification in workflow.
Line 80: Line 75:
* Different status of a Test Run for tracking  
* Different status of a Test Run for tracking  
* More than one tag for a test case
* More than one tag for a test case
 
|-
=== Cons{{result|fail}} ===
! colspan="2"| {{result|fail|Cons}}  
 
|-
| <!-- Cons for wiki -->
* Results tracking
* Results querying
* Data statistics
* Simple appearance
* Syntax editing without forms
* Cases without a category existed
* Cases have no 'review' phase
| <!-- Cons for Nitrate -->
* Users without authentication (Guests) are granted read only permission to Test Cases and Test Plans
* Users without authentication (Guests) are granted read only permission to Test Cases and Test Plans
* multi-testers contribute to one case not supported?
* multi-testers contribute to one case not supported?
* no history roll back
* no history roll back
* permissions for users are not well grouped
* permissions for users are not well grouped
|-
|}


== Must-Have and Nice-to-Have ==
== Must-Have and Nice-to-Have ==

Latest revision as of 10:06, 16 December 2010

Warning.png
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Overview

This proposal analyses our current mediawiki-based system workflow and use cases, list the pro's and con's and compare them with nitrate system. The purpose is to find out what features we Must-Have and Nice-to-have in future TCMS, aka nitrate, and nitrate should be customized bases on these requirements.

wiki-based TCMS VS Nitrate System

Wiki Nitrate
Use cases

General Manual Test Use case：

For each release:

  • Create test plan
  • (Update Release Criteria)
  • Search from categories or Create new test cases
  • Create test result template

Then for each build:

  • Create test result page
  • Use redirect link as current links
  • Send announcement
  • Execute tests and provide test results
  • Summarize the report manually

Manual testing Use Case:

  1. QE Project/Team Lead assigns feature to be tested
  2. QA searches TCMS for Test Plan
  3. QA creates new Test Run
  4. QA Executes Test Run
  5. Test Run report available for viewing

Writing a Test Plan Use Case:

  1. QE Project/Team Lead assigns feature to be tested
  2. QA writes a new Test Plan
  3. QA adds Test Cases:
    1. Create new Test Case
    2. Import XML Test Case
    3. Add existing Test Case
    4. QA Executes Test Run
Pass pass Pros
  • Easy to edit/modify
  • Support anonymous feedback
  • Integrated with FAS
  • Supports a decent API for extracting content and useful for metrics gathering
  • History roll back, easy recovery
  • Multi-testers contribute one case
  • Low barriers to entry
  • Flexibility
  • User can apply for different permission
  • Pages with different name space have diff permission.
  • Different name spaces and categories to organize pages.
  • Templates designed to fit for different instance.
  • Tree view showing the current plan, and its parents and children using a tree style layout. It provides the ability to edit both parent and child plans. .
  • Email Notification in workflow.
  • Runs and cases easily cloned along with more additional options
  • Bug list automatically generated
  • Test run report auto-generated
  • Test cases have reviewing status
  • Different status of a Test Run for tracking
  • More than one tag for a test case
Fail fail Cons
  • Results tracking
  • Results querying
  • Data statistics
  • Simple appearance
  • Syntax editing without forms
  • Cases without a category existed
  • Cases have no 'review' phase
  • Users without authentication (Guests) are granted read only permission to Test Cases and Test Plans
  • multi-testers contribute to one case not supported?
  • no history roll back
  • permissions for users are not well grouped

Must-Have and Nice-to-Have

<<TBD>>

Migration work

<<TBD>>

Retrieved from "https://fedoraproject.org/w/index.php?title=Rhe/tcms_requirements_proposal&oldid=211801"