Page 237 -

220 Chapter 8 Software testing

Weather
Information System

SatComms WeatherStation Commslink WeatherData

request(report)

acknowledge
reportWeather( )
acknowledge get(summary) summarise( )

send(Report)
acknowledge
reply(report)

acknowledge

occur. If you have developed a sequence diagram to model the use case implementa-
Figure 8.8 Collect
weather data tion, you can see the objects or components that are involved in the interaction.
sequence chart To illustrate this, I use an example from the wilderness weather station system
where the weather station is asked to report summarized weather data to a remote
computer. The use case for this is described in Figure 7.3 (see previous chapter).
Figure 8.8 (which is a copy of Figure 7.7) shows the sequence of operations in the
weather station when it responds to a request to collect data for the mapping system.
You can use this diagram to identify operations that will be tested and to help design
the test cases to execute the tests. Therefore, issuing a request for a report will result
in the execution of the following thread of methods:

SatComms:request → WeatherStation:reportWeather → Commslink:Get(summary)
→ WeatherData:summarize

The sequence diagram helps you design the specific test cases that you need as it
shows what inputs are required and what outputs are created:

1. An input of a request for a report should have an associated acknowledgment.
A report should ultimately be returned from the request. During testing, you
should create summarized data that can be used to check that the report is
correctly organized.
2. An input request for a report to WeatherStation results in a summarized report
being generated. You can test this in isolation by creating raw data corre-
sponding to the summary that you have prepared for the test of SatComms and
checking that the WeatherStation object correctly produces this summary. This
raw data is also used to test the WeatherData object.