invertexto.

com - Ferramentas e Aplicativos Online

O Teste de Software é um processo que inclui muitas atividades diferentes, e a

execução do teste é somente uma parte.

Ciclo de Vida de Testes

1. Planejamento
2. Preparação
3. Especificação
4. Execução
5. Entrega

Atividades e Tarefas de Teste

- Planejamento do teste
- Monitoramento e controle de testes
- Análise de teste
- Modelagem de teste
- Implementação do teste
- Execução de teste
- Conclusão de teste.

Viés de confirmação - O dev pode não vir a aceitar que seu código tem erro.

PRINCIPIOS DE TESTE

1. O teste mostra a presença, NÃO a ausência de defeitos.

2. Testes exaustivos são impossíveis.
3. Testes antecipados economizam tempo e dinheiro
4. Os defeitos se agrupam (Princípio de Pareto)
5. Os testes se degradam (Paradoxo do Pesticida)
6. Os testes dependem do contexto
7. A ausência de erros é uma ilusão.

INDEPENDÊNCIA DOS TESTES

- Sem independência: Pelo autor.

- Alguma independência: Pelos colegas do autor da mesma equipe.
- Alta independência: Testadores de fora da equipe do autor.
 - Independência muito alta: Testadores de fora da organização.

Planilha de Check List

Tela – Adicionar em qual tela está realizado o teste.

Cenário de Teste – Qual será a situação de teste que será tentada realizar?

Etapas – Em Terceira Pessoa, faça um mini roteiro usando as palavras DADO,

QUANDO, ENTÃO.

Esperado – O que ERA para acontecer – o correto.

Obtido – O que ACONTECEU de fato – usando seu cenário de teste.

Tipo – BUG / FUNCIONAL / NÃO FUNCIONAL / MELHORIA / SUGESTÃO.

Status – Aprovado ou Reprovado.

Planilha Bug Report

Índice - Pegar os números do Check List (RXX)

Tela – Em qual tela o Bug está acontecendo.

Título - Vai ser quase igual o campo O QUE ESTÁ ACONTECENDO, imagine que o
DEV vai estar lendo isso para resolver, pense nele, não em você.

Passos para Reproduzir - Faça o caminho para chegar no Bug, simples e intuitivo,
mas com detalhes, use > para ajudar no processo.

O que está acontecendo - Explique um pouco mais do Bug - detalhe de forma sucinta
e de fácil entendimento.

Imagem - Você pode anexar imagens para facilitar o problema.

O que deveria acontecer - O que ERA para acontecer – o correto.

Device – Onde foi testado (mobile/web...).

Conta – Qual credencial foi usada.

Tag de Severidade

Nível Probabilidade Gravidade

01 Alta Muito
02 Alta Média
02 Alta Pouco
02 Média Muito
03 Média Média
03 Média Pouco
03 Baixa Muita
03 Baixa Média
04 Baixa Pouca

TIPOS DE TESTE

1. Funcional
2. Não-funcional
3. Caixa-branca
4. Caixa-preta
5. Relacionado à mudança (re-teste)

Teste funcional – avalia as funções que um componente ou sistema deve executar.

As funções são "o que" o objeto de teste deve fazer.

O principal objetivo do teste funcional é verificar a integridade funcional, a correção

funcional e a adequação funcional.

Teste não-funcional – avalia atributos que não sejam características funcionais de

um componente ou sistema. O teste não funcional é o teste de "quão bem o sistema
se comporta". O principal objetivo do teste não funcional é verificar as características
não funcionais da qualidade do software

Sete dos Oito Pilares da Qualidade do Produto Software são NÃO-FUNCIONAIS.

1. FUNCIONALIDADE
2. DESEMPENHO
 3. COMPATIBILIDADE
4. USABILIDADE
5. CONFIABILIDADE
6. SEGURANÇA
7. MANUTEBILIDADE
8. PORTABILIDADE

Artigo - T-REX PRADA III: Uma heurística mnemotécnica para testes em

dispositivos móveis

A mnemônica “T-REX PRADA III” — onde cada letra representará uma abordagem
de testes que deverá ser refletida quando for realizado os testes em uma aplicação
mobile.

T - Tema escuro;

R - Rotação do dispositivo móvel;

E - Experiência do usuário;

X - Xiaomi;

P - Permissões;

R - Responsividade;
A - Amplificação;
D - Diferentes modelos e versões;

A - Atualização do aplicativo atual;

I - Interrupções;

I - Internet;

I - Interceptadores.

Tema escuro - Ao usufruir desta configuração, o tema geral dos comportamentos

nativos presentes em seu dispositivo móvel se converte para o modo escuro (no que

chamamos de “dark mode”), fazendo que os elementos gráficos que previamente

estavam em um modo claro e com cores vivas, passam a ficar e em um modo escuro

e com cores frias, com o intuito de reduzir a exposição à luz azul e ao cansaço visual
dos usuários que os utilizem.

Rotação do dispositivo móvel - Geralmente, ao se desenvolver um aplicativo, é

concebido a ideia de estar utilizando apenas uma das maneiras de visualização (a
menos que a aplicação em si tenha algum fluxo onde a função é abrir a câmera do
seu dispositivo, ou abrir algum documento em específico que precisa ser visualizada
em modo paisagem).

Por este motivo, é necessário testar, se, ao alternar-se entre os modos, podem
ocorrer erros no layout da sua aplicação, como por exemplo um toast que pode não
ficar responsivo no modo paisagem.

Experiência do usuário - analisa “o como” que o usuário manipula a aplicação,

podendo abranger todas as interações que o usuário pode realizar com ele. Dentre
estas interações, podemos citar a atratividade que o aplicativo demonstra para o
usuário, perante a outras aplicações, se todas as funcionalidades daquele aplicativo
são intuitivas ao usuário, ou se o aplicativo é acessível para pessoas que possuem
alguma dificuldade motora e/ou visual.

Xiaomi - Esta seção é específica para dispositivos móveis que estejam operando o
Android SO. No caso em específico, estaremos nos referindo aos da marca Xiaomi.
O que ocorre é que a Xiaomi utiliza um ROM próprio que customiza o Android SO,
criando um firmware customizado, denominado de MIUI. Esta ROM modificada pode
muitas vezes apresentar comportamentos adversos e inesperados na aplicação que
você está testando, comportamentos estes que muitas vezes podem passar
despercebidos ao testar um outro dispositivo móvel com um Android SO não-
modificado.

Vale ressaltar que não é apenas o Xiaomi que pode realizar alterações no Android
SO, alguns outros exemplos são: TouchWiz da Samsung, EMUI da Huawei e Oxygem
da OnePlus.

Permissões - Dentro de ajustes, nas configurações da aplicação a ser testado em

específico, o testador tem a possibilidade de dar acesso a diferentes permissões,
dentro eles podendo ser: localização, câmera, biometria, notificações, contatos,
microfones, galeria, entre outros.

Um outro fator que também é importante de ser testado é como o aplicativo se

comporta quando o seu armazenamento e cachê são limpos.

Responsividade - trata-se de como é a adaptação de uma tela de uma aplicação em

relação a diferentes dispositivos móveis com tamanhos diversos de tela.

Amplificação - A amplificação pode ser ajustada dentro de ajustes, nas

configurações de tela, na subcategoria de zoom da tela (no caso dos dispositivos
iOS), ou dentro das melhorias de visibilidade, na subcategoria de zoom da tela (no
caso dos dispositivos Android). A amplificação faz com que todo o conteúdo
apresentado seja ampliado, facilitando a experiência para usuários que podem
possuir uma deficiência visual.

Diferentes modelos e versões - Independentemente se você estiver testando

aplicativos nativos ou híbridos, cada modelo de dispositivo e cada versão de
dispositivo pode apresentar diferenças em seu funcionamento, podendo ser ou não
de interface.

Como não é viável obter todos os diferentes modelos de dispositivos móveis e

versões dos SO que tem hoje no mercado, é recomendado pelo menos que o testador
realize os testes nos dispositivos e versões que mais são utilizados na aplicação, ou
no caso de uma aplicação nova, os dispositivos e versões que mais são utilizados no
mercado.
Atualização do aplicativo atual - Todas as aplicações passam por atualizações, e
em algum momento a aplicação testada vai ter que ser publicada para o público, seja
na Google Play Store (para aplicativos Android), ou na AppStore (para aplicativos
iOS).

Considerando que há uma versão nova do aplicativo atual, é necessário realizar-se

os testes de adequação. Durante esta atualização, primeiro é necessário realizar
testes de confirmação para averiguar se os novos recursos propostos na atualização
estão sendo implementadas de forma correta, e por conseguinte, é necessário
realizar testes regressivos para verificar se estes recursos que foram implementados
não afetaram nenhum outro funcionamento dentro do aplicativo.

Como há uma nova atualização para o aplicativo, também deve-se verificar como que
o aplicativo desatualizado vai se comportar com esta nova atualização (pode ser que
a API altere algum endpoint que vai afetar diretamente as versões desatualizadas do
aplicativo), e como que pode ser apresentado a mensagem de que há uma nova
atualização do aplicativo para o usuário.

Interrupções - Deve-se também verificar qual será o seu comportamento quando for
exercido a estas interrupções.

Por exemplo, deve-se indagar e verificar qual será o comportamento do aplicativo no

momento que o usuário estiver recebendo uma ligação, ou quando o usuário receber
uma notificação de prioridade 0, ou quando o usuário deixar o aplicativo em segundo
plano e tenta retomar a atividade, basicamente qualquer motivo no qual o aplicativo
fique sobreposto.

Todas estas sobreposições podem fazer com que em algum momento o aplicativo em
questão possa perder a sua sessão, expirando-se algum token de acesso, por
exemplo, fazendo com que o aplicativo não fique funcional, necessitando que ele seja
reinicializado.

Internet - Outra questão a ser verificada é sobre a estabilidade do aplicativo no

momento que ele é colocado em uma conexão com banda menor, como por exemplo
uma conexão 2G ou 3G.

Como que o aplicativo deve reagir com timeouts, e se é apresentado alguma

mensagem de feedback para o usuário verificar a sua conexão.
Também pode ser verificado como o aplicativo reage no momento que o usuário ativa
o modo avião, um recurso que desliga os sistemas de telefonia celular, Wi-Fi, NFC,
Bluetooth e GPS. Ou até mesmo verificar como se comporta quando há alguma
dificuldade de processamento do servidor interno (HTTP error 5xx).

Interceptadores - E por último, mas não menos importante, ao testar uma aplicação
mobile pode-se utilizar softwares interceptadores para verificar como que a
informação está se deslocando do front-end e chegando no back-end.

TESTE DE CAIXA BRANCA E CAIXA PRETA.

Teste de Caixa Branca – Teste, funcional ou não-funcional baseado na análise da

estrutura interna de um componente ou sistema. (Glossário ISTQB).

Teste de Caixa Preta – Teste, funcional ou não-funcional, sem referência à estrutura

interna ou componente ou do sistema.

TESTE RELACIONADO Á MUDANÇA.

Existem dois tipos de testes relacionados à mudança, são eles:

Teste de Confirmação - Verifica se o comportamento foi corrigido.

Teste de Regressão - Verifica se a implementação não atingiu outras partes do

software.

LEMBRETE

- SEMPRE REALIZAR TESTE DE CONFIRMAÇÃO APÓS UMA MUDANÇA.

- SEMPRE REALIZAR TESTE DE REGRESSÃO ANTES DE SUBIR EM
PRODUÇÃO (Aprovação final do cliente ou ir para Store).

NÍVEIS DE TESTES

1. Teste de unidade/unitário/componente -> atuação do DEV (VERIFICAÇÃO)

 2. Teste de integração -> atuação do DEV (VERIFICAÇÃO)
3. Teste de sistema -> atuação do QA (VERIFICAÇÃO)
4. Teste de aceite -> atuação do QA (VALIDAÇÃO)

Teste Unitário - Se concentra em componentes que são testáveis separadamente.

Os objetivos incluem: reduzir o risco; verificar os comportamentos funcional e não
funcional do componente ao projetado e especificado; construir a confiança na
qualidade do componente; encontrar defeitos no componente; evitar que os defeitos
espalhem para níveis mais altos de teste.

Teste de Integração - Se concentra nas interações entre componentes ou sistemas.

Incluem: reduzir o risco; verificar se os comportamentos funcionais e não-funcionais
das interfaces estão projetados e especificados.

Teste de Sistema – Se concentra no comportamento e nas capacidades de todo um

sistema ou produto, geralmente considerando as execuções das tarefas de ponta a
ponta do sistema e os comportamentos não funcionais exibidos ao executar tais
tarefas.

Teste de Aceite – Geralmente se concentra no comportamento na capacidade de

todo um sistema ou produto. Podem ser teste alfa e beta. Este nível de teste não visa
encontrar defeitos, mas, sim, garantir que o comportamento do sistema esteja de
acordo com o especificado para o usuário final.
Os níveis de teste são diferenciados pela seguinte lista incompleta de atributos, para
evitar a sobreposição de atividades de teste:

- Objeto de teste;
- Objetivos do teste;
- Base de teste;
- Defeitos e falhas;
- Abordagem e responsabilidades

A Regra 10 de Myers indica que o custo da correção de um defeito tende a ser cada
vez maior quanto mais tarde ele for descoberto. Defeitos encontrados nas fases
iniciais da etapa de desenvolvimento do software são mais baratos de serem
corrigidos do que aqueles encontrados na produção.

TÉCNICAS DE TESTES FUNCIONAIS

Teste A/B - Compara duas ou mais versões diferentes de um elemento ou recurso, a

fim de determinar qual versão é mais eficaz em termos de desempenho ou impacto.

Teste ad-hoc - Exploratório e de forma não planejada, informal e não estruturada.

Teste exploratório - Heurísticas, Mindmaps, Hipóteses, Histórico de falhas,

Exploração em pares, Documentação, Reports.

Teste E2E – Verifica o comportamento de um sistema de ponta a ponta, simulando o

fluxo completo de um usuário ou processo, desde a entrada de dados até a saída de
resultados.

Teste em pares - Técnica onde dois ou mais testadores trabalham em conjunto para
corrigir defeitos do software. Podem ter papeis diferentes ou trabalhem em conjunto,
podendo ou não apresentar um timebox de 60-90min.

Teste Negativo – O objetivo é identificar como o software lida com situações de erro
ou exceção, e se é capaz de se recuperar de forma adequada, garantindo a
integridade, confiabilidade e robustez do sistema.

Teste de desempenho – Tem quantidade de usuários esperados. Tem resultado

esperado. Não tem tempo de execução.
Teste de carga – Tem quantidade de usuários esperados. Tem resultado esperado.
Tem tempo de execução;

Teste de estresse – Tem como objetivo determinar o desempenho do sistema com

volumes esperados. Não tem quantidade de usuários esperados. Não tem resultado
esperado. Não tem tempo de execução.

Teste de Fumaça - Verifica se uma nova versão ou uma nova funcionalidade de um

sistema de software está minimamente funcional e pronta para testes mais detalhes.
É uma abordagem rápida e superficial para identificar problemas graves ou falhas
grosseiras no software antes de prosseguir para testes mais aprofundados.

Teste de Sanidade – Esse tipo de teste pode ser executado para verificar a
integridade de um sistema após uma atualização ou mudança significativa, por
exemplo. Um teste de sanidade é geralmente é rápido e simples, projetado para
detectar problemas óbvios, como falhas de inicialização., erros de configuração ou
problemas de conexão.

Procurar - ISTQB Glossary -> Glossário de termos.

Particionamento de equivalência (Teste funcional de caixa preta) - Divide os

dados em partições, de tal forma que todos os membros de uma determinada partição
deve ser processado da mesma maneira. Existem partições de equivalência para
valores válidos e inválidos.

Análise de valor limite (Teste funcional de caixa preta) - É o particionamento de

equivalência, só que implementa os seus valores limites (valor abaixo do limite, o valor
limite, e um valor acima do limite).

Teste de tabela de decisão (Teste funcional de caixa preta) - testa as possíveis

combinações de entrada de um sistema, é especialmente útil em sistemas que
possuem um grande número de possíveis entradas e saídas.

Teste de Transição de Estados (Teste funcional de caixa preta) – Tem como

objetivo verificar se um sistema reage corretamente a mudanças de estados ou
condições em que se encontra. Ele é aplicado em sistemas que possuem
comportamentos complexos que variam de acordo com o estado em que se
encontram.

Teste de casos de uso - Tem como objetivo verificar se um sistema atende aos
requisitos funcionais especificados em seus casos de uso. O caso de uso é uma
descrição de como o usuário interage com o sistema em uma determinada situação.

TÉCNICAS DE TESTE DE CAIXA BRANCA

Fluxograma - É um diagrama que descreve um processo, sistema ou algoritmo de

computador. São amplamente utilizados em várias áreas para documentar, estudar,
planejar, melhorar e comunicar processos complexos por meio de diagramas claros
e fácies de entender.

Fluxogramas usam retângulos, ovais, diamantes e muitas outras formas para definir
os tipos de passos, assim como setas conectoras para definir fluxo e sequência.

Teste de cobertura de instruções - Tem como objetivo garantir que todas as

instruções (comando ou sentença) do código fonte de um programa sejam
executadas durante a execução dos testes. São linhas de código que não necessitam
de condições para serem executadas.

Teste de cobertura de decisões/ramificações - Tem como objetivo garantir que

todas as decisões lógicas do código fonte de um programa sejam avaliadas durante
a excecução dos testes. 100% de decisão garante 100% de instrução.
TESTE BASEADO EM EXPERIÊNCIA (não é teste de caixa branca) - Baseia no
conhecimento e na experiência dos testadores para identificar possíveis defeitos ou
problemas no software. A suposição de erro é uma técnica usada para prever a
ocorrência de erros, defeitos e falhas, com base no conhecimento do Testador,
incluindo:

- Como o aplicativo funcionou no passado.

- Os tipos de erros que os desenvolvedores tendem a cometer e os tipos de
defeitos que resultam desses erros.
- Os tipos de falhas que ocorreram em outros aplicativos semelhantes.

TESTES EXPLORATÓRIOS E RBT TESTING

“Se você tentar criar um conjunto abrangente de testes para cobrir todas as
possibilidades, você passará todo o seu tempo escrevendo testes e não sobrará
tempo para executá-los”

O que você precisa não é o conjunto perfeito de casos de testes abrangentes. Em vez
disso você precisa de uma estratégia de teste que responda a duas perguntas
principais:

1. O software se comporta como planejado sob as condições que deveria

ser capaz de lidar?
2. Existem outros riscos?

ESTRATÉGIAS DE TESTES EXPLORATÓRIOS

Testes Exploratórios baseados em sessões - Jon Bach e James Bach criaram a

prática de gerenciamento de teste baseado em sessão (SBTM). Nela, você estrutura
seu tempo em uma série de sessões (time-box)

Durante cada sessão, você faz anotações para saber o que explorou e quais
informações você encontrou. No entanto, suas anotações são para o seu uso.

Estratégia utilizada para tornar o teste exploratório mais efetivo e com objetivos mais
claros.
Testes exploratórios baseados em cenários - Comece escrevendo uma lista de
perguntas que você espera que as atividades de teste respondam. Por exemplo, você
pode ter perguntas muito gerais, como essa:

- Um usuário pode realmente usar o software para a finalidade a que se destina?

- O fluxo básico de trabalho de trabalho funciona?

Você também pode ter perguntas especificas sobre recursos ou interações, tal como
este:

- O software falhará normalmente se estiver sobrecarregado?

- O software é seguro?

Faça um brainstorming de uma lista de perguntas. Quando você ficar sem energia,
revise sua lista.

Abordagens para a geração de hipóteses em testes exploratórios

- Heurísticas: Uma técnica cuja principal função é auxiliar o testador a fazer

suposições com algum embasamento formal, seja por meio de mnemônicas
ou mapas mentais.

- Phoenix Checklist: Serve para auxiliar o testador a identificar novos cenários

de teste ou para identificar a causa raiz um defeito.
 - Diagrama de Ishikawa: Tem por objetivo determinar as origens de um
problema por meio da geração de uma lista detalhada das suas causas e as
suas sub causas.

- Os Cinco Porquês: Técnica cujo proposito é promover uma análise profunda

do problema em que estamos lidando por meio do questionamento.

DEPOIS DISSO TUDO, MUDE A SUA PERPECTIVA

Você como um explorador, para aumentar as chances de ver surpresas, você tem
que fazer questão de mudar sua perspectiva.

Direcione sua atenção para diferentes aspectos do software. Assistir partes diferentes
da tela. Espere surpresas e procure-as intencionalmente.

COM OUTRA PERPECTIVA

Sintonize cuidadosamente as coisas que você costuma observar; preste atenção aos
detalhes que você geralmente ignora.

Encontre uma maneira de cavar mais fundo. Considere uma área de um aplicativo
que você pode explorar e pergunte a si mesmo como você pode ir além.

COMO SABER QUANDO VOCÊ EXPLOROU O SUFICIENTE? Sua exploração

respondeu a todas as perguntas em aberto e não há mais incógnitas. Você não está
apreendendo nada novo. Você caracterizou as capacidades, limitações e riscos da
implementação existente.

Como resultado você se sente como se estivesse lidando com uma quantidade
conhecida sem mais surpresas descoberta, pelo menos por enquanto. Mais
informações não vão mudar nada. Você poderia coletar mais informações, mas não
faz mais sentido

QUANDO SE TERMINA DE TESTAR?

Testado = Verificado + Explorado

Você não termina o teste até verificar se o software atende as expectativas e explorar
se há riscos adicionais. Uma estratégia abrangente de teste incorpora ambas as
abordagens:

- Existem coisas que eu poderia fazer agora que não poderia fazer antes?
- Existem coisas que não posso fazer agora e que poderia fazer antes?
- Minhas ações têm resultados diferentes agora do que antes?

O QUE APRENDEMOS COM ISSO?

Resumo:

- A princípio o que você precisa não é o conjunto perfeito de casos de testes

abrangentes.
- Em SBTM você faz anotações para saber o que explorou e quais informações
você encontrou em um curto período de tempo.
- Em CBTM você faz uma lista de perguntas que você espera que as atividades
de teste respondam.
- Todas as estratégias devem possuir background de geração de hipóteses
- No final, mude sua perspectiva e refaça os testes.

RBT (Risk –Based Testing) (Teste Baseado em Risco).

O objetivo do risk-based testing é concentrar o teste em funções-chave e dedicar mais

tempo a elas.
É um método de teste de software baseado na probabilidade de risco. Isso envolve a
análise do risco com base na complexidade do software, criticidade do negócio,
frequência de uso e prováveis aéreas de defeito, entre outros fatores.

Desvantagens:

- Fazer análise de risco no final do processo de desenvolvimento do produto.

- Determinar incorretamente o nível aceitável de risco
- Concentra-se apenas em aéreas de alto risco
- Não identificar os riscos que afetam o desempenho futuro
- Os envolvidos na avaliação de riscos não tem experiencia ou conhecimento
para entender completamente o impacto dos resultados.
MOBILE:

Há três formas de aplicação mobile:

- Aplicações Web

- Aplicações Nativas;

- Aplicações Hibridas.

Aplicações Web - O acesso a uma aplicação Web faz-se, obrigatoriamente, através

de um browser. A maioria destas aplicações são desenvolvidas em JavaScript, CSS
e HTML5, ou seja, linguagens Web. Adequam-se a apresentação de dados, mas não
permitem a utilização de funcionalidades do dispositivo móvel, como por exemplo
câmera fotográfica.

Uma vez que são acedidas através de um browser não requerem instalação e,
tipicamente, têm um tempo de desenvolvimento curto e são mais baratas que as
aplicações nativas. As Web apps não podem ser utilizadas sem ligação à internet e
são mais difíceis de encontrar porque não há um sistema de pesquisa global como
os disponibilizadas nas lojas de aplicações.

Webview é quando se abre uma janela da web dentro de seu aplicativo.

Vantagens das aplicações Web

Multiplataforma: Uma aplicação web para mobile pode ser acessada em vários
dispositivos e plataformas sem a necessidade de desenvolver versões separadas
para cada sistema operacional.

Atualizações simples: As atualizações de uma aplicação web são instantâneas para

os usuários, pois não exigem a aprovação da loja de aplicativos. Os usuários sempre
têm acesso à versão mais recente.

Desenvolvimento rápido e econômico: O desenvolvimento de uma aplicação web

pode ser mais rápido e econômico, especialmente se os desenvolvedores já
possuírem experiência em tecnologias web.

Manutenção simples: A manutenção é centralizada, pois qualquer atualização ou

correção pode ser no servidor, refletindo imediatamente para todos os usuários.

Desvantagens das aplicações Web

Limitação: As aplicações web podem ter dificuldade em acessar totalmente os
recursos nativos do dispositivo, como câmera, GPS e sensores, em comparação com
aplicações nativas ou híbridas.

Desempenho inferior: Em alguns casos, as aplicações web podem ter desempenho

inferior em comparação com aplicações nativas, especialmente para aplicativos que
exigem muitos recursos gráficos ou processamento intensivo.

Dependência de uma internet estável: Muitas aplicações web dependem de uma

conexão de internet estável.

Menos integrações com o SO: As aplicações web têm menos integração com os
sistemas operacionais dos dispositivos em comparação com aplicações nativas, o
que pode resultar em uma experiência de usuário menos coesa.

Aplicações Nativas - O app nativo é o aplicativo tradicional: aquele que você baixa
diretamente na Apple Store ou na Google Play Store. Ele é desenvolvido com base
no sistema operacional em que vai funcionar, e usa os recursos nativos do aparelho
para sua operação, como câmera e GPS.

Alguns dos principais aplicativos que você utiliza no dia a dia são apps nativos, como
WhatsApp, Facebook e Instagram. As vantagens desse tipo de app estão
relacionadas ao fato de serem desenvolvidos de forma personalizada e exclusiva para
cada plataforma.

Vantagens das aplicações nativas

Alto Desempenho: Instalados diretamente nos dispositivos, eles utilizam todo o

poder de processamento disponível para executar ações rapidamente e diminuir
tempos de carregamento. A palavra-chave aqui é total compatibilidade com os
recursos da plataforma em questão.

Alto UI/UX: Os apps nativos também permitem a criação de interfaces que elevam a
experiência do usuário a outro patamar. Cada sistema operacional tem diretrizes
especificas de interface do usuário com práticas recomendadas.

Segurança: Todos os apps têm vulnerabilidade nesse quesito, mas os nativos são
mais fáceis de proteger pois não dependem de tecnologias mais suscetíveis a
ataques de hackers, como a JavaScript.
Aproveitamento: Aplicativos nativos extraem ao máximo os recursos de hardware
da plataforma escolhida.

Desvantagens das aplicações nativas

Tempo: Aplicativos nativos podem consumir mais tempo no desenvolvimento, uma

vez que demandam mais de uma versão para contemplar os usuários de cada
sistema operacional.

Recursos: Além do tempo, os aplicativos nativos podem exigir mais recursos para
serem desenvolvidos. Vai ser necessário contar com profissionais que dominem os
sistemas operacionais mais utilizados.

Manutenção: Como você vai estar lidando com duas bases de códigos diferentes,
manter aplicativos nativos acaba demandando atenção na gestão.

Aplicações Hibridas - Diferente dos nativos, os aplicativos híbridos são criados com
uma linguagem acessível para várias plataformas. Nestes casos são utilizadas
habilidades e tecnologias padrão Web, como HTML, CSS e JavaScript em vez de
linguagens nativas de cada sistema operacional.

Podem ser desenvolvidas com recurso a frameworks especificas, como o React

Native e o Flutter, e a grande vantagem em relação às aplicações nativas é o ciclo de
desenvolvimento ser substancialmente mais curto e mais barato.

O acesso faz-se através da App Store ou Google Play e durante a sua utilização
podem usar-se várias funcionalidades do dispositivo.

Vantagens das aplicações híbridas

Tecnologia padrão: As tecnologias usadas são mais populares, sendo mais fácil
encontrar profissionais aptos a desenvolvê-las.

Custo: O custo para o desenvolvimento de aplicativos híbridos geralmente é menor,

uma vez que reutiliza o mesmo código em várias plataformas.

Agilidade: Desenvolvedores economizam tempo quando o mesmo código pode ser

executado tanto no iOS quanto no Android, sendo uma boa opção para quem quer
lançar um app rapidamente no mercado.

Desvantagens das aplicações híbridas

Desempenho: Quando comparados aos aplicativos nativos, os híbridos não
funcionam tão rapidamente. Sua arquitetura conta com uma camada adicional entre
o código-fonte e a plataforma móvel e isso pode torná-los mais lentos.

Experiência do usuário: Cada plataforma tem suas regras de design. Ao usar

aplicativos híbridos com uma só base de código, é praticamente impossível cobrir
todos os detalhes que mudam em cada interface, comprometendo assim a
experiência de navegação do usuário. Além disso, é mais difícil depurar aplicativos
híbridos. Isso torna mais complexo detectar e corrigir bugs.

Recursos: Apesar de inicialmente mais baratos, desenvolver bons aplicativos

híbridos também demanda profissionais com larga experiência na resolução de
problemas que essa abordagem traz a médio e longo prazo.

Dependência de terceiros: Apesar de econômicos, os aplicativos híbridos

dependem de ferramentas de terceiros, diminuindo a autonomia para inovação.

Diferenças de Fabricantes - As diferenças entre os diversos fabricantes de celulares

podem ser amplas e abrangem várias áreas, desde hardware e design até software
e ecossistemas.

Xiaomi utiliza um ROM próprio que customiza o Android SO, criando um firmware
customizado, denominado de MIUI. Está ROM modificada pode muitas vezes
apresentar comportamentos adversos e inesperados na aplicação que você está
testando, comportamentos estes que muitas vezes podem passar despercebidos ao
testar um outro dispositivo móvel com um Android SO não-modificado.

Uma destas especificidades de alguns dispositivos Xiaomi é o de forçar o dark mode

em uma aplicação mobile (por mais que o dark mode seja bloqueado para o Android
SO), fazendo com que a interface fique numa propriedade que não fora estudado
anteriormente pelos designers. Ou quando o dispositivo não reconhece a biometria
facial ao entrar em uma aplicação (a não ser que este esteja programado no código
da aplicação que o parâmetro de autenticação seja fraco ao invés de forte), como é
um caso específico que ocorre nos Xiaomi Redmi Note 08 Pro.

Vale ressaltar que não é apenas o Xiaomi que pode realizar alterações no Android
SO, alguns outros exemplos são: TouchWiz da Samsung, EMUI da Huawei e Oxygem
da One Plus.

DIFERENÇAS ENTRE TESTAR NO DEVICE FÍSICO, EMULADOR E SIMULADOR

Emuladores: São ambientes de software que imitam “completamente” o hardware e

o software de um dispositivo específico.

Vantagens dos Emuladores: Permitem testar em diferentes versões do sistema

operacional e dispositivos. Úteis para depurar e testar funcionalidades básicas.
Disponíveis para várias plataformas (Windows macOS, Lunux).

Desvantagens dos Emuladores: Geralmente mais lentos do que dispositivos físicos.

Podem não refletir completamente o desempenho real do hardware.

Simuladores: Replicam o comportamento de um dispositivo, mas não emulam o

hardware. São comumente usados em ambientes de desenvolvimento integrado
(IDE). Melhor para ver responsividade de tela.

Vantagens dos Simuladores: Rápidos e eficientes para testar e depurar. Integração

direta com o ambiente de desenvolvimento.

Desvantagens dos Simuladores: Podem não representar com precisão o

desempenho do hardware real. Limitados em termos de teste de hardware específico.
Dispositivos Físicos (Device): Envolve usar um smartphone ou tablet real para
avaliar o aplicativo.

Vantagens do Device: Oferece a experiência mais próxima do mundo real. Permite

testar interações reais do usuário e verificar o desempenho real do hardware.

Desvantagens: Pode ser mais demorado e caro, especialmente para suportar uma
variedade de dispositivos. Acessibilidade limitada a dispositivos específicos.

DIFERENÇA EM .APK E .IPA

APK (Android Application Package / Android Package Kit): É o formato de arquivo

usado pelo sistema operacional Android. Contém todos os elementos necessários
para a instalação de um aplicativo no Android, como código de programação,
recursos, gráficos, etc. Pode ser instalado em dispositivos Android usando a Google
Play Store ou instalando manualmente.

IPA (iOS App Store Package / iPhone Archive): É o formato de arquivo usado pelo
sistema operacional iOS (iPhone, iPad, iPod Touch). Contém o código executável,
recursos, ícones, imagens e outros arquivos necessários para instalar o aplicativo no
iOS. Pode ser instalado em dispositivos iOS através da App Store ou usando métodos
alternativos como instalação via iTunes.

Ao contrário do .APK, para instalar o .IPA você tem de ter um certificado de teste no
seu iOS e só pode instalar a build via sites de distribuição (appcenter, diawi, etc).

SDK (Software Development Kit): Um SDK é um conjunto de ferramentas de

software que os desenvolvedores utilizam para criar aplicativos para uma plataforma
específica. Essas ferramentas geralmente incluem bibliotecas, documentação,
exemplos de código, compiladores e outras utilidades que facilitam o desenvolvimento
de software para um ambiente específico.

O uso de um SDK geralmente segue três etapas:

- Comprar ou baixar e instalar um SDK específico da plataforma.

- Usar o SDK para desenvolver sua aplicação em um ambiente de
desenvolvimento integrado.
- Utilizar as instruções, documentação, exemplos de código e ferramentas de
teste incluídas no SDK para um desenvolvimento eficiente.
Branches (Ramos) - Um branch é uma linha de desenvolvimento independente no
repositório de código-fonte. Ele permite que os desenvolvedores trabalhem em
funcionalidades, correções de bugs ou outras alterações sem interferir no código
principal.

Uso comum: Desenvolvedores criam branches para trabalhar em novas

funcionalidades ou correções. Depois de concluído o trabalho no branch, as
alterações podem ser mescladas (merged) de volta ao branch principal.

Builds - Um build é o processo de compilar o código-fonte em um formato executável

ou em outros artefatos executáveis. Isso envolve a tradução do código-fonte em
linguagem de máquina ou em um formato que possa ser executado pela máquina.

Uso comum: Os builds são frequentemente automatizados para garantir que o código
seja compilado corretamente e que o software seja funcional. Eles são fundamentais
para a implantação contínua e garantem que as alterações no código-fonte não
introduzam erros.

PR’s (Pull Requests) - Um PR é uma solicitação feita por um desenvolvedor para

mesclar suas alterações de um branch para outro. Em muitas plataformas de controle
de versão, como o GitHub, o Pull Requests é uma ferramenta para revisão de código
e colaboração.

Um desenvolvedor cria um branch para uma nova funcionalidade ou correção de bug,

faz as alterações necessárias e, em seguida, abre um PR para mesclar essas
alterações de volta ao branch principal. Outros membros da equipe revisam o código,
discutem as alterações e, se aprovado, o código é mesclado.

AMBIENTES DE TESTES

Master/Main - O branch ”master" é muitas vezes considerado o branch principal e

estável do código-fonte. Ele representa a versão mais recente e testada do software
que está pronto para ser implantado em produção.

Cada commit no “master” geralmente reflete uma versão do software que passou por
testes rigorosos. É considerado o ponto de referência para a versão atual do software
em produção.
Develop/TEST - O branch “develop” é utilizado para integração contínua. Ele reflete
o estado mais recente do código-fonte que está em desenvolvimento ativo. Novos
recursos e correções de bugs são mesclados no branch “developed”.

Pode não ser tão estável quanto o branch “master”, pois pode conter código em
desenvolvimento que ainda não passou por testes extensivos. É o ambiente que não
é atribuído recursos para simular o ambiente de produção.

Release/QA/Libera - O branch “release” é criado quando o desenvolvimento em

“develop” atinge um ponto em que uma versão estável está prestes a ser lançada.
Testes finais e correções de bugs são realizados no branch “release”. Uma vez que
o “release” é considerado pronto, ele é mesclado tanto no branch “master” quanto no
“developed”.

Pode conter apenas pequenas correções de bugs e ajustes finais antes do

lançamento. É o ambiente que tenta simular ao máximo o ambiente de produção.

Device Farms – Refere-se a um serviço ou plataforma que oferece a capacidade de

testar aplicativos em uma ampla variedade de dispositivos físicos. Esses dispositivos
podem incluir smartphones, tablets, smartwatch e outros dispositivos móveis.

O objetivo é permitir que desenvolvedores que testem seus aplicativos em uma

variedade de ambientes de hardware e software para garantir que funcionem
corretamente em diferentes dispositivos antes do lançamento.

INTERCEPTADORES

São como os encontrados em ferramentas como Burp Suite e Proxyman, são

componentes que ficam entre uma aplicação cliente (como um navegador web,
aplicativo móvel, etc.) e um servidor, interceptando e manipulando as comunicações
entre eles. Essas ferramentas são amplamente usadas por profissionais de
segurança, desenvolvedores e testadores para analisar, depurar e modificar o tráfego
entre um cliente e um servidor.

TESTES WEB

Diferentes Browsers – Testar em diferentes navegadores é uma prática crucial no

desenvolvimento web por várias razões. Cada navegador tem sua própria engine de
renderização, implementa padrões web de maneiras ligeiramente diferentes e pode
ter suporte variável para recursos específicos.

Compatibilidade com Padrões Web – Os navegadores podem interpretar e

implementar os padrões web de maneiras diferentes. Testas em diferentes
navegadores ajudar a garantir que sua aplicação web seja compatível com esses
padrões e exibida corretamente para todos os usuários, independentemente do
navegador que estão usando.

Renderização e Desempenho – Diferentes navegadores podem ter engines de

renderização distintas, o que pode afetar a forma como as páginas web são exibidas,
Testas em vários navegadores ajuda a garantir que a aparência e o desempenho da
sua aplicação sejam consistentes em todas as plataformas.

Suporte para Recursos e Tecnologias: Alguns navegadores podem oferecer

suporte a recursos específicos, como APIs, HTML5, CSS3, JavaScript ou outras
tecnologias emergentes, de maneiras diferentes. Testar em diferentes navegadores
permite identificar quais recursos podem ser utilizados de forma consistente em todas
as plataformas.
Experiência do usuário: Diferentes navegadores podem proporcionar diferentes
experiências de usuário, seja em termos de velocidade de carregamento,
responsividade ou comportamento geral. Testar em vários navegadores ajuda a
garantir uma experiência de usuário mais uniforme e satisfatória.

Correção de Bugs Específicos do Navegador: Alguns bugs podem ser específicos

de determinados navegadores. Testas em diferentes ambientes ajuda a identificar e
corrigir problemas que podem ocorrer apenas em um navegador específico.

Inspecionar página web – O recurso “Inspecionar” de um navegador web permite

que os desenvolvedores examinem e interajam com o código-fonte HTML, CSS e
JavaScript de uma página web em tempo real. Essa funcionalidade é uma parte
fundamental das ferramentas de desenvolvedor oferecidas pelos navegadores
modernos e desempenha vários papéis importantes:

- Análise de desempenho: Lighthouse no Chrome, Page Speed e afins.

- Testes Responsivos.
- Estilo e Layout: Broken Link Checker.

Guia WCAG - Guia WCAG | Guia de consulta rápida (guia-wcag.com)

O Web Content Acessibility Guidelines (Diretrizes de Acessibilidade para Conteúdo

Web), é um conjunto de diretrizes desenvolvido pelo World Wide Web Consortium
(W3C) para melhorar a acessibilidade de conteúdo na web para pessoas com
deficiência. O objetivo principal do WCAG é tornar a web mais inclusiva, garantindo
que websites e aplicativos sejam acessíveis a uma ampla variedade de usuários,
independentemente de suas habilidades ou deficiências.
Heurística Alter Face para testes Web - ALTER FACE Test Heuristic | PPT
(slideshare.net)

A - Ativação: Princípio
de ativação quando é
interagido com um
elemento (ex.: botão).

L – Layers: Quando há
elementos que se
subscrevem na tela (ex.:
bottomsheet).

T – Timing: Esperado
para dar feedback ao
usuário (ex.: componente visível por 05seg).

E – Exclusion Principle: Duas coisas não podem ocupar o mesmo espaço ao

mesmo tempo (ex.: 02 pop-ups).

R – Removable: Se há elementos para que se possa sair de janela/tela.

F – Floating: Elementos flutuantes ao dar scroll na tela.

A – Achievable: Algum elemento que não é alcançável à vista do usuário.

C – Collision: Algum elemento que interage com outro elemento em movimento,

havendo uma colisão.

E - Expansão: Layout que pode ser deformado dependendo da ação que o usuário
fez em um determinado elemento.

Terminologias
Constante – Em programação, uma constante armazena um valor fixo, que NÃO
mudará com o tempo de excecução do programa. Ou seja. O valor será definido uma
única vez e jamais será alterado durante a execução da aplicação.

Variável - É uma entidade destinada a guardar uma informação. Chama-se variável,

pois o valor contido nesta varia com o tempo, ou seja, não é um valor fixo. O conteúdo
de uma variável pode ser alterado, consultado ou apagado quantas vezes foram
necessárias no algoritmo.

Ao alterar o conteúdo de uma variável, a informação anterior é perdida, ou seja, a

variável armazena sempre a última informação recebida.

Exemplo: Cálculo da área de um círculo

Operadores

FOR: Loop de Repetição - O Loop For é usado para iterar sobre uma sequência
(como uma lista, uma tupla, uma string ou um intervalo numérico).
WHILE: Loop de Repetição com Condição - O Loop while executa um bloco de
código enquanto uma condição for verdadeira.

IF: Estrutura Condicional – O If é usado para tomar decisões condicionais no seu

código.

Array – Em programação, um array é uma estrutura de dados que armazena

elementos do mesmo tipo em posições de memórias contiguas. Os elementos em um
array podem ser acessados por meio de um índice ou uma chave. Os arrays são
utilizados para armazenar coleções de dados de maneira eficiente.

Termos Técnicos de Programação

Glossario (2) (1).pdf

LINE Design System for Messenger - Components

Buttons: floating action button - Material Design

UI (User Interface)

Definição: Refere aos elementos visuais e interativos com os quais os usuários interagem
em um produto digital. Isso inclui elementos como botões, menus, barras de navegação,
cores, tipografia e todos os elementos visíveis na tela.

Foco: A UI concentra-se na aparência estética e na apresentação visual de um produto. Uma

boa UI visa tornar a interação do usuário eficiente, intuitiva e agradável, garantindo que os
elementos visuais sejam claros e estejam dispostos de maneira lógica.

UX (User Experience)

Definição: Abrange a experiencia geral do usuário ao interagir com um produto, indo além
dos aspectos visuais. Envolve como os usuários se sentem ao usar o produto, quão fácil é
para eles realizarem tarefas especificas e como a interação global impacta a satisfação do
usuário.

Foco: A UX considera a jornada completa do usuário, desde o momento em que ele acessa
o produto até a conclusão de suas tarefas. Isso inclui fatores como facilidade de uso,
eficiência, utilidade, acessibilidade e prazer geral do usuário durante a interação.

Os Seis Princípios de design de Don Norman

1. Visibilidade
2. Feedback
3. Restrições
4. Mapeamento
5. Consistência
6. Affordance

50 UX Case Studies To Improve Your Product Skills (growth.design)

Conceitos de API

API Rest (Representational State Transfer) é um estilo de arquitetura de software que

define um conjunto de restrições para o design de serviços web/mobile. Uma API RESTful
utiliza os métodos HTTP (como GET, POST, PUT, DELETE) para realizar operações em
recursos, que podem ser identificados por URLs.
Por exemplo, imagine uma empresa distribuidora de livros. Essa distribuidora de livros
poderia oferecer aos clientes uma aplicação em nuvem onde os atendentes de uma livraria
verificassem a disponibilidade de um título diretamente com a distribuidora. Essa aplicação
poderia ser um projeto caro, limitado pela plataforma e que exigiria longos períodos de
desenvolvimento e manutenção contínua.

Como alternativa, a distribuidora, poderia fornecer uma API para verificar a disponibilidade
no estoque. Essa abordagem proporciona vários benefícios, incluindo:

- O acesso aos dados por meio de uma API ajuda os clientes a consolidarem
informações sobre seu inventário em um único local.
- A distribuidora de livros pode fazer alterações nos sistemas internos sem causar
impacto nos clientes, contanto que o comportamento da API não mude.
- Com uma API disponibilizada publicamente, os desenvolvedores que trabalham para
a distribuidora de livros, os vendedores ou terceiros poderiam desenvolver uma
aplicação para ajudar os clientes a encontrarem os livros que procuram. Isso poderia
resultar no aumento das vendas ou outras oportunidades de negócios.

Métodos HTTP

GET – O método GET solicita a representação de um recurso específico. Requisições

utilizando o método GET devem retornar apenas dados.

POST – O método POST é utilizado para submeter uma entidade a um recurso específico,
frequentemente causando uma mudança no estado do recurso ou efeitos colaterais no
servidor.

PUT – O método PUT substitui todas as atuais representações do recurso de destino pela
carga de dados de requisição.

PATCH – O método PATCH é utilizado para aplicar modificações parciais em um recurso.

DELETE – O método DELETE remove um recurso específico.

Swagger - é um conjunto de ferramentas de códigos aberto que permite a criação,
documentação e consumo de serviços da web RESTful. O Swagger inclui uma especificação
que descreve a estrutura de um serviço RESTful, juntamente com um conjunto de
ferramentas que suportam a implementação e a documentação dessa especificação.

Response Codes

Heurística VADER (Verbos, Autorização, Dados, Erros, Responsividade)

VERBOS - Verbos HTTP são comumente também conhecidos como métodos HTTP, essa
parte consiste em testar os verbos aptos e não aptos para o end-point. Coloco abaixo uma
descrição básica dos principais verbos/métodos:
 - GET: Serve para buscar dados, pode ser cacheado e nunca deve ser usado com
dados sensíveis.
- POST: Pode criar e atualizar dados, possui um corpo/payload e preferencialmente
não deve ter cache.
- PUT: Usado para atualizar dados, pode possuir corpo, mas normalmente é usado no
próprio path da url, que é o caminho para o identificador do recurso e a resposta bem-
sucedida pode ter corpo.
- DELETE: Usado para excluir dados e pode possuir corpo para envio, mas
normalmente é usado no próprio path da url com o identificador.

AUTORIZAÇÃO - Nesta etapa tudo se volta para o tipo de autorização que você utiliza, assim
você vai saber quais os pontos que que você tem que tomar cuidado, basicamente existem
dois tipos mais populares de autorização que são:

Basic: credenciais codificadas em base64

Bearer: tokens bearer para acessar recursos protegidos por OAuth 2.0.

Após isso, você pode realizar alguns cenários de testes utilizando alguns pontos:

- Validar Token (tipo de criptografia utilizar e testes de segurança).

- Quais os recursos a API Key devem acessar.
- Validar o não uso de Token, API Key ou Usuário e senha exposta na URL.
- Testes de Token, API Key ou Usuário e senha inválido ou inexistente.
- Restrições de acesso assim que for autorizado.

DADOS – Nesta parte, olhamos para os dados que trafegam na API, sendo um payload de
envio ou resposta de um end-point. Neste momento podemos realizar alguns testes:

- Tipagem: validação dos tipos do payload de envio e resposta com base na

documentação.
- Paginação: validar referencias para página anterior e seguinte, assim como a
contagem de itens quando for array.
- Formato: validar o tipo de retorno esperado pela API, os mais comuns são
application/json e application/xml.
- Tamanho: validar o tamanho do envio e retorno da API, para não afetar ao tempo de
resposta do end-point.

ERROS – Aqui, avaliamos minuciosamente o código de resposta para cada erro e suas
respectivas mensagens, também podemos incluir padrões de exceções para cada erros.
Abaixo detalhamos os principais códigos de erros:
 - 400 Bad Request: Servidor não entendeu a requisição feita.
- 403 Forbidden: Proibido o acesso em um determinador recurso.
- 404 Not Found: Servidor não encontrou o recurso solicitado
- 500 Internal Server Error: Erro genérico para quando o servidor encontrou algo que
ele não sabe lidar.
- 503 Service Unavailable: Quando o servidor se encontra em manutenção

RESPONSIVIDADE

- Tempo de resposta: Dada as ações que o end-point pode realizar, analisar o tempo
de resposta para essas ações e criar um padrão para o projeto.
- Falha rápida (fail test): É o conceito de interromper uma operação ao invés de tentar
continuar ou excecutar as etapas seguintes do end-point.
- Concorrência: A realização de requisições em sequência ou ao mesmo tempo, a fim
de avaliar a carga que pode ser aplicada ao servidor.