Actually , a good tester should focus on breaking the product and reporting the bugs right from the first release to the final release of the product. Now that is what is called killer attitude !!
However to achieve one's target as a tester, there are Do's and Dont's, which if followed properly can lead to a better testing result.
the Do's:
Do a sanity testing for every new release.
Ensure if all testing activities are in synchro with the test plans and strategy.
Strictly adhere to the input and exit criteria for all testing activities.
Update the test results for the test cases whenever it is run.
Identify areas where you might need technical assistance or trainings during testing. Plan and arrange for these technical trainings to solve this issue.
Strictly follow the test strategies as given in the test plan.
Try getting a release notes from the development team which contains the details of that release that was made to QA for testing. This should normally contain the following
The version label of code under configuration management.
Features part of a release.
Features not part of a release.
Fixed bugs/defects.
New Functionalities/Changes in the release.
Known problems.
Make sure the code is version controlled for each release.
Classify defects (Critical/ High/Medium/Low) in a mutual agreement with the Development team so that defects are fixed within the specified timelines.
However to achieve one's target as a tester, there are Do's and Dont's, which if followed properly can lead to a better testing result.
the Do's:
Do a sanity testing for every new release.
Ensure if all testing activities are in synchro with the test plans and strategy.
Strictly adhere to the input and exit criteria for all testing activities.
Update the test results for the test cases whenever it is run.
Identify areas where you might need technical assistance or trainings during testing. Plan and arrange for these technical trainings to solve this issue.
Strictly follow the test strategies as given in the test plan.
Try getting a release notes from the development team which contains the details of that release that was made to QA for testing. This should normally contain the following
The version label of code under configuration management.
Features part of a release.
Features not part of a release.
Fixed bugs/defects.
New Functionalities/Changes in the release.
Known problems.
Make sure the code is version controlled for each release.
Classify defects (Critical/ High/Medium/Low) in a mutual agreement with the Development team so that defects are fixed within the specified timelines.
the Dont's:
Dont update the test cases while execution of the same is going on. Normally people tend to update the test case based on the look and feel of the application.
Dont spend time in testing the features that are not part of this release.
Dont focus your testing on the non critical areas (from the customers perspective).
Even if the defect identified is of low priority, do not fail to document it.
Never make assumptions while verifying the fixed defects.
Dont update the test cases without running them actually, assuming that it worked in earlier releases. Remember, haste is waste.
Dont focus on many negative paths, which are going to consume lots of time but will be least used by customer.
Dont update the test cases while execution of the same is going on. Normally people tend to update the test case based on the look and feel of the application.
Dont spend time in testing the features that are not part of this release.
Dont focus your testing on the non critical areas (from the customers perspective).
Even if the defect identified is of low priority, do not fail to document it.
Never make assumptions while verifying the fixed defects.
Dont update the test cases without running them actually, assuming that it worked in earlier releases. Remember, haste is waste.
Dont focus on many negative paths, which are going to consume lots of time but will be least used by customer.
No comments:
Post a Comment