Por Matthew Heusser
Uma maneira de olhar para um plano de teste é como uma coleção de gerenciamento de trabalho de riscos. O checklist que apresentamos a seguir fornece ideias sobre quais podem ser esses riscos e como lidar com eles, juntamente com o que chamar de fora do escopo. O objetivo é cobrir o suficiente, equilibrando as principais questões com base em avaliações de especialistas com décadas de experiência. Vamos lá?
Abordagens a serem consideradas para o projeto de teste
Lista de recursos: Crie uma lista de recursos e transforme os recursos em casos de teste. Às vezes chamado de matriz de rastreabilidade, isso pode mostrar falhas na cobertura e até recursos que não precisam de mais trabalho.
Mapa da jornada do usuário: Em vez de listar recursos, considere todo um fluxo de comportamento do usuário, do check-in ao check-out. Um termo comum do e-commerce para isso é “o caminho para a compra”. Alguns recursos que não aparecem em nenhuma jornada do usuário podem garantir menos testes e menos desenvolvimento futuro, especialmente se não forem populares nos logs.
Log Mining: Organize as entradas de log por recurso e classifique para encontrar os recursos mais usados; concentre o tempo de projeto de teste nesses recursos principais.
Condições de exceção: Estes são testes para quando as coisas dão errado: o banco de dados está inativo, o site é recusado, a API não retorna por tanto tempo que o navegador expira. Ataques rápidos podem se sobrepor a esta categoria.
SFDIPOT – “San Francisco Depot”: o mnemônico significa estrutura, função, dados, interfaces, plataforma, operações e tempo (em inglês). Um exercício possível para o planejamento de testes é listá-los e, em seguida, criar subnotas para os riscos relacionados a esses elementos do software. Depois de concluído, revise essa lista de riscos com o plano de teste até o momento para garantir que esses riscos sejam cobertos. Em um programa grande, pode haver um diagrama SFDIPOT por recurso principal ou subsistema.
Outras estratégias de teste heurístico: A Estratégia de Teste Heurístico de James Bach, que definiu o SFDIPOT, é um tesouro de considerações para entender a missão do teste, a meta do produto e os objetivos de qualidade. Use-o para criar abordagens de teste totalmente novas e, em seguida, revise o plano para ver se elas estão incluídas.
Testes baseados em domínio: Onde ataques rápidos e exceções não requerem conhecimento do software, uma abordagem de domínio reconhece as diferentes condições potenciais e tenta encontrar testes relevantes e poderosos para tantas condições que façam sentido. O teste de domínio requer uma análise cuidadosa dos requisitos; as tabelas de decisão são um exemplo de teste baseado em domínio. Simplificando, quando os requisitos criam uma “parede de texto” que implica mais de uma dúzia de ideias de teste, considere a visualização como uma etapa intermediária antes de finalizar o plano de teste.
Uma árvore de decisão da qual os casos de teste detalhados podem derivar
RRCRC: Esse mnemônico desenvolvido por Karen Johnson significa recente, central, arriscado, sensível à configuração, reparado e crônico. A consideração desses elementos pode permitir que a equipe encontre as áreas de maior prioridade para reteste, especialmente para regressão.
Planejamento
Risco e prioridade: Defender risco, impacto e prioridade permite que os testadores testem primeiro as peças mais importantes. Isso pode fornecer informações cruciais para os programadores e realmente acelerar a entrega. Da mesma forma, se o projeto estiver sob alguma pressão de cronograma, um plano detalhado cria um dilema: os testes do projeto devem estar atrasados ou os testes devem estar incompletos? Planos que fornecem prioridade permitem que as equipes tomem essa decisão de forma mais educada, com menos risco na mesa.
Estrutura: O plano de teste deve abordar quem fará o teste em quais locais e como esse trabalho será rastreado. Se for rastreado em uma ferramenta de rastreamento eletrônico e as pessoas se inscreverem para trabalhar de forma auto-organizada, tudo bem; apenas documente. Se a equipe sempre usa a mesma abordagem e os documentos do projeto são repetitivos, considere criar padrões para a equipe, para que os planos só precisem abordar o que é diferente. A estrutura também pode incluir como o trabalho é dividido – por recurso, risco, carta, história, em uma planilha, em uma ferramenta de gerenciamento de casos de teste ou por algum outro mecanismo.
Criatividade humana: Um plano de teste deve detalhar o nível de criatividade que os testadores executarão. Isso pode variar de acordo com o nível de habilidade e o recurso do testador. Por exemplo, um plano de teste pode exigir que cada recurso seja testado de maneira precisa, mas documentar apenas a jornada do usuário em alto nível, alocando um timebox de duas horas para os testadores testarem cada fluxo principal. O continuum de testes exploratórios de James Bach (usado com permissão) visualiza essa diferença:
Comunicando: A forma como as pessoas demonstrarão progresso ou bloqueios pode retardar ou possivelmente acelerar o projeto. Algumas ferramentas modernas atualizam automaticamente as páginas da Web à medida que as pessoas realizam seu trabalho. Os relatórios devem incluir quais métricas são relatadas e quando.
Tempo: Um plano implica algum aspecto de quando as coisas vão acontecer. Isso inclui atividades em torno do desenvolvimento de um recurso e logo antes de um lançamento, que pode ser qualquer coisa, desde testes de “shakedown” até uma regressão detalhada de todo o sistema.
Ferramental e automação: Quais riscos serão cobertos pela automação e quais riscos serão medidos manualmente? Responder a essas perguntas pode incluir considerações sobre CI/CD, equipe, recursos e restrições de tempo, e pode orientar as pessoas a decidir onde injetar ferramentas e automação.
Interagindo com outros papéis: Tradicionalmente, o teste do desenvolvedor e o teste de unidade não são incluídos no planejamento de teste, mas as ferramentas modernas de gerenciamento de casos de teste podem tornar isso visível. Como os bugs são relatados, tratados, entregues e assim por diante deve estar em um plano de teste ou padrão de equipe.
Veja também: O que é Monitoramento Contínuo em DevOps?
Testes além de recursos
Acessibilidade: Pode ser fácil não planejar recursos para pessoas que precisam de ajuda para usar os dispositivos. Ter uma lista de verificação de planejamento de teste pode ajudar a nos lembrar de garantir que cada imagem tenha um texto descritivo ou seja possível ler e usar um site com apenas um teclado. Adicionar essa funcionalidade tenderá a tornar o software mais fácil de automatizar e navegar também.
Internacionalização e localização: Se o software precisar oferecer suporte a outros idiomas, isso é algo a ser testado. Mesmo que o software seja somente em inglês, se os nomes estiverem armazenados, você poderá encontrar caracteres em outros idiomas facilmente. O teste para eles pode ser feito em cinco minutos – se alguém listar o teste no plano.
Segurança: Verificação de código, verificação de vulnerabilidade e teste de penetração são três considerações para qualquer site moderno.
Desempenho e carga: Os usuários modernos esperam um carregamento de página em dois segundos, mesmo que sejam uma das milhares de pessoas que usam o software. É difícil pensar nisso como um teste “não funcional” se o software não funcionar sob carga.
Usabilidade: Muitos de nós vimos um software que atendeu a todos os requisitos, mas era tão doloroso de usar que o rejeitamos. Se os testadores tiverem poderes para fornecer esse feedback, esse aspecto deve ser documentado no plano de teste.
Finalmente, não esqueça o que você esqueceu
Desconhecidas conhecidas: Dependências externas que podem não funcionar, padrões que estão mudando, sistemas que não estão documentados e outras coisas podem dar problemas durante a noite. Se você listar esses riscos no plano, pelo menos poderá iniciar uma conversa – mesmo que não tenha planos para eles.
Fora do escopo: É comum que um plano de teste veja segurança, usabilidade, acessibilidade e até mesmo teste de carga como “fora do escopo”. Se o plano não tiver prioridade, uma resposta à pressão do cronograma quando defeitos excessivos atrasam o projeto pode estar fora do escopo do plano. Torná-los explícitos no plano permite que a administração assuma esses riscos intencionalmente ou certifique-se de que eles sejam contabilizados de outras maneiras.
Baixe aqui a planilha The Ultimate Software Test Planning Checklist para ajudá-lo a identificar riscos, aprender como lidar com eles corretamente e, finalmente, decidir se os elementos da lista de verificação estão “feitos”, “não feitos”, “fora do escopo” ou “irrelevantes”.
Matthew Heusser é o diretor administrativo da Excelon Development, com experiência em gerenciamento de projetos, desenvolvimento, redação e melhoria de sistemas. E sim, ele também faz testes de software.
Fonte: Gurock|TestRail
