The analogy of the iceberg or where the biggest benefits could be gained by doing QA

1                       Introduction

It is not a surprise to find examples, even from inside of several IT organizations, of people referring to quality activities as only ”testing”. However, testing is (or should be) an important part from a whole known as ”Quality Assurance”: while testing is a process that provides information about quality and related risks, QA contains all the planned activities used to ensure that a system meets the requirements of quality.

Also, it’s quite accepted all the benefits that are gained by starting quality activities as soon as possible (even from the beginning of a project!), and not only when test object has been delivered and it’s ready for test execution. In fact, following this last strategy could lead us, sooner or later, to important issues with the developed product, or even with the same development process as well. Therefore, QA should be the driving force behind the quality of both the project and the process. Let’s try to explain, with a simple analogy how this can be reflected in the real life.

2                       Influence   of an early start of test activities

As is evidenced in IT projects, the most visible part of a quality assurance process is the actual execution of the designed test cases. However, this does not means that test execution is the only remarkable activity to be performed in a well-established QA process. Furthermore, there are several important activities that should be performed before and after test execution to obtain the best possible insight into the quality of a developed product.

These activities would be the ones that are hidden from view, but nevertheless is where the biggest benefit is gained for the whole organization. That division between ”visible” and ”hidden” QA activities can be seen as an iceberg (as defined by TMAP® Next1), in which test execution remains at the top and rest of activities are out of sight. This analogy also help us to explain the importance, in terms of time and quality of an early involvement of QA, within the development process:

Figure 1: Iceberg analogy contained in TMAP® Next, that split QA activities

in Planning, preparing and measuring (test execution).

– Visible part is only a small portion of the total size of the

QA activities, excluding test execution, often involves significantly more than half of the total time (an average of 60% as stated by some studies) actually used in all the process.

– The hidden view will determine the robustness of tip of the iceberg. Early involvement of QA, that should start a long time before the developed product is ready for extensive testing, would have several benefits that can summarized as follows:

• Preparation of test execution can be done timely before test object is delivered, what makes testing be on the critical path of the development process as briefly as This will reduce what we know as ”time-to-market” (TTM).
• Total cost of development process could significantly decrease: even though it may seem strange (as the immediate effect is an increase of costs), early involvement of QA could save big amounts of money, as critical defects could be found in early stages of the process (even when the defect still not exist in the product) with a minimum As it’s easy to see, it’s quite more expensive to found and fix a defect, when, for example it’s already on production instead of discovering it when it’s only in requirements document.
• Quality of the product and the development process could be much better: effects will be consistent and long lasting if QA activities are started as early as possible (preferably at project initia- tion) and it’s also included throughout all the process . This will not be reflected by finding defects early, as mentioned above, but also in several other QA should be an essential part in several other activities within the Software Development Lifecycle (SDLC), from a product and process point of view:
  • QA must be a fundamental part in three main activities before a system is developed: define scope, create, edit and update requirements and user stories and collaborate in building-up of a functional design. The benefit could go further in software development methodologies like Agile, in which changing SCRUM teams could benefit from global vision from QA.
  • Experience and knowledge from QA will benefit all SDLC, as QA could help to ensure that all development teams are performing their job efficiently by following strict quality requirements.

• QA will work proactively in benefit of the process: an unwanted later involvement of QA will lead us to time pressures, ineffectiveness and inadequate quality of the test process. In this context, QA will not be able to focus on continuous improvement of development process, something that will be easier to achieve with a real participation in every important stage of the lifecycle.

An early involvement of QA should be seen as a long-time investment, that would allow us to see quick effects in the short term, due to its global vision. Those effects would be significantly bigger when the development process is gaining maturity due to a shared effort of all parties involved, including both QA and rest of development department.

1TMAP® Next defines a standard approach for structured testing

Más información

Isaac Álvarez Diz – Test Lead – Sogeti España

 isaac.alvarez-diz@sogeti.com