VOGO · Agent Testing
The agent for software testing
The test plan, test scenarios and cases, defects and reports — prepared and checked by the agent, following the recognised programmes of the profession.
For the organisation's applications and for the testing chapter of bids. The quality lead approves and is accountable.
- Every requirement, tested and proven
- Defects closed only after retesting
- People decide
Testing as a discipline, kept day by day by the agent; acceptance stays human
The agent holds together what easily drifts apart in a project: requirements, test cases, results and defects. Every test case starts from a requirement and ends up in a report, so you can see at any time what is validated, what is in progress and what has no coverage yet.
Scenarios are written point by point from the requirements, with positive, negative and boundary cases. A defect gets its severity class, is fixed, retested and only then closed, with regression of the area affected.
What it states about a standard rests on that standard's sources, kept locally; what it cannot find there, it says openly.
Fewer defects reaching users. Evidence for every requirement. The same accountability, with people.
The test plan
Objectives, test types, environments, test data, entry and exit criteria, in a plan approved before development.
Test scenarios and cases
From the requirements, point by point: positive, negative and boundary cases, each with its expected result and the evidence required.
Traceability
Requirement, test case, result and defect, linked in the compliance matrix; you can see at any time what is validated and what is not.
Defects and retesting
Four severity classes, the same in every stage; a defect is closed only after retesting and regression.
The test reports
At every milestone: the expected result against the actual one, the defects, the status of each requirement and the recommendation.
Security testing
Authentication, role-based access, data separation, injection; the plan sets what runs in the test environment and what on production.
Screen captures
Captures of the applications, always taken with the same settings, on the test account, for evidence and guides.
People decide
The agent prepares, checks and reports; acceptance and decisions on risks remain with the person responsible.
From the code of each delivery to the client's acceptance
The same test types we commit to in our bids, chosen according to what the project requires.
Unit and integration
Run automatically on every code delivery, before any formal testing.
Functional, end to end
On complete workflows, from data entry to result, including the error branches.
Interfaces and integrations
The interface contracts: valid message, wrong schema, duplicate, resuming after an interruption without duplicating the result.
Migration and reconciliation
Migrated data checked for volume, fields, relationships and metadata, then in workflows and reports.
Non-functional
Performance and load, availability, backup and restore, disaster recovery, capacity.
Security
Security audit, vulnerability scanning and penetration testing, following OWASP and OSSTMM.
Accessibility
Checks against EN 301 549 and WCAG 2.1, level AA.
Acceptance
Run by the client's team, on the approved scenarios, with the agent's preparation and support.
Four distinct activities, following the ISTQB syllabus
Planning
The test plan, the entry and exit criteria, the environments and the data, approved before development.
Design
The minimum scenarios required by the client, taken over in full, plus those derived from the requirements and workflows.
Execution
Run on the version installed in the test environment, with evidence for each step and defects recorded on the spot.
Reporting
The results by requirement, the defects with their severity, the retests and the recommendation for acceptance.
Testing starts with the first iteration, not at the end of development. The role that develops is separate from the role that validates: whoever fixed a defect does not validate its closure.
Entry and exit criteria. Formal testing starts with the component installed in the test environment, the automated tests passed, the functional documentation available and the client's team trained. It ends with all planned scenarios executed, no critical or major defect open and the results recorded.
Defects. Four severity classes — critical, major, medium, minor —, the same in every stage, so reporting stays comparable. Every fix is followed by retesting the affected scenario and by the regression suite, to confirm it has not broken anything else.
Acceptance. The criteria are the client's and are taken over in full; the team's internal checks complement them, they do not replace them.
What the client receives at each stage
Editable, versioned documents, linked to each other by the same requirement identifiers.
The test plan
Objectives, test types, environments, data, roles, entry, exit and retest criteria.
The test scenarios and cases
Preconditions, data, steps, expected result and evidence, each linked to the requirement it validates.
The system test and acceptance report
Concrete evidence of operation for all the implemented features and integrations.
The security test and validation report
The results of the audit, the scans and the penetration test, with the fixes and retests.
The defect register
The severity, the affected requirement, the scenario that found it, the fix, the version and the retest result.
The traceability matrix
For each requirement: validated, in progress or not covered, at any point in the project.
On the application screens, under every role, on desktop and on phone
How the agent tests a delivered application: the screens, the rights, the web services, the AI assistants and every upload to the server.
Roles and rights
Every screen, under every role: administrator, central user, unit user, no role, inactive account. What the menu shows, what opens, what a forbidden screen returns at its direct address.
Desktop and phone
Every screen twice, in a laptop window and on a phone, with captures named by screen, size and role.
Layout, measured
Scrolling in pages and dialogs is measured, not judged by eye; so are cut or overlapping elements and targets too small for a finger.
Screen consistency
The top bar, the menu, the buttons and the colours, compared from one screen of the application to the next.
Expected behaviour
Taken from the requirements and the project decisions. What is written nowhere is reported apart, as "expected behaviour undefined", not as a defect.
REST and SOAP web services
Each operation against its contract, plus security: the access key, the rights, access to someone else's data, the encrypted connection.
AI assistants
A simulator writes as real users do, a separate evaluator judges the answers; after training, the retest runs on new questions.
Delivery check
After every upload to the server, the version and the fingerprint of each file are confirmed at the destination; an unclear result is reported as a failure.
The standards it works by
ISTQB
Foundation and Advanced: Test Manager, Test Analyst, Technical Test Analyst, Test Automation, Agile; Security and Performance.
TMAP
Quality in cross-functional teams: testing built into delivery, not added at the end.
IREB CPRE
Clear, testable requirements, the basis of every test case.
ISO/IEC/IEEE 29119
The series of standards for the software testing process, documentation and techniques.
OWASP and OSSTMM
Application security and the methodology of security and penetration testing.
EN 301 549 and WCAG 2.1
The accessibility requirements for digital products and services, level AA.
ISO/IEC 25010
The quality characteristics of the software product: performance, reliability, security, usability.
ISO 9001 and ISO/IEC 27001
The quality management and information security practices applied throughout testing.
The tools
Playwright
Functional regression of the interface and the APIs, including access allowed or refused by role.
k6
Load and performance, on reproducible scenarios, compared with the requirements.
ZAP
Dynamic security checks; it does not replace the independent penetration test.
GitLab
The requirements, the test cases and the requirement–code–test link, with the result of each delivery.
Test planning, design, execution and reporting as distinct activities, with testing started from the first iteration — the same methodology we use in our projects and our bids. The references to ISO standards describe the practices applied, not certifications.
Frequently asked questions
Does it replace the tester?
No. The agent prepares the plan, the cases and the reports and runs the permitted checks; the tester and the quality lead approve them and are accountable for them.
What does it rely on when it cites a standard?
On the certification syllabi and the sources kept locally for each framework. What is not in its sources, it says so; it does not fill gaps from memory.
Does it help with bids?
Yes. It prepares the testing and quality assurance chapter of a bid: the methodology, the test types, the plan, the entry and exit criteria, defect management, the deliverables and the reports.
Who sets the acceptance criteria?
The client. The agent takes them over in full, does not replace them with criteria of its own, and adds the team's internal checks.
Does it test directly on production?
Only as far as the plan allows. Where the plan requires it, it creates test objects only, marked as such, touches nothing else, deletes them at the end and lists them in the report. It pauses between requests and writes no password or key into reports or captures.
Where is test data kept?
In the organisation's folder. Processing is based on the agreement between the organisation, VOGO and the provider of the artificial intelligence service.
See how VOGO Agent Testing works
A 15-minute demo, on an example or on one of your organisation's applications.