Key takeaways
The short version
- Include informal senior support when reviewing the effort spent on an engagement.
- Record the cause of extra work so a clarification request is not automatically counted as a defect.
- Use review records to distinguish correction time from time spent waiting.
- Agree the treatment of additional scope before undertaking it.
The tester finishes the booked days on a fixed-price application test. On paper, the engagement looks close to plan. Then a senior consultant spends an extra half day helping with the report, and a delivery manager spends two hours resolving a disagreement. The quote allowed for reporting and review, but not all of that extra work.
Those figures are illustrative. They show how easily a project can cost more than the assigned tester’s timesheet suggests.
To work out which parts were avoidable, the team first needs to see where the extra time went.
Where the additional work begins
In this example, the proposal includes testing two user roles. Only one account works when the test starts. The access request named the roles, but nobody confirmed that the accounts had been checked in the test environment.
The tester spends time investigating the failure. The delivery manager contacts the client, and both sides need to agree which work can proceed. Once the second account arrives, the tester revisits a workflow they could only partly assess earlier.
An access failure can happen despite reasonable preparation. Here, the missing confirmation is something the team can address. Assigning responsibility for checking the prerequisites before the start would give the client time to resolve the problem or agree a change to the dates.
The scoping article covers the information needed to make that decision. The commercial consequence in this example is time spent handling a dependency that the price assumed would already be resolved.
The tester records a genuine weakness, but the finding does not identify the permissions of the account used. The reviewer cannot tell whether the behaviour crossed an access boundary, so they return it for clarification.
The paragraph might take the tester twenty minutes to fix. Around that sit the reviewer’s time finding the omission and checking the revision against the evidence. If the evidence is no longer available, someone may also have to arrange access again.
Suppose the report passes through three review cycles instead of the one allowed for in the quote. Record the work done in those cycles, including any senior rewrite. Also record where the report waited for someone to respond. Waiting affects the delivery date, but it should not be counted as labour unless someone was actually working or blocked from assigned work.
OWASP’s reporting guidance describes reports that technical and executive audiences can understand. Applying that guidance during drafting helps reviewers assess the finding without reconstructing the engagement from scattered notes.
The debrief reopens the explanation
The client challenges the severity because the report does not explain a condition required for exploitation. A senior consultant joins another call and reviews the finding with the tester. This is where the illustrative extra half day could be spent, including preparation and amendments.
The client may have useful information, and some follow-up is part of the service. The cost becomes avoidable where the report omitted information already known during testing, or where nobody recorded an earlier decision.
It helps to keep those causes separate. New information from the client deserves an evidence review. A tester who cannot explain a conclusion may need coaching. Extra test coverage needs a scope decision. Calling all of it poor communication would make it harder to choose a useful response.
Account for the whole engagement
Use the project record to bring the extra work together. Include support given informally by senior testers and work done after report issue. Apply the business’s normal cost assumptions consistently when assessing margin.
| Additional work | Record needed |
|---|---|
| Access clarification | Time spent, dependency missing and when it became known |
| QA correction | Material defect, correction time and reviewer effort |
| Client discussion | Reason for the discussion and whether it changed the assessment |
| Work beyond the agreed scope | The request, approval and any agreed fee or schedule change |
Avoid counting the same work under several categories. The purpose is to understand the engagement’s actual effort and which decisions created it.
That extra half day costs the business something even if there is no additional invoice. Absorbing it may be a sensible commercial choice for the agreement or account. Knowing what you are absorbing lets you make that choice deliberately.
Change the point that caused the repeated cost
Review a sample of completed engagements before choosing a response. If missing access repeatedly creates additional setup work, improve the readiness check. If reports repeatedly omit preconditions, use those defects in drafting guidance and coaching.
After making a change, compare the relevant work on later engagements. Read the figures alongside differences in scope and complexity. The team performance framework defines measures for unplanned recovery work and senior intervention that can support this review.
For our example, I would start with an account check before testing and a check that the report explains the access conditions. The next project record can show whether those changes helped, including the time spent by people who were never assigned as the tester.
Explore further
Sources and further reading
These references add context to the points linked in the article. The practical recommendations are Simon's guidance unless another source is named.
- Web Security Testing Guide: Reporting — OWASP Foundation


