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

You can find more information about what a Scrum Meeting is and how it’s being administered for ArchivesSpace at: https://archivesspace.atlassian.net/wiki/pages/viewpage.action?pageId=36765732

In brief, it’s a monthly meeting that will be held the first of each month using Google Hangouts.  The first half of the meeting will review the previous sprint while the second half is planning for the next sprint.  This is where testing team members who attend can ask for clarification about how a feature is supposed to work, how to test a feature or bug and/or volunteer to test a feature or bug. 

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)

Ed Busch (buschedw@msu.edu)

Noah Huffman (noah.huffman@duke.edu)

Scott Hanrath (shanrath@ku.edu)

Max Eckard (eckardm@umich.edu)

Robert Lay (robert.lay@unt.edu) 

Chad Conrady (cconrady@mnmilitarymuseum.org)

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.

Due to the variety of issues to test, it is difficult to develop a testing protocol that covers everything.  However, you should be able to follow the guidelines below for most testing assignments:

• When you get your testing assignment, assign yourself as a watcher by clicking on “Start watching this issue” in the right corner(ish) of the JIRA page.

• Test the feature or bug
  • If you don’t know how to test the assigned issue, add a question/comment in JIRA to ask for assistance.

NOTE:  Do NOT click on the Accept or Reject buttons.  The Testing Team will not be the ones who make the final determination as to whether an issue is accepted or rejected.  Instead add your opinion to the comments in JIRA.

• 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