This project consists of an automated test suite developed in Python using the Pytest framework. The primary objective is to validate the business rules and contracts of the Users, Products, Login and Carts endpoints of the public API ServeRest, ensuring data integrity, system resilience and response accuracy.
During the fourth week of the Bootcamp, the project architecture was refactored following Quality Engineering best practices:
- Domain-Driven Modularization: Reorganized test files into clear modules based on context (Login, Users, Products and Carts), moving away from monolithic structures.
- Adoption of the AAA Pattern (Arrange, Act, Assert): Removed redundant
try/exceptblocks that cluttered the code. The structure now strictly follows the Arrange, Act, and Assert flow, making tests focused and readable. - Base URL Centralization: Created dedicated fixtures to manage the API base URL, eliminating string repetition across tests and facilitating seamless transitions between different testing environments.
- State Management (Setup/Teardown): Implemented automated database cleanup routines (
teardown), ensuring complete independence between test scenarios. - Contract Testing: Evolved from simple
status_codeand isolated key validations to full structural validation of the response payload using thejsonschemalibrary.
1. Objective and Strategy
- Objective: Ensure functional quality, contract stability and reliability.
- Strategy: Automation of functional and contract tests at the API layer.
- Tech Stack: Python 3.13.x, Pytest, Requests and JSONSchema.
- Scope:
/login,/usuarios,/produtosand/carrinhosendpoints. - Out of Scope: Load, stress and performance testing.
2. Mapped Test Scenarios
test_login.py: Authentication suite (success and failure scenarios).test_usuarios.py: Full CRUD operations with email validation.test_produtos.py: Product management and admin token validation.test_carrinhos.py: Purchase management, stock constraints and order cancellation.
3. Definition of Done (DoD)
- Naming convention:
test_<action>_<expected_result>. - Centralized fixtures (
conftest.py). - Dynamic test data (UUID).
- Full structural validation via
JSON Schema.
The project’s lifecycle and deliverables have been consolidated through a verification matrix, split across five key phases to ensure high engineering standards, architectural integrit, and robust test practices.
The journey began with the Planning phase, which established a solid foundation for the entire testing lifecycle. A test strategy was defined within the test-plan_week_004.md file, outlining target endpoints and explicit completion criteria. Additionally, supported by a detailed scenarios mapping process, which produced an exhaustive list of target endpoints evaluating positive, negative validation pathways.
Building upon this foundation, the project transitioned into the Test Expansion phase to validate core application components. This stage achieved complete functional CRUD validations for users and login mechanisms, managing the multi-scenario authenticatio. The products catalog integration flows covered, incorporating schema checks.
Project visibility and engineering insight were then prioritized during the Metrics phase. To ensure global maintainability, the entire repository documentation and execution logs were written in standard English. Simultaneously, a coverage framework was introduced, employing mathematical analysis to track tested endpoints against the total available API pathways, ensuring quantifiable test depth.
System resilience was actively enforced during the Defect Tracking phase through real bugs discovery. This involved active and continuous scanning of the application infrastructure, which successfully translated detected vulnerabilities into bug report logs opened directly on GitHub Issues for tracking and resolution.
Finally, the ecosystem was hardened in the Infrastructure phase to guarantee a reliable delivery. Contract verification was established to validate API response payload integrity across multiple endpoints using pytest-schema. This flow was fully automated through GitHub Actions, utilizing workflow definitions in the ci.yml file to trigger cloud automation instantly on every code push. The deployment pipeline is completed by the full dockerization of the application, achieving complete environment isolation using a optimized-slim base image.
QA-bootcamp-2026/
│
├── .github/
│ └── workflows/
│ └── ci.yml # CI/CD configuration (GitHub Actions)
│
├── semana_003/ # Sprint 3 Challenges
│ ├── tests/
│ │ ├── test_create_user_duplicated_email.py
│ │ ├── test_create_user_successfully.py
│ │ ├── test_delete_product.py
│ │ ├── test_delete_user_successfully.py
│ │ ├── test_if_API_is_online.py
│ │ ├── test_list_all_products.py
│ │ ├── test_runningALL.py
│ │ ├── test_search_product_by_id.py
│ │ ├── test_search_user_by_id.py
│ │ ├── test_search_user_by_nonexistent_id.py
│ │ ├── test_update_product.py
│ │ ├── test_update_user_nonexistent_id.py
│ │ └── test_update_user_successfully.py
│ └── conftest.py # Fixtures for Sprint 3
│ └── requirements.txt # Python project dependencies
│
├── semana_004/ # Sprint 4 Challenges
│ ├── tests/
│ │ ├── __init__.py
│ │ ├── schemas.py # JSON Schemas for validation
│ │ ├── test_carrinhos.py
│ │ ├── test_login.py
│ │ ├── test_produtos.py
│ │ └── test_usuarios.py
│ └── conftest.py # Fixtures for Sprint 4
│ └── requirements.txt # Python project dependencies
|
├── README.md # Project documentation
└── Dockerfile # Docker configuration for isolated test execution environment
└── package.json # Node dependencies for auxiliary tools
└── requirements.txt # Python project dependencies
To ensure the robustness and quality of the API, the automation strategy was based on the Operator Coverage methodology. This approach measures the extent of tested HTTP methods in relation to the available endpoints.
| Endpoint | POST | GET | PUT | DELETE | Total Operations |
|---|---|---|---|---|---|
/login |
✅ | - | - | - | 1 |
/usuarios |
✅ | ✅ | ✅ | ✅ | 4 |
/produtos |
✅ | ✅ | ✅ | ✅ | 4 |
/carrinhos |
- | - | ✅ | ✅ | 2 |
| Totals | 4 | 2 | 3 | 2 | 11 / 11 |
The calculation was performed using the Operator Coverage formula:
Since the API exposes 11 distinct operations across the four resources (Login, Users, Products and Carts) and all flows have been properly automated, the test suite has achieved 100% operation coverage.
Beyond achieving 100% operator coverage, the suite focuses on the quality of validations:
- Status Code Coverage: Validation of successful flows (200, 201) and expected error scenarios (400, 401, 403, 404).
- JSON Schema Validation: Guarantee that the API contract is respected in every response, ensuring the Front-End receives the expected data format.
- Integration Flows: Tests that orchestrate dependencies, such as creating a product for subsequent use in cart creation, simulating real-world system usage.
| Severity | Bug / Inconsistency | Expected Behavior | Actual Behavior |
|---|---|---|---|
| Critical | Privilege Escalation | The system must prevent a standard user from changing their profile to administrador: true. |
The PUT /usuarios/{id} endpoint allows the change, promoting the user to administrator. |
| Low | Response Inconsistency (Empty Payload) | Return a standardized validation error (400) on all routes when receiving {}. |
Returns 400 on public routes and 401 on private routes for the same payload. |
| Challenge | Solution |
|---|---|
| Contract Validation (JSON Schema) | Mapped specific error keys per field (e.g., "nome": "nome é obrigatório") instead of generic keys, facilitating error handling on the Front-End. |
| HTTP Verb Response | Strategic separation between mutation schemas (only message and _id) and reading schemas (full object), adjusting validation expectations. |
| Request Chaining | Implementation of chained flows (POST Product > Extract _id > Build Payload > POST Cart) to respect the API's relational architecture. |
| Data Mutability | Used the .copy() method on dictionaries to prevent data manipulation in one test from affecting the original fixture state in subsequent tests. |
| Pytest Rigor (Naming) | Developed a critical reading approach to Pytest error logs to quickly identify naming mismatches between fixtures and injected parameters. |
| Development Environment | Increased attention to visual file-saving indicators in VS Code, eliminating false positives caused by running outdated code. |
This challenge was a deep dive into what it truly means to be a Quality Engineer in practice. As our instructor Jacques Schmitz mentioned in our 1st Workshop, "QA acts throughout the entire cycle, acting as a facilitator for the team—influencing design, assisting with observability and managing how to handle the volume of data generated by the business." I realized that when we structure well-organized tests, our mission is not just to find bugs, but to prevent problems from arising while simultaneously reducing business risks.
Far beyond simply automating manual tasks, we are building a safety layer "to have peace of mind and security regarding changes" and to "ensure that changes do not break other aspects of the code," as stated by Professor José Correia, Software Quality Specialist, in the Início Rápido em Teste e QA course available on Udemy (which we studied during the first week of the Bootcamp).
The refactoring I carried out during this fourth week gave me a valuable insight: quality is an intrinsic part of architecture, and as QAs, we must act throughout the entire application lifecycle (as indicated by the shift-left approach), a topic covered in our second-week quiz. When we treat API contracts with the same care that we treat the user interface, we help everyone realize "that quality is a team effort and vital for the product," a concept emphasized by Correia.
In this way, we ensure that the entire ecosystem speaks the same language. Reflecting on this entire experience: I feel even more motivated and equipped with a stronger toolkit to apply this strategic vision in business scenarios, acting as an active project member who provides guidance on quality.
- AAA Pattern in Test Automation - Semaphore CI
- Pytest Documentation & Best Practices
- Pytest: Help your tests do more
- How to verify REST API test coverage
- Test Coverage Criteria for RESTful Web APIs
- Introduction to Contract Testing
- Understanding JSON Schema
- PyTest-Full-Stack 11 - Using pytest-docker package to test docker
- Clone the repository:
git clone <https://github.com/codebyfernanda/QA-bootcamp-2026.git>
cd QA-bootcamp-2026
- Create and activate a virtual environment:
# Windows
python -m venv venv
venv\Scripts\activate
# Linux/macOS
python -m venv venv
source venv/bin/activate
- Install the dependencies:
pip install -r requirements.txt
- Run the tests:
pytest -v
This project was developed by Fernanda Bastos dos Santos (@codebyfernanda), a student of Analysis and Systems Development at Mackenzie, during the BOOTCAMP | AWS AI FDE DRIVEN QUALITY ENGINEERING hosted by Compass UOL in partnership with AI/R Company.
I would like to express my sincere gratitude to Squad 2 for their engagement, knowledge sharing and support throughout our bootcamp journey. A special thanks goes to my colleagues Renan Pacheco and Vitor Kunicki — your patience, availability and guidance were fundamental in helping me overcome the challenges of this delivery.
I would also like to take this opportunity to thank my instructors, Amanda Almeida and Jacques Schmitz, for their continuous support and readiness to help with technical content during our training, as well as our Scrum Master, Leticia Souza, for her daily guidance and sensitivity toward our journey in the program. Thank you so much! :)