Curso de Engenharia da Computação CMM E PROCESSO DE TESTE DE SOFTWARE

Transcrição

1 Curso de Engenharia da Computação CMM E PROCESSO DE TESTE DE SOFTWARE Cristiano Pereira Godoy Itatiba São Paulo Brasil Novembro de 2004

2 ii Curso de Engenharia da Computação CMM E PROCESSO DE TESTE DE SOFTWARE Cristiano Pereira Godoy Monografia apresentada à disciplina Trabalho de Conclusão de Curso, do Curso de Engenharia da Computação da Universidade São Francisco, sob a orientação do Prof. Dr. Carlos Eduardo Camara, como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Dr. Carlos Eduardo Camara Itatiba São Paulo Brasil Novembro de 2004

3 iii O presente exemplar da monografia CMM e Processo de Teste de Software contempla as correções sugeridas pela banca examinadora durante a apresentação do Trabalho de Conclusão de Curso. Itatiba/SP, 08 de Dezembro de 2004 Prof Dr Carlos Eduardo Camara - Orientador

4 iv CMM e Processo de Teste de Software Cristiano Pereira Godoy Monografia defendida e aprovada em 27 de Novembro de 2004 pela Banca Examinadora assim constituída: Prof Dr Carlos Eduardo Camara (Orientador) USF - Universidade São Francisco - Itatiba - SP. Prof Mestre Sidney Piu de Campos USF - Universidade São Francisco - Itatiba - SP Prof Raimundo Cláudio de Vasconcelos USF - Universidade São Francisco - Itatiba - SP

5 v Agradecimentos Agradeço primeiramente ao Professor Carlos Eduardo Camara, meu orientador, que acreditou em mim e incentivou-me para a conclusão deste trabalho, face aos inúmeros percalços do trajeto. Agradeço também à Analista de Teste do CPqD (Centro de Pesquisas e Desenvolvimento), hoje atual namorada, companheira de percurso e de discussões profícuas, dentro e fora do contexto deste trabalho, agraciando-me incontáveis vezes com sua paciência e conhecimento. Alguns experimentos e vários entendimentos não teriam sido possíveis sem a colaboração de Reginaldo Pereira de Souza e José Rubens Garros Parra, por isso não posso deixar de agradecê-los também. Eu agradeço fraternalmente a todos.

6 vi Sumário Lista de Figuras... vii Lista de Tabelas... viii Resumo... ix 1 Introdução CMM (Capability Maturity Model) Nível 1 Inicial Nível 2 Repetível Nível 3 Definido Nível 4 Gerenciado Nível 5 Otimizado Conceito de Teste Formas Básicas de um Teste Verificação Validação Métodos Fundamentais de Teste Estágios dos Testes de Validação Teste de Unidade Teste de Integração Teste de Usabilidade Teste Funcional Teste de Sistema Teste de Aceitação Processo de Desenvolvimento x Estágios de Teste Concepção do Processo de Teste - Cmm nivel Fluxo de Atividades do Processo de Teste Solicitação Planejamento Projeto Preparação de Ambiente Execução Avaliação Conclusão Contribuições Extensões Referências Bibliográficas... 24

7 vii Lista de Figuras FIGURA 2.1 NÍVEIS DO MODELO CMM... 3 FIGURA 3.1 RELAÇÃO ENTRE PROCESSO DE SOFTWARE E TESTE FIGURA 4.1 FLUXO GERAL DAS ATIVIDADES DE TESTE FIGURA 4.2 ATIVIDADE DE SOLICITAÇÃO DE TESTE FIGURA ATIVIDADE DE PLANEJAMENTO DE TESTE FIGURA ATIVIDADE DE PROJEÇÃO DE TESTE FIGURA 4.5 ATIVIDADE DE PREPARAÇÃO DE AMBIENTE DE TESTE FIGURA 4.6 ATIVIDADE DE EXECUÇÃO DE TESTE FIGURA 4.7 ATIVIDADE DE AVALIAÇÃO DE TESTE... 22

8 viii Lista de Tabelas TABELA 3-1 CATEGORIAS DE TESTE DE SISTEMA TABELA 3-2 CATEGORIAS DE TESTE DE ACEITAÇÃO... 13

9 ix Resumo Esta monografia tem como objetivo principal, descrever um Processo de Teste de Software, utilizando praticas de Nível 3 do modelo de qualidade de software CMU/SEI-CMM Carnegie Mellon University/ Software Engineering Institute-Capability Maturity Model, também conhecido como CMM. Este processo é definido como um fluxo de atividades, onde cada uma possui um conjunto de entradas e saídas necessárias para a sua realização, tarefas a serem realizadas e responsabilidades, e tem como objetivo melhorar a qualidade do software produzido. No entanto, para tal definição é necessário ter o conhecimento do conceito de teste de software com algumas formas básicas, métodos e estágios do teste, além do conhecimento do modelo de qualidade de software CMM.

10 1 1 INTRODUÇÃO Nos últimos tempos a preocupação com a qualidade de software está se tornando cada vez maior em função do grande volume de software produzido atualmente e a exigência cada vez maior de seus usuários para que produza os resultados esperados sem erros ou falhos. A qualidade de software e o teste de software são considerados áreas de conhecimento da Engenharia de Software. Estas áreas têm recebido crescente atenção em função do grande volume de software que é produzido na atualidade[6]. Em função dos altos custos e da grande quantidade de tempo exigida pelas atividades de teste, estas atividades muitas vezes são negligenciadas ou reduzidas e, conseqüentemente, é comum a entrega do software para seu usuário com a presença de defeitos não revelados. Como parte da preocupação pela melhoria da qualidade do software (tanto do produto como do processo), muitas metodologias e técnicas têm sido desenvolvidas ao longo dos anos. O teste de software contribui para a melhoria da qualidade do software produzido na empresa, sendo considerada uma atividade essencial para ascensão ao nível 3 (três) do Modelo CMM (Capability Maturity Model), que é um modelo que permite avaliar a maturidade organizacional de uma empresa de software, tendo como foco o processo de software[4]. Na seção 2 (dois) será abordado o modelo CMM, um modelo de para medir a maturidade de uma empresa juntamente com seus níveis. Na seção 3 (três) será mostrado um pouco de teoria de Teste, como definição de teste, algumas formas, métodos e estágios de testes. Na seção 4 (quatro) quatro será apresentado uma concepção de um processo de teste, com suas atividades, seus critérios de entradas e saídas do inicio ao final do processo.

11 2 2 CMM (CAPABILITY MATURITY MODEL) Na década de 90, iniciou-se um movimento de entendimento e solução de problemas crônicos que afetam a indústria de software, principalmente os relacionados a não cumprimento de prazos, orçamentos e funcionalidades requeridas em seus produtos. Foi reconhecido que vários desses problemas estariam baseados no fato da construção de software estar sendo conduzida por métodos improvisados e de maneira artesanal, muitas vezes, mais dependente do talento profissional e de esforços heróicos individuais, do que de processos formais orientados ao gerenciamento e à engenharia de software[4]. O CMM é uma iniciativa do SEI (Software Engineering Institute) para avaliar e melhorar a capacitação de empresas que produzem software. O projeto CMM foi apoiado pelo Departamento de Defesa do governo dos Estados Unidos (DOD), que é um grande consumidor de software e precisava de um modelo formal que permitisse selecionar os seus fornecedores de software de forma adequada. Embora não seja uma norma emitida por uma instituição internacional como a ISO ou o IEEE, este modelo tem tido uma grande aceitação mundial. O CMM é um guia designado a ajudar as organizações de software a selecionar estratégias de melhoria de processos[3]. O objetivo deste modelo é que o processo de software possa ser repetido, controlado e medido e estabelecer uma compreensão comum entre clientes e a equipe de desenvolvimento de software sobre a necessidade dos clientes, o CMM leva a organização em direção a uma visão integrada onde as necessidades técnicas devem ser mantidas consistentes com as atividades desenvolvidas e com o planejamento do projeto. Para efetuar este processo, os requisitos do software devem ser documentados e revistos pelos gerentes de software e grupos afetados, incluindo representantes dos clientes e da comunidade de usuários. O modelo auxilia as organizações a implementarem um processo de melhoria gradativa, baseado em níveis de maturidade. O termo maturidade está associado ao grau de conhecimento, controle e sistemática de execução de um processo de software atingido por uma organização[3]. O CMM se divide nos seguintes níveis como mostra a figura 2.1:

12 3 processo em melhoria contínua Em otimização (5) processo previsível Gerenciado (4) processo disciplinado pouco controlado processo Definido (3) padronizado Repetível (2) Inicial (1) Figura 2.1 Níveis do Modelo CMM[4] Cada nível especifica um conjunto de processos que devem ser estabelecidos para se atingir a maturidade correspondente ao nível. Adicionalmente, cada nível serve de base para o estabelecimento dos processos do nível seguinte. Os cinco níveis do CMM são organizados em áreas chave (KPA). Ao todo, o modelo possui 18 áreas chave[2]. Cada área chave possui 5 características comuns: Compromisso em realizar Capacidade de realizar Atividades realizadas Medição e Análise Verificação da Implementação Cada área chave possui práticas chaves (KP). Ao todo, o modelo possui 316 práticaschave. As áreas chave do processo constituem a primeira divisão sistemática dentro dos níveis de maturidade de uma organização. Esses grupos de atividades, quando executadas em conjunto, satisfazem um conjunto de metas relevantes para a melhoria da capacitação do processo. O CMM considera cada área chave um processo particular[2].

13 4 Os níveis de maturidade descrevem os problemas mais predominantes daquele nível. Uma organização migra de um nível a outro sempre que consegue operacionalizar todas as áreas-chave específicas de um nível. 2.1 Nível 1 Inicial O desenvolvimento normalmente é caótico e dependente de esforços heróicos individuais. Não existem planos realistas de projeto, estimativas de custos, normas, procedimentos, padrões, documentação e controle que permitam ao gerente e à administração sênior conhecerem a situação do projeto, identificarem riscos, problemas e agirem preventiva ou corretivamente. Desvios não são tratados a tempo ocorrendo problemas freqüentes com relação a prazos, orçamentos, qualidade ou funcionalidades do produto de software [4]. Visibilidade do processo[1]: Estágios das atividades mal definidos; Dificuldade de visualizar e gerenciar o progresso e as atividades do projeto; Os requisitos fluem no processo de uma forma não controlada e há um produto resultante; O cliente somente verifica se os seus requisitos foram atendidos na entrega do produto. Áreas-chave de Processo: Este nível não possui áreas-chave de processos. 2.2 Nível 2 Repetível A organização programa controles básicos de gerenciamento de projetos, incluindo administração de requisitos, planejamento e acompanhamento do projeto de software. Adicionalmente, estabelece-se uma área de qualidade (SQA - Software Quality Assurance) para verificar ativamente a conformidade da aplicação de normas, padrões e procedimentos na condução de projetos. Aspectos como sub-contratação de terceiros, bem como gerenciamento de produtos e subprodutos resultantes dos projetos (SCM - Software Configuration Management), também são considerados no nível 2 do CMM. Ao atingir esse nível, a organização de software estará em melhores condições de controlar projetos,

14 5 gerenciar expectativas de clientes, estimar prazos e custos e assegurar a qualidade de seus produtos finais. [4] Visibilidade do processo[1]: As atividades, medições, pontos e verificação estão definidos; Requisitos do cliente e produtos do trabalho são controlados; É possível medir qualidade, custo e cronograma; O processo de desenvolvimento de software permite o gerenciamento entre pontos de transição ( milestones ); O cliente pode analisar o produto durante o processo de software ( Checkpoints ); Existem mecanismos formais para a correção de desvios; Os processos pertencem aos projetos e não às pessoas. Áreas chave de Processo[1]: RM Gerência de Requisitos SPP Planejamento de Projeto de Software SPTO Acompanhamento e Supervisão do projeto de Software SSM Gerenciamento de subcontratado de software SQA Garantia da qualidade de software SCM Gerência da configuração de software 2.3 Nível 3 Definido Nesse nível, é estabelecido um processo de desenvolvimento de software, notadamente baseado em uma metodologia de trabalho com ciclo de vida definido, técnicas e ferramentas apropriadas. Cria-se o grupo SEPG Sofware Engeneering Process Group, que será a equipe de trabalho responsável por estudar e implementar processos cada vez mais otimizados. No nível 3, temos a implementação de controles qualitativos do processo de software[4]. Visibilidade do processo[1]:

15 6 As atividades no processo definido de projeto de software são visíveis; Os processos utilizados estão estabelecidos e padronizados em toda a organização; Como estão estáveis, os processos podem ser medidos quantitativamente; Gerentes e engenheiros entendem suas atividades e responsabilidades no processo; Gerenciamento preparado pró-ativamente para possíveis riscos; O cliente pode obter status atualizado, rapidamente e corretamente, com detalhe entre as atividades; Os processos pertencem agora à organização e não aos projetos. Áreas chave de Processo[1]: OPF Foco no processo da organização OPD Definição do processo da organização TP Programa de treinamento ISM Gerência Integrada de Software SPE Engenharia de Produto de Software IC Coordenação entre grupos PR Revisões técnicas formais 2.4 Nível 4 Gerenciado A organização implementa métricas para medir características específicas dos produtos de software. São definidas e implementadas maneiras de se coletar, armazenar e analisar dados que servirão de base para melhorias específicas nos processos e produtos. Os controles passam a ser também quantitativo com relação à qualidade dos produtos e a eficiência do processo[4]. Visibilidade do processo[1]: Medidas de qualidade e produtividade são coletadas em todos os projetos; Gerentes possuem uma base de dados para tomadas de decisões; A habilidade de prever resultados é maior e a variabilidade do processo é menor;

16 7 O cliente pode estabelecer um entendimento quantitativo da capacidade do processo e riscos antes do projeto iniciar; Áreas chave de Processo[1]: QPM Gestão quantitativa dos processos SQM Gestão da qualidade de software 2.5 Nível 5 Otimizado A organização implementa meios automáticos para coletar dados sobre métricas visando prevenir a ocorrência futura de problemas e ineficiências. Enquanto os dados coletados no nível 4 possam informar, por exemplo, erros existentes em determinadas porções do software, os dados coletados no nível 5 servirão para otimizar o processo de desenvolvimento como um todo. O enfoque IDEAL é proposto pelo SEI para o ciclo de melhoria do processo de software baseado na iniciação dos esforços de melhoria, diagnóstico do processo de software, estabelecimento de mecanismos para melhoria do processo, ação para implementar as melhorias e nivelamento do processo por toda a organização[4]. Visibilidade do processo[1]: Melhoria contínua do processo objetivando produtividade e qualidade; Gerentes são aptos a estimar e monitorar a eficácia das mudanças; Forte relação de parceria com o cliente. Áreas chave de Processo[1]: DP Prevenção de não-conformidades TCM Gestão de Mudança Tecnológica PCM Gestão de Mudança do Processo

17 8 3 CONCEITO DE TESTE Teste é o processo de executar um programa com o objetivo de revelar a presença de erros e contribui para aumentar a confiança de que o software desempenha as funções especificadas[7]. 3.1 Formas Básicas de um Teste Existem duas formas de se testar um software, de acordo com o momento do processo de software em que o teste será realizado que são: Verificação e Validação[6] Verificação Trata-se de um processo de avaliação dos documentos e informações coletadas nas primeiras fases do processo de desenvolvimento do software devendo ser aplicado a todos os produtos produzidos em cada fase, evitando que os problemas migrem de uma fase para a outra, ou seja, é o processo de avaliar um software para determinar se o produto de uma dada fase de desenvolvimento satisfaz às condições impostas no inicio dessa dada fase. Não envolve em nenhum momento a execução do software no computador. A verificação garante que o software implementa corretamente uma função específica, ou seja, O produto esta sendo desenvolvido de maneira certa? [6] Validação Trata-se de um processo de avaliação de um sistema ou componente durante o seu processo de desenvolvimento ou no final, tendo o objetivo de comprovar se ele está de acordo com os requisitos e especificações realizadas e validadas pelas fases iniciais do projeto, ou seja, é o processo de avaliar um software, durante ou após o processo de desenvolvimento, para determinar se ele satisfaz aos requisitos especificado. A validação garante que o software que foi construído é adequado aos requisitos do cliente, ou seja, O produto certo foi desenvolvido? [6].

18 9 3.2 Métodos Fundamentais de Teste Existe enfoque diferente para categorizarem-se os teste de software e os conceitos divergem entre as pessoas. Do ponto de vista de quem testa, da cobertura, dos riscos, de como os testes estão sendo feitos e dos fornecedores de ferramentas pode-se encontrar diferentes abordagens, mas basicamente podem-se destacar os três métodos abaixo: Método da Caixa Branca - tem por objetivo determinar defeitos na estrutura interna do produto, através de testes que exercitem suficientemente os possíveis caminhos de execução. Requer conhecimento e acesso às estruturas internas do software em desenvolvimento, sendo considerado por alguns autores como teste estrutural. Os testes feitos pelos programadores nos seus códigos são normalmente caixas brancas[7]. Métodos da Caixa Preta - tem por objetivo determinar se os requisitos foram totais ou parcialmente satisfeitos pelo produto. Não verifica como ocorre o processamento apenas os resultados produzidos e não requer conhecimento interno do sistema apenas conhecimento dos requisitos do negócio. É considerado por alguns autores como teste funcional. Os testes feitos pelos usuários do sistema são normalmente caixas pretas[4]. Método da Caixa Cinza - utiliza o método da caixa preta, mas se baseia no conhecimento do funcionamento do software para a construção dos casos de teste.poderia ser exemplificado como um programador testando o seu código (caixa branca), mas avaliando a funcionalidade (caixa preta) ou vice-versa. 3.3 Estágios dos Testes de Validação Os métodos ou técnicas de teste (caixa branca, preta e cinza) devem ser utilizados em conjunto, organizados em estágios (também chamados de fases ou estratégias de teste) estabelecendo como, em que ordem e quem realizarão cada tarefa. Uma estratégia de teste de software integra técnicas de projeto de casos de teste em uma série bem definida de passos que resultam na construção bem sucedida do software [4]. Abaixo será descrito cada estágio do processo de Validação.

19 Teste de Unidade Concentra-se em cada unidade (ou módulo) do software, de acordo com o que é implementado no código-fonte, podendo ser realizado em paralelo para vários módulos. Uma unidade pode ser uma classe ou um conjunto de classes correlatas. Os testes de unidade são geralmente de caixa branca[6] Teste de Integração Concentra-se no projeto e na construção da arquitetura do software, identificando os erros associados às interfaces entre os módulos do software. As unidades que foram testadas separadamente são testadas de forma integrada. Os testes de integração geralmente misturam teste de caixa branca e de caixa preta[7] Teste de Usabilidade Este teste é aplicado várias vezes no processo de desenvolvimento do software, sendo responsável pela interação antecipada do usuário com o software em desenvolvimento, através de desenhos, protótipos ou produtos semi-acabados. Apesar desse tipo de teste ser iniciado na fase de verificação, é considerado uma atividade de validação, pois requer interação do usuário final com o produto acabado[7] Teste Funcional Tem o objetivo de detectar erros entre as especificações funcionais do software e seu atual comportamento. Nesta fase, o software já está totalmente produzido, não sendo necessário o conhecimento das estruturas internas do projeto. São realizados testes de validação de alto nível, se utilizado o Método da Caixa preta. Esses testes devem ser feitos por um grupo independente do desenvolvimento para aumentar a eficiência dos testes a serem aplicados[7] Teste de Sistema O software e outros elementos do sistema são testados como um todo, tendo como meta encontrar erros de comportamento do software em relação aos requisitos e objetivos originalmente especificados. O planejamento deste teste não é uma tarefa fácil, pois não existe um método genérico aplicável em qualquer situação. Uma forma para organizar os teste é relacioná-los em categorias, com objetivos bem definidos e distintos[6]. Os testes de sistemas podem ser subdivididos em categorias como mostra tabela 3.1.

20 11 Funcionais Não- Funcionais Categorias de Testes de Sistemas Utilizam o método caixa preta e têm como objetivo encontrar erros em relação às regras de negócio, aos requisitos e às funcionalidades da aplicação. Estresse Objetivo: Determinar o limite máximo de picos de carga que o software poderá suportar. Confronta o sistema com situação anormais de uso. Condições: Elevação momentânea de parâmetros chave do software como taxa de erros, volume transações, número de usuários simultâneos e combinações destes. Comentários:Trata-se de um tipo de teste fundamental. Carga Objetivos: Determinar o limite máximo de carga que o /Volume software poderá suportar. Condições: Ao contrário de teste de carga/estresse, esse tipo de teste não focaliza situações de pico, mas o aumento contínuo das condições de carga. Configuração Objetivos: Determinar configurações de software hardware, previstas na especificação de requisitos, em que o software não opera de forma adequada. Condições: Produto deve ser testado com todos os softwares e hardwares especificados nos requisitos. Compatibilidade Objetivos: Determinar as áreas em que o software apresenta incompatibilidade, especialmente quando se planeja realizar convenções. Uma situação típica em que isto ocorre é a mudança de versão de ambiente. Condições: Deve-se verificar a compatibilidade entre interfaces de hardware e software de diversas situações. Segurança Objetivos: Detectar formas de quebra de segurança do software. Condições: Validar todas as condições de segurança definidas nos requisitos. Performance Objetivos: Determinar se o desempenho em situações normais e de pico está consistente com os requisitos de

21 12 desempenho especificados. Condições: Medição das taxas de transação e tempos de resposta típicos e comparação com os valores especificados. Comentários: Este depende da especificação dos atributos de desempenho que são difíceis de estimar. Dados baseados em versões anteriores ou protótipos são fundamentais se tais metas são factíveis. Omitir estas informações é altamente indesejável. Instabilidade Objetivos: Determinar se os procedimentos de instalação geram erros. Condições: Devem-se executar as instruções de instalações em ambientais simulados (Laboratório de teste) ou reais, verificando se estas estão claras e completas, observando os resultados produzidos. Comentários: Recomenda-se que este seja executado, por usuários típicos. Confiabilidade/ Objetivos: Determinar as medidas de confiabilidade e Disponibilidade disponibilidade quando o software estiver operando com cargas típicas. Condições: Esse tipo de teste geralmente envolve a operação de software por longos períodos para que se possa medir o grau de confiabilidade e disponibilidade. Comentários: Geralmente é obtida a execução de outros testes de sistema. Recuperação Objetivos: Determinar o comportamento do software após ocorrência de um erro ou outras condições anormais. Condições: Geralmente são obtidos durante a execução de outros testes de Sistema. Comentários: Testar o tempo máximo estabelecido para recuperação de falhas.

22 13 Manutenibilidade Objetivos: Identificar situações em que, dada uma situação de erro do software, informações, documentações, e facilidades de manutenção não estejam disponíveis ou suficientes para a equipe de suporte. Condições: Devem-se provocar erros mais comuns do software e analisar a informação fornecida e o comportamento do sistema. Tabela 3-1 Categorias de Teste de Sistema Teste de Aceitação Tem por objetivo permitir ao cliente e/ou usuário final executar o software já finalizado. É aplicado após os testes de usabilidade, funcionalidade e o de sistemas. A tabela 3.2 lista as categorias de Teste de Aceitação. Categorias de Testes de Aceitação Teste Alpha Quando os clientes são convidados a operar o software em um ambiente simulado no fornecedor. Teste Beta É realizado por alguns clientes selecionados em seu próprio ambiente. Teste de Progressão São elaborados de acordo com a evolução do produto. Na medida em que o software ganha novas funcionalidades, um novo conjunto de testes deve ser criado. Todos os casos de testes nascem como testes de progressão e acabam tornando-se posteriormente testes de regressão durante o ciclo de vida do produto. Teste de Regressão Re-execução total ou parcial de testes previamente executados após uma manutenção corretiva ou evolutiva. Tabela 3-2 Categorias de Teste de Aceitação

23 Processo de Desenvolvimento x Estágios de Teste Cada estágio dos testes de validação é aplicado em um determinado momento do processo de desenvolvimento. Na figura 3.1 apresentamos a relação entre o Processo de Desenvolvimento e os Estágios dos Testes de Validação. Engenharia do Sistema Teste de Sistema Especificação de Requisitos Teste de Validação Projeto Teste de Integração Código Teste de Unidade Figura 3.1 Relação entre Processo de Software e Teste[7] O processo de teste inicia com os testes unitários, que visam verificar se cada módulo ou unidade satisfaz à sua especificação. Após testar separadamente cada módulo, estes são agrupados para compor os subsistemas, conforme a arquitetura do sistema definida na fase de projeto, sendo esta a fase de teste de integração; o objetivo destes testes é mais encontrar falhas de interfaceamento entre os módulos e subsistemas. Os testes de validação visam determinar se o software satisfaz aos requisitos especificados na fase de Análise/ Especificação de Requisitos e os testes de sistema visam exercitar o sistema como um todo, incorporando todos os componentes para determinar se o sistema completo satisfaz à sua especificação.

24 15 4 CONCEPÇÃO DO PROCESSO DE TESTE - CMM NIVEL 3 O Processo de Testes está organizado em atividades, onde cada uma possui um conjunto de entradas e saídas necessárias para a sua realização, tarefas a serem realizadas e responsabilidades. O Processo de Testes diz respeito à organização dos testes para o projeto do sistema, onde as atividades se iniciam em paralelo ao planejamento do projeto, seguindo um modelo iterativo e incremental. O Processo de Testes que está sendo definido diz respeito à organização das atividades de testes de sistemas de software, sendo executados inclusive por uma equipe de testes independente da equipe de desenvolvimento (Equipe de Teste). 4.1 Fluxo de Atividades do Processo de Teste Neste item será abordada cada atividade especifica do processo de teste, juntamente com seus objetivos, tarefas, entradas, saídas e responsáveis. A figura 4.1 mostra o fluxo geral das atividades do processo.

25 16 Início do Processo Solicitar Teste de Software Planejar Teste de Software Projetar Teste de software Preparar Ambiente de Teste Executar Teste de Software Avaliar Teste de Software Fim do Processo Figura 4.1 Fluxo Geral das Atividades de Teste Solicitação As atividades de testes se iniciam a partir de uma solicitação formal, feita por , por exemplo, pela área técnica ou equipe de desenvolvimento do projeto de acordo com a figura 4.2. Objetivo: Iniciar demanda para realização dos testes. Tarefa: Solicitar a necessidade de realização de teste. Entrada: Solicitação de Teste. Saída: Inicio das Atividades de Teste. Responsável: Área Técnica.

26 17 de Solicitação Área Técnica Solicitar Teste de Software Figura 4.2 Atividade de Solicitação de Teste Planejamento A partir da solicitação de testes, é feito um planejamento em conjunto com a área técnica responsável pelo sistema para atender os objetivos do produto a ser testado ( software, sistema ou componentes), definir o que vai ser testado (escopo dos testes), quem vai testar, quando serão realizados os testes, e os recursos necessários. Esta atividade prevê a elaboração de um documento chamado de Plano de Testes de Software, que terá como insumos alguns artefatos de especificação de requisitos. A figura 4.3 irá ilustrar o que foi descrito. Objetivo: Entender os objetivos do produto a ser testado e prever recursos necessários para a realização dos testes. Tarefa: Definir os item a serem testados a partir dos requisitos do projeto; Definir os tipos de testes a serem realizados e a necessidade de utilização de ferramentas de apoio; Definir condições de completeza dos testes (itens a serem testados e grau de cobertura por item); Definir condições termino dos testes; Definir recursos necessários para os testes (software, hardware, pessoas); Definir cronograma das atividades. Entrada: Requisitos do Projeto, para este processo será adotado que minimamente existam três documentos de requisitos, que são: Documento de Requisitos Suplementar, Documento de Caso de Uso e Documento de Requisitos Funcionais. Saída: Plano de Teste de Software. Responsável: Equipe de Teste de Software.

27 18 Documento de Requisitos Suplementar Documento de Caso de Uso Documento de Requisito Funcional Outros Documentos (se aplicável) Plano de Teste de Software Equipe de Teste Planejar Teste Figura Atividade de Planejamento de Teste Projeto Após o planejamento, a bateria de teste deve ser definida. Para tal os casos de teste e os procedimentos de teste são definidos, juntamente com a ordem de execução dos mesmos e são selecionados artefatos de teste de outros projetos que possam ser reaproveitados. Os casos de teste contêm valores de entrada e valores de saída esperados para cada instância de teste e as pré-condições necessárias para que o caso de teste possa ser executado. Os valores de entrada são escolhidos de acordo com critérios que maximizam a cobertura dos testes. Os casos de teste serão descritos em um documento chamado Especificação de Teste de Software. Os procedimentos de teste contem uma seqüência de passos a serem executados para a realização de um conjunto de testes semelhantes. Cada procedimento de teste corresponde a um roteiro para: instalação da aplicação a ser testada, instalação de ferramentas de apoio, realização de um caso de uso (teste funcional), scripts de teste (no caso de utilização de ferramentas de automação de testes). Os procedimentos de teste serão descritos em um documento chamado Procedimentos de Teste de Software. A figura 4.4 irá ilustrar o que foi descrito. Objetivo: Definir bateria de Teste, estabelecendo os procedimentos de teste, os casos de teste e a ordem de execução dos mesmos. Define-se como fazer. Tarefa: Definir bateria de testes estabelecendo: os objetivos dos testes e pré-condições necessárias para que o caso de teste possa ser executados; Especificar os Procedimentos de teste; Especificar os Casos de teste.