Quality Approaches - Understanding Business outcomes

Shifting Left before we even start writing code

My journey

I have been a QA Engineer for over 12 years now. Given my journey in this space, this is an excellent time to share some of my learnings with everyone. I look forward to healthy discussions around my articles as there is much more to learn for me to learn.

When I started my career out of University, I applied for roles within the Software Engineering space after completing my degree in Software Engineering. I had the chance to establish a Test Automation framework right from its inception. This was exciting to me, and from there on, I started to take more interest in learning about testing. I slowly realised that when we focused on writing code, we only looked at the solution via a technical lens to get code out. Observing the solution from a testers lens was much broader and covered many different aspects, which I fell in love with. Staying within test automation also helped me keep up to date with the code side of things, giving me the best of both worlds.

Initially, I would focus a lot on Test Automation and try and code everything without understanding what I was trying to test. I learnt some painful lessons and have decided to document a few of the lessons I have learnt in the hope of helping other fellow testers who are on their discovery journey. The more I worked in the industry, the more I realised that having a strategy on what to test is more important than just writing code to test systems, so I thought I’d share a few of the things I have learnt and continuously learning.

Shifting Left

We’ve heard the term shifting left quite a bit within the Testing space, but I still see some confusion when talking to other testers. Some consider shifting left, just writing more unit tests instead of e2e tests (think of the test pyramid) and consider testing begins when we start coding. But shifting left in a larger sense among the community means we look at the requirements and have some collaborative sessions with the team to determine if we are building the right thing for the customer. The customer is at the centre of everything we do, and having our lens focused on them has helped me immensely in my time as a Tester.

Below are a few approaches that have helped me engrain quality from the start of the SDLC, and I thought I’d share them. As a tester, these are not approaches I am responsible for, but if we utilise them, it has helped our teams build that shared understanding in the past.

My Approach to embed quality early on

Using business language to describe the business outcome that our stakeholders validate

This seems obvious, but many teams usually focus on the technical solution of a problem before diving into how a solution would help a customer solve a problem. Identifying the problem we are trying to solve for the customer is the first step we should look to. In my experience, having a common business language helps it be understood by all involved. Having this common language also helps align the goals of what the development team is being built with the organisation's overall objectives. Another beneficial outcome is that it encourages a user-centric / customer approach to development, focusing on addressing the customer's needs rather than addressing technical challenges at these early stages.

Critical success factors are specified, and measures are understood

Having a success factor and measures specified helps assess the project's success. If we constantly push out minor changes to our customers and experiment if those changes are successful, having these defined objectively helps us make decisions. I have seen entire solutions discarded based on metrics and KPIs not being reached, so this is a valuable thing to do.

A high-level Impact Story is defined

An impact story is something that provides insights into how a particular solution would provide benefits to its stakeholders. Examples of benefits are increased revenue, customer retention numbers, customer acquisition numbers etc. This ties in with the point above, but I have noticed that it helps build intrinsic motivation within the team. For example, one feature we were working on would bring in an additional revenue of 10 million per year. This was a significant number for us then, and the team’s focus on getting this built-in time and quality was high because we knew the target and the impact this would have on our business and our customers. Impact Stories has helped a team be laser focussed from my past experiences.

The solution adheres to the core pillars of Web3

Given my articles will focus on Testing in the Web3 world, this is something that we as a team collaborate on to ensure what we are building is concentrated around the pillars of Web3. Some examples are if the solution/ feature we are building follows the core principles of decentralisation. Do we have products designed with a permissionless structure? These are just a few things to consider, and as the Web3 world evolves, our considerations will keep changing.

To be continued…

My next article will discuss how to bake in Quality when defining User Stories. Usually, that’s the next step I’ve seen teams I’ve worked on move towards, to build that shared understanding between teams on what we are trying to develop. Please let me know if articles along these lines are of interest.

Also, some of these approaches may be too heavy, especially when working in startup environments, so I would be keen to see any other approaches others have used to build/ bake in Quality from the start before we even start thinking about writing code.