{"id":31,"date":"2019-03-14T09:14:57","date_gmt":"2019-03-14T09:14:57","guid":{"rendered":"https:\/\/epicomm.net\/web\/blog\/?p=31"},"modified":"2025-12-02T06:03:28","modified_gmt":"2025-12-02T06:03:28","slug":"dos-and-donts-of-testing","status":"publish","type":"post","link":"https:\/\/epicomm.net\/web\/blog\/dos-and-donts-of-testing\/","title":{"rendered":"Do&#8217;s and Don&#8217;ts of Testing"},"content":{"rendered":"<p><span><span><span style=\"font-size: medium\">The following testing problems are common in the sense that they are typically observed:<\/span><\/span><\/span><\/p>\n<ol>\n<li><span><span ><span style=\"font-size: medium\"><strong>Conflict Resolution:<\/strong><\/span><\/span><\/span><span><span ><span style=\"font-size: medium\"> Whenever there is any conflict between &#8216;testers &amp; developers&#8217; or &#8216;testers &amp; BA&#8217; 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.<\/span><\/span><\/span><\/li>\n<\/ol>\n<ol start=\"2\">\n<li><span><span ><span style=\"font-size: medium\"><strong>Update build while testing: <\/strong><\/span><\/span><\/span><span><span ><span style=\"font-size: medium\">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.<\/span><\/span><\/span><\/li>\n<\/ol>\n<ol start=\"3\">\n<li><span><span ><span style=\"font-size: medium\"><strong>Avoid iteration of testing:<\/strong><\/span><\/span><\/span><span><span ><span style=\"font-size: medium\"> Suppose, tester has been reported &#8216;x&#8217; 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.<\/span><\/span><\/span><\/li>\n<\/ol>\n<ol start=\"4\">\n<li><span><span ><span style=\"font-size: medium\"><strong>Bug reporting:<\/strong><\/span><\/span><\/span><span><span ><span style=\"font-size: medium\"> 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.<\/span><\/span><\/span><\/li>\n<\/ol>\n<ol start=\"5\">\n<li><span><span ><span style=\"font-size: medium\"><strong>Release rejection:<\/strong><\/span><\/span><\/span><span><span ><span style=\"font-size: medium\"> Smoke\/sanity testing should be done first. If any critical or showstopper bug occurred in the release don&#8217;t continue with the testing. Reject that release by sending &#8216;Rejection email&#8217; to the team. Developers should fix those issues first. Once the release will be stable, then only send release for testing. <\/span><\/span><\/span><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"<p>The following testing problems are common in the sense that they are typically observed: Conflict Resolution: Whenever there is any conflict between &#8216;testers &amp; developers&#8217; or &#8216;testers &amp; BA&#8217; 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 &hellip; <a href=\"https:\/\/epicomm.net\/web\/blog\/dos-and-donts-of-testing\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Do&#8217;s and Don&#8217;ts of Testing&#8221;<\/span><\/a><\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-31","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/epicomm.net\/web\/blog\/wp-json\/wp\/v2\/posts\/31","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/epicomm.net\/web\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/epicomm.net\/web\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/epicomm.net\/web\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/epicomm.net\/web\/blog\/wp-json\/wp\/v2\/comments?post=31"}],"version-history":[{"count":6,"href":"https:\/\/epicomm.net\/web\/blog\/wp-json\/wp\/v2\/posts\/31\/revisions"}],"predecessor-version":[{"id":63,"href":"https:\/\/epicomm.net\/web\/blog\/wp-json\/wp\/v2\/posts\/31\/revisions\/63"}],"wp:attachment":[{"href":"https:\/\/epicomm.net\/web\/blog\/wp-json\/wp\/v2\/media?parent=31"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/epicomm.net\/web\/blog\/wp-json\/wp\/v2\/categories?post=31"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/epicomm.net\/web\/blog\/wp-json\/wp\/v2\/tags?post=31"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}