Você já encontrou algum bug em um game, um problema ao mexer em um programa ou uma instabilidade ao salvar algum arquivo? Esse tipo de situação incomoda, principalmente por ser culpa de um programa com falhas.
Erros são passíveis de ocorrer ao construirmos um software, contudo, o teste serve justamente para revelar possíveis falhas/bugs e corrigi-las antes que o produto chegue ao consumidor final.
Visto como uma parcela do processo de qualidade de software, o teste tem um papel indispensável na influência da qualidade do que será produzido. Durante o processo de desenvolvimento, o que é testado muda conforme avanço das atividades – os requisitos, protótipo, modelo de dados lógico, modelo de dados físico, código-fonte, módulos funcionais e finalmente um sistema.
Mas, o que significa testar um software, afinal? É verificar, de maneira controlada, se o comportamento do processo está como especificado, ou seja, encontrar o máximo de erros dispondo de mínimo esforço, mostrando aos desenvolvedores se os resultados estão ou não de acordo com os padrões estabelecidos.
Para testar um software existem diversas abordagens, confira abaixo algumas delas:
Quadrantes do Teste Ágil ↩
O Quadrante é um guia para aplicação de alguma abordagem ou técnica de teste em um projeto desenvolvido em metodologia ágil.
A imagem abaixo mostra o Quadrante de Testes, que resume diferentes objetivos para compor uma estratégia de testes. Dos testes que suportam o time, àqueles que criticam o produto, separando-os por foco no negócio ou em tecnologia.
Testes que suportam o time ↩
São testes que ajudam os desenvolvedores (não somente esses testes), enquanto o produto é desenvolvido. São mais voltados para a qualidade e entendimento dos requisitos e arquitetura do que em testes como conhecemos de forma funcional. Estão presentes nos quadrantes 1 e 2.
O quadrante 1 representa a principal prática de desenvolvimento ágil, o TDD (Test Driven Development). Temos duas práticas aqui: teste de unidade, que valida uma parte da aplicação como objetos e/ou métodos e testes de componentes, que valida partes maiores da aplicação, como um grupo de classes que provêm o mesmo serviço. Eles medem a qualidade interna do produto.
O quadrante 2 continua guiando o desenvolvimento, mas de uma maneira mais alto-nível, com foco em testes que o cliente pode compreender, onde este define a qualidade externa que precisa.
É nesse momento que o cliente define exemplos que serão usadas para maior entendimento do funcionamento da aplicação.
Testes que criticam o produto ↩
Aqui acontecem os testes que avaliam a performance do produto, seja para achar erros, ou para propor melhorias, escrevendo, se necessário, mais critérios e exemplos. Os quadrantes 3 e 4 compreendem esse tipo de teste. Pode acontecer de, mesmo criando mecanismos para assegurar o atendimento da necessidade do cliente, isso não se efetivar.
Por isso, no quadrante 3, os testes são para criticar o produto e executá-lo como um usuário real. Essa tarefa, chamada de User Acceptance Testing (UAT), pode ser feita pelos testes ou pelo próprio cliente. O ponto central desse momento, além do UAT, é o teste exploratório. Assim, qualquer membro do time é capaz de aprender sobre a aplicação e executar mais testes simultaneamente, utilizando o feedback do último teste para a execução dos próximos, sempre observando o comportamento do sistema.
E no quadrante 4 estão os testes mais técnicos que criticam o produto quanto a performance, carga e segurança. As técnicas aplicadas vão desde os níveis mais baixos, como profiling de código, até a utilização de ferramentas que simulem vários usuários, simultaneamente.
A pirâmide de testes automatizados ↩
A pirâmide de testes automatizados nos mostra o quanto deve ser dedicado a cada nível de teste em uma equipe de desenvolvimento profissional, para que a equipe responsável encontre o menor número de bugs possível.
Testes de Unidades ↩
Na parte inferior da pirâmide, estão os testes de unidades. Geralmente são escritos por programadores, na linguagem de programação do sistema. Eles são redigidos antes de escreverem o código de produção para especificar aquilo que está sendo escrito. São executados como uma parte da Integração Contínua, garantindo que as intenções dos programadores sejam atingidas.
Testes de Componentes ↩
Servem para garantir que o componente esteja de acordo com as regras de negócio vigentes.
Envolve apenas um componente do sistema, qualquer outro componente é dissociado do teste. Ele passa dados de entrada para o componente e reúne dados de saída, atestando que a saída combina com a entrada.
Testes de Integração ↩
Os testes de integração garantem que as interfaces de integração e troca de mensagens entre componentes do sistema estejam funcionando conforme o esperado. Aspectos não funcionais também podem ser avaliados, tais como desempenho, taxa de transferência (vazão), segurança, etc.
Testes de Sistema ↩
É verificado se o sistema foi bem construído e se suas partes estão operando de forma integrada para realização de atividades do processo de negócio, de ponta a ponta.
Testes Manuais Exploratórios ↩
Esses testes não são automatizados e escritos. O objetivo deles é de explorar o sistema em busca de comportamentos inesperados e confirmar os esperados. Neste momento, precisamos de criatividade para investigar e explorar o sistema. Elaborar um plano escrito para este tipo de teste, acabaria com o seu propósito e a sua meta não é a cobertura.
Conclusão ↩
Agora que você já conhece algumas abordagens de testes no desenvolvimento de software, fica mais fácil entender a importância dessa área de conhecimento e enxergar o valor que esses testes podem trazer para o seu projeto.
A pirâmide de testes automatizados é um modo de pensar sobre diferentes abordagens de testes para se criar uma estratégia equilibrada para automação dessas operações. Seu ponto essencial é que, para obter feedback mais rápido, você deveria focar em automatizar mais em testes de baixo nível (Testes de Unidade) do que testes de alto nível (Testes de Sistema/GUI e Exploratórios). Testes de alto nível são mais lentos e mais caros para implementar e executar, além de serem mais vulneráveis às mudanças no sistema. Por isso, utilize a pirâmide de automação de testes como referência para definir a estratégia de automação de testes que, dessa forma, melhor responda aos riscos relacionados à qualidade do produto desenvolvido pelo seu projeto!
Na Squadra fazemos de tudo para que nossos projetos atendam a todas as necessidades dos clientes e temos especialistas em testes para acompanhar o desenvolvimento de cada um de nossos projetos.
