Modulo 1

1. O que é um software? E quais são os seus tipos?

 Um software é um programa utilizado para realizar tarefas do usuário.
o System software (Device Drivers, Sistemas operacionais, Servidores,
Utilities e etc.)
o Programming software (Compiladores, Debuggers, interpreters e etc.)
o Application software (Web application, Mobile apps, Desktop Applications
e etc.

Banco  IT Company  Develop  Test Deliver  Banco

2. O que é um teste de software?

 Teste de software é uma parte do processo de desenvolvimento de software.
 É uma atividade de detectar d identificar os defeitos em um software.
 O objetivo é liberar a qualidade do produto para o cliente.

3. Descrevendo a qualidade de software.

 Livre de bugs
 Entregue no tempo determinado
 Dentro do orçamento
 Atendendo requisitos e expectativas
 Sustentável

4. Projeto VS Produto
 Se o software é desenvolvido especificamente para um cliente com base em
seus requisitos, ele será chamado de projeto.
 Se o software é desenvolvido especificamente para vários clientes e seus
requisitos são baseados no mercado, ele será chamado de produto.

5. Defect, Error, Bug e Failure

 O defect é um erro encontrado APÓS o software entrar em produção.
 O error é mal-entendido por parte dos desenvolvedores de software.
 O bug é um resultado de um erro de codificação. Um erro encontrado no
ambiente de desenvolvimento, antes do produto ou projeto ser enviado ao
cliente.
 O failure é uma falha, é a incapacidade do sistema ou do componente do
software de executar sua função exigida nos requisitos.
 6. Por que softwares tem bugs?
 Má comunicação ou não comunicação
 Complexidade do software
 Erro na programação
 Mudança de requisitos
 Falha de testadores qualificados

7. SDLC – Software develompent life cycle / Ciclo de vida de desenvolvimento de

software
 O SDLC é um processo utilizado pela indústria de software para projetar,
desenvolver e testar o software.

Ciclo de vida de desenvolvimento de software

Analise de Requisitos  Projetar  Desenvolver  Testar  Manutenção

8. Modelo Cascata / Waterfall Model

 Analise de Requisitos
 Projetar sistema
 Implementação
 Teste
 Desenvolvimento
 Manutenção

Obs: A etapa seguinte só começa quando a etapa anterior é finalizada.

Vantagens:

 Qualidade do produto / projeto será boa.

 Desde que os requisitos não mudem, as chances de encontrar bugs serão
pequenas
 Investimento menor, já que os testadores são contratados nas etapas finais
 Preferência de projetos ou produtos pequenos com poucos requisitos.

Desvantagens:

 Mudanças de requisitos não são possíveis.

 Se houver um defeito nos requerimentos ele vai continuar até a última fase.
 O valor total investido é maior, por conta do tempo utilizado para realizar um
rework.
 Os testes serão realizados somente após a codificação.
9. Spiral Model

 Começando no centro da espiral.

 O modelo espiral é interativo, por conta da sua capacidade de repetir as interações
em determinados módulos.
 O Modelo espiral pode voltar a uma etapa, diferente da modelo cascata.
 Em todos os ciclos, será lançado um novo software para o usuário.
 O software vai conter múltiplas versões, por isso também é chamado de version
control model.

Vantagens:

 Testes são realizados em todos os ciclos, antes de ir para o próximo ciclo.

 Cliente vai utilizar o software de todos os módulos.
 Requisitos podem ser alterados no final de todos os ciclos, começando a levar
eles em conta no próximo ciclo.

Desvantagens:

 Requisitos não podem ser mudados antes de finalizar um ciclo.

 Todo ciclo no modelo espiral é como o modelo cascata.
 Testes não são realizados nas fases de requerimentos e de projeto.

Protótipo é o mesmo que blueprint do projeto.

Requerimentos iniciais  Protótipo  Cliente  Projetar, Desenvolver, testar e etc.

 Gmail case

 Login
 Check Inbox
 Compose
 Sent
 Recive e-mail
 Etc...

Banking Case

 Login
 Check Balance
 Fund Transfer
 Req statment
 Add Payee
 Etc...

 Cada função é um Modulo


10. V-Model // VV Model

V V Model  Verification Validation Module

11. Técnica para testar
 Teste estático ou Static Testing é o teste realizado no documento
o Review
 Uma análise realizada para remover ambiguidades, redundâncias e
erros nos documentos
o Walkthrough
 Um especialista verifica o erro para que não haja problemas no
decorrer do desenvolvimento ou na fase de testes.
o Inspection ()
 Uma verificação de alta prioridade com mesma intensidade que o
SRS (Software Requirement Specifications)

 Teste Dinâmico ou Dynamic Testing é o teste realizado no

o Unit Testing
 Teste realizado em uma pequena parte do código pelos
desenvolvedores
o Integration
 Teste realizado após o Unit Testing, utilizando todas as unidades
individuais testáveis, realizados pelos desenvolvedores e
testadores
o System Testing
 Teste realizado para garantir o funcionamento do sistema baseado
nos requisitos, geralmente realizado quando o sistema está
pronto.
o UAT
 Teste realizado para verificar se o sistema está atendendo as
regras de negócios.

12. Verificação / Validação

 Verifica se o produto / projeto está sendo construído da maneira correta.

 Foco na documentação
 Verificação geralmente envolve Reviews, Walkthrougs e Inspections.

 Verifica se o produto / projeto está sendo construído da maneira correta.

 Começa quando a verificação é completada
 Foco no Software
 Validação tipicamente envolve Unit testing, integration, system testing e UAT
testing
 Vantagens
o Testes são realizados em cada uma fase
 Disvantagens
o Documentação Maior
o Investimento maior

13. QA vs QC

QA – Relata o processo
QC – Realiza o teste de software

QA – Foco em construir a qualidade

QC – Foco em testar a qualidade

QA – Previne os defeitos
QC – Detecta os defeitos

QA – Processo orientado (Se envolve em quase todos os processos)

QC – Produto orientado (Se envolve somente no teste do produto)

QA – Envolvido em todo ciclo de vida do software

QC – Envolvido somente na parte do teste do SDLC

QE  Quality engineering

Diferença entre:

Software Enginner SE  Escreve o código em função do software

Quality Enginner QE  Escreve o código em função da qualidade de software
 Escreve o código e o utiliza para testar o software

P – People (QC) TESTER

P – Processo (QA)
P – Produto

Processos do SDLC

 Requirement Analisys - QA
 Desing - QA
 Coding - QA
 Testing - QC
 Deploymenet - QA
 Maintainance – QA
14. GUI Testing (System Testing)
 Graphical User-Interface Testing or GUI testing, é todo processo de testar o a
interface do usuário na aplicação
 O GUI incluí todos os elementos como: Menus, Checkbox, Buttons, Colors,
Fonts, Sizes, Icons, Contents, and Images.
 Testing Checklist:
a. Tamanho, posição, largura e comprimento dos elementos
b. Mensagens de erro
c. Sessões de tela
d. Fonte legíveis e não legíveis
e. Resolução de tela com zooming in e com zooming out
f. Alinhamento de textos e outros elementos como, botões,
ícones e etc
g. Cores das fontes
h. Se cada imagem tem uma boa clareza
i. Alinhamento de imagens
j. Ortografia
k. Testa se o usuário pode ficar frustrado ao usar o a interface do
sistema
l. Se a interface é atraente
m. Scrollbars estão alinhadas a pagina
n. Disabilitar campos se houver a possibilidade
o. Tamanho das imagens
p. Titulos (headings) alinhados ou não
q. Cores do Hyperlink
r. Teste de UI em elementos como butões, textbox, text área,
check box, radio buttons, drop downs, links etc.

15. Teste de usabilidade

 Durante as validações, providencia ajuda sensitiva ou não para o usuário
 Verifica o quão fácil é a usabilidade da aplicação
16. Functional Testing
 A funcionalidade é o comportamento da aplicação durante o uso
 O teste verifica como a aplicação deve funcionar
 Testa as propriedades dos objetos
a. Enable, disable, visible, focus e etc...
 Database/Backend Testing
a. Operações DML (Data Manipulation Language)
b. Insert, Update, Delete and Select
c. Validar as tabelas (column type, column length/comprimento,
number of columns)
d. Relation between the tables
e. Functions
f. Precedures/Procedimentos
g. Triggers
h. Indices
i. Views
 Testa a manipulação de erros
a. Testador verifica a mensagem de erro enquanto realiza ações
incorretamente na aplicação
b. Verifica se a mensagem de erro está legível
c. Verifica se a linguagem está compreensível para o usuário
 Testa cálculos
a. Testador verifica se os cálculos estão coretos
 Testa a existência de links e sua execução
a. Onde os links estão colocados
b. Verifica se os links estão navegando para a página ou não
c. Internal links  Link na sua página que leva para outra página
d. External links  Hyperlink
e. Broken links  Links que não funcionam
 Testa os cookies e sessões
a. Tempo de criação de arquivos do Browser enquanto navega
na internet.
b. Verifica se a sessão vai ser finalizada ou não no tempo
determinado pelo servidor da aplicação

17. Teste Não Funcional

 Quando a aplicação está estável é realizado o teste não funcional
 Foco na performance, no load e na segurança
 Performace (Speed) : Load testing, Stress Testing and Volume Testing
a. Load : Gradualmente aumentar o load da aplicação e verifica a
performace
b. Stress: Suddenly/De repente aumenta o load da aplicação e
verifica a performance
c. Volume : Verifica a quantidade máxima de dados a aplicação
consegue suportar
  Security Testing
a. Authentication  Objetivo de verificar se o usuário é validado
ou não
b. Acess Control  Verifica qual o tipo de acesso o usuário
contem
 Recovery Testing
a. Verifica se a aplicação tem a propriedade de recuperação ou
não
 Compatibility Testing
a. Forward compatibility
b. Backward compatibility
c. Hardware compatibility  Configuration Testing
 Installation Testing
a. Verifica se a tela está limpa para o entendimento
b. Navegação de telas
c. Testa a simplicidade
d. Un-installation
 Teste do lixo ou do saneamento
a. Se qualquer aplicação providencia funcionalidades extra é
considerada um bug.

18. Regression Testing

 O teste de regressão tem como principal objetivo certificar-se de que a
mudança na construção não vai impactar na funcionalidade da aplicação,
mudanças como adicionar, deletar ou modificar características/features.
 Unit Regression Testing
a. Testando somente as modificações realizadas pelo
desenvolvedor
 Regional Regression Testing
a. Testando as modificações e seu impacto no modulo
b. Analise de impacto realizada pelo QA e Dev para identificar o
impacto
 Full Regression
a. Testando a feature principal e o resto da aplicação
b. Exemplo: Desenvolvedor realiza muitas mudanças no modulo,
ao invés de realizar a identificação dos impactos é realizado o
full regression.
19. Re-Testing
 Quando um dev conserta um bug, o testador vai realizar o test no bug
consertado.
 Se o testador encontrou o bug e funcionou de outra forma, ele vai
fechar o bug, abrir novamente e mandar para o desenvolvedor
 O re-testing server para certificar-se de que o bug foi realmente fixado
na versão anterior
o Exemplo: Build 1.0 was released. Test team found some
defects (defect id 1.0.1, 1.0.2) and posted
o Build 1.1 was realesed, now testing the defect 1.0.1 and 1.0.2
in this build

20. Re-Testing Vs Regression Testing

 Uma aplicação sobre teste tem 3 modelos nomeados como: Admin, Purchase
and Finance.
 O modelo financeiro depende do modelo de compra.
 Se um testador encontrar um bug no Purchase, será necessário fazer o Re-
testing e verificar se o bug foi corrigido ou não. Após isso, será necessário
realizar o teste de regressão no modelo financeiro por conta da sua
dependência com o modelo Purchase.
21. Smoke Vs Sanity Testing
 Smoke Testing
 O teste Smoke certifica se a compilação recebida pelo desenvolvedor
está testável/estável
 É realizado por testadores e por desenvolvedores
 A aplicação pode tanto estável quanto não estável
 É realizado nas partes iniciais da compilação
 Faz parte do teste básico
 Geralmente realizado em uma nova realese
 Sanity Testing
 O teste Sanity é realizado durante a fase realese, feito para verificar o
funcionamento principal da aplicação sem se aprofundar muito.
 Sanity testing é realizado somente pelo testador
 É realizado nas builds estáveis
 Faz parte do teste de regressão
 É realizado quando não há tempo para fazer o teste profundo/in-
depth
22. Teste de exploração / Exploratory Testing
 Explorar a aplicação, compreendendo ela completamente e testando
