O documento discute os benefícios e papéis do teste de software. O teste de software busca identificar defeitos e melhorar a qualidade do software, prevenindo problemas. Um bom teste requer habilidades como exploração, resolução de problemas e perfeccionismo. O teste economiza tempo, reduz riscos e custos e melhora processos e qualificações.

1. Robson Tietz de Oliveira
MBA Qualidade de Software – UNISINOS
Bacharel em Processamento de Dados - UCPEL

2.  O teste de software busca contribuir com a
qualidade do software auxiliando a prevenir
defeitos e identificando os defeitos que estão
presentes no software.

3.  Provar que o software não faz o que deveria;
 Provar que o software faz o que não deveria;
 Provar que o programa não funciona;
 Não existe programa 100% livre de defeitos;
 Ter uma visão diferente do desenvolvedor;
 Diminuir o risco para o negócio.

4.  Explorador: não ter medo de se aventurar nas
situações;
 Resolvedor de problemas:
 Incansável: testar até estar satisfeito;
 Criativo: testar nem sempre é óbvio;
 Perfeccionista: teste não tem meio-termo;
 Exercitar o julgamento: tomar decisões enquanto
testa, que afetam para melhor ou pior a qualidade do
teste;
 Diplomático: o ser humano não gosta de ter erros
apontados, mas que o erro venha do programa;
 Persuasivo: quem conserta o defeito deve entender a
importância de fazê-lo;

5.  Economiza tempo;
 Reduz riscos;
 Reduz custos;
 Melhora processos;
 Melhora qualificações dos profissionais.

6.  Teste pode demonstrar a presença de defeitos,
mas não pode provar que eles não existem.
 O Teste reduz a probabilidade que os defeitos
permaneçam em um software, mas mesmo se
nenhum defeito for encontrado, não prova que
ele esteja perfeito. Teste não mostra que bugs
não existem.
 Os testes são indispensáveis para detectar os
defeitos que ainda escapam das revisões e para
avaliar o grau de qualidade de um produto e de
seus componentes.

7.  Líder do Projeto de Testes - Técnico responsável pela
liderança de um projeto de teste específico,
normalmente, seja um projeto novo ou uma
manutenção.
 Arquiteto de Teste - É o técnico responsável pela
montagem da infra-estrutura de teste, montando o
ambiente de teste, escolhendo as ferramentas de
teste e capacitando a equipe para executar o seu
trabalho neste ambiente de teste.
 Analista de Teste - É o técnico responsável pela
modelagem e elaboração dos Casos de teste e pelos
Scripts de Teste. Pode ser que em alguns casos os
Scripts de Teste sejam elaborados pelos testadores.
 Testador - Técnico responsável pela execução dos
Casos de Teste e Scripts de Teste.

9.  Testar pode ser aparentemente simples,
porém quando olhamos com “lupa”, vemos
que existe um novo universo logo ali, e no
caso em questão, um “projeto dentro de
outro projeto”.

10.  Software não faz o que a especificação diz
para fazer;
 Software faz algo que na especificação diz
para não fazer;
 Software faz algo que a especificação do
produto não menciona;
 Software não faz algo que a especificação do
produto menciona;
 Software é difícil de entender, difícil de usar,
lento, ou simplesmente aos olhos do testador
o “usuário não gostará”.

11.  Defeitos de interface com os usuários
 Defeitos no manuseio de defeitos
 Defeitos de limites
 Defeitos de cálculo
 Defeitos de inicialização ou fechamento
 Defeitos de controle de fluxo
 Defeitos de manuseio ou de interpretação de
dados
 Defeitos de condições de disputa
 Defeitos de carga
 Defeitos de hardware ou software

12.  Defeitos da funcionalidade – Ocorrem quando o software
executa uma ação não especificada nos seus requisitos ou
quando o requisito especifica uma coisa e o software faz
outra.
 Defeitos de usabilidade – São defeitos decorrentes da
dificuldade para se navegar em uma aplicação.
 Defeitos de desempenho – O programa não atende com
rapidez necessária às solicitações do usuário,
especialmente no caso dos sistemas interativos. Existem
estudos que indicam um tempo máximo de 3 segundos
como o tempo máximo que o usuário suporta sem desviar
a sua atenção para outra coisa.
 Defeitos de saída – Os resultados apresentados pelo
software não estão conforme definido pelas especificações
fornecidas pelo usuário ou foram mal projetadas
dificultando a sua análise.

13.  Prevenção dos defeitos – O programa não se
protege das entradas de dados não previstas que
posteriormente são processadas de forma
inadequada. O software pode, por exemplo,
aceitar valores em branco em campos numéricos.
 Detecção dos defeitos – O programa não trata
(ou trata inadequadamente) as indicações de
defeitos resultados das suas operações, tais
como: overflow, flags de defeitos, etc. Nestes
casos deveria ser dado um aviso da ocorrência do
problema.
 Recuperação dos defeitos – Mesmo detectando o
defeito, o programa falha porque não trata
adequadamente a situação.

14.  O programa não consegue tratar ou trata
inadequadamente valores extremos (o maior,
o menor, o primeiro, o último, etc) ou fora
dos limites estabelecidos.

15.  O programa efetua um cálculo e produz um
resultado errado, causado basicamente por:
lógica errada, defeito de codificação e/ou
imprecisão no cálculo.

16.  Alguns programas ou rotinas devem ser
inicializados respectivamente quando usados
pela primeira vez ou sempre que são
chamadas para execução. Muitos no
momento da inicialização criam um arquivo
em disco, a ausência deste arquivo poderá
causar problemas nas etapas seguintes do
processamento.

17.  O controle de fluxo controla, em
determinadas circunstâncias, o que o
programa fará a seguir. Um defeito deste tipo
leva o programa fazer coisas erradas,
parando ou tendo comportamento
inesperado.

18.  Ocorre quando um programa tem que passar
um grupo de dados para outro programa. No
processo, os dados podem ser corrompidos
ou interpretados incorretamente. As últimas
modificações de dados podem ser perdidas
ou estar disponível no momento errado.

19.  Ocorre quando o programa espera pela
resposta dos eventos A e B, sendo que é
suposto que A sempre termine primeiro. Se
por algum problema B terminar primeiro, o
programa pode não estar preparado para esta
situação e apresentar resultados inesperados.

20.  O programa não pode suportar um pico de
serviço em um determinado momento
(estresse) ou uma carga alta de serviço por
um tempo muito prolongado. Por exemplo,
os testes previram um pico de
processamento, porém não previram este
pico por um tempo prolongado.

21.  São defeitos decorrentes da
incompatibilidade entre o programa e o
ambiente onde está sendo processado,
gerando falhas de comunicação entre ambos.

23.  Verificar ortografia das mensagens e dos
campos.
 Verificar se campos de radio button
excludentes não podem ser marcados ao
mesmo tempo.
 Verificar layout do sistema, tentar manter a
aparência mais parecida possível com o
protótipo. Além disso deve-se verificar se os
campos e tabelas estão alinhados com
relação aos outros campos.

24.  Verificar lógica das mensagens. Ex.: Campo de filtro para período entre anos ____
a ____ colocar ano _2000_ a _1500_ deverá aparecer a mensagem "O ano final
deve ser maior que o inicial" e no caso de colocar ano _1500_ a _2000_ a
mensagem não deve aparecer.
 Fazer combinações de filtros e verificar se estão sendo listados resultados
relativos aos filtros selecionados.
 Verificar a ordenação das listagem (ver especificação).
 Verificar a ordenação de campos combo box (ver especificação).
 Verificar se os campos estão habilitados ou desabilitados conforme a
especificação.
 Ficar atento aos erros de java script.
 Preencher os campos de texto com caracteres especiais e/ou caracteres inválidos.
 Se não conseguir preencher com caracteres inválidos via teclado, tentar ctrl+v e
cola com o mouse.
 Verificar se o botão limpar está limpando todos os campos corretamente.
 Campos de texto deve ser possível pesquisar com uma substring. Ex.: Para
pesquisar um funcionário com nome Ana Paula Muniz, se eu digitar na consulta a
string "Ana" deve aparecer todos os funcionários que possuam a palavra Ana,
como Ana Maria, Luciana, etc.
 Verificar na especificação quais campos já devem vir preenchidos.

25.  Preencher os campos de texto com caracteres
especiais e/ou caracteres inválidos.
 Se não conseguir preencher com caracteres
inválidos via teclado, tentar ctrl+v e cola com
o mouse.
 Verificar se os campos estão habilitados ou
desabilitados conforme a especificação.
 Ao confirmar a operação de cadastro,
verificar se apareceu uma mensagem
informando que o item foi cadastrado.

26.  No exibir, deve-se ficar muito atento à
consistência dos dados, tipo se um dado foi
inserido no cadastro ele deve obrigatoriamente
aparecer no Exibir com sua respecitiva máscara.
 Deve-se estar ciente qual o valor que deve ser
exibido no caso de um campo não ter sido
preenchido. Às vezes deve aparecer o campo
vazio outras vezes deve aparecer algum caracter.
 Verificar na tela de exibição se todos os dados
alterados foram exibidos corretamente na tela,
inclusive ficar atento às máscaras.

27.  Este deve ser o caso de teste mais rigoroso e deve ser feito com mais atenção.
 Verificar se os campos atualizados foram realmente atualizados. Esta verificação
deve ser feita tanto no exibir quanto na tela de alteração.
 Verificar se na tela de alteração se todos os campos foram carregados
corretamente.
 Executar o fluxo de alteração mais de uma vez, para garantir que nenhum dado
esteja sendo mantido na sessão.
 Verificar a atualização de campos que fazem parte de pop-up. Pois muitas vezes
as alterações que são feitas dentro do pop-up se perdem ao fechar a janela.
 Verificar se os dados cadastrados/atualizados nos pop-up estão corretos.
 Quando houver uma tabela em que seja possível inserir e remover dados dela
antes de cadastrar, realizar testes de carga para ver se os dados estão sendo
mantidos/removidos corretamente.
 Ao confirmar a operação de atualização, verificar se apareceu uma mensagem
informando que o item foi atualizado.
 Verificar se ao chamar algum pop-up se ao fechar a janela, o fluxo continua no
modo de alteração.

28.  Tentar excluir um registro, no alert de
confirmação clicar em Cancelar e depois
verificar se o registro não foi excluído.
 Tentar excluir um registro, no alert de
confirmação clicar em OK e depois verificar
se o registro foi excluído.
 Realizar uma pesquisar e verificar se a
exclusão foi realizada realmente.
 Verificar se apareceu uma mensagem
informando que o item foi excluído.

29.  Ficar muito atento aos dados que contém no
relatório, ou seja, ao fazer uma filtragem de
dados, deve-se verificar se apenas aqueles dados
selecionados é que fazem parte do relatório.
 Verificar se o layout do relatório está idêntico ao
do protótipo.
 Verificar a ortografia dos relatórios.
 Verificar questões de agrupamento das colunas
quando há dados repetidos numa mesma coluna,
geralmente esta informação está presente no
projeto de teste ou especificação.

30.  O teste de software revela a presença de
defeitos, se as exigências de qualidade de
software estão sendo seguidas e geram
métricas para verificar a efetividade e a
eficiência das atividades e desenvolvimento
de software.
 As métricas de teste tendem a indicar o
aumento no número de defeitos e problemas
no processo de desenvolvimento, indicar se
um processo está sob controle e se os
objetivos estão sendo atingidos.

31.  Reportar a situação do teste
 Avaliar a qualidade do produto
 Analisar defeitos
 Avaliar risco do projeto
 Medir o progresso contra as metas
 Melhorar as técnicas de estimativa
 Medir a eficácia do processo de
desenvolvimento
 Identificar melhorias necessárias em
processos

32.  Mantis Bugtracker – reportar defeitos
 Testlink – criar casos de teste
 Selenium IDE – automação de teste funcional

33.  Categoria: categoria que pode ser um modulo ou
funcionalidade do sistema.
 Frequência: a frequência com que o bug ocorre
 Gravidade: a gravidade do bug para a aplicação
 Prioridade: a prioridade de correção do caso de
teste
 Resumo: descrição resumida do bug
 Descrição: descrição completa do problema
 Passos para reproduzir: passos necessários para
a reprodução do bug

34.  Titulo do Caso de Teste: titulo que descreve o
que o caso de teste faz
 Objetivo do Teste: descreva o objetivo deste caso
de teste e qual será o resultado final deste caso
de teste
 Pré-condições: todas as pré-condições
necessárias para executar o caso de teste, como
estar numa estar numa tela, ter algum dado
específico, etc..
 Ações do Passo: cria um passo do teste, como
clicar sobre o botão X
 Resultado esperado: o que se espera que
aconteça, como abrir uma tela

35.  Você “grava os passos” e “reproduz”

36. Obrigado a todos!
“I LIKE BUGS!”
Material: finalbug.blogspot.com