.png){kind=small}
.png){kind=small}
According to a post on the FEMAMA website, the costs for cancer treatment increase according to the stage of the disease. Treating cancer in an advanced stage is much more expensive than in the initial stage. According to the article, the treatment of colon cancer, in the first stage, costs over R$ 4,100. In the third stage, it goes to R$ 77,000. Breast cancer, which costs R$ 11,300 in the initial stage, increases to R$ 55,000 in the third stage. But calm down, you are not going crazy (neither am I), and we are still talking about Dev Box Testing. The point is that we have just concluded that medicine treatment is much more expensive and traumatic than prevention, and the further along the stage of the disease, the cure is more expensive and less likely. Following the same concept, we can reduce the cost of fixing a bug.
The work we would have to fix a potential bug due to incorrect understanding during planning would be very small, close to what we would spend to fix this bug after the functionality has already been delivered to the customer. As the bug would already be on the customer side, he could have financial loss, and loss of confidence in our product, among other problems.
For fixing it, we would have to stop a development team that is already involved in another activity. Developers would have to re-enter the context and understand the functionality until they find the root cause of the problem. This bug would have to go through all stages of the development process, such as code review and testing. A new version would be released to the customer who would have to schedule installation in his environment. What a hassle, isn't it? Now, imagine if this bug had been found in planning. In a few minutes of conversation between the team, what would generate a huge problem in the future could be solved. So, as in medicine, the sooner a bug is found, the easier and less impactful it is to fix.
But what does this Dev Box Testing have to do with it?
Dev Box Testing is the initial round of testing done on the development engine before the code is sent to the repository for review. It is an agile technique whose main objective is to reduce the cost of fixing a bug.
Development cycle WITHOUT Dev Box Testing:
Development cycle WITH Dev Box Testing:
1. On their machine after coding is complete, the developer invites the Quality Analyst to do Dev Box Testing together.
2. With both on the same machine, the developer demonstrates the implemented functionality.
3. The Quality Analyst takes control of the machine and performs some scenarios.
4. If bugs are identified, the developer following the test takes notes.
5. After completion, the Quality Analyst leaves the machine for the Developer to work on the fixes.
If one or both are working remotely and not in person, a tool for remote access can be used or the developer can run the scenarios according to the request of the person responsible for the tests.
• For complex bugs found during the dev box, the Quality Analyst can be called for further validation after the fix is implemented.
• Dev Box Testing is a basic, fast, and straightforward test, and is not intended to replace the complete test performed in the QA environment after submission to repository and code review. The complete test should run normally during the process, mainly because they may have be changes requested in the code review stage or they may be problems that will only appear in the test environment.
• The time taken for this should vary from 10 to 15 minutes, based on the complexity or defect implemented.
And what do we gain from it?
• Reduced feedback loop;
• Less rework;
• More agility in the development process;
• Better coverage of automatic tests;
• Better communication and integration between developer and Quality Analyst.
Imagine having to go back to an activity to perform the whole process again due to a bug that would be easily identified by the quality analyst, in the first test they performed? If this bug creates a constraint, the tester will also have to wait to proceed, even after the activity has been released to them. With the practice of Dev Box, we get faster feedback on problems. This bug would be fixed during development, when the person responsible for coding is still with the prepared environment, and “hands on” the project, which reduces rework since they would not have to go back to fix it after having delivered it.
Of course, most of the time it will not be possible to eliminate all the bugs in the dev box, not least because that is not the goal and the tests are basic. However, eliminating as much as possible in this step is essential, so that the most complete test, done after the code review process, can be done with more time and focus.
One of the benefits of this practice, in addition to faster feedback, less rework and more agility in the development process, is the improvement in the coverage of automatic tests performed by the developer. With this exchange of knowledge at the time of the dev box, the developer gains inputs to implement their tests so that they can cover a greater number of scenarios.
We know that teamwork is extremely important in agility, and even with teams formed by people with different specialties, the communication between them also changes. The quality analyst and developer sit down together to apply the Dev Box, which further establishes a better relationship, communication, and partnership between them, since both are focused on that moment and contributing to make the process more agile and deliver the task to the customer with greater quality in less time.
The purpose of this procedure is to streamline the development process, anticipating problems, so that the fix costs are lower, making the bug's life cycle shorter, saving time to focus on the scenarios that are most critical for the system.
The way of working presented here is a suggestion. You can and should adapt to your team and project that has specific characteristics and particularities, always thinking about reducing rework, and enabling more agility, quality and interaction between team members. As this is a simple practice, which has a positive impact, it is easy to include it in the team flow. So, what are you waiting to implement it and reap the results?
“The idea of applying dev box testing was just brilliant! During local test performance, they prevent bugs from advancing to other environments, as well as allowing the perspective of QA and the view of different scenarios. Hence, we have this in-depth analysis during development time. It is an extremely important practice for any system! - Gian Raphael Martins da Costa - Software Developer “
“Dev Box Testing has helped to pre-validate the development cycle. We are managing to anticipate problems and deliver flows for QA to follow without several interruptions caused by problems. Therefore, we are reducing problems that could pose a risk for Sprint and increasing the quality of product delivery. - Matheus Bongiorno - Software Developer”
“Dev Box Testing reduced time in the development flow, bugs can be identified faster and with less bureaucracy, in addition, this dynamic encourages those involved to identify alternative flows not previously seen, allowing greater coverage in the treatment of potential errors. - Daniel Elvis Quevedo - Software Developer”
“When we started using Dev Box in the team, it was difficult to assimilate that after deploying the application to be tested, the answer we got was:“ EVERYTHING IS CORRECT”, we were surprised, how is everything correct? no bug? NO. This has been happening due to the coexistence with QA provided by the practice of Dev Box. Programming has become somewhat preventive, as the points of failure are becoming increasingly clear. - Edson Pereira do Nascimento Junior - Software Developer”
“Devbox testing helped us improve the quality of delivery between the development and testing phases, reducing the number of basic errors found by the QA team. - Eduardo Marinho David - Software Architect”
“The dev box testing process helped a lot in deliveries, ensuring even more quality for the customer, who has been really satisfied with the result. - Alan Marcel da Costa - Product Owner”
“Dev Box Testing was a practice adopted in our sprints that brought many benefits. What initially emerged as a pilot in our projects ended up becoming an activity present in basically all our tasks. We applied this good practice for approximately 6 months and found that the number of bugs reported in the test stage decreased significantly, consequently there was less rework, both in the development and test stages, and provided even more quality in deliveries and better use of time in the sprints. Although our team has always worked in a united and collaborative way, this joint activity increased teamwork and allowed the developers to get to know and understand a little more of the work performed by the test specialist. Positive feedback came from all sides: Customers were happy with the quality of deliveries and low number of bugs in the production environment, as well as a united, engaged and motivated technical team. - Renata Gumerato Aguiar - Team Leader “
“Dev Box Testing brought even more agility to a team already used to great development practices and agile processes. We noticed that there was an improvement in integration between developers and quality analysts, in addition to greater care with the quality of the source code and understanding of the importance of tests. - Natalia Bortoletto Cruz - Manager”
