...
- Document who is going to test what on the first sheet of the testing spreadsheet. You may want to coordinate a quick call to make sure people are on the same page. Repeat testers will know the drill.
- Give testers a heads up on the process and make sure you communicate when you'd like testing done by. Even a couple hours of someone's time will be very helpful!
- Try not to help people too much, you want to make sure people are going to uncover issues and you might 'know exactly how to do something'. Testers are capturing their problems so we can surface issues. They can comment directly in the spreadsheet.
- Also, try not to assign yourself any tests if possible - you will be very busy during this phase verifying bugs, triaging tickets and helping testers.
*Accessibility testing:
- The timing of accessibility testing is importantant, because you want to make sure you balance a well working systems (no major bugs) and giving time for testers to do their work. These tests are specialized and need people who have an understanding of what to test and how to determine what pass/fail looks like.
*Admin set and Repository Admin issuesset issues:
- Because Hyrax deposits to the last admin set created, you've got to really make sure the test specify what admin set to use depending on what you are testing for. Since part of testing is creating new admin sets (with various settings), you will never really know what is going on with the settings on release, visibility, and mediation there will be. "Default Admin Set" should have no restrictions and can be used for general tests.
Repository Admin testing:
- With the "flippable" features, the Repository Administation test must make sure 1) they announce on Nurax before they test (since they will be turning features on and off) and 2) they return settings to the original settings"
...