Bad Dog!

Bad Dog!

There are criticisms of the TMMi. Reference models attract criticism for many reasons, but most criticisms emerge either because of the philosophy of the model or poor implementation.  In all cases, even though the criticisms are real, all of the potential issues that generate those criticisms are avoidable.  The typical criticisms of the TMMi are:

  1. The model is heavy.  The TMMi presents a framework that covers a full range of processes, activities and tasks required for pretty much any testing organization.  The model seeks to cover the entire spectrum of verification and validation.  Taken at face value, the model is huge which gives the model user (or casual reader) the perception that the model is heavy.  The omnibus coverage philosophy represents best practices to cover as many situations as possible.
  2. The model becomes the goal.  This criticism is related to the perception that the model is heavy. In some cases model advocates get over enamored by the breadth of the model and decide that every step, every activity and task is needed to satisfy the model.  Outsiders see this as the model specifying how work is being done rather than guiding the process.  This criticism is typically caused by poor training in how the model should be properly implemented.
  3. The TMMI slows process experimentation. This criticism is the outcome of here are the rules and do not deviate  implementation approach.  The implication is that  there is only one way to approach any problem and that the model implementation represents that approach.  This is purely an implementation problem.  One process cannot deal with all issues in a complex organization.  Process areas and practices noted in the model are a framework and not a specific blueprint for how to perform testing.  Exploration of new ideas is critical for growth.  Nothing in the model or model philosophy precludes experimentation and continuous process improvement.
  4. Application of the TMMi puts up barriers between testers and developers.  Waterfall methods typically leverage a production line model in which specialties complete their tasks then pass the partially completed deliverables to the next specialty.  For example, the flow might be from business analyst to designer to developer to tester.  The TMMi can be implemented in that manner but the TMMi can just as easily be implemented in a cross-functional Agile team. Organizational implementation philosophy is the driver rather the model’s philosophy.
  5. Model capability and performance are not linked.  Reference models reflect a philosophy that standard processes lead to performance.  The TMMi is no different than any of the other standard reference models.  I consider this philosophy a belief, like the belief in something were there is no tangible, measured proof.  Quantitative data is critical to understand whether any process is efficient or even effective.  The linkage must between performance and capability must be proved for every iteration.

All of the typical criticisms of the TMMi can be valid, however most of the discussions of the criticisms fail to reflect that most of the issue driving those criticisms are self-inflicted through the implementation.  Practitioners, methodologist and managers must remember that the goal of any implementation of the TMMi (or any reference model) is to deliver value to the organization rather than just to “do” the model. In all cases these criticisms can be mitigated by viewing the TMMi as a framework for change rather than an explicit recipe that requires each step be performed in one precise manner.

Advertisements