Introduction
Agile Testing is a practice that follows the agile principles and core values. Agile development does not consider testing as an independent phase but an integral part of the software development process. Agile teams follow the whole team model where they build quality-in to the software product continuously.
Testers on the agile teams help the product owners in elaborating the product backlog, defining tests to validate the acceptance criteria and collaborate with the development teams. Jile helps the agile teams in managing the testing process starting from designing test cases, planning them into release and iteration schedules, execute and track the test progress and manage associated defects.
Tests
Tests are formal specifications that validate the features, stories and non-functional constraints. They are defined as set of conditions with the expected outcome. During the backlog grooming process team member help the product owners to identify and document tests. Similar to tasks, tests are also estimated in hours.
Test can be either documented as a single step or a multi-step tests. Single step tests are usually used to document high level business tests and multi steps test are used to document detailed system acceptance tests etc.
All testing activities happens within the iteration boundary. Tests can be used to validate stories and features planned in a current release or iteration schedule or perform regression testing of stories or features completed in previous release or iterations schedules.
Story Testing
When a story is planned in an iteration all its tests and the tests associated with its constraints are automatically planned in the same iteration schedule. During the iteration team members can execute tests and capture the actual results and mark the tests as passed or failed. They can also update the actual consumed effort and estimated remaining effort regularly in the form of worklog.
If a team wants to validate stories belonging to a different team in the same iteration then they can create a test suite in their iteration backlog and import tests from the story.
Whenever the status of a test is updated it is reflected back in the story test progress throughout the iteration.
Feature Testing
Tests associated with features can be planned and executed in an iteration by creating a test suite and importing tests from a given feature. The test suite can contain a sub-set of tests from the feature enabling the feature to be tested partially across different iterations. Whenever the status of a test is updated it is reflected back in the feature test progress throughout the release.
Note : Kanban teams can directly plan and execute tests associated with a story or feature from their Kanban board.
Regression Testing
Regression testing is the process of validating that a recent change has not adversely impacted already completed features and stories.
To test stories that are marked as done in a completed iteration (which is part of an on-going release schedule), a new test suite can be created and tests can be directly imported from the done story.
To test stories that are marked as done in a completed iteration (independent or part of a completed release schedule), they must be first be imported into the product test library from the iterations done pile. Subsequently these tests can be planned into a new iteration schedule by importing from the test library and then be subsequent planned into any new iteration.
Similarly to test features that are done in a completed release schedule and moved to the done pile should first be imported into the product test library and can be subsequent planned into any new release / iteration schedule by importing from the test library.
Any updates to the tests will not be updated in the story or feature test progress and remain within the iteration test suite.
Tests Functions
Product - Test Library
Products Test Library Function helps the teams to manage a library of test suites for the product. A Test Suite is a collection of related test cases which are used to validate product features and stories.
Iteration Backlog - Test Suites
Iteration Backlog - Test Suites Function helps the teams to manage a backlog of test suites planned in an iteration schedule.
Iteration Backlog - Tests
Iteration Backlog - Tests Function helps the teams to manage a backlog of tests planned in an iteration schedule
Tests Attributes and Relationships
| ID | A Unique identifier with a 2 letter prefix and a sequence number in the form of TC###. ( Note : Workspace Admin can customize the prefix ) |
| Title | Brief Title of the Test |
| Description | Detailed Description of the Test |
| Status | Status of the Test |
| Category | Category in which the test belongs to. |
| Type | Test can be of 2 types.
1. Single Step - Test with a single test condition and expected result. 2. Multi Step - Tests with multiple test conditions, expected results and step level status |
| Owner | Test Owner. (Only members of the team to which the story is assigned can be tagged as Test Owner) |
| Tags | Set of labels to group or categorize related tests |
| Planned Effort | Planned Test Effort measured in person hours |
| Consumed Effort | Actual Consumed Effort measured in person hours |
| Remaining Effort | Projected Remaining Effort measured in person hours |
| Total Effort | Consumed Effort + Remaining Effort |
| Entity | DESCRIPTION |
| Test Runs | List of all test runs with execution results |
| Issues | List of all issues associated with this test |
Defects
Product Defect is a condition where the software does not meet the end user need or an error or fault in the software system. These are reported by the customers or end users during the actual usage of the product.
During the defect triage meetings these defects are analyzed and accepted for implementation. Defects are then broken into one or more defect stories, estimated and assigned to execution teams.
During Release planning accepted defects are planned into Release schedules based on the available capacity. It is advisable that certain fixed capacity is always allocated for defect fixes during release planning exercise.
Defect Functions
Product Defects
Products Defects Function helps the teams to manage the list of all product defects identified during production usage.
Product Backlog - Defects
Product Backlog - Defects Function helps the team to manage a backlog of product defects. Defects backlog is an ordered list of Defects needed to be fixed in the product.
Release Backlog - Defects
Release Backlog - Defects Function helps the team to manage a backlog of defects planned to be fixed in a release schedule.
- Create and plan new defects in the release backlog Visualize the flow of defects in the release backlog Track the progress of a defect fixes in the release backlog Rank the Defects within the Release Backlog Split large defects into multiple smaller defects Re-plan Defect fixes into another release schedule
Defect Attributes and Relationships
| ID | A Unique identifier with a 2 letter prefix and a sequence number in the form of DE###. (Note : Workspace Admin can customize the prefix) |
| Title | Brief Title of the Defect |
| Description | Detailed Description of the Defect |
| Severity | The Degree of impact on the software system |
| Tags | Set of labels to group or categorize related Defects |
| Status | Status of the Defect |
| Ready Date | Date on which the Defect was marked as 'Ready' for implementation. |
| Team | Scrum or Kanban team tagged to this Defect |
| Owner | Defect Owner. (Only members of the team to which the defect is assigned can be tagged as Defect Owner) |
| Release Schedule | Planned Release Schedule |
| Component | The software system or component in which the defect was found |
| Found in Version | Version of the software component where the defect was identified |
| Fixed in Version | Version of the software component where the defect was fixed. |
| Entity | DESCRIPTION | Stories | List of all child defect stories | Tests | List of all tests associated with this defect | Issues | List of all issues identified during the defect testing |
Issues
Issues are defects found during in-sprint testing process. Any issue identified during in-sprint testing process are added to the Iteration Backlog and needs to be fixed in the same iteration schedule. During Iteration closure open issues can be converted into a Defect and can be added to the Product Backlog to be fixed in future Release or Iteration schedules.
Similar to Tasks and tests, issues are also considered as work and are estimated in hours. Team members fix any open issues and update the consumed and remaining effort in the form of work-log.
Issues Functions
Iteration Backlog - Issues
Iteration Backlog - Issues Function helps the teams to manage a backlog of issues identified during an iteration . Issues is a condition where the software does not meet the requirement or acceptance criteria.
Issues Attributes
| ID | A Unique identifier with a 2 letter prefix and a sequence number in the form of ISA###. ( Note : Workspace Admin can customize the prefix ) |
| Title | Brief Title of the Issue |
| Description | Detailed Description of the Issue |
| Status | Status of the Issue |
| Severity | Severity of the issue |
| Owner | Issue Owner. (Only members of the team to which the story is assigned can be tagged as Issue Owner) |
| Tags | Set of labels to group or categorize related tasks |
| Planned Effort | Planned Task Effort measured in person hours |
| Consumed Effort | Actual Consumed Effort measured in person hours |
| Remaining Effort | Projected Remaining Effort measured in person hours |
| Total Effort | Consumed Effort + Remaining Effort |
Issue Ageing
State Types Configuration
Fixed State
- Select this state type for that status in your workflow, to which the issue will be moved once it has been fixed by a developer. 'Fixed By', 'Fixed On' and 'Time to Fix' details will be captured when an issue moves to this status. 'Time to Fix' is calculated as the time taken for the issue to reach 'Fixed' state from the time it was created (Time to Fix = Fixed On - Created On).
Verified State
- Select this state type for that status in your workflow, to which the issue will be moved once it has been verified by a tester. 'Verified By', 'Verified On' and 'Time to Verify' details will be captured when an issue moves to this status. 'Time to Verify'is calculated as the time taken for the issue to reach 'Verified' state from the 'Fixed' state (Time to Verify = Verified On - Fixed On).
Reopen State
- Select this state type for that status in your workflow, to which the issue will be moved when it is being reopened after it has been fixed. 'Reopened By', 'Reopened On' and 'Reopen Count' details will be captured when an issue moves to this status.
Done State
- Select this state type for the end state in your workflow. Done Date and 'Turnaround Time' will be captured when an issue moves to this status.
Exclude Weekends and Holidays
-
Jile provides additional configuration to choose if ageing metrics(Time to Fix, Time to Verify, Turnaround Time and Status Wise Time) should be calculated based on working days or calendar days.
Check this checkbox to calculate these metrics based on working days only.Un-check this to calculate the metrics based on calendar days, including all weekends and holidays.
Note: Changing this configuration will reflect for ageing metrics calculated henceforth and will not be applied to metrics already calculated for existing issues.
