Test Results Information Model
The following is the proposal for the information model (i.e. required bits) for test results and tooling used in the badging.
Parameter | Status | Description |
|---|---|---|
For each budge submission This information would be collected from the submitter, when the results are submitted for review to the program. A likely approach will be use of a template in the merge request comment, that makes the specific fields clear to the submitter. | ||
Applicant Information | Mandatory |
|
Badge Information | Mandatory | The following are "pick from list" type values, where there are only specific values allowed, i.e. the in-force program / badge types and releases.
|
For each set of results generated | ||
Results ID | Mandatory |
|
Test Tool Details | Mandatory |
|
SUT Information | TBD |
Notes:
|
For each test case included in submitted results | ||
Test Case ID | Mandatory |
|
Requirement ID | Optional |
|
Test Case Result | Mandatory |
|
Test Execution Log | TBD |
|
Comments
On Item 6 and Item 7, the things I don't like about those, is if the tool is generating these results, it means the tools have to update with each badge, to internalize the badge ID and the requirements. It might be easier if those are external review tools, that can verify a set of results meets requirements for badge A or B.
Hi Olivier, pls find my inputs
#3. As part the test execution, test cases produces the logs. This part is modelled for capturing this info
#4. Public URL for the CNF product page
#5. The tool used for testing the CNF testcases such as ONAP VTP.
Thanks @Kanag.
#3 - Ok, but is there any expectation of what is contained in the log? We are creating a common information model that says a log should be included. Is that enough, or do we expect certain information in those logs?
#4 - AI gree with @Lincoln Lavoie. Is this really something we should include in the testing tool?
#5 - @Lincoln Lavoiemade the suggestion that it would be testing project/tool name and version. (see his comment further below).
@Lincoln LavoieI do see your point for item 6. For Item 7, my thought was how will Anuket Assured know whether a test case that has passed or failed is mandatory or optional unless it is included in the tool/results. I am open to suggestions, but I would think the project (i.e. R*1, R*2, ONAP, etc) will know which tests are mandatory vs optional and could accommodate that information in the tool. The alternative would be that someone who validates the results in CVC has to look it up in a document. Other alternatives?
@Olivier Smith my thinking was, if there is a separate tool (basically some shell scripts or something similarly light weight) that are maintained in the review repo, those could be specific for each badge and badge release. So the testing tools focus on running testing, and don't have't internalize any information about each badge.
@Kanag for Item #4, why would the testing tool know about the URL for the product page? This would mean the tester has to enter that at test time, and it would be "spread" throughout the results set. However, usually the marketing folks at companies have strong feelings about where information like that lives and is pointed to. I don't think it's necessary in the results set.
For Item #5, I think we just need to define what should be included in this field. My suggestion would be it should be the tool project name (i.e. ONAP VNFSDK) and the version of the tool.
@Lincoln Lavoie @Marc Price
My understanding of the above is that we are looking to define a common set of agreed information to be provided in test results regardless of the project that is involved (i.e R*1, R*2, ONAP, etc). Assuming this to be true, my comments are as follows:
1) Test Case ID - A unique identifier for the test case which has been executed. It should be possible to use the Test Case ID to trace back to the specific requirement(s) that are covered by the unique test case.
2) Test Case Result - A pass or fail indication such as "P" or "F"
3) Test Execution Log - There is currently no description in @Kanag proposal.
4) CNF URL - There is currently no description in @Kanag proposal.
5) Test Tool Details - The purpose of this is not clear from the description @Kanag
6) LFN Badge ID - A unique identifier for the specific badge being for which the test is being conducted
I would also think that we should have information about whether a test is a Mandatory or Optional Test. A proposal would be:
7) Test Case Requirement - An indication of whether passing or failing (Test Case Result) is deemed mandatory or optional. Uses an indication such as "M" or "O" to clarify.
Olivier