A plan for executing testing on an artifact or specifications. A plan for executing testing on an artifact or specifications. If the element is present, it must have either a @value, an @id, or extensions An absolute URI that is used to identify this test plan when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which an authoritative instance of this test plan is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the test plan is stored on different servers. A formal identifier that is used to identify this test plan when it is represented in other formats, or referenced in a specification, model, design or an instance. The identifier that is used to identify this version of the test plan when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the test plan author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence. Indicates the mechanism used to compare versions to determine which is more current. A natural language name identifying the test plan. This name should be usable as an identifier for the module by machine processing applications such as code generation. A short, descriptive, user-friendly title for the test plan. The status of this test plan. Enables tracking the life-cycle of the content. A Boolean value to indicate that this test plan is authored for testing purposes (or education/evaluation/marketing) and is not intended to be used for genuine usage. The date (and optionally time) when the test plan was last significantly changed. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the test plan changes. The name of the organization or individual responsible for the release and ongoing maintenance of the test plan. Contact details to assist a user in finding and communicating with the publisher. A free text natural language description of the test plan from a consumer's perspective. The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate test plan instances. A legal or geographic region in which the test plan is intended to be used. Explanation of why this test plan is needed and why it has been designed as it has. A copyright statement relating to the test plan and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the test plan. The short copyright declaration (e.g. (c) '2015+ xyz organization' should be sent in the copyrightLabel element. A short string (<50 characters), suitable for inclusion in a page footer that identifies the copyright holder, effective period, and optionally whether rights are resctricted. (e.g. 'All rights reserved', 'Some rights reserved'). The category of the Test Plan - can be acceptance, unit, performance, etc. What is being tested with this Test Plan - a conformance resource, or narrative criteria, or an external reference... A description of test tools to be used in the test plan. The required criteria to execute the test plan - e.g. preconditions, previous tests... The threshold or criteria for the test plan to be considered successfully executed - narrative. The individual test cases that are part of this plan, when they they are made explicit. A plan for executing testing on an artifact or specifications. A textual description of the criterium - what is needed for the dependency to be considered met. Predecessor test plans - those that are expected to be successfully performed as a dependency for the execution of this test plan. A plan for executing testing on an artifact or specifications. Sequence of test case - an ordinal number that indicates the order for the present test case in the test plan. The scope or artifact covered by the case, when the individual test case is associated with a testable artifact. The required criteria to execute the test case - e.g. preconditions, previous tests. The actual test to be executed. The test data used in the test case. The test assertions - the expectations of test results from the execution of the test case. A plan for executing testing on an artifact or specifications. Description of the criteria. Link to predecessor test plans. A plan for executing testing on an artifact or specifications. The narrative description of the tests. The test cases in a structured language e.g. gherkin, Postman, or FHIR TestScript. A plan for executing testing on an artifact or specifications. The language for the test cases e.g. 'gherkin', 'testscript'. The actual content of the cases - references to TestScripts or externally defined content. A plan for executing testing on an artifact or specifications. The type of test data description, e.g. 'synthea'. The actual test resources when they exist. Pointer to a definition of test resources - narrative or structured e.g. synthetic data generation, etc. A plan for executing testing on an artifact or specifications. The test assertion type - this can be used to group assertions as 'required' or 'optional', or can be used for other classification of the assertion. The focus or object of the assertion i.e. a resource. The test assertion - the expected outcome from the test case execution.