The definition and provision of metadata has proved helpful in a variety of ways during the test development and test execution processes. This document defines a minimal set of metadata elements that can usefully be applied to tests that are intended for publication within a test suite.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
You may email comments on this document to firstname.lastname@example.org with the subject of your email "[comments] Test Assertion Guide" and one comment by email, the publicly archived list of the QA Interest Group.
@@Patent policy ??@@
This document has been produced as part of the W3C Quality Assurance Interest Group (QAIG). The goals of the QAIG are discussed in the QA Interest Group charter. The QAIG is part of the Quality Assurance activity at the W3C.
This document is a preliminary outline for a general guideline for defining and creating test assertions. It is a draft document that does not fully represent the consensus of the group at this time. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as anything other than a “work in progress”. Translations of this document may be available.
This document is a guide to defining and creating test assertions for specifications. Its purpose is to help the reader understand what test assertions are, why create them and most importantly, how to create them. As you will discover, there are no definitive definitions or ways to create test assertions. Achieving a standard way to represent these is not as important as being able to complement a specification with a well defined set of test assertions that can be used later as a starting point for a conformance test suite and that will provide invaluable insights on the meaning of conformance for this specification. We will share with you our experiences in developing assertions, lessons learned, tricks and tools we found helpful, hazards to avoid, and other tidbits of knowledge that may be helpful in crafting test assertions.
This document is organized to appeal to both the novice and those more experienced in creating assertions. The document presents basic definitions, rationale for creating assertions, when to create them, and the steps and principles to follow in order to create them. Throughout the document, we will provide examples and samples to illustrate what is presented. We hope that after using this guide, you will believe in the benefits of test assertions and be ready and able to create your own.
--Can be used as a starting point for developing conformance tests.
--The activity of defining test assertions has also proved very beneficial in helping tighten the loose ends of a specification, something that is better done as early as possible in the standardization process.
Many definitions, depends on your perspective.
Should we include different definitions and their sources or agree on a definition or both?
What are the components that make up a TA - Pre condition, condition, post condition?
What constitutes a TA?
Can be manual, automatically generated, any other ways?
What is the thought process? How do you determine pre and post conditions? How do you break a statement into small testable chunks? What are you looking for?
Apply the following principles when creating TAs:
Examples: ... shall offer A, B, or C, and no others ... occurs one or more times
The following QA Interest Group participants have contributed significantly to this document: