Principios QA & Testing

Dear testers: Yes, we model!

Imagine a road network such as the one illustrated as follows. This system becomes more complex as new roads are built. In order to be useful for users, the system requires maps (i.e. models). Otherwise, its value decreases since users are not able to know how to reach their destinations from their source points (unless they have indeterminate time to experiment without taking care about efficiency).

albert- yes we model

The same happens in information systems. Any activity aimed at adding value by improving the system’s quality (testing, maintenance, evolution, process reengi

Conceptual modeling is an essential technique to support knowledge management. Take a look around. In many technical and scientific areas, humans usually use models to structure thinking: We use maps (i.e. models) when we travel abroad; we cannot imagine constructing a building without blueprints and plans (i.e. models); scientists are trying to find out the map (i.e. the model) of the human genome; weathermen simulate (i.e. they model) the expected weather behavior; industrial processes are modeled and automated to guarantee quality results, etc.neering, etc.) requires knowing the functional requirements of the system. This is the reason why structured thinking and analysis are key skills in software engineering.  In contexts in which there is no documentation on such requirements or it is not available, structured thinking is even more critical, especially when reverse engineering needs to be performed.

In particular, testers we also need to continuously managing knowledge about the functional requirements of a system. As we perform testing activities, we continuously think about implicit models of the expected behavior, although sometimes these models only persist (for some time) in our minds. Otherwise, we would not be able to perform quality testing, because we need to know what behavior needs to be checked. And in order to check the behavior, we need to find out what is the expected behavior (i.e the requirements).

Making models explicit is pointed out as a necessity each time that, for example, testers write down on their own sketches to improve its understanding of the system under test. However, in contrast with other traditional disciplines, software engineering contexts suffer a lack of tools, methods and case studies to support conceptual modeling. “The shoemaker’s son always goes barefoot”…

Models always exist, but in different levels of formalism: from those that are only implicit in the mind of each professional to those that are explicitly specified in some accessible and persistent support (in the form of informal sketches, natural language documents or explicit models specified in a conceptual-oriented language). When models are explicitly specified in a structured language, then, knowledge management capabilities can be automatically supported if adequate tools are available. In testing, the benefits are great if we achieve the last situation, because the better we know the system, the better we perform testing.

Over the last decades, software has become an intrinsic part of business and society in a wide diversity of domains and, consequently, software errors have great impact on economy.  As systems become more complex, assisted and structured modeling for improving our quality services is a near-future investment in order to reduce risks such as rethinking, reworking, requirements conflicts and loss of knowledge. The more explicit and structured are our models, the more opportunities to validate, share and reuse the functional knowledge of systems are possible. When we model, we are forced to think in a less-ambiguous way. And if something remains non-clear, the necessary questions arise because of the necessity of completing the model. Investigation, requirements discovery, clarification of uncertain situations,… are also, in fact, main tasks of testers that conceptual modeling may help to improve.

A particular application of conceptual modeling is the assisted generation of functional models and documentation within the testing process. In Sogeti Spain we are working on this aim since testers use systems by experimentation every day and, by the way, they incrementally find out the functional requirements of the system under test. Generating functional models within the testing process allows to automatically obtaining documentation that can be used by project stakeholders (including the testers) because a knowledge repository (continuously validated and evolved) about the system becomes available. The aim is not only performing more testing, but also performing better testing.

It’s time to contribute to the challenge of providing better integrations of modeling in our quality services and to provide facilities to put them into practice. In testing, modeling reveals that from errors we learn, and by learning we find more errors. Testers are experts in both errors and learning. Therefore, dear testers: Yes, we model!

Acerca de Albert Tort

Albert Tort es CTO de Sogeti España (grupo Capgemini). Anteriormente fue investigador y profesor de la Universidad Politécnica de Cataluña, donde actualmente es también coordinador del posgrado en Software Quality Assurance. Es especialista en ingeniería de requisitos, modelización conceptual, calidad del software, testing e inteligencia artificial. Su tesis doctoral fue titulada "Testing and Test-Driven Development of Conceptual Schemas” y es autor de diversas publicaciones relacionadas con la ingeniería del software.

2 comments on “Dear testers: Yes, we model!

  1. Requirements are the base for development, maintenance and quality assurance activities. We cannot develop a system without knowing what to build; we cannot check the quality of a system without knowing the expected behavior; etc. Therefore, conceptual modeling should be performed as early as possible in the system’s lifecycle and continuously reused and evolved. However, nowadays, in many software development contexts, requirements are not explicitly specified (textually or using specialized models), and when these knowledge is required to be known by other people, then it needs to be recovered (usually with a higher effort produced by rethinking, renegotiation, reverse engineering,… ).

    Requirements specifications in the form of models allows sharing requirements knowledge in a less-ambiguous form and validating such knowledge. But, in fact, this is what requirements engineering is aimed for. Conceptual modeling is only a support for better performing this key activity.

    Really, making requirements explicit and defined in a common language/model forces to invest more time to define and clarify knowledge, but the value of explicitly specified requirements ireduces future requirements errors (that usually appear later), allows to apply automatic and semi-automatic validations, anticipates conflicts, and contributes to minimizing the risk of rework.

    Nowadays there exist several tools aimed at drawing conceptual models as UML diagrams and some of them allow to check its syntax (I think that a wide list can be found here: However, I also think that efforts to provide tools that perform better validation and model simulation are needed to take the most of it.

    Me gusta

  2. Nice post on conceptual modeling, But how much time do u take on it, and when do you do this modelling : Any tools you use to picture out ?

    Me gusta

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de

Estás comentando usando tu cuenta de Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: