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.
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 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!