Como estreitar os laços com desenvolvedores
Usando o DevBox Aprimorado para maximizar o trabalho em equipe entre Devs e Testers, melhorando a qualidade do software.
“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
Porquê continuar lendo
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.
DevBox Testing
Em contextos ágeis, principalmente em maturação, é muito comum ver o processo de desenvolvimento fluir desta forma:
- A história de usuário passa pelo refinamento de quem codifica;
- Refinada, a história é quebrada em pequenas tarefas durante a fase de planejamento;
- O código da história começa a ser escrito;
- Desenvolvedores realizam testes localmente, muitas vezes escrevendo testes unitários;
- Os pull-request são criados e revisados por devs durante a revisão de código;
- Uma vez que o pull-request seja aprovado e um artefato de desenvolvimento seja gerado, o software passa a ser testado.
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:
- Testers podem verificar os testes unitários e de integração que foram desenvolvidos durante a história;
- Questionar o software com o intuito de entender, verbalmente, como quem codificou se sente a respeito do que foi escrito. Por exemplo: “há um jeito melhor de escrever este mesmo código?” ou “o quão confiante você está nessa feature?”.
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.
Debug com Pato de Borracha
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:
- Quando fazemos algo que estamos acostumados — tipo codar — , tendemos a fazer isso no piloto automático. As ações simplesmente fluem, sem muito compromisso com pensar antes de agir. Quando paramos para explicar o que foi feito, somos forçados a parar e estruturar nosso raciocínio de maneira que consigamos expressá-lo corretamente. Neste ponto, revisamos a lógica do que fizemos;
- Complementar ao ponto anterior, o segundo estágio nos faz levar em consideração a diferença cognitiva entre nós e a pessoa a quem estamos explicando, disparando dois gatilhos psicológicos:
- O primeiro deles, explicado pela teoria do desenvolvimento cognitivo (Jean Piaget, 1919), acontece quando nos deparamos com a situação de explicar algo a alguém que possui um diferente entendimento acerca de um assunto. Em muitos casos, a discrepância de conhecimento é tão grande que precisamos simplificar e trazer analogias específicas para o contexto da pessoa a quem estamos explicando;
- O segundo efeito psicológico é o da aprendizagem através do ensino. Ao ensinarmos nossa lógica e o nosso código a outra pessoa, aprendemos ainda mais sobre o que fizemos.
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!
DevBox Aprimorado (Enhanced DevBoxing)
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:
- Deve acontecer antes de uma revisão de código formal (code review);
- Testadores precisam fazer leitura prévia do material utilizado para escrita de código, tipo a história de usuário, e participar ativamente dos planejamentos e refinamentos;
- Os testes iniciam somente quando o código for compreendido (e aceito) por ambas as partes. O nível de detalhamento deve ser estabelecido por ambos e, preferencialmente, reflexões e questionamentos devem ser levantados durante essa fase. Este aspecto é altamente suscetível a refatorações de código;
- Os testes unitários precisam ser revisados. Eles então passam a combinar o conhecimento de código da pessoa desenvolvedora com as técnicas de teste dominadas por testers, tornado-os mais eficientes;
- As falhas encontradas são consideradas como parte integral do processo de desenvolvimento, logo a sua correção é mais importante que a formalização num ticket. Esta fase se encerra quando as falhas são mapeadas e corrigidas;
- Em alguns casos, melhorias de código podem levar muito tempo para serem implementadas. Nessas ocasiões, as pessoas envolvidas devem conversar e definir um plano de ação. Novas tarefas de desenvolvimento e/ou débitos técnicos podem ser formalmente escritos e priorizados.
- O DevBox Aprimorado pode ser dado como concluído quando os pontos acima são satisfeitos ou ambas as partes atingem um acordo.
Benefícios do DevBox Aprimorado
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:
- Não só quem desenvolve aprende mais sobre o próprio código, a pessoa testadora entende mais profundamente a aplicação e as instruções que a compõe;
- Por entender o que está escrito, graças à paciente explicação de desenvolvedor, há uma desmistificação do código: ele deixa de ser algo de outro mundo e passa a ser um aspecto vital no dia-a-dia de um tester;
- O ciclo de feedback código-teste-falha é encurtado;
- As inconsistências encontradas podem ser corrigidas ali mesmo ou rapidamente mapeadas — afinal, o que traz valor aos usuários não é a descoberta de falhas, mas suas correções;
- Desenvolvedor e Testador aprendem a se comunicar de maneira mais amistosa e efetiva;
- Um laço de confiança é criado entre os membros da equipe;
- Dev aprende, pouco a pouco, a pensar como engenheiro de testes — e vice-versa. O que aprofunda as raízes da cultura de qualidade.
Prova de Conceito
O que Devs têm a dizer?
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.
Valor Percebido
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.
Como Engatar o Processo
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.
Satisfação
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.
O que aprender com isso?
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.
Conclusão
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.
Referências
- 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/
