agile techniques – Dev Box Testing

Dev box testing is a practice all teams should be doing. The idea is simple. When a developer writes a piece of code, which may have been to fix a bug, or implement a task within a story, just before the code is committed to the source control repository, the developer should ask the assigned tester and BA to come and sit at the developer’s machine to demo the changes that have been made. Hence the name dev box testing.

The steps involved in dev box testing can be summed up with the following:

  • The developer should demonstrate what he/she has done and run through the changes to the application that has been made.
  • The developer should let the BA or tester run the application and perform at minimum happy path testing.
  • This provides an opportunity for the BA to ensure that what has been produced meets the requirement.
  • This allows the testers to understand what has been developed. The developer should share with the tester information about how to test the code change by means other than just the UI, i.e. any database changes, service calls etc.
  • If any issues are found, the developer will fix them, and get them retested before anything is checked in.
    • Dev box testing commonly should not take any more than 10 minutes. It’s real value is that it allows for code to fail fast, which although that may seem a bit dramatic, is actually a really good thing! For example, even if you have a fantastically slick continuous integration process in place, the code still needs to be committed to source control, unit tests run and then deployed to a test environment before a tester and the BA can access the code change. This means there is always a delay in the code change being available to test, once it has been checked in. If a defect is found, such as a bug, a piece of functionality is implemented incorrectly or not at all, a vicious cycle begins. This is outlined in the diagram below.

      typcial flow before dev box testing

      Dev box testing helps by minimising the feedback cycle in terms of time. This is because code is tested before it is checked in. Any defects or requirements not implemented can be picked up and dealt with immediately. This also greatly improves the sharing of knowledge held by the developer with the testers. This knowledge sharing allows the tester to truly understand how the changes were implemented and understand how the application can be tested under the covers, away from just UI testing. Sharing this knowledge whilst it’s still hot, fresh in the developers mind is essential.

      The diagram below outlines a typical dev box testing flow. The key point to understand is that after the developer initially writes the code, the flow moves into an iterative cycle, between having the code dev box tested and the developer on the back of that coding any changes. This cycle repeats until the BA and tester are happy with the change made and the code can be committed to source control.

      dev box testing flow

      Dev box testing strongly encourages collaboration between the BA, developer and tester because it forces conversation, which is key to the success of successful software projects. It is important to point out that dev box testing is not about performing a full regression test, but more of a sanity check to ensure no obvious errors get deployed.

      Dev box testing is a great tool in the agile armoury that every team should employ. Any technique that aims to reduce bugs that are committed into source control, and actively encourages collaboration between team members has to be a good thing. There is no reason why you can’t start today!

You may also like...

4 Responses

  1. Vin D'Amico says:

    Outstanding idea! A side benefit is the increase in communication and collaboration that takes place. Everyone develops a better understanding of how the software works and why it behaves the way it does. Learning is enhanced and the final delivery is bound to benefit.

    Thanks for sharing.

  2. Like many things on the tinterweb this probably has many names. I myself call it a “show and tell”. I talked about it here:

    I think anything that takes a proactive approach to testing is invaluable. This itself if handled correctly I’ve found actually builds up strong bonds between the developer and tester. It is no longer a reactive, disapointing chat or email, you both face the challenges together and learn to improve one another.

    Good stuff! Thanks for sharing.

  3. Sharath says:

    Nice post Andrew. There are no doubts on the benefits of this process. We used to do something similar in our project but called it “demo” to the tester. The tester was encouraged to run positive tests on Dev’s PC during the demo. But I like your term -> “Dev Box Testing” :)

    Though this was an excellent feedback loop we could not keep up with it. Some reasons were
    – Testers were occupied in testing sessions when the developer wanted to move the story to testing
    – Product owners stuck in a meetings or un-available
    – 2 or more developers want to move their stories to testing

    But if this process suit your context +1 from me to the idea

  4. Nice post – thanks for sharing.

    Taking it one step further, we (Testers) also look at the supporting test code. This gives us a chance to help ensure the regression tests/checks are relevant – instils more faith in the CI process.

    Another great advantage of dev box testing is helping the move towards the whole team approach. The Programmer/Tester pairing (more so than BA – thats a deeper conversation) helps the Tester by having a greater understanding of the code e.g. in terms of regression testing. It helps the Programmer understand how Testers think and as such help them test e.g. building testability into the code, writing automated checks which the Tester would think of that a Programmer might not normally think of.

    I’m a Tester, BTW

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">