home
Home » Tools

Optimal Trace roll out

Submitted by ian_hurry on Tue, 2008-09-09 09:34.

I'd be interested to hear from other OT users as to their experiences of managing their user base, support, adoption of the tool, fit to pre-existing processes, etc.

» ian_hurry's blog | printer friendly version | 1199 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

OT rollout

Submitted by renabor on Tue, 2008-09-23 21:25. *

Ian,

I recently lead a group of analysts charged with implementing OT at our organization. We are a smaller IT organization - just 40 analysts, so managing the user base hasn't been difficult. Here is the approach we took:
1. Train team members - we brought in Compuware to do a 2 day training with selected analysts and QA folks.
2. Have trained analysts try it out on a smaller project and determine what works best.
3. Put together some best practices and publish (this helps us keep garbage out of the repository)
4. Have some additional analysts become early adopters and check in with them regularly to improve the best practices. We also asked these people to be mentors when the tool was rolled out to larger analyst community.
5. We created our own training material using our training software and require any analyst that wants to use the tool to complete the training
6. We held many learning events where we demonstrated the tool and talked to analysts about the tool, the tools benefits, and integration with our QA processes. We found some good effeciencies here that helped us sell the tool to skeptical analysts.
7. Develop strong use case practices. Before implementing the tool across the company, we ensured that ALL IT professionals were trained on Use Cases. I am a firm believer that you need solid requirements practices before you take on the challenge of rolling out a tool.
8. Use word of mouth advertising - we had the early adopters speak to the benefits that they gained by using the tool. As one said "I want to write all of my requirements in this tool."
9. Finally, we held a kick-off party by posting trivia questions on our SharePoint site and had a gathering at a local pub to roll out the tool.

Since we took it slow and gathered a great deal of feedback from our user base, the implementation has been relatively smooth. Our biggest hurdle was coming to agreement with the QA department on how our requirements feed into their testing process (they are far more rigid about stuff then we analysts will ever be!) Since we had strong requirements practices already, the tool augmented what we were already doing and provided effeciencies along the way.

Hope that helps,

Renee

» reply

OT roll out

Submitted by ian_hurry on Wed, 2008-09-24 06:53. *

Thanks Renee - pretty much in line with our experience!

» reply

Optimal Trace and testing

Submitted by kramerdog on Tue, 2008-09-23 23:19. *

Renee

I was interested to learn of your recent OT experiences. I have a number of years of experience of using OT (Catalyze) on smaller projects with one or two analysts and have ended up with my "own way of doing things".

I would be particularly keen to hear about what was the substance of the "agreement with the QA department on how our requirements feed into their testing process".

Did you define Test Cases within OT. Did you use the Test Case generation functionality and how useful did you find that? What methods did you use to produce Test Cases from Use Cases?

Cheers

Craig

» reply

OT test integration

Submitted by ian_hurry on Wed, 2008-09-24 08:10. *

Craig

We are utilising the OT to Test Director integration functionality.

Analysts create use cases within OT. The testers then use the generate test cases option within OT & then export these across into Test Director.

This is the principle, though it's not been thorougly proven yet.

Cheers,

Ian

» reply

Optimal Trace and Testing

Submitted by renabor on Wed, 2008-09-24 17:09. *

Craig,

We had long discussions on what constitutes a system test case and what constitutes a UAT test case and which requirements in OT feed into these different types of test cases. Basically, it came down to this:

Simple requirements, in general, equated to system test cases.
Use Cases, in general, equated to UAT test cases.

We do use the Test Case generation functionality within in the tool. However, we needed to set the expectation that this was really only the "shell" of our test cases - similar to when a tool generates code. You still need to fill in some missing pieces that come in design.

Analysts quickly learned that the test cases generated are only as good as the requirements you put into the tool. We recommend that you generate a sample test project before having your requirements reviewed, so the analyst can see what the generated test scripts will look like and whether or not you could test from them. This helps us refine our requirements before publishing for a walk-through.

Once the requirements have completed a walk-through, the QA department officially generates the test cases and uses OT to write the test scripts. We then export to QA Center for execution. We track defects using Track Record.

Renee

» reply

OT rollout

Submitted by rheath on Wed, 2008-09-24 03:31. *

I agree with Renee - the most important thing is for all stakeholders (the sponsors, users, analysts, developers and QA) to be comfortable with requirements in use cases before you go near any tool.
The advantages of Optimal Trace, we found, is that the flow diagrams are very useful when conducting the requirements workshops, the output in various forms such as Word or HTML helped to get sign off from all parties, and the potential to produce starting test scripts for QA helped to get buy in from the test areas.

» reply

OT and testing

Submitted by kramerdog on Wed, 2008-09-24 21:34. *

Thanks to everyone for the excellent responses on testing approach with OT.

I agree entirely that the Test Cases generated from Use Cases are only shells that need to be fleshed out. When you say Renee that you use OT to write the test scripts does that mean that you do the extra work within OT to produce fully scripted (manual) tests.

If this is the case, how do you manage changing requirements? From what I can see, you can't "synchronise" a Test Case with a changed Use Case and the issue is, what benefit would that bring when you have had to "manually" edit the Test Cases anyway to produce test scripts.

So I am presuming that you use the Traceability links between Use Cases and Test Cases and have to "follow through" from requirements changes to the affected Test Cases.

I am also interested, Renee, in the distinction you draw between System Test Cases and UAT Test Cases. Obviously, what you concluded on worked for you and your team, but the relationship between Use Cases and Test Cases probably depends upon the level to which the Use Cases are written.

I have found that detailed System Use Cases, which describe all interaction between the User and the System translate very well to System Test Cases.

UAT Test Cases then become a significant sample of the System Test Cases, perhaps simplified to some degree in terms of the number of scripted steps, as opposed to a different animal all together.

Does anyone else agree?

By the way, I am presuming that you didn't attempt to use OT for Unit Testing or tried and found it wasn't suitable?

Craig

» reply

Optimal Trace Roll Out

Submitted by renabor on Tue, 2008-09-30 19:43. *

Craig -

I agree with your point about System Use Cases making great system test cases. What I meant, but didn't elaborate on, is that we use the use case steps as the steps the user performs when testing - with details added in as appropriate from design. We use the simple requirements to determine what we should be testing as both positive, negative, and regression testing.

For UAT tests, we have the users run through all of the scenarios in the Use Case, but don't have them go into the detail we do in system testing.

As for generating the test cases in Optimal Trace, we do go through the extra effort of defining this in OT and manually updating if requirements change. Agreed that this is not ideal. We are a mostly waterfall development shop - so test cases are not generated until requirements are signed off on. That doesn't mean they don't change, but the cost of updating is then included in the cost of making the change.

I'm not saying this is ideal - just the way my current company has implemented.

For unit testing we use nUnit and did not attempt to try OT for this purpose.

Good discussion - thanks for your thoughts!

Renee

» reply

Post new comment

*
*
The content of this field is kept private and will not be shown publicly.

*

  Sponsored Announcements & Special Offers


Independent Evaluation of Requirements Management Solutions - Compliments of MKS
Forrester Research has released its evaluation of the requirements management market and gives MKS the highest score for its current offering. Get your complimentary copy of: The Forrester Wave: Requirements Management, Q2 2008.

Get Powerful: Visualize With iRise
Imagine being able to quickly assemble fully-interactive visualizations that mimic the exact look, feel, and behavior of applications – without any coding! No more confusing communication with stakeholders. No long hours handling rework. Now business analysts have a powerful ally in the fight to get it right – the first time. Isn’t it time you joined the thousands of business analysts iRise has already empowered? Download your FREE trial now!

Business Analyst Workbench Demo
Learn how Blueprint’s business analyst workbench enables you to elicit and validate requirements with stakeholders through visual simulation. Learn how to generate 100% ready-to-run test cases automatically. Free online demonstration.
© 2007 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group