UNIVERSIDADE DO SUL DE SANTA CATARINA ALESSANDRA MOHR MELHORIA NO PROCESSO DE TESTES DE SOFTWARE ALINHADO AO MODELO DE REFERÊNCIA CMMI

Transcrição

1 UNIVERSIDADE DO SUL DE SANTA CATARINA ALESSANDRA MOHR MELHORIA NO PROCESSO DE TESTES DE SOFTWARE ALINHADO AO MODELO DE REFERÊNCIA CMMI Palhoça 2011

2 ALESSANDRA MOHR MELHORIA NO PROCESSO DE TESTES DE SOFTWARE ALINHADO AO MODELO DE REFERÊNCIA CMMI Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação. Orientador: Prof. Vera Rejane Niedersberg Schuhmacher, Msc. Palhoça 2011

3 ALESSANDRA MOHR MELHORIA NO PROCESSO DE TESTES DE SOFTWARE ALINHADO AO MODELO DE REFERÊNCIA CMMI Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina. Palhoça, 24 de Novembro de Professora e orientadora Vera Rejane Niedersberg Schuhmacher, Msc. Universidade do Sul de Santa Catarina Profa. Maria Inés Castiñeira, Dra. Universidade do Sul de Santa Catarina Erika Reznik. Convidada

4 Dedico esta monografia a minha família, ao meu noivo e aos meus amigos Cátia e Jonathan que me apoiaram durante o andamento da monografia. A professora Maria Inés pela ajuda. A professora Vera pela orientação e apoio nos momentos difíceis.

5 AGRADECIMENTOS A professora Vera, minha orientadora, pelo auxílio, contribuições, orientações e amizade. A professora Maria Inés pela ajuda, atenção e apoio durante toda a confecção da monografia. Aos meus amigos, pelos momentos de distração e alegria. Em especial ao Jonathan e Cátia que durante o último ano me apoiaram e auxiliaram com revisões e sugestões para a monografia. A todas as pessoas da empresa que contribuíram e possibilitaram a execução deste trabalho. Aos convidados da banca por aceitarem o convite e, por dispor o tempo para contribuir com o seu conhecimento e experiência. A todos os professores que contribuíram para a formação acadêmica. Finalmente, a minha família pela compreensão durante os momentos de ausência. A minha irmã, que mesmo sem conhecer o assunto se dispôs a revisar o trabalho, agradeço as revisões, a força e as palavras de incentivo. Ao meu noivo pelo apoio e por estar ao meu lado durante os momentos difíceis. Muito obrigada!

6 RESUMO O software é usado como uma ferramenta para execução e automatização de tarefas, desde as mais simples até as mais complexas. Para que seja utilizado com eficácia, o mesmo deve atender às necessidades do cliente de forma que o seu uso agregue valor ao seu negócio. Construir um software, dependendo de suas características e de seu tamanho, é uma tarefa complexa e, por isso, erros podem ser cometidos durante o desenvolvimento. O teste é um importante recurso para identificar defeitos no software antes dele ser entregue para o cliente. Porém, para que o mesmo seja utilizado de forma eficiente, é importante ter processos definidos para assegurar que as suas atividades de testes estejam organizadas e padronizadas com o objetivo de avaliar, monitorar e mensurar a sua eficácia. Aliados a este contexto, o modelo de referência CMMI é uma importante ferramenta relacionada a melhorias no processo de desenvolvimento de software, fornecendo, também, padrões e metas para processos de qualidade de software. Com o objetivo de aplicar e avaliar os padrões de qualidade do modelo CMMI, esta monografia realizou um estudo de caso dentro de uma equipe de testes de uma empresa desenvolvedora de software. O processo atual foi mapeado e melhorias foram identificadas à luz da área de Verificação do modelo de referência CMMI. Os resultados obtidos, após a implantação e validação de algumas melhorias, demonstraram que os benefícios observados foram importantes em diferentes aspectos, como, por exemplo, redução do tempo para execução das atividades e melhor planejamento e acompanhamento do projeto. Palavras-chave: Teste de software, processo, CMMI.

7 ABSTRACT The software is used as a tool for implementing and automating tasks, from the simplest to the most complex. To be used effectively, it must meet the needs of the client so that its use adds value to your business. Building a software, depending on its characteristics and its size, is a complex taskand, therefore, mistakes can be made during development. The test is an important resource for identifying defects in software before it is delivered to the customer. But for it to be used with efficiently, it is important to have defined processes to ensure that their tests activities are organized and standardized in order to assess, monitor and measure its effectiveness. Allied to this context, the CMMI's reference model is an important tool related to improvements to the software development process, providing also standards and targets for software quality processes. With the objective of implement and evaluate CMMI's quality standards, this monograph conducted a case study with a test team of a software development company. The current process was mapped and improvements were identified using Verification CMMI's reference model. The results after the implementation and validation of some improvements, demonstrated that the benefits ware important in different aspects, for example, reducing the time for execution of activities and better planning and monitoring of the project. Keywords: Software testing, process, CMMI.

8 LISTA DE FIGURAS Figura 1 - Valores das metodologias ágeis Figura 2 Ciclo do Scrum Figura 3 Etapas Figura 4 - Macro processo da atividade de testes de software Figura 5 - Processo de planejamento e acompanhamento da execução dos testes Figura 6 - Processo de descrição e atualização dos casos de teste Figura 7 - Processo execução dos testes Figura 8 - Processo de criação do relatório do término dos testes Figura 9 Novo processo de análise das histórias e definição do tipo de teste Figura 10 Novo processo de planejamento e acompanhamento da execução dos testes Figura 11 - Novo processo de preparação do ambiente de testes Figura 12 Novo processo de revisão e apresentação dos casos de teste Figura 13 Novo processo de execução dos testes Figura 14 Novo processo de fechamento de projeto Figura 15 Novo processo de revisão dos critérios de liberação da release

9 LISTA DE QUADROS Quadro 1 - Tabela de descrição das melhorias Quadro 2 - Melhorias na etapa procedimentos iniciais Quadro 3 - Melhorias na etapa de planejamento Quadro 4 - Melhorias na etapa preparação Quadro 5 - Melhorias na etapa especificação Quadro 6 - Classificação dos testes Quadro 7 - Melhorias na etapa execução Quadro 8 - Melhorias na etapa entrega Quadro 9 - Ordem de implantação das melhorias

10 LISTA DE SIGLAS CAR - Causal Analysis and Resolution CM - Configuration Management CMMI - Capability Maturity Model Integration DAR - Decision Analysis and Resolution GG - Generic Goal IPM - Integrated Project Management ISTQB - International Software Testing Qualifications Board MA - Measurement and Analysis OID - Organizational Innovation and Deployment OPD - Organizational Process Definition OPF - Organizational Process Focus OPP - Organizational Process Performance OT - Organizational Training OTAN Organização do Tratado do Atlântico Norte P-CMM - People Capability Maturity Model PI- Product Integration PMC - Project Monitoring and Control PP - Project Planning PPQA - Process and Product Quality Assurance QA - Quality Assurance QPM - Quantitative Project Management RD - Requirements Development REQM - Requirements Management ROI - Return on investment RSKM - Risk Management SAM - Supplier Agreement Management SE-CMM - Systems Engineering Capability Maturity Model SG - Specific Goal SW-CMM - Capability Maturity Model for Software

11 TS - Technical Solution VAL - Validation VER - Verification

12 SUMÁRIO 1 INTRODUÇÃO PROBLEMA OBJETIVOS Objetivo Geral Objetivos Específicos JUSTIFICATIVA ESTRUTURA DA MONOGRAFIA QUALIDADE DE SOFTWARE ENGENHARIA DE SOFTWARE E QUALIDADE O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Fases genéricas do processo de software Definição Desenvolvimento Manutenção Metodologias ágeis Scrum TESTES DE SOFTWARE Processo de teste de software Procedimentos iniciais Planejamento Preparação Especificação Execução Entrega Modelos de processo de teste de software Equipe de testes Cargos e funções TÉCNICAS DE TESTE DE SOFTWARE Testes unitários Testes de integração Testes de sistema...39

13 2.4.4 Testes de aceitação Técnicas de testes Testes funcionais ou caixa-preta Testes de requisitos Testes de regressão Teste tratamento de erros Testes de interconexão Teste estrutural ou caixa-branca Testes de estresse Teste de performance Teste de recuperação Teste de segurança Testes não-funcionais Testes de usabilidade Testes de instalação MODELOS DE MELHORIA DO PROCESSO DE SOFTWARE SW-CMM CMMI Termos e nomenclatura do modelo CMMI Componentes Áreas de processo Níveis de maturidade e capacidade Representação contínua Representação por estágios Metas genéricas Metas e práticas das áreas de processo e níveis de maturidade Metas e práticas do nível 2 de maturidade Metas e práticas do nível 3 de maturidade Metas e práticas do nível 4 de maturidade Metas e práticas do nível 5 de maturidade MÉTODO CARACTERIZAÇÃO DO TIPO DE PESQUISA ETAPAS PARA DESENVOLVIMENTO DO PROJETO DELIMITAÇÕES MODELAGEM DO PROCESSO DE TESTE DE SOFTWARE... 63

14 4.1 DESCRIÇÃO DA EMPRESA ESTUDO DE CASO PROCESSO ATUAL DA ÁREA DE TESTES DA EMPRESA ESTUDO DE CASO Macro processo da atividade de testes de software Procedimentos iniciais Planejamento Preparação Especificação Execução Entrega AVALIAÇÃO DOS PROCESSOS ATUAIS SEGUNDO A ÁREA DE PROCESSO VERIFICAÇÃO DO CMMI Meta específica Preparar-se para verificação Análise de aderência do processo atual Meta específica Realizar revisão por pares Análise de aderência do processo atual Meta específica Verificar produtos de trabalho selecionados Análise de aderência do processo atual PROPOSTAS DE MELHORIAS Procedimentos iniciais Planejamento Preparação Especificação Execução Entrega PROPOSTA DO NOVO PROCESSO Procedimentos iniciais Planejamento Preparação Especificação Execução Entrega IMPLANTAÇÃO E VALIDAÇÃO DAS PROPOSTAS DE MELHORIAS Implantação CONCLUSÕES E TRABALHOS FUTUROS REFERÊNCIAS

15 ANEXO ANEXO A Modelo da planilha utilizada para inserção dos testes...115

16 1 INTRODUÇÃO A informação é um bem valioso dentro de uma empresa. Isso porque ela serve de base para a tomada de decisão e definição de estratégias. Organizar os dados para extrair informações não é tarefa fácil, já fazer essa organização sem a ajuda de um software é praticamente impossível. Os softwares são criados para auxiliar a organização e o armazenamento dos dados. Porém, desenvolver um software que atenda às necessidades de uma empresa pode ser uma tarefa relativamente complexa, isso porque, algumas vezes, a própria empresa não sabe o que realmente precisa. Segundo Kosciansk e Soares (2007, p. 172), sem uma definição precisa daquilo que se pretende construir, perde-se tempo, mais erros são cometidos e a qualidade do produto final é incerta.. Neste contexto, a Engenharia de Software foi desenvolvida visando apoiar o processo de desenvolvimento de software. Segundo Sommerville (2003, p.5), Engenharia de Software é a disciplina da engenharia que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de especificações do sistema até a manutenção desse sistema depois que ele entrou em operação. Não basta ter um software funcionando, é necessário que o mesmo tenha qualidade para ser entregue ao cliente. Dentre os objetos de estudo da Engenharia de Software, encontra-se a qualidade de software. Conforme Hetzel (1987, p. 15), qualidade de software é o conjunto de recursos e características de um software, diretamente relacionado à sua capacidade de satisfazer às necessidades específicas. Segundo Bartié (2002, p. 16), qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos. Portanto, ter um software de qualidade significa que o mesmo atenda aos requisitos captados com o cliente e não apresente falhas críticas que possam inibir o seu uso. Para apoiar a identificação de possíveis problemas no software, que podem ser falhas ou não-atendimento dos requisitos, durante construção, faz-se o uso de métodos de testes. Segundo Hetzel (1983, p. 6 apud HETZEL, 1987), "teste é qualquer atividade que vise a avaliar uma característica ou recurso de um programa ou sistema. Teste é a medida da qualidade do software." O International Software Testing Qualifications Board (2007, p. 10) explica que os testes de software reduzem os riscos de ocorrência de problemas identificados

17 17 pelo cliente. Além disso, ele [...] contribui para a qualidade dos sistemas de software se os defeitos encontrados forem corrigidos antes de implantados em produção. Há de reconhecer, porém, que os processos de testes utilizados nas empresas encontram diversos problemas. Bastos e outros (2007) relatam que, nas décadas de 70, 80 e 90, os testes eram feitos pelos próprios desenvolvedores e, muitas vezes, pelo próprio cliente. Por não conhecer as técnicas adequadas para realização da atividade, os desenvolvedores testavam somente seu próprio código com o pensamento de não encontrar defeitos. Já os clientes faziam os testes quando o produto estava pronto. Assim, os problemas eram identificados quando o sistema já estava em produção, sendo que nessa fase o custo de correção é muito mais alto. Segundo Bastos e outros (2007), um dos caminhos para desenvolver a qualidade do software é aprimorar o processo de testes. Ter pessoas especializadas para a atividade de testes é um dos passos necessários para atingir este objetivo. Mas, além de ter uma equipe de testes, esta precisa ter os processos mapeados e organizados. Segundo o Software Engineering Institute (2006, p. 4), existem [...] três dimensões críticas nas quais as organizações geralmente concentram-se: pessoas, procedimentos e métodos, e ferramentas e equipamentos. Os processos são os responsáveis por manter a coesão entre os três elementos. Além disso, os processos permitem o alinhamento do modo de fazer negócio. Permitem também explorar a escalabilidade e facilitam a incorporação do conhecimento e das melhores práticas. Processos permitem a otimização de recursos. Nos últimos anos, modelos de referência de melhoria do processo foram criados. Segundo Couto (2007, p. 18), os modelos são usados como ferramenta para conseguir mapear e melhorar os processos de desenvolvimento dos softwares. O autor afirma que organismos e entidades de padronização vêm desenvolvendo, em âmbito internacional, normas e modelos que visam assegurar e dar visibilidade à robustez dos processos relativos aos softwares. O modelo Capability Maturity Model Integration (CMMI) é destaque dentre os modelos de referência de melhoria de processo, devido à aceitação e respeito. Este trabalho busca identificar possíveis melhorias no processo de testes de software de uma empresa, tendo como base o modelo de referência CMMI.

18 PROBLEMA O teste é fundamental para garantir a qualidade de um software. Mas, quando o processo de testes não está mapeado e organizado, essa atividade pode ser feita de forma errada ou incompleta. Muitas vezes, os testes são realizados somente na última fase do projeto de software. Por isso, o tempo para testes é determinado, de forma errada, pela diferença entre o número de dias até o prazo e o número de dias utilizado no desenvolvimento. Com isso, o tempo acaba não sendo suficiente para executar os testes de forma adequada. Algumas atividades, como documentação, são deixadas de lado, assim, o risco de não executar um teste importante é alto. Além disso, a falta de definição de padrões e processos pode causar problemas para o projeto. Os resultados de uma atividade podem não ser adequados quando existe uma dependência do entendimento e interpretação das pessoas. Para ampliar as chances de sucesso de uma atividade, é necessário deixar claro o que precisa ser feito e quais são os resultados esperados. A pergunta de pesquisa que se propõe é: É possível por meio do modelo de referência CMMI propor melhorias para o processo de testes da empresa estudo de caso? 1.2 OBJETIVOS Os objetivos desta monografia são divididos em objetivo geral e específicos Objetivo Geral O objetivo desta monografia é mapear os processos da área de testes de uma empresa, analisar os problemas e propor melhorias para o processo, com base no modelo de referência CMMI.

19 Objetivos Específicos Os objetivos específicos são: Pesquisar e analisar os conceitos sobre qualidade e testes de software. Adquirir conhecimento sobre o modelo de referência CMMI. Mapear o processo atual da área de testes da empresa estudo de caso. Analisar os problemas do processo atual. Avaliar as possibilidades de adequação do processo de testes da empresa estudo de caso à área de Verificação do modelo CMMI. Propiciar a melhoria na qualidade do processo de testes da empresa estudo de caso. 1.3 JUSTIFICATIVA Deutsch (1979 apud PRESSMAN, 1995, p. 786) afirma que o desenvolvimento de software envolve uma série de atividades de produção em que as oportunidades de injeção de falhas humanas são enormes. Por isso, a atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão de especificação, projeto e codificação. Ter uma equipe com especialistas focados na atividade de testes é um fator importante para execução das atividades. Porém, para a equipe obter sucesso, é fundamental mapear os processos. Esse é o primeiro passo para a organização e correção das falhas existentes no fluxo de trabalho. Além disso, com o mapeamento do processo, é possível verificar se as atividades estão sendo executadas no momento e de forma correta. A falta de dados precisos e confiáveis dificulta a realização de estimativas corretas. Este pode ser considerado um dos fatores para os atrasos nas entregas dos softwares. Por meio do mapeamento dos processos é possível criar mecanismos para coletar dados e transformá-los em informações úteis para a estimativa do tempo necessário para execução das atividades.

20 20 Portanto, o mapeamento do processo atual é fundamental para a identificação e aplicação de melhorias nas atividades de teste de software da empresa estudo de caso. 1.4 ESTRUTURA DA MONOGRAFIA Esta monografia está dividida em cinco capítulos. O capítulo 1 apresenta uma introdução do assunto, o problema, os objetivos e a justificativa. O capítulo 2 contém a revisão bibliográfica que tem como principal foco a área de testes de software e o modelo de referência CMMI. No capítulo 3, descreve-se o método utilizado, as etapas e delimitações. Já o capítulo 4 apresenta a modelagem dos processos atuais da área de testes da empresa estudo de caso. Além disso, neste capítulo é apresentada a análise da aderência dos processos com o modelo CMMI, as melhorias identificadas e uma proposta de novos processos. Por fim, neste capítulo são apresentados os resultados obtidos com a implantação de algumas melhorias e, a validação da modelagem dos processos e melhorias propostas. Finalmente, o capítulo 5 contém as conclusões e ideias para trabalhos futuros.

21 21 2 QUALIDADE DE SOFTWARE Este capítulo apresenta a fundamentação teórica sobre os temas de domínio como Engenharia de Software, qualidade e testes de software, técnicas de teste de software e o modelo referência CMMI. 2.1 ENGENHARIA DE SOFTWARE E QUALIDADE Ao adquirir um produto ou serviço, as pessoas levam em consideração algumas questões, como, por exemplo: qualidade, nível de atendimento, prazo de entrega e preço. Dependendo do produto ou serviço, algumas dessas questões têm maior relevância. Assim, como em qualquer produto, ao adquirir um software, o cliente deseja que o mesmo tenha qualidade. O atendimento das necessidades e a entrega no prazo são algumas das expectativas dos clientes. Para Inthurn (2001, p.21), desenvolver softwares com qualidade significa: Alinhamento total entre as necessidades/expectativas dos usuários e especificações geradas. Alinhamento total entre as especificações aprovadas e o produto construído, e o produto final com a menor quantidade de erros possíveis. É ainda mais frequente do que se imagina a presença de empresas desenvolvendo e entregando aos seus clientes software apresentando defeitos, mal-estruturados, consumidores de recursos de máquina e, principalmente, que não atendam completamente às necessidades reais dos usuários. Também são frequentes os casos de empresas que atrasam absurdamente a entrega de softwares quer sejam um novo desenvolvimento ou customizações. Muitas dessas empresas que desenvolvem software, talvez a maioria, não utilizam qualquer tipo de método formal na gestão do projeto e documentação do produto. (TONSIG, 2008, p. 66). Os problemas descritos acima não são recentes. Em 1968, foi realizada em Garmish, na Alemanha, uma Conferência Internacional para discutir e tentar tratar a situação de caos em que se encontrava o desenvolvimento de software. O evento foi promovido pelo grupo de estudos em Ciência da Computação, do Comitê de Ciências, da Organização do Tratado do Atlântico Norte (OTAN). O principal organizador do encontro, Professor Fritz Bauer, desejando mostrar a importância da criação de softwares, segundo critérios, escolheu o

22 22 título Engenharia de Software para o evento. O uso desse termo propôs que os softwares poderiam ser produzidos utilizando os processos da engenharia. (TONSIG, 2008, p.68). Nesse evento, Fritz Bauer apresentou o primeiro conceito de Engenharia de Software: O estabelecimento e uso de sólidos princípios de engenharia para que possa obter economicamente um software que seja confiável e que funcione efetivamente em máquinas reais. (PRESSMAN, 1995, p.31). Engenharia de Software é metodologia para desenvolvimento de soluções em software, ou seja, roteiro que pode utilizar diversas técnicas. A sequência de passos preestabelecidos permite optar e variar técnicas e ferramentas nas suas diversas fases. [...] A Engenharia de Software visa sistematizar a produção, manutenção, a evolução e a recuperação de produtos intensivos de software, de modo que ocorra dentro de prazos e custos estimados, com progresso controlado e utilizando princípios, métodos, tecnologia e processos em contínuo aprimoramento. (REZENDE, 1999, p. 4). Segundo Tonsing (2008, p.66), a Engenharia de Software propicia métodos e técnicas que mostram o que deve ser feito na construção de um software. Por método, podese entender um caminho a ser percorrido em etapas em que se aplica um conjunto de técnicas, formas de caminhar pelo caminho, o que permitirá a construção de um software eficiente e seguro. Os métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projetos, análise de requisitos de software e de sistemas, projeto da estrutura de dados, arquitetura de programas e algoritmos de processamento, codificação, teste e manutenção. (PRESSMAN, 1995, p.31). Para sustentar cada um dos métodos, existem ferramentas que auxiliam a automação ou semi-automação dos mesmos. Por outro lado, os procedimentos têm como objetivo construir a ligação entre os métodos e ferramentas para possibilitar o desenvolvimento oportuno e racional de softwares. (PRESSMAN, 1995, p.32). Os procedimentos definem a sequência em que os métodos serão aplicados, os produtos que se exige que sejam entregues (documentos, relatórios, formulários, etc.), os controles que ajudam assegurar a quantidade e a coordenar as mudanças, e os marcos de referência que possibilitam aos gerentes de software avaliar o progresso. (PRESSMAN, 1995, p.32). A construção de um software com qualidade e que atenda plenamente as necessidades do cliente é uma tarefa complexa. Segundo Software Engineering Institute (2006, p. 5), [...] a qualidade de um sistema ou produto é altamente influenciada pelo processo utilizado para desenvolvê-lo e mantê-lo. Por isso, é importante ter processos que orientem as atividades.

23 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Peters e Pedrycz (2001, p.29) explicam que processo de desenvolvimento de software é o conjunto de atividades realizadas para produzir ou evoluir um software. Estas atividades têm como foco a produção de documentos e de um software que atenda as necessidades definidas junto ao cliente. Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, usado para atingir uma meta. Esta meta geralmente está associada a um ou mais resultados concretos finais que são os produtos da execução do processo. (PAULA FILHO, 2001, p. 17). Os processos permitem alinhar a maneira de fazer negócio. Permitem também explorar a escalabilidade e facilitam a incorporação do conhecimento e das melhores práticas. Processos permitem a otimização de recursos e uma melhor compreensão das tendências de negócio. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 4). Segundo Pressman (2006, p. 16), ao elaborar um produto ou sistema [...] é importante percorrer uma série de passos previsíveis um roteiro que ajuda a criar a tempo um resultado de alta qualidade. O roteiro que você segue é chamado de processo de software. Inthurn (2001, p.13) afirma que a melhoria da qualidade do produto não deve restringir-se somente aos métodos utilizados, mas deve concentrar-se no próprio processo de desenvolvimento do software [...], que pode ser controlado, medido e melhorado Fases genéricas do processo de software Segundo Sommerville (2003), o processo de software auxilia a organização das atividades necessárias para o desenvolvimento de um software. Por mais que existam vários modelos de processos de software, existem algumas atividades que são comuns a todos. Pressman (1995) relata que essas atividades, em comum, podem ser chamadas de fases genéricas do processo, e explica que existem três: definição, desenvolvimento e manutenção. A seguir, é apresentada uma breve explicação de cada uma dessas fases.

24 Definição que será desenvolvido. Segundo Pressman (1995), a fase de definição tem como objetivo tornar claro o Durante a definição, o desenvolvedor de software tenta identificar quais informações tem de ser processadas, qual função e desempenho desejados, quais interfaces devem ser estabelecidas, quais restrições de projeto existem e quais critérios de validação são exigidos para definir um sistema bem-sucedido. As exigências fundamentais do sistema e do software são identificadas.[...] Durante a definição, o desenvolvedor tenta definir como a estrutura de dados e a arquitetura de software têm de ser projetadas, como os detalhes procedimentais têm de ser implementados, como o projeto será traduzido numa linguagem de programação e como os testes têm de ser realizados.(pressman, 1995, p.46). Nessa fase, deve ser feita a Análise do Sistema que define o que o software irá desempenhar. Além disso, na definição, deve ser feito o Planejamento do Projeto de Software que tem como objetivo definir o escopo do projeto, fazer análise dos riscos, estimar os recursos e programar as tarefas. Por fim, na definição, é feita a Análise de Requisitos, que pode ser entendida como um detalhamento da função do software. (PRESSMAN, 1995, p.46). Tonsig (2008, p.126) afirma que os requisitos compõem o conjunto de necessidades estabelecidas pelo cliente/usuário do sistema que definem a estrutura e o comportamento do software a ser desenvolvido. Parte do fator de sucesso do desenvolvimento do software encontra-se na fase de Análise de Requisitos. Isso porque, nessa fase, as necessidades do cliente devem ser definidas, entendidas e transformadas em requisitos. Todas as pessoas envolvidas no projeto devem conhecer e entender os requisitos para que o software seja desenvolvido conforme o especificado. (TONSIG, 2008) Desenvolvimento A fase de desenvolvimento tem foco em como fazer. O desenvolvimento pode ser dividido em três macro atividades: Projeto de Software, Codificação e Realização de Testes do Software. (PRESSMAN, 1995).

25 25 Conforme Pressman (1995, p. 47), o Projeto de Software tem como objetivo traduzir [...] os requisitos do software num conjunto de representações (algumas gráficas, outras tabulares ou baseadas em linguagem) que descrevem a estrutura de dados, a arquitetura o procedimento algorítmico e as características de interface. A Codificação tem início após a conclusão da atividade de projeto. O objetivo dessa atividade é transformar os requisitos em trechos de código utilizando uma linguagem de programação para que possam ser lidos e interpretados pelo computador. A última atividade do desenvolvimento é a realização de testes do software. Estes servem para descobrir, relatar e acompanhar a correção de defeitos. Além disso, o teste serve para fornecer informações sobre a qualidade do software Manutenção A fase de manutenção concentra-se nas mudanças que estão associadas às correções de erros, adaptações exigidas à medida que o ambiente do software evolui e ampliações produzidas por exigências variáveis do cliente. (PRESSMAN, 1995, p.47). Segundo Pressman (1995), existem três tipos de mudanças: correção, adaptação e melhoramento funcional. Mesmo aplicando as melhores técnicas de teste de software, provavelmente o cliente irá descobrir defeitos. A manutenção corretiva muda o software para aplicar alguma correção de um problema identificado pelo cliente. A manutenção adaptativa é feita quando existe a necessidade de fazer uma alteração após mudança do ambiente original em que o software foi desenvolvido. Por fim, a manutenção funcional significa uma alteração no software para inclusão de novas funcionalidades que não foram previstas. Empresas desenvolvedoras de software elegem modelos de desenvolvimento de software que consideram mais adequados à sua realidade. A empresa em que este projeto está sendo desenvolvido optou, para a equipe em questão, fazer uso de um modelo considerado ágil, o Scrum.

26 Metodologias ágeis Segundo Pressman (2006, p. 72), nas últimas três décadas, vários métodos e notações para modelagem de Engenharia de Software foram analisadas e projetadas. Esses métodos têm mérito significativo, mas mostraram-se difíceis de aplicar e de manutenção desafiadora. Parte do problema é o peso desses métodos de modelagem. Uma saída para esse problema é a utilização das metodologias ágeis. Conforme Pressman (2006, p. 58), os métodos ágeis foram desenvolvidos em um esforço para vencer as fraquezas percebidas e reais da Engenharia de Software convencional. Para compreender o que são metodologias ágeis é necessário entender o contexto da agilidade na Engenharia de Software. Agilidade tornou-se atualmente uma palavra mágica quando se descreve um processo moderno de software. Tudo é ágil. Uma equipe ágil é uma equipe esperta, capaz de responder adequadamente a modificações. (PRESSMAN, 2006, p. 60). Além da questão das modificações a agilidade engloba a busca por melhorias na comunicação da equipe. A agilidade pode ser aplicada a qualquer processo de software. Entretanto para conseguir isso, é essencial que o processo seja projetado de modo que permita à equipe de projeto adaptar tarefas e aperfeiçoá-las, conduzir o planejamento para que se entenda a fluidez de uma abordagem de desenvolvimento ágil, eliminar tudo menos os produtos de trabalho mais essenciais e mantê-los simples, e enfatizar uma estratégia de entrega incremental que forneça o software funcionando ao cliente o mais rápido possível para o tipo de produto e ambiente operacional. (PRESSMAN, 2006, p. 60). Segundo Soares (2004, p.1), a ideia das metodologias ágeis é o enfoque nas pessoas e não em processos ou algoritmos. Além disso, existe a preocupação de gastar menos tempo com documentação e mais com a implementação. O autor ainda relata que as metodologias ágeis são adaptativas, ou seja, ao invés de tentar prever tudo elas se adaptam aos fatores que ocorrem durante o projeto de desenvolvimento. Há muitos anos, as metodologias ágeis vêm sendo discutida. Em 2001, ocorreu um fato marcante, a Aliança Ágil assinou o Manifesto para o Desenvolvimento Ágil de Software. Scott (2004, p.23) relata que o manifesto é definido por quatro declarações simples: Indivíduos e iterações valem mais que processos e ferramentas; um software funcionando vale mais que documentação extensa; a colaboração do cliente vale mais que negociação de contrato; responder às mudanças vale mais que seguir um plano.

27 27 Os conceitos do lado esquerdo devem ser mais valorizados do que os do lado direito. Scott (2004, p.23) reforça que o manifesto [...] define preferências, não alternativas, encorajando o enfoque de certas áreas, mas sem eliminar outras. Figura 1 - Valores das metodologias ágeis Fonte: Fundamentos do Scrum, Scott (2004) explica que a Aliança Ágil construiu doze princípios com o objetivo de melhorar o entendimento das pessoas sobre o desenvolvimento ágil de software. Segundo o autor, esses princípios são: satisfazer o cliente, entregando softwares continuamente em tempo hábil; mesmo nas fases avançadas do desenvolvimento entender e aceitar que as mudanças de requisitos as vezes são necessárias para conseguir adquirir com o cliente uma vantagem competitiva; entregar softwares funcionando em uma escala de tempo pequena, por exemplo, semanas ou alguns meses; durante todo o projeto deve existir um trabalho em conjunto das equipes de negócio e de desenvolvimento; confiança e motivação são elementos importantes para realização das atividades com sucesso; as informações precisam ser transferidas de forma clara e eficiente. Um dos melhores métodos para fazer isso é conversando pessoalmente com as pessoas. a principal medida de progresso de um projeto é ter o software funcionando; os envolvidos no projeto precisam ter capacidade de manter ritmo constante; para manter a agilidade é importante observar sempre a excelência técnica;

28 28 é essencial manter a simplicidade; a organização é muito importante, ela auxilia a criação de melhores arquiteturas, requisitos e projetos; a equipe deve refletir regularmente sobre como otimizar e tornar mais eficazes os processos. Segundo Pressman (2006, p. 63), existem diferentes modelos ágeis, mas todos [...] satisfazem (em maior ou menor grau) ao Manifesto para o Desenvolvimento Ágil de Software. O Extreme Programming, mais conhecido como XP, o Scrum e Crystal são algumas das metodologias ágeis Scrum O Scrum foi criado em 1990 por Jeff Sutherland e sua equipe. Esse modelo ágil possui alguns padrões de processo que se adaptam a projetos com frequentes alterações nos requisitos e que tenham prazos apertados. (PRESSMAN, 2006). Segundo Soares (2004, p. 5), o Scrum tem como foco encontrar uma forma de trabalho dos membros da equipe para produzir o software de forma flexível e em um ambiente em constante mudança. Os princípios do Scrum são usados para guiar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades de arcabouço: requisitos, análise, projeto, evolução e entrega. Em cada atividade de arcabouço, as tarefas de trabalho ocorrem dentro de um padrão de processo chamado de sprint. O trabalho conduzido dentro de um sprint (a quantidade de sprints necessária para cada atividade de arcabouço varia dependendo da complexidade e do tamanho do produto) é adaptado ao problema em mãos e é definido e, frequentemente, modificado em tempo real pela equipe Scrum. (PRESSMAN, 2006, p. 69). Um dos itens do Scrum é a lista de pendências, também chamada de backlog. Ela contém os requisitos ou características do projeto priorizadas. O gerente de produto avalia as prioridades dos itens a cada inserção de um novo item na lista. (PRESSMAN, 2006). As equipes no Scrum são chamadas de times, são pequenas e multidisciplinares, ou seja, possuem pessoas com diferentes habilidades e conhecimento. Dentro do time, existe o Scrum Master que é responsável por aplicar os conceitos e Scrum. Além disso, o Scrum

29 29 Master é responsável por retirar os impedimentos e garantir que exista a colaboração dentro do time. As reuniões diárias têm como objetivo expor para a equipe o que cada um fez desde a última reunião, os obstáculos que está encontrando e quais atividades estão planejadas até a próxima reunião. As reuniões são rápidas, normalmente 15 minutos. (PRESSMAN, 2006, p. 70). A figura 2 apresenta o ciclo da metodologia Scrum. Figura 2 Ciclo do Scrum Fonte: Entendendo o Scrum, O Scrum é baseado em três fases: pré-planejamento, desenvolvimento e pósplanejamento. No pré-planejamento, é escrito um documento com os requisitos. A priorização e as estimativas de esforço são feitas nessa fase. Além disso, no pré-planejamento é definida a equipe de desenvolvimento e as ferramentas que serão utilizadas. Na segunda fase, ocorre o desenvolvimento do software. Nesta fase, é feita a análise, o projeto, a implementação e os testes. Na fase de pós-planejamento, são feitas as verificações do progresso do projeto. Além disso, no pós-planejamento, ocorre a integração, testes finais e documentação. (SOARES, 2004).

30 TESTES DE SOFTWARE Na metade do ano de 1962, ocorreu a primeira tentativa dos seres humanos de explorar outros planetas. O foguete Marier I foi lançado em uma missão para Vênus. O controle terrestre ordenou o abatimento do foguete após o mesmo desviar da sua rota. Investigações revelaram que a falta de um simples hífen no programa de computador não foi percebida, causando assim falhas no software. O prejuízo dessa falha ultrapassou 18 milhões de dólares. (MARTIN ET MCCLURE, 1991 apud TONSIG, 2008 p. 71 e 72). O desenvolvimento de software está longe de ser tarefa simples. Segundo Delamaro, Maldonado e Jino (2007, p.1), a atividade de desenvolvimento [...] pode se tornar bastante complexa, dependendo das características e dimensões do sistema a ser criado. Desenvolver um software que atenda as necessidades dos clientes depende principalmente da habilidade e interpretação das pessoas que o constroem. Falhas humanas são responsáveis por grande parte dos problemas identificados. Por isso, mesmo utilizando ferramentas e métodos, os erros acabam surgindo. (DELAMARO; MALDONADO; JINO, 2007). Molinari (2003, p. 22 e 23) explica que o custo total efetivo do gerenciamento de qualidade é a soma dos quatro fatores: prevenção + inspeção + falha interna + falha externa. O objetivo da prevenção é identificar os erros antes que eles apareçam, ou seja, buscar ações que previnam o aparecimento de defeitos. Já o custo de inspeção tem como foco a medição, avaliação e auditoria dos produtos conforme os padrões e especificações. O custo para corrigir uma falha identificada antes da entrega do software para o cliente, falhas identificadas nos testes, é chamado de custo de falhas internas. Por fim, custos de falhas externas são os custos para corrigir uma falha identificada pelo cliente. Quanto mais falhas externas forem encontradas, mais desastroso será para a reputação da organização ou resultará em perda de faturamento futuro. Delamaro, Maldonado e Jino (2007) afirmam que as atividades de validação, verificação e teste têm como objetivo garantir que o produto está sendo desenvolvido conforme o definido e que apresenta o menor número de falhas. A verificação avalia se o software desenvolvido atende as necessidades definidas. Em termos gerais, a verificação diz respeito à atividade global de avaliação de software, englobando a revisão, inspeção, teste, análise de desempenho e auditoria. (HETZEL, 1987,

31 31 p. 14). Para Pressman (2006, p.289), verificação é o [...] conjunto de atividades que garante que o software implementa corretamente uma função específica. Por outro lado, validação é o conjunto de atividades diferentes que garante que o software construído corresponde aos requisitos do cliente. (PRESSAMAN, 2006, p. 206). Segundo Hetzel (1987, p.14), validação é o processo de avaliação do software no final do processo de desenvolvimento para ratificar o atendimento das necessidades previamente estabelecidas. Tradicionalmente teste de software é considerado um processo de validação, isto é, uma fase do ciclo de desenvolvimento do produto. Depois que o programa é terminado, o sistema é validado ou testado para determinar sua funcional e operacional performance. Quando a verificação é incorporada ao teste, o teste corre durante o desenvolvimento também. É uma prática combinar verificação com validação no processo de testes. (MOLINARI, 2003, p. 23). Os testes de software, que envolvem executar uma implementação do software com os dados de teste e examinar as saídas dele e seu comportamento operacional, a fim de verificar se ele está sendo executado conforme o esperado. Os testes são uma técnica dinâmica de verificação e validação porque trabalham com uma representação executável do sistema. (SOMMERVILLE, 2003, p. 358). Teste de software é a mais popular estratégia de gerenciamento de risco. São usados para verificar o encontro dos requisitos com o produto. (MOLINARI, 2003, p. 28). Segundo Koscianski e Soares (2007, p. 337), o objetivo do teste é encontrar defeitos, revelando que o funcionamento do software em uma determinada situação não está de acordo com o esperado. Inthurn (2001, p.51) afirma que o teste tem como objetivo [...] aprimorar a produtividade e fornecer evidências da confiabilidade e da qualidade do software em complemento a outras atividades de garantia de qualidade ao longo do processo de desenvolvimento de software. As finalidades do teste são: adquirir confiança no fato de que um sistema pode ser usado com uma margem de risco aceitável; fornecer informações que impeçam o aparecimento de erros; fornecer informações que ajudem a detectar erros antes do momento em que eles normalmente se manifestariam; descobrir erros e deficiências de um sistema; determinar quais são os recursos de um sistema; fornecer informações sobre a qualidade de um software. (HETZEL, 1987, p. 17). Molinari (2003, p. 97) explica que os testes e garantia de qualidade, também chamada de QA (Quality Assurance), são usados para descrever um grupo de processos de verificação e validação de software. O autor explica que a principal diferença entre essas duas atividades está no foco que cada uma tem. A meta de um testador de software é achar

32 32 bugs 1, achando-os o mais cedo possível, para que possam ser consertados o quanto antes. Por outro lado, as pessoas que trabalham na área de garantia de qualidade têm como meta criar e reforçar padrões e métodos de melhoria de desenvolvimento do processo e prevenir a ocorrência de bugs Processo de teste de software Assim como a atividade de desenvolvimento, a atividade de testes de software precisa ter um processo definido. Conforme abordado anteriormente, existem diversos modelos de desenvolvimento de software, mas algumas atividades são comuns a todos. O teste de software é uma dessas atividades. O ciclo de vida de testes pressupõe que sejam realizados testes ao longo de todo o processo de desenvolvimento. Em determinados pontos, os produtos intermediários do ciclo de desenvolvimento devem ser revisados com objetivo de criar as condições necessárias para uma correta implementação, procurando-se identificar defeitos o mais cedo possível. Os ciclos de vida de testes e de desenvolvimento são totalmente interdependentes, mas o ciclo de testes é dependente da conclusão dos produtos das atividades do ciclo de desenvolvimento. (BASTOS et al., 2007, p. 40). O processo de teste de software pode ser representado pelas seguintes etapas: Procedimentos iniciais, Planejamento, Preparação, Especificação, Execução e Entrega Procedimentos iniciais O objetivo da etapa de procedimentos iniciais é aprofundar o [...] estudo dos requisitos de negócio que dará origem ao sistema de informação a ser desenvolvido, de modo a garantir que o mesmo esteja completo e sem nenhuma ambiguidade. (BASTOS et al., 2007, p. 45). 1 Bug é um [...] defeito no software que, caso mantido, pode provocar falhas no sistema. (HETZEL, 1987, p. 15).

33 33 O plano de teste inicia nessa etapa. O plano de testes é utilizado para documentar o planejamento da atividade de testes. No plano deve ser observada a base, os requisitos da aplicação e os requisitos de teste. As principais atividades e os recursos necessários, pessoal e de ambiente, são descritos no plano de teste. (BASTOS et al., 2007). O plano de teste deve incluir todos os elementos necessários para que os testes sejam executados corretamente. Como elementos, pode-se considerar os procedimentos a serem cumpridos, o ambiente necessário e as ferramentas. (BASTOS et al., 2007, p. 170) Planejamento Segundo o International Software Testing Qualifications Board (2007, p. 15), planejamento de teste é a atividade que consiste em verificar a missão do teste, definido os seus objetivos e especificando as atividades de forma a alcançá-los. Na etapa de planejamento, é definida a estratégia de teste e continua-se a elaboração do plano de teste com a finalidade de [...] minimizar os principais riscos do negócio e fornecer os caminhos para as próximas etapas. (BASTOS et al., 2007, p. 46). Segundo Molinari (2003, p. 125), planejamento de teste é um processo. [...] Em geral, muito se fala de planejamento de testes, e pouco se faz. Muitos gerentes colocam testes em segundo plano, mesmo sabendo das possíveis consequências (e quase sempre) negativas. Bastos e outros (2007) explicam que o planejamento dos testes deve permanecer ativo durante todo o projeto, isso porque constantemente é necessário avaliar os rumos do projeto Preparação Para que o teste seja executado de forma correta e precisa, é importante que o ambiente de teste seja configurado corretamente.

34 34 A fase de preparação tem como objetivo a organizar o ambiente que será utilizado para realização dos testes. Essa configuração abrange desde os equipamentos até os softwares e ferramentas que serão utilizados para automação. Além disso, nessa etapa, é avaliada a necessidade de treinamentos para a equipe. (BASTOS et al., 2007). A criação do ambiente de testes [...] isolado, organizado, representativo e mensurável garante a descoberta de erros reais, ou seja, aqueles que realmente ocorreriam na produção e que porventura não foram descobertos em tempo de desenvolvimento. (BASTOS et al., 2007, p. 83). Além disso, e não menos importante, o ambiente de testes reduz a influência externa (BASTOS et al., 2007). Isso é importante porque as alterações no ambiente podem influenciar completamente o resultado dos testes, por exemplo, um módulo que estava funcionando em um ambiente pode não funcionar em outro ambiente. A garantia da integridade do ambiente de teste está diretamente relacionada à garantia de qualidade do produto. (BASTOS et al., 2007, p. 85) Especificação Na fase de especificação, o foco é a documentação de testes, ou seja, a elaboração e criação dos casos e roteiros de teste. Segundo Inthurn (2001, p.78), um caso de teste é um documento que descreve uma entrada, ação ou evento e uma resposta esperada, a fim de determinar se uma característica da aplicação está sendo executada corretamente ou não. Os casos de teste contêm uma identificação, a descrição dos objetivos, condições de entrada, os passos e resultados esperados ao executar os passos. Os casos de teste [...] refletem os requisitos que serão verificados durante o teste do software. (INTHURN, 2001, p. 78). Os casos de teste e os roteiros de teste devem ser elaboradas dinamicamente durante o decorrer do projeto de teste. Isso equivale a dizer que eles serão elaborados à medida que a equipe de desenvolvimento liberar alguns módulos ou parte do sistema para testes. (BASTOS et al., 2007, p. 47).

35 Execução Na fase de execução, os testes são executados seguindo os casos e roteiros de testes. Os testes deverão ser executados integralmente, por regressão ou parcialmente, sempre que surgir alguma mudança de versão dos programas em teste e nos ambientes de teste preparados, conforme previsto na estratégia e nos planos de teste. (BASTOS et al., 2007, p. 47). A execução dos casos de teste pode ser feita de forma manual ou automatizada. Os resultados obtidos em cada teste devem ser anotados. Os erros ou problemas devem ser relatados. Após a correção dos erros, é necessário executar novamente alguns testes para confirmar se realmente o problema foi solucionado. (INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD, 2007) Entrega O projeto de testes é finalizado na etapa de entrega. Toda a documentação dos testes realizados é arquivada. Além disso, são documentadas as melhorias que podem ser realizadas no processo das atividades de teste. Nessa fase ainda é elaborado um relatório com a descrição das conformidades e não-conformidades identificadas. Nessa fase é feita a verificação do que foi entregue e do que havia sido planejado. Além disso, são avaliadas as lições aprendidas com objetivo de buscar aprimorar a maturidade dos testes. (INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD, 2007).

36 Modelos de processo de teste de software Segundo Molinari (2003), existem modelos de teste de software que auxiliam a representação e orientação do processo de teste, são exemplos de modelos o modelo V e modelo W. O modelo de ciclo de vida em V pressupõe a realização dos testes durante todo o ciclo de desenvolvimento. Segundo esse modelo, para cada atividade de desenvolvimento existe uma atividade de testes, por exemplo, durante a atividade de construção do software são realizados testes nos requisitos e desenhos. Bastos e outros (2007) explicam que o conceito V de teste determina que o processo de testes inicie no momento em que o desenvolvimento tem início. Molinari (2003, p. 118) explica que esse modelo é simples e fácil de ser entendido. As atividades são ordenadas de forma sequencial em níveis de abstração de modo que as conexões com as fases de desenvolvimento ficam extremamente claras. No conceito V de teste, os procedimentos de fazer e conferir convergem do início até o fim do projeto. O grupo que faz trabalha com o objetivo de implementar o sistema, e a equipe que confere, simultaneamente, executa procedimentos de teste visando minimizar ou eliminar riscos. Com esse enfoque, se os grupos trabalharem juntos e de maneira integrada, o alto nível de riscos que caracteriza os projetos de desenvolvimento de software irá decrescer a um patamar aceitável que permita a conclusão bem-sucedida do projeto. (BASTOS et al., 2007, p. 41). O modelo W tem como base o modelo V. A principal diferença entre os dois é que o modelo W tem como objetivo reduzir os custos. Para isso, ele parte do princípio que quanto mais se testa, mais cedo se encontram os problemas. (MOLINARI, 2003, p. 119) Equipe de testes Segundo Bastos e outros (2007, p. 17), em grande parte das empresas, os testes são executados pelos desenvolvedores ou até mesmo pelos clientes. Esse cenário está longe de ser o ideal, isso porque quem poderia garantir que um software testado pelos próprios desenvolvedores está corretamente testado? Com toda a certeza, existem exceções, mas a

37 37 melhor maneira de testar um software é ter um processo de teste claramente definido. Por isso, a seguir, serão apresentados os principais cargos e funções da área de testes Cargos e funções O gestor de qualidade é responsável por verificar se o produto atende as necessidades do cliente e se foi desenvolvido conforme os requisitos. A principal função do gestor de qualidade é controlar a qualidade dos produtos. (BASTOS et al.,2007). O líder do projeto de testes é a pessoa responsável pela liderança de um ou mais projetos de teste. (BASTOS et al.,2007). Segundo o International Software Testing Qualifications Board (2007), as atividades típicas de um líder de teste são: coordenar a estratégia de testes, planejar os testes considerando os riscos do projeto, montar o relatório ao término dos testes, dentre outras. O arquiteto de testes é a pessoa responsável por montar os ambientes de teste, escolher as ferramentas de teste e capacitar a equipe para utilizar o ambiente de testes. (BASTOS et al.,2007). O analista de teste é o técnico responsável pela criação dos casos de teste. Já o testador executa os casos de teste criados pelo analista de testes. Em alguns casos, o próprio testador cria os casos de teste. Além disso, o testador pode auxiliar na configuração do ambiente e automação dos testes. (INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD, 2007). 2.4 TÉCNICAS DE TESTE DE SOFTWARE Segundo Peters e Pedrycz (2001, p. 383), o teste de software é executado em níveis diferentes por todo o ciclo de vida do software. O teste dos componentes individuais é o primeiro a ser feito. Mas testar componentes isolados não é o bastante para garantir que o

38 38 software esteja funcionando. Para isso, existe a necessidade de realizar os testes de integração. Para completar a atividade de testes, existem os testes de sistema e de aceitação. A seguir são detalhadas as fases e técnicas de testes de software Testes unitários Os testes unitários, também chamados de testes de componentes, são o estágio mais baixo da escala de testes e são aplicados, nos menores componentes de código criados, visando garantir que estes atendam as especificações, em termos de características e funcionalidade. (RIOS; TRAYAHÚ FILHO, 2006, p. 13). Segundo Molinari (2003), os testes unitários são feitos no nível de um componente ou uma classe, ou seja, o seu objetivo é testar somente um pedaço de código. O objetivo dos testes unitários é garantir que a lógica do programa esteja completa e correta. Garantir que o componente trabalhe conforme projetado. (PETERS; PEDRYCZ, 2001, p. 383). O teste unitário deve verificar a integridade dos dados armazenados durante a execução do código, se todos os caminhos estão sendo executados pelo menos uma vez e os caminhos de tratamentos de erros, ou seja, o teste deve verificar o comportamento do software quando são inseridos valores não verdadeiros. (INTHURN, 2001). Para realizar os testes unitários, é necessário ter conhecimento do código fonte, por isso, grande parte das vezes o teste é feito pelo próprio desenvolvedor Testes de integração Testar o software dividido por partes garante que cada parte funciona, mas não garante que as parte integradas funcionam. Os testes de integração são realizados para garantir que um ou mais componentes combinados (ou unidades) funcionam corretamente. (MOLINARI, 2003, p. 160).

39 39 Segundo Rios e Trayahú Filho (2006, p. 13 e 14), o objetivo do teste de integração é [...] assegurar que as interfaces funcionem corretamente e que os dados são processados de forma correta, conforme as especificações. Os testes de integração podem ser realizados de forma incremental, ou seja, os testes são executados à medida que os módulos são acrescentados até que todos os casos de teste sejam executados. (RIOS; TRAYAHÚ FILHO, 2006) Testes de sistema Segundo Peters e Pedrycz (2001, p.383), os testes de sistema são executados para garantir que o software como uma entidade completa esteja de acordo com os requisitos operacionais correspondentes. Os testes de sistema são executados pela equipe de testes e têm como foco a execução do sistema como um todo. Esse teste simula a utilização normal do sistema, [...] sendo testadas todas as suas funções de forma mais próxima possível do que irá ocorrer no ambiente de produção. (RIOS; TRAYAHÚ FILHO, 2006, p.14) Testes de aceitação Os testes de aceitação são [...] realizados pelos usuários, visando verificar se a solução atende aos objetivos do negócio e a seus requisitos, no que diz respeito à funcionalidade e usabilidade, antes da utilização no ambiente de produção. (RIOS; TRAYAHÚ FILHO, 2006, p. 15). Segundo Peters e Pedrycz (2001, p. 383), os testes de aceitação servem para determinar se os resultados do teste satisfazem aos critérios de aceitação dos participantes do sistema de software.

40 40 O teste de aceitação não deve ser executado somente no final do processo de desenvolvimento. O correto é executar testes nos produtos intermediários, isso porque quanto antes o problema for identificado, menor será o custo de correção. (BASTOS et al., 2007) Técnicas de testes Os testes de software podem ser divididos em testes funcionais, também chamados de testes caixa-preta, e testes estruturais, conhecidos também como testes caixabranca. As duas estratégias, ou técnicas, são [...] complementares e não exclusivas, o que significa que teremos um produto de maior qualidade se ambos os processos foram aplicados nas etapas de validação do software. (BARTIÉ, 2002, p. 104) Testes funcionais ou caixa-preta Os testes funcionais são utilizados para verificar se as funcionalidades estão de acordo com os requisitos especificados. Esse tipo de teste é realizado sem qualquer conhecimento do código. (RIOS; TRAYAHÚ FILHO, 2006). Os testes caixa-preta procuram identificar erros nas interfaces, na estrutura de dados ou acesso a banco de dados externos, funções ausentes ou incorretas ou problemas de desempenho. (MOLINARI, 2003). Os seguintes testes são considerados testes funcionais: testes dos requisitos, testes de regressão, testes de tratamento de erros e testes de interconexão.

41 Testes de requisitos Como o próprio nome já explica, os testes de requisitos têm como objetivo validar se os requisitos foram implementados corretamente. Os testes de requisitos devem ser considerados formalmente realizados após os programas se tornarem operacionais, embora os requisitos possam ser testados individualmente durante as fases anteriores do ciclo de vida. (BASTOS et al., 2007) Testes de regressão O software é modificado cada vez que um novo módulo ou uma nova funcionalidade é adicionado. Essa modificação pode gerar problemas no software que não existiam. Por isso, existe a necessidade de executar testes novamente após a realização de modificações no software para garantir que não existem efeitos colaterais indesejáveis. Esse tipo de teste é chamado de testes de regressão. (PRESSMAN, 2006). Testes de regressão são particularmente importantes durante a manutenção, pois nessa fase é mais frequente que alterações realizadas afetem outras porções de código. São usados também durante a integração, para confirmar a estabilidade dos módulos já integrados anteriormente. (PAULA FILHO, 2001, p. 172). Segundo Pressman (2006, p. 300), o teste de regressão pode ser conduzido manualmente, re-executando um subconjunto de todos os casos de teste ou usando ferramentas automatizadas de captação/re-execução Teste tratamento de erros Os testes de tratamento de erros determinam a capacidade do sistema de tratar apropriadamente transações incorretas. (BASTOS et al., 2007). Durante a construção, devem

42 42 ser feitos tratamentos no código para resolver erros que possam aparecer durante a execução do software Testes de interconexão Os testes de interconexão têm como objetivo validar a conexão entre softwares. O objetivo é verificar se os dados são transferidos corretamente. Os testes de interconexão devem ser conduzidos sempre que existir uma mudança nos parâmetros entre softwares de aplicações. (BASTOS et al., 2007, p.64) Teste estrutural ou caixa-branca O objetivo do teste de caixa-branca é garantir que as linhas de código estão corretas e serão executadas pelo menos uma vez. (MOLINARI, 2003). Para realizar os testes de caixa-branca, é necessário que o profissional de testes conheça a tecnologia empregada pelo software, bem como possua um adequado conhecimento da arquitetura interna da solução, ou seja, esse profissional deverá ter acesso a fontes, estruturas dos bancos de dados e realizar todos os testes previstos no processo de validação de componentes de software. (BARTIÉ, 2002, p. 104 e 105). Os seguintes testes são estruturais: teste de estresse, teste de performance, teste de recuperação, teste de operação, teste de conformidade e testes de segurança Testes de estresse Os testes de estresse avaliam o comportamento do software quando utilizado em condições extremas, por exemplo, pouca memória ou um grande volume de dados. (BASTOS et al., 2007).

43 43 O teste de estresse é realizado para confrontar os programas com situações anormais, dessa forma, o sistema é carregado com volumes não usuais com a intenção de paralo. Nesse momento, é monitorada a perda de desempenho do sistema e a sua suscetibilidade de falhas durante estas cargas. Se ele para como resultado de uma alta carga, este deverá passar por mais alguns testes de recuperação. (INTHURN, 2001, p.64) Teste de performance Os testes de performance, também chamados de testes de desempenho, tem como objetivo verificar se o software atende os requisitos de desempenho definidos. É fundamental que os requisitos estejam claros e bem definidos. Os cenários de teste também são importantes para esse tipo de teste. Os testes de performance podem ser executados simulando o acesso de n usuários à mesma informação ao mesmo tempo, simulando o trafego intenso na rede ou simular que n usuários estão executando a mesma transação. (BARTIÉ, 2002). O teste de desempenho preocupa-se com o rendimento, tempo de resposta e capacidade especialmente a capacidade do banco de dados. (INTHURN, 2001, p. 65) Teste de recuperação Os testes de recuperação validam a capacidade e qualidade da recuperação do software após crashes, falhas de hardware ou outros problemas catastróficos. (RIOS; TRAYAHÚ FILHO, 2006, p. 16). Segundo Bastos e outros (2007, p. 52), a recuperação é a capacidade de reiniciar operações após a perda da integridade de uma aplicação. O processo de recuperação inicia com a volta da aplicação ao ponto anterior ao problema. O próximo passo é o reprocessamento de todas as transações até o ponto de falha. Algumas aplicações suportam soluções de missão crítica, exigindo alto índice de disponibilidade do software. Nesse caso, a arquitetura da aplicação deve ser tolerante à falhas, ou seja, no caso de erros de qualquer natureza, o software deve ter a capacidade de se manter em execução até que a condição de impedimento

44 44 desapareça. Os testes de recuperação devem também contemplar os procedimentos de recuperação do estado inicial da transação interrompida, impedindo que determinados processamentos sejam realizados pela metade e sejam futuramente interpretados como completos. (BARTIÉ, 2002, P. 118 e 119) Teste de segurança Testes de segurança existem para identificar as vulnerabilidades e repará-las em seguida. (MOLINARI, 2003, p. 189). Rios e Trayahú Filho (2006, p.16) afirmam que esse tipo de teste valida a proteção do software contra acesso interno ou externo não autorizado. Segundo Bartié (2002), o objetivo do teste de segurança é identificar as falhas que possam comprometer a fidelidade e sigilo das informações ou até mesmo perda de dados. A importância desse teste está diretamente relacionada ao risco da perda ou do roubo de informações para os negócios. Algumas informações, se reveladas ou adulteradas, podem comprometer o negócio ou aumentar a vantagem competitiva dos concorrentes. (BASTOS et al., 2007, p. 56). Molinari (2002) explica que os testes de segurança simulam a quebra de protocolos de segurança com objetivo de avaliar o nível de segurança de toda a infraestrutura. Tentar invadir ou derrubar servidores de dados, descobrir senhas, tentar acessar funcionalidades que necessitam de perfil avançado, tentar obter informações sigilosas por meio da extração de backups são exemplos de testes de segurança Testes não-funcionais Além dos testes funcionais e estruturais existem os testes não-funcionais. Segundo o International Software Testing Qualifications Board (2007, p, 26), o teste não funcional valida o como o sistema trabalha. O termo não funcional descreve que o teste é executado para medir as características que podem ser quantificadas em uma escala variável, como o tempo de

45 45 resposta em um teste de performance. (INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD, 2007, p, 27). Os testes de usabilidade e instalação são exemplos de testes não-funcionais Testes de usabilidade A verificação da facilidade de uso do sistema é avaliada pelos testes de usabilidade. Esse tipo de teste é importante principalmente para aplicações web porque a navegação entre as páginas deve ser fácil. (RIOS; TRAYAHÚ FILHO, 2006). Além disso, os testes de usabilidade avaliam a clareza das mensagens e os mecanismos de ajuda ao usuário, por exemplo, mensagens que avisam o usuário quando as ações executadas irão causar danos irreversíveis. (BARTIÉ, 2002) Testes de instalação Os testes de instalação têm como foco a validação dos procedimentos de instalação do software. A ideia é aplicar as muitas variações de instalação (normal e as alternativas) e avaliar seu comportamento durante esses procedimentos. Recomenda-se que o próprio usuário realize essas instalações. (BARTIÉ, 2002, p. 117). Finalmente, a atividade de testes precisa ter o processo mapeado e organizado. Por isso, é importante estudar os modelos de melhoria de processos existentes para aplicar melhorias no processo de testes de software.

46 MODELOS DE MELHORIA DO PROCESSO DE SOFTWARE Segundo Software Engineering Institute (2006, p. 5), a qualidade de um sistema ou produto é altamente influenciada pelo processo utilizado para desenvolvê-lo e mantê-lo. Por isso, é importante para uma empresa ter processos definidos, que possam ser gerenciados e acompanhados, buscando sempre a melhoria contínua. Existem alguns modelos e normas para auxiliar as atividades de melhorias nos processos de software. Um programa de melhoria de processos não pode ser desenhado de forma intuitiva. Ele deve refletir o acervo de experiência dos profissionais e organizações da área. (PAULA FILHO, 2001, P. 387). O Software Engineering Institute tem um importante papel na criação e na manutenção de dois dos principais modelos de melhoria de processo de software. No final da década de 80, o instituto criou o Capability Maturity Model for Software (SW-CMM), Modelo de Maturidade e Capacidade para Software e, após algum tempo o CMMI, resultado da evolução do modelo SW-CMM SW-CMM O SW-CMM é um modelo de referência criado pelo Software Engineering Institute com patrocínio do Departamento de Defesa dos EUA. O objetivo inicial do SW- CMM era avaliar a capacidade dos fornecedores de software do departamento. O modelo tem como foco a melhoria de processos no desenvolvimento de software, ou seja, ele não prevê melhorias de processos em outras áreas, por exemplo, recursos humanos. O objetivo principal do SW-CMM é que as organizações conheçam e melhorem seus processos de desenvolvimento de software com a implementação de práticas definidas. A melhoria de um processo é baseada em vários pequenos passos, não em grandes revoluções. O SW-CMM organiza os passos evolucionários em cinco níveis, que definem uma escala para avaliar a maturidade do processo dentro da empresa. (KOSCIANSKI; SOARES, 2007). Os níveis do SW-CMM são compostos por Áreas- Chave de processos. Para cada área são definidas as metas, e são identificadas as atividades relacionadas. Os níveis são

47 47 cumulativos, ou seja, para conseguir atingir o nível 5, a empresa deve implantar todas as melhorias dos níveis anteriores. (KOSCIANSKI; SOARES, 2007). Os níveis do SW-CMM são: inicial, repetitivo, definido, gerenciado e otimizado. Quando uma empresa está no nível inicial, os processos não são organizados e, muitas vezes, os resultados positivos dependem muito das pessoas envolvidas no projeto. No nível 2, repetitivo, as atividades de desenvolvimento começam a ser organizadas. Nesse nível, é implantada a gestão de requisitos para melhorar a compreensão entre cliente e equipes de desenvolvimento, o planejamento do projeto, a gestão de configuração e de qualidade dentre outras. Os padrões para desenvolvimento de software são incluídos no nível 3. O uso de padrões permite a uniformidade no desenvolvimento de software. No nível 4, gerenciado, dados são coletados e analisados com objetivo de melhorar a qualidade dos processos. Por fim, o nível otimizado, ou nível 5, tem como foco a prevenção de defeitos, automação dos processos e melhoria na qualidade do software. (PETERS; PEDRYCZ, 2001, p. 383) CMMI Após o sucesso do SW-CMM, novos modelos foram criados para outras áreas, por exemplo, P-CMM para os processos de gestão de recursos humanos, SE-CMM para engenharia de sistemas. A diversidade de modelos começou a causar confusão. Para resolver o problema, o Software Engineering Institute criou um modelo integrador chamado CMMI (Capability Maturity Model Integration - Modelo Integrado de Maturidade e de Capacidade) (KOSCIANSKI; SOARES, 2007). Segundo Software Engineering Institute (2006, p. 7), o CMMI [...] é composto pelas melhores práticas associadas a atividades de desenvolvimento e de manutenção que cobrem o ciclo de vida do produto desde a concepção até a entrega e manutenção. O objetivo do CMMI é servir de guia para a melhoria de processos na organização e também de habilidade dos profissionais em gerenciar o desenvolvimento, aquisição e manutenção de produtos ou serviços. Assim como no caso do SW-CMMI esperase que com o uso do CMMI a organização seja mais eficiente, respeitando seus próprios prazos e construindo software com menos erros. (KOSCIANSKI; SOARES, 2007, p. 102). É importante destacar que o CMMI é um modelo de referência que descreve metas e práticas para implantação de melhorias nos processos. Porém, o modelo não define

48 48 como fazer. A definição de como será feito é especificada após análise dos processos da empresa, e isso pode variar de uma empresa para outra Termos e nomenclatura do modelo CMMI Para compreender e aplicar as melhorias nos processos, descritas no CMMI, é importante conhecer os termos e as nomenclaturas descritos no modelo Componentes No modelo CMMI, existem componentes agrupados em três categorias: requeridos, esperados e informativos. Os componentes requeridos descrevem o que uma organização deve realizar para implementar uma área de processo.[...] Os componentes requeridos no CMMI são as metas específicas e as metas genéricas. O critério utilizado na avaliação para decisão se o processo foi cumprido é a satisfação das metas. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 17). Já os componentes esperados orientam os responsáveis durante a aplicação das melhorias nos processos, isso porque eles descrevem o que é necessário fazer. (SOFTWARE ENGINEERING INSTITUTE, 2006). Finalmente, os componentes informativos apresentam detalhes importantes [...] às organizações para auxiliá-las na implementação dos componentes requeridos e esperados. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 17).

49 Áreas de processo Segundo Koscianski e Soares (2007, p.103), uma área de processo é um conjunto de práticas que, quando executadas coletivamente, satisfaz um conjunto de objetivos que é importante para que haja melhoria significativa nessa área. Conforme Software Engineering Institute (2006), o CMMI possui vinte e duas áreas de processo. Abaixo são apresentadas as áreas e seus acrônimos em inglês: Análise e Resolução de Causas (CAR); Gestão de Configuração (CM); Análise e Tomada de Decisões (DAR); Gestão Integrada de Projeto (IPM); Medição e Análise (MA); Implantação de Inovações na Organização (OID); Definição dos Processos da Organização (OPD); Foco nos Processos da Organização (OPF); Desempenho dos Processos da Organização (OPP); Treinamento na Organização (OT); Integração de Produto (PI); Monitoramento e Controle de Projeto (PMC); Planejamento de Projeto (PP); Garantia da Qualidade de Processo e Produto (PPQA); Gestão Quantitativa de Projeto (QPM); Desenvolvimento de Requisitos (RD); Gestão de Requisitos (REQM); Gestão de Riscos (RSKM); Gestão de Contrato com Fornecedores (SAM); Solução Técnica (TS); Validação (VAL); Verificação (VER).

50 50 Cada área de processo possui um objetivo. Este é descrito no componente informativo Objetivo da Área de Processo. Além disso, a documentação do CMMI apresenta na seção Áreas de Processo Relacionadas um componente informativo em que são mostradas as relações entre as áreas de processo. (SOFTWARE ENGINEERING INSTITUTE, 2006). O CMMI possui cinco metas genéricas, uma para cada nível de capacidade. Assim, para alcançar um determinado nível de capacitação, a meta genérica para aquele nível e as práticas genéricas que correspondem àquela meta precisam ser alcançadas. (PRESSMAN, 2006, p. 23). Segundo Pressman (2006, p. 23), as metas específicas estabelecem as características que devem existir se as atividades determinadas por uma área de processo tiverem de ser efetivas. Cada meta específica está associada a um nível de maturidade. No modelo CMMI, as metas específicas e genéricas estão com numeração sequencial. Cada meta específica inicia-se com o prefixo SG (Specific Goal), por exemplo, SG 1. Cada meta genérica é iniciada pelo prefixo GG (Generic Goal), por exemplo, GG 2. (SOFTWARE ENGINEERING INSTITUTE, 2006, p.24) Níveis de maturidade e capacidade Segundo Software Engineering Institute (2006, p. 31), no modelo CMMI, utilizam-se níveis para descrever um caminho evolutivo recomendado para uma organização que deseja melhorar os processos utilizados para desenvolver e manter seus produtos e serviços. Os níveis caracterizam melhorias a partir de um estado em que processos estão mal definidos em direção a um estado que utilize informações quantitativas a fim de determinar e gerenciar melhorias necessárias para satisfazer aos objetivos estratégicos da organização. (SOFTWARE ENGINEERING INSTITUTE, 2006, p.31) Pressman (2006) explica que o CMMI possui duas formas de representar as melhorias nos processos: como um modelo contínuo e como um modelo em estágios. No modelo contínuo, a representação dos níveis é realizada com base na capacidade. Por outro lado, o modelo em estágios utiliza a expressão níveis de maturidade para analisar o nível em que os processos de uma empresa se encontram.

51 51 A escolha do tipo de representação depende da forma de que a empresa deseja implantar as melhorias, por exemplo, a representação contínua permite a escolha da sequência da implantação das melhorias, diferentemente da melhoria por estágios que define um caminho a ser percorrido. Além disso, o conhecimento das pessoas envolvidas na implantação e a existência de um legado podem ser levados em consideração no momento da escolha. Ambas as representações possuem vantagens e desvantagens, e por isso algumas empresas optam por utilizar as duas representações. (SOFTWARE ENGINEERING INSTITUTE, 2006) Representação contínua Segundo Software Engineering Institute (2006, p. 25), a representação contínua permite que a organização escolha uma determinada área de processo (ou grupo de áreas de processos) e melhore processos relacionados a ela. A representação contínua utiliza níveis de capacidade para caracterizar a melhoria. Existem seis níveis de capacidade que vão do nível incompleto ao em otimização. Esse tipo de representação é flexível na implantação porque permite a melhoria no processo de diferentes áreas com nível de profundidade diferente. Uma empresa possui nível de capacidade 0, ou incompleto, quando o processo é executado parcialmente ou não é executado. Uma ou mais metas específicas da área de processo não são satisfeitas e não existem metas genéricas para esse nível, já que não há razão para institucionalizar um processo executado parcialmente. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 34). No nível 1 de capacidades, realizado, os objetivos específicos de cada área devem ser cumpridos com a utilização de processos. (KOSCIANSKI; SOARES, 2007). O nível gerenciado, ou nível 2 de capacidade, tem como característica a execução de processo, utilizando ferramentas adequadas no apoio das atividades e emprega pessoas experientes. Quando uma empresa implementa o nível 2 de capacidade, os processos devem ser monitorados, controlados e revisados. (SOFTWARE ENGINEERING INSTITUTE, 2006). No nível definido, ou nível 3 de capacidade, os processos são executados, seguindo com rigor os padrões definidos. São especificados os padrões e os mesmos devem ser utilizados em qualquer tipo de projeto da empresa. (KOSCIANSKI; SOARES, 2007).

52 52 No nível 4 de capacidade, gerenciado quantitativamente, os processos são controlados e monitorados por meio do uso de estatísticas. (SOFTWARE ENGINEERING INSTITUTE, 2006). No nível 5, otimizado, os processos são [...]sistematicamente gerenciados e implantados. Os efeitos da implantação da melhoria de processos são medidos e avaliados em relação aos objetivos de melhoria quantitativa previamente estabelecidos. (KOSCIANSKI; SOARES, 2007). Os processos são avaliados e melhorados constantemente Representação por estágios A representação por estágios utiliza caminhos em áreas predefinidas para aplicar as melhorias nos processos. O caminho é chamado de nível de maturidade. (SOFTWARE ENGINEERING INSTITUTE, 2006). Um nível de maturidade é um platô evolutivo definido para melhoria de processo da organização. Cada nível de maturidade representa o amadurecimento de um importante subconjunto dos processos da organização, preparando-os para alcançar o próximo nível de maturidade. Os níveis de maturidade são medidos pela satisfação das metas específicas e genéricas associadas a cada conjunto predefinido de áreas de processo. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 37). A representação por estágios prescreve uma ordem de implementação das áreas de processo de acordo com níveis de maturidade, definido um caminho de melhoria para a organização, do nível inicial ao nível em otimização. (SOFTWARE ENGINEERING INSTITUTE, 2006, p.10). O CMMI agrupa as áreas de processo em quatro categorias: gestão de processo, gestão de projeto, engenharia e suporte. Frequentemente, as áreas de processo interagem entre si. (SOFTWARE ENGINEERING INSTITUTE, 2006). Além disso, na representação por estágios, cada área de processo está relacionada a um nível de maturidade, ou seja, cada nível foca a implantação das melhorias em um determinado conjunto de áreas de processo. No nível inicial, a empresa, muitas vezes, possui um ambiente de desenvolvimento de software caótico. Geralmente, os projetos atrasam, e os custos ficam acima do previsto. Nesse nível, o sucesso dos projetos depende muito do comprometimento e empenho das pessoas envolvidas. (KOSCIANSKI; SOARES, 2007).

53 53 Já o nível 2 de maturidade, também chamado de gerenciado, garante que os projetos da organização são planejados e executados conforme uma política, ou seja, a empresa deixa o caos de lado e adota medidas de monitoramento, controle e revisão dos projetos. A implantação do nível 2 de maturidade permite o aumento da visibilidade do andamento e dos resultados de um projeto. (SOFTWARE ENGINEERING INSTITUTE, 2006). No nível definido, ou nível de maturidade 3, os processos são bem entendidos e caracterizados. A padronização de processos possibilita maior consistência nos produtos gerados pela organização. Na descrição dos processos, são usados padrões, procedimentos, ferramentas e métodos bem definidos. (KOSCIANSKI; SOARES, 2007, p. 107). Para conseguir atingir o nível 3 de maturidade, as empresas devem seguir o mesmo padrão, independente do tipo do projeto, essa é a principal diferença do nível 3 para o nível 2. O nível de maturidade 4, gerenciado quantitativamente, é caracterizado pela definição de objetivos de forma quantitativa para o desempenho e qualidade dos projetos. A principal diferença desse nível para o anterior é a análise estatística do desempenho dos processos. (SOFTWARE ENGINEERING INSTITUTE, 2006). Para atingir o nível 5 de maturidade, otimizado, a empresa deve buscar a melhoria contínua de processos. O uso de tecnologia e de inovações e a revisão contínua dos objetivos são necessários para a implantação do nível otimizado Metas genéricas Segundo Software Engineering Institute (2006), o modelo de referência CMMI possui cinco metas genéricas: GG 1 - Satisfazer metas específicas: o objetivo dessa meta é analisar se as metas específicas são atendidas; GG2 - Institucionalizar um processo gerenciado: o objetivo dessa meta é definir quais são as expectativas com relação aos processos. Além disso, todos os envolvidos devem conhecer as expectativas;

54 54 GG 3 Institucionalizar um processo definido: essa meta tem como foco o estabelecimento e a manutenção da descrição dos processos; GG 4 Institucionalizar um Processo gerenciado quantitativamente: o propósito dessa meta é definir objetivos quantitativos para avaliar a qualidade dos processos; GG 5 Institucionalizar um Processo em otimização: o intuito da institucionalização do processo é implantar melhorias de forma sistemática Metas e práticas das áreas de processo e níveis de maturidade A seguir, são apresentadas as metas e práticas de cada área de processo em cada nível de maturidade, conforme a representação por estágios do CMMI. Não existem áreas de processo relacionadas ao nível 1 de maturidade Metas e práticas do nível 2 de maturidade O nível 2 prevê melhorias nos processos das áreas de Planejamento de Projeto, Monitoramento e Controle de Projeto, Gestão de Requisitos, Gestão de Configuração, Gestão de Contrato com Fornecedores, Medição e Análise e Garantia da Qualidade de Processo e Produto. O objetivo da área de processo Planejamento de Projeto é fornecer subsídios para estabelecer e manter planos visando definir as atividades do projeto. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 329). Além disso, ter visibilidade do progresso do projeto é importante para que ações corretivas possam ser tomadas no momento correto. A área de Monitoramento e de Controle de Projeto tem como foco o auxílio nas atividades para monitorar e controlar o andamento do projeto. (SOFTWARE ENGINEERING INSTITUTE, 2006).

55 55 Segundo Couto (2007), a área de Gestão de Requisitos tem como objetivo auxiliar o entendimento entre o cliente e a equipe do projeto dos requisitos abordados. Essa área tem como foco a documentação, controle e manutenção dos requisitos. Conforme Software Engineering Institute (2006, p. 133), o objetivo da área de Gestão de Configuração [...] é fornecer subsídios para estabelecer e manter a integridade dos produtos de trabalho. Para isso, os produtos são identificados, configurados e auditados. Couto (2007) destaca que as metas dessa área são: a identificação dos itens de configuração, o controle sistemático das alterações e possibilidade de rastrear e verificar a integridade das configurações no decorrer do ciclo de vida dos softwares. Segundo Software Engineering Institute (2006), a área de Gestão de Contrato com fornecedores tem como foco o gerenciamento da aquisição de produtos de fornecedores. Por outro lado, a área de Medição e Análise tem como objetivo trabalhar no desenvolvimento de mecanismos para coletar informações para medição. Essas informações devem estar de acordo com as necessidades da gerência. (SOFTWARE ENGINEERING INSTITUTE, 2006). Por fim, a área de Garantia da Qualidade de Processo e Produto tem como objetivo acompanhar e avaliar se os processos estão sendo executados conforme o especificado Metas e práticas do nível 3 de maturidade No nível 3, as seguintes áreas são foco da melhoria dos processos: Análise e Tomada de Decisões, Gestão de Riscos, Gestão Integrada de Projeto, Foco nos Processos da Organização, Definição dos Processos da Organização, Treinamento na Organização, Desenvolvimento de Requisitos, Solução Técnica, Integração de Produto, Validação e Verificação. A área de processo Análise e Tomada de Decisões envolve o estabelecimento de diretrizes para determinar quais questões críticas devem ser submetidas a um processo formal para avaliação de alternativas e a aplicação desse processo nessas questões. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 133).

56 56 Outro ponto importante é ter um processo com o foco na análise dos riscos do projeto. Após mapear os riscos é possível estabelecer planos de contingência e mitigação. A área de Gestão de Riscos tem como foco a identificação dos riscos antes que eles se tornem um problema. (SOFTWARE ENGINEERING INSTITUTE, 2006). O objetivo da área de Gestão Integrada de Projeto é conseguir estabelecer e gerenciar o projeto, utilizando um processo definido e integrado. Já a área de processo Definição dos Processos da Organização, tem como foco o fornecimento de [...] subsídios para estabelecer e manter um conjunto utilizável de ativos de processo da organização e de padrões de ambiente de trabalho. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 221). Além de haver processos definidos, é importante manter uma rotina de melhoria dos processos. A área Foco nos Processos da Organização tem como objetivo o planejamento, implementar e implantar melhorias nos processos. Por outro lado, o objetivo da área de processo Treinamento na organização é fornecer subsídios para desenvolver as habilidades e o conhecimento das pessoas para que elas possam desempenhar seus papéis de forma eficiente e eficaz. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 278). Além disso, a área de Desenvolvimento de Requisitos busca auxiliar a atividade de produção e análise dos requisitos. Segundo Software Engineering Institute (2006, p. 61), a área descreve [...] atividades para obter e controlar mudanças de requisitos e assegurar que outros planos e dados relevantes se mantenham atualizados. Além disso, fornece rastreabilidade de requisitos, desde o cliente até o produto ou o componente de produto. Por outro lado, a área Solução Técnica tem como foco o desenvolvimento de soluções para atender aos requisitos. (SOFTWARE ENGINEERING INSTITUTE, 2006). A integração dos componentes de um produto é fundamental para a execução correta do mesmo. A área de Integração de Produto fornece subsídios para conseguir integrar os produtos de forma progressiva e incremental. (SOFTWARE ENGINEERING INSTITUTE, 2006). O objetivo da área de processo Validação é fornecer subsídios para demonstrar que um produto ou componente de produto satisfaz ao seu uso pretendido quando colocado em seu ambiente pretendido. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 487). A área de processo de Validação possui as práticas de seleção dos produtos, ou seja, os produtos ou componentes que serão validados são identificados, definição do ambiente para validação, estabelecimento dos critérios e procedimentos para validação e a realização da validação, ou seja, a execução dos procedimentos. (SOFTWARE ENGINEERING INSTITUTE, 2006).

57 57 Verificar se os requisitos especificados pelo cliente foram atendidos é essencial para o sucesso de um projeto. A área de Verificação tem como objetivo assegurar que a aplicação atende aos requisitos definidos. A área de processo Verificação envolve: preparação da verificação, execução da verificação e identificação de ação corretiva. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 501) Metas e práticas do nível 4 de maturidade No nível 4, os esforços para melhoria de processo são as seguintes áreas: Desempenho dos Processos da Organização e Gestão Quantitativa de Projeto. O objetivo da área de processo Desempenho dos Processos da Organização é fornecer subsídios para estabelecer e manter um entendimento quantitativo do desempenho do conjunto de processos padrão da organização no apoio aos objetivos para qualidade e para desempenho de processo, e prover dados, baselines e modelos de desempenho de processo para gerenciar quantitativamente os projetos da organização. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 263) Já a área de Gestão Quantitativa de Projeto tem como foco o gerenciamento do processo de forma quantitativa. O objetivo é avaliar a qualidade e desempenho dos processos especificados. (SOFTWARE ENGINEERING INSTITUTE, 2006) Metas e práticas do nível 5 de maturidade As áreas de processo do nível 5 de maturidade são: Análise e Resolução de Causas, Implantação de Inovações na Organização. O objetivo da área de Análise e Resolução de Causas é identificar e resolver as causas de problemas. O foco dessa área é a prevenção dos problemas. Já o objetivo da área de Implantação de Inovações na Organização [...] é fornecer subsídios para selecionar e implementar melhorias incrementais e inovadoras que melhorem, de forma mensurável, os processos e as tecnologias de uma organização. (SOFTWARE ENGINEERING INSTITUTE, 2006).

58 58 3 MÉTODO Segundo Magalhães (2005), método vem da palavra grega methodos e significa através ou ao longo do caminho. Já metodologia é o estudo dos caminhos que podem ser seguidos para resolver um determinado problema. Quando se usa a expressão método científico, o que se quer designar é, geralmente, a estrutura da parte do processo de conhecimento em que são elaboradas e testadas hipóteses que dizem respeito à ciência. (MAGALHÃES, 2005, p. 226). A metodologia científica possui uma grande função: propor métodos, técnicas e orientações que possibilitem coletas, pesquisar, organizar, classificar, registrar, interpretar, dados e fatos, favorecendo a maior aproximação possível com a realidade. (HEERDT; LEONEL, 2007). 3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA Conforme Silva e Menezes (2005, p. 20), pesquisa é um conjunto de ações, propostas para encontrar a solução para um problema, que têm por base procedimentos racionais e sistemáticos. A pesquisa é utilizada quando não existem soluções para um determinado problema. Demo (1996 apud MENEZES E SILVA, 2005, p. 19) afirma que pesquisa é um questionamento sistemático crítico e criativo, mais a intervenção competente na realidade, ou o diálogo crítico permanente com a realidade em sentido teórico e prático. Menezes e Silva (2005, p. 20) dividem a pesquisa do ponto de vista da natureza em básica ou aplicada. A pesquisa aplicada foi utilizada para elaboração dessa monografia. Segundo os autores, a pesquisa aplicada objetiva gerar conhecimentos para aplicação prática e dirigidos à solução de problemas específicos. Envolve verdades e interesses locais. Do ponto de vista da forma de abordagem, uma pesquisa pode ser quantitativa ou qualitativa. O projeto apresenta uma abordagem qualitativa. Pesquisa Qualitativa considera que há uma relação dinâmica entre o mundo real e o sujeito, isto é, um vínculo indissociável entre o mundo objetivo e a subjetividade do sujeito que não pode ser traduzido em números. A interpretação dos fenômenos e a

59 59 atribuição de significados são básicas no processo de pesquisa qualitativa. Não requer o uso de métodos e técnicas estatísticas. O ambiente natural é a fonte direta para coleta de dados e o pesquisador é o instrumento-chave. É descritiva. Os pesquisadores tendem a analisar seus dados indutivamente. O processo e seu significado são os focos principais de abordagem. (MENEZES; SILVA, 2005, p. 20). Conforme Menezes e Silva (2005), os objetivos de uma pesquisa podem ser exploratórios, descritivos ou explicativos. Esse projeto é classificado como pesquisa exploratória, pois tem como foco a familiaridade com um determinado problema de forma a possibilitar a construção de hipóteses. Além disso, a pesquisa exploratória envolve [...] levantamento bibliográfico; entrevistas com pessoas que tiveram experiências práticas com o problema pesquisado; análise de exemplos que estimulem a compreensão. (MENEZES; SILVA, 2005, p. 21). Por fim, Menezes e Silva (2005) afirmam que uma pesquisa pode ser classificada conforme o ponto de vista dos procedimentos técnicos. Seguindo esse ponto de vista, uma pesquisa pode ser bibliográfica, documental, experimental, levantamento, estudo de caso, pesquisa expost-facto, pesquisa-ação e participante. O presente projeto utiliza a pesquisa bibliográfica e estudo de caso. Segundo Menezes e Silva (2005, p. 21), a pesquisa bibliográfica é [...] elaborada a partir de material já publicado, constituído principalmente de livros, artigos de periódicos e, atualmente, com material disponibilizado na Internet. Os mesmos autores afirmam que a pesquisa, estudo de caso, [...] envolve o estudo profundo e exaustivo de um ou poucos objetos de maneira que se permita o seu amplo e detalhado conhecimento. Dessa forma, o presente trabalho também é um estudo de caso, pois ele se constitui em um estudo aprofundado do processo de testes na empresa considerada. 3.2 ETAPAS PARA DESENVOLVIMENTO DO PROJETO O processo de desenvolvimento deste projeto foi subdividido em etapas, são elas:

60 60 Figura 3 Etapas. Fonte: Elaboração do autor, Fundamentação teórica: A fundamentação teórica tem como objetivo fornecer subsídios para análise e modelagem do processo da etapa de testes, objeto de estudo neste projeto. Os seguintes assuntos foram abordados na fundamentação teórica: Engenharia de Software, qualidade, testes de software, técnicas de teste de software e o modelos de referência CMMI.

61 61 Modelagem do processo atual da área de testes: A modelagem dos processos é importante para a organização das atividades dentro de uma empresa ou área. Nessa etapa, foram coletadas informações sobre a fase de testes de software e, com base nesses dados, os processos atuais foram modelados. Análise da adequação dos processos com a área de Verificação do modelo de referência CMMI: Nessa etapa, foi avaliada a conformidade dos processos atuais da área de testes com a área de processo Verificação do modelo de referência CMMI. Descrição de possíveis melhorias: Nesta etapa o processo atual foi analisado e possíveis melhorias foram propostas. Modelagem do novo processo: O foco desta etapa é a modelagem do novo processo. As etapas anteriores fornecem informações para execução das atividades desta etapa. Implantação de algumas melhorias e análise dos resultados: O objetivo desta etapa foi selecionar e implantar algumas melhorias. Além disso, os resultados obtidos foram analisados. Validação: Por fim, nesta etapa o processo e as melhorias foram validados com algumas pessoas da empresa estudo de caso.

62 DELIMITAÇÕES O objetivo deste projeto foi modelar e propor melhorias nos processos da etapa de testes de uma empresa de desenvolvimento de software. Não foram modelados os processos de outras etapas do desenvolvimento de software. Os processos já existentes foram customizados com base em técnicas e modelos já existentes, ou seja, novas técnicas e modelos não foram apresentados no presente projeto. Além disso, na análise de aderência dos processos da empresa com relação ao modelo CMMI foram avaliadas somente as metas específicas da área de Verificação. Portanto, não foram avaliadas as metas genéricas e as outras áreas de processo.

63 63 4 MODELAGEM DO PROCESSO DE TESTE DE SOFTWARE Este capítulo contém uma breve descrição da empresa estudo de caso, a modelagem do processo atual da área de testes e a análise do processo com relação à área de processo Verificação do modelo CMMI. Além disso, são apresentadas descrições de melhorias, uma proposta de novo processo, os resultados obtidos com a implantação de algumas melhorias e, por fim a validação. 4.1 DESCRIÇÃO DA EMPRESA ESTUDO DE CASO A empresa estudo de caso atua na região da Grande Florianópolis há mais de três décadas. Atuando no setor de telecomunicações, a empresa possui clientes em vários países da América Latina. No estudo de caso é considerada uma área específica da empresa. A área em questão possui diversas equipes de desenvolvimento e uma equipe de testes. No que diz respeito às fases de teste, a equipe de testes realiza testes de integração e de sistema. Já com relação às técnicas, são executados somente testes funcionais, principalmente testes de requisitos e de regressão. Existe também, uma equipe responsável pela preparação, instalação e configuração do sistema para teste. As equipes trabalham na criação de um sistema, e o mesmo possui diversos módulos. O gerente de projeto planeja e acompanha as atividades de todas as equipes. A empresa estudo de caso utiliza como base a metodologia ágil Scrum para organizar as atividades de desenvolvimento de software. A empresa não adota todos os princípios do Scrum. Isso porque ela optou pelos que melhor atende as necessidades e se adéquam a realidade da empresa.

64 PROCESSO ATUAL DA ÁREA DE TESTES DA EMPRESA ESTUDO DE CASO A área de testes de software da empresa, estudo de caso, atualmente, não possui nenhum processo modelado e documentado. A escassa documentação gera situações em que as pessoas ficam em dúvida e executam as atividades da forma que acreditam ser a correta. Isso torna a tarefa de supervisão das atividades complexa, pois, para acompanhar e definir se uma atividade está sendo executada da forma correta, é necessário ter o processo padronizado, documentado e validado. Para reduzir os problemas e aplicar melhorias, primeiramente, é necessário modelar e documentar o processo atual. A seguir, é apresentada a modelagem do processo da área de testes de software Macro processo da atividade de testes de software Nos últimos meses do ano é feito o planejamento para o próximo ano, em que são definidas as funcionalidades que serão desenvolvidas 2, as datas de início e término do desenvolvimento e testes de cada release 3, bem como a data de entrega para o cliente. De modo geral, durante aproximadamente dois meses, o setor de desenvolvimento trabalha no aprimoramento dos módulos existentes ou até mesmo no desenvolvimento de novos módulos. A atividade de desenvolvimento inclui não só a codificação, mas também a realização de testes cruzados 4, ou seja, um programador faz testes nas alterações ou novas funcionalidades desenvolvidas por outro programador. Mas não existem critérios e documentações definidas para realização dessa atividade. 2 3 As informações das novas funcionalidades são descritas em um documento. Este é chamado Lista de Novas Funcionalidades. Esta lista é utilizada pela equipe de desenvolvimento e pela equipe de testes. A nomenclatura Release é utilizada pela empresa para definir um conjunto de novas funcionalidades do sistema, por exemplo, a release X possui as novas funcionalidades A, B e C. As funcionalidades podem ser desde um novo módulo até a criação de um novo relatório já existente. 4 A empresa utiliza a nomenclatura Testes cruzados para identificar a atividade de revisão por pares dentro da equipe de desenvolvimento.

65 65 Após o término da atividade de desenvolvimento, o Scrum Master da equipe de teste faz uma solicitação de geração de versão para a equipe de infraestrutura. O Scrum Master envia um para todos os envolvidos no projeto informando a liberação da nova versão. Durante cerca de dois meses, são executados testes nas novas funcionalidades e de regressão nas funcionalidades existentes. O planejamento das atividades de testes inicia com a leitura da documentação que descreve as novas funcionalidades. As atividades são listadas e divididas entre as pessoas da equipe, e isso é documentado em uma planilha. A primeira atividade é a criação ou atualização da documentação utilizada para realização dos testes. A equipe utiliza uma planilha para descrever os casos de testes, denominada planilha modelo. Essa planilha é usada na criação da planilha gerada a cada nova versão, ou seja, cada versão do sistema possui uma planilha com a descrição dos resultados de cada caso de teste. Após a revisão da documentação, instalação e configuração da versão, os testes são iniciados. Os problemas identificados são cadastrados em uma ferramenta chamada Bugzilla 5. Quando um bug é cadastrado, a ferramenta encaminha automaticamente um para a equipe de desenvolvimento responsável pelo módulo. O Scrum Master da equipe de testes acompanha a correção dos bugs e faz o planejamento da geração da nova versão para incluir a correção dos bugs encontrados que já foram resolvidos. Na maioria dos casos, é agrupada a correção dos bugs para gerar uma nova versão, mas em algumas situações, principalmente quando o bug é muito grave, é necessário gerar uma versão com a correção de apenas um bug. A solicitação de geração de uma nova versão é feita pelo Scrum Master da equipe de testes para a equipe de infraestrutura por meio de um . Todos os envolvidos com o projeto são avisados em qual data e hora será gerada a próxima versão. Além disso, é criada uma nova versão na ferramenta Bugzilla, ou seja, é feito o cadastro do número da nova versão do sistema na ferramenta. Essa informação será utilizada para associar o defeito encontrado e cadastrado no Bugzilla com a versão do sistema. Por fim, uma planilha é criada para ser usada durante a execução dos testes da versão. Os testes são repetidos até que não existam mais erros críticos. O relatório dos testes é criado quando as atividades são finalizadas. 5 Bugzilla é uma ferramenta desenvolvida pelo projeto Mozzila e serve para gerenciar o cadastro e correção dos bugs. Os bugs são associados a um módulo de um sistema e a uma versão (

66 66 A figura 4 apresenta o macro processo da atividade de teste de software, bem como o relacionamento entre as equipes envolvidas no processo. Após apresentação da figura 4, cada etapa do processo de teste, conforme teoria apresentada no capítulo 2, seção 2.3.1, é descrita em detalhe, ou seja, é detalhado como a equipe realiza as etapas de procedimentos iniciais, planejamento, preparação, especificação, execução e entrega. Figura 4 - Macro processo da atividade de testes de software. Fonte: Elaboração do autor, 2011.

67 Procedimentos iniciais O processo dessa etapa não foi modelado, porque não existem procedimentos formais e, a cada novo projeto, as atividades descritas nos procedimentos iniciais podem ser executadas de maneira diferente. Os requisitos são lidos durante o planejamento, porém não é feita uma análise detalhada dos mesmos. Assim, os testes, algumas vezes, podem ser iniciados mesmo que os requisitos não estejam completos ou bem claros Planejamento Durante toda a atividade de testes, o planejamento e acompanhamento estão presentes. O acompanhamento das atividades é realizado e registrado em uma planilha. No início dos testes de uma nova release, é criada uma planilha com a descrição das atividades que serão executadas. Toda semana, o Scrum Master da equipe de testes divide as atividades entre as pessoas da equipe. Além disso, todos da equipe validam se o tempo necessário para concluir as atividades está correto. Isso é feito na reunião de planejamento, na qual a equipe discute os objetivos da semana e as estimativas. Após a reunião de planejamento, a execução dos testes é iniciada. O testador executa cada um dos testes e relata os problemas identificados. O processo de execução dos testes é apresentado na seção O Scrum Master analisa cada bug identificado pelos testadores e prioriza, ou seja, define a ordem de correção. Existem cinco classificações de prioridade, de 1 a 5: bugs com prioridade 1 precisam ser resolvidos antes da entrega da release para o cliente. Além disso, reuniões diárias são realizadas para acompanhar o andamento das atividades. Essas reuniões duram aproximadamente quinze minutos. Cada membro da equipe relata o que fez no dia anterior, o que tem planejado para o próximo dia e se está com dificuldades ou impedimentos para realização das atividades.

68 68 A planilha de acompanhamento é atualizada após cada reunião, ou seja, o status da atividade é alterado com base nas informações passadas pelos testadores. O Scrum Master é responsável por tentar resolver os impedimentos levantados na reunião diária. Outra atividade do Scrum Master da equipe de testes é acompanhar o andamento dos testes e correção dos bugs. Quando o teste é concluído, o relatório de testes é descrito. A figura 5 apresenta, em detalhes, o processo atual de planejamento. Figura 5 - Processo de planejamento e acompanhamento da execução dos testes. Fonte: Elaboração do autor, 2011.

69 Preparação A preparação para realização dos testes é realizada à medida que a necessidade surge. No início do teste de uma release, é feita a solicitação de instalação da versão para a equipe de infraestrutura. Durante a execução dos mesmos, caso exista a necessidade de um ambiente para testes, é feita a solicitação para a equipe de infraestrutura. Mas esse processo não é formalizado nem padronizado, ou seja, cada solicitação pode ser feita de uma forma diferente. O processo dessa etapa não foi modelado, porque atualmente não existem padrões e atividades definidas Especificação Para executar um teste com qualidade, é necessário ter casos de testes que descrevam os passos e resultados esperados de cada teste. Além disso, é importante que os casos de testes sempre sejam atualizados. Atualmente, a equipe utiliza uma planilha para documentar os casos de teste. Essa planilha é composta por cinco colunas e n linhas. A primeira coluna contém a informação da profundidade do teste. A equipe utiliza a nomenclatura Tipo de teste para definir o nível de profundidade dos testes, o tipo pode ser Geral ou Específico. O tipo de teste geral compreende os testes que visam garantir o funcionamento básico do sistema. Já o teste específico é o teste completo, ou seja, compreende todos os testes descritos. A segunda coluna contém a descrição do teste. Já a terceira coluna possui a descrição do resultado esperado de cada teste. A quarta coluna contém o resultado do teste. Essa coluna pode ter os seguintes valores: Não executado, Passou, Falhou e Bloqueado. Os casos de teste que ainda não foram executados recebem o status Não executado. Após a execução do teste caso o resultado seja positivo, ou seja, o resultado obtido seja igual ao resultado esperado, o caso de teste recebe o status Passou, caso contrário recebe o valor Falhou. Por fim, caso não seja possível executar o caso de teste, o mesmo deve receber o valor Bloqueado.

70 70 O primeiro passo, para escrever o caso de teste, é a leitura dos cartões de história 6. Caso seja um novo módulo, é necessário criar uma nova aba na planilha modelo. Por outro lado, quando o módulo já existe, o testador faz a leitura dos casos de teste existentes. Caso seja necessário, o testador atualiza os casos de teste existentes. Os casos de teste das novas funcionalidades são criados. Por fim, é realizada a classificação, ou seja, cada caso de teste é analisado e a coluna Tipo de Teste é preenchida com o valor Geral ou Específico. Um exemplo dessa planilha encontra-se no anexo A. O processo, a seguir, apresenta a atividade de descrição e atualização dos casos de teste. 6 O cartão de história contém a descrição da funcionalidade. Eles são descritos pelos gerentes de produto e são utilizados pelos desenvolvedores durante o desenvolvimento do sistema. Os testadores também utilizam os cartões de história durante a análise para descrição dos casos de teste.

71 Figura 6 - Processo de descrição e atualização dos casos de teste. Fonte: Elaboração do autor,

72 Execução Após a reunião de planejamento, todos os testadores iniciam os testes. O primeiro passo para execução da atividade é acessar a planilha de testes. A cada versão gerada do sistema é criada uma planilha. Essa fica em um servidor no modo compartilhado, ou seja, todos os testadores utilizam a mesma planilha para documentar o status dos testes. Cada caso de teste é executado e a coluna status é preenchida. Caso o teste falhe, o testador deve verificar na lista de bugs abertos na ferramenta Bugzilla se o problema já foi reportado. Caso o problema não tenha sido reportado, o testador deve cadastrar o bug. Por fim, o ambiente de teste utilizado deve ser preenchido na planilha utilizada durante a execução dos testes. A figura 7 apresenta o diagrama que demonstra o processo de execução dos testes de novas funcionalidades e os testes de regressão.

73 Figura 7 - Processo execução dos testes. Fonte: Elaboração do autor,

74 Entrega Um relatório é criado após o término das atividades de teste. Esse relatório contém a descrição das novas funcionalidades, ambiente de testes, número da versão estável do sistema, pontos positivos e problemas identificados durante os testes da versão. Além disso, cada problema é analisado, melhorias e possíveis soluções são descritas. A análise é feita pelo Scrum Master juntamente com a sua equipe. Por fim, o relatório é encaminhado para os envolvidos no projeto. A figura 8 apresenta o diagrama da etapa de entrega. Figura 8 - Processo de criação do relatório do término dos testes. Fonte: Elaboração do autor, 2011.

75 AVALIAÇÃO DOS PROCESSOS ATUAIS SEGUNDO A ÁREA DE PROCESSO VERIFICAÇÃO DO CMMI No modelo de referência CMMI, os testes de sistema estão descritos na área de processo Verificação do nível três de maturidade, segundo a representação por estágios. A área de verificação possui três metas específicas: preparar-se para verificação; realizar revisão por pares; verificar produtos de trabalho selecionados. A seguir, é apresentada cada meta específica, seguida de uma análise da aderência do processo atual com a meta do modelo de referência utilizado Meta específica Preparar-se para verificação O objetivo dessa meta específica é realizar a preparação para a verificação. A meta Preparar-se para verificação possui três práticas específicas: SP 1.1 Selecionar produtos de trabalho para verificação, SP 1.2 Estabelecer ambiente para verificação e SP 1.3 Estabelecer procedimentos e critérios de verificação. A prática SP 1.1 consiste na seleção dos produtos que serão verificados e na escolha da abordagem de verificação. Já a prática SP 1.2 tem como foco a definição do ambiente que será usado na verificação. Por fim, a prática SP 1.3 define os tipos de teste que serão executados, os parâmetros de teste, os critérios de verificação, dentre outros. (SOFTWARE ENGINEERING INSTITUTE, 2006).

76 Análise de aderência do processo atual Os processos atuais atendem parcialmente a prática SP 1.1. No início de um projeto de testes, são selecionados e analisados os módulos que possuem novas funcionalidades. Porém não são definidos todos os métodos de verificação que serão empregados antes do início dos testes, ou seja, o teste é iniciado e, no decorrer do teste, são definidos os métodos necessários. Essa abordagem pode gerar alguns problemas, por exemplo, falta de informações para estimar e controlar o tempo das atividades. Além disso, depender da análise subjetiva das pessoas pode causar grandes diferenças na execução e resultado de uma mesma atividade. A prática SP 1.2 não é atendida completamente. Não existe uma análise e planejamento do ambiente de testes antes da execução dos testes. A solicitação de criação e configuração do ambiente de testes, em alguns casos, é feita sob demanda, ou seja, caso exista algum problema ou necessidade, é feita a solicitação. Caso a equipe de infraestrutura não possa atender a solicitação, será necessário esperar ou começar a execução de outra atividade. Isso pode acarretar alguns problemas, por exemplo, quando o testador voltar a executar a atividade, será necessário um tempo até o retorno ao ponto em que parou. Caso sejam necessários novos equipamentos, os mesmos deverão ser solicitados com uma antecedência para que o pedido seja atendido. Os processos atuais atendem parcialmente a prática SP 1.3. Alguns procedimentos de verificação não possuem descrição completa e clara dos resultados esperados. Outro ponto de falha com relação ao atendimento dessa meta é a definição do tipo de teste que será executado. Atualmente, isso é feito durante o andamento dos testes Meta específica Realizar revisão por pares O objetivo da meta específica revisão por pares é constituir [...] um exame metódico dos produtos de trabalho pelos pares dos responsáveis pela construção do produto para identificar defeitos a serem removidos e recomendar outras modificações. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 506).

77 77 Essa meta possui três práticas específicas: SP 2.1 Preparar-se para revisão por pares, SP 2.2 Conduzir revisão por pares e SP 2.3 Analisar dados de revisão por pares. A SP 2.1 tem como objetivo preparar o ambiente para a verificação. Primeiramente, a equipe de revisão é definida. A documentação que será utilizada na revisão é preparada e atualizada. Dentre os produtos de trabalho típicos dessa prática, pode-se citar o cronograma das revisões por pares, a lista de verificações, o material para treinamento e os produtos de trabalho selecionados. Além disso, o tipo de revisão que será utilizada deve ser selecionado, podem ser inspeções, revisões ativas, dentre outras. (SOFTWARE ENGINEERING INSTITUTE, 2006). Já a SP 2.2 tem como foco conduzir a revisão por pares nos produtos de trabalho selecionados e identificar as questões críticas resultantes. O principal objetivo dessa prática é identificar os problemas antecipadamente. Primeiramente, os papéis atribuídos são executados, os defeitos são identificados e documentados. Os itens de ação são identificados e comunicados. Por fim, os critérios de saída devem ser avaliados para que seja assegurado que os mesmos são satisfeitos. (SOFTWARE ENGINEERING INSTITUTE, 2006). Finalmente, a SP 2.3 consiste em analisar dados sobre preparação, condução e resultados de revisão por pares. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 509) Análise de aderência do processo atual Atualmente, existe uma forma de revisão por pares, os testes cruzados. Estes testes são realizados pelos desenvolvedores antes da release ser liberada para a equipe de testes. Porém, por mais que exista alguma atividade relacionada a revisão por pares, essa é feita de forma informal. Não existem processos, documentação e padrões para execução dessa atividade. Dentro da equipe de teste, não existem revisões por pares, nem na documentação criada, nem nos testes executados. Portanto, por mais que exista alguma forma de revisão por pares, as práticas SP 2.1, SP 2.2 e SP 2.3 não são atendidas.

78 Meta específica Verificar produtos de trabalho selecionados A meta específica verificar produtos de trabalho selecionados tem como foco a verificação dos produtos de trabalho em relação aos requisitos especificados. Recomenda-se que as atividades de verificação sejam realizadas ao longo do ciclo de vida do produto. (SOFTWARE ENGINEERING INSTITUTE, 2006, p. 510). Essa meta possui duas práticas específicas: SP 3.1 Realizar verificação e SP 3.2 Analisar resultados da verificação. A SP 3.1 consiste em realizar a verificação nos produtos de trabalho selecionados. Essa prática propõe que a verificação seja realizada de forma incremental. Isso porque, quanto mais cedo os problemas forem identificados, menores serão os custos de correção e o retrabalho. Os resultados da verificação devem ser identificados e descritos. (SOFTWARE ENGINEERING INSTITUTE, 2006). Já a prática SP 3.2 consiste na análise dos resultados das atividades de verificação. Os resultados da verificação devem ser comparados com os critérios de verificação estabelecidos para determinar a aceitabilidade. Os resultados das análises são registrados como evidência de que a verificação ocorreu. (SOFTWARE ENGINEERING INSTITUTE, 2006, p 511) Análise de aderência do processo atual A prática SP 3.1 é cumprida parcialmente. São realizadas verificações nos produtos de trabalho, porém elas não são realizadas de forma incremental. A verificação é realizada após o término do desenvolvimento. Muitos problemas são identificados e resolvidos antes do sistema entrar em produção, porém o custo da correção é mais alto do que se eles fossem identificados na fase de análise e descrição dos requisitos. A verificação é realizada com base nos requisitos definidos. Os resultados da verificação são registrados e arquivados em planilhas. Além disso, os defeitos são relatados no Bugzilla. Essa ferramenta possibilita o acompanhamento da correção dos problemas, bem como a criação de relatórios.

79 79 As atividades descritas na prática 3.2 são executadas informalmente. Durante a execução da verificação, os resultados são analisados com objetivo de definir quais verificações deverão ser executadas novamente ou aprofundadas. Além disso, o critério de aceitação é definido com base no prazo e na quantidade de problemas identificados que não foram resolvidos. Por ser um processo informal, não existem documentos que deixam claro os critérios de aceitação. Com isto, as atividades tornam-se mais complexas de serem realizadas. 4.4 PROPOSTAS DE MELHORIAS A seguir, são expostas as propostas de melhorias para as etapas de teste da empresa estudo de caso. As mesmas foram descritas para resolver os problemas identificados e atender às metas específicas da área de processo Verificação do modelo CMMI. Após a descrição, é apresentado, em cada etapa, um quadro com as seguintes informações: n : número sequencial para identificação; descrição: contém a explicação de cada item; autonomia: define a autonomia para implantação. Por exemplo, a equipe pode ter autonomia ou pode depender do envolvimento do gerente de projetos, da área ou até mesmo do gerente de produto. Todas as melhorias descritas precisam do apoio e aceitação dos gerentes da área e de projeto, isso porque o é necessário alocar tempo e recurso para implantação. O principal objetivo dessa informação é definir quais as pessoas são necessárias durante a implantação da melhoria. Na análise, são utilizados os seguintes valores: o equipe: quando a equipe de teste tiver autonomia; o gerente de projetos: quando envolver equipes diferentes ou até mesmo recursos, então o gerente de projetos deve intervir; o gerente da área: quando áreas diferentes da empresa forem envolvidas ou questões relacionadas ao produto; o gerente de produto: no caso da melhoria estar relacionada ao produto ou à documentação do desenvolvimento do produto.

80 80 benefícios: com objetivo de auxiliar a classificação do impacto do processo implantado, os benefícios de cada melhoria foram listados; impacto (I): definir o impacto é importante para analisar os benefícios que a melhoria irá proporcionar para o processo de testes da empresa. Além disso, o impacto é usado como fonte de informação para definição da prioridade. O impacto pode ser alto, médio ou baixo. Os impactos, juntamente com os seus critérios, são listados a seguir: o Impacto alto: tem como objetivo o aprimoramento no planejamento e acompanhamento do projeto: isso porque o planejamento é fundamental para a execução das atividades de forma organizada e acompanhada. Além disso, com planejamento é possível adotar medidas corretivas no momento adequado para conseguir atingir o objetivo de cumprir o prazo; focam na redução do tempo de execução dos testes: por não possuir testes automatizados 7, todos os testes são executados manualmente. Qualquer redução no tempo de teste é significativa, pois são executados diversos ciclos de testes em um mesmo projeto. Assim, se a redução for de 10 horas em cada ciclo e forem executados 5 ciclos, no final do projeto a redução será de 50 horas; visa diminuir a quantidade de bugs críticos no software: quanto mais estável estiver o software quando for entregue para testes, menor o número de ciclos que serão executados, com isso menor será o tempo necessário para concluir as atividades. Além da redução do tempo da equipe de testes, haverá uma redução do retrabalho da equipe de desenvolvimento; analisa e busca reduzir os erros identificados pelo cliente: problemas encontrados pelos clientes tem um custo alto de correção. Além disso, prejudicam a imagem da empresa. o Impacto médio: proporciona uma redução no tempo das atividades não relacionadas a execução dos testes, por exemplo: solicitação de configuração de 7 Existe um projeto em andamento com relação à criação de testes automatizados. Mas até a data de conclusão desse trabalho, os testes automatizados ainda não foram utilizados.

81 81 ambiente de testes e criação de relatórios. Estas atividades são executadas com uma frequência menor, por isso o impacto será menor; caso estiver relacionada à documentação de testes: a documentação de testes é importante durante a execução dos testes, já que ela orienta os testadores dos passos e resultados esperados de cada teste. Além disso, é importante ter um registro de quais testes foram executados em cada versão do sistema; se for relacionada ao ambiente de testes: não ter um ambiente de testes o mais próximo do utilizado pelo cliente pode gerar alguns problemas, como por exemplo, problemas que ocorrem somente no cenário do cliente. atividades relacionadas a análise dos problemas e definição de planos de correção: A análise dos problemas e definição de correções será realizada após a implantação de melhorias com impacto alto. Isso porque após as alterações os problemas conhecidos podem ser resolvidos. o Impacto baixo: padronização de documentos e criação de templates: antes de padronizar os documentos e criar templates e necessário corrigir os problemas identificados na execução das atividades. Por isso, por mais que melhorias no padrão e criação do template possam auxiliar a redução do tempo de execução das atividades, a padronização tem o impacto baixo. dependência (D): essa coluna informa se existe alguma dependência, entre melhorias, para implantação, ou seja, se é necessário implantar uma melhoria para que outra possa ser implantada. Caso exista, um número da melhoria é adicionado nessa coluna; Prioridade (P): definir a prioridade é fundamental para especificar a ordem de implantação. Os valores utilizados nesse campo são: Alta, Média e Baixa. o alta: melhorias que tem impacto alto e possuem outras melhorias que dependem da sua implantação, serão aplicadas em primeiro lugar; o média: melhorias com o impacto alto e melhorias com impacto médio que possuem melhorias que dependem da sua implantação; o baixa: melhorias com impacto médio que não possuem dependentes e todas as melhorias que possuem impacto baixo.

82 82 A seguir é apresentado o modelo de quadro utilizado para descrever as melhorias. N Descrição Autonomia Benefícios I D P Quadro 1 - Tabela de descrição das melhorias Fonte: Elaboração do autor, Procedimentos iniciais Uma melhoria na etapa de procedimentos iniciais é definir os métodos que serão utilizados em cada um dos produtos de verificação antes do início dos testes. Para isso, é necessário incluir a atividade de análise dos produtos. Essa análise tem como objetivo ler a descrição das novas funcionalidades de cada produto de verificação e definir quais métodos de testes serão utilizados. Essa análise irá fornecer subsídios para estimar o tempo de cada atividade no projeto. Além disso, a leitura antecipada da documentação também pode prevenir que os problemas se propagem para as próximas fases. Com isso, ao iniciar a execução dos testes, os requisitos devem estar mais claros. Outra melhoria que pode ser implantada nessa etapa é a integração da equipe de teste e de desenvolvimento no momento da execução dos testes cruzados. Como descrito anteriormente, a equipe de desenvolvimento realiza testes antes da liberação do software para a equipe de testes. Esses são realizados sem a utilização de uma documentação e isso dificulta a realização da atividade. Além disso, não são realizados testes de regressão, ou seja, o foco dos testes são as alterações. Por isso, quando o software é entregue para testes, as funcionalidades novas podem estar funcionando, mas o que já funcionava pode apresentar problemas. Com a integração das equipes nos testes cruzados, a qualidade do software poderá ser melhorada. Após ler a documentação, isto é, as histórias descritas pelos gerentes de produto, um analista de testes irá descrever os casos de teste necessários para testar as novas funcionalidades. Esses casos de teste serão usados primeiramente pelos desenvolvedores e depois pela equipe de testes. Além disso, o analista de testes irá selecionar quais casos de teste devem ser executados para garantir a regressão. Assim, o tempo utilizado nos testes

83 83 cruzados será otimizado. Isso porque o analista de teste irá descrever os testes de forma a cobrir o maior número de funcionalidades e os desenvolvedores irão executar os testes com base em uma documentação. Um ponto importante é que os testes realizados pelos desenvolvedores não irão substituir os testes realizados pela da equipe de testes. O objetivo da realização dos testes cruzados é eliminar os erros críticos ou muito básicos, antes da entrega do software para a equipe de testes. Para implantar a melhoria descrita anteriormente, é necessário realizar uma mudança nas funções dentro da equipe de testes. Atualmente, não existe o papel do analista de teste. Assim, serão separadas as atividades dos testadores dos analistas de teste. Os testadores serão responsáveis por executar os testes, já os analistas de testes terão como principal atividade a análise dos requisitos descritos nas histórias e a descrição dos casos de teste. Com a divisão das atividades, será possível alocar o recurso humano em atividades que apresentam maior habilidade. iniciais. O quadro 2 apresenta as melhorias propostas para a etapa de procedimentos N Descrição Autonomia Benefícios I D P 1 Ler as histórias antecipadamente. 2 Definir os tipos de teste que serão usados para verificação. 3 Integrar a equipe de testes e de desenvolvimento na execução dos testes cruzados. Gerente do projeto Equipe Gerente do projeto Quadro 2 - Melhorias na etapa procedimentos iniciais. Fonte: Elaboração do autor, Reduzir o número de bugs críticos. Melhorar o planejamento e acompanhamento. Reduzir o número de bugs críticos. Alto - Alta Alto 1 Média Alto 1 Média Planejamento O planejamento atual da equipe de testes da empresa é feito de forma informal. Os objetivos são definidos, porém as estimativas, algumas vezes, não são precisas. O planejamento é feito semanalmente e, por isso, não fica claro o esforço necessário para concluir o teste de uma release. A primeira melhoria para essa etapa é tratar cada release

84 84 como um projeto, assim, deve ser feito um planejamento do projeto, facilitando o acompanhamento das atividades. Com isso, será possível adotar medidas corretivas quando algum problema afetar o andamento ou for gerar atrasos. Além disso, a motivação das pessoas envolvidas no projeto é ampliada quando elas sabem quanto e o que falta para concluir o projeto. Um ponto importante para o planejamento do projeto é mapear os riscos e definir planos de mitigação e contingência. Atualmente, os riscos não são avaliados. Quando ocorrem, ações devem ser tomadas para tentar minimizar os problemas gerados. Porém, as ações realizadas para resolvê-los, não são documentadas. Com isso, caso o problema volte a ocorrer, não existe um histórico para ser usado como base para correção. Por isso, outra melhoria para a etapa de planejamento é definir os riscos e os planos necessários para evitálos ou tratá-los, caso ocorram. Além disso, as ações corretivas devem ser documentadas. As estimativas são fundamentais para o sucesso de um projeto. Por isso, as técnicas e critérios para realizar estimativas devem ser claras, documentadas e revisadas com uma frequência definida, por exemplo, após o término de cada projeto. O quadro 3 apresenta as melhorias propostas para a etapa de planejamento. N Descrição Autonomia Benefícios I D P 4 Fazer o planejamento de toda a release. 5 Mapear os riscos do projeto e definir planos de mitigação e contingência. 6 Criar mecanismos de coleta e análise de informações sobre a resolução de problemas. 7 Criar um documento com os critérios utilizados durante as estimativas. Deve existir um processo para atualização desse documento. Equipe Equipe Equipe Equipe Quadro 3 - Melhorias na etapa de planejamento. Fonte: Elaboração do autor, Melhorar o planejamento e acompanhamento. Melhorar o planejamento e acompanhamento. Analisar os problemas e definir planos de correção. Melhorar o planejamento e acompanhamento. Alto - Alta Alto 4 Média Médio - Baixa Alto - Média

85 Preparação Ter um ambiente de testes controlado, organizado e próximo da realidade do cliente influencia diretamente na qualidade da atividade de testes. Por isso, é necessário melhorar a organização e documentação desse ambiente. Antecipar as solicitações pode auxiliar na redução do tempo necessário para execução das atividades de verificação. Primeiramente, é necessário mapear o ambiente de testes atual. Conhecer o ambiente é imprescindível para que sejam feitas solicitações de novos equipamentos quando houver a necessidade. Além disso, o ambiente tem que ser isolado, ou seja, não devem existir interferências durante os testes. Nessa etapa, podem ser aplicadas melhorias com relação à organização do ambiente de testes. Os ambientes necessários para realização dos testes têm que ser identificados durante o planejamento. Além disso, é preciso criar formas de solicitações formais e, definir o cronograma e os responsáveis pela execução das atividades. Para padronizar a forma de solicitação é importante criar templates dos documentos que serão utilizados. O quadro 4 apresenta as melhorias propostas para a etapa de preparação. N Descrição Autonomia Benefícios I D P 8 Mapear o ambiente utilizado para realização dos testes. Equipe Melhorar o ambiente de testes. Médio - Média 9 Criar um template para solicitação de configuração do ambiente de testes. 10 Criar um mecanismo de registro do ambiente utilizado em um projeto. Equipe Equipe Quadro 4 - Melhorias na etapa preparação. Fonte: Elaboração do autor, Padronizar a documentação ou criar templates. Padronizar documentação ou criar templates. Baixo 8 Baixa Baixo 8 Baixa

86 Especificação Uma melhoria na etapa de especificação é a inclusão da revisão por pares na descrição dos casos de teste. Isso é importante para que o padrão seja mantido. A ideia é incluir mais um passo no processo de documentação, uma pessoa escreve e outra revisa. Para que a revisão seja eficiente, é necessário criar um documento com os critérios que devem ser levados em consideração durante a revisão. O resultado da revisão precisa ser documentado e arquivado. Mas esse não é o único benefício. Os dados da revisão por pares podem ser usados para identificar os principais problemas relacionados à especificação. Após a identificação, é possível definir medidas para melhorar o processo, por exemplo, realizar treinamentos ou reuniões para discussão e análise da atividade. Além disso, essa atividade ajuda a distribuir o conhecimento entre os membros da equipe. Após a descrição e revisão por pares dos casos de teste, a documentação deve ser apresentada para a equipe. Isso porque quando os testadores forem executar os testes, eles já terão conhecimento da descrição e ordem dos testes. Além disso, durante a revisão podem ser sugeridas melhorias nos casos de teste criados. Outro benefício dessa apresentação é que todas as pessoas da equipe terão conhecimento das novas funcionalidades. Outro ponto que precisa ser melhorado é a padronização da descrição dos casos de testes. A ideia é criar um documento com a descrição do objetivo dos casos de teste, ter orientações com relação à classificação do tipo de teste, ou seja, se o teste é Geral ou Específico, e outras informações que podem ser úteis durante a descrição do teste, como uma descrição sobre como organizar a sequência de testes na planilha. Outra melhoria no processo de especificação é a análise dos problemas relatados pelos clientes para melhorar a documentação de testes. Cada item deve ser analisado, e a causa deve ser identificada. Caso o problema esteja na documentação, a mesma deve ser melhorada. O quadro 5 apresenta as melhorias propostas para a etapa de especificação.

87 87 N Descrição Autonomia Benefícios I D P 11 Incluir a revisão por pares na atividade de documentação. 12 Realizar reuniões para análise dos problemas identificados durante a revisão por pares. 13 Realizar uma reunião para apresentação e discussão dos novos casos de teste. 14 Analisar os problemas relatados pelos clientes para identificar e corrigir falhas na documentação. Equipe Equipe Equipe Equipe Quadro 5 - Melhorias na etapa especificação. Fonte: Elaboração do autor, Melhorar a documentação de testes. Melhorar a documentação de testes. Melhorar a documentação de testes. Analisar e buscar reduzir os erros identificados pelo cliente. Médio - Média Médio 11 Baixa Médio - Baixa Alto - Média Execução Um problema enfrentado pela equipe de testes é a baixa qualidade do produto entregue para testes. Uma melhoria que pode ser implantada é o conceito de aceitação para o início dos testes. A ideia é definir um conjunto de testes básicos que devem ser executados pelo desenvolvimento antes da liberação do sistema para a equipe de testes. Os testes serão descritos pela equipe de testes e terá como objetivo apoiar a equipe de desenvolvimento para que a mesma execute testes que garantam o funcionamento básico do sistema. Por básico, pode-se entender como as principais funcionalidades do sistema. Por exemplo, em um cadastro os testes básicos, seriam: cadastrar, editar e excluir. A lista dos testes fornecida para o desenvolvimento também será utilizada pela equipe de testes. Essa lista será usada no primeiro teste após liberação da release para testes. Mas não adianta definir as medidas acima e não fazer nada quando os problemas ocorrem. Por esse motivo, é necessário documentar e analisar os resultados dos testes básicos. Caso eles sejam positivos, a equipe de desenvolvimento deve ser informada dos resultados. Caso sejam negativos, deve ser marcada uma reunião com os envolvidos para discutir os problemas e definir estratégias para melhorar a qualidade da atividade.

88 88 Outra questão relacionada à execução é a definição adequada do nível de profundidade do teste após cada alteração no módulo. Atualmente, existem dois níveis de profundidade dos testes: Geral e Específico. Porém, em alguns casos seria melhor ter mais níveis, pois existem testes que só precisariam ser executados quando forem feitas alterações que possam causar um grande impacto no sistema. Por isso, outra melhoria relacionada a execução dos testes é a divisão de mais níveis de profundidade dos testes. A ideia é ter quatro níveis: Básico, Geral, Específico e Completo. usada. O quadro 6 apresenta os objetivos de cada categoria e quando cada uma será Categoria Objetivos Quando será usado? * Verificar o funcionamento das * No primeiro teste após a geração de funcionalidades básicas de forma uma nova release. Será usado como rápida; Básico critério de aceitação. * Identificar problemas de geração de * No último teste antes da entrega para versão, configuração e no banco de o cliente. dados. Geral * Tem como objetivo verificar se o mínimo das funcionalidades está correto. * Em todos os módulos após a execução dos testes básicos e das alterações; * Nos módulos que tiveram alterações depois da execução dos testes especifico; * Nos módulos que não tiveram alterações. Específico Completo * Tem como objetivo verificar o comportamento do sistema em casos específicos. * Tem como objetivo executar e validar todas as funcionalidades do sistema. Quadro 6 - Classificação dos testes. Fonte: Elaboração do autor, * Nos módulos que tiveram alterações; * Quando o módulo começar a apresentar muitos problemas nos testes gerais. * Quando for feito uma alteração estrutural no módulo ou na aplicação. Com isso, a profundidade dos testes pode ser aplicada conforme a necessidade. Assim, o tempo da atividade de teste será empregado com mais eficiência, já que os testes serão aplicados com base na análise das alterações. O quadro 7 apresenta as melhorias propostas para a etapa de execução.

89 89 N Descrição Autonomia Benefícios I D P 15 Criar critérios de aceitação do sistema para início dos testes. 16 Aumentar as categorias utilizadas para definir o nível de profundidade dos testes. Quadro 7 - Melhorias na etapa execução. Fonte: Elaboração do autor, Gerente de Projeto Equipe Reduzir o tempo de teste. Reduzir o tempo de teste. Alto - Média Alto - Média Entrega Para liberar uma release, é necessário ter critérios definidos e documentados. Atualmente, não existem critérios claros, e isso pode prejudicar a qualidade do que será entregue para o cliente. Por isso, uma das melhorias da etapa de entrega é definir e documentar os critérios de liberação de uma release. Isso porque a liberação não deve depender de uma análise subjetiva. Ao término dos testes de uma release, os critérios devem ser revisados. Caso seja necessário, eles devem ser atualizados. Outro ponto importante nas entregas é documentar os pontos positivos e os problemas enfrentados durante o projeto de testes. Além disso, é importante fazer uma análise e propor melhorias para os problemas. Essas informações devem ser divulgadas e usadas para melhorar os processos e as atividades. Atualmente, algumas dessas atividades são executadas. Os dados são registrados e analisados, mas a forma de divulgação não é muito eficiente. O relatório é encaminhado para todos os envolvidos, porém não existe uma medida para melhorar os processos e as atividades. Uma ideia para resolver o problema é realizar uma reunião de entrega de release, na qual o objetivo é apresentar os resultados, os problemas enfrentados e as possíveis soluções. Além disso, os próximos passos para correção dos problemas e implantação de melhorias devem ser definidos. Após o término de uma release, pode ser feita uma reunião com a equipe para discutir os pontos positivos e negativos do projeto. Um ponto importante com relação à retrospectiva é documentar o que foi discutido. Essas informações serão usadas nos planejamento dos próximos projetos. O quadro 8 apresenta as melhorias propostas para a etapa de entrega.

90 90 N Descrição Autonomia Benefícios I D P 17 Definir e documentar os critérios de liberação de uma release. Gerente de Produto / Gerente de Projeto / Gerente da Área Reduzir o tempo de execução de atividades não relacionadas a testes. Médio - Baixa 18 Realizar reunião de entrega. 19 Realizar reuniões de retrospectiva com a equipe. 20 Criar mecanismos de coleta dos pontos positivos e negativos do planejamento de cada projeto de testes. Quadro 8 - Melhorias na etapa entrega. Fonte: Elaboração do autor, Gerente de projeto Equipe Equipe Analisar os problemas e definir planos de correção. Analisar os problemas e definir planos de correção. Melhorar o planejamento e acompanhamento. Médio - Baixa Médio - Baixa Alto 4 Média 4.5 PROPOSTA DO NOVO PROCESSO identificadas. A seguir, é apresentada a proposta dos novos processos com base nas melhorias Procedimentos iniciais O diagrama apresentado na figura 9 apresenta um novo processo para atender as melhorias descritas na seção O processo inicia com a análise das alterações e planejamento das atividades. Isso é feito pelo Scrum Master da equipe de testes e tem como saída uma Planilha de Planejamento. No planejamento as atividades são divididas entre os Analistas de Teste. A análise das novas funcionalidades inicia com a leitura das histórias pelo

91 91 Analista de Teste. Caso existam problemas na descrição das histórias o Analista de Testes deve criar um documento para escrever os itens identificados. O Scrum Master irá agrupar todos os problemas identificados pelos Analistas de Testes e, por enviar o documento para os Gerentes de Produto. Além disso, deve ser incluída no planejamento uma atividade de nova revisão das histórias após o parecer dos Gerentes de Produto com relação aos problemas descritos. Por outro lado, quando não são identificados problemas o Analista de Testes deve definir o tipo de teste e estimar o tempo necessário para execução dos testes. Por fim, o Scrum Master documenta as informações definidas pelo Analista de Testes na Planilha de Planejamento. Um ponto importante com relação a esse processo é que o papel de Analista de Testes não será executado por somente uma pessoa. O processo apresentado na figura 9 apresenta o planejamento da análise de todas as histórias, porém a análise é realizada nas histórias de uma única funcionalidade.

92 Figura 9 Novo processo de análise das histórias e definição do tipo de teste. Fonte: Elaboração do autor,