Web application penetration testing

Why a web application penetration test is commissioned and what it answers

A web application penetration test is a manual, scoped assessment in which a tester attacks a running application the way a motivated adversary would, then reports what an attacker could actually reach. Commissioning one usually follows a requirement: a compliance framework such as PCI DSS requirement 11.4.1, a customer security questionnaire, a product launch sign-off or an insurer's conditions. The test establishes whether the application's controls hold under deliberate misuse, and it produces evidence that the controls were checked against a named method rather than assumed. Before you commission one, confirm which requirement or stakeholder is asking, because that decides the depth, the authentication roles and the format of the report.

The work is mapped to the categories of the OWASP Web Security Testing Guide (WSTG) and to the OWASP Top 10 2025, so every finding can be traced to a recognized weakness class. For most applications the questions that matter are whether a user can reach another tenant's records (A01 Broken Access Control), whether login, session and recovery flows can be subverted (A07 Authentication Failures), whether user input can alter queries or rendered output (A05 Injection), and whether a workflow can be completed in a way the designers never intended (A06 Insecure Design). Business logic is the category most often missed, because a correct-looking request can still produce an incorrect outcome, such as applying a discount twice or skipping a payment step.

Scanners alone do not provide this coverage. Automated tools find known signatures and some injection patterns, but they cannot judge whether one user should see another user's data or whether a sequence of valid steps breaks a rule. The ASVS 5.0.0 guidance says that automated DAST and SAST tools cannot fully verify many requirements, especially business logic and access control. Ask the provider how it will combine scanning with manual testing, which roles and test accounts it will use, and whether it will receive design documents or an API specification. Those answers determine whether the report will answer the question you were asked.

What can be in scope for a web application penetration test

Scope decides what the tester can reach, which roles they can act as, and how hard they can push without harming your services. Agree each of these decisions in writing before testing starts, because they determine what the final report can and cannot claim.

Applications and hostnames

List every hostname, subdomain and application the test covers, including staging and pre-production copies that share code or data with production. Confirm which front ends, admin consoles and partner portals are in, and which are excluded because a third party hosts them. Unlisted hosts are a common source of gaps, so ask for an inventory from the asset owner and reconcile it against what the tester discovers.

APIs and backend services

Decide whether the REST, GraphQL, SOAP or internal APIs behind the front end are in scope, and whether they are tested directly or only through the browser. Ask for the API specification or schema, if one exists, and confirm whether undocumented endpoints are included. An API that is reachable from the internet but absent from the web test plan is a frequent finding in later reviews.

User roles and test accounts

Specify which roles the tester needs, such as anonymous visitor, standard customer, supplier, support agent and administrator. Provide one dedicated test account per role with realistic data permissions, and confirm whether multi-tenant boundaries need two accounts per role. Authorization findings depend on comparing what one role can reach with what another role should be able to reach.

Authenticated or unauthenticated coverage

Choose whether the test runs as an unauthenticated visitor, as authenticated users, or both. An unauthenticated test shows what an outsider can reach, while an authenticated test is needed to find flaws in workflows, object access and business logic. For critical applications, the CIS Controls treat authenticated testing as better suited to business logic flaws, so ask the provider to justify any choice that leaves it out.

Testing windows and rate limits

Set the testing windows, the maximum request rate, and which activities are off limits, such as denial-of-service checks, bulk account creation or mass email sends. Agree who on your side can pause the test and how to reach them out of hours. Rate limits matter because the tester must check resource consumption controls without degrading service for real customers.

Data handling and third-party components

Define how the tester may handle personal and payment data they encounter, where evidence is stored, and how it is deleted after reporting. Identify third-party services such as payment processors, identity providers and content delivery networks, and confirm that you have authority to test your side of each integration. Testing a provider's infrastructure without permission can breach contracts and provider testing rules.

How a manual web app test runs from scoping to retest

The sequence turns a written scope into validated findings, a report the client can act on, and a retest that confirms fixes. Each phase has a defined output so the client knows when it is complete.

Agree scope and rules of engagement
The client and DeployOpen define the application, environments, hostnames, user roles, testing windows and out-of-bounds functions, then record them in a written scope before any testing starts. The client confirms who is authorized to approve testing, who receives alerts during the test and which third-party services must not be touched. The step is complete when the signed scope lists every in-scope asset and the agreed test type, and the client has confirmed the expected timing in that document.
Review documentation and architecture
The tester reviews the material the client supplies, such as architecture diagrams, API specifications, authentication design, data flow descriptions and previous test reports. This shows which components handle authentication, authorization and payment functions, and where the application exposes undocumented endpoints. The step closes with a short test plan that maps planned activities to WSTG v4.2 categories and to the OWASP Top 10 2025 items most relevant to the application. Where the client needs requirement-level verification, the plan also records which OWASP ASVS 5.0.0 chapters apply and at which verification level.
Set up test accounts and roles
The client provisions test accounts in a non-production or agreed environment, usually one for each role the application defines, such as anonymous, standard user, administrator and any role tied to payments or regulated data. The tester confirms that each account can reach the functions its role should reach, and that the client has logged the accounts and their expiry. Authenticated coverage depends on this step, because access control and business logic flaws only appear when the tester can compare what different roles are allowed to do. The step is complete when the client confirms the account list in writing.
Test manually against WSTG categories
Testers work through the WSTG v4.2 categories, covering information gathering, configuration and deployment management, identity management, authentication, authorization, session management, input validation, error handling, weak cryptography, business logic, client-side testing and API testing. Automated tools support discovery, but the findings depend on manual analysis of how the application behaves under the test roles. Testers record each test case, its result and the evidence needed to reproduce a finding. The step closes when every planned category has a recorded outcome, including categories that were not applicable and the reason why.
Validate and rate findings
Each candidate issue is checked to confirm it is real, that it affects the application as deployed, and that the impact is understood in the client's context. The tester maps confirmed findings to the OWASP Top 10 2025 category and to the relevant WSTG test, and assigns a severity based on the agreed rating method. Duplicates, false positives and issues caused by the test environment are removed. The step is complete when each finding has a reproducible description and a clear status, and the tester has reviewed the list for consistency.
Deliver the report and debrief
The client receives a written report that describes the scope, method, test accounts used (without credentials), findings with reproduction steps at a level a developer can act on, and remediation guidance. Where ASVS was in scope, the report also lists the requirements checked, the requirements with exceptions and those that do not apply, because ASVS verification reports differ from a traditional list of issues. A debrief walks the engineering and security teams through the findings. The step closes when the client confirms receipt and the report is accepted under the terms of the written scope.
Retest fixes and close findings
After the client applies fixes, the tester repeats the relevant checks on the changed components and records whether each finding is resolved, partially resolved or still open. The retest scope is agreed in writing, so the client knows whether it covers only the original findings or includes any new code. The client confirms which fixes it has deployed and when, and the tester's retest note is added to the report record. Ask the provider how retest is priced and whether it is included in the original fixed-scope quote.

What authenticated versus unauthenticated coverage means

Unauthenticated testing shows what an anonymous visitor can reach, meaning public pages, login and registration forms, password reset endpoints, public APIs and anything exposed without a session. It finds misconfigurations, exposed administrative paths, verbose errors and injection points reachable before anyone signs in. It does not show what a logged-in customer, a support agent or an administrator can do once inside, and that is where most access control and business logic risk sits. Treat an unauthenticated-only result as a view of the outer edge, not of the application.

Authenticated testing covers each role's functions and data. CIS Controls v8.1 Safeguard 16.13 notes that for critical applications, authenticated testing is better suited than automated scanning to finding business logic vulnerabilities, and it expects testers to act as both authenticated and unauthenticated users. OWASP Top 10 2025 A01 Broken Access Control usually needs several roles because the flaw is a difference between roles: a standard customer should not read another customer's records, and a regional manager should not approve actions reserved for head office. A single test account rarely proves either boundary. Ask the provider which roles, tenants and privilege levels they will test, and whether each role is tested against the others' objects and functions.

The client has to supply the accounts and the context. Ask for a test account per role, with a written list of what each can do, plus any second tenant or organization needed to test cross-tenant access. Confirm how multi-factor authentication, one-time codes and CAPTCHA will be handled for test accounts, and whether the test environment mirrors production roles and data. Documentation such as role matrices and API references shortens the time testers spend discovering functions, and ASVS 5.0.0 encourages documentation-led testing over blind testing for this reason. Agree in writing how test data is created and removed, because authenticated tests change state and the client must know what will be modified.

Which weakness categories the test looks for and why they matter

This table maps each OWASP Top 10 2025 category to what it looks like in a web application, the WSTG test areas that cover it and why it matters to the buyer. Use it to check that the scope you agree covers the risks your auditor, customer or framework cares about.

Weakness category	What it looks like in a web app	WSTG areas and why it matters
A01 Broken access control	Users reach records, pages or functions they should not, such as another customer's account data or admin screens reachable by a standard role.	Authorization and session management. Top risk for multi-tenant and payment applications, and one scanners often miss without test accounts at several privilege levels.
A02 Security misconfiguration	Debug modes left on, default settings, verbose error pages, permissive CORS or headers missing on sensitive pages.	Configuration and deployment management, error handling. Usually found across environments, so scope should name staging and production if both are in use.
A03 Software supply chain failures	Vulnerable or unmaintained third-party components, build pipeline weaknesses or unverified packages loaded into the application.	Client-side testing and configuration review. A web test can identify exposed components; full dependency and pipeline review is a separate code and supply chain scope.
A04 Cryptographic failures	Sensitive data sent or stored without adequate protection, weak TLS settings, outdated algorithms or secrets exposed in responses.	Weak cryptography, configuration and deployment management. Affects regulated data handling and is often a direct requirement in framework checklists.
A05 Injection	User input reaches an interpreter such as a database query, operating system command, template or script without proper handling.	Input validation. Still a high-impact category; confirm whether the test covers all input channels, including headers, file uploads and API parameters.
A06 Insecure design	Flows that lack a safe design, such as no limit on password attempts, unsafe account recovery logic or trust placed in client-supplied prices.	Business logic testing. Scanners rarely find these, so the test needs documentation, workflow walkthroughs and authenticated testing of multi-step processes.
A07 Authentication failures	Weak login controls, MFA that can be bypassed, session tokens that persist after logout or unsafe password reset flows.	Identity management, authentication, session management. For identity provider changes or SSO, consider a focused authentication test in addition to this scope.
A08 Software or data integrity failures	Unsigned updates, unverified scripts loaded from third parties, or serialized data trusted without integrity checks.	Client-side testing and business logic. For payment pages, script integrity and change detection are specific compliance expectations to confirm in scope.
A09 Security logging and alerting failures	Security-relevant events such as failed logins or access denials are not recorded, or logs expose sensitive values.	Error handling and business logic review. Testers can show which events are visible in the application, but full monitoring assurance needs access to logs and alerting.
A10 Mishandling of exceptional conditions	Errors expose stack traces, fail open on timeouts or leave partial transactions in an inconsistent state after failure.	Error handling and business logic. Often linked to A01 and A06 findings, so testers should check how failures behave in payment and account flows.

How web app testing changes by architecture

When a single-page application (SPA) talks to a separate API, the browser client is only part of the attack surface. Much of the logic, authorization decisions and data exposure sit in the API, so the test scope usually covers both, and the two need to be scoped together. The client-side code is also a source of findings, including exposed secrets, trust placed in hidden controls and client-enforced checks that the server never repeats.

Scope boundary: Agree whether the API is tested as part of the web engagement or as a separate REST or GraphQL test, and record every host and base path.
Accounts: Provide at least two test users at the same privilege level plus one with elevated rights, so object and function level checks are possible.
Coverage: Client-side review tests what the bundle reveals, while server-side checks depend on authenticated API calls that the tester can repeat.
Client needs: A current route list, an API specification if one exists, and a way to obtain tokens for each test role.
Dependencies: Identify third-party identity providers and whether they are in scope.

Ask the tester how client-side and server-side findings will be separated in the report, and whether API-specific testing will follow the REST API security testing approach or a separate engagement.

Which compliance frameworks expect web application penetration testing

This table maps the frameworks and verification standards that most often shape a web application test, with the evidence each expects. Read it to decide which requirement sets your test must satisfy, then confirm the exact scope with your assessor before work starts. The main takeaway is that a single test rarely satisfies every framework, so the scope and report format should be agreed against the requirement you need to meet.

Framework or standard	What it expects for web applications	Evidence to ask for and points to confirm
PCI DSS v4.x requirement 11.4.1	Application-layer penetration testing that finds, at minimum, the vulnerabilities listed in requirement 6.2.4, including business logic abuse through API, client-side or feature manipulation	Written scope naming in-scope payment applications, a methodology, and findings mapped to 6.2.4 categories; confirm with the assessor which applications count as in scope
PCI DSS requirement 6.4.2 (replaced 6.4.1 on 31 March 2025)	An automated technical solution in front of public-facing web applications that detects and prevents web-based attacks; the earlier 6.4.1 review of public apps is superseded	Evidence the solution is deployed and configured for each public app; a penetration test alone does not satisfy this requirement, so confirm the control with your assessor
OWASP ASVS 5.0.0 (verification basis)	A requirement-by-requirement basis across 17 chapters, usually verified at Level 1 first and raised to Level 2 or 3 by risk	A verification report listing scope, all requirements checked, exceptions with guidance, and requirements marked not applicable
OWASP certification status	OWASP does not certify vendors, verifiers or software, so no vendor can claim an official OWASP ASVS certification	Ask providers to show their own method and report structure, not an OWASP seal; treat any unofficial ASVS trust mark with caution
CREST OWASP Verification Standard (OVS) accreditation	Accreditation of testing organizations to run web application assessments against ASVS at Levels 1 and 2, announced 28 October 2022	Ask whether the provider holds OVS accreditation for the ASVS levels you need and verify it on the CREST register
CIS Controls v8.1 Safeguard 16.13	Application penetration testing, with authenticated testing preferred for critical applications to find business logic flaws	Test accounts for each role, testers acting as authenticated and unauthenticated users, and business logic findings in the report

What the client receives and whether an auditor will accept it

A web application penetration test report is only as useful as its fit with the reader who asked for it. The cards below cover what a well-scoped report contains, how it differs from a verification report under ASVS 5.0.0, and what to confirm before the work starts.

Executive summary and scope

The summary states the overall risk picture in plain language for leadership, and the scope section records the exact hostnames, versions, user roles and test windows covered. It also records what was excluded, such as third-party services or production-only functions. Ask for the scope statement to be signed off before testing starts, because an auditor will check whether the tested surface matches the in-scope application.

Methodology mapped to WSTG

The methodology section shows which test categories were run, mapped to the WSTG v4.2 categories and the OWASP Top 10 2025. It states whether testing was unauthenticated, authenticated by role, or documentation-led, since that changes the depth of coverage. Ask for a table of categories tested, categories not applicable and the reason for each exclusion.

Findings with severity and evidence

Each finding carries a severity rating, the affected component, the weakness category and the evidence that confirmed it. Evidence should show what the tester observed without including attack payloads that could be reused against production. Ask how severity is calculated, for example whether the scheme is CVSS or a documented internal matrix, and whether business impact is considered.

Defensive reproduction steps

Reproduction steps describe the condition that was tested and the observable result, written so your engineers can verify the fix without receiving a working exploit. Good reports separate the defect from the proof, which keeps sensitive material out of tickets and shared drives. Confirm with your provider how reproduction material is stored, who can access it, and when it is deleted.

Verification report versus issues by exception

ASVS 5.0.0 notes that traditional penetration test reports list issues by exception, while a verification report should cover the scope, a summary of all requirements checked, the requirements with exceptions and guidance on resolving them, and any requirements that do not apply. If your auditor or a customer expects ASVS evidence, ask for this structure in the contract. A customer or auditor letter describing the test may also be requested, and that letter should be agreed with the provider in advance.

Retest results and acceptance

The retest section records each original finding as fixed, partly fixed or still open, with the date and version of the retested build. Ask whether retesting is included in the fixed-scope price or priced separately, and how many rounds are covered. Auditors generally expect the retest evidence to sit alongside the original report, so keep both under the same engagement reference.

What the client prepares before testing starts

Before a web application penetration test starts, the client must name the people who make decisions during the test. Name a technical contact who can answer questions about the application's architecture, a security contact who can accept or reject testing actions, and an operations contact who can stop traffic or restore a service. The escalation path for critical findings matters most here: agree in writing who receives a critical issue, how quickly they are reached outside business hours, and who decides whether testing pauses. Confirm these names and the escalation steps in the written scope, because a tester who finds an authentication bypass on a Friday evening needs a person to call, not a shared inbox.

Testing a web application or API properly depends on test accounts. Provide one account for each role the application defines, such as an anonymous visitor, a standard customer, a delegated administrator and a tenant or organization owner where multi-tenancy exists. Agree in advance what data those accounts may create, modify and delete, and whether the test data is seeded in a staging copy that mirrors production. For API testing, supply the current OpenAPI or other interface documentation, or grant source code access where the scope calls for documentation-led testing. Confirm with the engineering team which endpoints exist but are not documented, because the tester will ask about them. Also confirm the environment: the test target must be available for the agreed windows, with a known version and build that matches what will be deployed.

Network and governance steps can block a test as easily as a missing account. If the environment sits behind a web application firewall, a content delivery network or a bot filter, decide with the operations team whether the tester's source IP addresses are allowlisted, rate-limited separately, or tested through the same controls production traffic uses. Record change freeze windows so that no release lands during the test, and confirm that third parties are approved in writing. Cloud hosting providers, SaaS identity providers, payment processors and managed API gateways may each have their own testing rules, so check each one before the test window is booked. Finally, confirm with your own legal or procurement team who signs the rules of engagement. Your scope document should record every item in this section, and it is the written scope that binds both sides.

What to check when choosing a web app testing provider

Choosing a provider for a web application test is mostly a question of evidence: what method they follow, who actually runs the test, and what you receive at the end. The cards below cover the questions worth putting in writing before you sign, so the scope, the report and the retest terms can be checked against your auditor's or customer's expectations.

Methodology mapped to WSTG and ASVS

Ask which WSTG categories the test covers and whether the provider can map each finding to a WSTG test case and, if you need assurance against a verification standard, to ASVS requirements. A vague claim of following OWASP is not enough. Ask whether the test is documentation-led or source-assisted, since ASVS 5.0.0 favors hybrid testing and notes that automated tools cannot fully verify business logic or access control. Also ask which requirements the provider will not test and why.

Named tester qualifications and independence

Ask who will test your application, not only who sold the engagement. Request named testers, their relevant experience with web and API testing, and any recognized qualifications they hold. Confirm the testers are independent of the team that built or operates the application, and that they will not also be running your remediation work without disclosure. Write these answers into the contract so a change of tester requires your approval.

CREST OVS accreditation

Ask whether the provider holds CREST accreditation under the OWASP Verification Standard. CREST announced the scheme on 28 October 2022, and it assesses whether a testing organization can run ASVS-based web assessments at Levels 1 and 2. Accreditation is a useful signal but not a substitute for the scope and methodology review above. If you do not need an OVS-accredited test, ask the provider to explain its own quality controls for ASVS work.

Sample report, redacted

Ask for a redacted sample report from a comparable engagement before you commit. Check whether it lists each finding with reproduction steps at a defensive level, a severity rationale, affected components and remediation guidance, and whether it summarizes the requirements tested as well as the exceptions. If you need an ASVS-style verification report, confirm the provider produces one, since a traditional penetration test report lists issues by exception only.

Retest terms in writing

Ask whether retesting is included, how many retest rounds apply, and within what window after the final report. Confirm whether the retest covers only the reported findings or also the regressions a fix might introduce. Agree in advance how a finding that the client disputes will be handled, and whether the retest result is documented in a form your auditor or customer can read. Fees and timing should appear in the written scope, not in an email.

Data handling and test credentials

Ask how the provider stores findings, screenshots, test credentials and any production data encountered during testing. Confirm encryption in transit and at rest, who can access the working files, the retention period, and how and when data is destroyed at the end. Agree in writing which test accounts are created, how they are removed afterward, and whether any production data may be accessed at all.

Insurance and a written scope

Ask for evidence of professional indemnity and public liability insurance and check that the cover amounts match the risk of testing a live system. Then confirm the scope is written and signed before work starts. The scope should name the target URLs, APIs, roles, environments, testing windows, excluded functions and the testing rules for any third-party components. A scope that lives only in a proposal is hard to enforce if the test causes an outage.

Common questions about web application penetration testing cost and effort

What does a web application penetration test cost and what drives the quote?

The quote follows from the written scope, and DeployOpen does not publish a price list. The main cost components are the tester's time for planning, manual testing, validation and reporting, plus any retest rounds. The size and number of applications, the number of roles and user journeys to test, the count of API endpoints, whether the test is authenticated, and how much documentation or source code the tester receives all move the effort up or down. Ask for a quote that itemizes effort by application and role, states what is one-time and what recurs, and names the retest terms.

How long does a web application penetration test take?

Duration depends on the scope you agree in writing, so there is no fixed timeline that applies to every application. The largest factors are the number of user roles, the breadth of the API surface, the complexity of business workflows such as checkout or account changes, and how quickly test accounts and environments are ready. Ask the provider to separate preparation, testing windows, reporting and the client review period so you can see where delays would come from.

What must our team supply before testing starts?

Testing goes faster and covers more ground when the client prepares the inputs up front. Typical items to confirm with the provider are:

A staging or test environment that mirrors production controls
Test accounts for each role, with the permissions they should hold
API documentation, OpenAPI or GraphQL schemas, and architecture notes
Named technical contacts and an agreed testing window
Rules of engagement covering rate limits, data handling and third-party services

If the test is documentation-led, ask what additional source or configuration access the tester needs.

Can our internal security staff run the web application penetration test?

Internal staff can run useful checks, including scanning and regression testing, but an independent penetration test is usually performed by a separate team so that findings are not shaped by the people who built the application. Internal teams often lack the time or the independence that a compliance assessor or customer review expects. Before deciding, confirm the testers' skills in authenticated business logic testing and whether their report will meet the evidence your auditor or customer asks for. DeployOpen performs these tests as a fixed-scope service, and the written scope sets who does what.

How is retesting priced after the first report?

Retesting is usually a separate, scoped piece of work that checks whether the fixes for earlier findings work. Its cost depends on how many findings need verification, how many applications and roles are affected, and whether the fixes change the attack surface enough to need new manual testing. Ask the provider whether retest rounds are included or quoted separately, how long the window for fixes runs, and whether a retest report will list each finding as closed, open or partially addressed. Ongoing retainers are also available if you need recurring testing.

Does a web application penetration test satisfy PCI DSS requirement 11.4.1?

Requirement 11.4.1 of PCI DSS v4.x requires application-layer penetration testing that covers, at a minimum, the vulnerabilities listed in requirement 6.2.4, including business logic abuse through API manipulation and client-side functionality. A test satisfies the requirement only when its scope, method and tester qualifications match what the standard asks for and your assessor accepts the evidence. Confirm the scope with your Qualified Security Assessor before testing, because the assessor makes the compliance judgment and DeployOpen does not issue attestations or certifications.

Is a scanner report enough instead of a manual penetration test?

No, a scanner report alone is generally not enough when you need evidence of business logic or access control testing. The CIS Controls v8.1 Safeguard 16.13 notes that, for critical applications, authenticated penetration testing is better suited than automated code scanning to finding business logic flaws. ASVS 5.0.0 also states that automated DAST and SAST tools cannot fully verify many requirements, especially on business logic and access control. Scanners are useful for continuous coverage, and a manual test adds validated findings, context and a reasoned account of what was checked.

How DeployOpen scopes, tests, reports and retests web applications

DeployOpen is a Chainscore Labs company that runs security testing of web applications and APIs, with engagements agreed in a written, fixed scope before work starts. The steps below show how a manual web application penetration test is scoped, built, tested, documented and handed over, and how retesting and ongoing support fit in.

How we scope

Agree in writing which applications, hosts, APIs and user roles the test covers before any testing begins.
Confirm whether testing is authenticated, unauthenticated or both, and which test accounts and roles the client provides.
Record what is out of bounds, including production data handling, rate limits and any third-party services the application depends on.

How we build

Map each test activity to the relevant WSTG categories and to the OWASP Top 10 2025 items that apply to the application.
Use the client's architecture notes, API specifications and documentation where available, and confirm gaps with the client's engineers.
Combine automated tooling for coverage with manual testing of access control, business logic and multi-step workflows.

How we hand over

Deliver a written report that lists each finding with its affected component, evidence, risk rating and a fix recommendation.
Document the tested scope, the test approach and any areas not tested, so the client can explain coverage to its auditor or customer.
Walk the client's engineering and security teams through findings and agree a retest scope for the fixes.

How we support

Retest agreed findings after remediation and record the status of each one in an updated report.
Offer ongoing support, upgrades and continuous testing as a retainer once the initial engagement is complete.
Confirm with the client which compliance framework, such as PCI DSS or ASVS, the test should evidence before scoping begins.