From c8891d3040a0c0ef94d072f727f6034db08e5a84 Mon Sep 17 00:00:00 2001
From: Victor Manoel <117121760+VictorMPicoli@users.noreply.github.com>
Date: Sat, 14 Oct 2023 05:46:59 -0300
Subject: [PATCH] Docs: Rewrite Chapter 0 - Foundations (#11)

* docs: copied project structure for english translation

* Translation of folders 00 and 01

* Update of the translation proccess, please review item 06-unit.md for correct use of "Unit" terminology and all items for image sources integrity
---
 docs/en/00-foundation/00-intro.md             |  62 ++++
 .../00-foundation/01-tradicional-vs-agile.md  |  32 ++
 docs/en/00-foundation/02-interaction.md       |  18 ++
 docs/en/00-foundation/03-tools.md             |  39 +++
 docs/en/00-foundation/04-artifacts.md         |  36 +++
 docs/en/00-foundation/05-identify.md          |  41 +++
 .../00-foundation/06-cases-report-incident.md |  47 +++
 docs/en/00-foundation/07-questions.md         | 306 ++++++++++++++++++
 docs/en/01-approachs/00-intro.md              |  32 ++
 docs/en/01-approachs/01-white-box.md          | 111 +++++++
 docs/en/01-approachs/02-black-box.md          |  41 +++
 docs/en/01-approachs/03-gray-box.md           |  61 ++++
 docs/en/02-types/00-intro.md                  |   7 +
 docs/en/02-types/01-functional.md             |  92 ++++++
 docs/en/02-types/02-uat.md                    |  98 ++++++
 docs/en/02-types/03-exploratory.md            |  59 ++++
 docs/en/02-types/04-sanity.md                 |  60 ++++
 docs/en/02-types/05-regression.md             |  98 ++++++
 docs/en/02-types/06-unit.md                   |  98 ++++++
 docs/en/02-types/07-smoke.md                  |  46 +++
 docs/en/02-types/08-integration.md            | 160 +++++++++
 docs/en/02-types/09-non-functional.md         |  41 +++
 docs/en/02-types/10-load.md                   |  60 ++++
 docs/en/02-types/11-performance.md            | 116 +++++++
 docs/en/02-types/12-stress.md                 |  96 ++++++
 docs/en/02-types/13-pentest.md                |  78 +++++
 docs/en/02-types/14-accessibility.md          |  90 ++++++
 docs/en/02-types/15-compatibility.md          |  32 ++
 docs/en/03-admin/00-intro.md                  |   9 +
 docs/en/03-admin/01-plan.md                   | 266 +++++++++++++++
 docs/en/03-admin/01-priorizacao.md            | 105 ++++++
 docs/en/03-admin/02-sldc.md                   | 105 ++++++
 docs/en/03-admin/03-agile.md                  |  46 +++
 docs/en/03-admin/04-scrum.md                  | 108 +++++++
 docs/en/03-admin/05-kanban.md                 | 101 ++++++
 docs/en/03-admin/06-waterfall.md              |  51 +++
 docs/en/03-admin/07-v-model.md                |  41 +++
 docs/en/03-admin/08-report.md                 | 110 +++++++
 docs/en/03-admin/09-verificacao.md            | 129 ++++++++
 docs/en/04-execucao/00-intro.md               | 232 +++++++++++++
 docs/en/04-execucao/01-manual.md              |  65 ++++
 docs/en/04-execucao/02-automatizado.md        | 213 ++++++++++++
 42 files changed, 3638 insertions(+)
 create mode 100644 docs/en/00-foundation/00-intro.md
 create mode 100644 docs/en/00-foundation/01-tradicional-vs-agile.md
 create mode 100644 docs/en/00-foundation/02-interaction.md
 create mode 100644 docs/en/00-foundation/03-tools.md
 create mode 100644 docs/en/00-foundation/04-artifacts.md
 create mode 100644 docs/en/00-foundation/05-identify.md
 create mode 100644 docs/en/00-foundation/06-cases-report-incident.md
 create mode 100644 docs/en/00-foundation/07-questions.md
 create mode 100644 docs/en/01-approachs/00-intro.md
 create mode 100644 docs/en/01-approachs/01-white-box.md
 create mode 100644 docs/en/01-approachs/02-black-box.md
 create mode 100644 docs/en/01-approachs/03-gray-box.md
 create mode 100644 docs/en/02-types/00-intro.md
 create mode 100644 docs/en/02-types/01-functional.md
 create mode 100644 docs/en/02-types/02-uat.md
 create mode 100644 docs/en/02-types/03-exploratory.md
 create mode 100644 docs/en/02-types/04-sanity.md
 create mode 100644 docs/en/02-types/05-regression.md
 create mode 100644 docs/en/02-types/06-unit.md
 create mode 100644 docs/en/02-types/07-smoke.md
 create mode 100644 docs/en/02-types/08-integration.md
 create mode 100644 docs/en/02-types/09-non-functional.md
 create mode 100644 docs/en/02-types/10-load.md
 create mode 100644 docs/en/02-types/11-performance.md
 create mode 100644 docs/en/02-types/12-stress.md
 create mode 100644 docs/en/02-types/13-pentest.md
 create mode 100644 docs/en/02-types/14-accessibility.md
 create mode 100644 docs/en/02-types/15-compatibility.md
 create mode 100644 docs/en/03-admin/00-intro.md
 create mode 100644 docs/en/03-admin/01-plan.md
 create mode 100644 docs/en/03-admin/01-priorizacao.md
 create mode 100644 docs/en/03-admin/02-sldc.md
 create mode 100644 docs/en/03-admin/03-agile.md
 create mode 100644 docs/en/03-admin/04-scrum.md
 create mode 100644 docs/en/03-admin/05-kanban.md
 create mode 100644 docs/en/03-admin/06-waterfall.md
 create mode 100644 docs/en/03-admin/07-v-model.md
 create mode 100644 docs/en/03-admin/08-report.md
 create mode 100644 docs/en/03-admin/09-verificacao.md
 create mode 100644 docs/en/04-execucao/00-intro.md
 create mode 100644 docs/en/04-execucao/01-manual.md
 create mode 100644 docs/en/04-execucao/02-automatizado.md

diff --git a/docs/en/00-foundation/00-intro.md b/docs/en/00-foundation/00-intro.md
new file mode 100644
index 0000000..e331d8c
--- /dev/null
+++ b/docs/en/00-foundation/00-intro.md
@@ -0,0 +1,62 @@
+# **Fundamentos do Teste de Software**
+
+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
+
+The QA test in a software involves the testing of:
+
+- Performance
+- Adaptability
+- Functionality
+
+However, software quality assurance extends beyond the quality of the software itself. The activity also encompasses the quality of the **process**:
+
+
+- Development
+- Testing
+- Deployment
+
+# Quality Assurance (QA) in Software Development
+
+**Quality Assurance (QA)** focuses on the development cycle, which includes software requirements management, design, coding, testing, and release.
+
+Let's understand the fundamentals of software testing and how to apply them in our daily lives.
+
+## What is Quality?
+
+Quality can be simply defined as *"fit for use or function"*. The idea is to meet customers' needs and expectations regarding functionality, design, reliability, durability, and product price.
+
+## What is Assurance?
+
+Assurance is nothing more than a positive statement about a product or service that conveys confidence. It is the assurance that a product or service provides, indicating that it will function exactly as intended.
+
+Assurance ensures that it will work without any problems according to expectations and requirements.
+
+## Quality Assurance in Software Testing
+
+**Quality Assurance in testing** is defined as a procedure to ensure the quality of software products or services provided to customers by a company.
+
+QA focuses on improving the **software development process**, making it efficient and effective according to the defined quality parameters for software products.
+
+## *Error, Defect, and Failure*
+
+- **Error:** Human action that produces incorrect results.
+- **Defect:** Manifestation of the error in the software, also known as a *bug*.
+- **Failure:** Undesirable difference between observed and expected behavior (defect found).
+
+A person makes an **error**, which creates a **defect in the software**, which may or may not cause a **failure** in operation.
+
+## Testing Mindset
+
+As a QA engineer, your job is to look for failure points in a product, whatever it may be, and report them so they can be fixed, ensuring the highest quality product.
+
+To perform your function successfully, it's necessary to have the right mindset:
+
+- **Think as destructively and creatively as possible**
+
+**Important points:**
+
+1. Know the product you are testing.
+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
diff --git a/docs/en/00-foundation/01-tradicional-vs-agile.md b/docs/en/00-foundation/01-tradicional-vs-agile.md
new file mode 100644
index 0000000..f22064f
--- /dev/null
+++ b/docs/en/00-foundation/01-tradicional-vs-agile.md
@@ -0,0 +1,32 @@
+# **Traditional and Agile Testing**
+
+In testing techniques, there are two types of tests: traditional and agile.
+
+Traditional tests are based on a waterfall model lifecycle, where testing is conducted after software construction, with a focus on finding defects.
+
+On the other hand, agile tests are based on an iterative and incremental lifecycle model, where testing occurs during software construction, focusing on defect prevention.
+
+## *7 Principles of Traditional Testing*
+
+1. Testing demonstrates the presence of defects; however, it does not guarantee their absence.
+2. Exhaustive testing is impossible: Consider application risks and priorities, selecting possible values to provide maximum test coverage.
+3. Testing should start as early as possible; errors found later cost more to fix.
+4. Clustering of defects.
+5. Pesticide Paradox.
+6. Testing is context-dependent.
+7. The fallacy of absence of errors.
+
+## *Testing in Agile Methodology*
+
+The focus of Agile QA is on:
+
+- Bug prevention, identifying issues early to reduce costs and efforts.
+- Ensuring clear customer expectations.
+- Embracing new ideas.
+- The Tester is part of a team.
+- Quality is the team's responsibility.
+- Testing is an integral part of the software development process.
+
+Traditional QA focuses on finding defects, figuring out ways to break the software.
+
+Agile QA aims to prevent errors, identifying bugs in the early stages to optimize application construction, avoiding rework, and minimizing risks.
diff --git a/docs/en/00-foundation/02-interaction.md b/docs/en/00-foundation/02-interaction.md
new file mode 100644
index 0000000..ae3e697
--- /dev/null
+++ b/docs/en/00-foundation/02-interaction.md
@@ -0,0 +1,18 @@
+# **Interaction with the Team**
+
+- Agile Principles
+
+1. Face-to-face Communication: The most effective communication method is in person. Unlike the traditional model where the tester had limited access to other team members, here, developers and testers work side by side.
+2. Continuous Feedback: Working in sprints involves constant testing, providing immediate and progressive feedback to the team.
+3. Continuous Improvement: Both in processes and people, values of transparency, professional development.
+4. Have Courage
+5. Deliver Value to the Customer: Testers need to be close to the customer, understand their needs, and translate them into business-focused test scenarios.
+6. Keep it Simple: The nature of testing is to validate various aspects, but simplification and prioritization based on customer needs are necessary. Use lighter tools to optimize the development process.
+7. Respond to Changes: Adaptability to new scenarios and conditions that may occur during sprints, learning new skills and attitudes to become adaptable.
+8. Self-Organization: Agile teams self-organize to solve a problem in the best way, considering each team member's skills. This dynamic emerges from the team itself, requiring autonomy and collaboration with the team's purpose.
+9. People Focus: Agile methodology is more about people, the human factor, than methodological and bureaucratic factors. Apply all other principles and stay close to other team members for collaboration.
+10. Have Fun
+
+In this context, the tester plays an active and fundamental role in the product development process, from understanding business rules to delivering the complete product.
+
+They must add value by being a quality reference, serving the team and the customer, using their critical and analytical skills to find solutions to the team's problems.
diff --git a/docs/en/00-foundation/03-tools.md b/docs/en/00-foundation/03-tools.md
new file mode 100644
index 0000000..7751eff
--- /dev/null
+++ b/docs/en/00-foundation/03-tools.md
@@ -0,0 +1,39 @@
+# **Tools and Their Objectives**
+
+The main tools used in the process are subdivided into categories, according to the objective of each one.
+
+## **Categories of Tools**
+
+- **Project Management and Version Control Tools:**
+
+Used throughout the development process, from defining requirements and versioning them for staging, to project versioning for secure and risk-free implementation.
+
+Version control is applied to create stable releases for client delivery, while unvalidated development is restricted to test branches. This ensures there is always a stable, bug-free, and validated version in case an implemented feature breaks the code.
+
+### **Test and Defect Management Tools**
+
+- **Test Management:**
+  TestLink allows the creation of test cases and manages their execution, helping identify failed or successful tests. It also assists in assigning tests among team members and supervising the execution.
+
+- **Defect Management:**
+  Enables describing the found flaw, assigning severity, work allocation among team members, development tracking, separation by status, inclusion of test evidence, etc.
+
+### **Test Automation Tools**
+
+Test automation tools are used for executing repetitive tests that do not require human intervention, such as interface tests, integration tests, performance tests, security tests, regression tests, etc. It is a broad concept, varying between programming languages and different methodologies for automating manual tests.
+
+### **Performance Testing**
+
+Some performance testing tools include:
+
+- **JMeter:** Allows the creation of test scripts and simulation of various users, monitoring response time, service errors, and providing multiple reports.
+
+- **Gatling:** Monitors the application continuously and alerts upon detecting errors and slowdowns.
+
+- **LoadComplete:** Combines both functions by allowing script creation and continuous performance monitoring.
+
+- **BlazeMeter:** Enables the creation of test scripts and user simulation from various servers worldwide.
+
+### **Supporting Tools**
+
+May or may not be used; they formalize the process, performing similar functions as management tools.
diff --git a/docs/en/00-foundation/04-artifacts.md b/docs/en/00-foundation/04-artifacts.md
new file mode 100644
index 0000000..89710ac
--- /dev/null
+++ b/docs/en/00-foundation/04-artifacts.md
@@ -0,0 +1,36 @@
+# **Artifact Review**
+
+*Artifacts*: Types of tangible subproducts produced during software development. All the involved documentation such as use cases, requirements, and documentation describing the design and architecture.
+
+The inspection process involves planning, individuals reviewing each artifact, meetings for discussions and record-keeping, passing defects back to the author, and an overall assessment regarding the need for a new inspection based on changes during the process.
+
+## *Definition of Concepts*
+
+The term defect is often used generically, but it's essential to understand that the interpretation depends on the usage context. Defects found through inspection relate to deficiencies in the reviewed artifact, software faults described in IEEE 830, 1998.
+
+IEEE defines quality attributes that a requirements document must have; the lack of any of these attributes characterizes a defect:
+
+- Omissions 1-5:
+  - 1: Important requirement related to functionality, performance, external interface.
+  - 2: Software response to all possible input data situations.
+  - 3: Lack of sections in requirement specifications.
+  - 4: Absence of references like figures, tables, or diagrams; visual representation is common when describing a use case or software specification.
+  - 5: Lack of definition of unit measurement terms; in a field, we need to know how many characters it supports, input of text, and a series of components that need unit measurement definition, like a numeral.
+
+- Ambiguity: A requirement with multiple meanings in a term for a specific context, making it challenging to understand functionality, leaving room for defects.
+
+- Inconsistency: More than one conflicting requirement, conflicting instructions for the same context.
+
+- Incorrect Fact: Requirement describing a fact not true considering established system conditions. Asks for A, returns B.
+
+- Extraneous Information: Information provided in the requirement that is unnecessary or won't be used; inefficient description, increasing documentation and opening room for conflicting interpretations.
+
+- Others: Various, like placing a requirement in the wrong section of the document, applying a rule in the wrong place, for example.
+
+These classes can be further subdivided into more specific classifications depending on the need.
+
+## *Benefits of Applying Software Inspections*
+
+Inspections find errors early in the process, aiming to prevent rework in subsequent cycles, as costs and time exponentially increase throughout the development cycle.
+
+This promotes increased productivity in the team, generating more understandable artifacts, facilitating inspection, and benefiting subsequent phases of the cycle, such as the maintenance phase of the documentation.
diff --git a/docs/en/00-foundation/05-identify.md b/docs/en/00-foundation/05-identify.md
new file mode 100644
index 0000000..a758c22
--- /dev/null
+++ b/docs/en/00-foundation/05-identify.md
@@ -0,0 +1,41 @@
+# How to Identify What to Test
+
+During the testing process, it's necessary to identify what needs to be tested. To do this, understanding what a test is and how it's conducted is crucial.
+
+## The 3 Main Ways to Document a Test
+
+Let's understand the 3 ways to document a test so that we can identify what needs to be tested.
+
+### Test Scripts
+
+The most detailed way to document a test, scripts typically detail step-by-step actions and necessary data to run the test. It often includes steps to understand how the user interacts, what actions to perform, and in what order, including specific outcomes for each step, such as verifying changes.
+For example, the action might be clicking button X, and the result is a window closing. At the start of a project, the tester might not have an in-depth understanding of the function. Scripts assist in the smooth development of the process and understanding the system. However, projects often undergo changes, with pages redesigned, new features added, etc., so scripts must be regularly updated. The drawback here is that time spent updating the script could be invested in executing more tests. Moreover, scripts are designed to test very specific and repetitive actions, leaving room for bugs outside these predefined paths to go undetected, requiring constant evolution.
+
+### Test Cases
+
+The second most detailed way, test cases describe a specific idea to be tested without detailing the exact steps to be executed. For example, testing if a discount code can be applied to a discounted product. This doesn't describe which codes will be used, allowing different approaches to find the result. It provides greater decision flexibility to the tester to complete the test, benefiting experienced testers with a good understanding of the system's nature and functions. However, the absence of this familiarity and experience allows bugs to go unnoticed.
+
+### Test Scenarios
+
+The least detailed documentation, describing the goal the user might achieve when using the program. For instance, testing if the user can log out of the program when closing it. Various techniques are needed to properly validate and test the function, as scenarios provide minimal specification. Testers have ample flexibility in developing the test. This flexibility offers the same pros and cons as seen in test cases, being liberating for experienced testers and nearly impossible for novices.
+
+A combination of these modalities, often used simultaneously, can be employed, divided among the team based on their different skills and competencies within the project's specific context.
+
+## How to Identify What to Test
+
+Let's understand the different ways to test.
+
+### Documentation-Based Testing
+
+When conducting any test, the most up-to-date documentation should be requested, such as use cases, business rules, and any relevant documentation.
+
+It's crucial to start, finish, and report test cases continuously once the documentation is available, preventing forgetfulness and future rework.
+
+### Testing Techniques
+
+Testing everything is impossible, so applying techniques is essential to cover as much of the system as possible in the shortest time.
+
+- **Soft Skills**
+- **Exploratory Curiosity**
+- **Active Listening:** Not all information is in documents; sometimes, it's in people.
+- **Team Player:** Actively contribute to the group to complete tasks, achieve goals, and collaborate for the common objective.
diff --git a/docs/en/00-foundation/06-cases-report-incident.md b/docs/en/00-foundation/06-cases-report-incident.md
new file mode 100644
index 0000000..e3418e9
--- /dev/null
+++ b/docs/en/00-foundation/06-cases-report-incident.md
@@ -0,0 +1,47 @@
+# Test Cases, Incident Reports, and Priorities
+
+When conducting tests, it's necessary to write test cases for organized and standardized testing. Incident reports should be documented to fix issues and ensure software quality. Additionally, prioritizing incidents is essential to fix them according to their importance.
+
+## How to Write Test Cases from a User Story
+
+- **What Are User Stories**
+
+An informal and general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature can deliver value to the customer. They are not system requirements but are key components in development that emphasize end users, using non-technical language to provide context to the development team, instructing them on what they are building and what value it will generate for the user.
+
+They enable a user-centered structure, promoting collaboration, creativity, and product quality. They articulate how a single task can offer specific value to the customer.
+
+They are written in a few sentences with simple language that outlines the desired result. Requirements are added later once the team agrees on the user stories.
+
+### Example of a User Story
+
+**As a** customer
+**I want** various payment methods to be available
+**So that** I can pay for my order.
+
+## Specification of Test Cases
+
+How is a test case written?
+
+- **Title:** It should be concise, simple, and self-explanatory, providing information so the analyst knows the validation the test aims for (Validate User Registration, Order Placement, etc.).
+- **Detailed Objective:** Describe what will be executed, providing an overview of the test to be performed. For example, "Check if file upload with allowed extensions is possible," "Verify if the purchase order is sent with information on asset, quantity, price, etc."
+- **Preconditions Necessary for Execution:** Prevents necessary information from being missing, such as not specifying that the user must be registered to perform the test. These are fundamental elements for the test to be executed correctly, such as the need for the user to have registered a note previously to test the query. The absence of preconditions will result in a flawed and inefficient test.
+- **Defined Steps:** Describe all actions the analyst must follow during execution until reaching the expected result. "Access X functionality," "Click on Y button," "Fill out the presented form," "Check if a blank form is displayed."
+- **Expected Results:** Describes the expected system behavior after executing the steps. "Valid," "Displays," "Recovers," "Returns." It should be direct and clear to avoid false positives. "System displays an editing screen with filled fields," "The order is sent and results in the informed price," "Registration is saved in the database."
+
+The case should be self-sufficient, including all necessary information for execution within its body. It should be concise, optimizing execution time, and should have as few steps as possible, facilitating the understanding of the required stages.
+
+It's also necessary to include both valid and unexpected inputs, as well as valid and expected inputs.
+
+## Bug Classification: Severity and Priority
+
+- **Severity:** Defines the degree or intensity of a defect concerning its impact on the software and its operation.
+  - **S1 - Critical/Showstopper:** Testing blockage or functionality that causes the application to crash or affects major use cases of key functionalities, security issues, severe data loss. Blockages that prevent testing other functions.
+  - **S2 - Major:** Problems related to unexpected information, unwanted defects, unusual input that causes irreversible effects, etc. Navigation is possible but generates significant errors in function.
+  - **S3 - Moderate:** Functionality does not meet certain acceptance criteria, such as error and success messages not displayed.
+  - **S4 - Minor:** Has little impact, interface errors, typos, misordered columns, design flaws.
+
+- **Priority:** Bugs viewed from a business perspective, indicating which ones should be fixed first based on demand and current context.
+  - **P1 - Critical:** Must be fixed immediately. Severity 1, performance errors, graphical interface affecting the user.
+  - **P2 - High:** Functionality is not usable as it should be due to code errors.
+  - **P3 - Medium:** Problems that can be evaluated by the developer and the tester for a later cycle depending on available resources.
+  - **P4 - Low:** Text errors, minor user experience and interface improvements.
diff --git a/docs/en/00-foundation/07-questions.md b/docs/en/00-foundation/07-questions.md
new file mode 100644
index 0000000..bc9ff8e
--- /dev/null
+++ b/docs/en/00-foundation/07-questions.md
@@ -0,0 +1,306 @@
+# Questions and Answers
+
+Let's review the concepts learned so far and answer some questions.
+
+## *1) What are the phases involved in the software testing life cycle?*
+
+- Test Planning: Strategy to be applied in testing.
+- Test Case Development: Defining and developing test cases.
+- Environment Setup: Configuring the necessary software and hardware for testing.
+- Execution: Running the code and comparing expected results with actual results.
+- Closure: Evaluation of completion criteria based on test coverage, quality, critical business objectives, etc.
+
+## *2) What are the different types of testing?*
+
+- Black Box Testing: Based on requirements and specifications, without an internal view of software functionality, from a user perspective.
+- White Box Testing: Based on internal structure, architecture, and source code, used to test system units.
+- Gray Box Testing: Software debugging, tester has limited knowledge of internal functioning, mixed approach.
+
+## *3) What are the different levels of testing?*
+
+- Unit Testing: Validates individual parts of the code.
+- Integration Testing: Validates the interaction of individual project parts and their interaction with external interfaces.
+- System Testing: Functional, actually uses the system.
+- Acceptance Testing: With the user, system acceptance.
+
+## *4) Explain the bug life cycle or defect life cycle*
+
+- Defect Found (NEW)
+- Assign: Assign to a developer for correction.
+- Activity: Resolving the bug itself, reject or accept, return for further explanations, etc.
+- Testing: The fixed bug is tested again for validation. If it's not fixed, it returns to the activity phase.
+- Closed: Fixed, validated, closed.
+
+## *5) What is a test case?*
+
+It is a set of conditions and variables under which a tester will determine if a system under test meets the functional requirements correctly.
+
+## *6) What is the difference between functional and non-functional tests?*
+
+- Functional: **Performed before non-functional tests**, based on client requirements, describes what the product does.
+- Non-Functional: **Performed after functional tests**, based on client expectations, describes how the product works.
+
+## *7) What is Verification and Validation in Software Testing?*
+
+Verification - Static analysis technique, checks documentation, testing is done without code execution (review, inspection, step-by-step testing).
+
+Validation - Dynamic analysis technique where testing is done by executing the code (non-functional and functional testing techniques).
+
+## *8) What is usability testing?*
+
+Testing methodology where the end user is asked to use the software to check ease of use, perception, system performance, etc. A precise way to understand the customer's perspective, using prototypes, mocks, etc.
+
+## *9) What is coverage, and what are the different coverage techniques?*
+
+A parameter to describe how much source code is tested.
+
+- Statement Coverage: Ensures that each line of code was executed and tested.
+- Decision Coverage: Ensures that all true and false paths were executed and tested.
+- Path Coverage: Ensures that all possible routes through a specific part of the code were executed and tested.
+
+## *10) A defect that could have been removed during the initial stage is removed at a later stage. How does this affect cost?*
+
+Defects should be removed as early as possible because postponing removal increases costs exponentially. Early-phase removal is cheaper and simpler.
+
+## *11) What is regression and confirmation testing?*
+
+- Regression: Confirms that a recent code change does not adversely affect existing features.
+- Confirmation: When a test fails due to a defect, it is reported, a new version of the corrected software is sent, and the test is re-run. This is confirmation of the correction.
+
+## *12) What is the basis for estimating your project?*
+
+To estimate a project, you should:
+
+- Break down the entire project into smaller tasks.
+- Assign each task to team members.
+- Estimate the effort required to complete each task.
+- Validate the estimation.
+
+## *13) Which test cases are written first: white box or black box?*
+
+Usually, **black box test cases** are written first.
+
+Since these only require requirements and design documents or a project plan, these documents are readily available at the beginning of the project.
+
+White box tests cannot be executed in the initial project phase because they require a clearer understanding of the architecture, which is not available in the early stages. Therefore, they are generally written **after** black box tests.
+
+## *14) Mention the basic components of the defect report format*
+
+- Project Name
+- Module Name (if applicable)
+- Defect Detected In
+- Defect Detected By
+- Where the Defect Was Found
+- Defect ID and Name
+- Defect Snapshot (bug evidence)
+- Priority/Severity Status
+- Defect Resolved By
+- Defect Resolved On (date)
+
+## *15) What does the Cascade of Defects mean?*
+
+Cascading defects occur when one defect is caused by another defect, one defect adds to another.
+
+When a defect is present in any stage but goes unnoticed and unaddressed, it results in a significant increase in the number of defects.
+
+They are mostly detected during regression testing.
+
+## *16) What are the defect categories?*
+
+- Wrong: Indicates that requirements were implemented incorrectly, a deviation from the provided specification.
+- Missing: A variation from the specifications, an indication that a specification was not implemented, or a customer requirement was not noted correctly.
+- Extra: An attribute desired by the product's end user, not provided by the final customer. It is always a deviation from the specification but may be a desired attribute by the product's user.
+
+## *17) On what basis is the acceptance plan prepared?*
+
+- Requirement Document: Specifies what is required in the project from the customer's perspective.
+- Customer Input: May include discussions, informal conversations, emails, etc.
+- Project Plan: The project plan prepared by the project manager also serves as good input to finalize acceptance testing.
+
+## *18) Why is Selenium the preferred tool for automation testing?*
+
+Selenium is an open-source tool designed to automate web browser testing. Since Selenium is open source, there is no licensing cost, which is a significant advantage over other testing tools. Other reasons include:
+
+- Test scripts can be written in various programming languages: Java, Python, C#, PHP, Ruby, Perl, and more.
+- Tests can be conducted in various web browsers: Mozilla, IE, Chrome, Safari, or Opera.
+- It can be integrated with tools like TestNG and JUnit for test case management and report generation.
+- Integration with Maven, Jenkins, and Docker for continuous testing.
+
+## *19) What are the various components of Selenium?*
+
+- Selenium Integrated Development Environment (IDE)
+- Selenium Remote Control (RC)
+- Selenium WebDriver
+- Selenium Grid
+
+## *20) What are the different types of locators in Selenium?*
+
+A locator is an address that uniquely identifies a web element within a web page. To identify web elements accurately, Selenium offers different types of locators, including:
+
+- ID
+- Class Name
+- Name
+- Tag Name
+- Link Text
+- Partial Link Text
+- XPath
+- CSS Selector
+- DOM
+
+
+## *21) What is XPath?*
+
+XPath, also known as XML Path, is a language for querying XML documents. It is a crucial strategy for locating elements in Selenium automation. XPath comprises a path expression along with certain conditions. Here, you can easily write an XPath script/query to locate any element on a web page. XPath is designed to enable navigation of XML documents with the aim of selecting individual elements, attributes, or specific parts of an XML document for processing. It also produces reliable locators.
+
+
+## *22) What is the Difference Between Absolute and Relative Path?*
+
+- Absolute XPath:
+
+It is the direct way to locate an element, but the disadvantage of absolute XPath is that if there is any change made to the element's path, the XPath will fail. For example:
+
+         /html/body/div[1]/section/div[1]/div
+
+- Relative XPath:
+
+For relative XPath, the path starts in the middle of the HTML DOM structure. It begins with a double forward slash (//), which means it can search for the element anywhere on the web page. For example:
+
+       // input [@ id = 'ap_email']
+
+## *23) When Should I Use Selenium Grid?*
+
+Selenium Grid can be used to execute identical or different test scripts on multiple platforms and browsers simultaneously, enabling distributed test execution, testing across different environments, and saving execution time.
+
+## *24) How Do I Launch the Browser Using WebDriver?*
+
+The following syntax can be used to launch the browser:
+
+WebDriver driver = new FirefoxDriver()
+
+Driver WebDriver = new ChromeDriver()
+
+Driver WebDriver = new InternetExplorerDriver()
+
+## *25) Should Testing Be Done Only After the Completion of Development and Execution Phases?*
+
+Testing is always done after the development and execution phases. The earlier a defect is detected, the more cost-effective it is. For example, fixing a defect during maintenance is ten times more expensive than fixing it during execution.
+
+## *26) What Is the Relationship Between the Reality of the Environment and Testing Phases?*
+
+As testing phases progress, the reality of the environment becomes more crucial. For instance, during unit testing, you need the environment to be partially real, but in the acceptance phase, you must have a 100% real environment, or we can say it should be **the** real environment.
+
+## *27) What Is Random Testing?*
+
+Usually, in random testing, data is generated randomly, often using a tool. For example, the figure below demonstrates how randomly generated data is fed into the system.
+
+This data is generated using an automated tool or mechanism. With this random input, the system is then tested, and the results are observed.
+
+## *28) Which Test Cases Can Be Automated?*
+
+- Smoke Testing
+- Regression Testing
+- Complex Calculation Testing
+- Data-Driven Testing
+- Non-functional Testing
+
+## *29) Based on What Can You Measure the Success of Automation Tests?*
+
+- Defect Detection Rate
+- Automation Execution Time and Time Savings for Product Launch
+- Reduction in Labor and Other Costs
+
+## *30) How to Click on a Hyperlink Using linkText()?*
+           driver.findElement(By.linkText("Google")).click();
+
+This command locates the element using the link text and then clicks on it. This way, the user would be redirected to the corresponding page.
+
+## *31) What Is TestNG?*
+
+It is an advanced framework designed to leverage the benefits of developers and testers. It also has a built-in exception handling mechanism that allows the program to run without unexpectedly terminating.
+
+## *32) How to Set the Test Case Priority in TestNG*
+
+The code below helps you understand how to set the test case priority in TestNG:
+
+      ```java
+      package TestNG;
+      import org.testing.annotation.*;
+
+      public class SettingPriority {
+            @Test(priority=0)
+            public void method1() {}
+
+            @Test(priority=1)
+            public void method2() {}
+
+            @Test(priority=2)
+            public void method3() {}
+      }
+      ```
+
+Test execution sequence:
+
+ 1. Method1
+ 2. Method2
+ 3. Method3
+
+## *33) What Is Object Repository? How Can We Create an Object Repository in Selenium?*
+
+Object repository refers to the collection of web elements belonging to the Application Under Test (AUT) along with their locator values. In the context of Selenium, objects can be stored in an Excel spreadsheet that can be filled within the script whenever needed.
+
+## *40) How to Enter Text in a Text Box Using Selenium WebDriver?*
+
+Using the **sendKeys()** method, we can enter text into the text box.
+
+## *41) What Are the Different Deployment Strategies for End Users?*
+
+- Pilot
+- Gradual Rollout
+- Phased Implementation
+- Parallel Implementation
+
+## *42) Explain How You Can Find Broken Links on a Page Using Selenium WebDriver*
+
+Let's assume the interviewer presents 20 links on a web page, and we need to check which of these 20 links are working and which ones are broken.
+
+The solution is to send HTTP requests to all the links on the web page and analyze the response. Whenever you use the **driver.get()** method to navigate to a URL, it will respond with a status of 200-OK. This indicates that the link is working and was successfully retrieved. Any other status indicates that the link is broken.
+
+First, we have to use the anchor tags `<a>` to identify the different hyperlinks on the web page.
+
+For each `<a>` tag, we can use the 'href' attribute value to get the hyperlinks and then analyze the response received when used in the **driver.get()** method.
+
+## *43) Which Technique Should Be Considered in the Script If There Is No ID or Name of the Frame?*
+
+If the frame's name and ID are not available, we can use **frame by index**. For example, if there are 3 frames on a web page, and none of them have a frame name or ID, we can select them using a frame index attribute (zero-based).
+
+Each frame will have an index number, with the first one being "0", the second one "1", and the third one "2".
+
+      driver.switchTo().frame(int arg0);
+
+## *44) How to Take Screenshots in Selenium WebDriver?*
+
+You can capture screenshots using the **TakeScreenshot** function. With the help of the **getScreenshotAs()** method, you can save the captured screenshot.
+
+Example:
+
+       scrFile = ((TakeScreenshot)driver).getScreenshotAs(outputtype.FILE)
+
+## *45) Explain How You Would Log into Any Site if It Shows an Authentication Pop-Up for Username and Password?*
+
+If there is a login pop-up, we need to use the explicit command and check if the alert is actually present. The following code helps understand the use of the explicit command.
+
+       WebDriverWait wait = new WebDriverWait(driver, 10);
+       Alert alert = wait.until(ExpectedConditions.alertIsPresent());
+       alert.authenticateUsing(new UserAndPassword(**username**, **password**));
+
+## *46) How to Skip a Method or Code Block in TestNG?*
+
+To skip a specific test method or code, you can set the 'enabled' parameter in the test annotation to *false*.
+
+          @Test(enabled=false)
+
+## *47) Explain Briefly What the Below Code Snippet Indicates?*
+
+      WebElement sample = driver.findElement(By.xpath("//[contains(text(), 'data')]"));
+
+It defines a *sample* variable of type WebElement and uses an Xpath search to initialize it with a reference to an element containing the text value "data".
diff --git a/docs/en/01-approachs/00-intro.md b/docs/en/01-approachs/00-intro.md
new file mode 100644
index 0000000..4b29de5
--- /dev/null
+++ b/docs/en/01-approachs/00-intro.md
@@ -0,0 +1,32 @@
+# Testing Approaches
+
+Testing an application is a process that must be done with great care because it ensures that the software is working correctly and there are no defects that could harm the user. However, creating tests is not an easy task. There are two approaches that can be used to create tests, each with its advantages and disadvantages. They are:
+
+- Proactive: where the test design process starts as early as possible to find and fix errors before the build is created.
+- Reactive: an approach where testing does not start until after the design and development are complete.
+
+Given these two approaches, we can say that the proactive approach is the most recommended because it allows tests to be created before the code, enabling the developer to fix errors before the code is implemented. On the other hand, the reactive approach is more commonly used in projects with tight schedules as it allows development to be done first, followed by testing.
+
+## Black Box vs. White Box
+
+Testing approaches can be divided into two categories, **black-box** and **white-box**. The difference between them is that black-box focuses on the system's behavior, while white-box focuses on the internal structure of the code.
+
+### Black Box
+
+Black-box tests are the most commonly used because they are easier to implement and do not require knowledge of the programming language used. Moreover, they are easier to understand for non-technical individuals and can be implemented in different programming languages.
+
+Key aspects of black-box tests include:
+
+- Primary focus on validating **functional** business rules.
+- Provides abstraction to the code and focuses on the system's behavior.
+- Facilitates test communication between modules.
+
+### White Box
+
+White-box tests are more challenging to implement as they require knowledge of the programming language used. They are also harder to understand for a layman and are more difficult to implement in different programming languages.
+
+Some key aspects of white-box tests include:
+
+- Validates **internal** structure and functionality of code.
+- Knowledge of the programming language used is essential.
+- Does not facilitate test communication between modules.
diff --git a/docs/en/01-approachs/01-white-box.md b/docs/en/01-approachs/01-white-box.md
new file mode 100644
index 0000000..ff2cd88
--- /dev/null
+++ b/docs/en/01-approachs/01-white-box.md
@@ -0,0 +1,111 @@
+# **White Box Testing**
+
+Some of the key concepts defining white box testing are:
+
+- Involves testing the internal mechanisms of an application; the tester must be familiar with the programming language used in the application being tested.
+
+- Code is visible to testers.
+
+- Identifies areas of a program that have not been exercised by a set of tests.
+
+A technique where the internal structure, design, and code are tested to verify the input-output flow and improve design, usability, and security.
+
+Here, the code is visible to testers, also referred to as Transparent Box Testing, Open Box Testing, Glass Box Testing, etc.
+
+## Test Targets
+
+Some of the main targets of white box testing are:
+
+- Internal security vulnerabilities
+- Broken or poorly structured paths in the coding process
+- Flow of inputs specified by the code
+- Expected output
+- Functionality of conditional loops
+- Testing of each statement, object, and function individually
+
+## How to Perform White Box Testing?
+
+Let's go through the step-by-step process of performing white box testing:
+
+### 1. Understand the Code
+
+The first thing a tester will typically do is learn and understand the application's source code.
+Since White Box Testing involves testing the internal mechanisms of an application, the tester must be familiar with the programming language used in the application being tested.
+Additionally, the tester must be aware of coding best practices.
+Security is often a primary goal of software testing; the tester must locate security breaches and prevent attacks from hackers and users who can inject malicious code into the application.
+
+### 2. Create Test Cases and Execute Them
+
+The second basic step for white box testing involves testing the source code for proper flow and structure.
+
+One way to do this is by writing additional code to test the source code.
+
+The tester will develop small tests for each process or series of processes in the application; this method requires the tester to have an intimate knowledge of the code and is often done by the developer.
+
+Other methods include manual testing, trial and error, and the use of testing tools.
+
+#### Example of White Box Testing
+
+Consider a simple code example for white box testing:
+
+```c
+void printme(int a, int b) {     // Printme is a function
+  int result = a + b;
+
+  if (result > 0)
+    print("Positive", result)
+  else
+    print("Negative", result)
+}                              // End of the source code
+```
+
+The goal of White Box Testing in software engineering is to verify all decision branches, loops, and statements in the code.
+
+### White Box Testing Techniques
+
+Most techniques involve Code Coverage analysis, which fills gaps in a Test Case.
+
+This identifies areas of a program that have not been exercised by a set of tests.
+
+Once gaps are identified, you create test cases to verify the untested parts of the code, enhancing the product's quality.
+
+Automated tools are available to apply Code Coverage analysis.
+
+### Forms of Test Coverage
+
+Below are some code coverage analysis techniques a tester can use:
+
+1. **Statement Coverage:** This technique requires that all possible code statements are tested at least once during the testing process.
+
+2. **Branch Coverage:** This technique checks all possible paths (if/else and other conditional loops) in an application.
+
+### Types of White Box Testing
+
+Let's look at how white box tests are categorized:
+
+#### **Unit Testing**
+
+Often the first type of test applied to a program.
+
+Unit testing is performed on each unit or block of the code during its development. It is essentially done by the developer, who develops a few lines of code, a single function, or an object and tests to ensure it works before moving forward.
+
+This type helps identify most bugs in the early stages of software development, being cheaper and faster to fix.
+
+#### **Memory Leak Testing**
+
+Memory leaks are the main causes of slow applications. A QA specialist experienced in detecting them is essential for applications running slowly.
+
+#### **Penetration Testing**
+
+In this test, the tester/dev has complete information about the source code, network details, IP addresses involved, and all server information where the application runs.
+The goal is to attack the code from various angles to expose security threats.
+
+### White Box Testing Tools
+
+Here are some white box testing tools:
+
+- [EclEmma](https://www.eclemma.org/download.html)
+- [NUnit](http://nunit.org/)
+- [PyUnit](https://www.guru99.com/python-unit-testing-guide.html)
+- [HTMLUnit](http://htmlunit.sourceforge.net/)
+- [CppUnit](https://sourceforge.net/projects/cppunit/)
diff --git a/docs/en/01-approachs/02-black-box.md b/docs/en/01-approachs/02-black-box.md
new file mode 100644
index 0000000..3110e75
--- /dev/null
+++ b/docs/en/01-approachs/02-black-box.md
@@ -0,0 +1,41 @@
+# Black Box Testing
+
+Black box testing aims to verify whether the system under scrutiny is functioning correctly, meaning it adheres to business rules and system specifications.
+
+Black box tests have the following characteristics:
+
+- Testing where the internal functionalities of the code are not accessible to the tester.
+- Done from the user's perspective.
+- Entirely focused on business rules and application specifications, also known as Behavioral Testing.
+
+## How to Apply Black Box Testing
+
+To apply black box testing, the tester must follow these steps:
+
+1. Initially, business rules and specifications are examined.
+2. The tester selects valid inputs (positive scenario testing) to check if the system processes them correctly. Invalid inputs (negative scenario testing) are also tested to verify if the system detects them.
+3. The tester determines the expected outputs for each of the selected inputs.
+4. The tester constructs test cases with the selected inputs.
+5. Test cases are executed.
+6. The tester compares actual outputs with ideal outputs.
+7. Defects, if any, are corrected and retested.
+
+### Types of Black Box Testing
+
+Black box tests can be classified as:
+
+- **Functional Testing:** Related to the business rules of a system; conducted by testers.
+  
+- **Non-Functional Testing:** **Not related** to testing any specific feature but rather non-functional business rules like performance, scalability, and usability.
+
+- **Regression Testing:** This mode is applied after any fixes, upgrades, or maintenance in the code to verify if these changes have not affected features previously tested successfully.
+
+## Black Box Testing Techniques
+
+The following techniques are used to test a system:
+
+- **Equivalence Class Testing:** Used to minimize the number of possible test cases to an optimized level while maintaining reasonable coverage.
+
+- **Boundary Value Analysis:** Focuses on values at boundaries. This technique determines if a certain range of values is acceptable by the system or not, very useful for reducing the number of test cases. It is more appropriate for systems where an input falls within certain scopes.
+
+- **Decision Table Testing:** A decision table inserts causes and their effects into a matrix, with a unique combination in each column.
diff --git a/docs/en/01-approachs/03-gray-box.md b/docs/en/01-approachs/03-gray-box.md
new file mode 100644
index 0000000..7e7828f
--- /dev/null
+++ b/docs/en/01-approachs/03-gray-box.md
@@ -0,0 +1,61 @@
+# Gray Box Testing
+
+Gray box tests are a combination of white-box and black-box testing methods. They are used to test a product or application with partial knowledge of the application's internal structure. The purpose of this testing is to search for and identify defects caused due to improper application structure or usage.
+
+Some of the key characteristics of gray box testing are:
+
+- It is a combination of white-box methods (with complete code knowledge) and black-box methods (with no code knowledge).
+- System defects can be reduced or prevented by applying gray box testing.
+- It is more suitable for GUI, functional, security, web applications, etc.
+
+In this process, context-specific errors related to web systems are commonly identified. This improves test coverage by focusing on all layers of any complex system.
+
+In QA, gray box testing provides an opportunity to test both the front-end and back-end of an application.
+
+## Why Apply Gray Box Testing?
+
+Some of the benefits of applying gray box testing include:
+
+1. It provides the combined benefits of both other modalities.
+2. It combines input from developers and testers, enhancing the overall product quality.
+3. It reduces the overall cost throughout the functional and non-functional testing process.
+4. It provides developers enough time to fix defects.
+5. Testing is done from a user's perspective rather than a designer's viewpoint.
+
+## Gray Box Testing Strategy
+
+To perform gray box testing, the tester does not need access to the source code.
+
+A test is designed based on knowledge of algorithms, structures, architectures, internal states, or other high-level descriptions of program behavior.
+
+### Techniques Used for Testing
+
+The primary techniques used for gray box testing are:
+
+- **Matrix Testing:** This testing technique involves defining **all variables** that exist in a program.
+- **Regression Testing:** To check if the change in the **previous version** has regressed other aspects of the program in the **new version**. This will be done by testing strategies like retest everything, retest risky features, and retest within a firewall.
+- **Matrix or Action-Oriented Testing (OAT):** Provides maximum code coverage with a minimum number of test cases.
+- **Pattern Testing:** This technique is performed on historical data from the previous version's defects in the system. Unlike black-box testing, gray box testing operates by digging into the code and determining why the failure occurred.
+
+### Steps to Apply Gray Box Testing
+
+Let's look at the steps to apply gray box testing:
+
+1. Identify the **inputs**.
+2. Identify the **outputs**.
+3. Identify the main **paths**.
+4. Identify the **sub-functions**.
+5. Develop **inputs** for the **sub-functions**.
+6. Develop **outputs** for the **sub-functions**.
+7. Execute test cases for the **sub-functions**.
+8. Verify the **correct result** for the **sub-functions**.
+9. Repeat steps 4 & 8 for other **sub-functions**.
+10. Repeat steps 7 & 8 for other **sub-functions**.
+
+Note that gray box test cases may include:
+
+- GUI-related.
+- Security-related.
+- Database-related.
+- Browser-related.
+- Operating System-related.
diff --git a/docs/en/02-types/00-intro.md b/docs/en/02-types/00-intro.md
new file mode 100644
index 0000000..ce06cf6
--- /dev/null
+++ b/docs/en/02-types/00-intro.md
@@ -0,0 +1,7 @@
+# Testing Techniques
+
+Testing techniques are the methods applied to evaluate a system or component with the purpose of determining if it satisfies the business rules.
+
+This helps identify gaps, errors, or any elements that deviate from the acceptance criteria.
+
+These techniques ensure overall quality for the product or software, including performance, security, user experience, etc.
diff --git a/docs/en/02-types/01-functional.md b/docs/en/02-types/01-functional.md
new file mode 100644
index 0000000..c39c067
--- /dev/null
+++ b/docs/en/02-types/01-functional.md
@@ -0,0 +1,92 @@
+# Functional Testing Techniques
+
+Functional testing is a type of testing that validates the system against specifications and acceptance criteria. The purpose of this type of testing is to test each function of the software by providing appropriate input and verifying the output according to the functional requirements.
+
+Let's explore some of the key functional testing techniques.
+
+## Equivalence Partitioning (BVA)
+
+Equivalence partitioning is a testing technique based on requirements in the documentation.
+
+Executed through the black-box approach, it provides the tester with a clear understanding of test coverage based on requirements and specifications.
+
+It does not require knowledge of internal paths, structure, and implementation of the software under test and reduces the number of test cases to a manageable level. It is intuitively used by most testers.
+
+Partitioning divides user inputs into partitions or classes of equivalence, and then subdivides them into ranges of possible values, so that one of these values is elected as the basis for the tests. There are partitions for:
+
+- Valid values, which should be accepted by the system.
+- Invalid values, which should be rejected by the system.
+
+Consider a human resources system in a company that processes employee requests based on age. We have a business rule related to age stating that individuals under 16 years old cannot work, individuals between 16-60 years old are eligible for hire, and those who are 60 years old or older are not suitable for the job.
+
+Dividing these rules, we have:
+
+- Invalid partition: 0-15
+- Valid partition: 16-60
+- Invalid partition: 60-
+
+Equivalence partitioning guides us to choose a subset of tests that will find more defects than a randomly chosen set.
+
+When working with partitions, we observe a maxim that states:
+
+    "Any value within a partition is as good as any other."
+
+Therefore, values belonging to the same partition must be treated equally by the system, meaning they will produce the same result. Thus, any value within the equivalence class, in terms of testing, is equivalent to any other.
+
+To achieve satisfactory test coverage when implementing this technique, test cases must cover all existing partitions. In the example under analysis, we have identified 3 partitions.
+
+A test script for age validation in the hiring module would have 3 test cases:
+
+C1: Age = 5
+
+According to the rule, it should not work; the expected value is "Should not hire."
+
+C2: Age = 33
+
+According to the rule, it can work; the expected value is "Can hire."
+
+C3: Age = 65
+
+According to the rule, it should not work; the expected value is "Should not hire."
+
+It is understood that within the range of values 0-15, regardless of which one is selected within the invalid partition, it should not be accepted by the system. The same applies to the range of 16-60, multiple possibilities that result in acceptance in the system.
+
+It is not necessary to test all possible values; the coverage is sufficient when choosing one within each partition.
+
+## Boundary Value Analysis
+
+It assumes that the behavior at the edge of a partition is more likely to cause errors.
+
+In the example, with the boundary value technique, we would select the value 15, invalid according to the system, then we select 16, borderline, but it should yield a positive result.
+
+A good practice of combining techniques is to select a random value for each partition, test it, and then validate the boundary values within each partition.
+
+- Decision Table:
+
+A relevant method for documenting business rules to be followed by the system, created from the analysis of functional specifications and identification of business rules.
+
+The table contains trigger conditions, combinations of true or false for data entry, and results for each of the combinations. It is a way to express in a tabular form which set of actions should occur to arrive at an expected result.
+
+The main point of the table is the business rule, which defines the set of actions to be taken based on a set of conditions.
+
+In the example, if we know that from 0-15 should not work, in the table, we establish that
+
+0-15 Cannot
+
+16-60 Can
+
+This combination can/cannot, is a visual representation to assist in documenting the rules the system follows.
+
+## Transition between States
+
+It is based on the idea that a system can exhibit different behaviors depending on its current state or previous events. Creating a diagram allows the test to visualize the statuses, i.e., the transitions, data entry, and events that trigger actions.
+
+The technique helps identify possible invalid transactions because knowing what the system expects, when testing the combinations, we can discover faulty transactions.
+
+A person can be eligible to work and then become ineligible, invalid.
+
+### Techniques Based on Experience
+
+These are techniques where tests are derived from the skills and experience of the tester, the individual visualization capability of the professional, based on their past work, enabling them to find errors and faults that others may not discover.
+
+This topic is better explored in the article on [exploratory testing](test).
diff --git a/docs/en/02-types/02-uat.md b/docs/en/02-types/02-uat.md
new file mode 100644
index 0000000..172ec98
--- /dev/null
+++ b/docs/en/02-types/02-uat.md
@@ -0,0 +1,98 @@
+# User Acceptance Testing (UAT)
+
+User Acceptance Testing (UAT), often simply called acceptance testing, is a type of testing applied by the end user or the client to verify and accept the system before progressing the application to the production environment.
+
+User Acceptance Testing is performed at the end of the testing phase, after functional, integration, and system testing.
+
+## Purpose of UAT
+
+The primary purpose of UAT is to validate the flow from start to finish.
+
+It does not focus on cosmetic errors, typos, or system testing, and is conducted in a separate test environment with a setup similar to the production environment.
+
+**It is similar to black-box testing where two or more end-users are involved**.
+
+## Why is UAT Necessary?
+
+The need for this test arises once the software has passed integration, system, and unit testing, as developers might have built the software based on documented business rules under their own understanding, **leaving a chance that any further necessary changes during this phase might not have been efficiently communicated to them**.
+
+Therefore, to verify if the final product is acceptable to the customer/user, this test becomes necessary.
+
+### Prerequisites for UAT
+
+- Acceptance criteria must be available.
+- Application code must be completely developed.
+- Unit, integration, and system testing must have been completed.
+- No major issues in integration testing.
+- Only cosmetic errors are acceptable before UAT.
+- Regression testing must have been completed without major issues.
+- All reported bugs must have been fixed and retested before UAT.
+- Traceability matrix for all testing must be complete.
+- The UAT environment must be ready.
+- Testing Team must give the go-ahead for UAT.
+
+## How to Perform UAT
+
+UAT is done by the target audience of the system or software.
+
+It is usually done at the client's location, which is commonly known as **Beta Testing**.
+
+Once the entry criteria for UAT are satisfied, the following tasks need to be performed by the testers:
+
+1. Analysis of Business Rules.
+2. Creation of UAT Test Plan.
+3. Creation of UAT Test Cases.
+4. Preparation of Test Data (as it would be in Production).
+5. Execution of Test Cases.
+6. Cataloging the results.
+7. Confirming acceptance criteria.
+
+### 1. Analysis of Acceptance Rules
+
+One of the most crucial activities in UAT is to identify and develop test scenarios. These scenarios are derived from the following documents:
+
+- Project Plan
+- Use Cases
+- Process Flow Diagrams
+- Necessary Business Documentation
+- System Requirements Specifications
+
+### 2. Creation of UAT Test Plan
+
+The test plan defines the strategy that will be applied to verify and ensure that the application meets the acceptance conditions. It documents entry and exit criteria for UAT, the approach for scenarios and test cases, as well as the testing timeline.
+
+### 3. Identification of Test Cases
+
+Identification of scenarios will respect the business process and create clear test cases. The cases should sufficiently cover most of the UAT scenarios. Business use cases are inputs for creating test cases.
+
+### 4. Preparation of Test Data
+
+Using real-time data for UAT is recommended. The data should be scrambled for security and privacy reasons. Testers should be familiar with the database flow.
+
+### 5. Execute and Document Results
+
+Execute the tests and report any bugs, retest the bugs once they are fixed.
+
+### 6. Confirm Business Rules
+
+Business Analysts or UAT Testers need to provide a statement after testing. With this confirmation, the product is ready to proceed to Production. Deliverables for UAT are the Test Plan, UAT scenarios and test cases, results, and defect log.
+
+## UAT Exit Criteria
+
+Before proceeding to the production environment, the following must be considered:
+
+- No critical defects without fixes.
+- Business processes function satisfactorily.
+- Meeting for positive UAT declaration with stakeholders.
+
+## Best Practices
+
+- Prepare the UAT plan early in the project life cycle.
+- Prepare the checklist before UAT starts.
+- Conduct pre-UAT sessions during the system testing phase itself.
+- Clearly define UAT expectations and scope.
+- Test the business flow from start to end and avoid system tests.
+- Test the system or application with real-life applicable scenarios and data.
+- Think like a user unfamiliar with the system.
+- Perform Usability testing.
+- Conduct feedback sessions and meetings before proceeding to Production.
diff --git a/docs/en/02-types/03-exploratory.md b/docs/en/02-types/03-exploratory.md
new file mode 100644
index 0000000..d964bea
--- /dev/null
+++ b/docs/en/02-types/03-exploratory.md
@@ -0,0 +1,59 @@
+# Exploratory Testing
+
+Exploratory testing involves evaluating a product by learning about it through exploration and experimentation, including:
+
+- Questioning;
+- Study;
+- Modeling;
+- Observation;
+- Inference;
+
+Often described as simultaneous learning, test design, and execution, it focuses on discovery and relies on the individual tester's guidance to uncover potential defects not easily covered within the scope of other tests.
+
+## Why Use Exploratory Testing?
+
+Most software quality tests use a **structured** approach, with test cases defined based on metrics such as user history and software engineering parameters, ensuring adequate coverage from a technical perspective.
+
+What's lacking is coverage for extreme cases, which are checked during UAT and tested based on user personas. Exploratory Testing, on the other hand, is **random**, or unstructured by nature, and can reveal bugs that wouldn't be discovered in structured testing modes.
+
+Test execution is implemented without creating formal steps, making it a precursor to automation.
+
+It helps formalize discoveries and automate documentation. With the aid of visual feedback and collaborative testing tools, the entire team can participate in exploratory testing, enabling quick adaptation to changes and promoting an agile workflow.
+
+Moreover, testers can convert exploratory test sequences into functional test scripts, automating the process.
+
+Hence, exploratory testing speeds up documentation, facilitates unit tests, and helps create an instant feedback loop.
+
+## When Should You Use Exploratory Testing?
+
+It is suitable for specific scenarios, such as when someone needs to learn about a product or application quickly and provide rapid feedback. Exploratory testing helps assess quality from the user's perspective.
+
+In many software cycles, an initial iteration is necessary when teams don't have much time to structure tests; exploratory tests are quite useful in this scenario.
+
+Exploratory testing ensures no critical failure case goes unnoticed, guaranteeing quality. It also assists in the unit testing process, with testers documenting steps and using this information to test more broadly in subsequent sprints.
+
+It is especially useful when finding new test scenarios to enhance coverage.
+
+## When **Not** to Perform Exploratory Testing?
+
+Organizations should be able to strike a balance between exploratory and scripted testing. Exploratory tests alone cannot offer sufficient coverage; they are thus complementary to scripted tests in some cases.
+
+Especially in regulated or compliance-based testing, which requires scripted testing. In these cases, specific checklists and mandates need to be followed for legal reasons, making scripted testing preferable.
+
+An example is accessibility tests that follow legal protocols with defined standards needing approval.
+
+## Importance of Exploratory Testing for CI/CD
+
+*// CI/CD: Continuous Integration/Continuous Delivery, a method to deliver applications frequently to customers. //*
+
+Exploratory tests open testing to everyone, not just trained testers, making review faster and more efficient and allowing people beyond the traditional tester to participate.
+
+Exploratory tests **complement** QA team testing strategies, including a series of undocumented test sessions to find yet-to-be-discovered bugs.
+
+When combined with *automated tests* and other practices, they increase test coverage, discover extreme cases, and potentially add new features and improvements to the product.
+
+**Without structural rigidity, they encourage experimentation, creativity, and discovery within teams.**
+
+The almost instant nature of feedback helps bridge gaps between testers and developers, but most importantly, the results provide a user-oriented perspective and feedback for development teams.
+
+**The goal is to complement traditional tests and uncover hidden defects behind the traditional workflow.**
diff --git a/docs/en/02-types/04-sanity.md b/docs/en/02-types/04-sanity.md
new file mode 100644
index 0000000..157b39c
--- /dev/null
+++ b/docs/en/02-types/04-sanity.md
@@ -0,0 +1,60 @@
+# Sanity Testing
+
+Sanity testing is a type of testing performed after receiving a software build with minor changes in the code or functionality, **to ensure that bugs have been fixed and no new issues have been introduced.**
+
+The goal is to ensure that the proposed functionality works rudimentarily as expected.
+
+If it fails, the build is rejected to avoid the expenditure of time and resources involved in more rigorous testing.
+
+Sanity testing is a subset of regression testing and is applied to ensure that changes in the code work appropriately. It is a step to check whether the build can proceed to further testing or not.
+
+The focus of the team during sanity testing is to validate the application's functionality, not detailed testing.
+
+It is usually applied to a build where the production implementation is needed immediately, such as a critical bug fix.
+
+## Functionality of Sanity Testing
+
+The main objective is to determine that the changes or proposed functionality work as expected.
+
+If quality testing fails, the product is rejected by the QA team to save time and money.
+
+It is only applied after the product has passed the Smoke Test and the QA team has accepted it for further testing.
+
+## Examples of Sanity Testing
+
+In an e-commerce project, the main modules are the login page, the home page, and the user profile page.
+
+There is a defect in the login page where the password field accepts fewer than 4 alphanumeric characters, while the business rules state that this field should not be less than eight characters. Therefore, the defect is reported by QA for the developer to fix.
+
+The developer then fixes the issue and sends it back to the testing team for approval.
+
+QA checks whether the changes made are working or not.
+
+It is also determined whether this has an impact on other related functionalities. Assuming there is now a feature to update the password on the user profile screen, as part of the sanity test, the login page is also validated, as well as the profile page to ensure both work well with the addition of the new function.
+
+### Aspects of Sanity Testing
+
+Below are some aspects to consider when conducting sanity testing:
+
+1. Subset of Regression Testing: focuses on smaller sections of the application.
+2. May not have a script (occasionally).
+3. Not documented (occasionally).
+4. Specific and In-Depth: limited functionalities are thoroughly checked.
+5. Performed by testers;
+
+### Advantages of Sanity Testing
+
+- Helps quickly identify defects in the core functionality.
+- If defects are found during sanity testing, the project is rejected, saving time in running regression tests.
+- The testing technique is not as costly compared to other modalities.
+- Helps identify missing necessary objects.
+- Used to validate a small functionality of the application, whether it's working or not after a minor change.
+- Assists in scenarios where time to test the product, or perform the test, is limited.
+
+### Disadvantages of Sanity Testing
+
+- Focuses only on application functions and commands.
+- Cannot cover all test cases and scenarios.
+- Covers only a few functionalities of the application. Problems in unchecked functionalities cannot be discovered.
+- Sanity testing usually does not have a script. Therefore, future references are not available.
+- Does not cover the level of design structure, and thus, it will be difficult for the development team to identify and fix issues.
diff --git a/docs/en/02-types/05-regression.md b/docs/en/02-types/05-regression.md
new file mode 100644
index 0000000..59f02f9
--- /dev/null
+++ b/docs/en/02-types/05-regression.md
@@ -0,0 +1,98 @@
+# Regression Testing
+
+Regression testing is a type of testing used to confirm that recent changes in the code have not adversely affected existing features.
+
+Regression testing is a black-box testing technique, where test cases are re-executed to verify that previous functionalities of the application are working as intended and that new additions have not introduced any bugs.
+
+It can be applied to a new build when there is a significant change in the original functionality, as it ensures that the code still works once changes occur. Regression means "re-testing" these parts of the application that remain unchanged.
+
+Regression Testing is also known as Verification Method; test cases are often automated since they need to be executed repeatedly during the development process.
+
+## When Should We Apply Regression Testing?
+
+Whenever the code is modified, such as in the following scenarios:
+
+1. **New Feature Added to the Application**
+   Example: A website has a login feature that allows login via Email. Now providing the option to log in with Facebook.
+
+2. **When There is a Requirement Change**
+   Example:
+   "Remember Password" function removed from the login page.
+
+3. **When a Defect is Fixed**
+   Example:
+   A bug was found and reported, once the development team has fixed it, the QA team will retest it to ensure the issue has been resolved. Simultaneously testing other related functionalities.
+
+4. **When There is a Fix for Performance Issues**
+   Example: the loading time of a home page was 5 seconds, and an update reduces it to 2 seconds.
+
+5. **When There is a Change in Environment**
+   Example: the project moves from the Testing environment to the Production environment.
+
+## How to Perform Regression Testing?
+
+The need for regression testing arises when software maintenance includes enhancements, fixes, optimizations, or removal of existing features.
+
+These modifications can affect the system's functionality, necessitating regression.
+
+Testing can be applied using the following techniques:
+
+### 1. "Re-Test" Everything
+
+Retesting is one of the approaches used for regression testing. Here, all test cases need to be re-executed.
+
+Here, "re-test" is defined as when a test fails, and we determine the cause to be a software failure.
+
+The failure is reported, and once fixed in a new version of the software, re-execution of the test is necessary to confirm its correction.
+
+This process is known as "retesting" or confirmation testing and consumes both time and financial resources.
+
+### 2. Selective Regression Testing
+
+In this approach, specific test cases are selected instead of running the entire test suite.
+
+Selection is divided into two cases:
+
+- **Reusable:**
+      That **can** be used in later regression tests.
+
+- **Obsolete:**
+      That **cannot** be used in later regression tests.
+
+## Regression Testing Tools
+
+If the software undergoes constant changes, regression tests will become increasingly costly, as will the time invested in this process when done manually.
+
+In such situations, automation is the best choice.
+
+- **[Selenium](https://www.seleniumhq.org/):** an open-source tool used for automation testing in a web application. For browser-based regression tests, Selenium is utilized as well as for UI-level regressions.
+
+## What are Regression Testing and Configuration Management?
+
+Configuration Management in regression testing becomes imperative in Agile Methodology environments where code is continually changed.
+
+To ensure valid regression testing, we must follow these steps:
+
+- Changes in the code are not allowed during the regression testing phase.
+- A regression test case should consist of unchanged development changes.
+- The database used for regression must be isolated, and changes are not allowed.
+
+## What Are the Differences Between Re-Testing and Regression Testing?
+
+- **Re-Testing:**
+  - Means testing the functionality again to ensure the code correction. If not fixed, defects must be re-opened; if fixed, the defect is closed.
+  - Re-testing is applied to check if failed test cases in the final run obtain success after the defects have been fixed.
+  - Re-tests work to detect fixes.
+  - Defect verification is part of the process.
+  - Priority is higher than regression tests, therefore, performed earlier.
+  - It is a planned test.
+  - Cannot be automated.
+
+- **Regression Testing:**
+  - Means testing the application when it undergoes a change in the code to ensure the new code has not affected other existing parts of the software.
+  - Does not include defect verification.
+  - Based on project type and resource availability, regression testing can run parallel to re-testing.
+  - It is a generic test.
+  - Can be automated.
+  - Checks for unintended side effects.
+  - Occurs when modifications or changes become mandatory for the project.
diff --git a/docs/en/02-types/06-unit.md b/docs/en/02-types/06-unit.md
new file mode 100644
index 0000000..4128532
--- /dev/null
+++ b/docs/en/02-types/06-unit.md
@@ -0,0 +1,98 @@
+# Unit Testing
+
+Unit testing is a testing technique where individual units or components of software are tested.
+
+The purpose is to validate if each unit of the code functions satisfactorily.
+
+It is applied during the development phase (coding phase) of an application by developers. This practice isolates a section of code and checks its integrity, which can be an individual function, method, procedure, module, or object.
+
+## Why Apply Unit Testing?
+
+- Helps catch bugs early in the development cycle, saving costs;
+- Assists developers in understanding the basics of code testing and empowers them to make changes quickly;
+- Good unit tests serve as project documentation;
+- Aids in code reuse. Migrating both your code and your tests to a new project;
+
+## How to Apply Unit Testing
+
+To execute this technique, developers write a section of code to test a specific function in the application, which can also be isolated for more rigorous testing that reveals unnecessary dependencies between the function under test and other units, allowing them to be eliminated.
+
+This type of testing is commonly done automatically, but it can still be performed manually. Neither has a bias, although automation is preferable.
+
+Regarding the automated approach:
+
+- The developer writes a section of code in the application solely to test the function.
+- The developer might also isolate the function for more rigorous testing, helping to identify unnecessary dependencies between the code under test and other units in the product.
+- A coder generates automation criteria to validate that the code works. During the test case execution, the framework logs all failures, with some tools automatically reporting them and, depending on severity, halting any further tests.
+- The unit testing workflow is:
+  - Create test cases
+  - Review/Corrections
+  - Baseline
+  - Run the tests.
+
+## Unit Testing Techniques
+
+Mainly categorized into three parts:
+
+- Black Box: user interface testing, with input and output;
+- White Box: involves the functional behavior of the code;
+- Gray Box: used for running test suites, test methods, test cases, and performing risk analysis;
+
+Code coverage techniques used in unit testing are:
+
+- Statement Coverage
+- Decision Coverage
+- Branch Coverage
+- Condition Coverage
+- Finite State Machine Coverage
+
+### Example of Unit Testing: Mock Objects
+
+Unit testing relies on creating mock objects to test sections of code that are not yet part of a complete application. Mocks fill in the missing parts in the program.
+
+For instance, you may have a function that depends on variables or objects that have not been created yet. In unit testing, these will be replaced by mocks created only for the test to be conducted on the specific section.
+
+### Unit Testing Tools
+
+Some of the popular unit testing tools are:
+
+- [Junit](https://www.guru99.com/junit-tutorial.html)
+- [NUnit](https://nunit.org/)
+- [JMockit](https://jmockit.github.io/index.html)
+- [EMMA](http://emma.sourceforge.net/)
+- [PHPUnit](https://phpunit.de/)
+
+## Test-Driven Development (TDD) and Unit Testing
+
+Unit testing in TDD involves extensive use of testing frameworks, which are used to create automated cases.
+
+These frameworks are not exclusive to TDD, but they are essential to it due to the following characteristics of the process:
+
+- Tests are written before the code;
+- Heavily relies on testing frameworks;
+- All classes in the application are tested;
+- Quick and easy integration becomes possible;
+
+## Advantages of Unit Testing
+
+1. Developers seeking to learn what functionality is provided from a unit and how to use it can look at unit tests again and gain a basic understanding of the API;
+2. Unit Testing allows programmers to refactor the code at a later stage, ensuring that the module still works correctly (Regression Testing). The procedure is to write test cases for all functions and methods to ensure that new changes do not fail, which can be quickly identified and corrected;
+3. Due to the modular nature of unit testing, we can test parts of the project without waiting for others to be completed (mocks);
+
+## Disadvantages of Unit Testing
+
+1. Unit tests cannot detect all errors in a program, and it is impossible to evaluate all execution paths even in the most trivial programs;
+2. Due to its very nature, this technique focuses on a unit of code, so it cannot detect integration errors or broad-spectrum system failures.
+
+   It is recommended that this testing approach be combined with other techniques.
+
+### Best Practices
+
+Some of the best practices for unit testing are:
+
+- Unit tests should be independent. In case of any improvements or changes in business rules, the tests should remain unchanged;
+- Test only one piece of code at a time;
+- Follow clear and consistent naming guidelines for test units;
+- In case of code changes or any module, ensure there is a corresponding unit test case, and the module passes the tests before altering the implementation;
+- Bugs identified in this technique should be fixed before proceeding to other phases of the Development Cycle;
+- Adopt a "test while you code" stance. The more code is written without tests, the more paths need to be checked.
diff --git a/docs/en/02-types/07-smoke.md b/docs/en/02-types/07-smoke.md
new file mode 100644
index 0000000..f53b95e
--- /dev/null
+++ b/docs/en/02-types/07-smoke.md
@@ -0,0 +1,46 @@
+# Smoke Testing
+
+A technique that verifies whether the deployed version of the software is stable or not.
+
+It consists of a minimal set of tests applied to each software build to verify its functionalities.
+
+    Also known as "Build Verification Testing" or "Confidence Testing."
+
+In simple terms, smoke testing validates if vital features are working and if there are no showstoppers in the build under test.
+
+It is a quick and small regression test only to test the core functionalities, determining if the build is so faulty that it renders further tests a waste of time and resources.
+
+## Smoke Testing vs. Sanity Testing
+
+- *Smoke Testing* verifies critical functionalities, while *Sanity Testing* checks new functionalities like bug fixes.
+- *Smoke Testing* is documented or scripted, while *Sanity Testing* is not.
+- *Smoke Testing* checks the entirety of the system from start to end, while *Sanity Testing* checks only an individual component.
+
+## When to Apply Smoke Testing?
+
+Applied whenever new features are developed and integrated with an existing build, which is then deployed in the QA environment, ensuring all functionalities are working perfectly or not.
+
+<img src="https://www.guru99.com/images/3-2016/032816_1308_SmokeTestin1.png" alt="Testing Flowchart">
+
+If the build is positively verified by the QA team in Smoke Testing, the team proceeds with functional testing.
+
+### Reasons to Apply Smoke Testing:
+
+- All showstoppers will be identified here.
+- It is performed after a build is handed over to QA. Hence, most defects are identified in the early stages of software development.
+- With smoke testing, we simplify the detection and correction of major defects.
+
+## How to Apply Smoke Testing?
+
+This technique is generally done manually, although achieving the same effect through automation is also possible and varies from company to company.
+
+- **Manual Testing:**
+    Performed to ensure that critical paths' navigation is operating as expected and not hindering functionality.
+    Once the build is handed over to QA, high-priority test cases should be taken to locate major defects in the system.
+    If the build passes, we proceed to functional testing. If the test fails, the build is rejected and sent back to the development team, restarting the cycle.
+
+- **Automated Testing:**
+   Automation is used for regression testing; however, we can also apply it to these test cases, streamlining the verification process of new builds.
+   Instead of the inefficient process of repeating all tests whenever a new build is implemented, we can automate the necessary steps, saving time and resources.
+
+   <img src=https://www.guru99.com/images/3-2016/032816_1308_SmokeTestin2.png alt= "Testing Cycle Flowchart">
diff --git a/docs/en/02-types/08-integration.md b/docs/en/02-types/08-integration.md
new file mode 100644
index 0000000..99852ad
--- /dev/null
+++ b/docs/en/02-types/08-integration.md
@@ -0,0 +1,160 @@
+# Integration Testing
+
+It is a type of testing where software modules are logically integrated and tested as a group.
+
+A typical software project consists of multiple modules, coded by different programmers; the purpose of this level of testing is to expose defects in the interaction between these integrated modules. This technique focuses on validating the data communication between these modules, also known as *I & T (Integration and Testing)*, *String Testing*, and sometimes *Thread Testing*.
+
+## Why Perform Integration Testing
+
+Even though each module is unit-based, defects still exist for various reasons:
+
+- A module is generally designed by an individual developer, who may have a different understanding and logic than other programmers;
+- During module development, there is a high chance of changes in business rules from clients. These new requirements might not be thoroughly unit-tested, necessitating integration testing of the system;
+- The interface between modules and the database might be erroneous;
+- External hardware interfaces, if any, could be erroneous;
+- Improper exception handling can cause errors.
+
+## Example of Integration Testing Scenario
+
+Integration testing cases differ from other testing modalities in that they primarily focus on the interfaces and data flow/information between modules.
+
+The focus here is on integration links rather than the unit functions already tested.
+
+### *Integration Testing Cases Samples for the Following Scenario:*
+
+Application has 3 modules
+
+- Login Page;
+- Mailbox;
+- Delete Emails;
+
+All integrated logically.
+
+Here, we don't concentrate on testing the Login Page since tests for this feature have already been conducted in Unit Testing. Instead, we check its integration with the Mailbox.
+
+Similarly, we check the integration between the Mailbox and the Delete Emails module.
+
+   - Test Cases:
+     - Case 1
+       - Objective: Verify the interface link between Login and Mailbox;
+       - Test Case Description: Enter login credentials and click the Login button;
+       - Expected Result: Redirected to Mailbox;
+     - Case 2
+       - Objective: Check the interface link between Mailbox and Delete Emails;
+       - Test Case Description: From Mailbox, select the email and click a delete button;
+       - Expected Result: Selected email appears in the deleted/trash folder;
+
+## Types of Integration Testing
+
+Software engineering defines a myriad of strategies for performing integration testing, such as:
+
+- Big Bang Approach
+- Incremental Approach: further subdivided into two parts
+  - Top-Down Approach
+  - Bottom-Up Approach
+  - Sandwich Approach (combines the two above)
+
+### Big Bang Testing
+
+It is an integration testing approach where all components or modules are integrated together all at once and tested as a unit.
+
+This combined set of components is considered as one entity during testing; if any of the components in the unit are incomplete, integration will not be executed.
+
+- Pros:
+  - Convenient for small systems
+- Cons:
+  - Difficult to locate faults;
+  - Given the number of interfaces needing to be tested in this method, some interface connections might easily be overlooked;
+  - Since integration testing can only start after "all" modules have been architected, the testing team will have less time for execution in the testing phase;
+  - Given that all modules are tested at once, critical high-risk modules are not isolated and tested as a priority. Peripheral modules handling fewer user interfaces are not isolated for priority testing.
+
+### Incremental Testing
+
+In this approach, testing is done by integrating two or more logically related modules, then tested for proper functioning of the application.
+
+Then, other related modules are incrementally integrated, and the process continues until all logically related modules have been successfully tested.
+
+     Stubs and Drivers:
+    These are dummy programs used to facilitate testing activities. These programs act as substitutes for missing modules in testing. They don't implement the entire logic of the module but simulate data communication with the calling module during testing.
+       - Stub: is called by the sub-test modules.
+       - Driver: calls the module to be tested.
+
+### Bottom-Up Integration Testing
+
+It is the strategy where the lowest-level modules are tested first.
+
+These already tested modules are then used to facilitate testing of higher-level modules. The process continues until all the top-level modules have been verified.
+
+Once low-level modules have been tested and integrated, the next level of modules is formed.
+
+   1. Pros:
+      - Fault localization is easier;
+      - No time is wasted waiting for all modules to be developed as in the Big Bang approach.
+   2. Cons:
+      - Critical modules (at the top level of the software architecture) controlling the application flow are tested last and may be prone to defects;
+      - An early-stage prototype is not possible.
+
+### Top-Down Integration Testing
+
+A method where testing starts from the top and moves down following the software system's control flow.
+
+Higher levels are tested first, followed by lower levels, which are integrated to check software functionality. Stubs are used to test if some modules are not ready.
+
+   1. Pros:
+      1. Fault localization is easier;
+      2. The possibility of getting a prototype;
+      3. Critical modules are tested as a priority; significant design flaws can be identified and corrected first.
+   2. Cons:
+      1. Needs many Stubs;
+      2. Lower-level modules are inadequately tested.
+
+### Sandwich Testing
+
+Here, the highest-level modules are tested together with the lowest-level ones. Simultaneously, the lower ones are integrated with the higher ones and tested as a system.
+
+It combines both Top-Down and Bottom-Up approaches, so it's called Hybrid Integration Testing.
+
+It uses both Stubs and Drivers.
+
+## How to Perform Integration Testing?
+
+The testing procedure is independent of the above-mentioned strategies:
+
+  1. Prepare the Integration Test Plan;
+  2. Define test scenarios, cases, and scripts;
+  3. Execute test cases, reporting any defects;
+  4. Trace and retest defects;
+  5. Steps 3 and 4 are repeated until integration is successfully completed;
+
+### Example of a Test Plan
+
+- Methods/Approaches for testing;
+- In-scope and out-of-scope items for integration testing;
+- Roles and Responsibilities;
+- Prerequisites for integration testing;
+- Testing environment;
+- Risk mitigation plans;
+
+## Entry and Exit Criteria
+
+- Entry:
+  1. Unit testing of components/modules;
+  2. All high-priority bugs fixed and closed;
+  3. All modules to be coded are complete and successfully integrated;
+  4. Integration Test Plan, test cases, scenarios to be signed off and documented;
+  5. Testing environment set up for integration;
+- Exit:
+  1. Successfully tested integrated application;
+  2. Executed test cases are documented;
+  3. High-priority bugs fixed;
+  4. Technical documents to be submitted, followed by release notes;
+
+## Best Practices
+
+Consider the following best practices for integration testing:
+
+- First, determine the integration testing strategies that can be adopted, and then prepare test cases and data accordingly.
+- Study the application architecture and identify critical modules for priority testing;
+- Obtain the interface design from the Architecture team, create test cases to verify all interfaces in detail. Interface for database/external hardware/software applications must be thoroughly tested;
+- After test cases, test data plays a crucial role;
+- Always have the mock data prepared before executing. Do not select test data during test case execution;
diff --git a/docs/en/02-types/09-non-functional.md b/docs/en/02-types/09-non-functional.md
new file mode 100644
index 0000000..7ac0ab6
--- /dev/null
+++ b/docs/en/02-types/09-non-functional.md
@@ -0,0 +1,41 @@
+# Non-Functional Testing
+
+Non-functional testing is a type of technique to test non-functional parameters such as reliability, load testing, performance, and software responsiveness.
+
+The primary purpose is to test the system's read speed under non-functional parameters.
+
+These parameters are **never** tested before functional tests.
+
+It is essential to confirm that the reliability and functionality, the software's requirement specifications serve as the basis for this testing method, enabling QA teams to check if the system complies with user requirements.
+
+Increasing the usability, effectiveness, maintainability, and portability of the product are the goals of non-functional testing. This helps decrease manufacturing risks associated with non-functional components of the product.
+
+## Characteristics of Non-Functional Testing
+
+Non-functional testing is characterized by:
+
+- Being quantifiable, hence adjectives like "good," "better," etc., do not apply to this type of testing;
+- Exact numbers are unlikely to be known at the beginning of the requirement process;
+- Prioritizing requirements is crucial;
+- Ensuring that in software engineering, quality attributes are identified accurately;
+
+## Non-Functional Test Conditions
+
+Non-functional test conditions define the following parameters:
+
+- **Security:** Specifies how a system is protected from planned or unplanned intrusions from internal or external sources;
+- **Reliability:** The consistency with which a system completes tasks without error;
+- **Efficiency:** The capacity, quantity, and response time that software can support;
+- **Usability:** The simplicity with which a user can engage with a system, learn how to use it, and prepare inputs and outputs;
+- **Availability:** Establishes the user's reliance on the system during operation;
+- **Scalability:** Describes how much a program can increase its processing power to support growing demand.
+
+## Advantages of Non-Functional Testing
+
+It has the following benefits:
+
+- Offers a high level of security;
+- Ensures the system's capability for simultaneous users;
+- Enhances system efficiency;
+- There is no need to write test cases more than once as they are never altered;
+- Compared to other testing procedures, it has a shorter time commitment.
diff --git a/docs/en/02-types/10-load.md b/docs/en/02-types/10-load.md
new file mode 100644
index 0000000..fb8ae48
--- /dev/null
+++ b/docs/en/02-types/10-load.md
@@ -0,0 +1,60 @@
+# Load Testing
+
+Load testing is a type of performance test for a system or software product under real-life load conditions.
+
+Here, we determine the system's behavior when multiple users use the application simultaneously. It is the system's response measured under varying load conditions.
+
+## Objectives of Load Testing
+
+- Maximize the application's operational capacity;
+- Determine if the latest infrastructure can handle the application or not;
+- Determine the application's sustainability under extreme user loads;
+- Discover the total number of users that can access the application simultaneously;
+- Determine the application's scalability;
+- Allow more users to access the application.
+
+![Load Testing Flowchart](https://media.geeksforgeeks.org/wp-content/uploads/20190515173252/999.jpg)
+
+1. **Test Environment Setup:** First, create a dedicated environment to conduct the load test; this ensures it is done appropriately.
+2. **Load Test Scenario:** Here, scenarios are created, and then, load test transactions are determined for the application, and data is prepared for each transaction.
+3. **Execution of Test Scenarios:** Different measurements and metrics are collected to gather information.
+4. **Results Analysis;**
+5. **Re-Tests:** If a test fails, it is conducted again to obtain the correct result.
+
+## Load Testing Metrics
+
+Metrics are used to understand the performance of load tests under different circumstances. This tells us how accurate the test is in each different scenario.
+
+There are many metrics, such as:
+
+1. **Average Response Time:** Measures the time it takes for a response from a request generated by the client or user. It also shows the application's speed depending on how long the response takes for all requests made.
+2. **Error Rate:** Mentioned in terms of percentage and denotes the number of errors occurring during requests to the total requests. These errors usually occur when the application can no longer support the requests in the given time or due to other technical issues. This makes the application less efficient as the error rate rises.
+3. **Throughput:** Used to measure the amount of bandwidth consumed during load scripts or tests. It is also used to determine the amount of data used to check the requests flowing between the user's server and the main application server. It is measured in kilobytes per second.
+4. **Requests per Second:** Tells us how many requests are generated to the application server per second. Requests can be anything from requests for images, documents, web pages, articles, or anything else.
+5. **Concurrent Users:** This metric is used to determine how many users are actively present at a specific or any given time. It merely keeps track of the count of those who visit the application at any time, without raising any requests within the application. From this, we can easily identify peak times.
+6. **Peak Response Time:** Measures the time taken to handle the request. It also helps find the duration of the peak period (the longest time) in which the request/response cycle is taking more time.
+
+### Load Testing Tools
+
+Some of the load testing tools are:
+
+1. Apache JMeter
+2. WebLoad
+3. NeoLoad
+4. LoadNinja
+5. HP Performance Tester
+6. LoadUI Pro
+7. LoadView
+
+## Advantages of Load Testing
+
+- Improves the system's sustainability;
+- Enhances the system's scalability;
+- Helps minimize risks related to system downtime;
+- Reduces system failure costs;
+- Increases user satisfaction.
+
+## Disadvantages of Load Testing
+
+- Requires programming knowledge to conduct a Load Test;
+- Testing tools can be expensive.
diff --git a/docs/en/02-types/11-performance.md b/docs/en/02-types/11-performance.md
new file mode 100644
index 0000000..32bc28d
--- /dev/null
+++ b/docs/en/02-types/11-performance.md
@@ -0,0 +1,116 @@
+# Performance Testing
+
+Performance testing is a subset of Performance Engineering, a process that evaluates the behavior of a system under various extreme conditions.
+
+The main goal is to monitor and improve key performance indicators such as response time, throughput, memory usage, CPU utilization, and more.
+
+The three objectives are:
+
+- **Speed:** Response time to requests;
+- **Scalability:** Maximum user load the application can handle;
+- **Stability:** Determines if the API remains stable under various loads.
+
+## Why Perform Performance Testing?
+
+Features and functionalities supported by a software are not the only concerns. API performance, including response time, reliability, resource usage, and scalability, is also crucial.
+
+The goal is not to find bugs but to eliminate performance bottlenecks.
+
+Performance testing is applied to provide investors with insights about their applications regarding performance factors. More importantly, it reveals what needs improvement before the product goes to market.
+
+Without this testing, software would likely suffer from issues such as poor performance under stress, inconsistencies across different operating systems, and low usability.
+
+The test determines if the software meets performance parameters under predicted workloads. Applications released to the market with low performance metrics due to non-existent or inadequate testing will likely gain a bad reputation and fail to meet sales objectives.
+
+Moreover, critical applications such as space launch programs and medical equipment must undergo performance testing to ensure full functionality.
+
+### Types of Performance Testing
+
+1. **Load Testing:** Checks the application's ability to perform under **predictable** user loads to identify bottlenecks before the application is deployed.
+2. **Stress Testing:** Involves testing the application under **extreme** loads to assess how the system handles traffic and data processing. The goal is to identify the breaking point of the application.
+3. **Spike Testing:** Tests the software's reaction to a sudden spike in user-generated load.
+4. **Endurance Testing:** Ensures that the software can handle the expected load over a long period of time.
+5. **Volume Testing:** Large amounts of data are inserted into the database, and the overall system behavior is monitored. The goal is to check performance at different database volume levels.
+6. **Scalability Testing:** Determines the effectiveness of the software under increasing loads to accommodate a growing number of users. This helps plan capacity improvements for the system.
+7. **Capacity Testing:**
+
+## Common Performance Issues
+
+Most performance problems revolve around speed, response time, load time, and poor scalability. Speed is one of the most crucial attributes; a slow application will lose potential users. Performance testing ensures that an application runs fast enough to maintain a user's attention and interest. In the following list, we examine how speed is a constant concern.
+
+- **High Load Time:** Load time is typically the period an application takes to start; it should generally be as short as possible. While some applications cannot be started in less than a minute, the loading time should ideally be under a few seconds, if possible.
+- **Inadequate Response Time:** This refers to the time taken between user input and the application's output for that input. It should generally be very fast; if the wait is too long, the user loses interest.
+- **Poor Scalability:** A software product suffers from poor scalability when it does not support the expected number of users or when it does not accommodate a satisfactory range of users.
+- **Bottleneck:** These are obstructions in a system that degrade overall performance. They occur when code or hardware errors cause a decrease in throughput under certain loads. The key to locating a bottleneck is finding the section of code causing the slowdown and fixing it. Bottlenecks are commonly resolved by fixing the lines of code or adding hardware. Some common bottlenecks include:
+  - CPU Usage;
+  - Memory Usage;
+  - Network Usage;
+  - Operating System Limitations;
+  - Disk Usage;
+
+## How to Perform Performance Testing
+
+The methodologies for performance testing can vary, but the goal remains consistent.
+
+Generic flowchart of performance testing:
+
+![Performance Testing Process](https://www.guru99.com/images/performance_testing_process.png)
+
+1. **Identify the Test Environment:**
+   Understand the physical testing environment, production, and available testing tools. Understand details of the hardware, software, and network configurations used during testing before starting it. This process promotes greater efficiency.
+2. **Identify Performance Acceptance Criteria:**
+   This includes throughput objectives and constraints, response times, and resource allocation. It is also necessary to identify project success criteria beyond these objectives and constraints. Testers should also be empowered to define performance criteria and goals since project specifications usually will not include a wide enough variety of benchmarks for performance. If possible, finding a similar application for comparison purposes can help in defining performance goals.
+3. **Planning and Design of Performance Tests:**
+   Determine how usability will vary among end users to identify key test scenarios for all possible use cases. It is necessary to simulate a variety of end users, plan data for performance testing, and limit the metrics to be collected.
+4. **Test Environment Setup:**
+   Prepare the testing environment before its execution; also, organize tools and other resources.
+5. **Implement Test Design:**
+   Create performance tests according to the original design.
+6. **Execute the Tests**
+7. **Analyze, Tune, and Retest:**
+   Consolidate, analyze, and share test results. Then, tune specifically and retest to observe improvements or declines in performance. Since improvements generally decrease with each test, stop when the bottleneck is caused by the CPU. Then consider the option of increasing the CPU power.
+
+## Performance Testing Metrics: Monitored Parameters
+
+- CPU Usage: The amount of time a processor spends executing active threads.
+- Memory Usage: Physical space available in memory for processes on the computer.
+- Disk Time: The period during which the disk is occupied to execute a read or write request.
+- Private Bytes: Number of bytes a process has allocated that cannot be shared among other processes. These are used to measure memory leaks and memory usage.
+- Dedicated Memory: Amount of virtual memory used.
+- Memory Pages per Second: Number of pages written or read from the disk to resolve serious page faults. Serious faults are identified when code not currently under test group receives a call from somewhere else and is fetched from a disk.
+- Page Faults per Second: The overall rate at which faults are processed by the processor. Again, these occur when a process requires code from outside the group under test.
+- CPU Interrupts per Second: Average number of hardware interrupts a processor is receiving and processing every second.
+- Disk Queue Length: Average number of requests for read and writes in the queue for the selected disk during a sampling time.
+- Network Output Queue Length: Queue length of output packets. Anything above 2 means a delay, and the bottleneck needs to be resolved.
+- Total Bytes on the Network per Second: Rate at which bytes are sent and received on the interface, including framing characters.
+- Response Time: Time between user request and receipt of the first character of the response.
+- Throughput: Rate at which a computer or network receives requests per second.
+- Connection Pool Count: Number of user requests handled by a connection pool. The more requests handled by connections in the pool, the better the performance.
+- Maximum Active Sessions;
+- Hit Rates: Involves the number of SQL statements processed by data in the cache instead of expensive I/O operations. This is a good starting point for bottleneck solutions.
+- **Hits per Second:** The number of successful hits a web server receives during each second of a load test;
+- **Undo Segment:** Amount of data that can be rolled back at any given time;
+- **Database Locks:** Locking of tables and databases needs to be monitored and adjusted carefully;
+- **Longest Waits:** Monitored to determine which wait times can be reduced when dealing with how quickly data is fetched into memory;
+- **Thread Count:** The health of an application can be measured by the number of threads that are active and running;
+- **Waste Collection:** Refers to the return of unused memory back to the system. Waste collection needs to be monitored for efficiency.
+
+## Examples of Test Cases
+
+1. Verify that the response time is not more than 4 seconds when 1000 users access the site simultaneously;
+2. Check if the application's response time under load is within acceptable parameters when network connectivity is low;
+3. Determine the maximum number of users the application can handle before crashing;
+4. Verify the database runtime when 500 records are read/written simultaneously;
+5. Verify the CPU and memory usage of the application and database under peak load conditions;
+6. Validate the application's response time under low, normal, moderate, and excessive load conditions.
+
+## Performance Testing Tools
+
+Some of the most popular tools for performance testing are:
+
+- [LoadNinja](https://bit.ly/3knoPpQ)
+- [HeadSpin](https://bit.ly/3D8p93N)
+- [BlazeMeter](https://guru99.live/vVYFyu)
+- [HPLoadRunner](https://www.guru99.com/loadrunner-v12-tutorials.html)
+- [JMeter](https://www.guru99.com/jmeter-tutorials.html)
+
diff --git a/docs/en/02-types/12-stress.md b/docs/en/02-types/12-stress.md
new file mode 100644
index 0000000..c465b24
--- /dev/null
+++ b/docs/en/02-types/12-stress.md
@@ -0,0 +1,96 @@
+# Stress Testing
+
+Stress testing is a type of testing that assesses the stability and reliability of an application. Its objective is to measure the robustness and error-handling capability of a software under extreme load conditions, ensuring that the application does not crash under stress situations. Here, testing goes beyond usual operational points.
+
+In software engineering, stress testing is also known as resistance testing or overwhelming the system for a short period to validate its working capacity.
+
+The most prominent use of this technique is to determine the threshold beyond which software or a system breaks, also checking if the system demonstrates proper error handling under extreme conditions.
+
+## Importance of Stress Testing
+
+Consider the real-life scenarios below to understand the need for Stress Testing:
+
+- During an event, an online shopping site may experience a sudden spike in traffic or when it advertises a promotion.
+- When a blog is mentioned in a famous newspaper, it observes a sudden increase in accesses.
+
+It is imperative that stress testing be applied to accommodate these abnormal traffic situations; failure to accommodate can result in loss of revenue and reputation.
+
+This technique is also extremely important for the following reasons:
+
+1. Verify if the system functions under abnormal conditions.
+2. Display an appropriate error message when the system is under stress.
+3. System failure under extreme conditions can result in significant lost profits.
+4. It is better to be prepared for abnormal traffic situations.
+
+## Objectives of Stress Testing
+
+Analyzing the system's behavior after a failure, for successful recovery, the system must display an error message consistent with extreme usage conditions.
+
+To conduct stress testing, sometimes enormous sets of data can be used and lost during testing. Testers must not lose this confidential data during the process.
+
+The primary purpose is to ensure that the system recovers after a failure, which is called recoverability.
+
+## Types of Stress Testing
+
+Stress tests can be classified into:
+
+### Distributed Stress Testing
+
+In this mode, the test is performed through all the server's clients.
+
+The stress server's function is to distribute a set of stress tests to all clients and track each one's status. After the client contacts the server, it will add the client's name and send test data.
+
+Meanwhile, client machines send signals indicating they are connected to the server. If the server does not receive any signals from the machines, it needs to be checked for further debugging processes.
+
+![Distributed Stress Testing](https://www.guru99.com/images/s4.png)
+
+As shown in the image, the test can be specific to certain users or general across all connected clients.
+
+Nightly integrations are the best option for executing these scenarios. Large server groups need a more efficient method to determine which computers had stress failures that need verification.
+
+### Application Stress Testing
+
+Here, we focus on locating defects related to data locks and blocks, network issues, and performance bottlenecks in an application.
+
+### Transactional Stress Testing
+
+It applies the test to one or more transactions between two or more applications. It is used for system tuning and optimization. It is important to note that a transaction is significantly more complex than a request.
+
+### Systemic Stress Testing
+
+It is integrated stress testing that can be applied to multiple systems running on the same server, used to locate defects where one application generates data blocking in another.
+
+### Exploratory Stress Testing
+
+Applied to verify the system in unusual parameters or conditions unlikely to occur in a real scenario.
+Used to find unexpected defects such as:
+
+- A large number of users logged in simultaneously.
+- If virus scans are initiated on all machines simultaneously.
+- If the database went offline when accessed from a site.
+- When a vast volume of data is inserted into the database at once.
+
+## How to Conduct Stress Testing
+
+1. **Stress Testing Planning:** Collect data, analyze the system, and define objectives.
+2. **Automation Script Creation:** In this phase, automation scripts are created, and test data is generated for stress scenario.
+3. **Script Execution and Result Storage:**
+4. **Result Analysis:**
+5. **Adjustments and Optimization:** In this stage, final adjustments are made in the system; settings are changed, and code is optimized to achieve the desired benchmark.
+
+Finally, reapply the adjusted cycle to verify if it has produced the desired results. For example, it is not uncommon to apply 3 or 4 cycles of stress testing to achieve the desired performance.
+
+## Metrics for Stress Testing
+
+- **Measuring Scalability and Performance:**
+  - **Pages/s:** Measures how many pages had request/s.
+  - **Throughput Rate:** Basic metric, data volume in Response/s.
+  - **Scenarios:** Number of planned test scenarios vs the number of times a client was executed.
+- **Application Response:**
+  - **Number of Hits:** Average time to fetch an image or page.
+  - **Time to First Byte:** Time spent for the return of the first byte of data or information.
+  - **Page Load Time:** Time taken to retrieve all information on the page.
+- **Failures:**
+  - **Connection Failures:** Number of failed connections rejected by the client (weak signal).
+  - **Scenario Failures:** Number of scenarios that failed.
+  - **Hit Failures:** Number of failed attempts made by a system (broken connections or images not viewed).
diff --git a/docs/en/02-types/13-pentest.md b/docs/en/02-types/13-pentest.md
new file mode 100644
index 0000000..5a7fe4c
--- /dev/null
+++ b/docs/en/02-types/13-pentest.md
@@ -0,0 +1,78 @@
+# Security Testing
+
+Security testing is a type of software testing that discovers vulnerabilities, threats, and risks in a software application, preventing intruder attacks.
+
+The purpose of security testing is to identify all possible gaps and weaknesses in the system that may result in the loss of information, profits, and reputation in the hands of employees or outsiders of the organization.
+
+Once identified, vulnerabilities are verified so that the system continues to function and cannot be exploited.
+
+## Key Principles of Security Testing
+
+- **Confidentiality:** Limiting access to sensitive data managed by a system.
+- **Integrity:** Ensuring that data is consistent, accurate, and reliable throughout the software lifecycle and cannot be modified by unauthorized users.
+- **Authentication:** Verifying that sensitive data or systems are protected by a mechanism that verifies the identity of the user accessing them.
+- **Authorization:** Defining that all sensitive data and systems have access control for authenticated users according to their roles or permissions.
+- **Availability:** Ensuring that critical data and systems are available to their users when needed.
+- **Non-Repudiation:** Establishing that a sent or received data cannot be denied when exchanging authentication information with a demonstrable timestamp.
+
+## Types of Security Testing
+
+![Types of Security Testing](https://www.guru99.com/images/securityt2.png)
+
+- **Vulnerability Scanning:** Done through automated software to explore the system for vulnerability signatures.
+- **Security Scanning:** Involves identifying weaknesses in the network and system, providing solutions to reduce these risks. This scan can be applied manually or automatically.
+- **Penetration Testing:** Simulates malicious hacker attacks. Here, the analysis of a particular system is involved to check potential vulnerabilities to external attacks.
+- **Risk Assessment:** This technique involves analyzing security risks observed within the organization. Risks are then classified as low, medium, and high. This test recommends controls and measures to reduce risks.
+- **Security Audit:** Internal inspection of applications and Operating Systems for security flaws. An audit can also be done line by line in the code.
+- **Ethical Hacking:** The process of hacking an organization without malicious intent but rather to expose and fix system security risks.
+- **Posture Assessment:** This combines security scanning, ethical hacking, and risk assessment to demonstrate the overall security posture of an organization.
+
+## How to Perform Security Testing
+
+It is a consensus that the earlier security tests are applied, the better the results for the project.
+
+![Security Testing Workflow](https://www.guru99.com/images/securityt3.png)
+
+- **Requirements:** Security analysis on requirements, checking for abuse/misuse cases.
+- **Design:** Security risk analysis in the design, development of a test plan that includes security testing.
+- **Code and Unit Testing:** Static and dynamic tests, as well as white-box security testing.
+- **Integration Testing:** Black-box testing.
+- **System Testing:** Black-box and vulnerability scanning.
+- **Implementation:** Penetration testing, vulnerability scanning.
+- **Support:** Impact analysis of patches.
+
+The test plan should include:
+
+1. Security-related test cases and scenarios.
+2. Test data related to security testing.
+3. Necessary testing tools for the application.
+4. Analysis of test outputs from different tools.
+
+## Examples of Test Scenarios
+
+- A password should be encrypted.
+- Application or system should not allow invalid users.
+- Check cookies and session time for an application.
+- For financial websites, the back button in the browser should not work.
+
+## Security Testing Methodologies/Approaches/Techniques
+
+- **Tiger Box:** This hacking method is usually done on a laptop that has a collection of operating systems and hacking tools. This test helps penetration testers conduct vulnerability assessments and attacks.
+- **Black Box:** The tester is authorized to perform tests on everything about network topology and technology.
+- **Grey Box:** Partial information is provided to the tester about the system; it is a hybrid.
+
+## Roles in Security Testing
+
+1. **Hackers:** Access computer systems or networks without authorization.
+2. **Crackers:** Force entry into systems to steal or destroy data.
+3. **Script Kiddies or Packet Monkeys:** Inexperienced hackers with programming languages.
+
+## Security Testing Tools
+
+Here are some security testing tools:
+
+1. [Acunetix](https://bit.ly/3qH5T77)
+2. [Intruder](https://guru99.live/qxoGpg)
+3. [Owasp](https://guru99.live/qxoGpg)
+4. [WireShark](https://bit.ly/2TMN561)
+5. [W3af](https://bit.ly/2P5Qrm7-)
diff --git a/docs/en/02-types/14-accessibility.md b/docs/en/02-types/14-accessibility.md
new file mode 100644
index 0000000..656d274
--- /dev/null
+++ b/docs/en/02-types/14-accessibility.md
@@ -0,0 +1,90 @@
+# Accessibility Testing
+
+Accessibility testing is defined as a type of testing applied to ensure that the current application is usable by people with conditions such as deafness, color blindness, old age, etc.
+
+It is a subset of Usability Testing.
+
+These people use assistants that help them operate a software product, such as:
+
+1. **Speech Recognition:** Converts spoken language into text, which serves as input for the computer.
+2. **Screen Reader Software:** Used to read the text displayed on the screen.
+3. **Screen Magnification Software:** Used to enlarge the screen, making reading more comfortable for users with visual impairments.
+4. **Adapted Keyboard:** Designed for users with motor problems, making it easier for them to use.
+
+## Reasons to Perform Accessibility Testing
+
+- **Meeting the Market Demand:**
+With a significant number of users with limiting conditions, testing is applied to solve any accessibility issues, being a best practice to include this technique as a normal part of the development cycle.
+
+- **Compliance with Relevant Legislation:**
+Government agencies worldwide have produced legislation to determine that IT products are accessible to as many users as possible. This makes accessibility testing a fundamental part of the process, also due to legal requirements.
+
+- **Avoiding Potential Lawsuits:**
+In the past, Fortune 500 companies were sued for their products not being accessible to the market. It remains in the best interest of the company for its products to be accessible to avoid future lawsuits.
+
+## How to Perform Accessibility Testing?
+
+Accessibility testing can be manual or automated and can be challenging for testers due to their unfamiliarity with possible impairments. It is advantageous to work closely with people with disabilities so that they can expose specific needs, promoting a better understanding of their challenges.
+
+We have different ways to test, depending on each disability, such as:
+
+### 1. Visual Impairment
+
+Here, Screen Reader Software is used, which narrates the content displayed to the user, such as text, links, buttons, images, videos, etc.
+
+In summary, when starting one of these programs and accessing a website, it will narrate all the content, making navigation possible for visually impaired people.
+
+A poorly developed website can conflict with these programs, preventing correct and complete narration, and therefore generating inaccessibility. For example, due to structural errors, the software does not announce a link as such, describing it only as text and making it impossible for the user to recognize it.
+
+It is important to note that in this category, there are also other types of visual impairments, such as low vision or color blindness.
+
+In color blindness, the person is not blind but cannot see specific colors. Red and blue are common cases, making access complex if the website is based on one of these colors.
+
+The design of a website should take this into account. For example, a button in red might be more accessible if it has a black border.
+
+In low vision, the user is not completely blind but has difficulty seeing. The best thing to do is to avoid very small texts, structure the website so that the user can zoom in without breaking the layout, promoting a better experience.
+
+### 2. Other Disabilities
+
+A very important point is to consider access to the site without using the mouse.
+
+A user should be able to have complete access to links, buttons, pop-ups, drop-downs, etc., entirely from keyboard shortcuts.
+
+The focus must be entirely visible so that when pressing tab, the user can see where the control moves, with visible focus, we make access possible for individuals with low vision or color blindness, allowing them to identify the flow on the website and promoting ease of use.
+
+Finally, it is important to observe users with hearing impairments, such as deafness or hearing loss.
+
+Here, the user can access the site and see its content, but encounters problems with audio and video, making alt text imperative. Alternate text is a video supplement. In other words, if the site features a video tutorial for purchasing tickets, it should also offer an alternative in text form, allowing the user to understand the video content.
+
+## Examples of Test Cases
+
+Here are some examples of accessibility test cases:
+
+1. Does the application provide keyboard equivalents for all mouse operations?
+2. Are instructions provided as part of documentation or manuals? And are they easy to understand and apply when operating the software?
+3. Are tabs logically ordered to ensure smooth navigation?
+4. Are keyboard shortcuts available when operating menus?
+5. Does the product support all operating systems?
+6. Is the response time for each window or page clearly mentioned so users know how long to wait?
+7. Are all labels written correctly?
+8. Is the application's color palette flexible for all users?
+9. Are images and icons used appropriately for easy understanding?
+10. Does the application have audio alerts? Or video controls?
+11. Can a user change the default font for printing and displaying text?
+12. Can the user adjust or disable flashes, rotations, or moving displays?
+13. Ensure that color coding is not the only way to convey information or indicate actions.
+14. Test the application's colors by adjusting the contrast.
+15. Is audio and video content clear for people with disabilities? Test all multimedia pages without speakers.
+16. Is training offered to users with disabilities to promote familiarity with the software?
+
+### Accessibility Testing Tools
+
+Some of the most commonly used tools for accessibility testing are:
+
+- Wave
+- TAW
+- Accessibility Developer Tools
+- Quick Accessibility Page Tester
+- aDesigner
+- WebAnywhere
+- Web Accessibility Toolbar
diff --git a/docs/en/02-types/15-compatibility.md b/docs/en/02-types/15-compatibility.md
new file mode 100644
index 0000000..54e41f7
--- /dev/null
+++ b/docs/en/02-types/15-compatibility.md
@@ -0,0 +1,32 @@
+# Compatibility Testing
+
+Compatibility is the ability to coexist. In the context of software, compatibility testing verifies if your software can run on different hardware configurations, operating systems, applications, network environments, or mobile devices.
+
+It is also a type of Non-Functional Testing.
+
+## Types of Compatibility Testing
+
+<img src="https://www.guru99.com/images/c2.png" alt="Enumeration of Types of Compatibility Testing">
+
+- **Hardware:** Checks if the software is compatible with different hardware configurations.
+- **Operating System:** Ensures the software functions properly on different operating systems like Windows, Unix, Mac OS, etc.
+- **Software:** Validates if the application is compatible with other software. For example, MS Word should be compatible with other software like MS Outlook, MS Excel, etc.
+- **Network:** Evaluates the system's performance on a network with variable parameters such as bandwidth, operating speed, capacity, etc. It also validates the application on different networks with all the aforementioned parameters.
+- **Browser:** Checks the compatibility of the website with different browsers like Firefox, Chrome, IE, etc.
+- **Devices:** Verifies compatibility with mobile platforms like Android, iOS, etc.
+- **Software Versions:** Checks if the software application is compatible across different versions. For example, validating if Microsoft Word is compatible with Windows 7, Windows 7 SP1, Windows 7 SP2, etc.
+  There are two types of version checking in Compatibility Testing:
+  - **Backward Compatibility Testing:** Technique that validates the software's behavior and compatibility with its previous versions of hardware or software. This modality is quite predictable since all changes between versions are known.
+  - **Forward Compatibility Testing:** A process that verifies the application's behavior and compatibility with new versions of hardware or software. It is a more complex process to predict since changes in new versions are unknown.
+
+## Tools for Compatibility Testing
+
+1. **BrowserStack**
+2. **Virtual Desktops - OS Compatibility:** Applied to execute the application on multiple operating systems as virtual machines, various systems can be connected, and the results can be compared.
+
+## How to Perform Compatibility Testing
+
+1. **Initial Phase:** Define the group of environments or platforms that the application should work on.
+2. **Tester Knowledge:** The tester must have sufficient knowledge of the platforms/software/hardware to understand the expected behavior of the application under different configurations.
+3. **Environment Setup:** Configure the environment for testing with different platforms/devices/networks to check if the application functions correctly.
+4. **Bug Reporting:** Report bugs, fix defects, and retest to confirm the applied corrections.
diff --git a/docs/en/03-admin/00-intro.md b/docs/en/03-admin/00-intro.md
new file mode 100644
index 0000000..82cfded
--- /dev/null
+++ b/docs/en/03-admin/00-intro.md
@@ -0,0 +1,9 @@
+# Administração de Projetos
+
+Um projeto é uma empreitada temporária com o objetivo de criar um produto, serviço ou resultado únicos.
+
+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.
+
+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.
+
+Isto facilita o fluxo de trabalho do time de colaboradores.
diff --git a/docs/en/03-admin/01-plan.md b/docs/en/03-admin/01-plan.md
new file mode 100644
index 0000000..ea34bf9
--- /dev/null
+++ b/docs/en/03-admin/01-plan.md
@@ -0,0 +1,266 @@
+# Planejamento de Testes
+
+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.
+
+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.
+
+De acordo com a definição da ISTQB
+
+     "O Plano de Testes é um documento que descreve o escopo, abordagem, recursos e agenda das atividades de teste planejadas"
+
+## Importância do Plano de Testes
+
+Os benefícios do documento Plano de Testes são variados:
+
+- 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.
+
+## Como Escrever um Plano de Testes
+
+<img src="https://www.guru99.com/images/TestManagement/testmanagement_article_2_4_3.png" alt="Fluxograma Plano de Testes">
+
+### 1. Analise o Produto
+
+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.
+
+O produto sob testes é Guru99 Site Bancário. Deve-se pesquisar clientes, usuários finais e conhecer suas necessidades e expectativas do aplicativo.
+
+- Quem irá usar o Site?
+- Qual sua função?
+- Como funcionará?
+- Quais softwares/hardwares o produto utiliza?
+
+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.
+
+### 2. Desenvolve a Estratégia de Testes
+
+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:
+
+- Os objetivos de teste do projeto, bem como os meios para atingí-los.
+- Determina o esforço e custos necessários.
+
+<img src="https://www.guru99.com/images/TestManagement/testmanagement_article_2_4_6.png" alt="Fluxograma do Desenvolvimento de Estratégia">
+
+#### 2.1. Defina o Escopo de Testes
+
+Antes de iniciar qualquer atividade de teste, o escopo deve ser definido.
+
+- 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.
+
+Definir o Escopo de seu projeto de testes é importante para todos os investidores, uma vez que ajuda a:
+
+- 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. Como determinar o Escopo de Testes
+
+- Requerimentos de Cliente Precisos
+- Orçamento do Projeto
+- Especificação de Produto
+- Habilidades e Talentos no Time de Testes
+
+Agora deve-se definir claramente o que esta dentro e fora do escopo.
+
+#### 2.2. Identificando o Tipo de Testes
+
+Um tipo de teste é um procedimento padrão que provê um resultado esperado para os testes.
+
+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.
+
+Os tipos comumente utilizados são:
+
+- 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
+
+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. Documento Riscos e Problemas
+
+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".
+
+Exemplos de Riscos para documentação:
+
+- 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. Crie Lógicas de Teste
+
+Na lógica de testes, o Gerente deverá responder as seguintes perguntas:
+
+- Quem irá testar?
+- Quando o teste irá ocorrer?
+
+Você pode não conhecer exatamente os nomes de cada tester, mas o tipo de tester pode ser definido.
+
+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.
+
+Possuir as seguintes habilidades é o mais ideal para aplicação de testes:
+
+- Capacidade de compreensão do ponto de vista dos clientes
+- Forte desejo por qualidade
+- Atenção a Detalhes
+- Boa cooperação
+
+Em seu projeto, o tester irá tomar as rédeas da execução. Baseado no orçamento, pode-se selecionar terceirizações.
+
+*Quando o teste ocorrerá?*
+
+Atividades de teste devem ser associadas com atividades de desenvolvimento, devendo iniciar-se quando todos os itens necessários existirem.
+
+<img src="https://www.guru99.com/images/TestManagement/testmanagement_article_2_4_8.png" alt="Itens Necessários Para Início de Testes">
+
+### 3. Defina objetivos para o teste
+
+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.
+
+Para definir objetivos, deve-se:
+
+- 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. Defina os critérios de teste
+
+Os critérios são padrões ou regras nas quais os procedimentos de teste baseiam-se, existem dois tipos:
+
+#### 4.1. Critério de Suspensão
+
+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.
+
+*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.
+
+<img src="https://www.guru99.com/images/TestManagement/testmanagement_article_2_4_10.png" alt="Fluxograma Critérios de Suspensão">
+
+#### 4.2. Critérios de Saída
+
+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.
+
+Alguns métodos para definir os critérios de saída consistem na especificação de taxas par execução e sucesso.
+
+- 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.
+
+Estes dados podem ser coletados em documentos de Metrica para Testes.
+
+- 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. Planejamento de recursos
+
+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.
+
+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
+  - 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.
+
+  - 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
+
+#### 5.1. Recursos do Sistema
+
+Para testar um aplicativo web, deve-se planejar os recursos de acordo com:
+
+- 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
+
+### 6. Planeje o ambiente de testes
+
+*O que é o ambiente de testes?*
+
+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.
+
+#### 6.1. Como Configurar o Ambiente de Testes
+
+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.
+
+- 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?
+
+### 7. Cronograma e Estimativa
+
+Suponha que todo o projeto seja subdivido em tarefas menores e adicionados na estimativa da seguinte forma:
+
+- 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.
+
+Assim, pode-se elaborar o cronograma para completar todas as tarefas.
+
+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.
+
+Para elaborar o cronograma de um projeto, o Gerente de Testes precisa de diversas informações, tais como:
+
+- 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
+
+### 8. Determine os entregáveis para os testes
+
+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.
+
+Existem diferentes entregáveis em todas as fases do desenvolvimento
+
+<img src="https://www.guru99.com/images/TestManagement/testmanagement_article_2_4_15.png" alt="Antes do Teste, Durante o Teste, Após o Teste">
+
+Entregáveis são providenciados *antes* da fase de testes:
+
+- Documento Planos de Testes
+- Documento Casos de Teste
+- Especficiações do Design de Testes
+
+Entregáveis providenciados *durante* a fase de testes:
+
+- Scripts de Teste
+- Simuladores
+- Dados de Testes
+- Matriz de Rastreabilidade de Teste
+- Logs de erros e execuções
+
+Entregáveis providenciados *após* a fase de testes:
+
+- Resultados/Relatórios de Testes
+- Relatório de Defeitos
+- Instalação/Diretrizes dos Procedimentos de Testes.
+- Notas de Lançamento.
diff --git a/docs/en/03-admin/01-priorizacao.md b/docs/en/03-admin/01-priorizacao.md
new file mode 100644
index 0000000..1b95734
--- /dev/null
+++ b/docs/en/03-admin/01-priorizacao.md
@@ -0,0 +1,105 @@
+# 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/02-sldc.md b/docs/en/03-admin/02-sldc.md
new file mode 100644
index 0000000..ed87a1d
--- /dev/null
+++ b/docs/en/03-admin/02-sldc.md
@@ -0,0 +1,105 @@
+# Metodologias do Ciclo de Vida do Software
+
+Software Developmente Life Cycle é o processo seguido para o desenvolvimento de um software, englobando sua organização, planejamento, entrega e etc.
+
+## O que é SLDC?
+
+É 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.
+
+<img src="https://www.tutorialspoint.com/sdlc/images/sdlc_stages.jpg" alt="Fluxograma SLDC">
+
+### 1. Planejamento e Análise de Requerimentos
+
+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.
+
+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.
+
+### 2. Definindo Regras de Negócio
+
+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.
+
+### 3. Design da Arquitetura do Projeto
+
+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)
+
+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.
+
+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.
+
+### 4. Construção e Desenvolvimento do Produto
+
+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.
+
+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.
+
+### 5. Testagem do Produto
+
+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.
+
+### 6. Implementação no Mercado e Manutenção
+
+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).
+
+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.
+
+## Modelos SLDC
+
+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.
+
+Os modelos mais populares de SLDC são:
+
+- Cascata
+- Iterativo
+- Espiral
+- Modelo-V
+- Big Bang
+
+## O que é o o Quality Assurance no SLDC?
+
+O QA possui papel fundamental no processo que deve ser implementando no ciclo de desenvolemento.
+
+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.
+
+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.
+
+O QA em TI é integrado em todos os estágios de desenvolvimento, e é usado mesmo após o estágio de lançamento.
+
+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).
+
+## Quais Profissionais Integram o Time de QA?
+
+Podendo de empresa para empresa, as principais funções são:
+
+- 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.
+
+## Responsabilidades de um time de QA no TI
+
+O escopo de tarefas do QA deve ser bastante amplo. O time de quality assurance mais uma vez prova sua importância no SLDC.
+
+- 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.
+
+## Qual é o Papel do QA em Desenvolvimento de Projeto?
+
+Quality Assurance no ciclo de vida de desenvolvimento desempenha papel crucial em todos os estágios, como por exemplo:
+
+- 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.
+
+## A Importância do Processo de Quality Assurance
+
+- 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.
diff --git a/docs/en/03-admin/03-agile.md b/docs/en/03-admin/03-agile.md
new file mode 100644
index 0000000..9e470e4
--- /dev/null
+++ b/docs/en/03-admin/03-agile.md
@@ -0,0 +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;
diff --git a/docs/en/03-admin/04-scrum.md b/docs/en/03-admin/04-scrum.md
new file mode 100644
index 0000000..6d91c62
--- /dev/null
+++ b/docs/en/03-admin/04-scrum.md
@@ -0,0 +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.
+
+<img src="https://www.guru99.com/images/11-2014/agile_Processesv1_4.png" alt="Funcionamento Scrum">
+
+## Testagem Scrum
+
+É 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.
+
+## Características Chave da Metodologia Scrum
+
+- 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;
+
+<img src="https://www.guru99.com/images/11-2014/112714_1232_ScrumTestin1.jpg" alt="Papéis Metodologia Scrum">
+
+### 1. Papéis no 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;
+
+- 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;
+
+- 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
+
+### 2. Artefatos Scrum
+
+<img src="https://www.guru99.com/images/2/scrum_testing_2.png" alt="Fluxograma Artefatos Scrum">
+
+Um processo Scrum, inclúi:
+
+- 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;
+
+### 3. Cerimônias (Processos) em 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;
+
+## Papel do Tester no Scrum
+
+**Não há papel ativo do tester no Processo Scrum.**
+
+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.
+
+## Atividades de Teste no 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.
+
+- 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.
+
+- 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.
+
+## Relatório de Testes
+
+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.
+
+Existem duas métricas frequentimente usadas para reportar:
+
+### Gráfico Burn Down
+
+Diariamente, o Scrum Master registra o trabalho restante estiamdo para a sprint atual. O que nada mais é do que o Burn Down, atualizado diariamente.
+
+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.
+
+<img src="https://www.guru99.com/images/11-2014/112714_1232_ScrumTestin4.jpg" alt="Gráfico Burn Down">
+
+### Gráfico de Histórico de Velocidade
+
+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.
+
+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.
diff --git a/docs/en/03-admin/05-kanban.md b/docs/en/03-admin/05-kanban.md
new file mode 100644
index 0000000..5a51805
--- /dev/null
+++ b/docs/en/03-admin/05-kanban.md
@@ -0,0 +1,101 @@
+# 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.
+
+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.
+
+## O que é um Painél Kanban
+
+É uma ferramenta de gerenciamento de projetos Ágeis que auxiliam na visualização clara do projeto, maximizando eficiência (ou fluxo).
+
+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.
+
+## Elementos de um Painél Kanban
+
+Painés podem ser dividos em cinco componentes:
+
+1. Sinais Visuais;
+2. Colunas;
+3. Limites de Trabalho em Progresso;
+4. Ponto de Comprometimento;
+5. Ponto de Entrega;
+
+### 1. Sinais Visuais
+
+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.
+
+### 2. Colunas
+
+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.
+
+Cards fluem através deste fluxo até estarem completos.
+
+Fluxos de Trabalhos podem ser tão simples quanto "A Fazer", "Em Progresso", "Completo" ou bem mais complexas.
+
+### 3. Limites de Work in Progress (WIP)
+
+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.
+
+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.
+
+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.
+
+### 4. Ponto de Compromisso
+
+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.
+
+### 5. Ponto de Entrega
+
+É o fim do fluxo de trabalho para um time Kanban.
+
+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.
+
+    Jim Benson diz que o Kanban possui apenas duas regras:
+
+    "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!"
+
+## Tipos e Exemplos de Painéis Kanban
+
+O Kanban pode ser adaptado para diversos ambientes, desde a manufatura até os recursos humanos, do Ágil ao DevOps.
+
+O Tipo de ambiente adaptando o Kanban muitas vezes dita se o painél é físico ou digital.
+
+## Painéis Físicos
+
+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.
+
+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"
+
+É simples e fácil de montar, mas por vezes, a tela física não é ideal para times remotos.
+
+## Quadros Digitais
+
+Enquanto o sistema Kanban ganhou espaço com os times de software e engenharia, sofreu.
+
+Painéis digitais permitem que times que não dividem espaços físicos possam usar quadros Kanban remotamente e de forma assíncrona.
+
+A plataforma Trello oferece uma forma rápida e fácil de criar painéis Kanban virtualmente.
+
+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.
+
+## 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:
+
+- 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.
+
+Tanto o Kanban quanto o Scrum são estruturas Ágil populares entre desenvolvedores de software.
+
+## Iniciando um Quadro Kanban
+
+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:
+
+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;
diff --git a/docs/en/03-admin/06-waterfall.md b/docs/en/03-admin/06-waterfall.md
new file mode 100644
index 0000000..4465075
--- /dev/null
+++ b/docs/en/03-admin/06-waterfall.md
@@ -0,0 +1,51 @@
+# Modelo Cascata
+
+É 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.
+
+Cada etapa é estruturada para desenvolver uma atividade específica durante a fase SDLC.
+
+<img src="https://www.guru99.com/images/6-2015/052615_1232_WhatisSDLCo1.png" alt="Fluxograma Cascata">
+
+## Etapas do Modelo Cascata
+
+- 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.
+
+- 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.
+
+- Fase de Construção: Após o Design, passamos a construir de fato o código do software.
+
+- Fase de Testes: Após, testamos o software para verificar que foi feito conforme as especificações fornecidas pelo cliente.
+
+- Fase de Implementação: Implementa a aplicação no ambiente designado.
+
+- 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.
+
+## Quando Utilizar o Modelo Cascata?
+
+Pode ser aplicado quando:
+
+- 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;
+
+### Vantagens Modelo Cascata
+
+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;
+
+### Desvatagens do Modelo Cascata
+
+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;
diff --git a/docs/en/03-admin/07-v-model.md b/docs/en/03-admin/07-v-model.md
new file mode 100644
index 0000000..3bc6250
--- /dev/null
+++ b/docs/en/03-admin/07-v-model.md
@@ -0,0 +1,41 @@
+# Modelo V
+
+É uma estrutura de SLDC altamente disciplinada que possui uma faze de testes paralela a cada etapa de desenvolvimento.
+
+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.
+
+<img src="https://www.guru99.com/images/6-2015/052715_0904_GuidetoSDLC3.png" alt="Fluxograma Modelo V">
+
+## Exemplificação Cascata vs V
+
+Considere a seguinte sequência de passos:
+
+- 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.
+
+- 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.
+
+- Fase de Construção: Após o Design, passamos a construir de fato o código do software.
+
+- Fase de Testes: Após, testamos o software para verificar que foi feito conforme as especificações fornecidas pelo cliente.
+
+- Fase de Implementação: Implementa a aplicação no ambiente designado.
+
+- 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.
+
+**Todas estas etapas constituem o modelo CASCATA, de desenvolvimento.**
+
+### Problemas com o modelo Cascata
+
+Como pode observar, os testes são realizados apenas após a implementação estar finalizada.
+
+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.
+
+Desta forma, os custos de corrigir defeitos aumentam a medida que progredimos no SDLC. Quanto mais cedo detectados, mais baratos serão para corrigir.
+
+## Solução: Modelo V
+
+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.
+
+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.
diff --git a/docs/en/03-admin/08-report.md b/docs/en/03-admin/08-report.md
new file mode 100644
index 0000000..534d80e
--- /dev/null
+++ b/docs/en/03-admin/08-report.md
@@ -0,0 +1,110 @@
+# Elaboração de Relatório
+
+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.
+
+## O que é um 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.
+
+É 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.
+
+## Defeitos na Testagem de Software
+
+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.
+
+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.
+
+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
+
+## Relatório de Bugs na Testagem de Software
+
+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.
+
+Ao reportar bugs ao desenvolvedor, o seu relatório deve conter as seguintes informações:
+
+- 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.
+
+Outros elementos necessários para o relatório são:
+
+- 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?
+
+## Processo de Gerenciamento dos Defeitos
+
+Sistemática para identificação e correção dos bugs. O ciclo de gerenciamento dos defeitos contém os seguintes passos:
+
+ 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.
+
+<img src="https://www.guru99.com/images/TestManagement/testmanagement_article_4_4.png" alt="Ciclo de Gerenciamento de Defeitos">
+
+### Descoberta
+
+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.
+
+<img src="https://www.guru99.com/images/TestManagement/testmanagement_article_4_5.png" alt="Fluxograma Detecção e Reconhecimento de Defeitos">
+
+### Categorização
+
+A categorização de defeitos auxilia os desenvolvedores de software a priorizar suas tarefas de acordo com sua prioridade.
+
+- 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.
+
+### Resolução
+
+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.
+
+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.
+
+- 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.
+
+### Verificação
+
+Após o time de desenvolvimento ter corrigido e reportado o  defeito, a equipe de testes  verifica que os problemas foram realmente corrigidos.
+
+### Encerramento
+
+Uma vez que o defeito tenha sido resolvido e verificado, o status é alterado para *"Encerrado"*.
+
+## Relatório de Defeitos
+
+É 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.
+
+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.
+
+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.
+
+### Como medir e avaliar a qualidade da execução de testes
+
+- 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
diff --git a/docs/en/03-admin/09-verificacao.md b/docs/en/03-admin/09-verificacao.md
new file mode 100644
index 0000000..27f193d
--- /dev/null
+++ b/docs/en/03-admin/09-verificacao.md
@@ -0,0 +1,129 @@
+# 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:
+
+<img src="https://www.guru99.com/images/blog/submet.png" alt="Botão Submet">
+
+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.
+
+<img src="https://www.guru99.com/images/jsp/030116_0846_LearnDesign1.png" alt="Fluxograma Validação de Design">
+
+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.
+
+<img src="https://www.guru99.com/images/jsp/030116_0846_LearnDesign2.png" alt="Fluxograma Processo de Validação">
+
+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/04-execucao/00-intro.md b/docs/en/04-execucao/00-intro.md
new file mode 100644
index 0000000..ba7af98
--- /dev/null
+++ b/docs/en/04-execucao/00-intro.md
@@ -0,0 +1,232 @@
+# 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
+
+<img src="https://www.guru99.com/images/1/test-cases_01.png" alt="Tela de 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
new file mode 100644
index 0000000..d05e4ee
--- /dev/null
+++ b/docs/en/04-execucao/01-manual.md
@@ -0,0 +1,65 @@
+# 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
+
+<img src="https://www.guru99.com/images/typesofmanualtesting.png" alt="Diagrama dos 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
new file mode 100644
index 0000000..a2928d5
--- /dev/null
+++ b/docs/en/04-execucao/02-automatizado.md
@@ -0,0 +1,213 @@
+# 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.
+
+<img src="https://wac-cdn.atlassian.com/dam/jcr:c4c69694-506f-4d68-9563-c1bc5770e784/testing-stack@4x.png?cdnVersion=631" alt="Pirâmide Teste Automatizado/CI/CD">
+
+## *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:
+
+<img src="https://browserstack.wpenginepowered.com/wp-content/uploads/2020/01/test-automation-pyramid-640x586.jpg" alt="Estrutura de 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