Jama Company and Community News

Jama Connect® vs. IBM® DOORS®: Requirements-Driven Testing: A User Experience Roundtable Chat

By |

requirements-driven testing

Jama Connect® vs. IBM®DOORS®: Requirements-Driven Testing: A User Experience Roundtable Chat

Increasing industry challenges and complexities are pushing innovative organizations to consider modernizing the tool(s) they use for requirements management (RM). In this blog series, Jama Connect® vs. IBM® DOORS®: A User Experience Roundtable Chat, we’ll present several information-packed video blogs covering the challenges that teams face in their project management process.

In Episode 9 of our Roundtable Chat series, Mario Maldari – Director of Solutions Architecture at Jama Software® – and Susan Manupelli – Senior Solutions Architect at Jama Software® – discuss requirements validation, verification, and testing in addition to demonstrating test management in Jama Connect.

To watch other episodes in this series, click HERE.

Watch the full video and find the video transcript below to learn more!

VIDEO TRANSCRIPT:

Mario Maldari: Hello, welcome to the ninth edition of our vlog series. Today, we’re going to be talking about something that’s very important in requirements management, something that I’m particularly passionate about, and that’s requirements validation, verification, and testing. And I’m joined by my friend and colleague once again, Susan Manupelli. Susan and I have worked together for a long time, 15 years plus testing various requirements management tools using various techniques, and various software. I believe the most recent software you were using was IBM’s enterprise test management tool, something we used to call RQM. Looking back on all those years and all those tools you feel as though have been your biggest challenge.

Susan Manupelli: So talking about the ELM suite where we were talking about rational quality manager and also we were using that to test DNG. Really the issue, the biggest challenge is that they were two separate tools. So even though they were part of the same tool set, the UIs were completely different. They were very inconsistent in how you would use them. The review and approval aspect of RQM wasn’t that great. And again, it was completely different from the review and approval that you would get when you were working with DNG. And also because they were from two separate tools, in order to really get the traceability, that would be a challenge. You’d have to do reports that were outside of the individual tool tools. And then one of the biggest things too was the comparison. Things changed in RQM. It was not easy to find out what changed, even if you compared one test case to another.

Mario Maldari: Yeah, I recall some of those challenges. I think for me, the biggest challenge I had was the UI inconsistencies like you mentioned. Obviously, I was in one tool, I’d go to another. It’s completely different experience, completely different nomenclature. And then having to integrate between the tools and just frankly having to go to a separate tool to do the testing was problematic and challenging sometimes. So I think you hit an important topic in terms of having everything in one tool. And I’d like to show you how Jama does that. Okay. So in Jama, the fact that we have testing integrated into the tool allows you to do some pretty neat things. So as you can see here on my desktop, we have this dashboard, and I can define a relationship rule diagram in Jama where I can define that I want specific requirements to have validation points and test cases associated with them.

And so what that gives me is I can create some dashboard views for requirements, lacking test coverage, or I can even look at test case summaries. Right on the dashboard, I can look at test case progress, the priority of my tests. Jama even allows you when you’re testing to log defects. So I can track my defects here. And so for you and I, we always have to provide test case reports and summaries up through management, up through the development team. And so this allows you to have it all in one spot, which is really nice to have. So the testing itself in Jama, you basically enter it on the test plan tab and very similar to the way you and I worked, we have a concept of a test plan where you can define your test intent, the things you’re going to be testing, your approach, your schedule on your team, your entry criteria, your exit criteria.

And from there, as you pointed out, you can send this for a review and you can get an official sign-off from your development team or whomever you need to sign off on your test plan. And then once that’s in place, you can go to your test cases and you can start to group your tests according to functionality or whatever makes sense for your grouping and your organization of your suites of tests. And once they’re grouped, you can come to the test runs and this is where you actually will be doing your execution of your test. So I can click on one of these here and can start an execution and I can start to go through each step and pass or fail as I go through. And the nice thing about Jama, as I mentioned, is that you can actually go ahead and log a defect in real time and I can go ahead and log this defect.

And now when I’m saving this defect, it’s associated with this test execution run, which is associated with my test case, which is associated with multiple levels of requirements upstream. So now if I look at a traceability view, I will see my high level requirements traced all the way down to the defects. When I have logged a defect, I can actually go in and I can take a look at this test run and I can see the defects. And if I have something like an integration to another product like Jira for example, maybe my development team and is working in Jira and they love Jira, it automatically populates the defect in the defect tool like Jira. So a developer can come in here, they can make some changes, they can put in some comments, they can change the priority, the status, and all of that gets reflected back in Jama.

RELATED: Traceability Score™ – An Empirical Way to Reduce the Risk of Late Requirements

Mario Maldari: So really nice integration if you’re using something like Jira. From my perspective too, what would’ve been nice in my past test background is to have this concept of suspect trigger. And so if I look at the relationships for this particular requirement and I see that downstream there’s a validation of a test case, which is validated by length type, I can see that it’s flagged as suspect. So that means that something upstream has changed and my downstream test case is now suspect. And what does that mean? Maybe I need to change it, maybe I don’t. How do I know? I can come to the versions and I can say, “Well, the last time I tested this requirement was in our release candidate one, and what’s different now?” So I can compare our version three to version seven, run our compare tool, and I can see exactly what changed.

So as a tester, this is great to me, it’s not enough to know that something’s changed. I can actually see exactly what changed and maybe it’s just a spelling update and I don’t need to really change it. Or maybe it’s something more substantial like you see here. And at this point I can come in and I can make my change to my test and I can go ahead and I can clear the suspect flag.

So really nice level of granular control. What’s also good with the Jama’s we have these out of the box, and you’ll like this, Sue, out-of-the-box canned reports that have summaries of your tests, how many blocked, how many failed, how many passed executions. So these are canned reports that come with Jama. If you needed any customized reporting for your specific needs of the organization, we have that available as well. So really nice back to your point about having everything in one tool, this is it, and this is the benefit. Now, I know you’ve been at Jama for just about six months now. I’d love to hear your impression of the test management built-in, what your thoughts are there?

RELATED: Telesat Evolves Engineering Requirements Management & Product Development

Susan Manupelli: Oh, sure. Yeah, I do. I definitely love how everything’s in one tool and the ease with which you can just trace, actually verify the testing of your requirements. You can just go from requirements straight down to multiple levels of decomposition to your test cases. So you can see, answer the question, did your requirement are your requirements passing, which is great. And also the ability to display related queries right on the dashboard. I think that’s a huge plus the consistency of the UI between what you do for requirements, creating a test case isn’t any different than creating any other requirements.
So it’s a very familiar UI for both operations, which I think is important. The review and approval piece is really a nice strong point for Jama, and to be able to apply that to reviews for test cases is really great. And I just think it’s a really streamlined UI. It really has everything you need and nothing that you don’t. So I just think it’s a great tool. And then there’s one other aspect that I really like is the impact analysis. You mentioned being able to trace when something’s changed after the fact. It’s also to be able to say, “Hey, we’re looking at making a change here.” There’s one button in Jama, you click that impact analysis and it tells you all of your test cases that you might need to revisit if you make that change.

Mario Maldari: I call that the proactive method.

Susan Manupelli: Yes.

Mario Maldari: Yeah, the impact analysis is extremely important. And if you were a developer in an organization and you changed a requirement or you were about to change a requirement and you knew you had 30 tests that are associated with that, you could run the impact analysis. See all of those, and you could proactively warn your test team, “Hey guys, I’m about to make this change. Here it is. I’ll explain it to you. We can have a separate review and approval.”

So it really contains all of that and controls all of that for you. I’ve often said to people, it’s one thing to have your requirements in a tool, and that’s the first step. Define your requirements, have your traceability. But if you’re not doing your testing and validating those requirements, then how do you know that you built the right thing, right? So extremely important aspect testing to requirements in the supply. So any requirements gathering process so I’m glad we could talk about it today. Sue, glad I could have you to talk to about it. And I’d like to thank everyone for their time and thanks for participating in the vlog series and we’ll see you on the next one.

Is your data working for you? A consistent and scalable data model is instrumental for achieving Live Traceability™ and making data readily available across the development lifecycle.

Download our Jama Software® Data Model Diagnostic to learn more!

Thank you for watching our Episode 9, Jama Connect vs. IBM DOORS: Requirements Driven Testing. To watch other episodes in this series, click HERE.

To learn more about available features in Jama Connect, visit: Empower Your Team and Improve Your Requirements Management Process


Mario Maldari
Latest posts by Mario Maldari (see all)