Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Each release will have a release testing coordinator. This can vary from release to release. You will work closely with the Hyrax Tech Lead and Product Owner.

Follow the process outlined in Hyrax Testing and Release Process. As this is a new process, you may find that some sections need adjustment or more detail. 


When release is ready: 

  • Figure out what needs to be tested:

When a release is ready there will be a list of commits that have been merged since the last release. You may or may not understand the implications of these changes for testing. The tech lead (or others) will be able to help you determine what needs to be tested.

Here are some common situations to consider:

Is this a major, minor, or patch release? For major releases we test all the features we can on Nurax across browsers and platforms as well as testing for accessibility. Minor release process is in flux and will likely be determined on a case by case basis. Patch releases will usually happen without your involvement. 

  • Make sure Nurax is updated with the release:

You will hopefully have one or two people that can help get the release on Nurax. Once it's up, update the announcement text so people who may be checking out Hyrax (or documenters) know what they are seeing. 

  • Conduct a preliminary test on Nurax:

Conduct some basic testing to ensure there are not any major problems. (log in, submit a work, edit a work, test the new feature). At this stage you are trying to make sure the release is ready to be tested by the rest of the testing team. This is also a time to work with the PO to make sure new features seem ready to release (user acceptance testing). Any problems you see, document by added issue in Nurax Github and working directly with your Nurax point person or tech lead depending on the release. 

  • Create a testing spreadsheet:

Update the spreadsheet with what needs to be tested for each release.

  1. Browsers/platforms
  2. Accessibility
  3. Update an existing tests if any features change
  4. Add new tests for new feature sets
  5. Remove tests that are not needed
  • Identify testers:

Put a call out to find people to help you test. This could be between 3-10 people depending on the size and scope of the release. You want to try to give them a timeline and a due date. Most testers are busy but able to help out with some notice. Accessibility is particularly tricky to schedule because of limited number of testers, complexity of the test, and timing of the testing. 


Conducting testing:













Stuff you can't test:

There are few things you can't test, like "real time notification" or any email notification feature (like contact us forms!). This is because Nurax is does not have a SMTP server set up and has a particular configuration that might affect your ability to test everything. This is okay, please note anything that you can not test. 





  • No labels