Service
Testing
Proving the programme before traffic, not after the war room forms. Functional, integration, and go-live evidence on the journeys operators actually run.
Testing on a telecom programme is not a list of screenshots. It is evidence that a prepaid offer, a loyalty earn, a CRM case, and a bill still hang together after the change. Innova Core Technologies builds those plans from Riyadh as part of Data, Integration, Customer Experience, and Automation delivery — not as a week squeezed in before go-live.
We have watched programmes treat testing as a vendor gate. The vendor passes their script. The customer journey still breaks where campaign, Sugar CRM, MongoDB, and RBM meet. Certified, repeatable testing follows the identifier across those systems and includes the security and access cases that usually arrive too late.
Journeys, not modules
A module test that campaign passed does not prove the grant is billable. A CRM test that opened a case does not prove billing knows the account. We write scenarios as journeys: who the customer is, which keys they carry, what each system must do, what a failure looks like. Marketing, care, BSS, and security all have to recognise the scenario, or it will be waived as “not realistic†the night before launch.
Scope covers functional, integration, and go-live proving. Functional is the happy path and the obvious negatives. Integration is the hand-off: campaign to loyalty, CRM to RBM, digital profile to care. Go-live proving is the dress rehearsal in an environment that is close enough to teach you something — identifiers, volumes, and partner connections included, with an honest list of what it still cannot prove.
Security cases sit in the same pack. Privilege change, a restricted segment extract, a backup restore, a failed login that must alert. If those are “owned by another stream,†they will not be ready. Data security is a sister service; testing is how we show it works.
Defects a squad can act on
A defect that says “campaign is wrong†is not a defect. It is a complaint. We write system, data, expected result, observed result, and the journey that found it. Vendors and internal squads can act on that. Steering committees can see it. The goal is evidence, not optimism.
Entry and exit criteria are written before execution. We do not discover them in the war room. Severity is agreed with the business owner, not only with IT. A billing mismatch can be more severe than a cosmetic CRM field. Testing that cannot say “we will not go live with this class of defect†is decoration.
How it sits with upgrades and operations
Software upgrades reuse the same journey pack. A version move without a regression set is a hope. Freeze windows are part of the test plan: what must not change while we prove the new version. Rollback is a test case. If you have never restored, you have not tested the upgrade.
Handover includes the pack operations can rerun. Scripts, data sets, and the note on what is environment-specific. Automation is welcome when it is stable; it is not a substitute for a named owner who can read a failed journey and decide. We would rather a smaller pack that is rerun every release than a thousand cases that died with the project folder.
Traceability matters. A requirement, a journey, a defect, and a retest should be joinable without archaeology. That is how a steering committee sees progress without being shown a percentage that hides the one billing break that should have stopped the launch. We have sat with operators and integrators including Systems Arabia, STC, Zain KSA, Mobily, Airtel, Maalim Al Khabra, and Smart Solutions. The programmes that survived a steering committee were the ones that could show a journey, not a dashboard of pass percentages with no story.
If go-live is on the calendar and the test pack is still a vendor spreadsheet, that is the conversation. Request a callback. A coordinator in Riyadh will return it at Info@innovacore-tech.com or through the form.