Testes na Produção de Software

1. Introdução

É latente a necessidade de se gerenciar de formar eficiente e eficaz os processos de negócios e ou organizacionais de uma corporação (pública ou privada), a fim de se diminuir o tempo de resposta do mesmo.

Além disso, a maior utilização de sistemas informatizados como ferramentas para auxiliar, ou até mesmo gerenciar tais processos, torna imprescindível que esses sistemas sejam confiáveis, ou seja, que esses possuam uma margem de erro mínima, surgindo assim a necessidade de um Processo de Garantia de Qualidade dentro do Projeto de um Software.

Essa necessidade fez surgir padrões de processos de criação de softwares, os quais se preocupam com a qualidade final do produto a ser colocado no mercado. Dentro desses padrões, foram adotadas medidas, que visam sempre aumentar a qualidade de um software, e nesse ponto, tornou-se inevitável a introdução de fases de testes dentro da criação do Software.

Todavia, ressaltamos que a tarefa de efetuar testes em software foi considerada secundária por muito tempo, e que geralmente era vista com o um castigo para o programador, ou como uma tarefa onde não se deveria gastar muito com tempo e investimentos. O tema esteve relegado a segundo plano, e, até alguns anos atrás não se encontrava muita literatura sobre o assunto.

Um exemplo disso é a citação abaixo, de Beizer (Beizer, 1990):

Há um mito segundo o qual, se fôssemos realmente bons para programar, não haveria “bugs” a ser procurados. Se pudéssemos realmente nos concentrar, se todos usassem programação estruturada, projeto “top-down”, tabelas de decisão, se tivéssemos as balas de prata certas, então não haveria “bugs”.

Como fora visto isso realmente é um mito, porque os programas possuem um grande número de estados com fórmulas complexas, atividades e algoritmos. Também devemos considerar o tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo, o que só aumenta ainda mais a complexidade do mesmo. Assim, a presença de falhas é inevitável, e podemos afirmar que uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema.

2. Qualidade de um software

Pode-se garantir a qualidade do software através da definição e normatização de processos de desenvolvimento. Apesar dos modelos aplicados na garantia da qualidade de software atuar principalmente no processo, o principal objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente.

A fase de testes de software pode ser visto como uma parcela do processo de qualidade de software. Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software espera-se um produto final que melhor, que agrade tanto aos clientes quanto ao próprio fornecedor.

Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por entidades internacional e nacionalmente 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, CMMI e o MPS.Br.

3. Testes de software

Como conceito de testes de softwares o que Myers diz que: O teste consiste em executar o programa com a intenção de encontrar erros (bugs) (Myers, 1979).

Dentre os principais objetivos do processo de teste: (Beizer, 90)

• Foco na prevenção de erros (como outras fases da garantia da qualidade de software);
• Descobrir sintomas causados por erros;
• Fornecer diagnósticos claros para que os erros sejam facilmente corrigidos

Naturalmente o assunto não é tão simples assim, pois:

• Erros nem sempre são óbvios;
• Erros diferentes podem ter a mesma manifestação;
• Saber quem um programa não esta correto não necessariamente é saber como corrigir o erro.

Teste e depuração são conceitos diferentes, enquanto o primeiro mostrar que o software tem erros, a depuração encontrar a causa do erro detectado no teste, para então se projetar e implementar as modificações no programa para correção do erro.

Para poder realizar testes com eficácia é necessário definir um processo de teste de software, dentro do projeto. As seguintes etapas podem ser seguidas:

• Definir os processos
• Medir os processos
• Controlar os processos (garantir que a variabilidade é estável e os resultados previsíveis)
• Melhorar os processos

3.1. Técnicas de Testes

Existem muitas maneiras de se testar um software. Dentre ela podemos ressaltar: Testes Estruturais e Funcionais;

3.1.1. Teste Estrutural

Técnica também conhecida como “Caixa Branca”, baseia-se no teste dos caminhos lógicos através do software, fornecendo casos de teste que põem a prova conjuntos específicos de condições e/ou garante que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez.

Essa técnica visa o código-fonte do software, sendo 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

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.

3.1.2. Teste Funcional

Técnica também conhecida de “Caixa-Preta”, é utilizada para demonstrar que as funções do software são operacionais, ou seja, que a entrada é adequadamente aceita e a saída é corretamente produzida, assim a integridade das informações externas é mantida.

Considera-s que essa técnica é uma atividade complementar aos testes estruturais, com a finalidade de descobrir tipos/classes de erros, como:

É aplicável a todas as fases de teste: fase de teste de unidade, fase de teste de integração, fase de teste de sistema e fase de teste de aceitação.

3.1.3. 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.

3.2. Fases de Teste

3.2.1. Teste de Unidade

O teste unitário ou de unidade é uma modalidade de testes que se concentra na verificação da menor unidade do projeto de software. É realizado o teste de uma unidade lógica, com uso de dados suficientes para se testar apenas a lógica da unidade em questão. Em sistemas construídos com uso de linguagens orientadas a objetos, essa unidade pode ser identificada como um método, uma classe ou mesmo um objeto.

Características:

• Deve responder a seguinte pergunta: “Será que codifiquei direito?”
• Deve ser escrito pelo mesmo programador que desenvolveu o código a ser testado.
• Serve como documentação do sistema
• Essencial para análise de desempenho

3.2.2. 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. É executado para garantir que os componentes do modelo de implementação, funcionem corretamente quando combinados. O teste de integração também detecta imperfeições ou erros nas especificações das interfaces.

Características:

• Deve responder a pergunta: "Tudo se encaixa?".
• Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integração entre sistemas).

3.2.3. 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. É criado e executado pelo líder do projeto.

Essa fase é importante, pois, após serem feitos esses testes, o sistema está pronto e os requisitos de qualidade foram atingidos.

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.

Características:

• Deve responder a pergunta: "Esse software faz o que o usuário quer?"
• Comparar o sistema com seus objetivos originais
• Enfatizar a análise do comportamento da estrutura hierárquica de chamadas de módulos
• Fase mais complexa, devido à quantidade de informações envolvidas

3.2.4. Teste de Aceitação

Fase de Teste em que o teste é conduzido por 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.

É quando é feito a validação de um software, com o uso de dados ou cenários especificados ou reais. Podemos incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.

Características:

• Deve responder a pergunta: “É isso que eu (usuário) quero?”
• A validação é bem sucedida quando o software funciona de uma maneira razoavelmente esperada pelo cliente. Pressman, 1995
• Expectativas dos clientes documentadas
• Uso da documentação do usuário

3.2.5. Teste de Operação

Fase de Teste em que o teste é conduzido pelos administradores do ambiente final onde o sistema ou software entrará em funcionamento. Nessa fase de teste devem ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida. 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.

Características:

• Deve responder a pergunta: “Foi isso o que eu pedi?”
• Envolve testes de instalação, simulações com backup e restore das bases de dados, etc.

3.2.6. 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. É um teste seletivo, de um software que foi modificado ou de iterações anteriores. Tem como propósito garantir que qualquer falha tenha sido reparada e que nenhuma operação que funcionava anteriormente tenha falhado após os reparos, ou seja, que as novas características adicionadas não criaram problemas com as versões anteriores ou com outros sistemas

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.

Características:

• Deve responder a pergunta: “Continua tudo funcionando como antes?”
• Necessário para assegurar que modificações no programa não causaram novos erros
• Baseado em arquivo de 'log'

3.3. Casos Especiais

Em casos especiais como criação de Sistemas Operacionais, Sistemas Gerenciadores de Bancos de Dados (SGBD), e outros softwares comerciais disponibilizados no mercado nacional e internacional, os testes requerem fases 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. Roger 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 (Pressman, 2006).

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 real 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.

Há também quem fale em TESTE GAMA, porém, esses não são propriamente testes de software. Usa-se este termo de forma irônica referindo-se aos produtos que são má qualidade, os quais são entregues aos usuários finais, para que estes encontrem os defeitos já em fase de produção.

4. Recursos Humanos

Os recursos humanos para a formação de uma equipe de testes dependerá muito da estrutura organizacional da corporação desenvolvedora de software, porém, as pessoas responsáveis pelo exercício da atividade de teste deve possuir no mínimo as seguintes características, a fim de serem capazes de realizar com a máxima eficiência os testes necessários em um produto de software: paciência; perseverança; organização, firmeza de opinião, espírito investigador, capacidade de trabalhar em equipe e diplomacia

Uma equipe ideal de testes seria formada por:

• Gerente de Testes: Pessoa responsável pela liderança de um projeto de teste específico, normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou uma manutenção.
• Arquiteto de Teste: É o responsável pelo levantamento de necessidades relacionadas à montagem da infra-estrutura de teste, incluindo-se o ambiente de teste, a arquitetura de solução, as restrições tecnológicas, as ferramentas de teste. Também responsável pela liderança técnica do trabalho de teste e pela comunicação entre a equipe de teste e a equipe de projeto (ou equipe de desenvolvimento).
• Analista de Teste: É o responsável pela operacionalização do processo de teste. Deve seguir as orientações do gerente de teste e/ou do arquiteto de teste para detalhar a forma de execução dos testes e as condições de teste necessárias. Também deve focar seu trabalho nas técnicas de teste adequadas à fase de teste trabalhada.
• Analista de Ambiente: É o técnico responsável pela configuração do ambiente de teste e pela aplicação das ferramentas necessárias para tal. Esse profissional deve ser especializado em arquiteturas de solução e nos sistemas operacionais e softwares de infra-estrutura que regem o ambiente. Ele será responsável por tornar disponível o ambiente de teste.
• Testador: É o técnico responsável pela execução de teste. Ele deve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e evidenciar os resultados de execução. Em casos de execuções de teste mal-sucedidas, esse profissional pode também registrar ocorrências de teste (na maioria das vezes, bugs) em canais através dos quais os desenvolvedores tomarão conhecimento das mesmas e tomarão as providências de correção ou de esclarecimentos.
• Automatizador de Teste: É o responsável pela automação de situações de teste em ferramentas. Ele deve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e automatizar a execução desses testes na ferramenta utilizada. Normalmente são gerados scripts de teste que permitam a execução de ciclos de teste sempre que se julgar necessário, desde é claro, que sejam garantidas as mesmas condições iniciais do ciclo de teste ( valores de dados, estados dos dados, estados do ambiente, etc.).

Observamos que uma pessoa pode acumular mais de um dos papéis citados acima, de acordo com características e restrições de projetos de desenvolvimento de software nas quais estejam inseridas.

5. Ferramentas de teste

Uso de ferramentas automatizadas de teste que apóiam o processo de teste, reduzem as falhas introduzidas pela intervenção humana, aumentam a produtividade, facilitam estudos comparativos entre critérios.

6. Conclusão

Diante dos fatos apresentados, mostra-se patente que o ato de desenvolver produtos de software com qualidade é uma tarefa formada por um conjunto de ações nada triviais e que envolvem uma diversidade de profissionais muito grandes, tais como gerentes de projetos, analistas de sistemas, equipes de desenvolvimento e principalmente equipes de testes. O papel das equipes de testes é indiscutivelmente imprescindível na obtenção da qualidade.

As atividades de testar um software englobam habilidades como lógica, criatividade, tato, clareza conhecimento da aplicação, conhecimento de métodos de teste, conhecimento de regras do negócio, além de assumir o papel do usuário, entre outras. Portanto, a adoção de práticas de testes nas empresas que desenvolvem softwares, comprova e minimiza erros e principalmente o retrabalho, corroborando com o compromisso de cumprimento prazos e qualidade do produto final proposto.

Citamos Beizer novamente, como reflexão a atividade de Testes, na produção de Softwares: "Teste cedo e freqüentemente" (Beizer, 90)