Fundamentos de Teste de Software

Transcrição

1 Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 1- Visão Geral de Testes de Software Aula 1 Teste como Suporte para o Software

2 SUMÁRIO 1. INTRODUÇÃO Exemplos de casos de insucesso devido à ausência de teste Benefícios Custo de teste no ciclo de vida do desenvolvimento de software O Papel do Testador Definição do conceito de teste (Erro, Defeito e Falha) Padrões conceituais que são referências mundiais Processo de teste Abrangência na forma de condução Atividade do processo de teste Impacto na qualidade do produto Teste como processo de suporte Fases da garantia da qualidade Validação e Verificação ii

3 1. INTRODUÇÃO No mercado global, com a complexidade dos softwares, podemos ter a certeza que enfrentaremos a complexidade das equipes, o cronograma apertado para desenvolvimento, mercado/cliente/usuários mais exigentes, menos tolerância a falhas, menos tolerância aos atrasos das entregas. Para tanto: Precisamos criar softwares MELHORES, dentro do PRAZO, com CUSTO BARATO e de forma mais RÁPIDA. 2. Exemplos de casos de insucesso devido à ausência de teste Atualmente podemos perceber mais claramente qual o significado do custo quando não priorizamos os testes no ciclo de vida de nossos produtos. Abaixo descrevemos alguns casos de insucesso devido à ausência de teste. Em Junho de 1996, o primeiro lançamento do foguete Ariane 5 ( Ver Figura 1) da agência espacial européia falhou 37,5 segundos após sair do solo. Um erro de software levou o foguete a desviar da ascendente vertical e suas capacidades de auto-destruição foram ativadas. Figura 1- Exemplos de casos de insucesso 3

4 Symantec compensa 50 mil vítimas de atualização com falha na China. Cingapura - Companhia oferece extensão de licença do Norton sem custos aos afetados pelo update que tirava arquivos de sistema de uso. Mais de um mês após atualizar 50 mil PCs chineses com um update defeituoso, a Symantec decidiu compensar as vítimas. Em 18 de maio a empresa começou a distribuir o update problemático para o antivírus Norton, que classificou equivocadamente arquivos do sistema dos usuários como malwares e os colocou em quarentena, afetando o funcionamento do computador das vítimas e gerando uma onda de protestos na web. Quando uma famosa livraria abriu os negócios online, a compra de um número negativo de livros significava que o total da transação envolvida deveria retornar para o comprador. A equipe de desenvolvimento não tinha antecipado que alguém poderia solicitar a compra de um número negativo de livros e o código foi desenvolvido para permitir o reembolso pela equipe administrativa. No mês de abril de 2005 o site da rede americana de hotéis Holliday Inn deveria ter entrado no ar com uma promoção para quem se hospedasse na sua rede no estado da Flórida nos EUA de 98 dólares o casal. Por um erro de programação o valor que entrou no site foi de 0,98 dólares. Este erro ficou no ar por 24 horas, tempo suficiente para que pessoas fizessem as suas reservas. O hotel alegando que havia sido um erro, posteriormente cancelou todas essas reservas. Por decisão judicial, o hotel foi obrigado a honrar os seus compromissos. Isso custou ao Holliday Inn cerca de 500 mil dólares porque o analista de sistemas, achando que as alterações eram pequenas, preferiu correr o risco de colocar o site no ar sem um teste de aceitação, que custaria em torno de 50 dólares. Se ele tivesse feito uma análise de riscos, certamente não teria deixado de testar a aplicação. Diante desse contexto, podemos afirmar que o motivo pelo qual devemos testar um software é pelo simples motivo que o mesmo visa atender a uma demanda por questões de: Qualidade, Segurança, Economia, Negócio e Confiabilidade. 4

5 3. Benefícios Quais os reais benefícios do investimento em testes? Conforme afirmado em vários relatos de experiência e já percebido no mercado, os reais benefícios são a redução em 70% do índice de re-trabalho na correção de falhas em produção, redução em 50% do tempo de homologação de uma nova versão. Além disso, aumenta em aproximadamente 90% o índice de falhas detectadas antes da produção onde o custo é bem mais baixo, e aumenta a abrangência dos testes. Portanto, de uma forma geral, os maiores benefícios são (Ver Figura 2): Melhoria da qualidade do produto e do serviço; Identificação de defeitos para reduzir as falhas; Redução do custo de manutenção do software; Medição da qualidade através (Ex: número de defeitos encontrados, número de testes executados e percentual de cobertura do código pelos testes); Adequação às regras contratuais, requisitos legais e padrões industriais. Figura 2 Benefícios da prática de teste de software 5

6 4. Custo de teste no ciclo de vida do desenvolvimento de software Para analisar os impactos das falhas encontradas no software é necessário avaliar o impacto de quando os erros foram encontrados. Portanto, o impacto de se encontrar e consertar os defeitos aumenta consideravelmente ao longo do tempo. A regra 10 de Myers apresenta que o custo da correção de um defeito tende a aumentar quanto mais tarde ele for encontrado. Os defeitos encontrados nas fases iniciais do projeto de desenvolvimento do software são mais baratos do que aqueles encontrados na produção. Um estudo realizado observou que, quanto mais tempo levarmos para corrigir uma falha, mais custosa ela será. O gráfico apresentado tem como objetivo mostrar a proporção do aumento, onde, ainda na fase de levantamento de requisitos, o custo para correção é considerado muito baixo, praticamente zero. Na fase de desenvolvimento do sistema, o custo aumenta em 10 vezes comparado com a fase anterior. Já na fase de teste unitário e teste de integração, o custo é de 100 vezes o custo inicial. Enquanto que na fase do teste de sistema, o custo será de mil (1000) vezes. O teste de aceitação custará 10 mil e quando o software está em produção, estima-se que o custo para correção de uma falha é de 100 mil vezes o custo, se a mesma fosse ajustada na fase de levantamento de requisitos (ver figura 3). Figura 3 Custo do Teste 6

7 5. O Papel do Testador Diante dessas considerações, o testador atua para prevenir que as falhas sejam observadas no software quando ele já está em produção, como também para provocar, o quanto antes, a maior quantidade de falhas possível no software, para que as mesmas possam ser corrigidas e entregues ao cliente final. Portanto, o testador investigará se o produto está pronto para uso e quais são as possíveis ameaças que o mesmo apresenta. Além disso, a checagem dos processos de desenvolvimento também precisa ser realizada como forma de minimizar, através da garantia da qualidade, as falhas observadas no produto final. Figura 4 Papel do testador O papel do testador é executar as atividades centrais do esforço de teste, que envolve conduzir os testes necessários, além de registrar os resultados desses testes. Para desempenhar essa atividade é necessário: Identificar a abordagem de implementação mais apropriada para um dado teste; Implementar testes individuais; Configurar e executar os testes; Registrar os resultados e verificar a execução dos testes; Analisar erros de execução e recuperar-se deles; Avaliar um entregável com a intenção de encontrar defeitos. 7

8 O conhecimento e as habilidades do testador podem variar de acordo com os tipos de testes a serem executados, entretanto, geralmente o testador deve ter as seguintes habilidades: Conhecimento das abordagens e das técnicas de teste; Capacidade para diagnosticar e resolver problemas; Conhecimento do sistema ou do aplicativo em teste (desejável). Diante deste contexto, podemos afirmar que o testador através da execução dos testes visa adquirir confiança na qualidade através das informações que o teste provê, ou prevenir a ocorrência de falhas no ambiente de produção, pela detecção antecipada dos defeitos. 6. Definição do conceito de teste (Erro, Defeito e Falha) No que se refere às definições da disciplina de teste, vale ressaltar que não existe um conjunto universal de definições relativas ao teste de software. Alguns conceitos são importantes para o entendimento e possíveis adaptações dos processos, fazendo parte da base para a disciplina de teste. Nesse contexto, é imprescindível entender o conceito de erro, defeito e falha. Embora esses termos e definições (vide figura 5) estejam diretamente ligados ao processo de desenvolvimento de software, vários profissionais da área de TI desconhecem o seu significado e suas respectivas diferenças. a. Erro: Erro humano que produz um resultado incorreto b. Defeito: Manifestação de um erro no software c. Falha: pode ser considerada como um desvio apresentado pelo software, aquilo que é observado quando o mesmo está sendo executado. 8

9 Figura 5- Erro, Defeito e Falha Falha é um evento; defeito é um estado do software, causado por um erro. Os defeitos podem ser originados de vários fatores, tais como: Especificação de requisitos ambígua; Falha na gestão de mudanças dos requisitos; Profissionais que não possuem formação apropriada para construir os artefatos de software; Falha em declarar uma variável de entrada de dados; Projeto não delimitava tempo suficiente para que pudesse ser construída uma especificação detalhada. Os defeitos ocorrem no software porque os mesmos são escritos por pessoas, e por sua vez sabemos que as pessoas (profissionais) não conhecem e não dominam tudo. Entretanto, elas têm habilidades para tal responsabilidade, mas também não são perfeitas, o que nos leva a admitir que são suscetíveis de cometer erros. E por último, softwares são desenvolvidos sobre crescente pressão para entregá-los em prazos rigorosos, sem tempo para checar as atividades realizadas. 9

10 7. Padrões conceituais que são referências mundiais Aspectos Gerais das Normas/Padrões Padrões e Normas são criadas por grupos de profissionais e refletem um conhecimento coletivo. As duas maiores fontes de normas internacionais são: IEEE e ISO. Normas nacionais e de domínio específico são também importantes e disponíveis. Testadores devem estar atentos a normas que se aplicam ao seu ambiente ou contexto, sejam elas normas formais (internacionais, nacionais, ou de domínio específico) ou normas internas e práticas recomendadas. Como normas evoluem e mudam é necessário especificar a versão (data de publicação) da norma para garantir que a conformidade seja obtida. Quando uma referência a uma norma é especificada sem data ou versão, então a última versão é considerada como sendo referenciada. Utilidade de Normas/Padrões Normas/Padrões podem ser usadas como um instrumento para promover uma garantia de qualidade construtiva, tal que mantém foco em minimizar os defeitos introduzidos ao invés de encontrá-los através de teste. Coerência & Conflitos Algumas normas podem ser deficientes em coerência com outras normas, ou até fornecer definições conflitantes. É deixado a cargo dos usuários das normas determinarem a utilidade das diferentes normas em seu ambiente e contexto. Normas Internacionais ISO ISO [ significa International Standards Organization (alterado para International Organization for Standardization) e é formado por membros representando, para seu país, o corpo nacional representativo da padronização. Esse corpo internacional fomenta diversas normas úteis para testadores de software, tais como: 10

11 ISO 9126:1998, que atualmente é separada na seguinte norma e relatórios técnicos (technical reports - TR): ISO/IEC :2001 Engenharia de software Qualidade de produto Parte 1: Modelo de qualidade ISO/IEC TR :2003 Engenharia de software Qualidade de produto Parte 2: Métricas externas. ISO/IEC TR :2003 Engenharia de software Qualidade de Produto Parte 3: Métricas internas. ISO/IEC TR :2004 Engenharia de software Qualidade de produto Parte 4: Qualidade no uso de métricas. ISSO/IEC 12207:1995/Amd 2:2004 Sistemas e Engenharia de software Processos de Ciclo de Vida de Software. ISO/IEC :2003 Tecnologia da informação Avaliação de processo Parte 2: Realizando uma avaliação. Essa lista não é exaustiva; outras normas ISO podem ser aplicáveis ao contexto e ambiente de um testador. IEEE IEEE [ é o Institute of Electrical and Electronics Engineer, uma organização profissional com sede nos EUA. Existem representantes nacionais disponíveis em mais de uma centena de países. Essa organização fomenta diversas normas úteis para testadores de software, tais como: IEEE 610:1991 Norma IEEE de dicionário de computação. Uma compilação da norma IEEE de glossário de computação. IEEE 829:1998 Norma IEEE de documentação de teste de software. IEEE 1028:1997 Norma IEEE de revisão de software. IEEE 1044:1995 Guia IEEE para classificação de anomalias de software. Essa lista não é exaustiva; outras normas IEEE podem ser aplicáveis ao contexto e ambiente de um testador. 11

12 Normas Nacionais Muitos países têm suas normas específicas. Algumas dessas normas são aplicáveis e/ou úteis para o teste de software. Um exemplo seria a norma britânica BS e BS :1998 Teste de software. A BS é um glossário de termos de teste de software, juntamente com o seu parceiro BS componentes de teste de software. Além de também fornecerem uma descrição do processo de Teste de Componente. Portanto conclui-se que diversos padrões são considerados referencias na disciplina de testes. Porém, o mercado evidencia algumas normas mais que as outras (Ver figura 6). A referência que aborda a terminologia da engenharia de software, a IEEE 610, define que teste é o processo de operar um sistema ou componente através da observação dos resultados e avaliação de alguns aspectos de um determinado software. Já a IEEE 829, que trata de documentação, diz que teste é o processo de analisar o software para identificar as diferenças entre as condições existentes e as condições requeridas pelo cliente. No âmbito do padrão , que apresenta um vocabulário da disciplina, teste é o processo de exercitar o software para verificar se o mesmo satisfaz os requisitos e para detectar os erros no código. Figura 6 - Padrões 12

13 Diante dessas definições, vale ressaltar que todas as normas abordam o teste como um processo, através de uma atividade dinâmica, onde o software é executado para encontrar erros, e também é uma atividade estática, através da verificação das condições do sistema. 8. Processo de teste O processo de teste pode ser entendido como uma sequência de atividades executada para alcançar um objetivo específico (Ver Figura 7). Figura 7 Processo de teste O Processo de Testes de Software representa uma estruturação de fases, atividades, artefatos, papéis e responsabilidades que tem o objetivo de padronizar os trabalhos, além de maximizar a organização e monitoramento dos projetos de testes. Portanto, o objetivo do processo de teste é fornecer informação para garantir a qualidade do produto, decisões e processos para uma atividade de teste. Além disso, o processo de teste busca garantir que nenhum passo crítico do processo seja esquecido, ou seja, que todas as atividades sejam realizadas na ordem correta. O ISTQB define que Teste é um processo ao invés de uma atividade isolada, composta de um conjunto de atividades. 13

14 9. Abrangência na forma de condução O objetivo desta abrangência é assegurar que o software cumpra rigorosamente as suas especificações e atenda principalmente as necessidades do cliente. Diante desse contexto, o processo de teste pode ser tanto dinâmico como estático (Ver Figura 8): a. Dinâmico: Acontece quando o código é executado para demonstrar os resultados dos testes rodados. b. Estático: quando o teste é realizado antes da execução do código, através de técnicas de revisão, dentre as quais podemos citar a revisão informal, revisão técnica e a inspeção. Figura 8 Testes estáticos e dinâmicos 10. Atividade do processo de teste O propósito do processo de teste é fornecer informações para garantir a qualidade do produto, as decisões e os processos para uma missão de teste. As atividades são (Ver figura 9): Planejar e controlar o teste; Analisar e projetar o teste; Implementar e executar o teste; Avaliar o critério de saída e reportar; Atividades de fechamento do teste. 14

15 Figura 9 Atividades do processo de teste 11. Impacto na qualidade do produto Atualmente, podemos perceber que as organizações têm de produzir produtos e/ou serviços de qualidade não mais como uma estratégia de diferenciação de mercado, mas como uma condição de sobrevivência. O conceito de Qualidade foi inicialmente associado à definição de conformidade aos requisitos ou especificações do produto. Posteriormente, essa definição evoluiu para a busca da satisfação do cliente. Entretanto, a satisfação do cliente não é resultado apenas do grau de conformidade com os requisitos ou especificações, mas também de outros fatores associados, tais como: prazo, condições de pagamento, atendimento, pós-venda, flexibilidade, dentre outros fatores. Focando essa realidade foi possível perceber que a qualidade era fundamental no posicionamento estratégico da empresa perante o mercado. Além disso, logo em seguida surgiu o termo Qualidade Total que representa a busca da satisfação, não somente do cliente, mas de toda a organização que a compõe, buscando a excelência organizacional da empresa. A qualidade, conforme Crosby, está associada à idéia de zero defeito e de fazer certo da primeira vez. Já vimos (em O que é qualidade ) que para ele a qualidade significa conformidade com as especificações, e estas especificações variam para cada organização, conforme estas percebem as necessidades de seus clientes. No seu método não existe um padrão de tolerância a meta real é exatamente zero defeito. Já o autor Juran diz que Qualidade é adequação ao uso, onde a adequação é definida pelo consumidor mesmo quando ele deseja fazer algo fora do que o fabricante imaginou. 15

16 E não menos importante, referindo-se ao contexto da definição de qualidade, Deming frequentemente se referia ao efeito, e não ao conceito da qualidade. Para ele, os custos caem e a produtividade sobe, conforme a melhoria da qualidade é alcançada por meio de melhor gestão. A busca da qualidade é um dos principais objetivos da Engenharia de Software e muitos métodos, técnicas e ferramentas são desenvolvidos para apoiar a produção com qualidade. Atualmente tem-se dado grande importância ao processo de teste como forma de se garantir um software de melhor qualidade. As atividades de teste impactam diretamente na qualidade do produto final, através da avaliação das especificações e conformidade com o software entregue. Além disso, a adequação ao uso para atender às necessidades dos usuários e, consequentemente, atendimento às expectativas do cliente. As especificações devem refletir as necessidades levantadas, que são importantes critérios para definir a qualidade do produto em questão. 12. Teste como processo de suporte Teste é uma atividade de garantia da qualidade comparado a um processo de suporte. Teste é uma atividade que consideramos como recursiva, haja vista que os seus produtos gerados podem ser testados e analisados quanto a sua qualidade. Além de estar relacionado com a elaboração da documentação técnica, quando tudo que é produzido é factível de ser analisado pela garantia da qualidade, através de teste estático e suas atividades de revisão. Teste também faz interface com a atividade de manutenção, onde o software é entregue e possivelmente irá gerar correções e novas funcionalidades. Além disso, o teste é importante para garantir o correto funcionamento do sistema em produção. Alguns exemplos de processos de suporte executados durante todo o processo de desenvolvimento que fazem interface com o processo de teste (Ver Figura 10): Garantia da qualidade Gerência de projetos Gerência de configuração 16

17 Figura 10 Teste como processo de suporte 13. Fases da garantia da qualidade A garantia da qualidade é composta por 4 atividades. Primeiramente, os critérios de qualidade precisam ser definidos, que são declarações sobre o nível de qualidade a ser alcançado no software. Eles dependem da necessidade do negócio e tipo de produto em questão. A partir da definição dos critérios, existem duas atividades para averiguar se os critérios de qualidade foram alcançados no projeto, que é a validade e a verificação do software. E, finalmente, a consolidação dos resultados obtidos através de relatórios e indicadores de qualidade. Vale ressaltar que o teste é uma atividade que faz parte da garantia da qualidade, através de (Ver Figura 11): a. Definição do critério de qualidade b. Validação c. Verificação d. Relatório de qualidade Figura 11 Fases da garantia da qualidade 17

18 14. Validação e Verificação A Validação e a Verificação são conceitos de grande importância para a disciplina de teste, onde Validação é a avaliação da veracidade do produto baseado nas necessidades e requisitos definidos pelo cliente. Devemos, no decorrer do processo, questionar se estamos desenvolvendo o produto correto e se o sistema está de acordo com a especificação definida. A Verificação, por sua vez, é a avaliação se o objeto foi desenvolvido da maneira prevista, onde devemos nos questionar se estamos desenvolvendo o produto corretamente. Para isso existe diversas técnicas como, por exemplo, a inspeção e revisão(ver figura 12). Figura 12 Validação e Verificação A Validação e Verificação asseguram que o software cumpra com suas especificações e atenda às necessidades dos usuários. O processo de teste é dividido em duas grandes áreas: A estrutura do modelo V é uma aproximação do processo de testes que pode ser integrada com todo a processo de desenvolvimento. O modelo V representa o desenvolvimento versus o teste. O modelo V focaliza-se em testar durante todo o ciclo de desenvolvimento para conseguir uma detecção adiantada dos erros. 18