Como são os testes na Vórtx

Porque testar?

O teste de software é muito importante na garantia de controle da qualidade do sistema. Ele deve garantir que o sistema atenda a todos os requisitos conforme o aquilo que cliente solicitou. No entanto, o teste de software abrange uma área muito maior do que controle da qualidade do sistema.

Os testes são ferramentas que as empresas utilizam para minimizar custos financeiros e evitar que a reputação empresarial diminua. Quando um teste de qualidade é executado no sistema, é possível evitar que um problema cause muito prejuízo no futuro.

Um defeito que é descoberto em fase de produção, pode ter o custo para corrigi-lo de até 100 vezes mais sobre um defeito descoberto na etapa de teste. Uma empresa que produz softwares de baixa qualidade não é bem-vista no mercado. Sendo assim, negócios que viriam a ser fechados podem ser perdidos.
A importância dos testes de software no controle de qualidade

Resumidamente, testes são importantes principalmente para dar segurança à equipe de engenharia - para que eles possam realizar uma alteração no software com segurança, sem medo de criar bugs, principalmente os críticos, pois se "algo quebrar" o teste também falhará acusando o erro ocorrido. É muito ruim trabalhar em um sistema no estilo "conserta uma coisa e quebra duas", por isso reforçamos a necessidade de criação de testes, principalmente aqueles que envolvem regra de negócio.

Tipos de testes

Existem inúmeros tipos de testes que podemos usufruir para tornar a nossa plataforma cada vez mais resiliente. Veja abaixo uma figura que ilustra tipos de testes que temos em todo o mercado:

Porém, é óbvio que não conseguimos aderir todos os tipos de testes que a figura ilustra. Isso nos traria uma complexidade absurda, fora a grande quantidade de horas que deveria ser aplicada para construirmos todos estes tipos de testes.

Por isso, acreditamos em um conceito de losango ou honeycomb, que nos mostra que existem testes que são mais fáceis de serem criados e entregam mais (ou pelo menos igual) valor para o produto. Este conceito é baseado na pirâmide de teste:

A pirâmide de teste original de Mike Cohn consiste em três camadas que sua suíte de testes deve consistir (de baixo para cima):

• Testes Unitários
• Testes de Serviço
• Testes de Interface do Usuário

Infelizmente, o conceito da pirâmide de teste não é unanimidade. Alguns argumentam que a nomenclatura ou alguns aspectos conceituais da pirâmide de testes de Mike Cohn não são ideais. Do ponto de vista moderno, a pirâmide de testes parece excessivamente simplista e, portanto, pode ser enganosa.

Ainda assim, devido à sua simplicidade, a essência da pirâmide de testes serve como uma boa regra prática quando se trata de estabelecer sua própria suíte de testes. Sua melhor aposta é lembrar duas coisas da pirâmide de teste original de Cohn:

• Escrever testes com granularidade diferente.
• Quanto mais alto nível você obtiver, menos testes você deve ter.

Atenha-se à forma da pirâmide para criar uma suíte de testes saudável, rápida e de fácil manutenção:

• Escreva vários testes de unidade/integração pequenos e rápidos.
• Escreva alguns testes mais grosseiros e muito poucos testes de alto nível que testem sua aplicação de ponta a ponta.

Tome cuidado para não fazer uma complicação com os casos de testes e tornar a suíte de teste muito pesada e que levará muito tempo para ser executada.

Falamos ainda mais detalhadamente sobre a pirâmide aqui: A famigerada pirâmide de testes e a abordagem honeycomb

O que nós fazemos aqui na Vórtx

Dado todo esse cenário, não acreditamos friamente na pirâmide, e sim nós a visualizamos mais como um losango, criando bastantes testes nos use cases e garantindo que todas as regras de negócio são de fato testadas.

Se o software trabalha com use cases e os testa, então o restante da aplicação estará implicitamente testada.

Como saber se os testes estão dentro do padrão?

Para auxiliar a equipe de teste existem alguns pilares e quais fatores que pertencem a um software de qualidade. Esses pilares são:

• funcionalidade
• confiabilidade
• usabilidade
• eficiência
• manutenção
• portabilidade

Executar testes que garantam que os seis pilares sejam atendidos automaticamente garantirá que o sistema atenda os requisitos padrões para ser um software de qualidade.

Quality Assurance (QA)

O conceito de Quality Assurance (QA), que pode ser traduzido como “Garantia de Qualidade”, faz referência a um profissional ou a uma equipe cuja função é garantir a qualidade no desenvolvimento de um produto ou serviço. Ter a figura do QA é algo que é bastante discutido no mercado, inclusive aqui na Vórtx. Aqui temos squads com QAs e outras sem a figura exclusiva de uma pessoa de qualidade, e sobre o porquê disso, falaremos em um próximo artigo.

Por hora, apenas fique com a informação que temos este modelo híbrido aqui dentro, pois acreditamos que a qualidade é responsabilidade de todos e não apenas de uma só pessoa. Falando em responsabilidades, fiz uma pequena lista sobre indicadores de que estamos garantindo a qualidade:

Responsabilidades, como garanto a qualidade?

• Ser responsável por levar a mensagem de teste e qualidade para todos os integrantes do time, tendo autonomia de avaliar se a task está adequada ou não para ir para produção.
• Garantir que o produto seja entregue com a qualidade esperada (Definition of Done). Ou seja, a task deve estar contemplando todos os requisitos solicitados.
• Passar conhecimento para o time de desenvolvimento de como testar, sendo que este conhecimento pode ser gerado em qualquer área (Produto, Qualidade ou Negócio). É sabido que teste se aplica a todas as camadas do desenvolvimento e por isso é importante que todos tenham esse conhecimento para que o produto seja desenvolvido com um alto padrão de qualidade.
• Buscar atender à expectativa dos clientes. O nosso cliente espera que o produto atinja algumas características de qualidade que faz com que a experiência e o uso do software/produto seja realmente algo satisfatório.
• Buscar se antecipar a comportamentos inesperados na aplicação.
• Disseminar a metodologia de BDD entre a equipe. Para o seu bom funcionamento é importante que seja construído em equipe por isso, existe a técnica dos três amigos (https://www.agilealliance.org/glossary/three-amigos/).
• Possuir conhecimento das regras de negócio.

Ainda que este artigo não cubra as ferramentas que utilizamos (falaremos delas um dia), esta leitura tráz quais são os pilares do que acreditamos como qualidade e aonde investimos a maior parte do esforço para garanti-la.