{"id":710,"date":"2013-07-18T12:41:19","date_gmt":"2013-07-18T19:41:19","guid":{"rendered":"http:\/\/www.larrylawhead.com\/articles\/?p=710"},"modified":"2014-12-14T17:10:22","modified_gmt":"2014-12-15T00:10:22","slug":"managing-software-quality-assurance-test-rounds-part-i-understanding-the-nature-of-software-testing","status":"publish","type":"post","link":"https:\/\/www.larrylawhead.com\/articles\/2013\/07\/managing-software-quality-assurance-test-rounds-part-i-understanding-the-nature-of-software-testing\/","title":{"rendered":"Managing Software Quality Assurance Test Rounds \u2013 Part One (Understanding the Nature of Software Testing)"},"content":{"rendered":"

Professor Cem Kaner<\/a> J.D., PhD explains the \u201cImpossibility of Complete Testing\u201d in his lecture notes<\/a>. This lecture mathematically demonstrates how impossible it to test all the options of a given set of enhancements. The testing straggly is to identify the areas that are most likely to pose issues and to develop and apply test cases \/ scripts to these areas. Professor Kaner points out that planning is really the development of\u00a0 creating a sampling strategy. Any set of tests that a tester executes can only be a tiny sample of the set that could be run. The goal is to come up with a powerful enough sample to find the most defects.<\/p>\n

He likewise proposes this \u201crule of thumb\u201d.<\/p>\n

    \n
  1. Cover every line of code with at least one test case.<\/li>\n
  2. Include tests for every variable (input \/ output).<\/li>\n
  3. Check wether the variable can handle extreme values and special cases. (If the system can handle extreme values, then it can probably handle simpler ones.)<\/li>\n
  4. Include tests for every data flow or for every pair of variables that can possibly occur.<\/li>\n<\/ol>\n

    Professor Kaner concludes his notes by further recommending the following:<\/p>\n

      \n
    1. Develop the habit of \u201cForward Scanning\u201d. (Anticipate issues.)<\/li>\n
    2. Ongoing extension of testing depth.<\/li>\n
    3. Heuristics for sampling. (Allow the testers to learn how to improve their tests as they test.)<\/li>\n
    4. Holding risk-orientated discussions<\/li>\n
    5. Creating obvious stopping rules<\/li>\n<\/ol>\n

      Here is how I apply these recommendations:<\/p>\n

        \n
      1. Anticipate issues as you put together test strategy.<\/li>\n
      2. Each test round should result in more effective tests.<\/li>\n
      3. Testers should be allowed to improve their tests as they test.<\/li>\n
      4. Keep all stake holders in the loop as to the every changing set of risks during the test round.<\/li>\n
      5. Offer the stake holders exact criteria for a \u201cgo or no go\u201d for testing to be complete. Proceed with their agreement.<\/li>\n<\/ol>\n

        Now that we understand each test cycle contains the risk of wrongly identifying the tests which should be included in the plan, let\u2019s discuss how to identify, manage and report risk.<\/p>\n

        Click her for Part Two<\/a> –\u00a0Assessing Quality Assurance Risk<\/p>\n","protected":false},"excerpt":{"rendered":"

        Professor Cem Kaner J.D., PhD explains the \u201cImpossibility of Complete Testing\u201d in his lecture notes. This lecture mathematically demonstrates how impossible it to test all the options of a given set of enhancements. The testing straggly is to identify the areas that are most likely to pose issues and to develop and apply test cases<\/p>\n

        Read More<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[85,29],"tags":[19,58,57,59,56],"class_list":["post-710","post","type-post","status-publish","format-standard","hentry","category-managing-software-quality-assurance-test-rounds","category-quality-value","tag-larry-lawhead","tag-managing-software-tests","tag-managing-test-rounds","tag-software-test-management","tag-software-testing"],"_links":{"self":[{"href":"https:\/\/www.larrylawhead.com\/articles\/wp-json\/wp\/v2\/posts\/710","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.larrylawhead.com\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.larrylawhead.com\/articles\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.larrylawhead.com\/articles\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.larrylawhead.com\/articles\/wp-json\/wp\/v2\/comments?post=710"}],"version-history":[{"count":7,"href":"https:\/\/www.larrylawhead.com\/articles\/wp-json\/wp\/v2\/posts\/710\/revisions"}],"predecessor-version":[{"id":882,"href":"https:\/\/www.larrylawhead.com\/articles\/wp-json\/wp\/v2\/posts\/710\/revisions\/882"}],"wp:attachment":[{"href":"https:\/\/www.larrylawhead.com\/articles\/wp-json\/wp\/v2\/media?parent=710"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.larrylawhead.com\/articles\/wp-json\/wp\/v2\/categories?post=710"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.larrylawhead.com\/articles\/wp-json\/wp\/v2\/tags?post=710"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}