“Individuals and interactions over processes and tools” — Agile Manifesto

For those that work with a Scrum framework, ponder for a moment about your work context. It’s quite dynamic, isn’t it? In the blink of an eye, the user stories are finishing, and the scrum rituals are right around the corner. In such a volatile environment, what’s the quickest way of exchanging information?

The manifesto states that human interactions should take priority over tools and frameworks. In practice, it means that an agile context needs fluid communication and rock-solid teamwork so that the team can mature properly.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” — Agile Manifesto

Why you should keep reading

This article is for someone who’s looking for ways to improve the dialogue between testers and developers, the people that want to strengthen the ties between them and devs, and if you want to anticipate the testing activities and have no idea how. Even for you, tester, who fears looking into the source-code abyss — as it will look back into you. Don’t worry, I’ve got you!

Agile teams that are still maturing tend to try out new procedures when, in fact, they should focus on a more proactive, less formal communication to add fluidity to the team. Throughout the article, I’m going to show you two techniques. Combined, they become a powerful practice for alignment and flexible conversation.

DevBox Testing

In agile contexts, specially during maturation, it’s common to see the software development flow in this direction:

1. The user story is refined by a developer;
2. Once refined, the story is then pieced into smaller parts, the tasks. Usually, this happens during the sprint planning;
3. The code for the story start being assembled;
4. Developers perform local tests, possibly also concocting the unit tests;
5. Pull-requests are created and revised during the code review;
6. Once approved, the pull-requests generate a software artefact that will then be tested by the QA.

Notice how many steps there are before the code is released for testing. Practising DevBox seeks to shorten the feedback cycle provided by the testing process.

The concept of DevBox Testing is represented in a gamut of perspectives. The most common description, present in most of them, is that DevBoxing is a process that happens before the code review, where QAs test the application locally, inside the developer’s machine (box), then anticipating inconsistencies that would only be found after that piece of application is finished.

For its flexibility, many teams implement their own versions of DevBox. I point out to some additional aspects described by Chinmay Karadkar in his article:

1. testers should verify unit and integration tests that were developed during the user story;
2. They should also question the software, seeking to understand verbally how the developer feels about what they’ve accomplished. For example: “is there a better way to implement this code?” or “how confident you are in this feature?

The key aspect of this procedure is that, when performed in the developer’s machine, the interval between identifying a failure and correcting it is shortened, leading to cleaner codes.

Rubber Duck Debugging

The name is a reference to a story in the book The Pragmatic Programmer, by Andre Hunt and David Thomas, where a developer would walk up and down with a rubber duck in his hand.

This debugging technique consists of acquiring a rubber duck (or any other object), and showcase to them what you aim to achieve, explaining the code line by line.

There is psychology at work behind the scenes. In his article, David B Hayes explains why it works, pointing out to two stages:

1. When we do something we’re used to — like coding — , we tend to do it on auto-pilot. The actions simply flow, we don’t have to think too much about it. Then, when we need to explain what’s being done, our brain is rewired to reflect on it and structure our reasoning in a way that could properly express it. Here, we’re forced to revisit our logic;
2. Complementing the previous aspect, the second stage makes us ponder about the different cognitive abilities that our listeners might have. It triggers two different psychological aspects:

• The first one, explained by Piaget’s theory of cognitive development, happens when we are faced by a situation where we have to explain something to someone who possibly has a different understanding of it than us. In many cases, this difference in knowledge is so big that we have to create analogies and simplify the logic so we can be understood;
• The second effect is that we learn more when we teach. Teaching someone else about a given topic forces our brain to deeply analyse the subject, taking into account various contexts so that people of different backgrounds can understand what we say.

These two aspects, mixed together, give developers a profound understanding of their code, often leading to uncovering failures in their logic.

How do these techniques combine? We’re about to see it now!

Enhanced DevBoxing

I created this technique by combining the DevBox Testing and the Rubber Duck Debugging. I really tried to name this as Rubber Duck DevBoxing, but it lacked the punch the practice has.

When I started working in an agile team, around 2020, I just migrated from a context where I had convinced myself that I didn’t need to deal with code. This switch made me realise I had to completely leave this conviction behind. I had spent years running from coding, only to find myself in a situation where either I make amends with it, or drown.

Within months of work, my tester colleague and counterpart suggested that we implemented DevBox Testing in our teams, as a way to anticipate our testing.

There, I gazed at the opportunity of reconnecting with software code and still adding value to my team. Leveraging our maturation and strong amity between the team members, I managed to bind our DevBox practice to the premises of the Rubber Duck Debugging.

In this combination, you, tester, are the rubber duck.

During an Enhanced DevBox session, tester and programmer sit together to talk about the user story. Before even a single pull-request is created, the duo schedules one or two hours to walk through the code. Here, the developer explains what was coded, the reasoning behind it, what it seeks to achieve and, finally, unit and integration tests that were (or were not) developed for that story.

To work, the technique needs that some criteria is met:

• It should happen before code reviews;
• The tester should have properly indulged themselves in the user story and any other source material used for coding, whilst also actively engaging with the planning and refinement rituals;
• The testing starts only after the code is understood and accepted by both parties. The detailing level should be previously established and, preferably, the code should be questioned during this phase. This step is highly susceptible to code refactoring;
• Unit and integration tests should be revised. Then, the developer combines their coding knowledge with the testing expertise wielded by the tester, making the test scripts more efficient;
• The bugs found should be considered as an integral part of the development process, therefore correcting them is more important than formalising them by opening tickets;
• In some cases, code improvements can take long to be implemented. As such, the people involved should converse and define an action plan. New development tasks and/or tech debts can be formally written and prioritised.
• The Enhanced DevBoxing is concluded when all aspects above are satisfied or the parties reach an agreement.

The Benefits of Enhanced DevBoxing

Being the rubber duck has its advantages. Implementing this practice on my teams, I’ve observed a few aspects that set the tone for how the stories are developed:

• Not only do developers learn more about their code, testers also acquire a deep understanding of the application;
• The code becomes less and less scary to the tester, thanks to the consistent work of devs at explaining it;
• The feedback cycle of coding-testing-failure is greatly shortened;
• The bugs found can be immediately corrected and quickly mapped — because what adds value to the end user is fixing the bugs, not finding them;
• Developers and Testers learn to communicate in a non-aggressive, highly collaborative way;
• Trust between team members is increased as a whole;
• Developers start, little by little, to think like a tester, embedding quality to whatever they do. And vice-versa. This is a high indication of a quality culture.

Proof of Concept

What do the Devs have to say about this?

I performed an inquiry with the eight developers on my team to understand how they feel about Enhanced DevBoxing.

Using a form, I collected their answers on what they feel and their understanding of the practice.

Perceived Value

When asked about what they valued on Enhanced DevBoxing, the answers pointed out to “increased code quality”, “greater interaction between programmer and tester”, and “anticipated problems”. Below, some samples on their responses:

“Allows us to notice more details before delivery. There’s an incredible improvement on the quality of software artefacts, whilst also reducing our rework rate to almost zero. There’s also a tighter expectation alignment with the QA, allowing us to keep them informed throughout the entire process, instead of just throwing the application onto them, saying ‘now you just gotta test it’.” — Android Developer, 8 years of experience.

“Tester and devs in a better alignment, both with a greater knowledge on what’s been implemented. Two heads think better than one, isn’t it? Also, errors and improvements are mapped and worked on much faster” — Android Developer, 7 years of experience.

“In my understanding, this practice makes developers more confident on their deliveries and if the development matches what was established on the user story. With Enhanced DevBoxing, we can identify detours, and small problems can be fixed on the spot, improving and speeding up the deliveries.”— Java/Android Developer, 20 years of experience.

What It Takes to Make It Work

The Enhanced DevBox is an alignment process between two or more people, usually a developer and a tester. As such, there are a few fundamental aspects for it to flow properly.

Asked about why the practice works on their team, the devs gave me a variety of answers, but all of them pointed to shared responsibility and high maturity of those involved. In particular, they mentioned that the tester has to have a greater technical knowledge and ownership towards the product. Some of the testimonies are:

“I think it’s highly advantageous when the tester has ownership, a strong analytical look and tries to learn from the developers perspective. I’ve worked in contexts where the tester had little to no interest in knowing the details about an implementation, just wanted to perform functional tests. In these scenarios, I don’t think the Enhanced DevBoxing would be effective. I’ve also worked with testers who were too passive towards us, accepting anything the developers said. In my opinion, both parties should be very critical, proposing solutions, questioning the implementation, suggesting improvements, etc.” — Android Developer, 7 years of experience.

“The fact that the tester analyses the code is the main factor for me. In other teams, I had never seen that and it makes all the difference! — Android/iOS Developer, 7 years of experience.

“I believe that having a well informed tester, who seeks out more about the user story and its tasks, with a good understanding of code logic and the best practices of unit testing make the Enhanced DevBoxing as effective as it is” — Java/Android Developer, 20 years of Experience.

Satisfaction Level

The greatest benefit of practising the Enhanced DevBox is the fluidity with which it all occurs. Therefore, it’s important that the developers also feel that the process is valuable to their roles.

Inquired about how satisfied they were about adhering to this process, their answers were highly positive. They varied between a bigger feeling of partnership with their testers and a better understanding of their own code, as you can see on the comments below:

“I’m taking this practice with me to every other team I go to. There were a minimal amount of bugs registered since we implemented it, and small fixes can be done immediately. I feel like the quality of our deliveries has improved a lot after the Enhanced DevBoxing” — Android Developer, 8 years of experience.

“It’s a very good practice to try and explain the code to the tester, because we have to think about their context and be creative explaining it. So I feel very satisfied.” — iOS Developer, 4 years of experience.

“I feel very productive when I present my code to the test engineer. Together, we are faster at identifying problems, correcting them immediately. Besides, it adds a lot to the quality of the unit tests.” — Java/Android Developer, 20 years of experience.

What can be learnt from this?

Despite the simplicity of this technique, anyone who identifies themselves as testers has to detach themselves from their isolated bubble of testing and look at the bigger picture of software development. It’s necessary to adhere to the sense that software quality involves multiple techniques, perspectives, approaches and aspects.

As someone who tests applications, understand that your role is software engineering, not only testing. So get closer to the code, embrace it as part of your kingdom.

Practising the Enhanced DevBox also helps test engineers to face the source code with a smile, rather than fear, whilst also guiding the entire team to a quality culture.

If you want to learn about alternative ways to improve software quality, you could study the concept of Shift-Left Testing.

Conclusion

I hope that not only the Enhanced DevBoxing, but also the two techniques that compound it help to give ideas on how to improve the communication on your team. The goal is, always, to bring more high-quality software to life. If it works for you, don’t keep it to yourself, spread the word!

I’m available on LinkedIn, in case you want to talk more about the article (or software).

As always, I want to thank the privilege of being close to my brilliant brothers Wesley Oliveira and Tiago Pereira, for inspiring me to be a better version of myself everyday.

References

• Chinmay Karadkar, Dev Box — Where The Magic Happens: https://blog.gojek.io/dev-box-where-the-magic-happens/
• ShriKant Vashishtha, Dev Box Testing — Reduce Your Bug Life Cycle: http://www.agilebuddha.com/agile-testing/dev-box-testing/
• Rubber Duck Debugging — https://rubberduckdebugging.com/
• Wikipedia, Rubber Duck Debugging: https://en.wikipedia.org/wiki/Rubber_duck_debugging
• David B Hayes, Rubber Duck Debugging: The Psychology of How it Works: https://www.thoughtfulcode.com/rubber-duck-debugging-psychology/
• Wikipedia, Piaget’s theory of cognitive development: https://en.wikipedia.org/wiki/Piaget's_theory_of_cognitive_development
• Research Digest, Learning by teaching others is extremely effective — a new study tested a key reason why: https://digest.bps.org.uk/2018/05/04/learning-by-teaching-others-is-extremely-effective-a-new-study-tested-a-key-reason-why/