Process of the
Testing:
First the requirements(Say BRD) will be gathered from the client( this will be done by BA), then the BA will give handover about the requirements to the developers and Testers who are going to be involved in the project.
Once the handover is given by BA, then the BRD has to be analysed entirely by the Testing Team. Full document has to be analysed from testing perspective( Like sequence of the tabs, validation messages, Error messages, Mandatory fields of the screen, missing images, missing content etc). If there are any clarifications or the content needed from the client the testing person should send the clarifications mail to the respective BA. For this a separate template can be used by testing team which has the columns like S.No, BRD Name, Section Name, Section No, Tester Name, Clarifications, Remarks etc.(templates will be differed based on the company needs)
Once the clarifications mail are sent to BA, if he/she knows the answer for the queries, immediately they will send the reply mail to the testing person. Otherwise if BA doesn’t know the answers for the clarifications then the particular question should be sent as an email to the client. Once the BRD got signed off from the client, then the tasks will be assigned to both developers and testers on which module needs to be developed and tested.
After the tasks has been assigned, testing team will start creating the scenarios and test cases. Scenarios are the brief summary on what the tester is going to do in the application. Test Cases are the step by step process on how the tester has to do in the application. Once the test cases are created from testing team then the test cases needs to be swapped among the team members for a peer review. For Peer review there should be a separate template can be used from testing team. Peer review comments needs to be mentioned in the template and send it across the team members to update the comments mentioned in the test cases. This is called First Draft test cases. (Test case template also differs based on the company needs)
Once the review comments are incorporated in the test cases all these test cases have to be sent to the test lead. Test lead has to go through the written test cases and if there are any comments he has to mention the comments and send it back to the respective tester. Tester has to update the comments from test lead and send the mail back to test lead. This is called Second Draft Test Cases.
Once the test cases are finalized by the testing team. it should be sent to the client for review. Again if there are any comments from the client it has to be updated in the Test Cases. Signed off test cases are needs to be placed in any Test management tool for future reference.
By this time, developer would have finished the tasks assigned to them and they will release the build to testing team. Tester has to start do the testing by having the already written test cases. So at first smoke testing needs ot be done by the tester. Smoke testing is nothing but a major function testing like application is logging in and able to view all the main modules and has to make sure the application is ready to go for further testing. Then the functionality testing starts with the test cases. IF any bug encountered during the test case execution, then the particular bug has to be raised to the developers. For this any bug tool can be used. Note: If any bug found during smoke testing the respective bug should be sent to the developers immediately as an email and then it can be logged on to the bug tool because only when the bug has been fixed immediately then tester can continue for further execution.
Regression Testing: For ex: In the first build tester has found a bug and raised it to the developer. From dev it has been fixed. After the bug has come to the testing phase then the tester has to rerun the previously completed test cases also and have to make sure that the fix does not arise any other new fault.
Retesting: Retesting is testing only the particular defect raised and not running the already executed test cases.
Bug Life Cycle: Bug Status varies from company to company and also depends on the tool. Commonly used status is New, Open, Assigned, Fixed, Closed, Re-opened, Deferred.
Every day status should be sent by test lead to the Test Manager like how much testing completed, how many bugs reported, how many are in open status, reopen status etc.
First the requirements(Say BRD) will be gathered from the client( this will be done by BA), then the BA will give handover about the requirements to the developers and Testers who are going to be involved in the project.
Once the handover is given by BA, then the BRD has to be analysed entirely by the Testing Team. Full document has to be analysed from testing perspective( Like sequence of the tabs, validation messages, Error messages, Mandatory fields of the screen, missing images, missing content etc). If there are any clarifications or the content needed from the client the testing person should send the clarifications mail to the respective BA. For this a separate template can be used by testing team which has the columns like S.No, BRD Name, Section Name, Section No, Tester Name, Clarifications, Remarks etc.(templates will be differed based on the company needs)
Once the clarifications mail are sent to BA, if he/she knows the answer for the queries, immediately they will send the reply mail to the testing person. Otherwise if BA doesn’t know the answers for the clarifications then the particular question should be sent as an email to the client. Once the BRD got signed off from the client, then the tasks will be assigned to both developers and testers on which module needs to be developed and tested.
After the tasks has been assigned, testing team will start creating the scenarios and test cases. Scenarios are the brief summary on what the tester is going to do in the application. Test Cases are the step by step process on how the tester has to do in the application. Once the test cases are created from testing team then the test cases needs to be swapped among the team members for a peer review. For Peer review there should be a separate template can be used from testing team. Peer review comments needs to be mentioned in the template and send it across the team members to update the comments mentioned in the test cases. This is called First Draft test cases. (Test case template also differs based on the company needs)
Once the review comments are incorporated in the test cases all these test cases have to be sent to the test lead. Test lead has to go through the written test cases and if there are any comments he has to mention the comments and send it back to the respective tester. Tester has to update the comments from test lead and send the mail back to test lead. This is called Second Draft Test Cases.
Once the test cases are finalized by the testing team. it should be sent to the client for review. Again if there are any comments from the client it has to be updated in the Test Cases. Signed off test cases are needs to be placed in any Test management tool for future reference.
By this time, developer would have finished the tasks assigned to them and they will release the build to testing team. Tester has to start do the testing by having the already written test cases. So at first smoke testing needs ot be done by the tester. Smoke testing is nothing but a major function testing like application is logging in and able to view all the main modules and has to make sure the application is ready to go for further testing. Then the functionality testing starts with the test cases. IF any bug encountered during the test case execution, then the particular bug has to be raised to the developers. For this any bug tool can be used. Note: If any bug found during smoke testing the respective bug should be sent to the developers immediately as an email and then it can be logged on to the bug tool because only when the bug has been fixed immediately then tester can continue for further execution.
Regression Testing: For ex: In the first build tester has found a bug and raised it to the developer. From dev it has been fixed. After the bug has come to the testing phase then the tester has to rerun the previously completed test cases also and have to make sure that the fix does not arise any other new fault.
Retesting: Retesting is testing only the particular defect raised and not running the already executed test cases.
Bug Life Cycle: Bug Status varies from company to company and also depends on the tool. Commonly used status is New, Open, Assigned, Fixed, Closed, Re-opened, Deferred.
Every day status should be sent by test lead to the Test Manager like how much testing completed, how many bugs reported, how many are in open status, reopen status etc.
0 Comments