GARANTIA DE QUALIDADE DE SOFTWARE COM ÊNFASE EM TESTES DE SOFTWARE*
Flávia Perin**
Orientador: Prof. José Mário Frasson Scafi***
*Trabalho de Graduação
**Graduando em tecnólogo em Processamento de Dados pela Faculdade de Tecnologia de Americana
***Prof. da Faculdade de Tecnologia de Americana do Curso de Processamento de Dados
Resumo
Esta Monografia tem por objetivo detalhar como é aplicada a qualidade no processo de desenvolvimento de um
software, desde o seu surgimento como disciplina na Engenharia de Software até a sua evolução com o
aprimoramento das atividades de teste. No início do desenvolvimento de softwares, os testes tinham por objetivo
principal mostrar que o produto desenvolvido estava livre de erros, ou seja, em conformidade com os requisitos
especificados no início do projeto. Com a evolução no processo de qualidade de software, os testes passaram a ter
como objetivo principal o oposto de quando se iniciou: identificar o maior número possível de erros, a fim de tornar
o software confiável e de acordo com as especificações definidas no projeto. Este trabalho abordará conceitos de
qualidade, estratégias de testes e quais são os momentos adequados para se utilizar cada uma delas. Também tratará
dos profissionais responsáveis pela execução das atividades de testes, e todo o processo de documentação envolvido,
com a finalidade de adequar o projeto a cada uma das etapas envolvidas, resultando em um produto que se comporte
de acordo com o que foi especificado.
Introdução
A Engenharia de Software surgiu como uma disciplina cujo objetivo é aumentar a qualidade do software por
meio de metodologias, e conseqüentemente aumentar a maturidade das organizações ao adotarem estes métodos.
Com a evolução da Engenharia de Software, surgiu a necessidade de se implantar um processo de qualidade de
software, com o objetivo de gerenciar o nível de qualidade do produto e do processo de desenvolvimento. Na busca
pela adequação e conformidade dos softwares com seus requisitos iniciais, uma vertente teve sua importância
destacada e evolui constantemente: os testes de software. O processo de testes possui várias estratégias e devem ser
aplicadas em todas as etapas de desenvolvimento de um software, cada uma em um momento específico que busca
atingir um determinado objetivo. O teste de software envolve um conjunto de elementos que envolve desde uma
equipe capacitada para a execução das atividades, ferramentas utilizadas de acordo com a abordagem de teste e
documentação que especifica as conformidades, não conformidades e resultados dos comportamentos de testes. O
objetivo é gerar softwares confiáveis que atendam as especificações dos clientes, independente da complexidade do
projeto. A seguir, serão apresentadas a disposição dos capítulos e uma breve abordagem dos mesmos:
2 O PROPÓSITO DO TESTE: este capítulo abordará a Engenharia de Software, desde seu surgimento como
disciplina, sua evolução e o processo de testes no desenvolvimento do software. Tratará também da importância do
software e quais são suas limitações.
3 QUALIDADE DE SOFTWARE VERSUS TESTE DE SOFTWARE:
neste capítulo será abordado
os benefícios de um processo de qualidade e em que momento a qualidade é aplicada, incluindo custos na aplicação
desse processo e onde os erros são encontrados.
4 ESTRATÉGIAS DE TESTE: este capítulo define as fases de teste que um profissional deve ter me mente,
assim como estratégias estruturais e funcionais de teste de software, em quais momentos devem ser aplicadas e quais
são os objetivos dos mesmos.
5 AVALIAÇÃO DA APLICAÇÃO DOS TESTES: este capítulo trata das falhas no teste de softwares, e das
diferenças entre testes manuais e automatizados.
6 CONCLUSÃO: aborda o encerramento do trabalho com opiniões acerca do assunto desenvolvido e qual foi
o acréscimo obtido com o estudo do tema.
O propósito do teste
Importância dos testes de software
O desenvolvimento de sistemas de software permite que haja uma grande injeção de falhas humanas. Os
erros podem surgir logo no começo do processo, em que objetivos podem estar errados ou mal especificados,
transportando os erros para as fases posteriores. Devido à falha de comunicação humana com perfeição, o
desenvolvimento de software é acompanhado por uma atividade de garantia de qualidade.
A atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a
última revisão de especificações, projeto e codificação. O destaque crescente do software como elemento de sistema
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
e os custos envolvidos associados às falhas de software são forças propulsoras para uma atividade de teste cuidadosa
e bem planejada. Não é incomum que uma organização de software gaste 40% do esforço de projeto total em teste.
Atividades que exponham a vida de seres humanos em risco, como por exemplo sistemas para aviões, ou
monitoração de reatores nucleares, podem fazer com que os testes de software custem de três a cinco vezes mais que
todos os outros passos de engenharia de software juntos [BAR02].
Por outro lado, [BEI90] acredita que um debugger gasta muito tempo testando causas hipotéticas de
sintomas de não conformidade do software. Se nós incluirmos todo o trabalho de teste, de qualquer parte do
desenvolvimento de um software, o total de tempo gastos em testes pode variar entre 30% e 90% do tempo total.
Porém, se contarmos apenas os testes formais, conduzidos por um independente grupo de teste, este tempo varia
entre 10% e 25% do tempo total.Segundo [BEI90], as estatísticas mostram que o mesmo com o uso de boas práticas
de programação, existirão de um a três bugs a cada cem comandos. Uma taxa de 10% de erros significa as práticas de
programação ainda devem ser melhoradas. Vale lembrar que esta taxa de tolerância é variável, pois vários fatores
devem ser levados em consideração, inclusive a complexidade do código.
Durante as fases de definição e desenvolvimento, o engenheiro tenta construir o software, partindo de um
conceito abstrato para uma implementação tangível. O próximo passo, é a fase de testes. O engenheiro cria uma série
de casos de teste que têm a intenção de pôr à prova o software que ele construiu, ou seja, os casos de teste têm por
objetivo descobrir falhas e inconformidades no sistema que ele criou. De fato, a atividade de teste é um passo do
processo de engenharia de software que poderia ser visto como destrutivo, em vez de construtivo.
Os desenvolvedores de software são, por sua própria natureza, pessoas construtivas. A atividade de teste
exige que o desenvolvedor descarte noções preconcebidas de “corretitude” do software que ele acabou de
desenvolver e supere um conflito de interesses que ocorre quando erros são descobertos. A atividade de teste não
deve promover culpa ou ser considerada destrutiva.
De acordo com [BAR02 apud MYE79] uma série de regras podem servir como objetivos de teste:
1.
2.
3.
A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro.
Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto.
Um teste bem-sucedido é aquele que revela um erro ainda não descoberto.
Estes objetivos implicam em uma mudança drástica de ponto de vista. Eles apontam contrariedade ao ponto de
vista comumente defendido de que um teste bem-sucedido é aquele em que nenhum erro é encontrado. O objetivo é
projetar testes que descubram sistematicamente diferentes classes de erros e façam-no com uma quantidade de tempo
e esforço mínimos.
Se a atividade de teste for conduzida com sucesso (de acordo com o objetivo anteriormente estabelecido), ela
descobrirá erros no software. Como um benefício secundário, a atividade de teste demonstra que as funções de
software aparentemente estão trabalhando de acordo com as especificações, que os requisitos de desempenho
aparentemente foram cumpridos. Mas há uma coisa que a atividade de teste não pode fazer: mostrar a ausência de
bugs; ela só pode mostrar se defeitos de software estão presentes. É importante ter essa declaração em mente quando
a atividade de teste estiver sendo realizada.
Engenharia e testes de software: surgimento e evolução
No princípio do desenvolvimento de software, a atividade de testes era considerada uma tarefa simples, que
consistia em fazer verificações no código-fonte e corrigir problemas conhecidos e portanto, superficiais. Estas
tarefas eram realizadas pelos próprios desenvolvedores, pois não havia recursos especializados dedicados a essa
atividade. Desta forma, os testes eram realizados sem a intenção de descobrir erros, já que os programadores,
além de estarem “viciados” no seu próprio código-fonte, tendem a achar que seu trabalho está livre de erros.
Outro fator negativo da realização de testes pelos desenvolvedores, é que os mesmos eram realizados
tardiamente, quando o produto já estava prestes a ser finalizado. O que ocorria então, é que todos os erros e
inconformidades das etapas anteriores, eram transportados para a fase de desenvolvimento, para serem corrigidos
em uma só etapa. É notável que muitos dos erros ainda assim seriam deixados para trás e seriam percebidos
posteriormente pelos clientes. Apesar desta situação estar associada a uma má prática de desenvolvimento de
software, ela ainda continua presente em muitas organizações nos dias de hoje [BAR02].
Em 1957, o conceito de Teste de Software conseguiu ampliar seus valores e se tornou um processo de
detecção de erros de software, porém alguns paradigmas ainda eram mantidos, como por exemplo, os testes serem
realizados somente no final do processo de desenvolvimento.
No início da década de 1970, o processo de desenvolvimento de software passou a ser abordado de uma
maneira mais profunda, com a engenharia de software sendo adotada como modelo para as universidades e
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
organizações, porém os conceitos acerca do que era realmente teste de software, estavam um pouco difusos. Somente
em 1972 ocorreu a primeira conferência formal sobre testes na Universidade da Carolina do Norte.
Em 1979, [BAR02 apud MYE79] produziu um dos primeiros trabalhos mais profundos e completos sobre
um processo de teste. Segundo ele, teste era um processo de trabalho com a intenção de encontrar erros. Sua
premissa era a de que se o objetivo do teste fosse apenas provar a boa funcionalidade de um aplicativo, seriam
encontrados poucos defeitos, uma vez que toda a energia do processo de testes seria direcionada apenas na
comprovação deste fato. Porém, se o objetivo fosse a identificação de erros, um número maior de problemas seria
encontrado, uma vez que os profissionais de qualidade buscariam vários cenários para avaliar o comportamento do
software. Essa premissa provocou uma revolução na forma de abordar o problema, porém os testes continuariam a
ser executados tardiamente.
No início dos anos 1980, surgiram os primeiros conceitos de qualidade de software. Nessa abordagem,
desenvolvedores e testadores trabalhavam juntos desde o início do processo de desenvolvimento. Cada fase tinha sua
atividade de conferência, de forma a garantir que a etapa estava completa e bem compreendida. Muitas organizações
foram formadas e muitos dos padrões que utilizamos hoje nasceram nessa época nasceram nessa época, como os
padrões americanos formados pelo IEEE (Institute of Eletrical and Eletronic Engineers) e ANSI (American National
Standards Organization). No entanto, foi o modelo CMM (Capability Maturity Model), elaborado pelo Software
Engineering Institute, que ganhou maior dimensão e importância para as organizações de software, tornando-se um
modelo de avaliação mais reconhecido internacionalmente.
Somente nos anos 1990 é que ferramentas de teste começaram a ser produzidas. Determinados testes que
não eram possíveis de serem executados, agora poderiam ser feitos por meio de ferramentas desenhadas para
determinados objetivos. As ferramentas trouxeram alta produtividade e qualidade no processo de teste.
Limitações dos testes
O processo de qualidade de software existe para aumentar a confiabilidade do software. Os processos de teste
muitas vezes são executados sem o planejamento necessário, com massas de dados não controladas, ambientes com
alta interferência e com alta incidência de procedimentos manuais, tornando este processo frágil e pouco eficiente.
Um planejamento adequado e procedimentos automatizados de testes, garantem um alto nível de eficiência no
processo de qualidade de software, porém, nunca a total ausência de erros. Os testes têm como objetivo mostrar a
presença de erros, e nunca a ausência deles. Isto ocorre porque o plano de testes nunca conseguirá cobrir todas as
combinações existentes em um ambiente de execução real. O objetivo da realização dos testes é cobrir o maior
número possível destas combinações existentes.
Define-se a qualidade de software pelo número de requisitos que foram adequadamente testados e estão em
conformidade com o especificado. Um nível elevado de qualidade, além de ter uma vasta gama de cobertura, testa
novos requisitos e insere novos cenários não considerados anteriormente. Um software livre de erros, é um software
de baixa qualidade, com ausência de planejamento de testes e cobertura de requisitos especificados, o que irá gerar
um software de alto risco, com grandes possibilidades de impacto no ambiente interno e externo da organização.
Qualidade de software versus Teste de software
Onde a qualidade é aplicada
A qualidade de software é erroneamente interpretada no processo de engenharia de software. O
desenvolvimento de software é considerado uma linha do tempo e acredita-se que dentro desse processo existe um
período alocado especialmente para a realização de testes.
Este conceito confronta com a idéia de se identificar os erros nas fases iniciais do processo de
desenvolvimento do software, evitando a migração dos erros e, consequëntemente, elevando os custos de correção.
Segundo [BAR02], a qualidade não é uma fase do ciclo de desenvolvimento de software e sim uma parte de
todas as fases.
O processo de qualidade deve ser garantido em todas as fases do desenvolvimento do software, de forma a garantir
que não seja iniciada uma nova fase antes que a anterior a ela seja finalizada, testada e corrigida. Desta forma, a
propagação de erros é evitada e a concepção de garantia de qualidade de software é ampliada.
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
Esforço
para obter
Qualidade
Modelo
de
Negócios
Requisi
tos
Análise e
Modelagem
Implemen
tação
Testes de
Software
Disponibili
zação
Linha do Tempo
Figura 1: Qualidade aplicada em uma só etapa do desenvolvimento [BAR02]
Onde os defeitos são encontrados
Os erros são encontrados em todas as etapas do processo de desenvolvimento de um software. Estudos
revelam que a maior ocorrência dos erros, se concentra nas fases iniciais do processo de desenvolvimento. Reduzir
ao máximo a incidência de erros dentro do processo de desenvolvimento de um software, significa concentrar
esforços nas atividades iniciais do processo, pois muitos dos erros identificados no produto final são provenientes da
má especificação e entendimento sobre o propósito do sistema a ser desenvolvido.
De acordo com [BAR02], existe uma visão comum de entender que os defeitos são oriundos somente do
código-fonte do produto. Existe também um paradigma que defende que somente os profissionais de
desenvolvimento, qualidade e testes são os responsáveis por um software sem defeitos. Pode-se concluir que as duas
afirmações são incorretas. Primeiro porque os erros são gerados durante todo o processo de engenharia de software –
são os resultados de traduções imperfeitas de requisitos e especificações, que provocam a maior parte dos problemas.
Em segundo lugar, a participação das áreas de desenvolvimento e qualidade deverão interagir continuamente com as
áreas de negócio, suporte, infra-estrutura e atendimento ao cliente, com a finalidade de reduzir ao máximo o risco de
insucesso do projeto.
Qualidade em todo o ciclo do desenvolvimento
Fazer um levantamento criterioso e bem estruturado das atividades de especificação e modelagem, implica
em grande redução de erros, já que estes estão concentrados nas fases iniciais do ciclo de desenvolvimento. Porém,
para que a identificação e eliminação dos erros seja mais eficiente, é necessário que existam procedimentos que
avaliem a qualidade do que foi produzido em todas as etapas do processo de desenvolvimento. Assim, cada fase seria
adequadamente avaliada e vistoriada, impedindo que uma nova etapa seja iniciada sem que a anterior tenha sido
concluída corretamente.
O processo de garantia de qualidade em todo o ciclo de desenvolvimento permite a um número maior de
erros sejam identificados prematuramente, evitando a migração dos mesmos para as fases seguintes.
Conseqüentemente, os custos referentes às não-conformidades irão reduzir consideravelmente, tornando o processo
mais estável e menos caótico. Também poderá implicar na redução dos prazos de implantação do software, em
função da diminuição dos retrabalhos, o que irá resultar em clientes mais satisfeitos com a qualidade do produto,
equipes mais motivadas com a produtividade e uma empresa com mais solidez perante ao mercado. A cultura da
qualidade cria um ambiente favorável para prevenção e detecção de erros, transformando o processo de
desenvolvimento em uma atividade com etapas monitoradas e constantemente avaliadas, tornando o processo
confiável.
Benefícios de um processo de qualidade de software
O processo de qualidade de software tem por objetivo tornar o desenvolvimento do software um processo
claro e bem definido, identificando e corrigindo erros em cada fase do projeto, a fim de reduzir custos e gerar um
software de alta confiabilidade.
§ Confiabilidade do ciclo de desenvolvimento: É impossível desenvolver um software totalmente livre de
erros, independentemente do nível de complexidade que ele tenha. Com o objetivo de evitar custos
provenientes desta natureza, é necessário que se cria uma estrutura e processos que propiciem um ambiente
adequado e que permita a detecção do maior número de erros possíveis. Descobrir erros em todas as fases
do processo de desenvolvimento do software é criar consciência e tomar atitudes direcionadas a nãoproliferação de erros.
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
1.1.1.1.1.1 Custo
Completo
Produto acabado
Auditoria
§
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
Aumento de chances de sucesso do projeto de software: Um processo de qualidade de software tem como
objetivo eliminar ou minimizar os riscos e conflitos existentes durante todas as etapas do desenvolvimento
do software. Um eficiente processo de
Figura 2: Custos da qualidade versus processos da qualidade [BAR02]
§
§
§
§
§
qualidade de software é responsável por minimizar diversos pontos críticos nas etapas de desenvolvimento
do projeto, ao identificar antecipadamente inconformidades em documentos e análises realizadas,
garantindo assim, a confiabilidade do produto final.
Aumento da produtividade do desenvolvimento: O aumento de recursos direcionados ao desenvolvimento
de um projeto, ao contrário do que se imagina, não é necessariamente responsável por uma solução
tecnológica mais rápida e disponível aos clientes. Aumentar o número de desenvolvedores, significa
aumentar a capacidade de produção da equipe, possibilitando a diminuição de prazos e um resultado
fornecido mais rapidamente. Em contrapartida, estudos demonstram que a desorganização cresce à medida
que mais pessoas interagem em um ambiente que tenha um processo de qualidade falho. Uma vez que o
processo de qualidade é focado, um número menor de pessoas no desenvolvimento trabalham com grande
eficiência, atingindo êxito no projeto.
Fator desorganização : a desorganização reflete o número de erros gerados e o quanto este se propagou nas
fases do projeto. Quanto maior o número de erros e maior a propagação destes, maior será o nível de
desorganização do projeto estudado. A desorganização reflete na produtividade da equipe de
desenvolvimento e conseqüentemente nos retrabalhos do projeto tecnológico.
Fator retrabalho: O fator retrabalho está intimamente relacionado ao fator desorganização, o que por
conseqüência aumenta prazos, equipes e recursos financeiros. Uma equipe que se foca em retrabalho, está
perdendo tempo de desenvolvimento de novas funcionalidades, para corrigir um trabalho já executado
anteriormente. A desorganização em uma equipe de desenvolvimento pode ser reduzida ao se investir em
recursos que melhorem a qualidade de todo o processo. Uma equipe de qualidade elevará o nível de
produtividade do processo de desenvolvimento, garantindo melhor aproveitamento dos recursos já
existentes.
Diminuição da propagação de erros: um processo de testes regressivos, isto é, um processo que garanta que
a manutenção ocorrida na aplicação não afetou o comportamento das outras funcionalidades, é um dos
maiores benefícios obtidos durante o processo de qualidade de software. Isto descarta qualquer
possibilidade de novas mudanças propagarem erros para outros módulos Evita-se assim, o desperdício de
tempo com retrabalhos e aumenta a confiabilidade do sistema, já que nenhum erro, foi “deixado para trás”
ao ser desenvolvida uma nova funcionalidade.
Custos da qualidade de software
O custo da qualidade consiste na soma dos esforços e investimentos realizados com a finalidade de um
produto ou serviço atingir a qualidade desejada. Esses investimentos alocam todos os esforços relacionados aos
custos da não-conformidades (defeitos e suas correções) como todos os custos relacionados à manutenção da
conformidade dos produtos e serviços a serem produzidos (esforço para garantir a qualidade).
§
Custos da conformidade: consiste em todos os investimentos realizados para planejar e manter toda uma infraestrutura de pessoas, processos e ferramentas cujo objetivo é prevenir e detectar erros do processo. Todos esforços
envolvidos na intenção de melhorar e garantir o processo de desenvolvimento deve ser considerado custo da
conformidade, isto é, o custo para se obter e garantir qualidade.
§
Custos da não-conformidade: Compõe todos os custos de atividades relacionadas ao esforço de corrigir erros de
produtos originados no decorrer do processo de desenvolvimento.Tudo o que é realizado ou gerado em função de
defeitos produzidos durante os projetos de software deve ser encarado como não-conformidade, ou seja,
conseqüências financeiras da falta de qualidade.
Custo versus Qualidade
Aplicar conceitos de qualidade em todo o ciclo de desenvolvimento de um software envolve muito mais
fatores que recursos financeiros, profissionais e tempo. Por um lado, os profissionais de desenvolvimento
precisam direcionar seus esforços e contornar as restrições que lhes são impostas. Isto implica em priorizar as
atividades e enfatizar àquelas com mais problemas e criticidade. Por outro lado, a maturidade organizacional
do cliente é de suma importância. Se os processos no cliente não forem estruturados, é impossível estabelecer um
processo de qualidade completo. A falta de documentos básicos inviabilizam o processo, pois a informalidade do
desenvolvimento não possibilita a inspeção de documentações e especificações.
Custo da propagação de defeitos
O custo da propagação dos defeitos não leva em conta somente os recursos alocados na criação do software, o
tempo gasto, mas também a identificação dos erros, a correção, testes e implantação da correção. De acordo com
[BAR02, apud MYE79], quando um erro não é identificado, os custos de sua correção são multiplicados por dez, a
cada fase em que o erro migra.
Possuir um processo de detecção de problemas, de forma que os erros sejam identificados nas fases iniciais da
criação de um software, faz com que os custos de correção sejam mais baratos quando comparados às fases mais
tardias do processo de desenvolvimento.
Figura 3: Propagação de defeitos x Ciclo de desenvolvimento [BAR02]
10000
1234-
1000
AnáliseeModelagem
Código
TestedeSoftware
Produção
100
10
1
2
3
4
CiclodeDesenvolvimentodoSoftware
Estratégia de Teste
Depuração
Ocorre em conseqüência a testes bem-sucedidos. A depuração é o processo que resulta na remoção de um
erro, quando os testes o revelam, ou a partir de indícios de um problema. A depuração não pode ser considerada
teste, mas uma conseqüência dele. De acordo com [PRE95], a depuração terá sempre dois resultados:
§ A causa será encontrada, corrigida e removida
§ A causa não será descoberta
Neste último caso, o ponto de partida será sempre um indício ou suspeita, e a partir disso, um caso de teste é
projetado para auxiliar na identificação deste possível erro.
Fases dos testes sob a óptica do testador
De acordo com [BEI90], um testador deve ter em mente cinco fases essenciais, no qual o software é
submetido:
FASE 0 – Não há diferença entre teste e depuração. Exceto em suporte de depuração, o teste não tem propósito.
FASE 1 – O propósito do teste é mostrar que o software funciona.
FASE 2 – O propósito do teste é mostrar que o software não funciona.
FASE 3 – O teste não tem propósito de provar nada, exceto reduzir a chance de riscos de não funcionamento para
valores aceitáveis.
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
FASE 4 – Testar não é um ato. É uma disciplina mental que resulta em baixo risco do software sem muito esforço
despendido em teste.
Processo de qualidade
Os testes de validação e verificação são de extrema importância e devem ser aplicados em todo o processo
de desenvolvimento de software. O objetivo dos testes é capturar erros nas fases iniciais do processo, já que o custo
das correções aumenta exponencialmente quando os defeitos migram de uma fase para outra. Os testes de validação e
verificação são complementares, pois possuem objetivos distintos, o que fortalece o processo de detecção de erros e
aumenta a qualidade do produto final.
Testes de verificação
São testes caracterizados por não envolverem o processamento de softwares, pois antecedem a criação do
aplicativo, com o intuito de garantir definições claras e adequadas, que garantam a qualidade do desenvolvimento
desde o seu início.
Estes testes podem ser considerados como um processo de auditoria, incluindo documentos, gráficos,
manuais e código-fonte a cada etapa do processo de desenvolvimento do software. Este procedimento evita malentendidos, retrabalhos e conseqüentemente a migração de erros para as fases seguintes.
Testes de validação
Diferem-se dos testes de verificação pois envolvem o processamento dos softwares em um ambiente
tecnologicamente preparado para estas atividades. Estes testes se baseiam no comportamento do software, a partir de
condições simuladas, para que os resultados sejam comparados com as especificações produzidas pela área de
negócios.
Os testes de validação podem ser considerados como um processo formal de avaliação dos produtos
tecnológicos e têm por objetivo avaliar a conformidade do software, de acordo com os requisitos e especificações
anteriormente levantadas.
Técnicas de teste de software
Teste de caixa branca
Também conhecido como teste estrutural, esta estratégia tem por objetivo identificar erros nas estruturas internas
dos softwares, por meio da simulação de situações que exercitem adequadamente todas as estruturas utilizadas na
codificação. Estes teste são conhecidos pela grande eficiência na detecção de erros, mas por outro lado são
difíceis de ser implementados, já que requer um profissional com vasto conhecimento da tecnologia empregada
no software e na arquitetura interna da solução. Este profissional deverá ter acesso a código-fonte e a estrutura de
banco de dados.
Segundo [BAR02], o teste de caixa branca do software baseia-se num minucioso exame dos detalhes
procedimentais. Os caminhos lógicos através do software são testados, fornecendo-se casos de teste que põe à prova
conjuntos específicos de condições e/ou laços. Desta forma pode-se verificar se o comportamento esperando
corresponde ao comportamento real obtido pelos testes. De acordo com [PRE95], esta estratégia de testes tem por
finalidade avaliar exaustivamente as lógicas do software, porém possui a desvantagem de possuir um número de
caminhos lógicos muito extenso. O teste da caixa branca, entretanto, não deve ser desprezado como pouco prático.
Um número limitado de caminhos lógicos importantes pode ser selecionado e exercitado. Estruturas de dados
importantes podem ser investigadas quanto à validade. Os atributos, tanto do teste da caixa branca como do de caixa
preta, podem ser combinados para oferecer uma abordagem que valide a interface com o software e garanta
seletivamente que o funcionamento interno do software esteja correto. Este teste deve ser aplicado durante as etapas
iniciais da atividade de teste.
Teste de caixa preta
É conhecido também como teste funcional. De acordo com [PRE95], esta estratégia de testes baseia-se nos
requisitos funcionais do software, isto é, possibilita que o profissional de testes derive conjuntos de condições de
entrada que exercitem completamente os requisitos funcionais para um software. O teste da caixa preta tem por
objetivo descobrir erros nas seguintes categorias: funções incorretas ou ausentes; erros de interface; erros nas
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
estruturas de dados ou no acesso a bancos de dados externos; erros de desempenho; erros de inicialização e término.
Este teste deve ser aplicado durante as últimas etapas da atividade de teste.
Segundo o ponto de vista de [BAR02], o objetivo dos testes de caixa preta é verificar se o algoritmo inserido
no software produz os resultados esperados, diferentemente dos testes de caixa branca que verificam os
processamentos internos no software. A vantagem desta estratégia é o fato de que o profissional de testes não precisa
ter conhecimento da tecnologia empregada, ou da estrutura interna do software, o que facilita a capacitação do
mesmo. Estes testes são mais fáceis de serem implantados e são freqüentemente encontrados nas organizações em
forma de testes manuais executados por profissionais ou mesmo usuários do sistema, facilitando assim, a difusão
deste conceito nas organizações.
Testes de Validação
De acordo com [BAR02], é nesta fase que os profissionais de teste utilizam todos os recursos possíveis para
criar infra-estrutura que permita identificar o maior número de erros, tanto nos componentes isolados, quanto na
solução tecnológica como um todo. Para se obter êxito nesta etapa, é necessário um forte planejamento de todas as
atividades de teste, focando esforços nos componentes mais complexos e nos requisitos mais críticos.
Conseqüentemente, a eficiência dos procedimentos na detecção de erros, aumenta, visto que são nestes componentes
que se concentram a maior quantidade de erros.
Abordagens fundamentais dos testes
Todo o direcionamento dos testes, será baseado exclusivamente em requisitos da solução tecnológica a ser
desenvolvida ou na estrutura do código-fonte a ser implementado. Para cada uma dessas abordagens, existe um
conjunto de métodos diferentes de planejamento e obtenção dos casos de testes de validação.
§ Testes baseados na estrutura interna: requerem um profundo conhecimento da tecnologia e do projeto de
desenvolvimento, de modo a validar todos os algoritmos empregados pelo software. Por exigir
conhecimento da estrutura interna do software, a estratégia da caixa branca será utilizada para aborda-los.
§ Testes baseados em requisitos: são baseados em documentos de requisitos e modelados por meio de
especificações funcionais e suplementares. Os casos de testes devem avaliar todos os cenários existentes e
validar todas as variações (fluxos de processamento alternativos e de exceção) que uma solução tecnológica
deve suportar. São testes que devem ser empregados pela estratégia da caixa preta.
Progressividade e regressividade dos testes
§ Testes Progressivos: são testes elaborados de acordo com a criação de novas funcionalidades do software.
Nesta abordagem é necessário testar somente as inovações do software, assumindo que nenhum erro foi
introduzido após seu processo de desenvolvimento. Nesta categoria, as funcionalidades já existentes não são
testadas e considera-se que as novas alterações no código não impactaram na estrutura existente
anteriormente.
§ Testes Regressivos: esta abordagem reexecuta um subconjunto (total ou parcial) de testes previamente
executados. Seu objetivo é garantir que uma alteração ou criação de nova funcionalidade não causou
impactos nas estruturas já existentes. Toda nova versão do produto deveria ser submetida a uma nova sessão
de testes, a fim de assegurar que estes novos segmentos não afetaram outras partes do produto.
Categorias de teste
As categorias de testes são divididas de forma que cada uma delas foca a detecção de um problema. Assim, a
abordagem utilizada para isso varia de acordo com o propósito. Cada categoria possui seu ciclo de testes
independente, uma vez que suas naturezas são muitas vezes conflitantes, não possibilitando a coexistência.
Teste de Funcionalidade
É o tipo de teste que tem por objetivo simular todos os cenários de negócio e garantir que todos os requisitos
funcionais sejam implementados. Os testes funcionais exigem profundo conhecimento das regras de negócio de uma
aplicação para que todas as variações possíveis sejam simuladas, obtendo o máximo de cobertura dos cenários de
negócio.
Os testes funcionais devem ser direcionados pelos documentos de especificação funcional. Esses
documentos descrevem o comportamento que o software deve assumir nos diversos cenários existentes para cada
requisito de negócio. Os testes de funcionalidade são caracterizados pelo foco em negócio.
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
Teste de usabilidade
Esta categoria de testes tem por objetivo simular as condições de utilização do software sobre a perspectiva
do usuário final. Dessa forma, esses testes focalizam a facilidade de navegação entre as telas da aplicação, a clareza
de textos e mensagens que são apresentadas ao usuário, o acesso simplificado de mecanismos de apoio ao usuário, o
volume reduzido de interações para a realização de uma determinada função, padronização visual, entre outros
aspectos.
Teste de Carga (Stress)
Categoria de testes cujo objetivo é simular condições atípicas de utilização do software, provocando
aumentos e reduções sucessivas de transações que superem os volumes máximos previstos para o software, gerando
contínuas situações de pico e avaliando como o software e toda a infra-estrutura se comportam. Os testes de carga
avaliam como o conjunto da solução lida com variações sucessivas de processamento. São testes recomendados para
serem aplicados em softwares de missão crítica, pois requerem muito esforço na operacionalização. Estes testes
podem ser executados elevando e reduzindo o número de transações simultâneas, o tráfego de rede, aumentando o
número de usuários simultâneos e combinando todos estes elementos.
Teste de Volume
Categoria de testes cujo objetivo é determinar os limites de processamento e carga do software e de toda
infra-estrutura da solução. Diferentemente dos testes de carga, este tipo não focaliza oscilações de processamento,
mas o aumento contínuo dos parâmetros de execução.
É operacionalizado através de incrementos sucessivos de volume das operações realizadas com software, até
que este atinja o limite máximo ao qual toda a infra-estrutura está preparada para processar.
Teste de Configuração (Ambiente)
Categoria de testes cujo objetivo é executar o software sobre diversas configurações de softwares e
hardwares. Esses testes são recomendados para serem aplicados em softwares de missão crítica, pois requerem muito
esforço para operacionalizá-los. Eles podem ser executados variando os sistemas operacionais e suas versões,
variando os browsers, os hardwares que irão interagir com a solução ou então, combinando todos estes elementos.
Teste de Compatibilidade (Versionamento)
Esta categoria de testes tem por objetivo executar o software interagindo com as versões anteriores de outras
aplicações ou dispositivos físicos (softwares ou hardwares). Durante os procedimentos de mudança, é comum haver
falta de compatibilidade entre versões mais antigas e mais novas, o que significa que alguma interface foi
modificada, provocando incompatibilidade com as rotinas que as utilizavam. Estes testes podem ser realizados
importando-se dados gerados pela versão anterior ou comunicando-se com todas as versões de layout – antigas e
recentes.
Teste de Segurança
O objetivo desta categoria de testes é detectar as falhas de segurança que possam comprometer o sigilo e a
fidelidade das informações, bem como provocar perdas de dados ou interrupções de processamento. Os ataques à
segurança do software podem ter origens internas ou externas, provenientes de pessoas mal-intencionadas, que
variam desde profissionais descontentes até quadrilhas especializadas. Este teste tem como intuito avaliar o nível de
segurança que toda a infra-estrutura oferece, simulando situações que provocam a quebra de protocolos de
segurança, expondo quais são os pontos de maior fragilidade e risco de ocorrerem ataques.
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
Teste de Performance (Desempenho)
Esta categoria de testes tem por objetivo determinar se o desempenho, nas situações previstas de pico
máximo de acesso e concorrência, está consistente com os requisitos definidos. O critério de sucesso aqui
estabelecido é empregar o volume de transações e tempo de resposta obtidos nos testes e compara-los com os
valores-limite especificados.
Para esses testes, devemos especificar claramente o cenário que desejamos obter e
apontar quais são os tempos de resposta considerados factíveis à realização de cada um. Omitir informações significa
a criação de um cenário irreal, impossibilitando avaliar se o desempenho está condizente com o esperado.
Teste de Instalação
Essa categoria de testes tem por objetivo validar os procedimentos de instalação de uma aplicação, bem
como avaliar se estes possibilitam as várias alternativas previstas nos requisitos identificados. A idéia é aplicar as
muitas variações de instalação (normal e alternativas) e avaliar seu comportamento durante esses procedimentos.
Recomenda-se que o próprio usuário realize essas instalações.
Teste de Confiabilidade e Disponibilidade
O objetivo desta categoria de testes é monitorar o software por um determinado período de tempo e
avaliar o nível de confiabilidade da arquitetura da solução. Essas informações devem ser coletadas durante a
execução dos próprios testes de sistema, identificando sempre quando uma interrupção foi produzida por uma falha
da infra-estrutura (confiabilidade) e contabilizando o tempo necessário para resolução desse problema
(disponibilidade).
Teste de Recuperação
Categoria de testes que tem por objetivo avaliar o comportamento do software após a ocorrência de um
erro ou de determinadas condições anormais. Algumas aplicações suportam soluções de missão crítica, exigindo
alto índice de disponibilidade do software. Neste caso, a arquitetura da aplicação deve ser tolerante a 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 também devem contemplar os procedimentos de
recuperação do estado inicial da transação interrompida, impedindo que determinados processamentos sejam
realizados pela metade e sejam erroneamente interpretados como completos no futuro.
Teste de Contingência
Esta categoria de testes visa validar os procedimentos de contingência a serem aplicados à determinada
situação prevista no planejamento do software. Seu objetivo é simular os cenários de contingência e avaliar a
precisão dos procedimentos. Estes testes devem ser realizados pela própria equipe de plantão, na qual o tempo total
de execução do plano de contingência também será avaliado. Os testes podem ser executados por meio da instalação
emergencial de uma aplicação ou recuperação da perda de conexão da filial com a matriz.
Métodos estruturados de validação
Os métodos de verificação baseiam-se em técnicas de testes estáticos para avaliar a qualidade dos documentos
gerados durante todas as etapas do desenvolvimento do software; porém, para que se possa avaliar qualidade dos
documentos de um sistema, deve-se executar testes dinâmicos, de forma a submeter o software a determinadas
condições de uso e analisar se o comportamento está de acordo com o esperado. Assim, quanto maior a quantidade
de cenários estabelecidos para testes, mais qualidade o software terá.
Os métodos de validação devem se focar nos casos de testes, ou seja, são métodos que visam identificar
todos os cenário possíveis de teste. Os critérios para se obter os casos de teste, estão associados às duas abordagens
utilizadas nos testes de software: abordagem por requisitos ou estrutura interna. Estas abordagens permitem rastrear a
origem dos casos de testes, assim como quais casos de testes deverão ser aplicados a cada alteração no software.
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
Análise de cada fase de validação
Os testes de validação são aplicados diretamente nos softwares que estão sendo criados, com o objetivo de
identificar erros que foram introduzidos nas diversas etapas de desenvolvimento. Os testes de validação, também são
conhecidos como testes de baixo-nível e se caracterizam por exigir dos profissionais um vasto conhecimento da
estrutura interna do software. É ideal que estas atividades sejam realizadas por um profissional de testes, porém essa
decisão depende da maturidade organizacional, criticidade da aplicação, disponibilidade de recursos e das restrições
orçamentárias do projeto.
Teste de Alto Nível
Teste de Baixo Nível
Fase
da
Vali Categorias de Testes Aplicadas Características da Fase de Validação
daçã
o
Test
e de
Uni
dade
Test
e de
Inte
graç
ão
-
Estrutura Interna
Funcionalidade
Usabilidade
Segurança
Interfaces
Dependências
Componentes
Funcionais
Test Não Funcionais
e de
Performance
Siste
Instalação
ma
Recuperação
Carga
Test
e de
- Funcional
Acei
- Usabilidade
taçã
- Segurança
o
entre
-
Estratégia caixa branca e caixa preta.
Testa partes do software
Requer conhecimento da estrutura interna
-
Estratégia de caixa branca e caixa preta
Testa integrações entre partes do software
Requer conhecimento da arquitetura interna do software
Executada pelo desenvolvedor ou profissional de teste
-
Estratégia de caixa preta
Os testes são aplicados no software como um todo
Não requer conhecimento da estrutura interna do software
Requer ambiente muito semelhante ao da produção
Deve ser executada por um grupo de teste independente
-
Estratégia de caixa preta
Os testes são aplicados no software como um todo
Não requer conhecimento da estrutura interna do software
Requer ambiente muito semelhante ao da produção
Deve ser executado pelos usuários finais
Tabela 1: Análise das Fases de Validação [BAR02]
Validação da unidade
[PRE95] diz que este tipo de teste concentra-se no esforço de verificação da menor unidade do projeto de
software – o módulo.
Segundo [BAR02], é a primeira etapa do processo de validação que tem por objetivo é testar componentes
individuais de uma aplicação. Esta estratégia, caracterizada por testes de caixa branca, executa o software de forma a
executar adequadamente toda a estrutura interna de um componente, como desvios condicionais, laços de
processamento e caminhos alternativos de execução. Os testes de unidade objetivam: garantir a qualidade de
determinado componente tecnológico, avaliar a estrutura interna do software, garantir máxima cobertura do códigofonte, garantir o processamento de diferentes caminhos e garantir a adequação dos requisitos
A validação de uma unidade de software só será completa se testes estruturais (caixa branca) e funcionais
(caixa preta) forem aplicados, com objetivo de validar os requisitos do software.
Testes de caixa branca
São testes que têm por objetivo, exercitar a estrutura interna do software de diferentes formas, analisando
segmentos do código-fonte e simulando o processamento dos componentes. Este método, visa disparar rotinas
“encapsuladas” na unidade de software, com o objetivo de comparar os resultados obtidos com os resultados
esperados.
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
Nesta categoria de validação, é gerado um histórico de execução, identificando os testes que obtiveram êxito
e os que falharam, permitindo que os pontos de não-conformidade sejam corrigidos.
É uma estratégia de teste que exige um profissional com alto nível de compreensão e conhecimento de todo
o projeto. O ideal, seria integrar o processo de desenvolvimento com a aplicação de testes. Desta forma, haveria
auxílio mútuo entre o desenvolvedor e o profissional de testes. O primeiro, possui grande experiência na arquitetura
interna do projeto, tem conhecimento dos padrões, modelos de dados e ferramentas de desenvolvimento utilizadas. O
segundo, tem experiência no planejamento dos testes, e em como executa-los para detectar o maior número de erros.
Testes de caixa preta
São validações baseadas na arquitetura da aplicação, sendo possível identificar quais requisitos são mais
adequados aplicar durante os testes de cada unidade. Projetos orientados a objetos normalmente são separados em
pacotes de especialização (packages) que facilitam a organização e representam melhor a arquitetura aplicada ao
projeto do software. Cada pacote existente agrupa um conjunto de componentes que tem as mesmas características e
finalidades, possibilitando identificar um padrão único de abordagem dos testes.
Abordagem isolada
As unidades são testadas de forma totalmente isolada das demais, eliminando a dependência existente entre
outras unidades de software. Isso permite que os testes ocorram em qualquer seqüência ou momento do projeto de
desenvolvimento, uma vez que os componentes que são acionados por essa unidade não necessitam estar prontos ou
funcionando corretamente. Sem dependências, não existe seqüência de execução dos testes, permitindo a realização
de testes paralelos de unidades, eliminando o gerenciamento dos pré-requisitos dos testes.
Esta categoria de testes tem a desvantagem de exigir grande esforço na criação de simuladores para cada
componente que é acionado pela unidade que será alvo de testes. Devido ao fatos dos testes serem isolados, não
existem iterações dinâmicas com outras unidades de software, isto é, as chamadas realizadas a outros componentes
são realizadas somente por simulação, não ocorrendo realmente tais alterações. Devido a existência deste risco, é
fundamental aplicar esta estratégia juntamente com o teste de integração de unidades de software.
De acordo com [BAR02], esta abordagem é mais teórica que prática, pois a construção de simuladores para
todos os componentes envolvidos no projeto é muito complexo. [BAR02] acredita que uma nova geração de
ferramentas de testes construirá simuladores de forma dinâmica, eliminando o esforço de seu desenvolvimento.
Abordagem Top-down
Os testes unitários estão intimamente relacionados à forma como é conduzido o processo de
desenvolvimento do software. Nos projetos estruturados, atendidos tipicamente por processos de análise estruturada
ou análise essencial, as unidades são produzidas por meio de refinamentos sucessivos do projeto, isto é, quando uma
unidade de software está sendo criada, os níveis superiores estão todos construídos e validados, enquanto que os
níveis inferiores ainda não foram construídos. Assim, quando uma determinada unidade a ser validada é
disponibilizada, todas as demais unidades que acionam seus serviços e que estão localizadas em níveis hierárquicos
superiores estarão disponíveis para integrar os testes unitários como substituto natural dos controladores de testes. As
unidades inferiores não terão sido criadas, necessitando da construção de simuladores para responder a eventuais
chamadas acionadas pela unidade a ser testada.
A vantagem desta abordagem é o direcionamento explícito dos testes com relação aos requisitos de negócios
suportados pela aplicação. Estes testes exercitam as interfaces entre as unidades no sentido de cima para baixo,
dando origem ao nome desta categoria.
A desvantagem desta abordagem consiste no fato de ela estar fortemente apoiada na construção de
simuladores, aumentando significativamente os esforços de construção de um ambiente de testes nessas condições.
Outro fator de desvantagem é o fato de que, à medida que o projeto é desenvolvido e níveis mais baixos de
estruturação são atingidos, menores são os índices de cobertura, devido à dificuldade de simular operações de baixo
nível de funcionalidade, como tratamento de erros e restrições de segurança, o que torna o processo lento e pouco
flexível, necessitando de uma completa navegação da estrutura sempre que for acionar funcionalidades que estão
inseridas em unidades de nível hierárquico inferior.
Abordagem Bottom-up
Nesta categoria de validação, os testes unitários acompanham a estratégia de desenvolvimento baseado em
projetos não estruturados, chamados projetos orientados a objetos. Nesses projetos, não existe uma hierarquia de
unidades como eram modeladas as soluções baseadas nas análises estruturadas e essenciais. Nesse tipo de projeto
tecnológico, os problemas são fragmentados em um conjunto de pequenas unidades especializadas de software que
atenderão isoladamente a uma pequena fração do processo.
A vantagem dessa abordagem é a facilidade de realizar testes nas unidades mais básicas do projeto, o que
potencializa os testes de classes em projetos orientados a objetos. Nessa abordagem, os testes podem atingir a
cobertura total da estrutura interna, possibilitando a simulação de todos os fluxos alternativos de processamento,
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
além de exercitar os diversos desvios de condições existentes no código-fonte. Estes testes exercitam as interfaces
entre as unidades de baixo para cima.
A desvantagem dessa abordagem é a crescente complexidade que os testes ganham, à medida que eles
progridem e aumentam os níveis de interação com outras unidades, reduzindo o nível de cobertura estrutural
alcançado pelos testes.
Abordagem Big-bang
É considerado o método de validação mais utilizado na prática. Esta abordagem consiste na aplicação de
testes de integração realizados após a construção de todas as unidades de software, isto é, esses testes ocorrem com a
aplicação de todas as unidades ao mesmo tempo, não havendo ciclos parciais de integração.
Apesar de requerer menos esforço de execução, esta estratégia de testes possui resultados não satisfatórios,
devido a complexidade de se identificar erros, pois é difícil identificar qual dos componentes está gerando erro.
Integrações com abordagem mista
Esse modelo de integração representa uma combinação das abordagens Bottom-up e Top-down, visando
utilizar as vantagens de cada uma das técnicas.
Bottom-up
Princi
pais
Caract
erístic
as
-
-
Vanta
gens
-
-
Desva
ntagen
s
-
-
Comen
tários
-
Permite que as unidades mais básicas
(e talvez as mais críticas) sejam
testadas mais cedo.
As unidades podem ser integradas
em vários ciclos de testes, de acordo
com a necessidade do planejamento.
Maior ênfase na funcionalidade e no
desempenho dos módulos
Não há necessidade de simuladores
Maior facilidade de adaptar os testes
aos recursos humanos disponíveis
para executa-los
Maior cobertura das unidades mais
básicas e que atendem a aspectos
críticos de processamento
Erros na arquitetura da solução são
detectados mais cedo
Necessidade de controladores
Muitas
unidades
devem
ser
integradas antes de se conseguir
operacionalizar uma funcionalidade
Erros nas interfaces visuais são
detectados mais tarde
A produção do código avança mais
rapidamente do que por meio da
abordagem Top-down
Em geral essa abordagem é mais
intuitiva
Top-down
-
-
-
-
-
O módulo principal (main) é testado
primeiro
Apenas uma unidade é integrada a cada
ciclo
Maior ênfase nos protótipos visuais
Não há necessidade de controladores
Com o módulo principal (main) e alguns
módulos se obtém um protótipo nas fases
iniciais
Erros de interfaces são detectados mais cedo
Facilita a orientação dos testes de
funcionalidades da aplicação
Necessidade de simuladores
Erros na arquitetura da solução são
detectados tardiamente
Como as fases iniciais são muito
prolongadas, torna-se difícil sincronizar o
ritmo de desenvolvimento e disponibilidade
dos recursos de testes
Na prática, é muito difícil utilizar uma
abordagem puramente Top-down
Tabela 2: Diferenças entre as abordagens Bottom-up e Top-down [BAR02]
Validação do sistema
Trata-se de uma estratégia cujo objetivo é validar a solução como um todo. É a etapa de validação com
maior grau de incompreensão e de difícil operacionalização. Nesta fase, a maior parte dos defeitos de
funcionalidades deve ter sido detectada nos testes unitários e nos testes de integrações.
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
Como os testes de sistemas contam com uma infra-estrutura mais complexa de hardware (mais próximo do
ambiente real de produção), os testes de sistema deveriam concentra-se mais nos aspectos de performance,
segurança, disponibilidade, instalação, recuperação, entre outros. Nesse nível de testes, determinados aspectos das
funcionalidades que não puderam ser testados deverão integrar o planejamento dos testes de sistema, como testes de
integrações com sistemas externos (sem simulação), testes com dispositivos físicos (hardware), utilitários externos e
operacionalização do ambiente tecnológico.
Planejar validações de sistemas, requer um amplo entendimento dos requisitos não funcionais de um
software, que muitas vezes não foram definidos de forma clara ou representam cenários muito complexos. A falta de
um método único de como planejar e operacionalizar os testes de requisitos não funcionais, é preciso organiza-los e
dividi-los em categorias, com objetivos definidos e distintos.
Teste de recuperação
Segundo [PRE95], são testes de sistema que forçam o software a falhar de diversas maneiras e verifica se a
recuperação é adequadamente executada. Se a recuperação for automática, ou seja,, realizada pelo próprio sistema, a
reinicialização, mecanismos de checagem, recuperação de dados e reinício são avaliados quanto a concretitude. Se a
recuperação exigir intervenção humana, o tempo médio até o reparo é avaliado para determinar se ele se encontra
dentro de limites aceitáveis.
Teste de segurança
São testes que verificam se todos os mecanismos de proteção embutidos em um sistema o protegerão, de
fato, de acessos indevidos. Durante o teste, o analista deverá penetrar no sistema utilizando-se de qualquer
estratégia. Seu papel é fazer com que a segurança chegue em um ponto tal, que o acesso custe mais caro que o valor
da informação a ser obtida [PRE95].
Teste de stresse
É um teste realizado para confrontar os programas com situações anormais, exigindo recursos em
quantidade e freqüência.[PRE95] afirma que uma variação do teste de estresse, é uma técnica chamada teste de
sensibilidade. Em alguns casos, uma variedade muito pequena de dados contida dentro dos limites de dados válidos
para um programa pode provocar um processamento extremo ou mesmo errado, ou ainda gerar uma grande
degradação do desempenho. Este teste tem por objetivo descobrir combinações de dados dentro de classes de entrada
válidas que possam causar instabilidade ou processamento impróprio.
Teste de desempenho
É um teste que valida o desempenho de execução do software dentro do contexto de um sistema
integrado. Esta estratégia ocorre em todos os passos de processo de testes, porém só quando todos os elementos de
sistema estão plenamente integrados é que o desempenho real de um sistema pode ser verificado. Pode ser executado
juntamente com o teste de estresse, porém é necessário medir a utilização de recursos de hardware e software.
Validação de aceite
É o último estágio do processo de validação. Consiste na última etapa do processo formal de detecção de
erros no sistema, antes de sua disponibilização no ambiente de produção. Nessa etapa, o software é disponibilizado
para clientes e usuários para que eles validem todas as funcionalidades requisitadas no início do projeto. Neste
estágio, os usuários podem interagir com o sistema completo, que já foi anteriormente testado pelos profissionais de
teste.
Se esta fase apresentar muitas falhas, isso significa que as etapas de validação anteriores foram executadas
com pouca qualidade. Os procedimentos de aceite deverão ser realizados a cada ciclo de implementação da solução,
permitindo que sejam feitas correções dos pontos que não foram adequadamente atendidos pelo software. O aceite
pode ser dividido em três etapas:
§ Aceite formal
§ Alpha-teste
Homologação (aceite da solução)
Distribuição
§ Beta-teste
Aceite
For
mal
Alpha-
teste
Betateste
Todos
os
Client
es
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
Aceite Formal
Implantação Alpha
Implantação Beta
Implantação Total
Clientes planejam e Clientes são convidados Clientes
selecionados
Todos os clientes recebem o
realizam os testes do a operar o software no recebem o software para
software devidamente testado
software
fornecedor
operar em seu ambiente
Figura 4: Testes de Aceite [BAR02]
Aceite formal
É um processo de continuação dos testes de sistema. Por utilizar a infra-estrutura existente no ambiente de
homologação (inclusive os simuladores), o aceite formal segue um rigoroso planejamento das atividades de testes,
cabendo aos próprios clientes e usuários determinarem o que deverá ser testado e validar se os requisitos foram
adequadamente validados.
Na maioria dos casos, o aceite formal restringe-se apenas às funcionalidades de negócio, deixando outros
requisitos fora do escopo desses testes. Esses processos poderão ser totalmente automatizados pela equipe de testes,
cabendo aos clientes e usuários a conferência dessas atividades.
O aceite formal é muito empregado em projetos que são desenvolvidos para atender a um grupo de
empresas, possibilitando a criação de um comitê que atestará a aderência do software às necessidades do grupo.
Também são aplicados quando as outras estratégias de validação não foram executadas ou falharam.
Alpha-teste
Caracteriza-se pela ausência de formalidade no processo de validação, não existindo regras rígidas de
execução ou procedimentos de aceite. O objetivo desta categoria de validação é capturar a naturalidade dos próprios
usuários e dar a eles a possibilidade de realizar seus próprios testes. É recomendado que este processo seja
gerenciado por profissionais do teste, objetivando que um mínimo de cobertura seja garantido na realização dos
testes.
Nesta fase, os clientes operam o software em um ambiente simulado, localizado na empresa que
desenvolveu o software, porém em um ambiente que não seja o de desenvolvimento. Os profissionais incumbidos de
gerenciar o processo de aceite, garantir que os usuários executaram todos os pontos da aplicação, inclusive os mais
críticos, permitindo a identificação de erros em procedimentos implantados. [PRE95],[BAR02].
Beta-teste
Nesta etapa, os clientes operam o produto utilizando suas próprias instalações físicas para que o software
possa ser submetido às mesmas transações do dia-a-dia. Trata-se de uma implantação em paralelo, mas não
definitiva. Estes testes ocorrem até que o cliente se sinta seguro em realizar a mudança do aplicativo. Uma equipe de
testes deverá acompanhar esse processo, com o objetivo de corrigir eventuais erros que possam aparecer na
aplicação. O Beta-teste pode ser planejado em vários ciclos que englobam um número cada vez maior de clientes,
que executam a maioria das finalidades, a fim de se alcançar um elevado nível de cobertura e garantir que o aceite
seja efetivo e seguro.
Avaliação da aplicação dos testes
Porque os testes falham
Os processos de implantação de qualidade de software podem fracassar em alguns momentos. As origens do
fracasso podem ser diversas ou até mesmo não identificadas.
§
Ausência de uma área estruturada de Qualidade: a área de qualidade de software disponibiliza uma
infra-estrutura de recursos físicos que incluem máquinas e ferramentas, recursos humanos que planejam
e executam os testes, além do conhecimento adquirido pelo grupo. Atribuir outra área como
responsável pela qualidade de software, pode, muitas vezes, minimizar os benefícios conseguidos por
uma área especializada.
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
§
§
§
§
§
§
Qualidade não aplicada em todo o processo de Desenvolvimento: grande parte dos erros concentram-se
nas fases iniciais de levantamento e modelagem do software. A qualidade deve ser considerada uma
etapa única dentro do processo de criação de um software, e não uma etapa seguinte ao
desenvolvimento do software.
Testes comprometidos pela pressão: Quando os prazos de entrega do projeto excedem o planejado, é
comum sacrificar algumas fases de desenvolvimento, com o objetivo de compensar o atraso, e adicionar
este tempo ganho na codificação do produto final. As primeiras etapas comprometidas são as de
modelagem e estruturação da solução. A falta de empenho nestas fases, irão causar grande impacto nas
fases posteriores, pois vários aspectos do negócio deixarão de existir quando o projeto for codificado. A
etapa de testes, também prejudicada em seu planejamento justamente por consumir mais da metade do
processo de teste, perde eficiência na detecção de erros. Assim, o processo de testes de software se
torna falho e ineficiente, prejudicando a qualidade final do produto.
Delegação de Testes ao Analista de Sistemas: De acordo com [BAR02], o analista de sistemas possui o
conhecimento das regras de negócio e tende a realizar testes que não resultem em erros. O analista de
sistemas sabe quais são as consistências do sistema, executando testes que se baseiam em condições já
discutidas durante o desenvolvimento. O analista de testes atua com imparcialidade no planejamento e
criação dos cenários para executar os testes de software. Este profissional possui e percepção e
experiência das diversas categorias de testes, organizando-as e empregando-as de forma a apontar
situações não previstas pela equipe, o que resulta na maior eficiência durante o processo de detecção de
erros.
Falta de Profissionais especializados em Qualidade de Software: O profissional de desenvolvimento, ao
contrário do que ocorre em muitas organizações, não é capacitado para realizar testes de software. O
desenvolvedor é responsável por construir o software, enquanto que o analista de software é quem
avalia a solidez do mesmo. Os profissionais da área de qualidade devem possuir uma metodologia
voltada a encontrar falhas em todo o ciclo de desenvolvimento de software. Eles devem também
direcionar seus esforços e aperfeiçoar essas metodologias, padronizar as documentações e
procedimentos de qualidade e reduzir os esforços no planejamento e operacionalização dessas
atividades.
Falta de Testes regressivos: Em grande parte das empresas, os testes são direcionados somente nas
novas funcionalidades implementadas, o que são chamados de testes progressivos. Desta forma, as
funcionalidades já existentes são desconsideradas, aumentando a probabilidade de não se identificar
possíveis erros surgidos com a incompatibilidade de versões. Esta abordagem é adotada nas
organizações porque reduz o esforço de implantação em um ambiente de testes, porém aumenta a
incidência de erros no ambiente de produção.
Planejamento de Testes falho: O planejamento de testes tem como objetivo antecipar os passos de
realização de um trabalho, produzindo uma visão sobre um conjunto de situações. Um bom
planejamento deve ter um foco de longo prazo, para que o investimento realizado seja amortizado
durante período previsto pelo planejamento. A negligência no planejamento aumenta a probabilidade de
falhas na detecção de erros e o aumento dos custos finais provocados pela ineficiência e inflexibilidade
do modelo.
Testes manuais versus Testes automatizados
Os testes têm por objetivo identificar falhas e inconsistências em todo o processo de desenvolvimento de um
software. Além das inconformidades, os testes avaliam se o comportamento do sistema está de acordo com o
esperado. Os testes se associam à tecnologia com que são executados, podendo ser testes manuais ou testes
automatizados.
Testes manuais
Também chamados de testes estáticos, essa tecnologia consiste na utilização de recursos humanos para
realizar todos os procedimentos de testes especificados. A grande desvantagem, é a grande incidência de erros
humanos no processo, isto é, a não execução dos procedimentos na ordem estabelecida e valores digitados
erroneamente. Este tipo de teste deve ser analisado e adotado com cautela.
Testes automatizados
Também chamados de testes dinâmicos, essa tecnologia consiste na utilização de ferramentas de testes
que permitam simular usuários ou atividades humanas de forma a não requerer procedimentos manuais no
processo de execução dos testes. Esta tecnologia requer profissionais especializados, o que exige mais detalhes
no planejamento e tempo adicional para o desenvolvimento e automação dos testes. Possui um papel estratégico
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.
pois possibilita a realização de diversos ciclos repetidos de testes. Este processo requer um investimento inicial
muito alto, porém o ganho de tempo e confiabilidade no projeto final, incentivam a aderência a esta tecnologia.
Etapas dos Testes
Planejamento
Definição dos Casos de Testes
Execução dos Testes
Conferência dos Testes
Gerenciamento do Erro
Relatórios Finais
Duração Total (em Horas)
Teste Manual Teste Automatizado
32
40
262
117
466
23
117
58
117
23
96
16
1090
277
Melhoria (%)
- 25%
55 %
95 %
50 %
80 %
83 %
75 %
Tabela 1: Comparativo entre testes manuais e automatizados [BAR02]
Conclusão
O processo de qualidade de software, como o próprio nome sugere, não deve ser considerado como uma etapa no
processo de desenvolvimento, e sim fazer parte de todas as fases. Embora muitas organizações ainda não tenham
consciência da real importância dos testes e de uma equipe de profissionais para realizarem estas atividades, esta é
uma vertente da Engenharia de Software que tem evoluído constantemente e está sendo empregada cada vez mais
pelas organizações. O processo de testes, quando aplicado de forma adequada, detecta o maior número de erros
possíveis, percorrendo o maior número de caminhos de execução do software e amortiza os custos de manutenção,
uma vez que aumenta a conformidade da aplicação com o que foi especificado, e reduz a quantidade de erros
encontrados pelos clientes.
Os testes de software, contam com uma equipe de profissionais capacitados para esta atividade, e deveria
(de forma ideal) trabalhar de forma integrada com os profissionais envolvidos no projeto. Este processo, manual ou
automatizado também deve ser documentado, com a finalidade de adequar os testes aos requisitos definidos pelo
cliente, além de permitir que profissionais envolvidos indiretamente no trabalho possuam uma visão clara e definida
do andamento do projeto.
Muitas empresas ainda não têm consciência dos benefícios do processo de teste e que os erros migrados para
as etapas seguintes aumentam o custo do software de forma exponencial. Embora este processo de qualidade melhore
consideravelmente o desenvolvimento do produto, as organizações ainda não estão cientes da sua real importância e
além disso, não sabem como aplicar os conceitos de qualidade proporcionalmente ao tamanho e organização da
empresa. O processo de qualidade é muito amplo e aborda diversas estratégias. Portanto cabe a empresa estudá-las e
adequá-las às suas reais necessidades, aplicando os conceitos ideais à realidade de cada organização.
Referências bibliográficas
[BEI90] BEIZER, Boris. Software Testing Techniques. 2.ed. New York, NY, USA. The Coriolis Group, 1990. 550
p.
[PRE95] PRESSMAN, Roger S. Engenharia de Software.5.ed. São Paulo, SP, Brasil. Makron Books, 1995. 1056 p.
BACH, J. The Challenge of "Good Enough" Software.< http://www.satisfice.com>. Acesso em: 25 mai. 2006.
________ Exploratory Testing Explained. <http://www.StickyMinds.com>. Acesso em: 01 mai. 2006.
________ What is Exploratory Testing? <http://www.satisfice.com>. Acesso em: 01 mai. 2006.
_________ Exploratory Testing and the Planning Myth. Disponível em <http://www.StickyMinds.com>. Acesso
em: 01 mai. 2006.
_________ Reasons to Repeat Tests <http://www.satisfice.com>. Acesso em: 25 mai. 2006.
_________ How Much Is Enough? Disponível em <http://www.StickyMinds.com>. Acesso em: 01 mai. 2006.
[BAR02] BARTIÉ, Alexandre. Garantia de Qualidade de Software. 5.ed. Rio de Janeiro, RJ, Brasil. Elsevier,
2002, 295p.
Easy PDF Creator is professional software to create PDF. If you wish to remove this line, buy it now.