Processo De Teste De Software

Processo de Teste de Software

O teste do software é um processo realizado pelo testador de software que permeia outros processos da Engenharia de Software, e envolve ações que vão do levantamento de requisitos (necessidades) até a execução do teste propriamente dito. O objetivo, por paradoxal que pareça, é encontrar defeitos nos produtos, para que estes possam ser corrigidos pela equipe de programadores, antes da entrega final. A maioria das pessoas pensa que o teste de software serve para demonstrar o correto funcionamento de um programa, quando na verdade ele é utilizado como um processo da engenharia de software para encontrar defeitos.

O processo de teste de software é voltado para o alcance de um nível de qualidade de produto, que durante o processo de desenvolvimento de software muda conforme avanço das atividades - requisitos, protótipos, modelo de dados lógico, modelo de dados físico, código-fonte, módulos funcionais e finalmente um sistema.

O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou mesmo de uma maneira formal. Existem atualmente várias definições para esse conceito. De uma forma simples, testar um software significa verificar através de uma execução controlada se o seu comportamento corre de acordo com o especificado. O objetivo principal desta tarefa é encontrar o número máximo de erros dispondo do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos.

Introdução

Não se pode garantir que todos os programas funcionariam corretamente, sem a presença de erros humanos, visto que os mesmos muitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a complexidade.

Falhas podem ser originadas por diversos motivos, como os listados abaixo:

• A especificação pode estar errada ou incompleta.
  
  
  
  
  
• A especificação pode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software.
  
  
  
  
  
• Talvez a base de dados esteja organizada de forma que não seja permitido distinguir os tipos de usuário.
  
  
  
  
  
• Pode ser que haja um erro no algoritmo de controle dos usuários
  
  
  
  
  
• Pode ser que haja erros no código, o algoritmo pode estar implementado de forma errada ou incompleta.
  
  
  
  
  

Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema.

O teste de software pode ser visto como uma parcela do processo de qualidade de software. A qualidade da aplicação pode, e normalmente, varia significativamente de sistema para sistema, mas os atributos qualitativos previstos na norma ISO 9126 que são: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

Um desenvolvimento organizado de software tem como premissa uma metodologia de trabalho. Esta deve ter como base conceitos que visem a construção de um produto de software de forma eficaz. Dentro desta metodologia estão definidos os passos necessários para chegar ao produto final esperado. Esse é o campo de estudos da Qualidade de Software, uma sub-área da Engenharia de Software.

Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software espera-se um produto final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de desenvolvimento.

Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem ter uma metodologia de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porém, além de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais pressão por parte dos clientes para que o produto seja entregue num curto período de tempo. Este fato pode fazer com que uma sólida metodologia de trabalho acabe por se desequilibrar.

Independentemente da metodologia de trabalho empregada no desenvolvimento de um software, para que se obtenha um produto final com certo nível de qualidade é imprescindível a melhoria dos processos de engenharia de software.

Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como eficientes, como por exemplo, os SW-CMM, SE-CMM, ISO 15504 e o mais conhecido CMMI.

Outro fator com grande influência sobre a qualidade do software a ser produzido é o que diz respeito aos testes que serão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma disciplina dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e financeiros.

Técnicas de Teste

Atualmente existem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemas orientados a objeto. Apesar de os paradigmas de desenvolvimento ser completamente diferentes, o objetivo principal destas técnicas continua a ser o mesmo: encontrar falhas no software. Abaixo estão descritas as três técnicas mais conhecidas.

Caixa-Branca

Técnica de teste, também chamada de Teste Estrutural, que avalia o comportamento interno do componente de software. 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. Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem à construção do componente de software, cabendo, portanto avaliação de mais aspectos que os citados anteriormente. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações originadas por estruturas de condições são testadas. Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de classes de teste (test cases) para testar classes ou métodos desenvolvidos em Java. Também se enquadram nessa técnica testes manuais ou testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação reconhecidas pelo mercado de software. A aderência a padrões e boas práticas visa principalmente a diminuição da possibilidade de erros de codificação e a busca de utilização de comandos que gerem a melhor performance de execução possível. Apesar de muitos desenvolvedores alegarem que não haverá ganhos perceptíveis com essa técnica de teste aplicada sobre unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executado milhares ou milhões de vezes em intervalos de tempo pequenos. É na realidade de produção que a soma dos aparentes pequenos tempos de execução e consumo de memória de cada programa poderá levar o software a deixar de atender aos objetivos esperados. A técnica de teste de Caixa-Branca é recomendada para as fases de Teste da Unidade e Teste da Integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o código-fonte produzido.

Caixa-Preta

Técnica de teste, também chamado de Teste Funcional, em que o componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido.

O componente de software a ser testado pode ser um método, uma função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. A técnica de teste de Caixa-Preta é aplicável a todas as fases de teste - fase de teste de unidade (ou teste unitário), fase de teste de integração, fase de teste de sistema e fase de teste de aceitação.

A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações de teste). A aplicação combinada de outra técnica - Técnica de Particionamento de Equivalência (ou uso de Classes de Equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das classes de equivalência identificadas, o testador irá construir casos de teste que atuem nos limites superiores e inferiores destas classes, de forma que um número mínimo de casos de teste permita a maior cobertura de teste possível..

Outras Técnicas

Outras técnicas de teste podem e devem ser utilizadas de acordo com necessidades de negócio ou restrições tecnológicas. Destacam-se as seguintes técnicas: Teste de Performance, Teste de Usabilidade, Teste de Carga, Teste de Stress, Teste de Confiabilidade e Teste de Recuperação. Alguns autores chegam a definir uma técnica de Teste Caixa Cinza, que seria um mesclado do uso das técnicas de Caixa Preta e Caixa Branca, mas, como toda execução de trabalho relacionado à atividade de teste utilizará simultaneamente mais de uma técnica de teste, é recomendável que se fixem os conceitos primários de cada técnica.

Fases de Teste
Teste de Unidade

Também conhecida como Teste Unitário. É a fase do processo de teste em que se testam as menores unidades de software desenvolvidas ( pequenas partes ou unidades do sistema). O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.

Teste de Integração

Na fase de teste de integração o objetivo é encontrar falhas provenientes da integração interna dos componentes de um sistema. Geralmente os tipos de falhas encontradas são de envio e recebimento de dados. Por exemplo, um objeto A pode estar aguardando o retorno de um valor X ao executar um método do objeto B, porém este objeto B pode retornar um valor Y, desta forma gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério do gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construído..

Teste de Sistema

Na fase de Teste de Sistema o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca de falhas. Os testes são executados em condições similares - de ambiente, interfaces sistêmicas e massas de dados - àquelas que um usuário utilizará no seu dia-a-dia de manipulação do sistema. De acordo com a política de uma organização podem ser utilizadas condições reais de ambiente, interfaces sistêmicas e massas de dados.

Teste de Aceitação

Fase de Teste em que o teste é conduzido por usuários finais do sistema. Os testes são realizados, geralmente, por um grupo restrito 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. Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais. Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.

Teste de Operação

Fase de Teste em que o teste é conduzido pelos administradores do ambiente final onde o sistema ou software entrará em ambiente produtivo. Vale ressaltar que essa fase é aplicável somente a sistemas de informação próprios de uma organização, cujo acesso pode ser feito interna e/ou externamente a essa organização. Nessa fase de teste devem ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve testes de instalação, simulações com backup e restore das bases de dados, etc. Em alguns casos um sistema entrará em produção para substituir outro e é necessário garantir que o novo sistema continuará garantindo o suporte ao negócio.

Teste de Regressão

Teste de Regressão é uma fase de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a utilização de ferramentas de automação de testes, de forma que, sobre a nova versão ou ciclo de teste, todos os testes anteriores possam ser reexecutados com maior agilidade.

Testes Alpha, Beta e Gama.

Em casos especiais de processos de desenvolvimento de software - Sistemas Operacionais, Sistemas Gerenciadores de Bancos de Dados (SGBD), e outros softwares comerciais disponibilizados no mercado nacional e internacional - os testes requerem fases também especiais antes do produto ser disponibilizado a todos os usuários.

O período entre o término do desenvolvimento e a entrega é conhecido como fase alpha e os testes executados nesse período, como testes alpha. PRESSMAN afirma que o teste alpha é conduzido pelo cliente no ambiente do desenvolvedor, com este “olhando sobre o ombro” do usuário e registrando erros e problemas de uso.

Completada a fase alpha de testes, são lançadas a grupos restritos de usuários, versões de teste do sistema denominadas versões beta. O Teste Beta também é um teste de aceitação voltado para softwares cuja distribuição atingirá grande número de usuários de uma ou várias empresas compradoras. PRESSMAN afirma que o teste beta é conduzido em uma ou mais instalações do cliente, pelo usuário final do software. Diferente do teste alpha, o desenvolvedor geralmente não está presente. Conseqüentemente, o teste beta é uma aplicação “ao vivo” do software num ambiente que não pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ou imaginários) que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. Com o resultado dos problemas relatados durante os testes beta, os engenheiros de software fazem modificações e depois se preparam para liberar o produto de software para toda a base de clientes.

Os testes Gama não são propriamente testes de software. A comunidade do teste de software usa este termo de forma sarcástica referindo-se aos produtos que são mal testados e são entregues aos usuários ("end-users") para que estes encontrem os defeitos já em fase de produção.

Quando Devemos Testar?

Os testes realizados em cada fase do ciclo de desenvolvimento de software permitem que um número maior de erros seja descoberto antecipadamente, evitando a migração destes para as fases seguintes.

Desta forma, a reposta “Quando devemos testar?” torna-se simples. Teste o mais cedo possível e tantas vezes quanto necessário. A cultura do teste cria um ambiente favorável para detecção de erros e identificá-los rapidamente é o objetivo dos profissionais de testes.

Onde estão os erros?

Os erros ocorrem em todas as fases do processo de desenvolvimento de software. Porém, estudos demonstram que a maior incidência dos erros está concentrada nas fases iniciais do processo de desenvolvimento. Muitos dos erros identificados no produto final são provenientes a má especificação e entendimento sobre os objetivos a serem alcançados.

Se nosso objetivo é reduzir, ao máximo, o nível de erros dentro do processo de desenvolvimento de software, devemos nos concentrar nas atividades iniciais do processo. Desta forma, estaríamos identificando prematuramente os erros impedindo que estes migrassem para outras fases.

Entendendo o Processo de teste

Não é possível conceber um processo de teste de software sem integrá-lo com o ciclo de desenvolvimento de software. Um bom processo de teste é aquele que cria uma relação de “um-para-um” entre as fases de desenvolvimento e testes. Esta relação bilateral promove a colaboração entre as áreas e reforça a idéia do objetivo comum.

Modelo de Processo

O Processo de Teste de Software esta decomposto em fases. Cada fase tem uma numeração indicando a seqüência de execução dos testes a serem aplicados.