Clinica sobre conceitos básicos de teste de software
Transcrição
Clinica sobre conceitos básicos de teste de software
Clinica de Teste de Software Emerson Rios [email protected] 1 Primeira Empresa Brasileira com certificação Nível 2 Bibliografia 2 Primeira Empresa Brasileira com certificação Nível 2 3 4 5 Agenda do curso: • Alongamento para a competição • O que é teste • O que é defeito • Testando sem técnica • O caso da caneta • Terminologias e conceitos • Projeto e processo de teste • A visão da norma ISO/IEC 29119 • Como melhorar os seus testes? • MPT – Melhoria de Processo de Teste 6 Alongamento para a competição 7 O que é Teste de Software? 8 Introdução Exemplo de Requisito • O campo salário deve ser sempre maior do que R$1.000,00 Autores usados nesta definição ISO – International Standard Organization Martin Pol Emerson Rios/Trayahu Moreira Glenford Myers 9 O que é teste de software ? ISO/IEC • Testar software é a atividade de comparar o que um item de teste faz com o que é esperado que faça (ISO/IEC-29119) (visão do requisito do software) 10 O que é teste de software ? Martin Pol • Em linhas gerais, podemos dizer que o objetivo dos testes é encontrar defeitos: desta forma os testes são conduzidos para demonstrar a ausência de qualidade expressa pela presença de defeitos, para tal se faz necessário um processo (planejamento, especificação, execução, análise de resultados), considerando-se sempre os riscos do negócio e a qualidade do produto. (visão do processo, projeto, requisito, risco do negócio e a qualidade para o negócio) Obs.: Foram condensadas as três definições existentes no livro numa única definição. Fonte: Software Testing – A Guide to the Tmap Approach – Martin Pol e outros. 11 O que é teste de software ? Rios & Moreira • Verificar se o software é executado de forma controlada e está fazendo o que deveria fazer, de acordo com os seus requisitos, e não está fazendo o que não deveria fazer. (visão do requisito) Observação: Foram condensadas as duas definições existentes no livro em uma única definição. Teste de Software – Emerson Rios e Trayahu Moreira – Editora Altabooks – 2ª edição 12 O que é teste de software ? O que diz o papa (Glenford Myers) • Teste de software é um processo, ou um grupo de processos, definidos para garantir que um código faz o que ele foi desenhado para fazer, e não faz nada que não foi especificado para fazer. (visão do projeto e do requisito) The Art of Software Testing – Glenford Myers – 2ª edição (primeiro livro publicado sobre teste de software – 1979) 13 O que é teste de software ? Conclusão • • • • • Considerando-se todas as definições dadas sobre teste de software podemos concluir o seguinte: Testamos para verificar se o software está fazendo o que foi pedido que ele fizesse num requisito; O teste deve ser considerado um projeto; É importante termos um processo de teste; Testamos para garantir que o negócio não vai correr riscos provocados por defeitos em produção; Testamos para assegurar a qualidade do software. 14 Ufa! Agora eu sei a resposta Processo de Teste Planejar Planejar Testes Testes Requisitos Projetar Testes Visões: Requisito Qualidade/Riscos Projeto Executar Testes Analisar Resultados Gerenciar Defeitos 15 www.iteste.com.br Eu estava triste e deprimido. A minha mulher tinha me trocado por um desenvolvedor. Agora os meus filhos estavam sendo criados por um desenvolvedor. Nada me animava e eu estava a beira de uma depressão. Só tinha consolo no trabalho. Então eu testava .... Testava ... Testava.. Carlinhos, o testador Então um dia uma coisa maravilhosa me aconteceu. Eu encontrei um defeito, tão crítico, tão severo, tão importante para que o negócio não corresse risco, que os desenvolvedores tiveram que fazer horas extras para corrigi-lo. O negócio foi salvo, e eu sai da minha depressão. 16 A definição sobre o que é teste de software pode ser vista no filme acessado pelo link abaixo: O que é teste de software? http://www.youtube.com/watch?v=w47wtSC7b7c&feature=youtu.be Ver o artigo completo ou o link acima na área de download da iTeste (www.iteste.com.br ) ou no blog do Emerson na Editora Altabooks (http://blog.altabooks.com.br ). 17 O que é defeito? 18 História O ENIAC (Electronic Numerical Integrator and Computer), primeiro computador digital completamente eletrônico (1947), também contribuiu ao uso da palavra. Ele era movido a válvulas e, assim, atraía milhares de insetos. Como dezenas a centenas de válvulas queimavam a cada hora o computador, que ocupava o espaço de uma sala, era aberto frequentemente e montes de insetos mortos eram varridos para fora. Diz-se que esses insetos provocavam Curto Circuitos nas placas do ENIAC levando a falhas nos programas. Fonte: Wikipédia 19 Custo econômico dos defeitos Em 2002, um estudo financiado pelo NIST constatou que erros de software custam anualmente US$ 59 bilhões à economia dos Estados Unidos. O estudo também estimou que mais de um terço desse valor, ou aproximadamente US$ 22,2 bilhões, poderia ser economizado caso fossem realizados investimentos em uma melhor infraestrutura de testes. NIST – National Institute of Standards and Technology Fonte: Wikipédia 20 Muitas palavras para definir apenas uma coisa? • • • • • • • • • Defeito Falha Problema Incidente Anomalia Variância Inconsistência Bug Erro 21 Muitas palavras para definir apenas uma coisa? • • • • • • • • • Defeito Falha Problema Incidente (norma ISO 29119) Anomalia (IEEE 829) Variância Inconsistência Bug (ver defeito) Erro 22 Definição de defeito Fonte da definição Descrição de defeito ISO/IEC 29119 Qualquer condição que causa um desvio de um resultado baseado no que diz um requisito, um documento de especificação, um documento do usuário, um padrão, ou conforme a experiência ou percepção do técnico, que requeira investigação. Obs.: Defeitos podem ser encontrados em produtos de software ou artefatos de software. Martin Pol e outros Defeito ou falha é o resultado de um erro residente num código ou num documento. Rios & Moreira Defeito é uma diferença entre o resultado produzido e o especificado, quando as especificações existem e estão corretas. Ron Patton Um defeito ocorre quando o software não faz alguma coisa que pela especificação do produto deveria fazer Ou faz alguma coisa que a especificação diz para não fazer. Ou faz alguma coisa que a especificação não menciona. 23 Explicação mais detalhada Termo Definição Defeito Já definido Erro Falha humana que provoca o aparecimento de um defeito Bug Ver defeito Incidente A norma ISO diz que o testador registra um incidente que apenas virá defeito quando é reconhecido como tal Anomalia Igual a incidente (definido pela norma IEEE 829:2008) 24 Seqüência de eventos Erro pode ser cometido pelo desenvolved or ou pelo usuário Erro Incidente ou anomalia Defeito ou Bug 25 Visão geral dos processos de teste Plano de Teste Projeto e implementação Requisitos de ambiente Indicadores Diretivas Resultados da execução Especificações de teste Nenhuma ocorrência Execução Ocorrência ou resultado do re-teste Montagem do ambiente Relatório de ambiente implantado Registro de incidentes 26 Visão geral dos processos de teste Plano de Teste Projeto e implementação Requisitos de ambiente Indicadores Diretivas Resultados da execução Especificações de teste Nenhuma ocorrência Execução Ocorrência ou resultado do re-teste Montagem do ambiente Relatório de ambiente implantado Registro de incidentes 27 Ciclo de vida do defeito Encontrar defeito Reportar defeito Solucionar defeito (1) RELATÓRIOS DE GESTÃO Fonte: Tmap Nexst for result –driven test Tim Koomen e outros – UTN Publishers (1) Em inglês o termo usado foi Procedure 28 Nunca é demais lembrar O custo da correção do defeito Especificação Projeto Construção Teste Produção 29 www.iteste.com.br Bibliografia Autores usados no micro curso ISO/IEC 29119 – International Standard Organization Martin Pol e outros – Software Testing - A Guide to Tmap Approach – Editora Addison Wesley Emerson Rios/Trayahu Moreira – Teste de Software – Editora Altabooks – 2ª Edição Ron Patton – Software Testing – Editora SAMS 30 Quando eu estou triste e deprimido... Carlinhos, o testador A receita que o médico me passou foi: encontre um defeito de uma em uma hora. 31 A definição sobre o que é defeito pode ser vista no filme acessado pelo link abaixo: O que é teste de software? http://youtu.be/c84ryqx03t8 Ver o artigo completo ou o link acima na área de download da iTeste (www.iteste.com.br ) ou no blog do Emerson na Editora Altabooks (http://blog.altabooks.com.br ). 32 Teste de Software A intuição e a técnica 33 Exemplo Simples Você deverá testar o seguinte requisito: O programa deverá somar dois números que devem ter um ou dois dígitos. Quando o número for digitado, ele deve aparecer na tela, e após serem digitados os dois números, deve surgir o valor da soma na tela. A funcionalidade somar deve ser uma opção do menu na tela. 34 O que diz a intuição? Você chamou o programa, colocou os valores e ele fez a soma corretamente. O programa está correto? ? 4 ? 3 7 ? _ 35 Primeira visão Tudo bem. O programa fez o que o requisito pediu, porém: 1.Defeito de usabilidade: Não tem nenhuma informação na tela dizendo que você está usando o programa correto ou a funcionalidade correta. 2. Defeito de usabilidade: Não tem nenhuma instrução na tela sobre o que fazer. 3. Defeito de usabilidade: Como você sai dessa tela? 4. Defeito de design: A soma não está alinhada com os números. 5. Muitos outros defeitos poderiam ser alinhados ? 4 ? 3 7 ? _ 36 Relatando os defeitos Os defeitos ou incidentes devem ser registrados e enviados para os desenvolvedores que os aceitarão ou não. Correções deverão ser feitas para a próxima rodada de testes. Sugerimos que cada defeito seja registrado individualmente. 37 Segunda visão Os testes da primeira visão foram completos? Considere o seguinte: Matematicamente existem 39601 testes possíveis de serem feitos usando este mesmo programa. Temos números entre -99 e 99, o que incluindo 0 dariam 199 números. Para cobrirmos todo o universo teríamos 1992 = 39.601. Nós usamos apenas duas dessas possibilidades. ? 4 ? 3 7 ? _ 38 Segunda visão CT Resultado esperado Notas 99+99 198 Maior número possível -99+-99 -198 Não houve menção a nos negativos 99+-14 85 Maior número em primeiro -38+99 61 Maior número em segundo 9+9 18 Dois maiores dígitos 0+0 0 Programas muitas vezes falham com 0 0+23 23 Problemas com 0 -78+0 -78 Problemas com 0 Valores limítrofes é uma conhecida técnica de teste que usamos quando colocamos os valores máximos e mínimos 99,-99 nas operações de soma. Pergunta: Será que com esses casos de teste cobrimos todo o universo 39 de Casos de Testes Terceira visão CT Resultado esperado Notas 100 + 100 Mensagem de erro Embora o requisito limite em dois dígitos pode ser que o programa aceite <Enter>+<En ter> Erro - msg Será que aceita campos em branco 123456+0 Erro - msg Explorar os limites do campo 1,2 + 3 3,2 ou erro de definição? O requisito não fala em número decimal. Talvez seja um incidente Mensagem de erro O certo seria só aceitar valores numéricos A=B Teclas de controle + teclas de controle 40 Terminamos os testes? Acho que precisamos ainda de mais um caso de teste. O valor da soma será armazenado em algum arquivo? 41 Conclusões O número de casos de teste a serem criados e executados muitas vezes vai depender do prazo de teste ou de outros fatores. Além disso, não basta a nossa intuição, precisamos escrever cada um dos casos de teste. A mensagem é simples, quanto mais casos de teste usarmos tanto mais profundo será o nosso teste e tanto maior será a qualidade do software. 42 Eu quero testar mas não sei por onde começar... Carlinhos, o testador Um bom começo seria escrever os casos de teste associados a cada uma das funcionalidades ou requisitos do software. 43 A definição sobre o que intuição e técnica pode ser vista no filme acessado pelo link abaixo: http://www.youtube.com/watch?v=yM3Y18nUsfo&feature=channel Ver o artigo completo ou o link acima na área de download da iTeste (www.iteste.com.br ) ou no blog do Emerson na Editora Altabooks (http://blog.altabooks.com.br ). 44 O caso da caneta • Nós somos uma equipe e nos foi dado o encargo de testar um lote de canetas esferográficas, como esta acima, o que vocês acham que deveríamos fazer para conduzir esses testes, ou seja, como esses testes deveriam ser conduzidos? 45 Teste da caneta esferográfica Lista de testes propostos Testes a serem executados Testar o prendedor Parar de usar e voltar a usar Apertar a mola para ver se está funcionando direito Estressar a mola Verificar a carga Desmontar/montar Verificar o conforto para escrever Verificar o nível de resistência da caneta jogando ela no chão Escrever em diversos tipos de papel Escrever e depois passar o liquid paper Verificar se borra a escrita Verificar se fica um borrão grudado na ponta Avaliar a durabilidade da carga Verificar se a escrita falha Colocar a caneta em diferentes temperaturas (e escrever) 46 Terminologias e conceitos 47 Terminologias Teste Dinâmico Teste que para ser executado precisa de um código de programa Teste Estático Teste que para ser executado não precisa de um código de programa, exemplo, revisão, verificação, inspeção. 48 Terminologias Teste Baseado em Especificação (Teste Caixa Preta ou Teste Funcional) Teste executado com base numa especificação ou requisito. Item de Teste Sistema, software ou produto de trabalho (ex. requisito, especificação, etc.) que é objeto de teste 49 Terminologias Teste Baseado na Estrutura (Teste Caixa Branca) Teste no qual as entradas (dos casos de teste) são derivadas do exame da estrutura do item de teste Teste de regressão É o reteste de um software ou parte do software após o mesmo sofrer uma alteração ou correção. 50 Terminologias Teste de Carga Busca avaliar o comportamento do software após ser submetido a um grande volume de dados, conforme definido nos requisitos. Teste de performance Busca mostrar o comportamento do software a medida que vai sendo submetido a uma carga maior de dados, conforme definido nos requisitos. 51 A importância do teste de software • Porque é importante testarmos corretamente os softwares? 52 Defeitos podem ser perigosos 53 Empresa não consegue vender porque o software deu um problema Veja o desconsolo da vendedora Palestrante tenta comprar um produto na loja Tok & Stok mas o software (Oracle/Java) não deixa. Natureza do problema: Palestrante queria comprar dois presentes para dois casamentos que iriam ocorrer, coincidentemente, no mesmo dia, e, o sistema não deixava usar o mesmo CPF. 54 Defeitos custam caro 55 Os software têm defeitos 7 Atendem Não Atendem 93 Apenas uma parcela pequena das aplicações entregues atendem aos requisitos funcionais e de tempo de resposta e performance 75% da responsabilidade pelos problemas recaem sobre a área de desenvolvimento Fonte: Gartner Group - 2001 56 O custo dos defeitos “The Economic Impact of Inadequate Infraestruture for Software Testing” O custo dos defeitos atinge aproximadamente 1% do PIB americano A falta de uma infra-estrutura robusta e padronizada de testes pode acarretar os seguintes problemas: - Aumento de falhas devido a baixa qualidade - Aumento dos custos de desenvolvimento (re-trabalho) - Perda do tempo de mercado no lançamento de um produto - Aumento dos custos de suporte do produto 57 Por que os projetos de desenvolvimento falham? (ou estão sempre cheios de defeitos)? Falha na gerência de requisitos Comunicação imprecisa ou ambigua Grande complexidade Arquitetura frágil Inconsistências não detectadas em requisitos, projetos e implementações Testes insuficientes Avaliação subjetiva do status do projeto Falhas na administração dos riscos Alterações sem controle Insuficiência de automação Fonte: Capers Jones: Patterns of Software System Failure and Success 58 Por que o processo tradicional de testes não atendia? Nem todos os requisitos são testados Organizações independentes de teste ainda pouco usadas Informalidade no processo de testes Pouca importância atribuida ao processo de testes Defeitos só detectados em produção, onde custam de 100 a 1000 vezes mais para serem consertados Abordagens únicas para novas tecnologias Falta de automação de testes Falta de metodologia de teste 59 Custo do Defeito 60 Verdades sobre o conceito de teste Testar é um exercício de gerência de risco Treinamento em teste reduz custos a longo prazo Melhorar os testes reduz custos Ligar os documentos de desenvolvimento aos documentos de teste melhora os resultados Deve ser mantida uma relação entre os requisitos e as condições de teste Sempre teste o ambiente de teste É melhor encontrar um defeito nas primeiras fases do que em produção As ferramentas de teste não necessariamente melhoram o processo já existente. 61 Conceitos históricos Detecção Demonstração Descobrir defeitos, erros e deficiências do software Liberar sistema mesmo Definir capacidades e limitações correndo riscos Fornecer informações sobre a qualidade dos Garantir que o produto funciona componentes, sistemas e outros produtos Testes feitos pelos desenvolvedores Prevenção Trabalho nas especificações do software Gerar informações que previnem ou reduzem os defeitos Detectar defeitos nas fases iniciais Identificar riscos e problemas de forma a evitá-los no futuro Metodologias, processos, etc. Testes feitos por testadores Demonstração Detecção Mostrar que Encontrar funciona defeitos Década de 60 Década de 70/80 Prevenção Gerenciar a qualidade Década de 90 Por que os testes mudaram? 62 Níveis de Teste Teste Unitário ou Teste de componente – normalmente feito pelo programador. Teste de Integração – normalmente feito pelo analista de sistemas para um módulo ou conjunto de programas ou casos de uso em ambiente de desenvolvimento. Teste de Sistemas – normalmente feito pelo analista de testes (caso de testes) em ambiente de testes. Teste de Aceitação – normalmente feito pelo usuário em ambiente de homologação, 63 Características de qualidade dos softwares – ISO/IEC 25010 1. 2. 3. 4. 5. 6. 7. 8. Funcionalidade Performance Compatibilidade (inter-operabilidade) Usabilidade Confibilidade (maturidade, disponibilidade) Segurança Manutenibilidade Portabilidade A norma ISO/IEC 25010 substitui a antiga norma ISO/IEC 9126 64 Norma ISO/IEC 25010 Características SubCaracterísticas Integridade Funcionalidade Correção Completeza Tempo Performance Recursos Capacidade Compatibilidade Usabilidade Co-existência Interoperabilidade Facilidade de uso Acessabilidade, etc... Maturidade Confiabilidade Disponibilidade Tolerância a falhas Recuperação Confidencialidade Segurança Integridade Autencidade Responsabilidade Manutenibilidae Modularidade, reusabilidade, testabilidade.... Portabilidade Adaptabilidade, Facilidade de instalação,.... 65 Tipos de teste x características de qualidade Tipo de Teste Descrição Característica de qualidade Funcionalidade Testa as funcionalidades do software Funcionalidade Interface Testa ligações com outros sistemas Compatibilidade Carga e estresse Testa grandes volumes de entradas e o comportamento do software (tempo de resposta e funcionamento) Performance Produção Testa os procedimentos de produção Portabilidade Recuperação Testa os procedimentos de recuperação e de re-início Confiabilidade Regressão Testa as funcionalidades e outros procedimentos após uma alteração Todas Segurança Testa os procedimentos de segurança Segurança Etc. 66 Revisão 67 Primeira Empresa Brasileira com certificação Nível 2 Revisão O que é teste de software? O que é erro, defeito (bug), incidente e anomalia? Mostrar o ciclo de vida de um defeito Quando é mais barato a correção de um defeito? Quais são os níveis de teste? Cite duas características de qualidade dos softwares (ISO 25010) Relacione as características citadas anteriormente a um tipo de teste 68 Processos de Teste 69 Primeira Empresa Brasileira com certificação Nível 2 Teste de software é um projeto, acredite em mim. Teste de software é um projeto, acredite em mim. Teste de software é um projeto, acredite em mim. Teste de software é um projeto, acredite em mim. 70 E tem mais, deve ser um projeto paralelo e integrado ao projeto de desenvolvimento 71 Definindo projeto O que vocês acham que aconteceu quando o software entrou em produção? 72 Definindo projeto D Projeto é um processo único, consistente, com um conjunto único e coordenado de atividades, com dada de início e término, conduzidas para atingir um objetivo, com requisitos especificados, incluindo restrições de tempo, custo e recursos (ISO 10006) Projeto é um empreendimento temporário, conduzido para criar um produto ou serviço ou resultado único (PMI – Project Management Institute – PMBok 2008) (Gerenciando Projetos de Teste de Software – Editora ArtImagem) 73 Por que os projetos falham? Algumas causas do insucesso dos projetos: •Problemas de comunicação; •Não cumprimento dos prazos; •Mudanças de escopo constantes; •Escopo não definido adequadamente; •Concorrência entre o dia-a-dia e o projeto na utilização dos recursos; •Estimativas incorretas ou sem fundamento; •Riscos não avaliados corretamente; •Não cumprimento do orçamento; •Problemas com fornecedores; •Retrabalho em função da má qualidade do produto. Fonte: Estudo de Benchmarking em Gerenciamento de Projetos – Brasil 200974 Ciclo de vida de um projeto Evolução do custo e pessoal no ciclo de vida de um projeto (Fonte: PMBOK ® ) 75 Teste x desenvolvimento Planejamento Projeto Lógico Projeto Físico Construção Ciclo de desenvolvimento de sistemas Ciclo de Testes Passado Ciclo de Testes Presente Ciclo de Testes Futuro 76 Ciclo de vida do projeto de teste e o ciclo de vida de gestão do projeto 77 Processo (básico) de Teste Planejar Planejar Testes Testes Projetar Testes Executar Testes Analisar Resultados Gerenciar Defeitos 78 Etapas de Desenvolvimento e Tipos de Teste Requisitos do Negócio Teste de Aceitação Desenho Lógico da Aplicação Teste de Sistema Desenho Físico da Aplicação Teste de Integração Construção Teste Unitário 79 Integração entre os projetos de teste e de desenvolvimento Gerência de Requisitos Teste Desenvolvimento Verificação Especificação P L A N E J A M E N T O Execução (1) Teste Unitário Desenho Lógico e Físico Construção Teste de Sistema e Teste de Integração Execução (2) Implantação P L A N E J A M E N T O Teste de Aceitação Entrega Entrega Teste Desenvolvimento 80 Metodologia de Testes Visão Geral Etapas de Suporte Preparação Produtos Etapas de Realização Requisitos Planejamento Especificação Planos de Teste Especificação Planejamento Casos de Teste Execução Scripts ou procedimentos de teste 81 O que é e para que servem os processos? 82 O que é e para que servem os processos? Na engenharia de software, o processo tem como meta entregar um produto de software de maneira eficiente, previsível e que corresponda às necessidades de negócio. Geralmente inclui análise de requisitos, programação e testes, entre outras tarefas. (Wikipédia) 83 E os processos de teste de software, para que servem? 84 Processo de Teste Planejar Planejar Testes Testes Requisitos de Teste Projetar Testes Executar Testes Analisar Resultados Gerenciar Defeitos 85 Principais Documentos dos Projetos de Teste (IEEE 829:2008) • • • • • Plano Master de Teste Plano de Teste Projeto de Teste Roteiro/Procedimento de Teste Caso de Teste • • • • Relatório Relatório Relatório Relatório de Anomalias (Incidentes / Defeitos) de Estado de Encerramento / Sumário Master 86 • • • • • • • • • • • • • • • • 29119-3 Política Organizacional de Teste Estratégia Organizacional de Teste Plano de Teste Relatório de Estado do Teste Relatório de Término do Teste Relatório de incidente Lista de itens de ação Relatório de teste estático Especificação de teste – Especificação de desenho de teste – Especificação de caso de teste – Especificação de procedimento de teste Requisitos de dados de teste Requisitos de ambiente de teste Relatório de situação de ambiente de teste Conseqüências (gerados por CT) do teste Resultados (se o CT passou ou não) do teste Log de execução do teste Relatório de incidência IEEE 829-2008 •Plano Máster de Teste •Plano de Teste •Desenho (Projeto) de Teste •Casos de Teste •Procedimentos de Teste •Relatórios de Execução dos Testes Relatório de Estado de Teste Relatório de Teste (sumário) Relatório de Log de Teste Relatório de Anomalias (ex-Relatório de Incidentes) •Relatório Máster de Teste 87 29119-3 • • • • • • • • • • • • • • • • Política Organizacional de Teste Estratégia Organizacional de Teste Plano de Teste Relatório de Estado do Teste Relatório de Término do Teste Relatório de incidente (ver teste dinâmico) Lista de itens de ação Relatório de teste estático Especificação de teste – Especificação de desenho de teste – Especificação de caso de teste – Especificação de procedimento de teste Requisitos de dados de teste Requisitos de ambiente de teste Relatório de situação de ambiente de teste Conseqüências (gerados por CT) do teste Resultados (se o CT passou ou não) do teste Log de execução do teste Relatório de incidente IEEE 829-2008 •Plano Máster de Teste •Plano de Teste •Desenho (Projeto) de Teste de Aceitação, Sistema, Integração e Unitário •Casos de Teste de Aceitação, Sistema, Integração e Unitário •Procedimentos de Teste de Aceitação, Sistema, Integração e Unitário •Relatórios de Execução dos Testes Relatório de Estado de Teste Relatório de Teste (sumário) Relatório de Log de Teste Relatório de Anomalias (ex-Relatório de Incidentes) •Relatório Máster de Teste 88 Exemplo de um caso real Macro-atividade: Planejar Testes O objetivo desta macro-atividade é definir o planejamento de um projeto de teste de software, correspondente a um projeto de desenvolvimento. O planejamento dos testes deve seguir as regras básicas de gerência de projetos e os critérios específicos definidos nos templates correspondentes usados nesta etapa (Ex. Plano de Teste). Atividade: Realizar estudo de viabilidade do projeto de teste Atividade: Iniciar a elaboração do Plano de Teste Atividade: Definir o Ambiente de Teste Atividade: Configurar Ambiente de Testes para o Projeto Atividade: Verificar a testabilidade dos Casos de Uso ou dos Requisitos Atividade: Detalhar Planejamento das Atividades de Teste 89 Plano de Teste • • Introdução – Identificador do Plano de Teste; – Escopo; – Referências – Nível na seqüencia de teste – Classe de teste e visão das condições de teste Detalhes para este nível do plano de teste – Itens de teste e seus identificadores; – Matriz de rastreabilidade do teste; – Funcionalidades a serem testadas; – Funcionalidades que não serão testadas; – Abordagem do teste (Estratégia de Teste na ISO 29119); – Critérios de liberação/falha dos itens; – Requisitos de suspensão e retomada; – Entregas do teste; (continua) 90 Plano de Teste • • Gerência de Teste – Tarefas do teste; – Necessidades de ambientes; – Responsabilidades; – Integração entre as partes envolvidas; – Recursos e sua alocação; – Treinamento; – Cronograma, estimativas e custos; – Riscos e contingências; Geral – Procedimentos de garantia de qualidade; – Métricas; – Cobertura do teste; – Glossário; – Procedimentos de alteração do documento e histórico. 91 Planejar Testes - Artefatos Planejar Testes 92 Artefatos Gerados Checklist ANÁLISE Testabilidade Caso de Uso 93 Como seria uma estratégia de teste baseada nos riscos do produto ou negócio? 94 O teste da caneta esferográfica Plano de Teste 95 Plano de Teste • • • Detalhes para este nível do plano de teste – Itens de teste e seus identificadores; – Matriz de rastreabilidade do teste; – Funcionalidades a serem testadas; – Funcionalidades que não serão testadas; – Abordagem do teste (Estratégia de Teste na ISO 29119); – Critérios de liberação/falha dos itens; – Requisitos de suspensão e retomada; – Entregas do teste; Gerência de Teste – Tarefas do teste; – Necessidades de ambientes; – Responsabilidades; – Integração entre as partes envolvidas; – Recursos e sua alocação; – Treinamento; – Cronograma, estimativas e custos; – Riscos e contingências; Geral – Procedimentos de garantia de qualidade; – Métricas; – Cobertura do teste; – Glossário; – Procedimentos de alteração do documento e histórico. Plano de Teste Resumido 96 E neste Site? Qual seria a estratégia? 97 E neste Site? Qual seria a estratégia? 98 Desta forma eu destaquei alguns tópicos básicos para qualquer gerente poder entendê-lo, qualquer que seja o seu nível intelectual. Gerentes não gostam de ler mais de uma página. O meu Plano de Teste tem tantos campos que nenhum gerente vai ter a paciência de lê-lo. 99 Principais Documentos dos Projetos de Teste (IEEE 829:2008) • • • • • Plano Master de Teste Plano de Teste Projeto de Teste Roteiro/Procedimento de Teste Caso de Teste • • • • Relatório Relatório Relatório Relatório de Anomalias (Incidentes / Defeitos) de Estado de Encerramento / Sumário Master 100 Processo de Teste Planejar Planejar Testes Testes Projetar Testes Executar Testes Analisar Resultados Gerenciar Defeitos 101 Exemplo de um caso real Macro-atividade: Projetar Teste O projeto dos testes contempla a criação dos casos de teste (conforme template) e demais artefatos necessários às atividades de execução dos testes. Na ocorrência de alterações de requisitos, de design ou do código do sistema, durante ou posteriormente a esta atividade, a alteração é feita através de uma solicitação formal de mudança, onde são avaliadas as mudanças necessárias nos artefatos envolvidos. Atividade: Atividade: Atividade: Atividade: Definir os cenários de teste Elaborar Casos de Teste Estruturar Scripts de Teste Elaborar Procedimento de Teste 102 Projetar Teste - Documentos Planejar Projetar Testes Testes • Roteiro de Teste ou Procedimentos de Teste • Casos de Teste • Scripts de teste 103 Caso de Teste • Um caso de teste é uma descrição do teste a ser executado. Existe uma correspondência entre o casos de teste e o casos de uso, embora, na maioria das vezes, vários casos de teste correspondam a um caso de uso. 104 Caso de Teste – IEEE829 • Identificação do caso de teste • Itens de teste – componentes, módulos, casos de teste, etc. • Especificação das entradas – listar todas as entradas usadas para a execução do caso de teste • Especificação das saídas – listar todas as saídas geradas pelo caso deteste • Ambiente necessário • Requisitos especiais • Inter-dependência entre os casos de teste 105 Exemplo de CT Em um Caso de Uso de Transferência Bancária, um dos cenários é a Transferência “DOC para conta de terceiros”. • • • • • • Para se testar este cenário de especificação, devemos criar um cenário de teste para validar esta funcionalidade. Este cenário de teste, deve seguir os seguintes passos: Consultar o saldo da conta de origem; Consultar dados da conta destino; Transferir um valor da conta origem para conta destino; Consultar novamente o saldo da conta origem, verificando que o saldo inicial menos o valor transferido é igual ao saldo atual; Etc. Dentro – – – – deste cenário de teste podemos destacar diversos casos de testes: CT01 Preenchimento dos campos obrigatório na tela de transferência; CT02 Validação de CPF; CT03 Conta Destino inválida (se for possível); CT04 Transferência de valores negativos e muitos outros. 106 Caso prático Um Sistema web com os seguintes requisitos não-funcionais: •Deve operar em diferentes Browsers - Internet Explorer 5.0, 5.5, e 6.0, Netscape 6.0 e 7.0, Mozilla 1.1, firefox e Opera 7; •Deve poder usar diferentes plugins - RealPlayer, MediaPlayer, não usar nenhum; •Rodar em diferentes sistemas operacionais nas máquinas clientes - Windows 95, 98, ME, NT, 2000, e XP; •Deve receber páginas por diferentes servidores – IIS, WebLogic e Apache. •Deve rodar em diferentes servidores – Windows 2000, NT e Linux. 107 Caso de teste • • • Introdução (uma por documento) • – Identificador do documento – Escopo – Referências (itens de teste) – Contexto – Notas para descrição Detalhes (um por caso de teste) – Identificador do caso de teste – Objetivos – Especificações de entrada – Especificações de saída – Necessidades de ambiente – Requisitos ou procedimentos especiais – Dependências entre casos de teste Global – Glossário – Procedimentos de alterações do documento e histórico de alterações Referências (Itens de teste) – Requisitos – Projeto de teste e features – Guia do usuário – Guia operacional – Guia de instalação – Etc. 108 O teste da caneta esferográfica Casos de Teste 109 Exemplo de Casos de Teste 110 Exemplo de Casos de Teste Cenários de Teste Caso de Teste - CT01 01Teste Campo Obrigatório Pré-condições: Não se Aplica Pós-condições: Mensagem de Erro do Sistema Detalhamento: *PA: O Ator não informa o login e a senha. E1 PA: O ator seleciona a opção OK. **PS:: O Sistema verifica se os campos obrigatórios foram informados PS: O sistema apresenta a mensagem “O(s) Campo(s) << campo>> deve(m) ser informado(s).” e retorna ao passo anterior Massa de entrada e de Saída: Não se Aplica Critérios especiais: Não se Aplica Ambiente: Sistema Operacional Cliente Windows 2000, Browser Internet Explorer 6.0, Servidor de Aplicação IIS e SO Windows 2000. Implementação: Manual Iteração: 1ª Iteração Interdependências: Não se Aplica * PA - Passo do Ator ** PS - Passo do Sistema 111 Exemplo de Elaboração de Casos de teste Especificação do Sistema: O sistema apresenta os seguintes campos: Login e Senha RN01 O sistema apresenta as seguintes opções: OK e Limpar Caso o ator selecione a opção Limpar O sistema limpa os campos Login e Senha Caso o ator selecione a opção OK O sistema valida o preenchimento dos campos obrigatórios Login e Senha E1, RN02 O sistema valida o conteúdo dos campos Login e Senha E2, E3 Fluxos de exceções E1 – Campos Obrigatórios Caso um dos dois ou os dois campos Login e Senha não tenham sido preenchidos O sistema apresenta a mensagem “O(s) Campo(s) << campo>> deve(m) ser informado(s).” e retorna ao passo anterior. E2 – Validação Usuário e Senha O sistema apresenta a mensagem "O login ou senha informados não são válidos " e retorna ao passo anterior E3. Usuário Bloqueado. O sistema verifica que o usuário está bloqueado, e exibe uma mensagem com o texto descrito acima e retorna ao passo anterior. Regra de Negócio RN01 – Regra de Tamanho O Campo Login deve conter no máximo 10 Caracteres alfanuméricos, não podendo aceitar caracteres especiais tais como: !; @; #; $; %; ” ;‘ ;& ; *; ( ; ) ; +; = O Campo Senha deve estar protegido para identificação na digitação com o # como mascar e deve conter no máximo 8 Caracteres alfanuméricos não podendo aceitar caracteres especiais tais como: !; @; #; $; %; ” ;‘ ;& ; *; ( ; ) ; +; = RN02 – Regra de Bloqueio Após a terceira tentativa de acesso de um login onde a senha estiver incorreta o sistema bloqueia o acesso deste login ao sistema. Regra de Usabilidade: US01 – Formatação dos Campos O sistema não deve diferenciar caracteres minúsculos de maiúsculos para o campo Login (case insensitive), mais 112 para o campo senha deve ser diferenciado (case sensitive). Quantos casos de teste seriam necessários para testar esta funcionalidade ou requisito? Quanto tempo você estima que precisaria para testar este requisito? 113 Resposta dada por um especialista • Quantos casos de teste seriam necessários? – Entre 20 e 30 casos de teste • Quanto tempo seriam gasto na elaboração e na execução de cada caso de teste? – Elaboração – 3 minutos (45%) – Execução – 4 minutos (55%) 114 Processo de Teste Planejar Planejar Testes Testes Projetar Testes Executar Testes Analisar Resultados Gerenciar Defeitos 115 Principais Documentos dos Projetos de Teste (IEEE 829:2008) • • • • • Plano Master de Teste Plano de Teste Projeto de Teste Roteiro/Procedimento de Teste Caso de Teste • • • • Relatório Relatório Relatório Relatório de Anomalias (Incidentes / Defeitos) de Estado de Encerramento / Sumário Master 116 Vamos pensar um pouco. O que eu preciso para começar a executar os testes? Lembrese do Plano de Teste 117 Caso real - exemplo Macro-atividade: Executar Testes Executar casos de teste e/ou scripts automáticos, que foram definidos para cada iteração, bem como executar testes específicos, como teste de desempenho e outros. Na ocorrência de alterações das especificações ou do código, durante ou posteriormente a esta atividade, é verificado se estas alterações afetam também os casos de teste/scripts. Caso isto tenha ocorrido e a execução já tenha sido iniciada, será planejado um novo ciclo de teste ou teste de regressão. Antes de executar os casos de teste devem ser definidos os responsáveis pela sua execução. • • • • • Atividade: Atividade: Atividade : Atividade: Atividade: Executar Casos de Teste Executar Scripts de Teste Gerar Resultados (logs) de Teste Acompanhar Defeitos Executar Testes Especiais 118 Automação do Teste •Custo / Esforço • Cem Kaner estima que leva entre 3 a 10 vezes mais para criar , verificar e documentar teste automático do que criar e executar o mesmo teste manualmente. (Kaner, Improving the Maintainability of Automated Test Suites, p. 2.) • A Especialista em teste automatico Linda Hayes estima que gasta 5 a 10 vezes do tempo com teste automático em relação ao teste manual. (Hayes, Does Test Automation Save Time and Money? StickyMinds.com, August 8, 2001.) 119 Processo de Teste Planejar Planejar Testes Testes Projetar Testes Executar Testes Analisar Resultados Gerenciar Defeitos 120 Exemplo de um caso real Macro-Atividade: Gerenciar Defeitos Registrar e acompanhar a correção dos defeitos, decorrentes da execução dos testes. Se for identificado que o defeito persiste, após o re-teste, a correção é rejeitada, caso contrário ela é aprovada. Defeitos podem ser identificados durante ciclo de desenvolvimento, durante a execução do teste de aceite, no ambiente de homologação ou após a entrega do sistema (ambiente de produção). Em todos os casos, é utilizado um workflow para acompanhar todo o ciclo de vida do defeito. Atividade: Atividade: Atividade: Atividade: Cadastrar Defeitos Executar Re-Teste Rejeitar Correções Aprovar Correções 121 Principais Documentos dos Projetos de Teste (IEEE 829:2008) • • • • • Plano Master de Teste Plano de Teste Projeto de Teste Roteiro/Procedimento de Teste Caso de Teste • • • • Relatório Relatório Relatório Relatório de Anomalias (Incidentes / Defeitos) de Estado de Encerramento / Sumário Master 122 Gerenciar Defeito Gerenciar Defeitos 123 Gerenciar Defeito – Ferramenta de Workflow Workflow do Defeito DevTrack ClearQuest 124 Relatório de Incidentes O Relatório de Incidentes (defeitos) é o documento básico onde a equipe de testes relata os defeitos encontrados (programa e documentação) e normalmente deve ser encaminhado à equipe de desenvolvimento para as providências pertinentes. 125 Você está testando o site da Amazon. A funcionalidade testada é a compra através de cartões de crédito. Ao clicar na etapa de definir a forma de pagamento e indicar a bandeira do cartão o site trava e congela. A sequencia de teste logicamente foi interrompida pois você não pode mais continuar testando a compra. Como você relataria este incidente. 126 Relatório de Incidentes – IEEE 829 Introdução Identificador Escopo Referências Detalhes Sumário Data da anomalia Contexto Descrição da anomalia Descrição da execução (identificar o que foi executado) Resultados (mensagens, requisições operacionais, etc) Informações sobre o ambiente Eventos anormais (conexão com o Relatório de Anomalias) Qualquer situação que causou a interrupção do teste. Impacto Estimativa de urgência Descrição das ações corretivas Estado da anomalia Conclusões e recomendações Geral Procedimentos de alterações do documento e histórico de alterações 127 Exemplo da Ferramenta DevTrack 128 Processo de Teste Planejar Planejar Testes Testes Projetar Testes Executar Testes Analisar Resultados Gerenciar Defeitos 129 Principais Documentos dos Projetos de Teste (IEEE 829:2008) • • • • • Plano Master de Teste Plano de Teste Projeto de Teste Roteiro/Procedimento de Teste Caso de Teste • • • • Relatório Relatório Relatório Relatório de Anomalias (Incidentes / Defeitos) de Estado de Encerramento / Sumário Master 130 Exemplo de um caso real Macro-Atividade: Analisar Resultados Ao encerramento do projeto de teste conforme as regras definidas no Plano de Teste devem ser elaborados os artefatos de conclusão. Atividade: Gerar Resultados dos Testes Descrição: Ao final do projeto deve ser elaborado um Relatório de Sumário contemplando todas as informações relevantes coletadas durante o seu decorrer, assim como problemas ocorridos e não conformidades encontradas. Os indicadores fornecidos pelo projeto devem ser catalogados como histórico para uso em processos de planejamento e de estimativas. Responsáveis: LP Participantes: AT, TE Artefatos: Plano de Teste, Relatório de Sumário de Teste Ferramentas: Testlink 131 Analisar Resultado - ATIVIDADES Planejar Analisar Testes Resultados • Analisar Resultados (logs) • Gerar resultados dos testes 132 Analisar Resultado - Medição Planejar Analisar Testes Resultados Objetivo • Indicar a qualidade do produto • Avaliar a produtividade do processo • Realimentar dados para estimativa • Realimentar dados para a estratégia organizacional Se você não sabe onde você está, um mapa não vai ajudar!” Roger Pressman 133 Relatório de Sumário • • • Introdução – Identificador – Escopo – Referências Detalhes – Visão geral dos resultados do teste – Resultados detalhados do teste – Racional das decisões – Conclusões e recomendações Geral – Glossário – Procedimentos de alterações do documento e histórico de alterações 134 A Visão da norma ISO/IEC - 29119 135 Responsáveis pela execução do processo Gerente de Projeto Líder de Projeto de Teste Analista de Teste Analista de Requisitos Testador Arquiteto de Teste GP LP AT AS TE AR 136 Processos multicamadas de teste Estratégica Gerencial Operacional Processo organizacional de teste Processos de gerência de teste Processos de teste dinâmico 137 Processos multicamadas de teste com todos os processos Processo organizacional de teste Processos de gerência de teste Planejamento de teste Monitoramento e controle de teste Término de teste Processos de teste dinâmico Desenho e implementação do teste Configuração do ambiente de teste Registro de incidente de teste Execução do teste 138 29119-3 • • • • • • • • • • • • • • • • Política Organizacional de Teste Estratégia Organizacional de Teste Plano de Teste Relatório de Estado do Teste Relatório de Término do Teste Relatório de incidente (ver teste dinâmico) Lista de itens de ação Relatório de teste estático Especificação de teste – Especificação de desenho de teste – Especificação de caso de teste – Especificação de procedimento de teste Requisitos de dados de teste Requisitos de ambiente de teste Relatório de situação de ambiente de teste Conseqüências (gerados por CT) do teste Resultados (se o CT passou ou não) do teste Log de execução do teste Relatório de incidente IEEE 829-2008 •Plano Máster de Teste •Plano de Teste •Desenho (Projeto) de Teste de Aceitação, Sistema, Integração e Unitário •Casos de Teste de Aceitação, Sistema, Integração e Unitário •Procedimentos de Teste de Aceitação, Sistema, Integração e Unitário •Relatórios de Execução dos Testes Relatório de Estado de Teste Relatório de Teste (sumário) Relatório de Log de Teste Relatório de Anomalias (ex-Relatório de Incidentes) •Relatório Máster de Teste 139 29119-3 • • • • • • • • • • • • • • • • Política Organizacional de Teste Estratégia Organizacional de Teste Plano de Teste Relatório de Estado do Teste Relatório de Término do Teste Relatório de incidente (ver teste dinâmico) Lista de itens de ação Relatório de teste estático Especificação de teste – Especificação de desenho de teste – Especificação de caso de teste – Especificação de procedimento de teste Requisitos de dados de teste Requisitos de ambiente de teste Relatório de situação de ambiente de teste Conseqüências (gerados por CT) do teste Resultados (se o CT passou ou não) do teste Log de execução do teste Relatório de incidente IEEE 829-2008 •Plano Máster de Teste •Plano de Teste •Desenho (Projeto) de Teste de Aceitação, Sistema, Integração e Unitário •Casos de Teste de Aceitação, Sistema, Integração e Unitário •Procedimentos de Teste de Aceitação, Sistema, Integração e Unitário •Relatórios de Execução dos Testes Relatório de Estado de Teste Relatório de Teste (sumário) Relatório de Log de Teste Relatório de Anomalias (ex-Relatório de Incidentes) •Relatório Máster de Teste 140 Processo convencional em relação aos processos da norma Processos de gerência de teste Processos de teste dinâmico Planejar Testes Projetar Testes Executar Testes Gerenciar Defeitos Analisar Resultados O que faltou? Processo de teste organizacional Processo de gerência de teste •Monitoramento e Controle de Teste Processos de teste dinâmico •Configuração do ambiente de teste 141 Relatório de Estado • Relatório emitido durante o andamento do projeto, conforme definido no Plano de Teste (Plano de Comunicação), que demonstra o andamento do projeto, especificamente se ele está seguindo o que foi planejado ou se precisa de alguma correção. • Por exemplo, pode conter uma lista de casos de teste já executados, estatísticas de defeitos encontrados por casos de teste ou tipos de defeitos, comparação entre o previsto e o realizado, etc. 142 Atividades Executadas no Teste • • • • • • • • • • • Participação na revisão da documentação de desenvolvimento; Elaboração da lista de requisitos de teste usando os requisitos do sistema; Elaboração do Planejamento dos Testes (Plano de Testes com a Estratégia de Testes); Preparação do ambiente de testes Elaboração dos Casos de Teste; Preparação da massa de teste; Execução dos testes (programas e scripts); Registro dos defeitos encontrados; Documentação dos resultados do teste; Revisão dos resultados do teste; Manutenção da documentação de testes (bibliotecas de casos de testes, etc.) Fonte: Fátima Mattos, Eficácia no Teste de Sistemas 143 O que mais podemos fazer para melhorar os nossos testes? 144 Em que precisamos pensar para iniciar corretamente o teste da caneta? E o site na internet do RicoSurf? 145 Como melhorar os testes? Escolher um (ou mais) processos de testes adequada e integrada ao processo de desenvolvimento (já vimos) Estruturar uma área orientada para testes e com pessoal capacitado ( veja Ambiente de Teste) Utilizar um ambiente de testes adequado Utilizar ferramentas de automação dos testes (se for o caso) Utilizar regras de medição do projeto de testes Utilizar mecanismos de aferição do nível de maturidade do processo de testes visando conseguir melhorias contínuas Usar técnicas de gerência de projetos (PMI) 146 Recursos Humanos Líder do Projeto de Testes LT Técnico responsável pela liderança de um projeto de teste Arquiteto de Teste AT É o técnico responsável pela montagem da infra-estrutura de teste Analista de Teste AN É o técnico responsável pela modelagem e elaboração dos casos de teste e pelos “scripts” de teste Testador TE Técnico responsável pela execução dos casos de teste e “scripts” de teste Atenção: As terminologias usadas para identificar os técnicos da área de testes podem variar entre organizações. Além disso em algumas empresas um único técnico pode representar 147 diversos papéis. Preparação do Ambiente Atributos Unitário Integração Sistema Aceitação Escopo Unidade Individual Unidades agrupadas Sistema Inteiro Simulação da Produção Equipe Desenvolvedores Desenvolvedores e Testadores Testadores Testadores e Usuários Volume de dados Pequeno Pequeno Grande Grande Criação Manual Criação Manual Criação por processos Dados Reais Interfaces Não existem Não existem Simuladas Reais/Simuladas Ambiente Desenvolvimento Desenvolvimento Teste Produção Origem dos dados 148 NÍVEL Práticas do Processo de teste • • • • • • • • • • • • • • • • • • • • Metodologia de teste Ciclo de vida Nível de envolvimento Estimativas e planejamento Técnicas de especificação de teste Técnicas de teste estático Métricas Ferramentas de teste Ambiente de teste Ambiente de escritório Motivação e comprometimento Funções e treinamento da equipe Metodologia Comunicação Relatórios Gerência de defeitos Gerência de testware Gerência do processo de teste Avaliação Teste estruturais, tais como teste de segurança, teste de carga, etc. 149 Estrutura Organizacional Gerência de TI Gerência de Teste Gerência de Projeto A Gerência de Projeto n Estruturas organizacionais dependem muito da forma de atuar da empresa, logo podem variar entre uma e outra instituição. O importante é preservar a filosofia de atuação da equipe de testes. 150 Momento da Preparação • O ambiente de teste pode ser preparado em 2 momentos: – Estratégia de teste – Plano de teste 151 Revisão O que compõe o ambiente de teste? 152 O teste da caneta esferográfica Ambiente de Teste 153 Como melhorar os testes? Escolher uma metodologia de testes adequada e integrada ao processo de desenvolvimento Estruturar uma área orientada para testes e com pessoal capacitado Utilizar um ambiente de testes adequado Utilizar ferramentas de automação dos testes Utilizar regras de medição do projeto de testes Utilizar mecanismos de aferição do nível de maturidade do processo de testes visando conseguir melhorias contínuas Usar técnicas de gerência de projetos (PMI) 154 Ciclo de Teste Esforço despendido (horas) para testar Casos de Uso Simples Manual Intermediário Automat Manual Automat Complexo Manual Automat 1 6,0 10,07 12,0 23,01 16,0 29,64 2 12,0 10,37 24,0 23,41 32,0 30,32 3 18,0 10,67 36,0 23,81 48,0 31,00 4 24,0 10,97 48,0 24,21 64,0 31,68 5 30,0 11,27 60,0 24,61 80,0 32,36 Fonte: Instituto Atlântico – Fortaleza – CE - 2006 155 Considerações sobre automação para testar casos de uso (ver adiante): Casos de uso simples – poucas transações de interações com os usuários e/ou regras de negócio simplórias Casos de uso intermediários – poucas regras de negócio e uma forte interação do usuário com a aplicação, por meio de operações do tipo CRUD (Create, Read, Update e Delete) Casos de uso complexos – incorporam regras de negócio específicas do domínio da aplicação [Liane R. P. Bandeira – Qualidade do Produto a partir de Automação de Casos de Teste – Universidade Estadual do Ceará – 2005] 156 Quando se deve pensar em automatizar testes? Quando: Existirem fortes pressões para melhorar a qualidade; O projeto tiver situações que não possam ser testadas adequadamente pelos métodos tradicionais; O perfil dos softwares desenvolvidos forem complexos e com impacto no negócio; Estudos de custo/benefício justificarem o investimento; O tamanho do projeto ou do ambiente de teste justificarem. Obs.: Avaliar a possibilidade do uso de ferramentas abertas e livres 157 Considerações para automação de testes Ferramentas de mercado; • • • • • • • • HP Rational Segue Empirix Mercury Test Complete Test Link Mantis ........ Software Livre • Lembre-se que existem ferramentas disponíveis no mercado que podem ser utilizadas e que estão disponíveis em sites da internet para serem baixadas. • Pequenos desenvolvedores não possuem recursos para comprar ferramentas caras. 158 159 160 Ferramenta livres para teste de carga em ambiente Web 161 Teste de Carga com a ferramenta DieselTest no site da ALATS Máximo de 25 usuários Tempo de carga Script criado para o teste Tempo de carga de cada página Usuários “logados” 162 Teste de Carga com a ferramenta DieselTest no site da ALATS Máximo de 50 usuários Tempo de carga Usuários “logados” 163 Estimativas Conceitos básicos O que se quer estimar? » Tamanho » Esforço » Custo » Prazo 164 Conceitos básicos TAMANHO ESFORÇO CUSTO PRAZO 165 Estimativa e gerência de projeto Recursos desviados Falta equipe quando planejado Funcionalidades removidas Requisitos retirados estimativa PROJETO Requisitos acrescentados Equipe menos experiente Equipe atendendo outro projeto Novos recursos acrescentados 166 Se você não consegue medir só existe uma razão para você acreditar que ainda tem o projeto sob o seu controle: otimismo histérico. Tom de Marco. Não se pode gerenciar o que não se pode medir. 167 Métricas usadas em projetos de teste de software • Análise de Ponto de Teste • Ponto de Caso de Teste • Complexidade de Requisitos • Complexidade de Casos de Uso 168 Distribuição entre as etapas de teste Preparação Especificação Execução Transição 10% 40% 45% 5% Cada ambiente tem os seus próprios números Para aqueles que querem um número mágico para estimativas rápidas sugerimos um valor entre 1 e 2 horas de teste por ponto de função. No entanto cabe lembrar que são valores médios de mercado e nem sempre correspondem a um projeto de teste específico. 169 Estimativas de Capers Jones – livro Estimating Software Costs Cada estágio de testes poderá remover 30% dos defeitos existentes. Um sistema com 100PF teria potencialmente 316 defeitos. Neste caso, por exemplo, depois de 3 estágios de testes (TSU, TI e TS) ainda restaram 108 defeitos que iriam para os testes de aceitação com o usuário. 170 Boas métricas devem permitir que o gerente possa responder as seguintes perguntas: Por que os testes estão demorando tanto? Por que os testes ainda não terminaram? Quantos defeitos ainda podem ocorrer em produção? Quantos testes ainda serão necessários? Quando os testes terminarão? Quando os testes começarão a ser feitos pela equipe de testes/ Qual a qualidade do sistema testado? Quando o sistema poderá entrar em produção? Quantos defeitos foram encontrados e qual a sua classifação? 171 Outras métricas Número de defeitos / tamanho do software Número de defeitos / casos de teste Número de defeitos classificados por tipo, severidade, etc. Número de horas de teste (defeitos, casos de teste) por ponto de função Custo por defeito Etc. 172 Revisão Quando eu termino um projeto de teste de software? No caso do teste da caneta qual seria esse momento? Quando eu suspendo um projeto de teste de software? 173 MPT.Br Melhoria do Processo de Teste Brasileiro 174 O que é o modelo? • • O MPT.Br é um modelo que trata a melhoria do processo de teste através de melhores práticas. Objetivos: – Tornar-se um modelo de referência para definição, implantação e melhoria dos processos de teste; – Abordar a melhoria contínua nos processos de teste conforme os objetivos organizacionais e nível de maturidade almejado; – Fornecer uma base para avaliação e consequente identificação do grau de maturidade presente nas organizacionais; e – Reunir as melhores práticas e estruturá-las segundo o grau de complexidade versus o nível de maturidade que a mesma estará relacionada. 175 Modelo de Gestão • • SOFTEXRECIFE - Centro de Tecnologia de Software para Exportação do Recife, sociedadecivil sem fins l ucrativos, agente da Sociedade SOFTEX, que no Brasil possui mais de 1.000 empresas associadas. Sua missão é articular, fomentar e apoiar ações direcionadas à excelência do setor de software em Pernambuco. RIOSOFT - fundada em 1993 a partir do Programa SOFTEX 2000, com a combinação de ideais da classe empresarial atuante em Tecnologia da Informação e a vontade política da Prefeitura da Cidade do Rio de Janeiro, contando também com o apoio do SEBRAE-RJ, da ASSESPRO-RJ e do SEPRORJ. 176 Referências do Modelo • TMMi – Test Maturity Model Integration (versão 3.1): – desenvolvido para complementar o framework do CMMi; – organizado em 5 níveis de maturidade; – As 5 áreas de processo de qualidade abordam, dentre outros aspectos, o processo de testes e seu ciclo de vida, avaliação e controle da qualidade do produto; • ISO 29119 – Já vimos anteriormente 177 Estrutura do Modelo Base de Conhecimento ISTQB/CSTE/CBTS MPS.BR CMMI Referencial Teórico TMMI (versão 3.1) ISO 29119 •Conselho Consultivo •Conselho Técnico •Unidade Executora •Instituição Avaliadora •Instituição Implementadora •Implementador MPT.Br •Avaliador MPT.Br Modelo Gestão Modelo de Referência Modelo de Avaliação •SCAMPI •Modelo de Avaliação MPS.BR 178 Níveis de Maturidade Controle Estatístico do Processo Otimização do Processo de Teste Automação de Teste Gestão de Ferramentas Case Gestão de Defeitos Teste Não Funcional Avaliação da Qualidade do Software Organização do Teste (evolução) Automação e Otimização Prevenção de Defeitos Definido Gerenciado Parcialmente Gerenciado Organização do Teste Medição e Análise Teste estático Treinamento Garantia da Qualidade Teste de Aceitação Fechamento de Teste Gerência de Projeto de Teste (Evolução) Projeto e Execução do Teste (Evolução) Gerência de Requisitos de Teste Gerência de Projeto de Teste (Evolução) Projeto e Execução do Teste (Evolução) Gerência de Projeto de Teste Projeto e Execução do Teste 179 Site do MPT.BR 180 www.mpt.org.br Empresas que implementaram Empresas Avaliadas Data da Avaliação BisaWeb Brisa Brisa Brisa Brisa Cartello DATASUS FTS LTDA GCF Sistemas LTDA In Forma Software LTDA Informata iTeste Partec Procenge LTDA WPD Informática LTDA 20/12/11 13/03/12 13/03/12 26/07/12 15/05/12 14/02/12 17/03/10 04 e 05/04/11 15/05/12 12/11/10 10/05/12 22/11/11 29/11/10 30/11/10 12/11/10 Nível Estado Nível 1 Nível Nível Nível Nível Nível Nível Nível SE Nível Nível Nível Nível Nível Nível Nível 1 2 1 1 2 1 1 PE BA RJ DF SP PE RJ 1 1 1 2 1 1 1 PE PE PE RJ PE PE PE 181 Evolução / Planejamento do MPT.Br 182 Ano Nível Nível Nível Nível Nível Total 1 2 3 4 5 2010 5 - - - - 5 2011 2 1 - - - 3 2012 (*) 5 3 1 Total previsto 2013 (estimativa) 9 17 36 3 3 42 (*) Até o final de 2012 uma empresa será avaliada no nível 1, uma no nível 2 e uma no nível 3 Um empresa do nivel 1 deverá passar para o nivel 2. • Estrutura Organizacional – Comitê Gestor • Softex Recife • Riosoft (Agente Softex RJ) – Conselho Consultivo – Conselho Técnico – Unidade executora – Instituição Avaliadora – Instituição Implementadora – Implementador MPT Quanto maior o nível de maturidade tanto mais estável será o caminho dos projetos de teste de software Estimativa “boa” Boeing Company 150 Erro na estimativa % • Empresas com níveis altos de maturidade tendem a acertar mais nas estimativas 50 -50 -150 1 2 3 4 5 CMMI Level 185 Algumas atividades num projeto de teste de software • • • • Participação na revisão da documentação de desenvolvimento; Elaboração da lista de requisitos de teste usando os requisitos do sistema; Elaboração do Planejamento dos Testes (Plano de Testes e Estratégia de Testes); Preparação do ambiente de testes Elaboração dos Casos de Teste; Preparação da massa de teste; Execução dos testes (programas e scripts); • • • • Registro / acompanhamento dos defeitos encontrados; Documentação dos resultados do teste; Revisão dos resultados do teste (indicadores); Manutenção da documentação de testes (bibliotecas de casos de testes, etc.) • • • 186 Algumas atividades num projeto de teste de software Participação na revisão da documentação de Planejar desenvolvimento; • Elaboração da lista de requisitos de teste usando os requisitos do sistema; • Elaboração do Planejamento dos Testes (Plano de Testes e Estratégia de Testes); Especific • Preparação do ambiente de testes ar • Elaboração dos Casos de Teste; Gerenci Executa• Preparação da massa de teste; ar r • Execução dos testes (programas e scripts); defeitos • Registro / acompanhamento dos defeitos encontrados; • Documentação dos resultados do teste; Encerrar• Revisão dos resultados do teste (indicadores); 187 • Manutenção da documentação de testes (bibliotecas de • Revisão Geral 188 Primeira Empresa Brasileira com certificação Nível 2 Quais são os níveis de teste? • • • • Teste Teste Teste Teste Unitário ou Teste de Componente de Integração de Sistemas de Aceitação Defina Teste Caixa Branca e Teste Caixa Preta? 189 Revisão Quando os testes devem ser iniciados? • R.: O quanto antes (na fase de planejamento) Quais os documentos que devem ser usados num processo básico de teste de software? • R.: Estratégia de Teste, Plano de Teste, Casos de Teste, Relatório de Defeitos. Para que serve a Estratégia de Teste? • R.: Riscos x testes. Características de qualidade x testes. Módulos x testes. Definir as dimensões de teste que serão usada. Etc. 190 Revisão O que compõe o ambiente de teste? • • • • • • Hardware Software Ferramentas de automação Pessoal Local de trabalho Etc. 191 Considerações finais 192 Quadrilátero endemoniado Tempo Qualidade Funcionalidade Quando aumentam as pressões sobre o tempo e o dinheiro a tendência é reduzir os testes de funcionalidades e a qualidade dos testes Dinheiro Obs.: Demonic Quadrangle – M.Pol, E. Veenendaal, R. Teunissen 193 Balança Perigosa Orçamento Cobertura dos riscos Se não fosse o orçamento ( e o tempo) os testes poderiam eliminar todos os riscos 194 Bibliografia • Teste de Software, Editora Altabooks, 2a. Edição - Emerson Rios e Trayahu Moreira • Análise de Riscos em Projetos de Teste de Software, Editora Altabooks, Emerson Rios • Software Testing, Addison Wesley, Martin Pol, Erik Van Veenendaal e outros. • Managing the Testing Process, Microsoft Press, Rex Black • Test Process Improvement, Addison Wesley, Martim Pol e Tim Koomen • Qualidade de Software, Editora Prentice Hall, Ana Regina Cavalcanti da Rocha e outros. • Base de Conhecimento em Teste de Software, Editora Martins Fontes, Aderson Bastos, Emerson Rios, Ricardo Cristalli, Trayahu Moreira. • Garantia de Qualidade de Software, Editora Camus, Alexandre Bartiê. • Documentação de Teste de Software – Ed Imagem Art Studio – 2a edição – Emerson Rios • Gerenciando Projetos de Teste de Software – Ed Imagem Art Studio – Emerson Rios, Ricardo Cristalli, Trayahu Moreira. 195 FIM Um bom testador deve estar sempre aprendendo. Emerson Rios [email protected] 196