How to Accept a Parser from a Contractor: UAT Checklist and Readiness Criteria

Transfer of a parser from the developer is one of the most underestimated stages of a project. Even a well-written data scraper can fail in production if acceptance testing is done superficially. Incomplete data, missing critical attributes, crashes under increased volumes, blind spots without monitoring—all of these are the result of a lack of a systematic approach to UAT (User Acceptance Testing).

Over years of developing and implementing solutions for parsing websites and marketplaces, the ESK Solutions team has developed a structured checklist that helps clients objectively assess the parser's readiness for industrial operation. Below are the key blocks of this checklist and criteria that should be included in the technical specification and acceptance certificate.

Why UAT Testing of the Parser is Necessary

A parser is not a static product but a living service that depends on changes to the target resources. If testing is limited to a few trial runs, the risks after transfer increase sharply:

• the actual page structure may differ from the test sample;
• under load, bottlenecks in the architecture become apparent (memory leaks, locks);
• incorrect error handling leads to collection stopping without notifications;
• lack of documentation makes it impossible to quickly recover after a failure.

UAT gives the client the last control point before formal acceptance. It is not just a "works or not" check, but an assessment of compliance with the real business scenarios that were documented in the requirements.

Parser Acceptance Testing Checklist

1. Functional Testing: Accuracy and Completeness of Collection

The first and most obvious block is the correctness of the extracted data. It is necessary to:

• Comparison with a reference. Prepare a control sample of URLs (at least 50–100 pages) with manual export of target fields. Compare the parser's result with the reference. Acceptable deviation is no more than 1–2% for key attributes.
• Completeness of fields. Verify that all required attributes (price, name, SKU, availability) are filled, and for optional ones, the absence of data is correctly recorded (NULL, not an empty string).
• Handling dynamic content. If the page is rendered via JavaScript, the parser must wait for full loading. Test on slow connections and with timeouts.
• Pagination and navigation. Ensure that the parser correctly navigates through catalog pages, does not loop, and does not skip items.

2. Performance and Stability Testing

A parser that handles 1,000 items per hour may not withstand 100,000. Conduct stress tests:

• Volume testing. Run the collection on the full volume of the target catalog. Measure the actual speed, peak CPU and memory load, and the execution time of one cycle.
• Long run (Soak test). Leave the parser running for 24–72 hours under constant load. Monitor performance degradation, memory leaks, and network connection stability.
• Target site limitations. Check whether pauses between requests are observed and whether the parser causes IP blocks. A good parser should be able to work through proxy rotation and handle HTTP statuses 429/403 without crashing.

3. Error Handling and Exceptional Situations

Chaos in real data is inevitable: layout changes, internet outages, the server responds with unpredictable codes. The parser must survive this:

• Structure validation. If the target page has changed its DOM, the parser should log the error without interrupting the entire collection and move the URL to a queue for reprocessing.
• Logging. Verify that each failure is accompanied by a structured log entry: URL, error code, time. Without this, operation becomes guesswork.
• Self-recovery. The parser should resume operation after an abnormal termination (network failure, server reboot) from the stopping point without duplicating already collected data.

4. Security and Compliance

Even if the parser is internal, it can become a source of vulnerabilities:

• Configuration storage. Proxy credentials, API keys must not be stored in plain text in code or logs.

Parser readiness criteria for production

Acceptance is not just about testing, but also assessing the readiness of infrastructure and documentation. By the time the acceptance certificate is signed, four groups of criteria must be met.

1. Output data quality

• Field accuracy on the control sample ≥98%.
• Average processing time per URL meets the specified SLA.
• Output format (JSON, CSV, direct stream to database) matches the schema accepted by the client.
• A duplicate verification mechanism is in place: re-running should not create duplicates.

2. Reliability and built-in monitoring

Without monitoring tools, the parser becomes a black box. Required components:

• Health-check endpoints. Minimum — an HTTP endpoint returning the collector's status, number of processed/errored URLs, time of the last successful cycle.
• Alerting. Integration with corporate messenger or email for critical events (collection stop, success rate drop below threshold).
• Metrics export. Ability to send metrics to Prometheus, Grafana, or similar monitoring tools to integrate the parser into the client's overall monitoring framework.

Our specialists often design the monitoring framework in conjunction with cloud services: the collector is deployed in a managed cluster, and metrics are automatically aggregated in dashboards.

3. Documentation and knowledge transfer

A parser without documentation is a contractor's liability that will burden the client at every failure. The package must include:

• Deployment guide. Step-by-step installation instructions on a 'clean' server, including dependencies, environment variables, proxy configuration.
• Configuration description. All parameters (crawl depth, timeouts, data sources) with explanation of each parameter's impact.
• Disaster recovery instructions. How to restart from a checkpoint, clear the queue, unblock stuck tasks.
• Data storage schema. Database structure or output file format, field descriptions, table relationships.
• Maintenance policy. Recommendations for proxy pool refresh frequency, log cleaning, manual adaptation when the target site's structure changes.

If the parser has a web management interface, documentation requirements extend to it as well. Such an interface may be developed as part of web development services and must be accompanied by a description of all roles and screens.

4. Integration readiness

The parser rarely operates in isolation. Verify:

• Correct loading of data into the target system (ERP, CRM, analytical data warehouse).
• Support for incremental updates (only changes) and full reload.
• Availability of an API for manual initiation, pausing, and schedule configuration.

Post-acceptance monitoring and support

Signing the acceptance certificate does not mean the parser will no longer require attention. The first 2–4 weeks of production operation are a critical period when hidden defects and nuances not seen in test volumes are revealed.

During this period, it is important to perform daily checks:

• percentage of successfully processed URLs relative to planned volume;
• presence of anomalies in data structure (sharp decrease in item count, empty values in previously filled fields);
• correctness of alerts — both false positives and missed events.

The developer typically provides a warranty support period. During that time, all detected deviations from documented readiness criteria must be resolved at no additional cost. Therefore, it is important to specify these criteria in the acceptance certificate as concretely as possible — with numbers and references to test scenarios.

Frequently Asked Questions

Conclusion

Parser acceptance is not a formality, but a full-fledged project stage that determines how stable and predictably the solution will work in the coming months. The UAT checklist described above helps systematize expectations, avoid conflicts with the contractor, and obtain not just code but a tool ready for operation. Include specific criteria for accuracy, performance, monitoring, and documentation in the technical specification — then the acceptance certificate will become an objective document, rather than a cause for dispute.