Simplificando_Teste_de_Software_Compartilhando_experiências_Anne

SIMPLIFICANDO TESTE DE
S O F T WA R E
Compartilhando experiências
Anne Caroline Rocha

Copyright © Anne Caroline Oliveira Rocha, 2023
Todos os direitos reservados.
1ª edição – Julho 2023

Revisão: Farlley Derze
Aos meus pais –
Pelos ensinamentos que possibilitaram
a me tornar quem sou.
Ao meu esposo –
Por complementar minha vida e
partilhar experiências.
Aos meus filhos –

Por me ensinarem a ser mãe.
Aos meus irmãos –

Pelas alegrias que marcaram a minha infância.
Sumário
Sobre o livro
PARTE I - Conceitos sobre teste de software
1. O que é um software?
2. O que é teste de software?
2.1. Como alcançar qualidade em um software?
3. Em que momento os testes são realizados?
3.1. Processo de desenvolvimento tradicional
3.2. Processo ágil de desenvolvimento de software
4. Quais são os tipos de teste de software?
4.1. Teste funcional
4.2. Teste não funcional
4.3. Teste estrutural
4.4. Teste relacionado à mudança
5. Como identificar os diferentes níveis de teste?
5.1. Nível de Teste de unidade
5.2. Nível de Teste de integração
5.3. Nível de Teste de sistema
5.4. Nível de Teste de aceite
6. O que é pirâmide de automação de teste?
7. Como elaborar um Roteiro de Teste?
7.1. Localização
7.2 Objeto de teste
7.3. Caso de teste
8. Técnicas de teste
8.1. Classe de equivalência
8.2. Análise de valor limite
8.3. Tabela de decisão
8.4. Diagrama de transição de estados
8.5. Fluxograma
8.6. Teste de cobertura
8.7. Descoberta de erro
8.8. Teste exploratório
9. Onde utilizar as técnicas de teste?
10. Como reportar defeitos?
10.1. Taxonomia do defeito
10.2. Ciclo de vida do defeito
11. Como entrar na carreira de teste de software?
11.1. Gerente de testes
11.2. Analista de teste manual
11.3. Analista de automação de teste
12. Como planejar uma estratégia de teste?
12.1. Escopo
12.2. Lista de requisitos
12.3. Recursos
12.4. Cronograma
12.5. Prioridades
12.6. Indicadores
PARTE II - Relatos de experiência em teste de software
13. Como decidir se vale a pena ou não investir em teste de software?
14. Processo de desenvolvimento ágil ou tradicional?
15. A origem de um defeito e seu impacto no processo de desenvolvimento
16. Por que testar é importante?
17. Dicas para ter mais eficiência nos testes
18. Quando os testes podem ser automatizados?
19. Vale a pena investir em testes estruturais para sistemas legados?
20. O futuro dos testes e onde os testadores podem investir?
Glossário
Referências
Agradecimentos
Sobre o livro
Esta foto foi feita em meio à pandemia de 2020. Era um dos cenários que eu via todos os
dias no meu apartamento. A imagem representa as vezes que vi o sol nascer, quando acordava
bem cedinho, dedicada a escrever mais um capítulo deste livro. Me surpreendi com a cena, todos
os dias eram diferentes: o céu mudava de cor, as nuvens tinham formatos distintos, um presente
para mim. Mesmo cansada, estava focando no meu objetivo maior: compartilhar conhecimentos
com as pessoas da minha área profissional - Qualidade de software.
Escolhi essa foto porque se eu pensar de forma abstrata, consigo imaginar os prédios como
um teste caixa-preta (se você não conhece este termo, vai aprender neste livro) e quem sabe
aquele pixel vermelho em uma das janelas possa ser um bug na edição da foto. Além disso,
fotografar é uma das minhas paixões, poder compartilhar um pouco da minha arte nesse livro é
gratificante.
Tentei escrever este livro de forma que a leitura ficasse simples, para que mesmo quem
esteja iniciando na área consiga compreender os conceitos e colocá-los em prática. Fiz questão
de montar um glossário com as palavras mais técnicas, também com o mesmo objetivo de
facilitar a leitura.
Quando penso em testes de software, lembro-me dos desafios iniciais na minha carreira
quando, em 2007, na empresa onde eu trabalhava, passei de estagiária a Líder de Controle de
Qualidade logo após ter concluído a graduação em Ciência da Computação. Apesar de não saber
muito sobre o assunto, aceitei o desafio e tive que aprender o máximo que pude em pouco tempo,
para começar a liderar uma equipe de 5 pessoas.
Estudar naquela época já era um hábito, pois estava me formando na universidade, então
isso não foi um problema. A maior dificuldade que tive foi encontrar materiais em português que
eu pudesse utilizar nos meus estudos. Naquela época, não havia muita coisa, apenas livros não
acessíveis. Os que consegui ter acesso eram bem teóricos, ótimos para responder questões de
provas, mas não para aplicar no meu trabalho.
À medida que eu ia estudando, sempre tinha o hábito de fazer anotações e resumos. Então,
aproveitei esse conteúdo e iniciei minha escrita compartilhando conceitos e técnicas em um blog
sobre Teste de Software, o Grupo de Testadores de Software - GTSW [16].
Com isso, desde essa época, vem crescendo em mim a vontade de escrever um livro sobre
Teste de Software. A decisão veio a partir do momento que voltei a ensinar em um curso de teste
de software de forma online durante a pandemia de 2020, pois percebi que meus alunos tinham
muitas dúvidas sobre o assunto.
Logo, pensei em um livro que reunisse assuntos da área com uma linguagem simples, para
pessoas que estão iniciando na carreira de TI. Um livro sem muita formalidade, apenas para
transferir ao leitor alguns conhecimentos que adquiri com minha experiência profissional.
Além do conhecimento geral, sobre os principais conceitos na área de qualidade de software,
este livro também contém relatos de experiências vivenciadas tanto no mundo acadêmico,
durante o mestrado em Ciência da Computação, quanto como Analista de Qualidade em
empresas privadas e no serviço público.
Cada capítulo, deste livro, apresentará conceitos que poderão ser necessários nos capítulos
seguintes, desta forma uma leitura contínua é essencial para compreender melhor cada assunto.
Aproveite!
Anne Caroline Rocha
PARTE I - Conceitos sobre teste de software
1. O que é um software?
Antes de saber o que é teste de software, precisamos compreender o que é um software. O
software é todo e qualquer aplicação que roda em uma máquina (computador ou celular). No
computador, os softwares são conhecidos como aplicações e são utilizados para diversas
finalidades, por exemplo: a calculadora, o bloco de notas, o navegador, etc. No celular, os
softwares são chamados de aplicativos, os quais facilitam nosso dia a dia quando precisamos
pedir comida, fazer uma ligação, trocar mensagens, assistir vídeos, entre outros. É provável que
você conheça algumas dessas palavras presentes na Figura 1.1.
Figura 1.1: Nomes de softwares de computadores ou celulares.
Um software é construído pelo desenvolvedor através de uma linguagem de programação,

que é a forma que eles conseguem se comunicar com uma máquina, passando comandos lógicos
para elas realizarem. As linguagens são escritas em formato de texto, como se o desenvolvedor
pudesse escrever uma carta para a máquina, essa carta é chamada de código-fonte. Há diversas
linguagens de programação, como: Java, C, Cobol, Python, Ruby, JavaScript, etc.
A escolha de uma dessas linguagens vai depender da finalidade do software que será
construído e do ambiente em que ele será executado, ou seja, se será uma aplicação para um
computador, um aplicativo para celular ou até mesmo uma aplicação web, que dependerá da
internet para funcionar.
A Figura 1.2 apresenta um protótipo de um aplicativo de celular, no qual as pessoas apoiam

um determinado projeto através de doações. Como podemos observar nessa imagem, os
softwares geralmente possuem uma interface intuitiva, para que os usuários consigam explorar
todas as funcionalidades do aplicativo através de cliques em botões e preenchimento de
formulários.
Figura 1.2: Exemplo de aplicativo de celular.
(Fonte: https://br.freepik.com/)
Quando pensamos em um aplicativo que trata de recursos financeiros, a primeira coisa que
um usuário pensará antes de realizar a doação é sobre a segurança das transações que serão
realizadas nele. Será que um aplicativo que apresenta mensagens de erros ou dados que
desaparecem durante o seu uso, vai trazer confiança para seus usuários?
2. O que é teste de software?
Afinal, o que é testar? Esta palavra aparece em vários contextos da nossa vida cotidiana.
Certamente você já ouviu falar de um teste específico chamado test drive, que é realizado por
uma pessoa antes de comprar um carro, quando quer descobrir se vai gostar da dirigibilidade do
carro, da visibilidade dos retrovisores, do câmbio da marcha, da partida, do acelerador, do ar-
condicionado, etc. Todos estes itens podem ser verificados no test drive de um carro. Se o carro
“passou” no teste do possível comprador, então existe a chance de ele comprar o carro, caso
contrário ele provavelmente escolherá outro carro.
Assim como os carros são lançados em diferentes versões e modelos todos os anos,
recebendo mais e mais aperfeiçoamentos, os softwares também são lançados em versões. Uma
nova versão de um software pode conter um novo conjunto de funcionalidades desenvolvidas
(como um carro que agora tem um motor mais potente), ou pode adicionar apenas correções de
defeitos anteriores, pré-existentes (como um recall, que realiza reparos nos carros vendidos).
Exatamente para diminuir ao máximo a necessidade e ocorrência de recalls automotivos
(que têm um custo alto para a fabricante), muitos testes são feitos pelos engenheiros antes do
lançamento dos carros no mercado. De forma análoga, testes de software são necessários e
importantes para evitar um custo muito maior depois, quando um software estiver sendo usado
pelo usuário.
Para saber se um software será aceito após o seu lançamento, há testes que podem ser feitos
pelo próprio usuário em uma versão do software, chamada de versão beta. Os testes realizados
na versão beta, geralmente por um subconjunto de usuários reais, servem para verificar se há
defeitos no software e corrigi-los, antes de ele ser disponibilizado para um público maior.
Algumas vezes, os dados criados na versão beta são mantidos e já estão valendo para a
versão final do software. O que precisa ficar bem claro para os usuários é que aquela versão pode
conter defeitos e que eles fazem parte de um grupo seleto de pessoas que terão a oportunidade de
usar o software em primeira mão. Talvez você já tenha utilizado algum aplicativo ou jogo em sua
versão beta.
Assim como existe o teste beta, existe também o teste alfa. E quando ele é realizado? O teste
alfa é realizado por um ou mais usuários em um ambiente controlado, onde os dados realizados
no teste não são reais, ou seja, os dados não serão mantidos posteriormente.
Quando um usuário recebe uma versão do software para realizar o teste alfa ou beta, é
importante que outros testes sejam feitos anteriormente, durante o desenvolvimento do software,
de forma que a aplicação não possua falhas graves durante os testes dos usuários. Pois a
“imagem” do software é construída desde seu primeiro uso.
Nota: Lembra do test drive mencionado no início do capítulo? Embora seja realizado pelo
usuário final (o futuro motorista), qualquer defeito identificado ou opinião relatada não volta
para os engenheiros originais para o aperfeiçoamento do carro, como ocorreria se fosse um teste
beta. O carro já está “pronto” nesta versão para venda. Dessa forma, os test drives automotivos
têm objetivo de auxiliar no processo de compra do usuário, assemelhando-se às versões trial dos
softwares.
Teste de software é a arte de realizar uma simulação em um software, com o objetivo de

encontrar defeitos [1]. Caso a intenção de um testador, ao realizar os testes, seja garantir que a
aplicação não possua defeitos, esse pensamento irá revelar-se uma atividade exaustiva e sem
sucesso, pois os testes de um software só conseguem identificar a presença dos defeitos e não a
ausência deles [2].
Dependendo do software, o defeito encontrado pode ter um impacto maior ou menor para o
usuário final. Quando se trata de softwares que envolvem transações monetárias (como
aplicações bancárias ou de investimentos), que podem trazer prejuízos financeiros, ou aplicações
médicas, que podem afetar a saúde do paciente, um defeito pode ter um impacto alto na vida dos
usuários. No entanto, em jogos, utilizados para lazer, um defeito pode não trazer muitos
prejuízos para o usuário (talvez frustração seguida de um desabafo energético sobre a má
qualidade dele).
“Um software é considerado confiável à medida que o número de defeitos diminui

durante o seu uso.” - Myers [1]
Diferenciar os termos erro, defeito e falha pode ser essencial para entender melhor o que é
testar. Testar é uma atividade realizada para encontrar defeitos. Esses erros de programação
fazem a execução do software falhar: em vez de se comportar como esperado, a aplicação para
abruptamente ou apresenta um resultado incorreto. O software então possui um defeito.
Em resumo, um erro do desenvolvedor no código-fonte do software pode causar uma falha

durante a sua execução. Logo, através de testes, o defeito da aplicação será detectado. Em um
software, as vulnerabilidades podem ser causadas por erros ou pela ausência de programação que
previna certos incidentes, como: falta de segurança (quando o software está vulnerável a
ataques); falta de disponibilidade (quando o software não suporta a quantidade de usuários
simultâneos); falta de acessibilidade (quando o software não consegue ser utilizado por usuários
com baixa visão), entre outros.
Nota: Há muitos defeitos em softwares que não são identificados, os quais podem só causar
falhas na aplicação depois de muito tempo de uso. Somente quando a falha ocorre é que o defeito
se torna aparente e poderá ser corrigido. Às vezes, um software que não apresentava falhas pode
começar a aparecer pelo fato de passar a ser utilizado em contextos diferentes do convencional.
Para refletir: Se a execução de um software falhasse caso ele fosse usado de uma forma bem
específica (Ex.: clique no botão X, depois role a janela até o final duas vezes e por fim mova o
celular no sentido norte-sul), porque geralmente não é usado dessa forma, o software realmente
tinha um defeito ou foram os usuários que “criaram” os defeitos ao causarem falhas na aplicação
com a sua criatividade?
2.1. Como alcançar qualidade em um software?
Teste de software faz parte de uma área mais abrangente chamada de Garantia da Qualidade
de Software, cujo objetivo é verificar se todos os procedimentos relacionados à construção do
software estão de acordo com os padrões de qualidade estabelecidos.
De acordo com Myers, testes continuam sendo a “arte das trevas” do desenvolvimento de
software, pois ele percebeu que era comum profissionais de TI entregarem software sem a
realização de testes [1]. Costuma-se pensar que a qualidade de um software pode ser conquistada
ao realizar testes. Entretanto, testes por si só não garantem qualidade nenhuma [3].
A qualidade só é alcançada quando os defeitos reportados forem corrigidos. Com isso, fica
claro que testes é uma atividade puramente de desenvolvimento de software. Quando isso for
realmente percebido pelas equipes de teste e de desenvolvimento, os softwares poderão começar
a ser mais confiáveis e a ter mais qualidade.
Uma aplicação pode conter um conjunto de funcionalidades que determinam como um

software deverá ser executado. No caso de uma aplicação ter várias funções, ela é chamada de
sistema de informação. Um exemplo de sistema de informação é um aplicativo para realizar
compras (Figura 1.3), que tem funcionalidades para selecionar produtos, criar um carrinho,
realizar pagamento, gerenciar informações do cliente, gerenciar entrega e devolução dos
produtos.
Figura 1.3: Aplicativo para compras online.

(Fonte: https://br.freepik.com/)
Quando pensamos em uma documentação de sistema, pode não ficar claro quais
informações ela deve possuir. Geralmente não há um padrão formal de documentação para os
sistemas. Todavia, a documentação é tão importante quanto as regras para um jogo. Testar um
sistema sem documentação é como tentar descobrir como se joga um jogo sem suas regras.
Nota: Para ilustrar a complexidade, até hoje historiadores discutem como se joga o Senet, jogo
de mais de 4 mil anos atrás popular no Antigo Egito — ninguém ainda descobriu, mesmo tendo o
conhecimento claro do tabuleiro e das peças que constituem o mesmo!
Em uma documentação de sistema é essencial definir os possíveis cenários que o usuário
poderá executar no software e as regras que restringem as operações dos usuários em cada tela [4].
Essas restrições são chamadas regras de negócio, que descrevem o que o usuário pode ou não
fazer, quais campos são obrigatórios ou não e as partes do sistema que estarão disponíveis para
os usuários.
Quando não há uma documentação formal do sistema, no entanto, os testes podem ser
realizados de forma exploratória, baseando-se na experiência do testador. Mesmo nos testes
exploratórios é possível utilizar um checklist genérico, que pode ser encontrado na seção 8.7 do
capítulo 8 deste livro, para guiar o testador durante a realização dos testes, pois alguns sistemas
possuem componentes semelhantes.
Que componentes são esses? Componente é uma palavra genérica, mas quando falamos de
um sistema web, pensamos em um sistema que é acessado através de um navegador, que pode
possuir formulários de cadastro, alteração e remoção com campos de data, CPF, e-mail, com
alguns links ou botões, etc. Os campos, links e botões são os componentes.
Além dos checklists genéricos, que seriam uma documentação mais informal, a
documentação formal de teste consiste em roteiros de teste. Esses roteiros são compostos por
um conjunto de casos de teste, que descrevem todos os passos necessários para executar alguma
funcionalidade do sistema, e o resultado esperado após a execução dos passos. A elaboração
de um roteiro de teste será mais bem descrita no capítulo 7 deste livro. Um exemplo de
funcionalidade nos sistemas é a autenticação de usuários, ao permitir que apenas usuários
autorizados acessem a aplicação.
A fim de reduzir o esforço na elaboração de roteiros de teste, é possível criar casos de teste
genéricos. Por exemplo, independente do tipo de sistema, na autenticação de usuários pode-se
criar testes para:
● validar entrada com senha incorreta;
● validar entradas de campos obrigatórios;
● verificar autenticação com sucesso.
Os testes podem também ser automatizados. Desta forma, é possível repetir uma mesma
execução várias vezes, depois do esforço inicial da primeira execução pelo testador. Para criá-los
e executá-los, é necessário o uso de alguma ferramenta durante a execução dos testes. Apesar de
automáticos, todavia, eles não eliminam a necessidade de um testador ou de algum teste de
forma manual.
Durante a automatização dos testes, à medida que o sistema evolui, o testador precisa manter
os testes atualizados e rodá-los continuamente. A cada modificação do código do sistema, deve
haver também alteração nos casos de teste automatizados, para que eles continuem testando o
sistema. Dessa forma, é necessário a existência de testadores mais experientes, que configuram
os testes para detectar o maior número de defeitos e que sejam mais simples de serem mantidos.
Exemplo: A depender das necessidades e das características de cada sistema a ser testado, é
importante identificar quais tipos de testes de software serão realizados. Para exemplificar, caso
haja uma demanda de realização de testes de segurança em um sistema web, há várias estratégias
que poderiam ser utilizadas, com diferentes tipos, níveis e técnicas de teste.
Os próximos capítulos irão apresentar mais detalhes de como o teste de software pode ser
realizado na prática. Como pode ser observado no exemplo do Quadro 2.1, é importante
compreender que o teste de software pode ser classificado conforme:
● O que será testado: está relacionado ao objetivo que se quer alcançar após a
realização dos testes, conforme descrito no capítulo 4 sobre os tipos de teste.
● Onde irá testar: está relacionado à parte do sistema e ao ambiente onde os
testes serão realizados, conforme descrito no capítulo 5 sobre os níveis de teste.
● Como irá testar: está relacionado à maneira que os testes serão realizados,
conforme descrito no capítulo 8 sobre as técnicas de teste.
Quadro 2.1: Exemplo identificando o tipo, nível e técnica de teste.
O que? Tipo de teste
Esse teste tem o objetivo de Teste não-funcional.

identificar vulnerabilidades no
sistema e prevenir ataques.
Onde será testado? Nível de teste
A interface do sistema através Teste de sistema

de um navegador.
Como será testado? Técnica de teste
Será utilizado um checklist Baseado na experiência

com diversos testes de invasão.
3. Em que momento os testes são realizados?
As atividades de testes de software são realizadas durante a construção e manutenção de um
sistema. Para que essas atividades sejam realizadas de forma planejada é importante seguir um
processo. Um processo define um conjunto de atividades que podem ser executadas por cada
membro de uma equipe durante o desenvolvimento de um produto. O processo de teste de
software é parte do processo de desenvolvimento de sistemas, o qual pode ser um processo
tradicional ou ágil.
3.1. Processo de desenvolvimento tradicional

O processo de desenvolvimento tradicional contempla de forma detalhada cada uma das
atividades. Com isso, os artefatos produzidos por esse tipo de processo são mais completos e
requerem mais conformidade entre eles. Desta forma, a codificação do sistema só acontece após
a documentação ser revisada e aprovada. As atividades relacionadas à qualidade podem começar
a partir do momento em que há documentos sobre o sistema que será desenvolvido, como pode
ser observado na Figura 3.1.
Figura 3.1: Processo Tradicional de Desenvolvimento de Sistema.
Na linha referente ao papel Testador, a primeira atividade de revisar documentos pode ser
realizada através de uma revisão, inspeção ou com um checklist predefinido. Ela tem como
objetivo verificar se o documento está em conformidade com os modelos estruturais (diagramas
de classe, diagramas de caso de uso etc.) e os requisitos do sistema. Essas técnicas são
conhecidas como testes estáticos, já que não é necessário a presença do sistema em execução
para a realização desta revisão.
Em seguida, com a aprovação desses documentos, será realizada a atividade de criar
roteiros de teste para cada requisito do sistema. Esses roteiros de teste são compostos por vários
casos de teste. Quando uma parte do sistema estiver codificada e testada, via testes unitários e
revisão de código, os desenvolvedores disponibilizam um ambiente de teste para que os
testadores possam executar os testes de sistema, onde são realizados os testes dinâmicos.
O resultado das execuções dos testes é registrado em relatórios de defeitos, que indicam se
os testes passaram ou não. Esses relatórios de defeitos são passados para os desenvolvedores do
sistema, para que eles corrijam os defeitos encontrados. Após a correção dos defeitos, eles são
homologados pelos testadores, que confirmam se os defeitos foram corrigidos.
Algumas vezes, nessa atividade de homologação, novos defeitos são encontrados e precisam
ser adicionados ao relatório de defeitos. Além da confirmação dos defeitos encontrados no teste
de sistema, o cliente e os usuários também homologam o sistema, através do teste de aceitação
(teste alfa e beta). Quando o sistema passa nos testes e os requisitos foram implementados, ele
pode ser enviado para a produção, que é quando uma versão do sistema será disponibilizada
para uso geral.
Nem sempre um roteiro de teste cobre 100% das funcionalidades do sistema, por isso há
técnicas de elaboração de roteiros, que melhoram a qualidade deles reduzindo o número de casos
de teste. Essas técnicas de elaboração de roteiros podem ser vistas no capítulo 8.
O modelo tradicional de desenvolvimento de software tem muito em comum com outras

áreas de construção, como a Engenharia Civil. No entanto, a facilidade relativa com que um
software pode ser modificado, aliado com sua finalidade muito específica, fazem com que um
novo modelo de desenvolvimento necessite ser elaborado, o qual será abordado na próxima
seção.
3.2. Processo ágil de desenvolvimento de software

Considerando que os sistemas mudam de acordo com a necessidade de seus usuários, nos
processos tradicionais essas mudanças nos requisitos, que representam as fases iniciais do
processo, causam impactos diretamente nos prazos de entrega e nos custos do projeto.
Com os processos ágeis de desenvolvimento tornou-se possível lançar um produto viável

mínimo (MVP) já no início do projeto, para que ele pudesse ser validado antes mesmo de se
gastar recursos para construir uma solução completa, quando ainda não se tem a certeza de que
ele realmente atenderá as necessidades dos usuários.
A metodologia Scrum é uma das mais utilizadas nos processos ágeis de desenvolvimento
de software, pois ela descreve de forma precisa os papéis, artefatos e eventos produzidos em
cada etapa [14]. Por isso ela será utilizada para ilustrar esse tipo de processo, como pode ser
observado na Figura 3.2 abaixo:
Figura 3.2: Processo Ágil de Desenvolvimento de Sistema (Scrum).
A principal diferença entre uma metodologia ágil e uma tradicional é que na primeira uma
versão mínima do sistema já é entregue a cada ciclo e na segunda o sistema só é entregue quando
ele for completamente desenvolvido.
Com isso, no Scrum, a documentação, a codificação e os testes são realizados em cada ciclo
com o objetivo de colocar em produção uma parte estável do sistema. Dessa forma, as atividades
de teste são essenciais e precisam ser simplificadas, para que seja possível realizar os testes em
um curto espaço de tempo, no caso do Scrum, onde a duração de cada ciclo varia entre 1 e 4
semanas.
Em processos ágeis, algumas vezes a documentação não é bem detalhada e contempla

apenas o mínimo necessário para que se saiba o que precisa ser desenvolvido e testado [12]. No
Scrum, o time (equipe que pode ser composta por desenvolvedores e testadores) e o líder (SM -
Scrum Master) se reúnem com cliente ou gerente de produto (PO - Product Owner) antes de
cada ciclo (Sprint), para coletar os requisitos da parte do sistema que será desenvolvida. O
conhecimento sobre os requisitos do sistema não fica apenas com os analistas de requisitos,
como se observa no processo tradicional. Dessa forma, todo o time tem acesso ao cliente e eles
sabem exatamente o que precisa ser desenvolvido [12].
Devido ao curto espaço de tempo para realização dos testes em cada ciclo, para os testes
manuais ou automatizados pode-se criar casos de teste que foquem nas funcionalidades que
provavelmente possuem mais risco para o usuário final (ver técnicas de criação de roteiro no
capítulo 7). Dessa forma, há uma redução do custo na produção dos roteiros de teste, mas não
precisa deixar de criá-los. As funcionalidades menos críticas também precisam ser testadas e
para elas pode-se utilizar a técnica de teste exploratório [13].
A gestão de equipes em times ágeis pode ser mais simples do que em processos tradicionais,
pois o time ágil possui conhecimento de todas as etapas do processo, porque ele participa de cada
uma delas [14]. No processo tradicional, cada membro da equipe é especializado em suas tarefas e
conhece profundamente as etapas que ele participa e superficialmente as outras etapas.
No entanto, o Scrum Master no processo ágil precisa ter ciência diariamente sobre o
andamento do projeto, os impedimentos e o que está sendo produzido através de reuniões diárias
com o time. Essa é uma forma de garantir que o prazo de cada ciclo será cumprido.
O papel do testador em um time ágil nem sempre é especializado, ou seja, qualquer membro
do time de desenvolvimento pode realizar as atividades de teste. No entanto, quando existe um
ou mais membros do time que compõem pessoas especializadas em teste de sistema, a chance de
realizar testes mais eficientes é maior, ou seja, testes que permitem encontrar mais defeitos.
No cenário em que o time ágil é dividido em desenvolvedores e testadores, é importante que

os testadores participem das reuniões de planejamento com o cliente, para que possuam
conhecimento intrínseco sobre o projeto, pois nem sempre há uma documentação detalhada
sobre o sistema. Testadores em um time ágil podem ter muita influência no processo de
desenvolvimento, e mais ainda no produto desenvolvido [12].
“Não sente e espere que as coisas venham até você. Seja proativo! Nós testadores não
podemos esperar que as tarefas de teste cheguem até nós. Nós temos que nos aproximar
de desenvolvedores e clientes, nos envolver com o projeto e procurar o que fazer.” - L.
Crispin e J. Gregory [13]
Vale ressaltar, que para uma maior garantia de qualidade na realização de testes em
processos ágeis, é importante que testes automatizados sejam criados durante o desenvolvimento
do sistema [11]. Pois, por haver curtos ciclos de entrega de versão dos sistemas, seria inviável
realizar testes de regressão de forma manual a cada ciclo. Logo, os testes unitários e de
integração podem ser utilizados também para essa finalidade, ou seja, garantir que o que estava
correto, em versões anteriores, continuará funcionando [1]. Veja mais detalhes sobre isso no
capítulo 6 sobre a pirâmide de teste.
4. Quais são os tipos de teste de software?
As exigências por softwares com maior qualidade têm motivado a definição de métodos e
técnicas para o desenvolvimento de softwares que atinjam os padrões de qualidade impostos. O
ideal seria obter uma estratégia de teste com baixo custo de aplicação, mas ao mesmo tempo
com grande capacidade em revelar defeitos [5].
O interesse pela atividade de teste de software aumenta à medida que a ausência dela
influencia diretamente no custo final de um software produzido [5]. Esses custos podem ser
percebidos quando há um elevado número de defeitos detectados pelo usuário final, os quais
precisam ser corrigidos de forma imediata porque atrapalham o desenvolvimento de versões
futuras do sistema, além de impactar na imagem dele.
Uma forma de identificar quais tipos de testes podem ser realizados em um sistema é tentar
perceber o ponto de vista do usuário final, considerando os seguintes critérios:
● se o sistema apresenta informações claras para desempenhar uma tarefa;
● se as informações são corretas e consistentes, ou seja, não mudam à medida que
o sistema é utilizado;
● se o sistema é seguro o suficiente, quando há dados sensíveis e que não devem
ser expostos;
● se o sistema possui um tempo de resposta satisfatório durante a transferência de
dados, entre outros.
Esses mesmos e outros critérios podem ser explorados no momento do planejamento dos
testes, com a expectativa de tornar os testes cada vez mais robustos e de identificar
antecipadamente o maior número de defeitos possível.
Contudo, podemos observar no exemplo anterior que nem todos os critérios são relativos a
falhas de execução no sistema. Dessa forma, embora falhas causem defeitos que os testes podem
revelar, os testes também conseguem identificar outras características indesejadas relativas aos
requisitos de segurança, disponibilidade do sistema, usabilidade, entre outros.
Cada critério descrito anteriormente pode ser verificado através dos seguintes tipos de teste:
● teste funcional (caixa-preta);
● teste não funcional;
● teste estrutural (caixa-branca);
● teste relacionado à mudança (caixa-cinza).
Vale ressaltar que cada tipo de teste pode ser executado em diferentes fases do
desenvolvimento do sistema e engloba diferentes técnicas de teste, as quais podem ser realizadas
de forma automatizada ou manual.
4.1. Teste Funcional

O teste funcional tem como objetivo realizar testes em um sistema como se ele fosse uma
caixa-preta, como pode ser observado na Figura 4.1. Para este tipo de teste, os mecanismos
internos dele não são relevantes: ao passar certos valores de entradas, o sistema precisa retornar
resultados esperados. Esses resultados podem ser confirmados através da documentação de
requisitos do sistema.
Figura 4.1: Modelo representando a execução de um teste funcional.
Dessa forma, o teste funcional tem o objetivo de verificar se o sistema faz o que deveria
fazer de acordo com os requisitos elencados pelo cliente. Esses testes são realizados simulando o
uso do sistema, da mesma forma que o usuário final faria. Com isso, não há necessidade de
acessar o código do sistema durante a execução desse tipo de teste [5]. O teste funcional pode ser
realizado utilizando técnicas de teste de forma manual ou automatizada.
O custo para executar os testes funcionais é alto, até mesmo se eles forem realizados de
forma automatizada. O motivo é que esse tipo de teste depende de uma interface do sistema para
ser executado, logo qualquer alteração nela impacta diretamente os casos de testes, deixando os
roteiros de teste obsoletos, por isso precisam de atualização periódica [3].
4.2. Teste não funcional

O teste não funcional permite verificar se o sistema tem o comportamento esperado em
determinadas condições e ambientes, de acordo com os requisitos não-funcionais especificados.
Esses requisitos definem:
● onde o sistema estará disponível em navegadores e será responsivo às telas de
celular;
● a taxa de indisponibilidade, quando é aceitável que o sistema fique fora do ar
para manutenção;
● o nível de segurança desejável;
● a capacidade de usuários e de tráfego de dados, que o sistema precisa suportar;
● o tempo de resposta máximo para qualquer operação do sistema;
● a facilidade de realizar uma função no sistema em termos de número de cliques
ou facilidade de aprendizado, entre outros.
Dessa forma, é possível realizar diferentes técnicas de teste para verificar cada tipo de
requisito descrito. Esse tipo de teste pode ser realizado de forma manual ou automatizada, isso
vai depender da técnica de teste utilizada. Podemos citar as seguintes finalidades dos testes não-
funcionais (Figura 4.2), que geralmente são feitos por testadores durante o desenvolvimento do
sistema:
Figura 4.2: Modelo representando testes não funcionais.
O teste de desempenho tem o objetivo de identificar o desempenho do sistema quando

submetido a diferentes quantidades de carga. Essa carga pode estar relacionada com o número de
usuários simultâneos acessando o sistema ou à quantidade de dados que trafegam pelo sistema
em um determinado instante.
O teste de segurança tem o objetivo de detectar falhas de segurança que possam existir no
sistema. Esse teste previne que o sistema possa ser invadido por usuários mal-intencionados.
Dessa forma, tenta identificar vulnerabilidades no sistema durante uma autenticação ou prevenir
que dados sensíveis dos usuários sejam roubados.
O teste de usabilidade tem o objetivo de verificar se o usuário tem dificuldade em utilizar

um sistema pela primeira vez. Para essa técnica de teste não é necessária uma documentação do
sistema, pois o que importa é a impressão do usuário durante seu uso.
Geralmente é disponibilizado para o usuário, que irá testar um conjunto de tarefas, de modo
que ele verifique se consegue ou não realizar cada tarefa. Além disso, ele pode informar se teve
dificuldade em finalizar alguma delas. Um teste de usabilidade mais robusto pode gravar a tela e
o rosto do usuário, para perceber suas expressões durante o teste e ter um feedback mais
completo sobre o sistema.
4.3. Teste estrutural

O teste estrutural é conhecido como caixa-branca por depender do código-fonte do
sistema para que possa ser realizado, como pode ser observado na Figura 4.3. Pois o objetivo
desse tipo de teste é encontrar defeitos durante a programação do software. Dessa forma, pode-se
testar uma parte isolada do sistema ou um conjunto de componentes integrados entre si.
Figura 4.3: Modelo representando a execução de um teste estrutural.
A premissa é que uma função do sistema continue retornando valores corretos, mesmo que o
sistema evolua e novas funcionalidades sejam adicionadas.
Esse tipo de teste pode ser realizado pelo desenvolvedor, no próprio código-fonte do
sistema, mas nada impede que esse teste seja aprimorado por membros da equipe de testes. Neste
caso, novos casos de teste podem ser criados para abranger outros cenários passíveis de erros e
melhorar a cobertura dos testes.
O custo de realização do teste estrutural é baixo, pois o sistema ainda se encontra em

desenvolvimento. Além disso, quanto maior for o número de casos de teste realizados, com
diversos tipos de entradas, ele será mais eficiente. Pois pode-se abranger muitos cenários em um
curto tempo de execução, por se tratar de um teste automatizado [1].
4.4. Teste relacionado à mudança

O teste relacionado à mudança geralmente é realizado após a correção de algum defeito ou
após a adição de uma nova funcionalidade no sistema, quando ele já está sendo utilizado pelos
usuários (Figura 4.4). Seu objetivo é garantir que nenhum novo defeito seja acrescentado ao
sistema após a sua modificação ou evolução.
Figura 4.4: Modelo representando execução de testes relacionados à mudança.
De nada adianta testar um sistema, verificar que ele não possui defeitos para um conjunto de
casos de teste e após modificações no sistema, não verificar se aqueles casos de teste continuam
sem identificar defeitos.
O teste relacionado à mudança pode utilizar técnicas de teste funcional ou estrutural. Por
isso, ele é conhecido como teste caixa-cinza. Para facilitar a realização desses testes, é relevante
a utilização de testes automatizados. Entretanto, em técnicas de teste estruturais o custo de
automação é menor do que em testes funcionais, pois este depende da interface gráfica do
sistema para ser executado e requer uma frequência maior de atualização dos casos de teste [3].
As técnicas de teste que podem ser utilizadas são: teste de confirmação e teste de regressão.
O teste de confirmação pode ser realizado por testadores ou por membros de uma equipe de
atendimento ao cliente. Essa técnica tem o objetivo de verificar se um defeito encontrado no
sistema foi corrigido corretamente, antes de uma nova versão ser entregue para o usuário final.
O teste de regressão é realizado durante o desenvolvimento e geralmente é executado antes

da entrega de uma nova versão do sistema. A finalidade dessa técnica é garantir que, à medida
que o sistema evolui, o que já foi testado continua funcionando. Chamamos de regressão, porque
temos que testar novamente funcionalidades que já foram testadas antes.
5. Como identificar os diferentes níveis de teste?
Durante o ciclo de vida do desenvolvimento de um software, diferentes tipos de atividades
de teste podem ser realizadas. Independente do processo de desenvolvimento ser tradicional ou
ágil, os testes podem ser realizados em diferentes níveis.
Os níveis de teste podem ser mais bem observados em um modelo V, onde há uma
associação entre as atividades de desenvolvimento e as atividades de teste conforme o modelo V
da Figura 5.1. Na lateral direita, há 4 tipos de níveis de teste: teste de unidade; teste de
integração; teste de sistema; e teste de aceite.
Esses níveis correspondem aos 4 tipos de nível de desenvolvimento, presentes na lateral

esquerda: requisitos, especificação, projeto de software e codificação.
Figura 5.1: Modelo V que descreve os níveis de teste.
Os níveis de teste podem ser identificados de acordo com: onde o teste será realizado, quem
o realiza, o ambiente onde os testes são executados e os tipos de defeitos que eles identificam.
5.1. Nível de Teste de unidade

O teste de unidade é realizado durante a codificação e tem a finalidade de testar cada
entidade do sistema de forma independente. Por exemplo, em um sistema de calculadora
científica, os testes para cada operação matemática seriam realizados separadamente.
O nível de teste referente ao teste de unidade tem como objeto de teste:

● Código-fonte: código que descreve o que o sistema deve fazer.
● Classes: o código-fonte pode ser dividido em diferentes classes de acordo com
as entidades relacionadas ao sistema.
● Módulos: as classes do sistema podem ser divididas em módulos, os quais
agrupam o mesmo contexto.
Esse nível de teste precisa ter acesso ao código-fonte, então o teste de unidade é realizado
pelo desenvolvedor em um ambiente de desenvolvimento.
Após os testes de unidade serem executados, geralmente são encontrados defeitos dos
seguintes tipos:
● Funcionalidade: quando há erros relacionados a regras de negócio do sistema.
● Dados inconsistentes: quando houve divergência de dados em diferentes partes
do sistema.
● Lógica incorreta: quando o sistema possui erros relacionados à lógica de
programação.
● Exceções: quando o sistema não faz tratamento de um caso excepcional e para a
execução.
5.2. Nível de Teste de integração

O teste de integração é um nível de teste que complementa o teste de unidade, pois permite
realizar testes combinando diferentes componentes, para garantir que elas continuem
funcionando de forma integrada. A integração do sistema pode estar relacionada à comunicação
com um banco de dados local ou remoto, entre sistemas, com diferentes interfaces, entre outras
formas.
O nível de teste de integração tem como objeto de teste:

● Interfaces internas: quando um módulo do sistema precisa se comunicar com
outras interfaces internas (classes) do mesmo sistema.
● APIs (interfaces externas): quando a interface do sistema precisa se comunicar
remotamente com outra aplicação, para recuperar dados e exibir para o usuário.
Esse nível de teste de integração pode precisar ter acesso ao código-fonte ou não para ser
realizado, por exemplo, uma interface interna. Quando realizado pelo desenvolvedor em um
ambiente de desenvolvimento, a mesma ferramenta de teste unitário pode ser utilizada para
realizar esses testes, porém com objetivos diferentes.
Caso o teste de integração seja realizado por um testador, em um ambiente de teste, poderá
ser necessário utilizar alguma ferramenta para automatizar os testes, nesse caso o testador fará a
verificação a partir de interfaces externas, por exemplo, APIs, que se comunicam com cada
parte do sistema.
Há ferramentas que os testadores utilizam para realizar esses testes de integração. Esses
testes são escritos em linguagens de programação específicas da ferramenta selecionada, por
exemplo Supertest ou Cypress, que usam JavaScript. Como os testes realizados nestas
ferramentas usam como interface uma API, então o código de teste pode ser feito em uma
linguagem de programação independente da linguagem de programação utilizada no
desenvolvimento da API.
Uma técnica utilizada nesse tipo de teste de integração de interfaces internas são os objetos
mock. Eles têm a finalidade de simular partes do sistema que ainda não foram implementadas ou
serviços que ainda não estão disponíveis.
Por exemplo, pode haver um objeto mock que simula um cadastro de usuário, onde os dados
são gravados em arquivos temporários do sistema ou mesmo mantidos apenas na memória RAM
do computador. Dessa forma, os testes podem ser criados como se tudo estivesse funcionando.
No momento que aquela parte do sistema estiver disponível, basta trocar o objeto mock pela
classe do sistema equivalente e executar novamente os testes.
No caso das interfaces externas, elas podem se comunicar diretamente com a interface
gráfica do próprio sistema. Por exemplo, um serviço que lista todos os dados para serem exibidos
em uma tabela da aplicação. Assim, o sistema se comunica com algum serviço externo, como:
Web Service ou API REST. Por exemplo, um serviço que realiza a autenticação do usuário, onde
o usuário passa os dados de entrada, e outro sistema valida se é possível ou não autenticar.
Quando o sistema é separado por interfaces externas (ex. APIs REST) chamamos a camada
do sistema referente à interface gráfica de Frontend e a camada do sistema referente ao negócio e
acesso aos dados chamamos de Backend. Dessa forma, uma API consegue realizar a
comunicação entre essas diferentes camadas.
Após os testes de integração serem realizados, geralmente são encontrados defeitos dos
seguintes tipos:
● Falhas de comportamento: quando o sistema apresenta uma exceção e termina
a execução.
● Erros de regra de negócio: quando houve erros relacionados ao que o sistema
deveria fazer.
● Inconsistência de dados: quando houve divergência de dados durante a
transferência de dados na integração.
● Falhas de comunicação: quando não há comunicação entre a interface e o
sistema que fornece os dados.
5.3. Nível de Teste de sistema

O teste de sistema é realizado por testadores, sejam eles usuários finais ou membros da
equipe de testes. O objetivo deste teste é identificar falhas relacionadas às regras de negócio
especificadas para o sistema ou falhas de execução do sistema. Quando os testes de sistema são
realizados por usuários finais, são disponibilizados ambientes de teste, que podem ser alfa ou
beta.
O nível de teste de sistema tem como objeto de teste:

● Sistema em desenvolvimento: verificar se o sistema faz o que deveria fazer.
Esse nível de teste não necessita ter acesso ao código-fonte para ser realizado. Por isso ele
pode ser realizado por testadores, em um ambiente de teste.
Após os testes de sistema serem executados, geralmente são encontrados defeitos dos
seguintes tipos:
a execução.
● Erros de regra de negócio: quando houve erros relacionados ao que o sistema
deveria fazer.
● Inconsistência de dados: quando dados são corrompidos ou não são exibidos
corretamente.
● Problemas de ambiente: quando há erros específicos para uma plataforma, ou
seja, navegadores, sistemas operacionais, etc.
5.4. Nível de Teste de aceite

O teste de aceitação pode ser realizado pelo cliente, após o desenvolvimento, para verificar
se o que foi solicitado está realmente presente. Nesse nível de teste nem sempre é necessária uma
documentação, pois o cliente irá identificar se o que foi solicitado faz parte do sistema. Além
disso, geralmente é disponibilizado um ambiente de testes chamado "homologação" para o
cliente. Nesse ambiente, o cliente poderá executar o sistema livremente sem utilizar dados de
produção, ou seja, dados reais.
O nível de teste de aceitação tem como objeto de teste:

● Sistema em homologação: verificar se o sistema faz o que foi solicitado.
Esse nível de teste também não necessita ter acesso ao código-fonte para ser realizado. Com
isso, ele também pode ser realizado por testadores, clientes ou usuários finais.
Quando o teste de aceitação é realizado em um ambiente de homologação, por clientes ou

usuários selecionados, chamamos de Teste alfa. Ele também pode ser realizado em produção por
usuários finais selecionados, nesse caso chamamos de Teste beta.
Após os testes de aceitação serem realizados, geralmente são encontrados defeitos dos
seguintes tipos:
a execução.
● Erros em regras de negócio: quando há erros relacionados ao que o sistema
deveria fazer.
● Inconsistência de dados: quando dados são corrompidos ou não são exibidos
corretamente.
● Dificuldades de uso: quando o usuário não consegue realizar uma
funcionalidade com facilidade.
● Falhas não funcionais: quando os erros são relacionados à segurança,
disponibilidade, tempo de resposta, etc.
Assim, cada nível de teste tem seu objetivo e sua relevância, identificando falhas de
diferentes aspectos nos sistemas. Com isso, a realização de um nível de teste não anula a
necessidade de realizar os outros níveis. É importante observar que diferentes técnicas podem ser
realizadas em cada nível, inclusive se o modo de execução dos testes será automatizado ou
manual.
6. O que é pirâmide de automação de teste?
Como foi definido no capítulo anterior, durante o desenvolvimento de um software podemos

ter diferentes níveis de teste, cada um com seus objetivos. Além disso, vimos no capítulo 3, que
em processos ágeis o ideal é possuir um maior número de testes automatizados, já que os ciclos
de entrega do software geralmente ocorrem em poucas semanas, então fazer testes de regressão
manualmente seria inviável. No entanto, apenas conhecer os níveis de teste não nos dá uma
noção da quantidade de testes que deveria ser realizada em cada nível.
Os níveis de unidade e integração podem ser feitos de forma automatizada. Já os níveis de

sistema e aceitação podem ser feitos de forma manual ou automatizada. No entanto, nem sempre
a automação de todos os níveis de teste é vantajosa quando percebemos que o custo pode ser alto
à medida que os testes se aproximam da interface gráfica [12]. Por exemplo, os testes de sistema,
ao serem automatizados possuem os seguintes atributos menos favoráveis:
● Quebram com facilidade: a cada alteração da interface gráfica, pode ser
necessário atualizar os testes para que eles continuem funcionando.
● Alto custo para escrever: requer muito tempo para escrever os testes
automatizados, pois eles são complexos, já que precisam funcionar
inspecionando as telas do sistema.
● Muito tempo para execução: geralmente os testes automatizados da interface
gráfica demoram para serem executados por depender que o sistema seja
executado por completo durante os testes.
Levando em consideração os atributos menos favoráveis do teste de sistema automatizado,

Mike Cohn sugeriu que a quantidade de testes automatizados realizados em cada nível de teste
fosse baseada em uma pirâmide de teste, conforme a Figura 6.1 a seguir [12].
Figura 6.1: Modelo da pirâmide de testes automatizados.
Dessa forma a pirâmide seria composta por 3 camadas:

● Testes de unidade: ficam na base da pirâmide por serem realizados na
linguagem de programação do sistema, dessa forma são fáceis de escrever, e o
tempo de execução é em fração de segundos. Assim, a quantidade de testes
unitários deveria ser a maior parte.
● Testes de integração: ficam no meio da pirâmide e têm a finalidade de integrar
as camadas de desenvolvimento com o banco de dados. Esse teste pode ser feito
simulando algum serviço externo, que fornece dados para o sistema, ou interno
que integra os componentes do sistema. Esses testes também são fáceis de
escrever, pois podem ser escritos na mesma linguagem de programação do
sistema e possuem um alto desempenho de execução.
● Testes de sistema: ficam no topo da pirâmide, indicando que devem ser feitos
em menor quantidade do que os demais testes, pois são testes vulneráveis, por
dependerem da interface gráfica e são lentos durante a execução.
Um aspecto importante da pirâmide de teste é que os testes não precisam ser duplicados ou
triplicados em cada camada. À medida que os testes das camadas inferiores da pirâmide já
cobrem grande parte das funcionalidades do sistema, não é necessário refazer os mesmos testes
nas camadas superiores, que possuem um custo maior.
Por exemplo: um teste de integração poderia contemplar o cadastro de usuários no banco

de dados e o retorno de uma mensagem de sucesso. Até mesmo a validação dos dados de entrada
pode ser verificada (CPF, Data, etc.) e retornando suas respectivas mensagens de erro. Com isso,
o teste de sistema poderia ser realizado apenas para identificar se os elementos da interface estão
presentes, bem formatados e as mensagens para o usuário não possuem erros de ortografia.
Com isso, além dos testes automatizados previstos na pirâmide de teste, é importante que
testes de sistema manuais sejam executados de forma exploratória e em menor quantidade, pois
nem todo tipo de teste de interface pode ser automatizado, por exemplo a verificação de
ortografia, usabilidade, etc. Além deles, os testes de aceitação, também podem ser feitos de
forma manual por clientes e usuários. Se necessário, dependendo do tipo de sistema, outros testes
não-funcionais podem ser requeridos.
No caso dos testes unitários não serem bem escritos pelos desenvolvedores, isso pode levar à
necessidade de criação de mais testes nas camadas de integração e de sistema. Com isso a
pirâmide pode ser invertida, transformando-se em um cone, como pode ser visto na Figura 6.2
abaixo, demandando mais custo de realização dos testes. Quando não há tempo hábil para
automatização desses outros testes, é comum que sejam realizados apenas testes de sistema
manual de forma exploratória [11].
Figura 6.2: Modelo do cone de testes automatizados.
Uma boa prática seria capacitar a equipe de testes para investir na criação de testes
automatizados na camada de integração. Esses testes podem ser criados antes mesmo de todo o
sistema ser implementado, através de objetos mocks, descritos no capítulo anterior, garantindo
que os requisitos macro do sistema serão atendidos.
Esses testes de integração podem ser feitos em uma interface do sistema que se comunica
com a interface gráfica. Há algumas ferramentas de teste que podem ser utilizadas para os testes
de integração com API REST, como: Postman e Cypress. Isso foi explicado no capítulo 5, onde
é possível realizar os testes de integração mesmo sem conhecer a linguagem de programação do
sistema.
Em desenvolvimentos ágeis, utilizar o modelo de pirâmide de testes pode ser uma escolha,
quando se deseja ter uma integração contínua do sistema, já que para isso testes automatizados
são essenciais. A integração contínua é uma forma de disponibilizar futuras versões do sistema à
medida que novas funcionalidades são criadas, minimizando o risco das funcionalidades das
versões anteriores pararem de funcionar.
Veja na Figura 6.3 abaixo um modelo de integração contínua. Nela, observa-se que a cada
etapa de desenvolvimento, os testes automatizados são executados e uma nova versão é lançada.
Figura 6.3: Fluxo de integração contínua simplificado.
Para que a integração contínua seja efetiva, os testes automatizados são executados para
impedir ou permitir a integração de uma nova funcionalidade. Dessa forma, eles podem melhorar
a qualidade e reduzir o tempo para validar e lançar novas atualizações do sistema.
7. Como elaborar um Roteiro de Teste?
Roteiro de teste é um documento descrito pela equipe de testes, que contém um conjunto de
casos de teste necessários para realizar os testes de um determinado requisito de um sistema. Um
caso de teste é composto por uma sequência de passos a serem seguidos no sistema e um
resultado esperado. Segue no Quadro 7.1 abaixo um exemplo de caso de teste para a autenticação
de um usuário, conforme a Figura 7.1.
Figura 7.1: Tela de autenticação que permite a entrada de um usuário.

Quadro 7.1: Exemplo de caso de teste.
CT 01 - Realizar autenticação de usuário
Precondição: Usuário possuir um cadastro.
Passos: 1. Informar o e-mail do usuário
2. Informar senha do usuário
3. Clicar no botão ‘Entrar’
Resultado esperado:
1. Usuário consegue entrar no sistema.
Os testes funcionais, quando realizados de forma manual, podem necessitar da elaboração de

um roteiro de teste. A qualidade desses roteiros influencia diretamente na eficiência em detectar
falhas em um sistema. Portanto é possível melhorar a qualidade dos casos de teste através de
alguns pontos importantes, descritos a seguir, que podem ser levados em consideração.
Quando um roteiro de teste é escrito de forma objetiva, ele é facilmente executado pelo
testador. Uma prática que pode tornar um roteiro de teste mais objetivo é realizar revisões, com a
finalidade de detectar problemas de compreensão ou irrelevância nos casos de teste. Roteiros de
teste eficientes são aqueles que atingem a maior cobertura de requisitos do sistema possível e
encontram o maior número de defeitos.
Um caso de teste objetivo é aquele que possui passos referentes a uma única
funcionalidade. Um caso de teste deve ser também autossuficiente, nele deve estar contida toda a
informação necessária para executá-lo, ou seja, deve haver uma descrição sobre a precondição do
sistema para que o teste seja realizado.
É importante evitar casos de teste exaustivos, com um número muito grande de passos.
Testes grandes, que tomam muito tempo, tendem a causar dispersão no testador e assim ele
acaba perdendo o foco principal do teste.
Outra questão importante é manter a equipe de testes sempre informada sobre o andamento
dos projetos, principalmente a respeito da mudança de requisitos. Quando há uma nova versão do
documento de especificação do sistema, precisa haver atualização no roteiro de teste daquele
determinado caso de uso.
Ao aplicar boas práticas durante a elaboração de um roteiro de teste, é possível obter uma
melhoria significativa na execução dos testes. Pois os casos de teste se tornam mais consistentes
e possuem informações completas para auxiliar os testadores durante a execução. Outro
benefício é a possibilidade de reutilizar os casos de teste em outros roteiros semelhantes.
Um roteiro pode ser elaborado a partir dos documentos de especificação de um determinado
requisito do sistema, como: especificação funcional, guia de interface e modelagem do banco de
dados, etc. Roteiros de teste podem ter outras nomenclaturas, como: Projeto de Teste, Plano de
caso de teste, Especificação de Teste ou Script de Teste.
Os roteiros são importantes no momento da execução dos testes, pois o testador consegue
realizar uma sequência de passos de forma prática, sem a necessidade de consultar todos os
documentos de especificação no momento da realização dos testes. Em geral um roteiro de testes
é composto por um conjunto de Casos de teste, mas além deles pode haver também as seções de
Localização e Objeto de Teste, descritas na Figura 7.2 a seguir.
Figura 7.2: Estrutura de um roteiro de teste.
7.1. Localização
Essa seção do roteiro de teste serve para agrupar um conjunto de casos de teste à localização
da tela do sistema, na qual os testes serão executados. A localização pode ser escrita da seguinte
forma:
Tela inicial > Tela cadastro de usuário
7.2 Objeto de teste

Uma localização pode conter 1 (um) ou mais objetos de teste, onde este pode ser definido
como a ideia global de um conjunto de casos de teste. Por exemplo, na localização descrita
anteriormente, Tela inicial, um possível objeto de teste seria o Cadastro de usuário no sistema.
Outro objeto de teste para esta mesma localização poderia ser Autenticação de usuário no
sistema. Dessa forma o objeto de teste pode agrupar 1 (um) ou mais casos de teste.
7.3. Caso de teste

Um caso de teste é composto por uma descrição, por uma precondição, pelo procedimento e
pelo resultado esperado, que podem ser observados abaixo:
● Na descrição está a ideia específica do caso de teste;
● A precondição é um requisito para o comportamento do sistema antes da
execução do caso de teste;
● Nos passos estão os passos para a execução do caso de teste, que não deve fugir
do foco exposto na descrição do caso de teste;
● O resultado esperado descreve como o sistema deveria se comportar após a
execução do procedimento do caso de teste.
Exemplo: Um modelo de roteiro de teste, pode ser visualizado no Quadro 7.2:
Quadro 7.2: Modelo de roteiro de casos de teste.
Localização: Tela inicial > Tela cadastro de usuário
Objeto de teste: Cadastrar usuários
Caso de Teste: Verificar campos obrigatórios
Precondição: Sistema estar disponível
Passos:
1. Entrar na tela: Inicial > Cadastro
2. Não preencher os campos obrigatórios
3. Clicar no botão ‘Cadastrar’
Resultado esperado:
1. O sistema exibe uma mensagem solicitando o preenchimento de campos
obrigatórios.
Caso de Teste: Verificar cadastro com sucesso
Precondição: Sistema estar disponível
Passos:
1. Entrar na tela: Inicial > Cadastro
2. Preencher os campos obrigatórios
Resultado esperado:
1. O sistema exibe uma mensagem de sucesso.
Localização: Tela inicial > Tela autenticação de usuário
Objeto de teste: Autenticar usuário
Caso de Teste: Verificar login com sucesso
Precondição: Usuário possuir cadastro
Passos:
1. Entrar na tela: Inicial > Entrar
2. Preencher o e-mail e senha válidos
3. Clicar no botão ‘Entrar’
Resultado esperado:
1. O sistema realiza a autenticação do usuário.
Cada execução do roteiro deve ser guardada como histórico, para que o líder de teste tenha o
conhecimento do número de defeitos encontrados no sistema e criar indicadores e métricas de
teste para o sistema. Alguns pontos positivos sobre a criação de roteiros de teste, são:
● É possível ter controle sobre quais requisitos do sistema foram testados.
● É possível criar estratégias de teste para realizar testes mais eficientes.
● É possível selecionar um subconjunto de casos de teste para serem testados em
um teste de regressão.
Alguns pontos negativos sobre os roteiros de teste, são:

● Dependem de uma especificação de requisitos do sistema.
● Requerem um tempo de análise dos requisitos do sistema para que seja possível
criar o roteiro.
● Ficam desatualizados a cada alteração na especificação de requisitos.
Quando a equipe de testes possui muitos membros, é importante que os roteiros sejam
compartilhados, para que toda a equipe tenha acesso aos artefatos de teste. Para isso existem
ferramentas que permitem criar roteiros de teste, identificar cada atualização e gerenciar a
execução de cada roteiro de teste. Uma ferramenta gratuita e de código livre, que contém todos
esses atributos é o TestLink [17].
8. Técnicas de teste
Durante a criação de roteiros de teste, nem sempre é possível criar casos de teste para todos
os cenários existentes. Além disso, nem sempre há tempo hábil para executar uma grande
quantidade de casos de teste manualmente. É importante considerar e avaliar diferentes técnicas
de roteiros de teste a fim de criar um roteiro mais eficaz. Pode-se categorizar essas técnicas de
acordo com a seguinte estrutura presente na Figura 8.1:
Figura 8.1: Classificação das técnicas de teste.
● Técnicas baseadas na especificação:

○ Classes de equivalência;
○ Análise de valor limite;
○ Tabela de decisão;
○ Diagrama de transição de estados.
● Técnicas baseadas na estrutura:
○ Fluxograma;
○ Teste de cobertura.
● Técnicas baseadas em experiência:
○ Descoberta do erro;
○ Teste exploratório.
Para compreender melhor a relação entre uma especificação de requisitos e as estratégias de

criação de roteiros de teste pode-se observar a Figura 8.2 abaixo:
Figura 8.2: Relação entre especificação e técnicas de criação de roteiros de teste.
Uma documentação de caso de uso, por exemplo, contém informações relevantes durante a
criação de casos de teste. A interação entre cada caso de uso, com base nas pré e pós-condições,
pode ser modelada em um diagrama de estados.
A descrição dos fluxos principais, alternativos e de exceção podem ser modelados em um

diagrama de fluxograma e em cada caminho possível desse fluxo um caso de teste poderá ser
criado. Ainda na especificação dos dados que trafegam pelo sistema, como: tipo, limite,
obrigatoriedade, etc. Pode-se utilizar as técnicas de classes de equivalência ou valor limite na
criação de casos de teste.
Por fim, a definição de regras de negócio do sistema pode ser modelada em uma tabela de
decisão, a qual pode ser convertida em diferentes casos de teste. Cada uma dessas técnicas será
detalhada a seguir, nas subseções deste capítulo.
8.1. Classe de equivalência

A técnica classe de equivalência é utilizada para reduzir o número de casos de teste a um
nível controlável. Dessa forma, todas as combinações de possíveis dados de entrada são
divididas em classes. Assim, o objetivo da criação das classes de equivalência é cobrir o maior
número de requisitos com um menor número de casos de teste [5]. Observe na Figura 8.3 uma
abstração da divisão de classes.
Figura 8.3: Classes de equivalência de forma abstrata.
Uma forma de compreender melhor as classes de equivalência pode ser observando o

Quadro 8.1:
Quadro 8.1: Exemplo de classes de equivalência.
Intervalo de valores
1 classe válida 1 classe inválida
Casos de teste Valores Classes Entradas Tipo da

permitidos classe
CT01 18 a 60 anos 18 a 60 Idade = 40 Válida
CT02 < 18 Idade = 10 Inválida
CT03 > 60 Idade = 100 Inválida
No exemplo acima, considerando os valores permitidos, em um campo ‘idade’ do sistema,

foram definidas 2 (duas) classes de equivalência: valores válidos e valores inválidos. Como pode
ser observado, restringiu-se aos casos de teste CT01, CT02 e CT03, os quais são equivalentes a
realizar testes com qualquer valor dentro de cada classe. Desta forma, em vez de criar 100 casos
de teste foram criados apenas 3 representativos para as classes de equivalência.
8.2. Análise de valor limite

Considerando a técnica de classe de equivalência, é possível explorar os limites dos valores
e criar casos de teste mais eficientes. A técnica de análise de valor limite foi elaborada por
perceberem que havia uma maior chance de erros quando as entradas são referentes ao limite do
domínio [5]. Assim, no momento de escolher os valores para cada classe de equivalência, eles
serão guiados pelo valor limite. Observe na Figura 8.4 os valores do limite da fronteira no
intervalo numérico.
Figura 8.4: Apresenta valores limite em um intervalo.
Dessa forma, é possível aumentar o número de casos de teste, para que eles se tornem mais
eficientes, por terem uma maior chance de encontrar erros. No Quadro 8.2, há um exemplo de
múltiplas entradas para as idades, onde o número de casos de teste foi expandido de 3 (três) para
6 (seis) casos de testes.
Quadro 8.2: Exemplo de análise de valor limite.
permitidos classe

CT02 Idade = 19
CT03 Idade = 59
CT04 Idade = 60
Além destes 6 (seis) valores de entrada, é possível realizar um refinamento dos casos de
teste e criar outros casos de teste baseados na técnica de probabilidade de um erro ocorrer com as
seguintes entradas, conforme será apresentado no Quadro 8.3:
Quadro 8.3: Exemplo de análise de valor limite por probabilidade do erro.

permitidos classe

CT02 Idade = 19
CT03 Idade = 59
CT04 Idade = 60
CT07 Zero Idade = 0 Inválida
CT08 Negativo Idade = -18 Inválida
CT09 Branco Idade = Inválida

Nula
CT10 Inválido Idade = Inválida

ABC
Após adicionar os casos de testes referente à técnica de probabilidade do erro, no total foram
criados 10 casos de teste. Com isso, evitou-se realizar testes para cada entrada válida ou inválida,
sendo necessário apenas um subconjunto equivalente dessas entradas.
8.3. Tabela de decisão

A tabela de decisão é uma técnica que define quais ações serão executadas pelo sistema
quando houver um conjunto de entradas predeterminado. Dessa forma as regras de negócio do
sistema podem ser descritas em uma tabela, cujas colunas representam diferentes cenários. Cada
célula da tabela possui N valores de entrada (condições) e 1 saída (ações), como pode ser
observado no Quadro 8.4:
Quadro 8.4: Tabela de decisão com 4 regras.
Exemplo: critério de decisão para aplicar desconto na mensalidade dos discentes.
Regra 1 Regra 2 Regra 3 Regra 4
Condições
Casado? Sim Sim Não Não
Bom aluno? Sim Não Sim Não
Ações
Desconto (%) 60 25 50 0
A técnica de tabela de decisão pode ser utilizada para criar casos de teste de forma simples.
Basta trocar as colunas que contêm as regras por casos de teste. Em seguida, trocar as condições
por entradas e as ações por resultados esperados. Um exemplo desse tipo de tabela,
representando casos de teste, pode ser observada neste Quadro 8.5:
Quadro 8.5: Tabela de decisão convertida em casos de teste.
CT001 CT002 CT003 CT004
Entradas
Casado? Sim Sim Não Não
Bom aluno? Sim Não Sim Não

Resultados
esperados
Desconto (%) 60 25 50 0
8.4. Diagrama de transição de estados

O diagrama de transição de estados é uma técnica similar à tabela de decisão, no entanto o
foco é na transição dos comportamentos e não nas saídas do sistema. Assim, casos de testes são
baseados nas possíveis entradas que causam uma mudança de comportamento no sistema. A
Figura 8.5 apresenta um diagrama de estados para um sistema de bonificação para clientes, os
quais podem ganhar cupons de acordo com suas ações no sistema.
Figura 8.5: Diagrama de estados representando sistema de cupons para clientes.
Ao observar as possíveis entradas e as mudanças de estado do sistema, é possível

transformar cada situação em casos de teste, como pode ser observado no Quadro 8.6:
Quadro 8.6: Casos de teste baseados em um diagrama de estados.
Caso de Teste Função Evento/Entrada Resultado
Esperado
CT01 Convite amigos Amigo aceita Cupom bônus
CT02 Convite amigos Amigo não aceita Sem cupom
CT03 Cupom bônus Cupom usado Desconto
CT04 Cupom bônus Não usa em 10 dias Cupom expira
Nesta tabela pode-se observar que cada estado foi representado como uma função do
sistema, as transições são as entradas dos casos de teste e o novo estado após a transição é o
resultado esperado.
8.5. Fluxograma
A técnica de fluxograma permite criar um caso de teste para cada caminho completo do
fluxo. Assim, se o fluxo possui vários caminhos possíveis, cada caminho será transformado em
diferentes casos de teste. Por isso, pode-se considerar que essa técnica é baseada na estrutura, ou
seja, nos componentes que compõem todo o sistema. Um exemplo de fluxograma de um sistema
pode ser observado na Figura 8.6:
Figura 8.6: Fluxograma de um cadastro de discentes em sistema acadêmico.
Nesse caso, pode-se usar também uma tabela para representar o conjunto de casos de teste
para esse fluxograma. Para cada caminho do fluxo pode-se criar um ou mais casos de teste, como
descrito neste Quadro 8.7.
Quadro 8.7: Transformando um fluxograma em casos de teste.
Caso de Perfil de Caso de Uso Fluxo Resultado
Teste Usuário Esperado
CT01 Coordenador Cadastrar Principal Cadastrado

Discente com sucesso
CT02 Coordenador Cadastrar Alternativo Operação

Discente cancelada
CT03 Diretor Alterar Principal Alterado com

Discente sucesso
CT04 Diretor Alterar Alternativo Operação

Discente cancelada
8.6. Teste de cobertura

O teste de cobertura tem a finalidade de criar uma quantidade de casos de teste para garantir
que o sistema seja amplamente testado, de acordo com um percentual predefinido. A cobertura
geralmente é calculada investigando o código-fonte do sistema, onde após a realização dos
testes, identificam-se quais partes do código foram testadas e quais não foram. Há ferramentas
automáticas para calcular esse percentual, que são instaladas na própria ferramenta de
desenvolvimento do sistema, como pode ser visto na Figura 8.7.
Figura 8.7: Ferramenta que calcula o percentual de cobertura dos testes realizados em um código-fonte.
Ao final da realização dos testes, partes do código ficam marcadas nas cores verde, amarelo
e vermelho. Verde indica que passou completamente pela linha de código, amarelo indica que
não testou todas as condições em uma determinada linha e vermelho indica que os testes não
entraram naquele trecho.
8.7. Descoberta de erro

Na técnica de descoberta de erro, os testes são baseados nas experiências anteriores de um
testador. Os casos de teste selecionados contêm os testes que têm uma maior probabilidade de
detectar defeitos. Durante os testes, entradas inválidas são inseridas nos campos com o intuito de
verificar se o sistema é robusto o suficiente em condições anormais [5]. Apesar de não ser
necessário criar roteiros de teste específicos para cada sistema, os testadores podem se basear em
um checklist genérico para aplicações que possuem determinadas características. A lista do
Quadro 8.8 possui exemplos de testes genéricos que podem ser utilizados no contexto acima.
Quadro 8.8: Lista com 21 casos de teste genéricos para aplicações web.
Casos de teste genéricos
1. Layout 2. Campos obrigatórios 3. Máscara
4. Valores permitidos 5. Valores nulos 6. Valores limite
7. Caracteres especiais 8. Espaços em branco 9. Ortografia
10. Perfil de usuário 11. Autenticação 12. Eventos do mouse
13. Clique duplo 14. Navegador 15. Responsividade
16. Tempo de resposta 17. Formatação de tabela 18. Alerta de confirmação
19. Direção dos links 20. Descrição de 21. Intervalo de datas

legenda
1. Layout: identifique a presença ou ausência de elementos no layout de cada tela do

sistema.
2. Campos obrigatórios: verifique se os campos obrigatórios estão sendo corretamente

tratados. Por exemplo: ao deixar um campo obrigatório em branco, o sistema exibe uma
mensagem.
3. Máscara: verifique se os campos estão sendo preenchidos com suas respectivas

máscaras. Por exemplo: o campo CPF deve ser preenchido com a máscara NNN.NNN.NNN-NN
4. Valores permitidos: verifique se os campos estão sendo validados no caso de receberem

valores não permitidos. Por exemplo: campos numéricos não devem aceitar caracteres especiais
e/ou letras.
5. Valores nulos: verifique se um campo que só pode aceitar valor maior que zero, está
aceitando valor menor ou igual a zero.
6. Valores limite: verifique qual o valor máximo e mínimo permitido para cada campo. Por
exemplo: ao inserir um valor fora do limite, o sistema exibe uma mensagem.
7. Caracteres especiais: verifique se os campos de texto estão aceitando caracteres

especiais indevidos. Pois se o sistema processar um código HTML ou SQL, o sistema pode ficar
vulnerável a ataques.
8. Espaços em branco: num campo obrigatório, preencha com espaços em branco e

verifique se o sistema detecta que o campo estava sem nenhuma informação.
9. Ortografia: verifique a ortografia de todo e qualquer texto do sistema, inclusive de

mensagens de alerta e textos dos ícones.
10. Perfil do usuário: há sistemas que possuem diferentes perfis de usuários com diferentes
privilégios. Neste caso, é importante criar diferentes casos de teste considerando na pré-condição
o perfil do usuário. Inclusive deve haver casos de teste considerando que um usuário comum
pode não ter acesso às funcionalidades de um administrador do sistema.
11. Autenticação: quando o sistema possuir autenticação do usuário, é importante criar

casos de testes para não permitir que um usuário não autenticado acesse o sistema.
12. Eventos do mouse: realize testes que copiam textos com o mouse e colam para verificar
se estes campos estão sendo validados corretamente.
13. Clique duplo: ao criar um roteiro de teste para uma tela de cadastro, incluir um caso de
teste que verifique o comportamento do sistema quando o usuário clica duas vezes no botão
Salvar. Neste caso, o sistema não deve incluir os 2 registros, apenas 1 deles.
14. Navegador: os sistemas web geralmente possuem comportamentos diferentes quando

são visualizados em diferentes navegadores. Com isso é importante criar um caso de teste para
executar o sistema nos principais navegadores, por exemplo, Edge, Chrome, Firefox e Safari.
15. Responsividade: os sistemas web também podem ter exibições diferentes dependendo
da tela do dispositivo do usuário. Neste caso, é importante que seja criado um caso de teste para
verificar o comportamento do sistema nas principais resoluções.
16. Tempo de resposta: verifique se o tempo de resposta para carregar uma página ou um
combo box não ultrapassa o tempo máximo esperado. No caso de listas, pode ser necessário
incluir paginação para melhorar o tempo de resposta.
17. Formatação de tabela: verifique se o texto contido em uma tabela possui alguma
ordenação, paginação, se o alinhamento dos campos está de acordo com o padrão especificado.
18. Alerta de Confirmação: é importante que haja alertas de confirmação em botões, cuja
ação é de excluir ou cancelar uma operação. Criar casos de teste que verifiquem se ao clicar em
‘Não’, o sistema realmente “Não exclui” o elemento.
19. Direção dos links: verifique se os links de sistemas web estão sendo direcionados para
telas corretas de acordo com sua descrição. Além disso, pode se verificar se após o clique os
links continuam visíveis.
20. Descrição de legenda: em sistemas que possuem ícones para representar botões ou
legendas, é importante verificar se há um texto que descreva aquele ícone, seja visível ou quando
passamos o mouse.
21. Intervalo de datas: quando o sistema permite filtrar dados através de um intervalo de
datas, verifique se a data inicial não pode ser maior que a data final.
8.8. Teste exploratório

Na técnica de teste exploratório, os testes são realizados sem a presença de um roteiro.
Esses testes podem ser usados em equipes de teste de processos ágeis, quando nem sempre há
especificação detalhada do sistema ou quando não há tempo hábil para criar roteiros de teste.
Essa técnica depende da experiência do testador, pois cada teste executado é projetado na mente
do testador durante a execução dos testes. Uma desvantagem desse tipo de teste é que não é fácil
ter controle do que já foi testado.
Durante esses testes, diferentes técnicas descritas neste capítulo podem ser utilizadas, como:
tratamento de entradas com classes de equivalência e valor limite; cobertura dos requisitos com
fluxograma e diagrama de transição; ou validação das entradas com a técnica descoberta de erro.
9. Onde utilizar as técnicas de teste?
Compreender cada técnica de teste descrita no capítulo anterior é importante para decidir em
que momento do desenvolvimento do sistema elas podem ser utilizadas. Essa decisão pode
depender do tipo de especificação do sistema, do nível de teste a ser testado, algumas dependem
da arquitetura do sistema e outras dependem apenas da experiência do testador.
Quando essa análise não é feita, pode-se gastar tempo e custo do projeto e não ter o retorno
esperado. O Quadro 9.1 descreve o grau de dependência de cada técnica com os critérios
definidos.
Quadro 9.1: Exemplo de tomada de decisão sobre cada técnica de teste.

Técnica Depende de Experiência Nível de testes
especificação do testador
Equivalência Sim Média U/I/S/A
Valor limite Sim Média U/I/S/A
Tabela de decisão Sim Média U/I/S/A
Técnica Depende da Experiência Nível de testes

Documentação do testador
Transição de estados Sim Média I/S/A
Fluxograma Sim Média I/S/A
Cobertura Não Alta U/I/S/A
Técnica Depende da Experiência Nível de testes

Documentação do testador
Descoberta de erro Não Alta S/A
Exploratório Não Alta S/A

Legenda: U= Unidade; I = Integração; S = Sistema; A = Aceite.
Algumas dessas técnicas podem ser utilizadas tanto na construção de testes manuais como
também em testes automatizados e em diferentes níveis de teste. Por exemplo, pode-se utilizar as
técnicas de classe de equivalência ou análise do valor limite em testes unitários. As técnicas de
tabela de decisão, diagrama de estados e fluxograma podem ser utilizadas em testes de
integração.
Logo, a verificação da cobertura dos testes em teste automatizados é desejável. Portanto,

quanto mais casos de testes automatizados forem realizados, menor será o número de testes
manuais necessários. Para os testes funcionais, pode-se combinar várias dessas técnicas para
criar os roteiros de teste ou utilizar as técnicas de testes exploratórios e descoberta de erro, que
simulam o sistema do ponto de vista do usuário final.
10. Como reportar defeitos?
Encontrar defeitos é o principal objetivo dos testes de software, contudo não é o único. Os
testes também podem ser utilizados para indicar melhorias na interface ou confirmar que um
sistema é seguro. No momento em que um defeito é detectado, é de suma importância que seu
cadastro seja realizado. Já que os erros podem não existir mais à medida que novos dados são
inseridos na aplicação ou novas versões são lançadas.
Dessa forma, após o defeito ser registrado, é uma boa prática tentar reproduzir a falha
novamente, a fim de perceber se a descrição do defeito é suficiente para ser corrigido pelo
desenvolvedor. O uso de imagens com marcações na tela é relevante para o entendimento do
erro.
Quando houver uma documentação, vale a pena verificar se existe alguma regra de negócio
que confirme a existência do defeito. Isso permite que o testador tenha mais credibilidade sobre o
erro reportado.
No momento da descrição dos defeitos, há 6 características que ajudam no momento do

registro do defeito:
● Objetivo: o defeito precisa ser claro e objetivo, para aumentar a chance de ele
ser corrigido.
● Precisão: tente garantir que é realmente um erro e não um falso-positivo.
● Neutralizar: ao descrever os defeitos, escreva apenas fatos. Evite humor ou
emoção.
● Reproduzir: sempre que possível, reproduza o defeito ao menos 1 vez antes de
submeter para a equipe de desenvolvimento.
● Impacto: observe qual o impacto desse defeito e identifique a prioridade de
correção.
● Evidência: apresentar uma imagem e um texto com os passos para execução do
defeito pode ser essencial para que os desenvolvedores consigam corrigir o
defeito.
10.1. Taxonomia do defeito

As taxonomias representam um diagnóstico do estado do defeito detectado. Os defeitos
podem ser caracterizados de acordo com 4 taxonomias da Figura 10.1:
Figura 10.1: Taxonomia dos defeitos.
● Categoria: indica o tipo de defeito identificado.

● Situação: indica o ciclo de vida de um defeito.
● Prioridade: indica o momento que é esperado que o defeito seja corrigido.
● Severidade: indica o impacto que o defeito causa no sistema caso ele não seja
corrigido.
10.2. Ciclo de vida do defeito

A Figura 10.2 apresenta o fluxograma referente ao ciclo de vida de um defeito durante o
desenvolvimento do software. Esse ciclo inicia quando um defeito é encontrado. Em uma
ferramenta de gerenciamento de defeitos, o estado da tarefa que descreve o defeito ficará como
“Aberto”. Dessa forma, cada etapa que ele passar até ser corrigido precisa ser respeitada para que
se tenha um maior controle sobre os erros que já foram corrigidos ou não.
Figura 10.2: Ciclo de vida do defeito.
No momento em que o defeito inicia a sua correção, o seu estado fica “Em andamento”,
onde há 3 chances de estado seguinte, que são:
● Rejeitado: quando o desenvolvedor não consegue reproduzir o defeito.
● Feedback: quando o desenvolvedor possui alguma dúvida sobre o defeito e não
consegue corrigir.
● Resolvido: quando o erro é corrigido e precisa de uma nova revisão do testador
para poder fechar ou abrir novamente o defeito.
O Quadro 10.1 abaixo apresenta um modelo de reportar defeitos, independente se for

manual ou utilizando alguma ferramenta para gerenciar os defeitos.
Quadro 10.1: Modelo de descrição de defeitos.
Localização: Menu principal > Cadastro > Obras
Descrição do defeito: O sistema não exibe mensagem de erro quando campos

obrigatórios não são preenchidos.
Precondição: O usuário ter realizado autenticação no sistema.
Perfil: Engenheiro da obra
Passos:
1. Entrar na tela de Cadastro de Obras e clicar em ‘Adicionar’
2. Não preencher os campos obrigatórios.
Evidência do erro:
1. O sistema não está exibindo uma mensagem de erro solicitando o preenchimento
dos campos obrigatórios.
Resultado esperado:
1. Exibir mensagens solicitando o preenchimento de campos obrigatórios.
Imagem/vídeo: anexar uma imagem ou vídeo que represente a falha no sistema.
A imagem deve ser descritiva de forma que o desenvolvedor consiga perceber a evidência
do erro rapidamente. Para que não haja dúvidas sobre o que deve ser corrigido. Como pode ser
observado na Figura 10.3, a imagem pode ser editada incluindo textos e destaques para
referenciar os pontos de ajuste.
Figura 10.3: Exemplo de imagem que representa um bug.
Durante a detecção de um erro, mais importante que encontrá-los é garantir que o

desenvolvedor irá conseguir reproduzir e corrigir corretamente a falha. Além disso, é importante
que o defeito tenha sua validade com base em algum documento de especificação, o qual poderá
ser referenciado na descrição da “Evidência do erro”. Outra informação que pode ser relevante
na descrição do defeito é informar os dados de entrada ou perfis de usuários utilizados durante a
falha na execução do caso de teste.
11. Como entrar na carreira de teste de software?
E quem pode testar um sistema? A resposta é simples, qualquer pessoa que esteja envolvida
com o sistema. Assim, os prováveis candidatos a testador dos sistemas são: desenvolvedores,
testadores, clientes e usuários finais.
Cada tipo de testador analisará o sistema de uma ótica diferente. O cliente irá identificar se o
sistema faz o que foi solicitado. O usuário final testará a usabilidade do sistema. O
desenvolvedor verificará se o código continua funcionando a cada atualização. Já o testador
poderá analisar todas essas verificações que os outros fazem, sendo que de forma antecipada,
reduzindo custos para o projeto, utilizando técnicas e metodologias predefinidas.
“O custo de um bug encontrado no início do projeto é bem menor do que quando ele é
detectado pelo usuário final.” - Myers [1]
Para quem está querendo seguir uma carreira na área, o perfil de um testador pode ser
identificado pela sua precisão em analisar os sistemas, geralmente eles são minuciosos e atentos
a todos os detalhes.
O testador tem que conseguir interpretar bem os textos da documentação do sistema e ser
responsável por atividades dentro do processo de desenvolvimento que garantem a qualidade do
sistema que está sendo desenvolvido. Além disso, é essencial que o testador goste de se
comunicar, pois ele estará em contato com todos da equipe, seja o cliente no levantamento dos
requisitos ou desenvolvedores no momento de reportar um bug do sistema.
Quando o testador possui conhecimentos em lógica de programação de software, ele terá

habilidades desejáveis no momento de pensar em casos de testes mais robustos e que têm maior
probabilidade de encontrar defeitos. No entanto, não é necessário saber programar para conseguir
testar um sistema.
As vagas de emprego descrevem a carreira com os seguintes requisitos:

● Gerente de testes
● Analista de teste manual
● Analista de automação de teste
11.1. Gerente de testes

O gerente de testes é um papel necessário para planejar os tipos de testes que serão
realizados em cada projeto e irá se comunicar com os gerentes dos projetos para alinhar-se com
as novas demandas e planejar as atividades de teste da equipe.
Além disso, o gerente de testes define um plano estratégico de como os testes serão
realizados, quais ferramentas serão utilizadas, quais tipos de testes serão necessários. Ele também
consegue realizar métricas sobre o andamento dos testes e criar relatórios para a alta gestão da
empresa com esses dados coletados.
11.2. Analista de teste manual
O analista de teste manual tem como responsabilidade conhecer o negócio do sistema,
revisar documentação e identificar conflitos nos requisitos. Além disso, ele deve criar casos de
teste e executá-los a fim de identificar defeitos. À medida que defeitos são encontrados, ele deve
reportar e gerenciar todo o ciclo de vida desses defeitos até o seu encerramento.
11.3. Analista de automação de teste

O analista de automação de teste tem como responsabilidade criar scripts de teste
automatizados e mantê-los à medida que o sistema evolui. Além disso, ele precisa ter
conhecimento sobre os novos requisitos do sistema como também cada atualização, para que os
scripts de testes continuem sendo executados a cada iteração. Quando necessário, os defeitos
identificados pelos testes automatizados podem ser reportados e gerenciados até o seu
encerramento.
12. Como planejar uma estratégia de teste?
O plano estratégico de teste será usado durante o desenvolvimento de um software. Ele pode
ser descrito em um documento padrão ou pode ser definido em uma ferramenta de
gerenciamento de projetos. Geralmente, esse planejamento das estratégias é responsabilidade do
líder de testes. No entanto, quando não há uma equipe de testes no projeto, o plano pode ser
criado pelo líder de desenvolvimento.
As principais seções que compõem o plano de estratégias de teste são: escopo, lista de
requisitos, recursos, cronograma, prioridades e indicadores, como ilustrado na Figura 12.1.
Figura 12.1: Modelo de plano de estratégico de teste resumido.
12.1. Escopo
Define quais funcionalidades deverão ser testadas em nível macro até a entrega de uma parte
do produto. Além disso, o escopo também pode descrever o que não será testado (escopo
negativo). As informações contidas no escopo podem ser coletadas no plano do projeto, em uma
reunião com o cliente ou com o analista de sistemas.
12.2. Lista de requisitos

Define os requisitos funcionais e não-funcionais que devem ser testados.
● Requisitos funcionais: casos de uso.
● Requisitos não-funcionais: desempenho, segurança, interface, etc.
Para cada requisito definido, é necessário descrever a técnica de teste que será utilizada, para
garantir que o sistema seja testado de forma eficiente, mas atendendo os custos do projeto.
12.3. Recursos
Os recursos necessários para realizar os testes de software em um projeto precisam ser
definidos. Os recursos podem ser do tipo:
● Recursos humanos:
○ Gerente de teste;
○ Analista de teste;
○ DevOps.
● Ambientes:
○ Ambiente de teste;
○ Ambiente de homologação.
● Ferramentas de teste:
○ Open source;
○ Proprietárias.
12.4. Cronograma
O cronograma define o tempo que será necessário para realizar todas as atividades de teste
dentro de um projeto e os prazos relacionados. O cronograma da equipe de testes deve estar
alinhado com o do projeto. O cálculo do esforço para realizar as atividades de teste depende de
métricas coletadas a partir de estimativas e da base histórica.
Essas métricas precisam ser retroalimentadas à medida que novas atividades são realizadas e
os números mudam periodicamente. Uma recomendação que o líder de teste pode fazer é
solicitar que sua equipe registre as horas trabalhadas em cada atividade.
Além do tempo gasto por cada atividade, é importante ter o conhecimento do tamanho do
projeto, pois cada atividade de teste pode variar de acordo com o tamanho da especificação de
cada funcionalidade do sistema.
Exemplo: Uma funcionalidade sobre a autenticação do usuário em um sistema pode requerer

cerca de 5 casos de teste. Mas uma funcionalidade de transação bancária pode necessitar de 20
casos de teste. Logo, o tempo para elaborar o roteiro de teste varia de acordo com o tamanho da
funcionalidade. Esse tamanho pode ser percebido através da quantidade de regras de negócio que
há no caso de uso. Geralmente é necessário um ou mais casos de teste para cada regra de
negócio.
Assim, no caso de haver uma métrica para o tempo de criação de um caso de teste, será
possível estimar mais facilmente o tempo para elaboração de um roteiro de teste para uma
determinada funcionalidade.
As métricas que podem ser utilizadas para calcular o cronograma de testes são:
● Tempo de elaborar o roteiro de teste: esse tempo varia de acordo com o
número de casos de teste criados para o roteiro.
● Tempo de executar os testes: esse tempo varia de acordo com o tamanho do
roteiro e com o tipo de técnica de teste que será utilizada.
● Tempo de reportar defeitos: esse tempo depende da existência de erros no
sistema. Nesse caso, pode-se utilizar uma base histórica para saber o número
médio de erros que são encontrados em cada funcionalidade do sistema.
● Tempo de homologar um defeito corrigido: esse tempo varia de acordo com o
número de defeitos reportados.
12.5. Prioridades
A prioridade deve ser criada para definir o que precisa ser testado ou não, pois há projetos
que possuem curto prazo e baixo custo. Logo, fica inviável realizar testes funcionais manuais em
todo o sistema.
Dessa forma, pode-se encontrar uma estratégia de priorização das funcionalidades que
precisam de testes funcionais, utilizando roteiros de teste, e definição das funcionalidades que
podem ser testadas utilizando a técnica de testes exploratórios, que possuem baixo tempo e custo
de realização.
As prioridades podem ser feitas com base nos requisitos do sistema. Para isso, deve-se
avaliar o risco de uma falha acontecer no sistema. Assim quanto maior for o risco, mais bem
elaborados devem ser os testes.
A análise de riscos define risco através dos seguintes parâmetros:
● Impacto da falha sobre o sistema
● Probabilidade da ocorrência da falha
Assim, o risco é calculado pela fórmula:

Risco = Impacto x Probabilidade
As prioridades também podem ser utilizadas na ordenação dos casos de teste de acordo com
o risco. Dessa forma, no momento de um teste de regressão, pode-se definir os casos de teste que
serão testados ou não.
No Quadro 12.1, foram considerados os valores “2”, “5” e “9” para definir se a
probabilidade ou o impacto é baixo, médio ou alto, respectivamente.
Quadro 12.1: Análise de risco para casos de teste.
CASO DE TESTE IMPACTO PROBABILIDADE RISCO
CT001 2 2 4
CT002 9 2 18
CT003 9 5 45
Nota: Uma análise de risco pode ser feita pelo líder de projetos durante a elaboração do Plano de
Projeto. Nesse caso, diferentes riscos podem ser analisados, como: custo elevado do projeto,
equipe desqualificada, novas tecnologias, falta de gerência de configuração, curto prazo para o
projeto, requisitos inconsistentes, etc.
Nos quadros 12.2, 12.3, 12.4 e 12.5, por exemplo, foram analisados os riscos associados aos
requisitos de um sistema em desenvolvimento:
Quadro 12.2: Análise de risco para regras de negócio.
ATIVO - REGRAS DE NEGÓCIO
AMEAÇA (RISCO) VULNERABILIDADE (CAUSA)
Regras de negócio mudam a cada iteração Cliente indeciso
PROBABILIDADE IMPACTO GRAU DO RISCO
3 4 12
ACEITAR O RISCO MITIGAR (AÇÃO) REALIZADO
Sim Iniciar desenvolvimento após Sim
aprovação de regras
Quadro 12.3: Análise de risco para corretude dos documentos.

ATIVO - CORRETUDE DOS DOCUMENTOS
Documentação com requisitos incorretos Falta de revisão na documentação
5 4 20
Incluir tempo no projeto para
Sim revisar todos os requisitos Sim
Quadro 12.4: Análise de risco para completude dos documentos.

ATIVO - COMPLETUDE DOS DOCUMENTOS
Pouco tempo para produzir
Falta documentação para o sistema documentação completa
4 5 20
documentar todos os
Não requisitos Não
Quadro 12.5: Análise de risco para consistência dos documentos.

ATIVO - CONSISTÊNCIA DOS DOCUMENTOS
Há divergência entre as especificações e o código
do sistema Documentação desatualizada
5 4 20
Não atualizar todos os documentos Não
Como pode ser observado no exemplo acima, para cada ameaça (risco) é importante analisar
a vulnerabilidade (causa) existente que pode contribuir para cada risco acontecer. Após calcular
o valor do risco, é importante definir as ações que serão tomadas para mitigar, ou seja, reduzir a
chance daquele risco ocorrer.
Dica: Uma boa prática é transformar os quadros de análise de risco em um checklist, que pode
ser atualizado periodicamente, na coluna “Realizado”, a fim de identificar os riscos que já foram
mitigados ou não.
Alinhando a análise de riscos para ajudar na priorização dos testes, é possível também
aplicar a técnica para os casos de uso do sistema, a fim de definir a prioridade de criação de
roteiros de teste para aqueles casos de uso. Dessa forma, cada caso de uso é analisado de acordo
com os critérios: impacto, probabilidade, visibilidade, complexidade e modificações frequentes.
● Impacto (IM): se a funcionalidade possuir algum erro ou parar de funcionar, os
usuários vão ser gravemente impactados?
● Visibilidade (VI): o número de usuários que acessam essa funcionalidade do
sistema.
● Complexidade (CO): a funcionalidade possui muitas regras de negócio,

aumentando a chance de erros no sistema.
● Modificações frequentes (MF): a funcionalidade precisa ser modificada com
frequência, seja por novos requisitos ou por erros recorrentes no sistema.
● Probabilidade (PB): existe uma probabilidade maior ou menor de existir erros
nessa funcionalidade.
Quadro 12.6: Cálculo do fator de risco para casos de uso.

FATOR DE
RISCO
UC 001 - CADASTRAR CURSO 104
IMPACTO VISIBILIDADE COMPLEXIDADE ATUALIZAÇÕES PROBABILIDADE
5 5 3 5 3
Quadro 12.7: Cálculo do fator de risco para casos de uso.

FATOR DE
RISCO
UC 002 - CADASTRAR TURMA 174
7 7 6 5 5
Quadro 12.8: Cálculo do fator de risco para casos de uso

FATOR DE
RISCO
UC 003 - MATRICULAR ALUNO 259
10 10 9 5 8
Conforme pode ser observado nesses quadros acima, cada critério foi definido através de
uma escala de 0 a 10 pontos. Como há características mais críticas do que outras, a fórmula que
calcula o fator de risco utiliza a média ponderada, na qual cada critério tem seu peso específico.
FATOR DE RISCO =
(IM x P1) + (VI x P2) + (CO x P3) + (MF x P4) + (PB x P5)
Esses pesos podem mudar de acordo com cada projeto. No exemplo acima, os pesos
definidos para P1 a P5 foram 3, 10, 3, 3 e 5, nessa ordem. Outro ponto importante é definir uma
legenda para o fator de risco final, que varia entre alta, média e baixa. Assim, cada caso de uso
pode ser priorizado de acordo com seu risco. Após identificar o fator de risco de cada caso de
uso, é necessário tomar a decisão de quais tipos, níveis e técnicas de teste serão realizados em
cada situação.
12.6. Indicadores
Os indicadores de teste podem ser traçados se forem observados os fatores de risco de cada
caso de uso, dessa forma os seguintes critérios podem ser definidos:
● Prioridade em se testar os casos de usos de acordo com o valor do fator de
risco.
● Alta: maior que 150
● Média: de 115 a 149
● Baixa: menor que 115
● Quantidade de casos de teste por casos de uso.
○ Acima de 30: maior que 200
○ Até 30: de 150 a 115
○ Até 20: menor que 115
● Casos de uso que podem ser testados com teste exploratório.
○ Não: maior que 150
○ Sim: menor que 150
● Casos de uso que precisam de teste de regressão.
○ Sim: maior que 115
○ Não: menor que 115
● Cobertura dos testes automatizados para os casos de uso.
○ Acima de 70%: maior que 200
○ Até 70%: de 150 a 115
○ Até 50%: menor que 115
Além disso, os fatores de risco podem guiar para os tipos de teste a serem realizados:
● Quanto maior for
○ Impacto: então Teste de Sistema.
○ Visibilidade: então Teste de Carga.
○ Complexidade: então Teste Unitário.
○ Atualizações: então Teste de Regressão.
Ao definir os tipos de teste que serão realizados para cada caso de uso, é possível definir
também o modo de execução:
● Teste de Sistema – requisitos funcionais.
○ Modo: Manual.
○ Abordagem: Caixa-preta.
● Teste de Carga – requisito não-funcional de desempenho.
○ Modo: Automática.
○ Abordagem: Caixa-preta.
Ao concluir cada seção do plano estratégico de testes, ele deverá ser revisado
periodicamente, para verificar se as estratégias de teste, escopo, recursos e cronograma
continuam valendo para o estado em que o projeto se encontra. Pois há casos em que os
requisitos mudam, tornando necessário atualizar o plano para os novos critérios.
PARTE II - Relatos de experiência em teste de software
13. Como decidir se vale a pena ou não investir em teste de
software?
Ter ou não ter testadores para a equipe de desenvolvimento de um software é uma dúvida de
muitas empresas e líderes de projeto no momento de criar suas equipes para desenvolver um
novo sistema. Muitos ficam na dúvida se é realmente necessário contratar um testador
especializado em vez de usar um desenvolvedor da equipe para realizar os testes.
Outra dúvida recorrente, quando se resolve investir em teste de software, é sobre a

necessidade de contratar testadores para cada sistema ou testadores para todos os projetos da
empresa.
Quando a equipe de desenvolvimento realiza testes automatizados em seus códigos (teste

caixa-branca), eles ficam em dúvida se ainda é necessário um testador para fazer os testes de
sistema (teste caixa-preta).
E quando há poucos recursos financeiros para desenvolver um sistema, muitos se perguntam

se investir algum recurso em teste é realmente necessário.
Para todas as dúvidas descritas anteriormente a resposta seria: Depende! O primeiro critério
a ser analisado é a criticidade do sistema, ou seja, a empresa está disposta a pagar pelo prejuízo
causado por um defeito no sistema? Um defeito pode custar muito caro dependendo da
especialidade do sistema. Uma boa planilha de gerenciamento de riscos pode dar essa resposta.
Um modelo de planilha de riscos para auxiliar nos testes pode ser visto no capítulo 12.
O mais importante a ser levado em consideração é que em todos os casos, testes sempre
serão necessários. O que pode mudar é a forma em que se realizam esses testes. Assim como há
muitos tipos de testes de software, há também muitas estratégias que podem ser adotadas
dependendo do tipo de sistema e do processo que se está desenvolvendo. Essas estratégias
podem ser descritas em um Plano de estratégias de testes, criado antes mesmo de iniciar o
desenvolvimento do software.
No Plano de estratégias de testes pode-se definir se haverá testes de unidade realizados pelos
desenvolvedores ou não. No caso de haver testes de unidade, ainda assim existe a necessidade de
realização dos testes de sistemas, pois como foi visto no capítulo 5, cada nível de teste tem sua
finalidade e deve ser realizado de acordo com cada projeto.
Com alguns exemplos será possível entender melhor os critérios que devem ser levados em
consideração no momento de tomar uma decisão sobre os testes em um projeto.
Em um cenário em que a empresa possui 3 ou mais projetos sendo desenvolvidos

paralelamente, pode-se decidir ter pelo menos 1 testador por projeto ou ter uma equipe de testes
especializada em testar todos os projetos da empresa. Os dois casos são viáveis dependendo do
processo de desenvolvimento (ver capítulo 3) que é adotado pelos projetos.
Em um processo de desenvolvimento ágil, onde entregas são realizadas em curtos períodos

e novas funcionalidades podem ser incrementadas ao projeto à medida que novas versões são
disponibilizadas para o cliente, é um contexto que vale a pena possuir pelo menos um testador
por projeto. Pois, nesse cenário, com entregas tão rápidas, garantir que o testador estará
disponível para testar o sistema no momento exato antes de cada entrega pode ser desejável.
Além disso, quando o testador é parte de apenas um projeto, ele consegue se envolver mais com
os requisitos e poderá participar mais facilmente de todas as reuniões com o cliente.
No caso de um processo de desenvolvimento tradicional, em cascata por exemplo, os

requisitos do sistema são documentados logo após a abertura do projeto, ou seja, antes de iniciar
a etapa de desenvolvimento do sistema. Além disso, as entregas, para o cliente, são planejadas e
possuem prazos bem maiores do que em processos ágeis.
Nesse contexto, dependendo do tamanho do projeto, pode haver pelo menos um testador por
projeto, como também pode ter uma equipe de testes especializada para testar todos os projetos
da empresa, paralelamente, à medida que os projetos solicitam. No caso de haver uma equipe de
testes, um processo de teste de software bem definido é necessário, para que a equipe de testes
consiga gerenciar bem as demandas de cada projeto, garantindo os prazos planejados pelo líder
de cada projeto.
Quando há uma equipe de testes para todos os projetos da empresa, será necessário um
Líder de Testes para se comunicar com cada líder dos projetos e definir as atividades e
estratégias de teste que serão adotadas em cada projeto.
No caso de haver um ou mais testadores em cada projeto, quem será responsável por definir
atividades e gerenciar os testes será o próprio Líder do Projeto.
Os quadros 13.1 e 13.2 apresentam um comparativo entre ter testadores por projetos ou uma
equipe de testes para todos os projetos de acordo com vários critérios. Na coluna “Testador por
Projeto”, foi considerado apenas 1 testador por projeto e na coluna “Equipe de Testes” foram
considerados 1 Líder de Teste e pelo menos 2 testadores.
Quadro 13.1: Critérios de decisão para 1 testador por projeto.
Testador por projeto
Possibilidade de haver testadores experientes e capacitados.
Testadores com conhecimento detalhado sobre o projeto.
Maior facilidade em cumprir prazos específicos do projeto.
Risco alto para o projeto quando sair o testador da empresa.
Risco alto para o projeto quando o testador entrar de férias.
Maior controle sobre o momento da realização dos testes.
Maior chance de haver roteiros de teste com casos de teste

viciados, onde ambiguidades na coleta dos requisitos podem
esconder defeitos no sistema.
Maior custo com recursos humanos, quando houver mais de 6

projetos na empresa.
Quadro 13.2: Critérios de decisão para equipes de teste.
Equipe de Testes
Possibilidade de haver testadores experientes e capacitados.
Compartilhamento de conhecimento de testes dentro do

projeto.
Possibilidade de maior rotatividade de testadores.
Maior chance de encontrar defeitos, considerando que o

roteiro é criado para outro testador executar.
Necessidade de um Líder de Teste.
Necessidade de documentação detalhada do projeto.
Maior chance de haver roteiros de teste revisados.
Como pode ser observado nesses quadros, nos dois cenários há vantagens e desvantagens,
sendo que cada critério terá mais impacto dependendo da criticidade de cada projeto,
dependendo do processo de desenvolvimento adotado pela empresa e dependendo da quantidade
de recursos humanos a empresa pretende investir.
Nos dois casos, investimento em capacitação na área de teste de software é essencial para
garantir uma maior eficiência na realização dos testes, tanto com relação à qualidade dos roteiros
de teste, quanto à velocidade em realizar as atividades de teste e à quantidade de defeitos que os
testadores poderão identificar. A eficiência do testador em realizar os testes pode ser
fundamental para garantir um menor risco para o projeto.
14. Processo de desenvolvimento ágil ou tradicional?
Durante o planejamento da construção de um software, processos de desenvolvimento

precisam ser definidos para atender melhor à necessidade do projeto. Um projeto é um esforço
temporário empreendido para criar um produto, serviço ou resultado exclusivo [19].
Um projeto pode ter diferentes necessidades dependendo do tipo de software que será
desenvolvido. Antes de pensarmos qual o melhor processo de desenvolvimento que devemos
utilizar, precisamos primeiro compreender que tipo de software será produzido.
Um processo de desenvolvimento pode ser inadequado para certos tipos de projetos de
software. Uma decisão errônea pode causar transtorno em todas as pessoas envolvidas, já que a
probabilidade de o projeto não ser bem executado é alta, causando alta rotatividade na equipe,
pessoas desmotivadas, atrasos nas entregas, aplicação instável, clientes insatisfeitos, etc. [20]
Os processos de desenvolvimento tradicionais são recomendados para aplicações
construídas a partir de normas estabelecidas, cujos requisitos variam com o tempo de forma
lenta. Logo, é possível identificar os requisitos funcionais e não funcionais desde o início do
projeto. Isso permite a criação de um projeto de desenvolvimento com escopo e prazo bem
definidos, pois não haverá tantas surpresas e mudanças recorrentes durante a construção do
software.
Já os processos de desenvolvimento ágeis são recomendados para aplicações que não
possuem um escopo bem definido no início do projeto. A aplicação será adaptada de acordo com
a necessidade dos usuários à medida que versões do software forem lançadas. Geralmente, este
tipo de software tem relação com algum tipo de inovação. A inovação pode ser observada em
diferentes contextos: melhorar os procedimentos internos de uma empresa, criar um aplicativo
para uma nova técnica, modificar a forma de relacionamento entre as pessoas, etc.
Dessa forma, não existe melhor processo de desenvolvimento, existe sim o melhor processo
para cada necessidade. Então, decidir que processo de desenvolvimento do software será
utilizado durante a realização do projeto está diretamente ligado ao tipo de aplicação que será
construída. O Quadro 14.1 apresenta um resumo das características de cada tipo de processo.
Quadro 14.1: Características dos processos tradicionais e ágeis.
Características Processos Processos

tradicionais ágeis
Escopo flexível X
Escopo rígido X
Custo final definido de acordo X

com escopo inicial
Requisitos bem definidos no X
início do projeto
Erros críticos identificados nas X

fases iniciais do projeto
Entregas parciais X
No entanto, nem tudo está escrito em pedra, pois aplicações para a área de direito, que trata
de leis e normas, podem ser desenvolvidas em processos ágeis, quando o software tiver o
propósito de inovar.
Imagine uma rede social para profissionais de direito, cujo objetivo é alcançar um público a
nível nacional. Uma aplicação desta natureza, vai requerer, antes mesmo de seu
desenvolvimento, uma análise de mercado, análise do público-alvo, já que para construir esta
aplicação haverá custos variados dependendo do escopo da aplicação.
Fazer uma escolha de processo de desenvolvimento errada e não realizar nenhuma mudança
ou adaptação é corroborar com o fracasso do projeto. Quanto antes essa mudança puder ser
realizada, menores serão os custos desse projeto.
Um dos principais pontos de decisão pode ser na percepção se uma entrega parcial do
software pode atender ao seu usuário final de forma satisfatória. Você consegue se imaginar
utilizando um aplicativo do banco que realiza transações financeiras, mas não exibe o saldo da
conta?
Nesse contexto, um aplicativo de banco poderia ser desenvolvido em uma metodologia ágil
caso as entregas parciais não fossem disponibilizadas para o usuário final, mas fosse entregue
apenas para o responsável em validar cada versão do software. O desenvolvimento continuaria
sendo realizado em ciclos, mas sem impactar o cliente do banco. Então, quando a aplicação
atingisse o escopo adequado, ela seria entregue para os clientes do banco.
Vale refletir se nesse cenário realmente foi adotado um processo ágil, já que os clientes do
banco só teriam contato com a aplicação quando ela estivesse pronta. Se a aplicação não atender
às necessidades de seus clientes, devido a erros ou mudanças de requisitos no software, essa
metodologia ágil realmente foi executada? Já que as entregas parciais para o usuário final não
foram realizadas, será que era apenas uma metodologia tradicional mesclada com ágil?
15. A origem de um defeito e seu impacto no processo de
desenvolvimento
Durante o processo de desenvolvimento de um software, independente do modelo de
processo utilizado, podemos identificar defeitos em cada uma de suas etapas. De forma
generalizada, um processo contempla as seguintes etapas descritas na Figura 14.1:
Figura 14.1: Etapas de um processo de desenvolvimento de software.
● Definição dos requisitos do software: o analista de requisitos documenta o

sistema a ser desenvolvido, criando a documentação e protótipo do que será
entregue.
● Implementação do software: o desenvolvedor define a arquitetura do software,
desenvolve o sistema e realiza os testes estruturais.
● Validação do software: o analista de qualidade e o cliente realizam testes para
verificar e validar se o sistema não possui defeitos e se atende às necessidades
dos usuários.
● Entrega do software: o usuário final utiliza o sistema desenvolvido e verifica
se ele atende às suas necessidades.
● Manutenção do software: todos os papéis envolvidos durante o processo de
desenvolvimento farão a manutenção do sistema, para realizar melhorias e
correções que possam ocorrer.
Apesar da origem de um defeito ocorrer em qualquer uma dessas etapas, em cada etapa o
defeito terá um esforço e um impacto diferente para o processo de desenvolvimento. O esforço
pode ser mensurado pelo custo de identificação e de correção do defeito. Já o impacto pode ser
mensurado através do efeito colateral causado por aquele defeito, por exemplo, confiabilidade do
software após a entrega. O gráfico da Figura 14.2 apresenta a relação entre o impacto de um
defeito e o esforço para mitigá-lo nas diferentes etapas do processo de desenvolvimento.
Figura 14.2: Gráfico de impacto x esforço de um defeito nas etapas do processo de desenvolvimento de software.
Na etapa de definição de requisitos, quando o software ainda está sendo documentado,

defeitos podem ser identificados através de técnicas de inspeção, revisão, elaboração de cenários
de teste e criação de protótipos de tela. Estas técnicas podem garantir uma melhor compreensão
do sistema. Pois é possível realizar uma simulação antes mesmo do sistema ser desenvolvido,
trazendo um feedback dos usuários e corrigindo os defeitos ainda na primeira etapa. Isso leva a
um menor esforço e impacto para o processo.
Na etapa de implementação do software, defeitos podem ser identificados pelo

desenvolvedor, através de técnicas de revisão de código ou de testes estruturais. Desta forma, os
defeitos são corrigidos dentro da mesma etapa e não se propagam para outras etapas do processo.
Neste caso, o esforço para correção do defeito não é tão alto quanto nas etapas posteriores e o
impacto é reduzido já que o sistema ainda não foi entregue para o usuário final.
Na etapa de validação do software, o esforço de correção de um defeito é maior que nas

etapas anteriores, mas existe uma diferença neste esforço dependendo se é um erro que ocorre
em alguma parte nova do sistema ou se ocorre em uma parte que já tinha sido desenvolvida. No
primeiro caso, o defeito será corrigido de forma mais rápida, já que o desenvolvedor tem total
controle do código produzido. No segundo caso, aquele defeito pode demorar um tempo para ser
corrigido, pois ele precisa ser planejado e priorizado, além disso o desenvolvedor não terá muita
familiaridade com aquele código. O impacto daquele defeito ainda é menor do que quando o
defeito é encontrado nas etapas posteriores a esta.
Na etapa de entrega do software, o defeito geralmente é encontrado pelo usuário final.
Logo, o impacto é bem maior que nas etapas anteriores, já que nesta etapa um defeito pode
representar uma falta de confiança no sistema, por parte dos usuários. Com relação ao esforço de
correção, ele é alto, pois aquele defeito poderá atrasar a entrega de novas funcionalidades, já que
ele precisará ser priorizado, por ter sido detectado pelo usuário.
Na etapa de manutenção do software, o defeito poderá ser encontrado por todos os

envolvidos nas etapas de desenvolvimento do software. O esforço e o impacto são bem maiores
do que nas etapas anteriores. Pois esse defeito irá impactar no cronograma de entrega do sistema,
poderá trazer prejuízos para o usuário final e ser difícil de ser corrigido, necessitando de
atualização do código-fonte do sistema já desenvolvido.
Ao compreender a origem de um defeito e o impacto no processo de desenvolvimento,

percebemos o quanto é importante detectá-los nas primeiras etapas do processo, por serem mais
fáceis de serem resolvidos. Já que para os defeitos identificados após a etapa de entrega não
existe um momento previsto para sua correção, eles precisarão ser priorizados e impactar
diretamente nas futuras entregas do sistema. Logo, utilizar técnicas de teste que possam ser
realizadas para detectar o maior número de defeitos até a etapa de validação é a melhor saída
para garantir a qualidade e menor custo para construção daquele sistema.
16. Por que testar é importante?
Algumas vezes as atividades de teste não são valorizadas. Isso porque os testes geralmente
são feitos apenas após o desenvolvimento do sistema e nem sempre a equipe de testes tem
conhecimento das alterações dos requisitos ou das novas funcionalidades que surgem durante o
desenvolvimento.
Com isso, alguns defeitos ou sugestões de melhoria não são atendidos, por já terem sido
descartados durante o desenvolvimento. Os defeitos que realmente são aceitos se transformam
em tarefas fora do escopo, pois não tinha como prever a quantidade de defeitos que o sistema iria
possuir na versão, podendo causar um atraso na entrega do sistema para o cliente.
Para que um testador consiga demonstrar a importância dos testes de software, é necessário
que ele:
● tenha conhecimento aprofundado sobre testes, para que ele consiga argumentar
sobre a importância dos testes;
● perceba que testes fazem parte da etapa de desenvolvimento, de forma que o
testador se envolva com todas as etapas iniciais de aquisição do sistema,
desenvolvimento, como também entrega e feedback dos usuários.
Quando o conhecimento sobre testes é aprofundado, ele percebe que há muitos tipos de teste
e que cada um serve para uma finalidade diferente. Além disso, os testes podem ser realizados
em diferentes níveis do desenvolvimento.
Durante o desenvolvimento do sistema, os testes podem ser realizados pelos

desenvolvedores, através dos testes unitários. Os testadores podem se envolver com os testes de
integração, antes mesmo dos desenvolvedores implementarem as funcionalidades do sistema,
utilizando objetos mocks.
Dessa forma, haverá uma parceria entre testadores e desenvolvedores, pois os testes podem
ajudar na construção de sistemas corretos, reduzindo o retrabalho de corrigir defeitos que só
iriam aparecer quando o sistema já estivesse implementado [3].
Quando um software é entregue para o cliente sem testes, ele pode causar problemas em
diferentes contextos. Abaixo estão alguns argumentos para motivar a realização de testes:
1. Quando um produto não é testado, há uma chance deste produto possuir

defeitos, assim este produto pode não satisfazer às necessidades do cliente.
2. O cliente quando não está satisfeito com o produto pode não contratar
novamente a empresa.
3. Quando não há qualidade no produto, a empresa fica com imagem negativa,
logo é necessário mais investimento em marketing.
4. Se os erros são encontrados pelo cliente, o custo para corrigir estes erros é
muito maior do que quando o sistema ainda está em desenvolvimento [1].
5. Com os testes, novos clientes poderão ficar interessados em seus sistemas
devido às recomendações.
6. Com os testes, os desenvolvedores, apesar de parecer que não, ficam bem
satisfeitos e motivados com os elogios ao sistema feitos pelo cliente, já que
ele não encontra muitos defeitos.
7. Com os testes, minimiza-se a necessidade de atender telefones e responder
demandas para ajudar os usuários a utilizarem o sistema, logo, menor custo
com central de atendimento ao usuário.
Assim, quando há uma equipe de teste para testar o sistema, todos saem ganhando: o dono
da empresa (menos gastos com marketing e mais prestígio para a empresa), o cliente (satisfação
e confiança no sistema), os usuários (conseguem usar o sistema de forma confiável), os
desenvolvedores (motivados com o trabalho por criarem sistemas com qualidade) e os testadores
(mais reconhecimento).
Como foi relatado nos capítulos anteriores, o custo para corrigir um defeito após o
desenvolvimento do sistema é bem mais alto, pois quando um sistema é entregue para o cliente
sem ser verificado pela equipe de testes, o sistema passará para a etapa de 'manutenção'. Nesta
etapa, geralmente, a equipe que desenvolveu o sistema já pode ter sido alocada para um novo
projeto.
Como não é possível prever a demanda de defeitos futuros que podem ocorrer no sistema, é
provável que haja uma sobrecarga de novas tarefas para os desenvolvedores de projetos antigos.
Assim, o novo projeto poderá atrasar, pois parte da equipe terá que ser alocada novamente ao
projeto antigo.
Além disso, se parte da equipe que desenvolveu o sistema não trabalhar mais na empresa,
então o custo para corrigir aquele defeito será ainda maior, pois um outro desenvolvedor pode ter
uma certa dificuldade para corrigir esses defeitos, logo isso poderá demandar mais tempo e
consequentemente mais custo para a empresa.
17. Dicas para ter mais eficiência nos testes
Realizar testes de software é uma atividade que requer criatividade. Dessa forma, encontrar
técnicas que auxiliem na eficiência dessa atividade pode trazer bons resultados na identificação
de defeitos nos sistemas. A seguir foram descritas algumas dicas que podem servir como
orientação para a tomada de decisão em diversas situações:
1. A atividade de um testador pode iniciar o quanto antes com a revisão da documentação

do sistema. Isso pode diminuir bastante o custo do projeto final, evitando bugs futuros. Além
disso, preparar os roteiros de teste antes do software estar pronto pode economizar tempo valioso
no final do projeto.
2. O tipo de teste a ser realizado em um projeto deve ser adequado ao processo de

desenvolvimento. A escolha da melhor técnica e nível de teste vai depender de diferentes
aspectos, como: tamanho do sistema, quantidade de desenvolvedores, o risco para o negócio, o
prazo do projeto, etc.
3. Analise se a equipe de testes na sua empresa não é suficiente para garantir a qualidade de
todos os projetos, ou se o líder de projeto acha que não será necessário testar o sistema por falta
de tempo e prioridade.
4. Uma vez que dispomos de recursos humanos finitos alocados em tempo finito para os
projetos, a atividade de testes deve ser delimitada. Temos que garantir que o “custo da realização
de testes” seja bem menor do que o “custo de um defeito aparecer para o usuário”. Vamos
analisar as seguintes listas de custos referentes a defeitos nos sistemas:
a. Custos da realização dos testes:
● Alocação de pessoal especializado;

● Manutenção de documentação, roteiro de testes, testes automatizados
executáveis, etc.;
● Correção dos defeitos encontrados pela equipe de desenvolvedores (se não for
para corrigir, não há sentido em ter testado);
● Custo referente ao maior prazo de entrega do produto;
● Custo adicional referente ao risco de inserção de novos defeitos pelos
desenvolvedores durante as correções de defeitos citados no item anterior,
dentre outros;
b. Custo de um defeito aparecer para o usuário:
● Custo da atividade da área fim interrompida;

● Custo de imagem que o sistema vai sofrer com o usuário;
● Custo de atendimento e tempo de solução dele;
● Custos de correção de inconsistências no banco de dados referentes ao defeito,
dentre outros;
Assumindo que os testadores irão testar as funcionalidades mais críticas e importantes
primeiro, é natural que haja um “ponto de corte” a partir do qual “não vale a pena” testar mais.
Se o custo de realização dos testes está ficando alto demais, reavalie qual a melhor técnica
de teste para aquele cenário ou considere encerrado o trabalho de testes.
“Custo convertido em qualidade que realmente atende à necessidade do cliente é

investimento. Custo convertido em qualidade que o cliente não precisa é desperdício.” -
Ricardo Vargas [18]
5. Às vezes não é possível testar tudo de um software quando ele possui muitas
funcionalidades, então é importante criar alguma regra de prioridade para as funcionalidades a
serem testadas. Análise de risco e a frequência do uso das funcionalidades é uma boa maneira de
priorizar os requisitos.
6. Para justificar a necessidade de testes em um projeto, é importante saber qual é o custo e

quão eficiente é a equipe de testes. Para ter este conhecimento, é necessário analisar e mensurar.
Métricas são informações que podem ser colhidas durante o desenvolvimento do projeto,
como: número de cenários, número de defeitos encontrados, tempo gasto para executar um
roteiro de teste, entre outros. Quanto antes for iniciada a medição dos dados melhor será a
avaliação dos resultados.
7. À medida que um software evolui e testes são realizados antes do lançamento de cada
versão, a tendência é que os defeitos comecem a diminuir e o sistema comece a ser considerado
mais confiável.
Se nenhum critério tiver sido definido, os testadores irão continuar seus testes mesmo
quando defeitos raramente forem encontrados, tornando o custo dos testes maior do que o
necessário.
Isso significa dizer que pode existir um ponto de "estabilidade" no sistema, devido à sua
qualidade ou devido à diminuição do ritmo de manutenção dele. Se isso ocorrer, considere
orientar os testadores para realizar os testes apenas nos cenários mais críticos do sistema.
8. Organize bem os roteiros de teste e gerencie cada atualização deles, pois é bem provável
que eles serão reutilizados na fase de manutenção e evolução do software. Isto poderá
economizar parte do esforço de realizar o teste de regressão.
9. Assegure que a comunicação entre os membros das equipes de desenvolvimento e teste de

software seja clara e objetiva, para evitar que erros sejam cometidos por falta de entendimento
sobre uma funcionalidade. Defina padrões na descrição dos bugs, para evitar que cada membro
da equipe faça de outra forma e coloque menos informações que o necessário para o defeito ser
reproduzido pelo desenvolvedor e para aumentar a legibilidade do texto. Utilizar uma ferramenta
de gerenciamento de bugs é importante para conseguir priorizar os bugs e perceber o ciclo de
vida de cada bug, desde sua abertura até o encerramento.
10. Compartilhe conhecimentos com os outros membros da equipe, documentando cada

processo ou atividade de teste, garantindo que todos os membros da equipe saibam o que
precisam fazer. Como garantir a qualidade dos sistemas, se não há qualidade nos processos
internos da equipe de testes? Difícil, não acha?
Sempre que possível, capacite sua equipe. Assim, ela irá trazer melhores resultados e ficará
mais motivada para continuar trabalhando com teste de software.
11. Quando não se souber qual o melhor tipo de teste ou técnica que deverá ser utilizada
num projeto, a melhor forma é começar pelo mais simples, ou seja, fazer o mínimo de atividades
possível para atender às necessidades do projeto. Por exemplo, se não há documentação
suficiente para criação de roteiros de teste, então a estratégia pode ser realizar testes
exploratórios.
Além disso, o processo não deve ser cansativo para a equipe de teste, ou seja, muitas
atividades repetitivas e que não trazem eficiência para os testes. Escolher a melhor abordagem é
essencial para garantir a qualidade dos sistemas desenvolvidos e reduzir o custo para realizar os
testes.
18. Quando os testes podem ser automatizados?
Há muitas maneiras de automatizar o teste de software, a primeira e mais comum é através

do teste estrutural, no nível de teste unitário. Este tipo de teste geralmente é realizado pelo
desenvolvedor. Ele é útil para garantir que um componente do sistema não parou de funcionar
quando uma nova parte do sistema foi desenvolvida.
No entanto, é possível automatizar o teste funcional também. Ele tem a finalidade de

verificar se o sistema, do ponto de vista do usuário final, não apresenta defeitos em seu
funcionamento. Assim, esse tipo de teste é realizado a partir das telas, campos e botões do
sistema.
É comum imaginar um mundo ideal quando pensamos em um sistema que tenha todos os
seus testes automatizados. Então o trabalho de realizar testes se resumirá apenas à máquina.
Contudo, dependendo do sistema, é necessário planejar o momento certo de realizar esses testes
funcionais automatizados.
Se num cenário em que o sistema está sendo desenvolvido e possui algumas versões em
produção, e o cliente está sempre trazendo novas funcionalidades, melhorias na interface,
retirando outras funcionalidades, então este não será o melhor momento para automatizar os
testes funcionais.
Pois, neste caso, a interface do sistema sofrerá constante alteração, logo os testes terão que
ser atualizados frequentemente, gerando um grande retrabalho em manter esses testes [3]. Neste
cenário, é recomendável os testes estruturais automáticos, com testes unitários feitos pelos
desenvolvedores e testes de integração que podem ser feitos por desenvolvedores e testadores.
Dessa forma, o melhor momento para realizar os testes funcionais automáticos será com o
objetivo de realizar teste de regressão. Isso ocorre quando se tem um sistema que já está em uso,
com versões estáveis e com poucos defeitos. Pois, nesse caso, a interface do sistema irá sofrer
poucas alterações, então o custo de manter os testes automatizados funcionais será menor.
Há ferramentas para realizar os testes funcionais automatizados, para isso é necessário

verificar quais as tecnologias de suas interfaces: desktop, web ou dispositivos móveis.
Antes de utilizar qualquer ferramenta para automatizar os testes, é necessário analisar vários
fatores que irão definir o sucesso ou não dos testes. Algumas ferramentas possuem limitações e
não conseguem testar a interface de algumas aplicações, neste caso não faz sentido utilizá-las.
É importante destacar que o teste automatizado pode ter um baixo custo de execução (ex. no
nível de unidade), mas em todos os níveis há um alto custo de manutenção. Pois para que ele se
mantenha executando durante o ciclo de vida do sistema, ele precisa estar atualizado. Quando
essa manutenção não ocorre, muitas vezes os testes são descartados, pois passam a detectar erros
que não são erros, são apenas testes desatualizados.
Para garantir eficiência e manutenção desses testes automatizados é importante que eles
sejam adicionados a um ciclo integrado e de entregas contínuas de sistemas (CI/CD - Continuous
Integration / Continuous Delivery).
Em um processo de desenvolvimento com integração contínua, os testes não são esquecidos

e podem ser executados antes do lançamento de uma nova versão do sistema. Mesmo que um
teste esteja desatualizado, haverá uma demanda de atualização dele, já que o sistema só será
disponibilizado quando aqueles testes automatizados passarem.
Além da importância do CI/CD, há outros fatores críticos [7] que melhoram a elaboração e
manutenção dos testes automatizados:
1. Implementar códigos de testes reusáveis, com orientação a objeto, com

polimorfismo, métodos bem escritos, um código limpo e de fácil
compreensão.
2. Equipe de testes integrada com a equipe de desenvolvimento, que está
atenta a todas as mudanças no sistema.
3. Conhecer bem a ferramenta ou linguagem de programação utilizada para
automatização do teste.
4. Compreender conceitos de banco de dados para conseguir elaborar testes
mais completos, capazes de alterar e remover dados utilizados nos testes, e
permitir a execução contínua deles.
Assim estes e outros fatores podem ser considerados no momento de decidir se os testes
funcionais serão automatizados ou manuais. É bom sempre lembrar que o principal objetivo de
um caso de teste (automatizado ou não) é encontrar defeitos no sistema.
Se a probabilidade de encontrar defeitos em uma funcionalidade for baixa, devido à

simplicidade do requisito, talvez não seja necessário criar um teste automatizado para isso, já que
o custo de manter esses testes não é baixo.
A diferença principal entre o teste manual e o teste automatizado é que o primeiro detecta
defeitos no sistema no presente momento e o segundo detecta futuros defeitos. Já que o teste
automatizado é criado para passar (sempre verde), ele depende disso para se manter executando
continuamente.
19. Vale a pena investir em testes estruturais para sistemas
legados?
Sistemas legados é um gargalo que algumas empresas possuem e ficam anos mantendo
sistemas, que algumas vezes possuem tecnologias antigas e sem documentação.
Ao pensarmos nesse tipo de abordagem, dos sistemas legados, precisamos analisar que tipo
de teste poderia ser utilizado. Se tenho uma sugestão para este cenário, talvez sim, mas para cada
caso, teria que se analisar as diferentes variáveis para tomar uma decisão mais assertiva.
Algumas variáveis que podem ser analisadas seriam:
● tecnologia do sistema legado;
● arquitetura do sistema;
● tempo de vida útil do sistema;
● quantidade de recursos humanos para realizar esses testes, sem prejudicar os
novos sistemas da empresa;
● número de usuários que ainda usam este sistema;
● número de erros recorrentes no sistema;
● necessidade de atualização do sistema;
● custo de se construir um sistema novo, com novas tecnologias;
● custo de realização e manutenção dos testes, entre outras.
Depois de uma análise de todo esse contexto, seria possível dizer se vale a pena ou não
realizar algum tipo de teste. Tendo em vista que os testes estruturais geralmente são realizados
pelos desenvolvedores, utilizando a linguagem de programação do sistema, dependendo dessa
linguagem, pode não haver equipe capacitada para criar esses testes.
No caso de haver uma equipe capacitada, o custo para criar testes unitários para todo o
sistema pode ser alto, por demandar muito tempo. Caso o sistema esteja em constante
atualização, uma abordagem seria criar testes unitários para cada novo código criado nesse
sistema. Além disso, para as partes do sistema que não mudam, testes de integração poderiam ser
criados para as interfaces de comunicação de cada camada do sistema.
As desvantagens de realizar esses testes automatizados seriam:

● alto custo para criação de testes;
● risco de o sistema ser descontinuado em curto prazo.
As vantagens de realizar esses testes automatizados seriam:
● garantir a qualidade contínua durante a atualização do sistema;
● aumentar a performance dos testes de regressão;
● reduzir a quantidade de testes manuais.
Portanto, decidir se vale a pena ou não criar testes estruturais para sistemas legados não é
trivial. Uma escolha errada pode trazer altos custos para a empresa e ter baixos resultados em
termos de qualidade baseada em testes.
20. O futuro dos testes e onde os testadores podem investir?
A tendência é que sistemas sejam criados para as mais diversas finalidades e estejam cada
vez mais presentes em nossas vidas. Já existem até sistemas que programam outros sistemas.
Com IoT (Internet das coisas), a interface entre o sistema e o usuário não fica restrita a uma tela
de dispositivo, pois de repente o sistema se comunica com uma cafeteira ou com o portão de uma
casa.
Quando combinamos IoT com Inteligência Artificial, os sistemas podem ser parte do drone
que entrega pizza ou até mesmo um carro autônomo que dirige pela cidade. Dessa forma, a
confiabilidade do sistema torna-se um dos principais requisitos. Logo, a qualidade não se resume
apenas em encontrar defeitos em uma aplicação, mas sim à segurança delas. Sistemas seguros
podem garantir a vida e os bens de seus usuários.
Empresas, para se manterem no mercado, precisam estar em constante atualização e

informatização de seus processos [15]. Mesmo as empresas que já possuem sistemas de
informação precisam ficar atentas às novas tecnologias dos dispositivos de seus clientes, pois
nem todos os sistemas rodam em versões antigas ou mais recentes desses dispositivos. Portanto,
os sistemas precisam ser atualizados frequentemente, para que continuem atendendo a esses
requisitos.
Considerando as tendências das novas tecnologias, a qualidade dos sistemas terá um papel
importante, logo a necessidade de testes automatizados será cada vez maior. Pois nem sempre
será possível realizar os testes manuais na velocidade requerida em um ambiente de
desenvolvimento, considerando os cenários de um usuário final.
Assim como os sistemas estão evoluindo, os testes também estão. Já existem ferramentas
para realização de testes utilizando inteligência artificial. Além disso, as ferramentas de testes
automatizados estão cada vez mais integradas com os repositórios dos sistemas. Isso garante a
qualidade contínua das novas atualizações dos sistemas.
Os testadores têm que perceber, ao realizarem testes manuais, que a atividade exercida por
ele é um serviço. Entretanto, quando realizam testes automatizados, cada caso de teste escrito
será um produto que poderá ser utilizado novamente sempre que necessário ou refinado para se
manter em funcionamento.
Então para as empresas é mais vantajoso contratar funcionários que possuam o

conhecimento mais amplo, que realizem tanto os testes manuais quanto os automatizados.
Assim, capacitação em testes automatizados é uma prioridade dos testadores que queiram seguir
uma carreira na área de qualidade de software.
Quando pensamos em automação, manipular dados pode ser um diferencial na realização de

testes, pois nada se compara a criar modelos de teste para um conjunto de 10 itens com testes
para um cenário de milhares desses itens. Nesse contexto, encontrar profissionais com técnicas
de automação para o Big Data Testing pode ser um requisito desejável das empresas.
Outra tendência para os softwares é a necessidade de segurança das aplicações. Quem faz
parte da área de qualidade de software pode também investir na área de segurança, pois apesar de
haver profissionais de segurança da informação, nem sempre eles identificam vulnerabilidade
nos sistemas. Dessa forma, uma capacitação em testes de segurança de sistemas pode ser um
diferencial para o profissional da área de testes.
Glossário
Ambiente de homologação: é um ambiente utilizado para verificar o sistema antes dele ser
disponibilizado para o usuário final.
Ambiente de desenvolvimento: é um ambiente utilizado pelos desenvolvedores enquanto

desenvolvem o sistema.
API: Interface de Programação de Aplicação.
Artefato: é o produto de trabalho bem definido e tangível, consumido, produzido ou modificado

pelas tarefas.
Automação: é um sistema automático pelo qual os procedimentos são realizados sem a

necessidade da interferência humana.
Banco de dados: repositório para armazenar os dados do sistema.
Caso de teste: é o conjunto de passos que precisam ser realizados para realizar um teste no
sistema.
Checklist: é uma lista de itens a serem verificados durante uma revisão de artefatos dos
sistemas.
Ciclo de vida: descreve as etapas de um processo do início até o seu encerramento/manutenção.
Ciclo ou Sprint: é o tempo de realização e finalização de um conjunto de atividades dentro da

metodologia ágil Scrum.
Cobertura: é uma técnica que demonstra o percentual de testes executados para uma
determinada finalidade.
Código-fonte: documento em formato de texto escrito em uma linguagem de programação que

será interpretado por um computador.
Componente: é o termo utilizado para descrever o elemento de software que encapsula uma
série de funcionalidades. Um componente é uma unidade independente, que pode ser utilizado
com outros componentes para formar um sistema mais complexo.
Defeito: é uma falha na execução de um software, que foi detectada.
Desenvolvedor: também conhecido como programador, é o profissional que trabalha na área de

TI responsável por construir um software através da criação do código-fonte.
Desenvolvimento de software: é a atividade de construção de um software realizada por um

desenvolvedor.
Documentação: são os documentos que descrevem sistemas, processos, desenvolvimento e

testes.
Entidade: pode ser uma classe do sistema, uma tabela do banco de dados ou um componente do
sistema.
Erro em sistema: comportamento inesperado do sistema em um determinado cenário.
Especificação funcional: é um documento que descreve os requisitos funcionais do sistema.
Falha em sistema: é quando um erro ocorre durante a execução do sistema.
Funcionalidade: informações sobre o sistema que representam o funcionamento de uma parte

do software.
Guia de interface: protótipo de tela do sistema em forma de imagem que define as principais
funcionalidades do sistema.
Integração contínua: quando o sistema evolui, novas versões são lançadas periodicamente, logo
cada mudança precisa ser registrada em um repositório de versionamento.
Homologação: etapa de um processo de construção de um software, onde o sistema é avaliado

para aprovação ou reprovação.
Mock: são componentes que simulam o comportamento de componentes reais de forma

controlada.
Modelagem de banco de dados: são modelos que definem como serão construídas as estruturas
de dados que darão suporte aos sistemas.
Navegador: é um software que nos permite acessar páginas pela internet, exibindo imagens,
textos, vídeos e demais informações. São softwares como Microsoft Edge, Google Chrome,
Safari, Firefox, IE, etc.
Nível de teste: define onde os testes serão realizados, ou seja, se os testes serão feitos no código,
na interface, etc.
Nível macro: nível de abstração das informações sobre um sistema, ou seja, informações de alto
nível, sem muito detalhamento.
Pirâmide de teste: definição em forma de pirâmide para a proporção sobre a quantidade de

testes automatizados realizados em cada nível de teste.
Processo de desenvolvimento de software: define um conjunto de atividades que podem ser

executadas por cada membro de uma equipe durante o desenvolvimento de um software.
Produção: etapa de um processo de construção de um software, onde o sistema é
disponibilizado para os usuários.
Product owner: papel definido pela metodologia Scrum, responsável por coletar informações
sobre o produto que será desenvolvido.
Qualidade de software: define padrões para que sejam verificados durante a construção do
software.
Recall: é o procedimento gratuito pelo qual a empresa convoca o cliente para sanar os defeitos
encontrados em produtos vendidos ou serviços prestados.
Regra de negócio: definem como o negócio funciona, podem abranger diversos assuntos como
políticas, interesses, objetivos, compromissos éticos e sociais, obrigações contratuais, decisões
estratégicas, leis e regulamentações entre outros.
Requisito de software: descreve as regras de negócio de um software, definindo as condições e

as restrições nas quais o sistema deve funcionar.
Roteiro de teste: determina o contexto em que um conjunto de casos de testes precisam ser
executados.
Scrum: metodologia ágil utilizada para o desenvolvimento de softwares que ainda não possuem
todo o escopo definido no início do processo.
Scrum master: papel definido pela metodologia Scrum que é responsável por liderar o time de
desenvolvimento do software que será construído.
Software: são todas as aplicações que rodam em uma máquina (computador ou celular).
Sprint: ciclo de cada etapa do desenvolvimento de um software que utiliza a metodologia

Scrum, cada ciclo pode durar de 1 a 4 semanas.
Testador: profissional que trabalha na área de TI responsável por testar um software.
Teste alfa: teste realizado em um software antes do lançamento para o público geral.
Teste beta: teste realizado em um software durante o lançamento para um público específico.
Teste caixa-cinza: abordagem de teste que combina os testes caixa-branca e testes caixa-preta.
Teste de confirmação: abordagem para verificar se um defeito encontrado no sistema foi

corrigido corretamente.
Teste de regressão: abordagem para garantir que, à medida que o sistema evolui, o que já foi
testado continua funcionando.
Teste dinâmico: abordagem para realizar a verificação em um software que esteja em execução.
Teste estático: abordagem para realizar verificação em busca de erros em um artefato de
software sem a necessidade de que ele esteja em execução. Por exemplo, revisão do código-
fonte.
Teste estrutural ou caixa-branca: abordagem que depende do código-fonte para ser realizado,
por isso tem o objetivo de encontrar defeitos durante a programação do software.
Teste exploratório: abordagem onde os testes são realizados sem a presença de um roteiro de
teste.
Teste funcional ou caixa-preta: abordagem onde os testes são realizados simulando o uso do
sistema, da mesma forma que o usuário final faria, sem a necessidade de ver o código-fonte.
Teste não funcional: abordagem para garantir que os requisitos não funcionais foram atendidos
pelo software, como segurança, usabilidade, disponibilidade, etc.
Teste relacionado à mudança: abordagem para garantir que nenhum novo defeito seja
acrescentado ao sistema após a sua modificação ou evolução.
Test drive: é a condução de um automóvel para aferir a sua dirigibilidade e estado geral de
funcionamento.
Versão alfa: é a primeira versão do produto, geralmente uma fase em que ele ainda está em
testes e desenvolvimento.
Versão beta: é a versão que já pode ser disponibilizada para um subconjunto de usuários, mas
que ainda possui erros e necessita de melhorias.
Versão trial: é uma versão final do produto que é disponibilizada para teste por um período
determinado (7 dias a 1 mês).
Versionar: ato de criar versões para documentos em geral.
Web Service: é uma solução utilizada na integração de sistemas e na comunicação entre

aplicações diferentes.
Referências
[1] Myers, G. J. The Arts of Software Testing - 2nd. ed. John Wiley & Sons, Inc., USA, 2004.
[2] Dijkstra et al. Software Engineering Techniques. Nato Software Engineering Conference,
Itália, 1969. cap. 3 pág 16. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF
[3] Rätzmann, M. e Young, C. Galileo Computing Software Testing and Internationalization. ed.
Lemoine International, USA, 2003.
[4] Syllabus. Certified Tester Syllabus. BSTQB, CTFL 3.1, 2018
[5] Marchesi, M., Succi, G e Williams, L. Traditional and Agile Software Engineering Software.
Addison Wesley, 2003. cap. 8.
[6] Olegario, P. e Bandeira, L. Boas práticas adotadas em um Projeto de Design de Testes – Um

relato de experiência. Artigo publicado no II EBTS, Recife, 2007.
[7] Oliveira, J., Gouveia, C., Gouveia e Filho, R. A way of Improving Test Automation Cost-
Effectiveness. Artigo publicado no CAST'06, Indianápolis, EUA, 2006.
[8] Pressman, R. S. Engenharia de Software. 5 ed., McGraw-Hill, 2002.
[9] Adrion, W. R; Branstad, M. A and Cherniavsky, J. C. Validation, Verification and Testing of

Computer Software, published at ACM, p. 159–192, New York, 1982.
[10] Hailpern, B. and Santhanam, P. Software debugging, testing, and verification at

http://www.research.ibm.com/journal/sj/411/hailpern.html
[11] Fowler, M. The practical test pyramid. 2018 https://martinfowler.com/articles/practical-test-

pyramid.html
[12] Cohn, M. Succeeding with Agile. 2009 http://1.droppdf.com/files/AFvTS/succeeding-with-

agile-mike-cohn.pdf
[13] Crispin, L. and Gregory, J. Agile Testing: A Practical Guide for Testers and Agile Teams,
Addison-Wesley Professional, 2009 em https://agiletester.ca/
[14] Valente, M. T. Engenharia de Software Moderna: Princípios e Práticas para

Desenvolvimento de Software com Produtividade. 2020
[15] Magaldi, S. e Salibi Neto, J. Gestão do amanhã. ed. Gente, 2018
[16] Rocha, A. C. O. GTSW - Grupo de Testadores de Software, blog em

https://medium.com/gtsw
[17] TestLink - Ferramenta de gerenciamento de testes de software. Open source, 2022 em
http://testlink.org/
[18] Vargas, R. Curso de gerenciamento de projetos. 2022 em https://ricardo-vargas.com/pt/
[19] PMI, Project Management Institute. PMBOK Guide. 2022 em https://www.pmi.org/pmbok-

guide-standards/foundational/pmbok?sc_camp=8A8BABF66EF9499DB5CCD1C1044CB211
[20] DevMedia. Processo de teste ágil x tradicional. 2022 em

https://www.devmedia.com.br/processo-de-teste-agil-x-tradicional/36854
Agradecimentos
Agradeço a Deus, por me abençoar em cada etapa da minha vida.

A elaboração deste livro não seria realizada sem o apoio de pessoas que contribuíram direta
ou indiretamente durante todo o processo.
Agradeço aos meus pais, Wagna e Vital, por acreditarem em mim e sempre me apoiarem
nos meus sonhos, confiando que eu conseguiria concluir este livro, me incentivando inúmeras
vezes.
Agradeço ao meu esposo, Bruno, que esteve sempre ao meu lado, me apoiando nos meus
projetos, inclusive revisando esta obra e fazendo críticas construtivas.
Agradeço aos meus filhos, Renan e Martim, por contribuírem dia após dia, me ajudando a
priorizar minhas atividades e a organizar melhor meu tempo.
Agradeço à minha irmã, Karina, por estar sempre ao meu lado, desde os primeiros passos de
vida, até mesmo nos tempos mais difíceis da universidade, me apoiando em todos meus projetos
e sonhos.
Agradeço ao meu irmão, Vital, pela amizade e alegrias compartilhadas desde a infância.
Agradeço aos meus outros familiares, por me ajudarem em cada momento da minha vida,
sem medir esforços e por todas as alegrias partilhadas: Anete Araújo, Marcos Guedes, Deise
Araújo, Dante, Sara, Iris, Kivia Meira, Alex Araújo, Vinícius, Théo, Guilherme, Anna Paula e
Uriel Max.
Agradeço aos meus amigos, com os quais compartilhei momentos de alegria: Mara Caroline
Kelmer, Rafaela Morais, Rodrigo Nóbrega, Denise Vaz, Rodrigo Souza, Natália Lins, Uirá
Assis, Geysa Oliveira, André Santos, Rodrigo Azevedo, Pauliane Sampaio, Maria de Lourdes
Nascimento, Arthur Nóbrega, Tareb Edson, Marceli Souza e Augusto Dantas.
Agradeço aos meus colegas de trabalho, desta trajetória na área de teste de software: Rafaela
Batista, Thenio Silva, Jessé Maia, Eduardo Arruda, Flavio Córdula, Alan Bonifácio, Danielle
Souza, Júlia Queiroz, Tália Almeida, Tairine Ferraz, Kelly Trajano, Geysa Jerônimo, Ana Paula
Vale, Manuela Andrade, Emanuella Soares, Amanda Lopes, Amanda Silva, André Caldas, Alex
Martins, Laércio Bezerra, Tullio Henrique, Kivio Grangeiro, Karolline Mota, Jackson Alves,
Murilo Augusto Souza, Daniel Damasceno, Nickson Chagas, Issias Silva, Allisson Fernando e
Cecília Andrade.
Agradeço ao Raphael Patrício, por sua liderança impecável, por sempre confiar no meu
trabalho, permitindo implementar melhorias nos processos e inovações em qualidade de
software.
Agradeço às demais pessoas, que trabalharam comigo, compartilhando experiências e me
motivaram com suas ideias, que de alguma forma fazem parte deste livro: Felipe Guedes, Iza
Magna, Ricardo Barbosa, Fabiana Nascimento, Jackeline Gomes, Max Carvalho, Georgenes
Lima, Rony Rodrigues, Creusa Lucena, Cristina Ferreira, Ana Cláudia Silva, Anderson Clayton,
Sandro Lopes, Arthur Santos, Alan Araújo, Natália Bezerra, Dalila Azevedo, Luiz Cerqueira,
Ramon Xavier, Felipe Rosas, Cesar Peres, Vinícius Migliorança, Jessica Freitas, Júlia Vita,
Thamirys Gameiro, Ruan Campelo, Daniel Coelho, Verônica Antunes e Luanna Peixoto.
Agradeço ao Vitor Cardoso por ter me incentivado a continuar com a escrita desta obra,
mesmo que de forma indireta, quando me convidou para escrever um capítulo para o livro
“Debugando sua carreira”. Percebi o quanto era simples o processo de publicação de um livro e
pouco tempo depois, recebi o livro dele em casa, a sensação foi tão maravilhosa que comecei a
me imaginar recebendo o meu livro também.
Agradeço ao revisor Farlley Derze por ter aprimorado o texto com seu senso crítico e
analítico, o que me deixou mais confiante durante a publicação desta obra.
Agradeço aos colaboradores, que sugeriram ideias para os capítulos do livro através do blog
Grupo de Testadores de Software: Maurício Gamarra, André Leite, Gilson Júnior, André Luiz
Moraes, Eglom Sostenes, Osmar Leandro, Leiany Duarte, Marcus Silva e JJ.
Agradeço aos queridos futuros leitores, que já demonstraram interesse antes mesmo do
lançamento deste livro, me motivando na escrita e publicação: Dayana, Glaucia Conie, Caio,
Wederson Oliveira, Benjamim Rodrigo, Gislaine Oliveira, Gisele Cerqueira, Rony Correia,
Bruno Silva, Tatty Cassilha, Eduardo, Josué Moraes, Eliel Sousa, Diego, Victória, Diego Spotti,
Everton Mendonça, Ana Flávia Ramos, Maria Margarida Silva, Lucas de Miranda, Rosana, Ana,
Antônio Araújo, Edson Junior, Gabriela, Alex Lins, Bruno Iglesias, Karoline Pacheco, Fernando
Jordão, Jaqueline Santos, Amauri, Giseane Macedo, Felipe Espíndola, Luiz Ukan, Shirlane
Lima, Ana Alessandra, Luana, Soraia Silva e Roberta Moraes.

Simplificando_Teste_de_Software_Compartilhando_experiências_Anne

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Simplificando_Teste_de_Software_Compartilhando_experiências_Anne

Enviado por

Direitos autorais:

Formatos disponíveis

SIMPLIFICANDO TESTE DE

Anne Caroline Rocha

1ª edição – Julho 2023

Aos meus filhos –

Aos meus irmãos –

Figura 1.1: Nomes de softwares de computadores ou celulares.

Um software é construído pelo desenvolvedor através de uma linguagem de programação,

A Figura 1.2 apresenta um protótipo de um aplicativo de celular, no qual as pessoas apoiam

Teste de software é a arte de realizar uma simulação em um software, com o objetivo de

“Um software é considerado confiável à medida que o número de defeitos diminui

Em resumo, um erro do desenvolvedor no código-fonte do software pode causar uma falha

2.1. Como alcançar qualidade em um software?

Uma aplicação pode conter um conjunto de funcionalidades que determinam como um

Figura 1.3: Aplicativo para compras online.

O que? Tipo de teste

Esse teste tem o objetivo de Teste não-funcional.

Onde será testado? Nível de teste

A interface do sistema através Teste de sistema

Como será testado? Técnica de teste

Será utilizado um checklist Baseado na experiência

3.1. Processo de desenvolvimento tradicional

Figura 3.1: Processo Tradicional de Desenvolvimento de Sistema.

O modelo tradicional de desenvolvimento de software tem muito em comum com outras

3.2. Processo ágil de desenvolvimento de software

Com os processos ágeis de desenvolvimento tornou-se possível lançar um produto viável

Em processos ágeis, algumas vezes a documentação não é bem detalhada e contempla

No cenário em que o time ágil é dividido em desenvolvedores e testadores, é importante que

4.1. Teste Funcional

Figura 4.1: Modelo representando a execução de um teste funcional.

4.2. Teste não funcional

Figura 4.2: Modelo representando testes não funcionais.

O teste de desempenho tem o objetivo de identificar o desempenho do sistema quando

O teste de usabilidade tem o objetivo de verificar se o usuário tem dificuldade em utilizar

4.3. Teste estrutural

O custo de realização do teste estrutural é baixo, pois o sistema ainda se encontra em

4.4. Teste relacionado à mudança

O teste de regressão é realizado durante o desenvolvimento e geralmente é executado antes

Esses níveis correspondem aos 4 tipos de nível de desenvolvimento, presentes na lateral

Figura 5.1: Modelo V que descreve os níveis de teste.

5.1. Nível de Teste de unidade

O nível de teste referente ao teste de unidade tem como objeto de teste:

5.2. Nível de Teste de integração

O nível de teste de integração tem como objeto de teste:

5.3. Nível de Teste de sistema

O nível de teste de sistema tem como objeto de teste:

5.4. Nível de Teste de aceite

O nível de teste de aceitação tem como objeto de teste:

Quando o teste de aceitação é realizado em um ambiente de homologação, por clientes ou

Como foi definido no capítulo anterior, durante o desenvolvimento de um software podemos

Os níveis de unidade e integração podem ser feitos de forma automatizada. Já os níveis de

Levando em consideração os atributos menos favoráveis do teste de sistema automatizado,

Figura 6.1: Modelo da pirâmide de testes automatizados.

Dessa forma a pirâmide seria composta por 3 camadas:

Por exemplo: um teste de integração poderia contemplar o cadastro de usuários no banco

Figura 7.1: Tela de autenticação que permite a entrada de um usuário.

CT 01 - Realizar autenticação de usuário

Precondição: Usuário possuir um cadastro.

Passos: 1. Informar o e-mail do usuário

2. Informar senha do usuário

3. Clicar no botão ‘Entrar’

1. Usuário consegue entrar no sistema.

Os testes funcionais, quando realizados de forma manual, podem necessitar da elaboração de

Tela inicial > Tela cadastro de usuário

7.2 Objeto de teste