Principle 1: Looking at the bigger picture with risk
This May half term I visited Madrid and attended the expo QA Testing Conference to do my talk titled, Solving Testing problems through a set of principles.
Goal of my talk
My goal was to encourage people to reflect and think about the testing problems they have experienced and what testing principles they would have based on that. I do feel that I achieved this due to the success of both the Q&A with thought provoking questions and comments, along with people who came to discuss this topic with me afterwards. Thanks to those that have also given my talk a shout out. I enjoyed doing the talk and all the conversations we had together.
What is a Testing Principle?
For those that might be thinking, what is a Test Principle? A Testing Principle is a thing you must do OR things that you believe are correct OR professional guidelines. An example might be, to keep your gums and teeth in good condition you need to brush your teeth twice a day, floss and use mouthwash.
Why might you need to have a Testing Principle?
For me, software delivery is complex. As a test manager I have personally worked on something I would call a program. Lots of projects within and it can easily get overwhelming quite quickly. Testing principles help guide me when considering a matter or making a decision. I feel like I have accomplished more since I’ve had these principles than compared to when I didn’t have them, which I feel is powerful.
Principles are personal
One thing to note, in my opinion, is that principles are personal. How I see principles is going to be different from how you see them as we have different viewpoints, experiences and contexts. This is OK and for me, to be encouraged.
My 6 Testing Principle Themes
In the conference talk I spoke of how I have grouped my testing principles into themes: Risk, Purpose, Empathy, Role, Visibility and Learning. I thought I would do a blog series to cover each of those topics. Also to explore and expand on what I didn’t say. So here we go, let’s start with risk.
What is risk?
Risk is the possibility of something bad happening. If we break that down further.
- What is the bad thing?
- How likely is the bad thing to happen?
- If the bad thing happens, what impact does it have?
Tunnel vision focus
In the teams I’ve worked in both as a software tester and test manager I have noticed that we tend to focus on product risks. It’s not surprisingly really as that is the main focus, the product. However, I tend to see it in a different view to help me think bigger. There are the product risks at the centre and then you have the people, processes and project risks around that. It might be hard to think of all these things as a hands on person. I’ve certainly been like this as a test engineer in a team where I have tunnel visioned into the product detail, which is why in my opinion, roles such as Test managers are still vitally important. However testers in teams can still be aware of broader risks and highlight these to the appropriate stakeholder.
I didn’t go through what I meant by each of these broader risks in my talk, however, I’d like to see if I can explain it so anyone can understand where I’m coming from.
So let’s go through them one by one. Starting with People. The heart of the delivery engine. Then we will go onto processes, project and touch on product risks.
People (how we work together)
I’ve brainstormed a few ideas of areas I mean. There are likely more.
- Collaboration levels
- Communication
- Empathy
- Culture
- Skillset
Example of a people risk..
Poor levels of collaboration in a team, which is shown in team meetings where team members do not seem to understand each other, so the conversation goes around in circles. This creating inefficiencies and wasting time/money.
Processes
A process is a series of actions or steps taken in order to achieve a particular end).
It has taken me awhile to get my head around explaining this in simple terms. Someone mentioned in the Q&A that one of their own testing principles would be about continuous testing. A very interesting perspective. For me, I would sit this in a process. How you go about achieving an end state.
Examples of processes might be..
- How you get from the idea to production.
- Learning from incidents, so you can do your best to prevent them from happening again.
Example of a process risk..
There is no process in place to review a major outage in production, which might mean that production outage will happen again. This again wasting time/money/your business reputation.
Project
A set of objectives to be achieved within a timescale.
Examples of project areas..
- Project Goals - Why/Who/What
- Timescales
- Costs
Example of a project risk..
You work on delivering a product for two months and then the customer turns around and says that’s not what I wanted. Therefore wasting time/costing (and the team’s morale!)
Product
A product is any item or service you sell to serve a customer’s need or want.)
Examples
- System quality characteristic (usable, secure, performs, accessible etc..)
Example of a product risk
Building a product that is not easy to use, which results in customers feeling so frustrated that they ditch your product and sign up to your competitor’s product offering.
So if we have a problem of tunnel vision, how do we see the bigger picture?
I’ve worked in all sorts of interesting methodologies, some I would describe as very unique and called wagile. A mix of waterfall and agile. I’m a big fan and advocate of all things agile testing and I try and keep documentation light. However, I feel documentation is vitally important. We can’t remember everything. Our memory is faulty and at times inaccurate so writing things down is important for me. I always write test strategies, plans or notes (formats such as mind maps,tables, bullet point notes) for the projects I’m working on.
Where are your project goals in your Testing documentation?
The thing I see a lot from others is they miss referring back to the project goals in their Test strategies/plans.
Write down the project goals
Writing these project goals down help me see the bigger picture and ask the question, Are we doing what we set out to do? If we are not doing what we set out to do, then you can ask questions and get the group back on track.
Retrospectives are another good one where you can look at the 4 Ps I have described (product, project, processes and people). Is there anything we could make better?
Once I noticed in a project the Architect going off and creating an architecture diagram and leaving the requirements in the dust. This is a risk because we might not be building what the requirements are asking for and causing mass amounts of rework. Sometimes I find these types of risks very awkward to call out. The architect in my view is doing their best and getting on with the task at hand. However I need to do the right thing by the project, team and individual to help move in the right direction. I called it out to the appropriate stakeholder and did some other things (like create a TEAMS group with all of us in). From then on we started to improve how we collaborated. It was a wonderful transformation. I always remember even though it may feel awkward to call it. I am doing the right thing by the company/project/team. “Fight the good fight" is a mantra I will talk about in the role testing Principle theme.
Get creative with solutions
What’s interesting about having testing principles is that you can brainstorm solutions to them. There may be several solutions you can experiment with. I have given an example of how I document to see the bigger picture, however, you could for example refer to models. There are a lot out there that can help you. I am a big fan of Lisa Crispin and Janet Gregory’s book Agile Testing Condensed. There are a lot of ideas you can use in that book to help you think about the bigger picture. They also regularly blog about such topics. True thought leaders in our testing industry. Do check them out.
Wrap up
As always thank you for reading my blog posts. Onto the next in the series — purpose.
