Keeping testing up to speed with development
Back in October 2020, I wrote a post for Code & Wild about how I had found positive ways to work as a tester whilst transitioning to remote working.
https://medium.com/code-wild/ways-of-positive-remote-working-for-a-tester-214e844f0d10
In the same post it highlighted how as a company Bloom & Wild was fortunate enough to continue positive trade, despite the effects of the pandemic. Fast forward to the end of 2021, where some have experienced office life again, and the company (largely including tech) has been fortunate enough to have continued its positive growth in size. Not to mention this year’s acquisitions of Dutch flower company bloomon and French company Bergamotte. As we welcome bloomon & Bergamotte, we plan to accelerate our mission to build Europe’s most loved flower company. With these acquisitions, we consolidate our position as Europe’s leading online flower and plant delivery company. So needless to say — our teams are bigger!
Within technology, and our engineering team, we now have multiple core squads whose areas of ownership all align to parts of our user journey. I’m now a member of the Fulfilment & Delivery squad which aims to enable seamless, efficient and scalable fulfilment capabilities to deliver the best experience for our customers. The agile squad is made up of 1 tester (that’s me), 6 developers, 1 product manager and 1 engineering manager.
As with scaling fulfilment capabilities, scaling of teams can also come with challenges. A challenge which comes to mind is keeping teams feeling lean enough and processes streamlined so they maintain innovation and productivity within them. From a tester’s perspective, a challenge can often be managing workload in a team where there are an increasing number of developers. In this post I look to explore and detail the ways in which myself and my squad have found ways of working which help to remedy the question:
“As we scale and grow as a team, how do we keep testing up to speed with development”?
Now the obvious answer is hire more testers. As a result of our tech restructuring and growth this has been the case as the test team has doubled in size across the tech team. However, we cannot hire everyone at once and therefore in the short to medium term it requires certain ways of working to ensure the team operates to the best of its ability with its existing testing capacity. It is worth noting that regardless of the dev to tester ratio, what I aim to outline could be positive takeaways for teams of all different sizes.
So what are the ways in which we approached this?
Pair Testing:
Pair testing, also known in the testing world as buddy testing, has been a great way to speed up the process of testing in our squad. I see it as having both immediate and long term benefits for us as an agile team. The immediate benefit being 2 heads tends to be better than one and testing is completed faster as unknowns/questions are answered by the developer straight away. It has collaboratively enhanced the quality of testing because we get to look at what has been built from 2 different perspectives.
Thinking longer term, it provides me with a greater technical insight and therefore a deeper understanding of the logic (or features) being introduced. Whilst pairing, I can understand the ‘what’, whilst the developer who has worked on the feature provides the ‘why’ behind the solution / code. As a result, in the future when changes arose in the same area of code I could apply that deeper understanding and complete testing quicker and more efficiently. Essentially, testing tasks which might have been deemed complex in the past then started to become more second nature. There is also the added benefit of 1 on 1 time with developers which is important for bonding and getting to know each other in a remote set up.
As a concept, pairing was one which already existed within the squad. But as the squad increased in developer size, so did the use of pairing.
Labelling of Pivotal cards:
Pivotal Tracker is a project-planning tool used for feature and bug requests, similar to Jira. Using this tool we can easily assign tasks. Sensibly assigning testing tasks across the squad creates a culture where testing and associated quality is owned by everyone. To organise this, we utilised the labels feature within Pivotal Tracker to assign testing of pivotal cards to team members. New or more complex features (and bugs) which are user facing and require in-depth exploratory testing will be labelled as ‘tester-to-test’ — in my case ‘jon-to-test’. As are changes which require high level functional testing like regression testing. Technical dev tasks which cannot be completely tested against our backend system UI commonly get labelled ‘dev-to test’ with a developer owning the testing. This is normally in the case of low risk changes. For higher risk changes, we commonly pair to ensure we have increased confidence before releasing. To determine the risk we decide whether the changes fall inside or out of our list of critical operational flows that we own as a squad.
The above allows me to focus on the larger scale feature work that requires more of my time (and testing skills). This also keeps the work (I am not assigned to testing) flowing in order for the team to maintain progress across the sprint.
Team Testing Sessions:
Team test sessions have been extremely beneficial, especially when used for full stack projects. Combining frontend, backend & apps contributors, with testers, enables technical representation from all areas. There is also the obvious benefit that more people testing means quicker test coverage and therefore a more time efficient process. These sessions have great value, but they need to be planned for. It is important to prepare and organise the sessions. The more prior planning the more you get in terms of the testing output. Breaking down the test areas against supported browsers, devices & app versions then assigning them to team members enables you to get the most from the session.
Increased test coverage increases the chances of finding issues and spreading that out across a team testing session means issues can be found faster.
In contrast, if we take a phased approach, without the use of team testing, testing can end up feeling like a bottleneck in the system. A tester is then likely to constantly ask for more time or more help as they become aware that they can’t do all of the testing alone. A positive team dynamic is preserved by using team sessions. It reduces the time waiting for feedback, increases visibility on progress/blockers for those involved in the project and improves communication in order to deliver customer value sooner.
Use of shared test sheets / resources:
Test spreadsheets are a preferred method I like to use in order to note take and create test plans. The test (google) sheets commonly include technical context, test scenarios, test setup instructions and screenshots. This is not a fixed list as the test plan should cater to the test subject. It’s important to learn how to improve the test plan as we test. The value of testing is determined by whether it provides useful and timely information. As such, when new valuable information is found it should be added to the test sheet.
So how have they been useful? They act as a shareable resource that gets updated in real time, providing continuous updates to developers and product managers on the test progress being made. It eliminates the need for developers to ask or check in with the tester about progress as that progress is always visible and trackable via the sheet. It is another example where the feedback loop gets shortened and a way in which we can work faster, especially in a remote setup. As a result of using shared test sheets, bugs and issues have been resolved quicker.
Utilising testing on branch environments:
Within the tech team we aim to do a backend release everyday at 3pm (when not in a code freeze). This includes all backend changes merged to the staging environment that have been tested and accepted at that time. In addition to testing on staging, we have the ability to deploy to and test on a “per branch staging environment”, also known as a PBS. These test environments are used to test any heavy/risky backend changes that could break things or disrupt other people testing on staging. Backend changes merged to a PBS will not be included in the 3pm release and as such will not be a blocker at release time.
I have utilised PBS testing to be more time flexible and plan my day to day testing more effectively. Without a PBS environment I would have to wait until after the release to merge changes to staging and test. With a PBS I can commence testing sooner (without disrupting the release) and subsequently complete the testing tasks earlier. In addition, since thorough testing has been performed on a branch, this allows for a focus on only happy path flows and regression checks once merged to staging. This then leads to a faster acceptance & completion of the feature change or bug.
So to recap; whilst growing in developer size the ways in which the squad has worked to ensure testing keeps up to speed with development are:
- Increasing pair testing between tester and dev.
- Effective labelling of pivotal cards to assign testing ownership.
- Team testing sessions.
- Use of shared test resources for increased visibility on test progress.
- Utilising testing on branch environments to be more time effective.
Different squads of varied sizes may adopt different ways of working in order to help deliver project work planned on their roadmaps. As mentioned earlier in the post, what has been outlined could be of positive benefit for teams of all different sizes. I hope the points discussed may be of use to similar tech squads looking to avoid testing bottlenecks, more easily reach their ‘definition of done’ and create more streamlined processes for the development and testing phases of the work they deliver.
Jon Welch — Senior Test Engineer at Bloom & Wild
—
If you fancy joining us at Bloom & Wild then we have roles open for both testers and developers. Head over to our careers site for more details.
