A newsroom where writers, approvers, and readers each use a different screen. Ahead of company P's launch, we reviewed drafting, approval, publishing, editing, and scheduled publishing, checked permissions and browser rendering alongside them, and delivered the results within five business days.
In a newsroom, an article passes through several states before it reaches a reader. A draft in progress, an approved article, a scheduled article, and one already published may be the same document, yet each has to be handled differently.
Checking the design of the public page alone tells you nothing about this process. The person who writes an article, the person who approves it, and the person who reads it each use the service from a different position.
The pre-release review of company P's CMS-based newsroom centered on this publishing process. Acting as a reviewer separate from the build team, IXC defined what to verify before public release and carried it out.
Before a good-looking article page, we looked at the path to publication
The output of a newsroom is the page a reader sees. But when that page goes public, and in what state, is decided during the editing process.
You have to see whether a scheduled post publishes under the conditions set, whether an edit lands on the intended page, and whether users in different roles can perform the work they need. That is a different question from whether the page simply opens.
For this review, drafting, approval, publishing, editing, and scheduled publishing were set as the critical flows. The rendering of published pages and account permissions were checked alongside them.
Defining the scope this way lets the results be read around editorial work rather than a feature list. When a problem occurs, it can be tied to the stage of work it affects.
The five-business-day review began by defining its scope
In a QA engagement on a short schedule, what to verify has to be agreed first. Without a defined scope, even a large amount of testing can leave it unclear what evidence the launch decision rests on.
At company P, the review scope was fixed in writing before kickoff and executed within five business days. The checks needed before release were prepared to fit inside that schedule.
This period is not a schedule that applies equally to every CMS project. The time required can vary with the number of features, the environment, the materials provided, and the scope of fixes and re-verification.
What stands out in this case is not only that it finished quickly. The review was composed so that the set schedule and the agreed scope could be explained together.
Role-based access and what readers see were checked together
Editorial work involves differences in permission. Someone who can write, someone who can approve, and someone who only reads published articles cannot be checked under the same conditions.
The review examined how far an account without permission could reach, and also whether published pages rendered as intended across browsers.
The two checks look from different positions. Role-based access is a question of which actions are allowed; browser rendering is a question of how the published result is delivered.
Because a newsroom is both an editing tool and a public website, both are needed. It is a way of viewing the internal publishing process and the external reading experience as one continuous path.
We turned 'there is an error' into a record that can be fixed
Each confirmed defect was given a severity and reproduction conditions. The review results also included the areas that could not be verified and the parts left out of scope.
If every problem is listed at the same size, the development team has to judge priorities all over again. If the information needed to reproduce a problem is missing, they may have to re-establish the situation before they can even look for the cause.
The review result therefore has to be both a record of the errors found and a document that organizes the work to fix them. Under what conditions a problem occurred and how it could affect the release must be readable together.
This deliverable, too, was left as the basis for deciding whether to launch and in what order to fix. The fact that the review is complete is not stretched into a claim that every defect has been fixed or that the final release is done.
We produced material the launch decision could be discussed on
Company P was left with the review results for the agreed scope, a defect list, and the unverified areas. We set out not only what was confirmed within the schedule but also what could not be claimed.
The value of pre-release QA does not lie in vague reassurance. It lies in enabling a discussion, based on confirmed behavior and remaining problems, about what to fix before release and which conditions to accept.
The quality of a newsroom lies not only in the look of the article page but in the process by which a draft goes public. This review verified that process independently and left it as material for decision-making.