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
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
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 2011.
______________________________________________________ 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.
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.
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.
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.
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.
LISTA DE FIGURAS
Figura 1 - Valores das metodologias ágeis ... 27
Figura 2 – Ciclo do Scrum ... 29
Figura 3 – Etapas. ... 60
Figura 4 - Macro processo da atividade de testes de software. ... 66
Figura 5 - Processo de planejamento e acompanhamento da execução dos testes. ... 68
Figura 6 - Processo de descrição e atualização dos casos de teste. ... 71
Figura 7 - Processo execução dos testes. ... 73
Figura 8 - Processo de criação do relatório do término dos testes. ... 74
Figura 9 – Novo processo de análise das histórias e definição do tipo de teste. ... 92
Figura 10 – Novo processo de planejamento e acompanhamento da execução dos testes. ... 94
Figura 11 - Novo processo de preparação do ambiente de testes. ... 96
Figura 12 – Novo processo de revisão e apresentação dos casos de teste ... 97
Figura 13 – Novo processo de execução dos testes ... 99
Figura 14 – Novo processo de fechamento de projeto. ... 100
Quadro 1 - Tabela de descrição das melhorias ... 82
Quadro 2 - Melhorias na etapa procedimentos iniciais. ... 83
Quadro 3 - Melhorias na etapa de planejamento. ... 84
Quadro 4 - Melhorias na etapa preparação. ... 85
Quadro 5 - Melhorias na etapa especificação. ... 87
Quadro 6 - Classificação dos testes. ... 88
Quadro 7 - Melhorias na etapa execução... 89
Quadro 8 - Melhorias na etapa entrega. ... 90
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
VAL - Validation VER - Verification
1 INTRODUÇÃO ... 16 1.1 PROBLEMA ...18 1.2 OBJETIVOS ...18 1.2.1 Objetivo Geral ...18 1.2.2 Objetivos Específicos ...19 1.3 JUSTIFICATIVA ...19 1.4 ESTRUTURA DA MONOGRAFIA ...20 2 QUALIDADE DE SOFTWARE ... 21
2.1 ENGENHARIA DE SOFTWARE E QUALIDADE ...21
2.2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ...23
2.2.1 Fases genéricas do processo de software ...23
2.2.1.1 Definição ... 24 2.2.1.2 Desenvolvimento ... 24 2.2.1.3 Manutenção ... 25 2.2.2 Metodologias ágeis ...26 2.2.2.1 Scrum ... 28 2.3 TESTES DE SOFTWARE ...30
2.3.1 Processo de teste de software ...32
2.3.1.1 Procedimentos iniciais... 32 2.3.1.2 Planejamento ... 33 2.3.1.3 Preparação ... 33 2.3.1.4 Especificação ... 34 2.3.1.5 Execução ... 35 2.3.1.6 Entrega ... 35
2.3.2 Modelos de processo de teste de software ...36
2.3.3 Equipe de testes ...36
2.3.3.1 Cargos e funções ... 37
2.4 TÉCNICAS DE TESTE DE SOFTWARE ...37
2.4.1 Testes unitários ...38
2.4.2 Testes de integração ...38
2.4.5 Técnicas de testes ...40
2.4.5.1 Testes funcionais ou caixa-preta ... 40
2.4.5.1.1 Testes de requisitos ... 41
2.4.5.1.2 Testes de regressão ... 41
2.4.5.1.3 Teste tratamento de erros ... 41
2.4.5.1.4 Testes de interconexão ... 42
2.4.5.2 Teste estrutural ou caixa-branca ... 42
2.4.5.2.1 Testes de estresse ... 42 2.4.5.2.2 Teste de performance ... 43 2.4.5.2.3 Teste de recuperação ... 43 2.4.5.2.4 Teste de segurança ... 44 2.4.5.3 Testes não-funcionais ... 44 2.4.5.3.1 Testes de usabilidade ... 45 2.4.5.3.2 Testes de instalação ... 45
2.5 MODELOS DE MELHORIA DO PROCESSO DE SOFTWARE ...46
2.5.1 SW-CMM ...46
2.5.2 CMMI ...47
2.5.2.1 Termos e nomenclatura do modelo CMMI ... 48
2.5.2.1.1 Componentes ... 48
2.5.2.1.2 Áreas de processo ... 49
2.5.2.2 Níveis de maturidade e capacidade ... 50
2.5.2.2.1 Representação contínua ... 51
2.5.2.2.2 Representação por estágios ... 52
2.5.2.3 Metas genéricas ... 53
2.5.2.4 Metas e práticas das áreas de processo e níveis de maturidade ... 54
2.5.2.4.1 Metas e práticas do nível 2 de maturidade ... 54
2.5.2.4.2 Metas e práticas do nível 3 de maturidade ... 55
2.5.2.4.3 Metas e práticas do nível 4 de maturidade ... 57
2.5.2.4.4 Metas e práticas do nível 5 de maturidade ... 57
3 MÉTODO... 58
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ...58
3.2 ETAPAS PARA DESENVOLVIMENTO DO PROJETO ...59
3.3 DELIMITAÇÕES ...62
4.2 PROCESSO ATUAL DA ÁREA DE TESTES DA EMPRESA ESTUDO DE CASO ...64
4.2.1 Macro processo da atividade de testes de software ...64
4.2.2 Procedimentos iniciais ...67 4.2.3 Planejamento ...67 4.2.4 Preparação ...69 4.2.5 Especificação ...69 4.2.6 Execução ...72 4.2.7 Entrega ...74
4.3 AVALIAÇÃO DOS PROCESSOS ATUAIS SEGUNDO A ÁREA DE PROCESSO VERIFICAÇÃO DO CMMI ...75
4.3.1 Meta específica “Preparar-se para verificação” ...75
4.3.1.1 Análise de aderência do processo atual ... 76
4.3.2 Meta específica “Realizar revisão por pares” ...76
4.3.2.1 Análise de aderência do processo atual ... 77
4.3.3 Meta específica “Verificar produtos de trabalho selecionados” ...78
4.3.3.1 Análise de aderência do processo atual ... 78
4.4 PROPOSTAS DE MELHORIAS ...79 4.4.1 Procedimentos iniciais ...82 4.4.2 Planejamento ...83 4.4.3 Preparação ...85 4.4.4 Especificação ...86 4.4.5 Execução ...87 4.4.6 Entrega ...89
4.5 PROPOSTA DO NOVO PROCESSO...90
4.5.1 Procedimentos iniciais ...90 4.5.2 Planejamento ...93 4.5.3 Preparação ...95 4.5.4 Especificação ...96 4.5.5 Execução ...98 4.5.6 Entrega ...100
4.6 IMPLANTAÇÃO E VALIDAÇÃO DAS PROPOSTAS DE MELHORIAS ...102
4.6.1 Implantação ...102
5 CONCLUSÕES E TRABALHOS FUTUROS... 109
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
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.
1.1 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.
1.2.1 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.
1.2.2 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.
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.
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
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, pode-se entender „um caminho‟ a pode-ser percorrido em etapas em que pode-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.
2.2 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.”
2.2.1 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.
2.2.1.1 Definição
Segundo Pressman (1995), a fase de definição tem como objetivo tornar claro o que será desenvolvido.
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).
2.2.1.2 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).
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.
2.2.1.3 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.
2.2.2 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.
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, 2011.
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;
é 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.
2.2.2.1 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
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, 2009.
O Scrum é baseado em três fases: pré-planejamento, desenvolvimento e pós-planejamento. 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).
2.3 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,
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
„bugs1’, 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‟ ”.
2.3.1 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.
2.3.1.1 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).
1Bug é um “[...] defeito no software que, caso mantido, pode provocar falhas no sistema.” (HETZEL, 1987, p. 15).
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).
2.3.1.2 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.
2.3.1.3 Preparação
Para que o teste seja executado de forma correta e precisa, é importante que o ambiente de teste seja configurado corretamente.
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).
2.3.1.4 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).
2.3.1.5 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).
2.3.1.6 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).
2.3.2 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).
2.3.3 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
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.
2.3.3.1 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
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.
2.4.1 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.
2.4.2 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).
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).
2.4.3 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).
2.4.4 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.”
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).
2.4.5 Técnicas de testes
Os testes de software podem ser divididos em testes funcionais, também chamados de testes preta, e testes estruturais, conhecidos também como testes caixa-branca. 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).
2.4.5.1 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.
2.4.5.1.1 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).
2.4.5.1.2 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.”
2.4.5.1.3 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
ser feitos tratamentos no código para resolver erros que possam aparecer durante a execução do software.
2.4.5.1.4 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).
2.4.5.2 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.
2.4.5.2.1 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).
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 para-lo. 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).
2.4.5.2.2 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).
2.4.5.2.3 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
