ROI, eu também não te amo

Benjamin Butel compartilha sua perspectiva sobre o famoso ROI da automação no contexto da qualidade do software nesta entrevista da QE Unit.

Benjamin atua como um treinador ágil e de teste com uma abordagem e organização orientada para o produto. Sua prioridade é a criação de valor suportada por abordagens iterativas.

Esta entrevista é dedicada ao ROI (Return On Investment) da automação, uma questão que pode irritar sem contexto, como uma garrafa atirada ao mar. No entanto, levanta reais questões.

Esse compartilhamento nos leva a dar um passo para trás de uma perspectiva de negócios, a empresa e seus clientes voltando a focar nas questões e processos certos a seguir.

Junte-se à QE Unit para acessar conteúdo exclusivo e regular da comunidade.

Sobre Benjamin Butel

Como coach de teste, gosto de desenvolver estratégias de teste inteligentes para problemas de projeto de software. Também adoro liderar uma equipe de teste e ajudá-los a melhorar suas habilidades de teste e dar-lhes confiança em sua capacidade de sempre fazer o melhor de uma forma simples e divertida.

Também estou convencido de que a comunicação é a melhor chave para a melhoria, o sucesso pessoal e profissional. Organizado os encontros do Ministério de Testes de Rennes, membro do MForTest, e a Paris Test Conf.

Antoine: Pode começar por se apresentar?

Sou Test Coach na Klaxoon, empresa francesa que produz software voltado para colaboração empresarial. Uma das minhas paixões é o teste de software, além da minha função, gosto de participar do Ministério de Teste de Rennes. Desde o confinamento, organizamos eventos online que abrangem toda a França, o que nos tem permitido fazer bons intercâmbios.

Também participo na organização da próxima edição da Paris Test Conf. Nos últimos anos, também compartilhei minha perspectiva sobre os testes por meio de artigos na Taberna do Testador.

Antoine: Um assunto tende particularmente a incomodá-lo no campo de teste e da qualidade de software. Pode nos contar um pouco mais?

Já há algum tempo, tenho visto regularmente mensagens passando sobre o cálculo do ROI da automação. O que me incomoda a princípio é a falta de contexto que dificulta a articulação de uma resposta possível. Acima de tudo, isso me coloca a verdadeira questão que não se coloca: “Por quê?”.

Por que desejar calcular um ROI? Qual é o objetivo por trás desse cálculo de ROI? A questão extrai o porquê da automação. Isso leva a uma reflexão que não vejo emergir, continuamos focados nessa correlação entre automação e ganho financeiro. Pessoalmente, acho isso desnecessário, principalmente em um contexto ágil.

Antoine: Quais conceitos considera relevantes em relação à agilidade? É a noção de valor, diferente daquela de qualidade ou de teste?

Essa é a noção de valor. Se tentarmos responder ao porquê da automação com um “Ser mais rápido na minha fase de aceitação”, é um cartão vermelho para mim. Isso não faz sentido. A verdadeira questão é “Por que quer ir mais rápido na fase de aceitação?”. Se estamos caminhando para uma necessidade de aceleração, já temos um primeiro elemento de resposta. Resta a identificar o que gostaríamos de oferecer mais rapidamente, quais recursos, e por quê. Sem fazer o exercício até o fim, iremos iterar até a base inicial do trabalho realizado, seu significado, seu valor. O ponto de partida é o valor que queremos agregar e para quem.

“O ponto de partida é o valor que deseja trazer e para quem.”
Benjamin Butel

Se agora começarmos nosso pensamento a partir da criação de valor, podemos avaliar como a automação pode nos ajudar. A relevância de um ROI é questionável para este exercício. Como isso nos ajudará a medir o valor? Calcular o melhor custo é realmente a equação a ser perguntada? É aqui que o sapato aperta para mim, nós levamos o assunto para trás, começando com o ROI.

Antoine: Uma abordagem de ROI nos posiciona no final da cadeia para calcular o tempo economizado em testes manuais versus automatizados, por exemplo. A automação está ao serviço da criação de valor, o que deve ser medido?

A automação para mim é uma ferramenta, como o teste. Vou ainda mais longe, a produção de software é apenas uma ferramenta. Com exceção de algumas empresas especializadas em publicação de software cuja ferramenta é o trabalho deles, o trabalho não é a ferramenta que desenvolvemos. Se pegarmos nas ferramentas que apoiam a profissão bancária, o trabalho a fazer é o de banqueiro, apoiado em ferramentas que permitem acelerar e melhorar esta profissão. Nessa perspectiva, a automação é apenas uma ferramenta entre outras para ajudar a criar valor.

Calcular um ROI de automação de 25 entre 50 casos de teste manual nos faria pensar que economizamos pelo menos metade do nosso tempo. O prisma está errado, sem falar no tempo supostamente “economizado” que gastamos mantendo os testes. Questiono-me muito sobre a relevância desse ROI, mostrando uma falta de perspectiva das organizações. Acho difícil entender por quê.

“Se respondermos o “porquê” e o “para quem” corretamente, o ROI não é o assunto.”
Benjamin Butel

É claro que a automação pode levar um fator de confiança no limite. Mas se respondermos bem ao “porquê” e ao “para quem”, não é um ROI que irá apoiar a nossa tomada de decisões e prioridades a serem abordadas. Em qualquer caso, um ROI por si só não tornará possível impulsionar a produção de valor. Em vez disso, os indicadores devem ser definidos para medir o valor agregado após as mudanças e iterações que realizamos.

Devemos, de fato, responder a duas perguntas para impulsionar o valor criado “Como medir a produção de valor?” e “Como medimos se estamos produzindo melhor?”. O ROI ou a automação não me parecem as respostas sistemáticas nem certas para essas perguntas. Pode tentar responder rapidamente ao problema errado sem a perspectiva certa. Um exemplo é querer ir mais rápido em nossas iterações, compensando montes de problemas acontecendo em upstream de organizações em ruins. Ganhamos talvez algumas horas em testes, em detrimento dos dias perdidos no desenho e no alinhamento inicial.

Antoine: A nossa prioridade é, portanto, a produção de valor por meio de um sistema organizacional eficiente, iterando e melhorando. Tem alguma pista para medir este valor?

As ferramentas de satisfação do cliente são um bom ponto de partida para medir a qualidade de um produto. Também podemos usar a taxa de conversão, a satisfação de vários usuários do produto; voltamos à profissão apoiados nas ferramentas. A automação pode ser um dos elementos para acelerar, facilitar ou melhor concretizar esta profissão. Também nos esquecemos facilmente dos fatores humanos de conforto e uso, que podem, pelo contrário, exigir mais lentidão.

Os indicadores são, portanto, muito contextuais, são dependentes de cada contexto, empresa e negócio.

Podemos então trabalhar no alinhamento do produto, do pacote de software e até mesmo do sistema de informação a ser construído em face desses indicadores de valor. É aqui que entram em jogo os indicadores que medem a adequação do sistema organizacional para a criação de valor. É apenas começando pelo propósito do produto que podemos encontrar as organizações, ferramentas e processos certos.

“É apenas começando pelo propósito do produto que podemos encontrar as organizações, ferramentas e processos certos.”
Benjamin Butel

Obviamente, no início, não há milagre, partimos de um determinado estado, com suas vantagens e desvantagens. É a partir deste ponto de partida que devemos medir a melhoria progressiva da criação de valor por iterações. Calcular o ROI de testes automatizados não trará nenhum interesse em identificar essa melhor produção.

Não é necessário ter um ROI para iniciar um processo de automação. Podemos identificar um escopo mínimo de automação, explorar relevância e criação de valor com a equipe. Desde as primeiras iterações, podemos medir a adição de valor. Podemos perceber que ganhamos ou perdemos tempo, mesmo que o foco deva permanecer no valor, específico para cada contexto.

“Não é necessário ter um ROI para iniciar um processo de automação.”
Benjamin Butel

Se nos colocarmos em um contexto ágil, um dos grandes pontos fortes da automação é a confiança que a equipe traz durante os ciclos de desenvolvimento. Um cálculo do ROI comparando o teste manual com o teste automático não faz sentido neste contexto, a prioridade sendo construir o produto permitindo a criação de valor. A equipe deve responder coletivamente à pergunta do “Como”.

Como organizar? Como integrar qualidade? Os testes exploratórios automáticos serão, em última análise, apenas ferramentas para injetar qualidade nessa produção. Como saída, entregamos um produto com seu ecossistema de soluções em que podemos medir seu valor e áreas de melhoria. Podemos medir o sentimento, o factual, por exemplo, a taxa de retrocesso, anomalias. Mas eu realmente tenho dificuldade em entender o ponto de calcular um ROI antes mesmo de automatizar qualquer coisa, e para quê.

A minha mensagem é de tentar. Se a equipe achar que uma prática pode melhorar sua produção de valor, ela pode decidir testar sua hipótese em um pequeno perímetro no próximo sprint. Se realmente for criado valor, a equipe pode continuar ou, ao contrário, sem valor, parar imediatamente para avaliar outras oportunidades.

Antoine: Então, uma abordagem de automação com foco em testes se afasta do assunto real da produção de valor?

Tenho a sensação de que o ROI é muito semelhante à noção de ganho financeiro. Quando lidei com este indicador, era para atingir objetivos financeiros ou contratuais totalmente desproporcionais.

Um primeiro caso foi querer medir qual ganho entre a automação de 80% ou 100% dos testes existentes. Outra é a cobertura padrão de 60% do teste, sem nem mesmo uma noção do escopo coberto. O que significa 60%? Qual é a ligação ao valor? O que me interessa é a produção de valor, a rapidez na obtenção do feedback e a confiança da equipa.

Antoine: Isso levanta uma questão cultural da percepção do valor da qualidade pelas organizações. Acreditamos que a qualidade nos economiza dinheiro apenas pela automação, longe da criação de valor. Tem o mesmo sentimento?

Sim, embora tenha a sensação de que é uma visão de qualidade bastante francesa. Olhando para os meus homólogos anglo-saxões ou do outro lado do Atlântico, tenho a sensação de que o prisma não é o mesmo.

Basta olhar para pessoas como John Ferguson Smart, Lisa Crispin ou Janet Grégory. Quando os seguimos, encontramos os mesmos temas propostos: valor, produto e interações humanas. As ferramentas são então mecanismos que podem certamente acelerar as coisas e tornar a vida mais fácil, mas seu primeiro prisma é o do valor. Nenhum desses elementos aparece em um ROI de automação e não nos permite tirar alguns tipos de conclusões.

Antoine: O que podemos fornecer nas diretrizes quando vemos essas solicitações de ROI aparecerem?

Para mim, tem que se perguntar as perguntas certas. O surgimento desta questão não me choca, talvez em consequência de um reflexo managerial ou consequências de um ciclo em V. O que me interessa é voltar para o “Why”. Encontramos esses elementos no livro “Agile Testing Condensed” de Lisa e Janet: o porquê, o quem, depois o como. O cálculo do ROI da automação está incluído no Como, na terceira posição. Portanto, eu começaria com o “Por quê” e depois com o “Para quem”, que levará a um bom raciocínio.

“Começar com o “Por que” e o “Para quem” levará a um bom raciocínio.”
Benjamin Butel

Se quisermos ganhar dinheiro e reduzir a equipe de testes, sinto muito por si, mas é melhor demitir-se. Assim que tiver algo programático, a automação ainda estará sujeita à manutenção, não importa o que aconteça. O software vive e as ferramentas devem acompanhar seu desenvolvimento e suas mudanças. A agilidade também nos leva a ser mais pragmáticos, usando a ferramenta certa no momento certo para agregar valor. Portanto, tenho dificuldade em prever qualquer ganho de valor por meio da automação.

Minha experiência muitas vezes me mostrou que raramente vamos além da etapa 1 ou 2 em comparação com as contribuições que tínhamos imaginado.

Antoine: Podemos rapidamente fazer um filme sobre uma arquitetura de automação completa, quando uma abordagem just-enough era suficiente para a criação de valor.

Há feedback regular da Axa sobre sua infraestrutura de teste. Seria interessante ver o posicionamento que conseguiram fazer com esse investimento. Não vou falar por eles, mas imagino que eles tenham feito isso passo a passo, medindo o valor agregado pelo sistema geral aos negócios da Axa, em vez de medir o ganho de sua infraestrutura de teste. Convido a consultar os últimos artigos que eles têm publicados tanto para os resultados obtidos quanto para a estrutura implementada.

Se nos projetarmos em organizações políticas mais complexas, será complicado mudar mentalidades neste contexto. A resposta não deveria ser para mim não fazer o ROI; tem que dar um passo para trás do “Por que” no contexto, para entendê-lo.

Talvez no questionamento encontremos um ponto que não nos fará ir para a automação. Uma ideia mais benéfica pode surgir para responder melhor ao problema identificado. Muitas vezes é isso que acontece nas expressões de necessidade, chegamos diretamente com uma solução. O mesmo processo deve ser aplicado para subir na cadeia para avaliar outras pistas.

Antoine: Muitas vezes vejo um foco de perfis de engenheiros em assuntos puramente técnicos e tecnológicos. O que acaba de partilhar é, de facto, a materialização da necessidade de colaboração, empatia, escuta no cerne da criação de valor?

Isso é o que é desenhado por diferentes rituais, como de Impact Mapping ou de Example Mapping, onde o foco é, obviamente, a colaboração. Pode haver algumas ferramentas colaborativas para ajudar em um contexto remoto. Isso me lembra um tweet de Lisa nos dizendo para pegar um bloco de notas, levantar e compartilhar o que imaginamos em um quadro.

Estou profundamente convencido de que as trocas ativam mecanismos de colaboração muito mais fortes do que e-mails ou tickets. Estamos no manifesto ágil com “interações mais do que ferramentas”; colocamos as ferramentas e processos de apoio a esses mecanismos, sem negligenciá-los ou ser a primeira preocupação.

Quando começamos a atingir um bom nível de colaboração, podemos passar para o coletivo, passando um nível.

O coletivo derruba montanhas, não há nada mais forte para mim. Podemos ser colaborativos sem ser coletivos. Como uma equipa de futebol com os melhores jogadores atuando individualmente, eles não irão longe. Em software, podemos muito bem ter sucesso em 4 ou 5 sprints, e perder completamente o sprint 6 por cansaço ou falta de coletivo. Não é o ROI ou a automação que nos protegerá, são os sujeitos humanos, muito mais difíceis de medir e manter coesos.

Antoine: Além do que trocamos, tem algum conteúdo, citações ou pessoas que o inspiram ?

Internacionalmente, os livros de Lisa Crispin e Janet Grégory são para mim referências “Agile Testing” ou “Agile Testing Condensed”. Contém conteúdo e referências a mapeamento visual e pirâmides de automação. Há também algumas coisas interessantes de Alan Page sobre o Modern Testing, em particular do gerenciamento dos dados.

O livro “Le Chaînon Manquant” de Valentin Guerlesquin e Henri Bigot relata a transformação de uma equipe em um grande grupo. Posso dizer algo errado, mas não acho que exista a palavra ROI nenhuma vez neste livro! Não é disso que eu me lembrava de qualquer maneira. A história é a de uma equipe que busca iniciar a automação de testes e como isso acontece por meio de uma abordagem transversal. Eu realmente recomendo sem querer “anunciar” aos meus colegas; ele lê muito bem, de forma romântica, e pode ajudar as pessoas com dúvidas sobre automação.

Pequeno teaser, aproveito a oportunidade para compartilhar que o livro “Agile Testing Condensed”, de Lisa e Janet , em breve estará disponível em francês! Estamos finalizando a revisão com minha colega Emna Ayadi para um lançamento iminente.