OVERVIEW OF THE PROCESS

specific software, and their interactions, conducted within the context of other disciplines (McGregor,2001b). Hence, the RiPLE-TE was developed in order to support testing in the both SPL phases: Core Asset and Product Development. Figure4.1depicts the main flow of the RiPLE-TE.

Figure 4.1 RiPLE-TE main flow.

With the results gained through performing the systematic mapping study (as presented in Chapter3), we decided to adopt two different processes for testing in SPL, considering the peculiarities of each phase. In Core Asset Development, when assets have to be developed with a special attention to the forthcoming reuse, we advocate that unit and integration testing levels should be performed, whereas system and acceptance testing have to be postponed to Product Development, where the assets previously developed will be reused.

The purpose of such a division is linked to the role of testing in every phase, and it is in line with other approaches, such as (McGregor,2002). In Core Asset phase, assets are produced from scratch, while in Product Development these are instantiated into products.

Therefore, in a first moment testing should be concerned about evaluating assets from its initial development effort. If we think about testing levels, the initial effort should be devoted to unit testing. Yet, as we are dealing with a component-based development strategy (CBD), the SPL approach, here components act as ’units’. Thus, in order to ensure that a component may be further reused, it should be tested, under planned conditions. Although coupling and cohesion are considered the cornerstones in modular software development, provided by CBD, in practice it is quite normal to work with tightly coupled units. In these cases, after performing unit tests in a component, and ensure that it fulfills what it was specified to, integration tests are

4.1. OVERVIEW OF THE PROCESS

then performed.

We advocate the use of both testing levels since they are responsible for detecting different types of faults. Whereas unit testing independently tests methods, classes, and the interaction among these pieces which comprises a component, integration testing is responsible for testing the interaction among components interfaces and the integration between modules.

After unit and integration tests have been executed, the role of testing in core asset devel-opment phase is over, since the set of conditions to enable further reuse of components has been reached. In short, Core Asset tests try to minimize the Product testing. It can be achieved through preserving variability in core assets to facilitate reuse.

Next, in Product Development, the phase in which products are instantiated, integration testingis performed once again. But how come to perform integration tests again? Given that our purpose is to avoid repetition and thus consequently to reduce the overall testing effort, in CAD it is only necessary to perform the integration between tightly coupled units, regardless integrating the whole set of components. It is even advisable due to the behavior of the core asset base, in which there are several components, attending to a diverse range of variations, that not necessarily integrate with each other, but indeed should be ready for future integration, in PD.

This is when integration testing in PD takes place. At the moment of the product derivation, a set of components is selected from the core asset base. We have already ensured that individually the components are working as specified, as well as the integration among tightly coupled ones.

Then, it is time to test the integration of the larger set of components which will comprise the product, in order to ensure the workability of the interconnected modules as well.

Next, it is system testing time. This level is then focused on evaluating the product as a whole, against the requirements previously defined.

Acceptance testsare carried out after system testing, in order to receive customer feedbacks on the product just instantiated. The acceptance tests must be planned carefully with input from the customers and users. Acceptance test cases are based on requirements.

Figure4.2presents the RiPLE-TE expanded view on the interaction among testing levels and the SPL phases: (i) core asset, represented by the activities horizontally aligned on the top;

and (ii) product development, represented by the activities horizontally aligned at the bottom, so that we can give readers an overview on where this proposed process fits. This Figure shows a broader view of the process that will be, throughout this Chapter, detailed.

It is valid to mention that RiPLE-TE allows that unit tests may be performed during Product development. It is possible in cases in which a new requirement or feature is probably to be included in a specific product that does not belong to the Core Asset base yet. As long as

4.1. OVERVIEW OF THE PROCESS

Figure 4.2 Interaction among testing levels and SPL phases, in the context of the RiPLE-TE.

this new artifact is produced, and new code is developed, unit tests is then performed. But instead, whenever it occurs, we strongly recommend to use the RiPLE-EM activity (Oliveira, 2009) related to the propagation of assets, in which every new artifact that, at an initial moment, pertains to only one product, should be included in the core asset base, since reuse is motivated.

It eases the assets management. It is truly easier to maintain and evolve assets in the same base, than having different assets spread into different products.

In addition, with such a propagation we are in line with the purpose of unit testing (McGregor, 2001b), (Clements and Northrop,2001), that should be performed in Core Asset development, as soon as the core assets are being developed and their quality must be assured before instantiated into derived products.

The RiPLE-TE was modeled using the Eclipse Process Framework (EPF) Composer², a process management tool platform and conceptual framework, which provides an easy to learn user-experience and simple to use features for authoring, tailoring, and deploying of development process frameworks (Haumer,2007). The EPF Composer is an eclipse-based open source tool, available for free under the Eclipse Public license at the EPF homepage. The OMG SPEM (Software Process Engineering Meta-Model)(OMG,2008), which defines a formal language for

2EPF Composer homepage - http://www.eclipse.org/epf/