Important Note: The images seen on this page are meant as general examples, and differences might appear depending on the assignment! Likewise, the format of the Bug Verification Invitation might be different, depending on the test.
What is a Bug Verification cycle?
A Bug Verification cycle is a bit different from a regular Test Case execution cycle.
Instead of executing the steps of a Test Case in order to establish a Pass or Fail status, for a Bug Verification, the scope is to execute the ‘Steps to reproduce’ of a specific Bug, to see if it can be reproduced again in the given circumstances.
If you have not participated in any Bug Verification cycles, and you are not sure how to proceed, please feel free to read the below instructions for more information.
Check the information from the Invitation Email and confirm your participation
1. Open the invitation email and check the information
Pay extra attention to the following elements:
- The Assigned device & environment
- Each assignment has to be completed on the correct device or using the specific requirements mentioned in the invitation email.
- This may include the device to test on, browser, language, connection type, mobile network, build version, etc.
- Important: If you don’t have the device mentioned in the invitation, have updated the OS to a different version, or no longer meet the specific requirements, please let the Test Manager know by replying to the invitation email (using the “Reply all” function
- Deadline
- In order to be eligible for payment, you will have to finish the Bug Verifications before the deadline. If you have any problems or questions, please contact the Test Manager by replying to the invitation email. Please use the “Reply all” function or raise a ticket via Zendesk detailing the situation.
- Any Special Instructions regarding the task
Examples of email invitation types:
- Please note that currently, there are two types of invitations, as seen below:
2. Confirm your participation by replying to the email using the “I want to join the test!” button or the “Reply all” function
- Once you have verified that you are available, have access to the assigned device/environment, and can perform the assignment by the deadline outlined, you must Confirm your participation by using the “I want to join the test!” button or by replying to the invitation (with the“Reply all” function if there is no button in the email)
- This step is very important - if we don’t receive your confirmation in a couple of hours, you will be replaced with another tester!
- Once you confirm your participation, you can start testing right away; you don’t have to wait for any other confirmation email.
- If you cannot participate for any reason, then please use the “I can’t take part” button or reply to the email notifying us that you are not available so we can assign the task to another tester.
Check the testing instructions
1. Before you start testing, make sure to thoroughly read the Tester Specification document
- The Tester Spec can be found in the invitation email, by accessing the Test Cycle page link
- This document contains all the details about the project: info about the app/website under test, the scope of the test, the link to the app, etc.
- It’s important to note that for Bug Verification cycles, the Bug Tracker will not be linked in the Tester Spec, since reporting bugs is out of scope. Any issues reported during a Bug Verification cycle will be rejected (unless otherwise instructed).
Please make sure to read the Tester Spec very carefully before you start to execute the Bug Verification and familiarize yourself with the testing instructions, the scope of the test, and any requirements related to the application/website under test!
2. Access your assigned Bug Verification document
- Your assigned BV document can be found in the invitation email, by accessing the Bug Verification document link.
- Work only on the document provided. Do not create any copies and do not modify any of the information that is already present in the document!
- Note: Some BVs have a different format than the BV document example on this page. The most common format for our BVs is the one exemplified below, but sometimes you may receive a BV in a slightly different format (more details in the next section).
Legend:
- Device + OS version & Browser cells (header): you will have to add the details of the device used for the test, usually assigned to you in advance and mentioned in the email invitation.
- Issue Summary: The Issue Summary will include the Summary of the Bug that has to be tested. No actions are needed.
- Actual/Expected (Results): In this column, you will find the issue that was observed while following the ‘Steps to Reproduce' as well as the intended behavior that should be observed.
- Steps to reproduce: In the “Steps to reproduce” column, you will find the steps you have to perform in order to reproduce the Bug.
- Credentials/Connection/etc: In case of Bug Verification tests, you might have some columns with additional information. This information must be respected, as it is very important to try and reproduce the Bug as accurately as possible.
- Reference Video/Screenshot of the issue: In this column, you will have an attachment that will show the way the Bug occurs. You can use these attachments as a reference, in order to check if the Bug can be reproduced the same way, or not. Do not change/remove/edit the attachments in this column under any circumstance!
- Status: You will have to select a status based on the outcome observed. There are 2 options to choose from: ‘Reproducible’ or ‘Not reproducible’. ( ‘Blocked’ is a third option in some exceptional cases, as stated below)
- Tester Comment: In this section, you will have to elaborate on your observations while trying to reproduce the Bug (i.e. The issue occurs differently, the bug can be reproduced only on the second try by doing xyz, etc)
- Attachment URL (Required for ‘Reproducible’): You will have to add an attachment ONLY for ‘Reproducible’ bugs (or in instances where a blocker is encountered)
- Unless specified otherwise in the Tester Spec
- Note: Attachments must be added ONLY as TesterWork URLs
How to Complete the Bug Verification Document
General Info
- Before beginning the execution, read the test case instructions (Steps to Reproduce & Expected Results) to gain a basic understanding of each individual Bug; You can also view the provided attachments, in order to see how the Bug was observed to occur.
- Start following the Steps to Reproduce instructions and check if the Bug can be reproduced or not, by following the provided instructions
- Select a Status based on the Actual and Expected Results and add the relevant information where needed, especially for ‘Reproducible’ Bugs ( Attachments, and Your observations and remarks))
Bug Verification Status instructions
There are 2 statuses: ‘Reproducible’ or ‘Not reproducible’; In instances where you are unable to check a bug due to another issue occurring, you can also select the ‘Blocked’ status.
You will have to select the correct status for every Bug based on the Actual and Expected Results:
‘Not reproducible' status
- If you have followed all the instructions from the Steps to Reproduce column and found that the Actual results and the Bug in the attachment no longer occur, then the status can be set to ‘Not reproducible’.
- You don’t have to add Attachment URLs for ‘Not reproducible’ bugs (unless instructed otherwise in the Tester Spec document)
Example of ‘Not reproducible’ Bug:
'Reproducible' status
- If you have followed all the instructions from the Steps to Reproduce column and found that you could reproduce the Expected Results it means that the bug is ‘Reproducible’.
- Important: All ‘Reproducible’ Bugs must have an Attachment URL and a Comment elaborating the details and circumstances of the reproduction.
- Follow these steps in the case of Reproducible Bug:
- Status: Select the ‘Reproducible’ status
- Attachment URL: Add the attachment for the Reproducible Bug (Attachments must be added ONLY as TesterWork URLs)
- You can use THIS guide, in case you are not sure how to upload attachments to TesterWork
- Tester Comment: Mention the circumstances in which the Bug was reproduced, or give any details that might be useful in reproducing it again (in case the steps are a bit different)
Example of Reproducible Bug:
‘Blocked’ status
- If you can not execute the instructions from the Steps to Reproduce column due to an issue that prevents you from following the mentioned steps, then mark the Status as ‘Blocked’
- Example: The Steps instruct you to access the “Favorites” tab in order to interact with a Favorite track, but every time you try to open the tab, the app crashes. In this case, the Status will be ‘Blocked’ as you are unable to proceed as instructed in the Steps.
- Important: All ‘Blocked’ bugs must have an Attachment and a Tester Comment
- Follow these steps in the case of ‘Blocked’ bugs:
- Status: Select the ‘Blocked’ status
- Attachment URL: Add the attachment for the Blocked bug (Attachments must be added ONLY as TesterWork URLs):
- In order to add an attachment, you will have to record the behavior on your device and upload the screenshot/video on your TesterWork profile page (Attachments section), copy the generated URL and paste it into the BV document
- You can use THIS guide, in case you are not sure how to upload attachments to TesterWork
- Tester Comment: Mention the actual result encountered after following the Steps to Reproduce
Important notes for ‘Blocked’ bugs:
- DO NOT add more than 1 attachment link in the ‘Attachment URL’ cell
Example of a ‘Blocked’ Bug:
Do’s and Don'ts
Do’s
- Make sure to always confirm or decline your participation in the test case by replying to the invitation, either by selecting the proper button OR by using the “Reply All” option (if there are no buttons in the invitation)
- Before you start testing, make sure to thoroughly read the Tester Specification document
- Before beginning the execution, read the Bug Verification instructions (Steps to Reproduce & Expected Results) to gain a basic understanding of each individual Bug
- Add all the required details in the document when needed (especially for the Reproducible Bugs)
- Work only on the document shared with you in the Invitation email.
- You are allowed to edit ONLY the following fields:
- The TOP rows where you might be requested to add some information about the device, OS, browser version, etc. used in the current test
- The columns:
- Tester Comment
- Attachment URL (Required for Reproducible Bugs)
- Complete the task before the deadline
- Complete the BV following the instructions from this page + Tester Spec instructions
- If you receive a request from a Test Manager for your execution please make sure to answer that request
- If you have any questions or if you have any kind of trouble in regards to the test case execution, reach out to the Test Managers by replying to the invitation email (Reply All)
Don'ts
- Do not test on other devices than the one assigned to you in the Email Invitation (unless instructed otherwise by a Test Manager)
- If you confirmed your participation, please do not abandon the execution as this may result in you receiving fewer invites in the future
- Take your time with the test scenarios and do not rush through them. One step at a time.
- If Attachments (videos/screenshots) are needed, make sure to record only the BV flows. Do not record the Tester Spec, BV document, email invitation, personal information, etc.
- If Attachments (videos/screenshots) are needed, do not upload G-Drive links or any other cloud service - all Attachments have to be uploaded as TesterWork URLs
- Do NOT edit any of the following columns:
- Issue Summary
- Actual/Expected
- Steps to Reproduce
- Reference video/Screenshot of the issue
- Credentials/Connection/etc (any columns describing the additional information columns found before the ‘Status’ column)
Comments
0 comments
Article is closed for comments.