

 
     
 
 ­  

€­  



ASSISTENTE DE TECNOLOGIA
DA INFORMAÇÃO
Módulo 3
 2

Faça o teu melhor, na condição

que você tem, enquanto você
não tem condições melhores,
para fazer melhor ainda!

Mario Sergio Cortella

TESTE MANUAL DE SOFTWARE

“O teste de programas pode ser usado para

mostrar a presença de defeitos, mas nunca para
mostrar a sua ausência.” (Dijkstra)

Testar é o exercício de medir a qualidade e funcionalidade de um sistema.

Desde os primórdios da Era da Informação, os profissionais envolvidos

com tecnologia enfrentam desafios atrelados a qualidade dos softwares.

Boa parte dos produtos eletrônicos que atualmente consumimos possuem

softwares. Agora imagine se o fabricante do seu smartphone detecta um
problema e faz um recall (chamada para reparação de erros), como
geralmente vemos nas montadoras de veículos.

Você deve concordar que, embora isso ocorra às vezes, essa é uma
situação desconfortável.
 3
Considerando que é quase impossível desenvolver um software sem
falhas, temos que a única alternativa para enfrentar este percalço é o teste
de software.

Os testes têm como objetivo principal eliminar as possíveis falhas de

programação e intervir no software, de forma preventiva e corretiva, para
deixá-lo adequado ao negócio que vai atender.

“Pensar em teste de software nos remete, normalmente,

para a avaliação das linhas de código para encontrar
falhas. Mas não se engane, testar software tem um
objetivo muito mais amplo. O software precisa gerar o
resultado esperado, então testá-lo envolve analisar tudo o
que ele fornece de resposta e sua devida veracidade.
Testar um software envolve planejar e controlar a
aplicação, além de avaliar seus resultados. O principal
objetivo sempre será a busca de qualidade. E entender
estes conceitos pode significar a quebra de alguns
paradigmas.”

Professor José Macedo dos Santos

Por que o software deve ser testado?

1. Diminuir a possibilidade de erros no cliente;
2. Reduzir riscos ao negócio do cliente;
3. Atender todas as necessidades do cliente (contratual, legal, etc);
4. Garantir maior satisfação do cliente.

Etapas Simplificadas Do Desenvolvimento De Software

análise

desenvolvimento

teste
 4
Bem, talvez você esteja se perguntando “afinal para que serve mesmo um
teste de software?”.

Primeiro deixe-me contextualizar, para que possamos utilizar softwares

em nossos computadores e celulares se faz necessário que esses
softwares sejam analisados, desenvolvidos, testados e só então
disponibilizados para uso.

Imagine agora o seu Whatsapp, um software para bate-papo.

Muito antes que esse programa fosse disponibilizado para
download em seu celular, ele foi planejado por um analista,
programado por um desenvolvedor de sistemas, testado
por uma equipe (tanto na fase de análise quanto na fase de
desenvolvimento) e só depois ficou disponível para o usuário.

Todo desenvolvimento de software passa por etapas até chegar a sua

versão final, sendo o teste uma destas etapas.
“O sistema já está publicado em produção!”
“Testa tudo antes em homologação!”

Se você é da TI ou se relaciona com essa área de alguma forma, já deve ter

escutado as frases acima.

Durante a produção de um software é comum que ele seja publicado em

ambientes diferentes. Ambiente é o local onde o software é publicado para
que alguém possa acessá-lo e executar suas funções.

Sendo assim normalmente temos:

Ambientes
desenvolvimento

homologação

Produção
 5
Desenvolvimento: Ambiente para acesso ao sistema quando ele está na fase
de desenvolvimento. Esse ambiente é comumente usado pelos
desenvolvedores para terem uma visão de como está ficando o resultado
da programação, mas também pode ser usado pelos testadores.

Homologação: Ambiente para acesso ao sistema quando ele está na fase de

teste, geralmente após a conclusão do desenvolvimento (programação).
Esse ambiente é comumente usado pela equipe de teste na intenção de
simular o uso do sistema o mais próximo da realidade possível. Os dados
gerados nesse ambiente podem ser manipulados e não são dados reais.

Produção: Ambiente para permitir que o usuário final manuseie o sistema, é

nesse ambiente que de fato o sistema será executado e os dados serão
armazenados. Por definição, um software só pode ser publicado em
produção, após atingir todas as fases do desenvolvimento e estar apto a
ser entregue ao cliente. Os dados gerados nesse ambiente NÃO podem ser
manipulados, pois são os dados reais.

Busca por Qualidade

“A qualidade de software é uma área de conhecimento da engenharia de

software que objetiva garantir a qualidade do software através da
definição e normatização de processos de desenvolvimento. Apesar dos
modelos aplicados na garantia da qualidade de software atuarem
principalmente no processo, o principal objetivo é garantir um produto
final que satisfaça às expectativas do cliente, dentro daquilo que foi
acordado inicialmente. Segundo a norma ISO 9000 (versão 2000), a
qualidade é o grau em que um conjunto de características inerentes a
um produto, processo ou sistema cumpre os requisitos inicialmente
estipulados para estes. No desenvolvimento de software, a qualidade do
produto está diretamente relacionada à qualidade do processo de
desenvolvimento, desta forma, é comum que a busca por um software
de maior qualidade passe necessariamente por uma melhoria no
processo de desenvolvimento."

Fonte: http://pt.wikipedia.org/wiki/Qualidade_de_Software
 6
Não raro, percorremos o caminho da busca por qualidade, seja em
aquisições de grande ou pequeno porte. Basta imaginar os
eletrodomésticos, como uma geladeira que geralmente não dá defeitos, é
extremamente valorizada; enquanto outra que sempre dá alguma
manutenção, é descartada o mais breve possível.

No mercado de software essa busca segue a mesma direção, ou seja, os

clientes e usuários de TI prezam por qualidade. Portanto, clientes e
usuários de TI, tendem a valorizar aquele hardware ou software que quase
nunca dá problema em detrimento daquele que sempre dá alguma
manutenção.

Podemos inferir então que o sucesso do software pode estar ligado à

qualidade que eles demonstram ter. Muitos podem ser os motivos que
acarretam em baixa qualidade (ex: falta de tempo), apontamos como
possível solução a aplicação de técnicas de testes de softwares como uma
opção de ajuda necessária para aproximar os produtos da necessidade
imposta pelo mercado.

Qualidade é a capacidade de um serviço ou produto

atender as necessidades dos clientes ou usuários.

Segundo a Norma ISO 9126, essas são as características para qualidade:

Funcionalidade

portabilidade confiabilidade

manutenibilidade usabilidade

eficiência
 7
qualidade interna
e externa

Funcionalidade confiabilidade usabilidade

- Aquisição; - Maturidade; - Inteligibilidade;
- Acurácia; - Tolerância e falhas; - Apreensibilidade;
- Interoperabilidade; - Recuperabilidade; - Operacionalidade;
- Segurança de acesso; - Conformidade. - Conformidade.
- Conformidade.

eficiência manutenibilidade portabilidade

- Comportamento em - Analisabilidade; - Adaptabilidade;
relação ao tempo; - Modificabilidade; - Capacidade para ser
- utilização de recursos; - Estabilidade; instalado;
- Conformidade. - Testabilidade; - Coexistência;
- Conformidade. - Capacidade para
substituir;
- Conformidade.

Qualidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e

Portabilidade são atributos buscados no desenvolvimento de software e o
testador pode contribuir, sendo uma peça chave, para esta busca quase
que inalcançável.

O processo de teste é positivo quando encontra erros ou

defeitos e é eficiente quando utiliza a menor quantidade de
recursos possíveis para encontrar essas falhas e defeitos.

Motivos para testar

1. Para garantir que as necessidades dos usuários estejam sendo
atendidas;
2. Porque sempre partimos do pressuposto de que é provável que o
software possua defeitos;
 8
3. Para evitar constantes intervenções nos projetos anteriores em
produção;
4. Porque falhas podem custar muito caro;
5. Para avaliar a qualidade do software.

ERRO x DEFEITO x FALHA

Instrução ou Desvio da Processamento incorreto

comando incorreto especificação e comportamento inconsistente

Defeito erro falha

Universo Universo da Universo do

físico informação usuário

Embora não exista nenhum conjunto universal para definições relativas ao

teste de software, alguns conceitos importantes são aplicados para o
entendimento e estudo de testes de software. Portanto, é de suma
importância entender o conceito de erro, defeito e falha.

Apesar de estes termos e definições estarem ligados de forma direta ao

desenvolvimento de software, muitos profissionais da área de TI não
conhecem seu significado e suas diferenças.
 9
Erro: trata-se de uma ação humana (ex.: não entendimento de como
executar um cálculo).

Defeito: Causado por um erro de entendimento (ex.: código com fórmula de

cálculo mal escrita).

Falha: Tentativa de execução de um defeito. (ex.: execução de um

cálculo gerando resultados indevidos).

Falha é um evento. Defeito é um estado do software, causado

por um erro.

Vários fatores podem ocasionar um defeito em um software, são alguns deles:

• Pressão para que o software seja produzido rápido;

• Prazo de atendimento inadequado;
• Aplicação de forma inadequada da tecnologia;
• Falta de preparo da equipe;
• Falta de entendimento sobre as necessidades do cliente;
• Fator humano.

Os defeitos ocorrem no software porque eles são escritos por agentes

humanos, por sua vez, sabemos que os humanos, embora profissionais,
não conhecem e não dominam tudo, são passíveis de cometer erros.

Uma pessoa ... que cria ... que pode causar

comete um defeito no uma falha na
erro... software... operação.
 10
Custo Do Teste Tardio

Sempre que um novo erro é descoberto, tem a necessidade de avaliar o

impacto causado pelas falhas do sistema, e é importante, que a cada novo
erro seja feito uma nova análise.

Sendo assim, o impacto de encontrar e consertar os defeitos aumenta

consideravelmente ao longo do tempo.

De acordo com a regra 10 de Myers, “o custo da

correção de um defeito tende a aumentar quanto mais
tarde ele for encontrado.”

Os defeitos encontrados nas fases iniciais do projeto de desenvolvimento

do software são mais baratos do que aqueles encontrados na produção
(chama-se produção a execução do software nos terminais do usuário
final, ou seja, um software está em produção quando é usado pelo cliente).

Segundo estudos, quanto mais rápido corrigir uma falha, menor será o custo. O gráfico
apresentado tem como objetivo mostrar a proporção do aumento, observe
que na fase de requisitos, o custo para correção é praticamente zero. Já
quando o software está em produção, estima-se que o custo aumente em
100 mil vezes.
$
Sistema
$ 100.000 Rodando

d e a c e itação
$ 10.000 e
test do usuário

$ 1.000 testteemdea
sis
t e d e
$ 100 g r a m a n d o treosgramação
pro p
$ 101
$ requisito
 11
A Psicologia do Teste

Quando estiver testando e revisando deve ter o

pensamento de forma diferente da utilizada enquanto
está se analisando e desenvolvendo.

Os desenvolvedores de sistema também são aptos a

testarem seus próprios códigos, mas essa separação de
responsabilidade com os testadores de software é feita para ajudar a
focalizar o esforço e fornecer bebefícios adicionais, com visão
independente, profissional e treinada. Qualquer nível de teste pode ser
considerado um teste independente.

Quando um código é testado por uma pessoa que não teve influência do
desenvolvedor, há um grau de independência, o que pode representar uma
forma eficiente de encontrar defeitos e falhas. Vale a pena lembrar que
independência não é substituição. Os desenvolvedores também podem
encontrar defeitos no código.

Níveis de independência podem ser definidos como:

1. Baixo nível de independência: o software é testado por quem o

escreveu/desenvolveu;
2. Teste elaborado por outra(s) pessoa(s) (por exemplo, da equipe de
desenvolvimento);
3. Teste elaborado por pessoa(s) de um grupo organizacional diferente
(ex: equipe independente de teste);
4. Teste elaborado por pessoa(s) de diferentes organizações ou
empresas (terceirizada ou certificada por um órgão externo).

Pessoas e projetos são direcionados por objetivos. Pessoas tendem a

alinhar seus planos com os objetivos da gerência e outros envolvidos
(“stakeholders”) para, por exemplo, encontrar defeitos ou confirmar que o
software funciona. Desta forma, é importante ter objetivos claros do teste.
 12
Algumas pessoas entendem que identificar falhas durante o teste pode ser
uma crítica ao produto e ao autor (responsável pelo produto), assim, o
teste acaba sendo visto como uma atividade destuitiva, porém o teste é
importante e construtivo para o gerenciamento de risco do produto. Ser um testador
de falhas exige curiosidade, atenção aos detalhes, pessimismo
profissional, olhar crítico, comunicação eficiente com os desenvolvedores
e muita experiência para encontrar erros.

Se os erros, defeitos ou falhas são comunicados de uma forma

construtiva, podem-se evitar constrangimentos entre as equipes de teste,
analistas e desenvolvedores, tanto na revisão quanto no teste. O testador,
como líder da equipe, sempre deve ter uma boa relação com as pessoas.

Ele precisa comunicar informações sólidas sobre defeitos, progresso e

riscos de uma forma construtiva. Quando informado algum defeito do
software, pode ajudar o desenvolvedor (autor) ou o documentador do
software a ampliarem seus conhecimentos. Um defeito encontrado e
resolvido traz ganho de tempo, de dinheiro e reduz riscos.

Problemas de comunicação, embora possam ocorrer, devem

ser limitados ao máximo. Os testadores não podem ser vistos
apenas como mensageiros de más notícias e defeitos.

Existem formas de melhorar a comunicação e o relacionamento entre os envolvidos:

• Todos têm o mesmo objetivo quanto a qualidade do sistema, portanto é

necessário que haja espírito de colaboração em vez de disputas e
conflitos;
• Comunicar os erros encontrados nos produtos de uma forma neutra, dar
foco no fato sem criticar a pessoa que o criou, por exemplo, escrevendo
objetivamente o relatório de incidentes;
• Seja compreensivo. É importante saber dar uma notícia e compreender
como o outro irá recebê-la;
• Sempre confirme se a outra pessoa entendeu o que você falou e
vice-versa.
 13
Processo de Teste - PDCA

Plan, Do, Check, Act – Planejar, Fazer, Checar, Agir

1. Definir Meta; b
a 1
2. Definir Método; 7
3. Educar e Treinar; 2
4. Executar;
5. Coletar Dados; 3
6. Checar; 6 4
7. Ação: corretiva, preventiva, melhoria. 5
d
c

Conceitos Básicos do teste

Um documento de teste pode conter as seguintes terminologias:

requisitos, testar, bug.

requisitos - regras de negócio de sistema.

testar - descobrir falhas através da execução do sistema.

bug - é um defeito encontrado no sistema em execução.

Fundamentos do Processo de Teste de Software

Um processo de teste básico deve contemplar:

• Planejamento e controle;
• Análise e modelagem;
• Implementação e execução;
• Avaliação de critérios de saída e relatórios;
 14
• Atividade de encerramento dos testes.
• Melhoria/Corretiva/Preventiva.

A qualidade não é igual ao teste. A qualidade é conseguida

colocando o desenvolvimento e os testes em um liquidificador e
misturando-os até que um seja indistinguível do outro.

James A. Whittaker at Google

Mitos Sobre Os Testes

Os testadores devem
O testador é inimigo
ser os desenvolvedores
do desenvolvedor.
menos qualificados.

Um programador
O sistema está pronto
consegue testar
quando o desenvolvedor
eficientemente o
termina de codificar.
próprio código.

Nesse contexto ressalto o fato de que o testador não deve ser também o
desenvolvedor. É muito importante que a pessoa a testar, não seja a
mesma que programou. Para evitar vícios de execução e assim ter um
teste mais puro, que de fato simule o uso na ponta final.

Desenvolvedor e testador são partes da mesma equipe de forma que um

complementa o trabalho do outro e juntos ambos trabalham por um
resultado de qualidade.
 15
conceito de equipe única

testador desenvolvedor

Estratégias E Tipos De Teste De Software

Uma estratégia de testes de software integra métodos de projeto

de casos de teste em uma série bem planejada de passos que
resultam na construção bem sucedida de software. A estratégia
fornece um roteiro que descreve os passos a serem conduzidos
como parte do teste, quando esses passos são planejados e
depois executados, e quanto de esforço, tempo e recursos serão
necessários.

Fonte: (PRESSMAN, 2010)

Uma estratégia para testes de software pode ser vista no contexto da espiral mostrada na
figura a seguir:
Teste de Integração

Teste de Validação

Teste do Sistema

Teste de Unidade

Código

Projeto

Requisitos
Engenharia do Sistema
 16
O teste inicia no centro da espiral e vai passando por cada componente, ou
seja, trechos de código fonte do software. O teste vai se movendo para
fora, ao longo da espiral, seguindo para o teste de integração, que foca no
projeto e na construção da arquitetura do software.

Seguindo a espiral, tem o teste de validação, que é quando as

especificações dos requisitos são confrontadas com o software que
acabou de ser construído. Por último, é realizado o teste do sistema, onde
todos os elementos do software são testados como um todo.

Já quanto aos tipos os testes são classificados da seguinte maneira:

- Testes de Caixa-Branca (Estrutural), que se dividem em:

a. Testes de Unidade;
b. Teste de Integração.

- Testes de Caixa-Preta (Funcional), que se dividem em:

a. Testes Funcionais;
b. Testes de Aceitação;
c. Testes Exploratórios.

- Testes de Caixa-Cinza, que se dividem em:

a. Testes de Regressão;
b. Testes de Cobertura.

Teste da caixa branca

Conhecido também como “teste orientado à lógica ou estrutural”. Esse teste

utiliza o código fonte do sistema/programa para avaliar seus
componentes. Nele, pode ser analisado itens como: fluxo de dados,
condições, ciclos, entre outros. É utilizado para verificar itens como: a
criticidade, complexidade, estrutura e nível de qualidade do programa,
envolvendo confiança e segurança.
 A. Teste de unidade: é também conhecido como teste unitário. Avalia a
17
menor unidade do código. Esse teste verifica falhas em pequenas partes
do sistema, com ele é possivel fazer uma análise profunda e específica de
uma função independente das outras funções do sistema, assim, facilita a
descoberta de erros e falhas por módulos.

A base para o teste é o teste de caixa branca. Esse teste é planejado para
descoberta de erros devido ao fluxo impróprio de controle, comparações
incorretas e computações errôneas.

B. Teste de integração: avalia diferentes componentes que são

desenvolvidos separadamente, mas trabalham em conjunto. Quando esses
componentes são avaliados de forma isolada é possivel encontrar falhas
no resultado exibido, em consequência de erro em algum componente ou
mal funcionamento.

Teste da caixa preta

Diferente do teste anterior, que prioriza os aspectos internos, o teste da caixa

preta verifica aspectos externos. Os requisitos funcionais do sistema são
avaliados. Nesse teste, o modo de funcionamento e a operação não são
avaliados com foco nas funções que deverão ser desempenhadas pelo
software, dessa forma, é avaliado se um grupo de entrada de dados teve o
resultado pretendido nas saída, considerando sempre a especificação do
programa, ou seja, o que era esperado para o software fazer. É conhecido
também como técnica funcional;

A. Testes de Aceitação: Tem por objetivo verificar se o sistema está em

conformidade com os requisitos esperados pelo cliente; realizado pelo
cliente ou pelo testador, desde que o cliente faça um checklist do que é
esperado no sistema, que será executado no ambiente de homologação.
O sistema é utilizado para capacitar os usuários para que eles validem
todos os requisitos do sistema. Pode ser utilizado a ferramente
EasyAccept.
 B. Testes Exploratórios: Realizado por testadores quando não há muita
18
documentação sobre o sistema; realizado de forma manual; os defeitos
encontrados são reportados à medida que eles ocorrem.

Teste da caixa cinza

Tem esse nome pois é a junção do teste branco com o teste preto. Avalia
tanto os aspectos internos quanto os externos, de entrada e saída. Pode
utilizar-se de engenharia reversa;

A. Teste de regressão: Esse teste é realizado a cada nova modificação

(atualização) de um software, afim de evitar que ocorra os mesmos erros
na nova versão do sistema.

B. Testes de Cobertura: Teste funcional ou estrutural; Estrutural: tem a

finalidade de identificar se os testes realizados no sistema abrangem pelo
menos 95% do código produzido; Funcional: os roteiros de teste devem
abranger 100% das funcionalidades do software, deve haver pelo menos
um teste para cada regra de negócio.

Atividades de Verificação e Validação

A validação e a Verificação são conceitos importantes para o aprendizado

de testes.

Validação: avaliação da autenticidade do produto, baseado nas

necessidades e exigências do cliente.

Verificação: é a análise se o projeto foi desenvolvido da forma prevista, no

qual deve ser questionado se o produto está sendo desenvolvido de forma
correta. Para que isso ocorra, existem técnicas como, por exemplo,
inspeção e revisão.
 19
A validação e a Verificação certificam que o software atenda as
especificações e necessidades dos usuários.

A estrutura do modelo V é próxima ao processo de testes e também pode

ser integrada a todo o processo de desenvolvimento. O modelo V
representa desenvolvimento versus teste.

Durante todo o desenvolvimento é utilizado o Modelo V de testes, pois se

necessário é possivel ter uma detecção adiantada dos erros.

análise dos teste de

requisitos aceitação

especificação teste de
do sistema sistema

desenho do teste de
sistema integração

desenho do teste
componente unitário

codificação

Perfil do Testador

1. O testador não deve testar seu próprio programa.

2. De nenhuma forma, o testador deve duvidar que algum erro existe.
3. O testador ter cuidado para não reportar falsos bugs.
4. O testador não é inimigo do desenvolvedor.
5. O testador deve saber se comunicar com o desenvolvedor.
6. Os bugs descritos pelo testador sempre devem ser baseados em fatos.
7. É um bom testador aquele que encontra muitos bugs.
 20
ATIVIDADE

Na imagem abaixo localize os sete erros:

Descubra os 7 erros nas imagens

a b

Testar um software pode ser comparado a um jogo de 7 erros, em que você tem o software
desenvolvido de um lado e o escopo do projeto que contém os objetivos do outro.

Explicação:

A presente atividade visa permitir que você perceba que para identificar
erros, mesmo em um quadro simples, requer bastante concentração e
disposição. Localizar erros em software, devido a sua proporção, demanda
ainda mais concentração, disposição, criatividade e detalhamento.
 21

SÍNTESE DO MÓDULO

No módulo 3 você estudou sobre ferramentas que te permitiram entender como ocorre um teste
manual de software.

Exploramos brevemente as etapas simplificadas do desenvolvimento de software,

dessa forma você pode ver que o software percorre um longo
caminho até estar disponível para uso.

Inicialmente os estudos te levaram a entender que para produzir um

software é preciso analisar, desenvolver e testar. Sendo que o teste deve
ocorrer desde as fases iniciais as finais, minimizando assim os riscos de
falha e custos de manutenção. Estudamos também os tipos de ambiente
usados para publicação de software: desenvolvimento, homologação e
produção.

Num segundo momento você pode analisar os mitos mais comuns em

relação ao teste e conhecer as estratégias e tipos de testes existentes.

Ressalto aqui o conceito de equipe única, onde todos os envolvidos somam

suas habilidades sempre visando a qualidade do produto final. Memorize
esse conceito, assim além de técnica para testar você também terá um
diferencial humano, que é a colaboratividade.

Nos vemos no módulo 4.

 22

Glossário

B
Bug: é um jargão da informática que se refere às temidas falhas inesperadas
que ocorrem ao executar algum software ou usar um hardware.

C
Checklist: é uma lista de itens que foi previamente estabelecida para
certificar as condições de um serviço, produto, processo ou qualquer outra
tarefa.

Código fonte: vem do inglês source code e define um conjunto de palavras

escritas de forma ordenada contendo instruções em determinada
linguagem de programação.

I
ISO: A sigla ISO denomina a International Organization for Standardization,
ou seja, Organização Internacional de Padronização. Em outras palavras, é
um meio de promover a normalização de produtos e serviços, utilizando
determinadas normas para que a qualidade seja melhorada.

S
Softwares: É uma sequência de instruções escritas para serem interpretadas
por um computador com o objetivo de executar tarefas específicas.

Stakeholders: é qualquer indivíduo ou organização que, de alguma forma, é

impactado pelas ações de uma determinada empresa. Em uma tradução
livre para o português, o termo significa parte interessada
 23
REFERÊNCIAS

BOSSI, Aline. Teste de software no contexto da melhoria da qualidade. 2010. Disponível

em: http://aline-bossi.wordpress.com/tag /norma-ieee- 829/. Acesso em
03 set. 2019.

LAGES, Daniel Scaldaferri. Automação dos Testes: um lobo na pele de cordeiro? In:
Engenharia de Software Magazine, edição 29, 2010.

MACEDO, José. Teste de Software. Disponível em:

https://www.passeidireto.com/arquivo/50881972/apostila . Acesso em 03
set. 2019.

MOLINARI, L. “Testes Funcionais de Software”. Ed. Visual Books. Florianópolis,

2008.

VIEGAS, Júlio. TESTE DE SOFTWARE: INTRODUÇÃO, CONCEITOS BÁSICOS E TIPOS DE TESTES.

Disponível em: https://blog.onedaytesting.com.br/teste-de-software/ .
Acesso em 03 set. 2019