1. Exam examples Tor Stålhane

2. The A scenario – 1 We are working in a small software development company – 10 developers plus two persons in administrative support. Some other developers in our company have developed a set of Java classes that shall be used to extend system ABC – a system that we have already sold to more than a 100 customers. Thus, we cannot tolerate to release the extended system if it contains any serious errors. We have access to all code and all documentation – among other things the use cases, the sequence diagrams and the state charts for all the classes.

3. The A scenario – 2 Some of the methods that are needed to run the extended version of the system ABC have not yet been developed. In addition, two new components – bought from another company – will also be included but are not yet available. We have, however, a complete description of the interface and the services that these two components will provide. Even though we lack some components, we have decided to start testing, since the delivery date is drawing frightfully near.

4. The A problems How we can test the system even though several part are missing. How can we, in an efficient manner, use assertions to increase the benefits of our testing? How can we use an assertion pattern to check that we use the two components that we have bought in the right way, and which pattern should we use?

5. Comments to problem A – 1 Discuss the use of stubs, fakes and mocks. Choose one. Explain why you chose this. Discuss the use of assertions. Choose one. Explain why you chose this. Probably best to use custom assertions and check that the input parameters are in a range that later can be handled in a correct manner.

6. Comments to problem A – 2 Refer to the assertion discussion for the previous question. Interaction assertions will be the best choice. Explain why. Show and discuss a short example, e.g. if we do “A” then the component will return “B”.

7. The B scenario – 1 We are working in a company that specializes in developing software for GUI. We have no domain where we can claim extensive expertise. Instead, we rely on hiring in consultants for each specific domain when we start a new project. The current project shall develop software for a control room. The system will be used to control a steam boiler and the operator’s job is – among many other things – to react correctly on the alarm that will be set if the pressure in the boiler exceeds a certain limit. The customer’s main concern is that this event will occur rather seldom and the operator will thus not have a lot of experience with this.

8. The B scenario – 2 The system will first be installed at one single plant. Later, however, it will be installed in a lot of plants running a wide variety of computer systems. Portability is thus an important requirement for the system. You, as a testing expert, are given the task of defining a test or a set of tests that will give our customer confidence that the high-pressure alarm will be handled correctly.

9. The B problems How will you test that the operators are able to cope with high-pressure alarms, even under conditions of high stress. Describe a test for portability. You might want to use the ISO 9126 definition of portability that can be found in appendix A. Why is it important to define these tests early in the project – may be even during requirements elicitation?

10. Portability – criteria Adaptability: The capability of the software to be modified for different specified environments without applying actions or means other than those provided for this purpose for the software considered. Installability: The capability of the software to be installed in a specified environment. Co-existence: The capability of the software to co- exist with other independent software in a common environment sharing common resources Conformance: The capability of the software to adhere to standards or conventions relating to portability. Replacability: The capability of the software to be used in place of other specified software in the environment of that software.

11. Comments to problem B – 1 Use scenario testing and create a stressful situation for the operator. Set an “high pressure” alarm and check how long the operator needs to react correctly. Use the MbO for each portability criterion. Repeat the process until we reach a measurable and thus testable level.

12. Comments to problem B – 2 Tests need to be defined early so that: –We can start planning early –Include identified testing costs in the project budget –The developers can use the detailed requirements as input when developing the software – e.g. Easy-to-understand GUI Portable code