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.
How “shoulder checks” work
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:
The benefits
1. Knowledge sharing and better understanding
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.
2. Functional criteria are tested before release
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.
3. Improved delivery rates
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.
Tips to consider before implementing
Think about "if and why" shoulder checks are needed in your team.
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.
Communicate with your team to see if they are mostly on board.
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.
Tips to keep in mind after implementing
1. Document the process out and how it should work
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:
- 10-15min huddle with Dev, QA, Designer (if front end), and Business Analyst (optional);
- Live demo of user story implemented by dev, to verify designs;
- Agree which environment to use for testing activities;
- The purpose is to catch any critical issues with functionality/design earlier in the process and reduce feedback loops.
2. Both QA & developers have to take responsibility for the process
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.
3. 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. 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.
4. 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., 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.
Make quality a team responsibility
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.
