-
Notifications
You must be signed in to change notification settings - Fork 8
Testing Strategy
Nils Magne Lunde edited this page Nov 9, 2021
·
1 revision
This document exists to secure a common understanding of how we will ensure quality in the Envis project. The document will be worked on until the team can agree and approve on it, after which more specific test plans will be made.
It defines
- Process of testing
- Testing levels
- Roles and responsibilities of each team member
- Types of Testing ( Load testing, Security testing, Performance testing etc.)
- Testing approach & automation tool if applicable
- Adding new defects, re-testing, Defect triage, Regression Testing and test sign off
- Unit testing
- Component testing -> includes testing for a11y and performance
- Integration testing -> Testing wherever we access API's
- System testing -> SEO, a11y on a higher level, testing multiple screen sizes, etc
- Acceptance testing -> User Stories, definition of done
First of all testing is a responsibility of the team. Everyone should do their part in ensuring good quality and compliance with any rules that may apply.
In addition the following specific responsibilities are defined:
Role | Responsibility |
---|---|
Dev team | - Test for a11y while developing - Use screen readers - Use Lighthouse |
PO | Acceptanse testing - verify functionality to acceptance criteria in user stories |
TBD |
- Define number of requirement and setup required for each environment
- Define backup of test data and restore strategy
- Automation and Test management tools needed for test execution
- Figure out number of open-source as well as commercial tools required, and determine how many users are supported on it and plan accordingly
- Release management plan with appropriate version history that will make sure test execution for all modification in that release
- List all risks that you can estimate
- Give a clear plan to mitigate the risks also a contingency plan
- All these activities are reviewed and sign off by the business team, project management, development team, etc.
- Summary of review changes should be traced at the beginning of the document along with approved date, name, and comment
- Home
- The team
- How we work
- Retrospectives
- GitHub Actions
- Satellite sites
- Redirects
- Groups / Accesses / Sites
- Migrate production data to test
- Guide to upgrading dependencies