Ambiente, técnicas, processo, análise de riscos – servirão de alicerce para o planejamento dos testes.
O documento básico do planejamento de testes é o PLANO DE TESTES.
No Plano de Testes define-se o nível de cobertura dos testes e a abordagem dos testes.
Plano de Teste deve ter como base os requisitos da aplicação e os requisitos de teste.
O Plano de Teste descreve como o teste deverá ser executado e traça uma linha mestra a ser seguida.
O Plano de Teste é um acordo formal entre testadores, desenvolvedores e usuários.
O teste de software é o processo que visa executar o software de maneira controlada, com o objetivo de avaliar seu comportamento de acordo com o que foi especificado.
A execução dos testes é considerada um tipo de VALIDAÇÃO.
Os testes caixa-preta cobrem as funcionalidades, mas não todo código do programa, portanto, é impossível testar completamente todo sistema e afirmar que ele está livre de defeitos.
Segundo a estimativa de Beizer, a média do número de defeitos em programas liberados para testes e de 1 a 3 a cada 100 instruções executáveis.
Verificação; Revisão, inspeção técnica
Análise de Riscos;
Testes exaustivos só são justificados em sistemas críticos em que a taxa de defeitos deve ser próximo de zero, levando em conta que testar exaustivamente um software aumenta substancialmente e custo do projeto de teste.
O planejamento estabelece o que vai ser testado, durante quanto tempo e quando os testes serão interrompidos.
A metodologia TMAP (Matin Pol, Teunissem e Veernendaal) definem um docuemto chamado Estrutura de Teste, elaborado antes do Plano de Teste.
QAI = Estrutura de Testes
A partir do momento que o teste passa a ser tratado como um projeto ou processo e não mais como uma etapa no processo de desenvolvimento, precisamos planejá-lo.
O Plano de Teste é uma maneira de documentar o projeto de teste.
O Plano de Teste permite que os testes sejam repetidos e controlados e define o nível de cobertura segundo o qual os elementos mais críticos do software serão testados com prioridade e com cobertura mais ampla. Por elementos críticos, consideramos aqueles classificados pela análise de riscos ou caracterizado pelo cliente.
O Plano de Teste é elaborado nos moldes do padrão definido pelo IEEE 829. Mas, nem o IEEE, nem o QAI falam sobre estimativas e métricas de teste em seus modelos.
O IEEE define a seguinte hierarquia entre os documentos de teste:
• Estrutura de Teste;
• Casos de Teste e
• Procedimentos de Teste.
2. Desenvolvimento do Plano de Teste
Escopo; O Escopo define exatamente a extensão do projeto de teste, até mesmo suas interfaces com outros softwares.
Custo; É preciso medir o tamanho do projeto de teste para saber quanto ele vai custar. Como métricas de teste temos: Análise de Pontos de Teste ou Pontos de Caso de Teste.
Tempo; A estimativa de tempo - , e, conseqüentemente, a elaboração do cronograma – está ligada diretamente ao tamanho do projeto, que por sua vez, servirá de base para o cálculo dos custos.
Qualidade; É acompanhada através de um programa de indicadores a ser implementado no decorrer do projeto.
Comunicação; A função dessa “atividade” é garantir a maneira como as partes envolvidas no projeto receberão as informações de que precisas para tomar decisões. Além disso, é necessário prever no projeto como e com que freqüência serão feitas as reuniões de controle. Relatórios de defeitos servirão de elemento de comunicação entre equipes de teste e de desenvolvimento.
Integração; Descrever a integração com os projetos de desenvolvimento e até mesmo com outros projetos de teste.
Recursos Humanos; Definição de recursos humanos envolvidos em cada etapa do projeto. Definir funções e responsabilidades.
Riscos; O projeto de teste implica seus riscos específicos. Não misturar os riscos do projeto de teste com os riscos do negócio.
Suprimentos; Aquisição de software e ferramentas.
3. Significado do Plano de Teste
Segundo o QAI, o Plano de teste toma aproximadamente um terço do projeto de teste.
Problemas levantados pelo QAI que podem afetar um projeto de testes/plano de teste:
• Falta de treinamento; a equipe independente de testes de vê conhecer o processo de teste, seu ciclo de vida, metodologia usada e também técnicas específicas de teste.
• Desenvolvedores versus testadores; Os desenvolvedores não gostam que outras pessoas apontem seus erros, e os testadores tendem a apontar esses erros de maneira sarcástica. Brigas internas são ruins para o sucesso do projeto.
• Falta de ferramenta de teste; realizar testes de regressão manualmente.
• Falta de apoio da gerência; Além do suporte financeiro, algumas decisões não podem ser tomadas por técnicos.
• Falta de envolvimento dos usuários e dos clientes; Os usuários e clientes precisam estar envolvidos no projeto de teste, inclusive na elaboração do Plano de Teste.
• Falta de tempo para testar; Os desenvolvedores esgotam o prazo e transferem a pressão para a equipe de teste.
• Quem testa é a equipe de testa; por existir uma equipe de teste independente, os desenvolvedores não se preocupam em realizar os testes unitários e de integração ou o fazem de maneira incipiente.
• Alterações rápidas; O uso de ferramentas RAD que geram alterações rápidas e que nem sempre é possível testar com a mesma agilidade. Fazer uso de ferramentas.
• Os testadores são sempre os culpados; Quando os testadores acham muitos defeitos os desenvolvedores reclamam se deixam passar defeitos sérios também há reclamações.
• Os testadores precisam aprender a dizer não;
4. Tarefas para construir um Plano de Teste
- Montar a equipe de teste;
- Testar usando a equipe de desenvolvimento como equipe de teste
- Testar usando equipes independentes de teste e
- Testar usando equipes de não-especialistas em TI.
- Entender os riscos do Projeto;
- Procure entender o que significam os objetivos do projeto
- Entenda as áreas-chave e os processos-chave do negócio
- Identifique o grau de severidade das potenciais falhas
- Identifique os componentes do sistema
- Identifique, priorize e estime com precisão os recursos necessários para a execução do projeto
- Fases de teste
- Defina os requisitos de seu ambiente de teste
- Identifique as ferramentas necessárias
- Avalie os planos de contingência do plano do projeto
- Avalie outras vulnerabilidades fora da área de TI
- Construir o Plano de Teste;
- Estabelecer os objetivos do teste
- Desenvolver os roteiros de teste
- Definir a administração do teste e
- Escrever o plano de teste.
- Informações gerais
- Plano,
- Especificações e avaliação
- Descrição dos testes.
5. Atividades pós-plano
Quando se trata de teste, é muito importante que: todos os artefatos gerados durante projeto de teste sejam supervisionados por um gerenciamento de configuração.
Entre os artefatos de teste que devem estar sob os cuidados do gerenciamento de configuração, listamos:
• Plano de teste;
• Requisitos de teste;
• Script de teste e
• Outros artefatos usados nos testes.
O objetivo maior dos testes é reduzir a probabilidade de ocorrência de defeitos quando o sistema ou software estiver em produção.
A Estratégia de Teste, quando empregada, deve ser escrita antes do Plano de Teste.
A Estratégia de Teste é composta por Fatores de Teste e Fases de teste.
Fatores de teste; São os riscos que precisam ser tratados através da Estratégia de teste. Em resumo, podemos dizer que os riscos associados aos testes são chamados Fatores de Teste. Mas nem todos os fatores de teste são transformados necessariamente em risco.
Fases de teste; São as fases do desenvolvimento do software nas quais o teste será executado.
Como podemos ver, o que foi chamado anteriormente de fatores de teste poderia guardar semelhança com as características de qualidade, embora não façam parte da norma ISO 9126-1.
Características de qualidade segundo a norma ISO 9126-1
2. Confiabilidade;
3. Usabilidade;
4. Eficiência;
5. Manutenibilidade e
6. Portabilidade.
Um método de montar a estratégia de teste é associar o risco a uma característica ou sub-característica de qualidade da norma ISO 9126.
O importante dos riscos é definir a probabilidade de sua ocorrência e sua severidade em relação ao negócio.
Na formulação da estratégia de testes devem ser levados em consideração diversos fatores, tais como o porte e importância do software, os seu requisitos, os prazos estabelecidos, riscos do negócio e os custos envolvidos.
Uma estratégia de teste deve, portanto incluir:
• Estágios ou níveis de teste a serem abordados (unitário, integração, sistema e aceitação);
• Fase do desenvolvimento em que se aplica o referido teste;
• Os tipos de teste que devem ser executados (funcional, desempenho, carga, estresse etc.)
• As técnicas e ferramentas a serem empregadas no teste (funcionais ou estruturais) e
• Os critérios de conclusão com êxito do teste que serão aplicados.
Exemplo: Critérios podem permitir que o software evolua para o teste de aceitação quando 95% dos casos de teste estiverem sido executados com êxito.
2. Tipos de Teste. (o que testar?) – Teste de performance, Teste de carga ...
3. Técnica de Teste. (como testar?) – Estrutural ou Funcional.
É o processo que assegura o funcionamento correto de alguns aspectos ou de uma unidade do software. Segundo a norma IEEE 610.12-1990, as técnicas são procedimentos técnicos e gerenciais que ajudam a avaliação e melhoria do processo.
A técnica de teste Funcional garante que os requisitos especificados foram devidamente cumpridos pelo sistema. Valida se o que foi especificado foi implementado de modo correto. A preocupação funcional não é COMO o processo ocorre, e sim QUAIS SÃO os resultados do processo.
O teste funcional é realizado para assegurar que as especificações e os requisitos do software foram atendidos.
• Teste de regressão;
• Teste de erro de manuseio (usabilidade);
• Teste de suporte manual;
• Teste de integração;
• Teste de controle e
• Teste paralelo.
A técnica de teste Estrutural garante que a implementação de uma funcionalidade foram devidamente testada em sua totalidade. O objetivo do teste estrutural é acessar a implementação, de modo a gerar uma massa de teste que force a cobertura de toda a estrutura presente na implementação da aplicação, garantindo que a estrutura do produto desenvolvido funcione corretamente.
Os testes estruturais foram criados para verificar se o sistema desenvolvido e os programas funcionam. A técnica não determina o funcionamento correto da aplicação, e sim da estrutura.
• Teste de execução;
• Teste de contingência ou recuperação;
• Teste de operação;
• Teste de conformidade; (processo)
• Teste de segurança.
Os testes estrutural e funcional, podem ser realizados com o emprego de um conjunto pré-determinado de técnicas. Selecionada a técnica, é preciso determinar um método de teste para implementá-la, que pode ser dinâmico ou estático. As técnicas dinâmicas determinam se o sistema funciona corretamente quando está rodando, e o teste estático “olha” para o sistema quando este não é executado.
A análise dinâmica requer que o programa seja executado.
A análise estática, por outro lado, não envolve a execução do programa. Entre as técnicas comuns de análise estática temos as tarefas que verificam a sintaxe.
Uma ferramenta é um veículo para executar um processo de teste, é um recurso para o testador, mas sozinha, é insuficiente para a condução de um teste.
É uma das dimensões do teste que representa o “quando”, ou melhor, a que fase do desenvolvimento se aplica determinado teste.
Teste de unidade; Costuma ser feito pelo programador e testa as unidades individuais: funções, objetos e componentes.
Teste de iteração ou integração; Em geral, é realizado pelo analista de sistemas para um módulo ou conjunto de programas.
Teste de Sistema; Costuma se feito pelo analista de teste (caso de teste) em ambiente de teste.
Teste de aceitação; Sua execução é de responsabilidade do cliente. Em geral é feito pelo usuário em ambiente de homologação.
Resumo Livro BCTS: Capítulo 2 – Processo de teste
Resumo Livro BCTS: Capítulo 4 – Análise de Riscos
I like!
ResponderExcluirI like!
ResponderExcluir