Home : Support : Rally 101 Training : Rally 101 QA

Rally 101

Quality Assurance Fundamentals (Rally Team, Program & Enterprise)
Using Rally will enhance your ability as a quality assurance engineer to: 1) Prioritize your work, 2) View the team’s status for the iteration, 3) Create and manage test cases, 4) Signal a failing test case to development, and 5) Log and link defects against a user story. Click on a link to view an animated demonstration of the activity described: Understanding Rally Terminology - Basic overview of Release, Iteration, User Story, Defect, Test Case and Task. Understanding the Rally Interface - The typical pages that you will be using as a quality assurance engineer are 'My Home' and the 'Iteration Status' pages, including the 'Iteration Task Status', 'Iteration Test Case Status', and 'Iteration Defect Status' screens. Additionally, you may refer to the 'Defects & Tests' tab for Defect and Test Case management. Creating Test Cases - There are various methods for generating Test Cases, these include generating a Test Case directly from a User Story, manually creating a Test Case or importing Test Cases via a CSV import. Working on Your Tasks - All team members should be working towards getting Tasks "Completed" and the highest priority Story "Accepted" prior to moving to the next highest priority Story. It is important to update the Tasks you are working on to ensure that the team has an up-to-date view of the Project status. Running Test Cases and Recording Results - You will need to enter results for Test Cases you have run and add error messages or necessary information so development can diagnose the issue properly. Resolving Failing Test Cases - Rally supports a variety of methods to signal to development a failed Test Case, we will assume you “Block” the Card to communicate the status. Regardless of the method you use, you should manage "Major" failing Test Cases within the Iteration. However, you may record a "Minor Fail" for a particular Test Case, meaning the failure is not significant enough to prevent you from accepting the Story but it should be corrected within the Release. Product Management can then schedule the Defect against the failed test to be completed in a subsequent Iteration.

Quality Assurance Fundamentals (Rally Team, Program & Enterprise)

Using Rally will enhance your ability as a quality assurance engineer to:

1) Prioritize your work,
2) View the team’s status for the iteration,
3) Create and manage test cases,
4) Signal a failing test case to development, and
5) Log and link defects against a user story.

Click on a link to view an animated demonstration of the activity described:

Understanding Rally Terminology - Basic overview of Release, Iteration, User Story, Defect, Test Case and Task.

Understanding the Rally Interface - The typical pages that you will be using as a quality assurance engineer are 'My Home' and the 'Iteration Status' pages, including the 'Iteration Task Status', 'Iteration Test Case Status', and 'Iteration Defect Status' screens. Additionally, you may refer to the 'Defects & Tests' tab for Defect and Test Case management.

Creating Test Cases - There are various methods for generating Test Cases, these include generating a Test Case directly from a User Story, manually creating a Test Case or importing Test Cases via a CSV import.

Working on Your Tasks - All team members should be working towards getting Tasks "Completed" and the highest priority Story "Accepted" prior to moving to the next highest priority Story. It is important to update the Tasks you are working on to ensure that the team has an up-to-date view of the Project status.

Running Test Cases and Recording Results - You will need to enter results for Test Cases you have run and add error messages or necessary information so development can diagnose the issue properly.

Resolving Failing Test Cases - Rally supports a variety of methods to signal to development a failed Test Case, we will assume you “Block” the Card to communicate the status. Regardless of the method you use, you should manage "Major" failing Test Cases within the Iteration. However, you may record a "Minor Fail" for a particular Test Case, meaning the failure is not significant enough to prevent you from accepting the Story but it should be corrected within the Release. Product Management can then schedule the Defect against the failed test to be completed in a subsequent Iteration.