One challenge when I started on the Treatwell marketplace apps team was the ratio of developers to testers. To begin with we had 4 developers which seemed challenging when it came to testing, due to the concern that testing could become a bottleneck. Fast forward almost 2 years, we have 2 teams consisting of 7 developers per team resulting in 14 developers in total. The great thing from all this though is that although developer resource was increasing, testing is NOT a bottleneck, at no point does anyone look at our Kanban board and get overwhelmed with the amount of work items that are ready for testing.

How were we able to achieve this?

Quite simply we shifted our focus on quality to the left. So rather than following the traditional approach to quality and testing only being a concern at the end of the software development lifecycle (SDLC) which is more akin to quality control like this:

We started to think about quality further upstream, like this:

As you can see from the above, quality is embedded throughout the SDLC and isn’t limited to just the downstream section.

The important thing when thinking about quality is that it’s not only about thinking of testing but it’s also about the testability of the feature that you are working on and how you can validate that something behaves as expected. e.g. if storing some preferences locally on the app, how do you expose these for testing purposes via some UI so it can be validated.

In my current teams, conversations around quality start before any stories have been written, through collaborative processes like writing user stories as a team and user story mapping. These are a really powerful part of how we work and have an incredible impact on quality and testing as we are considering testability and quality before we have even created a story. It also enables us to have conversations about release strategy for a given piece(s) of work.

Once we have created our stories, we proceed to dev review where further conversations are had regarding quality. At this point in the process some stories for a given feature would have been created with some high level acceptance criteria. The developers and tester would review these stories and identify the following:

• Can we slice the stories into smaller deliverables in order to provide value for customers faster?
• Are there any coding/architectural challenges that could impact the delivery of the feature? e.g. changes to API behaviour
• Are there any questions/concerns over the acceptance criteria?
• Identify any additional criteria that should be considered
• Discuss how the feature will be tested

Once we have identified any concerns, we note them down and discuss as a wider group if necessary.

The next stage of our process is refinement. The expected outcomes are similar to those of dev review, however the difference here is that the entire team is involved in this, including Product Managers and Designers.

After refinement has taken place for a given set of stories, and just before development commences on a feature, we next have our conversations on quality at story kick off (or 3 amigos as it is otherwise known). This is a great opportunity to do the following:

• All platforms (iOS, Android and Backend where applicable) discuss the stories to build a shared understanding of what is to be delivered as in some cases time between refinement and kicking off a story can mean people forget what was discussed
• We have found it really useful to write these tests in Gherkin syntax as it helps to describe the behaviour
• These acceptance tests will test the acceptance criteria for a given story
• The acceptance tests can influence how a developer writes a feature
• The acceptance tests will cover the majority of the edge cases
• They will serve as a structure for creating automated tests which will in turn help describe the functionality of the code
• Discuss any changes to the backend services that could impact other teams

In conclusion, our main focus is to start having conversations about quality and testing as early as possible and not to limit those conversations to any one point during the workflow.

Although not necessarily upstream we have recently started experimenting by pairing on testing with developers. We have started by pairing on at least 2 stories per platform but we don’t want to limit ourselves so we will happily do more! Since doing this we have identified the following benefits:

• Developers receive feedback on issues straight away
• Developers become more aware of different testing techniques
• It saves time creating bugs in issue tracking software and the process of triaging/retesting etc
• Improves communication within the team

As a result of these conversations, the team will be encouraged to consider quality at every opportunity which results in a reduction in defects raised that ultimately means that not only are we building and shipping a better quality product, we have improved the cycle time. Testing isn’t truly scalable unless we shift left.