December 3, 2013

Dear testers: Yes, we model!

BY :     December 3, 2013

RoadsImagine a road network such as the one illustrated here. 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).

The same happens in information systems. Any activity aimed at adding value by improving the system’s quality (testing, maintenance, evolution, process reengineering, 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.

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.

As 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 their 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 obtain 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!

 

Albert Tort

About

Albert Tort is a Software Control & Testing specialist in Sogeti España. Previously, he served as a professor and researcher at the Services and Information Systems Engineering Department of the Universitat Politècnica de Catalunya-Barcelona Tech.

More on Albert Tort.

Related Posts

Your email address will not be published. Required fields are marked *

3 + 2 =


  1. Ben Visser · December 15, 2013 Reply

    Hi Albert,
    Can you elaborateon how the ‘test models’ relate to existing models, created by developers? And can you identity preferred types of models, from a testing perspective?

    • Albert Tort · December 24, 2013 Reply

      Hi Ben,

      Thank you for your interest.

      Both testers and developers need to know the functional requirements of the system in order to perform their work. Developers need to know the expected behavior of the system in order to know what to build and testers need to know the expected behavior of the system to know what to test.

      Therefore, both roles could use the same models since they need the same knowledge. In fact, the idea is reusing and sharing functional knowledge. However, in many situations, functional requirements are not modeled in any explicit and structured form during development and then testers need to “recover” these knowledge by experimentation. Even in case that functional requirements are modeled in development phases, these are not validated. Testers can validate them as they design test cases that can be used not only to test the system but also the modeled knowledge by executing test cases on the (previously created or recovered) model.

      Any kind of model aimed at specifying functional requirements can be use: From an structured textual description to models specified in a specialized/formal conceptual-oriented language (such as the Unified Modeing Language promoted by the Object Management Group). When using structured modeling languages, then automated validation and simulation techniques are applicable.

  2. Geert Vanhove · December 16, 2013 Reply

    Hi Albert,

    Another question: how do you cope with testing a system which has a lot of interfacing and dependencies with other systems? Are the models you use being fit for this integration? In today’s world, testing integration of systems if often more challenging than testing one (isolated) system. So we need to relate different models with each other? Who is best positioned for this?

    • Albert Tort · December 24, 2013 Reply

      Hi Geert,

      When developing/validating a model it is required to define its scope according to the project context. Certainly, a model may require knowledge of other dependent systems that is outside the scope of the model. If the models of external systems are not available, this external knowledge can be used in our models by mock-ups. This is the same technique used in system testing when we need to use unavailable dependent external functions that are not part of the testing scope.

    • Albert Tort · December 24, 2013 Reply

      Hi Geert,
      When developing/validating a model it is required to define its scope according to the project context. Certainly, a model may require knowledge of other dependent systems that is outside the scope of the model. If the models of external systems are not available, this external knowledge can be used in our models by mock-ups. This is the same technique used in system testing when we need to use unavailable dependent external functions that are not part of the testing scope.

*Opinions expressed on this blog reflect the writer’s views and not the position of the Sogeti Group