Continuous Testing

Subscribe to Continuous Testing: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Testing: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Continuous Testing Authors: Wesley Coelho, Rainer Ersch, Stackify Blog, Plutora Blog, Liz McMillan

Related Topics: Agile Digital Transformation, Continuous Testing, DevOps Journal

Blog Post

Debunking the OSLC Link-Only Myth | @DevOpsSummit #API #Agile #DevOps

Open Services for Lifecycle Collaboration is an open community for creating specifications for integrating lifecycle activities

Most large organizations require dozens and sometimes hundreds of specialized software tools to manage the lifecycle of the physical products or software applications they create. It isn't hard to imagine the monumental waste these organizations incur in attempting to manually coordinate the efforts of the teams that use these many disparate tools to create a single product. Open Services for Lifecycle Collaboration (OSLC) is an open community for creating specifications for integrating lifecycle activities across tools to address this problem. Now imagine how much more happy and productive an organization would be if all those tools could integrate via standard interfaces. In broad strokes, this is the goal of the OSLC community.

The technical foundation for OSLC is based on the W3C Linked Data method of publishing and accessing information and inspired by how the World Wide Web works. This "Linked Data" foundation is often misinterpreted to mean that data should only be linked across systems and never replicated or modified. The reality is that OSLC fully supports Create, Read, Update and Delete (CRUD) operations on lifecycle artifacts such as stories, defects and tests in a way that enables them to be integrated across systems through replication. Those artifacts, however, should of course be linked with one another across systems using OSLC links for navigation and traceability across systems. See the OSLC Primer for more detail.

While replication is fully supported by the technical underpinnings of OSLC, it is a widely held best practice within the community that data should only be replicated sparingly and only when necessary. Replicating data is inherently complicated and can lead to data inconsistencies if not done properly with a sophisticated toolset that must be correctly configured. However, the "C" in OSLC stands for "Collaboration" and the point of OSLC is to facilitate collaboration in the ways that create the most business value rather than to dictate a specific integration philosophy. And this means that replicating data with proxy object representations is OK when necessary to achieve the business outcome. In this case, a "proxy object" means a representation of a lifecycle artifact stored in another repository. Proxy objects should only contain values needed for local context and have an OSLC reference to the original object to apply services (e.g., CRUD).

Consider, for example, a software delivery team where the developers are using an Agile planning tool for software project management and the testers on the QA team have selected a specialized quality management tool to manage their work. The developers and testers require integration so that testers know what features and stories to test, while developers know which identified defects must be fixed.

To satisfy this integration need, Stories in the Agile planning tool can be represented as proxy objects (Requirements) within the quality management tool. Links are used to connect these two artifacts across systems for traceability. This allows the tester using the quality management tool to read the requirement and create the corresponding test cases to test it. Furthermore, the internal link between the requirement and the test case within the quality management tool enables traceability and reporting so the tester can verify that tests have corresponding requirements and vice versa.

Now when the tester inevitably finds a defect in the software, that defect report is filed in the tester's quality management system of choice and linked to the corresponding test case. But this doesn't get the defect fixed. The next step is for a proxy representation of the defect in the quality management tool to be created in the Agile planning tool and linked back to the original defect. This enables the developer to schedule the defect to be corrected in an upcoming Agile sprint.

As this example illustrates, addressing the business need for integration can require a combination of linking and replication techniques. While the information that is replicated should be minimized as much as possible, this approach is fully supported by OSLC. While Linked Data techniques are a crucial part of the solution and a foundation of OSLC, the notion that OSLC is only about links is just a myth.

More Stories By Wesley Coelho

Wesley Coelho is the Senior Director of Business Development at Tasktop Technologies. At Tasktop, he has taken a leading role in creating an extensive network of ALM integration partners including ten OEM distribution partnerships with companies such as IBM, HP, and CA Technologies.

Prior to Tasktop, Wesley led a software development team pioneering a new generation of eCommerce technology at Elastic Path Software. Wesley holds an undergraduate degree in Commerce from the University of Victoria and an M.Sc. in Computer Science from the University of British Columbia (Canada).

More Stories By Rainer Ersch

Rainer Ersch is a Senior Research Scientist with more than 33 years industry experience. He has worked as a director of SW Development Tools Enterpise Communications as well as serving as a consultant and coach for System and Software Development Environments. He has been active with the OSLC community as a member of the Steering Committee for over two years and as the workgroup lead of the ALM-PLM Interoperability Workgroup.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.