Growing complexity of your application requires more smartness and efficiency in your testing process - for example by managing assets centrally and reuse them across projects.
While Silk Central already provided some kind of reuse and sharing across projects via requirements integrations, source control integrations, shared manual test steps and keywords - there was no sharing of whole tests.
This is changed in 18.5 and explained in detail below.
Sharing tests as a project property
Contrary to shared test steps and keywords, shared tests do not exist in the library. Hence this is in some way a parallel concept and we will see over the next releases if they will coexist or merge at some point.
The intention to share tests is defined on project level - which feels in some way more natural as typically you will start with a project, build up your test set, etc. and then when you start the next project you will think about what parts of the old project you will reuse in your new project.
It is not uncommon that Silk Central users copy a whole project and remove the things they do not need. This approach works fine as long as you handle one project after the other - but as soon as you have two or more projects in parallel it can get tricky. Especially if tests are changed - then it is quite some effort to keep them in sync.
In Silk Central 18.5 you can now define for a project to share tests or consume tests:
![]()
A project can share its tests or consume tests from another project:
![]()
But it cannot do both as this might cause cyclic dependencies:
![]()
Of course one project can share tests to several other projects:
![]()
How does it work?
Imagine a project called "REPOSITORY":
![]()
Which shares following tests:
![]()
And imagine a project called "CONSUMER" which consumes tests from the "REPOSITORY" project:
![]()
So far the "CONSUMER" project's tests area consists of an empty test container only:
![]()
Now, to add tests from the REPOSITORY project to the CONSUMER project you simply copy & paste them between the projects.
![]()
Now one might say - well where is the difference? This looks the same as doing a x-project copy & paste in previous releases?
The difference is a connection between the tests in the "REPOSITORY" project and the tests in the "CONSUMER" project - it is called the Shared Test Reference and visible in the test's details:
![]()
This reference is kept wherever you move the test in the "CONSUMER" project and it allows you to directly go to the origin of the test in the "REPOSITORY" project.
The only way to delete the reference is to delete the origin of the test in the "REPOSITORY" project or disable the consumer project setting - then the test becomes an independent "local" test in the "CONSUMER" project.
Notification on Change
One of the biggest benefits of a central test repository and re-use is the reduction in maintenance overhead - for example if I have to change a certain test procedure I have to do that only one time and the changes are then considered in all the usages of this test procedure.
How can this be done with this new Shared Test Reference?
Let's start with some change in the "REPOSITORY" project - for example just change the name of a test:
![]()
And this change is immediately distributed to all the projects where this test is used? No - as this might not be the only change. You change the name, adjust the description, add/remove some step, change some attribute value, etc. - if every single change is distributed to all other projects it can get confusing and might have an impact on performance.
We wanted to have a dedicated action for a user to say "I am done with my changes and want to publish them." And this dedicated action is the creation of a new test version - as a test version represents a set of changes.
So we create a new version for the changed test:
![]()
So those changes together are now immediately distributed to all projects where this test is used? No - as the shared test reference is rather a loose reference.
What does that mean?
It means that changes are not pushed to, but have to be accepted in the "CONSUMER" project. The reason for this is that the tests in the "CONSUMER" project might have been changed as well and those changes should not be overwritten stubbornly.
So if you look into the "CONSUMER" project you will see a little overlay-icon indicating an available new version for this test:
![]()
Accept or Skip Changes
You then have two possible actions to react on such change notifications - acceptor skipthem:
![]()
Accepting changes means that the test in the "CONSUMER" project adopts all properties, attributes, and parameters from the test in the "REPOSITORY" project.
Skipping changes means that they are ignored this time, but the next time changes are available you will be informed again and can then again decide to accept or skip them.
So let's accept the changes and see what happens:
(1) The name is changed accordingly:
![]()
(2) Creation of test versions:
If you look into the test's history, you will see that the test now has 3 versions:
![]()
The first version was created when we initially copied the test from the "REPOSITORY" project. The second version is a restore point for the case you did local changes which should not be lost. And the third version is after the changes have been adopted so that you have a clear state to work with.
What changes are synchronized? (Extended Test Versioning)
Above you saw that the name was changed accordingly - but what changes are considered after all and was not test versioning for manual tests only?
Test versioning is now supported for manual and automated tests and covers all Silk Central internal information. Consequently an automated test version does not include the automation script - this is still located in the source control system and managed there.
Silk Central internal information means all properties, attributes, and parameters.
Beware of Inheritance!
However an important thing to consider is inheritance and the focus on tests (and not the structure)!
If properties, attributes, and parameters are inherited in the "REPOSITORY" project, they will be inherited in the "CONSUMER" as well. This means they will NOT be re-created in the "CONSUMER" project.
For example the two tests in the blue project inherit information (= yellow dots). When shared to the yellow project they inherit the "local" information (= blue squares):
![]()
If properties, attributes, and parameters are directly specified on test level in the "REPOSITORY" project, they will be directly specified on test level in the "CONSUMER" project as well. This means parameters and attributes will be created.
For example the two tests in the blue project have directly assigned information (=white & green dots). When shared to the yellow project this information is kept (and created if needed):
![]()
Not considering inheritance can cause problems if for example properties, attributes, and parameters are first directly assigned on test level in the "REPOSITORY" project and later changed to being inherited. As then adopting those changes in the "CONSUMER" project will remove those properties, attributes, and parameters - as for the test itself they are gone and structural information is not part of a test version which is the basis for adopting change!
Another important thing to consider together with automated tests (and possibly inheritance) is the need for matching source control settings in the "REPOSITORY" project and the "CONSUMER" project. If you have different settings the source control paths of your scripts will not match and therefore the tests cannot be executed as the sources will not be found.
No synchronization of structural changes
As already mentioned above the focus is on tests and not on test structures.
What does that mean?
It means for example that when you move a test around in the "REPOSITORY" project this movement will not be part of the next test version and therefore will not be "synchronized" to the "CONSUMER" project.
It also means that for example adding new tests to a folder in the "REPOSITORY" project will not trigger some kind of notification in the "CONSUMER" project that new tests exist.
Imagine following situation:
![]()
Now in the blue project the orange test is moved down and a new black test is added - this has no impact on the yellow project when next accepting changes:
![]()
The focus is on single tests only and those single tests will keep the reference wherever you move them. Consequently also moving the test in the yellow project will not break the reference:
![]()
Updating shared test
It is not uncommon that tests in the "CONSUMER" project are more up-to-date than their origin in the "REPOSITORY" project. The reason for that is that the "CONSUMER" project is the working project, which is closer to the daily testing and the latest project needs.
So you adjust the tests for the needs of the current project by changing step descriptions, adding steps, etc. - and at the end you feel that this is now the test everybody should use. Consequently you want to update the test in the "REPOSITORY" project with your local changes. How can you do that?
First - you need write permissions in the "REPOSITORY" project, without that you will not be able to change anything. If you have got those write permissions all you have to do is the following:
(1) Go to the History tab of your test:
As you can see some changes have been made - the name and description were changed, as well as the planned time.
![]()
(2) Click the "Push Changes to Shared Test" button
This will …
(a) … allow you to comment those changes:
![]()
(b) … create a new version for your test in the "CONSUMER" project:
![]()
(c) … create a restore point, adopt the changes, and create a new version for the test in the "REPOSITORY" project:
![]()
As a new test version is the vehicle to inform about changes - all the tests in other consuming projects will be flagged that changes are available.
Adding new tests
Like adjusting tests to the current needs it is not uncommon that in the "CONSUMER" project additional new tests are created - which you then would like to make available for general use.
Again you will need write permissions in the "REPOSITORY" project and then it is simply the reverse "Copy & Paste" action - meaning copying the test from the "CONSUMER" to the "REPOSITORY":
![]()
But the outcome - in terms of the reference - is the same. The test in the "CONSUMER" project will reference the test in the "REPOSITORY" project:
![]()
As structural changes - which includes adding new tests - are not synchronized to other consuming projects you will have to copy & paste this new test to all the other consuming projects where you need it.
Requirements Assignment
When copying tests from the "REPOSITORY" project to the "CONSUMER" project not only properties, attributes, and parameters are considered but also assignments to requirements.
If the same requirements (identified via the external Id) exist in the "CONSUMER" project then automatically the same assignment as in the "REPOSITORY" project is re-created.
![]()
![]()
Micro Focus proudly announces the general availability of Silk Central 19.0! If you already use Silk Central and you have a maintenance contract, you can 
