**
O processo de teste consiste em:
-- Planejar e Acompanhar
-- Analisar e Projetar
-- Implementar e Executar
-- Avaliar critérios de saída e reportar resultados do teste
-- Atividades de fechamento de teste
O foco do livro é dado nas 3 atividades do meio.
Análise e Projeto de Teste
Nas atividades de planejamento, o líder de teste e o gerente de teste trabalham junto aos stakeholders na definição dos objetivos de teste. No template IEEE 829, essa informação fica documentada em “Features to be tested”.
Um pouco mais sobre documentação e norma IEEE 829 em:
- Sem Bugs – Como documentar seus testes
- ANSI/IEEE 829-1983 IEEE Standard for Software Test Documentation –Description
A partir dos objetivos de teste, na fase de análise e projeto, são desenvolvidas as atividades de:
-- Identificar e refinar as condições de teste para cada objetivo de teste
-- Criar casos de teste que exercitem as condições de teste identificadas
Saber o que testar, ainda não é suficiente. É preciso saber em que ordem e o quanto. Para que as áreas mais importantes sejam testadas primeiramente e o esforço de teste seja mais efetivo e eficiente, é preciso priorizar as condições de teste.
Essa definição de prioridades normalmente envolve a determinação do impacto e da probabilidade de um risco de qualidade (Conceito aplicado em estratégia baseada em risco – que fica pra outro post).
Durante o processo, as condições de teste e o risco associado a elas pode mudar conforme as necessidades (ou entendimento das necessidades) do projeto. Essas atividades de priorização e re-priorização ocorrem durante todo o ciclo, da análise e projeto, à implementação e execução, e influencia na avaliação dos critérios de saída e report de resultados.
Objetivos de testes funcionais
Objetivos de teste funcionais podem ser aplicados durante todo o ciclo, em qualquer nível de teste. É importante testar os principais objetivos de teste primeiro para não se deparar com falhas muito graves ao final da execução.
No livro há um exemplo de um vídeo game e a funcionalidade de salvar e resumir o jogo. Um exemplo que eu gosto de usar é o de um telefone celular. Qualquer aplicação para celular deve ser capaz de tratar uma ligação. Ele deve ser interrompido para que o usuário receba a ligação e deve continuar após o término da ligação. Receber uma ligação é a funcionalidade principal do telefone (mesmo que hoje em dia eles praticamente cozinhem pra você), e quem está ligando não pode receber uma mensagem de indisponibilidade porque você está consultando sua agenda, ou porque está jogando, ou usando a calculadora. Esse é um teste que deve estar nos testes unitários, de integração, de sistema e de aceitação. Todos dando uma especial atenção a esse objetivo de teste. Lembrando que o teste começa ainda antes, na revisão de requisitos, de projeto e de código.
Posteriormente no livro é detalhada a estratégia baseada em riscos. Se você não está usando essa estratégia, você necessitará selecionar as entradas e técnicas de acordo com a estratégia utilizada, que claro, deve estar alinhada com o plano de teste, com as políticas de teste, etc.
Há duas escolhas importantes no processo de identificar e documentar as condições de teste:
- O nível de detalhamento das condições de teste na documentação
- A estrutura da documentação para as condições de teste
Há várias maneiras de se estruturar as condições de testes. Uma delas pode ser um paralelismo com a documentação base. Por exemplo, se a sua empresa trabalha com requisitos de marketing e especificações de requisitos, entende-se usualmente que o primeiro é uma descrição alto nível e o segundo, baixo nível. Assim, com base nesses documentos, você pode criar uma estrutura de condições de teste alto nível e uma em baixo nível equivalentemente.
Outra abordagem envolve a análise dos riscos de qualidade, identificando esses riscos para cada funcionalidade e assim temos as condições de teste.
O importante é que o nível de detalhamento deve estar alinhado com a estratégia de testes, que deve estar alinhada com o plano, que está alinhado com as políticas,...
Aproveite para criar a rastreabilidade nesse momento. É sempre mais fácil do que tentar criá-la numa abordagem bottom-up.
Tendo as condições de teste documentadas, o próximo passo é, normalmente, escrever os casos de teste. Há estratégias reativas discutidas no syllabus Foundation que nem sempre têm casos de teste documentados. Esses testes serão escritos utilizando técnicas que serão abordadas posteriormente.
Para os casos de teste, também deverá ser selecionado um nível e uma estrutura que deve ter todo o alinhamento já mencionado acima.
O processo de design depende agora das técnicas selecionadas para o projeto do caso de teste, mas em linhas gerais pode-se dizer que ele contém:
- Pré-condições
- Requisitos de ambiente
- Entradas de teste e outros requisitos de dados para o teste
- Resultados esperados
- Pós-condições
Definir os resultados esperados pode não ser tão trivial, especialmente considerando que esses resultados nem sempre são saídas na tela, mas condições de dados ou de ambiente. Para acuracidade dessa definição usamos o oráculo de teste.
Oráculo de teste
É a fonte que usamos para determinar o resultado esperado de um teste. Podem ser requisitos, um manual, um especialista,... Só não pode ser o código, ou a validade do teste estará comprometida. Seria o mesmo que testar o compilador.
Agora se você está achando que esse oráculo é uma especificação detalhada de testes, para a qual os resultados podem ser perfeitamente mapeáveis, isso é quase uma utopia. Normalmente essas fontes são superficiais, vagas, ambíguas e no caso de mais uma fonte, às vezes contraditórias. É preciso acrescer a elas experiência e um pouco de pessimismo profissional. Isso não acontece apenas no nível de sistema, mas em todos os outros níveis de teste.
Quem nunca teve a experiência de brincar de ping-pong com um bug? Vai pro teste, vai pro dev, vai pro teste, vai pro dev,... Isso decorre muitas vezes da ausência de um oráculo estável e confiável.
Padrões
Especificação de design de teste da IEEE 829:
Nele é descrita uma coleção de casos de teste e as condições de teste que ele cobre num alto nível. Inclui as seguintes seções:
- Identificador da especificação de teste
- Funcionalidades que serão testadas
- Refinamento de abordagem (técnicas específicas, ferramentas, etc)
- Identificação do teste
- Critério de validação (como determinar se a funcionalidade passou ou não no teste)
Essa coleção de testes descrita na especificação de design é também chamada de suíte de teste.
Especificação de casos de teste IEEE 829:
Detalha o caso de teste. Inclui as seguintes seções:
- Identificador da especificação de teste
- Itens de teste (o que vai ser entregue e testado)
- Especificações de entrada (arquivos, entradas do usuário, etc)
- Especificações de saída (resultados esperados, telas, arquivos, etc)
- Requisitos de ambiente (software, hardware, pessoal, etc)
- Requisitos procedurais especiais (permissões, intervenção do operador, etc)
- Dependência entre casos (se necessário para definir as pré-condições)
Casos de teste variam em esforço, duração, número de condições cobertas e podem ser escritos de maneiras diferentes.
ISO 9126:
Esse padrão determina seis características de qualidade de software: funcionalidade, confiabilidade, usabilidade, eficiência, manutenabilidade e portabilidade. Cada característica tem 3 ou mais sub-características. Vide figura abaixo.
O foco da certificação é na funcionalidade, os demais são considerados testes não funcionais, mas alguma dessas características pode sim vir a intervir no teste funcional.
Testes estáticos
São as inspeções, revisões. Todos conhecem a clássica curva de custo de detecção de um defeito ao longo das fases do projeto, certo? Tem um post do Fernando Palma sobre o assunto com uma figurinha do custo da não qualidade.
Fazer a análise e o projeto de teste em cima de uma especificação pode ser a própria revisão.
Métricas
Nessa parte do processo é possível medir:
- percentual de requisitos cobertos pelas condições de teste
- percentual de condições de teste cobertas pelos casos de teste
- número de defeitos encontrados na fase de análise e projeto de teste
Próximo post CTAL-related será sobre Implementação e Execução, continuando o fluxo do processo de teste.
Glossário de termos usados
Nenhum comentário:
Postar um comentário