It’s better with no model than ONE model Rikard Edgren
It has been said by many, but I heard it from Fiona Charles: “don’t ever fall in love with your model”, and this is a warning I want to elaborate.
A model is a powerful way to understand how the system works, and thereby also how it can fail.
But a model can also narrow your thinking, and stop you from testing outside the obvious patterns, in the ways your customers most certainly will.
So as a tester, you should use multiple (sometimes incoherent and contradictive) models, so you get a better coverage of the potential usage.
Having one model only is more dangerous than having none.
Here are some ideas that might help you use/create more models:
* requirements, and make sure to look for implicit as well as the explicit
* specifications are models, i.e. interpretations of what should be done; you’ll get different test ideas from functional, conceptual, technical and design specification
* the code is also a model, reading all of it is generally not feasible, but there might be some parts that are extra fruitful
* images; drawings, diagrams, mind maps, lists et.al. can show how things fit together, and if you don’t have them, you can create them (but don’t try to put everything in one place, rather use several with different angles, e.g. functional, architectural, technological, scenario-based…)
* test models – the way you think about, categorize and organize your tests, and the elements therein, is a model worth being aware of
* competitors products also model a solution to customers’ problems, and there might exist un-computerized solutions worth looking at
* the product in itself could be the best model; prototypes and early builds generate a lot of test ideas, especially because you can see how things can interact
You should be aware that each tester probably has his own implicit model of the system. This includes different aspects and is influenced by the functionality she has been testing, and which types of issues she has experienced, or heard about. It probably also includes a list of the most important quality characteristics, and it is a silent guide through the daily testing.
An implicit model is difficult to communicate, though.
With many models you can cover the product with different types of tests, and find more important things in the neverending flow of information.
Don’t forget the documentation (if the product has been around a while)
Documentation is good, and besides manuals, you can also use marketing material, customer stories et.al.
If the product has been around for a while you will use the earlier versions as models, and maybe you can try to find out the (implicit) models of your customers?
The designer, he/she usually have ideas of areas that was tricky to design, where they found a lot of bugs during basic test. It is easy to forget but a quick chat with the person behind the code can be quite useful.
I’m with you on this one, Thomas.
Those are more close to “inspiration to your model”, which is a very, very large subject…
But “other people’s models” is missing in my original list; they might be covered by the list, might not.