Note: The following checklists are defined in the most generic form, and do not promise to cover all processes that you are required to go through and follow during your work. There may be some processes which are completely missed out from the lists, or it may also contain processes which you do not need to follow in your form of work.
Just Get Started!Check the scripts assigned to you
This is the first and the most important thing to do! There is no specific logic used to assign scripts to testers or who should execute which. But you may come across practices where you will be assigned a script based either on your workload for the day, or your skill to understand and execute it in minimal time. So, make it a point to check your scripts first!
Check the status/comments of the defect in the Test Report Tool
Once you unveil a bug, it’s very important to keep a track of the status of it. This is because you will have to retest the bug once it is fixed by a developer. The general practice is to confirm if any fix to a bug is rendered successful, as it also makes sure that the tester can proceed with other tests, delving into the deeper side of that particular functionality. Sometimes, it also addresses issues related to understanding the functionality of a particular system. For example, a tester registering a defect, which is not an actual bug according to the programming/business logic. In that case, guidance from the developer will help in understanding the mistake made by the tester.
**Click anywhere on a checklist for printing.
Checklist for Executing Scripts
This is a general guidance checklist to be used when executing scripts so that you do not fail or forget an important step. It helps prevent errors from the side of the software tester.
☐ Update the test data sheet with required values, such as user name, functionality, test code, etc.
☐ Use naming conventions defined as testing standards to define a bug appropriately.
☐ Take screen prints for the script executed using naming conventions, and provide test data that you used for the testing. The screen prints will help other testers and developers to understand how the test was executed, and it will also serve as a proof for you. If possible, try to explain the procedure you followed, choice of data, your understanding, etc.
☐ If your team is maintaining any type of tracking sheet, do not forget to update all the tracking sheets for the bug, its status, time and date found, severity, etc.
☐ If you are using a test reporting tool, do not forget to execute the script in the tool. Many test reporting tools require scripts to be executed to start the life cycle of a bug. For example, some test director needs a script to be executed only till the step where the test script fails.
☐ Update the tracking sheets with current status, i.e., the status in reporting tools, etc., if it is required to be updated after you execute the script in the reporting tool.
☐ Check if you have executed all the scripts properly and updated the test reporting tool.
☐ After you complete your day’s work, it is better to do a peer-to-peer review. This step is very important and often helps in finding out missing steps/processes.Checklist for Logging Defects
Test Defects are then supposed to be logged in by the testers, before going for fixation to the developers. This checklist helps ensure you do not forget any crucial steps while logging those defects.
☐ First of all, confirm with your test lead if the defect is valid.
☐ Follow the appropriate naming conventions while logging defects.
☐ Before submitting the defect, get it reviewed by Work Lead/Team Lead.
☐ Give appropriate descriptions and names in the defect screen prints, as per naming conventions.
☐ After submitting defects, attach the screen prints for the defect, on the Test Reporting Tool.
☐ Note down the defect number/unique identifier and update the test tracking sheet with appropriate information.
☐ Maintain a defect log, defect tracking sheet, screen prints, dump folder, etc., for a backup.Checklist for Blocking and Unblocking Scripts
Blocking or unblocking of a script relates to a bug which affects the execution of a script. For example, if there is a bug on log-in screen, which is not allowing anyone to enter the account after entering valid username and password and pressing the ‘OK’ button, there is no way you can execute any test script which requires the account screen that comes after the log-in screen.
☐ Confirm with your test lead/work lead if the scripts are really blocked due to an existing bug.
☐ Block scripts with an active defect (Defect status: New/Assigned/Fixed/Reopen).
☐ Update the current script/defect in the test reporting tool and tracking sheets with the defect-number/unique identifier, which is blocking the execution of the script or testing of the defect.
☐ If a defect is retested successfully, then unblock all scripts/defects blocked by it.At the end of day, send an update mail to your Team Lead/Work Lead, which should include the following:
▬ Scripts executed (Number)
▬ Defects raised/closed (Number)
▬ If any comments are added on defects
▬ Issues/queries if any