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

@@ -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.

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.

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.

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.

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.

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.

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.