V 1.0 Projeto DPES-FNDE 21/03/2007



Documentos relacionados
Engenharia de Software II

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

GARANTIA DA QUALIDADE DE SOFTWARE

CHECK - LIST - ISO 9001:2000

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

ISO/IEC 12207: Gerência de Configuração

PLANOS DE CONTINGÊNCIAS

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

Plano de Gerenciamento do Projeto

Feature-Driven Development

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

a) Teste das funções do sistema com outros sistemas b) Teste de componentes que em conjunto compõem a função do sistema

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Processos de gerenciamento de projetos em um projeto

c. Técnica de Estrutura de Controle Teste do Caminho Básico

Engenharia de Software

Conteúdo. Disciplina: INF Engenharia de Software. Monalessa Perini Barcellos

Gerenciamento de Riscos do Projeto Eventos Adversos

Projeto de Sistemas I

Fundamentos em Teste de Software. Vinicius V. Pessoni

PR 2 PROCEDIMENTO. Auditoria Interna. Revisão - 2 Página: 1 de 9

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Unidade VI. Validação e Verificação de Software Teste de Software. Conteúdo. Técnicas de Teste. Estratégias de Teste

Engenharia de Requisitos

Fundamentos de Teste de Software

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Gerenciamento de projetos.

Qualidade de Software. Profa. Cátia dos Reis Machado

Teste de Software. Profa. Cátia dos Reis Machado

Universidade Paulista

Metodologia de Gerenciamento de Projetos da Justiça Federal

Análise e Projeto Orientados a Objetos Aula IV Requisitos. Prof.: Bruno E. G. Gomes IFRN

MASTER IN PROJECT MANAGEMENT

QUALIDADE DE SOFTWARE. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

Manual de Utilização

Conceitos de Banco de Dados

CHECK LIST DE AVALIAÇÃO DE FORNECEDORES Divisão:

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Lista de verificação (Check list) para planejamento e execução de Projetos

ENGENHARIA DE SOFTWARE I

LISTA DE VERIFICAÇAO DO SISTEMA DE GESTAO DA QUALIDADE

Manual SAGe Versão 1.2 (a partir da versão )

ADMINISTRAÇÃO DE ATIVOS DE TI GERENCIAMENTO DE LIBERAÇÃO

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

Conteúdo. Disciplina: INF Engenharia de Software. Monalessa Perini Barcellos

1 Inicie um novo. Guia de Referência Rápida de Gerenciamento de Projeto para o Project projeto

SISTEMAS INTEGRADOS DE GESTÃO PAS 99:2006. Especificação de requisitos comuns de sistemas de gestão como estrutura para a integração

PROFESSOR: CRISTIANO MARIOTTI

APOO Análise e Projeto Orientado a Objetos. Requisitos

Gerenciamento de Problemas

Testes de Software. Testes de Software. Teste de Validação. Teste de Defeito. Modelo de Entrada e Saída. Modelo de Entrada e Saída

Testes de Software. Testes de Software. Teste de Validação. Teste de Defeito. Modelo de Entrada e Saída. Modelo de Entrada e Saída

Planejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP

DIMENSIONANDO PROJETOS DE WEB-ENABLING. Uma aplicação da Análise de Pontos de Função. Dimensionando projetos de Web- Enabling

O modelo unificado de processo. O Rational Unified Process, RUP.

15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função

Tópicos. Atualizações e segurança do sistema. Manutenção Preventiva e Corretiva de Software (utilizando o MS Windows XP)

Módulo 3 Procedimento e processo de gerenciamento de riscos, PDCA e MASP

Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

SUMÁRIO Acesso ao sistema... 2 Atendente... 3

Processo de Implementação de um Sistema de Gestão da Qualidade

MUDANÇAS NA ISO 9001: A VERSÃO 2015

Extração de Requisitos

UNIP Ciência da Computação / Sistemas de Informação TED I - Orientações Gerais para Elaboração dos Documentos

Gerenciamento de software como ativo de automação industrial

2 Diagrama de Caso de Uso

Algoritmos: Lógica para desenvolvimento de programação de computadores. Autor: José Augusto Manzano. Capítulo 1 Abordagem Contextual

Abordagem de Processo: conceitos e diretrizes para sua implementação

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

ENGENHARIA DE SOFTWARE

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

Tipos de teste de software

Engenharia de Software I

Princípios do teste de software

Sistemas de Gestão Ambiental O QUE MUDOU COM A NOVA ISO 14001:2004

TOTVS Série 1 Varejo (Simples) - Módulo e-commerce

Engenharia de Requisitos Estudo de Caso

Concepção e Elaboração

Fundamentos de Teste de Software

Sphinx Scanner Informações gerais V

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

Introdução a listas - Windows SharePoint Services - Microsoft Office Online

Gerenciamento de Projetos Exercícios gerais com questões de concursos anteriores

Sistema de Controle de Solicitação de Desenvolvimento

Capítulo X. Gerenciar Mudanças dos Requisitos. Aluizio Saiter, M. Sc.

Modelo Cascata ou Clássico

Profa. Gislaine Stachissini. Unidade III GOVERNANÇA DE TI

Transcrição:

V 1.0 Projeto DPES-FNDE 21/03/2007

Índice 1 HISTÓRICO DE ATUALIZAÇÃO...4 2 APRESENTAÇÃO...5 3 OBJETIVOS DO TESTE...5 4 PRINCÍPIOS DO TESTE...5 4.1 TESTABILIDADE...6 5 MÉTODO DE TESTE...8 5.1 TESTE CAIXA-PRETA...8 6 FERRAMENTAS DE AUTOMATIZAÇÃO DE TESTES...8 6.1 FUNÇÃO...8 6.2 ESPECIALIZAÇÃO...9 7 CATÁLOGO DE IDÉIAS DE TESTE... 10 7.1 CATÁLOGOS ADEQUADOS... 10 7.2 CRIAÇÃO E MANUTENÇÃO DE SEUS PRÓPRIOS CATÁLOGOS... 10 7.3 LISTA DE IDÉIAS DE TESTE... 11 7.4 O QUE SÃO IDÉIAS DE TESTE?... 11 8 MEDIÇÕES... 12 8.1 MEDIDAS DE COBERTURA... 12 8.2 COBERTURA DE TESTE BASEADA EM REQUISITOS... 13 9 PLANEJAR TESTES... 14 9.1 PLANO DE TESTE... 14 9.1.1 Finalidade... 15 9.2 REQUISITOS DE TESTE... 15 9.2.1 Teste de integridade de dados e BD... 16 9.2.2 Teste funcional... 16 9.2.3 Teste do ciclo de negócio... 16 9.2.4 Teste de Interface de Usuário... 16 9.2.5 Teste de Carga... 17 9.2.6 Teste de Stress... 17 9.2.7 Teste de Volume... 17 9.2.8 Teste de Segurança e Controle de Acesso... 17 9.2.9 Teste de Falha e Recuperação... 17 9.2.10 Teste de Configuração... 18 9.2.11 Teste de Instalação... 18 9.2.12 Teste de Contenção... 18 9.2.13 Teste de Estrutura... 18 10 PROJETAR TESTE... 18 10.1 CASOS DE TESTE... 18 10.1.1 Cenário de Teste... 19 10.1.2 Fluxos (Básico e Alternativos)... 19 10.1.3 Sugestões de Casos de Teste... 19 10.1.4 Massa de Teste... 19 11 PREPARAR AMBIENTE DE TESTE... 20 11.1 FINALIDADE... 20 11.2 OCORRÊNCIAS... 20 12 IMPLEMENTAR TESTES... 21 12.1 PROCEDIMENTO DE TESTE... 21 12.1.1 Finalidade... 21 2

12.1.2 Condições... 21 13 EXECUTAR TESTES... 21 13.1 FINALIDADE... 21 13.2 TIPOS DE EXECUÇÃO... 21 13.3 RECUPERAR A PARTIR DE TESTES INTERROMPIDOS... 22 13.4 RESTAURAR O AMBIENTE DE TESTE AO ESTADO CONHECIDO... 22 14 REGISTRO DE ERROS DA RELEASE... 22 14.1 FINALIDADE... 22 14.2 OCORRÊNCIA... 22 15 AVALIAÇÃO DOS RESULTADOS DOS TESTES... 22 15.1 FINALIDADE... 22 16 DEFINIÇÃO DO CICLO DE TESTE... 23 16.1 PROCEDIMENTOS... 23 17 CONCLUSÃO... 24 ANEXO I - SUGESTÕES PARA FERRAMENTAS DE TESTE... 25 3

1 Histórico de Atualização Data Atividade Autor Versão 12/03/2007 Criação do documento Pedro Garcia (Borland) 1.0 21/03/2007 Revisão do documento Pedro Garcia (Borland) 1.0 01/06/2007 Revisão do documento Pedro Garcia (Borland) 1.1 4

2 Apresentação A atividade de teste de software é um elemento crítico da garantia da qualidade de software e representa a última revisão de especificação, projeto e codificação. Deve-se testar o mais cedo possível e tantas vezes quanto necessário. A cultura do teste cria um ambiente favorável para detecção de erros e contribui para a sua rápida identificação pelos profissionais de teste. O desenvolvimento de sistemas de software envolve uma série de atividades de produção em que as oportunidades para injetar a falibilidade humana são enormes. Erros podem vir a ocorrer até no início do processo, onde os objetivos podem ser errônea ou imperfeitamente especificados, bem como em estágios posteriores de projeto e desenvolvimento por causa da inabilidade humana de realizar e de se comunicar com perfeição, o desenvolvimento é acompanhado por uma atividade de garantia de qualidade. 3 Objetivos do Teste Num excelente livro sobre teste de software, Glen Myers enumera algumas regras que podem servir bem como objetivos de teste: Teste é um processo de execução de um programa ou sistema com a finalidade de encontrar erros, falhas; Um bom caso de teste é aquele que tem alta probabilidade de encontrar um erro ainda não descoberto; Um teste bem-sucedido é aquele que descobre um erro ainda não descoberto. Se o teste for conduzido de maneira bem-sucedida, ele descobrirá inconsistências no software. Como benefício secundário, o teste demonstra que as funções do software parecem estar funcionando de acordo com o especificado e que os requisitos de comportamento e desempenho parecem estar satisfeitos. 4 Princípios do Teste Antes de aplicar métodos para projetar casos de teste efetivos, é necessário entender os princípios básicos que guiam o teste de software. Nos tópicos abaixo estão os principais: Todos os testes devem ser relacionados aos requisitos do Cliente: o objetivo do teste de software é descobrir erros. Segue-se que os defeitos mais indesejáveis são aqueles que levam o programa a deixar de satisfazer os requisitos do Cliente; Os testes devem ser planejados muito antes do início de sua execução: o planejamento de teste pode começar tão logo a especificação de requisitos seja completada. A definição detalhada dos casos de teste pode começar tão logo o modelo de projeto tenha sido consolidado. Assim sendo, todos os testes podem ser planejados e projetados antes que código tenha sido gerado; 5

O princípio de Pareto se aplica ao teste de software: colocado simplesmente, o princípio de Pareto implica que 80% de todos os erros descobertos durante o teste serão provavelmente relacionados a 20% de todos os componentes do programa. O problema, sem dúvida, é isolar os componentes suspeitos e testá-los rigorosamente; O teste deve começar no varejo e progredir até o teste no atacado : os primeiros testes planejados e executados geralmente concentram-se nos componentes individuais. À medida que o teste progride, o foco se desloca numa tentativa de encontrar erros em conjuntos integrados de componentes e finalmente em todo o sistema; Teste completo não é possível: a quantidade de permutações de caminhos, mesmo para um programa de tamanho moderado, é excepcionalmente grande. Por essa razão, é impossível executar todas as combinações de caminhos durante o teste. É possível, no entanto, cobrir adequadamente a lógica do programa e garantir que todas as condições no projeto, em nível de componente, tenham sido exercitadas; Para ser mais efetivo, o teste deveria ser conduzido por terceiros : o desenvolvedor que escreveu o programa não é a pessoa mais adequada para conduzir os testes do software. 4.1 Testabilidade A testabilidade de software é simplesmente a facilidade com que um programa de computador pode ser testado a fim de garantir que ele execute sua função pretendida. Como o teste é profundamente difícil, vale a pena saber o que pode ser feito para facilitá-lo. Algumas vezes, a testabilidade é usada para dizer quão adequadamente um conjunto particular de testes vai cobrir o produto. É percebida pela menor ocorrência de erros e maior confiabilidade. Abaixo segue um conjunto de características que levam a um software testável : Operabilidade : Quanto melhor funciona, mais eficientemente pode ser testado. O sistema tem poucos defeitos; Nenhum defeito bloqueia a execução dos testes; O produto evolui em estágios funcionais, isto é permite desenvolvimento e testes simultâneos. Observabilidade : O que você vê é o que você testa Saída distinta é gerada para cada entrada; Estados e variáveis do sistema são visíveis ou consultáveis durante a execução; Os estados e variáveis anteriores do sistema são visíveis ou consultáveis, por exemplo, registro de transações; Todos os fatores que afetam a saída são visíveis; Saída incorreta é facilmente identificada; Erros internos são automaticamente detectados por meio de mecanismos de autoteste ; Erros internos são automaticamente relatados; O código-fonte é acessível. 6

Controlabilidade : Quanto mais você pode controlar o software, mais o teste pode ser automatizado e otimizado. Todas as saídas possíveis podem ser geradas por alguma combinação de entradas; Todo código é executável através de alguma combinação de entradas; Estados e variáveis do software e do hardware podem ser controlados diretamente pelo engenheiro de teste ; Formatos de entrada e saída são consistentes e estruturados; Testes podem ser especificados, automatizados e reproduzidos convenientemente. Decomponibilidade : Controlando o escopo do teste, podemos isolar problemas mais rapidamente e realizar novos testes mais racionalmente. O sistema de software é construído a partir de módulos independentes; Módulos de software podem ser testados independentemente. Simplicidade : Quanto menos há a testar, mais rapidamente podemos testá-lo. Simplicidade funcional, por exemplo, o conjunto de características é o mínimo necessário para satisfazer os requisitos; Simplicidade estrutural, por exemplo, a arquitetura é modularizada para limitar a propagação de defeitos; Simplicidade do código, por exemplo, um padrão de código é adotado para facilitar a inspeção e a manutenção. Estabilidade : Quanto menos modificações, menos interrupções no teste Modificações no software não são freqüentes; Modificações no software são controladas; Modificações no software não invalidam os testes existentes; O software se recupera bem das falhas. Compreensibilidade : Quanto mais informações disponíveis mais racionalmente vamos testar o software. O projeto é bem compreendido; As dependências entre componentes internos, externos e compartilhados são bem compreendidas; Modificações no projeto são informadas; A documentação técnica é acessível instantaneamente; A documentação técnica é bem organizada; A documentação técnica é específica e detalhada; A documentação técnica é precisa. 7

5 Método de Teste 5.1 Teste Caixa-Preta Também chamado de teste comportamental, focaliza os requisitos funcionais do software para garantir que estão plenamente satisfeitos. Isto é, o teste de caixapreta permite ao analista de teste derivar conjuntos de condições de entrada que vão exercitar plenamente todos os requisitos funcionais de um programa. O teste de caixa-preta não é uma alternativa às técnicas caixa-branca. É uma abordagem complementar que provavelmente descobrirá uma classe diferente de erros do que os métodos caixa-branca. Não é objetivo dos testes de caixa preta verificar como ocorrem os processamentos, mas sim, se estes produzem os resultados esperados. O método de caixa preta não requer conhecimento interno do sistema, mas somente o conhecimento dos requisitos de negócio Tenta encontrar erros das seguintes categorias: funções incorretas ou omitidas, erros de interface, erros de estrutura de dados ou de acesso a base de dados externa, erros de comportamento ou desempenho e erros de iniciação e término. Diferente do teste caixa-branca, que é realizado no início do processo de teste, o teste caixa-preta tende a ser aplicado durante os últimos estágios da execução dos testes. Como o teste caixa-preta despreza, propositalmente, a estrutura de controle, a atenção é focalizada no domínio da informação. Os testes são projetados para responder as seguintes questões: Como a validade funcional é testada? Como o comportamento e o desempenho do sistema são testados? Que classes de entrada vão constituir bons casos de teste? O sistema é particularmente sensível a certos valores de entrada? Como são isolados os limites de uma classe de dados? Que taxas e volumes de dados o sistema pode tolerar? Que efeito as combinações específicas de dados vão ter na operação do sistema? 6 Ferramentas de Automatização de Testes Existem várias ferramentas de automatização, e é improvável que uma única ferramenta seja capaz de automatizar todas as atividades de teste. Geralmente, as ferramentas de teste são avaliadas com base nas seguintes categorias: Função; Caixa branca versus Caixa preta; Especialização. 6.1 Função As ferramentas de teste podem ser caracterizadas pela função que executam. Estas são as designações de funções comuns para ferramentas: Ferramentas de aquisição de dados que adquirem os dados a serem usados nas atividades de teste. É possível adquirir dados através da 8

conversão, extração, transformação ou captura dos dados existentes, ou através da geração a partir de casos de uso ou especificações suplementares. Ferramentas de medição estática que analisam as informações contidas nos modelos de design, no código-fonte ou em outras fontes fixas. A análise produz informações sobre o fluxo lógico, o fluxo de dados ou as métricas de qualidade, como complexidade, capacidade de manutenção ou linhas de código. Ferramentas de medição dinâmicas que executam uma análise durante a execução do código. As medições incluem a operação do código em tempo de execução, como desempenho e detecção de erros na memória. Simuladores ou Geradores que executam atividades que não estão ou não podem estar disponíveis para fins de teste, por questão de tempo, custo ou segurança. Ferramentas de gerenciamento de teste que auxiliam no planejamento, design, implementação, execução, avaliação e gerenciamento dos artefatos ou atividades de teste. 6.2 Especialização Além das amplas classificações de ferramentas apresentadas acima, elas também podem ser classificadas por especialização: Ferramentas de registro/reprodução combinam a aquisição de dados com a medição dinâmica. Os dados de teste são adquiridos durante o registro de eventos (na implementação do teste). Mais tarde, durante a execução do teste, os dados são usados para "reproduzir" o script de teste usado para avaliar a execução do objetivo do teste; Ferramentas de medição de qualidade são ferramentas de medição estáticas que executam uma análise estática dos modelos de design ou do código-fonte para estabelecer um conjunto de parâmetros que descreva a qualidade do objetivo do teste. Os parâmetros podem indicar confiabilidade, complexidade, capacidade de manutenção ou outras medidas de qualidade; Ferramentas de monitoramento de cobertura indicam a abrangência do teste, identificando quanto do objetivo do teste foi coberto, em alguma dimensão, durante o teste. As classes comuns de cobertura incluem casos de uso baseados em requisitos, ramificações ou nós lógicos (baseados em código), estado dos dados e pontos de função; Geradores de caso de teste automatizam a geração dos dados de teste. Eles usam uma especificação formal das entradas de dados do objetivo do teste ou os modelos de design/código-fonte para produzir dados de teste que testem as entradas nominais, entradas de erro e casos de limite e fronteira; Ferramentas de comparação comparam os resultados do teste com os resultados de referência e identificam as diferenças. Os comparadores diferem quanto à especificidade para determinados formatos de dados. Por exemplo, os comparadores podem ser baseados em pixels (para comparar imagens de bitmap) ou em objetos (para comparar propriedades ou dados do objeto); Extratores de dados fornecem entradas para casos de teste provenientes de fontes existentes. As fontes incluem bancos de dados, streams de dados 9

em um sistema de comunicação, relatórios ou modelos de design/códigofonte. 7 Catálogo de Idéias de Teste A maior parte da programação dos testes consiste em aproveitar os itens que têm sido usados ao longo do tempo, utilizando-os mais uma vez em um contexto distinto. Esses itens podem abranger estruturas de dados (como listas vinculadas, tabelas de hashing, bancos de dados relacionais, etc.) ou operações (como pesquisa, classificação, criação de arquivos temporários ou exibição da janela de um navegador). Um desenvolvedor que exibe a janela de um navegador pode cometer um desses erros reincidentes: Criar uma nova janela quando outra já aberta deveria ser reutilizada; Não tornar visível a janela de um navegador que esteja oculta ou minimizada; Usar o Internet Explorer quando o usuário escolheu outro navegador padrão; Não verificar se o Javascript está ativado. 7.1 Catálogos Adequados O que torna um catálogo adequado? Ele contém um pequeno conjunto de idéias de teste que pode localizar um conjunto muito maior de falhas básicas. Ele pode ser examinado superficialmente com facilidade. Você deve ser capaz de ignorar as idéias de teste que não sejam relevantes para a sua situação. Não deve conter idéias de teste que nunca serão utilizadas. Por exemplo, alguém que nunca lida com navegadores da WEB não deve usar idéias de teste referentes a programas que usam navegadores da WEB. Alguém que trabalha com softwares de jogos precisa de um catálogo menor que alguém que trabalha com softwares nos quais a segurança é vital. A pessoa que lida com jogos pode se concentrar apenas nas idéias de teste com maior chance de localizar falhas. Considerando essas regras, é melhor existir mais de um catálogo. Como alguns dados e operações são comuns, as respectivas idéias de teste podem ser incluídas em um catálogo genérico para que todos os Analistas de Teste e Testadores possam usá-las. Outras são específicas de um determinado domínio; por isso, as idéias de teste correspondentes podem ser incluídas em um catálogo de idéias de teste específico do domínio. 7.2 Criação e Manutenção de Seus Próprios Catálogos Como mencionado anteriormente, o catálogo genérico não conterá todas as idéias de teste necessárias. Para que se possa manter um catálogo específico, terá de se criá-lo. Eis algumas sugestões: Deve-se evitar a tentação de preencher um catálogo com especulações sobre quais seriam as idéias apropriadas para a localização de falhas. Cada idéia de teste incluída no catálogo custa tempo e dinheiro: o tempo gasto 10

para manter o catálogo, o tempo de outros testadores para pensar sobre a idéia de teste e para implementá-lo. Adicionar apenas as idéias que tenham um registro de controle demonstrado e que é capaz de apontar pelo menos uma falha real. O ideal é que essas falhas não tenham sido identificadas por outros testes (ou seja, uma falha relatada pelo campo). Uma boa maneira de criar catálogos consiste em percorrer o banco de dados de erros e perguntar como cada falha poderia ter sido detectada anteriormente; A criação e a manutenção de um Catálogo de Idéias de Teste são tarefas que devem ter tempo alocado, como para qualquer outra atividade. 7.3 Lista de Idéias de Teste As informações usadas no design de testes são provenientes de vários locais: modelos de design, interfaces de classificador, diagrama de estados e o próprio código. Em determinado ponto, as informações do documento de origem devem ser transformadas em testes executáveis: Entradas específicas feitas no software em teste; Em determinada configuração de hardware e software; Inicializadas em um estado conhecido; Com resultados específicos esperados. É possível passar diretamente das informações do documento de origem para os testes executáveis. Mas normalmente é útil adicionar uma etapa intermediária. Nela, as idéias de teste são incluídas em uma Lista de Idéias de Teste. A lista é usada para criar testes executáveis. 7.4 O que são Idéias de Teste? Uma idéia de teste (ou requisito de teste) é uma declaração resumida sobre um teste que poderia ser realizado. Como exemplo, vamos utilizar uma função que calcula uma raiz quadrada. Eis uma lista de idéias de teste: Fornecer como entrada um número menor que zero; Fornecer zero como entrada; Testar um número que tenha uma raiz quadrada perfeita, como 4 ou 16 (o resultado é exatamente 2 ou 4?). Cada uma dessas situações poderia ser facilmente convertida em um teste executável com descrições exatas de entradas e resultados esperados. Todos os exemplos de raiz quadrada descrevem entradas, mas as idéias de teste podem descrever qualquer elemento de um teste executável. Por exemplo, "imprimir em uma HP LaserJet" descreve a configuração do teste, enquanto "testar com o banco de dados cheio" descreve a configuração e inicialização do sistema. Essas últimas idéias de teste são em si incompletas. Imprimir o que na impressora? Fazer o que com esse banco de dados cheio? Contudo, elas garantem que idéias importantes não sejam esquecidas, idéias que surgirão posteriormente no design de teste. As idéias de teste geralmente baseiam-se em modelos de falha, noções sobre quais falhas são plausíveis no software e sobre qual a melhor forma de descobri-las. Por exemplo, considere fronteiras. É seguro supor que a função de raiz 11

quadrada seja implementada de maneira semelhante a esta: double sqrt(double x) { if (x < 0) // erro de sinal... É plausível que < seja digitado incorretamente como <=. As pessoas sempre cometem esse tipo de erro; portanto, convém verificar. Não será possível detectar a falha se X tiver o valor 2, pois a expressão incorreta (x<=0) e a expressão correta (x<0) seguirão a mesma ramificação da instrução if. Da mesma forma, se X tiver o valor -5, não será possível encontrar a falha. A única maneira é atribuir a X o valor 0, o que justifica a segunda idéia de teste. Nesse caso, o modelo de falha é explícito. Em outros casos, é implícito. Por exemplo, sempre que um programa manipula uma estrutura vinculada, convém testá-la com uma circular. É possível ocorrer falhas que levem a uma estrutura circular difícil de ser tratada. Para fins de teste, elas não precisam ser enumeradas - basta saber que uma falha é provável o suficiente para justificar a execução do teste. É possível aplicar esses modelos de falha a vários artefatos diferentes. Por exemplo, o primeiro descreve o que fazer com uma expressão booleana. Elas podem ser encontradas no código, em condições de guarda em diagramas de estados e de seqüência, e em descrições de idioma nacional dos comportamentos de método (como pode ser encontrado em uma API publicada). Observe que uma Lista de Idéias de Teste específica pode conter idéias de teste provenientes de vários modelos de falha. Também pode conter idéias de teste derivadas de mais de um artefato. 8 Medições As principais medidas de um teste incluem a cobertura e a qualidade. A cobertura é a medida da abrangência do teste e é expressa pela cobertura dos requisitos e casos de teste ou pela cobertura do código executado. A qualidade é uma medida de confiabilidade, de estabilidade e de desempenho do objetivo do teste (sistema ou aplicativo em teste). Ela se baseia na avaliação dos resultados do teste e na análise das solicitações de mudança (defeitos) identificadas durante o teste. 8.1 Medidas de Cobertura As medidas de cobertura fornecem respostas à pergunta "Qual é a abrangência do teste?". As medidas de cobertura usadas com mais freqüência são a cobertura de teste baseada em requisitos e em códigos. Em resumo, a cobertura de teste é qualquer medida de abrangência relacionada a um requisito (baseada em requisitos) ou a um critério de design/implementação do código (baseada em códigos), como a verificação de casos de uso (baseada em requisitos) ou a execução de todas as linhas de código (baseada em códigos). Qualquer atividade sistemática de teste baseia-se em, pelo menos, uma estratégia de cobertura. Essa estratégia orienta o design de casos de teste declarando a finalidade geral do teste. A declaração da estratégia de cobertura pode ser tão simples quanto verificar todo o desempenho. Se os requisitos estiverem completamente catalogados, uma estratégia de cobertura baseada em requisitos poderá ser suficiente para produzir uma medida quantificável para testar a abrangência. Por exemplo, se todos os requisitos do teste de desempenho foram identificados, é possível fazer referência aos resultados 12

do teste para obter medidas, como 75% dos requisitos do teste de desempenho foram verificados. Se a cobertura baseada em códigos for aplicada, as estratégias de teste serão formuladas em termos da quantidade do código-fonte que foi executada pelos testes. Esse tipo de estratégia de cobertura de teste é muito importante para sistemas de segurança crítica. 8.2 Cobertura de Teste Baseada em Requisitos A cobertura de teste baseada em requisitos é medida diversas vezes durante o ciclo de vida do teste e fornece a identificação da cobertura do teste em um marco desse ciclo (como a cobertura de testes planejados, implementados, executados e bem-sucedidos). A cobertura de teste é calculada pela seguinte equação: Cobertura de Teste = T / RfT onde: T é o número de Testes (planejados, implementados, executados ou bemsucedidos) expressos como procedimentos ou casos de teste. RfT é o número total de Requisitos do Teste. Na atividade Planejar Teste, a cobertura de teste é calculada para determinar a cobertura dos testes planejados e o cálculo é efetuado da seguinte maneira: Cobertura dos Testes (planejados) = T p / RfT onde: T p é o número de Testes planejados expressos como procedimentos ou casos de teste. RfT é o número total de Requisitos do Teste. Na atividade Implementar Teste, à medida que os procedimentos de teste são implementados (como procedimentos de teste), a cobertura de teste é calculada usando a seguinte equação: Cobertura dos Testes (implementados) = T i / RfT onde: T i é o número de Testes implementados conforme expresso pela quantidade de procedimentos ou casos de teste para os quais existem scripts correspondentes. RfT é o número total de Requisitos do Teste. Na atividade Executar Teste, são usadas duas medidas de cobertura. Uma delas identifica a cobertura obtida com a execução dos testes. A outra identifica a cobertura dos testes bem-sucedidos (aqueles que foram executados sem falhas, como defeitos ou resultados inesperados). Essas medidas de cobertura são calculadas pelas seguintes equações: Cobertura dos Testes (executados) = Tx / Rft onde: Tx é o número de Testes executados expressos como procedimentos ou casos de teste. RfT é o número total de Requisitos do Teste. 13

Cobertura dos testes bem-sucedidos (executados) = T s / RfT onde: T s é o número de Testes executados expressos como procedimentos ou casos de teste que foram concluídos com êxito e sem defeitos. RfT é o número total de Requisitos do Teste. A transformação das relações anteriores em porcentagens permite a seguinte declaração sobre a cobertura de teste baseada em requisitos: x% dos casos de teste (T(p,i,x,s) nas equações anteriores) obtiveram uma taxa de êxito de y% Essa é uma declaração importante de cobertura de teste que pode ser comparada a critérios de êxito definidos. Se os critérios não forem atingidos, a declaração fornecerá uma base para prever a quantidade de esforço de teste restante. 9 Planejar Testes 9.1 Plano de Teste Este é o primeiro documento e o de mais alto nível gerado pelo processo de testes de software e deve ser elaborado de acordo com o objetivo de formalizar o processo de testes a ser iniciado, envolvendo os usuários, clientes e desenvolvedores. Um plano de testes refere-se a diversos projetos de avaliação, um para cada etapa do desenvolvimento ou versão intermediária do software. O Plano de testes deve prever, para cada versão intermediária do sistema, qual o tipo de teste apropriado à determinada etapa, quais suas condições (casos e requisitos de testes), os resultados obtidos e qual desses resultados serão admitidos. Para facilitar a elaboração desses documentos é possível utilizar o CaliberRM para criação de cada caso de teste utilizando o mesmo formato utilizado com os requisitos e facilitando a rastreabilidade de cada caso de teste com seu respectivo caso de uso. 14

9.1.1 Finalidade A finalidade do Plano de Teste é: Definir as metas e os objetivos dos testes no escopo da iteração (ou projeto), os itens-alvo, a abordagem adotada, os recursos necessários e os produtos que serão liberados. Comunicar a intenção do esforço de teste em determinada programação. Ganhar a aceitação e aprovação dos envolvidos no esforço de teste. Direcionar, orientar e restringir o esforço de teste, priorizando os produtos liberados úteis e necessários. Deve estabelecer uma visão clara de como será operacionalizado o processo, estabelecendo um escopo bem definido de trabalho e nivelando expectativas em relação aos testes. Devem-se evitar informações que não serão compreendidas ou que serão consideradas irrelevantes pelos envolvidos. 9.2 Requisitos de Teste O teste de software consiste em mais do que simplesmente avaliar as funções, a interface e as características de tempo de resposta de um objetivo do teste. Os testes adicionais devem se concentrar em características / atributos. Para conseguir isso, diferentes tipos de testes são implementados e executados, cada um com um objetivo e uma técnica de suporte específico. O foco 15

de cada técnica está em testar uma ou mais características ou atributos do objetivo do teste. Alguns destes tipos estão listados a seguir: 9.2.1 Teste de integridade de dados e BD Objetivo: Os bancos de dados e os processos de banco de dados deverão ser testados como um subsistema independente. Esse teste deve testar os subsistemas sem que a Interface do Usuário faça interface com os dados. É necessário efetuar pesquisas adicionais referentes ao Sistema de Gerenciamento de Banco de Dados (DBMS) a fim de assegurar que os dados foram distribuídos conforme o planejado e que todos os eventos de banco de dados ocorreram de forma adequada. Revisar os dados retornados para assegurar que os dados corretos foram recuperados pelas razões corretas. Experimentar processos e métodos de acesso a banco de dados para que se possa observar e registrar comportamentos-alvo incorretos ou a existência de dados corrompidos. Condições para execução: poderão necessitar de drivers ou de um ambiente de desenvolvimento DBMS para inserir ou modificar dados diretamente no banco de dados. Os processos deverão ser disparados manualmente. Deverão ser usados bancos de dados pequenos ou de tamanho mínimo (com um número limitado de registros) para aumentar a visibilidade de quaisquer eventos não aceitáveis. 9.2.2 Teste funcional Objetivo: detectar erros entre as especificações funcionais do software, e seu atual comportamento. Quando um erro for identificado, tanto a especificação quanto o comportamento poderão estar errados. Condições para execução: Produto deve ser testado com todos os softwares e hardwares especificados nos requisitos. 9.2.3 Teste do ciclo de negócio Objetivo: emular as atividades executadas no projeto ao longo do tempo. Deverá ser identificado um período, e deverão ser executadas as transações e atividades que ocorreriam durante esse período. Isso incluirá todos os ciclos diários, semanais e mensais, assim como os eventos que mudam com as datas. Condições para execução: Produto deve ser testado com todos os softwares e hardwares especificados nos requisitos. 9.2.4 Teste de Interface de Usuário Objetivo: é responsável pela interação antecipada do usuário com o software em desenvolvimento onde poderá, antecipadamente, detectar problemas na utilização do produto, como dificuldades de navegação, falta de clareza nas informações disponíveis, termos não adequados ao negócio suportado pelo software, entre outros. Condições para execução: Através da utilização de desenhos, protótipos ou mesmo produtos semi-acabados. 16

9.2.5 Teste de Carga Objetivo: Verifica a aceitabilidade do comportamento de desempenho do objetivo do teste em condições operacionais variáveis (como número de usuários, número de transações, etc.), enquanto a configuração permanece constante. Condições para execução: elevação momentânea de parâmetros chave do software, como taxa de erros, volume de transações, número de usuários simultâneos, e combinações destes. 9.2.6 Teste de Stress Objetivo: Consisti em testar o software em situações limites, como cadastrar valores ou determinadas informações que contenham uma grande carga de dados possíveis até que alguma falha ocorra. O teste de stress exige do sistema alguns recursos de qualidade, volume e freqüências anormais, como exemplo, pesquisas longas e exaustivas em disco, testes limites de memória, entre outros. Condições para execução: elevação momentânea de parâmetros chave do software, como taxa de erros, volume de transações, número de usuários simultâneos, e combinações destes. 9.2.7 Teste de Volume Objetivo: destinado a verificar a capacidade do objetivo do teste de lidar com um grande volume de dados, como entrada e saída ou residente no banco de dados. O teste de volume abrange, como, por exemplo, a entrada de dados do volume máximo de dados em cada campo ou a criação de consultas que retornem todo o conteúdo do banco de dados ou que tenham tantas restrições que nenhum dado seja retornado. Condições para execução: ao contrário do teste de carga e stress, esse tipo de teste não focaliza situações de pico, mas o aumento contínuo das condições de carga. 9.2.8 Teste de Segurança e Controle de Acesso Objetivo: demonstrar que todas as funcionalidades de segurança operam da maneira como foram especificadas e testar a resistência do sistema às ameaças existentes no ambiente, visando detectar formas de quebra de segurança do software. Condições para execução: geralmente são obtidos durante a execução de outros testes de Sistema. 9.2.9 Teste de Falha e Recuperação Objetivo: forçar o software a falhar, e verificar se a combinação do software com outros programas são realizados com sucesso. Tais testes são executados conforme as necessidades de cada testador. Essas falhas podem ocorrer devido a quedas na rede dos computadores ou na energia elétrica, além da execução de alguma funcionalidade do software que dependa de outros programas, entre outros. Quando ocorrer essas falhas, será verificado se a recuperação está sendo adequadamente realizada. 17

Condições para execução: geralmente são obtidos durante a execução de outros testes de Sistema. 9.2.10 Teste de Configuração Objetivo: determinar configurações de software e hardware, previstas na especificação de requisitos, em que o software não opera de forma adequada. Condições para execução: Produto deve ser testado com todos os softwares e hardwares especificados nos requisitos. 9.2.11 Teste de Instalação Objetivo: destinado a garantir que o objetivo do teste seja instalado conforme o esperado em diferentes configurações de hardware e/ou software e sob diferentes condições (como no caso de espaço insuficiente em disco ou interrupção de energia). Esse teste é implementado e executado em aplicativos e sistemas. Condições para execução: devem-se executar as instruções de instalação em ambientes simulados ou reais, verificando se estas estão claras e completas, observando os resultados produzidos. 9.2.12 Teste de Contenção Objetivo: destinados a verificar se os objetivos do teste podem lidar de forma aceitável com as demandas de vários atores no mesmo recurso (registros de dados, memória, etc.). Condições para execução: geralmente são obtidos durante a execução de outros testes de Sistema. 9.2.13 Teste de Estrutura Objetivo: preocupar com a função que o programa desempenha sem preocupar-se de como a função foi implementada, o teste estrutural enfoca a implementação e a estrutura da função. A intenção do teste estrutural é encontrar dados de teste que terão cobertura suficiente de todas as estruturas presentes na representação formal. Condições para execução: Embora geralmente usado durante a fase de codificação, testes estruturais devem ser usados em todas as fases do ciclo de vida do software nas quais o software é representado formalmente. 10 Projetar Teste 10.1 Casos de Teste Contém informações sobre os Objetivos, os Cenários e os respectivos Casos de Testes a serem abordados e planejados para realização dos testes funcionais. Defini os cenários a serem cobertos pelos casos de testes, com base nas especificações de caso de uso. A execução dos casos de testes visa verificar e validar as funcionalidades do sistema, e o seu correto funcionamento. Abrangendo seus fluxos principais e alternativos. 18

10.1.1 Cenário de Teste Objetivo: iniciar o processo de detalhamento dos testes de validação. Identificar o maior número de variações possíveis sobre um determinado requisito a ser testado. Cada cenário será validado por um conjunto de procedimentos que deverão ser levantados. 10.1.2 Fluxos (Básico e Alternativos) Detalha todos os procedimentos a serem realizados durante a execução dos testes. Cada cenário produz um conjunto diferenciado de procedimentos a serem seguidos, denominado fluxos. Os procedimentos definem o que e em que ordem, determinadas atividades deverão ser desempenhadas, visando a qualidade final dos testes. 10.1.3 Sugestões de Casos de Teste Detalha todas as informações a serem empregadas nos procedimentos definidos para cada cenário existente. Estas informações são referentes tanto às entradas de dados quanto às saídas esperadas para cada processamento. As primeiras sugestões de Casos de Teste podem ser identificadas logo na Fase de Levantamento de Requisitos, sendo identificadas subseqüentemente em cada iteração durante o restante do ciclo de vida do projeto. Os seguintes itens devem ser abordados: Identificação dos Casos de Testes; Definição de cada Caso de Teste; Detalhamento da Massa de Entrada (Entrada); Detalhamento da Massa Resultante (Saída); Critérios Especiais para Geração da Massa Ativa; Responsáveis; Definir Agenda de Levantamentos. Bons casos de teste são aqueles que encontram falhas no sistema até então não descobertas; Bons casos de teste são projetados levando em conta os requisitos do projeto. 10.1.4 Massa de Teste A definição de um conjunto de valores de entrada de teste que são usados durante a execução de um teste, e os resultados esperados mencionados para fins de comparação durante a execução de um teste. Normalmente, se começa a reunir sugestões de Massa de Teste logo na Fase de Levantamento de Requisitos, sendo esta tarefa desempenhada pelos analistas de requisitos em conjunto com a equipe de teste. 19

11 Preparar Ambiente de Teste 11.1 Finalidade Este ambiente deve fornecer toda a infra-estrutura necessária de hardware e software para a realização dos testes de software em condições conhecidas e controladas. Toda infra-estrutura deve estar disponível à equipe de testes e deve contemplar um ambiente semelhante ao de produção. Com isto será possível realizar um maior número de testes, principalmente os relativos a sistema, onde seja possível que requisitos como desempenho, volume e carga sejam medidos e estimados ao ambiente de produção. Neste ambiente deverão ocorre todos os processos de validação do software (os testes de usabilidade, funcionalidades e sistemas). Os testes são realizados com as técnicas de caixa preta, onde não se requer um conhecimento interno do software. Os testes são gerados com a finalidade de provocar situações específicas de negócio e verificar como estas foram tratadas. Através da análise deste comportamento o teste é dado como bem sucedido ou não. Podem ser empregadas técnicas de criptografia, impossibilitando que os dados, muitas vezes migrados de um ambiente real de produção, tornem-se de conhecimento dos profissionais do ambiente de teste. 11.2 Ocorrências Identificar as necessidades de ambiente, específicos para cada técnica de teste. Usando o Plano de Teste, identificar cada técnica que fará parte da abordagem de teste. Para cada técnica, listar os requisitos de ambiente específicos que precisarão ser satisfeitos para permitir a execução do teste. Definindo um inventário de itens básicos de hardware e software. Usando os requisitos identificados, agrupando em uma lista os itens de hardware e software necessários para a condução do teste. Definir um inventário detalhado de itens de hardware e software para suportar o processo de teste. Reunir os detalhes para cada configuração. Solicitar ajuda do suporte técnico ou dos recursos de administração do sistema, caso seja necessário. Descobrir os "extremos" mínimos e máximos para os possíveis ambientes. Em geral, esses extremos são suficientes para fornecer uma visão geral da experiência de ambiente. Definir os requisitos do processo de gerenciamento do Ambiente de Teste. Elaborar procedimento de gerenciamento para configurar, manter e gerenciar o ambiente de teste funcionando apropriadamente. 20

12 Implementar Testes 12.1 Procedimento de Teste 12.1.1 Finalidade Registrar os procedimentos de um determinado teste, normalmente um conjunto de instruções detalhadas para a configuração e a execução passo a passo, de um ou mais casos de teste elaborados para verificação e validação do caso de uso foco do teste. 12.1.2 Condições Cada cenário produz um conjunto diferenciado de procedimentos a serem seguidos, denominado como Procedimento de Testes. Os procedimentos definem o que e em que ordem, determinadas atividades deverão ser desempenhadas, visando a qualidade final dos testes. Os procedimentos de teste podem começar a serem identificados na fase de Iniciação. 12.1.2.1 Alguns Itens devem ser Observados Os Procedimentos de Teste devem considerar alguns aspectos: Compatibilidade e relevância do teste individual a ser executado pelo procedimento de teste, especialmente nos termos do objetivo do teste e seu escopo; Ponto do qual o procedimento de teste pode ser recuperado ou reiniciado se a sua execução falhar; Configuração de hardware e software para execução do procedimento de teste, por exemplo, resolução de vídeo, alocação de recursos, variáveis de ambiente, caso sejam necessários; Disponibilizar requisitos pré-existentes de consumo do procedimento de teste, tais como povoamento da base de dados, instalação de impressoras. 13 Executar Testes Devem ser aplicadas todas as atividades planejadas no Plano de Teste pertinente à fase executada, ou seja, preparar o ambiente e executar todo o conjunto de testes elaborados na fase de planejamento. 13.1 Finalidade Executar os conjuntos de testes apropriados necessários para validar a qualidade do produto. Capturar resultados de teste que facilitem a avaliação do produto Conduzir os testes incluídos no Conjunto de Testes, monitorando e suportando sua conclusão. 13.2 Tipos de Execução A execução dos Conjuntos de Testes e dos Scripts de Testes varia de acordo com o tipo de teste, ou seja, automatizado ou manual: 21

Teste automatizado: Os scripts de teste criados durante a atividade Implementar Teste são executados. Execução manual: Os Scripts de Teste estruturados e desenvolvidos durante a atividade Projetar Teste são usados para executar manualmente o teste. 13.3 Recuperar a partir de testes interrompidos Determinar a ação corretiva apropriada para a recuperação a partir da execução de um Conjunto de Testes interrompido e, se necessário, corrigir o problema, recuperando e executando novamente o Conjunto de Testes. 13.4 Restaurar o ambiente de teste ao estado conhecido Garantir que tenha sido feita uma limpeza apropriada do ambiente após a execução do Script de Teste. Restaurar o ambiente novamente ao seu estado original: Redefinição do ambiente básico (arquivo do Registro e outros arquivos de configuração); Restauração dos bancos de dados básicos ao estado conhecido; Além de outras tarefas necessárias a sua restauração. 14 Registro de Erros da Release 14.1 Finalidade Registrar todos os procedimentos e ocorrências (suspeitas e identificações de erros) realizados durante a execução de um ciclo de testes, bem como apontar as eventuais interrupções e re-processamentos ocorridos. O Registro de Erros da Release é uma prova de que os testes foram processados. Fornecer um registro detalhado usado para verificar se ocorreu a execução de um conjunto de testes, e fornecer informações relacionadas ao sucesso desses testes. Em geral, o foco está voltado para o provimento de uma faixa de auditoria precisa, permitindo a realização de um diagnóstico de falhas posterior a uma execução. Esses dados serão analisados subseqüentemente para ajudar a determinar os resultados de algum aspecto do esforço de teste. 14.2 Ocorrência Devem ser criados sempre que os Conjuntos de Testes forem executados. Deve ser composto de uma série de entradas que apresentem uma faixa de auditoria para diversos aspectos da execução de testes. 15 Avaliação dos Resultados dos Testes 15.1 Finalidade É produzido com o objetivo de sumarizar todos os sucessos e insucessos alcançados, após o término de todas as etapas do processo de validação. 22

Verificar se a atividade foi concluída de forma apropriada e se os artefatos resultantes são aceitáveis. Determinar se o Conjunto de Testes foi executado até o fim ou interrompido de forma anormal e avaliar se há necessidade de ação corretiva. A execução do teste é concluída ou finalizada em uma destas duas condições: Normal: todos os Scripts de Teste são executados até a conclusão conforme planejado. Anormal ou prematura: os Scripts de Teste não são executados completamente conforme planejado. A causa do término anormal precisa ser identificada e, se necessário, o erro deve ser corrigido e os testes devem ser novamente executados. Também é um excelente momento de propor melhorias no processo como um todo. 16 Definição do Ciclo de Teste A atividade de definição do Ciclo de Teste é um complemento à elaboração de Estratégia de Teste, e tem como objetivo principal registrar como será a simulação da execução dos processos de negócio que envolve o sistema em um período menor e controlado, o qual denominamos de Ciclo de Teste. Esta fase é de extrema importância, pois ela possibilita ao Arquiteto de Teste visualizar quais serão as dependências e seqüência de execução dos testes, antes de se iniciar a elaboração dos Planos de Teste, fato que facilita a atividade de Elaborar Planos de Teste e agiliza a atividade de Planejar Execução de Teste. 16.1 Procedimentos 1) Identificar, inicialmente, qual será o escopo do teste, através da Estratégia de Teste, entendendo qual será a integração e dependência entre Requisitos de Escopo (processos de negócio) do sistema alvo de teste. 2) Estabelecer através da Estratégia de Teste de quantos dias é o Ciclo de Teste para demanda em questão. Exemplo: 15 dias úteis. Esta quantidade de dias poderá ser alterada ao longo da elaboração do documento de Ciclo de Teste conforme a necessidade. 3) Registrar os Requisitos de Escopo na planilha de Ciclo de Teste de acordo com o especificado na Estratégia de Teste no tópico Casos de Uso Alvo de Teste, por exemplo. 4) Através dos Requisitos Funcionais e, eventualmente, mediante reuniões com a Unidade de Requisitos, identificar qual é a seqüência de cada execução dos Casos de Uso englobados no Requisito de Escopo, dentro do Ciclo de Negócio do Sistema alvo de teste. 5) Em alguns casos poderá se registrar diferentes cenários de execução de teste para o mesmo Requisito de Escopo, e isto deverá ser tratado dentro do documento. 6) O Analista de Teste, responsável pela elaboração do documento de Ciclo de Teste, deverá distribuir a seqüência de cada Caso de Uso nas datas de 23

referência estabelecidas na planilha. Isto demonstrará em qual posição, no tempo, deverá ser executado um determinado Caso de Uso para se validar o processo de negócio ao qual ela faz parte. 7) Deve-se identificar qual a característica de execução de Caso de Uso, identificando-o como on-line ou batch. 8) Deve-se identificar a existência de dependência de algum conjunto de dados, que deve ser pré-existente no ambiente-alvo (banco de dados ou arquivos) para a execução do teste de um determinado Requisito de Escopo. 9) Após a elaboração do documento, o Analista de Teste poderá promover uma reunião de revisão do documento produzido, com alguns representantes da Unidade de Requisitos, Análise e Projeto e da própria Unidade de Teste para validação. 10) Após finalizado, este documento será de extrema importância para o Líder da Unidade de Teste durante a atividade de planejamento. 17 Conclusão A atividade de teste serve para mostrar o quão é importante, pois não sendo utilizada causa impacto como não se testar suficientemente um software, gerando erros e manutenções que poderiam ser evitadas. Muitas vezes, a correção de um erro num software pode custar muito mais caro do que se tivesse sido gasto um tempo maior para executar os testes necessários. À medida que gestores, equipes, empresas, passam a adequar o trabalho no intuito de se produzir um software de qualidade o que não se restringe ao aspecto de Testes todas as partes envolvidas irão colher os frutos. Desde o usuário, que muito provavelmente ficará satisfeito com o produto logo na primeira entrega, quanto os próprios desenvolvedores, que começarão a abandonar a imagem de sempre atrasam na entrega ou de não era isso que eu queria. 24

Anexo I - Sugestões para ferramentas de teste E para melhor realizar a atividade de testes existem diversas ferramentas que permitem a otimização dos testes a serem realizados, uma dessas ferramentas é a suíte de testes Silk da Borland e o Borland Gauntlet responsável por estar realizando a integração continua do código fonte. Abaixo segue uma breve descrição das ferramentas. Borland SilkCentral Test Manager : Disponibiliza eficiência e visibilidade a equipe de teste em uma única ferramenta de gerencia de teste que suporta todos os passos cruciais do ciclo de vida da garantia de qualidade do software; Borland Gauntlet : Permite de forma pro ativa implementar e testar o código fonte a medida que ele entra no repositório de controle de versão, isolando defeitos e reportando métricas de desenvolvimento com a integração continua e a ferramenta de cobertura de código, melhorando assim a visibilidade, a qualidade do software e a produtividade dos desenvolvedores; Borland SilkTest : Aumentar a produtividade e reduzir custos com regressão automatizada e teste funcional do software que incluem funcionalidades como gravação de informações da interface gráfica do sistema e execução dessas informações, alem de uma linguagem de teste simples e de fácil aprendizado; Borland SilkPerformer : Permite testar a performance do sistema de forma automatizada para otimizar o tempo de resposta, a escalabilidade e a confiança da aplicação. Para maiores informações consulte o site: http://www.borland.com/br/products/silk/index.html 25