The W-model and Check, Explore and Accept

In an earlier post I wrote about the W-model. I wrote this: “Every different product generated in the development life cycle should be checked.” So how should I check this? The checking with software product should be done with testing. For this it is easy, but how is this testing build up. In my opinion the testing is build up out of three things: check, explore and accept. This post is a brain dump for me about this subject. How do you think about it? Am I wrong, did I miss things or do you agree with me? Please let me know.

W-Model

How do approve, accept and explore compare to the W-model? First we have to know what everything is.  These three are:

  1. ‘Check’ is the determination whether a created software product complies with the specifications.
  2. ‘Explore’ is an (in depth) investigation of non-specified parts of a (created) software product for errors.
  3. ‘Accept’ is whether the described specification or product is the correct solution of the (user) problem.

    You can agree or disagree with these statements, but this is my opinion on it. I’m not setting the definition on it, but for me testing consist of checking, exploring and accepting a product. With my idea you get the most of all three worlds.

    Check
    Checking a product is maybe the most important thing to do as a tester. As stated above approving means the product complies with the specifications. When do we do this? When looking at the W-model this starts early. The client states its business requirements and after they are written down he reviews them if they are correct. If they are correct the client approves them.

    After this all the separate deliverables are checked whether they are correct and if they still comply with an earlier product. When the software is built it is checked whether it complies with the deliverables. But is this what the client wanted? But are all errors found in the product? I don’t know! To know this the software needs to be accepted and explored.

    AAE-Approve

    Explore
    By exploring a software product you investigated the product to look for errors. Why do I look for errors? Because it is time consuming and the software can be approved. But what about security issues, usability and other non-functionals. These parts of the software are often ‘forgotten’. But also software that has been approved isn’t always good. It’s working as requested, but it also should be secure. Or functioning in a manner nobody at the start of the project thought about. This is why you explore a product. In my opinion the most fun of testing and also the most difficult part. A tester should be skilled enough to perform these exploratory tests. My experience is that testers who often explore a product find many serious errors. The preparation of the testing in such cases is difficult because the tester cannot rely on an exemption from the specifications, but the tester needs to be creative and skilful to find defects. Exploring can be done on all the deliverables in a W-model. But especially on functional and technical design and during the testing. Explore has some ideas from Exploratory Testing like the Context Driven School of James Bach, but they also use exploratory testing with approving. This is something I don’t comply with in the use of explore. But the use of heuristics and oracles is definitely a thing you should use when exploring with testing.

    AAE-Explore

    Accept
    Accepting a product is maybe the most difficult to comprehend for an IT professional. I had a discussion with an information analyst and his answer was when I asked him “how do you accept a product?”, he said to me “when the acceptance criteria are met”. This is where I disagree. Some of the acceptance criteria are specifications and should therefore be approved. Suppliers always want quantified acceptance criteria which makes them specifications. But a user (client) has to accept the product as the correct solution to his problem. Thus for me users are the only group that can accept a product. Accepting requires knowledge and experience with the process, and the system.  This knowledge can be acquired by using interview techniques or teaching the user on what to expect. Acceptance is done at the beginning and end of the W-model. Starting with the creation of the business requirements, during acceptance testing and operation and management.

    AAE-Accept

    I am not for one of these approaches for testing, but for the combination of this. When time is a problem you could use either checking or exploring while testing the software. But always use accept. Because the user has to work with it!

    In a next post I`ll write more about the ‘how’ of, for example accepting. Where this post describes the ‘what’ and ‘where’.

    The W-Model

    Last month I wrote an article in the Computable about the added value of evaluations over testing. I translated the article and posted it on this blog. A colleague of mine mailed me about it and about the use of the V-Model, Agile development and other things related to evaluations. He came up with the idea of a W-Model. At first I liked the idea with a W-Model. And I got some inspiration for this post. But after some research I found many different interpretations of the W-Model.

    One of the different models I found was one of Valerio. Valerio is a Dutch company that has its own testing methodology, like TMap®. The testing method of Valerio is SmarTEST . I like the name! The W-Model in SmartTEST looks like this.

    W-Model_SmarTEST

    Tip: For a better look check out the website of SmartTEST (in Dutch).

    The idea is to use increments to test the development. Design, Coding, Unit and Unit Integrations Tests are to be done in several increments to finalize. After this System Testing and Acceptance Testing is the safety net to check the result. But this model doesn’t support my idea of evaluations.

    Another model is one by Andreas Spillner. A German professor at the Hochschule Bremen. He published his W-Model on Stickyminds.com. And this one looks like:

    W-Model_Bremen 

    This looks more like it! Start the testing after requirements, but still not my idea.

    Finally I found a W-Model by Paul Gerrard. It is based on the W-Model by Paul Herzlich from 1993. This W-Model focuses on the products by development and tests the product, like evaluations.

    W-Model_Herzlich

    If I look all these different W-Models, the one I like the most is the W-Model by Herzlich/Gerrard. But to shed my light over it. Every different product generated in the development life cycle should be checked. This can be done by evaluations, analysis, checking, testing or control. So when I think about a W-Model it looks like this:

    W-Model

    In this you evaluate the requirements, functional and technical design. The code is checked by a static analysis (tool). After development, system and acceptance tests and operations and management defects can be fixed during debugging and changing. This is how I see the W-Model. When going further to the next stage Quality Gates can be used. All the evaluations, static analysis and changing en debugging is on ongoing process.