Lieutenant Commander
Lieutenant Commander
911 views

Best Practice for Testing Interfaces Between Development Projects

I wanted to pose a question to see how other folks are handling this situation.  I'm looking for some suggestions on best practices.  

We develop multiple control units, each one can be in a fashion as a standalone item that our company sells to end users (e.g. ECU1, ECU2, ECU3 . . . ) and has their own release schedule, own set of requirements, and own SILK projects.  However if our end users select to purchase ECU1 and ECU2 from us, there are additional features that are made available in our products so we need to test the interface of the different ECUs with each other.

Right now we have a SILK project for each of the items that includes all the tests for each component (ECU1 has a project, ECU2 has a project and so on).  I now need to develop tests that cover the interaction of a given version/build of ECU1 and a given version/build of ECU2.  Are there any suggested best practice on how to handle this?

1.  In hind sight, maybe each of our individual projects should have actually just been a component in a larger project, but I think that would have present problems with linking in requirements from different external sources/projects into a single project.  If we did things this way eventually almost all of our products would in essence just be a component of massive system and management of a single SILK project that size would be cumbersome.

2.  My second thought is to have another SILK project that is a system level project that handles all the interaction of components with each other only, but then I loose visibility from the individual projects perspective on the entire state of the system (individual projects handle stand-alone features and a system project handles interactions with other ECUs).  And then I would have to manage versions, builds, and test cycles in multiple projects whenever I have a new release build of any product.

3. My third idea was that  I could have shared test steps and ECU1 would then in essence run the same test as ECU2, but with this idea the run results would not be visible from the separate projects.  Ideally I was wondering if there was a way to share an actual test between silk projects and not just test steps.  My use case is ECU1 is at a stable release version 1A and was tested successfully against ECU2 version 2A, but ECU2 is currently going through a release cycle for version 2B.  The interface test between ECU1 and ECU2 was run with ECU1Version1A and ECU2Version2B from the ECU2 SILK project.  If that interface test could be shared between the two projects, then when viewing the system from the ECU1 project we could also see that the interface test was run against the latest version of ECU2 and the status of that test.  Is this possible?  Can Tests be shared as well as test steps?

Thanks -- Any ideas on best practices would be greatly appreciated.

0 Likes
1 Reply
Absent Member.
Absent Member.

Hi Ellen,

Thanks for your query and it certainly is a major topic for all users Project Configuration, to ensure you see coverage and tests results that are representative for what is delivered.

One option that you could do is create a test environment which would replicate some of the ideas you have referenced to see if these work more efficiently for your release schedule and delivery.

The benefit of Silk Central is we do not say you should use the product one way or another, it should be used what is the most efficient way for you.

Some of the variations other users use would be to have one test container which is the overall business unit, then each of the multiple control units could be a folder underneath this.

This provides flexibility in reporting across multiple units from both a project and folder level.

It also allows reuse of test assets, as each execution plan can select from multiple units if you need to create a plan which utilizes features from more than one unit.

Another option would be to have each of the control units as a test container in one project in itself. This would have some drawbacks though in that an execution plan is related to a container so creating cross-unit execution plans would be more difficult.

I would recommend setting up a trial project with these configurations and any others you may want to check that you can return the information you require.

It would also be useful to hear how other users manage this scenario, but hopefully, this gives you some ideas.

Any further questions let us know.

Thanks,

Matt

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.