Fundamentando o Teste de Software

Conceituando Teste de Software

O teste composto por diversas atividades: Planejamento e controle, Anlise e
modelagem, Implementao e execuo, Avaliao dos critrios de sada e
relatrios, e Atividades de encerramento de teste. Alm disso, o teste tambm
pode incluir a reviso de documentos, incluindo o cdigo fonte, e a anlise
esttica. Essas atividades podem acontecer de forma concorrente e no
necessariamente numa ordem especfica.
Como podemos notar, analisando as atividades que fazem parte dos testes,
podemos concluir que a execuo do teste apenas uma das atividades que
devem ser realizadas, ainda temos os planos, a modelagem e a avaliao de
resultados.
Os testes ainda podem ser definidos atravs de duas fronteiras: dinmicos ou
estticos. O teste dinmico consiste nas atividades de planejamento, execuo
e controle. No teste dinmico o software necessita ser executado. J o teste
esttico consiste nas atividades de reviso (na documentao do projeto e
cdigo fonte), inspeo (na documentao do projeto e cdigo fonte) e anlise
esttica de cdigo. O teste dinmico o mais utilizado, mas tambm tende a
ter um custo mais alto, pois o software j est sendo executado. Por isso
sempre importante anteciparmos os testes no ciclo de vida para prevenir
defeitos no cdigo. Se os testes iniciarem logo na fase de requisitos, por
exemplo, a reviso de documentos ajudaria nessa preveno e evitaria
diversas outras etapas com erros.
Algumas pessoas acham que o teste serve para confirmar que o software
funciona. Isso totalmente errado, o teste serve para encontrar defeitos,
prevenir defeitos, testar o nvel de qualidade do software ou ainda prover
informaes para uma tomada de deciso.
Os diferentes tipos de teste possuem tambm diferentes objetivos. No teste
feito em desenvolvimento atravs dos testes de componentes, integrao e de
sistemas o objetivo causar falhas, de modo que os defeitos possam ser
identificados e resolvidos. No teste de aceite junto ao usurio estaremos mais
focados em confirmar se o sistema est funcionando conforme esperado pelo
usurio. Os testes de manuteno so utilizados para verificar se novos erros

no foram introduzidos durante o desenvolvimento das mudanas e, por fim,

os testes operacionais avaliam caractersticas como confiabilidade e
disponibilidade.
Outra situao que causam confuses na rea de teste de software a
diferena entre o conceito de depurao de cdigo e teste. sempre bom
deixar claro que ambas so atividades diferentes. Enquanto que os testes
procuram demonstrar as falhas, a depurao concentra-se em identificar a
causa de um defeito. As duas atividades tambm possuem diferentes
responsabilidades, pois, testadores testam enquanto que desenvolvedores
depuram. Basicamente na depurao temos uma ferramenta que utilizada
por programadores que reproduzem a falha investigando o estado dos objetos
procurando pelo defeito.
Por fim, uma pergunta recorrente que todos sempre fazem : quanto ns
devemos testar? Para responder esse tipo de pergunta sempre devemos levar
em considerao quatro nveis de risco: o risco tcnico, risco do negcio e o
risco do projeto que tambm inclui restries do projeto como tempo e
oramento.

A Necessidade de Testar
Antigamente os sistemas de computadores no tinham nenhuma ou quase
nenhuma influncia nos negcios das organizaes. Atualmente este contexto
mudou radicalmente e as falhas em softwares podem acarretar srios prejuzos
financeiros, danos materiais, perda de reputao ou at mesmo causar mortes.
Os softwares esto presentes em praticamente todos eletrodomsticos,
motores, automveis, etc. Por exemplo, temos software presente em
elevadores que fazem parte de diversos edifcios, em aparelhos de televiso,
nos automveis que usamos no dia a dia, em celulares, em eletrodomsticos
como micro-ondas, geladeira, etc. Alm disso, temos tambm muitas
aplicaes crticas que se falharem podem causar srios danos. Exemplo
dessas aplicaes so os softwares de controle que esto presentes nas usinas
nucleares, softwares que esto presentes em aeronaves ou embutido em
msseis e radares, software que agem no controle de pacientes que so tratados
em casa ou em hospitais, etc. Alguns dos grandes desastres causados por
software esto: a exploso do foguete Ariane quarenta segundos aps a
decolagem em 1996 que foi causado por um erro no projeto do software que
fez com que o foguete desviasse de sua rota e explodisse; outro grave acidente
foi com o Airbus A380 devido as incompatibilidades das diferentes verses
usadas do software de projeto e projetos mecnicos CATIA, enquanto os
scios franceses utilizavam a ltima verso, a fbrica alem no tinha ainda
atualizado a mesma; Recentemente um novo sistema desenvolvido pela

Siemens para controlar a emisso de passaportes sem testes suficientes e sem

pessoal qualificado estragou com as frias de mais de meio milho de
britnicos. Atualmente diversos outros problemas causados por software
tambm resultaram em diversos problemas, como no Banco Ita, TAM, entre
outros. Estima-se que os defeitos de software tenham custado cerca de 60
bilhes de dlares no ano de 2007, de acordo com o National Institute OS
Standards and Tecnology.
Dessa forma, tornou-se fundamental o teste de software nos dias atuais.
Os testes de software so realizados, pois um humano independe da sua
qualificao ou experincia pode cometer um erro na especificao ou na
documentao que por sua vez produzir um defeito no cdigo, que se for
executado produzir uma falha visvel. Portanto, temos aqui trs conceitos
muito importantes: erro, defeito e falha. Tambm podemos observar que um
software pode conter defeitos, mas nunca falhar, pois para falhar ele precisa
ser executado ou observado. Alm disso, o defeito um estado do software
causado por um erro.
O erro cometido pelo ser humano advm de diversos fatores como mudanas
tecnolgicas, falhas na comunicao, problemas no processo, complexidade
do sistema, presso, prazo muito curto, etc. Algumas vezes as falha so
causadas por condies no ambiente como radiao, poluio, etc., que podem
influenciar a execuo do software devido alterao das condies de
hardware. Um exemplo disso uma corrente eltrica muito oscilante que pode
comprometer um equipamento que por sua vez pode levar a um defeito numa
parte do HD onde se encontra um software ou at mesmo ao travamento do
sistema operacional do equipamento acarretando outros problemas nos
softwares desse sistema.
O teste se faz ainda mais necessrio para construirmos uma confiabilidade no
sistema. A confiabilidade uma probabilidade que o software no causar
uma falha no sistema por um tempo e condies determinadas. Ou seja, um
software poder ter defeitos, mas mesmo assim ser confivel. Isso porque um
software nunca ser totalmente livre de defeitos, partes que no foram testadas
o suficiente ou utilizadas certamente tero deslizes, mas importante que as
partes principais ou mais especficas estejam funcionando corretamente para o
cliente. Por isso a confiabilidade tende a aumentar no decorrer do tempo
quanto mais o software for utilizado e executado. Quanto menos falhas forem
ocorrendo ao longo do tempo mais confivel o software vai se tornando.
Por fim, os testes tambm precisam ter certo nvel de independncia. Dizemos
que um teste com Baixo nvel de independncia aquele onde os testes so
realizados pelo prprio programador que escreveu o cdigo. Esse o pior dos
casos. O nvel Mdio de independncia aquele em que os testes so

realizados por um programador diferente daquele que fez o software. Um

nvel Alto de independncia e, dessa forma, mais desejado, aquele em que os
testes so realizados por uma pessoa ou por uma equipe que independente da
equipe de desenvolvimento. Por fim, um nvel ainda mais alto de
independncia seria um teste que fosse totalmente gerado por ferramentas e
que no houvesse nenhuma interveno humana. Obviamente que este ltimo
nvel de independncia impossvel de ser alcanado, por isso a melhor forma
de testar aquele teste realizado por uma equipe de testes independentes ou
em alguns casos por uma fbrica de testes como aquelas empresas que so
especializadas apenas em testar softwares sem que precisa-se arcar com os
altos custos de contratao, treinamento, atualizao da equipe e das
tecnologias e ferramentas.

Relao entre Qualidade e Teste

Qualidade um conceito muito relativo e depende do produto que est sendo
analisado, depende do observador, e temos ainda diversos aspectos que so
levados em conta.
Existem diversos conceitos de qualidade, um deles definido pela norma
NBR ISO 9000: "Qualidade a totalidade das caractersticas de uma entidade
que lhe confere a capacidade de satisfazer as necessidades explcitas e
implcitas".
Agora que conhecemos uma definio bsica sobre a qualidade em geral, se
trazermos a qualidade para o software teramos a seguinte afirmao:
Qualidade de Software aplicar os conceitos referentes a qualidade ao
software. O autor Pressman, um dos mais renomados autores de engenharia
de software, define qualidade aplicada ao software de forma mais detalhada
como: "Qualidade a conformidade a requisitos funcionais e de desempenho
explicitamente declarados, a padres de desenvolvimento claramente
documentados e a caractersticas implcitas que so esperadas de todo
software profissionalmente desenvolvido. A norma ISO/IEC 9126 vai um
pouco mais longe e define que um software de qualidade deve ser correto,
manutenvel, confivel, flexvel, eficiente, testvel, integro, portvel, fcil de
usar, reutilizvel e interopervel.
De forma sumarizada qualidade o grau a qual um sistema atende s
necessidades dos usurios de forma confivel, acessvel, segura, no tempo
certo e com o menor custo.
Outra definio bastante diversificada a de teste, segundo o autor Glenford
Myers testar analisar um programa com a inteno de descobrir erros e

defeitos. Outras definies tambm so dadas para o teste, porm

interessante saber tambm a definio de teste dada pelo ISTQB: Processo
que consiste em todas as atividades do ciclo de vida, tanto estticas quanto
dinmicas, voltadas para o planejamento, preparao e avaliao de produtos
de software e produtos de trabalho relacionados a fim de determinar se elas
satisfazem os requisitos especificados e demonstrar que esto aptas para sua
finalidade e para a deteco de defeitos.. Podemos verificar que o ISTQB
sugere uma definio um pouco mais ampla.
Uma pergunta a ser respondida : Ser que com teste podemos aumentar a
qualidade do software?
A resposta no. O teste ajuda a medir como est a qualidade do software e
reduz os riscos de ocorrerem problemas aumentando a confiabilidade do
software. A qualidade medida atravs de requisitos funcionais e no
funcionais, sendo que para os requisitos no funcionais podemos realizar os
testes de confiabilidade (capacidade do produto se manter no nvel de
desempenho nas condies estabelecidas), usabilidade (capacidade do produto
de software ser compreendido, seu funcionamento aprendido, ser operado e
ser atraente ao usurio), eficincia (capacidade do tempo de execuo e os
recursos envolvidos serem compatveis com o nvel de desempenho do
software), manutenibilidade (capacidade ou facilidade do produto de software
ser modificado, incluindo tanto as melhorias ou extenses de funcionalidade
quanto as correes de defeitos, falhas ou erros), portabilidade (capacidade do
sistema ser transferido de um ambiente para outro) e funcionalidade
(capacidade de um software prover funcionalidades que satisfaam o usurio
em suas necessidades declaradas e implcitas, dentro de um determinado
contexto de uso). Assim, o teste fundamental para a avaliao do software
desenvolvido, entretanto, testar um software no uma atividade trivial, e
exige conhecimentos, habilidades e infraestrutura.
Portanto, somente testar no garante a qualidade do software, mas ajuda a
diagnosticar como est a qualidade deste software.

Os Princpios do Teste
O teste possui sete princpios bsicos, so eles: Teste Demonstra a Presena
de Defeitos onde neste principio afirma-se que o teste pode mostrar a presena
de defeitos num software, mas jamais pode provar que eles no existem, e
mesmo que nenhum defeito seja encontrado no provado que ele esteja
perfeito ou livre de defeitos; Teste Exaustivo Impossvel em que neste
principio afirma-se que testar tudo no a melhor forma de testar, sendo
muitas vezes impossvel, exceto em alguns casos raros. Esse tipo de teste

caro, requer muito tempo e muitas pessoas envolvidas; Teste Antecipado o

terceiro principio onde se diz que o teste deve iniciar o mais cedo possvel no
ciclo de desenvolvimento de software, isso porque quanto mais tarde levarmos
para descobrir um erro mais caro custar para conserta-lo; Agrupamento de
Defeitos o quarto principio na qual se afirma que um nmero pequeno de
mdulos possui a maioria dos defeitos descobertos durante o teste ou ento
exibem a maioria das falhas operacionais; O Paradoxo do Pesticida o quinto
principio que afirma que um conjunto de teste que so repetidos vrias vezes
no encontraro novos defeitos aps certo tempo, devido a isso os testes
devem sempre passar por reviso e ser atualizados constantemente; Teste
Depende do Contexto o sexto principio que afirma que os testes so
realizados de diferentes formas conforme o contexto de cada um; Por fim, A
Iluso da Ausncia de Erros o stimo principio onde se afirma que encontrar
e consertar defeitos no ajuda se o sistema construdo no atende s
expectativas dos usurios.

Atividades do Teste
O Planejamento e Controle do teste a primeira atividade realizada. Nesta
atividade o Planejamento consiste em definir quais so os objetivos do teste e
especificamos quais as atividades necessrias para alcanar esses objetivos.
Nesta etapa de Planejamento tambm especificamos o escopo do projeto de
forma a detalhar as funcionalidades do software a serem testadas. O
Planejamento tem como sada o Plano de teste que um documento com a
descrio do escopo, meta, objetivos, recursos necessrios e cronograma.
Aps isso o Controle do teste acontece em todas as atividades como uma
forma de comparar o progresso atual contra o que foi planejado reportando o
status atual e os desvios que esto ocorrendo em relao ao plano definido.
Portanto, o Controle monitora o progresso durante todo o projeto. Podemos
notar que a atividade de Planejamento e de Controle so atividades voltadas
gesto, por isso normalmente so executadas por um gerente de teste ou
desenvolvimento dependendo do projeto.
A Anlise e Modelagem do teste tm como objetivo transformar os
objetivos em condies e modelos de teste. Diversas atividades principais so
especificadas nesta etapa como: reviso da base de testes, avaliao da
testabilidade dos requisitos e do sistema, identificao e priorizao dos testes
com base na analise das especificaes, projeo e priorizao dos casos de
testes de alto nvel, identificao das necessidades de dados para efetuar os
testes, planejamento e preparao do ambiente de teste, criao da
rastreabilidade entre requisitos e casos de teste.

Portanto, nesta etapa identificaremos tudo que deve ser testado analisando a
aplicao como um todo (Anlise) e depois modelamos como devemos testar
(Modelagem). Como podemos notar, na anlise identificamos o que necessita
ser testado e na modelagem detalhamos como iremos testar. Alm disso,
tambm obteremos a infraestrutura necessria para os testes.
Na Implementao e Execuo do teste onde preparamos e configuramos
o ambiente, criaremos scripts de testes de acordo com os casos de teste que
sero finalizados e priorizados, criaremos os dados de teste, verificaremos e
atualizamos a rastreabilidade bidirecional entre a base de teste e os casos de
teste, e, por fim, executaremos os testes manualmente ou com ferramentas e
registraremos os resultados da execuo comparando resultados obtidos com
os esperados. Os casos de teste especificam em detalhe como testaremos uma
determinada funcionalidade do sistema descrevendo o que ser testado, os
dados de entrada necessrios, quais os retornos esperados, etc.
A Avaliao do Critrio de Sada e Relatrio onde avaliamos a execuo
do teste dados os objetivos definidos no planejamento de teste, avaliamos se
sero necessrios mais testes ou se o critrio de sada deveria ser alterado e,
por fim, elaboramos um relatrio de teste resumido para todos os interessados
no projeto. Os critrios de sada podem ser definidos atravs de uma restrio
de tempo, nmero de requisitos cobertos, porcentagem de testes executados,
nmero de defeitos que permanecem, ou ainda se todos os casos de testes
foram executados ou aprovados, etc. Basicamente esses critrios so
acordados com os interessados e permite que um processo seja considerado
como completado.
A ltima etapa a Atividade de Encerramento de teste em que coletamos
todos os dados de todas as outras atividades para consolidar a experincia
obtida, o testware (toda documentao gerada pelo processo de teste como
planos de teste, condies de teste, casos de teste, base de teste utilizada, etc),
fatos e nmeros consolidados. Nesta etapa ainda checamos se todos os
entregveis planejados foram entregues, fechamos relatrios e incidentes,
documentamos o aceite do sistema, finalizamos e arquivamos o testware,
ambientes de teste, infraestrutura de teste para reuso, analisamos lies
aprendidas para determinar as mudanas para futuros projetos, e melhoramos
a maturidade do teste com as informaes coletadas.

Testadores de Software
Os testadores encontram defeitos com o intuito de poupar tempo, reduzir
riscos, reduzir custos e aumentar a produtividade.

Testadores em geral possuem uma viso diferente dos desenvolvedores como:

pessimismo, olhar crtico, atencioso aos detalhes e experincia em encontrar
defeitos. Quando o software testador por um testador tambm temos alguns
benefcios como viso independente (sem influncia do autor), capacitao e
treinamento especfico para testar.
Infelizmente os testadores so vistos como profissionais malvados, pois, ao
invs de criarem eles realizam tarefas destrutivas, isso porque muitas vezes o
cdigo precisa ser refeito ou reconstrudo. Isso ocorre devido as diferentes
perspectivas de cada um, onde programadores procuram construir os
softwares de acordo com os requisitos dos usurios e focam em fazer esse
software funcionar, alm disso, trabalham muito tempo e muitas horas para
isso, por outro lado, testadores se preocupam que o usurio tenha um sistema
funcional e confivel. Dessa forma, muito importante que os testadores
tenham uma boa comunicao com os desenvolvedores para no causar atritos
ou constrangimentos entre as equipes. Para isso, alm de uma boa relao que
construda no dia a dia e em cada comunicao que feita entre as partes, as
informaes tambm precisam ser slidas sobre qual o defeito que est
sendo apresentado, os erros encontrados devem ser reportados de forma
neutra, focar no ocorrido ao invs na pessoa que criou, interpretar a reao da
pessoa que est recebendo a notcia e confirmar que a pessoa realmente
entendeu o que aconteceu. A informao do defeito ajuda o desenvolvedor a
encontrar o defeito o mais rpido possvel e a ampliar os conhecimentos sobre
o software.
Alm dos testadores existem tambm outros papeis associados ao teste de
software, so eles: O lder ou gerente do projeto de testes aquele que
responsvel pela liderana de um projeto de teste, seja um projeto novo ou um
projeto que est em manuteno. J o engenheiro ou arquiteto de teste o
tcnico responsvel pelo levantamento de necessidades relacionadas com a
montagem da infraestrutura de teste, incluindo o ambiente de teste, a
arquitetura de soluo, as restries tecnolgicas e as ferramentas de teste. O
engenheiro de teste tambm responsvel pela liderana tcnica do trabalho
de teste e pela comunicao entre a equipe de teste e a equipe de projeto ou
equipe de desenvolvimento. O analista de teste o tcnico responsvel pela
operacionalizao do processo de teste. Os analistas devem seguir as
orientaes do gerente de teste ou do arquiteto de teste para detalhar a forma
de execuo dos testes e as condies de teste necessrias alm de focar o
trabalho nas tcnicas de teste adequadas fase de teste trabalhada. O testador,
como j verificamos, o tcnico responsvel pela execuo de teste sempre
observando as condies de teste e respectivos passos de teste documentados
pelo analista de teste evidenciando sempre os resultados de execuo. Por fim,
o automatizador de teste o tcnico responsvel pela automao de situaes
de teste atravs de ferramentas sempre devendo observar as condies de teste
e respectivos passos de teste documentados pelo analista de teste e

automatizando a execuo desses testes na ferramenta utilizada. Normalmente

so gerados scripts de teste que permitam a execuo de ciclos de teste desde
que sejam garantidas as mesmas condies iniciais do ciclo de teste como os
valores de dados, estados dos dados, estados do ambiente, etc.

Leia mais em: Fundamentos do Teste de Software para Certificao

CTFL http://www.devmedia.com.br/fundamentos-do-teste-de-software-paracertificacao-ctfl/30708#ixzz3lFyESukY