Workshop de Testes Conceitos Básicos PROSOFT Workshop de Testes Conceitos Básicos Daniel Leitão Juliana Xavier Setembro/ 2010

Agenda Histórico Definições Dimensões do Teste Casos de Teste Estágios Técnicas Tipos Casos de Teste Testes Exploratórios 2

Histórico Visão Histórica da Execução dos Testes Demonstração – Década de 70 Garantir que o produto funciona; Testes feitos pelos desenvolvedores. Detecção – Década de 80/90 Garantir que o produto atende aos requisitos; Testes feitos pelos desenvolvedores e usuários. Prevenção – Década de 90/00 Garantir que o produto funciona, atende aos requisitos e não tem defeitos; Testes feitos pelos desenvolvedores, usuários e testadores.

Definições “É um processo de exercitar um software ou componente sob condições específicas, observando ou gravando os resultados, e realizando uma avaliação sobre algum aspecto”. (IEEE) “Processo de executar um programa ou sistema com a intenção de encontrar defeitos”. (Glen Myers, 1979) “Qualquer atividade que a partir da avaliação de um atributo ou capacidade de um programa ou sistema seja possível determinar se ele alcança os resultados desejados” (Bill Hetzel, 1988) A primeira definição se refere ao teste negativo

Importância dos Testes PMBOK, 2008

Regra 10 de Myers Regra 10 de Myers Custo em U$ do defeito 12000 10000 8000 6000 4000 2000 The Art of Software Testing – Glenford Myers

Regra 10 de Myers The Art of Software Testing – Glenford Myers O custo aumenta aproximadamente em 10x de uma fase para outra. The Art of Software Testing – Glenford Myers

Importância dos Testes Para quem ainda duvida veja o que Myers afirmou Os testes unitários podem remover entre 30% e 50% dos defeitos dos programas Os testes de sistemas podem remover entre 30% e 50% dos defeitos remanescentes Dessa forma, os sistemas podem ir para produção ainda com aproximadamente 49% de defeitos Por último, ele afirma que revisões de código podem ainda reduzir entre 20% e 30% desses defeitos

Importância dos Testes Por que os testes executados pelos desenvolvedores não atendem? Desenvolvedores não são técnicos de teste, ou seja, não são testadores Desenvolvedores são mais sujeitos a pressões de prazo e custo do que uma equipe apartada Em geral, não possuem ferramentas, metodologia etc.

Importância dos Testes Quanto mais crítico for o software Mais testes serão gastos para o controle da qualidade do produto Logo, quem define a quantidade de testes é a criticidade do negócio 10

Papel do Testador É tudo na limpeza!

Garantia de Qualidade x Controle de Qualidade Garantia da Qualidade de Software Foco no processo Prevenção Controle de Qualidade de Software Foco no produto Detecção CMMI

Controle de Qualidade Está relacionado a um produto ou serviço específico Verifica se um produto ou serviço específico tem um atributo específico Identifica defeitos com o propósito principal de corrigi-los A disciplina de testes está nesse âmbito

Garantia de Qualidade Ajuda a estabelecer e avaliar processos Identifica fraquezas em processos e os aperfeiçoa Avalia se o controle de qualidade está funcionando SEPG e Equipe de Qualidade estão nesse âmbito

Dimensões do Teste (IEEE) Técnica de Teste (como testar) Tipos de Teste (o que testar) Estágios ou Níveis de Teste (quando testar)

Estágios de Teste Unidade Integração Sistema Aceitação

Teste Unitário Estágio mais baixo da escala de testes Verifica o funcionamento de um pedaço do software que possa ser testado isoladamente Falar da ferramenta Junit, PHPUnit.

Teste Unitário Sempre que possível, deve ser automatizado Normalmente feito pelo programador na etapa de implementação Falar da ferramenta Junit, PHPUnit.

Teste de Integração Verifica se os componentes funcionam corretamente juntos, conforme as especificações É alimentado pelos módulos previamente testados individualmente pelo teste de unidade

Teste de Integração Em geral, é feito ao término de cada iteração, dentro de um ambiente operacional controlado Normalmente feito pelo Analista de Sistemas para um módulo ou conjunto de programas

Teste de Sistema Visa a execução do sistema como um todo ou um subsistema (parte do sistema), dentro de um ambiente operacional controlado

Teste de Sistema Valida a exatidão e perfeição na execução das funções São realizados pela Equipe de Testes

Teste de Aceitação Verifica se a solução atende aos objetivos do negócio e a seus requisitos, no que diz respeito à funcionalidade e usabilidade, antes da utilização no ambiente de produção

Teste de Aceitação São os testes finais da execução do sistema, realizados pelos usuários Executado no ambiente de homologação Falar que o objetivo é achar erros de requisitos

Modelo em V CRAIG e JASKIEL, 2002 Figura 3. Modelo V descrevendo o paralelismo entre as atividades de desenvolvimento e teste de software (CRAIG e JASKIEL, 2002) Modelo em V CRAIG e JASKIEL, 2002

Técnicas de Teste

Testes Caixa Preta Visam verificar a funcionalidade e a aderência aos requisitos em uma ótica externa ou do usuário Não se baseiam em qualquer conhecimento do código ou da lógica interna do componente testado 27 27

Testes Caixa Branca Visam avaliar as cláusulas de código, a lógica interna do componente codificado, as configurações e outros elementos técnicos Também conhecidos como Testes de Caixa de Vidro 28 28

Tipos de Teste RUP 29

Funcionalidade Teste Funcional Teste de Regressão Teste de Volume Teste de Segurança

Funcionalidade Teste Funcional Teste destinado a validar as funções do sistema conforme o esperado Fornece as entradas e compara as saídas da execução do teste com o resultado esperado Pode ser implementado e executado em diferentes estágios de teste, como unidade, integração e sistema

Funcionalidade Teste de Regressão Visam garantir que mudanças realizadas não geraram impactos negativos no sistema Existem vários níveis de regressão Regressão Total Regressão Básica Regressão Seletiva Em geral, sempre que possível devem ser automatizados http://it.toolbox.com/blogs/enterprise-solutions/conducting-regression-tests-17638

Funcionalidade Teste de Volume Tem como objetivo verificar a capacidade do sistema de lidar com um grande volume de dados Abrange estratégias de teste, como a entrada de dados no volume máximo de cada campo ou a criação de consultas que retornem um grande volume de dados Exemplos: Relatórios com o período máximo permitido (1 ano, 2 anos etc) Inserção de arquivos no BD com o tamanho máximo permitido (500 MB, 1 GB etc) Exemplos de inclusão de imagens com tamanho máximo nos arquivos do BD.

Funcionalidade Teste de Segurança Testes destinados a garantir que as funcionalidades e os dados possam ser acessados apenas por determinados atores Devem validar os requisitos de segurança definidos para o sistema Objetivos Detectar vulnerabilidades Verificar robustez do sistema frente a determinados tipos de ataques CID Tipos de Ataque = SQL Injection

Usabilidade Testes de Usabilidade Enfatizam: Interface com o usuário Acessibilidade Estética Ajuda on-line e contextual Adequação a padrões Não esquecer de utilizar o padrão de interface visual do TJPE !!!

Confiabilidade Teste de Integridade Teste de Estrutura Teste de Estresse Teste de Fumaça (Smoke Test)

Confiabilidade Teste de Integridade Teste de Estrutura Testes destinados a avaliar a robustez do sistema (resistência a falhas) Pode ser implementado e executado em vários níveis (unidade, integração, sistema) Teste de Estrutura Em geral, é executado em aplicativos Web Verifica se todos os links estão conectados, que o conteúdo esperado é exibido e que não há link órfão

Confiabilidade Teste de Estresse Teste de Fumaça (Smoke Test) Destinado a avaliar como o sistema responde em condições anormais de uso O estresse no sistema pode abranger carga de trabalho extrema, memória insuficiente, hardware e serviços indisponíveis ou recursos compartilhados limitados Teste de Fumaça (Smoke Test) Executam testes básicos para verificar a estabilidade da versão Podem ser executados pela equipe de testes ou por outra equipe

Desempenho Teste de Carga Tipo de teste de desempenho usado para validar a aceitabilidade dos limites operacionais de um sistema de acordo com cargas de trabalho variáveis, enquanto a configuração permanece constante Durante os testes de carga, vários atributos do sistema são medidos Tempo de resposta de cada requisição, uso da CPU, uso da memória, tráfego de rede, etc Mostrar o relatório do SICASE

Suportabilidade Teste de Configuração Teste de Instalação Teste destinado a garantir que o sistema funcione conforme o esperado em diferentes configurações de hardware e/ou software Exemplos: Navegadores, Servidores de Aplicação, Banco de Dados, etc Teste de Instalação Teste destinado a garantir que o sistema seja instalado conforme o esperado em diferentes configurações de hardware e/ou software Configuração, o sistema já está funcionando. E instalação, é testar o processo de instalação.

Casos de Teste É um conjunto de entradas de teste, condições de execução e resultados esperados desenvolvidos para um objetivo específico Os casos de testes funcionais devem conter: Identificação Única (Ex: CT001) Objetivo Pré-condições Passos (Ação e Resultado Esperado) Pós-condições

Casos de Teste Em geral, estão associados a um requisito Podem ser: Positivos: têm como objetivo demonstrar que o requisito foi atendido Negativos: refletem uma condição ou dados inaceitáveis, anormais ou inesperados para demonstrar que o sistema responde da forma esperada NEGATIVOS: Entradas fora do domínio, excluir usuário inexistente, etc

Derivação de Casos de Teste Os casos de teste funcionais são derivados a partir dos cenários dos casos de uso

Derivação de Casos de Teste Passos para derivação dos casos de teste (Heumann) : Para cada caso de uso, gerar uma lista de cenários Para cada cenário, identificar, ao menos, um caso de teste e a condição que o farão ser executado Para cada caso de teste, identificar os dados que serão utilizados

Casos de Teste Exemplo:

Testes Exploratórios O que são testes exploratórios? “Testes em que o testador controla ativamente o design dos testes durante a execução e utiliza informações adquiridas para projetar novos e melhores testes” James Bach, “Exploratory Testing Explained”

Testes Exploratórios Simultaneamente Aprender sobre o produto Aprender caminhos em que o produto falha Aprender os pontos fracos do produto Aprender como testar o produto Testar o produto Reportar problemas Desenvolver novos testes com o que foi aprendido até o momento

Testes Exploratórios Todo testador pratica exploração em algum nível Desde os testes com roteiro aos testes ad-hoc Em que nível o seu teste é exploratório?

Testes Exploratórios Como funciona Durante um período de tempo (sessão), o testador interage com o produto para executar uma “missão de teste” e reportar os resultados Sessão Tempo Testador Produto Missão Relatório

Testes Exploratórios Sessão O testador recebe uma cartilha (fornecida pelo líder de testes) que contém a missão e, possivelmente, táticas a serem usadas Em algumas organizações, casos de testes e procedimentos podem ser usados como cartilhas Não deve ser muito longa Depende do objetivo da sessão, mas uma sessão típica dura em torno de 90 minutos

Testes Exploratórios Sessão É uma unidade básica de teste Deve ser ininterrupta E-mails, telefonemas, conversas devem ser evitados Revisável Para isso, o relatório deve estar em um formato possível de ser entendido por terceiros (o gerente do projeto, por exemplo)

Testes Exploratórios Exemplo de cartilha Teste todos os campos de entrada da tela “Inserir Produto”. Lembre-se de testar limites e dados inválidos. A primeira frase estabelece a missão A segunda, táticas a serem usadas

Testes Exploratórios Possível formato para relatório de sessão Cartilha Testador Data/Hora Observações Bugs Questionamentos

Testes Exploratórios Habilidades Projetista de testes Observador Todo testador exploratório é, em primeira instância, um projetista / arquiteto de testes Observador Testadores experientes diferem de novatos por perceberem mais facilmente comportamentos “não usuais” Crítico Um bom testador deve ser capaz de revisar e explicar sua lógica de achar um bug

Testes Exploratórios Habilidades Crítico Explorador de recursos Testadores experientes tendem a usar mais heurísticas para produzir novas e melhores idéias Explorador de recursos Um bom testador deve estar munido de ferramentas, informações e ter contato com pessoas que possam ajudar

Testes Exploratórios X Testes com Roteiro Conhecimento do domínio Com roteiros Falta de conhecimento pode ser minimizado durante a fase de projeto de testes Com exploração Não é possível prosseguir quando o conhecimento do domínio é insuficiente Treinamentos podem ser utilizados, mas introduzem overhead

Testes Exploratórios X Testes com Roteiro Complexidade do Sistema Com roteiros Possibilita um projeto de testes cuidadoso que se preocupa com as dependências entre os testes Com exploração Reside na experiência do testador para gerenciar as dependências entre os testes

Testes Exploratórios X Testes com Roteiro Nível de documentação Com roteiros Requer vasta e boa documentação Com exploração Não requer documentação (assumindo grande conhecimento do domínio)

Testes Exploratórios X Testes com Roteiro Prazos Com roteiros Requer tempo para preparação Com exploração Não requer grande tempo inicial para preparação

Testes Exploratórios X Testes com Roteiro Recursos Disponíveis Com roteiros Requer maior consumo de recursos (mais pessoas) Com exploração Ideal quando há limitação grande de recursos

Testes Exploratórios X Testes com Roteiro Habilidades Necessárias Com roteiros Requer grande habilidade dos envolvidos na análise e projeto dos testes; na execução, pode usar testadores com poucas habilidades Com exploração Requer testadores habilidosos na arte da exploração

Testes Exploratórios X Testes com Roteiro Cobertura Com roteiros Há rastreabilidade entre os testes e os requisitos / especificações que os originaram. Dessa maneira, pode-se calcular a cobertura Com exploração Não há como calcular a cobertura de maneira precisa

Testes Exploratórios X Testes com Roteiro Verificação Com roteiros Verifica formalmente se o sistema está de acordo com a sua especificação Com exploração O sistema é comparado apenas com as expectativas e o entendimento do testador sobre o que a aplicação deveria fazer

Testes Exploratórios X Testes com Roteiro Facilidade de reprodução Com roteiros Pode ser facilmente reproduzido Com exploração Apenas defeitos podem ser reproduzidos, os testes não.

Dúvidas | Sugestões SEPG: dinfo.sepg@tjpe.jus.br Mantis: “Processo de Software” UTS: dinfo.gedes.testes@tjpe.jus.br Telefone: 3419.3701 65

Workshop de Testes Conceitos Básicos PROSOFT Workshop de Testes Conceitos Básicos Daniel Leitão Juliana Xavier Setembro/ 2010