Tag Archive for: Product Quality

Tag Archive for: Product Quality

Ensure Product Quality with These Review Process Best Practices

Review Process Best Practices

Introduction

Reviews play a key role in successful product and systems development, helping to ensure the new project meets stakeholder, market, and compliance requirements. Peer and approval review processes enable organizations to both iterate and innovate quickly while providing a dedicated process to apply appropriate rigor for final reviews. In addition, integrating item workflow with approval reviews can eliminate manual processes and reduce human error.

In this blog post, we examine a generic approach to reviews and review coverage, independent of the application used. In the second half of this post, we’ll look into the way Jama Connect® can be used to support the review processes described in the first half.

Defining the Scope of a Review

The reviews discussed in this post are in reference to informal (aka ‘peer’) reviews, leading up to formal (aka ‘approval’) reviews.

For medical device manufacturers, the first part can also be applied to their existing document management (quality) system, where their formal review and sign-off are recorded for quality bodies, like the FDA (Food and Drug Administration).

Reviews Play a Key Role in Successful Product Development.

Reviews are an essential part of any product quality process, comparable to testing the product. Document reviews take place in the engineering phases of a product lifecycle when there is no product (parts) that can be subjected to tests yet.

Like testing, a review by itself can never cover 100% of all issues that are in the item under review. And as with testing, a review process is defined at multiple levels, each with a different focus, attention, or goal to ensure the highest degree of coverage that can be achieved.

Review Coverage

There are different ways to ensure your reviews get enough overlapping coverage to catch the issues:

  1. The reviewers you invite
  2. The focus you give each reviewer
  3. The goal you set per review

Related: Leveraging Peer and Approval Workflows to Optimize Your Peer and Approval Process

Who Should Be Included In A Review:

The documents you write, you do not write for your own benefit. Documents created form a means for knowledge transfer from the author to the next person in the product lifecycle. The information within the document should therefore be understandable for its intended audience (readers) and users (appliers).

Since the documents written are related to the level these documents describe in the system’s engineering V-model, it can quickly be understood which process roles need to be invited as reviewers:

Process roles depicted in the diagram above:

At any one level within the applied information architecture, there are at least two next levels that need to be invited, to make sure these following levels understand the information provided through those documents: the next level downstream (decomposition and detailing) and the same level across testing.

It is also important to know if the author has understood the documentation that was provided by the process role in the product engineering phase before theirs (i.e., the upstream level).

Inviting colleagues in the same field, or at the same product level as other product lines (i.e., fellow Subject Matter Experts, or SMEs), is a good way to ensure those reviewers understand and evaluate the documents against company standards to ensure a consistent quality of deliverables. It also ensures that specific product knowledge is spread throughout the company when involving fellow SMEs outside their own project.

Because of their differences in process roles, each reviewer will naturally focus on the information that is important for them to understand in order to be addressed in accordance with the process they manage and maintain.

For example:

The System Requirements Specification (SRS) should be reviewed by the person(s) responsible for writing:

  1. The stakeholder/customer requirements (upstream; correct interpretation and coverage of that level’s ‘asks’)
  2. The Subsystem Requirements Specification (downstream; is it understandable, unambiguous, and specific enough to be able to ‘answer’ the ‘ask’ that the SRS has for them)
  3. The System Acceptance Test Plan (across; is it understandable, unambiguous, and specific enough to be able to be tested)
  4. SMEs on topics described and/or referenced in your document (quality, sanity, and completeness)

General Guideline: There should be at minimum three, but preferably four reviewers in any review.

Tips for Conducting a Successful Review:

  • When parts of the system will be developed and provided by a third party (e.g., subcontractor), include that subcontractor.
  • When reviewing the product needs, or tests to validate these, of a specific customer, include that customer (or meaningful representatives).
  • Although there does not appear to be any relation in the various test levels, it is still interesting to invite testers from those other levels, as they provide different insights, they’ve applied for similar tests defined at their level.

Assign Focus Areas to Each Reviewer

Even though reviewers get invited depending on their process role, related to the document under review, it is also important to assign focus areas to each reviewer to ensure not all reviewers comment on the same spelling error, which usually is only a minor inconvenience that takes away the focus on the important issues.

Simply mentioning what their expected contribution is will already achieve such a focus, i.e.:

  • A reviewer invited because of their upstream relation to your document should be assigned to look at the correct interpretation and coverage of their provided input.
  • A reviewer invited because of their downstream relation to your document should be assigned to check if they understand your document and if it is unambiguous and specific enough for them to further decompose and detail.
  • A reviewer invited because of their ‘across’ relation to your document should be assigned to check if they understand your document and if it is unambiguous and specific enough for them to define test cases and/or test approaches.
  • A reviewer is invited because they’re an SME to ensure the quality, sanity, and completeness of your document.
  • Finally, only assign one of them to also check for grammar and spelling errors. This (simple) assignment will ensure all other reviewers won’t remark on them, as someone else is already tasked with that and it keeps focus on their own assigned areas.

Informal Reviews Leading up to Formal Reviews

Not every review carries the same weight. Not every review has a formal context and thus doesn’t require the involvement of authorized (senior) colleagues, or managers, to formally sign off on the document.

Reviewers tasked with formal sign-off of your document, usually have yet another focus than reviewers tasked with evaluating the quality and completeness of its content. Combining these two types of reviewers will ensure either role will question their contribution to the review while the other role is addressing their found issue. Therefore, it’s advisable to have a two-level approach to reviewing your documents:

  1. Evaluate the content regarding any product, service, or inconsistencies.
  2. Evaluate the content regarding any business contextual (i.e., legal, contractual) aspects.

The review process and approach as described above have the quality and completeness of the content in mind, to allow the formal approval reviews to be nothing more than an administrative necessity; The subsequent approval of a document becomes a hammer piece.

“Review Center is facilitating communication. It has ensured a shared view of the world and agreement from all stakeholders. There are no surprises anymore. Jama Connect enables us to review documents and make decisions easily with everyone coming to a shared conclusion.” Craig Grocott Head of Systems Engineering, Teledyne e2v

Related Customer Story: With Jama Connect®, TELEDYNE e2v Improves Communication and Reduces Risk

Review Process in Jama Connect

The review process and approach described above are independent of any application supporting your review process and/or approach.

Jama Connect supports the above-described review process and approach. It can even provide more focus.

Divide and Conquer

Atomic Nature of Jama Connect Items

All Items, Components, Sets, and Folders are atomic.

Although Jama Connect doesn’t really have the concept of ‘documents’, most customers use their ‘Sets of’ and ‘Folders’ to represent the content and respectively (chapter/paragraph) structuring of their documents. As with documents where chapters and paragraphs are used to group and structure your information related to specific topics, level/priority of information, Jama Connect uses Folders, and a folder structure in a similar way within a Set.

Because everything in your Jama Connect project’s structure is atomic, you can select a Set and generate a document, or start a review of that Set, and all child elements underneath.

Utilizing This Atomic Nature of Items

The same ability is there when you select a Folder within that Set, allowing you to only select chapters and/or paragraphs on specific topics from your total document to your subject matter experts (SMEs), without them having to go through the entire document. Each specific topic can be sent for review to each (group of) SME(s) to get the most out of finding issues and correcting the (technical) content of each part of your document.

Once all reviews on all specific topics are concluded, you can move to formally approve the entirety of that document.

Related: Review ROI Calculator – Improve Review Process

Rolling Reviews

A “rolling” review is a review that changes the content of requirements that are included in each of the review’s revisions. Using this methodology, the review is much smaller in scope and can typically be completed faster.

Rolling reviews are standard Engagement Workbook nowadays. This mechanism actually binds a number of the review approaches discussed above into one:

  • Divide and conquer
  • Peer reviews leading up to approval reviews

It’s centered around the fact that all Items are atomic, each Item Type has the same status workflow, and the use of Filters to define the content of your review, where each new version you create of your review, will re-collect all Items that comply to the filter you’ve set up and baselines them.

It allows you to review each Item, or a subset of Items, separately, and collect all Items that have reached a status that indicates these Items are mature enough (content is of the quality, sanity, and completeness your organization strives for). Those Items then allow you to organize an approval review for the entire ‘document’.

Jama Connect Review Process

When initiating a review in Jama Connect, the steps included support this generic review process:

  1. Include the linked Items – upstream, downstream, and across – so your review invitees can evaluate the traceability.
  2. When using the ‘Rolling Review’-approach, select the corresponding filter.
  3. Invite at least three, but preferably four, colleagues in accordance with the contributions you can expect from their engineering role.
  4. Rewrite the standard invitation text of the email to assign focus areas to the invitees.

Related: Best Practices for Jama Connect Review Center

Additional Review Activities

Collaborative Review Meetings

Jama Connect allows organizations to run reviews online, which enables reviewers to determine when and where to spend their time participating in that review. However, much is to be learned from review meetings, where comments of a reviewer spark new insights and subsequent questions from another reviewer.

If the Moderator organizes a Review Meeting, a collective get-together, to discuss the review results and its found issues with all review participants, focus on the issues found, avoid discussions that take longer than a few back-and-forths, as the goal of the meeting is to try to process as many issues as possible in the (short) time available.

These discussions are important, so write down their topics and allow time to go into these discussions later; Ensure the meeting timeframe of the review session has a section for the actual review and a section for discussions.

Simply accept all grammar and spelling errors and ask the author to correct them after the session.

One thing to consider:
Abbreviations, terms, and definitions and how they’re used throughout your document do matter and should not be considered grammar or spelling errors!

Preparing For a Review Session

Insist everybody comes into the review session prepared, i.e., they’ve read the review comments of the other reviewers, made notes, and have their response ready. If they’re not prepared, participants may only read and evaluate reviewers’ comments and then respond to a comment much later, while the rest of the reviewers are already addressing the next issue.

Being prepared means the meeting can have short, to-the-point, and decisive discussions during the session, while still allowing you to process as many issues as possible.

In Conclusion

Defining the steps for approaching reviews and review coverage will help teams bring the scope of the review process into a more precise focus. By using an iterative and collaborative approach for reviewing requirements and other artifacts in real-time, organizations can improve stakeholder alignment, reduce review cycles, and ease the path to compliance.

RELATED


[Webinar Recap] The Costly Impact of Ineffective Requirements Management in the Medical Device Industry

In this post, we recap a recent webinar hosted by Jama Software on the topic of requirements management in the medical device industry

Requirements management solutions enable the unification of siloed processes and data that often reside in outdated, disparate, and disconnected legacy systems. However ineffective and inefficient, the industry still relies overwhelmingly on static documents housed in Excel/Word and relies on manual processes that add significant risk to the development process.

Axendia conducted a research study focusing on the medical device industry’s approach to requirements management with a goal to identify and analyze the drivers, barriers, trends, and value of requirements management across the product development lifecycle.

9 out of 10 (87%) Executives surveyed for this report admitted to having a ‘not effective or somewhat effective’ requirements management process.

In a recent webinar, Axendia’s Senior Industry Analyst, Sandra K. Rodriguez and Jama Software’s medical and life science principal solutions lead, Steven Meadows, shared the outcomes of the research including:

  • The impact of having an ineffective requirements management process
  • The critical importance of requirements management to achieve improved patient outcomes, product quality, and time to market
  • The negative impact on budgets, verification and validation activities when relying on manual processes

Watch the full webinar to learn more about The Costly Impact of Ineffective Requirements Management in the Medical Device Industry.

 

Excerpt from webinar:

Requirements Management in the Medical Device Industry

Sandra Rodriguez: Thank you for that introduction, Marie, and good morning, good afternoon, or good evening, depending on where you’re joining us from today. Really quickly about Axendia, we were founded in 2005. Our headquarters are in Philadelphia, Pennsylvania. I’m physically located in San Juan Puerto, Rico, it’s a balmy 84 degrees today. What’s unique about Axendia is that our analysts all have industry experience. And combined, we average about 25 years of experience. We work with startup companies as well as fortune 500 global clients. And we really focus on the intersection of the business regulatory and technology trends that impact the industry. So really looking forward to sharing the outcomes of our latest market research on the state of requirements management in the medical device industry.

Just really quickly too, for the folks of you on the webinar today, congratulations, you will be the first to receive a copy of the research report. I’m not going to cover the report in its entirety today because we don’t want to take away the thunder of it, but we do hope that you will find today’s information valuable and timely and that you get some great takeaways from the report. Before I go into that, though, just a quick acknowledgment that the content of today has been sourced from our quantitative and qualitative research, as well as our interaction with FDA’s officials and industry executives, and then some firsthand experiences from our clients as well.

All right, so let’s start with the demographics. We surveyed a multitude of companies from around the world, companies that perhaps make more than one type of medical device product, but here you can see that the majority do market and sell single-use disposable consumable devices followed by diagnostic devices that have both hardware and software components and software as a medical device.

So those were the top three. As a result of that, we wanted to look at the data in a little bit more kind of slice it and dice it. So we specifically picked out software as a medical device, and you’ll see in the report, and as well as in the presentation today, how the opinions vary based on the type of medical device company that we surveyed for this report.

In addition, we got a good mix of small companies and large companies. The majority of the companies that did respond to the survey were under 50 million. So they could be startups, they could be a little bit pre-market followed by the $1 billion to $5 billion size companies when it comes to their revenue. So another thing that we did was we went ahead and compared these survey responses based on those two different size companies. We also got a significant number of R&D and product development personnel to take the survey, which is important.

These are what I call the boots on the ground, the companies that really understand requirements management inside and out. They’re the ones who are working on the new products as well as quality assurance personnel. And then we had a 17% representation of executive management. So another thing that you’ll see in the report is that we went back to the data and did do some comparison and filtering based on these three personas. And we were really surprised to see how the attitude shifted.

RELATED READING: 2022 Predictions for Medical Device Development

Sandra Rodriguez: From a geographic standpoint, we had a really good representation. Overall, the majority of survey respondents do work for companies that sell in market products in North America, so Canada, the United States, and Mexico followed by Europe and all the EU member states. And then, of course, Asia, South America, Africa, and Australia. So again, a really great representation of the medical device industry.

So this was our first question. And following the demographics, I think it’s really important to point out that this was the first question that it came when it came to requirements management processes. We wanted to understand from the market standpoint if people felt that their organization’s requirement management process was either effective or I’m sorry, not effective, somewhat effective, very effective or ideal. We were really surprised that when you combine not effective and somewhat effective, straight out the gate, we have a 68% of the market saying that there is a lot of room for improvement here. This is what I call aiming for average. And it’s definitely time for this to change because the complexity of the devices is changing. The regulatory landscape is changing. We have a lot more software as a medical device coming out there into the marketplace. And there’s a lot of hardware and software components that are going into these products, whether you’re doing remote monitoring of the products once they’re out in the field or in the patient.

So because of the complexity alone, you really need to have… You would want to see the very effective and ideal numbers go up because when we combine them, we’re only at 31%. And what’s really shocking is that only 2% of those companies that we surveyed for this research project believe that they have an ideal process. So we wanted to take a look at those numbers from the different personas. The quality personnel were of a little bit more positive. They believe that their requirements management process is very effective or ideal. So they account for about 53% of that. But when you look at the executive management, to have 87%, so almost 9 out of 10 executives indicating that their organization’s requirement process is not effective or only somewhat effective, that’s pretty shocking. Keep in mind that these are the folks that own the budgets.

So if you know that there’s a problem, we really need to do something to incentivize these folks to make the necessary change and get to that very effective or ideal state, even on the R&D and product development side, the same holds true with 68% of those professionals saying that their organization’s process is somewhat effective or not effective.

So we also asked the closed-loop system question. And we define a closed-loop system as one in which the desired output depends on the input signal and the feedback elements that are going to enable end-to-end traceability. So when you’re looking at a typical product development cycle, you have the finished product here in the middle. So you’re going from concept to prototype. Clinical, if you need to have a clinical trial for the type of medical device that you’re looking to bring to the market, going into manufacturing, marketing, commercial, and then obsolescence.

RELATED READING: Axendia Report: The Costly Impact of Ineffective Requirements Management

Sandra Rodriguez: So having that continuous feedback loop, really closing loop around that system, and having the necessary traceability that’s going to be required from a quality and from a regulatory standpoint. So we ask them, how effective is your organization at closing the loop across the product development cycle. Now, mind you, this was question number two. And we see here that 68% of the market, again, admitted that that process is not effective or only somewhat effective.

So again, really need to make the necessary changes there, and probably invest in the solutions so that you can close the gap and get that traceability and close the loop across the product life cycle. It’s interesting as an analyst because we don’t sell or implement software, but we stay really close to the market. And we follow these trends and we see significant investment in the life sciences when it comes to digital transformation or investing in business systems.

But it’s important to point out that without a product you wouldn’t be in business. So the solutions and the systems, the tools that you have in place when it comes to your product should be as important as the systems and tools that you give your salespeople, or your ERP, or however, you’re investing in those systems. You really need to make the necessary investments in order to make sure that your product is of the highest quality and that you can get to market sooner and on time and on budget because we’re going to learn in this presentation that the industry is really struggling with that.

Watch the full webinar to learn more about The Costly Impact of Ineffective Requirements Management in the Medical Device Industry.

READ MORE


[Webinar Recap] Optimizing Your QA Process by Integrating TestRail and Jama Connect®

In this post, we recap a recent webinar hosted by Jama Software on the topic of integrating TestRail and Jama Connect

As the digital demands of the business continue to escalate, software delivery teams are under extraordinary pressure to deliver more work faster. Speed, however, counts for little if these teams are not delivering a high-quality product of value; rapid turnaround for a customer request is futile if the feature doesn’t work properly or meet their needs.

Fortunately, including quality assurance and test teams in the earliest phases of the software delivery lifecycle has never been easier; striking the right balance between speed and quality.

By seamlessly linking requirements to their test cases and test results, product managers and system engineers benefit from real-time visibility into test coverage and automated compliance reporting.

Join Jama Software’s VP of Product Management, Jeremy Johnson, and Tasktop Director of Partner Pre-Sales, Zoe Vickers, for a webinar demonstrating:

  • How linking requirements in Jama to tests that can integrate directly to or from TestRail enables transparency and cross-team alignment
  • How to correct inefficiencies and speed up time-to-market while enhancing product quality and employee satisfaction

Watch the full webinar to learn more about Optimizing Your QA Process by Integrating TestRail and Jama Connect.

Integrating TestRail and Jama Connect

Excerpt from webinar below:

Jeremy Johnson: I’m going to start by going through the agenda of topics that we have lined up for you today. Most of you are likely already familiar with Jama Connect’s ability to manage requirements, test and risk as part of your overall product development life cycle. So we’re going to start this discussion specifically around our perspective on integrations. We’ll have Zoe come in and talk about Tasktop Hub for Jama Connect and tell you a little bit about Tasktop as a company. Then we’ll move into test management challenges that we see when we discuss product development with our customers and prospective customers. And we’ll also touch on the benefits of integrating TestRail and Jama Connect. Zoe will then dive a little bit deeper into the integration flow and some of the benefits and show a live demo, connecting TestRail and Jama Connect. And then we’ll recap some key takeaways and get into some questions and answers at the end of the session.

So like I mentioned I’d like to start here with Jama software’s perspective on integrations. And the first point to touch on here is really the best practice around product development is to view integrations as a means to achieve live traceability across the systems development life cycle. Many if not most of you are familiar with the V model, you see a representation here. And you may not be with live traceability. So it’s really a component where different pieces of data that impact the product development life cycle need to evolve, need to be very dynamic throughout the process. Things like verification and validation need to happen much earlier in the process.

So maintaining this live traceability between all of these different product development components, different assets that might be involved, different products that might be involved is critical to optimizing your product development life cycle and processes. The real key here of course is that with this notion of live traceability in place, issues are reduced, and those that do arise are found earlier in the process. You can see here based on data from industry sources, these issues, finding these issues earlier in the can save 16 to as much as 110 times the cost of not finding them until later in the process.

RELATED POST: Introducing TestRail for Jama Connect

Now I think everybody at this stage of evolution understands and agrees that this is the best practice. But really the challenge has been implementing this in the real world. So why is it that companies tend to struggle? And the reality is that most companies or probably nearly all companies don’t have an end-to-end system development process that covers all of these components. They tend to be broken up into silos, different toolsets, maybe even desktop tools and spreadsheets. Some of those things come into play. And all of those variability, all of that variability in the tool chain leads to potential issues. These areas with Xs on this representation of the V model. Those are potential areas where the traceability might be broken, and that results in significant manual effort, emails, meetings, all of those kinds of things, maybe a little bit of luck involved in trying to prevent delays and defects and rework and cost overruns that can come if those data points, that traceability is broken.

And Jama Software and Jama Connect as a product can certainly resolve some of these components in its inherent capability of tying risk and test information with requirements. But many companies have come to really accept this situation as unchangeable. If we don’t have a single platform to do all of this, then we inherently need to manage these things in silos and accept maybe desktop tools and spreadsheets or on some level part of the process. Then those are things that you’re simply not going to be able to control and manage. But a really a key to bringing this all together to achieving this live traceability is to sync these existing software tools, these best of breed tools.

Even in desktop tools and spreadsheets and things with requirements. So Jama Software is one of the companies that is really truly making this possible. So if we look at live traceability and an example of the connected data, the connected components within Jama Connect, you can see how easy it is to define elements, the relationships across tools, maybe even spreadsheets in this example. This happens to be from our medical device solution, but we have similar but tailored solutions for aerospace and defense automotive and semiconductor for industry industrial manufacturing, various different industries. These components are continually synced with best of breed tools. They’re applying their own specific engineering disciplines, and importantly linking that back to requirements and other vital components of the product development life cycle within Jama Connect.

So again you can see some of those connections in this diagram, very common for things like JIRA and Azure DevOps and downstream issue identification, task management, some of those things on the execution side. Zoe is going to touch a little bit on how JIRA comes into play in this scenario. We have test rail of course that Zoe will be talking about on the verification, the testing side. So those will come into play as we get deeper into this discussion. And one of the key ways that we help customers achieve this live traceability is with our strategic partnership with Tasktop. So to introduce you to Tasktop and some of their capabilities, I’ll now pass it over to Zoe.

Zoe Vickers: Thanks, Jeremy. I really appreciate it. Hi everyone. So what I just want to talk about as a whole is Tasktop has actually been a strategic partner of Jama’s for many years. And what this partnership really allows all of you Jama customers to do is you have the ability to integrate Jama with over 60 plus tools in the more agile DevOps testing ecosystem. The reason Jama decided to partner with us at Tasktop is because what we offer is an out of the box point and click configuration for setting up these integrations. What I mean by this is not a heavy services engagement. It is not something that each time you add a new project, you add new fields, you add new requirement types in JIRA that you might want to integrate with. Different tools like TestRail or JIRA. You don’t have to reach back out to Jama or Tasktop.

You are able to actually scale your integrations on your own. So that way you can build an enterprise wide solution within your own teams. One of the things that I want to show on the next slide is really the ability of what are all of the different connectors that Tasktop has. So I mentioned that we do allow you to integrate with over 60 different tools. Again, we actually have something called our integration test factory where internally at Tasktop we run over 500,000 tests a day, against every supported version of software that we have.

So again what we’re able to help, you do know we’ve helped many, many Jama customers do over the years is integrate drama with the fullest of tools on the right hand side. If you’re taking a quick look through that, they are out for the ties. Again, some of the most common ones that we are seeing specifically with Jama customers is we’re working with Azure DevOps, we’re working with JIRA, we’re working with TestRail, we’re working with Spark CA. And really the idea here is to bring in as much traceability across your different tool chains. So that way as you go back to some of those different traceability diagrams that Jeremy was talking about, you can see where all your [inaudible 00:12:05] teams are doing their work, and you actually have the visibility into the up-to-date status at any moment in time.

RELATED POST: Datasheet: Tasktop Integration Hub for Jama Connect

One of the big things that we talk about with Tasktop is why do you actually need an integration solution? There are some brilliant developers out there who can build a integration solution in-house. And a lot of times those integrations work beautifully, but what I’ve had many customers over the last few years talk with me about is that it’s hard to scale. And then it becomes a little bit more of a problem for them when it comes to error handling or troubleshooting. What we like to talk about at Tasktop is really to say first off integration solutions are needed, whether it’s through mergers or acquisitions or just growing teams as you go from large, medium, or small businesses. You have a lot of duplicate data entry that might be happening in a variety of tools.

Whether you’re communicating between your requirements tools, your agile teams, to your ITSM teams logging tickets. What task that’s going to help you do is actually eliminate a lot of that overhead and duplicate data entry, which then is going to help allow you to actually speed up your or delivery times and it’s also going to improve the communication between the teams, because they are able to collaborate across different tools without actually having to exit those applications. So one of the things that we’ll be able to even talk about today with Tasktop is you’re no longer going to have to walk across the office or send an email or extra Slack message. You can continue to comment back and forth in Jama, within TestRail, within JIRA. So that way your teams truly do have the end-to-end visibility of who’s working on what without having to log out of their tools of choice.

The main way that Tasktop actually does this is through something called model-based integration. So one of the big things that we like to talk about at Tasktop is there a value in just a simple point to point integration? Yes. This webinar today is talking specifically about Jama to TestRail. But we also need to be aware that none of you are going to operate in just the vacuum of those two tools. You probably have an entire ecosystem. 10, 15, 20 tools that your different teams are using. Tasktop is built to be an integration solution so you can scale across your entire organization. How we do this is that we are not actually a plugin to Jama or a plugin to TestRail. We are an independent third party solution that can be both on-prem or cloud hosted and how we actually offer this integration is through something we call model-based integration.

What a model is going to do is it is going to act as that universal translator to convert and normalize data between systems. What I mean by that is in that image on the right hand side you’re actually able to see for example I have a variety of different tools, this is an example customer we’ve worked with has. And specifically if we look at Jama they are doing a lot of their defect logging there. And as that relates back to their different requirements. So what I’m able to do is I’m able to take not only Jama, but also the specific work item that they’re working on. So there are different maybe bug or defect types with all the schema that makes up that specific item and map it into my specific model. From there, instead of just going over to TestRail, I could integrate that specific information with JIRA, with Azure DevOps, with a problem from ServiceNow.

And I’m also able to then take something like TestRail and map that into the model. So at any point in time when you want to add an additional tool or an additional work item, you want to actually bring integration and synchronization with your teams. You easily can map it to the model and reuse any half of any other integration to easily map it to. So an example of how this actually works is on this next slide imagine that you have your two different tools. So we have Jama test case on the left and we have a TestRail test case on the right. Then you have the model in the center. So think of your model as nothing more than a bucket of fields. Before you hopped on the webinar today, you probably decided, “Hey, I am interested in integration.” That means that probably on some little scratch piece of paper or an Excel document you have noticed and said, “Hey, I want to get information from this tool to this tool.”

The information I care about is something like a status or a priority or the assignee of this item. All that information goes into the model. Think of the model as Tasktop. From there I can easily map from Jama to the model, and you can see that we can have a one to one relationship between fields or a one to many. Then I can also map TestRail to the model. And as I do that, as we keep clicking through, you’re going to see these different boxes pop up, which shows a Jama collection and a TestRail collection. What that means is first off we look at the black lines. Tasktop is able to help route the data anywhere it needs to go to the correct fields, to the correct values via the model. From there, once we go into Tasktop later we’ll talk about how the architecture Tasktop works. Where in the previous side when I had shown you can map any tool to any other one half of an integration.

We see here that half of your integration is going to be called a Jama collection. That means we’re mapping from Jama to the model. And the other half of the integration is going to be from TestRail to the model and that’s your test rail collection. The reason this matters to you is that the second question I get from a lot of customers is, “Well, do we have to have all these fields equal? Does the schema in both tools need to match?” And the answer is no. You guys can start your integration with baby steps. You’re going to very easily be able to say, “This is this state of my Jama, this is the state of my TestRail. Let’s just start flowing information.” Then from there you can determine to scale.

Watch the full webinar to learn more about Optimizing Your QA Process by Integrating TestRail and Jama Connect.