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

Roles and Resposibilities for a Formal Review

-
The participants in any type of formal review should have adequate knowledge of the review process. The  best, and most efficient, review situation occurs when the participants gain some kind of advantage for their  own work during reviewing.  In the case of an inspection or technical review, participants should have been  properly trained as both types of review have proven to be far less success-ful without trained participants.  This indeed is perceived as being a critical success factor. The best formal reviews come from well-organized teams, guided by trained moderators (or review  leaders). Within a review team, four types of participants can be distinguished:  moderator author scribe reviewer the management (in addition to the main four roles) The moderator The moderator (or review leader) leads the review process .  He or she determines, in co-operation with the a uthor, the type of review, approach and the composition of the review team.  The mo
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