diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js
index b7eab12..cedd3e1 100644
--- a/docs/.vuepress/config.js
+++ b/docs/.vuepress/config.js
@@ -10,7 +10,8 @@ module.exports = {
},
nav: [
{ text: "Home", link: "/" },
- { text: "Guia", link: "/guide/" },
+ { text: "🇧🇷", link: "/guide/" },
+ { text: "🇺🇸", link: "/en/guide/" },
{ text: "Colaborar", link: "https://github.com/vcwild/qa4noobs" },
{ text: "He4rt", link: "https://twitter.com/He4rtDevs" }
],
@@ -74,6 +75,65 @@ module.exports = {
"01-manual",
"02-automatizado",
],
+ "/en/guide/": [
+ "00-FOUNDATIONS",
+ "01-APPROACHES",
+ "02-TYPES",
+ "03-ADMIN",
+ "04-EXECUTION",
+ ],
+ "/en/00-foundation/": [
+ "00-intro",
+ "01-traditional-vs-agile",
+ "02-interaction",
+ "03-tools",
+ "04-artifacts",
+ "05-identify",
+ "06-cases-report-incident",
+ "07-questions",
+ ],
+ "/en/01-approachs/": [
+ "00-intro",
+ "01-white-box",
+ "02-black-box",
+ "03-gray-box",
+ ],
+ "/en/02-types/": [
+ "00-intro",
+ "01-functional",
+ "02-uat",
+ "03-exploratory",
+ "04-sanity",
+ "05-regression",
+ "06-unit",
+ "07-smoke",
+ "08-integration",
+ "09-non-functional",
+ "10-load",
+ "11-performance",
+ "12-stress",
+ "13-pentest",
+ "14-accessibility",
+ "15-compatibility",
+ ],
+ "/en/03-admin/": [
+ "00-intro",
+ "01-plan",
+ "01-priorization",
+ "02-sldc",
+ "03-agile",
+ "04-scrum",
+ "05-kanban",
+ "06-waterfall",
+ "07-v-model",
+ "08-report",
+ "09-verification",
+ ],
+ "/en/04-execution/": [
+ "00-intro",
+ "01-manual",
+ "02-automated",
+ ],
}
}
};
diff --git a/docs/en/00-foundation/00-intro.md b/docs/en/00-foundation/00-intro.md
index e331d8c..ea46203 100644
--- a/docs/en/00-foundation/00-intro.md
+++ b/docs/en/00-foundation/00-intro.md
@@ -1,4 +1,4 @@
-# **Fundamentos do Teste de Software**
+# **Foundations On Software Testing**
Quality Assurance (QA) also known as QA Tests is an activity that guarantees the best possible quality for the product provided by a company to the final consumer
@@ -59,4 +59,4 @@ To perform your function successfully, it's necessary to have the right mindset:
2. Don't be afraid to think outside the box while testing it.
3. Don't be afraid to use it in the most incorrect way possible.
4. The software is guilty until proven innocent.
-5. QA is responsible for proving the software is guilty.
\ No newline at end of file
+5. QA is responsible for proving the software is guilty.
diff --git a/docs/en/00-foundation/01-tradicional-vs-agile.md b/docs/en/00-foundation/01-traditional-vs-agile.md
similarity index 100%
rename from docs/en/00-foundation/01-tradicional-vs-agile.md
rename to docs/en/00-foundation/01-traditional-vs-agile.md
diff --git a/docs/en/03-admin/00-intro.md b/docs/en/03-admin/00-intro.md
index 82cfded..aa7bfef 100644
--- a/docs/en/03-admin/00-intro.md
+++ b/docs/en/03-admin/00-intro.md
@@ -1,9 +1,9 @@
-# Administração de Projetos
+# Project Management
-Um projeto é uma empreitada temporária com o objetivo de criar um produto, serviço ou resultado únicos.
+A project is a temporary undertaking with the goal of creating a unique product, service, or outcome.
-O projeto é temporário pois tem prazo de começo e fim definidos, e é único pois possui um conjunto de operações designadas para atingir o objetivo.
+The project is temporary because it has defined start and end dates, and it is unique because it involves a set of operations designed to achieve the objective.
-A administração de projetos é a disciplina de planejar, organizar, motivar e controlar os recursos para atingir os objetivos do projeto, enquanto mantém em mente o escopo, tempo, qualidade e custos.
+Project management is the discipline of planning, organizing, motivating, and controlling resources to achieve the project's objectives while keeping in mind the scope, time, quality, and costs.
-Isto facilita o fluxo de trabalho do time de colaboradores.
+This facilitates the workflow of the team of collaborators.
diff --git a/docs/en/03-admin/01-plan.md b/docs/en/03-admin/01-plan.md
index ea34bf9..36a38ee 100644
--- a/docs/en/03-admin/01-plan.md
+++ b/docs/en/03-admin/01-plan.md
@@ -1,266 +1,263 @@
-# Planejamento de Testes
+# Test Planning
-Um Plano de Testes é um documento detalhado que descreve a estratégia de testes, objetivos, agenda, estimativas, entregáveis e recursos necessários para desenvolver os testes em um produto de software.
+A Test Plan is a detailed document that describes the testing strategy, objectives, schedule, estimates, deliverables, and resources required to perform testing on a software product.
-O plano auxilia a determinar o esforço necessário para validar a qualidade da aplicação sob testes. Este plano funciona como um blueprint para conduzir as atividades de teste como um processo definido, o que é monitorado de perto e controlado pelo Gerente de Testes.
+The plan helps determine the effort needed to validate the quality of the application under test. This plan serves as a blueprint for conducting testing activities as a defined process, which is closely monitored and controlled by the Test Manager.
-De acordo com a definição da ISTQB
+According to the ISTQB definition:
- "O Plano de Testes é um documento que descreve o escopo, abordagem, recursos e agenda das atividades de teste planejadas"
+ "The Test Plan is a document that describes the scope, approach, resources, and schedule of planned test activities."
-## Importância do Plano de Testes
+## Importance of Test Planning
-Os benefícios do documento Plano de Testes são variados:
+The benefits of the Test Plan document are diverse:
-- Auxilia pessoas fora do time de teste, como desenvolvedores, gerentes de business e clientes a entender os detalhes da testagem.
-- O plano guia o raciocínio, é como um livro de regras a serem seguidas.
-- Aspectos importantes como estimativa de testes, escopo dos testes, estratégias, etc são documentadas no Plano, para que possam ser revisadas pelo Time de Gerência e reutilizada para outros projetos.
+- It aids people outside the testing team, such as developers, business managers, and clients, in understanding the details of testing.
+- The plan guides reasoning and acts as a set of rules to be followed.
+- Important aspects such as test estimation, test scope, strategies, etc., are documented in the Plan so that they can be reviewed by the Management Team and reused for other projects.
-## Como Escrever um Plano de Testes
+## How to Write a Test Plan
-
+
-### 1. Analise o Produto
+### 1. Analyze the Product
-Como você pode testar um produto sem qualquer informação dele? Não pode. É necessário profunda familiaridade com um produto antes de testa-lo.
+How can you test a product without any information about it? You can't. You need a deep understanding of the product before testing it.
-O produto sob testes é Guru99 Site Bancário. Deve-se pesquisar clientes, usuários finais e conhecer suas necessidades e expectativas do aplicativo.
+The product under test is the Guru99 Banking Site. Research customers, end-users, and their needs and expectations from the application.
-- Quem irá usar o Site?
-- Qual sua função?
-- Como funcionará?
-- Quais softwares/hardwares o produto utiliza?
+- Who will use the site?
+- What is its function?
+- How will it work?
+- What software/hardware does the product use?
-A ideia é sondar o produto e revisar sua documentação, isto auxiliará a entender todas as features do projeto bem como sua usabilidade. Em caso de não entendimento, pode-se conduzir entrevistas com clientes, desenvolvedores e designers para maiores informações.
+The idea is to explore the product and review its documentation, which will help understand all the project's features and usability. If there is any lack of understanding, interviews can be conducted with customers, developers, and designers for further information.
-### 2. Desenvolve a Estratégia de Testes
+### 2. Develop the Test Strategy
-A Estratégia de Testes é um passo crítico ao elaborar um Plano de Testes dentro da testagem de software. Uma estratégia é documento de alto nível, que é geralmente desenvolvida pelo Gerente de Testes. O documento define:
+The Test Strategy is a critical step in creating a Test Plan within software testing. The strategy is a high-level document, typically developed by the Test Manager. The document defines:
-- Os objetivos de teste do projeto, bem como os meios para atingí-los.
-- Determina o esforço e custos necessários.
+- The test project's objectives and the means to achieve them.
+- Determines the required effort and costs.
-
+
-#### 2.1. Defina o Escopo de Testes
+#### 2.1. Define the Test Scope
-Antes de iniciar qualquer atividade de teste, o escopo deve ser definido.
+Before starting any testing activity, the scope must be defined.
-- Componentes do sistema a serem testados (hardware,software,middleware, etc) são definidas segundo o escopo.
-- Os componentes do sistema que não serão testados também precisão estar claramente definidos como não fazendo parte do escopo.
+- Components of the system to be tested (hardware, software, middleware, etc.) are defined according to the scope.
+- Components of the system that will not be tested must also be clearly defined as not within the scope.
-Definir o Escopo de seu projeto de testes é importante para todos os investidores, uma vez que ajuda a:
+Defining the scope of your test project is essential for all stakeholders, as it provides everyone with reliable and accurate information about the testing to be carried out. All project members will have a clear understanding of what will be tested and what will not.
-- Provê a todos com informação confiável e precisa da testagem a ser elaborada.
-- Todos os membros do projeto terão entendimento claro do que será testado, e do que não será.
+##### 2.1.1. How to Determine Test Scope
-##### 2.1.1. Como determinar o Escopo de Testes
+- Precise Customer Requirements
+- Project Budget
+- Product Specification
+- Skills and Talents in the Test Team
-- Requerimentos de Cliente Precisos
-- Orçamento do Projeto
-- Especificação de Produto
-- Habilidades e Talentos no Time de Testes
+Now, you need to define clearly what is within and outside the scope.
-Agora deve-se definir claramente o que esta dentro e fora do escopo.
+#### 2.2. Identifying Test Types
-#### 2.2. Identificando o Tipo de Testes
+A test type is a standard procedure that provides an expected outcome for tests.
-Um tipo de teste é um procedimento padrão que provê um resultado esperado para os testes.
+Each type of testing is designed to identify a specific type of bug in the product. However, all types share the common goal of early defect identification before the client release.
-Cada tipo de testagem é formulada para identificar um tipo específico de bug no produto. Mas, todos os tipos possuem como alvo atingir o objetivo comum de identificação antecipada dos defeitos, antes do lançamento ao cliente.
+Commonly used types include:
-Os tipos comumente utilizados são:
+- Unit Testing: Verifies the smallest verifiable software parts in the application.
+- API Testing: Validates the API created for the application.
+- Integration Testing: Individual modules are combined and tested as a group.
+- System Testing: Conducted on a complete and integrated system to evaluate compliance with requirements.
+- Installation/Uninstallation Testing: Focuses on what customers need to do to successfully install/uninstall, configure/remove new software.
+- Agile Testing: Evaluates the system according to agile methodology.
-- Teste Unitário: Verifica as menores partes de software verificável na aplicação
-- Teste de API: Valida a API criada para a aplicação
-- Teste de Integração: Módulos individuais são combinados e testados como um grupo
-- Teste de Sistemas: Conduzidos em um sistema completo e integrado para avaliar se está em conformidade com os requerimentos
-- Teste de Instalação/Desinstalação: Foca no que os clientes precisarão fazer para instalar/desinstalar e configurar/remover o novo software com sucesso
-- Teste Ágil: Avalia o sistema de acordo com a metodologia ágil
+There are a myriad of test types for the product, and the Test Manager should define the appropriate prioritization based on the application's functions and within the defined budget.
-Existe uma infinidade de tipos de teste para o produto, deverá o Gerente de Testes definir a Priorização adequada, com base nas funções da aplicação e respeitando o orçamento definido.
+#### 2.3. Document Risks and Issues
-#### 2.3. Documento Riscos e Problemas
+Risks are future and uncertain events with the probability of occurrence and the potential for loss. When the risk actually occurs, it becomes an "issue."
-Riscos são eventos futuros e incertos com probabilidade de ocorrência e potencial de perda. Quando o risco ocorre de fato, torna-se um "problema".
+Examples of documentation risks include:
-Exemplos de Riscos para documentação:
+- Team member lacks required skills: Plan training sessions.
+- The schedule is tight, making it difficult to complete requirements on time: Determine test priority for each activity.
+- Test Manager lacks adequate management skills: Plan training sessions for leadership.
+- A lack of cooperation negatively affects team productivity: Encourage each member in their tasks and inspire them to greater efforts.
+- Incorrect budget estimate and additional costs: Establish scope before starting work, pay due attention to planning, and continuously measure progress.
-- Membro da equipe não possui habilidade necessária: Planeje sessões de treinamento
-- O cronograma é apertado, tornando difícil completar os requisitos a tempo: Determine prioridade de testes para cada atividade
-- Gerente de Testes possui habilidades de gerência inadequadas: Planeje sessões de treinamento para lideranças
-- Uma falta de cooperação negativamente afeta a produtividade da equipe: Encoraje cada membro em suas tarefas, e inspire-os a maiores esforços
-- Estimativa de orçamento errada e custos adicionais: Estabeleça o escopo antes de iniciar o trabalho, preste atenção devida ao planejamento e constantemente meça os progressos
+#### 2.4. Create Test Logic
-#### 2.4. Crie Lógicas de Teste
+In test logic, the Manager must answer the following questions:
-Na lógica de testes, o Gerente deverá responder as seguintes perguntas:
+- Who will perform the test?
+- When will the test take place?
-- Quem irá testar?
-- Quando o teste irá ocorrer?
+You may not know the names of each tester, but the type of tester can be defined.
-Você pode não conhecer exatamente os nomes de cada tester, mas o tipo de tester pode ser definido.
+To select the right member for a specific task, you must consider whether their skills qualify them for the task and estimate the available budget. Incorrect selection can cause delays or project failure.
-Para selecionar o membro correto para uma tarefa específica, deve-se considerar se suas habilidades qualificam-se para a tarefa ou não, também estimando o orçamento disponível. Selecionar errôneamente pode causar atrasos ou falha no projeto.
+Possessing the following skills is most ideal for testing:
-Possuir as seguintes habilidades é o mais ideal para aplicação de testes:
+- Ability to understand from a customer's perspective.
+- Strong desire for quality.
+- Attention to detail.
+- Good cooperation.
-- Capacidade de compreensão do ponto de vista dos clientes
-- Forte desejo por qualidade
-- Atenção a Detalhes
-- Boa cooperação
+In your project, the tester will take the reins of execution. Based on the budget, you can select outsourcing.
-Em seu projeto, o tester irá tomar as rédeas da execução. Baseado no orçamento, pode-se selecionar terceirizações.
+*When will the test occur?*
-*Quando o teste ocorrerá?*
+Test activities should be associated with development activities and should start when all necessary items exist.
-Atividades de teste devem ser associadas com atividades de desenvolvimento, devendo iniciar-se quando todos os itens necessários existirem.
+
-
+### 3. Set Test Objectives
-### 3. Defina objetivos para o teste
+This involves the overall goal and achievement of the best execution. The goal of testing is to find as many defects as possible, ensuring that the software is bug-free before release.
-Consiste no objetivo geral e conquista da melhor execução. O objetivo dos testes é encontrar tantos defeitos quanto o possível, garantindo que o software seja livre de bugs antes de seu lançamento.
+To set objectives, you need to:
-Para definir objetivos, deve-se:
+- List all features (functionality, performance, GUI, etc.) that may require testing.
+- Define the target or objective of the test based on the above features.
-- Listar todas as features (funcionalidade, performance, GUI, etc) que podem precisar de testes.
-- Definir o alvo, ou objetivo, do teste baseado nas características acima.
+### 4. Define Test Criteria
-### 4. Defina os critérios de teste
+Criteria are standards or rules on which test procedures are based, and there are two types:
-Os critérios são padrões ou regras nas quais os procedimentos de teste baseiam-se, existem dois tipos:
+#### 4.1. Suspension Criteria
-#### 4.1. Critério de Suspensão
+Specify critical suspension criteria for a test. If these criteria are met during testing, the active test cycle will be *suspended* until the criteria are resolved.
-Especifique os critérios de suspensão críticos para um teste. Caso estes sejam atendidos durante a testagem, o ciclo de testes ativos será *suspendido* até que os critérios sejam solucionados.
+*Example:* If the team reports that 40% of cases have failed, you must suspend testing until the development team fixes all cases.
-*Exemplo:* Caso os relatórios da equipe indiquem que 40% dos casos falharam, você deve suspender a testagem até que o time de desenvolvimento corrija todos os casos.
+
-
+#### 4.2. Exit Criteria
-#### 4.2. Critérios de Saída
+Exit criteria specify the guidelines that denote success in a testing phase. Exit criteria are the target results of tests required before proceeding to the next development phase.
+E.g., 95% of all critical test cases must pass.
-Especificam as diretrizes que denotam sucesso em uma fase de testes. Os critérios de saída são resultados alvo dos testes, necessários antes de proceder para a proxima fase de desenvolvimento.
-Ex: 95% de todos os casos de teste críticos devem passar.
+Some methods for defining exit criteria consist of specifying execution and success rates.
-Alguns métodos para definir os critérios de saída consistem na especificação de taxas par execução e sucesso.
+- Execution Rate: It is the ratio of the number of executed test cases to the total number of cases.
+- Success Rate: The ratio of tests that have passed to the total number of executed test cases.
-- Taxa de execução: É a relação entre o número de casos de teste executados/total de casos.
-- Taxa de Sucesso: Relação entre número de testes que passaram/casos de teste executados.
+These data can be collected in test metric documents.
-Estes dados podem ser coletados em documentos de Metrica para Testes.
+- The Execution Rate must necessarily be 100%, unless a clear reason is provided.
+- The Success Rate depends on the project's scope, but it is ideal for it to be as high as possible.
-- Taxa de Execução deve ne cessáriamente ser de 100%, a não ser que uma razão clara seja provida.
-- Taxa de Suceso depende do escopo do projeto, mas o ideal é que seja tão alta quanto o possível.
+### 5. Resource Planning
-### 5. Planejamento de recursos
+Resource planning is a detailed summary of all types of resources required to complete a task or project. Resources can be human, equipment, and materials needed to finish a project.
-Planejamento de recursos é um sumário detalhado de todos os tipos de recursos necessários para completar um projeto de tarefa. Recursos podem ser humanos, equipamento e materiais necessários para finaliza um projeto.
+Resource planning is an important factor in test planning as it helps determine the number of resources to be employed in the project. Therefore, the Test Manager can accurately develop the schedule and estimates for the project.
-O planejamento de recursos é fator importante para o planejamento de testes uma vez que auxilia a determinar o número de recursos a serem empregados no projeto. Portanto, o Gerente de Testes pode elaborar corretamente o cronograma e estimativas para o projeto.
-
-- Recursos Humanos:
- - Gerente de Teste:
- 1. Administra todo o Projeto
- 2. Define diretrizes
- 3. Adquire os recursos necessários
- 4. Identifica e descreve técnicas/ferramentas/arquitetura de automação apropriadas
+- Human Resources:
+ - Test Manager:
+ 1. Manages the entire project.
+ 2. Defines guidelines.
+ 3. Acquires the necessary resources.
+ 4. Identifies and describes appropriate automation techniques/tools/architecture.
- Tester:
- 1. Executa os testes, cataloga resultados, reporta defeitos
- 2. Pode ser interno ou terceirizado, com base no orçamento disponível
- 3. Para tarefas que requeiram baixa especialização, é recomentdado o uso de equipe terceirizada para poupar custos
- - Desenvolvedor em Teste:
- 1. Implementa casos de testes, programa de testes, baterias etc.
+ 1. Executes tests, catalogs results, reports defects.
+ 2. Can be internal or outsourced, depending on the available budget.
+ 3. For tasks that require low specialization, it is recommended to use an outsourced team to save costs.
+ - Test Developer:
+ 1. Implements test cases, test programs, test batteries, etc.
- - Administrador de Testes:
- 1. Constrói e garante que Ambiente de Testes e seus recursos sejam administrados e recebam manutenção
- 2. Provê apoio ao Tester para uso do ambiente de testes
- - Membros SQA:
- 1. Responsável pelo Quality Assurance
- 2. Verifica e confirma se o processo de testes atende aos requerimentos especificados
+ - Test Administrator:
+ 1. Builds and ensures that the test environment and its resources are managed and maintained.
+ 2. Provides support to the tester for using the test environment.
+ - SQA Members:
+ 1. Responsible for Quality Assurance.
+ 2. Verify and confirm that the test process meets specified requirements.
-#### 5.1. Recursos do Sistema
+#### 5.1. System Resources
-Para testar um aplicativo web, deve-se planejar os recursos de acordo com:
+To test a web application, resources must be planned according to:
-- Servidor:
- - Instala a aplicação web sob testes
- - Inclui um servidor web separado, servidor para database e servidor para aplicação, caso seja aplicável
-- Ferramenta de Testes:
- - A ferramentas de teste é usada para automatizar os processos, simular operação apropriada de usuários e gerar resultados
- - Existem diversas ferramentas disponíveis para este uso (Selenium, QTP, etc)
-- Rede:
- - A rede deve incluir LAN e Internet para simular condições de negócios reais, bem como o ambiente de usuário
-- Computador:
- - O computador em que usuários comumente acessam o servidor web
+- Server:
+ - Installs the web application under test.
+ - Includes a separate web server, database server, and application server, if applicable.
+- Testing Tool:
+ - The testing tool is used to automate processes, simulate proper user operations, and generate results.
+ - There are various tools available for this purpose (Selenium, QTP, etc.).
+- Network:
+ - The network must include LAN and the Internet to simulate real business conditions and the user environment.
+- Computer:
+ - The computer on which users commonly access the web server.
-### 6. Planeje o ambiente de testes
+### 6. Test Environment Planning
-*O que é o ambiente de testes?*
+*What is the test environment?*
-Consiste em setup de software e hardware em que o time de teste desenvolve os casos. Caracteriza-se de um ambiente real de negócios e usuários, bem como ambientes físicos, como servidores e ambiente para execução de front-end.
+It consists of the software and hardware setup in which the test team develops test cases. It is characterized by a real business and user environment, as well as physical environments such as servers and front-end execution.
-#### 6.1. Como Configurar o Ambiente de Testes
+#### 6.1. How to Set Up the Test Environment
-Pressuponto cooperação entre time de desenvolvimento e time de testes, pergunte aos desenvolvedores todo o necessário para compreender a aplicação sob testes de forma clara.
+Assuming cooperation between the development team and the test team, ask the developers for all the necessary information to understand the application under test clearly.
-- Qual o máximo de usuários conectados ativamente o website pode aguentar de forma simultânea?
-- Qual os requerimentos de hardware/software para instalação do website?
-- O usuário precisa de alguma configuração específica para navegar no website?
+- What is the maximum number of actively connected users the website can handle simultaneously?
+- What are the hardware/software requirements for website installation?
+- Does the user need any specific configurations to browse the website?
-### 7. Cronograma e Estimativa
+### 7. Schedule and Estimation
-Suponha que todo o projeto seja subdivido em tarefas menores e adicionados na estimativa da seguinte forma:
+Suppose that the entire project is subdivided into smaller tasks and added to the estimate as follows:
-- Criação das Especificações de Teste:
- - Elaborado pelo Desginer de Testes
- - 170 horas de trabalho
-- Execução de Testes:
- - Tester, Administrador de Testes
- - 80 horas de trabalho
-- Relatório de Testes:
- - Tester
- - 10 horas de trabalho
-- Entrega de Testes:
- - 20 horas de trabalho
-- Total: 280 Horas de Trabalho.
+- Creation of Test Specifications:
+ - Developed by the Test Designer.
+ - 170 hours of work.
+- Test Execution:
+ - Tester, Test Administrator.
+ - 80 hours of work.
+- Test Report:
+ - Tester.
+ - 10 hours of work.
+- Test Delivery:
+ - 20 hours of work.
+- Total: 280 Hours of Work.
-Assim, pode-se elaborar o cronograma para completar todas as tarefas.
+This way, you can create a schedule to complete all the tasks.
-Elaborar cronogramas é um termo comum em administração de projetos. Ao criar uma agenda solida no Planejamento de Testes, o Gerente pode usar como ferramenta para monitorar o progresso e controlar custos adicionais.
+Creating schedules is a common term in project management. By creating a solid schedule in Test Planning, the Manager can use it as a tool to monitor progress and control additional costs.
-Para elaborar o cronograma de um projeto, o Gerente de Testes precisa de diversas informações, tais como:
+To create a project schedule, the Test Manager needs various information, such as:
-- Prazos de Funcionários e do Projeto: Dias de trabalho, prazo do projeto e recursos disponíveis são fatores que afetam o cronograma
-- Estimativa do Projeto: Com base na estimativa, o Gerente saberá quanto tempo será dispendido para completar o projeto. Podendo elaborar o cronograma apropriado
-- Riscos do Projeto: Compreender os riscos auxilia o Gerente a adicionar tempo extra suficiente ao cronograma para lidar com riscos
+- Employee and Project Deadlines: Workdays, project deadlines, and available resources are factors that affect the schedule.
+- Project Estimation: Based on the estimation, the Manager will know how much time will be spent to complete the project, enabling the creation of an appropriate schedule.
+- Project Risks: Understanding the risks helps the Manager add enough extra time to the schedule to deal with risks.
-### 8. Determine os entregáveis para os testes
+### 8. Determine the Deliverables for Testing
-Entregáveis são uma lista de todos os documentos, ferramentas e outros componentes que precisam ser desenvolvidos e mantidos em apoio ao esforço de testes.
+Deliverables are a list of all the documents, tools, and other components that need to be developed and maintained to support testing efforts.
-Existem diferentes entregáveis em todas as fases do desenvolvimento
+There are different deliverables in all phases of development.
-
+
-Entregáveis são providenciados *antes* da fase de testes:
+Deliverables are provided *before* the testing phase:
-- Documento Planos de Testes
-- Documento Casos de Teste
-- Especficiações do Design de Testes
+- Test Plans Document
+- Test Cases Document
+- Test Design Specifications
-Entregáveis providenciados *durante* a fase de testes:
+Deliverables are provided *during* the testing phase:
-- Scripts de Teste
-- Simuladores
-- Dados de Testes
-- Matriz de Rastreabilidade de Teste
-- Logs de erros e execuções
+- Test Scripts
+- Simulators
+- Test Data
+- Test Traceability Matrix
+- Error and Execution Logs
-Entregáveis providenciados *após* a fase de testes:
+Deliverables are provided *after* the testing phase:
-- Resultados/Relatórios de Testes
-- Relatório de Defeitos
-- Instalação/Diretrizes dos Procedimentos de Testes.
-- Notas de Lançamento.
+- Test Results/Reports
+- Defect Reports
+- Installation/Testing Procedure Guidelines
+- Release Notes.
diff --git a/docs/en/03-admin/01-priorizacao.md b/docs/en/03-admin/01-priorizacao.md
deleted file mode 100644
index 1b95734..0000000
--- a/docs/en/03-admin/01-priorizacao.md
+++ /dev/null
@@ -1,105 +0,0 @@
-# Priorização de Testes
-
-- A priorização é uma das formais mais eficientes para produzir produtos de alta qualidade de acordo com os padrões do mercado e de consumo.
-
-- É uma forma de priorizar e tabelar os casos do mais importante ao menos importante.
-
-- Minimiza custos, esforço e tempo durante a fase de testes.
-
-- É importante conhecer bem os benefícios, desafios e tecnicas de priorização dos casos para colher os melhores benefícios
-
-Priorizar testes é ordenar os casos de testes a serem eventualmente conduzidos.
-
-Priorizar os testes ajuda a satisfazar as limitações de tempo e orçamento na testagem para melhorar a taxa de detecção de falhas o mais rápido quanto o possível
-
-## Categorias de Prioridade
-
-- Prioridade 1:
-
- Casos de teste que **precisam** ser executados, ou as consequências podem ser piores após o lançamento do produto. Estes são casos de teste críticos, onde as chances de uma funcionalidade ser quebrada por uma funcionalidade nova são mais prováveis.
-- Prioridade 2:
-
- Casos que **podem** ser executados se houver tempo. Estes não são tão críticos, mas podem ser executados como uma medida de boas-práticas para dar um double check antes do lançamento.
-- Prioridade 3:
-
- Casos de teste que **não são** importantes o suficiente para serem testados antes do lançamento atual. Estes podem ser testados depois, logo após o lançamento da versão atual do software, novamente, como uma medida de boas práticas. Entretanto, não há dependência direta para com eles.
-- Prioridade 4:
-
- Casos que **nunca** são importantes, já que seu impacto é irrisório.
-
-No esquema de priorização, a diretriz principal a ser seguida é garantir que os casos de baixa prioridade não devem causar impactos severos no software. Esta priorização deve possuir diversos objetivos, assim como:
-
-- Baseada na funcionalidade que já foi comunicada aos usuários e é crucial do ponto de vista do business.
-
-- Avaliar a probabilidade de falhas ao checar a taxa de detecção de falhas de uma categoria de testes. Isto ajuda a entender se esta categoria é crítica ou não.
-
-- Aumentar a cobertura de código do sistema sob testes com maior velocidade utilizando os critérios de cobertura usados anteriormente.
-
-- Aumentar a taxa de detcção de falhas críticas em uma categoria de teste ao localizar falhas similares que ocorreram mais cedo no processo de testes.
-
-- Aumentar a probabilidade de falhas serem reveladas devido a mudanças específicas no código anteriormente no processo de Teste de Regressão.
-
-## - Tipos de Priorização de Casos de Teste
-
-- Priorização Geral:
-
-Aqui, os casos de teste são priorizados de acordo com o quão úteis eles serão para versions subsquentes do produto. Isto não requer qualquer conhecimento das versões modificadas, portanto, uma priorização geral pode ser aplicada logo após o lançamento de uma versão do programa fora do horário de pico. Devido a isso, o custo de aplicação desta categoria de priorização é amortizado durante lançamentos subsquentes.
-
-- Priorização de Casos de Teste Específica por Versão:
-
-Nesta modalidade, priorizamos os casos de forma que eles serão úteis de acordo com cada versão do produto. Isto requer conhecimento de todas as mudanças que foram feitas no produto. É aplicado antes da testagem de regressão na versão modificada.
-
-## Quais são as Diferentes Técnicas para Priorização?
-
-Podemos priorizar os casos de teste de acordo com as seguintes técnicas:
-
-### 1. Baseado em Cobertura
-
-Foca na cobertura de código pelos testes de acordo com as seguintes técnicas:
-
-- Cobertura Total de Extratos:
-
- Aqui, o número total de extratos cobertos por um caso de testes é usado como fator para priorizar os testes. Por exemplo, um teste que cubra 5 extratos receberá prioridade sobre um que cubra somente 2
-
-- Cobertura de Extrato Adicional:
-
- Esta técnica envolve selecionar iterativamente um caso de testes com o máximo de cobertura, e, então, selecionar um caso que cubra o que o anterior deixou de cobrir. O processo é repetido até que tudo esteja coberto.
-
-- Cobertura de Branches Total:
-
- Aqui, branches se refere ao total de possibilidades de output em uma condição, e a maior cobertura destas é o fator determinante.
-
-- Cobertura de Branches Adicional:
-
- De forma semelhante a cobertura de extratos adicional, aqui a técnica pega o teste com a maior cobertura de branches, e vai iterativamente selecionando os próximo de acordo com aqueles que o anterior não cobre.
-
-### 2. Baseada em Risco
-
-Aqui utiliza-se análise de risco para identifiar possíveis áreas-problema que, em caso de falha, podem levar a graves consequências.
-
-### 3. Baseada nas Regras de Negócio
-
-Nesta técnica a priorização é feita com base em diversos fatores que determinam as regras de negócio. Estes fatores são documentados nas condições de aceite. Casos de teste são pensados considerando a prioridade assinalada pelo cliente para uma regra, sua complexidade e volatilidade.
-
-Os fatores usados são:
-
-- Prioridade Indicada pelo Cliente: é a medida da importante de regras de negócio para um cliente sob o ponto de vista do business.
-- Volatividade da Regra de Negócio: indica quantas vezes a regra de negócios mudou.
-- Complexidade de Implementação: indica o esforço ou tempo necesário para implementar uma regra de negócio.
-- Tendência a erro: indica o quão passível de erro uma regra de negócio foi em versões anteriores do software.
-
-### 4. Baseada em Histórico
-
-Nesta técnica, a priorização é feita no histórico dos casos de teste, ou seja, os resultados das execuções anteriores são verificadas.
-
-É usado para determinar as possíveis chances de falha nos testes e aqueles em que o erro é mais provável recebem prioridade. A verificação de histórico é utilizada para selecionais quais casos de testes poderiam ser considerados para retestagem no ciclo atual.
-
-### 5. Baseado na Noção de Custo
-
-Aqui, o fator custo entra em voga, testes que custem menos serão priorizados sobre testes com maior custo, isto inclui:
-
-- Custo do processo de teste de regressão.
-- Custo da juntada das regras de negócio.
-- Custo para analisar se deve selecionar um caso de teste.
-- Custo de priorização dos casos de teste.
-- Custo da execução completa do teste.
diff --git a/docs/en/03-admin/01-priorization.md b/docs/en/03-admin/01-priorization.md
new file mode 100644
index 0000000..bea937d
--- /dev/null
+++ b/docs/en/03-admin/01-priorization.md
@@ -0,0 +1,105 @@
+# Test Prioritization
+
+- Prioritization is one of the most efficient ways to produce high-quality products according to market and consumer standards.
+
+- It's a way to prioritize and rank cases from most important to least important.
+
+- Minimizes costs, effort, and time during the testing phase.
+
+- It's important to have a good understanding of the benefits, challenges, and prioritization techniques to reap the best results.
+
+Test prioritization is about ordering the test cases to be eventually conducted.
+
+Prioritizing tests helps meet time and budget constraints in testing to enhance the fault detection rate as quickly as possible.
+
+## Priority Categories
+
+- Priority 1:
+
+ Test cases that **must** be executed, or the consequences may be worse after the product's release. These are critical test cases, where the chances of a new feature breaking an existing one are more likely.
+- Priority 2:
+
+ Test cases that **can** be executed if there is time. These are not as critical but can be performed as a best practice to double-check before release.
+- Priority 3:
+
+ Test cases that are **not** important enough to be tested before the current release. These can be tested later, immediately after the current version of the software is released, again as a best practice. However, there is no direct dependency on them.
+- Priority 4:
+
+ Test cases that are **never** important since their impact is negligible.
+
+In the prioritization scheme, the main guideline is to ensure that low-priority cases should not cause severe impacts on the software. This prioritization should have several objectives, such as:
+
+- Based on functionality that has already been communicated to users and is critical from a business perspective.
+
+- Assess the probability of faults by checking the fault detection rate of a test category. This helps understand if this category is critical or not.
+
+- Increase code coverage of the system under test more quickly using previously used coverage criteria.
+
+- Increase the detection rate of critical faults in a test category by locating similar faults that occurred earlier in the testing process.
+
+- Increase the probability of faults being revealed due to specific changes in the code earlier in the Regression Testing process.
+
+## Types of Test Case Prioritization
+
+- General Prioritization:
+
+Here, test cases are prioritized based on how useful they will be for subsequent versions of the product. This does not require any knowledge of modified versions, so general prioritization can be applied immediately after the release of a version outside of peak hours. Due to this, the cost of applying this prioritization category is amortized during subsequent releases.
+
+- Version-Specific Test Case Prioritization:
+
+In this mode, we prioritize the cases so that they will be useful according to each version of the product. This requires knowledge of all the changes made to the product. It is applied before regression testing in the modified version.
+
+## What Are the Different Techniques for Prioritization?
+
+We can prioritize test cases using the following techniques:
+
+### 1. Coverage-Based
+
+Focuses on code coverage by tests according to the following techniques:
+
+- Total Statement Coverage:
+
+ Here, the total number of statements covered by a test case is used as a factor to prioritize the tests. For example, a test covering 5 statements will receive priority over one covering only 2.
+
+- Additional Statement Coverage:
+
+ This technique involves iteratively selecting a test case with the highest statement coverage and then selecting a case that covers what the previous one missed. The process is repeated until everything is covered.
+
+- Total Branch Coverage:
+
+ Here, branches refer to the total possibilities of output in a condition, and the highest coverage of these is the determining factor.
+
+- Additional Branch Coverage:
+
+ Similar to additional statement coverage, here, the technique picks the test with the highest branch coverage and iteratively selects the next ones according to those not covered by the previous one.
+
+### 2. Risk-Based
+
+Here, risk analysis is used to identify potential problem areas that, if they fail, could lead to severe consequences.
+
+### 3. Business Rule-Based
+
+In this technique, prioritization is based on various factors that determine business rules. These factors are documented in the acceptance criteria. Test cases are designed considering the priority assigned by the customer to a rule, its complexity, and volatility.
+
+The factors used are:
+
+- Priority Indicated by the Customer: It is a measure of the importance of business rules to a customer from a business perspective.
+- Business Rule Volatility: Indicates how many times the business rule has changed.
+- Implementation Complexity: Indicates the effort or time required to implement a business rule.
+- Error-Prone Nature: Indicates how error-prone a business rule was in previous versions of the software.
+
+### 4. History-Based
+
+In this technique, prioritization is done based on the history of test cases, i.e., the results of previous executions are checked.
+
+It is used to determine the possible chances of failure in the tests, and those in which failure is more likely receive priority. History verification is used to select which test cases should be considered for retesting in the current cycle.
+
+### 5. Cost-Based
+
+Here, the cost factor comes into play, where tests that cost less are prioritized over tests with higher costs. This includes:
+
+- Cost of regression testing.
+- Cost of gathering business rules.
+- Cost of analyzing whether to select a test case.
+- Cost of test case prioritization.
+- Cost of full test execution.
diff --git a/docs/en/03-admin/02-sldc.md b/docs/en/03-admin/02-sldc.md
index ed87a1d..0acb72f 100644
--- a/docs/en/03-admin/02-sldc.md
+++ b/docs/en/03-admin/02-sldc.md
@@ -1,105 +1,104 @@
-# Metodologias do Ciclo de Vida do Software
+# Software Development Life Cycle Methodologies
-Software Developmente Life Cycle é o processo seguido para o desenvolvimento de um software, englobando sua organização, planejamento, entrega e etc.
+Software Development Life Cycle (SDLC) is the process followed for software development, encompassing its organization, planning, delivery, and more.
-## O que é SLDC?
+## What is SDLC?
-É um processo seguido para um projeto de software dentro de uma empresa. Consiste em um plano detalhado que descreve como desenvolver, manter, trocar, alterar ou melhorar partes específicas do software. O Ciclo define uma metodologia para melhorar a qualidade do softare e o processo geral de desenvolvimento.
+It is a process followed for a software project within a company. It consists of a detailed plan that describes how to develop, maintain, change, or enhance specific parts of the software. The cycle defines a methodology to improve software quality and the overall development process.
-
+
-### 1. Planejamento e Análise de Requerimentos
+### 1. Planning and Requirements Analysis
-Análise das regras de negócio é um dos estágios mais fundamentais no SLDC, é aplicado por membros sêniors no time com inputs dos clientes, departamento de vendas, pesquisas de mercado e especialistas na indústria. A informação é usada para planejar a abordagem básica do projeto e conduzir estudos de viabilidade do produto nas áreas econômicas, operacionais e técnicas.
+Analysis of business rules is one of the most fundamental stages in SDLC. It is performed by senior team members with inputs from clients, sales departments, market research, and industry experts. This information is used to plan the project's basic approach and conduct product feasibility studies in economic, operational, and technical areas.
-Planejar para os requerimentos de garantia de qualidade e identificação de riscos associados com o projetos também é são feitos no estágio de planejamento. O Resultado dos estudos de viabilidade é definir as diversas abordagens técnicas que podem ser seguidas para implementar o projeto com sucesso, assumindo riscos mínimos.
+Planning for quality assurance requirements and identifying project-associated risks is also done in the planning stage. The result of feasibility studies is to define the various technical approaches that can be followed to successfully implement the project while assuming minimal risks.
-### 2. Definindo Regras de Negócio
+### 2. Defining Business Rules
-Uma vez que a análise de requerimentos foi feita o próximo passo é definir e documentar claramente todas as regras de negócio e condições de aceite, recebendo a aprovação de clientes e analistas de mercado. Isto é feito através de um SRS (Software Requirement Specification) que consiste no design de todos os requerimentos do produto e seu desenvolvimento durante o ciclo de vida do projeto.
+Once requirements analysis is complete, the next step is to clearly define and document all business rules and acceptance criteria, obtaining approval from clients and market analysts. This is done through a Software Requirement Specification (SRS) that consists of the design of all product requirements and their development throughout the project's life cycle.
-### 3. Design da Arquitetura do Projeto
+### 3. Project Architecture Design
-SRS é a referencia para arquitertos de produto desenvolverem a melhor arquitetura possível. Com base nos requerimentos especificados no SRS, geralmente mais de uma abordagem de design é proposta e documentada em um DDS (Design Document Specification)
+The SRS serves as a reference for product architects to develop the best possible architecture. Based on the requirements specified in the SRS, typically more than one design approach is proposed and documented in a Design Document Specification (DDS).
-Este DDS é revisado por todos os investidores majoritários e baseado em diversos parâmetros como análise de risco, robustez do produto, modularidade do design, orçamento e restrições de tempo, escolhe-se a mlehor abordagem para o produto.
+This DDS is reviewed by all major stakeholders, and based on various parameters such as risk analysis, product robustness, design modularity, budget, and time constraints, the best approach for the product is chosen.
-Uma abordagem de design claramente define todos os módulos de arquitetura do produto junto de sua comunicação e representação do fluxo de dados com módulos externos (caso existam). O design interno de todos os módulos da arquitetura proposta devem ser claramente definidos com o máximo de detalhes no DDS.
+A clear design approach defines all the architecture modules of the product along with their communication and data flow representation with external modules (if any). The internal design of all modules of the proposed architecture should be clearly defined with maximum detail in the DDS.
-### 4. Construção e Desenvolvimento do Produto
+### 4. Product Construction and Development
-Aqui, o desenvolvimento propriamente dito começa, e o produto é construído
-O código de programação é gerado de acordo com o DDS neste estágio. Se o design é aplicado de forma detalhada e organisada, a geração de código pode ser concluída sem maiores dificuldades.
+Here, the actual development begins, and the product is built. The programming code is generated according to the DDS in this stage. If the design is applied in a detailed and organized manner, the code generation can be completed without major difficulties.
-Desenvolvedores devem conhecers as diretrizes de código definidas por sua organização, bem como as ferramentas pertinentes. A linguagem de programação a ser utilizada é definida de acordo com o software a ser desenvolvido.
+Developers should be familiar with the code guidelines defined by their organization, as well as the relevant tools. The choice of programming language to be used is determined according to the software to be developed.
-### 5. Testagem do Produto
+### 5. Product Testing
-Esta etapa é geralmente um subtipo de todos os estágios em modelos modernos de SLDC. Entretanto, esta etapa regere-se apenas a testagem do produto, onde defeitos são localizados, reportados, catalogados, corrigidos e validados, até que o produto atinja os maiores padrões de qualidade.
+This stage is generally a subset of all stages in modern SDLC models. However, this stage specifically focuses on product testing, where defects are located, reported, cataloged, corrected, and validated until the product meets the highest quality standards.
-### 6. Implementação no Mercado e Manutenção
+### 6. Market Implementation and Maintenance
-Uma vez que o produto é testado e esta pronto para ser implementado, ele é formalmente lançado a mercado. Por vezes a implementação de produto acontece em estágios, de acordo com a estratégia de negócios da organização. O produto pode ser lançado primeiro em um segmento limitado, e testado no ambiente de negócios real (UAT).
+Once the product has been tested and is ready to be implemented, it is formally released to the market. Sometimes, product implementation occurs in stages, according to the organization's business strategy. The product may be first released in a limited segment and tested in the actual business environment (User Acceptance Testing - UAT).
-Então, baseado em feedback, o produto pode ser lançado como estiver, ou com melhorias sugeridas pelo mercado alvo. Uma vez lançado no mercado, sua manutenção é feita com foco na base de usuários existentes.
+Then, based on feedback, the product may be released as is or with improvements suggested by the target market. Once released to the market, its maintenance is focused on the existing user base.
-## Modelos SLDC
+## SDLC Models
-Existem diversos modelos definidos e arquitetados que são seguidos durante o processo de desenvolvimento. Estes modelos também são chamados de Software Development Process Models. Cada modelo de processo segue uma serie de passos única para garantir o sucesso nos processos de desenvolvimento.
+Several defined and architected models are followed during the development process. These models are also called Software Development Process Models. Each process model follows a unique set of steps to ensure success in development processes.
-Os modelos mais populares de SLDC são:
+The most popular SDLC models include:
-- Cascata
-- Iterativo
-- Espiral
-- Modelo-V
+- Waterfall
+- Iterative
+- Spiral
+- V-Model
- Big Bang
-## O que é o o Quality Assurance no SLDC?
+## What Is Quality Assurance in SDLC?
-O QA possui papel fundamental no processo que deve ser implementando no ciclo de desenvolemento.
+Quality Assurance (QA) plays a fundamental role in the process to be implemented in the development cycle.
-Sua principal função é garantir que o softawre atenda as regras de negócio, esteja livre de bugs e funcione perfeitamente sob diferentes circunstâncias.
+Its primary function is to ensure that the software meets business rules, is free of bugs, and functions perfectly under different circumstances.
-Para a atual realidade de mercado, em que um produto ficará disponível em diversos modais, e é crítico que seja desenvolvido sem defeitos. Aqui entra o QA.
+For the current market reality, where a product will be available in various modes, it is critical that it is developed without defects. This is where QA comes in.
-O QA em TI é integrado em todos os estágios de desenvolvimento, e é usado mesmo após o estágio de lançamento.
+QA in IT is integrated into all stages of development and is used even after the release stage.
-Especialistas em QA criam e implementam diversas estratégias para melhoria de qualidade de software, aplicando diversos tipos de teste para garantir correta funcionalidade, este estágio é chamado de Controle de Qualidade (QC).
+QA experts create and implement various strategies for software quality improvement, applying various types of tests to ensure proper functionality. This stage is called Quality Control (QC).
-## Quais Profissionais Integram o Time de QA?
+## Which Professionals Are Part of the QA Team?
-Podendo de empresa para empresa, as principais funções são:
+Depending on the company, the main roles are:
-- Analista de QA: Posição proxima ao analista de negócios, coleta todas as informações do projeto, avalia riscos e pontos fracos, e cria documentações para descrever aspectos futuros do desenvolvimento que Engenheiros de QA devem atenter-se.
-- Lider de QA: A liderança do time é a pessoa que controla toda a equipe de especialistas. Além disso, o lead administra testes, cria planos de teste, processa a informação recebida de analistas, observa todos os prazos para garantir uma testagem oportuna.
-- Engenheiro de QA: Este especialista aplica os testes e faz tudo para melhorar a qualidade geral do software, deixando-o em conformidade com as regras de negócio.
+- QA Analyst: Close to the business analyst, they collect all project information, assess risks and weaknesses, and create documentation to describe future development aspects that QA Engineers need to pay attention to.
+- QA Lead: The team's leadership is the person who controls the entire team of experts. In addition, the lead manages tests, creates test plans, processes information received from analysts, observes all deadlines to ensure timely testing.
+- QA Engineer: This specialist applies tests and does everything to improve the overall quality of the software, ensuring that it complies with business rules.
-## Responsabilidades de um time de QA no TI
+## Responsibilities of a QA Team in IT
-O escopo de tarefas do QA deve ser bastante amplo. O time de quality assurance mais uma vez prova sua importância no SLDC.
+The scope of QA tasks should be quite broad. The Quality Assurance team once again proves its importance in SDLC.
-- Planejamentos de Testes: Os analistas planejam o processo de testes, com seus objetivos a atingir e quais abordagens usar.
-- Testes Iniciais: Engenheiros de QA conduzem a testagem inicial para identificar bugs durante a primeira fase de desenvolvimento, de forma a acelerá-la.
-- Execução de Testes: Engenheiros de QA aplicam testes manuais ou automatizados de diferentes tipos em acordo com as particularidades do software.
-- Análise de Defeitos: É necessário analisar todos os defeitos e identificar a razão de sua ocorrência.
-- Relatórios: Especialistas usam sistemas para o rastreio de bugs e criam relatórios para os desenvolvedores com descrições ods bugs e defeitos a serem corrigidos.
-- Colaboração: O time de QA colabora com analsitas de negócio, gerentes de projeto, devs e clientes para atingir a maior qualidade possível para um produto de software.
-- Sumário de Testes e Criação de Reports: Quando um software é testado, engenheiros de QA precisam criar um sumário dos relatórios para demonstrar o nível de qualidade do software.
+- Test Planning: Analysts plan the testing process, with their goals to achieve and which approaches to use.
+- Initial Testing: QA engineers conduct initial testing to identify bugs during the first development phase to expedite it.
+- Test Execution: QA engineers apply manual or automated tests of different types according to the software's peculiarities.
+- Defect Analysis: It is necessary to analyze all defects and identify the reason for their occurrence.
+- Reporting: Experts use bug tracking systems and create reports for developers with descriptions of the bugs and defects to be fixed.
+- Collaboration: The QA team collaborates with business analysts, project managers, developers, and clients to achieve the highest possible quality for a software product.
+- Test Summary and Report Creation: When software is tested, QA engineers need to create reports summarizing the quality level of the software.
-## Qual é o Papel do QA em Desenvolvimento de Projeto?
+## The Role of QA in Project Development
-Quality Assurance no ciclo de vida de desenvolvimento desempenha papel crucial em todos os estágios, como por exemplo:
+Quality Assurance in the software development life cycle plays a crucial role in all stages, such as:
-- Análise de Requerimentos: Em TI, o time de QA colabora com analistas de negócio para desenvolver um estudo de viabilidade das regras de negócio, análise de possíveis riscos, criação de plano de teste e construção da estratégia para a abordagem utilizada na garantia de qualidade (cada projeto requer uma abordagem individual devido as suas particularidades), quais testes usar, etc.
-- Design: É necessario revisão o design, verificar sua estabilidade, checar se sua arquitetura atende todos os requerimentos. Além disso, especialistas de QA produzem diagramas de fluxo de dados em conjunto com designers UI/UX e documentam-os. Por fim, engenheiros de QA testam testam o design após a sua conclusão para imitar o comportamento do usuário final.
-- Desenvolvimento> QA no desenvolvimento de softwares pode ser aplicada uma vez que o software, ou de acordo com a abordagem TDD (Test Driven Development), que define testagens durante o processo de desenvolvimento após cada iteração.
-- QA Pós Lançamento: Uma vez lançado, desenvolvedores devem realizar a manutenção do produto, o time de QA cria, então, guias de usuário e manuais do produto para entrega ao usuário final. Elaborando também documentação de testes para garantir que todos os bugs tenham sido identificados e tudo esteja corrijido.
+- Requirements Analysis: In IT, the QA team collaborates with business analysts to develop a feasibility study of business rules, analyze potential risks, create a test plan, and build a quality assurance approach (each project requires an individual approach due to its specificities), including which tests to use, etc.
+- Design: A review of the design is required, checking its stability, ensuring that its architecture meets all requirements. In addition, QA experts produce data flow diagrams in conjunction with UI/UX designers and document them. Finally, QA engineers test the design after completion to mimic end-user behavior.
+- Development: QA in software development can be applied once the software is developed, or according to the Test-Driven Development (TDD) approach, which defines testing during the development process after each iteration.
+- Post-Launch QA: Once launched, developers must maintain the product. The QA team then creates user guides and product manuals for delivery to end-users. They also create test documentation to ensure that all bugs have been identified and corrected.
-## A Importância do Processo de Quality Assurance
+## The Importance of the Quality Assurance Process
-- Poupa Recursos e Preserva Reputação: Sendo esta última uma das mais importantes. Por exemplo, se você desenvolve um software de trading, e não testou-o corretamente, usuários perderiam dinheiro, e mesmo compensados por suas perdas seria impossível salvar a reputação de seu produto. Portanto, a garantia de qualidade auxilia a detectar bugs antes que usuários os encontrem.
-- Previne Emergências: Imagine que voce encomenda o desenvolvimento de um softare para uso interno, e seus funcionários irão usá-lo para melhor comunicação com clientes. Um bug, mesmo que pequeno, pode levar a severas falhas como perda de dados e quebras de comunicação. Então, será mais complexo recuperar essas informações sem despesas adicionais.
-- Aumenta a Fidelidade de Clientes: Um software livre de bugs significa que clientes não enfrentam problemas au utilizar seu aplicativo. Além disso, se você responde as reclamções de clientes e corrige problemas rapidamente, sua clientela verá que os respeita e aspira aos mais altos niveis de qualidade. Como resultados, sua base de clientes é fidelizada, lucro adicional.
-- Impacta na Produtividade dos Colaboradores: Funcionários podem trabalhar melhor e mais eficientemente quando obstaculos como bugs de software não ficam em seu caminho. Colaboradores, portanto, não perdem tempo tentando descobrir motivos por trás de falhas no software e outros desafios para continuar o trabaho.
-- Torna o Software Mais Seguro: Por fim, a garantia de qualidade contribui para uma aplicação mais segura, elminando vulnerabilidades e defeitos, previnindo ataques maliciosos. O custo dos serviços de QA é incomparável a potenciais perdas financeiras que um empreendimento pode sofrer devido a falta de proteção confiável.
+- Saves Resources and Preserves Reputation: The latter being one of the most important. For example, if you develop trading software and have not tested it correctly, users would lose money, and even compensating for their losses would be impossible to save the reputation of your product. Therefore, quality assurance helps detect bugs before users encounter them.
+- Prevents Emergencies: Imagine that you commission the development of internal use software, and your employees will use it for better communication with clients. Even a small bug can lead to severe failures such as data loss and communication breakdowns. Recovering this information without additional expenses will be more complex.
+- Increases Customer Loyalty: Bug-free software means that customers do not face problems when using your application. Furthermore, if you respond to customer complaints and rectify issues promptly, your clientele will see that you respect them and aspire to the highest levels of quality. As a result, your customer base is retained, leading to additional profit.
+- Impacts Employee Productivity: Employees can work better and more efficiently when obstacles such as software bugs do not get in their way. Employees do not waste time trying to figure out the reasons behind software failures and other challenges to continue their work.
+- Makes Software Safer: Finally, quality assurance contributes to a more secure application by eliminating vulnerabilities and defects, preventing malicious attacks. The cost of QA services is incomparable to potential financial losses that a business can suffer due to a lack of reliable protection.
diff --git a/docs/en/03-admin/03-agile.md b/docs/en/03-admin/03-agile.md
index 9e470e4..9c049c5 100644
--- a/docs/en/03-admin/03-agile.md
+++ b/docs/en/03-admin/03-agile.md
@@ -1,46 +1,46 @@
-# Metodologia Ágil
-
-A metodologia ágil consiste em prática que promove a iteração contínua de desenvolvimento e teste através do SLDC no projeto. Na metodologia Ágil dentro do teste de software, tanto desenvolvimento quanto testes são concomitântes, ao contrário do modelo cascata.
-
-## Em que Consiste o Desenvolvimento de Software Ágil?
-
-Esta metodologia é uma das mais simples e eficientes para tornar a visão das necessidades de um negócio em soluções de software. Ágil é um temro usado para descrever as abordagens de desenvolvimento que aplicam planejamento, aprendizando, melhorias, colaboração em time, desenvolvimento evolucionário e entregas iniciais contínuas, Isto encoraja respostas flexíveis a mudança.
-
-Os quatro valores nucleares da metodologia Ágil são:
-
-- Interações individuais e em time acerca de processos e ferramento;
-- Software Funcional sobre documentação compreensível;
-- Colaboração com cliente sobre negociação de contrato;
-- Responder a mudança sobre seguir um plano;
-
-Metodologia Ágil vs Modelo Cascata
-
-- Metodologia Ágil
- - Metodologias Ágeis proponhem abordagens incrementais e iterativas ao design de software
- - O Processo Ágil na engenharia de software é dividido em modelos individuais que designers se debruçam sobre;
- - O cliente tem oportunidades frequentes e desde o início para ver o produto e realizar decisões ou mudanças no projeto;
- - É considerado inestruturado quando comparado ao modelo cascata
- - Projetos pequenos podem ser implementados rapidamente, já projetos grandes é difícil estimar o tempo de desenvolvimento;
- - Erros podem ser corrigidos no meio do projeto;
- - O processo de desenvolvimento é iterativo, e o projeto é executado em iterações curtas (2-4 semanas)
- - Documentação possui menor prioridade do que desenvolvimento de software;
- - Cada iteração tem sua própria fase de testes. Isto permite o implemento de testes de regressão toda vez que uma nova funcionalidade ou lógica for lançada;
- - No teste Ágil quando uma iteração termina, features enviáveis do produto são entregues ao cliente. Novas features são usáveis logo após o envio, o que é útil quando se tem bom contato com clientes;
- - Devs e testers trabalham juntos;
- - No fim de cada sprint, a aceitação de usuário é aplicada;
- - Requer comunicação próxima com desenvolvedores, para juntos analisar requerimentos e planejamentos;
-
-- Modelo Cascata:
- - Desenvolvimento do software flue sequencialmente do começo ao fim;
- - O processo de design não é subdividido em modelos individuais
- - O cliente pode ver o produto apenas no fim do projeto;
- - Modelo cascata é mais seguro por ser orientado pelos planos;
- - Todos os tipos dep rojetos podem ser estimados e completos;
- - Apenas no fim, o produto inteiro é testado. Se erros são localizados ou quaisquer mudanças forem feitas, o projeto começa todo de novo;
- - O processo de desenvolvimento se da por estágios, e o estágio é muito maior que uma iteração. Cada estágio termina com uma descrição detalhada do próximo;
- - Documentação é de altíssima prioridade e pode ser usada inclusive para treinar colaboradores e melhorar o software com outro time;
- - Apenas após a fase de desenvolvimento a testagem se inicia, pois partes separadas não são completamente funcionais;
- - Todas as features desenvolvidads são entregues de uma vez após uma longa fase de implementação;
- - Testers trabalham de forma separada dos devs;
- - Aceitação de usuários é aplicada no fim do projeto;
- - Devs não se envolvem nos processos de regras de negócio e planejamento. Geralmente, existem atrasos entre testes e código;
+# Agile Methodology
+
+The Agile methodology consists of practices that promote continuous development and testing iteration throughout the Software Development Life Cycle (SDLC) in a project. In the Agile methodology for software testing, both development and testing occur concurrently, unlike the waterfall model.
+
+## What Does Agile Software Development Entail?
+
+This methodology is one of the simplest and most efficient approaches to translate a business's needs into software solutions. Agile is a term used to describe development approaches that emphasize planning, learning, improvements, team collaboration, evolutionary development, and continuous early deliveries. This encourages flexible responses to change.
+
+The four core values of the Agile methodology are:
+
+- Individual and team interactions over processes and tools.
+- Working software over comprehensive documentation.
+- Customer collaboration over contract negotiation.
+- Responding to change over following a plan.
+
+Agile Methodology vs. Waterfall Model
+
+- Agile Methodology
+ - Agile methodologies propose incremental and iterative approaches to software design.
+ - The Agile process in software engineering is divided into individual models that designers work on.
+ - The customer has frequent opportunities from the beginning to see the product and make decisions or changes to the project.
+ - It is considered less structured compared to the waterfall model.
+ - Small projects can be implemented quickly, while large projects may have difficulty estimating development time.
+ - Errors can be corrected during the project.
+ - The development process is iterative, and the project is executed in short iterations (2-4 weeks).
+ - Documentation has lower priority than software development.
+ - Each iteration has its own testing phase. This allows the implementation of regression tests whenever a new feature or logic is introduced.
+ - In Agile testing, when an iteration ends, shippable product features are delivered to the customer. New features are usable right after delivery, which is useful when there is good customer contact.
+ - Developers and testers work together.
+ - At the end of each sprint, user acceptance is applied.
+ - Close communication with developers is required to jointly analyze requirements and planning.
+
+- Waterfall Model
+ - Software development flows sequentially from beginning to end.
+ - The design process is not divided into individual models.
+ - The customer can only see the product at the end of the project.
+ - The waterfall model is more secure because it is plan-driven.
+ - All types of projects can be estimated and completed.
+ - Only at the end is the entire product tested. If errors are found or changes are made, the project starts over.
+ - The development process occurs in stages, and each stage is much larger than an iteration. Each stage ends with a detailed description of the next.
+ - Documentation is of high priority and can be used for training employees and improving the software with another team.
+ - Testing only begins after the development phase because separate parts are not fully functional.
+ - All developed features are delivered at once after a long implementation phase.
+ - Testers work separately from developers.
+ - User acceptance is applied at the end of the project.
+ - Developers are not involved in business rule and planning processes. There are typically delays between testing and coding.
diff --git a/docs/en/03-admin/04-scrum.md b/docs/en/03-admin/04-scrum.md
index 6d91c62..6b49058 100644
--- a/docs/en/03-admin/04-scrum.md
+++ b/docs/en/03-admin/04-scrum.md
@@ -1,108 +1,108 @@
# Scrum
-Em testagem de software o Scrum é uma metodologia utilizada para construir aplicações complexas. Ela provê soluções fáceis para execução de tarefas complexas. Scrum auxilia o time de desenvolvimento a focas em todos os aspectos do desenvolvimento de um produto de software, como qualidade, performance, usabilidade, etc. Gera transparência, inspeção e adaptação durante o SLDC para evitar complexibilidade.
+In software testing, Scrum is a methodology used for building complex applications. It provides straightforward solutions for executing intricate tasks. Scrum assists the development team in focusing on all aspects of software product development, such as quality, performance, usability, etc. It generates transparency, inspection, and adaptation during the Software Development Life Cycle (SDLC) to avoid complexity.
-
+
-## Testagem Scrum
+## Scrum Testing
-É feita na metodologia scrum para validar as regras de negócio, e envolve a checagem de parâmetros não funcionais. Não existe papel ativo do tester no processo então é usualmente desenvolvida por developers com Testes Unitários. Por vezes times de testes dedicados são necessários a depender da natureza e complexidade do projeto.
+Scrum testing is performed to validate business rules and involves checking non-functional parameters. There is no active role for testers in the process, so it is usually developed by developers using Unit Testing. Dedicated testing teams may be required depending on the nature and complexity of the project.
-## Características Chave da Metodologia Scrum
+## Key Characteristics of the Scrum Methodology
-- Scrum possui agendas curtas para ciclos de lançamento com escopos ajustavens conhecidas como sprints. Cada realease pode possuir múltiplas sprints, e cada projeto Scrum pdoe possuir múltiplos ciclos de lançamento;
-- Uma sequência repetitiva de reuniões, eventos e milestones;
-- A prática de testagem e implementação de novas regras de negócio, conhecida como estórias, para garantir que part e do trabalho é lançada logo após cada sprint;
+- Scrum has short schedules for release cycles with adjustable scopes known as sprints. Each release may have multiple sprints, and each Scrum project may have multiple release cycles.
+- A repetitive sequence of meetings, events, and milestones.
+- The practice of testing and implementing new business rules, known as user stories, to ensure that parts of the work are released shortly after each sprint.
-
+
-### 1. Papéis no Scrum
+### 1. Roles in Scrum
- Product Owner:
- - Define as features do produto;
- - Decide a data de lançamentos e features relacionadas;
- - É responsável pela rentabilidade do produto;
- - Pode aceitar ou rejeitar um resultado;
+ - Defines product features.
+ - Decides release dates and related features.
+ - Is responsible for the product's profitability.
+ - Can accept or reject a result.
- Scrum Master:
- - Organiza o time e verifica sua produtividade;
- - Mantém a lista de bloqueios e remove barreiras no desenvolvimento;
- - Coordena com todos os papéis e funções;
- - Defente o time de interferências externas;
- - Convida para o Scrum diário, review da sprint e planejamento de reuniões;
+ - Organizes the team and checks its productivity.
+ - Maintains the list of impediments and removes barriers in development.
+ - Coordinates with all roles and functions.
+ - Defends the team from external interference.
+ - Invites to daily Scrum, sprint review, and planning meetings.
-- O Time:
- - Consiste geralmente de 5-9 membros;
- - Inclui desenvolvedores, designers, testers, etc;
- - O Time organiza e planeja o trabalho sozinhos;
- - Tem o direito de fazer tudo dentro das demarcações do projeto para atingir o objetivo da sprint;
- - Ativamente participa das cerimônias diárias
+- The Team:
+ - Typically consists of 5-9 members.
+ - Includes developers, designers, testers, etc.
+ - The team organizes and plans the work on its own.
+ - Has the authority to do everything within the project boundaries to achieve the sprint goal.
+ - Actively participates in daily ceremonies.
-### 2. Artefatos Scrum
+### 2. Scrum Artifacts
-
+
-Um processo Scrum, inclúi:
+A Scrum process includes:
-- Estórias de Usuários: São uma explicação curta das funcionalidades do sistema sob testes. Um exemplo para uma agência de seguros é - "Premium pode ser pago usando o sistema online";
-- Backlog do Produto: É uma coleção de estórias de usuários capturadas para um projeto Scrum. O P.O prepara e mantém este backlog. É priorizado pelo P.O, e qualquer um pode adicionar dados com sua aprovação;
-- Backlog de Lançamento: Um lançamento é um lapso temporal em que um número de iterações é completa. O P.O coordena com o Scrum Master para decidir quais estórias devem ser priorizadas em uma release. Estórias no backlog de lançamento são priorizadas para finalização em uma release;
-- Sprints: É um espaço de tempo determinado para finalização das histórias de usuário, decidida pelo P.O e time de desenvolvemento, geralmente 2-4 semanas;
-- Sprint Backlog: É um grupo de histórias de usuários a serem finalizadas em uma sprint. Durante o sprint backlog, o trabalho nunca é designado, e o time se habilita para um trabalho por si só. É de posse e administração do time enquanto o trabalho restante estimado é atualizado diariamente. É a lista de tasks que devem ser desenvolvidas em uma sprint;
-- Lista de Blocks: É uma lista de blocks e decisões que não foram realizadas, de posse de Scrum Master e atualizada diariamente;
-- Gráfico Burndown: Representa o progresso geral entre trabalho em desenvolvimento e trabalho completo através de todo o processo. Representa em forma de gráfico as histórias e features não finalizadas;
+- User Stories: Short explanations of system features under test. An example for an insurance agency is, "Premium can be paid using the online system."
+- Product Backlog: A collection of user stories captured for a Scrum project. The Product Owner prepares and maintains this backlog. It is prioritized by the Product Owner, and anyone can add items with their approval.
+- Release Backlog: A release is a time span in which a number of iterations are completed. The Product Owner coordinates with the Scrum Master to decide which user stories should be prioritized in a release. User stories in the release backlog are prioritized for completion in a release.
+- Sprints: A defined time frame for completing user stories, decided by the Product Owner and the development team, typically 2-4 weeks.
+- Sprint Backlog: A group of user stories to be completed in a sprint. During the sprint backlog, work is never assigned, and the team self-assigns tasks. It is owned and managed by the team, while remaining estimated work is updated daily. It is the list of tasks to be developed in a sprint.
+- Blockers List: A list of blocks and decisions not yet made, owned by the Scrum Master and updated daily.
+- Burndown Chart: Represents the overall progress between work in progress and work completed throughout the entire process. It graphically shows unfinished user stories and features.
-### 3. Cerimônias (Processos) em Scrum
+### 3. Ceremonies (Processes) in Scrum
-- Planejamento de Sprints: Uma sprint se inicia com o time importando estórias do Backlog de Lançamentos para o Backlog de Sprints. Os testers estimam o esforço para validar as diversas histórias no Sprint Backlog;
-- Scrum Diário: Apresentado pelo Scrum Master, dura cerca de 15 minutos. Durante o Scrum diário os membros irão discutir o trabalho completo no dia anterior, o trabalho planejado para o dia seguinte e dificuldades encontradas durante uma sprint. No decorrer da reunião diária o progresso de um time é rastreado;
-- Review da Sprint/Retrospectiva: Também apresentada pelo Scrum Master, dura entre 2-4 horas e discute o que o time desenvolveu na última sprint e que lições foram aprendidas;
+- Sprint Planning: A sprint begins with the team importing user stories from the Release Backlog into the Sprint Backlog. Testers estimate the effort to validate the various user stories in the Sprint Backlog.
+- Daily Scrum: Facilitated by the Scrum Master, it lasts about 15 minutes. During the Daily Scrum, team members discuss the work completed the previous day, planned work for the next day, and challenges encountered during a sprint. The team's progress is tracked during the daily meeting.
+- Sprint Review/Retrospective: Also facilitated by the Scrum Master, it lasts 2-4 hours and discusses what the team developed in the last sprint and what lessons were learned.
-## Papel do Tester no Scrum
+## Role of the Tester in Scrum
-**Não há papel ativo do tester no Processo Scrum.**
+**There is no active role for testers in the Scrum process.**
-Geralmente, os testes são desenvolvidos por um dev com o Teste Unitário. Enquanto o P.O é também frequentemente envolvido no processo de testes em cada sprint. Alguns projetos Scrum tem times de teste dedicados dependendo da natureza e complexibilidade do projeto.
+Usually, tests are developed by a developer with Unit Testing. The Product Owner is often involved in the testing process in each sprint. Some Scrum projects have dedicated testing teams depending on the nature and complexity of the project.
-## Atividades de Teste no Scrum
+## Testing Activities in Scrum
-- Planejamento de Sprints:
- - Aqui o tester deve escolher uma estória de usuário do backlog de produto para testes.
- - Como tester, deve decidir quantas horas (Estimativa de Esforço) levará para finalizar os testes para cada estória selecionada.
- - Deve saber quais os objetivos da sprint.
- - Contribuir para o proesso de priorização.
+- Sprint Planning:
+ - Here, the tester should choose a user story from the product backlog for testing.
+ - As a tester, they must decide how many hours (Effort Estimation) it will take to complete testing for each selected user story.
+ - They should know the sprint's objectives.
+ - Contribute to the prioritization process.
- Sprints:
- - Dão suporte a devs no teste unitário
- - Com testes de histórias de usuário completos, a execução de teste é desenvolvida em laboratório onde dev e tester trabalham juntos. Defeitos são catalogados na ferramenta de Gerenciamento de defeitos que são verificados diariamente. Defeitos podem ser conferidos e analisados durante uma reunião Scrum. Quaisquer bugs são retestados tão logo corrigidos e implementados para teste.
- - Enquanto tester, comparecer a todas as reuniões diárias para falar;
- - Trazers quaisquer itens de backlog que não foram completos na sprint atual, para inserção na proxima sprint;
- - Tester é resposável pelo desenvolvimento dos scripts de automação. Ele agenda as testagens automatizadas com o Sistema de Integração Contínuo (CI). Automatização recebe importância devido aos tempos de entrega curtos. Automatização de testes pode ser atingida utilizando diversas ferramentas pagas ou open-source disponíveis. Isto prova sua eficiência ao garantir que tudo que precisa ser testado esteja coberto. Cobertura de Testes Satisfatória pode ser atingida com uma comunicação proxima com o time.
- - Revisão dos resultados da Automação no CI e envio de Relatórios para os Investidores.
- - Execução de testes não funcionais para estórias de usuários aprovadas.
- - Coordenação com cliente e P.O para definir critérios de aceite para os Testes de Aceite.
- - No fim da Sprint, o tester também performa o UAT em alguns casos, e confirma a finalização dos testes para a sprint atual.
+ - Support developers in unit testing.
+ - With user story tests complete, the testing execution is done in a lab where the developer and tester work together. Defects are logged in the Defect Management tool, which is checked daily. Defects can be reviewed and discussed during a Scrum meeting. Any bugs are retested as soon as they are fixed and implemented for testing.
+ - As a tester, attend all daily meetings to provide input.
+ - Bring any backlog items not completed in the current sprint for inclusion in the next sprint.
+ - The tester is responsible for developing automation scripts. They schedule automated tests with the Continuous Integration (CI) system. Test automation is given importance due to short delivery times. Test automation can be achieved using various paid or open-source tools available. This proves its efficiency in ensuring that everything that needs to be tested is covered. Satisfactory test coverage can be achieved with close communication with the team.
+ - Review automation results in the CI and send reports to stakeholders.
+ - Execute non-functional tests for approved user stories.
+ - Coordinate with the client and Product Owner to define acceptance criteria for Acceptance Testing.
+ - At the end of the sprint, the tester may also perform User Acceptance Testing (UAT) in some cases and confirm the completion of testing for the current sprint.
-- Retrospectiva da Sprint:
- - Enquanto tester, ira estabelecer o que deu errado e o que obteve sucesso na sprint atual.
- - Identifica lições aprendidas e melhores práticas.
+- Sprint Retrospective:
+ - As a tester, establish what went wrong and what was successful in the current sprint.
+ - Identify lessons learned and best practices.
-## Relatório de Testes
+## Test Report
-Métricas de teste Scrum provém transparência e visibilidade para os investidores sobre o projeto. As métricas reportadas permitem que um time analise seu progresso e planeje estratégias futuras para melhoria do produto.
+Scrum testing metrics provide transparency and visibility for stakeholders about the project. The reported metrics allow a team to analyze their progress and plan future strategies for product improvement.
-Existem duas métricas frequentimente usadas para reportar:
+There are two metrics commonly used for reporting:
-### Gráfico Burn Down
+### Burn Down Chart
-Diariamente, o Scrum Master registra o trabalho restante estiamdo para a sprint atual. O que nada mais é do que o Burn Down, atualizado diariamente.
+Daily, the Scrum Master records the estimated remaining work for the current sprint, which is nothing but the Burn Down, updated daily.
-Este grafico provê visualização geral rápida do progresso no projeto, aqui, temos informações como o volume total de trabalho no projeto que precisa ser finalizado, volume de trabalho completo em cada sprint e etc.
+This chart provides a quick overall view of project progress, showing information such as the total volume of work in the project that needs to be completed, work completed in each sprint, and more.
-
+
-### Gráfico de Histórico de Velocidade
+### Velocity Chart
-Esta técnica prevê a velocidade do time em cada sprint, É um gráfico de barras que representa como o output do time mudou ao longo.
+This technique predicts the team's velocity in each sprint, represented as a bar chart showing how the team's output has changed over time.
-As métricas adicionais que podem ser úteis consistem na queima de cronograma, queima de orçamento, porcentagem do tema completo, estórias completas, estórias remanescentes, etc.
+Additional useful metrics include schedule burn, budget burn, percentage of theme completed, completed stories, remaining stories, etc.
diff --git a/docs/en/03-admin/05-kanban.md b/docs/en/03-admin/05-kanban.md
index 5a51805..e4c8ae8 100644
--- a/docs/en/03-admin/05-kanban.md
+++ b/docs/en/03-admin/05-kanban.md
@@ -1,101 +1,99 @@
# Kanban
-O Kanban é uma estrutura popular usada para implementar o desenvolvimento de software Ágil e DevOps, requer comunicação em tempo real de capacidade e transparência de trabalho.
+Kanban is a popular framework used to implement Agile and DevOps software development, requiring real-time communication of capacity and work transparency.
-Itens de trabalho são representados visualmente num painél Kanban, permitindo que os membros do time vejam o estado de cada setor do projeto a qualquer momento.
+Work items are visually represented on a Kanban board, allowing team members to see the state of each project sector at any given time.
-## O que é um Painél Kanban
+## What Is a Kanban Board
-É uma ferramenta de gerenciamento de projetos Ágeis que auxiliam na visualização clara do projeto, maximizando eficiência (ou fluxo).
+It is an Agile project management tool that aids in clear project visualization, maximizing efficiency (or flow).
-Isto auxilia tanto times Ágeis quanto DevOps em seu dia-a-dia de trabalho. Painéis Kanban usam cards, colunas e melhoria contínua para auxiliar times serviços e tecnologias a empenharem-se na quantidade correta de trabalho.
+This aids both Agile and DevOps teams in their day-to-day work. Kanban boards use cards, columns, and continuous improvement to help service and technology teams engage in the right amount of work.
-## Elementos de um Painél Kanban
+## Elements of a Kanban Board
-Painés podem ser dividos em cinco componentes:
+Boards can be divided into five components:
-1. Sinais Visuais;
-2. Colunas;
-3. Limites de Trabalho em Progresso;
-4. Ponto de Comprometimento;
-5. Ponto de Entrega;
+1. Visual Signals;
+2. Columns;
+3. Work in Progress (WIP) Limits;
+4. Commitment Point;
+5. Delivery Point;
-### 1. Sinais Visuais
+### 1. Visual Signals
-Um dos primeiros elementos perceptíveis sobre o painél são os cards visuais (adesivos, tickets, etc). Times Kanban escrevem todos seus projetos e items de trabalho em cards, geralmente um por card. Para times Ágeis, cada card pode encapsular uma estória de usuário. Uma vez no painél, estes sinais visuais auxiliam membros do time e investidores a rapidamente entender no que o time está focado.
+One of the first noticeable elements on the board is visual cards (stickers, tickets, etc.). Kanban teams write all their projects and work items on cards, usually one per card. Once on the board, these visual signals help team members and stakeholders quickly understand what the team is focusing on.
-### 2. Colunas
+### 2. Columns
-Outra marca registrada no painél Kanban são as Colunas. Cada coluna representa uma atividade específica que juntas compõem um fluxo de trabalho.
+Another hallmark of the Kanban board is the Columns. Each column represents a specific activity that, together, forms a workflow.
-Cards fluem através deste fluxo até estarem completos.
+Cards flow through this workflow until they are complete.
-Fluxos de Trabalhos podem ser tão simples quanto "A Fazer", "Em Progresso", "Completo" ou bem mais complexas.
+Workflows can be as simple as "To Do," "In Progress," "Done," or much more complex.
-### 3. Limites de Work in Progress (WIP)
+### 3. Work in Progress (WIP) Limits
-Número máximo de cards que podem estar em uma coluna a qualquer momento. Uma coluna com um limite WIP de três não podem conter mais do que três cards em si.
+The maximum number of cards that can be in a column at any time. A column with a WIP limit of three cannot contain more than three cards.
-Quando a coluna atinge seu máximo, o time precisa focar nestes cards para movê-los adiante, abrindo espaço para novos cards entrarem neste estágio do workflow.
+When the column reaches its maximum, the team must focus on these cards to move them forward, making room for new cards to enter this stage of the workflow.
-Estes limites WIP são críticos para expor gargalos na produção e maximizar o fluxo. Limites WIP provém avisos prévios de que você inscreveu-se em trabalho demais.
+These WIP limits are critical for exposing production bottlenecks and maximizing flow. WIP limits provide advance warnings that you have taken on too much work.
-### 4. Ponto de Compromisso
+### 4. Commitment Point
-Times Kanban usualmente possuem um backlog de seus painéis. É aqui que clientes e parceiros de time inserem ideias para projetos que o time pode assumir quando estiverem prontos. O ponto de compromisso é o momento em que uma idéia é assumida pelo time e o trabalho inicia-se no projeto.
+Kanban teams usually have a backlog on their boards. This is where customers and team partners enter project ideas that the team can take on when ready. The commitment point is when an idea is taken on by the team, and work begins on the project.
-### 5. Ponto de Entrega
+### 5. Delivery Point
-É o fim do fluxo de trabalho para um time Kanban.
+It is the end of the workflow for a Kanban team.
-Para a maioria dos times, o ponto de entrega é quando o produto ou serviço está nas mãos do cliente. O objetivo da equipe é levar os cards do commitment para a entrega o mais rápido quanto possível. O período de tempo entre os dois pontos pode ser chamado de Lead Time, times Kanban continuamente esforçam-se para melhorar e diminuir este tempo ao máximo.
+For most teams, the delivery point is when the product or service is in the hands of the customer. The team's goal is to take the cards from commitment to delivery as quickly as possible. The time between these two points can be called Lead Time, and Kanban teams continuously strive to improve and minimize this time.
- Jim Benson diz que o Kanban possui apenas duas regras:
+Jim Benson says that Kanban has only two rules:
- "Limite o WIP e visualize seu trabalho. Se começar apenas com estas duas regras e aplicá-las ao seu trabalho, seu painél Kanban será bastante diferente do descrito acima. E tá tudo bem!"
+"Limit WIP and visualize your work. If you start with just these two rules and apply them to your work, your Kanban board will be quite different from the one described above. And that's okay!"
-## Tipos e Exemplos de Painéis Kanban
+## Types and Examples of Kanban Boards
-O Kanban pode ser adaptado para diversos ambientes, desde a manufatura até os recursos humanos, do Ágil ao DevOps.
+Kanban can be adapted to various environments, from manufacturing to human resources, from Agile to DevOps.
-O Tipo de ambiente adaptando o Kanban muitas vezes dita se o painél é físico ou digital.
+The type of environment adapting Kanban often dictates whether the board is physical or digital.
-## Painéis Físicos
+## Physical Boards
-Os painéis mais simples de Kanban são quadros físicos divididos em colunas. Times marcam o quadro com post-its, que se movem através do workflow demonstrando progresso.
+The simplest Kanban boards are physical boards divided into columns. Teams mark the board with Post-its, which move through the workflow, showing progress.
-Uma vantagem de quadros físicos é que "está sempre ligado". Você não pode abrir uma aba nova em um quadro branco enorme logo ao lado da sua mesa"
+An advantage of physical boards is that "it's always on." You can't open a new tab on a huge whiteboard right next to your desk.
-É simples e fácil de montar, mas por vezes, a tela física não é ideal para times remotos.
+It is simple and easy to set up, but sometimes the physical screen is not ideal for remote teams.
-## Quadros Digitais
+## Digital Boards
-Enquanto o sistema Kanban ganhou espaço com os times de software e engenharia, sofreu.
+While the Kanban system gained popularity with software and engineering teams, it has suffered.
-Painéis digitais permitem que times que não dividem espaços físicos possam usar quadros Kanban remotamente e de forma assíncrona.
+Digital boards allow teams that do not share physical spaces to use Kanban boards remotely and asynchronously.
-A plataforma Trello oferece uma forma rápida e fácil de criar painéis Kanban virtualmente.
+The Trello platform provides a quick and easy way to create virtual Kanban boards.
-As vantagens de um quadro Kanban virtual estão na velocidade ed configuração, facilidade de compartilhamento e o caráter assíncrono do infinito número de conversas e comentários ao longo do projeto. Não importa onde ou quando os membros do projeto chequem o painél, eles verão o status mais atualizado. Além disso, voce pode usar um workflow construído em Trello para seus afazeres pessoais.
+The advantages of a virtual Kanban board include setup speed, ease of sharing, and the asynchronous nature of the countless conversations and comments throughout the project. No matter where or when project members check the board, they will see the most up-to-date status. In addition, you can use a Trello built-in workflow for your personal tasks.
## Kanban vs Scrum
-As diferenças entre Kanban e Scrum são bastante sutis. Na maioria das interpretações, os times Scrum utilizam um quadro Kanban, mas com processos, artefatos e papéis Scrum dentro dele. Existem, entretanto, diferenças chave:
+The differences between Kanban and Scrum are quite subtle. In most interpretations, Scrum teams use a Kanban board but with Scrum processes, artifacts, and roles within it. However, there are key differences:
-- Sprints Scrum tem datas de início e fim, enquanto o Kanban é um processo contínuo;
-- Funções do time são claramente definidas no Scurm (P.O, devs, Scrum Master), enquanto Kanban não possui papéis formais. Ambos os times são bem organizados;
-- Um painél Kanban é utilizado através do ciclo de um projeto, enquanto um quadro Scrum é limpo e reciclado após cada sprint.
-- Quadros Scrum possuem um número determinado de tarefas e datas de entregas fixadas;
-- Painéis Kanban são mais flexíveis no que tange a tarefas e limites de tempo. Tarefas podem ser repriorizadas, redesignadas ou atualizadas conforme necessário.
+- Scrum sprints have start and end dates, while Kanban is a continuous process.
+- Team roles are clearly defined in Scrum (Product Owner, developers, Scrum Master), while Kanban has no formal roles. Both teams are well-organized.
+- A Kanban board is used throughout the project lifecycle, while a Scrum board is cleared and recycled after each sprint.
+- Scrum boards have a fixed number of tasks and set delivery dates.
+- Kanban boards are more flexible regarding tasks and time limits. Tasks can be reprioritized, reassigned, or updated as needed.
-Tanto o Kanban quanto o Scrum são estruturas Ágil populares entre desenvolvedores de software.
+Both Kanban and Scrum are popular Agile frameworks among software developers.
-## Iniciando um Quadro Kanban
+## Starting a Kanban Board
-Kanban é um método "comece com o que sabe". Isto significa que você não precisa descobrir o que fará a seguir para iniciar o Kanban. O método presume três coisas:
+Kanban is a "start with what you know" method. This means you don't have to figure out what to do next to start Kanban. The method assumes three things:
-1. Você compreende os processos atuais, enquanto eles são aplicados, e respeita os papés, responsabilidades e hieriarquias atuais;
-
-2. Você concorda em perseguir a melhoria contínua através da mudança evolucionária;
-
-3. Você encoraja atos de liderança em todos os níveis, de colaboradores até gerentes sênior;
+1. You understand the current processes as they are applied and respect the current roles, responsibilities, and hierarchies.
+2. You agree to pursue continuous improvement through evolutionary change.
+3. You encourage acts of leadership at all levels, from team members to senior managers.
diff --git a/docs/en/03-admin/06-waterfall.md b/docs/en/03-admin/06-waterfall.md
index 4465075..5299f6b 100644
--- a/docs/en/03-admin/06-waterfall.md
+++ b/docs/en/03-admin/06-waterfall.md
@@ -1,51 +1,51 @@
-# Modelo Cascata
+# Waterfall Model
-É uma estrutura sequencial que divide o desenvolvimento de software em fases pré-definidas. Cada uma deve ser completa antes que a próxima possa ser iniciada, sem sobreposição entre fases.
+It is a sequential framework that divides software development into predefined phases. Each one must be completed before the next one can begin, with no overlap between phases.
-Cada etapa é estruturada para desenvolver uma atividade específica durante a fase SDLC.
+Each stage is structured to carry out a specific activity during the SDLC phase.
-
+
-## Etapas do Modelo Cascata
+## Stages of the Waterfall Model
-- Fase de Coleta das Regras de Negócio: Coleta de tantas informações quanto possíveis acerca dos detalhes e especificações do software desejado pelo cliente.
+- Business Requirement Gathering Phase: Gathering as much information as possible about the details and specifications of the software desired by the client.
-- Fase de Design: Planejamento da linguagem de programação a ser utilizada, database, etc. Que deve adequar-se ao projeto, bem como funções de alto nível e arquitetura.
+- Design Phase: Planning the programming language to be used, the database, etc. It should fit the project, as well as high-level functions and architecture.
-- Fase de Construção: Após o Design, passamos a construir de fato o código do software.
+- Construction Phase: After the Design, we proceed to actually build the software code.
-- Fase de Testes: Após, testamos o software para verificar que foi feito conforme as especificações fornecidas pelo cliente.
+- Testing Phase: Afterward, we test the software to verify that it has been created according to the specifications provided by the client.
-- Fase de Implementação: Implementa a aplicação no ambiente designado.
+- Implementation Phase: It implements the application in the designated environment.
-- Fase de Manutenção: Uma vez que o sistema está pronto para uso, pode ser necessário alterar o código mais tarde a depender de solicitações dos usuários.
+- Maintenance Phase: Once the system is ready for use, it may be necessary to change the code later depending on user requests.
-## Quando Utilizar o Modelo Cascata?
+## When to Use the Waterfall Model?
-Pode ser aplicado quando:
+It can be applied when:
-- Requerimentos não mudam constantemente;
-- Aplicação não é demasiadamente complexa;
-- O projeto é curto;
-- Regras de Negócio são claras;
-- O ambiente é estável;
-- Tecnologia e ferramentas usadas não dinâmicas, mas sim estáveis;
-- Recursos são disponíveis e direcionados;
+- Requirements do not change constantly;
+- The application is not overly complex;
+- The project is short;
+- Business rules are clear;
+- The environment is stable;
+- Technology and tools used are not dynamic but stable;
+- Resources are available and directed;
-### Vantagens Modelo Cascata
+### Advantages of the Waterfall Model
-1. Antes da próxima ffase de desenvolvimento, a anterior deve estar completa;
-2. Apropriada para projetos menores os requerimentos são bem definidos;
-3. Deve-se aplicar os testes de Quality Assurance (verificação e validação) antes de completar cada estágio;
-4. O desenvolvimento da documentação é feito em cada fase do SDLC;
-5. O projeto é completamente dependente do time, com intervenção mínima do cliente;
-6. Quaisquer mudanças no software são feitas durante o processo de desenvolvimento;
+1. Before the next development phase, the previous one must be completed.
+2. Suitable for smaller projects with well-defined requirements.
+3. Quality Assurance (verification and validation) tests should be applied before completing each stage.
+4. Documentation development is done at each stage of the SDLC.
+5. The project is entirely dependent on the team, with minimal customer involvement.
+6. Any changes to the software are made during the development process.
-### Desvatagens do Modelo Cascata
+### Disadvantages of the Waterfall Model
-1. Erros só podem ser corrigidos na etapa;
-2. Não é desejável para projetos complexos onde requerimentos mudem constatemente;
-3. Período de teste só ocorre nas etapas mais avançadas do processo de desenvolvimento;
-4. Documentação ocupa bastante do tempo de desenvolvedores e testers;
-5. O valioso feedback de clientes não pode ser incluído no processo de desenvolvimento já em execução;
-6. Pequenas mudanças ou erros que surgir no software finalizado podem gerar grandes problemas;
+1. Errors can only be fixed in the next stage.
+2. Not suitable for complex projects where requirements change constantly.
+3. The testing period only occurs in the later stages of the development process.
+4. Documentation takes up a significant amount of developers' and testers' time.
+5. Valuable customer feedback cannot be included in the ongoing development process.
+6. Small changes or errors that arise in the finished software can lead to major problems.
diff --git a/docs/en/03-admin/07-v-model.md b/docs/en/03-admin/07-v-model.md
index 3bc6250..4fabe66 100644
--- a/docs/en/03-admin/07-v-model.md
+++ b/docs/en/03-admin/07-v-model.md
@@ -1,41 +1,39 @@
-# Modelo V
+# V-Model
-É uma estrutura de SLDC altamente disciplinada que possui uma faze de testes paralela a cada etapa de desenvolvimento.
+It is a highly disciplined SDLC framework that has a parallel testing phase for each development step.
-O modelo V é uma extensão da modalidade de Cascata onde o desenvolvimento e testes são executados sequencialmente. Também conhecido como modelo de Validação ou de Verificação.
+The V-Model is an extension of the Waterfall model where development and testing are performed sequentially. It is also known as the Validation or Verification model.
-
+
-## Exemplificação Cascata vs V
+## Comparison of Waterfall vs. V-Model
-Considere a seguinte sequência de passos:
+Consider the following sequence of steps:
-- Fase de Coleta das Regras de Negócio: Coleta de tantas informações quanto possíveis acerca dos detalhes e especificações do software desejado pelo cliente.
+- Business Requirement Gathering Phase: Gathering as much information as possible about the details and specifications of the software desired by the client.
-- Fase de Design: Planejamento da linguagem de programação a ser utilizada, database, etc. Que deve adequar-se ao projeto, bem como funções de alto nível e arquitetura.
+- Design Phase: Planning the programming language to be used, the database, etc. It should fit the project, as well as high-level functions and architecture.
-- Fase de Construção: Após o Design, passamos a construir de fato o código do software.
+- Construction Phase: After the Design, we proceed to actually build the software code.
-- Fase de Testes: Após, testamos o software para verificar que foi feito conforme as especificações fornecidas pelo cliente.
+- Testing Phase: Afterward, we test the software to verify that it has been created according to the specifications provided by the client.
-- Fase de Implementação: Implementa a aplicação no ambiente designado.
+- Implementation Phase: It implements the application in the designated environment.
-- Fase de Manutenção: Uma vez que o sistema está pronto para uso, pode ser necessário alterar o código mais tarde a depender de solicitações dos usuários.
+- Maintenance Phase: Once the system is ready for use, it may be necessary to change the code later depending on user requests.
-**Todas estas etapas constituem o modelo CASCATA, de desenvolvimento.**
+**All these steps constitute the WATERFALL development model.**
-### Problemas com o modelo Cascata
+### Issues with the Waterfall Model
-Como pode observar, os testes são realizados apenas após a implementação estar finalizada.
+As you can see, testing is only performed after the implementation is completed. However, when working on a large project where systems are complex, it's easy to overlook key details in the initial phase. In such cases, a completely incorrect product will be delivered to the client, and there is the possibility of starting the entire project over.
-Mas se você estiver trabalhando em um projeto grande, onde os sistemas são complexos, é fácil perder detalhes chave na própria fase inicial. Nestes casos, um produto completamente errado será entregue ao cliente e existe a possibilidade de recomeçar todo o projeto.
+In this way, the costs of correcting defects increase as we progress in the SDLC. The earlier they are detected, the cheaper they will be to fix.
-Desta forma, os custos de corrigir defeitos aumentam a medida que progredimos no SDLC. Quanto mais cedo detectados, mais baratos serão para corrigir.
+## Solution: V-Model
-## Solução: Modelo V
+To address these conflicts, the V-Model was developed so that each development phase has a corresponding testing phase.
-Para endereçar estes conflitos, o modelo de testagem em V foi desenvolvido de forma que cada fase de desenvolvimento possui uma fase de testes correspondente.
+In addition to the V-Model, there are other categories of iterative development where each phase adds functionality to the project in stages. Each stage comprises an independent group of cycles for testing and development.
-Além do modelo V existem outras categorias de desenvolvimento iterativo, onde cada fase adiciona uma funcionalidade ao projeto em etapas. Cada etapa compreende um grupo independente de ciclos para teste e desenvolvimento.
-
-Exemplos destes métodos iterativos são o Desenvolvimento Ágil e o Desenvolvimento de Aplicação Rápida.
+Examples of these iterative methods are Agile Development and Rapid Application Development.
diff --git a/docs/en/03-admin/08-report.md b/docs/en/03-admin/08-report.md
index 534d80e..4185b3b 100644
--- a/docs/en/03-admin/08-report.md
+++ b/docs/en/03-admin/08-report.md
@@ -1,110 +1,110 @@
-# Elaboração de Relatório
+# Report Preparation
-Elaborar um relatório é uma tarefa que exige muita atenção e cuidado, pois é um documento que deve ser claro e objetivo, e que deve conter informações relevantes para o leitor.
+Preparing a report is a task that requires a lot of attention and care, as it is a document that should be clear and concise, containing relevant information for the reader.
-## O que é um Bug?
+## What is a Bug?
-Um bug é a consequencia/resultado de uma falha no código. Uma falha no código pode ter sido gerada por um erro de programação, ou por um erro de design. Geralmente erros no código acontecem por falta de conhecimento do programador, ou por falta de atenção.
+A bug is the consequence or result of a fault in the code. A fault in the code can be caused by a programming error or a design error. Code errors usually occur due to a lack of knowledge on the part of the programmer or due to inattention.
-É esperado que o software desenvolvido contenha uma quantidade razoável de bugs, pois é impossível prever todos os cenários possíveis de uso da aplicação. Porém, quanto mais bugs forem encontrados de forma tardia, mais tempo será gasto para corrigi-los, e mais tempo será gasto para testar a aplicação.
+It is expected that the developed software will contain a reasonable number of bugs because it is impossible to predict all possible application usage scenarios. However, the later bugs are found, the more time it will take to fix them, and the more time will be spent on testing the application.
-## Defeitos na Testagem de Software
+## Software Testing Defects
-Um defeito é uma variação ou desvio da aplicação de software em relação as regras de negócio ou requerimentos de business originais.
+A defect is a variation or deviation in the software application from the original business rules or requirements.
-Um defeito de software consiste em um erro no processo de codificação, o que causa resultados incorretos ou inesperado no programa, o que não atende aos requerimentos estabelecidos. Testers podem se deparar com tais defeitos ao aplicar os casos de teste.
+A software defect consists of an error in the coding process, which leads to incorrect or unexpected results in the program, not meeting the established requirements. Testers may encounter such defects when applying test cases.
-Estes dois termos possuem tênue diferença, e na indústria ambos são falhas que precisam ser corrigidas, sendo usadas de forma intercambeável por alguns times
+These two terms have a subtle difference, and in the industry, both are failures that need to be corrected and are used interchangeably by some teams.
-## Relatório de Bugs na Testagem de Software
+## Software Testing Bug Report
-Um relatório de bugs é um documento detalhado acerca de bugs encontrados na aplicação, contendo cada detalhe como descrição, data em que foi localizado, nome do testers que o encontrou, nome do dev que corrigiu, etc. Estes relatórios auxiliam a identificar bugs similares no futuro, de forma a evitá-los.
+A bug report is a detailed document about bugs found in the application, containing every detail such as description, date of discovery, the name of the tester who found it, the name of the developer who fixed it, etc. These reports help identify similar bugs in the future to avoid them.
-Ao reportar bugs ao desenvolvedor, o seu relatório deve conter as seguintes informações:
+When reporting bugs to the developer, your report should contain the following information:
-- Defeito_ID: Número de identificação única para o defeito.
-- Descrição do Defeito: Descrição detalhada incluindo informações sobre o módulo em que o defeito foi encontrado.
-- Versão: Em qual versão da aplicação o defeito foi localizado.
-- Data de Surgimento: Data em que o defeito surgiu.
-- Referência: Onde se provê referencias a documentações como requerimentos, design, arquitetura ou até mesmo capturas de tela do erro para auxiliar a compreensão.
-- Detectado por: Nome/ID do testers que identificou o defeito.
-- Status: Situação do defeito.
-- Corrigido por: Nome/ID do desenvolvedor que corrigiu.
-- Data de Encerramento: Data em que o defeito foi finalizado.
-- Gravidade: Descreve o impacto do defeito na aplicação.
-- Prioridade: Relacionada com a urgência na correção do defeito. A prioridade pode ser alta/média/baixa com base na urgência de impacto com que o defeito deve ser corrigido.
+- Defect_ID: A unique identification number for the defect.
+- Defect Description: Detailed description, including information about the module in which the defect was found.
+- Version: In which version of the application the defect was located.
+- Date of Occurrence: Date when the defect occurred.
+- Reference: Where references to documentation such as requirements, design, architecture, or even error screenshots are provided to help with understanding.
+- Detected by: Name/ID of the tester who identified the defect.
+- Status: The defect's situation.
+- Fixed by: Name/ID of the developer who fixed it.
+- Closure Date: Date when the defect was closed.
+- Severity: Describes the impact of the defect on the application.
+- Priority: Related to the urgency of defect correction. Priority can be high/medium/low based on how urgently the defect needs to be fixed.
-Outros elementos necessários para o relatório são:
+Other necessary elements for the report include:
-- Quando o bug ocorre? Como é possível reproduzí-lo?
-- Qual é o comportamento incorreto e o que era esperado?
-- Qual é o impacto no usuário? O quão crítica será sua correção?
-- Isto ocorre apenas com dados de teste específicos?
-- Qual build foi utilizada para o teste? (incluindo, idealmente, a commit do git)
-- Se o bug ocorre na versão mobile, qual modelo, tamanho de viewport e sistema operacional?
-- Se o bug ocorre em um browser, qual o tipo de browser, resolução e versão?
-- Se o bug ocorre em uma API, qual a API específica/fluxo de trabalho é impactado, quais são os parâmetros de request e resposta?
-- Captura de tela com as áreas relevantes demarcadas.
-- Video demonstrando os passos tomadas até ocorrência do bug.
-- Logs da aplicação/servidor
-- Qualquer feature de seleção/configuração específica, caso envolvida quando o bug ocorreu?
+- When does the bug occur? How can it be reproduced?
+- What is the incorrect behavior, and what was expected?
+- What is the user's impact? How critical is its correction?
+- Does this occur only with specific test data?
+- Which build was used for testing (ideally including the Git commit)?
+- If the bug occurs in the mobile version, what is the model, viewport size, and operating system?
+- If the bug occurs in a browser, what type of browser, resolution, and version?
+- If the bug occurs in an API, which specific API/workflow is affected, what are the request and response parameters?
+- Screenshot with relevant areas marked.
+- Video demonstrating the steps taken to encounter the bug.
+- Application/server logs.
+- Any specific selection/configuration feature, if involved when the bug occurred.
-## Processo de Gerenciamento dos Defeitos
+## Defect Management Process
-Sistemática para identificação e correção dos bugs. O ciclo de gerenciamento dos defeitos contém os seguintes passos:
+A systematic approach to identifying and fixing bugs. The defect management cycle consists of the following steps:
- 1. Descoberta do Defeito.
- 2. Categorização.
- 3. Correção do Defeito por Desenvolvedores.
- 4. Verificação por Testers
- 5. Encerramento do Defeito
- 6. Relatório de Defeitos ao fim do projeto.
+1. Defect Discovery.
+2. Categorization.
+3. Defect Resolution by Developers.
+4. Tester Verification.
+5. Defect Closure.
+6. Defect Reporting at the end of the project.
-
+
-### Descoberta
+### Discovery
-Nesta fase os times devem descobrir tantos defeitos quanto possível antes que o usuário final o faça. Um defeito é declarado como encontrado, e tem seu status alterado para "Aceito" uma vez reconhecido e aceito por desenvolvedores.
+In this phase, teams must discover as many defects as possible before the end-users do. A defect is declared found and its status is changed to "Accepted" once recognized and accepted by developers.
-
+
-### Categorização
+### Categorization
-A categorização de defeitos auxilia os desenvolvedores de software a priorizar suas tarefas de acordo com sua prioridade.
+Defect categorization helps software developers prioritize their tasks based on severity.
-- Crítica: Os defeitos que precisam ser corrigods **imediatamente** uma vez que podem causar grandes danos ao produto.
-- Alta: O defeito impacta as principais features do produto.
-- Média: O defeito causa desvios mínimos nas regras de negócio do poduto.
-- Baixa: O defeito em pouco afeta a operação do produto.
+- Critical: Defects that need to be fixed **immediately** as they can cause significant harm to the product.
+- High: The defect impacts the product's core features.
+- Medium: The defect results in minor deviations from the product's business rules.
+- Low: The defect has little effect on the product's operation.
-### Resolução
+### Resolution
-A resolução de defeitos na testagem de software é um processo que corrige desvios passo a passo, iniciando-se com a designação de defeitos para desenvolvedores, que por sua vez inserem os defeitos em um cronograma de acordo com sua prioridade.
+The resolution of defects in software testing is a process that corrects deviations step by step, starting with the assignment of defects to developers, who, in turn, insert defects into a schedule based on their priority.
-Uma vez que a correção seja finalizada, os desenvolvedores enviam um relatório ao Gerente de Testes, o processo auxilia na correção e registro dos defeitos.
+Once the correction is complete, developers send a report to the Test Manager, which helps in the defect correction and registration process.
-- Designação: Um desenvolvedor ou outro profissional recebe a correção a ser feita, e altera o status para *Respondendo*.
-- Fixação de Cronograma: O desenvolvedor assume parte do controle nesta fase, criando uma agenda para corrigir os defeitos com base em sua prioridade.
-- Correção do Defeito: Enquanto o time de desenvolvimento corrige os defeitos, o Gerente de Testes registra o processo.
-- Relatório da Resolução: Envio do relatório sobre a correção de defeito por parte dos desenvolvedores.
+- Assignment: A developer or another professional receives the correction to be made and changes the status to "Responding."
+- Schedule Fix: The developer takes some control in this phase, creating a schedule to fix the defects based on their priority.
+- Defect Correction: While the development team fixes the defects, the Test Manager records the process.
+- Resolution Report: The report on the defect correction is sent by the developers.
-### Verificação
+### Verification
-Após o time de desenvolvimento ter corrigido e reportado o defeito, a equipe de testes verifica que os problemas foram realmente corrigidos.
+After the development team has fixed and reported the defect, the testing team verifies that the problems have indeed been fixed.
-### Encerramento
+### Closure
-Uma vez que o defeito tenha sido resolvido e verificado, o status é alterado para *"Encerrado"*.
+Once the defect has been fixed and verified, the status is changed to "Closed."
-## Relatório de Defeitos
+## Defect Reports
-É um processo em que gerentes de testes preparam e enviam o relatório de defeitos para que o time de gerência provenha feedback no processo de gestão dos defeitos, bem como o status destes.
+This is a process where Test Managers prepare and send defect reports for management teams to provide feedback on the defect management process and the status of these defects.
-Então, o time de gerência checa o relatório, podendo enviar o feedback ou prover suporte adicional caso necessário. O relatório de defeitos auxilia a melhor comunicar, registrar e explicar defeitos com detalhes.
+The management team checks the report and may provide feedback or additional support if necessary. The defect report helps to better communicate, record, and explain defects in detail.
-O conselho de administração tem o direito de saber o status dos defeitos, uma vez que devem compreender o processo de gestão para auxiliar no projeto. Portanto, deve-se reportar a eles a situação atual dos defeitos, acatando feedback.
+The management board has the right to know the status of defects, as they need to understand the management process to assist in the project. Therefore, the current situation of defects must be reported to them, considering their feedback.
-### Como medir e avaliar a qualidade da execução de testes
+### How to Measure and Evaluate Test Execution Quality
-- Taxa de Rejeição dos Defeitos: (Número de defeitos rejeitados/Número total de defeitos)*100
-- Taxa de Vazamento dos Defeitos: (Número de defeitos não detectados/Total de defeitos do software)*100
+- Defect Rejection Rate: (Number of rejected defects/Total number of defects)*100
+- Defect Leakage Rate: (Number of undetected defects/Total software defects)*100
diff --git a/docs/en/03-admin/09-verificacao.md b/docs/en/03-admin/09-verificacao.md
deleted file mode 100644
index 27f193d..0000000
--- a/docs/en/03-admin/09-verificacao.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# Verificação e Validação
-
-A verificação, na testagem de software é um processo de checar documentos, design, código e programa para validar se o software foi construído de acordo com as regras de negócio.
-
-O principal objetivo é garantir a qualidade da aplicação, design, arquitetura, etc. Este processo envolve atividades como revisões, passo a passo e inspeções.
-
-## O que é Validação para testes de software?
-
-É um mecanismo dinâmico que testa e valida se o software de fato atende as exatas necessidades do cliente ou não. O processo auxilia a garantir que o produto atende o uso desejado em um ambiente apropriado. O processo de Validação envolve atividades como Teste Unitário, Teste de Integração, Teste de Sistema e Teste de Aceitação do Usuário (UAT)
-
-## Diferenças entre Verificação e Validação
-
-Vejamos as características que diferem Verificação de Validação:
-
-### Verificação
-
-- O processo de verificação inclue checar documentos, design, código e programa.
-- **Não envolve** a execução de código.
-- A verificação utiliza métodos como revisões, passo a passo, inspeções, verificação de mesa, etc.
-- Se o sistema está em conformidade com as especificações.
-- Encontra bugs no início do ciclo de desenvolvimento.
-- Alveja a aplicação e arquitetura de software, especificações, design completo, alto nível, design da base de dados, etc.
-- Time de QA realiza verificações e garante que o software encontra-se em conformidade com as regras de negócio.
-- Vem **antes** da Validação.
-
-### Validação
-
-- É um mecanismo dinâmico para teste e validação de um produto factual.
-- Sempre envolve a execução de código.
-- Utiliza-se de métodos como testes Caixa-Preta, Caixa-Branca e Não-Funcionais.
-- Pode localizar bugs que o processo de verificação não detectou.
-- Tem como alvo o produto em si.
-- Com o envolvimento do time de testes a validação é executada em código de software.
-- Vem **depois** da verificação.
-
-## Exemplos de Verificação e Validação
-
-*Um botão clicável de nome* **Submet**
-
-- Verificação checaria o documento de design e corrigiria o erro de digitação.
-- Do contrário, o time de desenvolvimento criaria o botão da seguinte forma:
-
-
-
-Portanto, a especificação é um botão de nome **Submit**
-
-- Uma vez que o código está pronto, a Validação é feita.
-- No processo de Validação, registra-se que o botão não é clicável.
-
-Graças ao teste de Validação, o time de desenvolvimento fará o botão Submit tornar-se clicável.
-
-## Validação do Projeto
-
-É um processo que avalia se produto de software está de acordo com os exatos requerimentos de usuários finais ou investidores. O propósito é testar o produto de software após desenvolvimento, para garantir que atenda as regras de negócios no ambiente de usuário.
-
-
-
-A validação preocupa-se em demonstrar a consistência e completude do design no que tange necessidades do usuário. Este é o estágio em que se constrói uma versão do produto e valida-se contra as regras de negócio.
-
-
-
-O objetivo é provar com evidências objetivas que o produto satisfaça as necessidades de usuários, as evidências objetivas não são nada além de provas físicas do output, como uma imagem, texto ou arquivo de audio que indique que o procedimento obteve sucesso.
-
-Este processo envolve atividades de teste, inspeção, análise, etc.
-
-## Verificação do Projeto
-
-É um método que confirma se o output de um produto de software designado atende as especificações de input ao examinar e prover evidências. O objetivo do processo de verificação é garantir que o design é idêntico ao especificado.
-
-Entrada de projeto é qualquer requerimento físico e de performance usado como base para propósitos de design. O output é resultado de cada fase de design ao final de todo o esforço de desenvolvimento. O output final é a base para registro mestre do dispositivo.
-
-### Processo de Verificação do Projeto
-
-- Identificação e Preparo
- - Durante o estágio de desenvolvimento de uma especificação, as atividades de identificação e verificação são feitas de forma paralela. Isto permite ao designer garantir que as especificações são verificáveis. Um engenheiro de testes pode, então, iniciar planos de teste e procedimentos detalhados. Quaisquer mudanças na especificação devem ser comunicadas.
- - Identificar a melhor abordagem para condução da verificação, definir métodos de medição, recursos necessários, ferramentas e instalações.
- - O plano de verificação completo será revisado pelo time de design para identificar eventuais problemas antes da finalização do plano.
-
-- Planejamento:
- - Planejar para verificação é uma atividade concomitante entre times de core e desenvolvimento. Isto ocorre através do ciclo de vida do projeto, e será atualizado conforme e quaisquer mudanças sejam feitas nos inputs.
- - Durante esta fase, o sistema ou software sob testes deve ser documentado em escopo.
- - Plano de testes preliminar e seu refinamento são feitos neste estágio. O plano captura as milestones críticas reduzindo os riscos do projeto.
- - Ferramentas, ambiente de testes, estratégia de desenvolvimento e identificação de requerimentos através de inspeção ou análise.
-
-- Desenvolvimento:
- - O desenvolvimento do caso de testes coincidirá com a metodologia SLDC implementada por um time. Uma variedade de métodos são identificados durante este estágio.
- - As entradas de projeto serão desenvolvidos de forma a incluir verificações simples, livres de ambiguidade e verificáveis.
- - Tempo de verificação deve ser reduzido quando conceitos similares são conduzidos em sequência. Até mesmo o output de um teste pode ser usado como input de testes subsequentes.
- - Links de tratabilidade são criados entre casos de testes e inputs de projeto correspondentes, para garantir que todos os requerimentos sejam testados e que o output de projeto atenda aos inputs.
-
-- Execução:
- - Os procedimentos de teste criados durante a fase de desenvolvimento são executados de acordo com o plano de testes, que deve ser estritamente seguido para atividades de verificação.
- - Caso qualquer resultado inválido ocorra, ou caso qualquer procedimento necessite de modificações, é importante documentar as mudanças e conseguir aprovações pertinentes.
- - Neste estágio, quaisquer problemas são identificados e catalogados como um defeito.
- - Matriz de tratabilidade é criada para verificar que todos os inputs de projeto identificados no plano de teste de verificação tenham sido testados e determinar a taxa de sucesso.
-
-- Relatórios:
- - Esta atividade é desenvolvida ao final de cada fase de verificação.
- - O relatório de verificação do design provê um sumário detalhado dos resultados de verificações que incluem gerenciamento de configurações, resultados de teste para cada modalidade e problemas encontrados durante a verificação
- - O relatório de rastreabilidade de verificação de design é criado entre requerimentos e resultados de teste correspondentes para verificar que todas as regras de negócio foram testadas e providas com resultados apropriados.
- - Qualquer inconformidade será documentada e apropriadamente abordada.
- - Revisões são feitas quando da finalização das verificações de design, e são aprovadas respectivamente.
-
-## Processo de validação do Projeto
-
-- Alguns dos designs podem ser validados ao comparar com equipamentos similares desenvolvendo atividades semelhantes. Este método é particularmente relevante para validar alterações de configuração para a infraestrutura existente, ou designs padrão que devem ser incorporados em um novo sistema ou aplicação.
-- Demonstração e/ou inspeções podem ser usadas para validar regras de negócio e outras funcionalidades do projeto.
-- Análises de produto podem ser feitas como modelagem matemática, uma simulação que recria a funcionalidade necessária.
-- Testes são executados no design final, que valida a habilidade do sistema de operar conforme as diretrizes estabelecidas.
-- Plano de testes, execução e resultados devem ser documentados e mantidos como parte dos registros de design. Portanto, Validação é uma coletânea dos resultados de todas as ações de validação.
-- Quando produtos equivalentes são utilizados na validação de design final, o fabricante deve documentar a similaridade e qualquer diferença da produção original.
-
-*Exemplo:*
-
-- Tomemos como exemplo um produto simples, um relógio a prova d'agua.
-- As regras de negócio podem definir que "o relógio deve ser a prova de água durante natação".
-- A especificação de design pode definir que "o relógio deve funcionar mesmo que o usuário nade por tempo prolongado">
-- Os resultados de teste devem confirmar que o relógio atende estas regras ou iterações de redesign são feitas até que satisfaça aos requerimentos.
-
-## Vantagens da Validação e Verificação de Design
-
-- Podemos monitorar continuamente os designs, o que nos permite atender aos requerimentos definidos por usuários em cada estágio.
-- Validar o design irá pontuar a diferença entre como a funcionalidade opera e como ela deveria operar.
-- Documentar os procedimentos de validação irá auxiliar a facilmente enteder a funcionalidade em qualquer estágio no futuro caso exista alguma mudança ou melhoria.
-- O tempo de desenvolvimento será consistentemente reduzido, melhorando a produtividade, o que habilita a entrega do produto conforme esperado.
-- Este processo inclue amplitude e escopo de cada método de validação que devem ser aplicados.
-- Qualquer diferença entre o resultado e as necessidades de usuário devem ser documentados.
-- Mudanças na validação de design levam a revalidações.
-- É importante documentar todas as atividades que ocorram durante a validação, o que adequadamente prova que o design atende aos requerimentos de usuário.
diff --git a/docs/en/03-admin/09-verification.md b/docs/en/03-admin/09-verification.md
new file mode 100644
index 0000000..8018f95
--- /dev/null
+++ b/docs/en/03-admin/09-verification.md
@@ -0,0 +1,129 @@
+# Verification and Validation
+
+In software testing, verification is a process of checking documents, design, code, and program to validate whether the software has been built according to the business rules.
+
+The main goal is to ensure the quality of the application, design, architecture, etc. This process involves activities such as reviews, step-by-step checks, and inspections.
+
+## What is Validation for Software Testing?
+
+It is a dynamic mechanism that tests and validates whether the software actually meets the exact needs of the customer or not. The process helps ensure that the product meets the desired use in an appropriate environment. The Validation process involves activities such as Unit Testing, Integration Testing, System Testing, and User Acceptance Testing (UAT).
+
+## Differences between Verification and Validation
+
+Let's look at the characteristics that differentiate Verification from Validation:
+
+### Verification
+
+- The verification process includes checking documents, design, code, and program.
+- **Does not involve** code execution.
+- Verification uses methods like reviews, step-by-step checks, inspections, desk checking, etc.
+- It checks if the system complies with the specifications.
+- It finds bugs in the early development cycle.
+- Targets the application and software architecture, specifications, complete design, high-level design, database design, etc.
+- The QA team performs verifications and ensures that the software complies with business rules.
+- Comes **before** Validation.
+
+### Validation
+
+- It is a dynamic mechanism for testing and validating an actual product.
+- Always involves code execution.
+- Uses methods like Black-Box, White-Box, and Non-Functional Testing.
+- Can find bugs that the verification process did not detect.
+- Targets the product itself.
+- With the involvement of the testing team, validation is performed on the software code.
+- Comes **after** verification.
+
+## Examples of Verification and Validation
+
+*A clickable button named* **Submit**
+
+- Verification would check the design document and correct the typographical error.
+- Otherwise, the development team would create the button as follows:
+
+
+
+So, the specification is a button named **Submit**.
+
+- Once the code is ready, Validation is performed.
+- In the Validation process, it is noted that the button is not clickable.
+
+Thanks to the Validation test, the development team will make the Submit button clickable.
+
+## Design Validation
+
+It is a process that evaluates whether a software product meets the exact requirements of end-users or investors. The purpose is to test the software product after development to ensure it meets business rules in a user environment.
+
+
+
+Validation concerns demonstrating the consistency and completeness of the design regarding user needs. This is the stage where a version of the product is built and validated against business rules.
+
+
+
+The goal is to provide objective evidence that the product meets user needs, where objective evidence is nothing more than physical proof of the output, such as an image, text, or an audio file that indicates the procedure's success.
+
+This process involves testing, inspection, analysis, and more.
+
+## Design Verification
+
+It is a method that confirms whether the output of a designated software product meets input specifications by examining and providing evidence. The purpose of the verification process is to ensure that the design is identical to what was specified.
+
+Design input includes any physical and performance requirements used as a basis for design purposes. The output is the result of each design phase at the end of all development efforts. The final output is the basis for the device's master record.
+
+### Project Verification Process
+
+- Identification and Preparation
+ - During the specification development stage, identification and verification activities are carried out in parallel. This allows the designer to ensure that the specifications are verifiable. A test engineer can then initiate detailed test plans and procedures. Any changes to the specification must be communicated.
+ - Identify the best approach for conducting verification, define measurement methods, required resources, tools, and facilities.
+ - The complete verification plan will be reviewed by the design team to identify any issues before finalization.
+
+- Planning:
+ - Verification planning is a concurrent activity between core and development teams. This occurs throughout the project's lifecycle and is updated when any changes are made to the inputs.
+ - During this phase, the system or software under test must be documented within scope.
+ - Preliminary test plans and their refinement are conducted at this stage. The plan captures critical milestones to reduce project risks.
+ - Tools, testing environment, development strategy, and requirements identification through inspection or analysis are included.
+
+- Development:
+ - Test case development coincides with the SLDC methodology implemented by a team. Various methods are identified during this stage.
+ - Design inputs will be developed to include straightforward, unambiguous, and verifiable checks.
+ - Verification time should be reduced when similar concepts are conducted in sequence. Even the output of one test can be used as input for subsequent tests.
+ - Traceability links are created between test cases and corresponding design inputs to ensure that all requirements are tested and that the design output meets the inputs.
+
+- Execution:
+ - The test procedures created during the development phase are executed in accordance with the verification plan, which must be strictly followed for verification activities.
+ - If any invalid results occur, or if any procedures require modifications, it is important to document the changes and obtain relevant approvals.
+ - At this stage, any issues are identified and cataloged as defects.
+ - A traceability matrix is created to ensure that all identified design inputs in the verification test plan have been tested and to determine the success rate.
+
+- Reporting:
+ - This activity is carried out at the end of each verification phase.
+ - The design verification report provides a detailed summary of the verification results, including configuration management, test results for each modality, and issues found during verification.
+ - The design verification traceability report is created between requirements and corresponding test results to verify that all business rules have been tested and provided with appropriate results.
+ - Any discrepancies will be documented and appropriately addressed.
+ - Reviews are conducted upon the completion of design verification and are approved accordingly.
+
+### Project Validation Process
+
+- Some designs can be validated by comparing them with similar equipment performing similar activities. This method is particularly relevant for validating configuration changes to existing infrastructure or standard designs to be incorporated into a new system or application.
+- Demonstrations and/or inspections can be used to validate business rules and other project functionalities.
+- Product analysis can be performed, such as mathematical modeling or simulation recreating the necessary functionality.
+- Tests are carried out on the final design to validate the system's ability to operate according to established guidelines.
+- Test plans, execution, and results must be documented and kept as part of the design records. Therefore, Validation is a collection of the results of all validation actions.
+- When equivalent products are used in final design validation, the manufacturer must document the similarity and any differences from the original production.
+
+*Example:*
+
+- Let's take a simple product as an example, a waterproof watch.
+- Business rules may state that "the watch must be waterproof during swimming."
+- The design specification may specify that "the watch must function even if the user swims for an extended period."
+- Test results must confirm that the watch meets these rules, or redesign iterations are made until the requirements are satisfied.
+
+## Advantages of Design Validation and Verification
+
+- We can continuously monitor designs, allowing us to meet user-defined requirements at each stage.
+- Validating the design will highlight the difference between how the functionality operates and how it should operate.
+- Documenting validation procedures will help easily understand the functionality at any stage in the future in case of changes or improvements.
+- Development time will be consistently reduced, improving productivity, enabling product delivery as expected.
+- This process includes the breadth and scope of each validation method that should be applied.
+- Any discrepancies between the results and user needs must be documented.
+- Changes in design validation lead to revalidations.
+- It is important to document all activities that occur during validation, adequately proving that the design meets user requirements.
diff --git a/docs/en/04-execucao/00-intro.md b/docs/en/04-execucao/00-intro.md
deleted file mode 100644
index ba7af98..0000000
--- a/docs/en/04-execucao/00-intro.md
+++ /dev/null
@@ -1,232 +0,0 @@
-# Execução de Testes
-
-Inicialmente para executarmos testes precisamos ter noção de como o software funciona, para isso talvez seja necessário que o software esteja em um estágio avançado de desenvolvimento, ou que ele tenha requerimentos muito consistentes.
-
-## Tipos de Execução de Testes
-
-Existem duas formas em quais testes podem ser executados, manualmente ou automaticamente. A execução manual é a mais comum, pois ela permite que o teste seja executado de forma mais rápida e simples. Porém, ela é mais propensa a erros, pois o teste pode ser executado de forma incorreta. Por outro lado, a execução automática é mais lenta, pois ela requer a criação de um script que será responsável por executar o teste.
-
-Devido a essas diferenças, a execução manual é mais recomendada para testes simples, enquanto a execução automática é mais recomendada para testes complexos.
-
-A complexidade de testes é relativa ao seu escopo, ou seja, quanto maior o escopo do teste, maior será a complexidade dele. Por exemplo, um teste que verifica se um botão está funcionando corretamente é um teste simples, pois ele possui um escopo pequeno. Por outro lado, um teste que verifica se um sistema inteiro está funcionando corretamente é um teste complexo, pois ele possui um escopo grande.
-
-Além disso, a complexidade de um teste também pode ser medida pela quantidade de passos necessários para executá-lo. Por exemplo, um teste que possui apenas um passo é um teste simples, enquanto um teste que possui vários passos é um teste complexo.
-
-## Casos de Teste e Cenários
-
-Casos de teste consiste em um grupo de ações executadas para verificar uma feature ou funcionalidade da aplicação de software. Um Caso de Testes contém passos de teste, de dados, pré-condições, pós-condições desenvolvidas para um cenário de testes específico, a fim de validar quaisquer requerimentos necessários.
-
-O caso de testes incluí variáveis e condições específicas, por meio das quais um engenheiro de testes pode comparar os resultados esperados, com os factuais, para determinar se um produto de software está funcionando de acordo com as regras de negócio determinadas.
-
-## Cenário de Teste Vs Caso de Teste
-
-- Cenário de Testes:
- - Um cenário contem documentação de alto nível que descreve uma funcionalidade a ser testada do começo ao fim;
- - Foca mais "no que" testar ao invés de "como" testar;
- - Os cenários possuem uma linha. Portanto, sempre existe a chance de ambiguidade ao testar;
- - Cenários de teste são derivados de artefatos como BRS, SRS, etc;
- - Auxilia com uma forma ágil de testar a funcionalidade do começo ao fim;
- - Os cenários de teste são ações de alto nível;
- - Comparativamente, menos tempo e recursos são necessários para criar e testar com o uso de cenários;
-
-- Casos de Teste
- - Contém passos definidos, dados necessários, resultados esperados para testagem de todas as features em uma aplicação;
- - Uma completa ênfase "em que testar" **e** "como testar";
- - Casos de teste possuem passos definidos, pré-requisitos, resultados esperados, etc. Portanto, não existe ambiguidade no processo;
- - Casos de teste são majoritariamente derivados de cenários de teste. Múltiplos casos de teste podem derivar de apenas um cenário;
- - Auxiliam na testagem exaustiva de uma aplicação
- - Casos de Teste são ações de baixo nível
- - Mais recursos são necessários para documentação e execução de casos de teste;
-
-## Formatação de Casos de Teste Padrão
-
-- ID: TU01
- - Descrição do Caso de Testes: Verificar login com informações válidas.
- - Passos do Teste:
- 1. Acessar o site;
- 2. Inserir ID de usuário;
- 3. Inserir senha;
- 4. Clicar em Submit;
- - Dados do Teste:
- 1. ID de Usuário: guru99;
- 2. Senha: pass99;
- - Resultados Esperados: Usuário deve logar na aplicação.
- - Resultados Factuais: Conforme esperado.
-- ID: TU02
- - Descrição do Caso de Testes: Verificar Login com informações inválidas.
- - Passos do Teste:
- 1. Ir até o Site;
- 2. Inserir ID de Usuário;
- 3. Inserir Senha;
- 4. Clicar em Submit;
- - Dados do Teste:
- 1. ID de usuário: guru99;
- 2. Senha: glass99;
-- Resultados Esperados: Usuário não deve logar na aplicação.
-- Resultados Factuais: Conforme Esperado.
-
-## Como Escrever Casos de Teste nos Testes Manuais
-
-Criemos um Caso de Testes para o Cenário: Verifique funcionalidade Login
-
-
-
-Passo 1) Um caso de testes simples para explicar o cenário seria
-
-- Caso de Testes #1
-- Descrição Do Caso:
- Verificar resposta quando informações de email e senha válidos são inseridos
-
-Passo 2) Testar as Informações
-
-A fim de executar os casos de teste, seriam necessárias as informações do teste, adicionadas abaixo:
-
-- Caso de Testes #1
-- Descrição do Caso:
- Verificar resposta quando dados de email e senha válidos são inseridos
-- Dados de Teste:
- Email: guru99@email.com
- Senha: lNf9^Oti7^2h
-
-Identificar os dados de teste pode demorar, e por vezes requerer a criação de dados novos, razões pelas quais precisa ser documentado.
-
-Passo 3) Executar Ações
-
-Para executar um caso, o tester deve desenvolver uma série de ações no UAT, que são documentadas da seguinte forma:
-
-- Caso de Testes #1
-- Descrição do Caso:
- Verificar resposta quando dados de email e senha válidos são inseridos.
-- Passos do Teste:
- 1. Inserir endereço de email;
- 2. Inserir senha;
- 3. Clicar em Sign In;
-- Dados de Teste:
- Email: guru99@email.com;
- Senha: lNf9^Oti7^2h;
-
-Muitas vezes os Passos de Testes não são simples assim, fazendo-se necessária a documentação. Além disso, o autor do caso de testes pode deixar o quadro de funcionários, entrar em férias, ficar doente ou demais situações do gênero. Uma contratação recente pode receber a função de executar o caso de testes, passos documentados irão auxiliar no desenvolvimento da função e facilitar revisões por outros investidores.
-
-Passo 4) Verificar o comportamento do AUT
-
-O objetivo dos casos na testagem de software é verificar o comportamento da UAT por um resultado esperado. Deve ser documentado como se segue:
-
-- Caso de Testes #1
-- Descrição do Caso: Verificar resposta quando dados de email e senha válidos são inseridos.
-- Passos do Teste:
- 1. Inserir endereço de email;
- 2. Inserir senha;
- 3. Clicar em Sign In;
-- Dados de Teste:
- Email: guru99@email.com;
- Senha: lNf9^Oti7^2h;
-- Resultados Esperados:
- Login com sucesso.
-
-Durante o período de execução do teste, o profisisonal irá verificar resultados esperados contra os resultados factuais, designando um status de Sucesso ou Falha.
-
-- Caso de Testes #1
-- Descrição do Caso:
- Verificar resposta quando dados de email e senha válidos são inseridos.
-- Passos do Teste:
- 1. Inserir endereço de email;
- 2. Inserir senha;
- 3. Clicar em Sign In;
-- Dados de Teste:
- Email: guru99@email.com;
- Senha: lNf9^Oti7^2h;
-- Resultados Esperados: Login com sucesso.
-- Sucesso/Falha: Sucesso.
-
-Passo 5) O caso de testes pode possuir uma pré-condição que especifique elementos necessários antes do inícios dos testes.
-
-Para o nosso caso de testes, uma pré-condição seria ter um browser instalado para obter acesso ao site sob validação. Um caso também pode incluir pós-condições que especifiquem quisquer elementos que apliquem-se após a finalização dos casos.
-
-Neste exemplo, a pós-condição seria que o horário e data do login sejam documentados na base de dados.
-
-## Melhores práticas para escrever um bom Caso de Testes
-
-Consideremos as seguintes práticas:
-
-### 1. Casos precisam ser simples e transparentes
-
-Crie casos que sejam tão simples quanto o possível. Devem ser claros e concisos uma vez que o autos do caso pode não ser aquele que o executará.
-
-Use linguagem assertiva como "vá para a pagina inciial", "insira os dados", "clique em x". Isto tornará a compreensão fácil, e a execução mais rápida.
-
-### 2. Crie casos com o usuário final em mente
-
-O principal objetivo de qualquer projeto de software é criar casos de teste que atendam as regras de negócio do cliente e sejam fáceis de operar. Um tester deve criar casos com o usuário final em mente.
-
-### 3. Evite repetição de casos
-
-Não repita casos de testes. Se um caso é necessário para a execução de outro caso, refira-se a ele por seu id na coluna de pré-condições.
-
-### 4. Não presuma
-
-Não presuma funcionalidades e features da aplicação enquanto prepara um caso de testes. Atenha-se aos documentos de especficiações.
-
-### 5. Garanta 100% de Cobertura
-
-Garanta que a escrita dos casos de teste verifiquem todos os requerimentos de software mencionados na documentação de especificação. Use matrizes de rastreamento para garantir que nenhuma função/condição seja deixada de lado.
-
-### 6. Casos de teste devem ser identificáveis
-
-Nomeie os ID para casos de forma que sejam indentificáveis facilmente ao vasculhar por defeitos ou identificar um requerimento de software nos estágios mais avançados.
-
-### 7. Implemente as técnicas de Testagem
-
-Não é possível verificar todas as possíveis condições na aplicação de software. As técnicas de testagem auxiliam a selecionar casos de teste com a maior possibilidade de localizarem defeitos.
-
-- Análise de Valor de Limite (Boundary Value Analysis - BVA): Como o nome sugere esta técnica define a testagem dos limites de um escopo específico de valores.
-- Partição de Equivalência (Equivalence Partition - EP): Esta técnica divide o intervalo em partes/grupos iguais que tendem a possuir o mesmo comportamento.
-- Técnica de Transição de Estado: Este método é utilizado quando o comportamento de um software muda de um estado para outro em seguida de uma ação particular.
-- Técnica de Dedução de Erros: Esta técnica deduz/antecipa os erros que podem surgir durante a execução de um teste manual. Este não é um método formal e se vale da experiência do testers com a aplicação.
-
-### 8. Auto-Limpeza
-
-O caso de testes criado deve voltar ao Ambiente de Testes em seu estado pre-testes, não devendo tornar o ambiente testes inutilizável. Isto é especialmente pertinente para testes de configuração.
-
-### 9. Repetíveis e Autônomos
-
-O Caso de Testes deve gerar os mesmos resultados todas as vezes, não importando quem realizou o teste.
-
-### 10. Revisão de Pares
-
-Após a criação dos casos de teste, leve-os para revisão por seus colegas. Seus pares podem descobrir defeitos no design do caso.
-
-*Inclua as seguintes informações ao desenvolver um caso de testes*:
-
-- A descrição de qual requerimento está sendo testado.
-- Expllicação de como o sistema será validado.
-- O setup de testes como uma versão da aplicação sob verificação, software, arquivos de dados, sistema operacional, acesso de segurança, data lógica ou física, horário do dia, pré requisitos como outros testes e quaisquer outras informações de setup pertinentes aos requerimentos sob teste.
-- Inputs, outputs, ações e seus resultados esperados.
-- Quaisquer provas ou anexos.
-- Use linguagem ativa para maiúsculas e minúsculas.
-- Caso de testes não deve possuir mais do que 15 passos.
-- Um script de teste automatizado é comentado com inputs, propósito e resultados esperados.
-- O Setup oferece uma alternativa para testes prévios necessários.
-- Com outros testes, deve ser uma ordem incorreta do cenário de negócios.
-
-## Ferramentas para Administração de Casos de Teste
-
-Ferramentas de administração são os elementos de automação que auxiliam a coordenar e manter os casos de testes. As principais funcionalidades de uma ferramenta como esta, são:
-
-1. Documentar Casos de Teste: com ferramentas, pode-se acelerar a criação de casos de testes com o uso de templates.
-2. Executar o Caso de Testes e Documentar resultados: Casos podem ser executados através das ferramentas, e resultados coletados para fácil registrar.
-3. Automatizar o Rastreio de Defeitos: Testes que obtiveram falha são automaticamente ligados ao rastrador de bugs, o que, por sua vez, pode ser designado aos desenvolvedores através de notificação via email.
-4. Rastreabilidade: Requerimentos, casos de teste e suas execuções são conectados através das ferramentas, e cada caso pode ser rastreado até os demais para validar cobertura.
-5. Proteção dos Casos de Teste: Casos de testes devem ser reutilizáveis, e protegidos de perda ou corrupção devido a controle de versões deficitário.
-
-As feramentas muitas vezes oferecem funcionalidades como:
-
-- Convenções de nomenclatura e numeração
-- Controle de Versão
-- Armazenamento read-only
-- Acesso controlado
-- Backup externo
-
-*Ferramentas de administração dos testes populares são*:
-
-- [Quality Center](https://www.guru99.com/hp-alm-free-tutorial.html)
-- [Jira](https://www.guru99.com/jira-tutorial-a-complete-guide-for-beginners.html)
diff --git a/docs/en/04-execucao/01-manual.md b/docs/en/04-execucao/01-manual.md
deleted file mode 100644
index d05e4ee..0000000
--- a/docs/en/04-execucao/01-manual.md
+++ /dev/null
@@ -1,65 +0,0 @@
-# Testes Manuais
-
-Esta técnica de testagem verifica casos executados manualmente por um profissional sem qualquer auxílio de ferramentas automatizadas. O propósito da Testagem Manual é identificar bugs, problemas e defeitos no aplicativo. Os testes de software manuais constituem a mais primitiva técnica dentre todas as abordagens, e auxilia na identificação de bugs críticos da API.
-
-Qualquer nova aplicação precisa ser manualmente testada antes que seja automatizada. Esta técnica requer maior esforço, mas é necessária para avaliar aplicabilidade de automação.
-
-O conceito de teste manual não requer qualquer conhecimento de ferramentas para teste. Um dos fundamentos da Testagem de Software é "100% de automação não é possível", o que torna a abordagem manual imperativa.
-
-## Objetivos do Teste Manual
-
-O conceito chave do teste manual é garantir que a aplicação esteja livre de bugs e funciona em conformidade com as regras de negócio funcionais.
-
-Baterias e casos de teste são desenvolvidos durante a fase de testes e devem ter 100% de cobertura, o que também garante que defeitos reportados sejam corrigidos por desenvolvedores, e que a retestagem tenha sido aplicada por testers nos defeitos corrigidos.
-
-Basicamente este técnica verifica a qualidade do sistema e entrega um produto livre de bugs para o cliente.
-
-## Tipos de Teste Manual
-
-
-
-O diagrama representa os tipos de teste manual. **Na verdade, qualquer tipo de abordagem para testes pode ser executada tanto manualmente ou com uma ferramenta de automatização**.
-
-- Teste Caixa-Preta;
-- Teste Caixa-Branca;
-- Teste Unitário;
-- Teste de Sistema;
-- Teste de Integração;
-- Teste de Integração;
-- Teste de Aceitação;
-
-## Como Aplicar Testes Manuais?
-
-1. Leia e compreenda a documentação do projeto de software e suas diretrizas, além disso, estude a Application Under Test (AUT), se possível.
-2. Rascunhe casos de teste que cubram todas as regras de negócio mencionada na documentação.
-3. Revise e estabeleça uma linha de base para os casos de teste com Team Lead e cliente (conforme aplicável).
-4. Execute os casos de teste no AUT.
-5. Reporte quaisquer bugs.
-6. Uma vez que bugs estejam corrigidos, execute novamente os testes que falharam para verifica se passam.
-
-## *Teste Manual vs Teste Automatizado*
-
-- Teste Manual:
- - Requer intervenção humana para execução dos testes.
- - Requer trabalho especializado, é demorado e implica altos custos.
- - Qualquer tipo de aplicativo pode ser testado manualmente, certas aobordagens são mais apropriadas para a execução manual.
- - Testes manuais podem se tornar repetitivos e tediosos.
-
-- Testagem Automatizada:
- - A automação é o uso de ferramentas para execução de casos de teste.
- - Poupa tempo, custos e força de trabalho. Uma vez registrados, é mais facil executar uma bateria de testes automatizados.
- - Testagem automatizada é recomendada apenas para sistemas estáveis e é majoritariamente utilizada para os Testes de Regressão.
- - A parte tediosa de executar repetidos casos de testes é delegada a um software automatizado.
-
-## Ferramentas para Testagem Manual
-
-1. Citrus;
-2. Zap;
-3. NUnit;
-4. Jira;
-5. SonarQube;
-6. JMeter;
-7. BugZilla;
-8. Mantis;
-9. Tessy;
-10. Loadrunner;
diff --git a/docs/en/04-execucao/02-automatizado.md b/docs/en/04-execucao/02-automatizado.md
deleted file mode 100644
index a2928d5..0000000
--- a/docs/en/04-execucao/02-automatizado.md
+++ /dev/null
@@ -1,213 +0,0 @@
-# Testes Automatizados
-
-Testagem automatizada é aplicação de ferramentas de software para automatizar um processo manual de revisão e validação do produto de software. Projetos Ágil e DevOps mais modernos incluem esta técnica.
-
-A modalidade cooloca responsabilidades de propriedade nas mãos do time de engenharia. Os planos de teste são desenvolvidos paralelamente ao roteiro de desenvolvimento padrão e executado automaticamente por ferramentas de integração contínua. Isto promove um time de QA eficiente, e permite que a equipe foque em features mais sensíveis
-
-Entrega Contínua (*Continuous Delivery*/CD) refere-se a entrega de novos lançamentos de código o mais rápido possível aos clientes, e a automatização de testes desempenha fator crítico para este objetivo. Não há forma de automatizar a entrega aos usuários se existe um processo manual e dispendioso dentro do processo de entregas.
-
-A entrega contínua faz parte de uma pipeline de implantação maior, sendo sucessora e também dependente da integração contínua (*Continuous Integration*/CI). Esta, por sua vez, é inteiramente responsável por executar testes automatizados em quaisquer mudanças de código, verificando se estas mudanças não quebram features estabelecidas ou introduzem novos bugs.
-
-O deploy contínuo entra em ação uma vez que a etapa de integração contínua passe no plano de testes automatizado.
-
-Esta relação entre testagem automatizada, CI e CD produzem muitos benefícios para um time de alta eficiência. A automação garante qualidade em todos de desenvolvimento ao verificar que novas commits não introduzam bugs, para que o software permaneça pronto para implantação a qualquer momento.
-
-
-
-## *Quais tipos de testes devem ser automatizados primeiro?*
-
-Consideremos por ordem de prioridade:
-
-### 1. Testes ponta-a-ponta (E2E)
-
-Discutivelmente um dos testes mais valiosos a serem implementados, a técnica simula uma experiência a nível de usuário através de todo o produto de software. Planos para testes ponta-a-ponta geralmente cobrem estórias a nivel de usuário como "o usuário pode realizar login", "o usuário pode efetuar um depósito", "usuário pode alterar configurações de Email".
-
-A implementação destes teste é altamente valiosa já que oferecem garantia de que usuários reais terão uma experiência suave e livre de bugs, mesmo quando novas commits são aplicadas.
-
-### 2. Testes Unitários ou de Unidade
-
-Como o nome sugere, testes unitários cobrem partes individuais de código, sendo melhor medidos em definições de função.
-
-Um teste unitário irá validar uma função individual, verificando que o input esperado em uma função irá coincidir com o output previsto. Código que possuam cálculos sensíveis (uma vez que pode referir-se a finanças, planos de saúde ou espaço aereo) são melhor cobertor por esta técnica de testes.
-
-Caracterizam-se por seu baixo custo e velocidade de implementação, provendo um alto retorno de investimento.
-
-### 3. Testes de Integração
-
-Muitas vezes uma unidade de código fará uma chamada externa para um serviço terceirizado, mas a base de código primária sob testes não terá acesso ao código deste utilitário de terceiros.
-
-Testes de integração irão lidar com o mock destas dependências de terceiros, com o intuito de verificar se o código que realiza a interface comporta-se como esperado.
-
-Esta técnica é similar aos Testes Unitários na forma com que são escritos e em suas ferramentas. São uma alternativa mais barata aos testes ponta-a-ponta, porém, o retorno de investimento é debatível quando a combinação de testes unitários e ponta-a-ponta já está estabelecida.
-
-### 4. Testes de Performance
-
-Quando usado no contexto de desenvolvimento de software 'performance' refere-se a velocidade e responsividade com que um projeto de software reaje. Alguns exemplos para métricas de performance são:
-
-- Tempo para carregamento de página
-- Tempo para renderização inicial
-- Tempo de resposta para resultados de pesquisa
-
-Esta modalidade de testes criam métricas e garantias para estes casos.
-
-Em sua versão automatizada, os testes de performance irão executar os casos de teste através das métricas e alertar o time caso regressões ou perdas de velocidade ocorram.
-
-## Quais tipos de teste devem ser executados manualmente?
-
-É discutível se todos os testes que *podem* ser automatizados, *deveriam* ser. A automação representa enorme ganho de produtividade e custo de horas de trabalho, isto posto, existem situações em que o Retorno de Investimento (*Return of Investiment*/ROI) para desenvolver uma bateria de testes automatizada é inferior quando comparado a execução de testes manuais.
-
-### 1. Teste Exploratório
-
-Teste automatizados são, por definição, scriptados, e seguem uma sequência de passos para validar um comportamento. Um teste exploratório é mais aleatório e aplica sequências não roteirizadas para localizar bugs ou comportamentos inesperados.
-
-Enquanto existem ferramentas para estabelecer uma bateria de testes exploratórios, elas não foram refinadas o suficiente, e ainda não receberam adoção ampla por empresas. Pode ser muito mais eficiente designar um tester manual e utilizar criatividade humana para explorar como é possivel quebrar um produto de software.
-
-### 2. Teste de Regressão Visual
-
-Uma regressão visual ocorre quando uma falha de design visual é introduzida na UI do produto, podendo constituir-se de elementos mal posicionados, fontes ou cores erradas, etc.
-
-Assim como no teste exploratório existem ferramentas para desenvolvimentos de testes automatizados com o intuito de detectar estas regressões. As ferramentas realizam capturas de tela a partir de diferentes estados do produto, aplicando reconhecimento óptico de caracteres (*Optical Character Recognition*/OCR) para comparar com os resultados esperados. Estes testes possuem desenvolvimento custoso, e as ferramentas também não possuem adoção ampla, tornando a opção humana e manual mais eficiente em alguns casos.
-
-### 3. Construindo estruturas de automação para times DevOps
-
-Não existe solução única para automação de testes, ao desenvolver um plano de automação alguns pontos chaves devem ser levados em consideração:
-
-- Frequencia de Lançamento:
- Produtos de software que são lançados em intervalos fixos, como mensalmente ou semanalmente, podem encaixar-se melhor com a modalidade manual. Produtos com lançamentos mais rápidos em muito se beneficiam dos testes automatizados uma vez que o CI e CD dependendem de uma testagem automática.
-
-- Ferramentas Disponíveis e Ecosistema:
- Cada linguagem de programação possui seu próprio ecosistema de ferrmentas complementares e utilidades. E cada tipo de padrão automatizado de testes detém um grupo de ferramentas próprio, que pode ou não estar disponível no ecosistema de certas linguagens. Implementar com sucesso um padrão de testes automáticos irá requerer uma interseção da linguagem e suporte de ferramentas.
-
-- Ajuste ao mercado do produto e maturidade da base de código:
- Caso o time esteja construindo um novo produto que não recebeu validação de público alvo e modelo de negócios, pode não fazer sentido investir em testes automatizados, considerando que estes atuam como um mecanismo de garantia que restringe regressões inexperadas de código. Considerando que a equipe trabalhe em alta velocidade pode ser frustrantemente custoso atualizar e manter testes automatizados quando o código muda drástica e rapidamente.
-
-## Pirâmide de Automação
-
-Esta categoria de estrutura pode auxiliar tanto desenvolvedores quanto QAs a criarem softwares de alta qualidade, reduzindo o tempo que desenvolvedores levam para se a mudança introduzida quebra o código e contribuindo para o desenvolvimento de uma bateria de testes mais confiável.
-
-Essencialmente, a pirâmide de testes, também conhecida como pirâmide de automação, estabelece os tipos de teste que devem ser inclusos em uma bateria automatizada. Também delimitando a sequência e frequência destes testes.
-
-O principal objetivo é oferecer feedback imediato, garantindo que mudanças no código não afetem negativamente features já existentes.
-
-### *Os Diferentes Níveis da Pirâmide*
-
-Esta estrutura opera em três níveis:
-
-
-
-#### *Nível 1) Testes Unitários*
-
-Testes unitários formam a base da pirâmide, validando componentes e funcionalidades individuais para validar que funcionem corretamente sob condições isoladas. Portanto, é essencial executar diversos cenários em testes unitários.
-
-- Sendo o subgrupo mais significativo, a bateria de testes unitários deve ser escrita de forma a ser executada o mais rápido quanto o possível.
-- Lembre-se de que o número de testes unitários irá aumentar conforme novas features são adicionadas.
-- Esta bateria de testes deve ser executadas sempre que uma nova funcionalidade é implementada.
-- Consequentemente, desenvolvedores recebem feedback imediato sobre se as features individuais funcionam em sua forma atual.
-
-Uma bateria de testes unitários eficiente e de execução rápida incentiva desenvolvedores a aplicarem-na com frequência.
-
-A aplicação do TDD (Test-driven-development) contribui para a criação de uma bateria robusta, uma vez que a técnica requer a escrita dos testes antes que qualquer código seja estabelecido, tornando-o mais direto, transparente e livre de bugs.
-
-#### *Nível 2) Testes de Integração*
-
-Enquanto testes unitários verificam pequenas peças do código, os testes de integração devem ser executadas para verificar como as diferentes partes do software interagem entre si. Essencialmente, são testes que validam como uma parte do código interagem com componentes externos, podendo variar de databases até serviços externos (APIs)
-
-- Testes de Integração constituem a segunda camada da pirâmide, isto significa que não devem ser executados com a mesma frequència dos testes unitários.
-- Fundamentalmente, testam como uma feature comunica-se com dependências externas.
-- Seja uma chamada no banco de dados ou serviço web, o software deve comunicar-se eficientemente e buscar as informações corretar para funcionar conforme o esperado.
-
-É importante ressaltar que esta técnica envolve interação com serviços externos, logo, sua execução será mais lenta do que a de testes unitários. Além disso, requerem um ambiente de pré-produção para poderem ser aplicados.
-
-#### *Nível 3) Testes ponta-a-ponta*
-
-O nível mais alto da pirâmide, garantem que toda a aplicação funcione como deveria ao testa-la do começo ao fim.
-
-- Esta técnica encontra-se no topo da pirâmide uma vez que leva mais tempo para ser executada.
-- Ao desenvolver estes testes, é essencial pensar a partir da perspectiva de um usuário.
-- Como um usuário utilizaria este aplicativo? Como os testes podem ser escritos para replicar estas interações?
-
-Eles também podem ser frágeis já que precisam testar diversos cenários de uso.
-
-Assim como testes de integração, podem exigir que a aplicação comunique-se com elementos externos, o que possivelmente contribui com gargalos na conclusão.
-
-Uma aula exemplificativa acerca da estratégia por trás dos testes ponta-a-ponta pode ser encontrada [aqui](https://youtu.be/kh-5UeQVlY0).
-
-### *Por que times Ágil deveriam usar a Pirâmide de Automação?*
-
-Os processos Ágil priorizam velocidade e eficiência, elementos oferecidos pela pirâmide através ao organizar o processo de testes em uma progressão lógica e clara, promovendo uma conclusão eficiente do trabalho.
-
-Uma vez que a estrutura é feita de forma a executar testes mais acessíveis no início, testers podem melhor administrar seu tempo, obtendo melhores resultados e melhorando o trabalho de todos os envolvidos ao fornecer as prioridades certas para o time de testes.
-
-Se scripts de testes são escritos com um foco maior na UI, chances são de que a lógica de negócios central e as funcionalidades back-end não foram suficientemente verificadas. Isto afeta a qualidade de produto e leva a um aumento no fluxo de trabalho das equipes.
-
-Além disso o tempo de resposta dos testes de UI é alto, o que leva a uma menor cobertura geral de testes. Ao implementar a pirâmide de automação tais situações são completamente solucionadas.
-
-Na automação de testes, ferramentas e estruturas como Selenium executam testes scriptados em uma aplicação de software ou componentes para garantir que funcionem como esperado. Seu único objetivo é reduzir o esforço e erro humanos, mas para que a máquina provenha os resultados corretos, deve ser apropriadamente direcionada.
-
-A pirâmide de automação procura atingir esta necessidade ao organizar e estruturar o ciclo de testes, racionalizando todo o processo e trazendo um gerenciamento de tempo eficiente, de forma a prover testers com modelos já validados com os quais moldar seus projetos.
-
-## O processo de testes back-end
-
-Comumente desenvolvida para verificação do banco de dados, o teste Back-End é um processo que verifica parâmetros de servidor em busca de uma transição suave. Constitui uma das mais essenciais atividades de teste, ocorrendo em todos os programas.
-
-O armazenamento de dados geralmente ocorre no backend, que é validado pelo processo de testes para remoção de quaisquer ameaças no banco de dados.
-
-### Qual a importância do teste backend?
-
-Existem diferentes tipos de bancos de dados disponíveis no mercado, variando de SQL, Oracle, DB2, MYSQL, etc. A organização de dados em tabelas específicas é um dos fatores importantes a serem considerados. Portanto, auxilia a oferecer o resultado correto no front end.
-
-Alguns dos problemas e complicações mais sensíveis como corrupção e perda de dados são solucionados através dos testes de database.
-
-### Como o processo Back End Funciona
-
-Não é obrigatório visualizar o teste backend através de interfaces gráficas de usuário, portanto, os testes ocorrem apenas em funcionalidades e códigos fonte. Os parâmetros de navegador são comumente verificados dependendo do programa ou projeto.
-
-A testagem backend é geralmente concluída em poucos passos, logo, é importante conhecer o objetivo do processo antes de iniciar.
-
-Os primeiros passos examinam o banco de dados e o servidor antes de progredir para funções, as etapas seguintes são construídas com base nas especificações e programação.
-
-1. Esquema;
-2. Tabelas do Banco de Dados;
-3. Colunas;
-4. Chaves e Índices;
-5. Procedimentos Armazenados;
-6. Gatilhos;
-7. Validações no Servidor do Banco de Dados;
-8. Validação da Duplicação de Dados;
-
-### Quando Aplicar Testes Backend?
-
-Testers preferem conduzir testes backend nos estágios iniciais por diversos motivos. A técnica ajuda a identificar alguns dos problemas básicos com o banco de dados, bem como a solucionar problemas relacionados ao servidor.
-
-As ferramentas atuais permitem facilmente identificar problemas no backend, poupando quantias expressivas de tempo sem comprometer a qualidade
-
-### Diferentes Tipos de Teste Backend
-
-Existem variadas abordagens para validação do backend, tornando-se necessária a compreensão dos requisitos para desenvolvimento de uma estratégia eficiente.
-
-- Teste Funcional
-- Teste Não-Funcional
-- Teste Estrutural
-
-## Teste Backend Vs Teste Frontend
-
-- Testes Backend:
- - Desenvolvido em testes de lógica de negócios e databases.
- - Uma base forte em bancos de dados e servidores é preferível para o tester.
- - A maioria dos testes são feitos no servidor do banco de dados.
- - Conhecimentos em linguagem de consulta estruturada SQL e outros scripts são uma necessidade.
- - Requer espaço de armazenamento no banco de dados para testar servidore
- - Alguns dos tipos de teste comuns involvidos são teste de API, SQL, etc.
-
-- Testes Frontend:
- - É dsenvolvido na interface e demais funcionalidades referentes ao usuário.
- - Entendimento sólido dos requisitos de business e experiência do usuário são necessários.
- - Familiaridade com estruturas de automação também é imperativo.
- - Requerem completo acesso para alteração de módulos e opções da interface fronted.
- - Alguns dos tipos de teste comumente envolvidos são testes Unitário, Aceitação, Regressão, etc.
-
-## Ferramentas para Teste Backend
-
-- Data Factory
-- Data Generator
-- TurboData
diff --git a/docs/en/04-execution/00-intro.md b/docs/en/04-execution/00-intro.md
new file mode 100644
index 0000000..76509d9
--- /dev/null
+++ b/docs/en/04-execution/00-intro.md
@@ -0,0 +1,231 @@
+# Test Execution
+
+To perform tests, it's essential to have an understanding of how the software functions. This may require the software to be in an advanced stage of development or have very consistent requirements.
+
+## Types of Test Execution
+
+There are two ways in which tests can be executed: manually or automatically. Manual execution is more common because it allows tests to be performed quickly and easily. However, it's more prone to errors since the test can be executed incorrectly. On the other hand, automated execution is slower as it requires the creation of a script responsible for running the test.
+
+Due to these differences, manual execution is more recommended for simple tests, while automated execution is more recommended for complex tests.
+
+The complexity of tests is relative to their scope; the larger the scope of the test, the more complex it becomes. For example, a test that checks if a button is working correctly is a simple test because it has a small scope. On the other hand, a test that verifies if an entire system is functioning correctly is a complex test because it has a large scope.
+
+Moreover, the complexity of a test can also be measured by the number of steps required to execute it. For example, a test with only one step is a simple test, while a test with multiple steps is a complex test.
+
+## Test Cases and Scenarios
+
+Test cases consist of a group of actions performed to verify a feature or functionality of a software application. A test case contains test steps, test data, preconditions, and postconditions developed for a specific test scenario to validate any necessary requirements.
+
+The test case includes specific variables and conditions through which a test engineer can compare the expected results with the actual results to determine if a software product is working in accordance with the specified business rules.
+
+## Test Scenario vs. Test Case
+
+- Test Scenario:
+ - A scenario contains high-level documentation describing a feature to be tested from start to finish.
+ - It focuses more on "what" to test rather than "how" to test.
+ - Scenarios have a narrative, so there is always a chance of ambiguity in testing.
+ - Test scenarios are derived from artifacts such as BRS, SRS, etc.
+ - Assists in an agile way of testing the feature from start to finish.
+ - Test scenarios are high-level actions.
+ - Comparatively, less time and resources are required for creating and testing using scenarios.
+
+- Test Case:
+ - Contains defined steps, required data, expected results for testing all features in an application.
+ - A complete emphasis on "what to test" **and** "how to test."
+ - Test cases have defined steps, prerequisites, expected results, etc. Therefore, there is no ambiguity in the process.
+ - Test cases are mostly derived from test scenarios. Multiple test cases can be derived from a single scenario.
+ - Assists in the exhaustive testing of an application.
+ - Test cases are low-level actions.
+ - More resources are needed for documenting and executing test cases.
+
+## Standard Test Case Format
+
+- ID: TU01
+ - Test Case Description: Verify login with valid information.
+ - Test Steps:
+ 1. Access the website.
+ 2. Enter the user ID.
+ 3. Enter the password.
+ 4. Click on Submit.
+ - Test Data:
+ 1. User ID: guru99.
+ 2. Password: pass99.
+ - Expected Results: User should log in to the application.
+ - Actual Results: As expected.
+- ID: TU02
+ - Test Case Description: Verify login with invalid information.
+ - Test Steps:
+ 1. Go to the website.
+ 2. Enter the user ID.
+ 3. Enter the password.
+ 4. Click on Submit.
+ - Test Data:
+ 1. User ID: guru99.
+ 2. Password: glass99.
+ - Expected Results: User should not log in to the application.
+ - Actual Results: As expected.
+
+## How to Write Manual Test Cases
+
+Let's create a test case for the scenario: "Check Login Functionality"
+
+
+
+Step 1) A simple test case to explain the scenario would be:
+
+- Test Case #1
+- Case Description:
+ Verify the response when valid email and password information is entered.
+
+Step 2) Testing the Information
+
+In order to execute test cases, the test information needs to be added as follows:
+
+- Test Case #1
+- Case Description:
+ Verify the response when valid email and password information is entered.
+- Test Data:
+ Email: guru99@email.com
+ Password: lNf9^Oti7^2h
+
+Identifying test data can take time and sometimes requires the creation of new data, which is why it needs to be documented.
+
+Step 3) Performing Actions
+
+To execute a test case, the tester must develop a series of actions in the UAT, documented as follows:
+
+- Test Case #1
+- Case Description:
+ Verify the response when valid email and password information is entered.
+- Test Steps:
+ 1. Enter the email address.
+ 2. Enter the password.
+ 3. Click on Sign In.
+- Test Data:
+ Email: guru99@email.com;
+ Password: lNf9^Oti7^2h;
+
+Often, test steps are not as simple, requiring detailed documentation. Additionally, the test case author may leave the organization, go on vacation, fall ill, or encounter other situations. A new hire may be assigned to execute the test case, and documented steps will facilitate their role and enable reviews by other stakeholders.
+
+Step 4) Verify the Behavior of the AUT (Application Under Test)
+
+The purpose of test cases in software testing is to verify the behavior of the UAT by comparing it to the expected result. It should be documented as follows:
+
+- Test Case #1
+- Case Description: Verify the response when valid email and password information is entered.
+- Test Steps:
+ 1. Enter the email address.
+ 2. Enter the password.
+ 3. Click on Sign In.
+- Test Data:
+ Email: guru99@email.com;
+ Password: lNf9^Oti7^2h;
+- Expected Results:
+ Successful login.
+
+During the test execution period, the professional will compare expected results with actual results, assigning a status of Pass or Fail.
+
+- Test Case #1
+- Case Description: Verify the response when valid email and password information is entered.
+- Test Steps:
+ 1. Enter the email address.
+ 2. Enter the password.
+ 3. Click on Sign In.
+- Test Data:
+ Email: guru99@email.com;
+ Password: lNf9^Oti7^2h;
+- Expected Results: Successful login.
+- Success/Failure: Success.
+
+Step 5) The test case may have a precondition specifying elements required before the start of testing.
+
+For our test case, a precondition would be to have a browser installed to gain access to the validation website. A test case may also include postconditions that specify any actions that apply after the completion of the test.
+
+In this example, the postcondition would be that the login date and time are documented in the database.
+
+## Best Practices for Writing Good Test Cases
+
+Consider the following practices:
+
+### 1. Test Cases Should Be Simple and Transparent
+
+Create test cases that are as simple as possible. They should be clear and concise since the author of the case may not be the one executing it.
+
+Use assertive language like "navigate to the home page," "input data," "click on X." This makes understanding easy and execution faster.
+
+### 2. Create Test Cases with the End User in Mind
+
+The primary goal of any software project is to create test cases that meet the client's business rules and are easy to operate. A tester should create test cases with the end user in mind.
+
+### 3. Avoid Test Case Repetition
+
+Do not repeat test cases. If one test case is needed for the execution of another, refer to it by its ID in the prerequisites column.
+
+### 4. Do Not Assume
+
+Do not assume application functionalities and features while preparing a test case. Stick to the specification documents.
+
+### 5. Ensure 100% Coverage
+
+Ensure that test cases cover all software requirements mentioned in the specification documentation. Use traceability matrices to ensure that no function/condition is overlooked.
+
+### 6. Test Cases Should Be Identifiable
+
+Name test case IDs in a way that they are easily identifiable when searching for defects or identifying a software requirement in the advanced stages.
+
+### 7. Implement Testing Techniques
+
+It is not possible to test all possible conditions in a software application. Testing techniques help select test cases with the highest likelihood of finding defects.
+
+- Boundary Value Analysis (BVA): This technique tests the boundaries of a specific range of values, as the name suggests.
+- Equivalence Partitioning (EP): This technique divides the range into equal parts/groups that tend to behave the same way.
+- State Transition Technique: This method is used when the behavior of software changes from one state to another following a particular action.
+- Error Guessing Technique: This technique guesses/anticipates errors that may arise during manual test execution. It is not a formal method and relies on the tester's experience with the application.
+
+### 8. Self-Cleaning
+
+Test cases should return the Testing Environment to its pre-test state, without rendering the test environment unusable. This is especially relevant for configuration tests.
+
+### 9. Repeatable and Autonomous
+
+Test Cases should generate the same results every time, regardless of who performs the test.
+
+### 10. Peer Review
+
+After creating test cases, have them reviewed by your colleagues. Your peers may find defects in the case design.
+
+*Include the following information when developing a test case*:
+
+- The description of the requirement being tested.
+- Explanation of how the system will be validated.
+- Test setup, such as a version of the application under verification, software, data files, operating system, security access, logical or physical data, time of day, prerequisites like other tests, and any other setup information relevant to the requirements being tested.
+- Inputs, outputs, actions, and their expected results.
+- Any evidence or attachments.
+- Use active language with proper capitalization.
+- Test cases should not have more than 15 steps.
+- An automated test script is commented with inputs, purpose, and expected results.
+- The setup provides an alternative for required pre-tests.
+- If there are other tests, it should be ordered correctly in the business scenario.
+
+## Test Case Management Tools
+
+Test case management tools are automation elements that help coordinate and maintain test cases. The main functionalities of such a tool are:
+
+1. Document Test Cases: With tools, test case creation can be accelerated using templates.
+2. Execute Test Cases and Document Results: Test cases can be executed through the tools, and results can be collected for easy record-keeping.
+3. Automate Defect Tracking: Tests that fail are automatically linked to the bug tracker, which can then be assigned to developers via email notification.
+4. Traceability: Requirements, test cases, and their executions are linked through the tools, and each test case can be traced back to others to validate coverage.
+5. Protect Test Cases: Test cases should be reusable and protected from loss or corruption due to poor version control.
+
+These tools often offer features such as:
+
+- Naming and numbering conventions
+- Version control
+- Read-only storage
+- Controlled access
+- External backup
+
+*Popular test case management tools include*:
+
+- [Quality Center](https://www.guru99.com/hp-alm-free-tutorial.html)
+- [Jira](https://www.guru99.com/jira-tutorial-a-complete-guide-for-beginners.html)
diff --git a/docs/en/04-execution/01-manual.md b/docs/en/04-execution/01-manual.md
new file mode 100644
index 0000000..250dfba
--- /dev/null
+++ b/docs/en/04-execution/01-manual.md
@@ -0,0 +1,64 @@
+# Manual Testing
+
+This testing technique involves manually executed test cases by a professional without any assistance from automated tools. The purpose of Manual Testing is to identify bugs, issues, and defects in the application. Manual software testing is the most primitive technique among all approaches and helps in identifying critical API bugs.
+
+Any new application needs to be manually tested before it is automated. This technique requires more effort but is necessary to assess the automation feasibility.
+
+The concept of manual testing does not require any knowledge of testing tools. One of the fundamentals of Software Testing is "100% automation is not possible," which makes the manual approach imperative.
+
+## Objectives of Manual Testing
+
+The key concept of manual testing is to ensure that the application is bug-free and works in compliance with functional business rules.
+
+Test suites and test cases are developed during the testing phase and should have 100% coverage, ensuring that reported defects are fixed by developers and retesting is performed by testers on the fixed defects.
+
+Basically, this technique checks the system's quality and delivers a bug-free product to the customer.
+
+## Types of Manual Testing
+
+
+
+The diagram represents the types of manual testing. **In reality, any testing approach can be performed either manually or with an automation tool**.
+
+- Black Box Testing
+- White Box Testing
+- Unit Testing
+- System Testing
+- Integration Testing
+- User Acceptance Testing
+
+## How to Apply Manual Testing?
+
+1. Read and understand the software project documentation and its guidelines, also study the Application Under Test (AUT) if possible.
+2. Draft test cases covering all business rules mentioned in the documentation.
+3. Review and establish a test case baseline with Team Lead and the client (as applicable).
+4. Execute the test cases on the AUT.
+5. Report any bugs.
+6. Once the bugs are fixed, re-run the failed tests to verify if they pass.
+
+## *Manual Testing vs. Automated Testing*
+
+- Manual Testing:
+ - Requires human intervention to execute tests.
+ - Requires specialized work, is time-consuming, and involves high costs.
+ - Any type of application can be manually tested; certain approaches are more suitable for manual execution.
+ - Manual testing can become repetitive and tedious.
+
+- Automated Testing:
+ - Automation involves the use of tools to execute test cases.
+ - Saves time, costs, and manpower. Once recorded, it's easier to execute a battery of automated tests.
+ - Automated testing is recommended only for stable systems and is mostly used for Regression Testing.
+ - The tedious part of executing repeated test cases is delegated to automated software.
+
+## Tools for Manual Testing
+
+1. Citrus
+2. Zap
+3. NUnit
+4. Jira
+5. SonarQube
+6. JMeter
+7. BugZilla
+8. Mantis
+9. Tessy
+10. Loadrunner
diff --git a/docs/en/04-execution/02-automated.md b/docs/en/04-execution/02-automated.md
new file mode 100644
index 0000000..ad47219
--- /dev/null
+++ b/docs/en/04-execution/02-automated.md
@@ -0,0 +1,213 @@
+# Automated Testing
+
+Automated testing is the application of software tools to automate a manual process of reviewing and validating software products. Modern Agile and DevOps projects include this technique.
+
+This approach places ownership responsibilities in the hands of the engineering team. Test plans are developed in parallel with the standard development script and are executed automatically by continuous integration tools. This promotes an efficient QA team and allows the development team to focus on more critical features.
+
+Continuous Delivery (CD) refers to delivering new code releases to customers as quickly as possible, and test automation plays a critical role in achieving this goal. There is no way to automate user delivery if there is a manual and time-consuming process within the delivery process.
+
+Continuous delivery is part of a larger deployment pipeline and is both a successor and dependent on continuous integration (CI). CI is entirely responsible for running automated tests on any code changes, ensuring that these changes do not break established features or introduce new bugs.
+
+Continuous deployment comes into play once the continuous integration step passes the automated test plan.
+
+This relationship between automated testing, CI, and CD yields many benefits for a highly efficient team. Automation ensures quality throughout development by checking that new commits do not introduce bugs, making the software ready for deployment at any time.
+
+
+
+## *What types of tests should be automated first?*
+
+Consider the following priority order:
+
+### 1. End-to-End (E2E) Tests
+
+Arguably one of the most valuable tests to implement, this technique simulates a user-level experience throughout the entire software product. End-to-end test plans typically cover user-level stories such as "the user can log in," "the user can make a deposit," "the user can change email settings."
+
+Implementing these tests is highly valuable as they provide assurance that real users will have a smooth, bug-free experience even when new commits are applied.
+
+### 2. Unit Tests
+
+As the name suggests, unit tests cover individual parts of the code, best measured in function definitions.
+
+A unit test will validate an individual function by checking that the expected input to a function matches the expected output. Code that involves sensitive calculations (such as finances, healthcare, or aerospace) is best covered by this testing technique.
+
+Unit tests are characterized by their low cost and implementation speed, providing a high return on investment.
+
+### 3. Integration Tests
+
+Often, a unit of code will make an external call to a third-party service, but the primary codebase under test will not have access to the code of this third-party utility.
+
+Integration tests will handle the mocking of these third-party dependencies to verify that the code that interfaces behaves as expected.
+
+This technique is similar to unit testing in how they are written and their tools. They are a cheaper alternative to end-to-end tests, but the return on investment is debatable when a combination of unit and end-to-end tests is already established.
+
+### 4. Performance Tests
+
+When used in the context of software development, 'performance' refers to the speed and responsiveness with which a software project responds. Some examples of performance metrics include:
+
+- Page load time
+- Initial rendering time
+- Search result response time
+
+These types of tests create metrics and assurances for these cases.
+
+In their automated version, performance tests will run test cases through the metrics and alert the team if regressions or speed losses occur.
+
+## What types of tests should be executed manually?
+
+It is debatable whether all tests that *can* be automated *should* be. Automation represents a significant gain in productivity and cost of labor hours, but there are situations in which the Return on Investment (ROI) for developing a battery of automated tests is lower compared to manual test execution.
+
+### 1. Exploratory Testing
+
+Automated tests are, by definition, scripted and follow a sequence of steps to validate a behavior. Exploratory testing is more random and applies non-scripted sequences to find bugs or unexpected behaviors.
+
+While there are tools to establish a battery of exploratory tests, they have not been refined enough and have not been widely adopted by companies. It can be much more efficient to assign a manual tester and use human creativity to explore how to break a software product.
+
+### 2. Visual Regression Testing
+
+Visual regression occurs when a visual design flaw is introduced in the product's UI, which may consist of improperly positioned elements, wrong fonts or colors, and more.
+
+Just as in exploratory testing, there are tools for developing automated tests to detect these regressions. The tools take screenshots from different product states, apply Optical Character Recognition (OCR) to compare them to expected results. These tests have a high development cost, and the tools have not been widely adopted, making the human and manual option more efficient in some cases.
+
+### 3. Building Automation Frameworks for DevOps Teams
+
+There is no one-size-fits-all solution for test automation. When developing an automation plan, some key points should be considered:
+
+- Release Frequency:
+ Software products released at fixed intervals, such as monthly or weekly, may be better suited to manual testing. Products with faster releases greatly benefit from automated tests, as CI and CD depend on automated testing.
+
+- Available Tools and Ecosystem:
+ Each programming language has its ecosystem of complementary tools and utilities. Each type of automated testing standard has its own set of tools that may or may not be available in certain language ecosystems. Successfully implementing an automated testing standard will require an intersection of language and tooling support.
+
+- Product Market Fit and Codebase Maturity:
+ If the team is building a new product that has not been validated by a target audience and business model, it may not make sense to invest in automated testing. Considering the team works at high speed, it can be frustratingly expensive to update and maintain automated tests when the code changes dramatically and quickly.
+
+## Automation Pyramid
+
+This framework can help both developers and QA teams create high-quality software, reduce the time developers spend figuring out if an introduced change breaks the code, and contribute to a more reliable battery of tests.
+
+Essentially, the testing pyramid, also known as the automation pyramid, establishes the types of tests to be included in an automated battery and defines the sequence and frequency of these tests.
+
+The main goal is to provide immediate feedback, ensuring that changes in the code do not negatively affect existing features.
+
+### *The Different Levels of the Pyramid*
+
+This framework operates on three levels:
+
+
+
+#### *Level 1) Unit Tests*
+
+Unit tests form the base of the pyramid, validating individual components and functionalities to ensure they work correctly under isolated conditions. Therefore, it's essential to run various scenarios in unit tests.
+
+- As the most significant subgroup, the unit test suite should be written to execute as quickly as possible.
+- Remember that the number of unit tests will increase as new features are added.
+- This suite should be run whenever a new feature is implemented.
+- Consequently, developers receive immediate feedback on whether individual features work in their current form.
+
+An efficient, fast-running unit test suite encourages developers to apply it frequently.
+
+The application of Test-Driven Development (TDD) contributes to creating a robust suite, as the technique requires writing tests before any code is established, making it more straightforward, transparent, and bug-free.
+
+#### *Level 2) Integration Tests*
+
+While unit tests verify small pieces of code, integration tests should be run to check how different parts of the software interact with each other. Essentially, these are tests that validate how a piece of code interacts with external components, ranging from databases to external services (APIs).
+
+- Integration tests constitute the second layer of the pyramid, meaning they should not be run as frequently as unit tests.
+- Fundamentally, they test how a feature communicates with external dependencies.
+- Whether it's a database query or a web service call, the software should communicate efficiently and fetch the right information to function as expected.
+
+It's important to note that this technique involves interaction with external services, so its execution will be slower than unit tests. Moreover, they require a pre-production environment to be applied.
+
+#### *Level 3) End-to-End Tests*
+
+The highest level of the pyramid ensures that the entire application works as it should by testing it from start to finish.
+
+- This technique is at the top of the pyramid because it takes longer to run.
+- When developing these tests, it's essential to think from a user's perspective.
+- How would a user use this application? How can tests be written to replicate these interactions?
+
+They can also be fragile as they need to test various usage scenarios.
+
+Like integration tests, they may require the application to communicate with external elements, which can potentially contribute to bottlenecks in completion.
+
+A helpful tutorial on the strategy behind end-to-end tests can be found [here](https://youtu.be/kh-5UeQVlY0).
+
+### *Why Agile Teams Should Use the Automation Pyramid*
+
+Agile processes prioritize speed and efficiency, elements offered by the pyramid by organizing the testing process in a logical and clear progression, promoting efficient work completion.
+
+Since the structure is designed to run more accessible tests first, testers can better manage their time, achieving better results and improving the work of everyone involved by providing the right priorities to the testing team.
+
+If test scripts are written with a greater focus on the UI, chances are that the core business logic and backend functionality have not been thoroughly verified. This affects product quality and leads to an increase in team workload.
+
+Additionally, the response time of UI tests is high, resulting in lower overall test coverage. By implementing the automation pyramid, these situations are completely addressed.
+
+In test automation, tools and frameworks like Selenium execute scripted tests on software applications or components to ensure they work as expected. Their sole aim is to reduce human effort and error, but for the machine to provide the correct results, it must be appropriately directed.
+
+The automation pyramid seeks to meet this need by organizing and structuring the testing cycle, streamlining the entire process and providing efficient time management, enabling testers to use validated patterns to shape their projects.
+
+## The Backend Testing Process
+
+Commonly developed for database verification, the Back-End test is a process that verifies server parameters for a smooth transition. It is one of the most essential testing activities, occurring in all programs.
+
+Data storage typically occurs in the backend, which is validated by the testing process to eliminate any threats in the database.
+
+### What Is the Importance of Backend Testing?
+
+Different types of databases are available in the market, ranging from SQL, Oracle, DB2, MYSQL, etc. Data organization into specific tables is one of the important factors to consider. It helps provide the correct output on the front end.
+
+Some of the most sensitive problems and complications, such as data corruption and loss, are solved through database testing.
+
+### How Does the Back-End Testing Process Work?
+
+It is not mandatory to view backend testing through user graphical interfaces; therefore, the tests occur only in functionalities and source codes. Browser parameters are commonly checked depending on the program or project.
+
+Back-end testing is usually completed in a few steps, so it's essential to understand the purpose of the process before starting.
+
+The initial steps examine the database and server before progressing to functions; the subsequent steps are built based on specifications and programming.
+
+1. Schema.
+2. Database Tables.
+3. Columns.
+4. Keys and Indexes.
+5. Stored Procedures.
+6. Triggers.
+7. Database Server Validations.
+8. Data Duplication Validation.
+
+### When to Apply Backend Testing?
+
+Testers prefer to conduct backend tests in the early stages for various reasons. The technique helps identify some of the basic problems with the database and also resolves server-related issues.
+
+Modern tools easily identify backend issues, saving significant amounts of time without compromising quality.
+
+### Different Types of Backend Testing
+
+There are various approaches to validate the backend, making it necessary to understand the requirements to develop an efficient strategy.
+
+- Functional Testing.
+- Non-functional Testing.
+- Structural Testing.
+
+## Backend Testing vs. Frontend Testing
+
+- Backend Testing:
+ - Focuses on testing business logic and databases.
+ - A strong foundation in databases and servers is preferable for the tester.
+ - Most tests are performed on the database server.
+ - Knowledge of structured query language (SQL) and other scripts is a necessity.
+ - Requires database server storage to test servers.
+ - Some common test types involved are API testing, SQL testing, etc.
+
+- Frontend Testing:
+ - Focuses on the interface and other user-related functionalities.
+ - Solid understanding of business requirements and user experience is required.
+ - Familiarity with automation frameworks is also imperative.
+ - Requires full access to change frontend modules and options.
+ - Some common test types involved are Unit Testing, Acceptance Testing, Regression Testing, etc.
+
+## Tools for Backend Testing
+
+- Data Factory.
+- Data Generator.
+- TurboData.
diff --git a/docs/en/guide/00-FOUNDATIONS.md b/docs/en/guide/00-FOUNDATIONS.md
new file mode 100644
index 0000000..6d0a489
--- /dev/null
+++ b/docs/en/guide/00-FOUNDATIONS.md
@@ -0,0 +1,15 @@
+# Foundations On Software Testing
+
+
+In these first steps we will talk about the fundamentals of software testing and how it is done.
+
+1. [Foundations On Software Testing](../00-foundation/00-intro.md)
+1. [Traditional and Agile Testing](../00-foundation/01-traditional-vs-agile.md)
+1. [Interaction with the Team](../00-foundation/02-interaction.md)
+1. [Tools and Their Objectives](../00-foundation/03-tools.md)
+1. [Artifact Review](../00-foundation/04-artifacts.md)
+1. [How to Identify What to Test](../00-foundation/05-identify.md)
+1. [Test Cases, Incident Reports, and Priorities](../00-foundation/06-cases-report-incident.md)
+1. [Q&A](../00-foundation/07-questions.md)
+
+← [Back to Roadmap](README.md)
diff --git a/docs/en/guide/01-APPROACHES.md b/docs/en/guide/01-APPROACHES.md
new file mode 100644
index 0000000..35ea5b4
--- /dev/null
+++ b/docs/en/guide/01-APPROACHES.md
@@ -0,0 +1,12 @@
+# Testing Approaches
+
+The nature of testing depends a lot on how we interact or not with the system under test. Given these factors, we can classify tests into three distinct approaches.
+
+In this second chapter we will discuss these different testing approaches, how they are performed and what are their advantages and disadvantages.
+
+1. [Testing Approaches](../01-approachs/00-intro.md)
+1. [White Box Testing](../01-approachs/01-white-box.md)
+1. [Black Box Testing](../01-approachs/02-black-box.md)
+1. [Gray Box Testing](../01-approachs/03-gray-box.md)
+
+← [Back to Roadmap](README.md)
diff --git a/docs/en/guide/02-TYPES.md b/docs/en/guide/02-TYPES.md
new file mode 100644
index 0000000..0ce9bb3
--- /dev/null
+++ b/docs/en/guide/02-TYPES.md
@@ -0,0 +1,24 @@
+# Testing Techniques
+
+There are numerous types of tests, each with its purpose and characteristics. If you are starting in the testing area, it is important that you understand the difference between each of them, as this will help you to choose the type of test that you will perform in each situation.
+
+In the following chapter we will describe in detail each of the existing types of tests, their characteristics and how to apply them.
+
+1. [Testing Techniques](../02-types/00-intro.md)
+1. [Functional Testing Techniques](../02-types/01-functional.md)
+1. [User Acceptance Testing](../02-types/02-uat.md)
+1. [Exploratory Testing](../02-types/03-exploratory.md)
+1. [Sanity Testing](../02-types/04-sanity.md)
+1. [Regression Testing](../02-types/05-regression.md)
+1. [Unit Testing](../02-types/06-unit.md)
+1. [Smoke Testing](../02-types/07-smoke.md)
+1. [Integration Testing](../02-types/08-integration.md)
+1. [Non-Functional Testing](../02-types/09-non-functional.md)
+1. [Load Testing](../02-types/10-load.md)
+1. [Performance Testing](../02-types/11-performance.md)
+1. [Stress Testing](../02-types/12-stress.md)
+1. [Security Testing](../02-types/13-pentest.md)
+1. [Accessibility Testing](../02-types/14-accessibility.md)
+1. [Compatibility Testing](../02-types/15-compatibility.md)
+
+← [Back to Roadmap](README.md)
diff --git a/docs/en/guide/03-ADMIN.md b/docs/en/guide/03-ADMIN.md
new file mode 100644
index 0000000..75c0437
--- /dev/null
+++ b/docs/en/guide/03-ADMIN.md
@@ -0,0 +1,19 @@
+# Project Administration
+
+Project administration is a crucial topic in the field of testing because it ensures that the project is being developed correctly and that there are no issues that could hinder development. However, managing a project is not an easy task. There are various ways to administer a project, each with its advantages and disadvantages.
+
+Let's explore how we can manage a project:
+
+1. [Introduction](../03-admin/00-intro.md)
+2. [Test Planning](../03-admin/01-plan.md)
+3. [Requirement Prioritization](../03-admin/01-priorization.md)
+4. [Software Development Life Cycle](../03-admin/02-sldc.md)
+5. [Agile Method](../03-admin/03-agile.md)
+6. [Scrum Method](../03-admin/04-scrum.md)
+7. [Kanban Method](../03-admin/05-kanban.md)
+8. [Waterfall Method](../03-admin/06-waterfall.md)
+9. [V-Model Method](../03-admin/07-v-model.md)
+10. [Creating a Test Report](../03-admin/08-report.md)
+11. [Verification and Validation](../03-admin/09-verification.md)
+
+← [Back to the Roadmap](README.md)
diff --git a/docs/en/guide/04-EXECUTION.md b/docs/en/guide/04-EXECUTION.md
new file mode 100644
index 0000000..ed41b9c
--- /dev/null
+++ b/docs/en/guide/04-EXECUTION.md
@@ -0,0 +1,11 @@
+# Test Execution
+
+Tests can be executed in two distinct ways: manually or automatically. The choice of which method to use depends on the type of project being developed and the type of test being conducted.
+
+We will delve into more details in this chapter.
+
+1. [Building Test Cases](../04-execution/00-intro.md)
+2. [Manual Testing](../04-execution/01-manual.md)
+3. [Automated Testing](../04-execution/02-automated.md)
+
+← [Back to the Roadmap](README.md)
diff --git a/docs/en/guide/LINKS.md b/docs/en/guide/LINKS.md
new file mode 100644
index 0000000..57e39fc
--- /dev/null
+++ b/docs/en/guide/LINKS.md
@@ -0,0 +1,67 @@
+# QA Roadmap
+
+## *Work in Progress*
+
+Please disregard any irrelevancies and potential grammar errors.
+
+> Relevant Links:
+
+[Roadmap_QA](https://roadmap.sh/qa)
+
+[Udemy_Software_Testing](https://www.udemy.com/course/teste-software-completo-testes-automaticos/)
+
+[Udemy_API](https://www.udemy.com/course/restful-apis/learn/lecture/6119416?start=0#overview)
+
+[Udemy_SQL](https://www.udemy.com/course/bancos-de-dados-relacionais-basico-avancado/learn/lecture/19043190?start=0#overview)
+
+[JS_For_Testers](https://www.youtube.com/playlist?list=PLzDWIPKHyNmLxpL8iQWZXwl_ln0BgckL)
+
+[CypressYT_Lesson](https://www.youtube.com/watch?v=Dbk2jeNBOrE)
+
+[CypressDIO_Course](https://web.dio.me/course/implementando-testes-automatizados-usando-cypress-em-uma-aplicacao-angular/learning/ea18fc2f-6620-4d38-931a-66f43cf9684b?back=/home)
+
+[SoftwareTesting](https://www.youtube.com/watch?v=NnamjfPYuiY)
+
+[CheatsheetMD](https://github.com/jpaulohe4rt/markdown4noobs/blob/master/src/Guia/Cheatsheet.md)
+
+[Good_Programming_Logic_Course](https://web.dio.me/course/logica-de-programacao-essencial/learning/10621ad4-a358-4cfb-b299-e1c4694e2939?back=/home)
+
+[4noobsHea4rtLabs](https://github.com/he4rt/4noobs)
+
+[Postman](https://web.postman.co/bootcamp)
+
+[Java_Lesson](https://web.dio.me/course/desenvolvimento-basico-em-java/learning/5ba0edbd-5ba3-4afb-ac63-471f736ad110)
+
+[LinkedIn_Job](https://www.linkedin.com/in/arthur-carneiro-153a9b169/)
+
+[GitHub_Jobs](https://github.com/frontendbr/vagas/issues)
+
+[GitHub_Profile_Generator](https://gprm.itsvg.in)
+
+qacademy.io
+
+Ishikawa Diagram/Fishbone Diagram/Cause-and-Effect Diagram
+
+The 7 tools of quality:
+
+1 - [Histogram](https://ferramentasdaqualidade.org/histograma/)
+
+2 - [Flowchart](https://www.voitto.com.br/blog/artigo/fluxograma)
+
+3 - [Control Chart](https://eprconsultoria.com.br/carta-de-controle/)
+
+4 - [Ishikawa](https://www.siteware.com.br/metodologias/diagrama-de-ishikawa/)
+
+5 - [Check Sheet](https://ferramentasdaqualidade.org/folha-de-verificacao/)
+
+6 - [Scatter Plot](https://www.siteware.com.br/metodologias/o-que-e-diagrama-de-dispersao) <- High complexity
+
+7 - [Pareto Chart](https://ferramentasdaqualidade.org/diagrama-de-pareto/)
+
+[SeleniumMegaCourse](https://www.youtube.com/playlist?list=PLOQgLBuj2-3LqnMYKZZgzeC7CKCPF375B)
+
+[AgileTesters](https://agiletesters.com.br/)
+
+[Locust.io](https://locust.io/)
+
+[Kotlin](https://kotlinlang.org/docs/getting-started.html#install-kotlin)
diff --git a/docs/en/guide/README.md b/docs/en/guide/README.md
new file mode 100644
index 0000000..6e1dbeb
--- /dev/null
+++ b/docs/en/guide/README.md
@@ -0,0 +1,32 @@
+# He4rt Developers - 4noobs
+
+Welcome to the 4noobs of tests! We are very happy to see you here.
+
+In this course you will learn about software testing from absolute zero to some of the most used techniques in the market.
+
+We hope you enjoy it and that this content helps you become a better professional.
+
+For any questions, please contact us on [He4rt Developers Discord](https://discord.com/invite/5kwDQuv).
+
+Good studies!
+
+## Summary
+
+1. [Testing Foundations](00-FOUNDATIONS.md)
+1. [Testing Approaches](01-ABORDAGENS.md)
+1. [Types of Tests](02-TIPOS.md)
+1. [Project Administration](03-ADMIN.md)
+1. [Test Execution](04-EXECUCAO.md)
+
+## Credits
+
+- **Victor Manoel** - _Software Quality Engineer_ - [@Keeabo](https://www.linkedin.com/in/victor-manoel-0b4413191/)
+- **Victor Wildner** - _Software Quality Engineer_ - [@vcwild](https://twitter.com/vcwild)
+
+## References
+
+- [ISQTB CTFL](https://www.istqb.org/certifications/certified-tester-foundation-level)
+- [Agile Testers](https://agiletesters.com.br/)
+- [Roadmap QA](https://roadmap.sh/qa)
+- [Cypress Course DIO](https://web.dio.me/course/implementando-testes-automatizados-usando-cypress-em-uma-aplicacao-angular/learning/ea18fc2f-6620-4d38-931a-66f43cf9684b?back=/home)
+- [qacademy.io](https://qacademy.io/)
diff --git a/docs/guide/03-ADMIN.md b/docs/guide/03-ADMIN.md
index ceebcf1..8b3b4ad 100644
--- a/docs/guide/03-ADMIN.md
+++ b/docs/guide/03-ADMIN.md
@@ -14,5 +14,6 @@ Vejamos como podemos administrar um projeto:
1. [Método Waterfall](../03-admin/06-waterfall.md)
1. [Método V-Model](../03-admin/07-v-model.md)
1. [Elaborando um relatório de testes](../03-admin/08-report.md)
+1. [Verificação e Validação](../03-admin/09-verificacao.md)
← [Voltar ao Roadmap](README.md)