Functional testing of 1C-Bitrix: where the site breaks
Functional testing of 1C-Bitrix starts not with checking the markup, but with business scenarios where an error costs the most: checkout, exchange with 1C, access control, external integrations.
These places break quietly — the page opens, the buttons click, but on the customer's side orders are already being lost and stock balances are diverging.
The cart is a classic point of failure.
A product is added, but when the discount is recalculated or the delivery method is changed, the total is recalculated incorrectly; a promo code is applied to one item instead of the entire cart; with parallel orders, excess stock is written off.
The customer sees an error on the site at the moment of payment — and leaves instead of reporting it.
The exchange with 1C breaks unnoticed by the storefront: prices and stock stop updating, orders are not uploaded to the accounting system, the product catalog and warehouses diverge. The error accumulates for days until a manager reconciles the data manually.
Access rights are the third risk zone: a guest sees wholesale prices, a regional manager gets access to someone else's database, and a section for authorized users is open via a direct link.
Integrations with payments, delivery services, and external services add their own failures: a payment goes through, but the order status does not change; the delivery calculation returns an empty response for a non-standard address.
Each such gap means manual support work, refunds, and lost trust. We break down how to identify these points of failure before customers find them.
What testing delivers: measurable business impact
Functional testing of 1C-Bitrix answers one question: what exactly breaks for the user after the next change. The regression suite runs on every release and covers typical scenarios — checkout, payment, registration, catalog export, exchange with 1C.
Errors that previously surfaced in production a day or two after deployment are caught before publication, so the flow of support requests drops predictably: tickets become several times fewer, not just a few percent fewer.
The speed of releasing changes grows not because "we write code faster," but because the fear of deployment is removed.
When there are automated checks on critical paths and a clear rollback protocol, releases go out more often and in smaller increments — edits to templates, components, and 1C exchange rules stop being an all-day event.
The team doesn't waste time manually clicking through the same scenarios over and over, and support focuses on development rather than sorting out repetitive incidents.
A separate effect is the disappearance of entire classes of failures. Data integrity checks during 1C exchange eliminate desynchronization of stock and prices; cart and payment tests — stuck orders and lost payments; access rights control — leaks through open sections.
This isn't "it became a bit more reliable," but a different operating profile: site stability stops depending on who exactly deployed the release and on which shift.
In practice, this shows up in the metrics: the share of incidents found by users decreases, the average time between releases shrinks, and the time to resolve a single request drops because the cause is already localized by a test. Let's break down how such a testing loop is built for a specific site and its integrations with 1C.
Testing Modes: Manual Run, Automated Tests, Regression
The three modes do not replace but complement each other: manual testing catches what cannot be described by a formal scenario, automated tests maintain stability over the long haul, and regression testing protects already working scenarios from new edits.
The choice depends on what changes in the release and what the cost of an error is in a specific area.
| Mode | When it fits | Limitations |
|---|---|---|
| Manual testing | New scenarios, layout, forms, payment, integrations with 1C | Expensive to repeat, depends on the reviewer's attention |
| Automated tests | Stable scenarios: authorization, cart, checkout, data exchange | Require maintenance when layout and logic change |
| Regression testing | Before every release and after core edits | A full run takes time, prioritization is needed |
| Smoke checks | After deployment and updates | Cover only the critical path, do not replace a full run |
How we choose a mode for a task
If a release touches business logic — payment, personal account, exchange with 1C — first a manual run of new scenarios, then locking them in with automated tests. This way the check is not lost with the next edit: the scenario is described once and then runs without a human.
For regular updates of the core and modules, regression along priority paths and smoke checks after rollout are sufficient. A full run of all scenarios on every release is unjustified — we select those that touch the changed code.
What the combination of modes provides
Manual testing reveals defects that automated tests miss: incorrect texts, shifted layout, illogical transitions. Automated tests lock in the result and remove the human factor on repetitive steps.
Regression testing covers the main risk — "fixed one thing, broke another." Smoke checks provide quick confidence that the site is alive after deployment and allow rolling back the release before the client sees the problem.
How the audit works: stages of engineering work
An audit begins not with running tests, but with an inventory: which components and modules are involved, where caching happens, which integrations with 1C and external services exist, and which scenarios are critical to the business.
Without this, the testing plan turns out to be formal — it covers what is easy to test, not what breaks in production. That is why the first stage always produces a map of the system and a list of risks, rather than a report on the number of test runs.
Next, we build the sequence so that each stage relies on the result of the previous one.
- Site audit — we examine the structure, core and module versions, edit history, and current errors in the logs. We record what is already unstable: these are future points of failure.
- Testing plan — we describe which paths we cover, which scenarios we consider critical, what we test manually, and what we automate. We agree on priorities: first, what directly affects orders and data.
- Environment setup — we spin up a copy as close to production as possible: the same versions, the same cache and queue settings, the same 1C database. Testing on a "clean" build catches non-existent problems and misses real ones.
- Test run — functional testing of 1C-Bitrix follows the agreed scenarios: order placement, exchange with 1C, access rights, forms, integrations. We record every failure with reproduction steps, not just "it doesn't work."
- Analysis and prioritization — we divide findings into blockers, critical, and cosmetic. Blockers are fixed immediately; the rest — with an estimate and an order of priority.
- Re-run — we confirm that the fixes didn't break neighboring scenarios. Regression here is cheaper than a rollback in production.
- Handover of results — a report with reproducible steps, a list of what was fixed, remaining risks, and monitoring recommendations.
This sequence delivers a predictable result: by the time of deployment, the team has not "we think we tested everything," but a list of covered paths and explicitly named areas that remained outside the testing. Describe your task — we'll come back with an estimate and a testing plan for your setup.
What remains in hand: artifacts and regulations
A check does not end with a "works" verdict. Its result is a set of artifacts that the client's team uses to ship releases and accept changes without us. Each document covers its own class of errors, which is why the list is fixed.
- Test cases for critical scenarios: order placement, payment, registration, integration with 1С, catalog export. Each step with an expected result and a note on whether the defect reproduces again.
- Inspection report: what was tested, on which environment, which defects were found, what was fixed, what remains with a priority label. No "all good" — with references to specific pages and scenarios.
- Risk map: bottlenecks that do not break now but will fail under load growth or a core update — heavy catalog queries, scheduled synchronization with 1С, component cache.
- Release regulation: deployment order, mandatory checks before publication, rollback points, who confirms the release. The rule "first to the test environment, then to production" stops relying on one engineer's memory.
- Acceptance checklist: a short list of 10-15 items that a lead or manager goes through before handing over a task — forms are submitted, emails arrive, payment goes through, the old version of the page opens.
- Configured monitoring: alerts about site downtime, errors in logs, unavailability of the exchange with 1С. An incident is caught before the client calls, not after.
- Backups and recovery verification: schedule, retention period, where copies are stored and how to deploy them on a clean environment. A copy that has never been restored does not count as a copy.
- Accesses and documentation: accounts with roles, environment diagram, instructions for typical operations — updating content, adding a section, editing prices.
The kit remains with the client and is not tied to us: a new contractor or an in-house developer enters the project using these documents rather than reconstructing the logic from the code.
The release regulation and acceptance checklist usually outlive several team changes — they are what holds quality when the inspection is long over.
Case study: how validation eliminated 1C exchange failures
The client is a wholesale company with an online store on 1С-Битрикс and synchronization of catalog, prices, and stock with the accounting system.
The exchange ran on a schedule but regularly failed: some products were not updated, prices diverged from actual ones, and managers corrected items manually. Synchronization errors surfaced only at the customers' end — as checkout failures and support questions.
What it was like before validation
We started with functional testing of the exchange: we ran a full synchronization cycle on a test environment, analyzed the logs, and reproduced scenarios that in normal operation passed "by luck." We identified accumulated failures — from duplicate items to interruptions in the middle of a batch, when part of the data was written and part was not.
We separately checked the behavior on re-run: without proper handling, a repeated exchange multiplied errors instead of fixing them.
What we changed
We rewrote the exchange logic with idempotent processing — a re-run is now safe and does not create duplicates. We added package integrity validation before writing and clear notifications on discrepancies, so a failure is visible immediately rather than a day later.
We set up automatic restart of failed tasks and separated write permissions so that manual edits would not conflict with the exchange.
What the result was
The number of support requests about price and stock discrepancies dropped by roughly five times. Exchange downtime during a failure decreased from several hours to minutes — the task recovers on its own, without an engineer's involvement.
The share of successful synchronization cycles grew to stable values, and manual catalog edits practically disappeared from the managers' daily work.
How is pre-release verification different from regular regression?
Pre-release verification answers one question: can this build be rolled out today. Engineers run critical scenarios — order placement, payment, authorization, catalog export, exchange with 1C — on the same dataset as production.
The goal is to catch the regression introduced by a specific change and prevent it from reaching customers. Such a run is one-time: it is tied to the rollout date and closes together with the release.
Regression is not a one-time event but a permanent quality loop. It exists independently of releases: the set of checks is fixed, runs on a schedule and after every change in code, configuration, or on the 1C side.
The point is that the system changes not only when you touch it: the platform core is updated, new module versions arrive, the vendor changes the export, 1C itself is updated. Any of these events can break a scenario that worked yesterday.
The difference shows up in frequency and coverage. Before a release, only what is affected by the change is checked — quickly and in a targeted way.
Regression runs the entire critical path end to end, including integrations and background jobs, and does so regularly rather than occasionally.
That is exactly why regression catches degradation that a one-time check physically cannot see: discrepancies in stock balances after exchange, timeouts during export, errors in emails and notifications.
The practical conclusion is simple: a one-time check reduces the risk of a specific release, while a permanent quality loop reduces the risk of the entire system.
The former without the latter leaves blind spots between rollouts — and that is usually where problems surface that the customer learns about before the team does.
Common technical concerns from clients
Before work starts, the same questions almost always come up — about load, access, integrations, and compatibility with what is already running. Below are the answers as we give them at technical meetings.
Will the site handle peak load after the improvements?
We don't guess: before release, we run load testing on scenarios that replicate real traffic — taking into account caching, sessions, and database calls. We look not at the average response time, but at behavior at peak and the point where the system begins to degrade.
If the headroom is less than needed, we optimize queries and caching before deployment, not after an incident.
What access do you need, and how safe is it?
We need access to the development environment and the test environment, and to production — only during deployment. We work through separate accounts with limited permissions, without a shared administrator password.
All actions are logged, access is revoked upon completion of the stage — you can see at any moment who did what.
Won't the current integrations break?
First, we inventory everything that exchanges data with the site: inventory, payment, delivery, CRM, external services. For each integration, we check the exchange format, error handling, and behavior when the external side is unavailable.
We roll out changes so that old and new calls work in parallel — that way, a rollback doesn't sever connections.
Is this compatible with our infrastructure and platform version?
Before assessment, we verify the requirements against your environment: core version, server configuration, database environment, installed modules. If an update is mandatory, we plan it as a separate stage with testing on a copy of the production environment. That way, you see the real constraints before work begins, not at the moment of deployment.
What if something goes wrong after release?
We maintain a rollback point: a backup of the database and files before deployment, versioning of changes. If a deviation appears after release, we return to the previous state within minutes, and analyze the cause on a copy. This is a standard part of the procedure, not a separate service.
Describe your task and current environment — we'll come back with an estimate, a testing plan, and a list of required access.
Let's discuss the task: we'll come back with an estimate and a plan
The check begins with an analysis of the current state: which modules and components are involved, how the templates are structured, where the data is stored, which integrations with 1C are already working.
Without this, there will be no plan — functional testing of 1C-Bitrix is built around the specific configuration of the project, not according to a generic checklist.
Describe the task in free form: what is concerning you now, what has changed recently, which customer scenarios break most often. This is enough to come back with an estimate and a testing plan.
Next, we fix the scope of work and timelines, agree on priorities, and only after that do we proceed to testing. The plan includes:
- inventory of components, modules, and custom modifications with risk assessment;
- verification of user scenarios: ordering, payment, registration, personal account, forms;
- testing of the exchange with 1C — exports, synchronization of nomenclature, prices, stock, orders;
- verification of access rights and roles: what a guest, manager, and administrator see;
- running across browsers and devices, including mobile scenarios;
- load testing of key pages and entry points;
- a report with a list of defects, their priorities, and recommendations for remediation.
As a result, you get not an abstract "everything works," but a list of specific places where the system's behavior diverges from the expected, with reproduction steps indicated. This allows you to plan improvements based on facts, not guesses.
Tell us what is happening with the site right now and what result you need — we'll come back with an estimate, a testing plan, and timelines.