Construir casos de teste que não chupam (e Como Evitar Erros Comuns)

Os testes de software são um componente crucial do ciclo de vida do desenvolvimento de software. Sem ele, poderia faltar problemas de funcionalidade ou grandes falhas de usabilidade que acabam por frustrar os seus utilizadores finais. Mas todos os casos de teste não são criados de forma igual. Escrever casos de teste de alta qualidade e eficazes é tão importante como testar as suas aplicações. De facto, casos de teste mal escritos podem resultar num processo de teste que é pouco mais eficaz do que não testar de todo.

Então, o que é que casos de teste mal escritos têm em comum? Como podem os profissionais de testes de software escrever casos de teste de qualidade ao mesmo tempo que evitam erros comuns? Para descobrir, procurámos na web os melhores conselhos para escrever casos de teste eficazes e contactámos um painel de profissionais de desenvolvimento e testadores de software e pedimos-lhes que ponderassem sobre esta questão:

“O que têm em comum os casos de teste mal construídos (e como podem os programadores evitar estes erros)?”

Conheça o nosso Painel de Especialistas em Testes de Software:

Descubra o que os nossos profissionais tinham a dizer, lendo as suas respostas abaixo.

Avaneesh Dubey

@qsometests

Avaneesh Dubey é o CEO da Qsome Tech. A sua carreira está marcada por um forte conjunto de inovações em diferentes aspectos dos negócios: Pessoas, Processos, e Tecnologia. Agora, está a construir a Qsome Tech como inovadora de ponta na área da Qualidade de Software.

“Há algumas coisas que muitos casos de teste mal construídos têm em comum…”

1. Demasiado específicos – executam apenas uma condição de teste específica.

Casos de teste precisam de considerar uma variedade de condições que se espera que o software trate. O caso de teste tem de ser capaz de testar exaustivamente o módulo de software com quase todas as combinações possíveis de condições principais. Para ser capaz de testar exaustivamente todas as combinações de condições, o autor deve encontrar uma forma de apresentar estas condições de modo a que seja fácil para os outros reverem.

2. Cobrir uma pequena parte da funcionalidade – precisam de testar uma parte maior do sistema.

Casos de teste focam frequentemente uma função específica. Muitas vezes esta função é determinada pela concepção técnica interna do software. Em vez disso, os casos de teste precisam de reflectir os padrões e fluxos de utilização. Cada caso de teste deve tentar cobrir tanto do fluxo quanto razoavelmente possível – atravessando os limites técnicos da aplicação subjacente.

3. Teste de acordo com uma função específica do utilizador.

Vimos frequentemente casos de teste escritos para uma função específica do utilizador. Isto limita-os no seu âmbito e, por conseguinte, compromete significativamente a sua eficácia. Os casos de teste que são mais eficazes reflectem os padrões de utilização. Uma aplicação empresarial, por exemplo, deve ser testada com casos de teste que são concebidos para testar todo o processo empresarial – abrangendo todas as funções do utilizador e todos os sistemas que possam estar envolvidos no processo empresarial.

4. Escrito para provar que os casos de utilização mais comuns estão bem cobertos na aplicação.

Este é, na minha opinião, um dos problemas mais comuns e resulta daquilo a que chamo uma abordagem “preguiçosa” à concepção de testes. O desenhador do teste simplesmente repete o documento de requisitos em casos de teste. O desenhador do teste deve, em vez disso, procurar os ‘casos de canto’ ou ‘condições de limite’. A maioria dos programadores é facilmente capaz de escrever código para os casos de utilização mais comuns. Os problemas surgem no momento em que existe uma condição do caso de utilização mais comum. Um caso de teste bem desenhado apanhá-los-á facilmente.

5. Qualquer caso de teste pode tornar-se completamente inútil se não for catalogado sistematicamente e mantido disponível para utilização.

Imagine uma biblioteca com livros não catalogados e não mantidos sistematicamente nas prateleiras. Seria impossível utilizar os livros se não os encontrar com facilidade quando precisar deles.

Muitas vezes centenas de casos de teste são escritos com muito esforço e depois atirados para uma estrutura de pastas partilhadas. Embora isto possa funcionar se tiver muito poucos casos de teste, isto apenas colapsa no momento em que o número de casos de teste aumenta. Por conseguinte, precisamos de etiquetar e catalogar sistematicamente os casos de teste. Depois, um sistema de gestão de testes deve ser capaz de ‘retirar’ os casos de teste quando estes precisam de ser executados. Criar e manter múltiplas versões de casos de teste é crucial.

Wes Higbee

@g0t4

Wes Higbee é o Presidente da Full City Tech Company.

“Código de teste que foi forçado é normalmente inútil…”

Talvez haja uma regra de que deve haver 100% de cobertura de código, ou que não se pode adicionar código sem pelo menos um teste. Assim, as pessoas escrevem apenas código de teste suficiente para satisfazer essa regra. É papelada glorificada, relatórios TPS (Espaço de Escritório).

As pessoas aprendem imitando o que observam. Assim, se exigir testes sem ajudar as pessoas a compreender o valor dos testes, então elas tendem a vê-lo como cerimonioso e apenas tentam copiar testes existentes e calçar o seu caso de uso.

Testar não é um fim em si mesmo. Testar, quando benéfico, proporciona confiança, pode poupar tempo, e pode salvaguardar mudanças futuras. Assim, se as pessoas que experimentaram estes benefícios podem transmiti-los aos seus pares, então outras pessoas procurarão esses benefícios e isso leva frequentemente a testes produtivos.

As pessoas que experimentaram os benefícios dos testes devem tentar exaltar esses benefícios, não os testes em si. Por exemplo, se pegarmos num código complicado num sistema de software real que no passado esteve cheio de bugs, e pusermos alguns testes simples à sua volta e já não tivermos esses bugs – então a confiança subirá, as pessoas não terão tanto medo, e lembrar-se-ão disso e levarão os testes à mesa quando se sentirem incertos a seguir.

Não é necessário impor testes se as pessoas tiverem experimentado os benefícios em primeira mão.

Bernard Perlas

@MinhaCorporação

Bernard Perlas é um Gestor de Garantia de Qualidade na MyCorporation que recebeu formação na Universidade DeVry. Ele realiza testes para produtos existentes, bem como actualizações de produtos e sistemas internos. Ele trabalha na concepção de testes de automação de IU e testes de caixa cinzenta do local para assegurar que a informação é correcta.

“Os casos de teste mal construídos têm em comum etapas de teste vagas…”

Para evitar estes erros, é necessário ser específico em relação àquilo que está a testar e estar livre dos seus passos ao longo do caminho. Quanto mais específico for, mais será capaz de replicar problemas e identificar áreas a melhorar e agir sobre eles.

Benjamin Waldher

@wildebeest_dev

Benjamin Waldher é o Engenheiro Chefe de Operações de Dev na Wildebeest.

“Os casos de teste pobres são frequentemente muito dependentes de…”

O funcionamento interno do código a ser testado, o que pode significar que se os detalhes internos de uma função forem alterados, então o caso de teste irá quebrar-se – mesmo que a função já funcione correctamente. Se sentir que está a cometer este erro, pode ser porque as funções que está a testar são demasiado longas, ou pode precisar de exercer mais separação de preocupações.

Matt MacPherson

@itsMattMac

Matt MacPherson é o fundador da Edabit.

“Há algumas coisas que os casos de teste mal construídos têm em comum…”

1. Testar coisas irrelevantes

Testar sem qualquer objectivo real é inútil. Sou um grande fã do princípio da responsabilidade única. Cada teste unitário deve testar uma coisa e é isso.

2. Testar imediatamente

Provavelmente vou apanhar muitas falhas por este, mas nunca teste unitário até as minhas decisões de concepção se terem solidificado. Isto porque sei que estou obrigado a fazer grandes alterações e essas alterações são susceptíveis de quebrar muitos dos meus testes. Isto significa que na prática ou acabarei por escrever menos testes ou não farei grandes alterações de design. Ambos são maus, e esperar pela clareza do design resolve o dilema.

3. Testes de integração vs. testes unitários

Vejo muitos programadores a fazer testes de integração quando estão realmente a tentar fazer testes unitários (e vice-versa). Quando se testa a aplicação como um todo para bugs, é considerado um teste de integração. O teste de unidade preocupa-se com uma unidade específica de comportamento de códigos enquanto o teste de integração se preocupa com o comportamento da aplicação como um todo.

Manu Singh

@ClrMobile

Manu Singh é um Arquitecto Móvel na Clearbridge Mobile com experiência em Design, Desenvolvimento, e Testes Android. Na Clearbridge, Manu gere recursos de projecto para uma equipa de programadores que constrói aplicações de classe mundial para clientes empresariais.

“Há vários pontos comuns que os casos de teste mal construídos partilham…”

Primeiro, os casos de teste podem ser demasiado simples, significando que apenas testam a função principal sem testar demasiados casos extremos. Para evitar isto, um revelador deve cobrir o maior número possível de casos de canto. Se uma interface está a ser desenvolvida e requer uma entrada que não é trivial, então o teste de entradas más ou vazias é importante.

Segundamente, os casos de teste mal construídos não reflectem a forma como um utilizador irá perceber e utilizar a funcionalidade. Fazer casos de teste para isto é mais difícil de fazer, uma vez que é preciso entrar na mente de outro utilizador. Pense em segmentar os seus utilizadores e identificar os seus casos de utilização. Depois identifique os caminhos mais rápidos para completar uma viagem do utilizador, uma vez que um utilizador tentará reduzir o número de passos que necessita de introduzir para completar uma determinada viagem. É importante qualificar diferentes casos de utilização, com designers e gestores de projecto para identificar melhor estes tipos de casos de teste.

E, finalmente, um caso de teste mal construído não testa contra aspectos de uma aplicação que possam causar o seu início em paralelo ou depois de outra. Muitas vezes, os casos de teste apenas testam uma característica específica de uma aplicação sem verem as ramificações de múltiplas características a serem activadas e a interagir com elas. A consideração de casos de teste interfuncionais é importante, especialmente se houver restrições de desempenho. Duas funções aparentemente separadas podem consumir os mesmos recursos, causando assim bloqueios.

Rick Rampton

@QASource

Rick Rampton é Chefe de Sucesso do Cliente no QASource, supervisionando o marketing, vendas e gestão de clientes. Tem sido fundamental na construção de QASource, com um historial comprovado na construção, gestão e retenção de equipas de engenharia de alto desempenho offshore. Sediado em Pleasanton, Califórnia, QASource é um dos principais fornecedores mundiais de software de QA.

“Existem múltiplos identificadores que nos permitem reconhecer um caso de teste mal construído…”

1. Muitas vezes, um resumo dos casos de teste mal construídos não destaca o objectivo do caso de teste, ou o que precisa de ser alcançado.
2. O pré-requisito para executar o caso de teste não está claramente definido ou ausente, o que pode causar confusão ao revelador/teste sobre quais os dados ou condições de teste necessários antes de executar o caso de teste.
3. Se faltarem etapas nos casos de teste, então deixa lacunas para o revelador/teste, fazendo com que estes façam suposições ao executar casos de teste. Isto pode causar a inexactidão da execução do caso de teste e a falta de cenários importantes.
4. A ausência do ambiente certo para a execução dos casos de teste é outro indicador de casos de teste mal construídos.
5. Se o resultado esperado não for claramente descrito no caso teste, então o testador não terá a certeza sobre os resultados/ tem de verificar com esse caso teste.

Rachel Honoway

@rachelhonoway

Rachel é um executivo experiente especializado em Startups da Internet e Empresas em Modo de Crescimento. A sua carreira tem sido passada a trabalhar de forma prática com empresários para construir e fazer crescer produtos SaaS e serviços relacionados.

“A sequência de eventos é muitas vezes demasiado simplificada, levando a um caso de teste mal construído…”

Os promotores tendem a assumir um caminho recto e lógico do princípio ao fim. Na realidade, porém, os utilizadores finais tomarão um número exponencial de caminhos, muitos deles ilógicos. Quando os programadores não levam tempo a considerar todas as variáveis que podem estar a afectar o utilizador no momento em que são confrontados com a funcionalidade/página/função, deixam muito espaço para falsos testes positivos.

De facto, os programadores devem observar vários utilizadores enquanto interagem com a plataforma, e depois passar algum tempo a pedir aos defensores internos do cliente (apoio ao cliente, gestores de produto, agentes de vendas) que compreendam melhor o utilizador. Os agentes de vendas podem ajudar a definir quem é o utilizador e descrever a necessidade que a aplicação está a satisfazer. Os representantes do serviço de apoio ao cliente podem identificar pontos comuns de colagem para a base de utilizadores, como palavras-passe perdidas ou detractores de atenção comuns, como anúncios na página. Os responsáveis pelo produto podem fornecer informações sobre como o utilizador interage com a aplicação e como essa interacção se enquadra no maior fluxo de trabalho ou na rotina diária do utilizador, descrevendo as distracções que ocorrem fora da própria aplicação (gestão de múltiplos ecrãs ao mesmo tempo, utilizadores móveis a receber notificações enquanto conduzem, etc.).

Entendendo o que pode afastar o utilizador final do caminho lógico e recto, ajudará os programadores a testar essas variáveis e a assegurar uma experiência bem sucedida apesar das distracções, caminhos ilógicos e perda de foco.

Anthony Breen

@BreenAnthony77

Anthony Breen é o Co-Fundador e CEO da aplicação The Feasty Eats. Feasty Eats é uma plataforma integrada SaaS que ajuda os restaurantes a conduzir o tráfego durante os seus tempos de baixo volume.

“Ao considerar casos de teste…”

É importante que os criadores voltem a alguns dos aspectos mais simples, mas mais importantes, do processo de inquérito. Tal como numa experiência científica, há dois factores que devem estar na vanguarda da mente de qualquer desenvolvedor a fim de facilitar um teste eficaz e significativo: clareza e controlo. Mais especificamente, as hipóteses claramente delineadas e a atenção cuidadosa aos indicadores-chave de desempenho precisam de ser comunicadas antes do início do teste. Ao fazê-lo, cria-se um quadro forte para uma investigação mais aprofundada.

Além disso, é essencial que todas as variáveis não só sejam identificadas mas também cuidadosamente controladas. O enviesamento deve ser eliminado das populações de teste e as potenciais variáveis de confusão devem ser identificadas para que os programadores possam adquirir dados perspicazes e precisos. Um objectivo bem definido e claramente articulado, quando emparelhado com um ambiente de teste meticulosamente controlado, não só produzirá resultados valiosos como, mais importante ainda, suscitará novas questões e hipóteses que conduzem a um inquérito alargado.

Devlin Fenton

@devfen

Devlin Fenton é o CEO da Go99. Devlin lidera uma pequena equipa especializada de engenheiros e programadores que se dedicam à resolução de problemas pela Indústria, para a Indústria. Esta equipa lançou recentemente uma plataforma de correspondência de carga digital destinada a perturbar a indústria de camiões da América do Norte, no valor de 700 mil milhões de dólares. Devlin acredita Construir uma equipa de peritos e deixá-los prosperar.

“Os piores casos de teste são aqueles que não existem…”

De longe, o maior problema é que não existem em número suficiente e o sistema não pode ser testado de forma fiável de forma automatizada. Falta-lhes consideração pela prioridade. Uma vez que os programadores entram em casos de teste de escrita, muitas vezes desenvolvem muitos dos mais fáceis, que testam código trivial, estático e de baixo risco. Deve ser feito um esforço no sentido de visar códigos complexos e arriscados e, para isso, por vezes o caso de utilização é também mais complexo e mais difícil de desenvolver.

A crença é que se não é um teste unitário não deve ser feito. Os testes de integração, testes de dados, testes de desempenho, testes de stress, etc., devem fazer parte do conjunto de testes.

A falta de foco em termos do objectivo é outra questão. Por exemplo, isto é um teste de unidade, teste de integração, teste de desempenho, ou outro tipo? A mistura destas prioridades torna os casos de utilização mais frágeis e mais difíceis de corrigir. Precisam de ter foco e ser anotados em conformidade para que o conjunto de teste possa ser executado de forma direccionada.

Adicionalmente, alguns casos de teste carecem de rigor, cobrindo apenas um caminho feliz e não o suficiente dos fluxos alternativos e de excepção. Efectivamente, o caso de utilização segue o padrão de make-it-work do desenvolvedor, em vez do padrão de teste make-it-fail.

P>Outra questão são os casos de teste que não são mantidos, o que os faria falhar se fossem executados, ou se fossem comentados em conjunto. À pressa, os programadores alteram muitas vezes o código e contornam a fixação dos casos de teste.

Casos de teste de construção pobre podem também carecer de clareza quanto ao que está a ser testado, incluindo o objecto, o método ou o cenário. Os casos de teste devem seguir uma convenção (nomeação, comentários, etc.) que facilite a identificação do âmbito do teste.

Casos de teste bem construídos evitam uma teia de dependências. As dependências entre casos de teste devem ser evitadas; caso contrário, uma única falha pode mostrar muitos testes a falhar, tornando mais difícil identificar a causa. Se houver uma lógica comum para estabelecer condições prévias, ou avaliar os resultados, tal lógica deve ser abstraída e partilhada em vez de empilhar os casos de teste.

Rohit Keserwani

@EquifaxInsights

Rohit Keserwani é um Consultor BI e Analista Comercial Sr. para Equifax.

“Observei as seguintes características normalmente presentes em casos de testes maus…”

1. Análise de impacto não documentada. Quando um analista de testes não documenta o impacto, suponha que não conhece o impacto. O resultado? POOF…!

2. A pré-condição do ensaio ou não está definida ou está pouco articulada.

3. Olhando para o fundo do utilizador e assumindo as coisas. Se não compreender o nível de conhecimento da pessoa que vai testar, não assuma nada. Basta documentar tudo até ao mais ínfimo pormenor. Caso contrário, pode acabar por assumir alguns conhecimentos que lhes faltam, o que pode levar o utilizador a testar de forma diferente do esperado.

4. Passar critérios e tolerância não claramente definidos. Se por qualquer razão os critérios de aprovação não forem articulados, a pessoa que testa é deixada à sua sorte para decidir se um determinado teste passou ou não. Se não tiver um cenário de aprovação claramente definido, o testador não terá uma referência com a qual se possa comparar. Isto criaria ambiguidade e eventualmente colocaria todo o esforço de teste em jogo.

Pete Van Horn

@PraxentSoftware

Pete Van Horn é um Analista de Tecnologia de Negócios para a Praxent.

“Tenho muita experiência com casos de teste mal construídos, e também sou provavelmente culpado de os escrever de tempos a tempos…”

Muitas vezes, um caso de teste não é facilmente executável. Se eu for um desenvolvedor, devo ser capaz de ter informação suficiente e estar posicionado de forma a poder executar o meu caso de teste para determinar um resultado. Penso que uma coisa sobre casos de teste é que eles não têm necessariamente de resultar no resultado pretendido, mas precisam sempre de ser executáveis de ponta a ponta. Mesmo que se obtenha um resultado negativo, isso é melhor do que ficar preso. Um caso de teste mal construído não permite que quem está a fazer o teste o execute completamente.

Em termos de erros dos programadores, talvez eu esteja a pensar demais, mas normalmente os programadores não escrevem o caso de teste. Podem escrever testes unitários, mas um caso de teste é normalmente escrito por um analista de negócios ou por um arquitecto de soluções. Eles são responsáveis pela criação do resultado esperado. Eu diria que ter casos de teste bem escritos encontra realmente a sua génese em ter requisitos realmente bem redigidos. Ter bons requisitos permite criar um bom caso de teste. E um bom caso de teste é capaz de ser executado de ponta a ponta, sem interrupção.

Hans Buwalda

@logigear

At Stackify, compreendemos quão crucial é o teste de software no ciclo de vida do desenvolvimento, pelo que é um tópico que discutimos regularmente. Sabia que pode integrar o APM na sua estratégia de testes? Descubra como aqui.

Para mais conselhos de especialistas sobre como escrever casos de testes de qualidade (e porque é que é como o método científico), consulte este post, ou visite este artigo para uma lista de 101 dicas de testes de software de especialistas e conselhos para tirar o máximo partido do seu processo de testes. Para uma análise mais aprofundada dos tipos de testes de desempenho e testes de software, etapas de testes de desempenho, e melhores práticas, visite este guia.