IntroductionIn a previous post I talked about "What are Testers for? What should a Tester Do?". I discussed the sphere of influence which a Tester has and suggested that maybe the boundaries we work to, as Testers, aren't in the right place.
I also covered the idea of Testers adding value. I think there is a general perception in the industry that Testers are there to prevent a loss of Quality - they just 'test the codes' and make sure there aren't any 'bugs', they are gatekeepers.
Well if that were true it would suck, I don't think I'd enjoy a role where all I got to do was kick the tyres. I also don't consider that to be adding value. Sure, it is valuable but in this scenario, the best possible outcome is that the Quality which existed in the developers intended solution has been delivered.
Before we go on it would help if you read my previous post about ‘what’ Quality is here.
So now we know what Quality is, let’s explore how it changes through the development process.
Where is Quality?Let's think about how much 'potential Quality' there is at each stage of a development cycle, and how it can change as it becomes 'realised Quality':
|Quality degrades through each phase|
- Business Vision: The business has identified a market it wants to enter or a demand it wants to supply.
- Quantifying the Idea: This is the point at which you start breaking that idea into 'pieces' of work and thinking about who may do the work.
- Requirements: Once the idea has been broken into 'pieces', specific requirements are written to attempt to quantify what work needs to be done and how we will know when it has been achieved.
- Implementation: The requirements are then turned into 'stuff' - the embodiment of those requirements.
- Release/Launch: The 'stuff' is then sent off into the wild with the hope that it fulfils the Business Vision it was built to deliver.
I think of it as if there is a bucket (the process and the people) and water (the Quality). If we have a good process and good people, then as we build things, we get to the end with as much water in our bucket as we started with. But, what happens if we have a hole in our process, or several holes? Our bucket wouldn't let us deliver any water/Quality at all! The really important thing here is that we can't top up our bucket. Once we lose Quality it STAYS lost.
So looking at the graph, the best possible outcome is that the blue line stays horizontal - we deliver something into the world which completely fulfils the original vision of the business, nothing more, nothing less.
|If everything is perfect...!|
Why does Quality degrade?
- Poor Process - This is a wide topic, but suffice it to say, if your process does not encourage efficiency, openness, accountability, focus and delivery, your going to lose Quality.
- People - People are everything, not having the right people will make everything much harder, if not impossible. Similarly, if people are not motivated or focussed, Quality will suffer.
- Communication - Passing the information about the idea down the process chain to the end can end up being like ‘Chinese whispers’, meaning that over time the idea is warped and degraded and the output does not fully realise the original idea.
- Context/Understanding - Decisions will be made throughout the process and out of context, the wrong choice may be made. Without a good understanding of the idea and the goal, people can make less than optimum decisions.
- Changing Business Needs - The longer the time between the Business Vision and the Launch, the more chance there is that the original idea is out of date. The market may have changed, customers expectations may have changed etc. This is mitigated by utilising the correct processes and methodology.
The Testers part in this.You'll remember the point I made in this article about the scope and boundaries a Tester may or may not have. If a Tester’s only input is during the implementation phase, then the best possible impact they can have on Quality is to maintain it through the 4th section on the graph:
|Is this the only place we can make a difference?|
If the scope of the Tester is purely limited to that section of the process, then this is the result. But, what if we really go after that idea of expanding our influence and our challenging behaviour, what could that mean for Quality?
Let’s Start at the End.Release/Launch. Now, I’m not going to suggest that as a Tester you should be knowledgeable or skilled enough to second guess the Sys Admins and Infrastructure team in your company. But, that doesn’t get you off the hook! As a Tester you must be focussed on minimising risk and risk often comes with difference.
Look at the differences between how you test during the implementation phase and the system when it is deployed into Production. These differences fall into two categories: Infrastructure and Use.
- The closer your testing environments are to the Production infrastructure, in terms of spec and scale, the better. Let’s say you have an environment which once tested became the live Production environment. The risk of ‘deployment’ related issues is reduced considerably versus a test environment which bears little resemblance to the Production environment. As a tester it’s your responsibility to drive toward this goal and ensure you get the ‘best’ test environments you can.
- Use it like a customer! Always use the ‘C’ word! If your testing is focussed on exercising the system in the same way that it will be used once it’s launched then you are going to be finding the important issues which may affect the customers.
Deployment Success/Failure criteria. Making a change, testing it and releasing doesn’t mean the change is working. You need to monitor the release to ensure the behaviour it is exhibiting is what was desired, and that unexpected and/or undesired behaviour does not present itself. The best way to know this, is to include ‘success/failure’ criteria into your release plan.
What else is required?Requirements. When we go to planning and are given pieces of work to undertake, this work will have requirements associated. Depending on your processes, habits and traditions, these may take different forms but they will try to convey ‘what it needs to do’.
This phase is absolutely critical.
This phase takes the abstract, delicate, ‘vision’ of an idea and attempts to solidify it into a hard and fast mould. A bit like making a plaster cast, the requirements are the mould, if the mould is loose, not detailed and not rigid, then the plaster model is will not be what the artist envisaged.
The science of good requirements is a well documented area, as a tester, you should be intimate with this knowledge! I won’t cover it here. However, as a Tester you are in a unique position to be able to guide, influence and improve requirements standards. You should have excellent business context understanding, combined with a good interpretation of how the requirements may be implemented. This means you can bridge the skills and knowledge gap between Business Analyst/Product Owner and Developer in a way no one else can.
...and…Quantifying the Idea. So someone in the business (or in the industry) has a had an idea. Before we head into requirements and development, we need to really get to grips with the idea. As a Tester this means, I’m thinking about the following questions:
- Who would use this new feature?
- What is the use case? Are there some case studies we could look at (even theoretical one’s are useful)?
- How will this affect the use of other features?
- How do we expect the new feature to change our revenue?
- Do I know enough about this subject yet?
During this phase I would expect in most cases that wire frames and prototypes are built, theories should be tested and validated and alternative options investigated. In some ways it’s helpful to use this phase to think of as many reasons as possible why we shouldn't build this idea.
That’s not to say we should be negative, let’s face it, if nobody built anything we wouldn't have much work on would we!? The point I am trying to make is, that the best ideas will always stand up to scrutiny. You will find that scrutiny actually improves ideas, because they change and adapt as weaknesses and flaws are discovered.
As a Tester you are again in a unique position to work on this phase. Your business context knowledge, experience of how users interact with the existing product, their complaints, and the things they like, are all available to you. Combine this with your ability to think critically, but objectively about things and your inbuilt curiosity and desire to learn make you a valuable asset here.
Sure the decision makers (Business Analysts, Product Owners, etc.) have much of this information, and it is certainly not your job to be hijacking these decisions away from them, but you do have a different skill set and way of thinking. Use it.
And finally...Business Vision. So this is a tougher nut to crack. ‘Business Vision’ is seated in the domain of the ‘higher ups’, the Business Leaders. I'm not about to suggest you should be scheduling weekly checkpoints with your CEO, to test his 5 year plan for the company (although…!?). Of course, that’s not the way to go. But we really have to be paying a lot of attention to this. The Business Vision is going to dictate the work coming through the business for the foreseeable future, you need to be aware of these so you can up-skill and gain knowledge of the new things you will be encountering.
It’s not good enough to wait until you need the skills and the knowledge, before you start to learn. Be proactive. When the Business says “we’re changing”, be ready, waiting. This is the way in which you can ensure that - as the decisions are being made, the requirements set, the code written - you are right there, challenging, validating, questioning and adding value, every step of the way.
Final thoughtsIt is easy to think of ourselves as "just Testers". Let's face it, there's always so much to do, without seeking out more work! But I would really urge you to consider expanding your horizons. I am increasingly coming around to the idea that the title of "Tester" is an inaccurate representation of what our real skills and value are. You have a unique skill set and a unique viewpoint, often able to bring together aspects from all around the business, which other disciplines have less access to. You really should be using it!
|Go add value!|