Fundamentos de testes de Software

1
Testes de Software
Módulo 01

22
Thayse Severiano
/in/thayseseveriano/
| Especialista em Testes
/thaysetss
/Thaysetss
@thayse.tss

33
Agenda
• O que é teste de software?
• Por que testar um software?
• Custo de um bug;
• Qualidade x Testes;
• Critérios de testes;
• Técnicas de Testes.

44
O que é teste de software?
Na literatura e na prática
4

55
• É uma etapa do desenvolvimento que garante que um software faz o que
deve fazer e não faz o que não deve fazer;
• É o processo executado para encontrar as falhas e defeitos de um software;
• Ações realizadas para garantir que o software atingiu a qualidade desejada;
Na literatura

66
• Garantir que um problema foi resolvido;
• Garantir que o requisito solicitado atenderá todas as expectativas dos
clientes;
• Confirmar que novas funcionalidades não impactaram no restante do
software;
• Verificar o comportamento da aplicação em diferentes ambientes, como
navegadores, dispositivos, resoluções;
• Compartilhar conhecimento com os demais integrantes do time.
Na prática também é...

77
Por que
testar?
O que acontece com um software não testado, ou pouco testado?
7

8
Por que eu preciso testar meu software?
• Liberar versões com mínimo de bugs;
• Redução do risco de interrupção nas rotinas dos clientes;
• Entregar software com mais qualidade para os usuários;
• Faz o que deve, não faz o que não deve fazer;
• Evitar prejuízos financeiros e de imagem;

99
Na França, uma mulher pediu divórcio de
seu marido quando descobriu a traição por
um bug nas notificações do Uber.
O marido entrou com processo contra a
empresa pedindo indenização de 45 milhões
de euros pelo fim do casamento.

10
Em maio de 2018, por 9 dias, o Facebook alterou as configurações de
privacidade de 14 Milhões de usuários para ‘Público’ sem o consentimento
destes usuários.

11
Em 2017 o software que determina as folgas dos pilotos, concedeu folga para
um número excedente de profissionais, deixando em torno de 15 mil voos
sem piloto e co-piloto.

12
Em 2017, um erro no software do módulo de controle do motor, em raras
condições, causava a parada do motor do veículo, o que causou um acidente
e um recall em 162 mil veículos

1313
Em 2018, efetuei o pagamento de 2 multas
por atraso na declaração do Imposto de
renda. Depois de 2 meses recebi notificação
de não pagamento de uma das multas e
tive bloqueio do meu CPF.
Um erro de software confundiu os
pagamentos e deixou um débito do valor da
segunda multa e o crédito do pagamento
pendente no meu CPF.

1515
O Boeing 737 MAX 8 teve duas falhas que causou 346 mortes entre
outubro de 2018 e Março de 2019 na Indonésia e Etiópia
-Erro na leitura dos dados recebidos dos sensores do ângulo de ataque
-Correção do ângulo de ataque do sistema MCAS

16
Custo de um bug
O custo de correção de um bug aumenta exponencialmente conforme este bug avança no
desenvolvimento de software.

17
Custo de um bug
Quanto mais alto na pirâmide,
maior o custo.

18
Testes x Qualidade de software
Testes de Software
Execução de validações e verificações no software para
identificar se os requisitos estão desenvolvidos conforme
solicitado.
Identifica os possíveis problemas e oportunidades de
melhoria no software desde o momento da concepção.
Qualidade
Vai garantir que o software será desenvolvido de acordo
com os padrões definidos em processos, contrato, etc.

1919
Testes: Estou fazendo o software certo?
Qualidade: Estou fazendo certo o software?

20
Classificação dos testes
Teste de Caixa Branca
Quando eu conheço o que tem dentro. No caso do software é o teste que consegue ver a codificação e a estrutura interna
da aplicação.
Critérios avaliados nesta etapa:
- Cobertura Lógica;
- Método dos caminhos básicos;

21
Cobertura lógica por comandos
Garante que haverá um teste passando por todos os
comandos do meu código.
Exemplo:
- idade = 1,5;
- idade = 3,5;
- idade = 5,5;
- idade = 6,5;
- Idade = 7,5;
- idade = 8,5;
- idade = 10
- idade = 11;
- idade = 12;
- idade = 13;
- Idade = 14
- idade = 15;
Teste caixa branca:

22
Cobertura lógica por decisões
Garante que todas as entradas e saídas sejam percorridas
pelo menos 1 vez.
Exemplo:
- idade = 0; idade = 2;
- idade = 2,1; idade = 4;
- idade = 9,1; idade = 10;
- idade = 10,1; idade = 11;
- idade = 11,1; idade = 12;
- idade = 12,1; idade = 13;
- idade = 13,1; idade = 14;
- Idade = 14,1; idade = 15;
Teste caixa branca:

23
Classificação dos testes
Teste de Caixa Preta
Quando eu não sei como o software é desenvolvido. Não tenho acesso ao código fonte. Geralmente realizados a nível
de telas e APIs e são executados com base no conhecimento das entradas/saídas e fluxos de uma aplicação.

2424
Partição em classes de Equivalência
Separação das condições de entradas em um número finito de classes que terão o mesmo comportamento, para obter maior sucesso
nos testes.
- Identificar os subconjuntos que são equivalentes;
- Identificar as entradas válidas e inválidas;
24

2525
Exemplo:
Tenho um campo em que é informado o Mês de vencimento do cartão de crédito.
Os meses são de janeiro (01) a Dezembro (12). Estas são as entradas válidas.
Minhas partições são:
1. Menores que 1;
2. De 1 a 12;
3. Maiores que 12.
Não é preciso testar todos os números possíveis. Sabendo a partição de equivalência,
escolhe-se uma entrada de cada partição para realização dos testes.
Meus subconjuntos:
1. -8;
2. 9;
3. 21.

2626
Valores limite
É complementar à técnica de Classe de equivalência.
Testar as “bordas” de cada equivalência.
Meus limites são: 0; 1; 12; 13.

2727
Grafo de causa e efeito
Esse critério de teste verifica o efeito combinado de dados de entrada.
As causas (condições de entrada) e os efeitos (ações) são identificados e combinados em um grafo a partir do qual é montada uma
tabela de decisão, e a partir desta, são derivados os casos de teste e as saídas.
27
Exemplo:
Em um e-commerce, é oferecido frete grátis quando o valor da compra é maior que R$60,00 e no máximo 3 itens são adicionados ao
pedido.
1. Identificação da causa e efeito:
Causa: valor da compra > 60 e #produtos < 3
Efeito: frete grátis
2. Criar um grafo com as entradas e saídas:

2828
Grafo de causa e efeito
Com base no grafo, é montada a tabela de decisão.
28
Agora com a tabela em mãos, é possível utilizar os dois outros critérios para identificação dos testes mais assertivos para cada
funcionalidade.

2929
Baseado em erros
Nesta técnica utiliza-se o conhecimento do time e o histórico de erros para agregar nossa base de testes, em que consideramos os
erros que já aconteceram antes.
Quanto mais experiente é o time, mais testes baseados em erros será
Possível realizar.
29

31
Testes de Software
Módulo 02

3232
Vimos antes...
• Técnicas de Testes.

3333
Agenda
• Tipos de testes;
• Testes unitários;
• Cobertura de código.

3434
Tipos de testes e as características
34

3535
Tipos de testes
Vamos fazer um apanhado geral sobre
os tipos de testes mais comuns e mais
utilizados.

3636
• Faz o que deve fazer?
• Tem funcionalidade adequada?
• Cumpre seu propósito?
• Faz os cálculos corretamente?
• Respeita a funcionalidade?
• Representa a parte de negócio;
Testes funcionais

3737
• O software está completo?
• Verifica se todos os requisitos solicitados foram implementados;
• Verifica se todos os fluxos desenvolvidos são percorridos até o fim
• Exemplo:
• Quero editar meu cadastro de colaborador.
• Acesso a tela;
• Seleciono o modo de edição;
• Altero o dado que está desatualizada.
• Ao salvar a alteração, recebo uma mensagem dizendo que a alteração não pode ser
realizada.
Característica: Completude
Teste funcional

3838
• Está retornando o resultado correto?
• Verificar se todos os resultados estão de acordo com o especificado;
• Exemplo:
• Mensagem informando que ocorreu erro ao editar meu cadastro, indicando que o CPF
não é válido.
• Após a mensagem de erro, o CPF é alterado conforme dado inserido na edição.
Característica: Correção
Teste funcional

3939
• Apropriado: o resultado está certo na forma apropriada?
• Quando os resultados são alcançados, estão de acordo com o esperado?
• Exemplo:
• Não é possível ver a mensagem completa.
• A mensagem de erro informando que o CPF está inválido, possui o botão ‘OK’ por baixo de
outro componente e não permite clicar e a única alternativa é recarregar a página.
Característica: é Apropriado
Teste funcional

4040
• Tem como objetivo garantir que o
software desenvolvido é fácil de usar;
• Que o usuário consegue identificar
como realizar as operações sem
longos treinamentos;
• Que as atividades do usuário são
otimizadas e percorrem os passos
necessários para alcançar um
objetivo.
Testes de usabilidade

4242
• O usuário identifica o significado dos elementos da tela?
• O usuário sabe pra onde ir depois que realizar o passo?
• O usuário consegue identificar o comportamento da tela?
Característica: Reconhecimento
Todas as interfaces Xiaomi MIUI 12
Teste de Usabilidade

4343
• Preciso fazer um treinamento para ensinar o usuário?
• Ele consegue identificar os fluxos com pouco ou nenhuma orientação?
Característica: Facilidade no aprendizado

4444
• Facilidade de navegação;
• Facilidade de operação;
• Garantia de otimização do tempo de uso do usuário;
• Usuário possui um fluxo linear de navegação;
• Usuário consegue fazer todas as ações com o mínimo de cliques
necessários;
• O usuário consegue executar as ações rapidamente;
• Quanto menos tempo eu levo pra realizar determinado fluxo, melhor é a
operabilidade.
Característica: Operabilidade

4545
Característica:
Operabilidade

4646
Característica: Operabilidade

4747
Testes de usabilidade – Facilidade no
aprendizado

5050
• O sistema direciona o usuário para seguir os caminhos certos;
• A aplicação induz o usuário a preencher ou selecionar as informações
corretamente;
• O sistema se protege de entradas inválidas ou incorretas, limitando na tela
as opções disponíveis e dando feedback quando o usuário está interagindo;
• Existem “travas” nos campos que impedem o usuário de inserir tipos de
dados inválidos;
Característica: proteção contra erros

5151

5252

5353
• O sistema é agradável aos olhos;
• A composição de cor está ideal;
• Os tipos de campos estão condizentes com os seus propósitos?
• Faz sentido para os movimentos humanos;
• Ergonômica;
• Quantidade de informações na tela;
• Espaços vazios na tela para relaxar ou estética para que o usuário fique
muito tempo na aplicação sem cansar;
• Cores cansativas / Cores relaxantes;
• Responsividade;
Característica: Estética

5454

5555

5656

5757
• Garantir que o sistema é acessível para qualquer pessoa com pouca ou
nenhuma supervisão;
• Existe contraste entre a cor das fontes e a cor do fundo?
• A fonte possui tamanho suficiente para leitura por pessoas que possuam
alguma restrição visual;
• Possui espaçamento adequado entre as letras para facilitar leitura por
pessoas com dislexia;
• Pessoas com pouca escolaridade ou sem alfabetização;
• Crianças e pessoas com necessidades intelectuais;
• Cores com diferença de contraste no aspecto
Característica: Acessibilidade

58
Característica: Acessibilidade
Fonte:
Open Dislexic

6565
• Funcionamento em conjunto com outras aplicações;
• Garantir que o software funciona independente do que está instalado na
máquina ou dispositivo;
• Software é compatível com outros softwares;
• Funcionamento independente de outras aplicações, como anti-vírus, firewall,
etc...
Testes de compatibilidade

6666
• Capacidade de existir e se permitir existir independente do que esteja
instalado;
• Existir no mesmo “ambiente” que os concorrentes: iFood, Rappi, Uber Eats;
• Não interferir no funcionamento alheio ou permitir que outro software interfira
no seu funcionamento;
Característica: Coexistência
Teste de Compatibilidade

6767
• Facilidade de comunicação;
• Capacidade de enviar e receber dados;
• Capacidade de sincronizar informações;
Característica: interoperabilidade
Teste de Compatibilidade

6868
• Garantir a disponibilidade dos serviços;
• O sistema estará em funcionamento sempre que o usuário precisar;
Testes de confiabilidade

6969
• Consegue identificar um erro antes que aconteça.
• Capacidade de avisar o usuário de que algo errado vai acontecer ou que
conseguir agir quando uma falha pode ocorrer.
Característica: maturidade
Teste de Confiabilidade

7070

7171

7272
• Mantém o software disponível para usuários e para outros softwares.
Característica: disponibilidade

7373

7474

7575

7676
Capacidade de identificar que a falha uma falha pode ocorrer e efetuar
compensações para evitar problemas maiores.
Característica: tolerância a falhas

7777
Característica: tolerância a falhas

7878
Capacidade de se recuperar quando uma falha ocorre.
Gerar pouco ou nenhum impacto nas ações dos usuários quando uma falha
ocorre.
Característica: Recuperabilidade

7979
Característica: Recuperabilidade

8080
• Garante que o software executa em um tempo adequado;
• Verifica a quantidade de recursos utilizadas (CPU, disco, memória, rede);
• Comporta a quantidade de requisições, usuários ou conexões definidas;
• Garante que o software responde em um tempo aceitável.
Testes de desempenho

8181
Garante que o sistema suporta uma quantidade de usuários, volume de
dados, volume de requisições, etc...
Característica: capacidade
Teste de desempenho

8282
Característica: utilização de recursos
Teste de desempenho
• Garantir que o software utiliza os recursos de forma adequada;

8383
Característica: tempo de resposta
Teste de desempenho
• Performance do software.
Com 3 segundos sem resposta, um site pode perder até 10% dos usuários;
Após 30 segundos estima-se que perde-se 80% dos usuários.

8484
• Trata da facilidade de efetuar manutenções no software após a entrega
inicial e até o fim do ciclo de vida.
• Garantir que o software poderá evoluir com o passar do tempo
Testes de manutenção

8585
Característica: modularidade
Teste de manutenção
• Validar que o software pode ter algumas partes facilmente substituível;
• Garantir que o mal funcionamento de uma parte do software não impacta no
restante;

8686
Característica: reusabilidade
• Garantir que os componentes do software pode ser reaproveitado;
• Esta característica se aplica tanto a código fonte de sistema quanto código
de automação de testes;

8787
Característica: analisabilidade
• Facilidade de analisar o código.
• Garantir que qualquer programador consegue identificar o que o código faz
sem grandes esforços

8888
Característica: modificabilidade
• Facilidade em trocar componentes.
• Exemplo: drivers de acesso a banco, framework de front-end

8989
Característica: testabilidade
• Garantir que o software é facilmente testável;
• Esta característica se aplica a testes unitários, testes automatizados de
interface e testes funcionais.

9090
• Garantir que o software funciona em todos os ambientes necessários;
• O software irá se adaptar em uma nova condição.
Testes de portabilidade

9191
Característica: adaptabilidade
Teste de portabilidade
• Garantir que o software funciona em um novo ambiente, seja ele, um novo
navegador, um novo sistema operacional, um novo banco de dados, etc.

9494
Característica: Instalabilidade
• Facilidade em instalar ou desinstalar um software;
• Publicar novas versões, atualizar versões;
• Possibilidade de mudar de ambiente conforme necessidade de recursos;

9595
Característica: Instalabilidade

9696
Característica: Substituibilidade
• Facilidade em substituir um software, seja em uma nova versão, seja em
migração de tecnologia ou até mesmo substituir o software de um
concorrente.
• Teste com objetivo de realizar um incremento entre um software anterior com
um novo software atendendo todas as necessidades do cliente.

9797
• Garantir que as informações sensíveis estão bem guardadas e são
acessadas somente por quem tem autorização;
• Garantir que o software está protegido contra invasões;
• Garantir que as modificações feitas em informações sensíveis são
devidamente mapeadas e permite rastreio;
• Garantir
Testes de segurança

9898
Característica: Confidencialidade
Teste de segurança
• Garantir que somente pessoas autorizadas vejam determinadas
informações;
• Garantir que o software não induz o usuário a fazer uso indevido de
informações confidenciais ou as quais ele não deveria ter acesso;

9999
Característica: Integridade
Teste de segurança
• Garantir que somente pessoas autorizadas possam alterar informações;
• Garantir que todas as alterações de informações sensíveis possuem registro
de quem efetuou, onde efetuou e o horário em que a alteração foi realizada;

100100
Característica: Não repúdio
Teste de segurança
• Capacidade do software de minimizar o risco de ter alguma transação
realizada sem que o autor esteja ciente;
• Exemplo:
• As transações bancárias de alto valor passam por um processo de avaliação manual
antes de envio para o Banco Central;
• O software deve ter uma camada de proteção que diminua os riscos do operador efetuar
a avaliação de uma forma indevida e acusar o software de tê-lo feito.

101101
Característica: Responsabilidade
Teste de segurança
• Garantir que o software foi utilizado de uma determinada forma por um
usuário.

102102
Característica: Autenticidade
Teste de segurança
• Garantir que uma pessoa é ela mesma;
• Garantir que a transação foi realmente realizada;

103
Testes de Software
Módulo 03

104104
Tipos de testes
O que é, como faz, ferramentas e frameworks

105105
Vimos antes...
• Técnicas de Testes;
• Tipos de testes;

106106
Agenda
• Testes unitários;
• Cobertura de código;
• Testes de integração;
• BDD;
• TDD;
• Testes em equipes ágeis.

107
Custos de Testes
• Testes de interface: são os
testes mais caros de executar.
Também são chamados de End
to End (e2e).
• Depende do ambiente completo
para execução;
• São testes que geram
dificuldade em identificar
quando quebram.

108
Custos de Testes
• Testes de Integração: verifica
se o conjunto de funciona bem
juntos.
• Não testa o fluxo completo, e
sim, várias integrações que
podem estar no meio de um
fluxo.
• Está no meio termo entre
unitários e e2e.
• Não garante que todo o fluxo
está funcionando.

109
Custos de Testes
• Testes unitários: são os testes
mais baratos e onde
deveríamos ter o maior volume
de testes.
• Tem como objetivo validar a
menor porção do software, que
são os métodos.

110
Custos de Testes
• Quando a quantidade de testes
se concentra no topo e inverte a
pirâmide e temos um cone de
sorvete.
• Este modelo aumenta o custo
de desenvolvimento, pois o
maior esforço de testes está
justamente na parte mais lenta
e mais cara do processo.

111
Testes unitários
• São os testes mais baratos tanto para fazer quanto pra executar;
• Quando o teste quebra, sabemos exatamente onde falhou, onde está o problema e qual regra quebrou;
• Não depende de nenhum outro ambiente para execução;
• Executa com tempo muito inferior aos demais tipos de testes;
• Garante cada uma das funções isoladamente;
• Permite com muita facilidade identificar a porcentagem do código fonte que está passando por testes;
• Mão de obra disponível em qualquer projeto;
• Pouca manutenção necessária, e quando é necessário, é muito mais rápido e fácil.

112
Ferramentas e frameworks
Testes unitários
C Unit - Check
Cobol Unit

113113
No exemplo que vimos antes...
113

114114
No exemplo que vimos antes...
114
Utillizando também os valores limite:
Cenário 01: Valor da compra R$59,99 e 2 itens na sacola;  Cobra frete
Cenário 03: Valor da compra R$60,01 e 2 itens na sacola;  Frete grátis

116
Vamos ver na prática?
Testes unitários
X
Testes de Interface

118
Cobertura de código
• Verificação de quantas linhas de códigos foram executadas quando os testes rodaram;
• Garante que os fluxos foram cobertos por testes;
• Identifica quando o teste passa em funções, condições e linhas de código;
• Uma cobertura de 80% não indica que eu testei 80% dos testes necessários;
• Para que a cobertura de testes tenha cobertura dos cenários necessários, vamos aplicar as técnicas
vistas ao longo desse treinamento.

122
Testes de integração
• Fase em que os módulos são combinados e testados em grupo;
• Vem após o teste unitário e são mais caros para implementação e execução;
• Também chamado de testes de serviços;
• Já é possível validar a regra de negócio, integrando as unidades;
• Neste tipo de testes é possível validar:
• Testes de APIs;
• Testes de drivers do banco de dados;
• Testes de envio de e-mail;
• Testes de integração com sistemas externos;

124124
• CEP com formatação inválida – retorna Erro 400
• CEP inexistente – Retorna “erro”=true
Api consulta de CEP
https://viacep.com.br/

125125
Api consulta de CEP
Retorno 9 caracteres Com letra Com espaço Caracteres
especiais
CEP Válido CEP Inexistente
400
Erro true
200
• Com 9 Caracteres: 890150000
• Com letra: 89015A00
• Com espaço: 89015 00
• Com caractere especial: 89015♥00
• CEP Válido: 89015205
• CEP Inexistente: 89000015

127127
Api consulta de CEP
Retorno 9 caracteres Com letra Com espaço Caracteres
especiais
CEP Válido CEP Inexistente
400
Erro true
200
• Com 9 Caracteres: 890150000
• Com letra: 89015A00
• Com espaço: 89015 00
• Com caractere especial: 89015♥00
• CEP Válido: 89015205
• CEP Inexistente: 89000015

129129
Teste em equipes ágeis
Como o teste faz parte do processo de desenvolvimento

130130
• CEP com formatação inválida – retorna Erro 400
• CEP inexistente – Retorna “erro”=true
Teste em equipes ágeis
https://viacep.com.br/

131131
O que muda?
O time inteiro é responsável por todas as entregas e a
qualidade desta entrega;
O time de testes apoia o desenvolvimento e não atua
somente no fim da sprint.
Um time, um único objetivo.
Entrega de valor.
Não é sobre encontrar bugs. É sobre preveni-los.
Teste automatizado é o maior aliado.
Comprometimento do time com as entregas.

132132
O que muda?
Em uma equipe ágil, o teste faz parte de todas as
etapas de desenvolvimento e é executado por
todos os membros do time!
A atividade de testes inicia na planning meeting
quando o time já identifica cenários de testes
enquanto a história está sendo lida.
O time (inteiro) já começa a identificar os cenários
de testes e identifica pontos de melhoria na
história, dificuldades técnicas, impactos em outras
funcionalidades já existentes, etc...

133133
BDD
• Behaviour Driven Development
• BDD não é automação!
• BDD é um conjunto de práticas de
desenvolvimento para ajudar equipes a
entregar mais rapidamente um software com
maior qualidade.
• Tem como maior objetivo reduzir os
problemas de ambiguidade na comunicação
entre todas as áreas;
• Ao desenvolver uma nova funcionalidade, os
usuários, clientes e demais interessados
contribuem com exemplos de como esta
nova implementação deve funcionar.
• Todas as áreas interessadas “falam a
mesma língua”.

134134
TDD
• Test Driven Development
• Red > Green > Refactor
• Vantagens:
• Todo código já nasce com testes unitários;
• Evita códigos complexos sem necessidade;
• Garante que os requisitos serão atendidos.
• Mesmas ferramentas de Teste Unitário.

135135
Integração contínua x Entrega contínua
• Para conseguir fazer pequenas entregas de valor em um curto espaço de
tempo é necessário utilizar ferramentas que possam dar rápido feedback sobre
a saúde da aplicação;
• As ferramentas nos ajudam a ter noção do real estado de saúde de uma
aplicação logo após o commit de alguma alteração.
• No processo de integração contínua, é possível efetuar o build da aplicação, o
deploy em um ambiente controlado, execução dos testes e obter o resultado ao
final do processo.
• No processo de entrega contínua, após todos os passos serem executados e o
resultado for sucesso, é feito o deploy da aplicação em ambiente de produção.

137137
Muito obrigada!
Thayse dos Santos Severiano
Especialista em Testes

Fundamentos de testes de Software

Mais conteúdo relacionado

Mais procurados

Semelhante a Fundamentos de testes de Software

Fundamentos de testes de Software