Saturday, 10 August 2013

Agile QA Best Practices


Step 1: As story reach to you
·          Open the story, change the status on ‘Testing/In Testing’ and assign it to yourself.

·          Investigate the story & read the acceptance criteria thoroughly.

·          If the story doesn't have a check list you should write it (before creation, ask other members of your team maybe it has been already created- (As per your Project Process).

·          Before closing the story, checklist should be reviewed by other member of the team and then attached to the story.

·          You can create various labels such as (‘AutomationToDO, 'ChecklistToDO', 'ChecklistToReview', 'NeedtoTestonUAT' etc.).  This will help the team member to keep the track of the stories and it is easy to search the stories.


Step 2: What next

·          Waiting for the information: Once the story is updated with the additional information, and story is assigned back to you when answered. If the answer is sufficient, remove the flag and continue testing. If new questions appear, perform the described above flow again.

·         Blocked story/issue: Once the blocking defect is fixed (marked as done or Ready for UAT), remove the flag and continue testing.

·         “Re-opened” stories: Once related issues are resolved, the story will be assigned back to you to continue testing.


Step3: Taking Story to conclusion
 The story/defect is waiting for the information from another person (BA or DEV):
·         The story is assigned to the person
·         The proper comment is be added
·         The story is flagged
·         The story status remains unchanged.

The story/defect testing is blocked by the defect (blocker) that isn’t related to your story:
·         The story assignee remains unchanged (you should be still there)
·         The blocking defect is linked to the story (“blocks” or ‘is blocked by’)
·         The proper comment is added
·         The story is flagged
·         The story status remains “In Testing”

 If a defect related to user story is found (one or all acceptance criteria are not satisfied):
·         Enter an Intra-sprint bug and assign it to developer who worked on it. If it's not obvious who worked on the task, assign it to the lead developer or Team lead to triage and assign it to the proper resource
·         Related issues are linked (“relates”)
·         The proper comment is added
·         The status of story is ’Reopened’.

 If a defect is NOT related to user story and all acceptance criteria are satisfied:
·         Enter a bug and assign it to developer
·         Link bug to appropriate epic
·         We do not reopen story with such bugs
·         Story should be moved to next step Ready for Deployment to UAT/DONE
·         Add label ‘Automation-ToDo’ etc.

 If  all acceptance criteria of user story are satisfied:
·         Checklist should be revised and attached
·         All related bugs are fixed
·         The proper comment is added.
·         The status of story is ’Done’ or ‘Ready for Deployment to UAT’ as per your project needs.
·         Log the time spent to work on the user story.

Defect Logging
Step4: Filling ticket
·         Defect should be logged against your project.

·         Summary format should highlight: “Business Flow/Flavor – Page – Sub-page: issue description”.

·         Summary should give all the information about the issue.

·         For browser specific issues Summary should contain browser, e.g. Chrome

·         For regression issues Summary should contact word “Regression”

·         If you’re not able to describe the issue fully in the Summary, please add “see description” to the Summary.

·         If you find any blocker, please investigate the behavior and make sure there is no workaround. If it is possible to avoid the issue by some specific steps, please write the summary mentioning workaround.
Step5: fields to capture:
·         Clear steps to reproduce – if you’re not sure about the steps, please investigate the issue or ask teammates about the help.

·         Expected and actual result (expected should be written first).

·         Attachments, where appropriate. In case of seeing stack trace error, please add .txt, .doc file with the error text, not the snapshot.

·         Enter the information related to environment on which you encounter the issue mentioning the build no.

·         Notes if there is anything additional you want to let people now.

·         Associate with the current sprint or if it is intra-sprint defect log it accordingly.

·         Write the detail steps if work around is present.

·         Defects should be associated / related to the corresponding user story. If there is no story, e.g. the issue is regression, if there is story related to regression then associate it else skip it.

·         Defects should be linked to the mentioned epics corresponding to the project. If you’re not sure where to link, please ask QA mates to help. If there is no epic for your issue check with your team mates.

No comments:

Post a Comment