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.

Return to Top

Story Development

• A Story issue is handed off for testing, with the Functional Specification document attached and a complete Acceptance Criteria section in place.
• The Story is broken down into Tasks by the development team.
• Testers create Test Cases based on the acceptance criteria in the document.

Return to Top

Coding

• Code is written and submitted one Task at a time by the developers.
• The code for each Task is checked individually by the development team.
• Completed Tasks are moved to "Testing" status, and the related code is imported into the OLE Test Environment in bi-weekly updates.

Return to Top

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 first into Milestones. A Milestone Release is the release of a new numbered version of the OLE software package, and represents the implementation of a large bundle of new functions and features.
    • The Demo Environment and official download link are updated only on Milestone releases.
    • The current Milestone Release is OLE-0.8.0.
  • OLE Milestone Releases are subdivided into Iterations. Iterations are marked with a letter, and are bi-weekly, internal updates to the OLE application for testing purposes. Each Iteration marks the implementation of a large grouping of Tasks and newly resolved Bug/Defect issues.
    • The Test Environment is updated with each Iteration.
    • The current Iteration is OLE 0.8.0-J. (9/7/2012)

Return to Top

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.

Return to Top

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.
• 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.

Return to Top