Apostila 3 - Curso Assistente de TI - Qualificar ES

Prévia do material em texto

ASSISTENTE DE TECNOLOGIA 
DA INFORMAÇÃO
��������������
�������������������������������
������������������
�������������������������
�	����������������������
��
�������������������������������
��������������������
���
���������������������������
�����������

��������������������������������������������������
������������������������������
�������������������
� �������
���������������������������������
�	�������
��������������������
�����������������������������������

��
���������������������­��������������������
�����
�������­������������
������������������
�����
���������������������
Módulo 3
22
TESTE MANUAL DE SOFTWARE
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
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.
“O teste de programas pode ser usado para 
mostrar a presença de defeitos, mas nunca para 
mostrar a sua ausência.” (Dijkstra)
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:
desenvolvimento
homologação
Produção
Ambientes
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
confiabilidade
usabilidade
eficiência
manutenibilidade
portabilidade
7
qualidade interna
e externa
Funcionalidade confiabilidade usabilidade
- Aquisição;
- Acurácia;
- Interoperabilidade;
- Segurança de acesso;
- Conformidade.
- Maturidade;
- Tolerância e falhas;
- Recuperabilidade;
- Conformidade.
- Inteligibilidade;
- Apreensibilidade;
- Operacionalidade;
- Conformidade.
eficiência manutenibilidade portabilidade
- Analisabilidade;
- Modificabilidade;
- Estabilidade;
- Testabilidade;
- Conformidade.
- Adaptabilidade;
- Capacidade para ser 
instalado;
- Coexistência;
- Capacidade para 
substituir;
- Conformidade.
- Comportamento em 
relação ao tempo;
- utilização de recursos;
- Conformidade.
Qualidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e 
Portabilidade são atributos buscados no desenvolvimento de softwaree 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
Defeito erro falha
Instrução ou 
comando incorreto
Universo
físico
Universo da
informação
Desvio da 
especificação
Processamento incorreto
e comportamento inconsistente
Universo do
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 
comete um
erro...
... que cria
defeito no 
software...
... que pode causar
 uma falha na 
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.
$
$ 100.000
$ 10.000
$ 1.000
$ 100
$ 10$ 1requisito
programan
do teste d
e 
programação
teste de
sistema
teste de ac
eitação
do usuário
Sistema 
Rodando
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;
2. Definir Método;
3. Educar e Treinar;
4. Executar;
5. Coletar Dados;
6. Checar;
7. Ação: corretiva, preventiva, melhoria.
1
2
3
4
5
6
7
a
b
c d
Conceitos Básicos do teste
Um documento de teste pode conter as seguintes terminologias: 
requisitos, testar, bug.
requisitos
testar
bug
- regras de negócio de sistema.
- descobrir falhas através da execução do sistema.
- é 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 GoogleMitos Sobre Os Testes
Os testadores devem 
ser os desenvolvedores 
menos qualificados.
O sistema está pronto 
quando o desenvolvedor 
termina de codificar.
Um programador 
consegue testar 
eficientemente o 
próprio código.
O testador é inimigo 
do desenvolvedor.
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.
 
17
 A. Teste de unidade: é também conhecido como teste unitário. Avalia a 
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. 
18
 B. Testes Exploratórios: Realizado por testadores quando não há muita 
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
requisitos
especificação
do sistema
desenho do 
sistema
desenho do 
componente
teste
unitário
teste de
integração
teste de
sistema
teste de
aceitação
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
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.
a b
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, desenvolvere 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