Forums/qTest Forums/Knowledge Base

Using qTest: A Case Study

Uy Tran
posted this on June 28, 2012 03:07 am

DivineSolutions Inc. (DSI) is a global computer technology firm that specializes in developing enterprise software solutions, with customers in more than 30 countries. DSI was in the final stage of developing  BestDeals, a Web-based system that provides retailers and vendors in any industry with a communication portal for establishing contracts. The R&D manager of DSI decided to set up a Quality Control (QC) team that would fully test the functionality of BestDeals before officially launching the marketing campaign for this product. Led by Mark Dale, the QC team was made up of 20 members and arranged into three groups: Business Analyst (BA), Tester (TES), and Developer (DEV).  To facilitate this effort, Mark conducted research into issues management tools available on the market, and chose to purchase qTest.
Following is a typical workflow for how qTest would be used for a specific testing event:

  1. In the Test Plan tab, Mark organizes a set of releases, builds, and timeframes, according to the BestDeals project development plan.
  2. In the Requirement tab, the BA lead assigns requirements to each member of the BA group. In response to her assignment, Anna Butler, a BA team member, creates a requirement called “Register vendor account” under the module “Manage Account” and indicates its target release. Comments and relevant attachments are added into this requirement to assist the TES group in designing proper test cases.
  3. In the Test Design tab, the TES group lead establishes test case writing assignments for each group member. According to his assignment, TES group member Kyle Meier specifies a set of test cases and corresponding test steps under the “Manage Account” module.  Kyle then links these test cases to the “Register vendor account” requirement.
  4. In the Test Execution tab, Kyle had earlier created a set of test cycles, test suites, and test runs that were associated with a specific release defined in the Project tab. This helps Kyle effectively organize the test execution process. Kyle imports the above test cases into a test suite to create a set of test runs. He then assigns these test runs to every member in the TES group and schedules the execution plan accordingly.
  5. Kyle notifies members of the TES group, and each team member starts to execute their assigned test runs. As they test, users detect bugs and submit them to the system. Typically, each defect is assigned to a relevant member of DEV group, and each defect is accompanied by a detailed description and supporting attachments.
  6. In the Defect tab, DEV group members query the system to look for their assigned defects. After debugging, they update the resolved defect’s state to “Resolved” and assign it back to the TES group for retesting.
  7. Members of the TES group conduct retesting on the resolved defect. If no problems are found, TES group members will update the defect’s state to “Closed”. They can also change the state of the defects that are not properly debugged to “Reopened” and assign them back to the DEV group to repeat the testing cycle.

At any time during the course of the project, Mark can access the Report tab and examine different types of reports to keep track the overall status of product testing.


workflow.jpg

 

A typical workflow using qTest

 
Topic is closed for comments