With the growth of applications complexity, the amount of variation points and the number of possible combinations among them can be considered as a problem to be concerned with, specially surrounding the creation of test assets that handle many variations. This context depicts a tradeoff between testability and the number of variabilities a product line contains.In this context, we have just finished a systematic review on Software Product Line Testing (SPLT) which covers, among many other issues regarding this interesting research topic, variability testing concerns.
It is worthwhile to mention this aspect has been gained special attention among the SPLT researchers since this is not a very mature topic with many "open questions" to be addressed.
Following we illustrate the summary of important studies we have collected on this topic, presenting the effort devoted to solve this problem.
One proposes a solution, the cumulative variability coverage which accumulates coverage information across a series of product line instance development activities, to be further exploited in a target testing activities for product line instances. In another solution, constraints are placed into the product line architecture. Instead of having components with large amount of variability, for testability improvement commonalities and variabilities must be separated and the variabilities must be encapsulated into subcomponents. The objective is to reduce the retest of components and products when modifications are made so that independence of feature and components as well as the reduction of side effects are important. Other proposes to establish a coherent traceability from requirements to implementation and test assets. There are some ways to achieve this traceability between test assets and implementation, where the mechanism used in the product to implement the variation can be appropriate for implementing the test software for that portion of the software.
Furthermore, our intention regards to figure out how the SPLT approaches tackle variability along the software lifecycle, even though we have not gained answer to this question yet by reading and analyzing these and other studies. This can indeed be an extra research question to be addressed in future work!
3 comments:
Ivan and Paulo, do you think that variabilities implemented using different techniques such as AOP, Inheritance, and so on are going to be tested in the same way? What about the feature type (optional, or exclusive, or and so on), does it have to be considered during testing? In your opinion, do you think that you need to test all the variants separately? I really can't imagine how variability is going to be tested, can you give me a brief and possible way to do that? If you already have the answer let me know :)
You retract in this post the preoccupation with variability testing, and illustrate some propose of solution, but a questioning wich have is about how you deal commonality testing, factor whose defect will affect all applications.
Ivan, do you think that test cases in single systems has the same effect as in a software product line including the variation points?
This question is a resume of what i think that the marcela's post asking about...
Post a Comment