monografia

60 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
60
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
1
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

monografia

  1. 1. LARISSA ROSOCHANSKY TESTES E O CICLO DE DESENVOLVIMENTO DE SISTEMAS FASP SÃO PAULO – 2006
  2. 2. LARISSA ROSOCHANSKY 05020430019-3 TESTES E O CICLO DE DESENVOLVIMENTO DE SISTEMAS Trabalho de conclusão de curso como pré- requisito para obtenção do grau de Engenheiro de Sistemas sob orientação do Prof. Edison Kalaf. FASP SÃO PAULO – 2006
  3. 3. Autor: Larissa Rosochansky Título: Testes e o Ciclo de Desenvolvimento de Sistemas Banca examinadora: Prof. Edison Kalaf FASP SÃO PAULO – 2006
  4. 4. Dedico este trabalho ao meu marido, que sempre me apoiou em todas as minhas decisões, e a meu pai, inspiração intelectual, sempre.
  5. 5. Resumo Este trabalho apresenta uma visão prática da aplicação da fase de testes dentro do ciclo de vida de um sistema, desde seu planejamento até o encerramento desta fase, com uma reunião de lições aprendidas. Por ser uma abordagem prática do trabalho feito pelo autor nestes últimos dois anos em uma empresa de renome em "outsourcing" de serviços de teste, pode muitas vezes divergir das idéias existentes no mercado. Mesmo assim, a intenção é demonstrar a importância da observância real desta fase dentro do ciclo de vida, assim como seu impacto na redução de custos geral. Assim sendo, mostraremos a abordagem prática com uma visão gerencial, atingindo a todo o público interessado e atuante no ciclo de vida de sistemas.
  6. 6. Índice Sumário 1. Objetivo.............................................................................................................1 2. Introdução.........................................................................................................2 2.1. Princípios de teste...............................................................................................4 2.2. Níveis de Teste em uma organização................................................................4 2.3. Resumo................................................................................................................5 3. Histórico de testes...........................................................................................6 3.1. Início de tudo: um acidente................................................................................6 3.2. Décadas de 70 e 80..............................................................................................6 3.3. A trama se complica: década de 90...................................................................6 3.4. Parem tudo, a Web chegou.................................................................................7 3.5. Anos 2000: caindo na real..................................................................................8 3.6. Resumo................................................................................................................8 4. Testes e o ciclo de desenvolvimento...........................................................10 4.1. Redução de custos............................................................................................10 4.2. A relação custo/benefício de testes.................................................................13 4.3. Resumo..............................................................................................................14 5. Abordagens de testes....................................................................................15 5.1. Testes estáticos.................................................................................................15 5.1.1. Tipos de testes estáticos............................................................................................15 5.2. Testes dinâmicos..............................................................................................16 6. Técnicas de teste............................................................................................17 6.1. Teste de caixa preta..........................................................................................17 6.1.1. Teste de equivalência de classes...............................................................................18 6.1.2. Teste de valores limites..............................................................................................18 6.1.3. Tabela de decisão......................................................................................................19 6.1.4. Teste de matriz ortogonal...........................................................................................19 6.1.5. Diagramas de transição de estado.............................................................................20 6.2. Teste de caixa branca.......................................................................................21 6.2.1. Teste de fluxo de controle..........................................................................................21 6.2.2. Níveis de cobertura....................................................................................................22 6.2.3. Teste do caminho básico............................................................................................23 6.3. Encontro de erros..............................................................................................23 6.4. Resumo..............................................................................................................23 7. Níveis de testes..............................................................................................25 7.1. Teste unitário.....................................................................................................25
  7. 7. 7.2. Teste de integração ou modular.......................................................................26 7.3. Teste de sistemas..............................................................................................27 7.4. Teste de integração de sistemas......................................................................27 7.5. Teste de aceite...................................................................................................28 7.6. Testes de operabilidade....................................................................................28 7.7. Resumo..............................................................................................................29 8. Tipos de testes...............................................................................................30 8.1. Teste de requisitos............................................................................................30 8.2. Teste de desenho..............................................................................................30 8.3. Teste de regressão............................................................................................31 8.4. Teste de usabilidade.........................................................................................31 8.5. Teste de backup e recuperação.......................................................................31 8.6. Teste de desempenho.......................................................................................32 8.7. Teste de segurança...........................................................................................32 8.8. Teste de stress / volume...................................................................................32 8.9. Resumo..............................................................................................................33 9. Processo de testes.........................................................................................34 9.1. Planejamento e controle...................................................................................34 9.1.1. Escopo do teste..........................................................................................................35 9.1.2. Análise de risco..........................................................................................................35 9.1.3. Objetivos do teste.......................................................................................................35 9.1.4. Estratégia do teste......................................................................................................36 9.1.5. Gerenciamento de problemas e controle de mudanças.............................................36 9.2. Análise e desenho do teste..............................................................................36 9.2.1. Revisão da base de testes.........................................................................................37 9.2.2. Identificação das condições e requisitos de teste.......................................................37 9.2.3. Criação dos casos de teste........................................................................................37 9.2.4. Automação: quando usar...........................................................................................38 9.2.5. Avaliar a testabilidade dos requisitos e do sistema....................................................39 9.2.6. Desenhar a preparação de ambiente e necessidades de infra-estrutura...................40 9.3. Execução dos testes.........................................................................................40 9.4. Avaliação do critério de saída e relatórios......................................................41 9.5. Atividades de encerramento dos testes..........................................................41 9.6. Resumo..............................................................................................................42 10. Papéis e profissões existentes em testes.................................................43 10.1. Testador...........................................................................................................43 10.2. Analista de testes - negócios.........................................................................43 10.3. Analista de testes - técnico............................................................................44 10.4. Líder de equipe................................................................................................44
  8. 8. 10.5. Gerente de testes............................................................................................44 10.6. Gerente de defeitos.........................................................................................44 10.7. Arquiteto de testes..........................................................................................45 10.8. Resumo............................................................................................................45 11. Defeitos e seu gerenciamento....................................................................46 11.1. Objetivos do gerenciamento de defeitos.......................................................46 11.2. Atividades do gerenciamento de defeitos.....................................................46 11.3. Início e fim do gerenciamento de defeitos....................................................47 11.4. Classificação dos defeitos..............................................................................47 11.5. Análise dos defeitos........................................................................................49 11.6. Resumo............................................................................................................49 12. A prática de testes hoje...............................................................................50 12.1. Testes, o “mal necessário”.............................................................................50 12.2. Profissionais de testes qualificados, uma raridade......................................51 12.3. Certificações de testes no Brasil...................................................................51 12.4. Resumo............................................................................................................52 13. Métricas de teste..........................................................................................53 13.1. Onde aplicar as métricas................................................................................53 13.2. Considerações importantes...........................................................................54 13.3. Melhorando as métricas..................................................................................55 ..................................................................................................................................55 13.4. Resumo............................................................................................................55 14. Ferramentas disponíveis.............................................................................56 14.1. Gerenciadores de teste...................................................................................56 14.1.1. Ferramentas Mercury...............................................................................................56 14.1.2. Ferramentas Rational...............................................................................................57 14.2. Outras ferramentas de teste...........................................................................58 14.2.1. Gerenciadores de mudanças e configuração...........................................................58 14.2.2. Ferramentas para teste e gerenciamento em sites..................................................58 14.2.3. Ferramentas auxiliares diversas...............................................................................58 14.2.4. Ferramentas abertas para testes..............................................................................58 14.3. Resumo............................................................................................................59 15. Conclusão.....................................................................................................60 16. Bibliografia....................................................................................................62 17. Glossário.......................................................................................................65
  9. 9. Índice de Imagens Figura 1 - Fases do Projeto de Software............................................................2 Figura 2 – Custo da remoção de defeitos nas diferentes fases (por multiplicador)......................................................................................................10 Figura 3 - Fases do Projeto x Fases de Teste.................................................11 Figura 4 – Modelo V............................................................................................12 Figura 5 - Teste caixa preta...............................................................................17 Figura 6 - Relações de Níveis e Tipos de teste...............................................33 Figura 7 - Curva S - Esforço de Teste..............................................................42 Figura 8 - Quadro Comparativo de Certificações de Testes..........................52
  10. 10. 1 1. Objetivo Esta monografia destina-se a todos os profissionais envolvidos no ciclo de vida de um projeto de software e, também, à alta gestão de TI, a fim de esclarecer o que é teste, como a fase de testes se enquadra no ciclo de vida de desenvolvimento de um sistema e qual sua importância no produto final, assim como os riscos da má implantação da fase de testes nestes pontos.
  11. 11. 2 2. Introdução A meta principal de todo projeto de software é, sempre, entregar ao cliente o produto no prazo e custo acordados, com a qualidade esperada. Para tal, necessitamos de alguns pressupostos: deve haver uma metodologia para o ciclo de vida, e o software deve ser considerado como um projeto. Em um projeto de software, normalmente, possuímos as seguintes fases: Figura 1 - Fases do Projeto de Software Iremos nos focar, aqui, somente na fase de testes, que normalmente abrange o projeto como um todo, agindo diretamente na qualidade. E, sem uma gestão adequada do projeto como um todo, não há que se falar em qualidade, pois não haverá um produto a ser entregue. Qualidade, atualmente, é a palavra da moda. E, como qualquer moda, muitos querem utilizar sem saber exatamente como. Diversas empresas procuram por fábricas de software com CMMI 5, mas simplesmente não estão dispostas aos ônus de fornecer informação e arcar com toda a metodologia e custos associados necessários. Nesta luta insaciável pela qualidade, a fase de testes de software é um dos maiores aliados. E, normalmente, a menos observada e mais prejudicada. Se a fase de construção de um produto de software se atrasa no cronograma geral do projeto, normalmente a data do “Go Live” não é afetada, e sim a fase de testes. Muitas vezes, este desprezo pela fase de testes encontra- se no desconhecimento do que é esta fase, e de como planejá-la adequadamente. Mas, afinal, o que é testar um software? Vamos ver algumas definições do que é Teste: - “Testar é o processo de executar um programa ou sistema com a intenção de encontrar erros”. Glenfond Myers, The Art of Software Testing - “Testar é qualquer atividade direcionada à avaliação de um atributo de um programa ou sistema. Testar é a métrica da qualidade de software”, Bill Hetzel, The Complete Guide to Software Testing - “O processo de avaliar ou exercitar um sistema ou um componente de sistema por meios manuais ou automatizados para verificar se satisfaz requisitos específicos ou identificar as diferenças entre os resultados esperados e resultados reais”, IEEE
  12. 12. 3 Se juntarmos todas essas definições, podemos entender perfeitamente o propósito de testar um software, ao invés de procurar uma definição para esta atividade. Desta maneira, os testes de softwares existem para: - Medir os resultados contra os requisitos, ou seja, verificar se os resultados estejam iguais a aquilo que é esperado pelo requisito; - Documentar as diferenças entre os resultados reais e resultados esperados; - Ajudar a resolver estas diferenças fornecendo os devidos resultados e achados no debugi . Secundariamente, os objetivos do teste são: - Fornecer confiança ao sistema, através do envolvimento do usuário; - Garantir que o sistema funcionará tanto do ponto de vista funcional quanto de desempenho; - Garantir que as interfaces entre os sistemas funcionem; - Estabelecer exatamente o que o sistema faz (e não faz) para que o usuário não receba nenhuma surpresa à época da - Identificar áreas problemáticas onde os produtos do sistema não atendam às especificações acordadas - Melhorar os processos de desenvolvimento que ocasionam erros. E, dependendo do papel exercido por uma pessoa, podemos dizer que testar serve: - Desenvolvedor: validar que um programa ou sistema tenha sido desenvolvido de acordo com seus requisitos. - Gerente de projeto: mede se o produto a ser entregue foi feito com qualidade, se preocupando com a integração das equipes de teste e desenvolvimento, determinando riscos, problemas e gerenciando por métricas. - Analista de testes: Analisar e definir a melhor estratégia para testar os requisitos, encontrando erros significativos dentro do prazo alocado para isto, e verificar se a correção para este erro torne o software ou sistema conforme com os requisitos. - Empresa ou negócio desenvolvendo o software: melhorar a qualidade e satisfação do cliente, redução de custos relacionados a reclamações de usuários e re-escrita do software, assim como aumento da margem de lucro para o negócio.
  13. 13. 4 2.1. Princípios de teste Testar demonstra a presença de defeitos: o teste pode demonstrar que há defeitos, mas não pode assegurar que não existam defeitos. Testes reduzem a probabilidade de que defeitos não descobertos continuem no sistema mas, mesmo que nenhum defeito tenha sido encontrado, não é uma prova de que o aplicativo não possui problemas. Testes exaustivos são impossíveis: testar tudo (todas as combinações de entradas e pré-condições) não é factível exceto em casos triviais. Ao invés de testes exaustivos, usam-se riscos e prioridades para focar no esforço de teste. Testes prévios: as atividades de teste devem começar o quanto antes no ciclo de desenvolvimento de software, e deve estar focado em objetivos definidos. Agrupamento de defeitos: um pequeno número de módulos contém a maioria dos defeitos descobertos durante o teste pré-produção, ou demonstrar as maiores falhas operacionais. Paradoxo de teste: se os mesmos testes são repetidos diversas vezes, eventualmente este set de casos de teste não encontrará nenhum defeito novo. Para superar este paradoxo, os casos de teste necessitam ser regularmente revistos e revisados, e novos e diferentes testes precisam ser escritos para exercitar diferentes partes do software ou sistema para encontrar potencialmente mais defeitos. Teste é contextual: o teste é feito de maneira diversa em contextos diferentes. Por exemplo, o teste de uma funcionalidade é feito de maneira totalmente diferente do teste de aceite do usuário. Ilusão da falta de erros: encontrar e corrigir defeitos não adianta se o sistema não possui usabilidade e não atende às necessidades e expectativas dos usuários. 2.2. Níveis de Teste em uma organização Existem também níveis de maturidade de Teste em uma organização, criados por Boris Beizer em seu livro intitulado Software Testing Techniques, divididos em 5 níveis, a exemplo do CMMI. São eles: - Nível 1 - "Não há diferença entre testar e depurar. Além de servir como suporte ao debug, testar não possui outro." Pode-se encontrar defeitos mas não há um esforço formal para encontrá-los. - Nível 2 - "O propósito do teste é demonstrar que o software funciona." Esta abordagem, que começa com a premissa de que o software está correto, pode nos cegar para descobrir defeitos. Glenford Myers escreveu que aqueles fazendo os testes podem subconscientemente selecionar casos de teste que não vão falhar. Assim, os casos de testes criados a fim de encontrar defeitos escondidos, nunca existirão.
  14. 14. 5 - Nível 3 - "O propósito do teste é demonstrar que o software não funciona." Esta abordagem assume que o software não funciona e desafia o testador a encontrar seus defeitos. Com esta abordagem, serão selecionados os casos de teste para avaliar minuciosamente o sistema, seus limites, usando casos de testes extremamente bem construídos para este fim. - Nível 4 - "O propósito do teste não é provar nada, apenas reduzir o risco percebido de não funcionar a um nível aceitável." Não se faz um julgamento prévio do software, somente há a preocupação de entregá-lo da melhor maneira possível. - Nível 5 - "Testar não é um ato, é uma disciplina mental que resulta em um software de baixo risco sem muito esforço de testes”. Com esta maturidade, a equipe de testes é colocada logo no início do projeto de software, ajudando a definir requisitos, sempre em mente a faceta do que é testável e mensurável. 2.3. Resumo Os graus de maturidade de uma organização e a análise destes é o que permite identificar a qualidade para se implantar satisfatoriamente o teste. Uma fase de testes bem planejada e bem executada garante a qualidade do produto, assim como de futuros projetos similares. E, no mundo atual, garantir a qualidade do produto entregue é garantir a permanência da empresa no mercado.
  15. 15. 6 3. Histórico de testes Infelizmente, não temos um histórico muito preciso sobre a história de testes no Brasil. Muito do que será dito aqui corresponde à história nos Estados Unidos. 3.1. Início de tudo: um acidente Em 1961, um simples erro de software causou a destruição de uma aeronave. Este simples, mas caro erro levou a Força Aérea a demandar uma verificação independente em todas as futuras missões críticas. A metodologia de verificação e validação evoluiu deste requisito. 3.2. Décadas de 70 e 80 Uma década depois, no início da “era dos computadores”, na década de 70 e 80, temos o início dos métodos formais e métricas utilizados até hoje. Logicamente, o mercado de então se comportava de uma maneira totalmente diferente. Computadores e softwares associados eram construídos para durar (pelo menos cinco anos para os softwares e 10 anos para o hardware). Nesta ótica, os investimentos nesta área derivavam de longas projeções, e os compromissos feitos eram duradouros. Normalmente um parceiro de tecnologia desta época venderia hardware, software, suporte, educação e consultoria. Uma vez escolhida o parceiro, a empresa estaria presa a ele até a total depreciação do hardware e software, um processo que poderia levar 10 anos ou mais. Estes consumidores exigiam confiabilidade e qualidade em seu produto. Testes era uma parte integrante deste processo. Apenas alguns parceiros existiam, sempre com diplomas de engenharia, e cada um possuía uma maneira própria de fazer as coisas. Para a maioria das empresas nesta época, qualquer aplicativo ou sistema operacional rodava apenas em um ambiente. Eram muito raras as situações onde um aplicativo ou hardware deveriam interagir, quiçá trocar informações em tempo real. 3.3. A trama se complica: década de 90 Na década de 90, os Pcs se popularizaram, e com isso surgiram os softwares baratos para o público em geral. Durante toda a década de 90, os computadores continuaram a se tornar mais baratos, poderosos e rápidos. Assim, os desenvolvedores de software foram levados a explorar os
  16. 16. 7 computadores de uma maneira mais ampla, rápida e melhor. E os consumidores foram levados a atualizar-se, apenas para se manter competitivos em seus negócios. Ou assim se imaginava. Os criadores de software criaram técnicas de desenvolvimento rápido de aplicativos (RADii ) para que pudessem estar à altura do hardware e das demandas dos consumidores nesta nova indústria, onde ser o primeiro no mercado normalmente era a chave do sucesso. Ferramentas de desenvolvimento tornavam “escrever programas” cada vez mais fácil. E os diplomas menos importantes. Diferentemente dos anos 80, onde uma nova versão de um aplicativo seria uma versão mais forte do que já existia, nos anos 90, uma nova versão de um aplicativo normalmente seria uma versão completamente diferente, contendo "bugs"iii muito mais sérios do que seu predecessor. O cronograma agressivo de entrega deixava pouco tempo para testes nas funcionalidades base, o que dirá testar os diversos ambientes onde o software era esperado rodar, como computadores feitos por diferentes companhias, e diferentes versões de sistemas operacionais. Assim, era testado pelos usuários, com grupos de suporte aos produtos ajustando os problemas. Os custos de atendimento ao usuário eram altíssimos então. 3.4. Parem tudo, a Web chegou Em poucos meses, toda empresa grande de software e hardware tinha garantida sua presença na web. O processo de conserto de bugs se tornou muito mais eficiente porque não era mais necessário enviar as correções para todos que haviam comprado o software; o custo de correção caiu a quase zero, pois os usuários faziam o "download" da solução na Internet. Os sites de atendimento ao usuário forneciam um lugar único de informação e atualizações tanto para o usuário quanto para o atendimento a este, e o tempo necessário para tornar uma correção disponível ao público era irrisório. O custo de implantação destes sites de atendimento ao usuário era mínimo e a redução de custos monstruosa. A qualidade dos produtos aumentou, não porque novas técnicas de teste foram criadas, mas sim porque as correções eram entregues mais rapidamente. Aliás, a preocupação com a qualidade na entrega do produto diminuiu consideravelmente. Para que gastar com testes se era possível consertar os defeitos depois do produto entregue? Enquanto isso, os consumidores baseavam suas decisões de compra na disponibilidade e propaganda dos softwares. Eles compravam o primeiro produto que encontravam que atendesse às suas necessidades em termos de funcionalidade, sem se preocupar com a confiabilidade dele. Normalmente não
  17. 17. 8 há nenhuma informação de confiabilidade de um software, pois não há padrões estabelecidos. A decisão de entregar o produto é geralmente baseada pelas datas estabelecidas pelo mercado, e não pela atual confiabilidade do produto. Tornou- se prática comum distribuir versões de correções de bugs apenas após poucas semanas da versão inicial – depois que o mercado já estava conquistado. Conseqüentemente, métricas de confiabilidade não são consideradas como cruciais ao sucesso comercial do produto. Esta tendência se espalha no mercado de software e hardware. 3.5. Anos 2000: caindo na real Após a falência de muitas empresas "pontocom" e a queda do mercado em 2001 e 2002, investidores exigem lucratividade. Em contrapartida, na década de 90, os consumidores adquiriam os novos softwares, sem saber exatamente se necessitavam desta nova versão. Mais ainda, quando a utilizavam, não era completamente, apenas algumas poucas funcionalidades. Desta maneira, estas aplicações cliente servidor pesadas foram substituídas por aplicações leves, com muito menos funcionalidades, baseadas em "browser"iv . Os consumidores nunca sentiram falta das funcionalidades que se foram, visto que não as utilizavam. Desenvolvedores argumentavam, na década de 90, com sucesso, que investir em melhores ferramentas construiria um software melhor, ao invés de investir em um melhor processo de testes. Como a maioria das melhoras de qualidade veio de padronização e melhoria no processo de desenvolvimento, isto funcionou. Entretanto, as falhas reais nos produtos foram erros nas funcionalidades, e aplicações que não rodavam bem em grandes sistemas, ou sistemas que eram simplesmente muito caros para manter. E isto são coisas que as ferramentas de desenvolvimento não podem identificar, mas testes sim. 3.6. Resumo No mercado atual, a área financeira da empresa não vai permitir que um servidor seja jogado fora até que seja totalmente depreciado. Nem aceitarão a compra de um novo sistema operacional ou outros softwares sem uma justificativa de custo benefício aceitável. A partir do momento que os consumidores não querem mais comprar algo porque é novo, as coisas começam a mudar. Quando consumidores exigem confiabilidade ao invés de funcionalidades e custos, a balança volta a pesar em direção à confiabilidade, e na qualidade. O valor de utilizar métodos formais e métricas se torna a diferença entre empresas que sobrevivem e outras que não.
  18. 18. 9 E é assim que estamos hoje. Nos afastamos da “era de ouro” da Internet, caindo na real, nos preocupando em desenvolver o melhor software possível dentro do prazo e custo acordados.
  19. 19. 10 4. Testes e o ciclo de desenvolvimento Testes possibilitam a evolução de um software de um estado de hipotética utilidade a um estado de comprovada utilidade. Para se conseguir isso, devem- se testar requisitos, desenho, código, documentação e procedimentos operacionais. Testando-se em todo o ciclo de vide, e não apenas na fase “designada” a testes, pode ajudar, em um mínimo, a trazer antecipadamente problemas ã tona com maior facilidade e chance de correção. 4.1. Redução de custos Envolver a equipe de testes antecipadamente no ciclo de vida do sistema foca a equipe de testes em prevenir erros, ao invés de encontrá-los, além de reduzir, e muito, os custos de um projeto. Quanto antes um erro for identificado no ciclo de vida, menor será o custo do seu reparo. Fase do desenvolvimento de Software Média relativa do custo de remoção do defeito Especificação dos requisitos 1 Desenho 2,5 Construção 6,5 Teste integração 16 Documentação 40 Teste integração de sistemas 40 Produção 110 Figura 2 – Custo da remoção de defeitos nas diferentes fases (por multiplicador) Desta maneira, o teste deve começar na fase onde começa o projeto, ou seja, onde se estabelece os objetivos do projeto também se devem estabelecer os objetivos do teste. Depois, fundamentalmente, na fase de Elicitação de Requisitosv , ou seja, quando do levantamento dos requisitos junto ao cliente.
  20. 20. 11 Figura 3 - Fases do Projeto x Fases de Teste E o que deve ser testado nesta fase? O requisito perfeito é aquele que seja claro, correto, completo, consistente, testável, modificável e rastreável. Assim, o tipo de teste que é feito nesta fase, é o Teste Estático, ou seja, aquele teste que é conduzido com o exame detalhado das características de um produto, como uma documentação, para verificar um conjunto de atributos e padrões. O que testes busca nessas revisões antecipadas, antes da fase de testes propriamente dita, é assegurar a testabilidade do sistema, potenciais defeitos e ambigüidades, e um conhecimento antecipado e geral da aplicação, de maneira a escrever casos de testes mais abrangentes. A fase de testes começa, e é conhecida, na fase do projeto físico do sistema, ou seja, na sua construção. Nesta fase temos os testes unitários, sistema, integração, aceite e usabilidade, do qual falaremos mais adiante. Mas, baseado em uma metodologia voltada à qualidade, baseada no modelo CMMivi , a equipe de testes está sempre envolvida, na revisão de pares, garantia de qualidade de software, métricas, gestão de mudanças e gestão e acompanhamento de defeitos. Baseado em um estudo especial comissionado pelo Departamento de Defesa e Carpers Jones (Software Product Research, 1994; Jones, 2000) foi
  21. 21. 12 estimado a efetividade da remoção do defeito para organizações em diferentes níveis do CMMvii : • Nível 1: 85% • Nível 2: 89% • Nível 3: 91% • Nível 4: 93% • Nível 5: 95% Falando em outro modelo amplamente conhecido em qualidade, temos o “V-Modelviii ”, que é uma representação gráfica do ciclo de vida de desenvolvimento de software. O V-Model é o modelo utilizado pelo governo alemão para o desenvolvimento de software, definindo os resultados a serem alcançados em um projeto e a abordagem para consegui-los. Este modelo mostra claramente a necessidade de Teste em todas as fases, visto que pontos de qualidade existem para todas as fases do ciclo. Figura 4 – Modelo V Erros encontrados antes nesse processo são, em média, pelo menos 20% mais baratos para corrigir do que se achados após a implantação (de acordo com figura 2). Desta maneira, há um benefício financeiro expressivo ao monitorar e gerenciar testes para encontrar e fazer correções na oportunidade menos custosa.
  22. 22. 13 E, da mesma maneira, apesar do maior esforço de testes ocorrer durante o que chamamos de fase de execução, teste é uma atividade a ser desenvolvida em paralelo com desenvolvimento, como se fosse um projeto dentro de outro projeto. Por mais que possa parecer uma duplicação de custos, à primeira vista, ter uma estrutura hierárquica completa para cada fase do projeto, este custo se paga com a redução dos defeitos, e maior qualidade do produto a ser entregue, como visto anteriormente. 4.2. A relação custo/benefício de testes A qualidade nunca é um acidente. Melhorar a qualidade não implica automaticamente em levar mais tempo para os "deliverables"ix e aumentar custos. É possível minimizar riscos enquanto se maximiza a qualidade. A quantidade de testes que devemos (e estamos dispostos a) fazer depende diretamente dos riscos envolvidos. Programas ou sistemas de alto risco requerem mais casos de teste e mais ênfase em testes. Programas com baixo risco ou impacto limitado de falha não precisam da mesma preocupação. No mundo atual, de softwares críticos ao negócio, não é objetivo de testes encontrarem todos os defeitos, o que é praticamente impossível. Ao invés disso, testes devem garantir que dentre os defeitos encontrados estão todos aqueles que possam causar uma real interrupção nos ambientes de produção. Em outras palavras, encontrar os defeitos que fazem a diferença. Atingir a alta qualidade é possível e não custa muito. Como visto anteriormente, um defeito encontrado em produção custa 100 vezes mais caro para ser removido do que aquele encontrado na fase de requisitos. Há um mito que diz que o ROIx (Return over investment) não é atingido pelas melhorias de processo e qualidade do ciclo de desenvolvimento de software. Definitivamente, não é proibitivo alcançar melhorias significativas de processo e cada melhoria deste processo reflete uma melhoria direta na redução dos custos e na satisfação do cliente. A habilidade de uma empresa de competir efetivamente e implantar mudanças é amplamente aumentada pela melhoria de qualidade e previsibilidade do software. A satisfação do cliente traz a melhoria da imagem e percepção da marca para a empresa, resultando em ganhos mensuráveis e quantificáveis do ROI.
  23. 23. 14 4.3. Resumo Testar não é uma atividade isolada, ou desordenada. Ele existe para prevenir defeitos, muito mais do que corrigi-los, e deve existir desde o início do projeto. Nos dias atuais, a importância de testes no ciclo de desenvolvimento de software e sua inserção antecipada trazem muitos benefícios ao produto desenvolvido bem como ao custo do software em si. Nos grandes modelos usados atualmente, como CMMi e V-Model, não se fala mais de testes como uma atividade relegada ao desprezo, mas sim a atividade chave para que a Melhoria contínua pregada por estes modelos possa acontecer. E, quanto antes for inserida a equipe de testes no projeto, maior é o benefício do ponto de vista qualitativo e de custos. A próxima fase pelo qual o mercado passará agora não será a prevenção de defeitos mas sim a redução deles, baseado em estatísticas de projetos anteriores, de maneira extremante efetiva e que possibilitará, e muito, a diminuição de custo de software. Assim, contratar uma empresa possuidora de nível 5 de CMMi não apenas garantirá um produto de qualidade bem como um produto mais barato, devido à metodologia de redução de defeitos.
  24. 24. 15 5. Abordagens de testes Antes de entrarmos nos tipos de testes propriamente dito, vamos nos ater a uma outra visão, a abordagem de testes. Existem dois tipos de abordagens que podem ser feitas em testes: testes estáticos e testes dinâmicos. 5.1. Testes estáticos O teste estático é um exame detalhado das características de um produto em relação a um esperado conjunto de atributos, experiências e padrões. Como o produto sendo examinado é estático, e não em movimento (como a execução de um programa, por exemplo), o seu comportamento a entradas diferentes não pode ser avaliado. A descoberta de defeitos ou desvios cedo em um projeto resulta em mudanças mais baratas e menos sofríveis. E, no ciclo de desenvolvimento, o único teste disponível durante as fases de pré-construção são os testes estáticos. A abordagem de teste estático faz parte dos testes de caixa branca, ou seja, o teste tem acesso ao código (veremos este tipo de teste mais adiante). Nesta abordagem usam-se diversos tipos de técnicas como revisão de código, inspeção e outros. 5.1.1. Tipos de testes estáticos Protótipo: revisar o modelo de um produto definido sem sua total funcionalidade do produto final proposto; o protótipo é mostrado, exercitado, e seu resultado avaliado, levando a uma melhora no design deste. Esta técnica é usada intensamente para verificar e validar o desenho da interface do usuário e para confirmar a usabilidade Auto-revisão: processo do autor de um produto ler seu produto a fim de encontrar defeitos. Listas de checagem: série de itens comuns, ou perguntas a fim de verificar a completeza dos passos de uma tarefa. Estas listas de checagem também podem ser usadas para o estágio de preparação do processo de inspeção. Mapeio: identificação de funções da especificação e demonstração de como esta função, direta ou indiretamente, mapeia aos requisitos. Revisão: usadas para fornecer ao projeto controle e segurança, focado em problemas que impactam o produto, processo de desenvolvimento e o projeto.
  25. 25. 16 As revisões lidam com as características do que está sendo construído, como está sendo construído, e quais os recursos usados para construí-lo. As revisões não são formais, mas são uma maneira excelente de colher feedbacks de pares e membros da equipe. Passo a passo: são mais formais do que revisões mas menos formais do que inspeções. Geralmente são feitas como reuniões agendadas onde os participantes são convidados a participar. As minutas das reuniões são anotadas, assim como os problemas e as ações a serem tomadas resultantes. Os problemas e ações recebem responsáveis e há acompanhamento dessas ações. Mesmo não sendo tão formais quanto inspeções, estas reuniões são uma alternativa viável se há problemas de tempo envolvidos. Inspeções: são a forma mais organizada de se fazer testes estáticos e, sendo assim, é a maneira mais efetiva e econômica para detectar defeitos antecipadamente no ciclo de vida. O processo de inspeção é um procedimento muito bem definido e compreensivo, incluindo planejamento, preparação, reunião de inspeção, re-trabalho e acompanhamento. É uma revisão ordenada com diversas pessoas de várias áreas (negócio, técnico) para fornecer visões mais compreensivas sobre os produtos de trabalho. 5.2. Testes dinâmicos Teste dinâmico é o processo de verificação ou validação de um produto executando-o ou operando-o sob exame e observando seu comportamento com diferentes entradas e ambientes. Onde um módulo é testado estaticamente olhando para sua documentação, é executado dinamicamente para testar o comportamento de sua lógica e sua resposta às entradas. Alguns exemplos significativos de teste dinâmico podem ser execução de casos de testes em um sistema funcional, simular cenários de utilização com usuários finais reais para testar usabilidade e testes paralelos em um ambiente de produção, entre outros.
  26. 26. 17 6. Técnicas de teste Existem três técnicas de teste mais comuns: caixa preta, caixa branca e encontro de erros. Técnicas de teste que examinam os interiores de um produto usam a abordagem de caixa branca. A técnica que observa como uma unidade sob teste se comporta apenas checando suas entradas e saídas é uma abordagem caixa preta. A técnica de encontro de erros é onde experiência e intuição são aplicadas para inesperados mas recorrentes erros. 6.1. Teste de caixa preta No teste de caixa preta, os testadores possuem uma visão externa do sistema, não requerendo conhecimento da parte interna, estrutura ou implantação do software. Preocupam-se com “o que” é feito ao invés de “como” é feito. Para testar este sistema, todas as combinações de entrada possíveis são colocadas e as saídas são examinadas. Devem ser usadas tanto entradas válidas quanto inválidas. O processo de teste de caixa preta usualmente é feito assim: - Requisitos ou especificações são analisados; - Entradas válidas são escolhidas baseadas na documentação para determinar se o sistema se comporta da maneira como deveria se comportar; - Resultados esperados destas entradas são definidas; - Testes são executados; - Resultados reais são comparados com resultados esperados; - Chega-se à conclusão se o sistema está funcionando de acordo ou não. Esta técnica pode ser aplicada em todas as fases de teste: unitário, integração, sistema e aceite. Conforme vamos passando de módulo a um subsistema a um sistema a caixa fica maior, com entradas e saídas mais complexas, mas a técnica continua a mesma, conforme figura abaixo. Figura 5 - Teste caixa preta
  27. 27. 18 Da mesma forma, conforme vai aumentando o tamanho da caixa, torna-se necessário o uso da técnica de caixa preta, já que existem muitos caminhos a serem testados para a técnica de caixa branca, conforme veremos adiante. Uma das desvantagens da técnica de caixa preta é o fato do testador nunca saber quanto do sistema já foi testado. Não importa quão esperto ou minucioso ele seja, alguns caminhos jamais serão exercitados. E, isso vai de encontro com um dos princípios de teste, “testes exaustivos são impossíveis”. Mas, mesmo não sendo possível testar todas as combinações existentes, a técnica de caixa preta direciona o testador a subconjuntos de testes que são efetivos e eficientes em encontrar defeitos. E essa é a vantagem desta técnica: estes subconjuntos vão encontrar mais defeitos do que um mesmo número equivalente, mas randomicamente criado. Em outras palavras, a técnica de caixa preta ajuda a maximizar o retorno do investimento de testes. Neste tipo de testes, são utilizadas as seguintes técnicas: 6.1.1. Teste de equivalência de classes O teste de equivalência de classes é a técnica utilizada para diminuir o número de casos de testes a um número gerenciável mantendo uma razoável cobertura de testes. Assim, ao invés de se testar todas as possíveis entradas, testa-se somente as classes equivalentes, ou seja, um conjunto de dados que são tratados pelo sistema da mesma maneira ou espera o mesmo resultado; apenas um dado deste conjunto já testa esta condição (se este dado encontra um defeito, todos deste conjunto também, e vice-versa). E, lógico, sempre, deve- se testar todas as exceções (testes negativos). Este tipo de testes é aplicável em todas as fases de testes, desde que as entradas e saídas possam ser divididas baseadas nos requisitos. 6.1.2. Teste de valores limites O teste de valores limites foca-se nos valores que estão nas “pontas” dos conjuntos, justamente porque é neste ponto onde se encontram muitos defeitos. Desta maneira, devem-se antes identificar as classes equivalentes, depois encontrar os valores limites de cada classe e escrever casos de teste que testem valores um ponto menor que o limite, o limite, e um ponto maior. Como o teste de equivalência, também pode ser aplicado em todas as fases de testes, desde que as entradas e saídas possam ser divididas e encontrado limites nelas.
  28. 28. 19 6.1.3. Tabela de decisão A tabela de decisão é uma excelente ferramenta para capturar alguns tipos de requisitos de sistema e para documentar desenho interno do sistema. São utilizados para guardar regras de negócio complexas que devem ser implantadas por um sistema e servem como um guia para a criação de casos de testes. Infelizmente, é muito complexo explicar esta técnica sem exemplos concretos. Deve-se seguir um padrão para construir a tabela de decisão, conforme mostrado: Regra 1 Regra 2 … Regra p Condições Condição 1 Condição 2 … Condição n Ações Ação 1 Ação 2 … Ação o Neste padrão, as condições são as condições de entrada, as ações são as ações que devem ser tomadas pelo sistema dependendo das condições de entrada e cada regra significa um conjunto de condições e respectivas ações. Após completar toda a tabela com os valores, cada coluna (regras) significa um caso de teste. Caso a condição seja um conjunto ou uma faixa de valores, devem-se escrever casos para cada um dos valores limites (neste caso, usa-se conjuntamente a técnica de valores limite com a tabela de decisão). 6.1.4. Teste de matriz ortogonal O teste de matriz ortogonal baseia-se na idéia de que a maioria dos problemas em software são causados por interações envolvendo uma ou duas variáveis, e que a maioria dos defeitos seria descoberta se fossem executados todas as combinações envolvendo uma ou duas variáveis. Este tipo de técnica define um conjunto mínimo que guia os testadores a todos os defeitos individuais ou com outra variável. O sucesso desta técnica em diversos projetos, documentados ou não, é o maior incentivo para seu uso. Simplificando algo que normalmente soa muito complicado, pegando qualquer matriz ortogonal com um número x de linhas e um número y de colunas, escolhendo-se quaisquer duas colunas (um par), cobrem-se todas as
  29. 29. 20 mais problemáticas situações, economizando muitos casos de teste, horas e dinheiro. Para implantar a abordagem ortogonal é interessante utilizar ferramentas preparadas para isto, como a rdExpert, da empresa Phadke Associates (http://www.phadkeassociates.com/). Ou, caso prefiram, Neil J.A. Sloane mantém um grande catálogo de matrizes ortogonais como referência (http://www.research.att.com/~njas/oadir/index.html). Em muitos casos, ao construirmos matrizes não nos apercebemos que existem restrições a opções (e a matriz testa todos os pares), e seria muito difícil identificá-las manualmente. Por isso, utilizando ferramentas como a já citada rdExpert ou a AETG pode ajudar muito nesta tarefa. O processo para utilizar as matrizes ortogonais é: - Identificar as variáveis; - Determinar o número de opções de cada variável; - Encontrar uma matriz ortogonal que possua uma coluna para cada variável e valores dentro das colunas que correspondam às escolhas para cada variável; - Mapear o problema a ser testado na matriz ortogonal; - Construir os casos de teste. A grande promessa do teste ortogonal é que, ao criar e executar de 1 a 20% dos casos de teste, pode-se encontrar de 70 a 85% do total de defeitos. É sempre fundamental lembrar que esta técnica pode muitas vezes deixar de fora testes importantes que devem ser feitos. Para isso, recomenda-se sempre usar o bom senso e a experiência prévia do testador, além das técnicas já explicadas anteriormente. Esta técnica também pode ser aplicada a todas as fases de teste, requerendo apenas uma combinação de entradas, com muitos valores, resultando em simplesmente uma quantidade absurda de casos para testar. 6.1.5. Diagramas de transição de estado Os diagramas de transição de estado é outra excelente ferramenta para capturar alguns tipos de requisitos de sistema e para documentar desenho interno do sistema. Estes diagramas documentam os eventos que entram e são processados por um sistema assim como as respostas do sistema. É uma ferramenta perfeita para ser utilizada quando o sistema necessita lembrar-se de algo que ocorreu antes ou quando ordens de operação válidas ou inválidas existem. Estes diagramas direcionam os esforços de testes identificando os estados, eventos, ações e transições que deveriam ser testadas. Juntas, definem como
  30. 30. 21 um sistema interage com o mundo exterior, os eventos que processa e a ordem válida e inválida destes eventos. Este tipo de técnica não é aplicável quando o sistema não possui estados ou não possui a necessidade de responder em tempo real a eventos de fora do sistema. 6.2. Teste de caixa branca No teste de caixa branca, os testadores possuem uma visão interna do sistema. Preocupam-se com “como” é feito ao invés de “o que” é feito. Este tipo de teste é orientado pela lógica: os testadores estão preocupados com a execução de todos os caminhos possíveis do fluxo do programa. A abordagem caixa branca é essencialmente um método de teste unitário e é quase sempre feito pelo pessoal técnico. Cada técnica do teste de Caixa Branca oferece apenas uma faceta para a solução da complexidade geral ao problema de testar completamente todos os aspectos do caminho lógico e seu conteúdo. Os testes de caixa branca dependem da estrutura do programa, e assim possuem como processo: implantação é analisada, caminhos são identificados, entradas e resultados para estas entradas são determinadas, testes são executados, resultados comparados e feito um reporte. O teste de caixa branca pode ser aplicado em todos os níveis de desenvolvimento de software: unitário, integração e sistema. Apesar do teste de caixa branca ser visto como uma atividade de teste unitário, este tipo de visão é uma visão muito restrita. O teste caixa branca é um teste de “caminhos”, e não de código. Desta maneira, podemos aplicar as mesmas técnicas de teste de caminhos entre módulos de um subsistema, subsistemas de um sistema, e ate entre sistemas inteiros. As desvantagens do teste de caixa branca é o escopo (a quantidade de casos de testes a serem testados pode ser tão grande que simplesmente não vale a pena), estes testes também podem não detectar erros simples de dados. Além disso, o teste de caixa branca assume que o caminho sendo seguido pela aplicação é o correto; como os testes são feitos baseados nestes caminhos, não se pode descobrir caminhos alternativos por teste de caixa branca. A última desvantagem cai no fato do testador ter de possuir conhecimentos de programação, para fazer os testes necessários. A vantagem principal desse tipo de abordagem é que o testador, nesse tipo de teste, pode ter certeza de que todos os caminhos foram do software foram identificados e testados. 6.2.1. Teste de fluxo de controle
  31. 31. 22 Esta abordagem identifica os caminhos de execução através de um modulo de um software e então cria e executa casos de testes para cobrir esses caminhos. Um caminho pode ser definido como uma execução de seqüência de instrução que começa em um ponto determinado e termina em uma saída. Os gráficos do fluxo de controle são a base para o teste de Fluxo de Controle. Estes gráficos documentam a estrutura de controle do módulo. Estes módulos são convertidos em gráficos, os caminhos através dos gráficos são analisados e os casos de testes são criados a partir desta análise. O teste de fluxo de controle só será completo quando usado junto com o teste do caminho básico. 6.2.2. Níveis de cobertura Cobertura por instruções Cobertura por instruções é uma técnica de caixa branca utilizada para verificar que cada instrução no programa seja utilizada pelo menos uma vez. Isto garante a cobertura lógica completa. Esta cobertura testará apenas se a instrução foi alcançada, não testando a condição falsa, por exemplo. Cobertura por decisão Esta cobertura é uma melhoria em cima da cobertura por instruções onde todos os ramos, verdadeiros ou falsos são testados. A cobertura por decisão é alcançada quando todos os ramos foram atingidos e cada ponto de entrada foi chamado ao menos uma vez. Mas, uma vez que uma condição seja satisfeita não necessariamente irá testar os outros ramos da mesma instrução. Cobertura por condição O objetivo do teste da cobertura por condição é que todas as condições dentro e uma instrução, e não penas uma decisão específica, sejam testadas para garantir cobertura total. Assim, a cobertura é atingida quando cada decisão é verdadeira pelo menos uma vez, e falsa pelo menos uma vez, e cada ponto foi chamado pelo menos uma vez. Cobertura por múltiplas condições O objetivo é garantir que todas as combinações de diferentes condições sejam testadas, podendo-se usar para isso a tabela de decisão. Cobertura por caminho Garantir que todas as possíveis combinações de caminhos de um fluxo sejam chamadas pelo menos uma vez, baseado em todas as possíveis
  32. 32. 23 combinações de resultados de condições em cada decisão de todos os pontos de entrada ate todos os pontos de saída. 6.2.3. Teste do caminho básico Este teste utiliza uma analise da topologiaxi do gráfico de fluxo de controle para identificar os casos de teste. Para descobrir quantos casos de testes devem ser criados, utiliza-se a complexidade ciclomática que é exatamente o número mínimo de caminhos independentes, não circulares (chamados de caminhos básicos) que podem, em uma combinação linear, gerar todos os caminhos possíveis através do módulo. Desta maneira, a Complexidade Ciclomática (C) é definida por pontas- nódulos+2. O processo do teste estruturado baseia-se nos seguintes passos: derivar o gráfico do fluxo de controle baseado no módulo, computar a complexidade ciclomática do gráfico, selecionar um conjunto de C caminhos básicos, criar um caso de teste para cada caminho básico e executar estes testes. O conjunto de casos de teste encontrado garante a cobertura tanto de instruções quanto de ramos. 6.3. Encontro de erros Baseando-se em experiências passadas, dados de teste podem ser criados para antecipar aqueles erros que ocorrem com maior freqüência. Usando a experiência e o conhecimento da aplicação, são testados dados inválidos que representam os erros comuns que um usuário pode cometer para verificar como o sistema lidará com esses erros. Uma abordagem estruturada para esta técnica é enumerar uma lista de possíveis erros e criar testes para atacá-los. Estas listas de defeitos e falhas podem ser construídas baseadas em experiência, defeitos disponíveis e dados falhos, e do conhecimento comum do por que o software falha. 6.4. Resumo
  33. 33. 24 Em todos os softwares a serem testados sempre devemos utilizar a abordagem de teste caixa branca e a caixa preta, em diferentes momentos do processo de testes e em diferentes tipos de testes, conforme veremos adiante. Agora, qual técnica deve ser utilizada entre as diversas apresentadas aqui dependerá do escopo do projeto, o modelo de desenvolvimento utilizado, os riscos, além do prazo e orçamento, conforme explicado anteriormente. Logicamente, conforme a experiência no gerenciamento da fase de testes aumenta, tomar esta decisão torna-se muito mais fácil.
  34. 34. 25 7. Níveis de testes O teste avança por diversos níveis físicos da mesma maneira que o ciclo de vida de desenvolvimento de software. Cada nível completo representa um marco no plano do projeto e cada estágio representa um nível de integração física e qualidade. Estes estágios de integração são conhecidos como níveis de teste. Produtos de trabalho de software, tais como cenários de negócio ou casos de uso, especificações de requisitos, documentos de desenho e código são muitas vezes utilizados como base do teste em um ou mais níveis de teste. Em qualquer modelo de ciclo de vida, existem diversas características do bom teste: - Para cada atividade de desenvolvimento há uma atividade de teste; - Cada nível de teste possui objetivos específicos a estes níveis; - A análise e criação dos testes para um determinado nível devem começar durante a atividade de desenvolvimento correspondente; - Os testadores devem ser envolvidos na revisão da documentação assim que os rascunhos estejam disponíveis no ciclo de desenvolvimento. É importante salientar que estes níveis de teste não são fixos, podendo ser combinados ou reorganizados dependendo da natureza do projeto ou da arquitetura do sistema. Para cada um dos níveis de teste que veremos a seguir, podem ser identificados seus objetivos genéricos, a base do teste, o objeto do teste, defeitos típicos e falhas a serem encontradas, requisitos do aparato de teste e ferramentas, além de abordagens específicas e responsabilidades. Os níveis de teste mais utilizados são Teste Unitário, Teste Funcional, Teste de Integração, Teste de Integração de Sistemas, Teste de Aceite e Teste de Regressão. 7.1. Teste unitário O teste unitário é o teste inicial do código novo e modificado de um módulo. Verifica as especificações do programa contra a lógica interna do programa ou módulo e valida esta lógica. Os objetivos deste teste são testar a função de um programa ou unidade de código, testar a lógica interna, verificar o desenho interno, testar a cobertura de caminhos e condições, testar condições de exceções e manejo de erros.
  35. 35. 26 Este teste ocorre após as fases de construção desta unidade e possui como produtos de entrada o desenho interno da aplicação, além do Plano Mestre de Testes e Plano Unitário de Testes e, como produto de saída, o Relatório do teste Unitário. Quem deve participar deste teste é o desenvolvedor, usando como método técnicas de caixa branca e técnicas de cobertura de testes. As ferramentas ideais para este nível de teste são debug, reestruturação, analisadores de código e ferramentas de cobertura de caminhos/instruções. Para que este nível de teste possa ser feito seu executor deve ser treinado na metodologia de testes e no uso efetivo das ferramentas descritas anteriormente. Os programas e módulos devem ser exercitados o teste de mesa antes de serem integrados e testados. Esta revisão deve ser feita previamente pelo programador e depois de uma maneira mais formal através de inspeções. Os passos para preparação do teste unitário são: - Determinar a integração do desenvolvimento e abordagem de teste (cima pra baixo, baixo pra cima ou uma combinação dos dois); - Determinar as técnicas de teste caixa branca a serem utilizadas e as sub-técnicas particulares que melhor se aplicam; - Criar os conjuntos de condições (um ou mais níveis dependendo do detalhe). A melhor abordagem no teste unitário é criar os casos de teste ao mesmo tempo em que o código é desenvolvido. As vantagens desta abordagem são criar casos de teste mais objetivamente, não sendo influenciado pelo estilo do código e não deixar de escrever algum caso. 7.2. Teste de integração ou modular Os testes de integração verificam a execução correta de componentes da aplicação de não requerem que esta interaja com outras aplicações. A comunicação dentre os módulos dentro dos subsistemas é testada em um ambiente controlado e isolado. Os objetivos deste teste são verificar tecnicamente a correta interação entre os módulos e subsistemas. O teste de integração deve ser feito a fim de verificar os requisitos funcionais do sistema. Este teste ocorre após as fases de teste unitário dos módulos e possui como produtos de entrada o desenho interno e externo da aplicação, além do Plano Mestre de Testes e Plano de Testes de Integração e, como produto de saída, o Relatório do teste de Integração. Quem deve participar deste teste é o desenvolvedor e o testador, usando como método técnicas de caixa branca e caixa preta, além de gerenciamento de problemas e configuração. As
  36. 36. 27 ferramentas ideais para este nível de teste são debug, reestruturação, e analisadores de código. Para que este nível de teste possa ser feito seu executor deve ser treinado na metodologia de testes e no uso efetivo das ferramentas descritas anteriormente. 7.3. Teste de sistemas Os testes de sistemas verificam a correta execução de todos os componentes da aplicação incluindo interfaces com outras aplicações. Tanto os testes funcionais quanto estruturais são feitos para verificar que o sistema esteja funcionando. Os objetivos deste teste são verificar que os componentes do sistema exerçam funções de controle, executar testes entre os sistemas e demonstrar que o sistema funcione tanto funcional quanto operacionalmente como especificado. Durante o teste de sistemas, a estabilidade funcional e estrutural do sistema será demonstrada assim como os requisitos não funcionais, como desempenho e confiabilidade. Este teste ocorre após as fases de teste de integração e possui como produtos de entrada os requisitos detalhados e o desenho externo da aplicação, além do Plano Mestre de Testes e Plano de Testes de Sistemas e, como produto de saída, o Relatório do teste de Sistemas. Quem deve participar deste teste é o desenvolvedor, o testador e os usuários, usando como método técnicas de gerenciamento de problemas e configuração. 7.4. Teste de integração de sistemas Os testes de integração de sistemas verificam a integração de todas as aplicações, incluindo interfaces internas e externas à organização com seus componentes físicos, lógicos e de infra-estrutura em um ambiente similar ao de produção. Os objetivos deste teste são testar a existência de produtos e aplicações que são necessárias para funcionarem juntas em um ambiente similar ao de produção (físico, lógico e de rede), garantir que o sistema funcione junto a todos os componentes do ambiente como um sistema total e garantir que as versões do sistema possam ser implantadas no ambiente atual. Este teste ocorre após as fases de sistema e possui como produtos de entrada a estratégia de teste, além do Plano Mestre de Testes e Plano de Testes de Integração de Sistemas e, como produto de saída, o Relatório do teste de Integração de sistemas. Quem deve participar deste teste é o testador de sistemas, usando como método técnicas de caixa branca e caixa preta, além
  37. 37. 28 de gerenciamento de problemas e configuração. Para que este nível de teste possa ser feito seu executor deve ser treinado na metodologia de testes. 7.5. Teste de aceite Os testes de aceite verificam que o sistema esteja de acordo com os requisitos do usuário conforme foram definidos. Este teste simula o ambiente do usuário e enfatiza segurança, documentação e testes de regressão e serve para demonstrar que o sistema funciona como esperado pelo cliente e usuário final para que estes o aceitem. Os objetivos deste teste são verificar que o sistema faça exatamente o que os requisitos pedem para ele fazer, nem mais nem menos. Este teste ocorre após as fases de sistema e possui como produtos de entrada as necessidades do negócio e requisitos detalhados, além do Plano Mestre de Testes e Plano de Testes de Aceite e, como produto de saída, o Relatório do teste de Aceite. Quem deve participar deste teste são os usuários, usando como método técnicas de caixa preta, além de gerenciamento de problemas e configuração. Para que este nível de teste possa ser feito seu executor deve ser treinado na metodologia de testes, conhecimento do produto e da estratégia de lançamento do negócio. 7.6. Testes de operabilidade Os testes de operabilidade verificam que o sistema possa operar em um sistema de operação. Estes testes são feitos depois ou concorrentemente com os testes de aceite. Os objetivos deste teste são garantir que o produto possa operar no ambiente de produção, garantir que o produto atenda a um nível aceitável de serviço conforme estabelecido no SLAxii (Service Level Agreement), garantir que o produto opere como definido nos padrões operacionais e garantir que o produto possa ser recuperado ou reiniciado de acordo com os padrões. Este teste ocorre após as o fim dos testes e possui como produtos de entrada o Plano de Testes de Aceite, o aceite do usuário, Plano de teste operacional, além dos padrões operacionais e, como produto de saída, o Relatório do teste operacional. Quem deve participar deste teste é o pessoal de operações, usando como método gerenciamento de problemas e configuração. Para que este nível de teste possa ser feito devem ser usadas ferramentas de desempenho.
  38. 38. 29 7.7. Resumo É imprescindível sabermos qual o nível de teste que estamos utilizando, já que o foco muda totalmente. Quando estamos fazendo um teste de integração, modular, o foco é de que este módulo funcione, não se importando com a interoperabilidade com os outros módulos. Desta maneira, cada nível de teste muitas vezes tem que criar casos de testes novos, já que o foco a ser testado muda totalmente. Mostramos neste capítulo os níveis básicos de teste, que são Teste Unitário, Teste de Integração, Teste de Sistemas, Teste de Integração de Sistemas e Teste de Aceite. Estes níveis não são fixos, podendo ser acoplados a outros dependendo da complexidade do projeto. Muitas vezes, o teste de Integração de Sistemas é feito junto com o teste de Sistemas.
  39. 39. 30 8. Tipos de testes Já vimos os níveis de teste, ou seja, qual é o foco dado a cada nível de teste. Agora, para que esta idéia fique mais fácil de compreender, alguns tipos de testes que podem ser usados em cada nível de testes. É sempre fundamental lembrarmos que nada, em teste, é fixo. Sempre os tipos de teste devem adaptar-se ao produto que se está testando e o tipo de projeto onde este produto está inserido. 8.1. Teste de requisitos Teste de requisitos envolve a verificação e validação destes através de testes estáticos e dinâmicos. A validação dos requisitos é alcançada pelo teste de aceite do usuário. A princípio, o teste de requisitos faz somente a verificação. Os objetivos deste teste são verificar que os requisitos encontrados atendam às necessidades de negócio do usuário final antes que o desenho da aplicação comece e avaliar os requisitos no tocante à sua testabilidade. Este teste ocorre logo após a fase de elicitação de requisitos, tendo como produto de entrada os requisitos detalhados e saída os requisitos verificados. Quem deve participar deste teste são os usuários e desenvolvedores, usando como método JADxiii , técnicas de teste estático, listas de checagem, mapeio, e revisões de documentos. As ferramentas ideais para este nível de teste são ferramentas CASE. Para que este nível de teste possa ser feito seu executor deve ser treinado na aplicação. 8.2. Teste de desenho O teste de desenho envolve a verificação e validação do desenho do sistema através de testes estáticos e dinâmicos. A validação do desenho externo é feito durante o Teste de Aceite do Usuário e a validação do desenho interno é coberta durante o teste Unitário, Integração e Sistema. A princípio, o teste de desenho faz somente a verificação do desenho externo e interno. Os objetivos deste teste são verificar que o desenho do sistema aos requisitos de negócio e técnicos acordados antes que a construção do sistema comece e identificar requisitos faltantes. Este teste ocorre após as fases de desenho interno e externo estarem completas e possui como produtos de entrada o desenho interno e externo da aplicação e, como produto de saída, os desenhos internos e externos verificados. Quem deve participar deste teste são os usuários e
  40. 40. 31 desenvolvedores, usando como método JAD, técnicas de teste estático, listas de checagem, protótipos, mapeio e revisões de documentos. As ferramentas ideais para este nível de teste são ferramentas CASE e de protótipo. Para que este nível de teste possa ser feito seu executor deve ser treinado na aplicação e possuir um treinamento técnico. 8.3. Teste de regressão O teste de regressão verifica que nenhuma mudança indesejável tenha sido introduzida ao sistema como resultado de mudanças em outras partes do sistema. Este teste sempre deve ser feito antes de ser iniciado o teste de uma nova versão, e como último teste, para garantir que nenhum dos consertos dos desvios encontrados durantes os testes da versão corrente tenham criado outros desvios. Para executar um teste de regressão, o sistema deve ser executado pelo menos duas vezes no mesmo cenário de teste, ou seja, a primeira na fase correspondente, e a segunda no teste de regressão, e os resultados são comparados. Os resultados desta comparação são usados para documentar e analisar as diferenças. 8.4. Teste de usabilidade O teste de usabilidade garante que o produto final é usável, de uma maneira prática, dia-a-dia. Este tipo de teste busca a simplicidade e o fato de ser amigável ao usuário. Este tipo de teste normalmente é feito como parte do teste funcional nos níveis de teste de Sistemas e teste de Aceite. Os objetivos deste teste são garantir que o sistema seja fácil de operar de um ponto de vista do usuário e do provedor de serviços, e que as funcionalidades sigam um caminho intuitivo. 8.5. Teste de backup e recuperação Recuperação é a habilidade de um sistema reinicializar após uma falha; este processo normalmente envolve voltar a um ponto no ciclo de processamento onde a integridade do sistema é garantida e refazer as transações deste ponto em diante. A natureza da aplicação, o volume de transações, o desenho interno da aplicação para lidar com o processo de reinício, nível das pessoas envolvidas, ferramentas e documentação, tudo afeta o processo de recuperação.
  41. 41. 32 O teste de backup e recuperação deve ser feito como parte do teste de Sistemas e verificado durante o teste de Desempenho sempre que a continuidade do processo seja um requisito crítico para a aplicação. Riscos de falha e perdas potenciais devido à inabilidade da aplicação de se recuperar ditarão a extensão do teste requerido. 8.6. Teste de desempenho Teste de desempenho é feito para verificar que o sistema atenda o nível desejado de desempenho em um ambiente de produção. O que deve ser considerado aqui é o tempo de resposta, tempo de saída, problemas técnicos de desenho, e assim por diante. O teste de desempenho pode ser feito em um ambiente de produção, em um ambiente simulado ou um protótipo. Na fase de desenho os critérios de desempenho devem ser estabelecidos. A mensuração do desempenho deve começar assim que produtos executáveis (não necessariamente sem defeitos) sejam produzidos. 8.7. Teste de segurança Segurança de um sistema é necessária para garantir a proteção da informação confidencial dentro de um sistema e outros sistemas afetados, protegendo-os de perda, corrupção ou mau uso dos dados. A quantidade de testes necessários dependerá da avaliação dos riscos de uma falha na segurança. Os testes devem focar-se e limitar-se àquelas funcionalidades desenvolvidas como parte do sistema, mas podem incluir funções de segurança previamente implantadas mas necessárias para testar completamente o sistema. O teste de segurança pode começar a qualquer tempo dentro do teste de sistemas, continuar no teste de aceite e ser terminados no teste de operabilidade. 8.8. Teste de stress / volume O teste de stress pode ser definido como processar um grande número de transações no sistema dentro de um determinado período de tempo e é feito para medir as características de desempenho do sistema sob condições de pico de uso. Fatores de stress podem ser aplicados a diferentes aspectos do sistema como transações de entrada, linhas de relatório, tabelas internas, comunicações, capacidade de processamento do computador, saídas, espaço em disco, etc.
  42. 42. 33 O teste de stress não deve começar até as funções do sistema estarem totalmente testadas e estáveis. A necessidade é detectada na fase de desenho e deve começar assim que produtos estáveis sejam entregues. 8.9. Resumo Comentamos aqui apenas os tipos de testes mais comuns, e não todos existentes. Existem muitos outros tipos de teste e cada projeto pode precisar de um tipo de teste diferente. Mas, como se pode perceber, cada tipo de teste se relaciona com uma fase de testes. Para se ter uma idéia melhor, vamos ilustrar a relação dos tipos de teste com os níveis de testes em uma tabela, como veremos a seguir: Tipos Níveis Unitário Integração Sistemas Integração de Sistemas Aceite Operabilidade Função/Requisitos x x x x x Instalação x Interface x X x X Regressão x x x X x Usabilidade x x Backup e Recuperação x x X X Desempenho x X X Segurança x x X X Stress/Volume x X Figura 6 - Relações de Níveis e Tipos de teste
  43. 43. 34 9. Processo de testes A parte mais visível do Processo de testes é a execução, mas isto não é somente o que ocorre no Processo de testes. Para ser mais eficiente e efetivo, os planos de testes devem conter tempo no planejamento dos testes, desenho dos casos de testes, preparação para execução e avaliação do status. O processo de testes básico, assim, deve conter estes passos: • Planejamento e controle; • Análise e desenho; • Implantação e execução; • Avaliar critério de saída e relatórios; • Atividades de fechamento da fase de testes. Mesmo que logicamente ordenadas, algumas vezes estas fases podem se sobrepor e ocorrer simultaneamente. Não podemos nos esquecer também que Testes é um processo iterativo, ou seja, estes passos ocorrerão dentro de cada nível de teste visto anteriormente. A primeira camada de planos e testes é conhecida como Plano Mestre de Testes. As camadas subseqüentes são tratadas como refinamentos adicionais ao Plano Mestre e podem ser chamados de Planos Detalhados de testes. 9.1. Planejamento e controle Planejamento é a atividade de verificar a missão do teste, definir os objetivos do teste e especificar as atividades de testes necessárias para atingir à missão e aos objetivos. Planejar por si só já é um processo completo. Desta maneira, planejar passo a passo garante um plano construído sistematicamente e completamente. Controle é uma atividade contínua de comparar o progresso atual com o esperado no plano. Para controlar o teste, este deve ser monitorado durante todo o processo. Planejamento de testes possui como maiores atividades: • Determinar escopo e riscos, além de identificar os objetivos do teste; • Determinar a abordagem do teste (técnicas, itens a serem testados, cobertura, identificação e envolvimento dos times);
  44. 44. 35 • Determinar os recursos necessários para o teste (por exemplo, pessoas, ambiente, computadores); • Implantar a estratégia de testes; • Agendar tarefas de análise e desenho de testes; • Agendar implantação do teste, execução e avaliação; • Determinar o critério de saída do teste. Controle dos testes possui como maiores atividades: • Mensurar e analisar os resultados; • Monitorar e documentar o progresso, cobertura do teste e critério de saída; • Iniciar ações corretivas, quando necessário; • Tomar decisões. 9.1.1. Escopo do teste O objetivo geral em testar é diminuir os riscos inerentes a sistemas. Assim, áreas devem ser identificadas para serem focados os testes que atendem a determinados riscos/problemas, e devem ser adereçados pela estratégia de teste. É necessário focar o teste porque não existem recursos ilimitados (pessoas, tempo, etc.) e não é possível testar-se todo o sistema exaustivamente. Com este foco, podemos denominar o escopo do teste como os atributos de um sistema que devem ser testados para garantir que os requisitos técnicos e de negócios sejam atendidos. 9.1.2. Análise de risco Medir o risco antes de testar ajuda a identificar aplicações de alto risco, e a aumentar o esforço de testes, e também ajuda a focar em áreas de maior risco onde o teste deve ser mais detalhado. Geralmente, quanto maior o custo potencial de um erro, maior o esforço de testes designado para evitar estes erros. As áreas de risco de maior influência em um projeto são: tamanho do projeto, experiência com a tecnologia e estrutura do projeto. 9.1.3. Objetivos do teste São aqueles que devem ser atingidos para garantir que os objetivos do sistema serão atingidos e que este se demonstrará aceitável ao cliente.
  45. 45. 36 Os objetivos do teste devem focar-se nas grandes atividades de testes que devem ser realizadas para finalizar com sucesso o teste do sistema. O propósito de se definir os objetivos de testes é definir critérios de avaliação de quando o teste estará completo. Os objetivos do teste baseiam-se em requisitos de negócio, requisitos técnicos e riscos. 9.1.4. Estratégia do teste É o conjunto de atividades que serão desenvolvidas para atingir os objetivos do teste. Por exemplo, se o escopo do teste é o desempenho, a estratégia do teste será o teste de stress/volume e teste de desempenho feitos no nível do teste de Integração antes que todo o sistema passe pelo teste de sistemas. Para formar a estratégia, devem ser levados em conta os riscos, restrições e exposições, se existentes. Os planos estratégicos direcionarão as futuras necessidades de recursos e tempo. 9.1.5. Gerenciamento de problemas e controle de mudanças Gerenciamento de problemas é o processo pelo qual os problemas são controlados e rastreados dentro de um projeto de desenvolvimento. É muito importante que a mesma ferramenta de gerenciamento de problemas seja usada no projeto inteiro e esta é uma ferramenta chave para os testadores. Controle de mudanças ou gerenciamento de mudanças controla todas as mudanças feitas no projeto, como requisitos, etc. 9.2. Análise e desenho do teste Análise e desenho do teste é a fase onde os objetivos gerais do teste são transformados em condições tangíveis de teste e desenho de teste. As maiores atividades na análise e desenho do teste são: • Rever a base de testes (requisitos, arquitetura, desenho); • Identificar condições ou requisitos de teste e dados necessários de teste baseado na análise dos itens do teste, especificações, comportamento ou estrutura; • Criar os casos de teste; • Avaliar a testabilidade dos requisitos e do sistema;
  46. 46. 37 • Desenhar a preparação de ambiente necessária e identificar quaisquer necessidades de infra-estrutura e ferramentas. 9.2.1. Revisão da base de testes Antes da criação dos casos de teste em si, devemos identificar qual a base de testes, ou seja, quais são os requisitos, como é a arquitetura e desenho dos sistemas a serem testados. É imprescindível que a primeira atividade do testador, ao entrar em contato com o sistema pela primeira vez, seja ler toda a documentação disponível, começando pelo plano mestre de testes. Desta maneira, temos como atividades: • Identificar a documentação do sistema existente; • Compreender qual o nível do teste a ser feito; • Compreender o critério de entrada e saída desta fase de testes; • Examinar o modelo de dados e diagrama de contexto da aplicação; • Obter a visão e compreensão geral do sistema. 9.2.2. Identificação das condições e requisitos de teste Após a compreensão do sistema a ser testado, devem-se identificar quais serão as condições e requisitos que serão testados nesta fase. Por exemplo, a criação de um caso de teste para um sistema Mainframe difere da criação de um caso de teste para um sistema baseado em web. Da mesma maneira, dependendo do nível do teste, o caso de teste é completamente diferente, além do requisito que deve ser seguido. Caso estejamos testando o nível de teste unitário, devemos nos ater aos requisitos de componente; caso o nível seja um teste de integração, devemos testar os requisitos de sistema, e assim por diante. Da mesma maneira devemos nos preocupar com as condições do teste, quais serão os cenários e abrangência do teste a ser feito. Nesta fase, devemos nos preocupar com a criticidade do sistema assim como a relação custo/benefício. Como já dito anteriormente, um sistema médico deve ser 100% testado por ser um sistema de alta criticidade. 9.2.3. Criação dos casos de teste A criação dos casos de teste deve focar-se nas técnicas de teste, ferramentas, estratégias de criação e integração além das características básicas do sistema a ser testado. Assim, após a compreensão do universo onde o sistema se enquadra, da identificação dos requisitos a serem testadas e as condições, devemos transformar estes requisitos em casos de teste.
  47. 47. 38 Para tal tarefa, usamos as técnicas de caixa preta e caixa branca vistas anteriormente. Ao nos preocuparmos em transformar requisitos em casos de testes, precisamos considerar se os testes serão feitos em processos batch, em telas web, “client server” e considerarmos também o exercício dos testes válidos e inválidos. O tipo de documentação também deve ser levado em consideração (extrair um caso de teste de um requisito é diferente de extrair um caso de teste de um caso de uso). Outro ponto fundamental a ser considerado é que os casos de teste são criados para serem reutilizados (regressão). Para construir um caso de teste devemos: • Compreender o requisito; • Determinar a abordagem a ser usada (caixa preta ou caixa branca); • Desenvolver as condições de teste a serem usadas; • Desenvolver o cabeçalho do caso de teste; • Criar os passos do teste; • Definir os resultados esperados; • Desenvolver os procedimentos e dados (pré-requisitos e pré- condições para que este teste possa ocorrer, dados necessários, tipo de login, etc.). Para transformar um caso de uso em um caso de teste podemos: • Logicamente agrupar os casos de uso. Este agrupamento normalmente é baseado em uma funcionalidade ou seqüência de funcionalidades; • Determinar as estratégias e técnicas de teste que serão aplicadas aos casos de uso e identificar entradas válidas e condições para os testes. Exemplos de técnicas e abordagens: técnicas “basis-path”, cobertura condicional de qualquer condição, técnicas de teste em loop e métodos de classe de equivalência; • Criar testes para entradas e condições inválidas e inesperadas; • Verificar que todos os casos de usos tenham casos de teste associados. 9.2.4. Automação: quando usar Uma consideração sempre importante na criação dos casos de teste é quando utilizar a automação dos casos de teste. Atualmente, muito se fala em automação dos casos de teste, nos seus benefícios e pontos positivos. Mas até que ponto isto é apenas um modismo e não uma necessidade?
  48. 48. 39 Ao ser considerada a automação dos casos de teste devemos considerar um tempo maior para a criação do script do teste (que normalmente é programado), o expertise da equipe de testes na ferramenta de automação e em programação, e a real necessidade de automação. Quando estamos lidando com uma aplicação GUI (Graphic User Interface) altamente volátil, o tempo de construção dos scripts do caso de teste não justifica a automação, visto que o tempo de vida desta aplicação e do script criado é muito pequeno. Agora, se estamos falando de um conjunto de casos de teste de regressão, para uma aplicação estável, que é executado semanalmente antes de um novo release o investimento na criação dos scripts para automação possui retorno total. Ao mesmo tempo, existem alguns tipos de teste que obrigatoriamente devem ser automatizados, como os testes de carga e stress. É praticamente impossível, do ponto de vista financeiro, contratar 300 testadores para executar o mesmo tipo de teste simultaneamente. Nestes casos, a automação é essencial. O processo decisório da automação de um caso de teste deve possuir as seguintes perguntas: 1. Automatizar este caso de teste e executá-lo apenas uma vez custa mais do que executá-lo manualmente apenas uma vez. Quanto mais? 2. Um teste automatizado possui uma linha do tempo finita, durante o qual deve recuperar este custo adicional. Este teste provavelmente deixará de ser válido mais cedo ou mais tarde? Quais são os eventos responsáveis por diminuir seu tempo de vida? 3. Durante seu tempo de vida, qual a probabilidade deste caso de teste encontrar novos defeitos (além daqueles encontrados a primeira vez que foi executado)? Quanto o custo desta incerteza justifica o custo da automação? Como visto, automatizar não é sempre indicado. Devemos sempre levar em consideração a aplicação em si, sua volatilidade, expertise da equipe e custo/benefício da automação para somente então, decidir se deve haver automação e quais são os testes que devem ser automatizados. 9.2.5. Avaliar a testabilidade dos requisitos e do sistema Em um mundo ideal, esta avaliação deveria ser feita na fase de elicitação de requisitos pela equipe de testes já participante do processo. Infelizmente, muitas vezes a equipe de testes é envolvida somente na fase específica destes. Quando isto ocorre, a equipe de testes deve verificar se os requisitos
  49. 49. 40 apresentados são testáveis, ou seja, se são claros, quantitativos, objetivos e não são ambíguos e/ou ambivalentes. Um exemplo de um requisito não testável seria um que diz: “O sistema deve possuir um tempo de resposta adequado”. Adequado é subjetivo, e muitas vezes o que é adequado a uma pessoa não é adequado à outra. O requisito ideal neste caso seria: “O sistema deve possuir um tempo de resposta de no máximo 3 segundos”. Este requisito é quantitativo, objetivo e, desta maneira, testável. 9.2.6. Desenhar a preparação de ambiente e necessidades de infra- estrutura Após a criação dos casos de teste, a equipe de testes possui a visão geral de quais as necessidades de infra-estrutura e quais os dados que o sistema deve possuir para que os testes possam ocorrer. É neste exato momento que a equipe de testes deve fazer um relatório com suas necessidades de infra-estrutura e dados e fazer uma reunião onde devem ser verificados se estes pontos já estão em ordem para que a execução dos testes comece sem empecilhos. Nesta reunião devem participar o gerente de testes, o gerente do projeto, assim como o responsável pela arquitetura e pelo ambiente. Todos reunidos devem decidir se o ambiente está pronto, se todo o código foi compilado, se todos os casos de teste estão criados e revistos, e se todos os dados necessários ao teste estão presentes. Caso obtenha-se uma resposta afirmativa para todos estes pontos, é acordado por todos que a execução dos testes pode começar. 9.3. Execução dos testes A execução dos testes é a fase onde todos os casos de testes criados devem ser executados, os defeitos relatados, arrumados e retestados para garantir que foram consertados com sucesso. As maiores atividades desta fase são: • Executar os casos de teste manuais ou automatizados, caso seja o planejado; • Relatar o resultado da execução do teste gravando as versões do sistema em teste, ferramentas de teste e dados; • Comparar os resultados reais com os resultados esperados;
  50. 50. 41 • Reportar as discrepâncias como incidentes e analisá-las de maneira a encontrar sua causa (gerenciamento de defeitos); • Repetir as atividades de teste para cada discrepância (re-execução do teste para confirmar se o incidente foi corrigido). 9.4. Avaliação do critério de saída e relatórios Avaliar o critério de saída é a fase onde a execução dos testes é avaliada de acordo com os objetivos definidos ao teste. Por exemplo, um critério de saída seria 100% dos casos de teste executados, todos os defeitos com severidade 1 e 2 arrumados e de severidade 3 e 4 adereçados (mesmo que não arrumados, que tenham sido definidos que serão arrumados em uma próxima versão). A fase de avaliação do critério de saída possui as seguintes atividades: • Verificar os resultados dos testes em relação ao critério de saída especificado no plano de testes; • Avaliar se mais testes são necessários ou se o critério de saída deveria ser modificado; • Escrever um relatório resumo da execução dos testes aos stakeholders. 9.5. Atividades de encerramento dos testes A fase de encerramento dos testes ocorre após o término da execução e serve para apresentar os resultados do teste, se o critério de saída foi atingido com sucesso, além de uma reunião de lições aprendidas. A reunião de lições aprendidas serve para toda a equipe de testes se pronunciarem sobre fatos que ocorreram positivos e deveriam ser repetidos em novas versões, fatos que ocorreram que atrasaram ou prejudicaram o teste, enfim, todos os fatos relevantes à fase de testes são avaliados para melhoria contínua da fase de testes em novas versões e novos projetos. As atividades do encerramento dos testes possuem as seguintes atividades: • Verificar quais entregáveis planejados foram entregues, o encerramento dos relatórios dos incidentes ou a abertura de pedidos de mudanças àqueles que continuam abertos, além da documentação do aceite do sistema; • Finalizar e arquivar o testwarexiv , ambiente de testes e sua infra- estrutura para reuso posterior; • Entrega do testware para a organização de manutenção;
  51. 51. 42 • Análise das lições aprendidas para futuras versões e projetos visando a melhoria da maturidade da equipe de testes. 9.6. Resumo Como visto neste capítulo, o processo de testes é um projeto em si dentro de outro projeto. Por este motivo, deve ser cuidadosamente planejado, analisado, desenvolvido e construído. Desta maneira, o esforço da equipe de testes começa junto com o projeto em si, com uma equipe menor, e este esforço vai crescendo conforme o desenvolvimento do software até obter sua atividade máxima na execução, diminuindo depois disso, conforme gráfico a seguir: Curva 'S' 0 50 100 150 200 250 300 350 400 Tempo CasosdeTeste Figura 7 - Curva S - Esforço de Teste
  52. 52. 43 10. Papéis e profissões existentes em testes Cada dia que passa os testes tornam-se mais importantes no mercado de trabalho. E, como a qualidade tornou-se fator fundamental, sem o qual uma empresa não alcança os níveis mais altos de CMM, também aumentou muito a importância de profissionais de testes experientes. Por esta razão, a importância da divulgação dos papéis, profissões e da carreira de testes dentro de uma empresa torna-se fundamental. As empresas devem deixar de colocar apenas profissionais juniores em testes e, quando amadurecem profissionalmente, os direcionarem a área de desenvolvimento e encarar a área de testes como algo sério e profissional, indicando que há sim uma carreira de sucesso em testes. 10.1. Testador O testador desempenha o papel mais simples entre os papéis na equipe de testes. Ele é responsável por executar os casos de testes que já foram criados, relatando os incidentes. Normalmente são usados profissionais mais juniores para este papel. Se bem treinados e guiados, eles podem continuar na carreira de testes, como Analista de Testes. Caso seu perfil seja mais técnico, ele pode ser um Analista de Testes técnico como, por exemplo, um especialista em automação de testes ou um especialista em testes de carga e desempenho. 10.2. Analista de testes - negócios O Analista de Testes focado em Negócios desempenha o papel de criar os casos de testes baseado nos requisitos, extrapolando cenários e fazendo estimativas para quantidade de casos de testes e tempo de criação. Este profissional possui uma grande visão analítica e é capaz de compreender o negócio e o ambiente onde o sistema está inserido. Normalmente o Analista de Testes focado em Negócios trabalha nos níveis de Testes de Integração, Testes de Sistemas e Testes de Integração de Sistemas. Com o tempo e experiência, o Analista de Testes focado em Negócios pode desempenhar o papel de Líder de Equipe, coordenando a equipe de testes e atuando como o braço direito do gerente de testes.
  53. 53. 44 10.3. Analista de testes - técnico O Analista de Testes com foco técnico é um profissional de TI que desempenha um importante papel na equipe de testes. Como ele possui um grande conhecimento de programação, ele é um profissional perfeito para criar os casos de teste automatizados, além de atuar como especialistas nos testes de carga e desempenho. Normalmente, este profissional também possui um vasto conhecimento nas ferramentas específicas de teste para fazer sua automação e os testes de carga/stress/desempenho. 10.4. Líder de equipe O Líder de Equipe desempenha o papel de coordenação dos Analistas de Testes e Testadores, atuando como o braço direito do Gerente de Testes. Possui uma forte visão gerencial, bom relacionamento em equipe e foco nos resultados. Este profissional é responsável pelo reporte diário da criação e execução dos testes, criação dos gráficos como Curva S e administração das ferramentas de testes, como criação dos scripts e cabeçalhos de testes. 10.5. Gerente de testes O Gerente de Testes é um gerente de projeto que atua gerenciando todas as atividades e custos da fase de testes. Este profissional possui a visão gerencial e profundos conhecimentos nas técnicas de gerenciamento de projetos, como PMIxv . Atua diretamente com o Gerente do Projeto do Sistema e assegura a correta execução da fase de Testes e de todas as atividades inerentes a esta. É responsável por todos os relatórios gerencias, pela criação do Plano Mestre de Testes, definição do critério de entrada e saída das fases de teste. 10.6. Gerente de defeitos O Gerente de Defeitos é um profissional que atua como a ponte entre o time de testes e o time de desenvolvimento gerenciando as incidências encontradas e priorizando sua correção.
  54. 54. 45 Possui como principal característica a comunicação e gerenciamento de conflitos, garantindo uma tranqüila execução e correção de defeitos. Também é responsável por gerenciar reuniões diárias de status da correção de defeitos, criação de relatórios gerenciais sobre quantidade, qualidade e causa de defeitos e por aplicar técnicas de redução de defeitos garantindo a melhoria contínua do ciclo de desenvolvimento da aplicação. 10.7. Arquiteto de testes O Arquiteto de Testes é um profissional técnico de TI responsável por desenhar e criar a infra-estrutura do ambiente de testes e de toda a solução de testes, como um todo. Este profissional atua como um verdadeiro arquiteto da solução e do ambiente, definindo quais ferramentas, servidores devem ser utilizados, além dos dados, backup e gerenciamento de versões. 10.8. Resumo Neste capítulo listamos somente os papéis mais comuns e importantes da equipe de testes. Obviamente, existem muitos outros papéis e com certeza com o aprofundamento das técnicas e ferramentas de testes muitas outras profissões serão criadas na carreira de testes. O mais importante é que os executivos de TI percebam que a carreira de testes existe, não é modismo e deve ser exercida em todos os projetos de desenvolvimento de sistemas. E, com o tempo, a devida importância a este profissional seja reconhecida, e que cursos superiores e de pós-graduação específicos na área de testes sejam criados.
  55. 55. 46 11. Defeitos e seu gerenciamento Uma das definições e propósito de testes é “encontrar defeitos”. Por esta razão, entender a necessidade do gerenciamento de defeitos é essencial ao entendimento do que são os testes. Mas, antes de compreender o que é o gerenciamento dos defeitos, devemos entender o que é um defeito. Desta maneira, podemos definir que um Defeito é qualquer erro, falha ou não conformidade na aplicação ou em qualquer documentação relacionada a esta (requisitos, casos de uso, etc.). O gerenciamento de defeitos é um conjunto de processos para gerenciar a rastreabilidade e conserto dos defeitos encontrados durante o teste e desempenhar a análise causal deste. As atividades principais são coletar, armazenar, reportar, analisar e garantir a integridade dos dados dos defeitos. 11.1. Objetivos do gerenciamento de defeitos Entendendo o que é o gerenciamento de defeitos, compreender seus objetivos torna-se muito simples. Os objetivos são: • Facilitar a resolução dos defeitos assegurando a consistência dos dados fornecidos e assegurar que o defeito foi entendido e recriado por parte da equipe de desenvolvedores; • Facilitar a comunicação entre desenvolvedores e testadores; • Melhorar tanto o produto final como o processo de desenvolvimento e gerenciamento de defeitos; • Manter um histórico de defeitos levantados que serão usados para criação de relatórios e que poderão ser consultados em versões futuras. 11.2. Atividades do gerenciamento de defeitos Para atingir os objetivos descritos acima, o gerente de defeitos deve: • Identificar e registrar os defeitos levantados: o candidato a defeito deve ser identificado como válido ou não; • Identificar e definir responsabilidades: verificar a integridade das informações fornecidas (se são suficientes ou não para recriar o defeito), definir o responsável pela sua resolução e se possível definir um prazo;

×