Missing States

MSDN Blog Postings » Missing States

MSDN Blog Postings » Missing States — Wed, 19 Sep 2007 20:41:29 GMT

PingBack from http://msdnrss.thecoderblogs.com/2007/09/19/missing-states/

re: Missing States

Michele — Sat, 22 Sep 2007 14:15:09 GMT

Preconceived notions about the product being tested, whether from the developers, documentation, or even the tester herself, can truly hinder the process of finding information. If testers are not careful, they could simply be subconciously providing evidence to fit whatever model they have selected.

It is also not a bad idea, if you have the time, to provide yourself with more than one model for testing the same product. For instance, after receiving a change list on the product in test, I may use a development model for testing, then walk away and defocus.

I will deliberately change my focus by asking myself questions about how I have been viewing the product. What information have I been finding? What am I possibly overlooking? The questions generally depend on the product. But I find this exercise very helpful in checking my current model of testing and the bias it may contain. When I return to the product in test, it is essentially with a new set of eyes. This provides me with a new model for testing the same product, which enables me to find new information and/or problems with the software.

Since the models that we use are always linked to our past experiences and possible biased opinions that lie in our minds, it is a good idea to question ourselves and our models as much as we question the product.

re: Missing States

Shrini — Sat, 22 Sep 2007 20:10:19 GMT

Michael,

I am happy to see this post dealing with models. I would have loved to see a post preceding this on the lines of "What is a model (definition, types, modeling techniques)".

When you say "Every tester forms a model of each application they test" - I would ask “what is a model” to start with. That is probably a great place to start discussion on software models when we talk about testing.

When you talk about models by developer, customer - you are bringing an interesting dimension to modeling in testing.

Cem Kaner in one of his presentations mentions that "Testers look for different things for different stakeholders (Stakeholder is some one who is impacted by action/inaction, success/failure of a product/server)"

Extending that - A tester would not only need to model the software system in his/her own thinking but relentlessly look for other models of the software (of the other stakeholders) and check the software usage patterns, behaviors, claims, anomalies etc.

That is why tester job becomes interesting, vast and an “open ended search for problems”

>>> Sometimes this model is explicit, such as when the tester is doing model-based testing.

Did you mean Finite state model based Test design? When people say “model based testing” (in Harry Robinson’s style) – they actually mean [finite state machine] model based test [design]ing.

This means - Finite state machine model based test design = Model based testing.

Note that words in [] are conveniently ignored. This gives an impression that FSMs are only ways of doing explicit or “formal” or mathematical modeling.

>>> every application functions according to a model.

Probably it is other way round. How about this rephrase – “A model helps us to understand some observable behavior”. A model in simplistic terms is a “view”, a description or representation. Model is not an absolute thing where as the application is.

A software application has many views (infinite). A model helps us to comprehend some set of application behavior.

Every model has boundaries. A good tester creates many models and is aware of boundaries of those models. An important thing about knowing the boundaries is about understanding things that lie outside that specific model.

When we talk about different models – developer, tester, customer – more than having match between these models (that would be more of confirmatory thing) – but thinking about as many models as possible in a given time frame and check customer and developers regarding those models.