November 3rd, 2021 by Adam Sandman
The upcoming release of our Spira platform includes a new set of custom property types in addition to the eight existing types already in the system. These new types are designed to increase the flexibility and security of the system. We have introduced a new password custom property type that lets you securely store test data in the system for use in manual and automated testing. In addition, we have added release and automation host custom property types to assist in common use cases.
The Password Custom Property
We have added a new custom property type of Password:
This new custom property type allows users to store important test data such as logins, passwords, and other Personally Identifiable Information (PII) in Spira without it being visible on the screen to the user, and more importantly, the data is encrypted inside the Spira database (in addition to the entire database itself being encrypted at rest).
When you add a password custom property and enter it in text, the data is displayed only when you click on it:
and is blurred out as soon as you click away.
One common use of this custom property is when using Spira with Rapise to manage an external (non-TaraVault) Git test framework repository, where the Git login and password are managed by Spira. For example, when using Spira and Rapise with repositories hosted in such platforms as GitLab, GitHub, or BitBucket.
The Release Custom Property
A common request from customers is the ability to associate artifacts with additional releases. For example, requirements are typically associated with the release that the feature is planned to be introduced in, but it may be useful to know what release the feature was phased-out in as well? Or a defect may need more release fields than just detected, planned, and verified. You can now add additional Release fields as custom properties:
Once you have added the new Release custom property, it will appear in the "Releases" section of the artifact it was added to. For example, we have added "Removed Release" to the Requirement artifact in this example, so the value can now be set on the requirements page just like any other field:
These new custom properties can of course be shown in the list pages, filtered and sorted on as well as controlled by the workflow.
The Automation Host Custom Property
One request we have heard from customers and partners (shout out here to Hugo at Coveros) is the need to associate Test Sets and test results (Test Runs) with the equipment being used to execute the test. Now, Spira already has a built-in Automation Host field that can be used for automated testing, but it would be useful to have different sets of test equipment that could be associated with the test execution. For example, you may use some equipment to run the test, as well as the equipment that the test is being performed on. This is quite common in hardware testing.
You can do this already with List or Multilist custom properties, but the problem is that there is no way to associate meta-data about the equipment with the item, it is just a simple name and ID. However, we have now added in v6.13 the ability to create custom properties that use the Automation Host list as their source. That means you can now add multiple custom properties of type Automation Host:
When you do that to the test set or the test run, you can then have the user pick the appropriate test equipment from the dropdown list:
but unlike a simple List property that has just the name, when you associate the Test Run and/or the Test Set with the Automation Host you can have additional meta-data on the Automation Host itself, including its own custom properties:
This is very useful when you want to categorize the test equipment in different ways and store key information such as serial numbers, version numbers, manufacturers, etc.