O teste ad-hoc é um tipo de teste de software que os programadores e as empresas de software implementam quando verificam a iteração actual do software. Esta forma de teste proporciona um maior nível de conhecimento sobre o programa, localizando problemas que os testes convencionais podem não ser capazes de destacar.
É fundamental que as equipas de teste tenham uma compreensão completa do processo de teste ad hoc para que saibam como contornar os seus desafios e garantir que a equipa pode implementar esta técnica com sucesso.
Saber exactamente como funcionam os testes ad-hoc e quais as ferramentas que podem facilitar a sua implementação, permite a uma empresa melhorar continuamente os seus próprios procedimentos de garantia de qualidade. O processo de teste formal segue regras muito específicas, o que pode fazer com que a equipa não detecte determinados erros – as verificações ad-hoc podem contornar estes pontos cegos e testar rapidamente todas as funcionalidades do software.
Neste artigo, examinamos em pormenor os testes ad-hoc e a forma como pode utilizá-los em seu benefício quando desenvolve um produto de software.
Significado de testes ad hoc: O que é Teste Ad-Hoc?
Os testes ad-hoc são um processo de garantia de qualidade que evita regras e documentação formais, ajudando os testadores a encontrar erros na sua aplicação que as abordagens convencionais não conseguem identificar. Normalmente, isto requer um conhecimento abrangente do software antes do início dos testes – incluindo uma compreensão do funcionamento interno do programa. Estas verificações ad-hoc têm como objectivo quebrar a aplicação de forma a reflectir os dados introduzidos pelo utilizador, tendo em conta várias situações potenciais para que os programadores possam corrigir quaisquer problemas existentes.
A falta de documentação é fundamental para esta técnica, que não inclui nenhuma lista de verificação ou casos de teste para orientar os testadores através das características de uma aplicação. Os testes ad-hoc consistem inteiramente em testar o software da forma que uma equipa decidir ser eficaz nesse momento específico. Isto pode ter em conta testes formais pré-existentes, mas também pode simplesmente envolver a realização do maior número possível de testes no tempo (provavelmente limitado) que é atribuído a esta técnica.
1. Quando e porque é que é necessário efectuar testes ad hoc em testes de software?
A principal razão pela qual as empresas efectuam testes ad-hoc deve-se à sua capacidade de descobrir erros que as abordagens tradicionais não conseguem encontrar. Isto pode dever-se a uma série de razões, como o facto de os casos de teste convencionais seguirem um processo especialmente normalizado que não pode ter em conta as idiossincrasias de uma aplicação.
Cada tipo de teste pode oferecer novas perspectivas e abordagens interessantes para a garantia de qualidade – o que também mostra problemas com a estratégia de teste habitual. Por exemplo, se os testes ad-hoc conseguirem identificar uma preocupação que os casos de teste da equipa não abordam, isso sugere que podem beneficiar da recalibração da sua metodologia de teste.
Os testadores podem efectuar verificações ad-hoc em qualquer ponto do processo de teste. Normalmente, serve de complemento à garantia de qualidade tradicional (e mais formal) e, com isto em mente, os testadores podem realizar inspecções ad-hoc enquanto os seus colegas realizam exames mais formais. No entanto, podem preferir guardar as verificações ad-hoc para depois do processo de teste formal, como um acompanhamento que visa especificamente os potenciais pontos cegos.
Os testes ad-hoc também podem ser úteis quando o tempo é especialmente limitado devido à falta de documentação – o momento certo depende da empresa e da sua abordagem preferida.
2. Quando não é necessário efectuar testes ad hoc
Se não houver tempo suficiente para realizar testes ad-hoc e formais, é importante que a equipa dê prioridade a estes últimos, uma vez que garantem uma cobertura substancial dos testes – mesmo que ainda existam algumas lacunas.
Se os testes formais da equipa encontrarem erros que necessitem de ser corrigidos, é geralmente melhor esperar até que os programadores concluam as alterações necessárias para efectuar verificações ad-hoc. Caso contrário, os resultados que fornecem podem tornar-se rapidamente desactualizados, especialmente se os testes estiverem relacionados com o componente que já apresenta erros.
Além disso, devem ser efectuados testes ad-hoc antes da fase de testes beta.
3. Quem está envolvido nos testes ad hoc?
Existem várias funções-chave envolvidas no processo de testes Ad-Hoc, incluindo:
– Os testadores de software são os principais membros da equipa que realizam verificações ad hoc. Se estiver a realizar testes de pares ou de amigos, então vários destes testadores trabalharão em conjunto nos mesmos componentes.
– Os programadores podem utilizar estas verificações de forma independente, antes da fase formal de garantia da qualidade, para inspeccionar rapidamente o seu próprio software, embora com menos profundidade do que os testes ad-hoc dedicados.
– Os chefes de equipa ou de departamento autorizam a estratégia global de testes, ajudando os testadores a determinar quando devem iniciar os testes ad hoc e como os realizar sem perturbar outras verificações.
Vantagens dos testes ad hoc
As vantagens dos testes ad-hoc nos testes de software incluem:
1. Resoluções rápidas
Como estes testes não envolvem documentação frequente antes, durante ou depois das verificações, as equipas podem identificar problemas muito mais rapidamente. Esta simplicidade oferece uma enorme liberdade aos testadores.
Por exemplo, se testarem um componente e não conseguirem identificar quaisquer erros, a equipa pode simplesmente passar para o teste seguinte sem registar esse facto num documento.
2. Complementa outros tipos de testes
Nenhuma estratégia de testes é perfeita e, normalmente, é impossível atingir 100% de cobertura, mesmo com um calendário exaustivo. Haverá sempre lacunas nos testes convencionais, pelo que é importante que as empresas integrem várias abordagens.
Os testes ad-hoc têm como objectivo específico encontrar os problemas que os testes formais não conseguem cobrir, garantindo uma cobertura global mais ampla dos testes.
3. Execução flexível
Os testes ad-hoc podem ocorrer em qualquer ponto do processo de garantia de qualidade antes do teste beta, permitindo que as empresas e as equipas decidam quando é melhor executar estas verificações. Podem optar por realizar testes ad-hoc em simultâneo com os testes convencionais ou podem esperar até mais tarde – seja como for, a equipa beneficia das opções à sua disposição.
4. Maior colaboração
Os programadores estão mais envolvidos neste processo do que em muitas outras formas de teste – especialmente se a empresa estiver a utilizar testes de pares e de amigos.
Como resultado, os programadores obtêm uma melhor percepção das suas próprias aplicações e podem ser capazes de resolver os erros com um nível mais elevado. Isto ajuda a melhorar ainda mais a qualidade geral do software.
5. Perspectivas diversas
Os testes ad-hoc podem mostrar a aplicação de novos ângulos, ajudando os testadores a interagir com estas funcionalidades de novas formas. As perspectivas adicionais são fundamentais durante os testes, uma vez que as verificações formais apresentam frequentemente, pelo menos, pequenas lacunas.
Se os testadores ad-hoc utilizarem o software com a intenção específica de o quebrar, poderão identificar mais facilmente os limites do programa.
Desafios dos testes ad hoc
O processo de teste ad-hoc também tem vários desafios, tais como:
1. Dificuldade em apresentar relatórios
A falta de documentação torna os testes ad-hoc muito mais rápidos, mas também pode dificultar a elaboração de relatórios para qualquer coisa que não seja um problema grave.
Por exemplo, um controlo previamente efectuado pode tornar-se mais relevante numa data posterior, apesar de não ter conduzido inicialmente a resultados significativos. Sem uma documentação exaustiva, a equipa pode não ser capaz de explicar estes testes.
2. Menos repetível
Na mesma linha, os testadores podem não estar totalmente conscientes da condição exacta necessária para causar as reacções que observam. Por exemplo, uma verificação ad-hoc que devolva um erro pode não ter informação suficiente para a equipa tomar medidas. Poderão não saber como repetir este teste e obter o mesmo resultado.
3. Requer experiência em software
Como a velocidade é fundamental nos testes ad-hoc e, normalmente, envolve a tentativa de quebrar a aplicação, é importante que estes testadores tenham um conhecimento profundo deste programa.
Saber como funciona permite aos testadores quebrar e manipular o software de mais formas, mas isto pode aumentar significativamente as exigências de competências para os testes ad-hoc.
4. Responsabilidade limitada
A falta de documentação pode causar mais problemas do que apenas um relatório deficiente; pode também prolongar inadvertidamente o processo de teste, afectando a utilidade de testes ad-hoc rápidos e individuais.
Os testadores podem ter dificuldade em acompanhar o seu progresso sem documentação suficiente ao longo de cada fase. Isto pode mesmo levá-los a repetir uma verificação que outros testadores já efectuaram.
5. Pode não reflectir a experiência do utilizador
O objectivo de praticamente todos os tipos de testes é ter em conta os erros que afectam de alguma forma os utilizadores finais. Os testes ad-hoc baseiam-se principalmente num testador experiente que tenta imitar um utilizador inexperiente e isto deve ser consistente em cada verificação, incluindo as suas tentativas de quebrar a aplicação.
Características dos testes Ad-Hoc
As principais características dos testes ad-hoc bem sucedidos incluem:
1. Investigação
A principal prioridade dos testes ad-hoc é identificar erros na aplicação utilizando técnicas que as verificações convencionais não têm em conta. Os exames ad-hoc vasculham este software com o objectivo expresso de encontrar falhas no procedimento de teste da equipa, incluindo a cobertura dos seus casos de teste.
2. Não estruturado
As verificações ad hoc não têm normalmente um plano definido para além da realização do maior número possível de testes fora dos limites típicos da garantia de qualidade formal. Normalmente, os testadores agrupam as verificações por componente por uma questão de conveniência, mas nem isso é necessário – podem até conceber as verificações enquanto as executam.
3. Orientado para a experiência
Os testadores ad-hoc utilizam a sua experiência de software pré-existente para avaliar quais os testes que trariam mais benefícios e resolver os pontos cegos comuns nos testes formais.
Embora o processo de teste ainda não esteja totalmente estruturado, os testadores aplicam os seus conhecimentos de verificações ad-hoc anteriores, entre outros, enquanto decidem a sua estratégia.
4. Vasto leque
Não existem guias exactos para as verificações que a equipa deve efectuar durante os testes ad-hoc, mas normalmente abrangem uma série de componentes – possivelmente com maior incidência nos aspectos mais sensíveis da aplicação. Isto ajuda os testadores a garantir que os seus exames são capazes de complementar totalmente os testes formais.
O que é que testamos nos testes ad hoc?
As equipas de garantia de qualidade testam normalmente o seguinte durante os testes ad-hoc:
1. Qualidade do software
Estas verificações têm como objectivo identificar erros na aplicação que os testes convencionais não conseguem descobrir; isto significa que o processo testa principalmente a saúde geral da aplicação.
Quanto mais erros os testes ad-hoc conseguirem localizar, mais melhorias os programadores podem implementar antes do prazo.
2. Casos de teste
Os testes ad-hoc geralmente não implementam casos de teste – e isto é especificamente para que a equipa possa investigar a sua eficácia em fornecer uma cobertura ampla. Os casos de teste são provavelmente inadequados se as verificações ad-hoc conseguirem encontrar erros que os processos de teste convencionais não conseguem.
3. Pessoal de controlo
O objectivo também pode ser verificar as competências e os conhecimentos da equipa de testes, mesmo que os casos de teste sejam adequados. Por exemplo, a sua metodologia de implementação dos casos pode ser insuficiente e os testes ad-hoc podem ser essenciais para colmatar as lacunas resultantes na cobertura dos testes.
4. Limites do software
Os testes ad-hoc também procuram compreender os limites da aplicação – por exemplo, a forma como responde a entradas inesperadas ou a cargas elevadas do sistema. Os testadores podem estar a investigar especificamente as mensagens de erro do programa e o desempenho desta aplicação quando está sob pressão significativa.
Esclarecer alguma confusão:
Testes ad hoc e testes exploratórios
Algumas pessoas consideram que os testes ad-hoc e os testes exploratórios são sinónimos, embora a verdade seja mais complicada do que isso.
1. O que são testes exploratórios?
Os testes exploratórios referem-se a procedimentos de garantia de qualidade que investigam o software de um ponto de vista holístico e combinam especificamente os processos de descoberta e de teste num único método. Trata-se normalmente de um meio-termo entre os testes totalmente estruturados e as verificações ad-hoc de forma totalmente livre.
Os testes exploratórios funcionam melhor em cenários específicos, por exemplo, quando é necessário um feedback rápido ou se a equipa tiver de abordar casos extremos. Este tipo de teste atinge normalmente todo o seu potencial quando a equipa utiliza testes com guião em paralelo.
2. Diferenças entre Testes Exploratórios
e testes ad hoc
A maior distinção entre os testes ad-hoc e os testes exploratórios é o facto de os primeiros utilizarem documentação para registar e facilitar as suas verificações, ao passo que os testes ad-hoc evitam isso completamente. Os testes exploratórios dão mais ênfase à liberdade dos testes, mas nunca ao mesmo nível que uma abordagem ad-hoc, que é totalmente não estruturada.
Os testes exploratórios também envolvem a aprendizagem sobre a aplicação e o seu funcionamento interno durante estas verificações – os testadores ad-hoc têm frequentemente um conhecimento abrangente da funcionalidade do software antes de começarem.
Tipos de testes ad hoc
Existem três formas principais de testes ad-hoc em testes de software, incluindo:
1. Testes com macacos
Talvez o tipo mais popular de testes ad-hoc, os testes-macaco são aqueles que envolvem uma equipa que analisa aleatoriamente diferentes componentes.
Normalmente, isto ocorre durante o processo de teste da unidade e efectua uma série de verificações sem quaisquer casos de teste. Os testadores investigam os dados de forma independente e completamente não estruturada, permitindo-lhes examinar o sistema em geral e a sua capacidade de resistir à pressão intensa dos inputs dos utilizadores.
A observação dos resultados destas técnicas não escritas ajuda a equipa de testes a identificar erros que outros testes unitários não detectaram devido a deficiências nos métodos de teste convencionais.
2. Testes com amigos
Num contexto ad-hoc, os testes de parceria utilizam, no mínimo, dois membros da equipa – normalmente um testador e um programador – e ocorrem principalmente após a fase de testes unitários. Os “companheiros” trabalham em conjunto no mesmo módulo para detectar erros. As suas competências diversificadas e a sua vasta experiência fazem deles uma equipa mais eficaz, o que ajuda a aliviar muitos dos problemas que surgem devido à falta de documentação.
O programador pode até sugerir alguns dos testes, permitindo-lhe identificar os componentes que podem necessitar de mais atenção.
3. Teste de pares
O teste em pares é semelhante, na medida em que envolve dois membros da equipa, mas normalmente são dois testadores diferentes, um dos quais executa os testes reais enquanto o outro toma notas.
Mesmo sem documentação formal, a tomada de notas pode permitir que a equipa acompanhe informalmente as verificações individuais ad hoc. Os papéis de testador e escriba podem alternar consoante o teste ou o par pode manter os seus papéis atribuídos ao longo de todo o processo.
O testador com mais experiência é normalmente aquele que efectua as verificações reais – embora partilhem sempre o trabalho uns com os outros.
Testes Ad-Hoc manuais ou automatizados?
Os testes automatizados podem ajudar as equipas a poupar ainda mais tempo durante a fase de garantia de qualidade, o que permite aos testadores encaixar mais verificações na sua agenda. Mesmo sem uma estrutura definida, é essencial que os testadores trabalhem para maximizar a cobertura e a automatização incentiva inspecções mais aprofundadas deste software.
As verificações ad-hoc automatizadas são geralmente mais exactas do que os testes manuais, devido à sua capacidade de evitar erros humanos durante as tarefas repetitivas – o que é especialmente útil quando se aplicam os mesmos testes em diferentes iterações. O sucesso deste procedimento depende normalmente da ferramenta de teste automatizado que a equipa selecciona e da sua funcionalidade.
No entanto, os testes automatizados têm algumas limitações. Por exemplo, o principal ponto forte dos testes ad-hoc é a sua capacidade de emular os dados introduzidos pelo utilizador e de efectuar verificações aleatórias à medida que o testador as vai inventando. Estes testes podem perder a sua aleatoriedade se o programa de testes da organização tiver dificuldades com verificações complexas.
O tempo necessário para automatizar estas tarefas altamente específicas pode também limitar as poupanças de tempo típicas deste processo. É importante que as equipas investiguem minuciosamente as ferramentas de automatização disponíveis para encontrar uma que corresponda ao projecto da sua empresa.
O que é necessário para iniciar os testes ad hoc?
Eis os principais pré-requisitos dos testes ad-hoc:
1. Pessoal qualificado
Como os testes ad-hoc são inspecções rápidas e aleatórias do funcionamento interno do software, é normalmente útil ter testadores com experiência no software. Devem também ter um conhecimento prático dos princípios fundamentais dos testes, o que lhes permite identificar facilmente as verificações mais eficazes.
2. Uma abordagem não estruturada
Os testadores devem estar dispostos a abandonar as suas estratégias habituais de testes ad-hoc; esta mentalidade é tão crítica como os próprios controlos de qualidade. Este método só pode ser bem sucedido sem estrutura ou documentação e é vital que os testadores se lembrem disto em todas as fases.
3. Software de automatização
Embora os testes ad-hoc se baseiem mais no teste de entradas e condições aleatórias, a automatização continua a ser uma técnica muito eficaz em qualquer contexto.
Por este motivo, as verificações ad-hoc devem implementar ferramentas de teste automatizadas sempre que possível, uma vez que a aplicação correcta pode simplificar significativamente o processo.
4. Outras formas de ensaio
Os testes ad-hoc funcionam melhor em conjunto com outras verificações que adoptam uma abordagem mais formal – ajudando a equipa a garantir uma cobertura substancial em todo o software. É vital que os testadores misturem várias técnicas, embora isso possa ser feito antes, durante ou depois de concluírem os testes ad-hoc.
Processo de testes ad hoc
Os passos habituais que os testadores devem seguir quando efectuam testes ad-hoc em testes de software são
1. Definição dos objectivos dos testes ad-hoc
Esta fase é limitada devido à falta de documentação e de estrutura, mas continua a ser fundamental que a equipa tenha uma orientação clara. Os responsáveis pelos testes podem começar a partilhar ideias vagas sobre os próximos testes a realizar e os componentes a que devem dar prioridade.
2. Selecção da equipa de teste ad-hoc
À medida que a equipa faz um brainstorming de uma série de potenciais verificações ad-hoc, também descobre quais os testadores mais adequados para este tipo de testes. Normalmente, seleccionam testadores que compreendem intimamente a aplicação e podem também associá-los a um programador.
3. Execução de testes ad-hoc
Depois de decidir quais os testadores adequados para esta fase, estes membros da equipa começam as suas verificações num ponto acordado do teste. O seu objectivo é realizar o maior número possível de verificações ad-hoc – que os testadores podem não ter concebido até esta fase.
4. Avaliação dos resultados dos ensaios
Após a conclusão dos testes (ou mesmo entre verificações individuais), os testadores avaliarão os resultados, mas sem os documentar formalmente num caso de teste. Se detectarem quaisquer problemas com a candidatura, registam-nos informalmente e discutem os próximos passos da equipa.
5. Comunicar os erros detectados
Depois de avaliarem os resultados, os testadores devem informar os programadores sobre os erros presentes no software, para que estes tenham tempo suficiente para os corrigir antes do lançamento.
A equipa de testes também utiliza a informação para determinar como melhorar os seus processos de teste formais.
6. Repetição dos ensaios, se necessário
É provável que a equipa de testes repita o processo ad-hoc para novas iterações da aplicação, a fim de verificar se esta lida bem com as actualizações. Como os testadores terão corrigido muitas das lacunas previamente identificadas nos seus casos de teste, as futuras verificações ad-hoc poderão exigir uma abordagem diferente.
Melhores práticas para testes ad hoc
Há certas práticas que as equipas de teste devem implementar durante os testes ad-hoc, incluindo
1. Identificar potenciais lacunas nos testes
Embora os testes ad-hoc impliquem muito menos planeamento do que outros tipos, a equipa continua a tentar colmatar as lacunas na garantia de qualidade. Se os testadores ad-hoc suspeitarem de algum problema específico com os casos de teste da equipa, devem dar prioridade a esse problema enquanto realizam as suas verificações.
2. Considerar um software de automatização
As estratégias de automatização, como a hiperautomatização, podem oferecer muitas vantagens às empresas que pretendem efectuar testes ad-hoc.
O sucesso deste processo depende de vários factores-chave, incluindo a ferramenta que a empresa escolhe, bem como as complexidades gerais dos seus testes ad-hoc.
3. Tomar notas completas
A falta de documentação nos testes ad-hoc serve sobretudo para simplificar ainda mais este processo – a equipa poderia beneficiar da tomada de notas informais à medida que avança. Isto dá aos testadores um registo claro destas verificações e dos seus resultados, aumentando a sua repetibilidade global.
4. Continuar a aperfeiçoar os testes
Os testadores ad-hoc aperfeiçoam continuamente a sua abordagem para ter em conta as alterações na estratégia de testes da equipa. Ao analisar as versões mais recentes do software da empresa, por exemplo, podem ajustar estas verificações em resposta a casos de teste formais mais recentes e mais inclusivos.
7 Erros e armadilhas na implementação
Testes Ad-Hoc
Como em qualquer processo de teste, existe uma vasta gama de potenciais erros que a equipa deve tentar evitar, tais como
1. Testadores inexperientes
Para manter o ritmo esperado dos testes ad-hoc, o chefe de equipa deve atribuir os testadores com base nos conhecimentos e competências que possuem. Embora muitas formas de teste possam acomodar pessoal de garantia de qualidade de nível básico, as verificações ad-hoc requerem membros da equipa que compreendam totalmente o software, de preferência com experiência na execução destes testes.
2. Controlos desfocados
Os testes ad-hoc podem melhorar significativamente a cobertura dos testes devido ao seu ritmo mais rápido – a equipa não precisa de preencher documentação extensa antes e depois de cada verificação.
No entanto, os testadores ad-hoc devem ainda manter uma forte concentração; por exemplo, podem decidir dar prioridade a certos componentes com um maior risco de falha.
3. Sem planeamento
Evitar qualquer tipo de plano pode limitar a eficácia dos testes ad-hoc. Apesar da natureza não estruturada desta abordagem, é importante que a equipa tenha uma ideia aproximada dos testes a executar antes de começar.
O tempo é limitado durante este processo e saber como proceder pode oferecer muitos benefícios.
4. Demasiado estruturado
No extremo oposto do espectro, esta abordagem baseia-se normalmente na falta de planeamento, uma vez que ajuda os testadores a subverter activamente os casos de teste e a encontrar erros ocultos.
Os testes ad hoc são também conhecidos como testes aleatórios e a imposição de uma estrutura pode impedir que estas verificações localizem erros.
5. Sem alterações a longo prazo
O objectivo dos testes ad-hoc é identificar quaisquer pontos fracos nos casos de teste da equipa; isto examina a sua estratégia global tanto quanto o próprio software.
No entanto, isto significa que os testes ad-hoc geralmente só são eficazes se a equipa utilizar esta informação para aperfeiçoar as suas verificações formais ao longo do tempo.
6. Conjuntos de dados incompatíveis
Praticamente todas as formas de teste requerem uma forma de dados simulados para avaliar como a aplicação responde; algumas ferramentas permitem que os testadores preencham automaticamente um programa com dados simulados.
No entanto, isto pode não reflectir a forma como um utilizador utilizaria o software – as verificações ad hoc requerem conjuntos de dados que o software provavelmente encontrará.
7. Silos de informação
É essencial que os testadores e os programadores estejam em constante comunicação uns com os outros, mesmo que estes últimos não façam parte do processo de testes ad-hoc.
Isto ajuda toda a gente a compreender quais os testes que foram realizados – mostrando as próximas acções a tomar, ao mesmo tempo que evita que os testadores repitam desnecessariamente certas verificações.
Tipos de resultados dos testes ad hoc
Os controlos ad-hoc produzem vários resultados distintos, incluindo:
1. Resultados dos testes
Os testes individuais produzem resultados diferentes, específicos para o componente exacto e a abordagem envolvida – que pode assumir muitas formas.
Normalmente, é da responsabilidade do testador determinar se os resultados constituem um erro, embora a falta de documentação torne difícil a comparação com as suas expectativas. A equipa transmite estes resultados aos programadores se detectar algum problema.
2. Registos de testes
O próprio software utiliza um sistema complicado de registos internos para monitorizar as entradas do utilizador e destacar uma série de problemas de ficheiros ou bases de dados que possam surgir.
Isto pode apontar para um erro interno, incluindo a parte específica do software que está a causar o problema. Com esta informação, os testadores ad-hoc e os programadores podem resolver os problemas que descobrem muito mais facilmente.
3. Mensagens de erro
Muitas verificações ad-hoc visam especificamente quebrar o software e expor os seus limites, o que significa que as mensagens de erro da aplicação são um dos resultados mais comuns destes testes.
Ao provocar deliberadamente mensagens de erro, a equipa pode mostrar o que o utilizador final médio vê sempre que as acções inesperadas que toma têm um efeito adverso no funcionamento do programa.
Exemplos de testes ad hoc
Eis três cenários de testes ad-hoc que mostram como uma equipa pode implementá-lo em diferentes aplicações:
1. Aplicação Web de comércio electrónico
Se uma empresa quiser testar uma aplicação Web baseada no comércio electrónico, pode utilizar testes ad-hoc – especificamente testes com macacos – para ver se a plataforma lida bem com interacções inesperadas dos utilizadores.
Os testadores podem tentar levar cada funcionalidade ao limite, por exemplo, adicionando artigos ao seu cesto em quantidades irrealistas ou tentando comprar produtos que não estão em stock. Não estão limitados pelos casos de teste da equipa e há poucos limites para as verificações que podem efectuar; os testadores podem até tentar concluir compras utilizando URLs desactualizados.
2. Aplicação de ambiente de trabalho
Os testadores ad-hoc também podem implementar estas técnicas para aplicações de ambiente de trabalho, com um possível enfoque em diferentes máquinas e na forma como cada uma delas se adapta ao programa.
Os membros da equipa podem efectuar estas verificações repetidamente para ver como a alteração das definições de hardware ou software afecta o desempenho geral de uma aplicação. Por exemplo, uma placa gráfica específica pode ter dificuldades em processar a interface.
Em alternativa, estes testadores podem simplesmente dar ao seu programa entradas impossíveis e ver como responde, por exemplo, se consegue apresentar correctamente mensagens de erro que expliquem adequadamente o problema ao utilizador final.
3. Aplicação móvel
Uma forma de os testadores ad-hoc examinarem uma aplicação móvel é testar os seus protocolos de segurança – podem tentar aceder directamente às ferramentas de desenvolvimento da aplicação, por exemplo.
A equipa pode tentar verificar se é capaz de executar acções não autorizadas, encontrando lacunas e explorações comuns; podem pedir especificamente aos membros da equipa com experiência em segurança de aplicações que facilitem esta tarefa.
Isto também pode implicar a realização de testes em pares com os programadores, devido à sua visão do design da aplicação, permitindo que um testador quebre o software e mostre exactamente onde falta a sua segurança.
Tipos de erros e bugs detectados
através de testes ad hoc
As verificações ad-hoc podem revelar muitos problemas com um programa, tais como:
1. Erros de funcionalidade
A utilização de testes ad-hoc para examinar as características básicas de uma aplicação pode revelar erros graves que afectam a forma como os utilizadores finais podem interagir com ela.
Por exemplo, um teste com macaco das opções de pagamento de um sítio de comércio electrónico ilustrará as condições que impedem a transacção.
2. Questões de desempenho
Os testadores podem trabalhar especificamente para criar problemas de desempenho no programa – por exemplo, enchendo a base de dados com várias entradas de spam.
Isto pode manifestar-se como um tempo de atraso significativo ou mesmo como uma instabilidade geral do software, o que conduzirá provavelmente a uma falha (potencialmente em todo o sistema).
3. Problemas de usabilidade
Estas verificações podem também detectar falhas na interface e na experiência geral do utilizador. A IU de uma aplicação móvel, por exemplo, pode ter uma apresentação diferente noutro sistema operativo ou resolução de ecrã. Uma interface deficiente pode levar a que os utilizadores tenham dificuldade em utilizar esta aplicação.
4. Falhas de segurança
A natureza aleatória dos testes ad-hoc permite-lhe abranger uma série de preocupações de segurança comuns e raras; um testador pode utilizar estas verificações para encontrar os backdoors administrativos de um programa.
Alternativamente, a sua inspecção pode mostrar que o software não tem encriptação de dados.
Métricas de testes ad-hoc comuns
Os testes ad-hoc utilizam várias métricas para facilitar os seus resultados, incluindo:
1. Eficiência na detecção de defeitos
Esta métrica analisa a eficácia do processo de teste na detecção de defeitos em cada forma de teste, incluindo testes ad-hoc. A eficiência da detecção de defeitos é a percentagem de defeitos detectados dividida pelo número total de problemas – mostrando a eficácia dos testes.
2. Taxa de cobertura dos ensaios
Uma função auxiliar dos testes ad-hoc é aumentar a cobertura, verificando os componentes de uma forma que os casos de teste não têm em conta. Isto significa que os testadores também terão como objectivo aumentar radicalmente a cobertura dos testes em cada verificação, tanto quanto possível.
3. Duração total do ensaio
Os testes ad-hoc são muito mais rápidos do que outros processos de garantia de qualidade – e é essencial que os testadores trabalhem para manter esta vantagem. As métricas de duração dos testes mostram aos membros da equipa como podem poupar tempo e aumentar ainda mais as vantagens das estratégias ad-hoc.
4. Taxa de colisão
Estes testes têm frequentemente como objectivo quebrar o software e provocar uma falha ou um erro grave – permitindo-lhes ir além das estratégias de teste típicas e encontrar problemas inesperados. Para o efeito, pode ser útil saber com que frequência o software falha e quais as causas desses problemas.
5 melhores ferramentas de teste ad hoc
Existem muitas ferramentas de teste gratuitas e pagas disponíveis para testes ad-hoc em testes de software – as cinco melhores são as seguintes:
1. ZAPTEST Free & Enterprise Edition
O ZAPTEST é um programa de teste de software abrangente que fornece um forte nível de funcionalidade de teste + RPA nas suas versões gratuita e empresarial.
Esta suite de automação de software de pilha completa + RPA permite a realização de testes completos em diferentes plataformas móveis e de ambiente de trabalho; a tecnologia 1SCRIPT do software também permite que os utilizadores executem as mesmas verificações repetidamente com facilidade. Para além disso, a ferramenta tira partido da visão computacional mais avançada, o que permite ao ZAPTEST executar testes ad-hoc a partir de uma perspectiva humana.
2. Pilha de navegadores
O BrowserStack é uma plataforma em nuvem que pode facilitar o teste em mais de 3.000 máquinas diferentes, com o recurso adicional de automatizar scripts Selenium. Embora ofereça uma forte cobertura para projectos de software, funciona melhor com aplicações móveis e de browser.
As soluções de teste BrowserStack também incluem uma avaliação gratuita com 100 minutos de testes automatizados, embora esta possa ter uma utilização limitada.
Embora a abordagem baseada na nuvem possa ser útil, também afecta negativamente o tempo de resposta da plataforma.
3. LambdaTest
O LambdaTest também utiliza tecnologia baseada na nuvem e coloca uma forte ênfase no teste do navegador, o que pode limitar a sua eficácia para outras aplicações – embora ainda se adapte bem a programas iOS e Android. Esta é uma plataforma útil quando a escalabilidade é uma preocupação e integra-se com muitos outros serviços de alojamento de testes.
No entanto, alguns utilizadores têm reacções contraditórias em relação ao preço da aplicação nas várias opções não experimentais disponíveis, o que pode limitar a acessibilidade das pequenas organizações.
4. TestRail
O TestRail é geralmente bastante adaptável devido ao facto de funcionar inteiramente no navegador e, apesar de se concentrar fortemente em casos de teste eficientes, também possui uma funcionalidade ad-hoc directa. A análise que fornece após cada teste também pode ajudar as equipas que evitam activamente fazer a sua própria documentação independente, permitindo-lhes ainda validar o seu processo de teste.
No entanto, os conjuntos maiores podem ter dificuldades com o seu formato baseado no browser, o que pode limitar significativamente as poupanças de tempo dos testes ad-hoc.
5. Zéfiro
O Zephyr é uma plataforma de gestão de testes da SmartBear que ajuda as equipas de garantia de qualidade a melhorar a visibilidade dos seus testes, ao mesmo tempo que se integra bem com outro software de rastreio de erros.
No entanto, esta funcionalidade está limitada a determinadas aplicações, sendo o Confluence e o Jira as que mais beneficiam do Zephyr – estas podem não ser as soluções mais eficazes para todas as empresas. Existem vários programas escaláveis disponíveis sob a marca Zephyr a preços diferentes.
Lista de verificação, dicas e truques para testes ad hoc
Eis algumas dicas adicionais que as equipas devem ter em conta quando realizam testes ad-hoc:
1. Dar prioridade aos componentes sensíveis
Algumas características ou componentes estão naturalmente mais expostos ao risco de erro do que outros, especialmente se forem importantes para o funcionamento geral do programa.
Todas as abordagens aos testes devem identificar as partes de uma aplicação que podem beneficiar de uma atenção mais aprofundada. Isto é especialmente útil quando o tempo total para os testes é limitado.
2. Investigar diferentes ferramentas de teste
A ferramenta que uma organização implementa para facilitar os seus testes pode afectar a cobertura e a fiabilidade destas verificações.
Com os testes ad-hoc, vale a pena analisar o maior número possível de programas para encontrar aqueles que se adequam ao seu aspecto centrado no utilizador. O software que utiliza tecnologia de visão por computador, como o ZAPTEST, pode abordar testes ad-hoc utilizando uma estratégia semelhante à humana.
3. Adoptar uma mentalidade ad-hoc
Os testes ad-hoc oferecem uma enorme liberdade ao longo da fase de garantia de qualidade, mas a equipa tem de se empenhar para obter os principais benefícios da estratégia.
Por exemplo, os testadores ad-hoc devem evitar todos os seus documentos habituais para além da tomada de notas básicas e devem inspeccionar o software de uma perspectiva totalmente nova.
4. Confiar nos instintos de teste
A experiência com testes ad-hoc ou verificações gerais de software pode ajudar a destacar pontos de falha comuns, o que ajuda os testadores a determinar como detectar erros de todos os tipos.
É vital que os testadores confiem nos seus instintos e utilizem sempre este conhecimento em seu proveito – podem intuir quais as verificações ad-hoc que serão mais úteis.
5. Registar integralmente os erros descobertos
Embora os testes ad-hoc não tenham documentação formal e se baseiem sobretudo em notas informais, é essencial que a equipa seja capaz de identificar e comunicar a causa de um erro de software.
Devem registar todas as informações que o teste forneça e que sejam relevantes para os programadores, tais como as potenciais causas destes problemas.
6. Ter sempre em conta o utilizador
Todas as formas de teste pretendem acomodar a experiência geral do utilizador até um certo ponto – e os testes ad-hoc não são excepção. Embora muitas vezes analisem mais profundamente o funcionamento interno da aplicação e até o seu código interno, os testadores ad-hoc devem tentar quebrar este software de formas que os utilizadores teoricamente poderiam.
7. Melhorar continuamente o processo
As equipas de testes devem aperfeiçoar a sua abordagem aos testes ad-hoc entre várias iterações do mesmo software e de um projecto para o outro.
Podem recolher feedback dos programadores para ver até que ponto os seus testes ad-hoc ajudaram a fase de garantia de qualidade e se conseguiram aumentar significativamente a cobertura dos testes.
Conclusão
Os testes ad-hoc podem ajudar organizações de todos os tipos a autenticar a sua estratégia de teste de software, mas a forma como implementam esta técnica pode ser um factor significativo na sua eficácia.
Equilibrar os diferentes tipos de testes é a chave para obter o máximo de benefícios das verificações ad-hoc – especialmente porque esta forma de teste pretende complementar as outras, preenchendo uma lacuna estratégica.
Com uma aplicação como o ZAPTEST, as equipas podem realizar testes ad-hoc com maior confiança ou flexibilidade, especialmente se implementarem a automatização. Independentemente da abordagem específica da equipa, o seu empenho nos testes ad-hoc pode revolucionar todo o programa ou projecto.
