Qualidade de software acabou ganhando destaque há poucos anos, antes não era escopo dos projetos, não entrava como um requisito aparente, mas, no final, a importância de se entregar algo que fizesse sentido para a necessidade de clientes e, claro, que funcionasse era um consenso.
Em 2009, Mike Cohn apresentou em seu livro “Succeeding with Agile” a definição de pirâmide de testes e desde então as indústrias têm usado esse conceito no dia a dia, em alguns momentos com nuances novas.
Algumas publicações dividem a pirâmide em três partes e outras de forma mais complexa, mas o que realmente importa é se ela está adequada à cultura da organização que está atuando como veremos ao longo deste texto.
Instituições financeiras
Atuar em instituições financeiras sempre foi um assunto polêmico para algumas pessoas, motivo de curiosidade para outras, mas parando para pensar, tirando questões vitais como quando atuei em áreas como metroviária e aérea, lidar com dinheiro de outras pessoas também é um tema muito delicado.
Você precisa garantir a qualidade de software do produto que está nas mãos de clientes, pois uma vez que perca a confiança no produto, com certeza não hesitará na busca por uma iniciativa/empresa concorrente.
Além disso, muitas instituições desta área estão no mercado há muitos anos, existindo muitos legados, servidores antigos e muita dificuldade de mover todo o sistema para a nuvem.
Na contramão de algumas opiniões, tenho observado que o que mais tem revolucionado a tecnologia no Brasil são, sim, muitas instituições financeiras trazendo inovações e tecnologias de ponta.
Time de alta performance
Em uma rápida busca na internet, encontrei a seguinte definição de time de alta performance:
“Uma equipe de alta performance é um time formado por profissionais especialistas, mas com habilidades que se complementam. Eles compartilham de uma única visão e têm os mesmos objetivos. Juntos, os profissionais de alta performance colaboram e se desafiam para produzir um trabalho muito acima do comum.”
Analisando essa definição, fico imaginando o que temos feito ao longo do tempo para atingir um bom resultado, entregando produtos de qualidade para clientes.
Nesta linha de pensamento, dois fragmentos desta frase chamam a minha atenção: “colaboram e se desafiam”. Isso é o mais importante que tenho observado: um time que realmente se conhece, sabe ver o que a outra pessoa precisa, sabe o dia que não está bem e ocupa o lugar desta pessoa em uma entrega crucial. Esse é o time de alta performance.
Em uma de minhas tarefas no DevOpsDays, desafiei a plateia a pensar se era capaz de brigar com colegas de trabalho e ainda assim no final do dia sair para um “happy hour”. Eis que uma turma sentada na primeira fila não se conteve e começou a rir, as pessoas disseram que brigavam o dia todo e que era ali que saíam os melhores resultados.
Veja bem, não estou dizendo que para entregar um produto de qualidade, eu preciso brigar com meu time para isso, mas ser capaz de entender quem é que está atuando comigo.
Pirâmide de testes e microsserviços
A pirâmide de testes é uma forma gráfica de demonstrar de forma simples os tipos de testes, seus níveis, velocidade de implementação e complexidade dos testes realizados.
A relação pode ser feita para nos ajudar a chegar ao custo de implementar e manter cada nível de teste, além de nos fornecer informações de qual nível devemos testar primeiro e o porquê.
Indo um pouco mais além, ela pode nos trazer um guia para saber o que precisamos testar e se estou repetindo algum fluxo de testes, refletir sobre a teoria apresentada é crucial, mas antes disso vamos tentar entender cada nível.
Interpretada de várias formas com níveis que podem variar de nomes, segue abaixo como utilizamos dentro da nossa estrutura:
- Testes unitários: testam a menor parte do código desenvolvido. Consiste em validar dados válidos e inválidos, sendo aplicado por pessoas desenvolvedoras ou analistas de teste. Uma unidade é a menor parte testável de um programa de computador.
- Testes de Componentes: limita o escopo em uma parte do sistema testado, devem ser realizados com seu componente e em um ambiente controlado, normalmente são utilizados mocks para as respostas das chamadas dos serviços.
- Testes Integrados: verificam como as unidades interagem entre si ou com alguns componentes externos. Podem validar a integração com módulos externos e conexões com banco de dados.
- Testes Manuais: são mais exploratórios com o intuito de imitar as ações da pessoa usuária usando os cenários que refletem o que as pessoas comuns provavelmente farão no aplicativo.
Inclusive, temos uma trilha do Zup Decodifica dedicada especialmente aos testes automatizados, onde também citamos a pirâmide de testes, vale a pena conferir!
Testes x Qualidade de software x Time
Enfim, o que tudo isso tem a ver com qualidade de software e onde conseguimos utilizar a teoria da pirâmide de testes nesse conceito todo?
Sempre defendi uma boa teoria, mas também sempre ouvi que a prática era bem diferente, mas analisando de um ponto de vista mais global, podemos adaptar a teoria à nossa cultura e foi isso que criamos dentro de nossos times na Zup.
Nesse momento, chegamos à palavra-chave que me traz de encontro a qualidade de software na equação:
cultura + time de alta performance = produto entregue com qualidade.
Na prática
Assim chegamos à montagem desse time de alta performance. Eu vinha de um projeto onde tínhamos uma pessoa QA por squad, ou seja uma pessoa profissional de qualidade para cada cinco ou seis devs.
O problema surgiu quando a QA saia de férias, as histórias ficavam paradas na coluna de “Testing”. Quando o time fazia horas extras para uma entrega crucial, a QA fazia ainda mais horas extras ainda, não conseguia concluir todas as atividades de testes e algum ponto era deixado para depois, fosse um teste automatizado ou a captura das evidências dos testes, que em um banco não é algo adequado.
Quando migrei de projeto resolvemos implementar algo diferente e queríamos muito que funcionasse sem pressionar ninguém a ficar sobrecarregado. Optamos por uma estrutura inicial de apenas uma pessoa profissional de qualidade para dois ou três squads, ilustrada abaixo, mas onde todo mundo seria guardião da qualidade de software e como isso funcionou?
No início fizemos algumas palestras sobre as metodologias de qualidade, mostramos alguns cenários que poderiam acontecer e montamos templates:
- Desenvolvimento;
- Automação de Testes;
- DOR e DOD;
- Acordos do time;
- Entre outros.
Todo mundo é responsável pelos testes automatizados, fazem revisão de código, podem abrir bugs (sim, nós gostamos deles como evidência e como histórico) e acima de tudo: se respeitam e se ajudam.
Conclusão
Nesse momento, você termina de ler esse artigo e pensa: não existe mundo ideal e aqui não irá funcionar. Bom … se não tentar, nunca vai saber, não acha?
Estávamos em um ambiente que poderia dar certo ou errado, e ninguém quis desistir, porque como disse anteriormente, nós gostamos (e muito) de receber desafios.
Quando estamos trabalhando com qualidade de software, esbarramos em alguns erros, tivemos que ajustar a comunicação, em outros momentos precisamos ter empatia pela pessoa que não acordou muito bem, adaptamos de novo, assumimos nossos erros e compartilhamos eles.
Por fim, entendemos que a alta performance se desenvolve também através da maturidade construída por sucessos e falhas, experimentos de táticas, técnicas, dinâmicas e processos que nos movem rumo à evolução.
Espero que tenha gostado do artigo! Continue acompanhando nossas dicas, pesquisas e mais na Central do Conteúdo.
Referências:
Especificando minha vida com exemplos – Mônica Cachoni
Succeeding with Agile: Software Development Using Scrum – Mike Cohn
Testing Strategies in a Microservice Architecture – ThoughtWorks
