{"id":20230,"date":"2015-05-28T11:55:14","date_gmt":"2015-05-28T06:25:14","guid":{"rendered":"http:\/\/www.tothenew.com\/blog\/?p=20230"},"modified":"2015-05-28T17:53:56","modified_gmt":"2015-05-28T12:23:56","slug":"some-dos-and-donts-while-designing-test-cases","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/some-dos-and-donts-while-designing-test-cases\/","title":{"rendered":"Some Do&#8217;s and Don&#8217;ts while designing  Test Cases:"},"content":{"rendered":"<p>It is very important for a test engineer to draft good and complete test cases as it shows how comprehensively a test engineer has understood the application requirements.\u00a0 With the following Do\u2019s and Don\u2019ts a test engineer can develop an effective test case with little efforts and save a lot of time.<\/p>\n<p><strong><em>Do\u2019s:<\/em><\/strong><\/p>\n<ul>\n<li>Identify and draft test cases for each unit or component or module<\/li>\n<li>Write test cases with all the mandatory fields such as test case ID, priority, description, execution steps, expected result and actual result<\/li>\n<li>Design more functional test cases<\/li>\n<li>Focus on functional as well as UI aspects<\/li>\n<li>Write execution steps in points so that the steps are clearly readable<\/li>\n<li>Clearly identify the expected results for each test case<\/li>\n<li>Design the test cases as per the workflow of the application<\/li>\n<li>Security is of high priority in web testing and hence document test cases related to the application security.<\/li>\n<li>Create a <a href=\"http:\/\/en.wikipedia.org\/wiki\/Traceability_matrix\">traceability matrix<\/a> to understand the test case coverage with the business requirement documents. Traceability matrix ensures that all test cases are covered and no functionality is missed while testing.<\/li>\n<\/ul>\n<p><strong><em>Don\u2019ts:<\/em><\/strong><\/p>\n<ul>\n<li>Do not write repetitive UI test cases. This will lead to high maintenance since UI will evolve over time.<\/li>\n<li>Do not concentrate on negative paths for user acceptance test cases if the business\u00a0requirements clearly indicate\u00a0 the application behavior and usage by the business users.<\/li>\n<li>Do not fail to get the test cases reviewed by individual module owners of the development team. This will enable the entire team to be in the same line.<\/li>\n<li>Do not leave any functionality uncovered in the test cases until and unless it is specified in the\u00a0test plan.<\/li>\n<li>Do not to write test cases on assumptions. If the requirement is not clear ask development team\/business analyst.<\/li>\n<li>Do not write test cases on error messages based on assumptions. Document error message validation test cases if the exact error message to be displayed is given in the requirements.<\/li>\n<\/ul>\n<p>Every project team\/vertical should follow a standard test case template. Example of a test case template is shown below:<\/p>\n<p><a href=\"\/blog\/wp-ttn-blog\/uploads\/2015\/05\/1.png\"><img decoding=\"async\" loading=\"lazy\" class=\"alignnone size-full wp-image-20231\" src=\"\/blog\/wp-ttn-blog\/uploads\/2015\/05\/1.png\" alt=\"1\" width=\"624\" height=\"103\" \/><\/a><\/p>\n<p>In the test case document prepared by the test engineer, he should also maintain version history and summary in different tabs as shown below:<\/p>\n<p><a href=\"\/blog\/wp-ttn-blog\/uploads\/2015\/05\/2.png\"><img decoding=\"async\" loading=\"lazy\" class=\"alignnone size-full wp-image-20233\" src=\"\/blog\/wp-ttn-blog\/uploads\/2015\/05\/2.png\" alt=\"2\" width=\"404\" height=\"39\" \/><\/a><\/p>\n<p>Thank You!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>It is very important for a test engineer to draft good and complete test cases as it shows how comprehensively a test engineer has understood the application requirements.\u00a0 With the following Do\u2019s and Don\u2019ts a test engineer can develop an effective test case with little efforts and save a lot of time. Do\u2019s: Identify and [&hellip;]<\/p>\n","protected":false},"author":171,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":16},"categories":[1,1816],"tags":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/20230"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/171"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=20230"}],"version-history":[{"count":0,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/20230\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=20230"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=20230"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=20230"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}