Testes de Software em Smartphones

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…

Como me tornei auto-didata em inglês

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…

De mãos dadas com as heurísticas

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 …

How to strengthen the bond with the developers

A technique to improve teamwork between Devs and Testers, enhancing software quality in the process.

Group of African people working together in front of a laptop.
Designed by senivpetro @ Freepik

“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

Three people testing a software
Designed by pch.vector @ Freepik

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 subjected to deeper testing.

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:

  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

A yellow rubberduck
Designed by freepik @ Freepik

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

Two people talking about code in front of the computer
Designed by stories @ Freepik

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:

  • 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 Dev and tester”, and “anticipated problems”. Below, some samples on their responses:

Pizza graph displaying the replies to “Do you see value in practising the Enhanced DevBox?”, where 100% of the answers were “yes”.
“Do you see value in practising the Enhanced DevBox?”. 100% of the answers are “yes”.

“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 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.

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 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.

What can be learnt from this?

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.

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

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.

Grupo de pessoas Pretas trabalhando juntas em frente a um laptop.
Feito por senivpetro @ Freepik

“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

Três pessoas testando um software
Feito por pch.vector @ Freepik

Em contextos ágeis, principalmente em maturação, é muito comum ver o processo de desenvolvimento fluir desta forma:

  1. A história de usuário passa pelo refinamento de quem codifica;
  2. Refinada, a história é quebrada em pequenas tarefas durante a fase de planejamento;
  3. O código da história começa a ser escrito;
  4. Desenvolvedores realizam testes localmente, muitas vezes escrevendo testes unitários;
  5. Os pull-request são criados e revisados por devs durante a revisão de código;
  6. 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:

  1. Testers podem verificar os testes unitários e de integração que foram desenvolvidos durante a história;
  2. 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

Um patinho de borracha amarelo
Feito por freepik @ Freepik

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:

  1. 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;
  2. 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)

Duas pessoas falando sobre código na frente de um computador
Feito por stories @ Freepik

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 precisa 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:

Gráfico em formato de pizza com o resultado da pesquisa para a pergunta “Você vê valor na prática do DevBox Aprimorado?”, onde 100% das respostas foram “sim”.
Resultado da pesquisa

“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


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.