Uma análise empírica sobre testes em aplicações móveisFoto de smartphones do PCMagO futuro da tecnologia está nesses incríveis dispositivos que carregamos atualmente em mãos. Por acreditar fielmente nisso, dedico a maior parte da minha carreira ao ente…
Aos 16 anos, tomei a decisão de que aprenderia inglês sozinho.Pedi aos meus pais que guardassem o pouco dinheiro que tínhamos, pois os cursos eram (ainda são) extremamente caros e eu sou uma pessoa muito orgulhosa.A jornada não foi fácil, mas compartil…
Entendendo o que são e sua importância em nossas tomadas de decisãoVamos ali no hortifruti comprar umas frutas. Chegando la, nos deparamos com um problema. Como saber quais estão maduradas? Como saber que a fruta não está estragada por dentro?Você não …
“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
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.
In agile contexts, specially during maturation, it’s common to see the software development flow in this direction:
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 testers 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:
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.
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:
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!
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 dev 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:
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:
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.
When asked about what they valued on Enhanced DevBoxing, the answers pointed out to “increased code quality”, “greater interaction between Dev 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.
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 QA 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 QA, 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.
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 QA, 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 QA. 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.
Despite the simplicity of this technique, anyone who identifies themselves as a tester 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 testers 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.
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.
“Indivíduos e interações mais que processos e ferramentas” — Manifesto Ágil
Para você que trabalha com Scrum, por exemplo, pense um pouco sobre o seu contexto. É dinâmico, não é? Num piscar de olhos, as histórias já estão terminando e os ritos de conclusão de sprint se aproximando. Num ambiente tão volátil, qual a forma mais rápida de trocar informação?
O manifesto tem, como seu primeiro pilar, que interações humanas têm mais prioridade que as ferramentas usadas. Na prática, isso significa que um contexto ágil precisa de uma comunicação fluida e um forte trabalho em equipe para amadurecer de maneira apropriada.
“O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento
é através de conversa face a face.” — Manifesto Ágil
Este artigo é para você que está procurando meios de tornar a conversa mais efetiva entre quem testa e quem desenvolve. Ou para você que quer andar de mãos dadas com devs. Ou para você que quer antecipar seus testes e não tem ideia de como fazer isso. Ou até mesmo você que ainda tem medo de olhar o código fonte. I’ve got you!
Times ágeis em maturação tendem a buscar procedimentos mais sólidos quando, em alguns casos, tudo o que basta é uma comunicação ativa e com menos formalidades para adicionar fluidez ao time. No decorrer do artigo, apresentarei duas técnicas que, quando combinadas, tornam-se uma poderosa prática de comunicação e alinhamento.
Ao final deste artigo, trago uma prova de conceito com os resultados obtidos por exercitar essa prática em minha equipe.
Em contextos ágeis, principalmente em maturação, é muito comum ver o processo de desenvolvimento fluir desta forma:
Observe quantas etapas existem antes do código ser liberado para teste. A prática do DevBox visa encurtar o ciclo de feedback que é providenciado ao testar uma aplicação.
O conceito de DevBox Testing é debatido de várias perspectivas. A descrição comum a todas é ser um procedimento que ocorre antes da revisão de código, onde pessoas testadoras testam a aplicação no computador (box) de uma pessoa desenvolvedora, antecipando inconsistências que poderiam ser encontradas somente após a aplicação ser liberada.
Por ser um processo flexível, muitas equipes implementam suas próprias versões do DevBox. Aqui, trago alguns adicionais descritos por Chinmay Karadkar em seu artigo:
O importante desta prática é que, por ser executada na máquina de dev, o tempo entre identificação da falha e correção da mesma é encurtado, levando a códigos mais limpos.
O nome dessa técnica é originário de um conto do livro O Programador Pragmático, de Andrew Hunt e David Thomas, que fala sobre um desenvolvedor que andava com um patinho de borracha para todo canto.
Essa técnica de debug consiste em adquirir um patinho de borracha (ou, literalmente, qualquer outro objeto), apresentar o que você busca alcançar com o programa e explicar, de maneira detalhada, cada uma das linhas de código.
Existe uma psicologia por trás dessa prática. Em seu artigo, David B Hayes explica o porquê da técnica funcionar, apontando dois estágios:
A soma destes dois aspectos traz ao desenvolvedor um profundo entendimento sobre seu código, o que abre margem para detectar falhas em sua própria lógica.
Como as duas técnicas se combinam? Veremos isso agora!
Criei essa técnica combinando o DevBox Testing e o Debug com Pato de Borracha. Tentei chamar de DevBox com Pato de Borracha, mas não transmitiria a ideia que a prática tem.
Quando comecei a trabalhar em um time ágil, em 2020, eu tinha acabado de sair de um contexto onde desenvolvi uma convicção, a de que não precisava mexer com código, e percebi que precisava abandoná-la. Passei anos fugindo da programação só para cair de paraquedas em um ambiente que me deixaria cara a cara com ela.
Com alguns meses de trabalho, uma colega testadora — hoje Scrum Master — sugeriu que trouxéssemos o DevBox Testing para o nosso contexto, de forma que antecipássemos nossos testes e nos aproximássemos dos desenvolvedores.
Enxerguei no DevBox a oportunidade de me reaproximar do código e ainda assim agregar valor. Aproveitando nossa crescente maturação e forte interação dos membros da equipe, pude incorporar à nossa prática de DevBox Testing as premissas da Rubber Duck Debugging.
Nessa junção, você é o patinho de borracha.
Durante um DevBox Aprimorado, Testers e Dev se juntam para falar sobre a história. Antes de um pull-request ser aberto, a dupla tira uma ou duas horas para passar por todo o código. Aqui, quem desenvolve explica o código, a lógica por trás dele, o que quer alcançar e, finalmente, os testes unitários e de integração desenvolvidos (ou o porquê de não) para aquela história.
Para que a técnica funcione, é preciso satisfazer alguns critérios:
Ser o patinho de borracha tem suas vantagens. Aplicando essa prática em minhas equipes, observei alguns aspectos que guiaram o ritmo como as histórias são desenvolvidas:
Realizei uma pesquisa com as oito pessoas desenvolvedoras com quem trabalho para entender melhor como eles se sentem ao utilizar o DevBox Aprimorado e trazer a ótica deles sobre o processo.
As respostas foram obtidas através de um formulário onde perguntei o que acham do DevBox Aprimorado, como se sentem durante as sessões e o valor que eles enxergam na prática.
Quando solicitadas que indicassem o valor que enxergam nessa prática, as respostas apontavam para “aumento da qualidade de código”, “melhor interação entre Dev e Tester” e “antecipação dos problemas”. Abaixo, algumas das respostas:
“Possibilita a descoberta de certos detalhes antes da entrega. Há uma incrível melhoria na qualidade dos artefatos. Também reduziu para quase zero a taxa de retrabalho, além de uma grande melhoria no alinhamento de expectativas com os testadores. Dessa forma, conseguimos manter o testador informado do que está acontecendo desde o início. Não é só jogar o resultado e falar ‘testa aí’.” — Desenvolvedor Android, 8 anos de experiência.
“Tester e devs mais alinhados entre si, ambos com um ótimo conhecimento do que foi implementado. Duas cabeças pensam melhor que uma né? Os erros e as melhorias são encontrados de forma mais rápida.” — Desenvolvedora Android, 7 anos de experiência.
“Ao meu ver a estratégia do DevBox traz muita segurança ao Dev. Tanto em relação à qualidade da entrega quanto também se o escopo está aderente ao que foi definido na User Story. Conseguimos identificar alguns desvios e pequenos problemas podem ser corrigidos de imediato, melhorando a qualidade e acelerando muito o processo de entrega das User Stories.” — Desenvolvedor Java/Android, 20 anos de experiência.
O DevBox Aprimorado é um processo de alinhamento entre duas ou mais pessoas. Dessa forma, existem algumas características que são fundamentais para que a comunicação flua.
Perguntadas sobre o porquê de dar certo na equipe, as pessoas desenvolvedoras deram respostas bem variadas, mas todas apontavam para uma responsabilidade compartilhada e alta maturidade de ambas as partes. Em particular, apontaram um perfil de quem testa com um maior conhecimento técnico e responsabilidade pelo produto. Trouxe alguns depoimentos a respeito:
“Eu acho o processo vantajoso quando o tester tem ownership, é crítico e busca aprender com a explicação do dev. Eu já vivenciei situações em que o tester não tinha interesse em saber detalhes da implementação, só queria saber o funcional. Então, em um cenário desse, não vejo muito sentido em fazer o DevBox. Também já trabalhei com testers que eram passivos e que aceitavam qualquer coisa que o dev falasse. Eu acho que os dois papéis, dev e tester, têm que ser críticos, propor soluções, sugerir, questionar.” — Desenvolvedora Android, 7 anos de experiência.
“O fato do engenheiro de testes analisar o código é a principal diferença pra mim. Em outros times eu nunca vi isso e percebo que faz diferença!” — Desenvolvedor Android & iOS, 7 anos de experiência.
“Acredito que ter um tester preparado, que sempre está bem informado sobre o contexto da tarefa, com um bom conhecimento da linguagem de programação, e sobretudo sobre testes unitários faz com que os DevBox sejam muito produtivos.” — Desenvolvedor Java/Android, 20 anos de experiência.
O maior benefício de praticar um DevBox Aprimorado é a fluidez com que o processo discorre. Assim, é importante que os desenvolvedores também sintam que o processo é produtivo pra eles.
Perguntados sobre o nível de satisfação e como se sentem em relação à adesão ao processo, suas respostas foram extremamente positivas. Variaram entre um maior sentimento de parceria com testers e um melhor entendimento do próprio código, como pode ver nos comentários abaixo:
“Vou levar essa prática comigo para todos os times que eu participar. Foram pouquíssimos bugs abertos depois que essa prática foi implementada. Além de pequenos detalhes já serem corrigidos na hora. Qualidade elevadíssima com o DevBox” — Desenvolvedor Android, 8 anos de experiência.
“É uma boa prática tentar explicar o código para o tester, pois temos que pensar na didática da explicação. Então me sinto bastante satisfeito” — Desenvolvedor iOS, 4 anos de experiência.
“Tenho achado muito produtivo apresentar o código gerado para o testador. Identificamos problemas de forma mais rápida que podem ser corrigidos de imediato. Além de acrescentar muito em relação à qualidade dos testes unitários que estamos gerando.” — Desenvolvedor Java/Android, 20 anos de experiência.
Apesar da simplicidade de ser uma prática comunicativa, quem é engenheiro de testes precisa desprender-se das amarras do teste e olhar para o software como um todo. É necessário um forte sentimento cultural de que qualidade envolve múltiplos níveis, técnicas, perspectivas e abordagens.
Como alguém que testa aplicações, entenda e aceite que seu papel também é engenharia de software. Aproxime-se do código, abrace-o como parte do seu reino.
Exercitar o DevBox Aprimorado também serve como um meio para diminuir o medo do código, além de ser uma boa forma de seguir a trilha da cultura de qualidade.
Se quiser conhecer outros meios eficazes de melhorar a qualidade de seu software, estude o conceito de Shift-Left Testing — comece com este ótimo artigo de Tainara Reis a respeito do assunto.
Espero que não só o DevBox Aprimorado, mas as duas técnicas principais te tragam ideias de como melhorar a comunicação de sua equipe. O objetivo é, sempre, trazer aplicações com mais qualidade para o mercado. Se funcionar em sua equipe, não se acanhe, espalhe-a por aí.
Caso queira trocar uma ideia comigo, estou disponível no LinkedIn.
Como sempre, agradeço o privilégio de contar com meus brilhantes irmãos Wesley Oliveira e Tiago Pereira, por me inspirarem a ser uma versão melhor de mim todos os dias, e ter a esplêndida revisão de minha piveta Tarsila Santana.
Como estreitar os laços com desenvolvedores was originally published in Revista TSPI on Medium, where people are continuing the conversation by highlighting and responding to this story.
Recent Comments