Update CTFL documentation: change tags to stageB and fix grammar issues

Author: Gabriel Laureano

docs/istqb/ctfl/README.mdx

@@ -8,7 +8,7 @@ draft: false
 
 # Certified Tester Foundation Level
 
-CTFL é uma certificação reconhecida internacionalmente para profissionais de qualidade de software e teste de software. É oferecida pela ISTQB (International Software Testing Qualifications Board) e é considerada um padrão de base na indústria de testes de software.
+CTFL é uma certificação reconhecida internacionalmente para profissionais de qualidade de software e teste de software. É oferecida pela ISTQB (International Software Testing Qualifications Board) e é considerada um padrão básico na indústria de testes de software.
 É a primeira certificação da ISTQB e é um pré-requisito para outras certificações mais avançadas, como CTAL e CTAL-TAE. 
 
 A seguir, você encontrará a documentação criada como resumo de estudo para a certificação CTFL.
@@ -18,38 +18,38 @@ Consegui a certificação CTFL em 30/08/2024 e resolvi compartilhar o material q
 
 ### Capítulos
 
-- [Capitulo 1: Fundamentos de Teste](./ctfl/ctfl_01)
-- [Capitulo 2: Testes no SDLC](./ctfl/ctfl_02)
-- [Capitulo 3: Teste Estático](./ctfl/ctfl_03)
-- [Capitulo 4: Técnicas de Teste](./ctfl/ctfl_04)
-- [Capitulo 5: Gerenciamento de Teste](./ctfl/ctfl_05)
-- [Capitulo 6: Ferramentas de Teste](./ctfl/ctfl_06)
+- [Capítulo 1: Fundamentos de Teste](./ctfl/ctfl_01)
+- [Capítulo 2: Testes no SDLC](./ctfl/ctfl_02)
+- [Capítulo 3: Teste Estático](./ctfl/ctfl_03)
+- [Capítulo 4: Técnicas de Teste](./ctfl/ctfl_04)
+- [Capítulo 5: Gerenciamento de Teste](./ctfl/ctfl_05)
+- [Capítulo 6: Ferramentas de Teste](./ctfl/ctfl_06)
 
 ### Fluxo de Estudo
 
 ```mermaid
 timeline
 	title Timeline de Estudo
 	section Primeira Parte
-		Capitulo 1
+		Capítulo 1
 			: K1, K2
 			: Fundamentos de Teste
-		Capitulo 2
+		Capítulo 2
 			: K1, K2
 			: Testes no SDLC
-		Capitulo 3
+		Capítulo 3
 			: K1, K2
 			: Teste Estático
-		Capitulo 4
+		Capítulo 4
 			: K2, K3
 			: Técnicas de Teste
 	section Segunda Parte
 		Aplicação
 			: Aplicação de Técnicas de Teste
-		Capitulo 5
+		Capítulo 5
 			: K1, K2, K3
 			: Gerenciamento de Teste
-		Capitulo 6
+		Capítulo 6
 			: K1, K2
 			: Ferramentas de Teste
 		Revisão
@@ -62,9 +62,9 @@ timeline
 
 ### Referências
 
-- Syllabus CTFL 4.0 (BSTQB pt_BR) — Utilizado para a criação deste material.
-- Syllabus CTFL 4.0 (ISTQB en) — Documento oficial da ISTQB, utilizada para desambiguação de termos.
-- MermaidJS — Utilizado para a criação de diagramas no markdown.
+- Syllabus CTFL 4.0 (BSTQB pt_BR) — Utilizado para a criação deste material;
+- Syllabus CTFL 4.0 (ISTQB en) — Documento oficial da ISTQB, utilizado para desambiguação de termos;
+- MermaidJS — Utilizado para a criação de diagramas no markdown;
 - As demais bibliografias já estão referenciadas adequadamente nos Syllabus.
 
 ---

docs/istqb/ctfl/ctfl_01.mdx

@@ -2,7 +2,7 @@
 sidebar_position: 1
 title: Capítulo 1
 description: CTFL - Capítulo 1 - Fundamentos de Teste
-tags: [stageA, istqb, ctfl, capitulo]
+tags: [stageB, istqb, ctfl, capitulo]
 draft: false
 ---
 

docs/istqb/ctfl/ctfl_02.mdx

@@ -2,7 +2,7 @@
 sidebar_position: 1
 title: Capítulo 2
 description: CTFL - Capítulo 2 - Testes ao longo do Ciclo de Vida de Desenvolvimento de Software
-tags: [stageA, istqb, ctfl, capitulo]
+tags: [stageB, istqb, ctfl, capitulo]
 draft: false
 ---
 
@@ -49,7 +49,7 @@ Os testes gerados podem ser mantidos como garantia de qualidade durante uma refa
 
 ### 2.1.4 DevOps e Testes
 
-DevOps é a cultura de entregar dinamicidade entre o desenvolvimento e a infraestrutura.
+DevOps é a cultura de entregar dinamismo entre o desenvolvimento e a infraestrutura.
 
 Com o DevOps, os testes (automatizados) podem ser incorporados à rotina de desenvolvimento.
 

docs/istqb/ctfl/ctfl_03.mdx

@@ -2,7 +2,7 @@
 sidebar_position: 1
 title: Capítulo 3
 description: CTFL - Capítulo 3 - Teste Estático
-tags: [stageA, istqb, ctfl, capitulo]
+tags: [stageB, istqb, ctfl, capitulo]
 draft: false
 ---
 
@@ -17,10 +17,10 @@ Podem identificar problemas antes dos testes dinâmicos.
 ### 3.1.1 Produtos de trabalho examináveis por testes estáticos
 
 - Testes estáticos são executados em produtos como:
-	- User stories, DoR e Requisitos;
+	- User stories, DoR e requisitos;
 	- Código;
-	- Planos de Teste;
-	- Documentação de Projeto;
+	- Planos de teste;
+	- Documentação de projeto;
 	- etc.
 
 Qualquer produto de trabalho que possa ser lido é um objeto de revisão.
@@ -33,17 +33,17 @@ Defeitos de código são menos custosos se identificados na análise estática.
 
 ### 3.1.3 Diferenças entre testes estáticos e testes dinâmicos
 
-Estáticos e Dinâmicos se complementam.
+Estáticos e dinâmicos se complementam.
 
 Alguns defeitos são exclusivamente descobertos em um deles.
 
 - Defeitos comuns encontrados no ESTÁTICO:
-	- Defeitos de Requisitos;
-	- Defeitos de Projeto;
-	- Defeitos de Código;
-	- Desvios de Padrão;
-	- Vulnerabilidades de Segurança;
-	- Lacunas de Cobertura.
+	- Defeitos de requisitos;
+	- Defeitos de projeto;
+	- Defeitos de código;
+	- Desvios de padrão;
+	- Vulnerabilidades de segurança;
+	- Lacunas de cobertura.
 
 ### 3.2 Processo de feedback e revisão
 
@@ -54,28 +54,28 @@ Esse feedback evita desentendimentos.
 
 ### 3.2.2 Atividades do processo de revisão
 
-- Processo de Revisão:
+- Processo de revisão:
 	- Planejamento: escopo da revisão;
-	- Início da Revisão: garantir a preparação dos participantes;
-	- Revisão Individual: cada revisor avalia o produto de trabalho;
-	- Comunicação e Análise de Problemas: ações de acompanhamento necessárias;
-	- Correção e Relatório: cada defeito resulta em um relatório e ação corretiva.
+	- Início da revisão: garantir a preparação dos participantes;
+	- Revisão individual: cada revisor avalia o produto de trabalho;
+	- Comunicação e análise de problemas: ações de acompanhamento necessárias;
+	- Correção e relatório: cada defeito resulta em um relatório e ação corretiva.
 
 ### 3.2.3 Funções e responsabilidades nas revisões
 
-Responsabilidades na Revisão:
+Responsabilidades na revisão:
 
 - Gerente: decide o que deve ser revisado;
 - Autor: cria e corrige o trabalho;
 - Moderador: garante o andamento eficaz das reuniões;
 - Relator: reúne as anomalias e registra as informações;
-- Líder da Revisão: responsável geral pela revisão.
+- Líder da revisão: responsável geral pela revisão.
 
 ### 3.2.4 Tipos de revisão
 
-- Revisão Informal: não segue um processo definido;
+- Revisão informal: não segue um processo definido;
 - Walkthrough: passo a passo conduzido pelo autor;
-- Revisão Técnica: revisores qualificados analisam;
+- Revisão técnica: revisores qualificados analisam;
 - Inspeção: mais formal, processo genérico completo.
 
 ### 3.2.5 Fatores de sucesso para revisões

docs/istqb/ctfl/ctfl_04.mdx

@@ -2,7 +2,7 @@
 sidebar_position: 1
 title: Capítulo 4
 description: CTFL - Capítulo 4 - Análise e Modelagem de Teste
-tags: [stageA, istqb, ctfl, capitulo]
+tags: [stageB, istqb, ctfl, capitulo]
 draft: false
 ---
 
@@ -11,48 +11,48 @@ draft: false
 ### 4.1 Visão geral das técnicas de teste
 
 - Técnicas de Teste Caixa-Preta
-	- Analisa o comportamento do objeto de teste
+	- Analisam o comportamento do objeto de teste.
 - Técnicas de Teste Caixa-Branca
-	- Analisa a estrutura interna do objeto de teste
+	- Analisam a estrutura interna do objeto de teste.
 - Técnicas de Teste Baseada na Experiência
-	- Usa o conhecimento e experiência do testador
+	- Usam o conhecimento e a experiência do testador.
 
 ### 4.2 Técnicas de Teste Caixa-Preta
 
 ### 4.2.1 Particionamento de Equivalência (EP)
 
-Divide os dados em partes para serem testados.
+Divide os dados em partes para serem testadas.
 
-Cada partição de dados é agrupada de forma que possam ser testadas com o mesmo processo.
+Cada partição de dados é agrupada de forma que possa ser testada com o mesmo processo.
 
 - Dados que podem ser agrupados:
 	- Input
 	- Output
 	- Valores Internos
 	- Parâmetros de Interface
 
-Compreender como os dados são processos é complicado.
+Compreender como os dados são processados é complicado.
 
 Usar o particionamento com cuidado.
 
 A cobertura é feita validando cada partição com pelo menos um caso de uso.
 
 ### 4.2.2 Análise de Valor de Limite (BVA)
 
-BVA (Boundary Value Analysis) se concentra nos valores limites.
+BVA (Boundary Value Analysis) se concentra nos valores-limite.
 
-- BVA de 2 Valores: é validado todos os dois limites da partição
-	- Exemplo: `00-01|10-11|20-21|30-31|`
-- BVA de 3 Valores: é validado todos os dois limites da partição e seu vizinhos
-	- Exemplo: `00-01|09-10-11|19-20-21|29-30-31|`
+- BVA de 2 Valores: são validados os dois limites da partição:
+	- Exemplo: `00-01|10-11|20-21|30-31|`.
+- BVA de 3 Valores: são validados os dois limites da partição e seus vizinhos:
+	- Exemplo: `00-01|09-10-11|19-20-21|29-30-31|`.
 
 ### 4.2.3 Teste de Tabela de Decisão
 
-Usada para testar combinações de requisitos do sistema.
+Usado para testar combinações de requisitos do sistema.
 
-É gerada uma tabela de requisitos em que cada coluna é um req e ações associadas.
+É gerada uma tabela de requisitos em que cada coluna é um requisito e ações associadas.
 
-Age como a "tabela verdade" de lógica computacional.
+Age como a "tabela verdade" da lógica computacional.
 
 Na tabela, todas as decisões são desenhadas.
 
@@ -82,96 +82,97 @@ stateDiagram
 
 ```
 
-- Cobertura
-	- Cobertura de Todos os Estados
-	- Cobertura de Transições Válidas
-	- Cobertura de Todas as Transições
+- Cobertura:
+	- Cobertura de Todos os Estados;
+	- Cobertura de Transições Válidas;
+	- Cobertura de Todas as Transições.
 
 ### 4.3 Técnicas de Teste Caixa-Branca
 
 ### 4.3.1 Teste de Instrução e Cobertura de Instrução
 
-- Teste de Instruções
-- Teste de Ramificação
+- Teste de Instruções;
+- Teste de Ramificação.
 
 ### 4.3.1 Teste de Instrução e Cobertura de Instrução
 
-Teste de instrução
+Teste de instrução.
 
-Itens de Cobertura são Instruções Executáveis.
+Os itens de cobertura são instruções executáveis.
 
-Casos de teste são instruções no código
+Os casos de teste são instruções no código.
 
-Não pega casos que dependem de dados
+Não detecta casos que dependem de dados.
 
 ### 4.3.2 Teste de Ramificação e Cobertura de Ramificação
 
 Usando um grafo de fluxo de controle, cada ramificação é um caso de teste.
 
-As ramificações geralmente são os IF ou LOOPs.
+As ramificações geralmente são os IFs ou LOOPs.
 
 ### 4.3.3 O valor do Teste Caixa-Branca
 
 Usa toda a implementação durante o teste, facilitando a detecção de defeitos de especificação.
 
-Os testes de caixa branca podem ser usados como teste estático.
+Os testes de caixa-branca podem ser usados como teste estático.
 
 ### 4.4 Técnicas de Teste Baseadas na Experiência
 
-- Suposição de erro
-- Teste exploratório
-- Teste baseado em lista de verificação
+- Suposição de erro;
+- Teste exploratório;
+- Teste baseado em lista de verificação.
 
 ### 4.4.1 Suposição de Erro
 
 Cria o caso de teste já pensando nos erros possíveis.
+
 São criados com base em erros já experienciados e como o software funcionava anteriormente.
 
 ### 4.4.2 Testes Exploratórios
 
-Os teste são modelados, executados e avaliados ao mesmo tempo.
+Os testes são modelados, executados e avaliados ao mesmo tempo.
 
-Útil quando não há um conhecimento de como o sistema irá se comportar.
+Úteis quando não há conhecimento de como o sistema irá se comportar.
 
 ### 4.4.3 Testes baseados em Lista de Verificação
 
-O tester cria uma lista de verificação que será usada como cobertura.
+O testador cria uma lista de verificação que será usada como cobertura.
 
-O itens são formulados em formado de pergunta.
+Os itens são formulados em formato de pergunta.
 
 Pode ser usado como um teste de suporte.
 
 ### 4.5 Abordagens de Teste Baseadas na Colaboração
 
-Objetivos de EVITAR defeitos.
+Objetivo de EVITAR defeitos.
 
 ### 4.5.1 Escrita colaborativa de histórias de usuários
 
-Junta, a equipe escreve as UserStories
+A equipe escreve as User Stories.
 
-Usando "3C"
+Usando "3C":
 
-- Cartão: descrição da história
-- Conversação: como o software será usado
-- Confirmação: critérios de aceite
+- Cartão: descrição da história.
+- Conversação: como o software será usado.
+- Confirmação: critérios de aceite.
 
 ### 4.5.2 Critérios de Aceite
 
-Critérios para que os stakeholders aceite a implementação como completa.
+Critérios para que os stakeholders aceitem a implementação como completa.
 
 - São usados para:
-	- Definir escopo
-	- Chegar em consenso com stakeholders
-	- Descrever cenários
-	- Base dos Testes de Aceite
-- Podem ser Orientados por:
-	- Cenários
-	- Regras
+	- Definir escopo;
+	- Chegar a um consenso com stakeholders;
+	- Descrever cenários;
+	- Base dos Testes de Aceite.
+- Podem ser orientados por:
+	- Cenários;
+	- Regras.
 
 ### 4.5.3 Desenvolvimento Orientado por Teste de Aceite (ATDD)
 
-ATDD é uma abordagem que prioriza o teste
+ATDD é uma abordagem que prioriza o teste.
 
-Os casos são criados antes da implementação da UserStories
+Os casos são criados antes da implementação das User Stories.
 
 ---