The software Quality Assurance role (QA) has traditionally been seen as a person who finds bugs and tries to break things. While these tasks are still a big part of the QA’s role, there has been a shift towards a more holistic approach where QAs advocate for the overall quality of delivery — both product and process.

As a QA, I have found that incorporating “shoulder checks” (some call it “desk checks”, “3 amigos” or “walk-throughs”) into the agile software development lifecycle seem to significantly help with quality output. This also shifts the responsibility of quality control to the entire team. In no way am I saying every single team or project should do this- this is just simply my learnings and tips.

Case Study

I was working in a digital consultancy firm as a Test Analyst and joined into a large mobile app project that was already almost a year into development. It was March 2020, which as you know meant COVID was about to hit Australia. A week into onboarding to the project, the entire 12 person internal team was forced to work remotely. With so many moving parts and different integrated third parties, I found it quite challenging to understand how everything worked, including the technical details and features built.

During the first couple of weeks, it felt like the first time I was seeing a feature was when the user story was assigned to QA for testing. Occasionally, the behaviours/designs varied across iOS and Android. Sometimes, this was intended due to native limitations. Other times, however, the differences were a result of miscommunication. Coincidentally, other team members felt a bit of a disconnect as well (e.g., Android Developers from iOS Developers, Developers from QA, QA from Developers, etc.). This was also apparent in the output of work as some tickets seemed to go back and forth between QA, Business Analysts (BA) and Developers, which resulted in missed bugs.

At last, a solution was born — Shoulder Checks!

How it works

• After the Developer has finished writing a feature, but before they merge it, they initiate a quick 5–10 minute shoulder check with a QA, and if required, a Designer and BA
• Shoulder checks would normally be for pretty big features- Developers could screen record or skip the shoulder check for smaller features (this is up to the team to decide)
• During the shoulder check, the Developer will showcase each acceptance criteria, the QA can ask the Developer to verify other cases they are aware of, and the designer can validate that the designs match the specifications
• If there is anything that needs to be fixed as a result of the shoulder check, the Developer has the opportunity to do so before merging in the feature
• If the shoulder check passes, the Developer can merge the feature
• QA will test that feature and can now focus on exploratory testing and edge cases since most of the critical functionality has already been co-tested during the shoulder check

The following flow chart is an example of what the process can look like and where shoulder checks can fit in:

How I’ve seen it benefit:

Team

Shoulder checks involve more team members and quality checks. It helps ensure that the entire team is focused and responsible for quality output. This sort of “co-testing” leads to more knowledge sharing organically. Developers tend to learn a bit more about testing and testers learn a bit more about development and implementation. Sometimes a bug is not a bug, it’s intended behaviour. There have been many times where I check with a Developer about a bug I am about to report but it ends up being a native limitation or additional requirement from the ones laid out. Instead of having to Slack a Developer about this “bug” or even write up a ticket for it, it can be picked up and quickly addressed during the shoulder check even before the code has been merged.

Through these shoulder checks, there is more cross team knowledge on the product and how it’s supposed to function and look. Sometimes, due to lack of communication as well as having the UI design not reflected in the ticket acceptance criteria, there can be misconceptions on the agreed designs. However, through shoulder checks with the team on how the product should look and function, we avoid creating a bug ticket (check out Jo tan’s article on Creative QA from a Designer’s perspective on Shoulder Checks).

Additionally, if a feature’s acceptance criteria has been missed while I am testing, I feel a bigger sense of responsibility because that is something that I could have identified earlier during the shoulder checks.

Clients

I’m sure many QAs know this familiar story- it’s 3pm on the last day of the sprint and the features are finally starting to be assigned to you for testing. ALL EYES ON YOU. That leaves you a two hour window to test and pray features have met at least the critical acceptance criteria before handing the build over to the client.
With shoulder checks, critical functionality has already been co-tested before the end of the software development cycle (end of sprint) which can help give clients some certainty around stability of features in the next build (or a heads-up that the feature will most likely not be ready at the end of sprint).

In some teams, the client’s Product Owner (PO), BA or QA join in on shoulder checks as well. This has helped align/confirm client requirements in the built feature. Including clients in shoulder checks has also allowed them to be more involved in the development process instead of just sprint planning in the beginning and user acceptance testing at the end.

Overall, clients should have a better product at the end since features have been through more quality gates. Additionally, they are more aware of delivery progress in advance such as delays in a feature due to critical bugs or missed acceptance criteria during shoulder checks.

Delivery

Shoulder checks have seemed to improve overall delivery of products. Critical functionality is tested earlier in the sprint, which has also helped expose any risks to delivery earlier on. I find that one of the biggest time suckers is when QA has to reopen a user story due to a failed or missed acceptance criteria. This is easily caught in shoulder checks and reduces the back and forth later on in the sprint. Subsequently, there is more alignment on requirements and the features that are built as QA, designers, BA and Developers are communicating frequently.

One of the biggest benefits I have recognised from shoulder checks is the quality in design. I have a terrible eye for design and pixels, but a designer can easily and quickly pick out such issues right away during the shoulder check. Having designers in these shoulder checks is even more beneficial and important if the application is design heavy. On one project, Developers would tend to send screenshots of new screens that they are currently implementing as a rough draft to get design feedback earlier on.

Tips

Before implementing

Think about if and why shoulder checks are needed for your team

I would recommend avoiding implementing a process just to implement a process. This should be a result of some issues your team is looking to improve on. If your process is already working great, shoulder checks may only slow it down.

Have a conversation with the team to see if they are mostly onboard

At this time, it would be good to understand any concerns or hesitations. One common concern of shoulder checks was the additional time it would take. Previously when a user story failed and had to be reopened it took quite a bit of time to investigate, write out the issue, coordinate with the Developers on a fix and then have to re-test again. Ideally, shoulder checks should reduce the overall time in delivery since user stories would be reopened less often and avoid the failure cycle. Additionally we agreed that if shoulder checks felt like a waste of time or were not beneficial in any way, we would revisit the process and remove Shoulder Checks after a few weeks of trial.

After implementing

Document the process out and how it should work

After communicating with the team, I link them to a confluence page with the flow diagram and a few dot points about how it can be ran like in the screenshot below

QA (and/or Developers) have to own this process

The entire team needs to be on board (including changing/altering this process if it isn’t actually helping). In the beginning, it might take a few nudges for the QA to organise these Shoulder Check calls but once the rhythm is created, Developers should be initiating the shoulder checks when they are ready.

Be flexible and adapt the process to work for your specific team

Every team works differently. It’s important to see what’s working and what isn’t and adapt the process to continue creating efficient and effective processes.

For example, we found that for smaller features (such as the creating static pages in the app) a screen record thrown into a slack channel of the feature was enough for a shoulder check.

We also found for more complex features, bringing in the other platform Developer into the shoulder check if there is a discrepancy in the feature behaviour across the two platform helped a lot with cross platform alignment and integration.

Post the notes from the shoulder check somewhere

Sometimes it’s hard to remember what was agreed upon to change or why something was implemented in a certain way.

Posting notes from the shoulder checks (e.g., list of changes that need to be made or if it passed the shoulder check) in the Slack thread or the JIRA ticket itself can help communicate the progress/changes needed for that feature.

Phew, congrats on getting to the end

After working the concept of shoulder checks with three different teams at three different companies this year, the biggest benefits I have seen are an increase in quality output, less feedback loops and closer teamwork.

I will leave you with a fun fact: The term “shoulder checks’ derived from working in person and just looking over the shoulder of the developer demoing the feature to the QA, Designer and BA.