Teste de penetração em aplicações web – tudo o que você precisa saber

Web application penetration testing is a manual security assessment that simulates real attacks against a web application to find exploitable vulnerabilities before attackers do. A strong web app pentest goes beyond automated scanning by testing authentication, authorization, business logic, session handling, input validation, APIs, and the OWASP Top 10 using a structured methodology such as the OWASP Web Security Testing Guide.

For SaaS, B2B and B2C internet-facing platforms, a web application pentest is often required for SOC 2, ISO 27001, PCI DSS, HIPAA, customer security reviews, vendor assessments, and enterprise sales. It gives security and engineering teams evidence of what is exploitable, how severe each issue is, and what needs to be fixed first.

At Blaze Information Security, we conduct hundreds of SaaS and web application penetration testing assessments every year. Our 2025 Annual Penetration Testing Review analyzed 660 penetration tests across 145 organizations, producing 3,294 confirmed vulnerabilities from manual testing rather than theoretical scanner output. That experience shows a clear pattern: modern web application risk is usually concentrated around identity, authorization, APIs, sensitive data exposure, and business logic.

This guide explains what web application penetration testing is, what it includes, how it differs from vulnerability scanning, how to prepare, which methodologies matter in 2026, what tools are commonly used, how long a test takes, and what to expect from a high-quality report.

What is web application penetration testing?

Web application penetration testing is a controlled security assessment designed to evaluate a web application's resistance to real-world attacks. During a web app pentest, security consultants manually test the application for vulnerabilities that could allow unauthorized access, data exposure, account takeover, privilege escalation, payment abuse, business logic abuse, or compromise of connected systems.

Unlike a basic vulnerability scan, a penetration test does not stop at listing possible issues. A pentester verifies findings, attempts safe exploitation, evaluates impact, chains weaknesses where relevant, and documents practical remediation steps for engineering teams.

A web application penetration test typically examines five core areas:

• Identity and access control: Authentication, authorization, session management, SSO, SAML, OAuth, OpenID Connect, SCIM, invitation flows, and role-based access control.
• Application and API behavior: REST, GraphQL, WebSocket, backend API endpoints, user input handling, server-side validation, and business logic abuse cases.
• Sensitive workflows: Payments, checkout flows, subscriptions, admin actions, file uploads, file downloads, exports, previews, and privileged operations.
• Data protection and browser-side controls: Sensitive data exposure, encryption use, security headers, client-side controls, and browser-side protections.
• Operational security: Third-party integrations, logging, monitoring, error handling, and alerting for suspicious or unauthorized activity.

The primary goals and tangible benefits of web application penetration testing include:

• Identifying exploitable security weaknesses: A web app pentest uncovers vulnerabilities in design, implementation, configuration, access control, and business logic.
• Evaluating security controls: Testing shows whether controls such as authentication, authorization, encryption, rate limiting, input validation, and session management work under attack conditions.
• Ensuring compliance: Web penetration testing helps ensure the application adheres to industry frameworks and regulations, such as GDPR, HIPAA, SOC 2, ISO 27001, and PCI DSS, which are crucial for maintaining trust and compliance requirements.
• Providing actionable recommendations: A good report includes severity, business impact, affected endpoints, reproduction steps, proof-of-concept evidence, and specific remediation advice.
• Integrating security into the development lifecycle (SDLC): Findings from a web app pentest help engineering teams fix current issues and improve secure coding, code review, threat modeling, and release processes.
• Maintaining customer trust and brand integrity: Regular testing demonstrates that your organization takes application security seriously, especially when selling to enterprise customers or handling regulated data.
• Cost-effective and proactive risk management: Addressing vulnerabilities post-attack can be costly. Penetration testing proactively identifies and resolves security weaknesses, making it a cost-effective strategy for risk management.
• Prioritizing security investment: Penetration testing helps teams focus on real, exploitable risks rather than long lists of theoretical scanner alerts.

Web application penetration testing vs. web application vulnerability scanning

A vulnerability scan is not the same as a web application penetration test. Both are useful, but they answer different questions. A vulnerability scanner asks, "What known issues might exist?", whereas a web application penetration test asks, "What can an attacker actually do?"

Automated scanners are useful for identifying common misconfigurations, missing headers, outdated components, exposed files, known CVEs, and some injection patterns. They are fast, repeatable, and helpful for continuous monitoring. Vulnerability scanning is also useful for compliance programs, including SOC 2 security monitoring and remediation workflows.

Manual web application penetration testing goes deeper. It tests how the application behaves in context. For example, a scanner may miss that a standard user can modify another customer's invoice by changing an ID in an API request. It may also miss logic flaws such as bypassing a checkout flow, abusing a password reset process, escalating privileges across tenant boundaries, or chaining a low-severity XSS with weak session controls.

For mature security programs, the strongest approach is not "scanner or pentest." It is both. Use continuous vulnerability scanning, then run manual web app pentests before major releases, after significant architectural changes, during compliance cycles, and when onboarding major enterprise customers.

Preparing for a web application penetration test

Preparing for a web app pentest is critical. The better the preparation, the more useful the assessment will be. Good preparation helps testers cover the full attack surface, avoid wasting time on access issues, and focus on vulnerabilities that matter to the business.

Before the test begins, prepare the following information:

Organizations might opt for a full white-box test for a more in-depth assessment. In this scenario, the penetration testing team is given access to the web application's source code. This enables a thorough understanding of the application's architecture and logic, often uncovering vulnerabilities that are difficult or impossible to detect through grey-box or black-box testing.

Leveraging OWASP methodologies in web app penetration testing

The Open Web Application Security Project (OWASP) heavily influences industry-wide methodologies in web application security. OWASP is a cornerstone in our industry, providing comprehensive, open-source frameworks to guide web app pen testing.

Central to the approach is the OWASP Top 10, a widely recognized document that outlines the 10 most critical web application exploits and security risks. This list, updated every couple of years based on evolving threats (the last update was in 2025), serves as a roadmap for identifying and prioritizing common vulnerabilities.

Equally important is the OWASP Testing Guide, a detailed manual that provides a comprehensive methodology and checklist for security testing web applications. It encompasses various test cases, techniques, and best practices that are invaluable for any application penetration tester. This guide is structured to cover all aspects of a web app, from initial mapping and information gathering to vulnerability exploitation and post-exploitation analysis.

Also valuable is the OWASP Application Security Verification Standard (ASVS), which sets a security controls and requirements framework for development teams. This is particularly useful for aligning security testing with industry best practices and ensuring comprehensive coverage of all security aspects of a web application.

For testing, the OWASP Cheat Sheets are a useful reference comprising a series of concise, practical guides on specific security topics. These cheat sheets are handy for quick references on best practices and recommended security measures.

Integrating these OWASP resources into testing methodologies ensures our assessments are thorough, up to date and aligned with global best practices.

Common vulnerabilities in web applications

Web application vulnerabilities can come from insecure design, implementation flaws, misconfigurations, weak access controls, unsafe dependencies, missing validation, and poor assumptions about how users will interact with the system. Blaze's analysis of common penetration testing findings shows that recurring issues often involve identity and authorization issues, sensitive data exposure, insecure configurations, and application-specific logic flaws.

OWASP Top 10 2025 risks in web applications

The OWASP Top 10 provides a useful starting point for understanding the risks most commonly associated with modern web applications.

The OWASP Top 10:2025 provides a useful starting point for understanding the most critical risks associated with modern web applications. For web application penetration testing, it helps security teams and developers prioritize the issues most likely to expose sensitive data, enable account takeover, break tenant isolation, compromise supply chains, or allow attackers to abuse application logic.

• A01:2025 — Broken Access Control: Access control failures remain the top web application security risk. These flaws allow users to act outside their intended permissions, such as viewing another customer's data, modifying another user's records, accessing admin functions, bypassing tenant boundaries, or abusing server-side request forgery paths, now consolidated under this category.
• A02:2025 — Security Misconfiguration: Security misconfiguration moved up in the 2025 list because modern applications rely heavily on configuration across cloud services, containers, APIs, identity providers, frameworks, and deployment pipelines. Common examples include exposed admin panels, verbose error messages, insecure CORS policies, default settings, missing security headers, overly permissive storage, and unnecessary services.
• A03:2025 — Software Supply Chain Failures: This category expands the older "Vulnerable and Outdated Components" risk into a broader supply chain concern. It covers weaknesses in third-party dependencies, open-source packages, build systems, CI/CD workflows, software distribution, package integrity, and dependency trust. In a web app pentest, this means reviewing not only known vulnerable libraries, but also how software artifacts are built, updated, verified, and deployed.
• A04:2025 — Cryptographic Failures: Cryptographic failures occur when sensitive data is not properly protected in transit, at rest, or during processing. Examples include weak encryption, missing TLS protections, insecure key management, predictable tokens, poor password storage, exposed secrets, and sensitive data leakage. These flaws can expose personal information, financial data, credentials, healthcare records, or confidential business information.
• A05:2025 — Injection: Injection vulnerabilities happen when untrusted input is interpreted as a command, query, expression, or executable instruction. This includes SQL injection, NoSQL injection, command injection, LDAP injection, template injection, and cross-site scripting. Attackers can exploit injection flaws to read or modify data, bypass controls, execute commands, or compromise users.
• A06:2025 — Insecure Design: Insecure design refers to weaknesses caused by flawed architecture, missing threat modeling, unsafe assumptions, or business workflows that fail under attack conditions. Examples include bypassable approval flows, weak abuse controls, unsafe trust boundaries, insecure multi-tenant design, and payment or subscription logic that can be manipulated.
• A07:2025 — Authentication Failures: Authentication failures occur when login, session, identity, or account recovery controls are implemented incorrectly. Common examples include weak password reset flows, insecure MFA enforcement, predictable tokens, session fixation, excessive session lifetime, insecure cookies, account enumeration, and authentication bypass in APIs or SSO integrations.
• A08:2025 — Software or Data Integrity Failures: These failures occur when an application does not properly verify the integrity of software, code, updates, data, or trusted workflows. This can affect CI/CD pipelines, signed updates, plugin systems, serialized objects, deployment artifacts, and data imported from external systems. The result can be unauthorized code execution, tampered data, or compromised application behavior.
• A09:2025 — Security Logging and Alerting Failures: Logging without effective alerting is not enough. This category covers missing, incomplete, or ineffective logging and alerting for security-relevant events such as login abuse, privilege changes, suspicious API activity, failed access control checks, data exports, account takeover attempts, and administrative actions. Without proper alerting, attackers can operate longer before detection.
• A10:2025 — Tratamento Inadequado de Condições Excepcionais: Esta nova categoria foca no que acontece quando as aplicações encontram estados anormais, erros, casos extremos, dependências falhas, condições de corrida, entradas inesperadas ou falhas parciais do sistema. Um tratamento de exceções deficiente pode fazer com que as aplicações falhem de forma insegura, exponham informações confidenciais, ignorem verificações de segurança, entrem em estados inseguros ou se comportem de maneira imprevisível sob condições de ataque.

Dependendo do contexto da aplicação, os riscos do OWASP Top 10 2025 podem levar a violações de dados, apropriação de contas, escalonamento de privilégios, falha no isolamento de inquilinos, abuso de pagamentos, interrupção de serviço, comprometimento da cadeia de suprimentos, exposição regulatória e danos à reputação. Compreender estas categorias é um primeiro passo útil, mas um teste de intrusão real em aplicações web deve ir mais longe, identificando vulnerabilidades mais complexas, verificando a sua explorabilidade, avaliando o impacto no negócio e mapeando caminhos de ataque específicos da aplicação.

Ferramentas de teste de intrusão em aplicações web comumente utilizadas

As ferramentas de teste de intrusão desempenham um papel importante nas avaliações de segurança de aplicações web, mas não substituem a análise humana. Elas ajudam os testadores a interceptar pedidos, mapear funcionalidades, descobrir endpoints ocultos, realizar fuzzing de parâmetros, verificar vulnerabilidades e documentar descobertas. Algumas ferramentas populares incluem:

• Burp Suite Professional: Uma ferramenta abrangente de teste de segurança de aplicações web que oferece capacidades de teste automatizadas e manuais. Inclui funcionalidades como proxy de pedidos, análise de tráfego e exploração de vulnerabilidades. Alternativas de código aberto podem ser ZAP e Caido.
• ffuf (Fuzz Faster U Fool): ffuf é um fuzzer web altamente eficiente escrito em Go. É utilizado para descobrir elementos e diretórios num servidor web e é particularmente eficaz para ataques de força bruta a diretórios e nomes de ficheiros em aplicações web.
• Amass: Uma ferramenta avançada para enumeração de subdomínios, útil para descobrir ativos externos associados a uma aplicação web alvo.
• Postman: Comumente utilizado para desenvolvimento de API, Postman também é valioso para explorar e testar APIs em aplicações web, ajudando a identificar vulnerabilidades relacionadas a APIs.
• Aquatone: Uma ferramenta de reconhecimento de domínios que coleta dados visuais de ativos web, oferecendo uma visão geral rápida da superfície de ataque externa de uma aplicação.
• XSStrike: Uma ferramenta especializada na detecção e exploração de vulnerabilidades de Cross-Site Scripting (XSS) em aplicações web. Utiliza técnicas de fuzzing e análise avançada.
• SQLMap: Uma ferramenta de teste de intrusão de código aberto para automatizar a detecção e exploração de vulnerabilidades de injeção de SQL em aplicações web.
• Param Miner: Uma ferramenta para descobrir parâmetros ocultos e não vinculados em aplicações web, o que pode revelar problemas de segurança frequentemente ignorados. Arjun também é uma alternativa ao Param Miner com capacidades semelhantes.

É importante notar que, embora as ferramentas automatizadas possam aprimorar o processo de teste de intrusão ao identificar rapidamente vulnerabilidades comuns, elas ainda não podem substituir a análise detalhada e específica do contexto fornecida por um pentest manual. Uma abordagem equilibrada, combinando testes automatizados e manuais, é essencial para uma avaliação de segurança de aplicações web completa e eficaz.

As certificações certas para pentest de aplicações web

Não faltam certificações de teste de intrusão no mercado, mas apenas algumas focam fortemente em pentest de aplicações web. Ao contratar um fornecedor de testes de intrusão ou investir na capacitação da sua equipe interna com habilidades relevantes de pentest web, certifique-se de verificar as seguintes certificações:

• OffSec Web Expert (OSWE – WEB-300)
• GIAC Web Application Penetration Tester (GWAPT)
• Burp Suite Certified Practitioner (BSCP)
• eLearnSecurity Web Application Penetration Tester Extreme (eWPTX)
• OffSec Web Assessor (OSWA – WEB-200)
• Pentester Lab Pro labs

Qual é a duração média de um projeto de teste de intrusão em aplicações web?

Embora seja possível estimar prazos gerais, a duração específica de um teste de intrusão em uma aplicação web ou SaaS depende muito das características e requisitos únicos da aplicação em questão. Abaixo, detalhamos os prazos mais comuns com base em nossa experiência.

Fatores que influenciam a duração de uma avaliação de pentest em aplicações web:

• Tamanho da aplicação: O número de páginas, funcionalidades, endpoints de API e perfis de usuário impacta diretamente o tempo necessário. Mais elementos significam uma área maior a ser coberta durante os testes.
• Modelo de autenticação: SSO, SAML, OAuth, MFA, SCIM, fluxos de convite e recuperação de conta aumentam o escopo e exigem testes minuciosos.
• Cobertura de API: APIs REST, GraphQL, WebSocket e APIs de suporte a dispositivos móveis adicionam caminhos de teste adicionais.
• Complexidade: Funcionalidades personalizadas, interfaces de usuário sofisticadas e lógica de back-end complexa aumentam o tempo de teste.
• Maturidade de segurança: Aplicações maduras podem exigir testes mais avançados para descobrir falhas de lógica sutis e caminhos de ataque encadeados.
• Integração com serviços de terceiros: Inúmeras integrações (como gateways de pagamento e APIs externas) exigem tempo adicional para avaliar a segurança dessas interações.
• Requisitos regulatórios: Se a aplicação precisar aderir a padrões e estruturas de segurança específicos, como PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, etc., pode ser necessário tempo adicional para avaliá-la minuciosamente de acordo com esses padrões.
• Colaboração do cliente: A velocidade das respostas do cliente a consultas e o fornecimento das informações necessárias também podem afetar o cronograma.

Nota de escopo para aplicações web com IA e LLM

Se a sua aplicação web inclui agentes de IA, fluxos de trabalho baseados em LLM, ações autônomas, geração aumentada por recuperação (RAG), lógica de negócios orientada por prompts ou integrações que permitem que um modelo chame ferramentas ou APIs, defina o escopo desses recursos explicitamente.

Um teste de intrusão (pentest) padrão em aplicações web ainda deve testar autenticação, autorização, APIs, exposição de dados, lógica de negócios e os riscos do OWASP Top 10. No entanto, riscos específicos de LLM, como injeção de prompt, injeção indireta de prompt, vazamento de dados, agência excessiva, uso inseguro de ferramentas e abuso de fluxos de trabalho orientados por modelos, podem exigir um teste de IA ou pentest de LLM.

Para 2026, essa distinção é importante. Muitas aplicações estão adicionando recursos de IA mais rápido do que as equipes de segurança conseguem modelar as novas fronteiras de confiança. Se um fluxo de trabalho de IA puder ler dados confidenciais, acionar ações, consultar sistemas internos, enviar solicitações, resumir registros de clientes ou chamar ferramentas externas, ele deve ser incluído no escopo do teste de segurança.

Preços e orçamento para um pentest de aplicação web

Para muitos escopos de SaaS, APIs e aplicações web, um teste de intrusão em aplicação web geralmente se enquadra na mesma faixa orçamentária que outras avaliações de segurança na camada de aplicação. O guia de custos de testes de intrusão da Blaze explica os principais fatores de precificação que as equipes devem considerar ao planejar o orçamento para um pentest de aplicação web.

Para uma aplicação web pequena, o preço costuma ser menor devido ao escopo limitado. Para uma plataforma SaaS complexa com múltiplas funções, isolamento de inquilinos, SSO, APIs, manipulação de arquivos, faturamento e funcionalidades administrativas, o esforço é significativamente maior.

Ao comparar orçamentos, não avalie apenas o preço. Um pentest de aplicação web de baixo custo pode incluir apenas varredura automatizada e um relatório genérico. Uma avaliação de alta qualidade deve incluir testes manuais, revisão de lógica de negócio, testes de controle de acesso baseado em funções, cobertura de API, prova clara de explorabilidade, orientação prática de remediação e opções de validação de correção.

Uma maneira melhor de avaliar o custo é perguntar:

• Quantos dias de teste estão incluídos?
• O teste cobrirá funcionalidades autenticadas e não autenticadas? Quantas funções de usuário estão incluídas? As APIs estão incluídas?
• A equipe testará a lógica de negócio e o controle de acesso manualmente?
• O reteste está incluído?
• Os resultados serão entregues em um formato que os desenvolvedores possam utilizar?
• O relatório dará suporte a SOC 2, ISO 27001, PCI DSS, HIPAA ou revisões de segurança de clientes?
• Haverá uma reunião de encerramento com as partes interessadas técnicas?

O que esperar de uma avaliação de pentest de aplicação web

Esta lista descreve um processo típico de teste de intrusão em aplicações web e foi projetada para ser acessível e informativa para quem é novo nesse tipo de avaliação de cibersegurança.

1. Consulta inicial e definição de escopo: Antes do início dos testes, espere uma breve discussão para definir o escopo do teste. Isso definirá as expectativas e determinará a melhor abordagem para a avaliação de segurança da aplicação.
2. Fase de reconhecimento: Os testadores coletarão informações sobre sua aplicação, como sua tecnologia e estrutura, para ajudar a planejar a estratégia de teste.
3. Varredura automatizada de vulnerabilidades: A equipe usará ferramentas especializadas para verificar sua aplicação web em busca de vulnerabilidades conhecidas. Esta etapa ajuda a identificar possíveis pontos fracos.
4. Testes manuais e exploração: Além das ferramentas automatizadas, espere testes manuais onde especialistas tentam explorar as vulnerabilidades identificadas. Isso demonstra como um invasor poderia comprometer sua aplicação.
5. Atualizações e comunicação regulares: Durante todo o processo, a equipe de testes manterá você informado, fornecendo atualizações e explicando suas descobertas de forma clara.
6. Relatório abrangente: Após o teste, você receberá um relatório detalhado. Este documento listará as vulnerabilidades identificadas, sua gravidade e o impacto potencial em sua aplicação.
7. Orientação para remediação: O relatório também incluirá recomendações para corrigir as vulnerabilidades. Essas sugestões serão práticas e priorizadas com base no risco.
8. Reunião de encerramento pós-pentest: Frequentemente, a equipe de testes oferecerá uma sessão de encerramento para revisar as descobertas, responder às suas perguntas e discutir os próximos passos para proteger sua aplicação.
9. Validação de correções: Após corrigir as vulnerabilidades, você pode ter a opção de realizar um novo teste para garantir que as ações de remediação foram eficazes.

Considerações finais

O teste de penetração em aplicações web é uma das formas mais práticas de avaliar a resiliência da sua aplicação contra ataques reais. Ele ajuda a identificar vulnerabilidades que scanners não detectam, valida se os controles de segurança funcionam como esperado e fornece às equipes de engenharia prioridades claras de remediação.

Para empresas de SaaS e organizações que dependem de aplicações web, um pentest de alta qualidade pode apoiar a conformidade, vendas corporativas, confiança do cliente e redução de riscos. Os melhores resultados vêm de uma metodologia estruturada, contas de teste realistas, um escopo claro, comunicação eficiente e testes manuais focados na lógica de negócios real da aplicação.

Se sua organização precisa de um teste de penetração em aplicação web para um produto SaaS, portal do cliente, plataforma baseada em API, requisito de conformidade ou revisão de segurança corporativa, a Blaze Information Security pode ajudar você a definir o escopo da avaliação e identificar o nível de teste que se ajusta ao seu perfil de risco.

Perguntas frequentes

O que é teste de penetração em aplicações web?

O teste de penetração em aplicações web é uma avaliação de segurança manual que simula ataques reais contra uma aplicação web para identificar vulnerabilidades exploráveis. Ele testa áreas como autenticação, autorização, gerenciamento de sessão, lógica de negócios, APIs, validação de entrada e os riscos do OWASP Top 10.

Quanto tempo leva um teste de penetração em aplicação web?

Um teste de penetração típico em aplicação web leva de 5 a 15 dias úteis. Aplicações menores podem levar cerca de uma semana, enquanto plataformas SaaS complexas com múltiplas funções, APIs, integrações e fluxos de trabalho sensíveis podem levar várias semanas.

O teste de segurança de aplicações web pode ser automatizado?

Parcialmente, sim. Scanners e ferramentas automatizadas desempenham um papel na segurança de aplicações web. No entanto, não devem ser vistos como um substituto para o pentest manual.

Aplicações internas devem passar por pentest?

Sim. Aplicações internas devem ser testadas quando lidam com dados sensíveis, suportam fluxos de trabalho críticos ou podem ser exploradas por usuários internos ou atacantes que já obtiveram acesso à rede. Interno não significa seguro.

Qual é a diferença entre varredura de vulnerabilidades e pentest de aplicações web?

A varredura de vulnerabilidades utiliza ferramentas automatizadas para identificar problemas potenciais. O pentest de aplicações web verifica manualmente as vulnerabilidades, testa a explorabilidade, avalia o impacto nos negócios e encontra falhas de lógica que scanners automatizados frequentemente deixam passar.

O teste de segurança de aplicações web pode ser automatizado?

Parcialmente, sim. Scanners automatizados podem identificar problemas comuns, como cabeçalhos ausentes, componentes desatualizados, arquivos expostos e alguns padrões de injeção. No entanto, eles não podem substituir o teste de penetração manual para lógica de negócios, fluxos de autenticação e autorização, isolamento de tenant ou caminhos de ataque encadeados.

Qual é a metodologia OWASP para testes de penetração em aplicações web?

O Guia de Testes de Segurança Web da OWASP fornece uma metodologia estruturada para testar aplicações web e serviços web. Ele abrange áreas como coleta de informações, configuração, gerenciamento de identidade, autenticação, autorização, gerenciamento de sessão, validação de entrada, tratamento de erros, criptografia, lógica de negócios, testes do lado do cliente e testes de API.

Com que frequência uma aplicação web deve passar por um pentest?

A maioria das organizações deve realizar um teste de penetração em aplicações web pelo menos anualmente e após grandes mudanças. Aplicações SaaS, fintechs, de saúde e de pagamento de alto risco podem precisar de testes mais frequentes, especialmente após alterações em autenticação, autorização, APIs, pagamentos ou isolamento de tenant.

O que devo fornecer antes do início de um pentest de aplicação web?

Você deve fornecer URLs da aplicação, limites do escopo, contas de teste para cada função, documentação da API, dados de teste, contexto da arquitetura, fluxos de trabalho principais, restrições conhecidas e um canal de comunicação para dúvidas e descobertas urgentes.