The OLE Testing Process in Jira
Outlined below is a brief overview of the OLE testing process. The outline below is more of a summary than a detailed exploration, and is meant to help give a general picture of the OLE testing workflow, and how it fits into the larger scheme of the OLE development cycle.
Feature Development
- An Enhancement (PP) issue is handed off for testing, with the Functional Specification document attached and a complete Acceptance Criteria section in place.
- Testers create Test Cases based on the acceptance criteria in the document.
Coding
- Code is written and submitted one Enhancement (PP) at a time by the developers.
- The code is given an initial review by the development team.
- Completed Enhancements (PP) are moved to "Testing" status, and the related code is imported into the OLE Test Environment as needed.
Code Promotion
- The testers review the Release Documentation on the Kuali wiki to determine if a Task belonging to one of their Stories is ready for testing.
- OLE Releases are divided into release versions. A major release is a new numbered version of the OLE software package, and represents the implementation of a large bundle of new functions and features. A minor release is a bundle of updates and bug fixes released as needed, and marked with a tag rather than a major version number.
- The Demo Environment and official download link are updated only for major release versions (e.g., OLE 0.8, OLE 1.0, OLE 1.5, OLE 2.0, and so on).
- The Test Environment is updated with minor release versions (e.g. r16094, r16528). Updates to the Test Environment occur as needed, when there is a sufficiently stable working version of the code that functional testing can begin.
- OLE Releases are divided into release versions. A major release is a new numbered version of the OLE software package, and represents the implementation of a large bundle of new functions and features. A minor release is a bundle of updates and bug fixes released as needed, and marked with a tag rather than a major version number.
Review of Existing Test Cases
- The testers revisit the OLETS Test Cases relevant to the promoted Tasks or Bug/Defects. The Test Case may need to be revised at this point, especially for Task testing.
- If the functionality to be tested was not previously available, this is the best time for testers to review the process necessary to accomplish the main function described by the Test Case.
- The Test Case must have the following information to be ready for testing:
- A description stating the purpose of the Test Case
- Steps describing the method for executing the test
- A Selenium test script is recorded while the test is being executed.
Testing Outcome
- Results are gathered from testing, and a determination is made as to whether the Test Case should pass or fail.
- Pass
- If the tester is able to successfully execute all testing steps necessary to fulfill the purpose of the Test Case, the test can be considered passed.
- Fail
- If the tester is unable to successfully execute all testing steps required by the Test Case, the test can be considered failed.
- If the tester is able to execute all necessary steps, but the outcome does not satisfy the Acceptance Criteria statement on which the Test Case is based, then the test can be considered failed.
- Pass
- If the test passes, it is automatically assigned to the QA Analyst (Jain).
- If the test fails, it is automatically assigned to the QA Manager (Rich).
- In case of failure, the Task or Bug/Defect associated with the Test Case will be returned to an "in development" status.