Integration Testing Use Cases from the Data's Perspective

In previous posts we looked at how to use a C.R.U.D. matrix to determine if there were any use cases we might want to add to the use case diagram to improve test adequacy. We noted that the process of working through the C.R.U.D. matrix was an important as the matrix itself, providing “Ah, Ha!” moments with valuable insight into the testing of the product. When completed the C.R.U.D. matrix was essentially a high level test case for the entire system, providing expected inputs (read), and outputs (create, update, delete) for the entire system in a compact, succinct form. We then utilized the use case diagram to develop an operational profile to help with a bit of test planning, identifying high trafficked use cases in the system, high risk data, and even design of load and stress tests.

Library management system use case diagram

Still working at the use case diagram level – the 30,000-foot view of the system – a good next step in test design is to ask how the use cases of the diagram should be tested in concert, i.e. integration testing of the use cases. One obvious way to approach integration testing of use cases is from the perspective of one or more of the actors in the use case diagram. If pressed for time in test design, one might select the view point of a subset of the actors that collectively cover all the use cases in the diagram. For example, referring to the use case diagram in the side bar, one might choose to integration test all use cases from the viewpoints of the Self Service Kiosk and Book Curator actors. In doing so all use cases would be exercised.

An alternate strategy for the integration testing of use cases – the one we’ll focus on in this post -- is from the perspective of the underlying data. This approach has the advantage that it can yield tests that cross actor boundaries; so not only testing use cases in concert, but actors as well.

Martin Pol et.al.’s[1] book provides a good description of how to design tests from a C.R.U.D. matrix, which they call “data cycle testing”. Tests are designed to exercise data across its lifecycle, from initial creation, to subsequent use -- reading and updating -- to eventually being deleted.

Using the C.R.U.D. matrix below as an example (which we derived in a previous post; this matrix corresponds to the use case diagram above), one begins by selecting a data entity (columns of the C.R.U.D. matrix) from which tests are to be designed. Ideally one would design tests for each data entity (what Martin Pol et.al. prescribes). In a pinch for time, however, one might focus on data entities most critical to the system.

Library management system C.R.U.D. matrix

For this example let's focus on a “high risk” data entity Check Out Requests (see my book, Chapter 2’s section Risk Exposure and Data on how to identify high risk data entities).

 

Check Out Requests Example

Use Cases that exercise Check Out Requests

The figure to the right shows the use cases from the C.R.U.D. matrix above that create, read, update or delete data entity Check Out Requests. To design data lifecycle tests for Check Out Requests, we can use a simple process based on three basic steps:

1. Create data (in this case a Check Out Request), then read to verify correctness
2. Update data (i.e. a Check Out Request), then read to verify changes
3. Delete data (i.e. a Check Out Request), then try to read to verify the data is really gone

Applying this three step process to these use cases, the following combination of use cases could, for example, be used to data lifecycle test Check Out Requests:

1)     (Create) Lend a copy or copies of a book, then

a)      Do a search on that book; Confirm checked out status

b)     Reserve a copy for pickup at the library; You shouldn’t get a copy checked out

c)      Try to transfer a checked out book to another library; You should be prevented from this

2)     (Update) Return a book that was checked out

a)      Do a search and confirm the book status is now checked in

b)     Reserve a book for which all copies were formerly checked out; you should be able to get the copy that was just checked in

c)      Transfer to another library a copy of a book that formerly checked out, but has just been checked back in.

3)     (Delete) Delete all copies of a book from the library (remember, the title remains); doing this removes all check out records for those copies.

a)      Do a search and confirm no copies are available

b)     Confirm you can’t reserve these deleted books

c)      Confirm you can’t transfer these deleted copies to another library

---

[1] Pol et.al., Software Testing