This article is more than 1 year old

Do you have a mature testing process?

Or is it just an overhead getting in the way of release?

How mature is your testing? Do you slip in a few tests if you have time after the final compile, or are your requirements each defined by a set of tests before you start? Do you review the quality of what you delivered afterwards with a view to doing better next time – or avoid such post-mortems, in case they provide a further opportunity for promoting the guilty and sacking the innocent?

At a roundtable on testing run by Compuware earlier this year (see the blog entry here), I was most interested in the TMMi testing maturity model, and it's about time for an update.

At the roundtable, the Compuware representative, Sarah Saltzman, was (very properly) most reluctant to talk about Compuware products such as QAdirector , which support its approach to risk-based testing – so I arranged to meet up for an update (As a result, I hope to bring you a report on Compuware's requirements management tool, OptimalTrace, in Reg Developer soon).

But I also wanted an update on TMM (or TMMi, Test Maturity Model integrated; the terms seem intechangeable in practice), and how it related to Compuware's own CQMM (Compuware Quality Maturity Model) internal maturity model. In general, I think independent process models are good, because they are less likely to be biased by a vendor's technology choices and capabilities. However, vendor-sponsored models have their place: they help you put tools into a process context and can be easier to deal with when starting out, because the mapping to the vendor's tools should be obvious.

But why doesn't a vendor like Compuware simply adopt an independent model such as TMMi instead of a proprietary model? Well, in this case, probably because Compuware was working on CQMM before it met TMM, but CQMM represents a more pragmatic approach, which may therefore affect a customer's existing process less; while TMMi has a more rigorous ISO15504 evaluation process (and independent evaluation is important). Probably, you need both, and Compuware claims that the two models aren't that different (it estimates a 95 per cent match).

Perhaps the most obvious difference, apart from the fact that TMMi is more accessible (CQMM is hardly mentioned on the Compuware web site, it's the internal framework for Compuware consultancy, it seems) is in the terminology used to describe the stages of maturity:

  • CQMM moves from Chaos to Quality Control, Quality Assurance, Quality Management and finally Quality Governance.
  • TMMi starts at Chaotic lack of process and then moves to Project Specific process, Institutionalisation and Standardisation of process, Quality and Measured process, Optimised and Self Improving process – which map pretty well onto the accepted CMMI maturity levels

Compuware now actively supports TMMi, after a pretty thorough evaluation. Sarah says: "We are very enthusiastic about the collaborative work we are doing with the TMM Foundation. The trustees have some great experience and have done a great job in developing the TMM model. We fully recognise the need for an independent maturity model and believe that the TMM approach fits really well with our quality maturity model. The development of industry standards like this is a really important part of the industry growing up and software quality and testing being taken more seriously within organisations." ®

More about

TIP US OFF

Send us news


Other stories you might like