(Se é que existe disputa…)

Bem amigos, sejam bem-vindos a este embate de dois gigantes, dois dos grandes gladiadores do novo milênio!

De um lado do ring temos ele… aquele que é tão sinistro (perdão pelo carioquês), que consegue lidar com Android com o pé nas costas enquanto toma uma xícara de café espresso e tem primos mineiros barra pesada que só falam UI (perdão pelo trocadilho) de uma forma peculiar, enquanto comem maçãs gourmetizadas. Uma salva de palmas para o Teste Instrumentado!

Do outro lado do ring temos ele… aquele que é velho de guerra, já lutou diversas batalhas e nunca caiu. Tem no sangue a tabela periódica e sabe de cor o número atômico do Selênio, bebe água usando uma cabaça (que ganhou de um amigo gringo que insiste em chamar de Calabash) e tem uma dieta baseada em pepinos (fornecidos pelo mesmo amigo gringo que dá nome estranho às coisas e nesse caso os chama de Cucumber). Uma salva de palmas para o Teste Funcional!

E começa a luta! Os dois partindo pra cima…

A luta segue adiante, mas pára subitamente e os dois param de se atacar. O público fica confuso, os juízes mais ainda…

O clima de dúvida paira no ar. Todos ficam atônitos e então os dois lutadores decidem se pronunciar:

Essa luta não tem sentido, somos irmãos. Temos nossas diferenças, mas também somos muito parecidos.

Disse o Teste Funcional enquanto o Teste de Instrumentação concordava.

O público, que queria ver o circo pegar fogo, vai deixando o local aos poucos.

Os dois saíram do ring abraçados e seguiram seu caminho em paralelo. Eu, o narrador que vos fala, tenho o dever de explicar o porquê dessa reviravolta. Então vamos lá! Bora conhecer um pouco mais sobre os dois.

Teste Instrumentado

É focado nas possíveis interações com uma tela. Ou seja, o objetivo dele é apenas validar os estados que a tela pode assumir de acordo com os inputs que ela receber.

O foco é validar coisas como:

– Visibilidade de itens, botões e diversos outros tipos de componentes;
– Comportamento por meio de um input na tela, seja vindo de uma interação ou do recebimento/carregamento de um dado.

Assim, ele é executado de forma que as ações de um usuário são simuladas para que seja possível realizar validações sobre um ou mais aspectos da tela. 

Repare que todas as vezes que eu falei sobre tela usei a palavra no singular e não no plural. Isso se deve ao fato de que o teste instrumentado busca realizar validações de UI apenas no nível unitário de tela. Ou seja, testes de UI que realizam navegações entre duas ou mais telas não se encaixam nesse tipo de teste.

Esse “teste unitário” de tela é viabilizado por ferramentas que permitem abrir uma tela específica sem a necessidade de seguir um fluxo, como seria numa interação real. Ou seja, é possível iniciar uma tela específica diretamente, apenas colocando no estado que for necessário para a interação e, assim, realizar a asserção.

Um ponto interessante é que os testes instrumentados estão totalmente ligados ao mundo mobile, no qual na plataforma Android se encontra de forma mais madura do que a iOS.

Nas terras do robozinho verde a ferramenta mais utilizada é um framework de teste do Google chamado de Espresso. Por meio da disposição de diversos métodos de asserção de views e utilizando a linguagem nativa da plataforma, o Espresso possibilita a criação de testes instrumentados que conseguem interagir com os elementos da tela de forma precisa. Aqui tem uma série de posts se você quiser saber mais sobre o assunto, e caso queira aprender mais sobre os testes instrumentados no Android, dê uma olhada neste post do Victor Nascimento.

Nas terras da maçã a história é um pouco mais peculiar. Existem ferramentas que possibilitam a realização dos testes instrumentados, porém é importante salientar dois detalhes. O primeiro é que no iOS esse tipo de teste é chamado apenas de teste de UI. O segundo é que a principal ferramenta de referência não é muito aceita pela comunidade. O UITesting, framework oficial de testes de UI da Apple, não atendeu as expectativas dos desenvolvedores até o momento, devido a alguns fatores como a falta de documentação mais explicativa, ciclo de vida de teste lento e oneroso e métodos pouco intuitivos. A alternativa que a comunidade tem aderido é o KIF, que se dispõe a ser um framework mais simples de usar. Por isso, até o momento a prática do uso de testes instrumentados ou de UI tem sido mais sólida no Android do que no iOS.

Teste Funcional

 

O teste funcional é um velho de guerra, muito utilizado há um bom tempo. Ele tem o objetivo de validar a aceitação de requisitos, regras de negócio e afins. Para isso, a arquitetura de testes das suas ferramentas são formadas por cenários que normalmente navegam pelo software para realizar essas validações dentro de n telas para chegar ao objetivo final de validação. Ou seja, é possível realizar a validação de todo um fluxo que um usuário faria.

Existem diversas ferramentas de teste funcional, dentre elas se destacam o Calabash e o Appium, no mundo mobile, e o Selenium no mundo Web. Grande parte delas tiram proveito do Cucumber, ferramenta que dá a possibilidade de escrever testes em linguagem natural, em diversas linguagens.

Entendendoo o embate entre os dois testes…

Chegamos ao momento derradeiro, quando vamos entender as fagulhas que geraram o “conflito” entre os dois tipos de testes.

Bom, vamos deixar algo bem claro aqui: comparar os dois tipos de teste é algo super natural e bastante pertinente, pois vimos que cada um tem particularidades e características que os credenciam para serem utilizados em cenários distintos. O que não devemos fazer é colocar os dois num embate no qual apenas um será o vencedor, no contexto de estratégia de teste para produtos digitais mobile. Não faz sentido usar uma comparação, com o objetivo de exclusão, entre duas coisas tão complementares. Enquanto temos os testes funcionais garantindo que tudo que o que está sendo desenvolvido está de acordo com as regras de negócio e critérios de aceitação, temos os testes instrumentados dando segurança e qualidade à implementação, validando cenários que podem prevenir erros comuns que poderiam ser pegos por um usuário real da aplicação durante alguma interação.

Outro ponto que vale a pena ser destacado é que a instrumentação é um termo relacionado à categoria do tipo de execução. Ou seja, as ferramentas de teste, por meio da instrumentação, simulam as interações de um usuário com as telas. O teste instrumentado fica restrito apenas a validar essas interações, enquanto o teste funcional, por meio da instrumentação, valida o negócio e não apenas a interação.

Ou seja, os dois testes são bastante pertinentes e muito necessários!

Aplicando teste funcional e teste instrumentado

Bom, agora que já entendemos as semelhanças e diferenças desses dois tipos de teste é hora de entender o momento de aplicar um ou outro num cenário real. Assim, vamos supor que estamos desenvolvendo a funcionalidade de login (exemplo suuuper original, né?), nos nossos aplicativos Android e iOS. Precisamos testar essa feature? Com certeza! Como? vamos descobrir…

– A nível funcional

Pensando no ponto de vista do negócio, um teste funcional tem que validar as regras de negócio relacionadas ao login. Logo, alguns exemplos do que testar nesse caso seriam:

sucesso de login com usuário padrão; sucesso de login com um ou mais usuários com características de negócio específicas, caso se aplique; falha de login com um ou usuários com características de negócio específicas, caso se aplique.

– A nível instrumentado

Pensando no ponto de vista das interações do usuário com as nossas telas, um teste instrumentado vai validar se o usuário consegue interagir com a tela de login em todas as formas que ela possibilita. Assim, se a nossa tela de login for implementada de uma forma em que o botão de login só é habilitado caso os campos necessários para o login estejam preenchidos, teremos os seguintes casos de teste: todas as combinações possíveis de preenchimento dos campos, validando se o botão foi habilitado ou não; preenchimento dos campos com caracteres não permitidos (caso a validação seja feita pelo app e não pela API); e validação, a nível de captura de chamada, se ao logar (de forma mockada) com um usuário e senha a próxima tela será chamada de forma correta.

E então, o que fazer com esses dois ?

Visto que entendemos a importância e a necessidade dos dois tipos de teste, cabe a nós tirar proveito desta união. Porém a pergunta que você, caro amigo leitor (ah, vai.. entra no jogo e faz de conta também), deve ter em mente é a seguinte:

Tá, você já me explicou porque a luta entre os dois foi interrompida e eu também entendi porque os dois são irmãos, agora me diz: como vou fazer pra enfiar esses dois caras no meu dia-a-dia? Já tenho que fazer teste unitário e tu me vem com essa?! Ce é loko, cachoeira!

Calma, calma.. Não criemos pânico !

Eu vou responder a sua pergunta com outra pergunta: qual o limite da garantia de qualidade?

Bom, se você não vai responder então eu vou: Não existe limite, existe bom senso! Bom senso este que está relacionado à estratégia de testes a ser colocada em prática.

Algumas vezes, quando um time falha na definição de uma boa estratégia para atacar os testes do software que está sendo implementado, ocorrem situações não muito desejadas.

A primeira delas é o anti-pattern conhecido como cupcake. Aqui existe uma grande quantidade de testes, porém distribuída de uma forma mal estruturada, pois fica evidente a falta de definição do que testar e no final partes iguais do software estão sendo testadas repetitivamente, gerando desperdício de tempo de implementação e de execução dos testes.

A segunda situação é o anti-pattern conhecido como ice-cream. Nesse caso, a situação parece estruturada, pois a quantidade de testes está bem segmentada. Porém, está desbalanceada. Existe uma quantidade muito grande de testes de UI, o que acaba elevando o tempo de execução dos testes, por serem mais lentos por natureza. Não sendo suficiente, nesse anti-pattern existem muitos testes manuais. Se o tempo de execução de um teste de UI é um pouco demorado, um teste manual que depende de uma pessoa fazer validações é muito maior. Sem contar os riscos de falsos positivos, por conta de erro humano. O que piora a situação é a pequena quantidade de testes nos níveis mais abaixo, nos quais o sistema deveria ter garantia de qualidade nas suas unidades e acaba não tendo. Assim, os testes de UI acabam sobrecarregados com validações que poderiam ser feitas a nível unitário ou a nível de integração.

Ou seja, o caminho a ser seguido não é o de sair testando tudo ao mesmo tempo como se não houvesse amanhã, mas sim o caminho do equilíbrio. Equilíbrio este que pode ser associado a alguns pontos:

– Equilíbrio de estimativa – num ambiente ágil, os incrementos de softwares são desenvolvidos a cada sprint de acordo com a ordem de prioridade, levando em consideração a geração de valor e o esforço. Muitos times comprometem sua estratégia de testes, não levando em consideração que os testes também fazem parte do incremento e acabam estimando apenas o esforço de implementação. O que ocorre no final das contas é que os testes ficam em segundo plano, à mercê do tempo disponível do time. Assim, um incremento é dado como pronto sem a quantidade de testes necessária. Não caia nesse erro. O objetivo do desenvolvimento de um produto digital é o de atingir os objetivos de negócio de um cliente. Tentar atingi-los sem testes é o mesmo que atirar no escuro!

– Equilíbrio de estratégia – o ideal, para conseguir sucesso implementando os principais tipos de teste, é conseguir ser efetivo, entender os objetivos de cada tipo e como eles se aplicam ao seu contexto. No caso dos testes funcionais e dos instrumentados é possível ter esse equilíbrio quando os testes de UI são bem planejados e divididos de acordo com a pertinência de cada aspecto do software. Quando um time não tem muito conhecimento sobre os testes instrumentados, acaba usando os testes funcionais de uma forma exacerbada, aumentando sua complexidade e o seu tempo de execução.

Busque sempre o equilíbrio e não caia em anti-patterns !

Bem amigos, acho que por hoje é só. Nossos amigos Teste Funcional e Teste Instrumentado já estão de boa, sem treta, tudo na paz.

Agora a luta é nossa! Vamos lutar por mais qualidade utilizando não apenas esses dois tipos de testes, mas outros que nos ajudem no processo de garantia de qualidade. A você, que é do mundo da maçã, torço para que Apple melhore o UITesting. Até lá, temos o KIF do nosso lado para nos ajudar o/

Nossa transmissão termina por aqui. Tchau e até a próxima!

Alguns links de referência:

Introducing the Software Testing Cupcake (Anti-Pattern)
– Espresso
WWDC 2015
Calabash
Appium

Trabalha com QA, Android ou iOS e quer fazer parte de um time ágil de verdade? Clique aqui.

QA

Sobre o Autor

Desenvolvedor Android, está concluindo o curso de Ciência da Computação na UERJ. Gosta de estudar tudo relacionado a Android e Internet das Coisas, mas de vez em quando lê uns artigos sobre startups. Nas horas vagas dá aula de FIFA 16 e Counter-Strike e sofre assistindo a zaga do Fluminense jogar. Também finge que joga bola de vez em quando.

  • Carlos Henrique

    Muito bom o texto, me esclareceu algumas dúvidas que eu tinha.

    • Natan Ximenes

      Booa Carlos, que bom que o post te esclareceu algumas duvidas ! Qualquer outra duvida que surgir, só falar 😉

cases

rio de
janeiro

Rua São José, 90
Sala 2121 - Centro
(21) 2240-2030
CEP: 20010-020

são
paulo

Av. Nações Unidas
nº 11.541 - 3º andar
(11) 4119-0449
CEP: 04578-000

belo
horizonte

Av. Getúlio Vargas, 671
Sala 800 - 8º andar
(31) 3360-8900
CEP: 30112-021