1. Software Testing and Quality Assurance
Lecture 18 - Test Analysis & Design Models (Chapter 4, A Practical Guide to Testing Object-Oriented Software)

2. Lecture Outline
Testing Specific Types of Models

3. Testing specific types of models: requirements model
Acceptance testing often finds faults that result from problems with the requirements
(missing requirements, contradiction in requirements).
There is no UML model on which the requirements are based,
so comparison to the basis model refer to documents produced by marketing, system engineering or client organization.

4. Testing specific types of models: requirements model (cont...)
Outline of testing the requirements models:
Develop the ranking of use cases by computing combined frequency and criticality information for a use case.
Determine the total number of test cases that can be constructed given the amount of resources available.

5. Testing specific types of models: requirements model (cont...)
Ration the tests based on the ranking
Write scenarios based only on the knowledge of those in the domain expert’s role
Check for completeness, consistency, and correctness

6. Testing specific types of models: requirements model example (cont...)
Use
Frequency
Criticality
Combined value
Rank
Number of test cases
Start Brickles
Medium
High 1 3
Pause Brickles
Low
Stop Brickles 2
Break brick
Wins
Loses

7. Testing specific types of models: requirements model (cont...)
Criteria for requirement inspection:
Any system functionality is specified in the same manner everywhere it is described.
Consistency
Each use case accurately represents a requirement.
Correctness
The use cases represent all of the functionality needed for a satisfactory product. No use case is needed that is not required functionality.
Completeness
Interpretation for domain modeling
Criteria

8. Testing specific types of models: analysis models
Domain analysis model
Application analysis model
A domain model is a representation of the knowledge in a domain as seen through the eyes of a set of domain experts.

9. Testing specific types of models: analysis models— domain analysis model
Two groups are formed:
Group one: developers group ―creates the domain model
Group two: testers and domain expert group ―serves as testers of that model. (this group creates the test cases of the model).

10. Interpretation for domain modeling
Testing specific types of models: analysis models— domain analysis model (cont...)
Criteria for domain analysis model inspection
Model elements should be consistent with company’s definitions and meanings
Consistency
The description of domain concepts are accurate; the algorithms will produce the expected results
Correctness
The concepts are sufficient to cover the scope of the content specified. Sufficient detail is given to describe concepts to the required path.
Completeness
Interpretation for domain modeling
Criteria

11. Testing specific types of models: analysis models— application analysis model
Multiple domain models contribute to the single application analysis model.
Criteria for application analysis model inspection.

12. Interpretation for domain modeling
Testing specific types of models: analysis models— application analysis model
Where there are multiple ways to represent a concept of action, those ways are equivalent
Consistency
Experts agree with the attributes and behaviors assigned to each concept; on the steps in each algorithm; major states for each conceptual entity.
Correctness
The ideas expressed in each use case can be represented by the concepts and algorithms in the model. No design information is included in the model.
Completeness
Interpretation for domain modeling
Criteria

13. Testing specific types of models: design models
Architectural design model: provided the basic structure of the application by defining how a set of interfaces are related.
Detailed class design model: provides the precise semantics of each class and identifies the architectural interface to which the class corresponds.

14. Testing specific types of models: design models— architectural model
The architectural model is the skeleton of the entire application.
Non-functional requirements are blended with functional requirements.
A software architectural model is the basic structure that defines the system in terms of computational components and interactions among those components.

15. Testing specific types of models: design models— architectural model (cont...)
Representations of the architecture:
To represent an architecture:
Relationships
States
Algorithms
Tool support: Rational Rose performs a variety of consistency checks on the static-relationship model.

16. Testing specific types of models: design models— architectural model (cont...)
Consistency checks will prevent certain types of connection from being established.
However, it is not sufficient for determining whether the functionality is correctly implemented
Architecture description languages provide the capability to represent a system at a high level of abstraction (e.g. Rapide)

17. Testing specific types of models: design models— architectural model (cont...)
Testing the architecture:
The Software Architecture Testing (SAT) technique is a special type of guided inspection that requires the following steps:
Test cases are constructed.
The tests are conducted on the product
The results of the test are evaluated for correctness.

18. Testing specific types of models: design models— architectural model (cont...)
Constructing test cases:
Test cases are constructed from the use cases.
The test cases for the architecture are defined at a higher level than more detailed design models.

19. Interpretation for the architectural design model
Testing specific types of models: design models— architectural model (cont...)
Criteria for the architectural design model inspection:
Each use of the system can be handled only in one set of interfaces.
Consistency
The architecture satisfies its constraints; uses the appropriate architecture patterns; represents the interactions between interfaces.
Correctness
A sufficient set of interfaces are defined to provide all of the services needed for the application’s functionality. The relationship between the interfaces allows for the flow of control and data necessary to realize all of the uses described in the use case diagram.
Completeness
Interpretation for the architectural design model
Criteria

20. Testing specific types of models: design models— architectural model (cont...)
Test execution:
Test cases are executed by constructing a message-sequence diagram.
The diagram reflects preconditions for a test case.

21. Testing specific types of models: design models— architectural model (cont...)
Verification of results:
When the output from the test is in the form of diagrams, the resulting diagrams must be verified after each test execution by domain experts.
When the output is the result of an execution, the test result can be verified by having those domain experts construct event sequences that would be produced by an architecture that performs correctly.

22. Key points Testing the requirements models:
Develop the ranking of use cases by computing combined frequency and criticality information for a use case.
Determine the total number of test cases that can be constructed given the amount of resources available.
Ration the tests based on the ranking
Write scenarios based only on the knowledge of those in the domain expert’s role
Check for completeness, consistency, and correctness

23. Key points
A domain model is a representation of the knowledge in a domain as seen through the eyes of a set of domain experts.
Multiple domain models contribute to the single application analysis model.
Design models
Architectural design model
Detailed class design model

24. Announcement
Quiz # 3
Saturday November 22, 2008