Improving the quality of deliveries and team growth with the Dev Box technique
One of the most important rules of agile development is fast feedback. The faster we know if the product we are developing is valuable, the faster we can make changes and deliver a better product. “Valuable” in this context can mean many things: Absence of critical bugs if the product solves our customer problem, nice UI and UX, high code quality, and so on. Is there a way that we can test all those at an early stage of development, so we can have that fast feedback? Yes, there is! In this article, I will talk about a technique called Dev Box.
First, we must discover which is the earlier step in the development process that we can test our software and still receive precious insights. Well, we know that the later step possible is production, but is too late. If we found a critical issue on production, we already lost time on development, deploying to a developer environment, verify if it works, deploying to production, and then testing on production. We would need to run this entire pipeline again to fix this issue. Because of that, this should be the least possible scenario to happen (overall sometimes it will unfortunately happen). The next logical conclusion is to test when it is deployed to a test or development environment. Even though it’s earlier and faster than production, it still consumes some time because the developer has to push the changes to the repository, open a merge request, wait for code review, and automated tests, and then deploy on a development environment to test. It’s earlier, but not earlier enough. So the earlier step that we can test for worthy information is just after the development is complete, before the commit or push to a repository. At this point, we already have a complete testable code and all the time used was only for developing it.
Now that we have already discovered when to start testing code, we must learn how to test this code effectively. At this point, you are probably asking how would a QA test this code if it exists only on the developer machine. The answer is pairing! A quick pair session between developer and QA to test a feature just developed. The objective is to verify together if this new feature matches all acceptance criteria. The testing occurs on the developer machine, therefore, “dev-box”. Besides testing, this session also improves the relationship between dev/QA, and both can learn a lot with it. QAs can learn better about how the code works, system limitations, the application architecture, and other technical knowledge that only the developer knows. On the other hand, developers can learn how to test better: acceptance criteria, improvements to code, and other knowledge that only the QA knows. So beyond testing the application, the Dev Box process also evolves the team knowledge and synergy.
The whole Dev Box process should take between 5 and 10 minutes, so it’s easier to fit it into the development process. First, the developer explains what he just developed: what the new feature should do, changes that he made to the code, cases he already tested, and any information he finds relevant. Then do the testing together: The developer shows, step-by-step, all the test cases he thought for this feature and review together with the QA if they are approved. After this, the developer, and the QA can discuss if new tests should be added or if fixes/improvements should be made on code.
If everything is fine, then go ahead and push it to the repository. If improvements can be made, then write them down and apply them to the code. You both should decide if another dev-box session is needed to validate the new changes and improvements.
To conclude, Dev Box is easy to introduce and easy to maintain a quality process that speeds up the feedback loop, making it possible to find bugs and improvements faster and earlier. Moreover, it also improves team synergy and accelerates the growth of developers and QAs.
