The software Quality Assurance role (QA) has traditionally been seen as a person who finds bugs and tries to break things. While these tasks still remain a big part of the QA’s role, the industry has seen a shift towards a more holistic approach where the QA role advocates for the overall quality of delivery — both product and process.
Incorporating the exercise of “shoulder checks” into the agile software development lifecycle increases quality output. The “shoulder checks” practice, also known as the three amigos, shifts the responsibility of quality to the entire team.
In this post, you’ll learn what shoulder checks are, how to implement them in your team, and what benefits you can expect, so you can successfully implement Quality as a team responsibility.
Once a developer finishes writing a feature and before they merge it, they initiate a quick 5–10 minute shoulder check (in person or in a video call) with a QA, and if required, a designer and business analyst.
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.
Shoulder checks would normally be for big features - developers could screen record or skip the shoulder check for smaller features. If anything needs to be fixed as a result, the developer can do so before merging. If the shoulder check passes, the developer can merge the feature.
Once merged, the QA/tester will test that feature and can then 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 shows where shoulder checks can fit in in an agile software development lifecycle using Jira:
Shoulder checks involve more team members in Quality and ensure that the entire team focuses on quality output. This sort of “co-testing” leads to more knowledge sharing organically. Developers learn more about testing and testers learn more about development and implementation.
Sometimes a bug is not a bug, it’s intended behavior. Instead of having to message a developer about a specific “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 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, you can have misconceptions about the agreed designs. However, through shoulder checks with the team on how the product should look and function, you avoid creating a bug ticket.
Many QA’s know this familiar story- it’s 3 pm on the last day of the sprint and the features are finally starting to be assigned to you for testing. ALL EYES ARE 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 been co-tested before the end of the software development cycle which gives clients some certainty around the stability of features in the next build.
In some teams, the client’s Product Owner, BA, or QA can join in on shoulder checks as well. This helps align/confirm client requirements in the built feature. Including clients in shoulder checks, allows 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, clients are more aware of delivery progress in advances such as delays in a feature due to critical bugs or missed acceptance criteria during shoulder checks.
When critical functionality is tested earlier in the sprint, it helps expose any risks to delivery earlier on. One of the biggest time wastes 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.
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.
Avoid implementing a process just to implement a process. Seeking a new process 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 and understand if they have any concerns or hesitations. If shoulder checks feel like a waste of time or are not beneficial in any way, you should revisit the process and remove shoulder checks after a few weeks of trial.
After sharing the shoulder checks process with your team, write a small summary with a few points about how it can be run and link it to somewhere where it is visible. Don’t get too detailed with this summary and highlight only the most important aspects.
For example, a summary could look like this:
In order for shoulder-checks to work, 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 organize these shoulder check calls but once the rhythm is created, developers should be initiating the shoulder checks when they are ready.
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. It could be that you choose to bring in the other developers into the shoulder check if there is a discrepancy in the feature behavior across two platforms for example and align.
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., a list of changes that need to be made or if it passed the shoulder check) in your messaging system thread or the Jira ticket itself can help communicate the progress/changes needed for that feature.
The biggest takeaways from shoulder checks are an increase in quality output, fewer feedback loops, and closer teamwork and visibility.
Shoulder checks are easy to implement and can significantly improve Quality. That's because this shift-left approach brings testing sooner into the development lifecycle and gives more focus on quality throughout the entire software development lifecycle.
If you want to improve quality as a team responsibility, shoulder checks are an easy way to bring more visibility, transparency, and collaboration into your work.