Quality as a Team Responsibility

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”) 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 for anyone interested.

Image for post
Image for post

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:

Image for post
Image for post

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 be addressed during the shoulder check.

Through these shoulder checks, there is more cross team knowledge on the product and how it functions and is supposed to look. Sometimes, due to lack of communication as well as having the UI design not reflected in the ticket acceptance criteria, it tends to cause some misconception on how the product should look like. However, through shoulder checks with the team on how the product should look and function, we avoid creating a bug ticket.

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 have 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.
  • Before implementing shoulder checks, 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. I found having a conversation with each team member privately worked best for me, then I would bring up the summary from the conversations in retro to either implement shoulder checks or address the concerns in another way. 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 and avoid the failure cycle. Additionally we agreed that if shoulder checks felt like a waste of time or was not beneficial in anyway, we would revisit the process and remove Shoulder Checks after a few weeks of trial.

After implementing

  • Be flexible and adapt the process to work for your specific team
  • Do a trial run for a few weeks and communicate that it can be scrapped if it doesn’t help
  • QA (and/or Developers) have to own this process and get the entire team on board (including changing/altering this process if it isn’t actually helping)
  • Developers should be initiating the shoulder checks when they are ready
  • For complex features, bring in the other platform Developer into the shoulder check if there is a discrepancy in the feature behaviour across the two platforms (this helps a lot with cross platform alignment)
  • 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.

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

I am curious to know about anyone else’s experience with this technique and if you have seen success or failure with it!

Senior QA at Propel Ventures

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store