Hello hopefully you recognise the model above from my previous post. If you haven't let me quickly explain the idea behind it. The model above is my representation of where I believe QA belongs and how it is a continuous exercise. Each hexagon represents the activity or stage of development and in the middle of it all is QA. This does not mean it is to be done by the QA person / department but it should be thought of as an activity within each hexagon.
I plan to do an article on each hexagon and this one is on:
Planning the initial phase of work or the initial idea could be the most important area this is where the project starts and if you do this but wrong then it sets you up badly for the rest of the project. It goes back to the old saying s*@t in s*@t out. Now this is common sense but it is an area that can go wrong so many times because we don't question our own decisions and we do not like other people to question our decisions.
So how can we add QA/Testing into this so we don't create the wrong plan? I think there are several ideas we can implement to make sure we stay on track creating the right plan. I am going to briefly discuss some ideas which will hopefully allow you to do some more research into some of these ideas so you can pick out important elements that may work for you and your team. Firstly there is a great book which I may mention a lot called Qualitative Research Design by Joseph A Maxwell. This book talks about an extremely important model which is shown below.
An Interactive Model of Research Design
The model above shows how we can split our initial idea or phase of work up to help validate and research it to make sure the idea or phase of work is the correct one. It allows you to add some structure into the thought process giving you a framework to guide you on the right path. Each box addresses a specific concern or problem.
Goals:What do you want to achieve with this initial idea or this phase of work? Why is it worth doing?
Conceptual Framework:What do you think this idea or phase of work is going to solve? What initial plans or beliefs do you take into this phase. What prior experience or feelings are you bringing into this phase of work?
Research Questions:What specifically do you want to achieve in this initial phase? What do you not know yet and what do you want to know? What questions help you achieve this and do they relate to each other in any way?
Methods:What are you actually going to do to learn about this initial phase?
Validity:How might you be wrong? What alternative ideas are there?
This may seem familiar and other research methods follow a similar pattern but what is important about this model is how it is laid out. It is not liniar one box does not come after another box. Research Questions sit at the heart of the model but each box can feed into the questions but they can also feed into other boxes. This is so important as it means you can validate (Test) part of your idea or the question you going to ask or your initial feelings about this phase of work. Each box can inform another and this can help you to build up a solid foundation.
Another idea which comes from Jeff Patton is called story boarding. Now this is a tool of visualising stories on a horizontal access and timeline now if you don't use user stories I don't believe that matters as it doesn't really matter. What you are actually doing is discussing as a team how your initial idea / plan is affected by the end user and their journey in using the product. This can show hidden problems that you may not have thought of as you suddenly plunged into thinking like the user.
What you do is create user activities on how they may use your product and write them down and stick them on the wall in the order that they take to use your product. This is from their point of view and not a technical discussion. What you then do is break down each activity to list out what other activities may need to happen to make sure the higher level activity happens. Jeff shows this in his blog The New User Story Backlog is a Map
The above link will take you to Jeff's original blog on story mapping. He discusses this as viewing you backlog in more of an interactive state rather than a flat list but I believe this to be more useful in planning your initial phase or idea before stories or requirements even get into your back log. Thinking like the user and going through the journey on how they are using / going to use the product and visualising this on a wall with sticky notes just helps bring out questions and validate the idea the discussion this creates is the important part especially from a testing point of view.
The last idea I would like to talk about for validating / QA / Testing your initial idea or phase of work is called the ladder of inference. I have discussed this in my archived blog series Communicating as a Tester which you can read here. This is an important concept for validating your own thoughts.
Ladder Of Inference
It shows how decisions are come to initial developed for how we come to conclusions while communicating with others but can be used for showing how the initial idea was developed. As you climb the ladder you start of with the present reality and facts, you then take another step up and select the facts that are what you believe to be at the time the important ones and select your own reality. You then interpret that reality and jump up another rung and make assumptions. From those assumptions you form beliefs which in turn allow you to take action which is the initial idea or phase of work. Awesome done we have climbed the ladder and everything is cool or is it?
By knowing how we got to an idea we can reverse our actions to make sure it is the correct one. We basically go down the ladder in reverse. By discussing how each step influenced the next step but in reverse and with other people we can ensure we haven't made any drastic mistakes or errors. We can also see if another person's reality while going up the ladder is difference to ours even though they were given the same initial reality and facts and then we can question why.
That is it for this part hopefully I have introduced you to the idea of getting QA in early. I have hopefully shown that by having a sturdy foundation to your idea you set yourself up for success before we have even got to the developing phase. Part two will be about the backlog and the stories / requirements within it and how we continue the QA process. Again if you want to talk about any of this or just want to reach out please get in contact via linkedin or twitter.