4. QA Documentation - Tivix/cpf GitHub Wiki
1. Test Strategy
The main goals of testing are:
- validate the functionality of the software to ensure it meets the specified requirements and works as intended,
- identify and eliminate defects and errors that could negatively impact the software’s performance and stability,
- ensure the software is user-friendly and intuitive, offering a positive and satisfactory user experience,
- reduce the overall development and maintenance costs by detecting and fixing issues early in the development process.
Project/Sprint timeline:
Currently we are working using Kanban board.
Lifecycle of Tasks:
Our board consists of 6 columns -> No Status, Todo, In Progress, In Review, In Testing, Done.
No Status
-> it is a kind of backlog, where all task's drafts belongs. Every member can create a ticket.
Todo
-> all task here are ready to do. Most of the time (except bug tickets, this one is mostly QA responsibility) PM is the one who decides what is ready to do
In Progress
-> if task is in progress that means Dev is working on it. Assigned Dev moves task from TODO to In Progress.
In Review
-> when task is in this column it means that PR is ready to merge or is still in code review process. Assigned Dev moves task from here to In Testing after code review and PR Merged. We do have some automation, so once PR is merged ticket should close itself and move to In Testing.
In Testing
-> after PR is merged, task is being moved to this column, here QA tests new functionality and make sure it meets requirements and there are no critical bugs.
Done
-> here lies task which ended it's lifecycle, meaning all requirements are implemented and it is tested and there are no issue with it. By default QA will move ticket to Done.
Test Approach:
As for today we only do Manual testing. Maybe in the future we will incorporate Test automation.
Testing Types:
For now our main type is Functional testing with some Usability testing.
Testing Tools:
Manual testing leveraging dev tools in a browser.
Hardware-Software Configuration:
Mainly used browser is Chrome (latest) on Mac OS (also latest).
2. Bug Reporting
When reporting a bug we should stick to below template:
Title: [BUG] Area of app - short description
Steps: Add steps to reproduce our bug.
Actual result: How bug looks like with short description and preferably screenshot.
Expected result: Description of how fixed version should look like with preferably link to figma or screenshot from figma (designs).
Relates to: Link to User Story with this feature (if applicable).
Example: