EDUARDO FINOTTI GUSTAVO ROBERTO NITO
PRIORIZAÇÃO DE TESTES DE SOFTWARE: UM ESTUDO DE CASO
FLORIANÓPOLIS 2015
PRIORIZAÇÃO DE TESTES DE SOFTWARE: UM ESTUDO DE CASO
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. MARIA INÉS CASTIÑEIRA, DRA.
FLORIANÓPOLIS 2015
PRIORIZAÇÃO DE TESTES DE SOFTWARE: UM ESTUDO DE CASO
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.
Agradecemos a Deus primeiramente e dedicamos este trabalho a nossas famílias que sempre nos deram muito apoio em todos os momentos. Principalmente o apoio recebido nessa etapa tão importante em nossas vidas.
Agradecemos, a Maria Inés, nossa orientadora, pelo imenso apoio, e a coordenadora do curso, Vera Schumacher.
Eduardo Finotti agradece a: Deus primeiramente
A minha família pelo grande apoio, principalmente a Valdir Luiz Finotti. Agradeço também pela paciência dos amigos e namorada, Fabíola Cardoso. Ao colega Gustavo Nito pela parceria não só no desenvolvimento deste trabalho, mas durante todo o curso.
Aos professores do curso, que contribuirão com seu conhecimento e experiência ao longo dos anos.
Aos convidados da banca que aceitaram o convite e dispuseram seu tempo para colaborar com o trabalho.
Gustavo Roberto Nito agradece a: A Deus.
A orientadora Maria Inés Castiñeira por toda dedicação, paciência, força e auxilio que nos foi fornecido.
A coordenadora Vera Schuhmacher, que sempre apoiou e nos forneceu toda a estrutura necessária para o andamento da graduação.
Ao Cristiano Caetano e Leandro Cunha por todos os ensinamentos na área de Qualidade de Software.
Aos professores do curso, que contribuirão com seu conhecimento e experiência ao longo dos anos.
Aos convidados da banca que aceitaram o convite e dispuseram seu tempo para colaborar com o trabalho.
Ao meu colega Eduardo Finotti, por todo esforço e parceria para realização deste trabalho.
Aos meus Pais por toda a dedicação, apoio, incentivo e amor durante toda a minha vida.
"Para uma tecnologia de sucesso, a realidade deve ter prioridade sobre as relações públicas, pois a Natureza não pode ser enganada." (Richard Feynman).
O desenvolvimento de software é um processo com um alto grau de complexidade. Com o intuito de atingir um adequado padrão de qualidade do produto, os testes de software geralmente fazem parte desse processo. Neste trabalho é apresentado um estudo de caso que descreve a aplicação de técnicas de análise de risco para realizar priorização de testes de software em uma empresa de desenvolvimento da Grande Florianópolis. Nessa empresa, devido a fatores externos à equipe de qualidade, muitas vezes o tempo definido para a execução dos testes acaba sendo reduzido e não é suficiente para aplicar todo o processo de testes conforme panejado. Para solucionar essa problemática é utilizada a análise de risco. O trabalho inicialmente apresenta uma revisão da literatura. Esta aborda assuntos como processos de desenvolvimento de software, qualidade, tipos de testes e análise de riscos. No estudo de caso primeiro é mostrado o processo de testes da empresa em estudo. A seguir, as estimativas para as atividades desse processo são calculadas para dois casos de uso de um projeto de software. Na continuação e apresentada a técnica de priorização dos testes, aplicando a análise de risco. A priorização de testes é realizada considerando a probabilidade do erro acontecer, a relevância de cada funcionalidade e regra do sistema para o negócio do cliente e a severidade do impacto causado pelo acontecimento do erro no negócio do cliente. A técnica é aplicada nos casos de teste dos dois mesmos casos de uso e as estimativas são novamente calculadas. Finalmente são discutidos os resultados obtidos.
Palavras-chave: Teste de software, Priorização de testes, Processo de teste de software, Análise de risco.
Software development is a process with a high degree of complexity. In order to achieve an adequate standard of product quality, software tests are often part of this process. This paper presents a case study that describes the application of risk analysis techniques to perform prioritization of software testing in a development company of Florianópolis. In this company, due to external factors to the quality of staff, often the time set for the tests ends up being reduced and it is not enough to apply all the testing process as panejado. To solve this problem is to use risk analysis. The work initially presents a literature review. This addresses issues such as software development processes, quality, types of tests and risk analysis. In the first case study is shown company testing process under study. The following estimates for the activities of this process are calculated for two cases of use of a software project. The maintenance and presented the technique of prioritizing the testing, applying risk analysis. The prioritization testing is performed considering the error probability happens, the relevance of each system's functionality and rule for the client's business and the severity of the impact of the error event in the customer's business. The technique is applied in test cases of the two same use cases and estimates are recalculated. Finally the results are discussed.
Keywords: Software Testing, Prioritization of Testing, Software Testing Process, Risk Analysis.
1 INTRODUÇÃO ... 12 1.1 PROBLEMA ...14 1.2 OBJETIVOS ...15 1.2.1 Objetivo Geral ...15 1.2.2 Objetivos Específicos ...16 1.3 JUSTIFICATIVA ...16 1.4 ESTRUTURA DA MONOGRAFIA ...17 2 REVISÃO DA BIBLIOGRÁFICA ... 18 2.1 ENGENHARIA DE SOFTWARE ...18
2.1.1 Processo de Desenvolvimento de Software ...19
2.1.2 Atividades Guarda-Chuva ...19
2.1.3 Modelo de Processos de desenvolvimento de software ...20
2.2 QUALIDADE DE SOFTWARE ...23
2.3 TESTES DE SOFTWARE ...24
2.3.1 Validação e Verificação ...25
2.4 PROCESSO DE TESTE DE SOFTWARE ...26
2.4.1 Procedimentos iniciais ...27 2.4.2 Planejamento ...27 2.4.3 Preparação ...28 2.4.4 Especificação ...29 2.4.5 Execução ...30 2.4.6 Entrega ...30 2.5 EQUIPE DE TESTES ...31 2.5.1 Cargos e funções ...31
2.6 TIPOS DE TESTE DE SOFTWARE ...32
2.6.1 Testes unitários ...32
2.6.2 Testes de integração ...33
2.6.3 Testes de sistema ...34
2.6.4 Testes de aceitação ...34
2.7 TÉCNICAS DE TESTES ...35
2.7.1 Testes funcionais ou caixa-preta ...35
2.7.1.1 Testes de requisitos ... 36
2.7.1.2 Testes de regressão ... 37
2.7.1.3 Teste tratamento de erros ... 38
2.7.1.4 Testes de interconexão ... 38
2.7.2 Teste estrutural ou caixa-branca ...39
2.7.2.2 Testes de estresse ... 39 2.7.2.3 Teste de performance ... 40 2.7.2.4 Teste de recuperação ... 40 2.7.2.5 Teste de segurança ... 41 2.7.3 Testes não-funcionais ...42 2.7.3.1 Testes de usabilidade ... 42 2.7.3.2 Testes de instalação ... 43 2.8 GERENCIAMENTO DE RISCOS ...43 2.8.1 Definição de Risco ...43 2.8.2 Gerenciamento de Riscos ...44 2.8.3 Riscos e Testes ...45 2.8.4 Importância e Benefícios ...46
2.9 CONSIDERAÇÕES FINAIS ...49
3 MÉTODO... 50
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ...50
3.2 ETAPAS PARA DESENVOLVIMENTO DO PROJETO ...52
3.3 DELIMITAÇÕES ...53
4 ESTUDO DE CASO - APLICAÇÃO DA PRIORIZAÇÃO DE TESTES ... 54
4.1 A EMPRESA (SOFTPLAN). ...54
4.2 PROCESSO DE TESTES DA EMPRESA ...55
4.2.1 Estimativas ...56
4.2.1.1 Estimar a Revisão da Especificação de Negócio ... 56
4.2.1.2 Estimar o projeto dos Casos de Testes ... 57
4.2.1.3 Estimar a execução dos Casos de Testes ... 57
4.2.2 Revisar Especificação de Software ...58
4.2.2.1 Registrar as não-conformidades ... 59
4.2.3 Projetar casos de testes ...60
4.2.3.1 Mapeamento dos itens de testes ... 61
4.2.3.2 Elaborar casos de testes ... 62
4.2.3.2.1 Listas de Verificação...62
4.2.3.3 Abordagens para execução de testes ... 63
4.3 ESTUDO DE CASO ...65
4.3.1 Casos de Uso ...66
4.4 ESTIMATIVA ...68
4.4.1 Aplicação da estimativa ... 70
4.5 REVISÃO DE ESPECIFICAÇÃO ...71
4.6 ESPECIFICAÇÃO DOS CASOS DE TESTES ...73
4.6.1 Exemplo de caso de documento de teste...74
4.6.1.1 Aplicando o documento de testes ... 76
4.7 PRIORIZAÇÃO DOS TESTES ...82
4.7.1.1 Priorização Aplicando Análise de Risco ... 83
4.7.1.2 Aplicação da Priorização ... 86
4.7.1.3 Estimativa com a priorização de testes... 88
4.7.1.4 Considerações Finais do Capítulo ... 89
5 CONCLUSÕES E TRABALHOS FUTUROS... 90
REFERÊNCIAS ... 92
ANEXO ... 95
5.1 ANEXO A – CRONOGRAMA DAS ESTAPAS PARA DESENVOLVIMENTO DO PROJETO 95 ... 95
5.2 ANEXO B – CRONOGRAMA DAS ESTAPAS PARA DESENVOLVIMENTO DO PROJETO 96
1 INTRODUÇÃO
Muitas das empresas e organizações que constituem o setor produtivo são baseadas em dados. Esses dados são processados, gerando informações de diversas naturezas para a organização, assim, auxiliando na tomada de decisões da corporação, auxiliando a mesma de diversas formas.
Segundo Laudon e Laudon (1999, p. 10), “conhecimento é o conjunto de ferramentas conceituais e categorias usadas pelos seres humanos para criar, colecionar, armazenar e compartilhar a informação”. Essas informações são resultado da manipulação desses dados, através de um “sistema de informação”, porém relacionados e baseados no conhecimento humano.
Para que esses dados possam ser analisados e armazenados, são desenvolvidos softwares, que auxiliam no processamento desses dados e que geram informações para a organização. Sem esses sistemas informatizados, seria impossível, ou muito difícil, fazer essas análises ou armazenar os dados da organização.
Um fator prezado pelas empresas é a satisfação dos clientes em relação ao produto que está sendo entregue. Para atingir essa satisfação, é preciso que o software tenha boa qualidade, em todos os sentidos, como possuir boa usabilidade, atingir os objetivos propostos e atender as necessidades do cliente, por exemplo.
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. ” Alguns desses defeitos ou problemas identificados no software ainda podem ser devidos a requisitos do cliente não atendidos durante o desenvolvimento. Com isso, entende-se que, para existir um software com uma boa qualidade, é necessário que este contemple o que foi decidido e levantado junto ao cliente, não exibindo falhas que interfiram em seu uso correto.
Para que esses erros ou falhas nos softwares sejam identificados, é feito o uso dos métodos de testes. Segundo Hetzel (1983, apud HETZEL, 1987p. 6), "teste é qualquer atividade que vise a avaliar uma característica ou recurso de um programa ou sistema. Teste é a medida da qualidade do software."
Além dos testes realizados nos softwares, alguns outros fatores também podem influenciar na qualidade do mesmo, como requisitos que não foram bem especificados pela empresa, na hora de solicitar um sistema para gerir seus dados, não se obtendo uma boa
definição do que é necessário implementar. Segundo Koscianski 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. ”.
Em muitos projetos, ainda existem problemas na hora de executar esses testes no software desenvolvido. Como a cultura de testes não está bem consolidada em todas as organizações de software, muitas vezes, os testes são deixados de lado ou são executados pela própria equipe de desenvolvimento, ou seja, os programadores.
Diversos autores afirmam que, quando existem a execução dos testes, feita de forma sistemática, dentro de um processo, o custo de correção de defeitos na produção cai drasticamente (Regra 10 de Myers). Além disso, o custo do software tende a ser relativamente menor quando o software é bem testado (BASTOS, 2007, p. 22).
O custo de uma correção é muito mais caro quando descoberto mais tarde, ou seja, quanto mais adiante no processo de desenvolvimento de software o defeito é descoberto, mais caro ele se torna para ser corrigido.
Para que o teste seja executado de forma que possa contemplar todas as condições possíveis de serem executadas em um sistema, são criados os casos de teste. Estes são desenvolvidos a partir dos casos de uso, ou seja, dos caminhos que englobam os requisitos do sistema, como regras de negócio, regras de tela, requisitos funcionais, entre outros. Conforme Heumann (2001), um caso de teste é um conjunto de entradas de teste, condições de execução e resultados esperados para um objetivo particular: exercer um caminho particular do programa ou verificar o cumprimento de um requisito específico, por exemplo.
Assim, dentro de um caso de teste, tem-se uma pré-condição, um processamento e um resultado esperado, e, como citado, este resultado esperado tem como base os requisitos do sistema.
Por isso, uma boa tática é fazer a revisão da especificação. Quem realiza essa tarefa é o analista de testes. Ela tem por objetivo encontrar dúvidas ou artefatos que impedem o entendimento da criação do caso de teste e da própria execução destes.
Segundo Bastos (2007, p.22),
A correção de defeitos encontrados na fase de desenho custa menos que a de defeitos encontrados na fase de produção. Alguns especialistas, como Rex Black (1999), afirmam que existe uma progressão do tipo “dez, cem, mil” se compararmos os custos dos defeitos encontrados na fase de desenho, da codificação e da produção.
Quando os testes são executados por uma equipe de testes, geralmente são executados a partir dos casos de testes, desenvolvidos, considerando a documentação do sistema.
1.1 PROBLEMA
Pela experiência dos autores percebe-se que devido a decisões além da equipe de testes o tempo disponibilizado para a equipe desenvolver o seu trabalho pode ser reduzido considerando o tempo previsto inicialmente como adequado. Isso pode acontecer por diversos fatores, dentre eles, equipe de testes reduzida, datas de entrega mal definidas, fraca cultura de testes ou decisões estratégias tomadas pela gerência do projeto além das questões técnicas compreendidas pela equipe de testes. Muitas pessoas pensam que o teste detalhado não é tão relevante, contudo, qualquer erro, falha ou defeito, tem certo grau de “importância” dentro do sistema, ou seja, um erro, falha ou defeito pode ser mais ou menos prejudicial ao sistema.
Por isso, tendo como base essa possível redução dos prazos de teste e o risco que o defeito, ou o não atendimento do requisito pedido pelo cliente, pode causar no sistema, este trabalho propõe criar uma priorização da execução dos testes.
Segundo Bastos (2007, p. 23), uma das maneiras de priorizar os testes de um software é analisar os principais riscos para o negócio que uma determinada falha poderia causar. A partir desses esclarecimentos sobre a temática do trabalho, é apresentada a problemática do mesmo.
O teste é fundamental para garantir a qualidade de um software (Black, 2008, p.1). Porém, quando o tempo para a execução de testes não é suficiente para que todos os testes sejam executados de maneira correta, alguns testes devem ser priorizados, de forma que, talvez, alguns outros fiquem fora da execução. Nesse caso é essencial que os testes que deixam de ser realizados sejam aqueles mais inócuos, aqueles que poderiam achar falhas menos graves ou em funcionalidades que não afetam tanto o negócio do cliente.
Na empresa do estudo de caso, 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 de entrega 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 por exemplo a documentação, são deixadas de lado, assim, o risco de não executar um teste importante pode ser alto.
Os resultados de uma atividade podem não ser adequados quando existe uma dependência do entendimento e interpretação das pessoas, a partir de documentação incompleta ou inexistente. 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.
Assim, diante da impossibilidade de desenvolver e aplicar todos os possíveis casos de teste, é necessário definir de alguma maneira quais são os testes mais relevantes, que devem ser realizados para garantir os requisitos mínimos de qualidade, e quais testes são menos relevantes, aqueles cuja ausência compromete em menor medida os resultados do desenvolvimento de software.
Dessa forma, as perguntas de pesquisa propostas neste trabalho são: Como realizar a priorização da execução desses testes? No que se basear para criar técnicas de priorização de teste? Quais os critérios para a escolha de uma técnica a ser usada em uma situação específica?
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 é pesquisar e escolher ou desenvolver técnicas para realizar a priorização dos testes de software e aplicar esse processo em um estudo de caso.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho são:
• Realizar um levantamento da literatura sobre qualidade e testes de software; • Pesquisar sobre métodos de testes de software;
• Criar métodos e técnicas de priorização na execução do projeto de testes;
• Aplicar a priorização de testes em um projeto da empresa do estudo de caso, visando diminuir a quantidade de horas necessárias para que o projeto de testes seja realizado.
1.3 JUSTIFICATIVA
Um estudo conduzido pela NIST (National Institute of Standards and Technology), em 2002, informou que defeitos em software custam para a economia dos Estados Unidos da América $59.5 bilhões de dólares anualmente, mais de um terço deste custo poderia ser evitado com melhores testes de software executados.
Segundo Pressman (1995, p. 23), “A qualidade de software frequentemente é suspeita. Só recentemente começamos a entender a importância dos testes de software sistemáticos e tecnicamente completos. Somente agora estão começando a surgir conceitos quantitativos sólidos de confiabilidade e garantia de qualidade de software. ”
A entrega de um software de qualidade é de extrema importância para mantermos a satisfação e confiança do cliente. Para garantir a entrega, é necessário manter uma equipe de testes para que os defeitos sejam descobertos ainda em produção, visando à qualidade do produto.
Conforme Caetano (2009) relata em seu artigo, se considerarmos o tamanho dos softwares atuais e sua complexidade, dificilmente conseguiremos executar todos os testes
envolvidos para uma cobertura de 100%. Dificultando ainda mais esta situação, temos os prazos curtos e orçamentos limitados.
Desta forma, este trabalho se propõe pesquisar técnicas e metodologias para priorização dos testes, de forma que acobertem uma maior porcentagem possível, garantindo uma entrega de maior qualidade e evitando gastos no tempo de produção e gastos futuros de manutenção.
1.4 ESTRUTURA DA MONOGRAFIA
Esta monografia está dividida em 5 capítulos. A seguir, será apresentada estrutura do trabalho:
• Capítulo 1 – Introdução: este capítulo apresenta a introdução, problema, os objetivos e a justificativa do trabalho.
• Capítulo 2 – Revisão bibliográfica: este capítulo apresenta temas relacionados à Qualidade, Processos e Testes de software.
• Capítulo 3 – Metodologia: Neste capitulo, é descrita qual a metodologia de pesquisa utilizada para desenvolver esta monografia.
• Capitulo 4 – Aplicação da Priorização de casos de testes - estudo de caso
2 REVISÃO DA BIBLIOGRÁFICA
Neste capítulo, apresentaremos a fundamentação teórica sobre os temas de Engenharia de Software, Qualidade de Software e Testes.
2.1 ENGENHARIA DE SOFTWARE
Segundo Pressman (2011), nos dias atuais, os softwares se incorporaram em sistemas de todas as áreas, fabricas, transportes, medicina, telecomunicações, indústrias, máquinas, isto é, uma lista quase infindável. Ninguém poderia prever que estes milhares de softwares precisariam ser corrigidos, adaptados e ampliados com o passar do tempo.
Conforme aumenta a importância do software, a comunidade da área tenta desenvolver tecnologias e ferramentas que facilitam o seu desenvolvimento com uma melhor qualidade. (Pressman, 2011, p.30). Porém os softwares não conseguem garantir uma total e perfeita funcionalidade do produto desenvolvido, o surgimento de uma tecnologia que garanta isso, ainda, é incerta, pois os softwares não só facilitam a distribuição da informação, como também, em muitos casos, eles são responsáveis diretos e indiretos pela vida de muitas pessoas. Para um software resultar em um produto de qualidade, surge a engenharia de software.
“A engenharia de software é uma disciplina de engenharia relacionada a todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção, depois que este entrar em operação”. (Sommerville,2007, p.15).
Segundo Finkelstein (1996), a Institute of Electrical and Electronics Engineers define a Engenharia de software como: A aplicação de uma abordagem sistemática, disciplinada e quantificável no desenvolvimento, na operação e manutenção de software; isto é, a aplicação de engenharia ao software.
Esta engenharia visa ao desenvolvimento do software de uma forma, segura, com qualidade e sustentabilidade financeira, oferecendo a forma mais apropriada para garantir estes quesitos (Pressman, 2011, p.39).
2.1.1 Processo de Desenvolvimento de Software
Segundo Sommerville (2007, p. 6), o processo de software é um conjunto de atividades e resultados associados que produzem um produto de software. Este autor afirma que em todo processo de software existem basicamente quatro atividades fundamentais que são comuns a todo processo:
1. Especificação de software: engenheiros juntamente com os clientes definem o software que será produzido e as restrições para sua operação.
2. Desenvolvimento de software: o software é projetado e programado.
3. Validação de software: atividade na qual o software é verificado para garantir se é o que o cliente deseja.
4. Evolução de software: são feitas modificações no software para se adaptar às mudanças dos requisitos tanto do cliente quanto do mercado.
Diferentes autores podem agrupar ou nomear essas atividades de forma um pouco diferente, mas todos eles concordam no desenvolvimento dessas atividades básicas. Também, de acordo com o tipo de software, podem existir mais ou menos fases, algumas podem ser feitas em conjunto ou com diferente ordenação, para isto existem diferentes modelos de processo de desenvolvimento.
2.1.2 Atividades Guarda-Chuva
Pressman (2011) complementa que as atividades genéricas são complementadas por uma série de atividades guarda-chuva, entre as quais podem ser citadas:
• Acompanhamento e controle do projeto de software: permite à equipe de software avaliar o processo com base no plano de projeto e realizar as ações necessárias para manter o cronograma;
• Gestão de risco: avalia os riscos que podem afetar o resultado do projeto ou a qualidade do produto;
• Garantia de qualidade de software: define e conduz as atividades necessárias para garantir a qualidade do software;
• Revisões técnicas formais: avaliar os produtos de trabalho da Engenharia de Software, num esforço para descobrir e remover erros, antes que eles sejam propagados para a próxima atividade;
• Medição: define e reúne medidas de processo, projeto e produto que ajudam a equipe a entender um software que satisfaça às necessidades do usuário;
• Gestão de configuração de software: gerência dos efeitos das modificações ao longo de todo o processo de software.
• Gestão de usabilidade: define os critérios para a reutilização dos produtos de trabalho, inclusive componentes de software;
• Preparação e produção do produto de trabalho: tratam sobre os documentos, modelos, registros, formulários e listas.
2.1.3 Modelo de Processos de desenvolvimento de software
Conforme Sommerville (2007, p. 6), o modelo de processo de software é uma descrição simplificada do processo de software que apresenta uma visão do mesmo. Os modelos de processo incluem as atividades, que fazem parte do processo de software, os produtos de software e os papéis das pessoas envolvidas na engenharia de software.
Segundo Pressman (2011, p. 53), todos os modelos de software podem acomodar atividades metodológicas genéricas, porém cada um deles dá uma ênfase diferente a essas atividades e define um fluxo de processos que invoca cada atividade metodológica, tarefas e ações de engenharia de software de forma diversa.
Os seguintes modelos são alguns dos mais conhecidos: 1. Modelo Cascata:
Algumas vezes chamado de ciclo de vida clássico, sugere uma abordagem sequencial e sistemática para o desenvolvimento de software, iniciando com o levantamento de requisitos
das necessidades do cliente, posteriormente a fase de planejamento, modelagem, construção, emprego e, por fim, o suporte contínuo do software concluído. (PRESSMAN, 2011, p. 59).
2. Modelo em V:
Descreve a relação entre ações de garantia de qualidade e as ações associadas à comunicação, modelagem e atividades de construção iniciais. Conforme a equipe de software desce no lado esquerdo do V, os requisitos básicos dos problemas são refinados em representações mais detalhadas de forma progressiva e técnicas do problema e sua solução. Após o código ser gerado, a equipe se desloca para o lado direito do V, realizando uma série de testes com a finalidade de validar cada um dos modelos criados à medida que a equipe se move para baixo no lado esquerdo do V. A grande diferença com relação ao modelo clássico seria que este modelo fornece uma melhor forma para visualizar a verificação e as validações aplicadas ao trabalho de engenharia anterior. (PRESSMAN, 2011, p. 60).
3. Modelo Evolucionário
Modelos evolucionários são iterativos, pois apresentam características que possibilitam desenvolver versões cada vez mais completas de software. (PRESSMAN, 2011, p. 62).
4. Modelo Incremental
Este modelo combina elementos do fluxo de processos lineares e paralelos. Aplica sequencias lineares de forma escalonada, à medida que o tempo avança. Cada sequência linear gera “incrementais”, entregáveis, aprovados e liberados de software, de maneira similar aos incrementais gerados por um fluxo de processos evolucionário.
5. Modelo Concorrente
Possibilita à equipe representar elementos concorrentes e iterativos de qualquer um dos modelos descritos anteriormente. Define uma série de eventos que irão disparar transições de estado para estado para cada uma das atividades, ações ou tarefas da engenharia de software. (PRESSMAN, 2011, p. 67).
6. O Processo Unificado
Enfatiza o papel da arquitetura de software e ajuda ao arquiteto a manter o foco nas metas corretas. Sugere um fluxo de processos interativo e incremental, fornecendo uma sensação evolucionária, essencial no desenvolvimento de software moderno. (PRESSMAN, 2011, p. 71).
7. Desenvolvimento Ágil.
A engenharia de software ágil une filosofia com um conjunto de princípios de desenvolvimento. A filosofia defende a satisfação do cliente e a entrega de incremental prévio, equipes pequenas e motivadas, métodos informais, artefato de engenharia de software mínimos e acima de tudo simplicidade no desenvolvimento geral. Os princípios de desenvolvimento priorizam as entregas mais que a análise e o projeto, também priorizam a comunicação ativa e continua entre clientes e desenvolvedores. (PRESSMAN, 2011, p. 81).
7.1Extreme Programming – XP (Programação Extrema)
Para ilustrar um processo ágil, surge a Extreme Programming – XP (Programação Extrema), que emprega uma abordagem orientada a objetos como seu paradigma de desenvolvimento preferido e envolve regras e práticas constantes no contexto de quatro atividades metodológicas: planejamento, projeto, codificação e testes. Um projeto XP segue de forma rigorosa os princípios KIS (keep it simple, ou seja, preserve a simplicidade). É preferível um projeto simples do que uma representação mais complexa. (PRESSMAN, 2011, p. 88).
7.2Scrum
Os seus princípios são constantes com o manifesto ágil e utilizados para orientar as atividades de desenvolvimento dentro de um processo que incorpora as atividades estruturais: requisitos, análise, projeto, evolução e entrega. Em cada atividade, ocorrem tarefas a realizar dentro de um padrão de processo. O trabalho realizado dentro de uma Sprint é adaptado ao problema em questão e definido, e, muitas vezes, modificado em tempo real pela equipe Scrum. Este método enfatiza o uso de um conjunto de padrões de processos de software que provaram
ser eficazes para projetos com prazos e entrega apertados, requisitos mutáveis e críticos de negócio. (PRESSMAN, 2011, p. 95).
2.2 QUALIDADE DE SOFTWARE
Segundo Pressman (2011), no desenvolvimento de software, a qualidade de um projeto engloba o grau de atendimento às funções e características especificadas no modelo de requisitos.
Um bom software, assim como os serviços que ele fornece, possuem atributos associados que demonstram a qualidade do software. Estes atributos refletem o comportamento do software e estão ligados diretamente a sua aplicação, por exemplo, um software bancário deve ser seguro, um jogo interativo deve ser ágil. Um software de qualidade deve ter um conjunto de atributos. Os seguintes são alguns exemplos de atributos de um software de qualidade. (SOMMERVILLE, 2007, p. 9).
• Facilidade de Manutenção: deve ser escrito de forma que possa evoluir e atender as necessidades do cliente. É um atributo fundamental, pois a mudança do software é inevitável em um ambiente de negócios de constante evolução.
• Confiança: este nível pode conter confiabilidade, proteção e segurança. Não pode causar danos físicos ou econômicos no caso de falhas.
• Eficiência: não deve desperdiçar recursos do sistema. Eficiência inclui tempo de resposta, tempo de processamento, utilização de memória, entre outros.
• Usabilidade: O software deve ser usável, sem muito esforço pelo tipo de usuário para o qual ele foi planejado. Deve apresentar interface amigável e documentação adequada.
Para um software possuir qualidade em todos estes itens, ele deve ser muito bem testado antes de ser colocado em uso.
2.3 TESTES DE SOFTWARE
Desenvolver um software com todos os seus processos está longe de ser uma tarefa simples.
De acordo com 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 às necessidades dos clientes depende principalmente da habilidade e interpretação das pessoas que o constroem.
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; fornece informações sobre a qualidade de um software. (HETZEL, 1987, p. 17).
Molinari (2003, p. 22 e 23) diz 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.”
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).
Por isso, “A meta de um testador de software é achar bugs∗, 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”. (HETZEL, 1987, p. 15).
2.3.1 Validação e Verificação
Delamaro, Maldonado e Jino (2007) afirmam que as atividades de validação, verificação e teste têm como principal objetivo garantir que o produto está sendo desenvolvido conforme o definido e que apresenta o menor número de falhas possível.
A verificação tem como objetivo verificar se o que foi desenvolvido está de acordo com 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 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. ” (PRESSMAN, 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).
No mesmo contexto, Sommerville afirma que:
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).
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.”.
2.4 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, entretanto algumas atividades são comuns a todos, e dentro desse contexto de desenvolver um sistema, existe a atividade de teste de software.
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).
Apesar disso, Myers (1979) nos mostra que aparentemente o conhecimento sobre teste de software é muito menor em relação a outros aspectos e/ou atividades do desenvolvimento de software.
O teste de produtos de software evolui basicamente pelas seis etapas apresentadas a seguir:
• Procedimentos iniciais;
• Planejamento;
• Especificação;
• Execução;
• Entrega.
2.4.1 Procedimentos iniciais
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).
Uma boa forma de garantir uma boa especificação de testes é ter requisitos de sistema bem definidos.
Por isso, nos procedimentos iniciais, é feito um “[...] 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).
Para que o teste seja executado da maneira mais eficaz, “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.4.2 Planejamento
Antes de executar qualquer atividade, relacionada a testes, desenvolvimento de software, ou qualquer outra área, deve-se ter um bom planejamento.
Por isso, segundo o International Software Testing Qualifications Board (2007, p. 15), “planejamento de teste é a atividade que consiste em verificar a missão do teste, definindo os seus objetivos e especificando as atividades de forma a alcançá-los. ”
Bastos (2007) diz que o planejamento dos testes deve permanecer “ativo” durante todo o projeto, pois constantemente é necessário avaliar os rumos que o projeto está seguindo.
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 o conhecimento prático dos autores, existe um certo receio com o planejamento, muito se fala de planejamento de testes, e pouco se faz, alguns gerentes colocam testes em segundo plano, mesmo sabendo das possíveis consequências (quase sempre) negativas.
A esse respeito Molinari (2003, p. 125) afirma que “planejamento de teste é um processo. [...]”.
2.4.3 Preparação
Para que o teste seja executado de forma correta e precisa, é importante que o ambiente de teste seja configurado corretamente, e esta fase tem como principal objetivo 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.
“A garantia da integridade do ambiente de teste está diretamente relacionada à garantia de qualidade do produto. ” (BASTOS et al., 2007, p. 85).
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).
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.
2.4.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.
Dentro desta documentação, podemos citar o Roteiro de Testes que contém os casos de testes, nele serão incorporados todos os casos de testes de um Caso de Uso.
Portanto, um caso de teste “descreve uma condição particular a ser testada e é composto por valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado”. (CRAIG e JASKIEL, 2002).
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).
Ou seja, para cada Caso de Uso, haverá pelo menos um documento de Especificação ou Roteiro de testes. O documento de Especificação de testes terá as ações necessárias para testar determinada função do sistema.
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.4.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.4.6 Entrega
A entrega é o marco final do processo de testes. A documentação utilizada é armazenada em repositórios para futuras execuções e consultas.
Depois disso, é realizada a documentação das lições aprendidas e melhorias encontradas durante todo o processo de testes, além de ser 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, como já foi relatado, são avaliadas as lições aprendidas com objetivo de buscar aprimorar a maturidade dos testes. (INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD, 2007).
2.5 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. ” Nesse processo de testes, os profissionais desenvolvem diferentes tarefas as quais podem requerer diversas habilidades. Por isso, a seguir, serão apresentados os principais cargos e funções da área de testes.
2.5.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).
O Analista de Teste geralmente tem experiência em programação, e deve ter o conhecimento do sistema e/ou da aplicação em teste, e tem experiência em vários tipos e técnicas de testes, tem um entendimento no que é uma falha ou defeito. Ele tem como papel monitorar detalhadamente o processo de testes e o resultado de cada ciclo, se for necessário, além de elaborar os artefatos de testes.
Já o testador tem experiência em diversos tipos de testes, conhece as técnicas e alguns deles têm o conhecimento sobre automação de testes. Seu papel é executar os testes, reportar os defeitos e, dependendo do caso, automatizar os testes.
2.6 TIPOS DE TESTE DE SOFTWARE
A atividade de teste consiste de uma análise dinâmica do produto, ela é uma atividade importante para a identificação e correção de erros que existem no sistema.
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.6.1 Testes unitários
Os primeiros testes que o desenvolvedor deve executar são os testes unitários. Eles são elaborados durante a fase de desenvolvimento. Tem como principal objetivo testar a menor
funcionalidade existente do software, isto é, isolar funcionalidades do sistema, e verificar se essas funcionalidades têm como retorno o esperado, em relação à entrada informada.
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 a 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).
Geralmente, quem executa esse tipo de testes é o próprio desenvolvedor, pois é importante conhecer o código fonte do sistema em questão. Então, logo que desenvolvido, o programador executa este tipo de teste, garantindo que o que ele acabou de programar está funcionando como o especificado.
Os testes unitários podem ser considerados como teste da caixa preta, citados mais adiante.
2.6.2 Testes de integração
Durante o Teste de integração, os módulos são testados em grupo, ele é realizado depois dos testes unitários e antes do teste de sistema.
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).
Portanto, esse teste é alimentado pelos módulos que já foram testados individualmente. 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.6.3 Testes de sistema
Esse tipo de teste é executado para avaliar o software com objetivo de buscar defeitos por meio da utilização do sistema, como se fosse o usuário final no comando dos testes.
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.6.4 Testes de aceitação
Esses testes são realizados geralmente por um restrito grupo de usuários finais do sistema. Esses simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado.
Os testes de aceitação são “[...] realizados pelos usuários, visando a 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.7 TÉCNICAS DE TESTES
Com o aprimoramento na execução de testes surgiram diversas maneiras de se testar um software. Segundo as experiências profissionais dos autores, existem algumas técnicas que foram muito aplicadas em sistemas desenvolvidos em linguagens estruturadas e que até hoje têm grande importância nos sistemas orientados a objeto.
Apesar de os tipos de desenvolvimento serem diferentes, o principal objetivo dessas técnicas ainda continua a ser o mesmo: encontrar falhas e defeitos no software. As principais técnicas existentes são: técnica funcional e estrutural.
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.7.1 Testes funcionais ou caixa-preta
Segundo Myers (2004), também chamada de teste funcional, teste comportamental, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo.
Nessa técnica de teste, o componente de software a ser testado é manuseado como uma caixa-preta, isto é, não é considerado o código do sistema, conforme ilustrado na Figura 1.
São informados os dados de entrada, o teste é executado e o resultado da saída é comparado a um resultado já esperado, assim, avaliando se o comportamento está correto ou se existe um defeito. Há sucesso no teste se o resultado gerado pelo sistema for o que se esperava.
Figura 1 - Técnica de Teste Funcional.
Fonte: The Art of Software Testing, 2004.
Testes funcionais podem ser considerados os: testes dos requisitos, testes de regressão, testes de tratamento de erros e testes de interconexão.
A técnica de teste funcional é aplicável a todos os níveis de teste (PRESSMAN, 2006). 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).
2.7.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).
Portanto, uma boa prática de testes é avaliar os requisitos descritos pelo Analista de sistemas e apontar falhas nos requisitos, principalmente no que se diz respeito a interferência ou mal entendimento desses requisitos para a criação dos casos de testes.
Ou seja, se um requisito está mal escrito, com uma dupla interpretação, por exemplo, isso pode interferir na criação dos casos de testes. Por isso, esses testes são executados antes mesmos do ciclo de vida, para que o analista de sistemas corrija os requisitos, e a criação dos casos de testes seja desenvolvida de maneira correta.
2.7.1.2 Testes de regressão
Os testes de regressão não correspondem literalmente a um nível de teste, contudo é uma atividade muito importante para garantir que, quando é alterada alguma funcionalidade no sistema o que já estava funcionando, continue funcionando corretamente, ou seja, impede “efeitos colaterais”. Tem como objetivo aplicar, a cada nova versão do software, os testes que já foram executados nas versões ou ciclos de testes anteriores.
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 teste 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, reexecutando um subconjunto de todos os casos de teste ou usando ferramentas automatizadas de captação/re-execução. ”
2.7.1.3 Teste tratamento de erros
Nesse teste, é tratado principalmente o cenário em que acontece algum erro inesperado ou que não faça parte da execução normal do software, como, por exemplo, um Web Service não estar disponível, assim, verificando se o sistema está tratando corretamente essa situação.
“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.7.1.4 Testes de interconexão
Esse tipo de teste é realizado, porque softwares de aplicação costumam estar conectados com outros softwares de mesmo tipo, ou não, comunicando-se o tempo todo entre si.
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).
Um bom exemplo é o caixa eletrônico de um banco, pois a interface é um sistema (geralmente desenvolvida em uma linguagem orientada a objeto, com uma interface “amigável”), e a parte de processamento de dados é totalmente diferente (muitas vezes desenvolvida uma linguagem estrutural, completamente separada da interface). Nesse caso, são fornecidas entradas por um sistema, o processamento dos dados recebe esses dados, processa e retorna uma saída.
2.7.2 Teste estrutural ou caixa-branca
Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos. (PRESSMAN, 2005).
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).
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). Assim, pode se dizer que essa técnica avalia o comportamento interno do software, conforme ilustrado na Figura 2.
Figura 2 - Técnica de Teste Estrutural.
Fonte: The Art of Software Testing, 2004.
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.7.2.2 Testes de estresse
Alguns autores chegam a definir como uma técnica de teste caixa cinza, que seria um mesclado do uso das técnicas de caixa preta e caixa branca.
Segundo Finkelstein (1996), a partir dos testes de estresse, torna-se possível observar o comportamento do sistema durante situações críticas, identificando falhas não toleráveis e potencialmente difíceis de serem encontradas em situações normais de funcionamento.
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 pará-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.7.2.3 Teste de performance
Também, considerados testes de caixa cinza, os testes de performance, os testes de performance ou de desempenho, têm como objetivo verificar se o software atende os requisitos de desempenho definidos. É fundamental que os requisitos estejam claros e bem definidos, pois esses testes são realizados em cima dos requisitos não funcionais do sistema, e os cenários de teste também são fundamentais para este 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.7.2.4 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).
Ou seja, é a capacidade de reiniciar operações após a perda da comunicação de uma aplicação. Por exemplo: Ao desligar o computador, queda de energia elétrica, entre outros, garantindo a continuidade das operações após um desastre.
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 às 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 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).
2.7.2.5 Teste de segurança
Este teste é importante, pois: “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). Assim, tendo como principal objetivo garantir que os dados do sistema não são roubados, testando a vulnerabilidade do sistema.
“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.
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.
2.7.3 Testes não-funcionais
Além dos testes funcionais e estruturais existem os testes não-funcionais. Segundo Myers (2004), entre verificações cabíveis, estão a relação da interface com conhecimento do usuário, a compreensibilidade das mensagens de erro e a integridade visual entre diferentes componentes.
“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 respostas em um teste de performance. ” (INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD, 2007, p, 27).
Segundo o International Software Testing Qualifications Board (2007, p, 26), o teste não funcional valida o ‘como’ o sistema trabalha.
Podemos citar como testes não-funcionais os testes de usabilidade e instalação.
2.7.3.1 Testes de usabilidade
O teste de usabilidade tem como principal objetivo verificar a facilidade de uso do sistema.
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). Por exemplo, um sistema com uma ótima usabilidade facilita muito a vida de quem tem algum tipo de deficiência visual. 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).
2.7.3.2 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).
2.8 GERENCIAMENTO DE RISCOS
Este capítulo apresenta o que é um risco para o desenvolvimento de um software e qual a sua importância, para que futuramente seja possível realizar a priorização do que ser testado em relação com os maiores riscos principalmente para o software e para a organização.
2.8.1 Definição de Risco
O Software Engineering Institute (2002) define risco como a possibilidade de sofrer perda.
Para Bastos (2007), ao avaliar os riscos de um projeto, estamos buscando aqueles fatos cujas ocorrências poderão acarretar perdas para a empresa (BASTOS, 2007, p. 22).
Ou seja, a perda pode ser para a empresa em geral, ou para o projeto em si, pois, em desenvolvimento de projeto, a perda representa o impacto sobre o projeto em termos de diminuição da qualidade do produto final, aumento de custos, atraso na conclusão, ou fracasso do projeto.
Projetos de software possuem inúmeros fatores de riscos, como requisitos incertos, tecnologia desconhecida pela equipe, dependência de outros projetos, falta de documentação,
