The fact that a document opened once was not enough to decide on the replacement. In the HTML5 migration of internet banking document viewer, company N, the main flows were checked per browser and operating system, and the scope confirmed and the risk remaining were consolidated into a release decision document.
Viewing a document looks simple. When the file opens and the content appears, it feels finished. In real work, however, reading on screen is followed by printing or saving, and those flows are needed too.
Internet banking document viewer, company N, was replacing its existing viewer with an HTML5-based one and preparing for release. Because document rendering and the actions that follow can change with the browser and operating system combination, evidence was needed that could explain which environments had been checked and for what.
The goal of this review, carried out in 2025, was not to offer vague reassurance. It was to make it possible for the release meeting to review the facts confirmed and the conditions not yet confirmed side by side.
Before testing began, the release target was fixed
While development continues, the object of verification tends to change as well. If the file checked first and the file actually released differ, the first question becomes whether the earlier results still apply at all.
This project started after the scope had been agreed in writing against a single release-candidate build. That keeps it clear which target the review results are a judgment about.
Fixing the scope does not mean prohibiting change. It is there to explain the conditions under which the results apply. When the target changes, it has to be possible to separate what was confirmed earlier from what has to be confirmed anew.
In a pre-release review, clarity about the target matters as much as the schedule. If "it was tested" comes without the information of which build was checked, the relationship between the deliverable actually being released and the verification record goes blurry.
Rendering, print, and save were examined together with the environment combinations
The critical flows were set as document rendering, print, and save. Each flow was run in the agreed browser and operating system combinations.
Keeping a list of functions and a list of environments separately is not enough. Only by connecting which function was run in which environment can the missing combinations be found.
That a document opens correctly in one environment, for example, says nothing about the print result in another. Conversely, no matter how many environments are prepared, if the only action actually confirmed is opening a document, the depth of the review is limited. This is why functions and environments are looked at together.
In this project too, defects were recorded on the basis of the scenario results for each combination. The severity of each problem and the conditions under which it occurred were kept together so that the order of fixes could be discussed.
The excluded scope was recorded as part of the result
Not every environment can be checked to the same depth. Within a limited schedule, it has to be decided which combinations and actions to verify first.
The project recorded the environments and flows that were not checked as exclusions. Instead of showing only the items that passed in the results document, the parts the judgment did not reach were recorded alongside them.
That something could not be checked does not mean it failed. Nor does it mean it was confirmed to be free of problems. Keeping these two apart is what stops a reader of the verification results from adding assumptions of their own.
When the review scope is clear, the operations team can also interpret the results more accurately. When a question comes in after release, there is a starting point for confirming whether that environment was already examined or was outside the verification target at the time.
Requesting a fix and confirming a fix were kept separate
Receiving word that a defect has been fixed after handing it over, and running the corrected result to confirm it yourself, are different steps.
In the company N project, the fixes went through one round of re-verification. On top of the initial findings, there was a step that reviewed the results after the fixes.
Re-verification, too, has to be read within the scope and conditions of the fixes that were checked. Confirming that one problem was improved cannot be taken as confirming every other environment or any later change.
What matters is whether the record describes the final state of the review. If only the initial defect list or only the fix requests survive, what was resolved and what remained at release time has to be traced all over again.
The final deliverable was a release memo that gathered the basis for the decision
The verification results, the exclusions, the assumptions behind the verdict, and the residual risk were consolidated into a release memo. The results were reviewed within a decision framework that distinguishes ready, ready with conditions, and hold, and the process included a person in charge signing off.
What this case emphasizes is not the name of a particular verdict but a structure that can explain the verdict. Which environments were examined, what was not checked, and on what assumptions the judgment was made all have to be in the same document.
Reviewing a document viewer is also distinct from certifying the security of the financial service as a whole or every operating condition. It is the work of delivering the results of what was run within the agreed target and scope.
As important as changing the technology to HTML5 was establishing the grounds for releasing that change. This project turned a report of "it works" into a record that can explain how far the checks went and on what assumptions the judgment was made.
