Pular para conteúdo

Qualidade e Testes de Software 🧪

Bem-vindo ao curso de Qualidade e Testes de Software. Aqui você aprenderá a garantir a excelência técnica de seus produtos através de processos rigorosos de validação e verificação.

Foco do Curso

Metodologia: Aprendizado prático baseado em TDD, automação e modelos de qualidade de mercado (CMMI/MPS.br).

🎯 O Que Você Vai Aprender

  • Garantia de Qualidade --- Entenda a diferença entre erro, defeito e falha, e como o papel do QA agrega valor ao negócio. Ver Fundamentos

  • Técnicas de Teste --- Domine testes de Caixa Preta e Caixa Branca, análise de valores limite e partição de equivalência. Ver Técnicas

  • Automação --- Aprenda a criar scripts robustos de automação web com Selenium/Playwright e testes de API com Postman. Ver Automação

  • TDD e CI/CD --- Implemente o ciclo Red-Green-Refactor e integre seus testes em pipelines automatizados no GitHub. Ver Prática

📚 Jornada de Aprendizado (16 Aulas)

O curso é estruturado para levar você do zero à automação profissional.

🏛️ Módulo 1: Fundamentos (Aulas 01-04)

🏗️ Módulo 2: Boas Práticas e Técnicas (Aulas 05-08)

🧪 Módulo 3: Tipos de Teste e TDD (Aulas 09-12)

🚀 Módulo 4: Automação e Gestão (Aulas 13-16)

Começar Minha Jornada em QA

Plano de Ensino 🧭

Curso: Qualidade e Testes de Software
Público-alvo: Estudantes de ADS, Ciência da Computação e Desenvolvedores de Software
Carga Horária: 20 Aulas (80 Horas Teórico-Práticas)

🎯 1. Objetivos do Curso

  • Compreender os fundamentos conceituais e arquiteturais de Qualidade e Testes de Software.
  • Aplicar padrões de projeto, sintaxe moderna e boas práticas da indústria.
  • Desenvolver soluções completas através de exercícios práticos e desafios de projeto.

📚 2. Cronograma de Aulas (Matriz de 20 Semanas)

Aula Tema Central Atividades e Entregas
01 Qualidade de Software e Papel do QA Teoria, Prática Guiada, Quiz e Exercícios
02 Modelos de Qualidade de Software Teoria, Prática Guiada, Quiz e Exercícios
03 Ciclo de Vida de Testes (STLC) Teoria, Prática Guiada, Quiz e Exercícios
04 Documentação e Controle de Testes Teoria, Prática Guiada, Quiz e Exercícios
05 Melhores Práticas de Programação Teoria, Prática Guiada, Quiz e Exercícios
06 Controle de Versão e CI Teoria, Prática Guiada, Quiz e Exercícios
07 Técnicas de Teste: Caixa Preta Teoria, Prática Guiada, Quiz e Exercícios
08 Técnicas de Teste: Caixa Branca Teoria, Prática Guiada, Quiz e Exercícios
09 Tipos de Testes Funcionais Teoria, Prática Guiada, Quiz e Exercícios
10 Testes Não Funcionais e Usabilidade Teoria, Prática Guiada, Quiz e Exercícios
11 Desenvolvimento Orientado por Testes (TDD) Teoria, Prática Guiada, Quiz e Exercícios
12 Testes Unitários e de Integração Teoria, Prática Guiada, Quiz e Exercícios
13 Automação de Testes Web Teoria, Prática Guiada, Quiz e Exercícios
14 Testes de API Teoria, Prática Guiada, Quiz e Exercícios
15 Gestão de Defeitos e Ferramentas Teoria, Prática Guiada, Quiz e Exercícios
16 Projeto Integrador Final Teoria, Prática Guiada, Quiz e Exercícios
17 Testes de Carga, Estresse e Performance Teoria, Prática Guiada, Quiz e Exercícios
18 Testes de Contrato de APIs e Schema-First Teoria, Prática Guiada, Quiz e Exercícios
19 Testes de Regressão Visual e Automação E2E Teoria, Prática Guiada, Quiz e Exercícios
20 Projeto Capstone: Suíte Autônoma de Qualidade de Software Teoria, Prática Guiada, Quiz e Exercícios

🧠 3. Metodologia de Ensino

  • Teoria Fundamentada: Aulas com conceitos detalhados, diagramas arquiteturais e sintaxe de referência.
  • Ciclo Teoria ⇄ Prática: Cada aula conta com Quiz Interativo (10 questões) para validação imediata, Lista de Exercícios Sanfonados (com Gabarito Explicado) e Desafio de Projeto Prático.
  • Laboratório Contínuo: Ambientes configurados passo a passo na seção de Setups da plataforma.

💼 4. Competências e Perfil Desenvolvido

  • Dominar as ferramentas e fluxos de desenvolvimento de Qualidade e Testes de Software.
  • Resolver problemas técnicos de alta complexidade com código limpo e performático.
  • Construir portfólio prático com 20 projetos aplicados.

📊 5. Critérios de Avaliação

  • 20 Listas de Exercícios: Resolução individual dividida em Básico, Intermediário e Desafio.
  • 20 Quizzes Interativos: Validação formativa com feedback imediato via JavaScript.
  • 20 Desafios de Projetos: Aplicações práticas consolidando o aprendizado de cada unidade.

Aulas

Aulas do Curso

Bem-vindo à seção de aulas! Aqui você encontra todo o conteúdo do curso organizado em 5 módulos estruturados.

📚 Módulos do Curso

Aula 01 - Qualidade de Software e Papel do QA 🧐

🧠 Conceitos de Qualidade

A qualidade de software não é apenas a ausência de bugs, mas a conformidade com os requisitos e a satisfação do usuário final. De acordo com a ISO/IEC 25010, a qualidade é dividida em características como adequação funcional, eficiência de desempenho, usabilidade, entre outras.

Note

Conceito: Qualidade é o grau no qual um conjunto de características inerentes satisfaz a requisitos.

⚠️ Erro, Defeito e Falha

É fundamental entender a cadeia de causalidade em QA:

  1. Erro: Uma ação humana que produz um resultado incorreto (ex: erro de lógica durante a codificação).
  2. Defeito (Bug): A manifestação do erro no artefato (código, documento).
  3. Falha: O desvio do comportamento esperado durante a execução (o sistema "quebra" ou retorna valor errado).

Fluxo de Causalidade

graph LR
    A[Ação Humana] -- Erro --> B[Código/Documento]
    B -- Contém --> C[Defeito]
    C -- Execução --> D[Falha]
    D -- Impacto --> E[Usuário]

🔍 Verificação x Validação

  • Verificação: "Estamos construindo o produto corretamente?" (Foco no processo: revisões, inspeções, análise estática).
  • Validação: "Estamos construindo o produto correto?" (Foco no produto: testes de execução contra requisitos do usuário).

💻 Visão Geral dos Testes

Vamos ver como um QA interage com o terminal para realizar uma verificação básica de ambiente.

npm --version 10.2.4 git status No branch main. Your branch is up to date. python --version Python 3.11.5

📝 Exercício de Fixação

  1. Explique com suas palavras a diferença entre um Erro e uma Falha.
  2. Dê um exemplo de uma atividade de Verificação que não envolva a execução do código.

🚀 Mini-Projeto

Objetivo: Identificar falhas em um site simples. - Escolha um site de livre acesso. - Tente realizar 3 fluxos diferentes (ex: busca, login, adicionar ao carrinho). - Documente se houve alguma Falha ou se o comportamento foi o esperado (Sucesso).

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 01

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 01

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 01

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 01

➡️ Próxima Aula: Aula 02

Aula 02 - Modelos de Qualidade de Software 📊

🏛️ Modelos de Referência

Para garantir que uma empresa produz software com qualidade, existem modelos que avaliam a maturidade dos processos. Os dois principais no Brasil são o CMMI e o MPS.br.

CMMI (Capability Maturity Model Integration)

O CMMI é um modelo global que foca na melhoria de processos em organizações de diferentes tamanhos. Ele possui 5 níveis de maturidade:

  1. Inicial: Processos imprevisíveis e reativos.
  2. Gerenciado: Processos caracterizados para projetos (foco em gestão).
  3. Definido: Processos padrões para toda a organização.
  4. Gerenciado Quantitativamente: Processos medidos e controlados.
  5. Em Otimização: Foco na melhoria contínua dos processos.

🇧🇷 MPS.br (Melhoria de Processo do Software Brasileiro)

Criado pela SOFTEX, o MPS.br é um modelo mais acessível para pequenas e médias empresas brasileiras. Ele possui 7 níveis de maturidade (de G até A):

graph TD
    G[Nível G: Parcialmente Gerenciado] --> F[Nível F: Gerenciado]
    F --> E[Nível E: Parcialmente Definido]
    E --> D[Nível D: Definido]
    D --> C[Nível C: Definido e Gerenciado]
    C --> B[Nível B: Gerenciado Quantitativamente]
    B --> A[Nível A: Em Otimização]

📈 Métricas de Defeitos

Qualidade sem medição é apenas opinião. Algumas métricas essenciais:

  • Densidade de Defeitos: Número de defeitos / Tamanho do software (ex: KLOC).
  • Eficiência de Remoção de Defeitos (DRE): Quantos defeitos foram encontrados antes do lançamento vs. após.

💻 Verificando Status de Maturity no Projeto

git log --oneline | wc -l 152 (Número de commits para rastreabilidade) pytest --version pytest 7.4.0

📝 Exercício de Fixação

  1. Qual o nível de maturidade do CMMI onde os processos passam a ser medidos quantitativamente?
  2. Por que o MPS.br é considerado mais adequado para PMEs brasileiras em comparação ao CMMI?

🚀 Mini-Projeto

Objetivo: Analisar um processo fictício. - Imagine uma empresa que não documenta nada e os prazos nunca são cumpridos. - Em qual nível do CMMI ela estaria? - Liste 3 ações imediatas para levá-la ao Nível 2.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 02

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 02

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 02

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 02

➡️ Próxima Aula: Aula 03

Aula 03 - Ciclo de Vida de Testes (STLC) 🔄

⚙️ O que é STLC?

O STLC (Software Testing Life Cycle) é uma sequência de atividades específicas realizadas durante o processo de teste para garantir que os objetivos de qualidade do software sejam atendidos.

Diferente do SDLC (Desenvolvimento), o STLC foca exclusivamente nas fases de teste.

🗺️ Fases do STLC

graph TD
    A[Análise de Requisitos] --> B[Planejamento de Testes]
    B --> C[Desenvolvimento de Casos de Teste]
    C --> D[Configuração do Ambiente]
    D --> E[Execução de Testes]
    E --> F[Encerramento de Testes]

Detalhamento das Fases:

  1. Análise de Requisitos: O que será testado? (Funcionalidades, performance).
  2. Planejamento: Estimativa de tempo, recursos e ferramentas.
  3. Casos de Teste: Criação dos passos e dados de entrada.
  4. Ambiente: Setup do hardware/software (QA environment).
  5. Execução: Rodar os testes e reportar bugs.
  6. Encerramento: Relatório final e lições aprendidas.

⚖️ STLC vs SDLC

Fase SDLC Fase STLC Correspondente
Requisitos Análise de Requisitos de Teste
Design Planejamento e Design de Testes
Codificação Desenvolvimento de Casos de Teste
Testes Execução e Report
Manutenção Testes de Regressão

💻 Simulação de Configuração de Ambiente

mkdir test-environment cd test-environment docker pull qa-image:latest Ambiente QA pronto para execução.

📝 Exercício de Fixação

  1. Em qual fase do STLC são definidos os Critérios de Aceite?
  2. Por que é importante configurar o ambiente de teste de forma isolada do ambiente de desenvolvimento?

🚀 Mini-Projeto

Objetivo: Mapear as fases de um teste simples. - Cenário: Testar o botão "Esqueci minha senha" de um sistema. - Descreva o que você faria em cada uma das 6 fases do STLC para esse cenário.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 03

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 03

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 03

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 03

➡️ Próxima Aula: Aula 04

Aula 04 - Documentação e Controle de Testes 📄

📑 A Importância da Documentação

Testar sem documentar é apenas "brincar" com o software. A documentação garante a rastreabilidade, repetibilidade e serve como evidência para auditorias.

Important

Se não foi documentado, o teste não foi feito!

🛠️ Principais Artefatos

1. Plano de Testes

Documento de alto nível que descreve a estratégia, o escopo, os recursos e o cronograma das atividades de teste.

2. Caso de Teste (Test Case)

Um conjunto de condições ou variáveis sob as quais um testador determinará se um sistema funciona corretamente.

Exemplo de Caso de Teste: | ID | Descrição | Pré-condição | Passos | Resultado Esperado | | :--- | :--- | :--- | :--- | :--- | | CT-01 | Login com Sucesso | Usuário cadastrado | 1. Inserir email correto
2. Inserir senha correta
3. Clicar em Entrar | Redirecionamento para a Home |

3. Relatório de Bugs (Bug Report)

Documento que detalha um defeito encontrado. Deve conter: - Título claro - Passos para reproduzir - Resultado atual vs. Resultado esperado - Severidade e Prioridade

📊 Indicadores (Métricas)

pie title Taxa de Defeitos por Status
    "Corrigidos" : 45
    "Em Aberto" : 25
    "Em Re-teste" : 15
    "Rejeitados" : 15

💻 Verificando Cobertura de Logs

cat logs/test-execution.log | grep "FAILED" ERROR: CT-05 Falhou - Timeout ao carregar checkout ls docs/test-cases/*.xlsx casos_de_teste_v1.xlsx

📝 Exercício de Fixação

  1. Qual a diferença entre um Cenário de Teste e um Caso de Teste?
  2. Imagine que você encontrou um erro ortográfico em um botão. Qual seria a Severidade e a Prioridade desse bug?

🚀 Mini-Projeto

Objetivo: Escrever seu primeiro relatório de bug. - Acesse um aplicativo qualquer. - Identifique um comportamento estranho ou um erro real. - Escreva um Bug Report completo seguindo a estrutura vista em aula.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 04

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 04

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 04

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 04

➡️ Próxima Aula: Aula 05

Aula 05 - Melhores Práticas de Programação ✨

🧹 Introdução ao Clean Code

Escrever código que funciona é fácil; difícil é escrever código que outros (e você mesmo no futuro) consigam entender e testar. O Clean Code (Código Limpo) é a base de um software com alta qualidade.

Tip

Código limpo deve ser lido como uma prosa bem escrita.

🏗️ Princípios para Testabilidade

Para que um software seja facilmente testado, ele deve seguir alguns princípios:

  1. Nomes Significativos: Variáveis e funções devem dizer a que vieram.
    • ❌ v = 10
    • ✅ max_retry_attempts = 10
  2. Funções Pequenas: Uma função deve fazer apenas uma coisa.
  3. DRY (Don't Repeat Yourself): Evite duplicidade de código para não ter que atualizar testes em múltiplos lugares.
  4. KISS (Keep It Simple, Stupid): Evite complexidade desnecessária.

🛠️ Refatoração

Refatorar é o processo de melhorar a estrutura interna do código sem alterar seu comportamento externo. No contexto de QA, refatoramos para: - Remover código "cheiroso" (Code Smells). - Facilitar a criação de testes unitários.

graph LR
    A[Código Sujo/Legado] --> B{Possui Testes?}
    B -- Não --> C[Criar Testes de Proteção]
    B -- Sim --> D[Refatorar Pequenos Pedaços]
    C --> D
    D --> E[Código Limpo e Testável]

💻 Refatoração na Prática (Terminal)

git diff main -- stat utils.py | 45 +++--- pytest utils.py 15 passed in 0.05s (Refatoração validada!)

📝 Exercício de Fixação

  1. O que é um Code Smell? Cite um exemplo comum.
  2. Por que a regra do "Escoteiro" (Deixe o código sempre um pouco mais limpo do que você o encontrou) é importante para a qualidade?

🚀 Mini-Projeto

Objetivo: Identificar e limpar um trecho de código. - Abaixo está um código "sujo": 

def p(a, b):
    x = 0
    for i in range(len(a)):
        x += a[i] * b
    return x
- Tarefa: Reescreva este código seguindo os princípios de Nomes Significativos e Simplicidade.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 05

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 05

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 05

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 05

➡️ Próxima Aula: Aula 06

Aula 06 - Controle de Versão e CI 🐙

🌿 Versionamento com Git

O controle de versão é o alicerce de qualquer projeto de software moderno. Para o QA, entender Git é essencial para: - Testar branches específicas antes do merge. - Rastrear em qual commit um bug foi introduzido (git bisect). - Garantir que a versão testada é a mesma que irá para produção.

Fluxo Básico de Branches

gitGraph
    commit
    branch develop
    checkout develop
    commit
    branch feature/qa-tests
    checkout feature/qa-tests
    commit
    commit
    checkout develop
    merge feature/qa-tests
    checkout main
    merge develop

🚀 Integração Contínua (CI)

A Integração Contínua é a prática de integrar o código em um repositório compartilhado várias vezes ao dia, onde cada integração é verificada por um build automatizado e testes.

Important

O objetivo do CI é encontrar erros o mais rápido possível (Fail Fast).

Componentes de um Pipeline de CI:

  1. Trigger: Evento que inicia o processo (ex: Push no GitHub).
  2. Build: Compilação do código.
  3. Test: Execução de testes unitários e de integração.
  4. Result: Notificação de sucesso ou falha.

💻 Executando uma Pipeline Localmente

git checkout -b fix/login-issue git commit -m "Fix login validation bug" git push origin fix/login-issue GitHub Actions: Running CI Pipeline... ✅ Build Success | ✅ Tests Passed

📝 Exercício de Fixação

  1. Qual a vantagem de usar o comando git branch para realizar testes?
  2. O que acontece se uma etapa de teste falhar dentro de uma pipeline de CI?

🚀 Mini-Projeto

Objetivo: Configurar um "CI manual". - Crie uma pasta local. - Crie um script shell (ou .bat) que: 1. Liste os arquivos da pasta. 2. Tente executar um comando de teste fictício (ex: python -m unittest). 3. Salve o resultado em um arquivo resultado_ci.txt. - Simule uma falha e veja o registro no log.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 06

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 06

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 06

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 06

➡️ Próxima Aula: Aula 07

Aula 07 - Técnicas de Teste: Caixa Preta 🌑

📦 O que é Teste de Caixa Preta?

Os testes de caixa preta focam nos requisitos funcionais do software. O testador não tem acesso ao código interno; ele se baseia apenas nas entradas e saídas esperadas.

Note

Também conhecido como teste baseado na especificação.

🎯 Técnicas Principais

1. Partição de Equivalência

Divide os dados de entrada em conjuntos que devem ser processados da mesma forma. Testamos apenas um valor de cada conjunto.

Exemplo: Campo "Idade" (1 a 120 anos) - Set 1: Menores que 1 (Inválido) - Set 2: 1 a 120 (Válido) - Set 3: Maiores que 120 (Inválido)

2. Análise de Valor Limite

Foca nas "bordas" das partições, onde a maioria dos erros ocorre.

Exemplo (Idade 1 a 120): - Testar: 0, 1, 2, 119, 120, 121.

3. Tabela de Decisão

Usada quando diferentes combinações de entradas resultam em diferentes ações.

graph TD
    A[Usuário Ativo?] -->|Sim| B[Tem Saldo?]
    A -->|Não| C[Negar Transação]
    B -->|Sim| D[Aprovar Transação]
    B -->|Não| E["Negar (Saldo Insuficiente)"]

💻 Simulando Entradas de Caixa Preta

python validator.py --age 0 ERROR: Idade mínima é 1. (Validado Limite Inferior) python validator.py --age 60 SUCCESS: Acesso permitido. (Validado Equivalência) python validator.py --age 121 ERROR: Idade máxima é 120. (Validado Limite Superior)

📝 Exercício de Fixação

  1. Um campo de senha aceita de 8 a 16 caracteres. Quais valores você escolheria para uma Análise de Valor Limite?
  2. Por que a Partição de Equivalência ajuda a reduzir o tempo total de execução dos testes?

🚀 Mini-Projeto

Objetivo: Aplicar técnicas de caixa preta. - Cenário: Um sistema de e-commerce dá 10% de desconto para compras acima de R$ 500,00 e frete grátis para compras acima de R$ 1.000,00. - Tarefa: Crie uma pequena tabela com 5 casos de teste que cubram a Partição de Equivalência e os Valores Limite desta regra.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 07

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 07

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 07

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 07

➡️ Próxima Aula: Aula 08

Aula 08 - Técnicas de Teste: Caixa Branca ⚪

🔍 O que é Teste de Caixa Branca?

Ao contrário da caixa preta, os testes de caixa branca (ou teste estrutural) permitem que o testador olhe para o interior do código. O objetivo é verificar a estrutura lógica, caminhos, fluxos de controle e condições.

Note

Foco na implementação e na eficiência do algoritmo.

🏗️ Técnicas Principais

1. Cobertura de Código (Code Coverage)

Mede o percentual do código que é executado pelos testes. Existem sub-níveis: - Cobertura de Instruções: Cada linha de código foi executada? - Cobertura de Decisões/Caminhos: Todos os if/else foram percorridos em ambas as direções?

2. Fluxo de Controle

Utiliza grafos para representar a lógica do programa e identificar caminhos que podem não estar sendo testados.

graph TD
    Start((Início)) --> A[Entrada X]
    A --> B{X > 10?}
    B -- Sim --> C[Ação A]
    B -- Não --> D[Ação B]
    C --> End((Fim))
    D --> End

3. Teste de Fluxo de Dados

Foca no ciclo de vida das variáveis (onde são declaradas, usadas e destruídas).

📊 Cobertura na Prática

Muitas ferramentas geram relatórios automáticos de cobertura (ex: coverage.py, Istanbul, Jacoco).

pytest --cov=app tests/ ----------- coverage: platform win32 ----------- Name Stmts Miss Cover app/auth.py 50 5 90% app/db.py 30 15 50% (Atenção aqui!)

📝 Exercício de Fixação

  1. Se um código possui 100% de Cobertura de Instruções, ele está livre de erros de lógica? Justifique.
  2. Qual a principal diferença entre um teste de Caminho e um teste de Decisão?

🚀 Mini-Projeto

Objetivo: Desenhar um fluxo de controle. - Abaixo está um pseudocódigo: 

LEIA temperatura
SE temperatura > 30:
    EXIBA "Quente"
SENÃO SE temperatura < 15:
    EXIBA "Frio"
SENÃO:
    EXIBA "Agradável"
- Tarefa: Desenhe o Grafo de Fluxo de Controle para este código e identifique quantos casos de teste são necessários para garantir 100% de cobertura de decisões.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 08

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 08

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 08

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 08

➡️ Próxima Aula: Aula 09

Aula 09 - Tipos de Testes Funcionais ✅

🎭 Classificação dos Testes

Os testes funcionais podem ser classificados de acordo com seu objetivo dentro do ciclo de vida do software.

🧪 Principais Tipos

1. Testes de Regressão

Servem para garantir que uma nova alteração (ou correção de bug) não quebrou funcionalidades que já estavam funcionando. - Importante: São os maiores candidatos para automação.

2. Testes de Fumaça (Smoke Test)

Um conjunto mínimo de testes para verificar se as funções básicas do sistema estão operando. Se o Smoke Test falha, o build é rejeitado imediatamente.

3. Testes de Aceitação (UAT)

Realizados pelo usuário final ou cliente para validar se o sistema atende às necessidades de negócio antes da entrega oficial.

4. Testes Exploratórios

Uma abordagem menos formal onde o testador aprende sobre o sistema, projeta e executa os testes simultaneamente. Baseia-se na experiência e curiosidade do QA.

mindmap
  root((Testes Funcionais))
    Regressão
      Automação
      Impacto
    Fumaça
      Sanidade
      Instabilidade
    Aceitação
      Negócio
      Alfa/Beta
    Exploratórios
      Criatividade
      Heurísticas

💻 Automatizando a Regressão

pytest tests/regression/ Ran 152 tests in 12.4s ✅ All tests passed. Baseline maintains stable.

📝 Exercício de Fixação

  1. Qual a diferença entre um Smoke Test e um Sanity Test (Teste de Sanidade)?
  2. Quando é mais indicado utilizar o Teste Exploratório ao invés de testes baseados em scripts/casos de teste?

🚀 Mini-Projeto

Objetivo: Planejar um teste de aceitação. - Imagine um sistema de "Gestão Escolar". - Escolha uma funcionalidade: "Lançamento de Notas". - Escreva 3 critérios que o Professor (Usuário Final) usaria para Aceitar ou Rejeitar essa entrega.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 09

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 09

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 09

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 09

➡️ Próxima Aula: Aula 10

Aula 10 - Testes Não Funcionais e Usabilidade 🧠

🏗️ Além da Funcionalidade

Um software pode fazer exatamente o que foi solicitado, mas ser impossível de usar, lento ou inseguro. É aqui que entram os Testes Não Funcionais.

🧪 Principais Categorias

1. Performance, Carga e Estresse

  • Performance: O quão rápido o sistema responde?
  • Carga: O sistema aguenta 1.000 usuários simultâneos?
  • Estresse: O que acontece se o sistema receber 10x mais carga do que o planejado? (Ponto de ruptura).

2. Segurança

Verifica vulnerabilidades, permissões de acesso e proteção de dados sensíveis (LGPD).

3. Usabilidade e UX (User Experience)

Avalia a facilidade de aprendizado, eficiência de uso e o nível de satisfação do usuário.

graph LR
    A[Qualidade] --> B[Funcional]
    A --> C[Não Funcional]
    C --> D[Performance]
    C --> E[Segurança]
    C --> F[Usabilidade]
    C --> G[Portabilidade]

🎨 Conceitos de UX para QAs

Um QA deve se preocupar com as 10 Heurísticas de Nielsen, como: - Visibilidade do status do sistema. - Correspondência entre o sistema e o mundo real. - Flexibilidade e eficiência de uso.

💻 Monitorando Resposta de Sistema

ab -n 100 -c 10 https://api.exemplo.com/v1/search Requests per second: 15.4 [#/sec] (mean) Time per request: 649 ms (mean) Atenção: Latência acima do SLA (500ms).

📝 Exercício de Fixação

  1. Qual a diferença entre um Teste de Carga e um Teste de Estresse?
  2. Como um problema de usabilidade pode afetar a imagem de uma empresa, mesmo que o sistema não tenha bugs funcionais?

🚀 Mini-Projeto

Objetivo: Auditoria de Usabilidade. - Escolha um formulário online complexo (ex: cadastro em site oficial). - Identifique 2 pontos onde a Heurística de Prevenção de Erros poderia ser melhor aplicada. - Sugira uma melhoria para cada ponto.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 10

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 10

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 10

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 10

➡️ Próxima Aula: Aula 11

Aula 11 - Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵

🔄 O Ciclo do TDD

O TDD (Test Driven Development) não é apenas uma técnica de teste, mas uma metodologia de design de software. O mantra é: "Nunca escreva uma linha de código sem antes ter um teste que falhe."

A metodologia baseia-se em um ciclo curto e repetitivo:

  1. 🔴 RED: Escreva um teste pequeno que falhe (pois a funcionalidade ainda não existe).
  2. 🟢 GREEN: Escreva a quantidade mínima de código para fazer o teste passar.
  3. 🔵 REFACTOR: Melhore o código escrito, removendo duplicidade e aplicando padrões, garantindo que o teste continue passando.
stateDiagram-v2
    [*] --> Red
    Red --> Green : Escrever código mínimo
    Green --> Refactor : Melhorar estrutura
    Refactor --> Red : Próximo requisito
    Refactor --> [*] : Funcionalidade Completa

🧠 Por que usar TDD?

  • Foco no Requisito: Você só implementa o que é estritamente necessário.
  • Documentação Viva: Os testes servem como exemplos reais de uso do código.
  • Redução de Bugs: Problemas de lógica são encontrados instantaneamente.
  • Confiança na Refatoração: Você pode mudar o código sabendo que os testes te protegem.

💻 TDD no Terminal

pytest tests/test_math.py FAILED: test_sum_two_numbers not found (RED) nano math_utils.py # Implementando def sum(a,b): return a+b pytest tests/test_math.py PASSED: test_sum_two_numbers (GREEN) nano math_utils.py # Refatoração do código

📝 Exercício de Fixação

  1. No ciclo do TDD, por que é proibido escrever mais código do que o necessário para o teste passar na fase GREEN?
  2. Qual a diferença entre um teste escrito antes do código (TDD) e um teste escrito depois do código pronto?

🚀 Mini-Projeto

Objetivo: Aplicar o ciclo Red-Green-Refactor mentalmente. - Requisito: Uma função que recebe um nome e retorna "Olá, [Nome]". - Passo 1 (Red): Como seria a chamada deste teste? Qual seria o erro esperado? - Passo 2 (Green): Qual o código mínimo para retornar a string correta? - Passo 3 (Refactor): O que você poderia melhorar se tivesse que tratar nomes vazios?

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 11

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 11

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 11

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 11

➡️ Próxima Aula: Aula 12

Aula 12 - Testes Unitários e de Integração 🔗

🏗️ A Pirâmide de Testes

A base da qualidade técnica de um sistema reside na proporção correta de tipos de testes automatizados. - Unitários: Testam componentes isolados (funções, classes). Devem ser maioria por serem rápidos e baratos. - Integração: Testam a comunicação entre dois ou mais componentes (ex: app e banco de dados).

graph TD
    A[UI / E2E] --- B[Serviços / Integração]
    B --- C[Unitários]
    style C fill:#f9f,stroke:#333,stroke-width:4px

📐 Estrutura AAA (Arrange, Act, Assert)

Um bom teste automatizado deve ser organizado em três etapas claras:

  1. Arrange (Organizar): Configura o cenário, cria os objetos e prepara os dados.
  2. Act (Agir): Executa a ação ou função que se deseja testar.
  3. Assert (Verificar): Valida se o resultado obtido é igual ao esperado.

Exemplo (Python):

def test_deve_aplicar_desconto():
    # Arrange
    original_price = 100
    expected_price = 90

    # Act
    final_price = apply_discount(original_price, 10)

    # Assert
    assert final_price == expected_price

🎭 Mocks e Dublês de Teste

Quando um componente depende de algo externo (como uma API de pagamentos ou um Banco de Dados), usamos Mocks. O Mock simula o comportamento da dependência, permitindo que o teste unitário continue sendo rápido e independente.

💻 Monitorando Cobertura Unitária

pytest --cov=services tests/unit/ TOTAL: 85% Cobertura pytest tests/integration/ 3 Failed: Banco de Dados não respondeu (Mock não utilizado!)

📝 Exercício de Fixação

  1. Por que não devemos testar o Banco de Dados real em um Teste Unitário?
  2. Identifique as fases (Arrange, Act, Assert) em um teste de login que você realizaria manualmente.

🚀 Mini-Projeto

Objetivo: Desenhar um teste de integração. - Cenário: Uma função que salva um pedido no banco e envia um email de confirmação. - Como você testaria isso sem enviar um email real para o cliente? - Desenhe o fluxo indicando onde entraria um Mock.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 12

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 12

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 12

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 12

➡️ Próxima Aula: Aula 13

Aula 13 - Automação de Testes Web 🤖

🕸️ Por que automatizar a Web?

A automação de interfaces web (E2E - End-to-End) permite simular a jornada completa do usuário no navegador. Isso reduz drasticamente o tempo de testes de regressão em sistemas complexos.

Important

A automação web deve focar nos caminhos críticos (Happy Path) do negócio.

🛠️ Ferramentas Populares

1. Selenium WebDriver

O veterano do mercado. Suporta múltiplas linguagens (Python, Java, C#) e navegadores. Baseia-se em um protocolo de comunicação com o driver do browser.

2. Playwright / Cypress

Ferramentas modernas que rodam "mais perto" do browser, oferecendo maior velocidade, estabilidade (auto-waiting) e recursos de depuração (Trace Viewer).

📍 Localizando Elementos (Locators)

Para o script interagir com a página, precisamos "achar" os elementos HTML. As melhores práticas recomendam usar (em ordem de prioridade): 1. ID: id="submit-button" 2. Name: name="email" 3. Data-attributes: data-testid="login-btn" (O favorito dos QAs!) 4. CSS Selector ou XPath (Use como última opção).

graph LR
    A[Início do Script] --> B[Abrir Navegador]
    B --> C[Navegar para URL]
    C --> D[Localizar Elemento]
    D --> E[Interagir: Click/Type]
    E --> F[Validar Resultado: Assertion]
    F --> G[Fechar Navegador]

💻 Automação no Terminal

npx playwright test Running 5 tests using 3 workers ✅ [chromium] › login.spec.ts:12:5 › successful login ✅ [firefox] › checkout.spec.ts:45:5 › add item to cart 5 passed (15.2s)

📝 Exercício de Fixação

  1. O que é Flakiness (instabilidade) em testes automatizados e como ferramentas modernas como o Playwright ajudam a evitá-lo?
  2. Por que o uso de data-testid é melhor do que usar classes CSS para localizar elementos em um teste?

🚀 Mini-Projeto

Objetivo: Escrever um script fictício (Pseudocódigo). - Cenário: Validar a busca de produtos no Google. - Escreva o passo a passo do script: 1. Qual URL abrir? 2. Qual o seletor do campo de busca? 3. O que digitar? 4. Como validar que a busca funcionou?

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 13

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 13

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 13

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 13

➡️ Próxima Aula: Aula 14

Aula 14 - Testes de API 📡

🔌 O que são APIs?

APIs (Application Programming Interfaces) são pontes que permitem que diferentes sistemas se comuniquem. Atualmente, o padrão REST é o mais utilizado em sistemas web e mobile.

Testar a API é testar o "coração" do negócio sem a interferência da interface visual (mais rápido e estável).

🔑 Conceitos Fundamentais HTTP

1. Métodos (Verbos)

  • GET: Buscar informações.
  • POST: Criar um novo recurso.
  • PUT/PATCH: Atualizar informações.
  • DELETE: Remover um recurso.

2. Status Codes

  • 2xx (Sucesso): Ex: 200 OK, 201 Created.
  • 4xx (Erro do Cliente): Ex: 400 Bad Request, 401 Unauthorized, 404 Not Found.
  • 5xx (Erro do Servidor): Ex: 500 Internal Server Error.

🛠️ Testando com Postman

O Postman é a ferramenta líder para testes de API. Ele permite criar coleções de requisições e automatizar validações usando JavaScript.

sequenceDiagram
    participant QA as Postman/QA
    participant API as Servidor API
    participant DB as Banco de Dados
    QA->>API: POST /login (JSON Payload)
    API->>DB: Verifica Credenciais
    DB-->>API: OK
    API-->>QA: 200 OK + Token JWT

💻 Teste de API via Terminal (cURL)

curl -X GET https://api.exemplo.com/usuarios/1 { "id": 1, "nome": "Ricardo", "ativo": true } newman run colecao_testes.json Finalized: 25 Assertions Passed | 0 Failed

📝 Exercício de Fixação

  1. Qual a diferença entre o status code 401 e o 403?
  2. Por que é considerado "boa prática" testar as APIs antes de testar a interface visual (Frontend)?

🚀 Mini-Projeto

Objetivo: Validar uma resposta JSON. - Recebemos o seguinte JSON da API: 

{
  "status": "sucesso",
  "data": { "valor": 150.00, "moeda": "BRL" }
}
- Tarefa: Escreva 2 validações que você faria nesta resposta (ex: validar o campo status, validar o valor).

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 14

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 14

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 14

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 14

➡️ Próxima Aula: Aula 15

Aula 15 - Gestão de Defeitos e Ferramentas 🐛

📊 O Ciclo de Vida de um Bug

Encontrar um bug é apenas metade do trabalho. A outra metade é garantir que ele seja corrigido, retestado e encerrado. O Ciclo de Vida do Defeito define os estados pelos quais um bug passa.

stateDiagram-v2
    [*] --> Novo
    Novo --> Aberto : Analisar
    Aberto --> Corrigido : Desenvolvedor fixa
    Corrigido --> Reteste : QA verifica
    Reteste --> Fechado : Sucesso
    Reteste --> Aberto : Falha (Reabrir)
    Aberto --> Rejeitado : Não é bug
    Aberto --> Postergado : Baixa Prioridade

🛠️ Ferramentas de Gestão (Jira)

O Jira é a ferramenta padrão de mercado para gestão ágil e rastreamento de bugs. Através dele, conseguimos: - Criar Issues (tarefas/bugs). - Definir Prioridade (Urgência: Crítica, Alta, Média, Baixa). - Definir Severidade (Impacto técnico: Bloqueante, Crítico, Menor). - Acompanhar o progresso via Boards Kanban ou Scrum.

Métricas de Acompanhamento

  • Bug Leakage: Defeitos que escaparam para produção.
  • Bug Open Rate: Velocidade de descoberta vs. Velocidade de correção.

💻 Rastreando Bugs no Console

jira login --email qateam@empresa.com jira issue list --project QA --status "In Progress" QA-125: Falha no cálculo de frete (Alta) jira issue create --title "Página de erro 404 ao salvar perfil" ✅ Issue QA-256 criada com sucesso!

📝 Exercício de Fixação

  1. Qual a diferença entre uma issue Rejeitada e uma issue Postergada?
  2. Por que é importante anexar Evidências (screenshots, logs, vídeos) em um report de bug?

🚀 Mini-Projeto

Objetivo: Simular um Board de Gestão. - Imagine que você encontrou 3 bugs: 1. O logotipo está ligeiramente torto. 2. O banco de dados cai ao processar 10 pedidos. 3. O botão de "Logout" não funciona. - Tarefa: Classifique cada um por Severidade e Prioridade e indique qual deve ser corrigido primeiro.

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 15

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 15

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 15

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 15

➡️ Próxima Aula: Aula 16

Aula 16 - Projeto Integrador Final 🎓

🏁 O Desafio Final

Chegamos ao final da nossa jornada! Agora é hora de consolidar todo o conhecimento em um projeto prático real. Você assumirá o papel de um QA Pleno responsável por garantir a qualidade de uma nova funcionalidade de um sistema.

📋 Escopo do Projeto

Você deverá testar um módulo de "Reserva de Vagas de Estacionamento".

Atividades Obrigatórias:

  1. Planejamento (STLC): Defina o escopo e o que será testado.
  2. Técnicas de Caixa Preta: Aplique Valor Limite e Partição de Equivalência para o campo "Horas de Reserva" (mínimo 1h, máximo 24h).
  3. TDD e Testes Unitários: Escreva (em pseudocódigo ou código real) 2 testes unitários para a regra de cálculo de preço.
  4. Automação Web: Escreva o roteiro (ou script) para validar o fluxo de reserva no site.
  5. Relatório de Defeitos: Documente pelo menos 1 bug fictício encontrado durante os testes.

📊 Estrutura de Entrega Esperada

graph TD
    A[Plano de Teste] --> B[Lista de Cenários]
    B --> C[Execução e Evidências]
    C --> D[Relatório de Bugs]
    D --> E[Relatório de Cobertura Final]

💻 Simulando a Validação Final

pytest --version ./run-all-tests.sh Testes Unitários: ✅ PASSED Testes de API: ✅ PASSED Testes Web (E2E): ✅ PASSED Projeto Validado. Parabéns, você é um QA de Sucesso! 🚀

🏆 Critérios de Avaliação

  • Rigor Técnico: Uso correto das técnicas de Valor Limite.
  • Organização: Documentação clara e estruturada.
  • Visão Crítica: Capacidade de identificar riscos e bugs complexos.
  • Domínio de Ferramentas: Demonstração de conhecimento em automação.

📝 Considerações Finais

A área de Qualidade e Testes é dinâmica e fundamental para o sucesso de qualquer empresa de tecnologia. Continue estudando, praticando TDD e explorando novas ferramentas de automação!

Sucesso na sua carreira em QA! 🧪✨

🔗 Materiais da Aula

  • Slides --- Material visual com diagramas e conceitos-chave. Slide 16

  • Quiz --- Teste seu conhecimento com 10 questões interativas. Quiz 16

  • Exercícios --- 5 exercícios progressivos (básico → desafio). Exercício 16

  • Projeto --- Aplicação prática dos conceitos da aula. Projeto 16

Parabéns!

Você concluiu todas as aulas deste curso!

🏆 Voltar à Trilha de Aulas

Aula 17 - Testes de Carga, Estresse e Performance 📈

Objetivo Pedagógico

Objetivo: Conceber e executar testes de carga, capacidade máxima (estresse), pico (spike) e resistência (soak) em sistemas distribuídos utilizando k6, analisando métricas de percentis (p95, p99), throughput (RPS) e thresholds.

📑 1. Fundamentos Teóricos & Análise Técnica

A qualidade de um sistema em escala de produção transcende a corretude funcional: sistemas que se degradam sob tráfego violam acordos de nível de serviço (Service Level Agreements - SLA).

A disciplina de Engenharia de Performance classifica os ensaios de carga em categorias com objetivos distintos: 1. Tipologias de Testes de Performance: - Teste de Carga (Load Testing): Avalia o comportamento do sistema sob volume esperado de usuários simultâneos em regime normal de operação. - Teste de Estresse (Stress Testing): Aumenta a carga progressivamente além dos limites projetados para descobrir o ponto de ruptura (Breaking Point) e avaliar se o sistema falha de forma graciosa (Graceful Degradation). - Teste de Pico (Spike Testing): Aplica uma onda súbita e massiva de requisições em segundos para testar a capacidade de auto-scaling e absorção rápida de tráfego. - Teste de Resistência (Soak / Endurance Testing): Mantém carga moderada por períodos extensos (horas ou dias) para diagnosticar vazamentos graduais de memória (Memory Leaks) e esgotamento de conexões em pool de banco de dados.

  1. Métricas Críticas de Observabilidade:
  2. A Falácia das Médias: O tempo médio de resposta mascara caudas de lentidão sofridas por usuários reais. A engenharia de confiabilidade utiliza Percentis: p95 (95% dos usuários responderam abaixo deste tempo) e p99 (o percentil 1% mais lento).
  3. Throughput e Taxa de Erro: Requisições por segundo (RPS) suportadas concomitantemente à manutenção da taxa de erro HTTP 5xx abaixo de limites rígidos (ex: < 0.1%).

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    k6["Motor k6 (Virtual Users - VUs)"] --> Ramping["Estágio de Ramp-Up (0 -> 500 VUs)"]
    Ramping --> Plateau["Estágio de Platô de Carga (500 VUs por 5m)"]
    Plateau --> Spike["Estágio de Pico (Spike para 2000 VUs)"]
    Spike --> Metrics["Coleta de Métricas em Tempo Real"]
    Metrics --> P95["Latência p95 < 200ms"]
    Metrics --> P99["Latência p99 < 500ms"]
    Metrics --> Err["Taxa de Erro < 0.5%"]
    style k6 fill:#e1f5fe,stroke:#01579b
    style Ramping fill:#fff3e0,stroke:#e65100
    style Spike fill:#ffebee,stroke:#c62828
    style P95 fill:#e8f5e9,stroke:#2e7d32
    style P99 fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Thresholds Declarativos (SLOs): Condições no script de teste que causam falha imediata no pipeline de CI se os percentis aceitáveis forem excedidos. - Virtual Users (VUs) Assíncronos: Arquitetura baseada em Go do k6 que executa milhares de VUs leves sem a sobrecarga de threads pesadas de ferramentas legadas. - Cenários de Chegada Realista (Open Models): Modelagem de tráfego que injeta requisições de forma independente da velocidade com que o servidor responde. - Identificação de Gargalos de Conexão: Diagnóstico de starvation de pools de threads, locks de banco de dados e saturação de socket TCP TIME_WAIT.

🛠️ 2. Implementação Prática em Engenharia de Performance e Testes com k6

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// load_test_k6.js (Script de Teste de Carga com Thresholds de SLA em k6)
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 50 },  // Ramp-up gradual para 50 VUs
    { duration: '1m',  target: 200 }, // Carga constante de 200 VUs
    { duration: '20s', target: 500 }, // Spike súbito para 500 VUs
    { duration: '30s', target: 0 },   // Ramp-down para repouso
  ],
  thresholds: {
    http_req_duration: ['p(95)<300', 'p(99)<800'], // 95% das requisições devem responder em < 300ms
    http_req_failed: ['rate<0.01'],                 // Menos de 1% de falhas permitidas
  },
};

export default function () {
  const params = {
    headers: { 'Content-Type': 'application/json' },
  };

  const res = http.get('https://api.empresa.com/v1/produtos', params);

  check(res, {
    'status é 200': (r) => r.status === 200,
    'tempo de resposta < 400ms': (r) => r.timings.duration < 400,
  });

  sleep(1); // Tempo de reflexão (think time) do usuário virtual
}

💡 Análise Passo a Passo do Código

  1. Estágios Multi-fase: Simula a evolução orgânica do tráfego corporativo desde o aquecimento até o pico de estresse.
  2. Thresholds como Quality Gates: Integra a validação de performance diretamente no pipeline de automação, quebrando o build caso o p95 ultrapasse 300ms.
  3. Validações com check: Verifica a integridade funcional do payload da resposta simultaneamente à medição de latência.

🎯 3. Próximos Passos & Sequência Didática

Aula 18 - Testes de Contrato de APIs e Schema-First 📜

Objetivo Pedagógico

Objetivo: Estruturar testes de contrato de APIs orientados a microsserviços usando o Pact Framework (Consumer-Driven Contracts), prevenindo quebras de integração sem a necessidade de manter ambientes integrados frágeis e pesados.

📑 1. Fundamentos Teóricos & Análise Técnica

Na arquitetura de microsserviços, a proliferação de serviços interdependentes torna os testes de ponta a ponta (E2E) excessivamente lentos, frágeis e difíceis de manter.

Os Testes de Contrato Dirigidos pelo Consumidor (Consumer-Driven Contract Testing - CDC) resolvem esse problema desacoplando a validação: 1. O Paradigma Consumer-Driven: - O Consumidor (Consumer) define formalmente quais endpoints consome e quais campos do payload e status de resposta são estritamente necessários para seu funcionamento. - Essa expectativa é serializada em um arquivo de contrato padronizado (o arquivo Pact JSON). 2. Validação Isolada do Provedor (Provider Verification): - O Provedor (Provider) não necessita que o consumidor esteja online para testar a integração. - O provedor lê o arquivo Pact publicado em um servidor central (Pact Broker) e simula as requisições contra sua própria API em ambiente de teste unitário/componente, atestando se sua implementação satisfaz o contrato prometido. 3. Prevenção de Quebras de Produção com can-i-deploy: - Antes de realizar o deploy de qualquer microsserviço em produção, a ferramenta consulta o Pact Broker via CLI (pact-broker can-i-deploy). - Se o provedor não tiver verificado positivamente a versão exata do contrato exigido pelo consumidor, o deploy é bloqueado no pipeline de CI.

📐 Arquitetura Conceitual & Diagrama de Fluxo

sequenceDiagram
    autonumber
    participant C as Consumidor (Frontend/App)
    participant B as Pact Broker (Repositório Central)
    participant P as Provedor (API Microsserviço)
    Note over C: Teste Unitário do Consumidor gera contrato Pact JSON
    C->>B: Publica Contrato (v1.2.0)
    Note over P: Provedor executa suite de testes de contrato
    P->>B: Baixa contratos vigentes dos consumidores
    P->>P: Executa replay das requisições contra API local
    P->>B: Publica resultado: Verificação APROVADA!
    Note over C,P: Ferramenta can-i-deploy libera o deploy em produção!

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Desacoplamento de Ambientes: Elimina a dependência de ambientes de teste integrados instáveis onde a queda de um serviço trava o teste de todos os demais. - Evolução Segura de APIs: Campos não utilizados pelos consumidores podem ser depreciados ou removidos sem receio de impactos em produção. - Pact Broker Matrix: Matriz multidimensional que valida a compatibilidade cruzada entre versões de consumidores e provedores em múltiplos ambientes (Dev, Staging, Prod). - Mocking Determinístico: O framework provê servidor mock local gerado a partir do contrato para testes unitários do consumidor.

🛠️ 2. Implementação Prática em Pact Framework e Testes de Contrato Dirigidos pelo Consumidor (CDC)

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// consumer_contract.test.js (Definição de Contrato Pact com Mock Service)
import { PactV3, MatchersV3 } from '@pact-foundation/pact';
import axios from 'axios';

const { like, string, integer } = MatchersV3;

const provider = new PactV3({
  consumer: 'WebFrontend',
  provider: 'OrderService',
});

describe('Contrato com OrderService', () => {
  it('deve retornar pedido detalhado com status 200', async () => {
    // 1. Definir expectativa do contrato
    provider
      .given('existe um pedido com ID 100')
      .uponReceiving('uma requisição para buscar o pedido 100')
      .withRequest({
        method: 'GET',
        path: '/orders/100',
        headers: { Accept: 'application/json' },
      })
      .willRespondWith({
        status: 200,
        headers: { 'Content-Type': 'application/json' },
        body: {
          id: integer(100),
          customerName: like('Carlos Silva'),
          status: string('PROCESSANDO'),
        },
      });

    // 2. Executar teste contra o Mock Server do Pact
    await provider.executeTest(async (mockserver) => {
      const response = await axios.get(`${mockserver.url}/orders/100`, {
        headers: { Accept: 'application/json' },
      });
      expect(response.status).toBe(200);
      expect(response.data.id).toBe(100);
    });
  });
});

💡 Análise Passo a Passo do Código

  1. Uso de Matchers de Tipo (like, integer): Evita acoplamento a valores estáticos, validando que o provedor retorne os tipos de dados acordados.
  2. Provider State (given): Informa ao provedor qual estado inicial de banco de dados deve ser configurado antes do teste de validação.
  3. Geração Automática do Pact JSON: A execução bem-sucedida do teste unitário serializa o contrato formal para upload no Pact Broker.

🎯 3. Próximos Passos & Sequência Didática

Aula 19 - Testes de Regressão Visual e Automação E2E 👁️

Objetivo Pedagógico

Objetivo: Construir uma suíte robusta de testes de ponta a ponta (E2E) e regressão visual com Playwright, aplicando Page Object Model (POM), isolamento de storage state e comparação pixel a pixel com snapshots.

📑 1. Fundamentos Teóricos & Análise Técnica

Os testes automatizados tradicionais focados no Document Object Model (DOM) garantem que elementos HTML existam na tela, mas são completamente cegos para falhas de renderização gráfica: sobreposição indevida de elementos CSS, layout quebrado em responsividade ou fontes ausentes.

A união de Automação E2E Moderna com Testes Visuais oferece a garantia final de qualidade na interface do usuário: 1. Playwright vs. Ferramentas Legadas: - O Playwright comunica-se diretamente com os motores dos navegadores (Chromium, Firefox, WebKit) via Chrome DevTools Protocol (CDP) e protocolos nativos, eliminando intermediários frágeis como o WebDriver. - Auto-Wait Nativo: Aguarda automaticamente que os elementos estejam visíveis, estáveis e interativos antes de disparar cliques ou preenchimento de campos, eliminando esperas arbitrárias (sleep) e testes intermitentes (flaky tests). 2. Testes de Regressão Visual (Snapshot Testing): - Captura telas em resolução configurada e compara a imagem resultante pixel a pixel com um baseline pré-aprovado mantido no repositório. - Qualquer desvio superior a um limiar de tolerância configurado (ex: maxDiffPixelRatio: 0.05) gera um mapa de calor diferencial (diff image), alertando sobre quebras involuntárias de CSS ou componentes. 3. Autenticação Otimizada via Storage State: - O ciclo de login é executado uma única vez na suíte, e os cookies/tokens de sessão são gravados em disco, permitindo que dezenas de testes iniciem já autenticados instantaneamente.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Test["Playwright Test Runner"] --> Setup["Carrega Storage State (Sessão Prévia)"]
    Setup --> Page["Renderiza Página com Viewport Responsivo"]
    Page --> Action["Interação do Usuário (Click, Type via Auto-Wait)"]
    Action --> Snap["Captura Screenshot Atual"]
    Snap --> DiffEngine["Motor de Comparação de Pixels"]
    Baseline["Baseline de Imagem Aprovada"] --> DiffEngine
    DiffEngine --> Eval{"Diferença > Tolerância?"}
    Eval -- Não --> Pass["Aprovado (Zero Regressão Visual)"]
    Eval -- Sim --> DiffMap["Gera Imagem Diff Destacando Quebra Visual"]
    DiffMap --> Fail["Build Falha no CI"]
    style Test fill:#e1f5fe,stroke:#01579b
    style DiffEngine fill:#fff3e0,stroke:#e65100
    style Pass fill:#e8f5e9,stroke:#2e7d32
    style Fail fill:#ffebee,stroke:#c62828

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Padrão Page Object Model (POM): Encapsulamento de seletores de tela e interações em classes dedicadas para simplificar a manutenção dos testes. - Isolamento Total por BrowserContext: Cada teste executa em um contexto de navegador completamente isolado, sem contaminação de cache ou cookies. - Rastreamento com Trace Viewer: Gravação completa da execução do teste com vídeo, snapshots de DOM a cada passo e linha do tempo da rede. - Tolerância a Anti-Aliasing: Configuração de limiares que ignoram diferenças imperceptíveis causadas por renderizadores de fontes em diferentes SOs.

🛠️ 2. Implementação Prática em Automação End-to-End e Visual Testing com Playwright

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// visual_regression.spec.ts (Teste Visual e E2E Responsivo com Playwright)
import { test, expect } from '@playwright/test';

test.describe('Validação Visual do Dashboard de Vendas', () => {
  test('deve renderizar o layout do dashboard sem regressão visual', async ({ page }) => {
    // 1. Navegação com garantia de carregamento de rede estável
    await page.goto('/dashboard', { waitUntil: 'networkidle' });

    // 2. Ocultar elementos dinâmicos imprevisíveis (ex: relógios, avatares)
    await page.addStyleTag({
      content: '.dynamic-timestamp, .live-notification { visibility: hidden !important; }'
    });

    // 3. Validação funcional via Auto-Wait
    const metricCard = page.locator('[data-testid="total-sales-card"]');
    await expect(metricCard).toBeVisible();

    // 4. Comparação de Regressão Visual com baseline de imagem
    await expect(page).toHaveScreenshot('dashboard-baseline.png', {
      maxDiffPixelRatio: 0.02, // Permite no máximo 2% de diferença aceitável
      fullPage: true,
    });
  });
});

💡 Análise Passo a Passo do Código

  1. Diretiva networkidle: Aguarda o encerramento de requisições de API assíncronas antes de congelar a imagem para o snapshot.
  2. Mascaramento de Conteúdo Volátil: Evita falsos positivos em testes visuais ocultando dados que se alteram em cada segundo.
  3. Validação de Página Completa (fullPage): Garante a integridade do design em todo o scroll da página, protegendo rodapés e seções inferiores.

🎯 3. Próximos Passos & Sequência Didática

Aula 20 - Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀

Objetivo Pedagógico

Objetivo: Conceber uma arquitetura holística de qualidade de software: pirâmide de testes completa, orquestração de testes unitários, de mutação (Stryker), contratos e performance em pipeline integrado com relatórios de cobertura consolidados.

📑 1. Fundamentos Teóricos & Análise Técnica

A maturidade de uma organização de engenharia é medida pela robustez de sua estratégia de qualidade automatizada.

O Projeto Capstone de Qualidade e Testes sintetiza os modelos teóricos e práticos da disciplina: 1. A Pirâmide de Testes Equilibrada: - Base Larga (Testes Unitários): Milhares de testes rápidos e determinísticos com cobertura de branches superior a 80%. - Camada Média (Testes de Integração e Contrato): Centenas de testes validando a comunicação de componentes, repositórios de dados e contratos de APIs. - Topo Estrito (Testes E2E e Visuais): Dezenas de cenários de fluxos críticos de negócio (User Journeys) com validação visual automatizada. 2. Além da Cobertura Tradicional: Testes de Mutação: - Uma cobertura de código de 100% não garante que os testes sejam eficazes se os asserts forem superficiais. - Os Testes de Mutação (Mutation Testing) introduzem falhas propositais no código-fonte (mutantes: alteração de operadores >, inversão de booleanos) para verificar se a suíte de testes existente detecta e elimina o mutante (Mutation Score). 3. Orquestração e Quality Gates Automatizados: - O pipeline consolida relatórios de cobertura, métricas de performance e relatórios de vulnerabilidade em um portal unificado, bloqueando releases que não atinjam os thresholds de qualidade corporativa.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Code["Push de Código no Repositório"] --> Gate1["Fase 1: Unit Tests & Análise de Mutação (Stryker)"]
    Gate1 --> Gate2["Fase 2: Testes de Contrato CDC (Pact Broker)"]
    Gate2 --> Gate3["Fase 3: Testes E2E e Regressão Visual (Playwright)"]
    Gate3 --> Gate4["Fase 4: Testes de Carga e SLA (k6)"]
    Gate4 --> Dashboard["Dashboard Unificado de Métricas de Qualidade"]
    Dashboard --> Status{"Mutation Score > 80% & p95 < 300ms?"}
    Status -- Sim --> Deploy["Deploy Seguro em Produção"]
    Status -- Não --> Block["Bloqueio Imediato de Release"]
    style Code fill:#e1f5fe,stroke:#01579b
    style Gate1 fill:#fff3e0,stroke:#e65100
    style Gate4 fill:#f3e5f5,stroke:#7b1fa2
    style Deploy fill:#e8f5e9,stroke:#2e7d32
    style Block fill:#ffebee,stroke:#c62828

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Mutation Score Indicator: Percentual de falhas sintéticas injetadas que foram capturadas por asserções de teste reais. - Execução em Matriz Paralela: Distribuição dos testes em múltiplos runners de CI para manter o tempo total de feedback abaixo de 10 minutos. - Relatórios Padronizados JUnit/Allure: Geração de artefatos padronizados para visualização executiva e histórica das suítes de teste. - Zero-Flakiness Policy: Isolamento automático de testes instáveis para quarentena sem comprometer a confiança da equipe nos pipelines.

🛠️ 2. Implementação Prática em Engenharia de Qualidade Contínua e Pirâmide de Testes

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// quality_pipeline_capstone.yml (Orquestração Completa dos Gates de Qualidade em CI)
name: Comprehensive Quality Pipeline

on: [push, pull_request]

jobs:
  unit-and-mutation:
    name: Unit & Mutation Testing Gate
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - name: Rodar Testes Unitários com Cobertura
        run: npm run test:unit -- --coverage --coverageThreshold='{"global":{"lines":80}}'
      - name: Executar Teste de Mutação com Stryker
        run: npx stryker run --reporters clear-text,dashboard

  contract-tests:
    name: Contract Verification Gate
    needs: unit-and-mutation
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - name: Verificar Contratos no Pact Broker
        run: npm run test:contract

  e2e-and-visual:
    name: Playwright E2E & Visual Gate
    needs: unit-and-mutation
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - name: Instalar Navegadores Playwright
        run: npx playwright install --with-deps
      - name: Executar Suíte E2E e Visual
        run: npx playwright test

  performance-k6:
    name: Performance SLA Gate
    needs: [contract-tests, e2e-and-visual]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: grafana/k6-action@v0.3.1
        with:
          filename: tests/perf/load_test_k6.js

💡 Análise Passo a Passo do Código

  1. Dependência Hierárquica (needs): Economiza recursos de computação interrompendo o pipeline nas fases rápidas antes de disparar testes pesados.
  2. Avaliação de Cobertura Rígida: Falha imediatamente caso a cobertura de linhas de código caia abaixo do limiar de 80%.
  3. Integração do Stryker: Avalia matematicamente a força das asserções da suíte através de mutação de bytecode/AST.

🎯 3. Próximos Passos & Sequência Didática

Exercícios

🏋️ Exercícios do Curso

Lista completa das 20 unidades de exercicios organizadas em 5 módulos didáticos.

🏋️ Exercício 01 – Qualidade de Software e Papel do QA

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 01 sobre Qualidade de Software e Papel do QA, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Qualidade de Software e Papel do QA, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Qualidade de Software e Papel do QA** fundamenta-se em princípios consolidados de engenharia de software (Conceitos de Qualidade, ⚠️ Erro, Defeito e Falha, Verificação x Validação, Visão Geral dos Testes). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Qualidade de Software e Papel do QA. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Qualidade de Software e Papel do QA** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Qualidade de Software e Papel do QA. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 01 Responder Quiz 01

🏋️ Exercício 02 – Modelos de Qualidade de Software

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 02 sobre Modelos de Qualidade de Software, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Modelos de Qualidade de Software, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Modelos de Qualidade de Software** fundamenta-se em princípios consolidados de engenharia de software (️ Modelos de Referência, MPS.br (Melhoria de Processo do Software Brasileiro), Métricas de Defeitos, Verificando Status de Maturity no Projeto). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Modelos de Qualidade de Software. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Modelos de Qualidade de Software** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Modelos de Qualidade de Software. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 02 Responder Quiz 02

🏋️ Exercício 03 – Ciclo de Vida de Testes (STLC)

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 03 sobre Ciclo de Vida de Testes (STLC), cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Ciclo de Vida de Testes (STLC), definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Ciclo de Vida de Testes (STLC)** fundamenta-se em princípios consolidados de engenharia de software (⚙️ O que é STLC?, ️ Fases do STLC, ⚖️ STLC vs SDLC, Simulação de Configuração de Ambiente). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Ciclo de Vida de Testes (STLC). Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Ciclo de Vida de Testes (STLC)** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Ciclo de Vida de Testes (STLC). Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 03 Responder Quiz 03

🏋️ Exercício 04 – Documentação e Controle de Testes

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 04 sobre Documentação e Controle de Testes, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Documentação e Controle de Testes, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Documentação e Controle de Testes** fundamenta-se em princípios consolidados de engenharia de software (A Importância da Documentação, ️ Principais Artefatos, Indicadores (Métricas), Verificando Cobertura de Logs). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Documentação e Controle de Testes. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Documentação e Controle de Testes** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Documentação e Controle de Testes. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 04 Responder Quiz 04

🏋️ Exercício 05 – Melhores Práticas de Programação ✨

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 05 sobre Melhores Práticas de Programação ✨, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Melhores Práticas de Programação ✨, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Melhores Práticas de Programação ✨** fundamenta-se em princípios consolidados de engenharia de software (Introdução ao Clean Code, ️ Princípios para Testabilidade, ️ Refatoração, Refatoração na Prática (Terminal)). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Melhores Práticas de Programação ✨. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Melhores Práticas de Programação ✨** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Melhores Práticas de Programação ✨. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 05 Responder Quiz 05

🏋️ Exercício 06 – Controle de Versão e CI

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 06 sobre Controle de Versão e CI, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Controle de Versão e CI, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Controle de Versão e CI** fundamenta-se em princípios consolidados de engenharia de software (Versionamento com Git, Integração Contínua (CI), Executando uma Pipeline Localmente, Mini-Projeto). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Controle de Versão e CI. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Controle de Versão e CI** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Controle de Versão e CI. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 06 Responder Quiz 06

🏋️ Exercício 07 – Técnicas de Teste: Caixa Preta

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 07 sobre Técnicas de Teste: Caixa Preta, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Técnicas de Teste: Caixa Preta, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Técnicas de Teste: Caixa Preta** fundamenta-se em princípios consolidados de engenharia de software (O que é Teste de Caixa Preta?, Técnicas Principais, Simulando Entradas de Caixa Preta, Mini-Projeto). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Técnicas de Teste: Caixa Preta. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Técnicas de Teste: Caixa Preta** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Técnicas de Teste: Caixa Preta. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 07 Responder Quiz 07

🏋️ Exercício 08 – Técnicas de Teste: Caixa Branca ⚪

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 08 sobre Técnicas de Teste: Caixa Branca ⚪, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Técnicas de Teste: Caixa Branca ⚪, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Técnicas de Teste: Caixa Branca ⚪** fundamenta-se em princípios consolidados de engenharia de software (O que é Teste de Caixa Branca?, ️ Técnicas Principais, Cobertura na Prática, Mini-Projeto). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Técnicas de Teste: Caixa Branca ⚪. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Técnicas de Teste: Caixa Branca ⚪** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Técnicas de Teste: Caixa Branca ⚪. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 08 Responder Quiz 08

🏋️ Exercício 09 – Tipos de Testes Funcionais ✅

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 09 sobre Tipos de Testes Funcionais ✅, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Tipos de Testes Funcionais ✅, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Tipos de Testes Funcionais ✅** fundamenta-se em princípios consolidados de engenharia de software (Classificação dos Testes, Principais Tipos, Automatizando a Regressão, Mini-Projeto). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Tipos de Testes Funcionais ✅. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Tipos de Testes Funcionais ✅** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Tipos de Testes Funcionais ✅. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 09 Responder Quiz 09

🏋️ Exercício 10 – Testes Não Funcionais e Usabilidade

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 10 sobre Testes Não Funcionais e Usabilidade, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Testes Não Funcionais e Usabilidade, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Testes Não Funcionais e Usabilidade** fundamenta-se em princípios consolidados de engenharia de software (️ Além da Funcionalidade, Principais Categorias, Conceitos de UX para QAs, Monitorando Resposta de Sistema). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Testes Não Funcionais e Usabilidade. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Testes Não Funcionais e Usabilidade** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Testes Não Funcionais e Usabilidade. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 10 Responder Quiz 10

🏋️ Exercício 11 – Desenvolvimento Orientado por Testes (TDD)

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 11 sobre Desenvolvimento Orientado por Testes (TDD), cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Desenvolvimento Orientado por Testes (TDD), definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Desenvolvimento Orientado por Testes (TDD)** fundamenta-se em princípios consolidados de engenharia de software (O Ciclo do TDD, Por que usar TDD?, TDD no Terminal, Mini-Projeto). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Desenvolvimento Orientado por Testes (TDD). Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Desenvolvimento Orientado por Testes (TDD)** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Desenvolvimento Orientado por Testes (TDD). Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 11 Responder Quiz 11

🏋️ Exercício 12 – Testes Unitários e de Integração

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 12 sobre Testes Unitários e de Integração, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Testes Unitários e de Integração, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Testes Unitários e de Integração** fundamenta-se em princípios consolidados de engenharia de software (️ A Pirâmide de Testes, Estrutura AAA (Arrange, Act, Assert), Mocks e Dublês de Teste, Monitorando Cobertura Unitária). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Testes Unitários e de Integração. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Testes Unitários e de Integração** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Testes Unitários e de Integração. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 12 Responder Quiz 12

🏋️ Exercício 13 – Automação de Testes Web

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 13 sobre Automação de Testes Web, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Automação de Testes Web, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Automação de Testes Web** fundamenta-se em princípios consolidados de engenharia de software (️ Por que automatizar a Web?, ️ Ferramentas Populares, Localizando Elementos (Locators), Automação no Terminal). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Automação de Testes Web. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Automação de Testes Web** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Automação de Testes Web. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 13 Responder Quiz 13

🏋️ Exercício 14 – Testes de API

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 14 sobre Testes de API, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Testes de API, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Testes de API** fundamenta-se em princípios consolidados de engenharia de software (O que são APIs?, Conceitos Fundamentais HTTP, ️ Testando com Postman, Teste de API via Terminal (cURL)). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Testes de API. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Testes de API** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Testes de API. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 14 Responder Quiz 14

🏋️ Exercício 15 – Gestão de Defeitos e Ferramentas

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 15 sobre Gestão de Defeitos e Ferramentas, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Gestão de Defeitos e Ferramentas, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Gestão de Defeitos e Ferramentas** fundamenta-se em princípios consolidados de engenharia de software (O Ciclo de Vida de um Bug, ️ Ferramentas de Gestão (Jira), Rastreando Bugs no Console, Mini-Projeto). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Gestão de Defeitos e Ferramentas. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Gestão de Defeitos e Ferramentas** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Gestão de Defeitos e Ferramentas. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 15 Responder Quiz 15

🏋️ Exercício 16 – Projeto Integrador Final

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 16 sobre Projeto Integrador Final, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Projeto Integrador Final, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Projeto Integrador Final** fundamenta-se em princípios consolidados de engenharia de software (O Desafio Final, Escopo do Projeto, Estrutura de Entrega Esperada, Simulando a Validação Final). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Projeto Integrador Final. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Projeto Integrador Final** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Projeto Integrador Final. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 16 Responder Quiz 16

Projetos

🚀 Projetos do Curso

Lista completa das 20 unidades de projetos organizadas em 5 módulos didáticos.

Projeto 01: Auditoria de Qualidade Inicial 🔍

🎯 Objetivo

Realizar uma análise crítica de um site ou aplicativo popular sob a ótica de um QA, identificando possíveis falhas de lógica ou usabilidade.

🛠️ O que fazer

  1. Escolha um site simples (ex: um e-commerce local ou site de notícias).
  2. Navegue pelo fluxo principal (ex: buscar um produto e adicionar ao carrinho).
  3. Documente:
    • Cenário de Sucesso: O que deveria acontecer?
    • Pontos de Atenção: Algo demorou? Alguma mensagem foi confusa?
    • Identificação: Se você encontrasse um erro, ele seria um Erro, Defeito ou Falha?

📤 Entrega

Um documento curto (Markdown ou PDF) contendo a análise do fluxo escolhido e a classificação de pelo menos 2 potenciais problemas encontrados.

Projeto 02: Dashboard de Métricas 📊

🎯 Objetivo

Aplicar cálculos de maturidade e eficiência de defeitos em um cenário hipótetico de empresa.

🛠️ O que fazer

Imagine os seguintes dados de uma Sprint: - Defeitos encontrados pelo QA: 45 - Defeitos encontrados pelo Cliente em Produção: 5 - Total de linhas de código alteradas: 10.000 (10 KLOC)

Calcule: 1. DRE (Defect Removal Efficiency). 2. Densidade de Defeitos (Defeitos por KLOC). 3. Indique em qual nível do MPS.br (G ou F) esta empresa provavelmente se encontra, justificando com base na organização das métricas.

📤 Entrega

Um relatório com os cálculos realizados e a justificativa da maturidade sugerida.

Projeto 03: Canvas do STLC 🔄

🎯 Objetivo

Estruturar o Ciclo de Vida de Testes para uma funcionalidade nova.

🛠️ O que fazer

Funcionalidade: "Login via Biometria no App Bancário". 1. Análise: Liste 3 dúvidas que você enviaria para o PO (Dono do Produto) sobre este requisito. 2. Planejamento: Defina qual será o ambiente de teste necessário (Simuladores? Aparelhos reais?). 3. Desenvolvimento: Escreva o título de 3 Casos de Teste (1 positivo, 1 negativo, 1 de borda).

📤 Entrega

Um mapa mental ou lista estruturada seguindo as fases do STLC aplicadas ao login por biometria.

Projeto 04: Fábrica de Artefatos 📄

🎯 Objetivo

Criar documentação técnica profissional para um bug e um caso de teste.

🛠️ O que fazer

  1. Cenário: Ao tentar recuperar a senha, o usuário recebe o email, mas o link leva para uma página de erro 404.
  2. Tarefa A: Escreva o Bug Report completo (Título, Severidade, Prioridade, Passos, Resultado Esperado/Atual).
  3. Tarefa B: Escreva o Caso de Teste de Recuperação de Senha (com 5 passos detalhados).

📤 Entrega

Dois arquivos Markdown (um para o Bug e outro para o Caso de Teste) seguindo os padrões vistos em aula.

Projeto 05: Código Limpo, Teste Pronto ✨

🎯 Objetivo

Identificar "Code Smells" e propor melhorias que facilitem a criação de testes.

🛠️ O que fazer

Analise o código abaixo (Pseudocódigo): 

function processar() {
  let a = document.getElementById('v1').value;
  // Faz 50 linhas de cálculos matemáticos aqui...
  // Envia para o banco de dados direto daqui...
  alert('Salvo com sucesso');
}
1. Liste 2 problemas deste código sob a ótica do Clean Code. 2. Explique por que é difícil testar este método unitariamente. 3. Reescreva a estrutura (apenas os nomes das funções/módulos) de como você separaria esse código.

📤 Entrega

Relatório de análise e proposta de nova arquitetura modular.

Projeto 06: Minha Primeira Pipeline 🐙

🎯 Objetivo

Desenhar o fluxo de automação de um repositório Git.

🛠️ O que fazer

Desenhe (pode ser usando Mermaid ou texto) um Workflow do GitHub Actions que: 1. Dispare ao fazer um push na branch develop. 2. Execute em um container Ubuntu. 3. Tenha os seguintes passos: - Checkout do código. - Instalação de dependências. - Execução do Linter. - Execução de Testes Unitários. - Envio de notificação se falhar.

📤 Entrega

O arquivo .yml (mesmo que fictício) ou o diagrama do fluxo da pipeline.

Projeto 07: O Mestre da Caixa Preta 🌑

🎯 Objetivo

Aplicar técnicas de partição e limite em um sistema de regras de negócio.

🛠️ O que fazer

Sistema: Cálculo de IR (Imposto de Renda). - Isento: até R$ 2.000,00. - Alíquota 10%: de R$ 2.000,01 até R$ 5.000,00. - Alíquota 20%: acima de R$ 5.000,01.

  1. Defina as Partições de Equivalência (Válidas e Inválidas).
  2. Liste os Valores Limite para cada faixa.
  3. Crie uma pequena tabela com 5 entradas de teste e o resultado esperado.

📤 Entrega

Tabela de testes e definição das partições e limites.

Projeto 08: Por Dentro do Código ⚪

🎯 Objetivo

Analisar a lógica interna e garantir 100% de cobertura de decisão.

🛠️ O que fazer

Código a ser testado: 

def validar_cupom(codigo, valor_minimo):
    if codigo == "MOD11":
        if valor_minimo > 50:
            return "Desconto Aplicado"
        return "Valor insuficiente"
    return "Cupom inválido"
1. Desenhe o grafo de fluxo. 2. Quantos casos de teste são necessários para 100% de cobertura de Decisão? 3. Liste as entradas (codigo, valor_minimo) para cada caso.

📤 Entrega

Desenho do fluxo e lista de casos de teste estruturais.

Projeto 09: Estratégia de Regressão ✅

🎯 Objetivo

Definir um conjunto de testes de regressão para uma mudança de código.

🛠️ O que fazer

Cenário: Uma alteração foi feita no módulo de "Cálculo de Frete" de um e-commerce. 1. Liste os 5 fluxos mais críticos do sistema que você testaria em um Smoke Test após essa mudança. 2. Defina 3 cenários de Regressão específicos no módulo de carrinho de compras que podem ter sido afetados. 3. Escolha um cenário para um Teste Exploratório de 30 minutos e defina o seu objetivo (Charter).

📤 Entrega

Documento contendo a lista do Smoke Test, os cenários de Regressão e o objetivo do Teste Exploratório.

Projeto 10: Checkpoint de Usabilidade 🧠

🎯 Objetivo

Avaliar a experiência do usuário baseada em heurísticas.

🛠️ O que fazer

  1. Escolha um aplicativo de banco ou rede social.
  2. Tente realizar a tarefa: "Encontrar as configurações de privacidade".
  3. Avalie usando as Heurísticas de Nielsen:
    • O sistema deu feedback?
    • A linguagem era simples?
    • Foi fácil voltar para o início se você errasse o caminho?
  4. Sugira uma melhoria visual ou de fluxo.

📤 Entrega

Um relatório de usabilidade de uma página com os pontos positivos, negativos e a sugestão de melhoria.

Projeto 11: TDD na Prática 🔴🟢🔵

🎯 Objetivo

Exercitar o pensamento Red-Green-Refactor.

🛠️ O que fazer

Requisito: Criar um validador de senhas. - Regra: A senha deve ter no mínimo 8 caracteres. 1. Fase RED: Escreva como seria a chamada do teste unitário passando uma senha de 5 caracteres. Qual o erro esperado? 2. Fase GREEN: Escreva a função mínima para fazer esse teste passar. 3. Fase REFACTOR: Como você melhoraria o código se agora tivesse que validar também a presença de um número?

📤 Entrega

A sequência de pseudocódigo ou código (Python/JS) demonstrando os 3 passos do ciclo.

Projeto 12: Organizando com AAA 🔗

🎯 Objetivo

Estruturar um teste unitário profissional e identificar a necessidade de mocks.

🛠️ O que fazer

Cenário: Testar uma função enviar_notificacao(usuario_id) que busca o email no banco de dados e chama um serviço de email externo. 1. Escreva o teste usando as seções Arrange, Act e Assert. 2. Identifique quais partes do código devem ser substituídas por Mocks e explique o porquê. 3. Qual seria o seu "Assert" principal? (Ex: Verificar se a função de email foi chamada com os dados corretos).

📤 Entrega

Representação estruturada do teste (AAA) e a justificativa para o uso dos mocks.

Projeto 13: Roteiro de Automação 🤖

🎯 Objetivo

Planejar a automação de um fluxo de interface.

🛠️ O que fazer

Fluxo: "Esqueci minha senha". 1. Mapeie os seletores (ex: id, name) dos campos necessários. 2. Escreva o script (passo a passo) que o robô deve seguir. 3. Defina o ponto de verificação final (Assertion) que garante que o processo funcionou. 4. Crie um cenário de erro que o robô também deve testar (ex: email inválido).

📤 Entrega

Documento com o mapeamento de seletores e o fluxo lógico do robô de automação.

Projeto 14: API Master 📡

🎯 Objetivo

Documentar requisições e validações de uma API REST.

🛠️ O que fazer

API fictícia de Tarefas (To-do List): POST /tasks. 1. Defina o JSON de entrada (ex: título, descrição, status). 2. Liste 3 Status Codes que essa API pode retornar e em quais situações (ex: 201, 400, 401). 3. Escreva um pequeno script de teste (em texto) para validar se o campo "id" está presente na resposta.

📤 Entrega

A especificação técnica da requisição e a lista de validações de sucesso e erro.

Projeto 15: Gestor de Crises 🐛

🎯 Objetivo

Priorizar e gerenciar um backlog de defeitos críticos.

🛠️ O que fazer

Backlog de Bugs encontrados 2 dias antes do lançamento: - Bug A: Botão de ajuda com link quebrado (Severidade Baixa). - Bug B: Usuário consegue comprar sem ter saldo (Severidade Crítica). - Bug C: Site demora 10 segundos para abrir no iPhone (Severidade Média).

  1. Defina a Prioridade de correção (1, 2, 3) para cada um.
  2. Escreva um argumento para o PO (Dono do Produto) sobre por que o Bug B impede o lançamento do sistema.
  3. Desenhe o ciclo de vida que esse Bug B percorrerá desde a abertura até o fechamento.

📤 Entrega

Plano de ação para os bugs e justificativa técnica da priorização.

Projeto 16: Portfólio de QA 🎓

🎯 Objetivo

Consolidar todas as entregas do curso em um único repositório de portfólio.

🛠️ O que fazer

  1. Crie um arquivo README.md principal para o seu portfólio de estudos.
  2. Organize os links para os mini-projetos mais importantes que você realizou (ex: Projeto 04, Projeto 11, Projeto 14).
  3. Escreva um parágrafo sobre qual área de QA você mais se identifica (Manual, Automação, Performance ou Segurança) e por quê.

📤 Entrega

O link (ou o conteúdo) do seu README de portfólio consolidando sua jornada no curso.

Quizzes

🧠 Quizzes de Fixação

Lista completa das 20 unidades de quizzes organizadas em 5 módulos didáticos.

🧠 Quiz 01 – Qualidade de Software e Papel do QA 🧐

  1. Qual é o conceito fundamental e objetivo principal de Qualidade de Software e Papel do QA 🧐?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Qualidade de Software e Papel do QA 🧐?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Qualidade de Software e Papel do QA 🧐, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Qualidade de Software e Papel do QA 🧐?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Qualidade de Software e Papel do QA 🧐 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Qualidade de Software e Papel do QA 🧐, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Qualidade de Software e Papel do QA 🧐?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Qualidade de Software e Papel do QA 🧐 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Qualidade de Software e Papel do QA 🧐 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Qualidade de Software e Papel do QA 🧐 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 02 – Modelos de Qualidade de Software 📊

  1. Qual é o conceito fundamental e objetivo principal de Modelos de Qualidade de Software 📊?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Modelos de Qualidade de Software 📊?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Modelos de Qualidade de Software 📊, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Modelos de Qualidade de Software 📊?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Modelos de Qualidade de Software 📊 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Modelos de Qualidade de Software 📊, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Modelos de Qualidade de Software 📊?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Modelos de Qualidade de Software 📊 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Modelos de Qualidade de Software 📊 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Modelos de Qualidade de Software 📊 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 03 – Ciclo de Vida de Testes (STLC) 🔄

  1. Qual é o conceito fundamental e objetivo principal de Ciclo de Vida de Testes (STLC) 🔄?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Ciclo de Vida de Testes (STLC) 🔄?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Ciclo de Vida de Testes (STLC) 🔄, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Ciclo de Vida de Testes (STLC) 🔄?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Ciclo de Vida de Testes (STLC) 🔄 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Ciclo de Vida de Testes (STLC) 🔄, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Ciclo de Vida de Testes (STLC) 🔄?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Ciclo de Vida de Testes (STLC) 🔄 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Ciclo de Vida de Testes (STLC) 🔄 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Ciclo de Vida de Testes (STLC) 🔄 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 04 – Documentação e Controle de Testes 📄

  1. Qual é o conceito fundamental e objetivo principal de Documentação e Controle de Testes 📄?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Documentação e Controle de Testes 📄?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Documentação e Controle de Testes 📄, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Documentação e Controle de Testes 📄?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Documentação e Controle de Testes 📄 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Documentação e Controle de Testes 📄, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Documentação e Controle de Testes 📄?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Documentação e Controle de Testes 📄 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Documentação e Controle de Testes 📄 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Documentação e Controle de Testes 📄 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 05 – Melhores Práticas de Programação ✨

  1. Qual é o conceito fundamental e objetivo principal de Melhores Práticas de Programação ✨?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Melhores Práticas de Programação ✨?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Melhores Práticas de Programação ✨, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Melhores Práticas de Programação ✨?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Melhores Práticas de Programação ✨ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Melhores Práticas de Programação ✨, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Melhores Práticas de Programação ✨?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Melhores Práticas de Programação ✨ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Melhores Práticas de Programação ✨ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Melhores Práticas de Programação ✨ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 06 – Controle de Versão e CI 🐙

  1. Qual é o conceito fundamental e objetivo principal de Controle de Versão e CI 🐙?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Controle de Versão e CI 🐙?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Controle de Versão e CI 🐙, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Controle de Versão e CI 🐙?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Controle de Versão e CI 🐙 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Controle de Versão e CI 🐙, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Controle de Versão e CI 🐙?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Controle de Versão e CI 🐙 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Controle de Versão e CI 🐙 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Controle de Versão e CI 🐙 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 07 – Técnicas de Teste: Caixa Preta 🌑

  1. Qual é o conceito fundamental e objetivo principal de Técnicas de Teste: Caixa Preta 🌑?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Técnicas de Teste: Caixa Preta 🌑?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Técnicas de Teste: Caixa Preta 🌑, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Técnicas de Teste: Caixa Preta 🌑?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Técnicas de Teste: Caixa Preta 🌑 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Técnicas de Teste: Caixa Preta 🌑, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Técnicas de Teste: Caixa Preta 🌑?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Técnicas de Teste: Caixa Preta 🌑 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Técnicas de Teste: Caixa Preta 🌑 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Técnicas de Teste: Caixa Preta 🌑 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 08 – Técnicas de Teste: Caixa Branca ⚪

  1. Qual é o conceito fundamental e objetivo principal de Técnicas de Teste: Caixa Branca ⚪?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Técnicas de Teste: Caixa Branca ⚪?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Técnicas de Teste: Caixa Branca ⚪, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Técnicas de Teste: Caixa Branca ⚪?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Técnicas de Teste: Caixa Branca ⚪ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Técnicas de Teste: Caixa Branca ⚪, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Técnicas de Teste: Caixa Branca ⚪?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Técnicas de Teste: Caixa Branca ⚪ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Técnicas de Teste: Caixa Branca ⚪ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Técnicas de Teste: Caixa Branca ⚪ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 09 – Tipos de Testes Funcionais ✅

  1. Qual é o conceito fundamental e objetivo principal de Tipos de Testes Funcionais ✅?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Tipos de Testes Funcionais ✅?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Tipos de Testes Funcionais ✅, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Tipos de Testes Funcionais ✅?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Tipos de Testes Funcionais ✅ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Tipos de Testes Funcionais ✅, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Tipos de Testes Funcionais ✅?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Tipos de Testes Funcionais ✅ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Tipos de Testes Funcionais ✅ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Tipos de Testes Funcionais ✅ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 10 – Testes Não Funcionais e Usabilidade 🧠

  1. Qual é o conceito fundamental e objetivo principal de Testes Não Funcionais e Usabilidade 🧠?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Testes Não Funcionais e Usabilidade 🧠?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Testes Não Funcionais e Usabilidade 🧠, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Testes Não Funcionais e Usabilidade 🧠?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Testes Não Funcionais e Usabilidade 🧠 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Testes Não Funcionais e Usabilidade 🧠, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Testes Não Funcionais e Usabilidade 🧠?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Testes Não Funcionais e Usabilidade 🧠 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Testes Não Funcionais e Usabilidade 🧠 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Testes Não Funcionais e Usabilidade 🧠 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 11 – Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵

  1. Qual é o conceito fundamental e objetivo principal de Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Desenvolvimento Orientado por Testes (TDD) 🔴🟢🔵 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 12 – Testes Unitários e de Integração 🔗

  1. Qual é o conceito fundamental e objetivo principal de Testes Unitários e de Integração 🔗?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Testes Unitários e de Integração 🔗?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Testes Unitários e de Integração 🔗, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Testes Unitários e de Integração 🔗?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Testes Unitários e de Integração 🔗 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Testes Unitários e de Integração 🔗, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Testes Unitários e de Integração 🔗?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Testes Unitários e de Integração 🔗 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Testes Unitários e de Integração 🔗 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Testes Unitários e de Integração 🔗 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 13 – Automação de Testes Web 🤖

  1. Qual é o conceito fundamental e objetivo principal de Automação de Testes Web 🤖?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Automação de Testes Web 🤖?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Automação de Testes Web 🤖, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Automação de Testes Web 🤖?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Automação de Testes Web 🤖 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Automação de Testes Web 🤖, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Automação de Testes Web 🤖?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Automação de Testes Web 🤖 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Automação de Testes Web 🤖 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Automação de Testes Web 🤖 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 14 – Testes de API 📡

  1. Qual é o conceito fundamental e objetivo principal de Testes de API 📡?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Testes de API 📡?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Testes de API 📡, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Testes de API 📡?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Testes de API 📡 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Testes de API 📡, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Testes de API 📡?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Testes de API 📡 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Testes de API 📡 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Testes de API 📡 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 15 – Gestão de Defeitos e Ferramentas 🐛

  1. Qual é o conceito fundamental e objetivo principal de Gestão de Defeitos e Ferramentas 🐛?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Gestão de Defeitos e Ferramentas 🐛?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Gestão de Defeitos e Ferramentas 🐛, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Gestão de Defeitos e Ferramentas 🐛?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Gestão de Defeitos e Ferramentas 🐛 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Gestão de Defeitos e Ferramentas 🐛, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Gestão de Defeitos e Ferramentas 🐛?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Gestão de Defeitos e Ferramentas 🐛 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Gestão de Defeitos e Ferramentas 🐛 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Gestão de Defeitos e Ferramentas 🐛 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 16 – Projeto Integrador Final 🎓

  1. Qual é o conceito fundamental e objetivo principal de Projeto Integrador Final 🎓?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Projeto Integrador Final 🎓?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Projeto Integrador Final 🎓, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Projeto Integrador Final 🎓?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Projeto Integrador Final 🎓 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Projeto Integrador Final 🎓, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Projeto Integrador Final 🎓?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Projeto Integrador Final 🎓 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Projeto Integrador Final 🎓 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Projeto Integrador Final 🎓 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 17 – Testes de Carga, Estresse e Performance 🚀

  1. Qual o propósito principal de Testes de Carga, Estresse e Performance 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Testes de Carga, Estresse e Performance 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Testes de Carga, Estresse e Performance 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Testes de Carga, Estresse e Performance 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Testes de Carga, Estresse e Performance 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Testes de Carga, Estresse e Performance 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Testes de Carga, Estresse e Performance 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Testes de Carga, Estresse e Performance 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Testes de Carga, Estresse e Performance 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Testes de Carga, Estresse e Performance 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 18 – Testes de Contrato de APIs e Schema-First 🚀

  1. Qual o propósito principal de Testes de Contrato de APIs e Schema-First 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Testes de Contrato de APIs e Schema-First 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Testes de Contrato de APIs e Schema-First 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Testes de Contrato de APIs e Schema-First 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Testes de Contrato de APIs e Schema-First 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Testes de Contrato de APIs e Schema-First 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Testes de Contrato de APIs e Schema-First 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Testes de Contrato de APIs e Schema-First 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Testes de Contrato de APIs e Schema-First 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Testes de Contrato de APIs e Schema-First 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 19 – Testes de Regressão Visual e Automação E2E 🚀

  1. Qual o propósito principal de Testes de Regressão Visual e Automação E2E 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Testes de Regressão Visual e Automação E2E 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Testes de Regressão Visual e Automação E2E 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Testes de Regressão Visual e Automação E2E 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Testes de Regressão Visual e Automação E2E 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Testes de Regressão Visual e Automação E2E 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Testes de Regressão Visual e Automação E2E 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Testes de Regressão Visual e Automação E2E 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Testes de Regressão Visual e Automação E2E 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Testes de Regressão Visual e Automação E2E 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 20 – Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀

  1. Qual o propósito principal de Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Projeto Capstone: Suíte Autônoma de Qualidade de Software 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

Slides

Configuração

Ambientes de Desenvolvimento 🛠️

Guias para configurar seu computador para automação de testes e garantia de qualidade.

Setup 01: Selenium & WebDriver 🤖

O Selenium é o padrão de mercado para automação de navegadores web. Nele, usamos o WebDriver para controlar o navegador.

1. Instalando o Selenium (Python)

Se você estiver usando Python, instale via pip: 

pip install selenium

2. WebDrivers (Navegadores)

Para que o código consiga "clicar" no navegador, você precisa do driver correspondente:

3. Gestão Automática de Drivers

A melhor prática hoje é usar bibliotecas que gerenciam os drivers para você:

from selenium import webdriver
from selenium.webdriver.chrome.service import Service as ChromeService
from webdriver_manager.chrome import ChromeDriverManager

driver = webdriver.Chrome(service=ChromeService(ChromeDriverManager().install()))

4. Playwright (Alternativa Moderna)

Se preferir usar o Playwright (muito comum em JS/TS e Python): 

pip install playwright
playwright install

5. Solução de Problemas ⚠️

  • Drivers Desatualizados: Sempre garanta que a versão do seu navegador (Chrome) é a mesma da versão do driver (ChromeDriver).
  • Path: Se não usar o manager, o executável do driver deve estar no PATH do sistema.

Setup 02: Testes de API (Postman & Insomnia) 📡

Para testar o backend e os endpoints do sistema, precisamos de clientes de API robustos.

1. Postman

O Postman é a ferramenta mais completa para gestão de coleções de API e automação de testes contratuais.

  • Download: postman.com/downloads.
  • Principais Funções:
    • Criação de Ambientes (Environments).
    • Scripts de testes em JavaScript.
    • Runner de coleções.

2. Insomnia

Uma alternativa leve e focada em design, excelente para testes rápidos e suporte nativo a GraphQL e gRPC.

3. Newman (CLI para Postman)

Para rodar seus testes do Postman em pipelines de CI/CD: 

npm install -g newman

4. Dica de Produtividade 🚀

Sempre documente o base_url em uma variável de ambiente no Postman. Assim, você alterna entre http://localhost:3000 (desenvolvimento) e https://api.empresa.com (produção) com apenas um clique.

5. Solução de Problemas ⚠️

  • Erro de SSL: Se estiver testando em ambiente local com HTTPS sem certificado válido, desabilite a "SSL Certificate Verification" nas configurações da ferramenta.
  • CORS: Alguns navegadores barram requisições, mas ferramentas como Postman e Insomnia ignoram regras de CORS, facilitando os testes.

Setup 03: Python para QA 🐍

O Python é uma das linguagens mais amigáveis para quem está começando na automação de testes.

1. Instalando o Python

  1. Baixe a versão mais recente em python.org.
  2. IMPORTANTE: Marque a caixa "Add Python to PATH" na instalação!
  3. Teste no terminal: python --version.

2. Ambientes Virtuais (VENV)

Sempre crie ambientes isolados para seus projetos de teste para evitar conflitos de bibliotecas: 

python -m venv venv
source venv/bin/activate  # Linux/Mac
.\venv\Scripts\activate   # Windows

3. Gerenciando Dependências (PIP)

Use o pip para instalar bibliotecas como pytest, selenium e behave (BDD): 

pip install pytest selenium behave

4. PyTest (O Framework de Escolha)

O PyTest é o padrão para testes em Python. Crie um arquivo test_exemplo.py e rode: 

pytest

5. Solução de Problemas ⚠️

  • 'python' não encontrado: Certifique-se de que o PATH foi configurado corretamente.
  • Permissão no Windows: Se não conseguir ativar o venv, rode Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser no PowerShell (como Admin).

Setup 04: Java & Maven para QA ☕

O ecossistema Java é muito forte em empresas enterprise para automação com Selenium e RestAssured.

1. JDK (Java Development Kit)

  1. Baixe o JDK 17 ou 21 (LTS) no site da Oracle ou Adoptium.
  2. Configure a variável JAVA_HOME.

2. Apache Maven

O Maven é o gestor de dependências padrão para projetos Java. 1. Baixe em maven.apache.org. 2. Adicione a pasta bin ao seu PATH. 3. Teste: mvn -version.

3. IntelliJ IDEA (Comunidade)

Excelente suporte para refatoração e execução de testes JUnit/TestNG. 1. Baixe a versão Community em jetbrains.com/idea.

4. Dependências de QA comuns (pom.xml)

No seu projeto Maven, você geralmente incluirá: - selenium-java - junit-jupiter - rest-assured

5. Solução de Problemas Comuns ⚠️

  • Erro de Compilação: Verifique se a versão do JDK no IntelliJ está alinhada com a do seu sistema.
  • Maven não baixa pacotes: Pode ser problema de Proxy da empresa ou rede. Verifique seu arquivo settings.xml.

Setup 05: Node.js & Playwright / Cypress 🟢

O ecossistema JavaScript/TypeScript é hoje um dos mais populares para automação de testes "Shift Left".

1. Instalando o Node.js

  1. Baixe a versão LTS (Long Term Support) em nodejs.org.
  2. Teste: node -v e npm -v.

2. Playwright (O sucessor do Selenium)

Moderno, rápido e com suporte nativo a execução paralela. 

npm init playwright@latest

3. Cypress (Focado em Desenvolvedores)

Excelente para testes E2E com uma interface visual incrível. 

npm install cypress --save-dev
npx cypress open

4. TypeScript (Recomendado)

Para automação robusta, prefira TypeScript ao invés de JS puro para ter autocompletar e tipagem nos seus seletores.

5. Solução de Problemas Comuns ⚠️

  • npm ERR!: Tente limpar o cache: npm cache clean --force.
  • npx não funciona: Verifique se o Node foi instalado com permissões de administrador.

Setup 06: VS Code para QA 💻

O Visual Studio Code é o editor de texto mais versátil para quem trabalha com múltiplos frameworks de automação.

1. Extensões Essenciais para QA

Abra o VS Code (Ctrl+Shift+X) e instale: - Python: Suporte completo para scripts. - Python Test Explorer: Interface visual para PyTest. - Playwright Test: Execute testes do Playwright direto no editor. - Thunder Client: Alternativa ao Postman dentro do VS Code.

2. Snippets e Produtividade

Configure atalhos para gerar estruturas de casos de teste Markdown ou blocos de código Selenium rapidamente.

3. Terminal Integrado

Use o terminal do VS Code (Ctrl+') para rodar seus testes sem trocar de janela.

4. Git Integrado

Use a aba de "Source Control" para dar commit e push nos seus scripts de teste para o GitHub.

5. Solução de Problemas ⚠️

  • Editor Lento: Desabilite extensões que você não está usando no momento. QA costuma ter muitas e isso consome RAM.

Setup 07: Git & GitHub 🐙

Versionamento de código é o que separa um testador manual de um QA Automation profissional.

1. Instalando o Git

  1. Baixe em git-scm.com.
  2. Configure sua identidade: 
    git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

2. GitHub Acadêmico

Crie uma conta no GitHub para hospedar seus repositórios de estudo e portfólio de automação.

3. GitHub Desktop (Opcional)

Se preferir uma interface visual ao invés do terminal: 1. Baixe em desktop.github.com.

4. Workflow de QA

Sempre crie branches para novos testes: git checkout -b feature/testes-login

5. Solução de Problemas ⚠️

  • Erro de Autenticação: Use o GitHub CLI ou configure chaves SSH para não precisar digitar senha a todo momento.
  • Conflitos: Se o "Merge" falhar, use o VS Code para resolver os conflitos de linha por linha.

Setup 08: Docker para QA 🐳

O Docker permite rodar ambientes inteiros (Bancos, APIs, Selenium Grid) sem sujar sua máquina local.

1. Docker Desktop

  1. Baixe em docker.com/products/docker-desktop.
  2. IMPORTANTE: No Windows, certifique-se de que o WSL 2 está instalado e ativo.

2. Selenium Grid em Container

Para rodar testes em paralelo em diferentes navegadores: 

docker run -d -p 4444:4444 --name selenium-grid selenium/standalone-chrome

3. Docker Compose

Use arquivos docker-compose.yml para subir seu app + banco de dados para testes em um único comando.

4. Limpeza

Para não ficar sem espaço em disco: docker system prune

5. Solução de Problemas ⚠️

  • Engine not running: Verifique se o ícone da baleia está verde na barra de tarefas.
  • Falta de RAM: O Docker consome bastante memória. Aumente o limite nas configurações do Docker Desktop se os containers caírem.

Setup 09: Bancos de Dados para QA 🗄️

Saber manipular dados é vital para criar massas de teste e verificar a persistência.

1. DBeaver (Ferramenta Universal)

A melhor ferramenta para conectar em qualquer banco (SQL, NoSQL). 1. Baixe em dbeaver.io.

2. SQLite (Para Estudos)

Leve e não exige instalação de servidor. Ótimo para treinar SELECT, INSERT e DELETE.

3. PostgreSQL / MySQL

Os bancos mais comuns no mercado. Você pode rodá-los via Docker (conforme vimos no Setup 08).

4. Verificação de Dados

Sempre compare o que o seu teste automatizado diz com o que está gravado no banco de dados.

5. Solução de Problemas ⚠️

  • Erro de Driver: O DBeaver baixa os drivers automaticamente, mas você precisa de internet na primeira conexão de cada tipo de banco.
  • Query Lenta: Verifique se o banco não está bloqueado por outra transação (Deadlock).

Sobre

Sobre o Curso

🎓 Excelência em Qualidade e Testes de Software

Este curso foi projetado para transformar desenvolvedores e aspirantes a QA em especialistas em garantia de qualidade, focando em processos modernos, automação e mentalidade ágil.

🎯 Objetivos do Curso

  • Mentalidade de Qualidade --- Compreender que qualidade não é uma fase, mas um processo contínuo integrado ao desenvolvimento.

  • Domínio de Testes --- Dominar técnicas estatutárias e dinâmicas de teste, desde unitários até testes de fim-a-fim.

  • Especialista em Automação --- Criar suítes de testes automatizados que reduzem o esforço manual e aumentam a confiabilidade do código.

  • Cultura TDD --- Aprender a pensar no comportamento antes da implementação, garantindo códigos limpos e testáveis.

📚 O Que Você Vai Aprender

Módulo 1 – Fundamentos e Modelos

  • Qualidade de Software e o papel estratégico do QA
  • Modelos de Maturidade: CMMI e MPS.br
  • Ciclo de Vida de Testes (STLC)
  • Planejamento e Documentação Formal

Módulo 2 – Melhores Práticas e Técnicas

  • Clean Code e Refatoração para Testabilidade
  • Técnicas de Caixa Preta (Equivalência, Limites)
  • Técnicas de Caixa Branca (Fluxo, Cobertura)
  • Integração Contínua (CI) com Testes

Módulo 3 – TDD e Tipos de Teste

  • O Ciclo Red-Green-Refactor
  • Testes Funcionais vs Não Funcionais
  • Testes de Regressão e Aceitação
  • Testes de Usabilidade (UX) e Carga

Módulo 4 – Automação e Gestão

  • Selenium e Playwright para Web
  • Automação de APIs com Postman
  • Gestão de Defeitos com Jira
  • Projeto Integrador de Finalização

🛠️ Metodologia

Foco em Hands-on. Cada aula contém teoria fundamentada seguida por exercícios práticos e um mini-projeto. O objetivo é que você saia com uma base sólida para atuar como QA ou como um Software Engineer in Test (SDET).

Pronto para garantir a qualidade? Começar Agora

Materiais 📚

Bem-vindo à seção de materiais complementares do curso. Aqui você encontra recursos adicionais para apoiar seus estudos e aprofundar seus conhecimentos em Qualidade e Testes de Software.

  • Slides

    • Acesse os slides de todas as aulas (Reveal.js) para revisão.

  • Exercícios

    • Pratique com listas de exercícios e confira as soluções.

  • Quizzes

    • Teste seus conhecimentos com quizzes interativos por módulo.

  • Projetos

    • Desenvolva projetos práticos e o Projeto Integrador Final.

  • Setup

    • Guias de instalação e configuração das ferramentas de QA.

📖 Referências Recomendadas

Para quem deseja ir além dos slides e aulas práticas:

  • Clean Code (Robert C. Martin)
  • Test Driven Development: By Example (Kent Beck)
  • ISTQB Foundation Level (Manual Oficial)

Tip

Utilize estes materiais para complementar o estudo de cada aula. A área de testes exige constante atualização!

🏷️ Índice de Tags Didáticas

Navegue pelas aulas, exercícios e projetos do curso organizados por temas, tecnologias e conceitos fundamentais:

tags.md:145-167/name

Versão para Impressão

Esta página foi gerada automaticamente para impressão.