General information

• Sprints
  • Each sprint lasts one month
  • Weeks 1-3 of the month = testing by Testing Team
  • Week 4 = the Q/A group tests deliverables of the sprint and indicates which stories are accepted for the scheduled release and which are rejected.
• Three sprints per release
• Community testing of a release candidate occurs during the three weeks prior to each scheduled release
• One release every four months (i.e. three per year)
  • Maintenance releases necessary to address critical bugs may occur independent of this schedule

Schedule

1. Scrum meeting held on the first of every month
2. As soon as possible after Scrum meeting, Testing Team holds meeting
3. Testers comment on issue in JIRA
   1. Can test daily as testing is supported by nightly builds
4. Participate in community testing prior to release if desired (not required)
5. Repeat

Scrum meeting

Variant name: Sprint Retrospective & Planning Meeting

...

As for attendance, the Testing Lead (Miloche) or a designee should attend.  Anyone else is welcome to attend.

Testing Team

Members:

Miloche Kottman (mkottman@ku.edu) (Leader)

...

Public User Interface Enhancement project liaison: Mark Custer (mark.custer@yale.edu)

Meeting

The Testing Team will have at least one meeting a month as soon as possible after the Scrum Meeting to give out testing assignments and to answer any questions about the selected stories, e.g. how should it be tested. 

Testing Website

You can use the hosted website at: http://test.archivesspace.org/ to test or you can download and install your own copy.  New builds will be installed nightly for quicker testing.  (In the past, if an issue was rejected there usually wasn’t time to fix it in the sprint so it had to be moved to the next sprint).

Testing

Testing occurs during the first three weeks of the month.  It is recommended that you test all of your assigned issues at least once during the first week of testing.

...

• If the feature or bug fix worked as expected, add a comment to the issue in JIRA indicating that it worked.
  • If you’re not sure it worked, add a comment describing what happened when you performed the test.  A follow up group (Q/A group) will decide it the story is accepted or rejected.
• If multiple people are assigned the same issue to test, all assignees should comment in JIRA about their experience, even if it’s just to say: Ditto.
• If the feature or bug fix did not work as expected, add a comment to the issue in JIRA indicating that it didn’t work. It’s also a good idea to include the steps you took, the results you received and the result you expected.  Feel free to attach screenshots and/or additional documentation if needed to clarify your results.
• New builds of the test site will be loaded nightly so you should be able to re-test problem issues the next day or so.
• Week 4 of the month
  • The Q/A group will review comments and decided whether the issue is accepted or rejected, i.e. they get to click the buttons.

Community Testing

Three weeks prior to a scheduled release, the ArchivesSpace community will be invited to download and install the candidate release to test.  As members of the community, Testing Team members are welcome to test the new release if desired but don’t forget to also test your assignments from whatever sprint we are working on.

Additional information

Additional information about the splitting out of testing and prioritization can be found at: https://archivesspace.atlassian.net/wiki/pages/viewpage.action?pageId=35749916