The future of Rational RequisitePro, Requirements Composer & DOORS

Just how many requirements tools does IBM need? A question I’m sure many people have been asking themselves over the last couple of weeks since IBM Rational announced its latest wave of tools, including Rational Requirement Composer (their latest offering in the requirements tools space).

After these types of announcements, you can guarantee that before the week is out, rumors are spreading about the future of existing tools, which in this case mean a number of theories about the future of Rational RequisitePro and DOORS (a new addition to the Rational portfolio after the recent acquisition or Telelogic).

So if you are an existing RequisitePro or DOORS customer, what can you expect from IBM Rational over the next couple of years? This presentation from IBM gives a pretty good overview.

How do I integrate IBM Rational Quality Manager with Jazz?

I’ve been asked this question a couple of times this week, so thought the topic was worth a post to clear up the confusion. IBM have put a lot of marketing cash into advertising “Jazz”, but interestingly if you were to phone up your local friendly IBM Rational Sales person and ask to buy “Jazz”, you couldn’t. Instead, you would be offered one of the new Jazz-based tools, one of which is IBM Rational Quality Manager.

So the answer is… there is no integration setup! Because Rational Quality Manager could not exist without Jazz and there would be no reason for Jazz (or to give it its full name, the Jazz Team Server) to exist unless tools like Rational Quality Manager were built upon it. If you want all the techy details about how Jazz works, you’re best looking on Jazz.net.

A lot of the Jazz-based tools are only just being released, like Rational Team Concert and Rational Requirements Composer, whilst others are still in the Rational Labs and may never see the light of day like Rational Financier, Rational Tempo, Rational Ensemble and Rational Governor. You can see some early screenshots here.

Rational Testers Can Now Author Tests Online Too with RQM!

I’ve been involved in a few test tool evaluations in my time and every place has a different set of prioritised needs. This said, there are some common features that tend to bubble to the top of most people’s list, like a small installation footprint, on-line authoring of test cases and easy access to those test cases for people who are not a member of the core project team. With existing IBM Rational test tools like Rational TestManager (TM), Rational ClearQuest TestManager (CQTM) or Rational Manual Tester (RMT), whichever way you cut it, the answers to these questions are no, no, no

But if you are about to undertake a test tools evaluation, I recommend taking a look at IBM Rational Quality Manager ( due to be released into open Beta on the 7th of July 2008 ) before you buy HP / Mercury Quality Center or Compuware QACenter because if you ask the same questions the answers are yes, yes, yes

I’ve only seen demo’s of Rational Quality Manager’s Web 2.0 test case authoring capabilities so can’t comment too strongly until I get my hands dirty (I’ll re-post once the open beta is released). What I can say for sure is that the way Rational Quality Manager supports a tester in authoring and executing test cases will be a make-or-break feature. After all, testers spend the majority of their time testing – writing tests, running tests and analysing test failures to help isolate any bugs they find… And who wants to use a tool for much of their working day whose primary feature isn’t A1 perfect? Not me.

Bye, Bye MS Word. Hello Rational Quality Manager!

So if you are from the school of thought that says its a good idea to create a documented test plan (similar to that described in the IEEE 829 standard for software testing documentation) then I imagine you write it in MS word. I know I’ve written a few of these in my time (some that I’m not particularly proud of, but that’s another story!) and I’ve read plenty of other people’s as well.

So let’s assume you’re past the discussion about whether a document like this is a good idea on your particular project and focus on whether the vehicle used to host this document can make it more or less beneficial to your project’s success? This is the question that IBM Rational must have asked themselves a number of months ago and decided that, “yes”, it does matter and the best place for it is within IBM Rational Quality Manager, captured as a collection of configurable test-plan-section-widgets (sorry, that’s the best way I can describe it, I’ll try to dig out a picture and post it so you can see what I mean).

Do I like this idea? Yes and No.

“Yes”, because I can see it reducing the number of times I get annoyed asking for a test plan and then receiving either a massive email attachment that I can’t easily download on the move or a response of “let me send you a copy later, I think Fred has the latest version, but I’m not sure” and then it never arriving. So from a config management, collaborative working, accessibility and backup point of view, it get a thumbs up.

Why “No” then? Because whenever you template anything you restrict thinking and creativity and that’s something you need to have in bucket loads if you want to plan a testing project that finds anything other than the basic bugs. I also like to see a good picture in a test plan (when the occasion requires it) to explain maybe how the app is going to be divided for testing or how different types and levels of test are going to be spread across the life-cycle (for example) and as far as I know you can’t add pictures to your test plan in RQM, only words (don’t hold me to this one, I’ll let you know for sure after the 7th of July when the open beta is released).

Update: You can add atachments to a Test Plan in RPM, so I’ll stick my pictures there

Migrating TestManager to Rational Quality Manager

I attended a webcast last night on the new IBM Rational testing product (Rational Quality Manager, or RQM for short) and one of the questions on everyones lips was if you are an existing IBM Rational customer with existing IBM Rational testing tools, what is the upgrade or migration path.

To cut a long story short, Rational Quality Manager will be able to import test assets from Rational TestManager (TM) Rational ClearQuest TestManager (CQTM) and Rational Manual Tester (RMT). As I understand it, this will be an import tool, rather than a synchronisation tool, so once you’ve moved your test assets across, I imagine most people will then look at gradually retiring TM, CQTM or RTM and solely use RQM. There will of course be exceptions, like people who have heavily customised the CQ part of CQTM to do something unique.

This is one of the first things I plan to test on July the 7th when the Open Beta for RQM is released, but if the dev team have put as much effort into the migration tool as they have into the fancy new web 2.0 interface, then I’m sure it’ll be fine… famous last words

My talk @ Software & Systems Quality Conference

I blogged earlier about my presentation at the UK Software & Systems Quality Conference in London, on the 29th of September.

For those that are interested, I’ve added the full abstract for the presentation below.  You can also download the slides from here.

A Thinking Framework for Context-Driven Test Documentation

Whenever the topic of documentation is discussed, it always reminds me of the story of Goldilocks and the Three Bears. In this story, a family of three bears live in a house in the woods. One day, the bears go for a walk, leaving their house unlocked. While they are out, Goldilocks enters the house and discovers three bowls of porridge. The bowls have been heated to each bears’ specific taste so when Goldilocks samples the porridge she finds that the father’s porridge is “too hot”, the mother’s porridge is “too cold”, but the cub’s porridge is “just right”.

Many testers experience a similar problem when using other testers’ documentation as a basis for their own, only to discover that it results in “too much” or “too little” information and does not fulfil their own written communication needs. Goldilocks could easily move from one bowl of porridge to another, however, we aren’t always so fortunate, regularly finding ourselves with documentation that has become out-of-date, yet is too sparse or too unwieldy to maintain.

Working with too much or too little test documentation can significantly reduce the productivity of any test team. As testing matures as a profession, so must our ability to reason about documentation and select an approach that complements our own specific context. Hence, this talk will share a thinking-framework for making decisions that allow us to spend just the right amount of time documenting and leave the maximum amount of time for finding bugs.

The talk will begin by discussing documentation from past projects to reveal the foundation of the framework – the fact that our written communication needs move along a scale from being light and agile to formal and disciplined, depending on our context. Many factors affect our context as testers, so the second part of the talk will focus on the factors that change our written communication needs (often in relation to increasing or decreasing our use of other communication channels) and how these factors can be used to reason about the level of detail and formality of our documentation.

PDF Version

Simple Documentation for Software Testing

I was recently accepted to talk at the UK Software & Systems Quality Conference in London, on the 29th of September. My talk is titled “A Thinking Framework for Context-Driven Test Documentation” and with only a few weeks until the material needs to be submitted to the organisers, how to get my messages across has been at the forefront on my mind. One of the first points I intend to make is that… It’s OK to be confused about test documentation, because lets face it, there are so many options it makes test documentation confusing! In fact I think a lot of testing projects fail (or to put it a nicer way, could do better) if they thought more about what (and how) they were going to communicate using written media. (If you were wondering, I do intend to go on and talk about how to work around this confusion and not just leave the audience hanging )

One of the reasons I think it can be so confusing is the vast number of phrases, terms and definitions that can come up during a conversation about test documentation. With this thought in mind I started making a list. I must confess, I got to about 20 items and then run out of steam so I turned for inspiration to the International Software Testing Qualifications Board (ISTQB) glossary, an old ISEB Practitioner course syllabus and a copy of the IEEE 829 standard I have as PDF. I’ve added the list below.

• Test
• Test Plan
• Master Test Plan
• Project Test Plan
• Stage Test Plan
• Phase Test Plan
• Level Test Plan
• Iteration Test Plan
• Test Schedule
• Test Handbook
• Test Script
• Test Log
• Test Idea
• Test Idea List
• Test Case
• Abstract Test Case
• Concrete Test Case
• Low Level Test Case
• High Level Test Case
• Logical Test Case
• Test Case Specification
• Test Procedure Specification
• Test Specification
• Test Case Suite
• Test Charter
• Test Design Specification
• Test Interface Specification
• Test Execution Schedule
• Workload Analysis Model
• Test Data
• Test Results
• Test Strategy
• Test Policy
• Test Automation Architecture
• Test Environment Configuration
• Defect Management Plan
• Incident Management Plan
• Problem Management Plan

I knew there was a lot, but this is crazy and I’m sure there are many others that I’ve missed! No project needs this much documentation – Not if they want to get some actual testing done, that is. Lets hope with the aid of a good thinking framework projects can get to a simple set of documentation for software testing.

I’ll upload the material once it’s finished, but if you want to listen in person, you can register here.

Update (08.08.08): I’ve just finished the slides for this presentation and how to whittle down the vast number of possible testing documents into something useful hasn’t made the final version of the presentation.  Instead, it’s focused on how to decide the level of detail we should write our Test Case.  I would’ve liked to cover both areas as they’re a nice link, but with only a 40 minute slot, there’s only so much that can be covered

Update (04.09.2008) : This post (“Simple Test Management: Testing like a Scrum Master”) is a spin off from this original post.

IBM Rational Quality Manager Beta – 1 day to go!

After attending a couple of demos earlier this month at the RSDC, I’ve been eagerly waiting for the IBM Rational Quality Manager Beta to arrive and now there’ s only 1 day to go!!! Looks like we’re going to be getting 8.0 versions of Performance Tester and Functional Tester as well so there’s some serious downloading to be done tomorrow

Should have some initial thoughts to share by the end of the week.

UPDATE:

So it turns out that It is the enhanced versions (v8.0) of the Rational Quality Management point products, like Rational Performance Tester, Rational Functional Tester and Rational Service Tester for SOA that are being released on the 24th of June (today).

Rational Quality Manager and Rational Test Lab Manager are due on the 7th of July. And here was me thinking I was going to get to play with the cool new stuff today