English version

For my first contribution to the Spanish TMMi chapter, I thought I would provide a light-hearted look at my career and share some  thoughts on doing good testing!

Many years ago (1991 to be exact), I started my career in software testing. In those days, testers were kept out of sight and only involved at the end of projects to state “it works!”. Life as a tester was a lonely job and I thought I was unique in wanting to test (better). No email, social media, internet as we know it today; I thought I was on board StarTrek on a voyage into the unknown!

Then all changed! At the inaugural Eurostar testing conference in 1993 I found out there were many lonely testers bedsides myself and this started a journey of recognition of testing as a mainstream career in the IT industry. Rightly so as verification and validation testing activities even today will take up between 40-80% of project budgets; a good reason to get it right and (continuously) ensure test activities are increasingly effective and efficient!

Testing is not new though; who owns a copy of “Software Testing Techniques” by Boris Beizer first published in the 1980’s? However, as testing methods, processes and techniques evolved, we in the industry realised that what was needed was a model defining the generic requirements of a good testing process structured in progressive levels of capability. I, together with other founding members, established the TMMi Foundation. The first deliverable made available to the testing fraternity was The TMMi Model (later, they made available their own assessment method, TAM, accompanied by formal training packages for Assessor and Lead Assessors).

The TMMi model is deliberately written defining the generic requirements of a good testing process are, the “what” a process should do. It does not define “how” the generic requirement is undertaken for any particular Software Delivery Life Cycle (SDLC) or, more importantly, how Organisational Units (OUs) satisfy the requirements. It is for the assessors to interpret how TMMi requirements are undertaken by OUs and then ensure that satisfaction of TMMi requirements  is achieved and is fit for purpose.

Form my thinking though, a standard reference model that is used to measure a test process capability should not just be used to measure the current, static, capability. It should also be used by organisations to identify ways to improve the efficiency and effectiveness of the testing process as well.

Progressive test process maturity should be reflected in levels of capability of the testing process;

    1. Demonstrate the requirements are satisfied and find defects
    2. Find defects early and remove cheaply
    3. Prevent defects from appearing

This is reflected in progressing from TMMi Level 2 up to TMMi Level 5; Simple really!

Do not forget that we should also be ensuring that the testing and quality related processes are also improved to ensure that test and test related quality activities are increasingly effective and efficient! An OU certified to TMMi level 2 should look to improve; not just stay at TMMi level 2!

Measurement is a very important element in the test process for many different reasons. Measurement can also greatly assist in communicating what is happening today and identifying where things can and should be improved but this is for a separate paper coming soon!

Before I finish though, a few words on the human ability to complicate everything! In my opinion, life should be simple; if you complicate the process, you increase the risk that the users of the process will try and avoid following the (complicated) process!

Let us look at the mental approach to “why test?”. We often come up with complicated answers but, traditionally (and still prevalent today), the answer is;

“we test to demonstrate that what should happen does and what should not happen does not.”

This approach uses requirements and other documentation to identify what to test. This is the same source documentation used by the thinking process of requirements analysts and software developers to develop the software. The probability that, what is documented and developed based on that documentation is developed as stated and will work as documented. Further, testing will only confirm that what is documented and developed from the documentation works as stated!

A much better answer to the question is

“we test to demonstrate what should happen does not and what should not happen does!”

With this approach, testers are thinking about what could happen which has not been thought about by users, business analysts or developers etc. This has a much better probability of finding defects that have not been thought about by software developers; trust me it is statistically proven!

In closing, I was asked a question at a conference in 1995 and my response is still valid even today.

What makes a good tester?

A good tester has a highly logical brain which, at the same time, is severely corrupted by lateral thinking!

Translated, test for what is obvious and documented and, at the same time, look for what nobody has thought about!

 

Brian Wells
12 February 2021

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos requeridos están marcados *

Publicar comentario