...
Felicity Dykas University of Missouri
Jennifer Bielewski
Apologies
DSpace 7.0 Testathon Planning
- Tim Donohue and Bram Luyten joined the meeting to discuss the testathon.
- Dates and updates on releases / Tim
- Active beta releases have been used to push features out. Beta 5 is the final beta and will include fixes of a lot of bugs.
- March 17 - QA; complete all development, internal testing, review. The group is on track for this. Between March 17 and the test-a-thon testathon the group will be working to prepare the code for the testing. Work is still being done on configuration entities / database.
- April 19 - Begin the test-a-thontestathon. The test-a-thon testathon will last three weeks
- Next week - would like to announce the test-a-thontestathon
- A month after the end of the testtestathon - a-thon - final release. This will depend on the feedback received during the test-a-thontestathon. If large bugs are found, this date could be 2-3 months after the test-a-thontestathon.
- See DSpace 7 working group notes for other dates
- Draft DSpace Release 7.0 Testathon Page
- Discussion about the dates
- Ramadan is from April 13-May 12. The test-a-thon testathon dates are problematic.
- Easter is April 4.
- Tim will take this to the DSpace meeting. It may be possible to push the dates back a week.
- Test-a-thon testathon plans / Bram
- Bram drafted a test plan spreadsheet. He based it on previous test-a-thons testathons and modified it based on new features.
- How DCAT can contribute to tests
- Write new tests
- Test
- Spreadsheet Spreadsheet - has two tabs
- Tab 1: Summary
- Summarizes the state of the execution
- Links to angular IU ad Angular UI and the Rest UI
- Angula Angular UI - important. On second tab this is used to build links which will contextualize for one's own repository. So, tests will not need to be done on a local installation. However, if the local installation includes customized workflows it may be useful to ensure that customisations customizations are not broken.
- Status
- There are tests for each status.
- Some indicate that the status is "not applicable," this means that it is not supposed to work for the first release. It will be scheduled for DSpace 7.1 or 7.2. Attendees agreed that it is useful to retain these in the spreadsheet.
- Date and people testing.
- Colors
- Yellow = something is wrong with the test description. Reviewers can mark the test as being unclear.
- Red = there is a problem with the test and the expected results are not happening. E.g., UI problem.
- Tab 2: Test cases
- Each test has a persona and an account associated with it. There is a password for each account. The password is the name of the software.
- Persona. There is a link for the persona. The link goes to a specific page or homepage.
- Each test has an ID and feature category.
- There is an a column for expected behavior or results.
- Discussion about spreadsheet
- Previous tests had a field for Jira. All agreed that this will still be useful. It is a way for testers to see information on the feature and issues reported. Bram added a column for github, where this information is now stored.
- Comments: Add details about the testing here. The team will follow the comments and will add the information to tickets. Issue templates. These are used by the Team. More data is added than is found in the spreadsheet to all the Team to sort issues.
- Access to spreadsheet. Attendees discussed whether the spreadsheet should be open to all for viewing and editing. Decision: lock content that will not need to be modified and make it editable by all. Bram will make a backup of the original.
- Tab 1: Summary
- Test workflow
- Enter data and name or nickname; enough information so that you can be contacted.
- Add test status.
- Add comments to provide further information.
- If something is tested prior to the test-a-thontestathon, it should be retested, and the information updated. Retesting is needed as the team may have made changes up until the test-a-thontestathon.
- Retesting: The last test and person will be entered here. If re-testing, the original information will be overwritten. The spreadsheet has versioning, so previous entries can be accessed.
- Discussion about workflow:
- Previous tests were different than this one, as the features were familiar to testers. DSpace 7 has new features. DCAT 7 will need help in created scenarios.
- Look at DSpace 7 documentation (though it is not updated)
- Do what you can and add comments to the spreadsheet.
- Contact Tim. He indicated that he will be glad to answer question and to review test scenarios. Ping him on Slack.
- Previous tests were different than this one, as the features were familiar to testers. DSpace 7 has new features. DCAT 7 will need help in created scenarios.
- Other tests
- Invite people to test out installation instructions. Oracle database, etc. These may need to be described on the test-a-thon testathon page.
- Bram will create a video about the test plan.
- How DCAT can contribute to tests
- Write new tests / scenarios
- Test
- Announcements for the Test-a-thon testathon / Jennifer Bielewski (Marketing Group)
- Where to announce?
- DCAT email list
- DSpace email list
- Google group
- IR managers email list (Kimberly)
- Ivy Plus (Gail)
- Canandian Canadian IR managers slack (Mariya)
- User groups (Jennifer can ask Mic to help)
- COAPI (Jere)
- What to announce?
- The test dates
- Where testing is needed. Push this out on Twitter.
- Announcement
- Jennifer will set up a Google doc we and we can all read and comment on the draft announcement.
- Where to announce?
- URLs from related to the meeting:testathon
DCAT news
- DCAT will delay its next user documentation sprint
- Maureen (chair) will send out an email to ask for volunteers to help with the testing
Meeting notes by Felicity