Teste de Software Moderno: Estratégias de Testes

Entenda quais estratégias de testes de software você pode utilizar para aumentar drasticamente a qualidade de suas aplicações e economizar até 90% na homologação com testes de aceitação automatizados.

Dio Ianakiara
Getty/IO Blog - The Blockchain Company

--

Nota: Em nosso último artigo da série Teste de Software Moderno falamos sobre Os fundamentos do teste de software, as diferenças entre teste legado moderno e a diferença entre qualidade e testes. Como continuação desta série nosso próximo passo é falar sobre as estratégias de testes de software. Preparado? Então vamos lá!

Como você já deve saber, toda aplicação moderna possui diversas camadas e estas camadas são subdivididas em outras camadas e partes ainda menores. Para escolher a melhor estratégia de teste para nossas aplicações, precisamos entender como um sistema funciona internamente e como estão divididas estas camadas (layers).

Imagine que a seguinte aplicação simples possui apenas três camadas:

Cada uma das camada acima possui suas próprias subdivisões que podem ser testados em conjunto ou individualmente e é aqui que começa nossa jornada. Meu objetivo com este artigo é apresentar 3 estratégias que podem ser implementadas em conjunto para elevar a qualidade de suas aplicações e reduzir drasticamente os custos com testes de software.

A seguir são apresentadas as 3 principais estratégias que são utilizadas no teste de software moderno.

Testes Unitários (Unit Testing)

Observando a imagem acima podemos notar pequenos blocos em azul escuro dentro da camada chamada API, cada bloco representa uma função ou componente que deve possuir um único objetivo. Quando testamos estes pequenos blocos de forma isolada utilizamos uma técnica chama unit testing (testes unitários).

O objetivo de um teste unitário é validar a menor parte de um sistema de forma isolada, para garantir que funcione exatamente como é esperado

Os testes de unitários são adequados principalmente para a execução de testes em baixo nível. Por exemplo, imagine uma função que valida CPF’s e que possua 5 cenários de testes, para cada um criamos cinco variações de entradas, logo, se um usuário precisasse testar cada um desses cenários isso seria extremamente lento.

Se alguém alterou o componente ou função e acidentalmente introduziu algum defeito, a execução de testes unitários deve alerta-lo — em seu ambiente de integração contínua.

Isso nos mostra, que se este problema fosse identificado através da interface de usuário ele só iria ser encontrado muito mais tarde em seu processo de qualidade ou até no ambiente de produção por um usuário no pior caso.

Exemplo de teste unitário em Javascript — https://mochajs.org/

Os testes de unitários funcionam sempre em colaboração com outros tipos de testes e não devem ser sua única estratégia de qualidade.

Testes de Integração (Integration Testing)

Os testes de integração validam se comunicação entre dois ou mais componentes está funcionando corretamente. Por exemplo, se você possui alguma API e gostaria de testar algum endpoint com múltiplas entradas e respostas diferentes, você precisa fazer um teste de integração.

Os testes de integração são mais frágeis do que os testes unitários, já que os componentes não são testados isoladamente. Por exemplo, se estamos pensando na comunicação entre uma API e um banco de dados, os dados armazenados precisam ser rigidamente controlados para garantir o mesmo comportamento em cada execução. Por exemplo, se alguma instrução DDL ocorrer em seu banco de dados no mesmo fluxo testado, os testes de integração precisam ser corrigidos.

Exemplo de teste integração de uma API com Supertest:

http://engineering.invisionapp.com/post/express-integration-testing-supertest/
http://engineering.invisionapp.com/post/express-integration-testing-supertest/

O exemplo acima demonstra como é simples criar testes de integração para API’s com Node.js.

Este mesmo tipo de teste pode ser criado em minutos, mesmo para outras linguagens utilizando o poder das libs Superagent e Mocha.

Embora os testes de integração sejam mais sensíveis as alterações dos componentes e dados que integram algum fluxo de inteligência, eles são extremamente eficientes na detecção de erros de negócio. Alterações em um fluxo de execução, são rapidamente identificadas nos erros que são apresentados no sistema de integração contínua.

Testes de Aceitação (Acceptance Testing)

Testes de aceitação acontecem na camada da interface de usuário e normalmente envolvem todas as camadas da aplicação testada para validar um cenário de negócio.

Segundo o dicionário de testes da International Software Testing Qualifications Board (ISTQB) testes de aceitação são testes formais com relação às necessidades dos usuários, requisitos e processos de negócios conduzidos para determinar se um sistema satisfaz ou não os critérios de aceitação.

Alguns exemplos de cenários em testes de aceitação:

  • Login e Logout
  • Acessar sua caixa de mensagens
  • Envio de mensagem em um chat
  • Transferência de dinheiro de uma conta para outra (TED ou DOC)

Os testes de aceitação são muito mais sensíveis a alterações no sistema do que qualquer outro tipo de teste, justamente, por testar o fluxo de informações entre várias camadas de uma aplicação distribuída. Eles também podem ser utilizados para identificar se uma nova versão do sistema apresenta regressões em relação à versão anterior.

Segundo nossa querida Wikipedia, O teste de regressão é uma técnica do teste de software que consiste no teste de versões mais recentes do software, para garantir que não surgiram novos defeitos em componentes já analisados. Se, ao juntar um novo componente ou as suas alterações com os componentes restantes do sistema e surgirem novos defeitos em componentes inalterados, então considera-se que o sistema regrediu.

Embora isso pareça muito óbvio, os testes de aceitação precisam de um trabalho constante para que fiquem sempre atualizados.

Testes de aceitação podem ser planejados e executados de várias maneiras, há casos de empresas que possuem equipes de testes com mais de 100 testadores humanos, e apesar de dispendioso, esse modelo de desenvolvimento inchado funciona há muitos anos de maneira “satisfatória???”. Os processos de desenvolvimento e qualidade de software variam muito de uma empresa para outra e ainda podem ser vistos de várias formas, porém o mais difícil é entender se o que está sendo aplicado realmente tem um resultado positivo.

Validar um sistema com 100 testadores pode ser uma solução que funciona, entretanto, o custo do software passa a ser exorbitante com o passar do tempo

No Teste de Software Moderno, os testes de aceitação são criados utilizando a metodologia de desenvolvimento guiado por comportamento (BDD — Behavior Driven Development) e podem gerar uma economia de até 90% em relação aos testes criados por testadores humanos. Isso acontece porque os testes são criados através de scripts que são executados automaticamente no ambiente de integração contínua para cada mesclagem de código que ocorre em seu sistema de versionamento (git).

Testes de aceitação podem ser criados para qualquer tipo de aplicação, seja web, mobile, desktop, watch e até aplicações de background.

Integração Contínua (Continuous Integration — CI)

Este tipo de teste ocorre on-demand e pode ser criado com equipes com um ou mais analistas de qualidade e teste de software.

As imagens abaixo apresentam dois exemplos de testes escritos com Gherkin Language (Cucumber) para descrever o comportamento desejado de uma funcionalidade em um sistema.

https://en.wikipedia.org/wiki/Cucumber_(software)#Gherkin_.28Language.29
https://en.wikipedia.org/wiki/Cucumber_(software)#Gherkin_.28Language.29

É fácil observar que existem várias entradas de dados distintas nestes scripts, e que — os melhores analistas de negócios e qualidade conseguiriam escrever os cenários ainda mais complexos, sem a necessidade de programação.

Testes de Aceitação automatizados podem gerar uma economia de até 90% em relação aos testes criados por testadores humanos

Este mesmo tipo de teste pode ser executado em múltiplos browsers simultâneamente ex: Chrome, IE, Firefox e Safari. Já no caso mobile é possível testar aplicativos com Cucumber em até 1000 (mil) smartphones reais com tamanhos de telas diferentes utilizando devices farms como AWS Device Farm ou Xamarin Test Cloud.

Continua…

No próximo artigo continuaremos nossa série e falaremos sobre como criar planos testes de forma eficiente e porque sua empresa precisa repensar os processos de qualidade de software. Fique ligado!

Contato

Software Architecture Models — Getty/IO Inc. 2017

Se você tem desafios com teste e qualidade de software, envie uma mensagem para hello@getty.io, nós podemos te ajudar.

Juntos, imaginamos e criamos aplicações web e mobile que escalam automaticamente e estão sempre disponíveis a partir de qualquer dispositivo em qualquer lugar.

Realizamos mentoring especializado react, react native, redux, processos de desenvolvimento, arquitetura e qualidade de software.

Getty/IO Inc. — 2017

Artigos Relacionados

--

--