QA process. RFC

[peterMuriuki]

A few thematic bullet points, around how we would like our Qa process to happen, starting from devs identifying the issues that they would like to work on, either from the issues list of ideally from the milestone.

1. What kind of information does the Qa team require to be able to update or anticipate required changes in the relevant automation scripts
   • are the tag release notes enough for e.g. https://github.com/opensrp/web/releases/tag/v2.0.0.
   • Question to QA: does reading the above notes give you enough context to understand how the current deployment is affected.
   • Question to Devs: who is the target audience for the release notes, Currently, we use the pr titles as the release notes.
2. what issues that frustrate the Qa process that can be alleviated from engineering side?
   • A change in selector targets has been mentioned before, i.e. Changes to text have been known to break tests.
3. How do we expect feedback from QA?
   • Probably the easiest part of all this. Issues are re-opened and moved back to pending in the projects. Devs or PM can then triage, and re-assign them to a correct milestone
4. Running the tests.
   • so far this seems to solely fall in the domain of the QA engineers.
   • What about once we have a CI/CD process for running the automated tests.
     - Automated tests failing will probably not stop us from merging prs. This is however subject to ones' best judgement and peer review.
     - QA team will still own the QA process, Identifying, and reporting new and unresolved issues.
5. What github projects should Qa team work with, How do they relate to other GH projects on the repo, guess we need to also to talk to PM

Related links:

• Web tech call [Nov 2 2021] Testing and Mobile Quest demo #866
• [New Feature Request]: Adding automation testing intergrated to GitHub Actions #966