Dev Box testing, name comes from the practice where initial round of testing is done on developer’s(Dev) machine(Box) before the developer checks in the code to the source repository and mark the task (story or defect) as development complete.
I feel this is one of the crucial step towards getting faster feedback, every task done by the developers gets tested on their machine by BA’s & QA’s and feedback is provided on the spot, it sounds very simple and yes it is simple if followed properly else it could turn out to be chaotic.
How it should be done ??
There is no formal process of how it should be done so it’s best left to the team, few ways I have done it so far.
- The developer demonstrates the functionality implemented and run through the changes that has been made and impact on other functional areas to BA & QA who took the responsibility of that defect or story.
- Developer handover his/her machine to QA or BA to run through scenarios, mainly happy path scenarios and make sure goal of the task is accomplished.
- Time spent for this should range between 10 to 15 minutes based on the complexity of the story or defect implemented.
Where does it fall within iteration ?
Why teams should follow:
- Faster feedback, it reduces the significant time to find defect and get it fixed, in usual iteration model where this process is not followed feedback will come very late and if defect found it will get into priority queue and developer available at that point in time will fix it, turn around time in this case is quite high.
- BA gets an opportunity to ensure that implementation meets business requirements.
- Developers & QA’s can share knowledge and context around how QA’s test complex stories beyond UI e.g. with service calls, databases, etc and developers can share better ways of doing the same thing.
- Most importantly, if issues are found developer can quickly fix them and get it tested faster.
- Time utilisation, developers can utilise the time when they run the build locally before check-in.