# December 2, 2021
8:00am Pacific time

In Attendance
-------------

- Chair: (Alec/Wing It)
- Present: Sonya, Alec, Antti-Jussi, Marc, Ronald, Dulip, Andrew
- Regrets: Rondineli

Upgrade Testing Project
-----------------------
- Brainstorming
- Community testing plan for major releases (Alec)
- need to review existing upgrade documentation offline
- Representative (real world) upgrade testing (Alec)
- can test with our own data sets when there's a release candidate for 3.4
- what would be the end result of 3.4 release candidate upgrade? What would we want to report on with a test? Important to document this in detail (maybe this is better to do with first round of testing)
- can include some real-world data in automated testing: existing data set is here: https://github.com/pkp/datasets.
- Real world data would need to be anonymized, or be okay with being published. Can we create a simple tool to anonymize sensitive data? Could also keep data secret(encryption not sufficient for GDPR)
- making copy of files folder is most time consuming step for testing upgrade. Would be great if upgrade process could have dry run that takes into account missing files during upgrade test. Would save time copying all the files. May be unique to 3.3 upgrade and won't be in the future? (Alec can check)
- What can we start working on?
- identify some fast testing - checking before and after stats to see if data lines up.
- "health check" comparing what things should be vs what's actually showing up
- Other tools like nagios can check parameters against constraints (e.g. if they can be extracted via JSON)
- Andrew can pull up some examples
- What about generation of health checks?
- Automatically generate before upgrade, then after
- Requires SQL to generate reports on old DB. Better to document as part of upgrade process?
- Document generation of report on old DB before code upgrade, then compare against fresh report after upgrade.
- Document side-by-side process with old and new (test) upgrade.
- Template for reporting results? Can start with current release - Antti-Jussi can add with current upgrade project. We can collectively tackle this and document our own practices
- Alec willing to share how to write a cypress(?) test

Actions for next meeting:
---------------------------
1. start thinking about "health checks" and fast testing. Andrew can start us off with some examples.
2. Create place to start sharing our own testing procedures and tests (non-judgemental). Sonya can create google doc and share out for everyone to use.

Performance Testing Project
---------------------------
- tabled for next meeting

Other topics
------------
- RS: Where should we store information on non priority topics?
- e.g. I have a use case for data validation for OMP installations
- can create parking lot for tracking our ideas (Sonya)

Next Meeting
------------

- Time/Date:
- January 6, 8am Pacific Time (1st Thursday of the month, 8:00am Pacific time)
- Chair: Marc :) (Chair rotation: Marc, Dulip, Andrew, Rondineli, Sonya, Ronald, Antti-Jussi)
- Agenda items:
- Performance Testing Project
- updates on upgrade testing project