QA Retrospective 03.05 - 05.05

[MilanVojnovic95]

QA Retrospective

Why retrospective?

• Enhance QA crew performance and increase the transparency of the project processes.
• Which tasks did the QA team cope with successfully?
• Which task execution was not effective? Which issues can be tackled?
• What we should start doing, stop doing, keep doing, do more of or less of.

Some of the challenges:

• Onboarding
• Establishing QA environment
• Automation tests

The Goal:

• To ensure the quality of the dapp under development.

What went well:

• Established QA environment at Swapr
• Old documents reviewed and improved
• Planned and written manual regression tests
• Test Plan Written:
   - 30 test scenarios
   - 60 test cases
• Consistent testing and retesting of PRs
• Automation-test framework configuration and setup
• Written smoke/regression automated tests
• Written a Test Plan with Test Cases that describe a set of steps, conditions, and parameters required to check the implementation of the whole part of a testing function.
• More advanced Test Suites have been written for:
   - Adding liquidity
   - Creating campaign
   - Swap
   - Wrap
   - Changing network
• Performing manual functional testing on PR
• Improved development process by adding DOD

What could we do better:

• Better monitoring of the work and status of the tickets on Zenhub
• Improve automated tests
• Dedicate more to non-functional testing ( performance and document testing )
• Write an onboarding doc in such a way that any of the new contributors can be easily handled

What has been done so far

Automation test plan

We use the automation test plan mainly to write test cases where we look to cover as many steps and expected results as possible. Each test case or scenario has its ID so that we can easily track in the code what has been done or find out if a particular test needs a change or improvement. Due to the detailed descriptions and links by an ID between the test plan and the code, it is easy for other community members to review or a new member to onboard because we have covered most of the features on Swapr.

Manual regression test plan

We use the manual test plan in almost every manual PR test, this doc plays a big role in the first PR test as well as after the bug fixing and in the final part when the release takes place. There are shorter and longer versions depending on whether the whole system or just a certain component is being tested. It can also be used when onboarding a new contributor.

QA process

1. Execute Tests and Report Defects

Manual tests are run in accordance with previously designed test cases. All bugs detected are written in the comment section on PR. Additionally, the launch of automation tests where bugs are detected or it is noted what should be updated in the test to keep up with the new feature.

2. Run Re-Tests and Regression Tests

Once bugs have been found, submitted, and fixed, QAs test the functions again to ensure that they didn’t miss any anomalies. They also run regression tests to verify that the fixes have not affected the existing functions.

3. Run Release Tests

Once developers issue a release notification that details a list of already implemented features, fixed bugs, recurring issues, and limitations, the QA team must identify the functionalities being affected by these changes. Then, the team must design modified test suites that cover the scope of the new build.
The QA team must also perform smoke tests to ensure each build is stable. If the test passes, then modified test suites are run, and a report is generated at the end.

Miro presentation

[niemam29]

Great job getting all this together!