Mar 14
SNEHA
Do’s and Don’ts of Testing
On 03-14-2019
The following testing problems are common in the sense that they are typically observed:
- Conflict Resolution: Whenever there is any conflict between 'testers & developers' or 'testers & BA' regarding requirement, they can concern with the related person who knows all the requirements or can send query to the customer. If any suggestions/changes found in SRS by testers those should be asked to BA through email. Because if requirements are not clear, testers can not do proper testing.
- Update build while testing: Sometimes, developers upload new build (by uploading files) when testing is in process. This should not happen as this can imapct the tested modules as well. So first let testers complete their testing , let them report all the bugs. Developers should fix those bugs and then only give new release to testers.
- Avoid iteration of testing: Suppose, tester has been reported 'x' no. of bugs, developers should fix all the bugs or atleast 90% of bugs should be fixed, then only release should be sent for re-testing to avoid iteration of testing.
- Bug reporting: Bugs can be discussed orally with developers or team but report them as well in defect tracking tool, so that we can keep track of all the reported, fixed, re-opened, closed..etc bugs.
- Release rejection: Smoke/sanity testing should be done first. If any critical or showstopper bug occurred in the release don't continue with the testing. Reject that release by sending 'Rejection email' to the team. Developers should fix those issues first. Once the release will be stable, then only send release for testing.