# QA Guidelines
# Intro
Quality Assurance can help Scrum teams to clarify the goal and stay on track to actually reach that goal without too much deviation. It also helps clarify the responsibilities of every role involved in the product development lifecycle. Defining a clear way of doing things, no matter it is about development, handling issues or setting up proper monitor and control mechanisms will reduce the risk of making the same mistakes again later on or when approaching a new project. When there's a clear, measurable, path to the goal you're trying to achieve it's easier to observe when things are not going as planned. Any deviation will be noticed before it turns into an issue and improvements or counter-measures can be taken on time if necessary. It is a failsafe mechanism, a fuse box that can prevent or drastically limit the damage that could happen in some cases.
In the development, process PLUSTEAM uses the agile methodology SCRUM combined with BDD & TDD for QA purposes.
# Sprint QA Plan
In every Project Sprint (Milestone) the QA team must participate to guarantee that every story (GitLab Issue) is done successfully, for this the QA must review it and test it.
To have total control of the project, the main branches must be protected by the Project Managers and each issue finished must pass the Code Review. Every done story (GitLab Issue) must contain the Unit Test ready to QA can make the Behavior Tests with all the other issues.
In case of a story (Gitlab Issue) don't pass the tests, it's important to add basic comments about the test (Browsers, Steps, etc), otherwise when a test is unsuccessful, must be commented it with full BUG description or Improvement and open the story (GitLab Issue) to notify to developers responsible.
# Code Review
The Code Review is a technique used to avoid errors and ensure all team is following the same development guidelines.
Every single story (Gital issue) must create a merge/pull request and mark the open issue with the tag Ready for Test assigned to the Project Manager or QA of the team. Then the team and QA/Project Manager participate into review the issue source code, evaluating some aspect as if the code is legible for others, follow the development guidelines, can be improved and don't contain errors. To pass a Code Review at least half of the team must qualify positively the issue and the QA or Project Manager decide if the issue is ready for merge else the development must resolve the discussions of the issue.
Once an issue has the positive votes of the team and passes the QA tests, the issue must be merged deleting the branch and must be marked with the tag Reviewed and Tested if it contains automated tests.
Example:
In this board, the story (GitLab Issue) "Implement Motion/Animations on +Landing Sections Part 2" is opened with the label Ready for Test, this issue must have a merge/pull request related that can be tested and verified for the team using Code Review technique.
In this merge/pull request we can see that was approved for 2 of the 3 members of this project. The Project Manager was assigned and merged the issue and put the only tag Reviewed because this issue doesn't have automated tests
# Roles
Developer (TDD): The Developer Team must make a Unit Test for each piece of code wrote (issue).
QA / Project Manager (BDD): The QA Team must make the Behaviour Test of all these issues by each milestone.
# Issues and Merge/Pull request States
Possible states are shown in the following image
