Desk checks or dev box testing
A desk check or dev box testing is an informal manual process for verifying the programming and logic of a story in the developer’s environment, before pushing or merging the code.
“Quality is not an act, it is a habit.” — Aristotle
Regular and methodical dev box testing reduces defects discovered in the later stages of the development lifecycle and saves much time. In good agile teams, dev box testing for every story is a common practise.
In any agile team, the team comprises of various roles. But the participants of a desk check are the following roles:
- Developers (referred to as ‘devs’ in this article)
- Quality Analysts or test engineers (referred to as ‘QA’ in this article)
- Business analyst or product owner (referred to as ‘BA’ in this article)
Benefits of a desk check
The benefits of a desk check are threefold:
- Early Feedback
To find any bugs, mismatch with requirement or missing acceptance criteria.
It helps to align the BA, developer and QA’s understanding on the final story outcome.
- Input to QA to prepare for testing
Based on the desk check, QA knows that the story is going to move to the testing phase soon and can make sure that the required automated tests, environment, list of test cases and test data is ready to test the story thoroughly.
How to go about a desk check
As mentioned before, in an ideal scenario, the devs who worked on the task, BA and the QA are part of the desk check. The following are the major steps in this process.
Step 1 —
Developer (or a pair of developers) pick their story, analyse it and start working on it. They move to step 2 once they are comfortable that the story is “dev complete”. That is:
- code is clean, well designed and solves the problem statement efficiently
- unit tests are complete
- all acceptance criteria are satisfied, including design in case of UI story
Step 2 —
The developer invites the QA and BA to perform the desk check. In case of a remote/distributed team a video call can be set up for the same.
IMPORTANT: Before the desk check starts, the devs must prepare their local dev environment with the relevant test data handy. They must also have the story description and acceptance criteria ready for verification.
Developer : sets a quick context about the story, explaining the inputs and outputs. They must also take note of all the bugs or discrepancies found during the desk check
QA : tests the story for different scenarios, especially edge scenarios. [In the remote situation, the QA can guide the developer to follow steps and observe the results]
BA: actively participates in the testing, specifically focusing on the business aspect of the story.
Step 3 —
If any bugs or discrepancies are found, then developer continues of the development of the story to fix the issues, and call for another desk check when done.
Step 4 —
Developer can move to the code review stage after a successful desk check.
Things to remember
- Test the behaviour — A desk check is a test of the behaviour of the code. Hence, the QA and BA must drive the desk check rather than the developer. A developer tends to be biased, since they know the actual implementation.
- Time box — As far as possible, a desk check must be time-boxed. Maybe not more than 15–30 mins. QAs must beware of going into a complete testing mode.
- Receive feedback well — The feedback of the desk check must be taken positively. It is not meant to blame or point out problems. Its purpose is to identify discrepancies early and help mitigate them.
- Give helpful feedback — As a flip side of the above point, the feedback must be given in a crisp manner with enough reasoning and expected result, so that the developer can take proper action.
- Be sensitive and creative — In case the developer explains that it is difficult to implement a particular suggestion, then the QA and BA must try to understand the issue and cooperate. In such cases, various solutions can be applied depending on the situation. Example, an alternate implementation can be attempted, a tech huddle or discussion can be done with the whole team at a convenient time or the BA can try to negotiate or change the requirement to accommodate.
In my personal experience, desk checks are a very important agile ceremony which helps to fail fast and avoid defects in the future.
For it to be successful the developers, QA and BA have to be aligned with the process and purpose of the activity and take complete advantage of it prevent issues later in the development life cycle.
All the best !