Teste de Software

 

O que é Teste de Software?

​

​

​

​

​

​​​​​

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

​

 

 

 

"O Teste de Software é uma atividade estruturada, baseada em técnicas e normas, cujo objetivo é identificar defeitos antes que o sistema chegue às mãos do cliente. Através da execução de cenários e validações cuidadosamente planejadas, garantimos que o software esteja funcionando corretamente, atendendo às regras de negócio e às expectativas do usuário final.

​

Além de aplicar métodos e boas práticas, o Analista de Teste também usa sua experiência, intuição e conhecimento do sistema para identificar pontos frágeis. Em geral, os testes são elaborados para forçar o erro, explorando combinações atípicas e situações inesperadas. Por isso, costumamos dizer que a atividade de teste tem uma natureza destrutiva — não no sentido negativo, mas como uma abordagem intencional para revelar os limites do sistema e torná-lo mais seguro e confiável.

Em outras palavras, testar é desafiar o sistema antes que o cliente o faça."  Teste de Software, Testes Manuais. Soares, Ana Paula Costa. Edição Revisada. 2025.

 

“Em 1979, Glenford Myers publicou o livro The Art of Software Testing, uma obra pioneira que consolidou os fundamentos da área de teste de software. A publicação não apenas reuniu conceitos e boas práticas da época, como também popularizou o termo “teste de software”, nomeando oficialmente a nossa área de atuação.” Teste de Software, Testes Manuais. Soares, Ana Paula Costa. Edição Revisada. 2025.

 

O que é Teste Manual?

 

"Os testes manuais, especialmente os baseados na técnica de caixa preta, são fundamentais para validar se um sistema está de acordo com as regras de negócio, os padrões visuais definidos, as mensagens apresentadas ao usuário, bem como o formato, tipo, tamanho e características dos campos. Também envolvem a verificação do uso adequado de hints, textos de ajuda, padronização de cores, ortografia e demais aspectos funcionais e visuais especificados pelo cliente.

​

Esse tipo de validação é realizado pelos analistas de teste antes que o sistema seja entregue ao cliente, garantindo que tudo esteja funcionando conforme o esperado do ponto de vista do usuário final. Neste livro, vamos explorar os diversos tipos de validações manuais, com ênfase na importância, necessidade e relevância desse processo dentro do ciclo de desenvolvimento." Teste de Software, Testes Manuais. Soares, Ana Paula Costa. Edição Revisada. 2025.

​

É importante que o Teste do QA aconteça antes da homologação pelo Cliente - o TESTE BETA, para que o impacto dos eventuais defeitos existentes não seja sentido pelos clientes relacionados ao projeto. 

 

Teste de Software é um processo normatizado que usa técnicas de execução de sistema para encontrar defeitos antes que este seja entregue ao cliente – usuário final.

 

A missão do teste de software é  assegurar que o software  seja confiável,  funcional e de alta qualidade,  proporcionando  aos usuários a melhor experiência possível e  minimizando riscos associados a defeitos e problemas

Fazemos:

Testes funcionais e não funcionais

Mitigação de erros sistêmicos

Testes de Carga e Performance de Serviços

​

A qualidade começa na documentação!

 

É importante que os projetos mantenham legado  e informações atualizadas para os sistemas que desenvolvem.

É importante o envolvimento do QA desde o início do projeto.

Fazendo o entendimento das documentações

Refinando e tirando dúvidas

Elaborando o roteiro de teste

O envolvimento do profissional nos ritos e cerimônias faz com que o conhecimento agregado seja relevante para a qualidade do projeto

​

PILARES

​

Processo

Um processo bem definido ajuda a garantir que todos os aspectos do teste sejam abordados de maneira sistemática e eficiente.

Desde quando o profissional é alocado até o monitoramento da implantação

 

Um processo de teste estruturado permite que a área de QA agregue valor à empresa, garantindo a entrega de software de qualidade dentro dos prazos e atendendo às necessidades do cliente. Respeitar as fases do processo de teste assegura que todos os aspectos do sistema sejam validados e a qualidade seja mantida.
Referência: "Software Testing: A Craftsman's Approach" de Paul C. Jorgensen

 

Seguir as fases do teste ajuda a identificar problemas cedo, reduzindo custos de retrabalho e aumentando a eficiência do processo. Testes bem estruturados são mais rápidos e eficazes, permitindo detectar falhas antes de impactar os usuários finais.
Referência: "Agile Testing: A Practical Guide for Testers and Agile Teams" de Lisa Crispin e Janet Gregory

 

A execução de testes bem definidos e sequenciais resulta em um produto final mais confiável. Isso evita falhas críticas no lançamento e fortalece a confiança do cliente e da empresa no software entregue.
Referência: "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" de Jez Humble e David Farley

​

Produto

O produto é um pilar essencial no processo de teste porque a qualidade do produto final reflete diretamente a eficácia dos testes realizados. O foco em garantir que o produto esteja de acordo com os requisitos e atenda às expectativas dos usuários finais é fundamental.

 "Software Testing: A Craftsman's Approach" de Paul C. Jorgensen

​

Pessoas

As pessoas são o pilar central de qualquer processo de teste, pois são elas que executam, planejam e analisam os testes. A habilidade, conhecimento e colaboração entre os membros da equipe são cruciais para o sucesso do processo. Testadores bem treinados e engajados garantem que os testes sejam conduzidos com qualidade, e a colaboração entre desenvolvimento, QA e outras áreas agrega um valor significativo ao projeto.

"The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win" de Gene Kim, Kevin Behr e George Spafford

​

Projeto

​

O projeto envolve o planejamento, cronograma e a alocação de recursos necessários para a execução dos testes. O sucesso de um processo de teste depende de uma gestão eficiente do projeto, com um planejamento bem definido e comunicação clara entre as equipes. A fase de testes deve ser integrada no ciclo de vida do desenvolvimento do software para garantir que o produto seja testado de acordo com os requisitos de tempo, custo e qualidade.

 "Agile Testing: A Practical Guide for Testers and Agile Teams" de Lisa Crispin e Janet Gregory

 

Ambiente 

​

​O ambiente de teste inclui a infraestrutura, hardware, software, dados e configurações utilizados durante o processo de teste. Garantir que o ambiente de teste seja semelhante ao ambiente de produção é fundamental para obter resultados realistas. Abaixo, referencias:

​

1-  O ambiente de teste deve ser definido pelo nível de testes a ser executado, ou seja, quanto maior o nível, mas, o ambiente de teste deverá ser capaz de reproduzir as características do ambiente de produção.

O ambiente de testes deve ser isolado, com processamento independente e características similares ao ambiente de desenvolvimento e produção e deve ser restrito à equipe de testes para garantir a integridade dos testes realizados.

​

http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx#:~:text=1.1%20Ambiente%20de%20Testes,caracter%C3%ADsticas%20do%20ambiente%20de%20produ%C3%A7%C3%A3o.&text=Logo%20adiante%20no%20item%205,de%20uma%20f%C3%A1brica%20de%20testes.

​

​

2 - Um ambiente de teste é uma configuração projetada para imitar condições do mundo real para testes de software. Ele fornece o hardware, software e configurações necessários para avaliar a funcionalidade, o desempenho e a compatibilidade do aplicativo antes da implantação.

Ambiente de controle de qualidade/teste é usado para executar testes funcionais, de regressão e de integração. Ele espelha o ambiente de produção o mais próximo possível, garantindo que todos os componentes funcionem perfeitamente juntos. O objetivo é identificar e corrigir problemas que podem afetar a funcionalidade ou experiência do usuário.

​

https://phoenixnap.pt/gloss%C3%A1rio/ambiente-de-teste#:~:text=Um%20ambiente%20de%20teste%20%C3%A9,do%20aplicativo%20antes%20da%20implanta%C3%A7%C3%A3o.

 

3 -   De acordo com (RIOS, Emerson & MOREIRA, Trayahú, 2003), ao definir  o ambiente de teste, devemos considerar:

O sistema operacional;

A arquitetura do sistema;

A identificação dos componentes;

O meio de acesso ao sistema;

A linguagem de programação utilizada;

A conectividade entre os ambientes.

 

  Segundo (RIOS, Emerson & MOREIRA, Trayahú, 2003), a criação de um ambiente de teste isolado deve contar com algumas características capazes de garantir a integridade dos testes realizados. São elas:

Ambiente isolado, com processamento independente e características similares ao ambiente de desenvolvimento e produção;

Ambiente restrito à equipe de teste;

Criação da massa de teste com dados conhecidos e representativos quantidade e qualitativamente, de modo a atender aos cenários de teste a serem executados e garantir a cobertura do código.

 

  Segundo (RIOS, Emerson & MOREIRA, Trayahú, 2003), para a criação da massa de teste podem ser empregados dados de produção, mas, para isso, dois procedimentos devem ser adotados:

   Definição algoritmos de filtragem para reduzir a massa de dados, conservando a apresentação do universo de teste;

   Mascarar os dados, garantindo a integridade da informação.

   É aconselhável que a base de teste tenha no máximo 30% do tamanho da base de produção. Para que o ambiente de teste esteja o mais próximo do ambiente real

​

​​​

Metodologias

​

Modelos de Desenvolvimento que vamos tratar por aqui: Cascata e Ágil. 

Dentro do Ágil, a grande maioria do Mercado de TI segue o Scrum — embora o movimento ágil também englobe outras vertentes como Kanban, XP (Extreme Programming), SAFe, entre outras.

 Mas aqui, o foco é na atuação do QA, e vamos comparar duas frentes que  mais usamos:

🔹 Cascata – com etapas sequenciais, onde o QA entra depois do desenvolvimento.
🔹 Scrum (Ágil) – com ciclos curtos (Sprints), entregas contínuas e QA integrado ao time desde o início.

 

 

​

​

​

​

 

 

 

 

 

 

​

Teste Manual Funcional 

​

• Finalidade: Validar se o sistema funciona conforme esperado, seguindo os requisitos funcionais. Normalmente é feito quando a automação não é viável ou ainda não está implementada.

• Como funciona: Um tester executa manualmente o processo de uso do sistema, validando se as funcionalidades estão de acordo com o esperado (exemplo: criar um usuário, buscar um produto, etc.).

• Ferramentas: Nenhuma ferramenta específica para automação, apenas o próprio sistema sendo testado.

• Particularidades:

  • Foco na funcionalidade: Testa os recursos do sistema de forma individual.

  • Intervenção humana: Exige que um tester realize as ações manualmente.

  • Ideal para testes exploratórios: Onde não há um roteiro claro ou os requisitos mudam frequentemente.

​

Teste Manual de API com o Postman

• Finalidade: Validar se os endpoints da API funcionam corretamente, retornando os dados esperados e com o comportamento certo, conforme o design da API.

• Como funciona: O tester utiliza o Postman para enviar requisições para os endpoints da API (GET, POST, PUT, DELETE) e valida as respostas (status, dados retornados, tempo de resposta, etc.).

• Ferramentas: Postman.

• Particularidades:

  • Foco em APIs: Testa especificamente o comportamento da API, verificando se a comunicação entre sistemas está funcionando como esperado.

  • Validação manual: Os testes são feitos manualmente, e a análise dos resultados é feita em tempo real no Postman.

  • Testes exploratórios: Ideal para validar diferentes cenários de resposta e falhas de comunicação entre sistemas.

 

Automação

​

"Testes automatizados não se resumem a apenas “clicar no play”. Para que sejam efetivos, exigem investimento significativo em infraestrutura, servidores robustos, capacitação técnica, ferramentas (com ou sem licenciamento), além de manutenção constante para garantir compatibilidade com os sistemas da empresa.

​

Automatizar testes exige escopo claro, estabilidade do sistema e propósito definido. Não faz sentido desenvolver scripts para cenários altamente condicionais, instáveis ou com exceções específicas — nesses casos, o esforço muitas vezes não se justifica. Além disso, testes automatizados não substituem os testes manuais, especialmente quando falamos de percepção, contexto e expectativa do cliente, algo que somente o olhar humano é capaz de avaliar.

​

A verdade é simples: um tipo de teste não anula o outro. Pelo contrário — eles se complementam. Saber quando aplicar cada abordagem é parte do papel estratégico de quem trabalha com qualidade de software." Teste de Software - Testes Manuais. Soares, Ana Paula Costa. Edição Revisada, 2025.

 

A automação de um software envolve a criação de scripts ou programas que executam tarefas de forma automatizada, muitas vezes, para melhorar a eficiência, reduzir erros humanos e economizar tempo. 

Automatizar testes antes da validação manual e de o software estar minimamente estável é um tiro no pé — tanto em custo quanto em tempo perdido. Essa abordagem ignora princípios bem estabelecidos em QA e Engenharia de Software.

​

A área de Qualidade tem Princípios consolidados que precisam ser seguidos para que obtenhamos os melhores resultados com os testes, e um deles é ter estabilidade no software antes de iniciar a automação.

 

Teste Manual Precede a Automação

​

“Automação de testes não é descoberta de bugs. Ela valida comportamentos esperados já conhecidos. Ou seja: precisa de base manual testada.” Lisa Crispin & Janet Gregory, Agile Testing

 

Agile Testing – Lisa Crispin & Janet Gregory
“Don’t automate tests until the functionality is stable.” -  Não automatize testes até que a funcionalidade esteja estável.
Fala muito sobre o valor da validação manual para entender as regras de negócio antes de investir em scripts que vão quebrar a cada mudança.

 

Continuous Delivery – Jez Humble & David Farley
Defende testes automatizados, mas só após as validações manuais e integração contínua minimamente estável.
Mostra os custos de manter automações frágeis em ambientes em mudança.

 

Testing Computer Software – Cem Kaner
Reflete sobre o erro comum de tentar automatizar antes de entender a complexidade dos fluxos. Destaca o papel exploratório do teste manual como base para scripts eficazes.
 

Exemplos de mercado

​

 Spotify

Time de QA só automatiza depois de duas iterações com testes manuais rodando de forma estável.

“Não investimos em automatizar aquilo que ainda está mudando.”

 

 ThoughtWorks

Mantém o conceito de "Script Readiness": um requisito mínimo de estabilidade funcional, documentação e criticidade antes de qualquer investimento em automação.

 

 Nubank (prática comum em fintechs)

Primeiro rodam as funcionalidades com beta testers e análise manual, depois passam para automação de regressivos (inclusive com Feature Toggles).

 

Automação testa previsibilidade, não descoberta – logo, precisa de base estável.

Automação em cima de código instável é desperdício de esforço   vira retrabalho.

Manual garante entendimento do fluxo e mapeamento de exceções – essencial antes de transformar isso em script.

É caro manter automações quebrando o tempo todo porque testamos algo que ainda muda.

 

 

https://bstqb.online/sobre

O que diz o BSTQB? 

​

O BSTQB®é o ponto de referência nacional para as certificações internacionais em Teste de Software (ISTQB®) e Engenharia de Requisitos (IREB®).

​

Conforme o  material para Certificação CTFL,  para profissionais da área de Teste, temos Benefícios e Riscos da Automação de Teste no Capítulo 6 do Syllabus:

“A simples aquisição de uma ferramenta não garante o sucesso. Cada nova ferramenta exigirá esforço para obter benefícios reais e duradouros (p. ex., para a introdução, manutenção e treinamento da ferramenta). Há também alguns riscos que precisam ser analisados e atenuados.

​

Os possíveis benefícios do uso da automação de testes incluem:

​

• Economia de tempo com a redução do trabalho manual repetitivo (p. ex., executar testes de regressão, reinserir os mesmos dados de teste, comparar os resultados esperados com os resultados reais e verificar os padrões de codificação);

• Prevenção de erros humanos simples por meio de maior consistência e repetibilidade (p. ex., os testes são consistentemente derivados dos requisitos, os dados de teste são criados de maneira sistemática e os testes são executados por uma ferramenta na mesma ordem e com a mesma frequência);

• Avaliação mais objetiva (p. ex., cobertura) e fornecimento de medidas que são muito complicadas para serem derivadas por humanos;

• Acesso mais fácil a informações sobre testes para dar suporte ao gerenciamento de testes e aos relatórios de testes (p. ex., estatísticas, gráficos e dados agregados sobre o progresso dos testes, taxas de defeitos e duração da execução dos testes);

• Redução dos tempos de execução de testes para proporcionar detecção antecipada de defeitos, feedback mais rápido e menor tempo de lançamento no mercado;

• Mais tempo para os Testadores criarem testes novos, mais profundos e mais eficazes.

 

Os possíveis riscos do uso da automação de testes incluem:

​

• Expectativas irreais sobre os benefícios de uma ferramenta (incluindo funcionalidade e facilidade de uso); 

• Estimativas imprecisas de tempo, custos e esforço necessários para introduzir uma ferramenta, manter scripts de teste e alterar o processo de teste manual existente;

• Usar uma ferramenta de teste quando o teste manual é mais apropriado;

• Confiar demais em uma ferramenta, por exemplo, ignorando a necessidade do pensamento crítico humano;

• A dependência do fornecedor da ferramenta, que pode fechar as portas, aposentar a ferramenta, vender a ferramenta para outro fornecedor ou fornecer um suporte deficiente (p. ex., respostas a consultas, atualizações e correções de defeitos);

• Usar um software de código aberto que pode ser abandonado, o que significa que não há mais atualizações disponíveis, ou que seus componentes internos podem exigir atualizações bastante frequentes como um desenvolvimento adicional;

• A ferramenta de automação não é compatível com a plataforma de desenvolvimento;

• Escolha de uma ferramenta inadequada que não cumpra os requisitos normativos e/ou as normas de segurança. ”

 

 https://bstqb.online/files/syllabus_ctfl_4.0br.pdf

 

Tipos de Testes Automatizados

​

 Teste Automatizado Web - Regressivo

​

• Finalidade: Verificar se as novas alterações no sistema não afetaram funcionalidades existentes (aquelas que já estavam funcionando corretamente). É uma maneira de validar que mudanças não introduziram bugs.

• Como funciona: O teste simula o comportamento do usuário real, realizando ações típicas de navegação na aplicação (como clicar, preencher formulários, navegar entre páginas, etc.), mas de forma automatizada.

• Exemplos de Ferramentas Free e seus conceitos: Selenium, Cypress, TestCafe, Playwright.

  • Selenium – Versátil e compatível com múltiplas linguagens, ideal para cenários mais complexos e integração com diferentes frameworks.

  • Cypress – Focado em aplicações modernas (JavaScript), com execução rápida e fácil depuração.

  • TestCafe – Simples de configurar e executar, com bom suporte a testes paralelos e ambientes CI/CD.

  • Playwright – Suporta múltiplos navegadores e linguagens, ideal para testes cross-browser robustos e modernos.

• Particularidades:

  • Enfoque na experiência do usuário: O objetivo é replicar o uso real da aplicação de forma automatizada, sem envolver simulações de carga ou estresse.

  • Foco em regressão: Garante que os recursos já existentes não sejam comprometidos após novas atualizações.​

​

Teste de Carga (que abrange Performance e Stress)

​

• Finalidade:

  • Teste de Carga: Verificar se o sistema consegue lidar com uma quantidade esperada de usuários ou transações de maneira estável.

  • Teste de Performance: Medir o tempo de resposta do sistema sob condições normais de operação.

  • Teste de Stress: Testar os limites do sistema, expondo-o a condições extremas para identificar pontos de falha e entender o comportamento do sistema quando ele é sobrecarregado.

 

Como funciona:

• Teste de Carga: Simula múltiplos usuários acessando o sistema simultaneamente, verificando o desempenho sob cargas conhecidas (quantidade de acessos ou transações esperadas).

• Teste de Stress: Testa o sistema até o ponto de falha, aumentando gradualmente a carga até que o sistema não consiga mais suportar o tráfego.

• Teste de Performance: Avalia a resposta do sistema sob uma carga controlada, considerando tempo de resposta e a capacidade de suportar múltiplas requisições.

• Ferramentas: JMeter, K6, LoadRunner, Gatling.

• Particularidades:

  • Teste de Carga: Foca em avaliar a capacidade do sistema em condições normais.

  • Teste de Stress: Foca em verificar a resistência do sistema sob condições extremas.

  • Teste de Performance: Avalia qualidade do desempenho, como o tempo de resposta e o comportamento sob carga.

 

Esses dois tipos de teste têm finalidades diferentes, mas ambos são essenciais para garantir a estabilidade e o desempenho de um sistema, cada um em seu contexto de uso.

 

O que deve ser automatizado - O que levamos em consideração para elencar um software para ser automatizado?

​

Para que um software seja elencado para automação de testes, diversos aspectos precisam ser observados. Isso garante que o esforço de automação seja eficaz e traga benefícios para o processo de qualidade. 

 

Abaixo uma forma didática de descrição do que é, o motivo e onde a informação sobre a Disciplina de Teste está referenciada:

​

1. Estabilidade do Sistema

​

• Descrição: A automação é mais eficaz em sistemas estáveis. Testes automatizados devem ser usados em cenários onde os fluxos de trabalho, funcionalidades e interface de usuário são relativamente constantes.

• Por quê?: A automação em sistemas com constantes mudanças pode resultar em manutenção constante dos scripts, o que gera custo e pouco retorno.

 "The Art of Software Testing" de Glenford J. Myers – Myers recomenda que a automação seja aplicada a sistemas estáveis para evitar retrabalho constante.

​

2. Testes “Repetíveis”

​

• Descrição: A automação é ideal para testes que precisam ser repetidos várias vezes ao longo do ciclo de desenvolvimento.

• Por quê?: A automação economiza tempo e esforço em testes repetitivos, como testes de regressão, testes de carga e performance.

 "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" de Jez Humble e David Farley – O livro discute a importância de automação de testes em processos contínuos, como testes de regressão e validação contínua.

​

3. Complexidade do Sistema

​

Descrição: Sistemas com grande complexidade, como aqueles com várias interações e camadas de integração (por exemplo, APIs, banco de dados, interfaces de usuário), geralmente se beneficiam da automação.

Por quê?:  A automação ajuda a cobrir mais cenários sem aumento significativo no esforço.

"Test Automation in the Real World" de David Burns – O autor fala sobre como a automação pode melhorar a cobertura de testes em sistemas complexos e reduzir o risco de falhas.

 

Para que a automação de testes tenha sucesso é necessário ter infraestruturas e práticas essenciais. Caso contrário, a automação pode falhar em entregar os resultados esperados. 

​

   Ambiente de Teste Dedicado

​

  Acesso Completo ao Sistema

Por quê?: Para automatizar testes de forma eficaz, é necessário que a equipe de QA e os profissionais de automação tenham acesso total ao sistema, incluindo bancos de dados, APIs, logs de servidor e demais componentes do sistema. Isso permite que eles possam validar todos os cenários, desde a interação do usuário até os dados persistidos. "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" de Jez Humble e David Farley – Os autores explicam a importância do acesso total e das integrações no ciclo de vida de testes, para garantir que os testes cubram todas as camadas do sistema

 

Integração com APIs e Banco de Dados

Por quê?: Sistemas complexos frequentemente envolvem várias interações entre APIs, banco de dados, e interfaces de usuário. A automação de testes deve cobrir todos esses aspectos para garantir que as integrações funcionem corretamente. "The Art of Software Testing" de Glenford J. Myers – Myers defende que, para testes automatizados eficazes, é essencial a possibilidade de validar as interações entre as diversas camadas do sistema, como APIs e banco de dados

 

Cultura de Colaboração entre Times

Por quê?: A automação de testes em sistemas complexos exige a colaboração de várias equipes (Desenvolvimento, Infraestrutura, QA, etc.), pois cada uma delas pode ter responsabilidades diferentes e insights importantes sobre como o sistema funciona. "Agile Testing: A Practical Guide for Testers and Agile Teams" de Lisa Crispin e Janet Gregory – O livro sugere que a colaboração entre equipes é fundamental para o sucesso da automação, especialmente em ambientes ágeis, onde as mudanças são constantes.

 

Ferramentas de Automação Adequadas e Escaláveis

Por quê?: Ferramentas de automação que não sejam adequadas ao sistema em questão podem gerar dificuldades de manutenção, como scripts frágeis ou complexidade excessiva. "Test Automation in the Real World" de David Burns – O autor fala sobre como a escolha das ferramentas corretas é crucial para o sucesso da automação, especialmente em sistemas complexos, onde as integrações são fundamentais.

 

4. Alta Frequência de Mudanças no Código

​

• Descrição: Em ambientes ágeis, onde o código é alterado com frequência, a automação de testes pode garantir que novas alterações não quebrem funcionalidades existentes.

• Por quê?: Testes automatizados são fundamentais para validar rapidamente alterações e garantir que o sistema continue funcionando conforme o esperado após modificações.

 "Agile Testing: A Practical Guide for Testers and Agile Teams" de Lisa Crispin e Janet Gregory – O livro explora a importância da automação de testes em ambientes ágeis, onde o código está em constante evolução.

​

5. Existência de Testes Repetitivos e de Longo Prazo - se não, para que automatizar?

​

• Descrição: Testes que precisam ser executados frequentemente, como testes de regressão ou de performance, são bons candidatos à automação.

• Por quê?: A automação reduz o esforço manual e o tempo gasto para realizar esses testes repetitivos.

"Software Testing: A Craftsman's Approach" de Paul C. Jorgensen – Jorgensen defende que testes repetitivos são candidatos ideais para automação, já que a manutenção de scripts para testes regressivos é eficiente.

​

6. Relevância do Escopo de Teste

​

• Descrição: Testes que cobrem funcionalidades críticas ou de alto risco devem ser automatizados para garantir que estão sendo validados consistentemente.

• Por quê?: Funcionalidades essenciais devem ser sempre verificadas, e a automação ajuda a garantir que esses testes sejam executados de forma consistente.

"The Testing Practitioner’s Handbook" de Andrew L. Kline – Este livro discute como selecionar e priorizar testes para automação, com ênfase nas funcionalidades críticas.

​​

​

7. Custo de Manutenção e Recursos

​

• Descrição: A decisão de automatizar depende da relação custo-benefício. Testes simples e de baixo custo são mais adequados para serem feitos manualmente.

• Por quê?: Se a manutenção dos testes automatizados for mais cara que a realização dos testes manuais, a automação pode não ser viável.

 "Test Automation: A Manager's Guide" de Mark Fewster e Dorothy Graham – O livro explora os custos e benefícios da automação de testes, ajudando a avaliar quando automatizar testes de forma eficaz.

​

8. Integração Contínua e Entrega Contínua

​

• Descrição: A automação de testes é essencial para ambientes de Integração Contínua (CI) e Entrega Contínua (CD), onde testes precisam ser executados a cada commit ou entrega.

• Por quê?: Em CI/CD, testes manuais não são viáveis - imagina os QAs atuando antes de cada GMUD????? - devido à frequência de integrações. A automação garante a execução de testes de forma rápida e consistente.

 "DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations" de Gene Kim, Patrick Debois, John Willis e Jez Humble – O livro detalha a integração de testes automatizados no ciclo de vida DevOps, reforçando a importância da automação.

 

Papéis e responsabilidades:

​

•DEV: Ajusta código para otimização. Avalia os erros encontrados após o Teste. Corrige erros encontrados pelos testes.

•Infra: Avalia impacto na infraestrutura.

•Negócio: Define requisitos e impactos esperados.

 

Papel do QA Automatizador em Testes de Performance

​

O QA automatizador é responsável por transformar requisitos de desempenho em testes automatizados, garantindo que a aplicação suporte cargas esperadas.

 

Principais Responsabilidades:

•Criação de Scripts no K6:

•Escreve e parametriza scripts em JavaScript para o K6.

•Implementa autenticação, headers dinâmicos e correlação de tokens.

•Define thresholds (limites de desempenho aceitáveis).

•Correlação de APIs:

•Captura e reutiliza dados entre requisições (ex: session ID, tokens).

•Garante que a comunicação entre endpoints reflita cenários reais. [desafios**]

•Configuração de Cenários de Teste:

•Define ramp-up e ramp-down de usuários virtuais.

•Inclusão dos Testes na Esteira CI/CD:

•Integra testes no pipeline usando GitHub Actions.

•Configura alertas automáticos em caso de falhas de performance.

•Armazena logs e métricas para análise contínua - Banco de Dados.

•Análise de Resultados e Otimização:

•Gera relatórios de performance para times de DEV, Infra e Negócio.

 

 

Tempo mínimo de planejamento e desafios -  Quando pedir o Teste de Carga? 

​

​​•Mínimo: 2 a 4 dias para entender API e configurar K6.

Este período contempla atividades como compreender a API, configurar o ambiente de testes e ajustar os scripts conforme as necessidades específicas do projeto. A quantidade de APIs que podem ser compreendidas e configuradas no K6 em um período de 2 a 4 dias depende de diversos fatores, como a complexidade de cada API, a experiência da equipe e a qualidade da documentação disponível. Não há uma métrica de mercado específica que determine esse número. No entanto, com base em práticas comuns, é razoável estimar que uma equipe experiente possa configurar testes de performance para 1 a 3 APIs simples ou moderadamente complexas nesse intervalo de tempo.  Para APIs mais complexas ou com documentação limitada, o tempo necessário pode ser maior. É fundamental avaliar cada caso individualmente e ajustar o planejamento conforme as especificidades do projeto.

 

•Desafios: Autenticação, headers dinâmicos, correlação de tokens, tempo de resposta instável.

 

Quais dados podemos coletar?

 

WEB:

Taxa de Sucesso/Falha dos Testes Automatizados → % de testes que passaram x falharam.
Tempo Médio de Execução dos Testes → Mede a eficiência da suíte de testes (se estiver aumentando, pode indicar um problema).
Número de Bugs Encontrados por Teste Automatizado → Mede a efetividade dos testes em capturar falhas.
Reexecução de Testes → Quantidade de vezes que um teste precisa ser reexecutado para passar (pode indicar instabilidade).

 

Performance:

Tempo de Resposta sob Carga - Mede o tempo médio para processar requisições sob diferentes cargas.

Throughput (Requisições por Segundo - RPS) - Número de requisições processadas por segundo em diferentes cenários de carga.

Taxa de Erros Sob Carga - Percentual de falhas quando o sistema é submetido a alta carga.

​

​

Testes Web, API e Performance.:  Report - Automação de Teste

 

Eclipse | IDE (ambiente de desenvolvimento) usada para escrever, editar e rodar os testes automatizados. Os testes de Web e API em Java, estruturados com Cucumber, são criados e organizados dentro do Eclipse. Facilita o versionamento e integração com Maven e Git. 

 

Cucumber (para testes Web) | Utilizado para automação de testes funcionais em aplicações Web com foco em BDD (Behavior Driven Development). Os scripts são escritos em linguagem natural (Gherkin) e rodam integrados com Selenium ou outras bibliotecas. O automatizador usa o Eclipse para codar os steps e rodar os testes. Exemplo: verificar login, formulário, botões etc. 

 

Cucumber (para testes de API funcional) | Mesma estrutura que o teste Web, mas em vez de interagir com browser, interage com APIs (REST, SOAP). O script é feito em Gherkin no Eclipse, e os steps Java usam bibliotecas como RestAssured para fazer requisições e validar respostas (status, JSON, etc). Automatiza fluxos como cadastro, autenticação, envio de dados via API. 

 

K6 (para testes de performance) | Ferramenta de código aberto para testes de carga e stress em APIs e sistemas. Os testes são escritos em JavaScript, o que torna fácil para devs automatizadores. Roda via CLI e também pode ser integrado no GitHub Actions. No CI, o K6 executa os testes com métricas como tempo de resposta, throughput, falhas etc. Exemplo de comando: k6 run teste-performance.js ou k6 cloud para testes na nuvem. 

​

💡 Resumo Integrado – Como tudo se conecta

​

No Eclipse o automatizador desenvolve os testes em Java. Para testes Web, usa Cucumber + Selenium. Para APIs, Cucumber + RestAssured. O Maven organiza tudo e executa.
Os testes rodam localmente ou na esteira via GitHub Actions, com os emuladores, containers e tudo isoladinho via Docker.
Para performance, o time escreve scripts em JavaScript com K6 e integra no pipeline pra validar a estabilidade e escalabilidade do sistema/API. 

 

​

MOBILE:

​

Java - Linguagem de programação base para escrever os testes automatizados. Usada em conjunto com outras ferramentas como Appium, JUnit e Cucumber.

​

Cucumber - Framework de BDD (Behavior Driven Development). Permite escrever os testes em linguagem natural (Gherkin), facilitando o entendimento entre áreas técnicas e de negócio. Ex: Dado que o usuário acessa o app...

​

JUnit - Framework de testes unitários e de integração em Java. É usado para estruturar e executar os testes automatizados (inclusive os de interface com Appium).

​

GitHub Actions - Ferramenta de CI/CD usada para executar automaticamente os testes mobile na esteira a cada commit ou PR. Integra com emuladores e containers para rodar os testes.

​

Android Studio (emulador local) - Usado como emulador local para rodar os testes mobile manualmente ou testar scripts de automação. Ideal para desenvolvimento e debug.

​

Genymotion (emulador na esteira) - 

Emulador Android usado em pipelines CI/CD, mais leve e estável que o Android Studio para execuções em nuvem ou containers. Ideal para rodar testes automatizados na esteira.

​

Docker - Cria ambientes isolados e padronizados para rodar os testes. Permite simular o ambiente de produção/desenvolvimento localmente e na CI. Usado para levantar containers com Appium, Genymotion, etc.

​

Appium - Framework de automação para testes mobile (Android e iOS). Permite escrever scripts em Java que interagem com o app como se fossem usuários reais. Pode ser usado com dispositivos reais, emuladores ou em containers.

​

Maven -  Gerenciador de dependências e build para projetos Java. Usa-se para compilar os testes, baixar libs (Appium, Cucumber, JUnit) e rodar testes com comandos padronizados (mvn test).

​

​

💡 Resumo Integrado – Como tudo se conecta

 

 

Você escreve seus testes em Java, estruturando com JUnit e descrevendo cenários com Cucumber. O Appium executa esses testes no app, que está rodando em um emulador Android (local via Android Studio ou na esteira via Genymotion). O Maven cuida do build e da execução, e o GitHub Actions automatiza tudo isso nas pipelines. O Docker garante que o ambiente seja sempre igual, em qualquer máquina.

 

Importância - Quality Assurance

 

Análise de documentações - O QA contribui na análise crítica das documentações, apontando possíveis inconsistências, evitando assim retrabalho em fase de desenvolvimento.

 

Certificação - Realiza a verificação das funcionalidades previstas em documentação, bem como os cenários de testes de negócio elencados pela Unidade, com o objetivo de encontrar defeitos e evitá-los em ambiente de produção.

 

 

Indicadores de qualidade das entregas - Levantamento e apresentação de reports diários, semanais e mensais, que contém  indicadores que contribuem para as tomadas de decisões do projeto.

 

Processos - O QA auxilia na identificação de falhas e melhorias nos processos, otimizando-os e contribuindo para eficiência na entrega final do projeto.

 

Documentações de entendimento - Elaboração de documentos de entendimento do projeto a fim de manter vivo o conhecimento do negócio obtido na atuação.

 

 

Impactos de NÃO TER O COLABORADOR DE QUALIDADE

 

A presença de um Quality Assurance (QA) nos projetos de desenvolvimento de software é crucial para garantir a qualidade e o sucesso do produto final

 

Diminuição da Qualidade do Produto
Sem o colaborador de qualidade, os produtos finais podem ter mais falhas, erros não detectados e não atender aos requisitos do cliente, prejudicando a confiança no produto.
"The Art of Software Testing" de Glenford J. Myers

​

Aumento nos Custos de Correção de Defeitos
A falta de um colaborador de qualidade pode resultar na detecção tardia de erros, aumentando significativamente os custos de manutenção, já que os problemas só serão identificados após o lançamento do produto.
"Software Engineering: A Practitioner's Approach" de Roger S. Pressman

​

Baixa Satisfação do Cliente
Se a qualidade do produto não for controlada adequadamente, os usuários finais podem ter uma experiência ruim, resultando em insatisfação e até perda de clientes.
"Agile Testing: A Practical Guide for Testers and Agile Teams" de Lisa Crispin e Janet Gregory

 

Baixa Eficiência no Desenvolvimento
A ausência de um colaborador de qualidade para testar e validar o software pode levar a erros no código e à necessidade de retrabalho, atrasando o cronograma do projeto.
"Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" de Jez Humble e David Farley

 

Risco de Instabilidade no Sistema
Sem um colaborador de qualidade realizando testes rigorosos, o sistema pode apresentar falhas durante a utilização real, impactando negativamente a estabilidade e confiabilidade do produto.
"The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win" de Gene Kim, Kevin Behr e George Spafford

Problemas de Integração e Interoperabilidade
 

A falta de um colaborador de qualidade pode resultar em falhas de integração entre as diversas partes do sistema, como APIs e bancos de dados, causando falhas no funcionamento geral do software.
"Test Automation in the Real World" de David Burns

 

Maior Risco de Falhas em Produção
Sem o colaborador de qualidade, o produto pode ser liberado para produção sem a devida validação, aumentando o risco de falhas catastróficas que impactam diretamente os usuários finais.
"Test-Driven Development: By Example" de Kent Beck

 

Falta de Documentação e Histórico de Testes
Sem o colaborador de qualidade, a documentação dos testes realizados e os resultados encontrados ficam comprometidos, dificultando a rastreabilidade e análise futura do projeto.
Referência: "Software Testing: A Craftsman's Approach" de Paul C. Jorgensen

 

Dificuldade na Manutenção e Evolução do Software
A ausência de controle de qualidade pode resultar em uma base de código desorganizada, dificultando a manutenção e evolução do sistema ao longo do tempo.
"Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing" de William E. Lewis

 

Impedimento na Adoção de Metodologias Ágeis
A falta de um colaborador de qualidade pode prejudicar a implementação de metodologias ágeis, já que testes contínuos são fundamentais para garantir entregas incrementais e eficazes.
"Agile Testing: A Practical Guide for Testers and Agile Teams" de Lisa Crispin e Janet Gregory

​​​​​​