Pages

Tuesday, August 30, 2016

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
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
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
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
 

Tuesday, March 22, 2016

Timeboxing: Budgeting Time in Test Design with an Operational Profile

Use Case Levels of Test: Innovate & Work Smart in Software Test Design
In the last few posts we've been talking about the importance of operational profiles as a tool for working smart in test design and how to generate an operational profile from a use case diagram using a simple QFD matrix. In this post we look at how to use an operational profile for budgeting your time in test design to maximize bang for the buck, or or as John Musa said, “More reliable software, faster and cheaper”.

 

Timeboxing

The strategy for test design presented is my book is to budget test design time for each use case based on an operational profile: an analysis of the frequency of use of each use case. After all, frequency of use is opportunity for failure: the more use, the more opportunities for the user to find defects.

The idea of budgeting a fixed time for some task is called timeboxing. Timeboxing is a planning strategy often associated with iterative software development in which the duration of a task (design tests for a use case) is fixed, forcing hard decisions to be made about what scope (number and rigor of tests) can be delivered in the allotted time. What’s new with the approach here is that budgeted times are based on an operational profile.

To illustrate, say you’ve been given a week to write test cases from the use cases of the library system (see last two posts). During that week you estimate your team will be able to spend about 40 staff hours. To get an idea of how best to budget the teams’ time, you construct a quick spreadsheet using the relative frequencies from the operational profile (again, see last two posts). Results are shown below; hours budgeted (right column) have been rounded to the nearest whole hour.

Allocating 40 hours of test design, timeboxing, based on the operational profile
Allocating 40 hours of test design based on the operational profile

The first thing you will notice in this example is that some tests have been allocated zero hours of test design; that is based on the low frequency of use. And this is a good time to reiterate one of the reasons use cases have gained attention in testing: in a pinch (you’ve run out of time for test design), the use cases for which you didn't get around test design are workable substitutes for full-fledged test cases.

Alternatively you may decide you really want some tests designed for each use case regardless of how little they are used. The figure below illustrates budgeting the 40 hours of test design to strike a balance between the spirit of the operational profile and yet having some time for test design for all use cases. And I think it is the spirit of what the operational profile is showing us that is important for planning. That combined with some common sense will lead to a better allocation of time.

Allocating 40 hours of test design, timeboxing, based on the operational profile

Reallocation of 40 hours honoring the spirit of the operational profile, yet still making sure each use case has at least a minimal amount of test design.

 

Timeboxing, Use Case Levels of Test, and Test Rigor

Timeboxing, use case levels of test, and test rigor
The four use case levels of test
In the side bar is an illustration I've used before of the four levels of use case test, and a strategy based on it for test design. Using that illustration, once budgeted time is in place for each use case (level 1), test design would proceed use case by use case, working top-down from level 2 (use case), to level 3 (single scenario) to level 4 (operations) until the budgeted time for a use case is up.

For use cases for which many hours have been budgeted, this strategy will produce tests at all levels, 2-4. And at any given level, when the option is available to increase or decrease rigor, rigor could be increased.[1] Tests at more, deeper levels, with increased rigor, will translate to more tests, with greater detail, and ultimately more test execution time for frequently used use cases.

For use cases for which few hours have been budgeted, test design may not progress deeper than level 2 (use case) or 3 (single scenario) before time is up. And at any given level, less rigor is likely in order to accommodate for less budgeted time. Tests at fewer levels with less rigor will translate to fewer, coarser granularity tests for use cases used infrequently.

 

Footnotes

[1] For an example of what I mean by increased or decreased test design rigor, refer to Chapter 4 of the book, Control Flow Graphs: Adjusting the Rigor of Test Design. Similar ideas for adjusting rigor are provided at all use case levels of test. I'll also be covering this in some future post.

Thursday, March 10, 2016

From Use Case Diagram to Operational Profile



Book Use Case Levels of Test. Innovate & Work Smart in Software Test DesignIn the previous post we explored an important question related to working smart in test design: Does it really make sense to spend the same amount of time and rigor on test design for all use cases? We looked at the idea of an operational profile, a tool used in software reliability engineering to spot the high traffic paths through your system allowing you to concentrate test design on the most frequently used use cases, and hence those having a greater chance of failure in the hands of the user.

In this post we'll look at how to generate an operational profile from a use case diagram.

 

The QFD Matrix

QFD (Quality Function Deployment) is a product-planning tool that is used to translate business drivers into the technical requirements and design aspects of a product. Though originally developed for manufacturing industries in the 1960s, today QFD-like ideas are being used successfully for all sorts of applications, including software development, the services industry, and process management, and is considered an essential part of the quality improvement toolkit.

QFD boiled down to simple mechanics is about establishing priorities, the key tool being a QFD matrix. QFD is an ideal tool for representing a use case diagram – establishing links between actors and use cases -- and for generating an operational profile from that diagram.[1]

The easiest way to see how to generate an operational profile from a use case diagram using a QFD matrix is with an example. Using the public library book management system use case diagram from the previous post, we build a simple QFD matrix, here implemented as an Excel spreadsheet (below). In this matrix, all actors of the use case diagram are placed in rows, and the use cases are placed across the top as columns.

QFD matrix for a use case diagram. Rows of matrix are actors from the use case diagram; columns are the use cases.
QFD matrix to generate operational profile from use case diagram; rows are actors, column use cases

 

Quantify Numbers of Actors in Use Case Diagram

The next step in analyzing your use case traffic is to quantify the number of each type of actor in the use case diagram. How many book curators are there? How about librarians; self-service kiosks? Don’t get hung-up on precise numbers; ball park numbers are all you need to understand the relative numbers of actors, e.g. how many librarians do you have relative to curators: Same amount; twice as many? How about internet users; how many more than kiosks: Twice as many; a hundred times as many?

At this point you might say, “I have no idea how many internet users to expect!”. To which I would respond: Bingo, we’ve just identified a non-functional requirement that needs clarification! Asking questions about numbers of actors in the use case diagram is a healthy thing to be doing early on.
Keeping in mind that the goal is to get ballpark numbers for the operational profile you might try this. Rather than agonizing over whether there is one versus two book curators, or fifty versus two hundred internet users, try working with orders of magnitude. An order of magnitude estimate is one given in terms of a factor of 10:
100 = 1
101 = 10
102 = 100
103 = 1000
104 = 10,000
etc..
By their nature of separation, it’s usually easier to come up with orders of magnitude estimates. What’s the average life of a person? Rather than getting into debates about the numerous factors that affect people’s longevity—health, lifestyle, country, even what century—it’s pretty clear that it’s on an order of magnitude of 100 years; 10 is way too small and 1000 is way too big. Use order of magnitude estimates to get you in the ball park, then step back and refine your estimates if you feel so inclined, doubling here, and halving there.

So for our library use case diagram, using orders of magnitude estimates, let's say there is one curator, ten librarians, one self service kiosk, and one hundred internet users that might be accessing the system each day. This information is placed in the matrix in column Number of Actors (below)

QFD matrix to generate operational profile from use case diagram; in this step you quantify the number of each type of actor
QFD matrix to generate operational profile from use case diagram; in this step you quantify the number of each type of actor

 

Quantify Use Case Frequency of Use by Actors

With estimates of numbers of each type of actor identified you now turn to the question of who does what, i.e. which actors use what use cases .. and how often! In a use case diagram this information is captured as relationships – depicted as lines – between actors and use cases. In the QFD matrix it is captured by placing a number in the cell that corresponds to the intersection of an actor (row) and use case (column). The number you place in the cell is the number of times a “typical” actor of that type will execute that use case per some unit of time, say daily. If an actor never uses a particular use case the cell is left blank.

Again, using orders of magnitude to estimate frequency of use will help avoid analysis paralysis. Once in the ballpark you can step back and tweak the estimate, doubling here and halving there if needed. For the library use case diagram, orders of magnitude estimates for each actor are provided in the matrix below; frequency is given in times per day each use case is executed by each actor of that type.

QFD matrix to generate operational profile from use case diagram; cells show which actors use what use cases .. and how often!
QFD matrix to generate operational profile from use case diagram; cells show which actors use what use cases .. and how often!
 
Notice that the Book Curator executes the Add Books to Library Database use case and Remove Books from Library Database use case .5 and .05 times a day, respectively.  Are those order of magnitude estimates? Yes; when a use case is used less than once per unit of time – here daily – you can get the order of magnitude estimate as follows. The curator adds about 100 books (order of magnitude) a year; a year is about 200 working days, so the formula for calculating daily use is:
100 / 200 = .5
Similarly, the curator removes about 10 books a year (order of magnitude; the library is growing!), so the formula for calculating daily use is:
10 / 200 = .05
Getting estimates of the number of actors of each type and frequency of use information is the hard part of analyzing the traffic through your use cases. All that is left is to crank out the results. The matrix below shows the final results: an estimate of the frequency of daily execution of each use case by all actors in the library book management system (also shown are the formulas you need for this; the top formula calculates absolute number of times per day; the bottom formula calculates relative frequency.)

Final QFD matrix to generate operational profile from use case diagram.
Final QFD matrix to generate operational profile from use case diagram.

In a future post we’ll look at how to put these relative frequencies to work in test design.


[1] You really don’t need to know much more about QFD to generate an operational profile from a use case diagram, but if you want to learn more refer to Denney, Succeeding with Use Cases, Part 1, which gives a broader treatment of the combined use of QFD with use cases.

Pages