Test Design Techniques

-

  • Test conditions are documented in a Test Design Specification. Test conditions should be selected and prioritized.  
               
  • Test cases are documented in a Test Case Specification. Writing a good test case which shows the clear traceability to the test basis (e.g. the requirement specification) as well as to test conditions is of importance.
  • Test procedures are documented in a Test Procedure Specification (also known as atest script or a manual test script). It is important to look at how to translate test cases into test procedures relevant tothe knowledge of the tester who will be executing the test, and we will look at how to produce a test execution schedule, using prioritization and technical and logical dependencies.

Formality of test documentation
  • Testing may be performed with varying degrees of formality.
  • Very formal testing would have extensive documentation which is well controlled, and would expect the documented detail of the tests to include the exact and specific input and expected outcome of the test.
  • Very informal testing may have no documentation at all, or only notes kept by individual testers, but we'd still expect the testers to have in their minds and notes some idea of what they intended to test and what they expected the outcome to be.
Most people are probably somewhere in between.
  • The right level of formality for you depends on your context: 
    • a commercial safety-critical application has very different needs than a one-off application to be used by only a few people for a short time.
  • The level of formality is also influenced by your organization - its culture, the people working there, how mature the development process is, how mature the testing process is, etc.
  • The thoroughness of your test documentation may also depend on your time constraints; under excessive deadline pressure, keeping gooddocumentation may be compromised.



Comments

Post a Comment

Popular posts from this blog

Types of Review

-
A single document may be the subject of more than one review. If more than one type of review is used, the  order may vary.  It is  apparent that none of the following types of review is the 'winner', but the different types serve different purposes at different stages in the life cycle of a document. The main review types:  Walkthrough Technical Review Inspection Walkthrough A walkthrough is characterized by the author of the document under review guiding the participants through  the document and his or her thought processes , to achieve a common understanding and to gather feedback. This is especially useful if people from outside the software discipline are present, who are not used to, or  cannot easily understand software development documents.  The content of the document is explained step by  step by the author, to reach consensus on changes or to gather information.  Within a walkthrough the author does most of the preparation. The participa
Read more

Phases of Formal Review

-
Phases of a formal review In contrast to informal reviews, formal reviews follow a formal process.  A typical formal review process consists of six main steps: Planning Kick-off Preparation Review meeting Rework Follow-up Planning The review process for a particular review  begins with a 'request for review'   by the author to the moderator (or inspection leader).  A moderator is often assigned to take care of the scheduling (dates, time, place and invitation) of the review. On a project level, the project planning needs to allow time for review and rework activities , thus providing engineers with time to thoroughly participate in reviews. For more formal reviews ,e.g. inspections, the moderator always performs an entry check and defines at this stage formal exit criteria. The entry check is carried out to ensure that the reviewers' time is not wasted on a document that is not ready for review.  A document containing too
Read more

Structure Based or Whitebox Testing Techniques

-
Image
Using structure-based techniques to measure coverage and design tests Structure-based techniques serve two purposes:  test coverage measurement structural test case  design.  They are often used first to assess the amount of testing performed by tests derived from  specification-based techniques, i.e. to assess coverage. They are then used to design additional tests with  the aim of increasing the test coverage. Structure-based test design techniques are a good way of generating additional test cases that are  different from existing tests. They can help ensure more breadth of testing, in the sense that test cases  that achieve 100% coverage in any measure will be exercising all parts of the software from the point of  view of the items being covered. What is test coverage? Test coverage measures in some specific way the amount of testing performed by a set of tests . Wherever we can  count things and can tell whether or not each of those things has been tested b
Read more