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.

How do approve, accept and explore compare to the W-model? First we have to know what everything is. These three are:
- ‘Check’ is the determination whether a created software product complies with the specifications.
- ‘Explore’ is an (in depth) investigation of non-specified parts of a (created) software product for errors.
- ‘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.

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.

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.

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’.


