O Guia Definitivo de
Testes Contínuos

06. Testes Funcionais¶

Os testes funcionais são focados no aspecto funcional do software (Surpresa!).

Principalmente, eles fazem a pergunta: "O sistema tem bugs?" Em outras palavras, focam em quão bem o software funciona de acordo com as especificações de design e em manter todos os riscos relacionados sob controle. Os testes funcionais verificam as funções centrais, a entrada de testes, as funções de menu, a instalação e a configuração em máquinas localizadas etc.

Como mencionado anteriormente, especialmente nos testes funcionais, é importante que as equipes saibam se sabem o que estão testando. Quais aspectos já foram testados e quais estão faltando? Quão minuciosamente eles são testados?

Do nosso ponto de vista, há três formas principais de fazer testes funcionais:

Ad-hoc:

Ad-hoc equivale a pedir a qualquer um para "testar o sistema por um tempo". Isso é típico daqueles que veem os testes como algo do tipo colocar o software na frente de alguém que faz cliques aleatórios, observando "como está". Não há nenhum elemento de controle, é impossível de rastrear e não há como saber o quão bem ou mal está indo. Os testes servem para obter informações sobre a qualidade, e isso não nos dá tal informação, então nunca recomendaríamos essa abordagem de "testes".

Testes com Scripts:

Nos testes com scripts, primeiro nos perguntamos: "O que é que eu quero testar?" Depois, documenta-se isso e executam-se os testes de acordo com o documento, registrando o que deu certo e o que deu errado. O grande protagonista deste plano de jogo é o "caso de teste." As duas etapas, a de design e a de execução, são tão distantes uma da outra que poderiam ser concluídas por duas pessoas com habilidades diferentes. Um especialista de negócio com conhecimento em projetar casos de teste poderia criar uma planilha (ou ferramenta) com todos os casos que tem interesse em testar. Depois, outra pessoa, que talvez não tenha tanta experiência, poderia pegar aquela documentação e executá-la passo a passo, indicando os resultados de cada teste. Ao fazer isso, o ideal é planejar, deixar um registro de tudo o que foi feito, organizar a equipe e analisar quão profundamente tudo foi testado. Esse método é adequado para testes de regressão, para transmitir a outra pessoa o conhecimento sobre o que foi testado e para documentar o comportamento esperado do sistema.

Testes Exploratórios:

Com o advento das metodologias ágeis e o foco na adaptação à mudança, os casos de teste tornam-se menos relevantes. Nem sempre é ideal ficar esperando que documentos sejam entregues indicando o que testar e qual é o resultado esperado para transmitir uma ideia de quão bem ou mal o sistema funciona. É por isso que existe a abordagem de testes exploratórios, na qual o foco está em projetar e executar testes simultaneamente e, ao fazê-lo, familiarizar-se e aprender mais sobre o sistema. O foco está em encontrar erros e riscos o mais cedo possível. Além disso, é possível se adaptar mais facilmente à mudança, seja dentro da aplicação ou do contexto. Como os testes exploratórios eliminam a necessidade de manter documentos de casos de teste, eles abrem espaço para uma maior flexibilidade. Cada ação que tomamos é baseada no resultado que obtivemos, decidindo o que fazer (e projetando o teste) na hora. Mas atenção: isso não é ad-hoc, porque há uma metodologia bem definida para seguir esse esquema que nos permite organizar, rastrear, controlar e gerenciar todo o processo. Ela visa melhorar de ciclo para ciclo em vez de executar os mesmos testes repetidamente em cada ciclo (pois isso é tedioso, propenso a erros e é melhor do que apenas executar uma verificação automatizada).

Os casos de teste são frequentemente registrados em planilhas ou, melhor ainda, em ferramentas específicas destinadas a esse fim. As alternativas mais ágeis aos casos de teste são sessões de teste, checklists de revisão e mind-maps para registrar ideias de teste em vez de ter uma lista passo a passo de ações a testar. Em qualquer uma das estratégias-chave, é fundamental ter alguma ideia do que é o todo (total de casos de teste, total de funcionalidades a serem testadas, user stories a serem cobertas etc.) e como avançar. Isso é o que significa a cobertura que está sendo obtida. Claro, é necessário priorizar isso de acordo com os níveis de importância e risco para o negócio e os usuários de cada aspecto.

Para alcançar a maturidade em testes e, especialmente, os testes contínuos, deve estar claro o que está sendo testado, como e quão bem. Recomendamos os testes com scripts ou exploratórios, mas nunca os testes ad-hoc.