Current Location ：
Acceptance Testing and Go-Live Sign-Off for a Phone System
Deployments rarely go live because everything works. They go live because the date arrived and the problems that remain seem tolerable. That is not necessarily wrong, but it is worth making explicit, because the alternative is an unspoken set of assumptions that surfaces weeks later as a dispute about whether the system was ever really finished. Acceptance testing exists to convert 'it seems fine' into a written record of what was tested, what passed, what failed, and what was knowingly accepted. This article covers how to define those criteria, who should own the decision, and how to handle the defects that will still be open on the day.
Write Criteria Before Testing Starts
Criteria written after testing has begun tend to describe whatever already works. Criteria written before describe what the business actually needs. The difference matters, because the point of acceptance is to protect the organisation against inheriting a system that technically functions but does not support how people work. Writing them early also forces the conversation about what 'working' means, which is often the first time anyone asks.
| Criterion area | Example of a testable criterion | Why it is written this way |
|---|---|---|
| Core calling | Internal and external calls complete in both directions from a sample of sites | Observable and repeatable by anyone |
| Reachability | Every published business number rings at an answered destination | Prevents silent gaps between the number list and the system |
| Emergency | Emergency calls from each site reach an answered service with correct location information | Cannot be assumed; must be demonstrated per site |
| Features in daily use | Transfer, hold, and voicemail retrieval behave as staff expect | Targets what people actually do, not what the platform can do |
| Integration | Directory, presence, or application integration works in the real workflow | Integration defects hide in the workflow, not in the interface |
| Reporting | Administrators can retrieve the reports the business relies on | Reporting is often assumed and rarely tested |
Who Signs Off, and On What
Sign-off needs a named person with authority to accept risk on behalf of the business, and it needs to be clear what they are accepting. Technical teams can confirm that tests passed; they cannot confirm that a known defect is acceptable to the business. Separating those two statements prevents the common situation where an engineer's 'it works' becomes an organisation's 'we accept this gap' without anyone deciding it.
Handling Open Defects
There will be open defects on the day. The useful approach is to classify them rather than to argue about whether they block. Anything affecting emergency calling, reachability of published numbers, or the ability to work at all should block. Anything cosmetic or affecting a small population can be accepted in writing, with an owner and a date.
- Classify each open defect as blocking, accepted with a date, or accepted permanently
- Require a named owner and a target date for anything accepted with a date
- Record why an accepted defect is acceptable, since the reason is forgotten before the risk is
- Re-test blocking items after remediation rather than accepting an assurance
- Confirm that emergency calling has no open defects at any site before go-live
Keep the Record
The acceptance record is not project bureaucracy; it is the reference for the first incident review and for the next change. When something breaks six months later, the question is usually whether it ever worked. A dated record of what was tested and what was accepted answers that immediately, and it protects both the delivery team and the business from a conversation based on memory.
Redstone Approach
Redstone supports acceptance planning and go-live readiness for deployments on the REX IP-PBX platform and RGW gateway lines. Our teams can help define testable acceptance criteria, structure the test window, participate in verification at each site, and record results including any accepted defects. We work alongside your project and network teams, and we agree the scope of acceptance support in writing before the deployment schedule is committed.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
