One of the most challenging things in a project is our ability to understand and express (to ourselves and our customer) what we intend to do. This is one of the reasons we have iterative ways of working, to continuously learn and adapt.
- How can we create better requirements based on feedback from testing.
- How do we know if our users will benefit from our new product features (or not)?
- What user problems are we actually solving
(and why)? - How do we demonstrate the value of the product?
What the designers say, when asked, what they consider the most difficult part of their job, is not the design, but to understand what the customer actually need and want. This could take the form of a workshop, where we meet to discuss and agree on what is needed from us.
To be a customer is also difficult. It depends on our perception and ability to express a future scenario in where, we think, a specific solution (feature) would be the most useful and desired to fit our needs, intentions and requirements (also including the end customers).
Difficulty In Communication
Our difficulties in communicating can be illustrated with the four quadrants of the so called “Johari Window” (a tool for understanding and training of self-awareness and communication skills).
- Shared (what is known both to us and others).
– Data
– Information
– Agreements - Blind spots (what is known to others but not by us).
– Underlying needs
– Actual problems to be solved
– Unexpressed wishes - Hidden (not known by others but known to us).
– Assumptions
– Expectations
– Previous knowledge
– Bias and beliefs - Unknown (not known by others or by us).
– Creative new ideas
– Unchartered territory
– New areas to be explored (unknown problems)
– Missing requirements
The challenge is to know yourself, and your ability to ask the right questions.
From a testing point of view it all comes down to our ability to focus on what is important to find out about the product and how to get that information.
– Identify underlying needs.
– The business value/outcome relating to the effect of the intended product use.
– Provide feedback by clarifying questions and proposals how to improve the needs and requirements.
Just like there are several heuristics we use in testing, there are heuristics how to write good requirements and how to do a good design (design patterns and intent).
Testing should be part of the requirements modelling (whether we chose to describe/document it or not).
Exploration is most effective when using a scientific approach, to:
- Observe (what do you see, pay attention to detail, but don’t miss the whole picture).
- Question (asking “what if..”, ”what should happen when..”, “in what way may the system fail”, both open ended and specific questions, to discover potential problems and the value of the product).
- Evaluate (to get answers by running tests and feed back the result for further questioning, clarification of the requirements and new/modified test ideas where to go next).
The results of our test efforts should also include a proposed clarification of the requirements (if needed). If we are unable to express our thoughts and understanding from using the product (before the customer sees it), valuable feedback and knowledge may be lost.
If we get lost in the “unknown area” in our communication with the customer, i.e. missed questions, there may be serious consequences afterwards as well.
Example:
- What possible performance bottlenecks exists in the most common and critical configurations of the system?
By asking open ended questions when exploring the actual system behavior will encourage the discovery of new and important information.
If, for example, the database isolation level is too high in a customer database, it may cause unnecessary waiting time and give slow performance.
Writing the Requirements
The person writing the requirements may be unaware of how the database isolation level affects the overall performance (since this is a design decision). The design may be implemented by an outsourced team without enough knowledge of the actual number of users trying to access the same database tables. The customer (when doing acceptance testing) may be unaware of which configurations will expose critical system bottlenecks.
If the testers are looking for bottlenecks, their findings may lead to better requirements and better design from start. Performance is a system architecture decision which is usually very expensive and time consuming to change afterwards.
A better way to look at requirements may be to focus on the needs of the customers instead of the requirements themselves. Requirements tend to lock our minds into a proposed solution, which may not fit the problem properly, since we may not even understand the underlying problems we are trying to solve.
Software Testing Requirements
There are many ways to explore the customer needs. One way is to invite yourself into a real scenario where the customer uses your current version of the product (or similar) in their daily work. You can then bypass a huge hurdle in your understanding of what the customer mean when they say something, it is because they usually can’t (so you will understand them correctly according to the Johari Window).
Imagine yourself going to a car dealer buying a new car, and the first thing the sales person asks from you is to give him a detailed specification of the car you want to buy. Ok, it should have four wheels, be practical to use when driving to work, having space enough when shopping or going for holiday camping. And it should be red. Did we miss anything?
By watching what people actually do gives us a lot of ideas of possible solutions as well. By talking about their needs, as we understand them, testing becomes a journey of discovery, communication and insights. The resulting requirements will be a proposal of possible solutions to a better understood problem.
Requirements Proposal
The requirements proposal (as part of an ongoing investigation) should be iterated and tested to the point where the team and the customer feels comfortable it will actually be a good (enough) solution to their problems.
To get there some heuristics may be useful:
- Simplify
Simplify your thoughts and express what is needed so others easily can understand what you mean. If the problem is not well understood this part is usually difficult. Do more work on understanding what customer problem you are trying to solve. - Clarify
Give your definitions of the words you use in the context of the intended product solution. Also paraphrase parts that people find difficult to understand. - Explain
Explain what you mean when, for example, you say the system should be easy to use. It should give meaning and explain why the system should be easy to use in certain situations. I.e. the user interface should be designed to minimize the need of looking in the user manual for help. There should be a logical flow of events following a scenario for the checkout procedure with a minimum number of steps. - Give an example
Provide realistic examples of the intended use. Valuable insights will be achieved by creating examples. Especially when exceptions occurs. E.g. the user have ordered a subscription for 6 months. During that period the users’ card expires, or needs to be replaced with a new one. Is it possible to do the change, and are all relating information updated accordingly on all web pages.
References
- Johari window
http://www.businessballs.com/johariwindowmodel.htm
