Using models / user flows in software testing

So I saw this article on models, user flows and what not:

And I wondered, how would testers use these models and user flows for testing? If you were handed them, how would you practically approach it from a testing perspective?

It’s been a long time since I even tried something like this and I’m sure many of you have clever ways of finding problems with them.

I’m a big fan of models and user flows. My personal favorite is the state diagram. Written well, they could offer more to my testing efforts than the traditional state diagram. Consequently, one of the outputs to many of my exploratory sessions is to make my own model of how I think the system works. If I put my model next to the programmer’s (or architect’s) model and it comes out relatively close, then we both know we’re on the right path.

A big advantage to a model is that a whole lot of text can fit into one picture (1000 words, I believe), so rather than flipping through a specification document, I can look at a couple of models for an idea of the same information. That doesn’t, however, excuse me from knowing what is in the big document. The model may be wrong, or out of date, or confusing, or…

Models also offer an interesting look into what the model-maker is thinking about. For example, in the flows offered in the blog above, the arrows mostly go forward. Almost no arrow goes backward. So, was the designer not thinking about “oops?” Are they not thinking about what might go wrong? Or is it just an omission to the model to keep it simple? As a tester, it is at least worth discussing.

1 Like