4ª Parte Processo de Teste

Transcrição

1 4ª Parte Processo de Teste Atividades de preparação Ø Planejamento: define itens a testar, aspectos gerenciais e recursos necessários; para a execução da bateria de testes. Ø Desenho: completa as especificações dos testes da bateria; procedimentos e casos de teste. Atividades de realização Ø Implementação: monta o ambiente de teste; implementando os componentes de teste; instalando e configurando os itens a testar. Ø Execução: executa os testes da bateria; produzindo os relatórios resultantes. Atividades de realização. Ø Verificação do término: inspeciona os testes; determinando se estão satisfeitas condições de completeza e sucesso. Ø Balanço final: realiza o balanço final dos testes da bateria; registrando as conclusões e lições aprendidas. Planejamento Ø Definir escopo O que será e o que não será testado? Ø Definir recursos Equipamentos, treinamentos, pessoal, software, componentes Ø Definir prazos Quando inicia? Quando termina? Quantas horas de dedicação? Planejamento Ø Definir abordagem Quais tipos de teste serão executados? Usabilidade? Segurança? Desempenho? Funcional? Ø Definir critérios de cobertura Quando parar? Ø Definir mecanismos de registro e acompanhamento Como registrar erros? Como registrar tarefas? Como acompanhar status da execução? Ø Identificar e acompanhar riscos Que problemas podem acontecer? Qual o impacto? Qual a probabilidade? Quais as contramedidas? 1

2 Criação de um Plano de Teste Desenho da bateria de testes tarefas. Ø Desenhar a bateria de testes, estabelecendo: objetivos dos testes; reutilização de especificações de testes existentes; ordenamento dos casos de teste. Ø Especificar os procedimentos de teste. Ø Especificar os casos de teste. Ø Revisar informalmente as especificações dos testes. Especificações de testes: Ø contêm os detalhes dos testes a serem realizados; Ø separação entre planos e especificações permite reaproveitamento das especificações: diversas baterias do mesmo projeto; Ø especificação de teste tipicamente deriva de: caso de uso de desenho; requisito não-funcional referente ao produto como um todo. Volume das especificações de testes: Ø especificações de testes geralmente ocupam várias páginas: para cada caso de uso; Ø Descrição dos Testes pode chegar a dezenas ou centenas de páginas: mesmo em produtos relativamente simples. Procedimentos de teste: Ø contêm seqüência de ações que devem ser executadas; para realizar grupo de testes semelhantes; Ø correspondem a roteiros importantes de casos de uso de desenho; Ø pode ser executados de forma manual ou automática; Ø testes automatizados podem ser codificados: em linguagem de script de ferramenta de automação de testes; na própria linguagem de implementação, dentro de pacote de classes de teste. Procedimentos de teste: Ø descrevem seqüência de passos para executar uma variação de teste; nos testes funcionais, cada variação é tipicamente baseada nos subfluxos e fluxos alternativos do caso de uso de desenho; convém prever execução de seqüências erradas mas possíveis; Ø fluxo do procedimento representa passos executados; por testador humano ou automatizado; em termos das telas, campos e comandos envolvidos; valores dos campos determinados por cada caso de teste 2

3 Procedimentos de teste: Identificação Objetivo Requisitos especiais MERCI-ETF-GU-PT-IU Verificar se a inclusão de um usuário é feita corretamente. Nenhum. Fluxo 1. Acionar Novo. 2. Preencher Nome, Login, Senha. 3. Selecionar Grupos do Usuário. 4. Acionar Salvar. Casos de teste: Ø contêm para cada instância de teste: valores de entradas; valores esperados de saídas; Ø valores de entrada escolhidos: critérios que maximizam a cobertura do teste; Ø também podem ser automatizados; podem ser embutidos em scripts ou classes de teste; como os procedimentos; podem ser obtidos de arquivos ou bancos de dados de casos de teste. Qualidade de casos de teste: Ø objetivo principal: detectar defeitos ainda não descobertos; e não demonstrar que o programa funciona corretamente; Ø devem incluir: descrição das saídas esperadas; usada para comparação com as saídas reais obtidas; Qualidade de casos de teste: Ø devem cobrir: entradas válidas; entradas inválidas; combinações de entrada relevantes; execução de procedimentos errados mas possíveis; Ø devem exercitar: roteiros mais prováveis; roteiros correspondentes a situações excepcionais e a erros do usuário. Ordem de casos de teste: Ø casos de teste têm ordem especificada de execução; Ø execução correta de um caso pode depender de um estado de uma base de dados; Ø produzido pela execução bem-sucedida de um caso anterior. Exemplo de Caso de Teste Identificação Itens a testar Entradas MERCI-ETF-GU-CT-AU1 Processamento correto de alteração de usuário. Nome Login Senha Grupos do Usuário Campo Campo Joaquim Pereira joaquim senha01 Gestor de Compras Valor Valor Saídas esperadas Nome Joaquim Pereira Senha senha01 (oculto como *******) Grupos do Usuário Gestor de Compras Ambiente Banco de dados de teste. Procedimentos 1. Inclusão de Usuário - MERCI-ETF-GU-PT-AU 2. Pesquisa de Usuário - MERCI-ETF-GU-PT-PU Dependências Banco de dados de teste deve ter um usuário com o login dado. Por exemplo, pode ter sido executado o caso de teste Inclusão de usuário 1 (MERCI-ETF-GU-CT-IU1). 3

4 Criação dos Procedimentos e Casos de Teste Implementação dos testes tarefas. Ø Configurar ambiente de testes. Ø Disponibilizar todos os recursos necessários. Ø Instalar: itens a testar; ferramentas; estruturas provisórias. Ø Codificar componentes de teste; se necessário. Implementação dos testes: Ø testes implementados devem ser automatizados; Ø cria-se Bateria de Testes de Regressão de Software: script de ferramenta de automação de testes; pacotes de classes de teste; Ø especificações dos testes: servem como insumo para a codificação da Bateria; Ø testadores experientes: podem preferir desenhar e implementar diretamente a bateria; sem especificações de testes manuais. Implementação dos Testes Como tornar a atividade de teste mais eficiente? Ø Questões similares tendem a surgir durante o desenvolvimento de software. O reuso de soluções e alternativas já utilizadas para os testes tende a reduzir esforço e gerar mais qualidade Idealmente, deveriam ser definidos modelos de testes, para auxiliar nessas tarefas Padrões de Teste! Implementação dos testes O que é um padrão? Ø Christopher Alexander Catálogos de padrões para arquitetura de cidades, casas e prédios. Ø Descreve um problema que ocorre inúmeras vezes em determinado contexto Ø Núcleo da solução para aquele problema Visando uso sistemático em distintas situações Implementação dos testes Conceito Ø solução, aplicável em várias situações, para um problema conhecido de teste de software Qualquer tipo de boa prática, princípio abstrato ou heurística não é necessariamente um padrão! 4

5 Implementação dos testes Padrões importantes Ø Factory Ø Builder Ø Object Mother (Populator) Ø Test Procedure Ø Test Case Implementação dos testes Padrões importantes Implementação dos Testes Execução dos testes Ø Configurar ambiente de execução contínuo Ø Continuum, Hudson Ø Política para atualização de repositório Execução dos Testes Relatórios dos testes: Ø folhas de Registros de Testes: registram passos relevantes da execução; alguns passos podem gerar incidentes; Ø folhas de Relatórios de Incidentes de Testes: encaminhados à equipe de Implementação; para correção dos defeitos encontrados. Ø incidentes também podem gerar: solicitações de correção do desenho; solicitações de correção dos próprios testes. 5

6 Relatórios dos testes: Ø Idealmente, uma ferramenta de registro e acompanhamento de BUGs deveria ser utilizada ü Motivação Manter um banco de dados de bugs é uma das características imprescindíveis de qualquer boa equipe de software Ø Rastrear erros conhecidos Ø Documentar e acompanhar o processo de correção de erros de forma automática Ø Facilitar a comunicação entre equipes de testes e implementação Erro grave: Ø Programadores acreditam que podem lembrar de todos os seus bugs, ou mantê-los em post-its. ü Exemplo Ilustrativo Histórico Mikey estava desenvolvendo algumas funcionalidades extras para um cliente de FTP e criou uma função para copiar strings sem reusar as funções já existentes. Ele esqueceu de colocar o null no final da string. Jill estava testando o software e de repente o servidor de ftp travou. Ela então reproduziu os passos para verificar se isso se repetia, utilizando outra máquina. Acontece novamente. Ela então anota uma lista de passos para reproduzir o problema. A partir disso ela cria o bug. ü Registro de Bugs Elementos fundamentais Ø Passos para sua reprodução As vezes, o testador não lembra, ou o bug é intermitente Ø Resultados esperados Pode ser difícil entender por que é um bug se não sabemos qual era o resultado esperado Ø Resultados obtidos Parece fácil? Ø Muitos bugs são relatados de forma incorreta ü Exemplo Ilustrativo Histórico Willie acredita que o bug está no servidor de ftp, assim, resolve que ele não será corridigo. Jill acha muito estranho que um servidor usado há anos apresente tal problema e reativa o bug. Willie então analisa a explicação de Jill e repassa o bug para Mikey. Mikey estuda o bug e faz um diagnóstico completamente errado, colocando bug como corrigido. O bug retorna então para Jill. ü O Ciclo de Vida de um Bug Durante sua vida, o bug deve ter apenas um responsável Ø Funciona como uma batata quente! Qualquer um pode resolvê-lo Idealmente, após a solução de um bug, os passos para sua reprodução deveriam ser verificados Apenas quem abriu o bug pode fechá-lo! 6

7 ü Exemplo Ilustrativo Histórico Jill reproduz os passos do bug e o encontra novamente. Ela reativa o bug passando-o diretamente para Mikey. Mikey estuda o bug profundamente e descobre a causa, corrigindo o problema. Ele então coloca o bug como corrigido. O bug retorna então para Jill que verifica a correção e fecha o bug. ü Dicas de Uso Reduzir ao máximo o número de passos para reprodução do bug Apenas quem abriu o bug pode fechá-lo Há muitas maneiras de se resolver um bug: Ø corrigido, não será corrigido, postergado, não reproduzível, duplicado, etc. Ø Entenda cada um desses tipos de solução e oriente a sua equipe Não Reproduzível = irreprodutível Ø Ponto negativo para a equipe de teste Bugs devem estar associados a versões do software Ø Evita retrabalho em desenvolvimentos iterativos com equipes Relatório de Testes Verificação do término Ø Analisar atendimento aos critérios Balanço final Ø Registro das ações aprendidas para auxiliar projetos futuros Uso de uma ferramenta em especial Adequação de uma técnica de teste Dificuldade em se verificar algum objetivo Ø Perguntas associadas: O que foi feito e não deveria mais ser feito O que não foi feito mas deveria ser feito O que foi feito e e deveria continuar sendo feito BSTQB Ø Brazilian Software Testing Qualification Board ( Ø Certified Tester Foundation Level CTFL 40 questões, 60% para aprovação Ø Certified Tester Advanced Level CTAL 100 pontos, 65% para aprovação 2 anos de experiência com teste ou pesquisa acadêmica 3 anos trabalhando com desenvovlmento de software 7

8 CBTS Ø Certificação Brasileira de ( 100 questões, 75% para aprovação Ø Melhoria de Processo de Teste Brasileiro (MPT.Br) Nível 1: Parcialmente Gerenciado (práticas genéricas)» PG1 Atingir os resultados definidos» PG2 Estabelecer uma política organizacional» PG3 Planejar a execução do processo» PG4 Identificar e disponibilizar recursos» PG5 Definir responsabilidade e autoridade» PG6 Prover treinamento Ø Melhoria de Processo de Teste Brasileiro (MPT.Br) Nível 1: Parcialmente Gerenciado (práticas específicas)» PET1 Identificar casos de teste» PET2 Executar casos de teste» PET3 Reportar incidentes» PET4 Acompanhar incidentes Ø Nível 1: Parcialmente Gerenciado Gerência de Projetos de Teste» GPT1 Realizar análise de risco do produto» GPT2 Estabelecer objetivos do teste» GPT3 Definir estratégia de teste» GPT4 Definir o escopo do trabalho para o projeto de teste» GPT5 Estabelecer estimativas de tamanho» GPT6 Definir o ciclo de vida do projeto de teste» GPT7 Estimar o esforço e o custo Ø Nível 1: Parcialmente Gerenciado Gerência de Projetos de Teste» GPT8 Estabelecer e manter o orçamento e o cronograma do projeto» GPT9 Identificar riscos do projeto» GPT10 Planejar os recursos humanos» GPT11 Planejar o ambiente de teste para o projeto» GPT12 Planejar os artefatos e dados do projeto» GPT13 Estabelecer indicadores de desempenho de teste Ø Nível 1: Parcialmente Gerenciado Gerência de Projetos de Teste» GPT14 Estabelecer o Plano de Teste» GPT15 Revisar e obter compromisso com o Plano de Teste» GPT16 Monitorar o projeto» GPT17 Gerenciar o envolvimento dos stakeholders» GPT18 Executar revisões em marcos do projeto» GPT19 Analisar e registrar os problemas identificados» GPT20 Estabelecer e acompanhar ações corretivas até a sua conclusão 8

9 Ø Melhoria de Processo de Teste Brasileiro (MPT.Br) Nível 2: Gerenciado (práticas genéricas)» PG7 Controlar produtos de trabalho» PG8 Monitorar e controlar o processo» PG9 Fornecer visibilidade do processo para a gerência superior Ø Melhoria de Processo de Teste Brasileiro (MPT.Br) Nível 2: Gerenciado (práticas específicas)» PET5 Estabelecer padrões de documentação de casos de teste» PET6 Estabelecer padrões de documentação de incidentes Ø Nível 2: Gerenciado Gerência de Projetos de Teste» GPT21 Definir critérios de entrada e saída do teste» GPT22 Definir critérios de suspensão e reinício do teste» GPT23 Monitorar critérios de entrada, saída, suspensão e reinício do teste» GPT24 Monitorar defeitos» GPT25 Planejar e conduzir revisões de qualidade do produto ü Referências Eliane Martins, Curso de Testes, IC UNICAMP. Ana de Alencar Price, Curso de Testes, Instituto de Informática UFRGS. Atif Memon, Curso de Testes, University of Maryland. José Carlos Maldonado, Curso de Testes, USP/São Carlos. Guide to the Software Engineering Body of Knowledge, SWEBOK, W. Paula Filho, Engenharia de Software: Fundamentos, Métodos e Padrões, LTC, 2a Edição, ü Referências Software Testing On-line Resources, Site com link para diversas ferramentas: Outro site com link para diversas ferramentas: R. Binder, Testing OO Systems, R. Pressman, Engenharia de Software, 3ª edição, 1995 G. Myers, The Art of Software Testing,