...
| Field Name | Old Test Spec Name | How to fill it | Additional Comments |
|---|---|---|---|
| Name | Test case subsection title | Has to be a short string indicating the purpose of the test. | It is recommended to avoid using the requirement name and ID. LDM-639 test cases have been named following the verification elements, and therefore the requirements names, mainly for lack of time. Note that the Test Design is not used anymore and there is no need to have at the beginning of the name an identifier following the previous naming. Old test cases will keep it only for backward compatibility. |
| Objective | Test Items | Describe the scope of the test. The requirement to be implemented can be used as a reference, describe what you are going to test. It may be only a part of the requirement. In some cases, milestones defined in the test plan LDM-503 may drive the scope of the test. | This field will appear in the Test Specification as "Test Items". Avoid including the requirements text. |
| Precondition | Input Specification | This field should include all inputs required to run the test. | This field will appear in the Test Specification as "Input Specifications". For example, the input data required (do not specify versions). The field is provided by the test management plugin in JIRA and can't be renamed. |
| Folder | A Test Specification document will be produced for each folder, including all test cases defined in it. | ||
| Status | When you create a new test case the status is set to "Draft". Once When the Test Specification is approved test case is ready to be submitted for approval, set the status to "Defined". The test cases will not be approved one by one but will be submitted to the CCB for approval (via RFC) within a new version of the test specification. Once the Test Specification is approved the status of the "Defined" the test draft test cases will be moved in status set to "Approved" and the new issue of the document uploaded in Docushare. Once a test case is not valid anymore, its status has to be set to "Deprecated" When you are going to modify approved test cases:
| Do not delete test cases, this may remove important information from the system. The Jira Test Management plugin is not going to enforce a new version when an approved test case is modified. | |
| Priority | Set the priority that you think is more appropriate. By default is set to "Normal". | In the future, this information can be used to prioritize test cases. At the moment is not used. | |
| Component | DM (Data Management) | This field may be useful when filtering across test cases. | |
| Owner | Who is in charge to write and maintain the test case. | In the future, the test case may be executed by a different person, but the owner will not change. | |
| Estimated Time | Fill it in case you have an idea how much time it can take to run the test case, otherwise, let it blanc | ||
| Verification Type | It can be "Test", "Inspection", "Demonstration" or "Analysis". Use the most appropriate type. In general, this should be a "Test". | This information should be derived by the requirement and Verification Element definition. | |
| Verification Configuration | Not required. | It can be used in case a test case shall test a specific configuration of a software product, but this is against the principle that a Test Case should be generally formulated. Specific configurations will be specified during the test run definition. | |
| Predecessor | Intercase Dependencies | This is the list of test cases that need to be completed (successfully) before the actual test case can be executed. | This does not imply that those test cases are part of the test script. Usually, they are not. |
| Critical Event | This field is mandatory but should not be relevant for DM. Therefore set it to "False". | ||
| Associated Risks | This field should not be relevant to DM. Leave it blanc. | ||
| Unit under test | This field should not be relevant to DM. Leave it blanc. | In the future, we may use the components defined in the model in Magic Draw to group test cases, instead of using the folder. | |
| Required Software | Environment Needs - Software | List here the required software packages that are needed to be installed in the system to run the test | In case the test case is to verify the functionalities of a specific DM software package, for example, science_pipeline, this shall NOT be listed here, but in the Objective field, Test items section. |
| Test Equipment | Environment Needs - Hardware | List here the required hardware that is needed to be installed in the system to run the test. This usually implies a server with a specific CPU power, RAM and available disk space. | The exact hardware used for the test will be specified in the Test Plan or the Test Run. This information can be different each time a test case is executed. |
| Test Personel | This field has not been used until now by DM during the definition of the test. Leave it blanc or list here external people that may need to be involved during the verification | These people are not the owner nor the test engineer that is going to run the test. They may be for example stakeholder, that need to assess the scientific results to ensure that the test has passed. | |
| Safety Hazards | This field should not be relevant to DM. Leave it blanc. | ||
| Required PPE | This field should not be relevant to DM. Leave it blanc. | ||
| Postconditions | Output Specifications | Specify here what output is expected from the test. | For example, the output data expected. This field has been called "Postcondition" due to the duality with the "Precondition" field provided by default. |
...
- Open a Jira issue in DM project (who: the person requesting the test)
- Add content to Jira using test cases, test plans and test cycles (who: the Jira issue assignee)
- Create a ticket branch in the Github repository of the document to update (who: the Configuration Release Manager)
- Auto-generate the document from Jira using the tool docsteady (automatic, in a first time the CRManager)
- The autogenerated parts of the document will include all changes implemented in the Jira ATM objects (test plan, test cases, etc). Never edit directly in GitHub, the parts of the documents that are auto-generated from Jira.
- See the above Test Specification and Test Plan and Report descriptions for the detailed list of autogenerated sections.
- Edit the parts of the document that are not generated from Jira, directly in the branch.
- Once all the editing are done, a pull request is created and the Jira issue status is set to "In Review"
- Reviewers will comment and request changes using the pull request
- If comments are accepted, edits need to be done in Jira. If a comment affects a part that is not auto-generated, the changes will be done directly in the ticket branch. Some changes may affect the auto-generation script, docsteady.
- Once the PR is approved, the ticket branch is merged into master.
...