1. Applying Use Cases (Chapters 25,26)
Sriram Mohan

2. Outline Use Cases in Design and Implementation
From Use Cases to Test Cases

3. Tracing Requirements to Design
Some Requirements can be easily traced to code
Orthogonal Design Problem
For instance, if a feature mostly involves interaction between the software and one or more actors, the use case events correspond well with the steps of the implementation algorithm. When quality requirements or complex data structures are involved, the design does not follow as directly. When the form of the requirements and the form of the design and implementation are different, we say that their correlation is orthogonal. We need to worry about this, because it is easier to test those requirements when they are directly mapped to code.
For instance, the system must check to ensure the username follows established convention can be easily tested. However, if the requirement states that the system must be able to handle transactions, then it is difficult to verify this requirement. This is mostly true for performance requirements. Performance requirements do not depend on the logical structure of the code, but might depend on the data structure that is used and how the various system code interacts. This makes performance requirements difficult to verify. This is important, because good system design should be driven not by how easy it is to map requirements, but by other important factors.

4. Solving the Orthogonality Problem
Object-oriented design
Well written use cases
Modeling Software Systems
OO hides architectural problems, along with other “detail”. It is a representation of the real world object and even if the underlying process changes, the real world abstraction doesn’t. Other OO principles such as inheritance, information hiding help as well.
Itemized requirements can sometimes be a problem, because in some cases, different parts of the system must interact in order to achieve that functionality. However, well written use cases, do a better job of providing the behavior of a system in sequential fashion, complete with alternate flows.
Software systems are complex and they can be embedded in other complex systems. There might be complex interactions. It is difficult to keep track of the entire system, so we model to provide something that we can understand. What is commonly done is to abstract the system into a simplified model, removing the minute details. The model should help us understand the system. The model should be carefully selected to ensure that it doesn’t misrepresent things and lead us down the wrong path.
Many different aspects of the model can be modeled. Concurrency, logical structure, data flow, the interaction between the models etc. Together these various models will help us get a better view of the system structure.

5. Solving the Orthogonality Problem
A potential solution: comes from software architecture
The software architecture helps us understand
“what the system does and how it works, how the elements interact, and what type of patterns and pieces or the system are involved”
The software architecture helps us
Understand what the system does
How the system works
Extend the system
Reuse parts of the system
Typically, we have built systems like this before or there are other people who have developed systems like this before, we need to look at these and our experience.

6. Solving the Orthogonality Problem (continued)
Architectural views :
Logical (for users)
Implementation (programmers)
Process (integrators)
Deployment (system engineers)
Use-case view (designers/testers; ties things together)
Different groups of stakeholders need to consider your model from differing perspectives. So we use the 4+1 view. The logical view talks about the system functionality. It gets into the logical substructure of the system in terms of subsystems that drive the functionality of the system.
The Implementation view is targeted at programmers.
The process view talks about non-functionality requirements and in case of multi-threaded system, it can be used to model the various processes that exist and how they interact. They can be used to deal with concurrency issues etc.
The deployment view talks about how the system will interact with the external environment, other systems etc. It is not concerned with what the interactions are, but that when there is interaction there are constraints that need to be met.
More details in the software architecture class.

7. Extra Credit
How are use cases realized in the design model? Read Chapter 25 and submit a report. Please submit it via (Angel – Weekly Content – Extra Credit – Week 05 – Use Case Realization)

8. Outline Use Cases in Design and Implementation
From Use Cases to Test Cases

9. Questions before Testing
What is this system supposed to do?
What are the things that can go wrong?
How does the system respond?
How do I create and record testing scenarios?
How do I know that the system has been tested completely?
Is there anything else the system is supposed to do?
Typically, the testers are provided with a minimal set of specifications, or not. But in either case, the testers must view the system as an unknown, a black box that needs to be tested. While reasoning about the task, each tester must think about these questions
Use cases are not testing cases, but go a long way in answering the above questions. With it detailed listing of all interaction scenarios, it can help describe the various things the system can do. With its description of the basic flow and the alternate flow it can be used to talk about things that can go wrong. With pre and post conditions it helps describe the various states of the system and also describes the various supplementary specs.
The use case technique builds a set of assets that can directly drive the testing process.

10. Testing Terms Test Plan Test Case Test Procedure Test Script
Test Plan contain information about the purpose and the goals of testing within the procedure and the various strategies of testing
Test case is a set of test inputs, execution conditions and expected results developed for a particular objective(maybe a program path)
Test item – The item being tested
Test procedure – a set of detailed instructions for the setup, execution and evaluation of a test case
Test Script – a software script that automates the execution of a test procedure.

11. Test Plans
The use cases each become multiple test cases in the test plan.
The test cases form the foundation on which to design and develop the test procedures. The depth of testing depends on the number of test cases, The use cases provide the input to the process and the biggest work in testing is actually developing the test cases. The use case with their scenario based approach makes the development of test cases a lot easier.

12. How do we use the use case?
Steps in creating a test case:
Identify use-case scenarios (basic and alternate flows)
Identify the test cases
Identify the test conditions
Add data values to the test case

13. 1. Identify the Scenarios
Identify the various paths through the system
As the test cases become more and more complex, more and more scenarios will result. In many situation, the tester will need to devise a strategy that recognizes that it is impractical to test all the possible scenarios, but still ensure that adequate testing is achieved. It is important for the tester to realize that the use cases may not be comprehensive. The test teams review process might reveal additional scenarios from executing the use case. If this is not covered by design, then you have to make sure that the design is modified as well.
Scenario Number
Originating Flow
Alternate Flow
Next Alternate
Next Alternate..

14. 2. Identify the Test cases
More than one test case can occur from each scenario. For instance, based on the input the expected result could be different.
Test Case ID
Scenario
Description
Expected Result
Actual Result
If this is the case(data values triggers different test cases for a particular scenario), the test case must explicitly identify the data values.

15. ¾.Identify Conditions and Populate table
Test Case Id
Scenario
Description
Cond. 1 2 3
Expected Result
Actual Result
Without the actual data values, this table doesn’t really make sense. In some cases, we may not know the actual values and we have to look at supplementary specifications to find them. In some cases, it might be we end up with a data range instead of data values.
Use as many conditions as necessary for a use case,

16. Some final remarks How much do we test?
Black box testing tests the functionality. What about the internal design decisions?
With the amount of test cases that have to be tested, we have to look for tool support and most IDE’s come with some help for this. Even then it is a lot of work. Typically depending on time, not all cases can be tested. Usually only the most critical cases are tested. This is done by choosing the one that is either the primary user interface, has a particularly important architectural component, just the priority. You have to establish a fine balance between the cost, risk and necessity of verifying the use case.
Internal design decisions are tested by testing the white-box behavior of the system.