Try Dev Box Testing And See How Much Time You Can Save

• Imagine that you and your team have created a perfect process. You've set up a board with the relevant columns, established a nice workflow for Github, and created scripts for Continuous Integration. Everything is working as it should. Metaphorically speaking, you're following the recipe by the book, but are you going to risk tasting it when it's finished, or will you conduct a taste test each time after you season? 

Every time a developer pushes a change scripts, it automatically triggers dozens of tests and validations. Some other developer reviews the code and makes improvements, changes are made, some more pipelines run, and then the code is automatically deployed to an environment where a QA Engineer can start testing.

During the first five minutes of testing, the QA Engineer notices that the developer has forgotten a simple, but necessary requirement. He then creates an issue in some track system, and the whole process repeats, perhaps many times.

Does this sound familiar to you?

It shouldn’t. Let me explain why. 

We're so stubbornly set in our processes, that we forget an important Agile manifesto value:

'Individuals and interactions over processes and tools.'

That's what Dev Box Testing is all about - setting the tools aside for a moment, and interacting with human beings. Here's why: 

• Rather than pushing the changes to a repository after coding is finished, the developer should show what he implemented to a QA. The QA should then evaluate it for ten to fifteen minutes to check if the basic criteria and scenarios have been accomplished. If something doesn't seem right, the QA can then communicate the issues directly to the developer, and the defect can then be quickly fixed. Piece of cake, right?

So what are the main advantages of this technique?

• -Results in quick feedback which saves a lot of time - trust me. 
• -It improves team communication. 
• -It saves server (pipeline) resources.
• -It helps to avoid unnecessary tickets.

Here's a diagram to help you visualize how much time you can save compared to a normal bug fixing cycle:

It's a free and easy  time saving technique that's simple to implement, so why not give it a try? Whether you're a QA or a developer, you can bring this culture into your team. Happy testing!