First model, than build
Mar25
I’ve mentioned the use of MBT in evaluating requirements in an earlier post. The last few days I had an interesting mail conversation with Joost Jongman (@jjongman), an intern with us a Sogeti. The conversation was about how I see the use of MBT. He responded on some remarks I made on Twitter, this blog and my latest article which was published in Methods & Tools magazine (Spring 2010)
This is where I think modelling has the highest potential with testing right now; in (re)modelling the requirements or test base. A lot of companies have problems with writing down their requirements for a project. And what requirements that are delivered are of dismal quality. The (new) Agile helps to fuel the creation on bad and unclear requirements.
As a tester you are depended on the documentation to be clear, unbiased, complete and understandable and testable. When in doubt you request more information about the subject. This way you can do the best testing possible. But what to do when the documentation is bad, unclear, segmented and just wrong?
Creating a model can help with this. A model is something analysts, developers and testers understand. And the creation of the model challenges everybody to think about the current documentation. Where there are loopholes in the documentation, multi conceivable, unclear or even full of mistakes become clear when trying to create a model for this.
For instance, when a tester creates a model and but there are still questions, then the model can be used as a peg to create very clear questions. As an example, you can evaluate the model using numbers for the decision points and process blocks to create a clear link between the question and the step in the model (where that question is about). The incomplete model is also an excellent medium to obtain support from analysts/designers, because it’s obvious that information is missing or unclear.
As a result testers look at it from a testing perspective, developers from a coding perspective and analyst from a design perspective. With this everybody will try to understand the documentation in another way and ask questions about the loopholes. As a result challenge the quality of the requirements.
When you record in the (master) test plan that a test manager should approve the model design before the specification phase starts the model becomes a powerful tool to monitor the start of the specification phase. Testers will not be forced to already start specifying test cases without a completed review of the documentation and thus model. When it is forced upon the testers to start before the model is approved this will lead to a change in the test plan and thus a test manager will need to determine the impact on lead time and costs. This is an additional tool for a test manager to ensure that the model is approved.
It’s the cheapest to resolve errors as early as possible. We’ve known this a long time. Just ask Boehm. With creating models from the documentation the quality can be checked early in the development life cycle. Any defects can be resolved and don’t show up in the test execution phase. Also any ambiguity can be resolved. Thus creating a better product while designing the application.
The models are a clear and understandable product for all parties involved and evaluate the documentation in a simple step.
Thanks to Luc Bos and Joost Jongman to trigger me about this subject.
March 29th, 2010 at 14:50
Hello Ewald,
as you already read in our mail conversation I think a little different about the potential of MBT. Therefore I have written my own posts ( http://bit.ly/9w2vvg ) so that other people can read about my opinion as well. I’m keen on discussing new MBT insights.
Joost Jongman
February 5th, 2012 at 22:25