Test Early and Collaboratively with “Desk Checking”

Republishing my article here from an old blog site. Desk checking is still, to date, one of the most useful and widely adopted practice of the agile teams I have coached; here’s a breakdown of how it works.

A desk check is when a developer demos to the team (testers, analyst, other developers) a partial or completed item or module. The goal is to inspect the solution fast and do quick changes if necessary without the code leaving the developer’s local machine.

WHY? FAST FEEDBACK AND SHARED ACCOUNTABILITY

A shorter feedback loop is key to failing and learning fast — or validating whether we’ve done the right things and if we’ve done the things right. Through desk checking, the developer gets validation against acceptance criteria from a tester’s and analyst’s (or other team member’s) perspective right away.

Any issue can also be discovered and fixed quickly without progressing to any environment beyond the developer’s local machine

It also creates a shared accountability on quality. Desk check facilitates this through team collaboration rather than separation of responsibilities where only the testers are responsible for inspection (e.g. a “throw-off-the-wall” testing mindset).

The goal of desk checking is to inspect the solution fast and do quick changes if necessary without the code leaving the developer’s local machine.

HOW? CHECK EARLY AND OFTEN

Do desk checks as soon as there is any work item that can be presented to others for feedback, and before the developer moves onto another task.

On a typical desk check, the developer calls out team members and shows the solution to them including running common usage scenarios that meets the acceptance criteria and discussing technical aspects that may be relevant to the audience.

A tester/analyst can raise bugs or problems during the session, or agree with the developer that acceptance criteria has been met (at least on the surface). They can also run some exploratory tests while at it. Other developers may also pitch in a test or two or probe to understand the system design even more.

HACKS

We’ve found some good practices and tweaks to desk checks over the years; consider trying them out and taking in what fits:

• Timebox and Goals. Desk checks could be tedious and lengthy if not time-boxed (15 minutes seemed reasonable) and set with a goal (“check against acceptance criteria” or “test against major risks”). Make sure to agree on these constraints early on.
• Soft-Logging. Consider soft-logging the feedback (e.g. comments on the task or story, write them down on post-it notes, post in the chat system) rather than formally tracking them in the bug repository. Note that speed and team accountability is of utmost interest, so any “process” added could be an overhead. Keep it simple.
• Technical Details. Usually it helps if you discuss high-level technical details such as APIs, data tables, and configurability on the session. This helps testers design better tests.
• Do it ASAP. Some teams end up not doing desk checks because the audience (e.g. testers) are busy or unavailable. However, the goal is fast feedback loop; and while it’s best to demo with as much stakeholder as possible, their absence should not hamper getting fast feedback. Just grab another team member (or anyone who has some level of understanding of the scope) and get it moving quickly.
• Do it on bugs too. Ideally, everything is desk checked. Practically though — some bug fixes are too minor to even spend time to validate together (e.g. alignment issues, spelling mistakes). Feel free to decide as a team on what you’d like to do desk checks against.
• Include the Product Owner or UAT Testers. Desk check can also serve as a quick way to get feedback from the product owner and end-users, or walkthrough the functionality to a separate user acceptance test team.

DESK CHECKING FOR REMOTE TEAMS

I have worked with remote teams where we had some members working out of Melbourne, Australia and the rest in Manila, Philippines.

What typically worked with this setup are:

• Calling out desk checking through the chat system (we used Slack)
• The developer sharing his screen for the demo (we used Skype, Google Hangouts, or Screenhero)
• Complementing it, whenever possible, with a video conference (through Skype or Google Hangouts)

It could be challenging if your teams are in a big timezone gap. On these cases, it might be best to do local desk checks rather than involving the remote team. Consider changing your team structure to allow this to happen (e.g. consider Spotify’s “squad” model).

ACT AND ADAPT

So far, I have not seen a team that rejected or stopped doing desk checks after we’ve introduced them. There’s a lot of benefit finding and fixing obvious problems fast without the developer switching to a different task yet, and whether you’re in an agile or traditional development environment I believe desk check is worth trying.