CORE Evaluate · Automated software testing
Find issues before release, and fix the ones CORE can.
CORE tests how your application behaves, performs and holds up to attack, across the browsers and devices your users have. Then it connects each finding to a fix, and re-tests to prove it.
package.json · upgraded, suite re-runauth/rate-limit.ts · limit addedtests/checkout.spec · selector repairedNine kinds of testing, one platform
See exactly what CORE tests, and how.
Choose the tests your release needs. Each one comes with the checks it runs, the evidence you get back, and what self-heal fixes for you.
Self-heal. When a screen changes and a test breaks, CORE repairs the test. When the application itself is wrong, it proposes the fix.
What you get
- Pass or fail for every journey, with screenshots
- The exact step that failed, and why
- Traceability from each requirement to its tests
Functional testing
Every journey, run the way your users run it.
CORE turns your requirements into end-to-end journeys and runs them the way a real user would: signing in, filling forms, moving through workflows and checking every outcome against the business rule behind it.
What CORE checks
- User journeys from start to finish
- Business rules, validations and calculations
- Roles and permissions for each kind of user
- Edge cases, bad inputs and error messages
- Emails, notifications, files and exports
- Workflows that span several screens or systems
Self-heal. Broken selectors and outdated test data are repaired automatically and re-run, so the suite stays green for the right reasons.
What you get
- A run-to-run comparison
- New failures separated from known issues
- A clear go or no-go summary for the release
Regression testing
Prove that what worked yesterday still works today.
After every change, CORE re-runs what used to work, so side effects are caught before your users find them. Suites can run in full or be targeted at the code that changed.
What CORE checks
- Full and risk-based regression suites
- Tests targeted at the code that changed
- Smoke tests on every build
- Visual comparison of key screens
- Flaky tests detected and isolated
- Runs on a schedule or from your pipeline
Self-heal. Tests update themselves when an API changes in an agreed way. Unexpected contract changes are flagged for your review.
What you get
- Results for every endpoint
- Contract drift highlighted before it breaks production
- Request and response evidence for each failure
API and integration testing
Check every handshake between your systems.
CORE validates the interfaces your application depends on: its own APIs, the services it calls, and the data that moves between them, against the contracts each side expects.
What CORE checks
- Contracts checked against OpenAPI specifications
- Status codes, payloads and schemas
- Authentication and token handling
- Error handling, timeouts and retries
- Third-party services you depend on
- Data passed correctly from system to system
Self-heal. Slow queries, missing caching and other causes found under load come back as proposed fixes, then the test is re-run to prove the gain.
What you get
- A clear verdict: pass, pass with warnings, or fail
- Response time against users, with the degradation point marked
- A detailed PDF report with prioritized recommendations
Load and performance testing
Find your breaking point before your customers do.
Tell CORE the URL and how many users to simulate. It runs from a runner inside your own hosting, measures how response times and errors change as load grows, and shows where performance starts to degrade.
What CORE checks
- Smoke, average load, stress, spike, soak and breakpoint tests
- Response times at p50, p95 and p99 against your targets
- Throughput and error rates as users increase
- The user count where performance degrades
- Risk acknowledgement and domain check before any traffic
- Automatic stop if error thresholds are crossed
Self-heal. Common layout breaks such as overflowing text or hidden buttons come back with a proposed fix, re-checked on every affected combination.
What you get
- Screenshots for every combination
- Layout differences highlighted side by side
- Issues grouped by browser, system and screen size
Browser and device testing
The same experience on every screen your users have.
CORE checks layout and behavior across the browser, operating system and screen-size combinations you choose, from a wide desktop monitor down to a small phone.
What CORE checks
- Chrome, Edge, Firefox and Safari
- Windows, macOS, iOS and Android
- Desktop, laptop, tablet and phone screen sizes
- Layout breaks, overflow and overlapping elements
- Touch, mouse and keyboard behavior
- Responsive breakpoints and orientation changes
Self-heal. Supported vulnerabilities are fixed automatically and re-tested. Anything that needs judgment is flagged for your team to review.
What you get
- Findings ranked by severity
- The file and line, or the request, behind each finding
- A remediation plan your engineers can act on
Security testing and VAPT
Find the weaknesses an attacker would look for.
CORE scans your code, dependencies and configuration, then tests the running application for vulnerabilities, with penetration testing where it is in scope.
What CORE checks
- Code and dependency vulnerabilities
- Misconfigurations and exposed secrets
- OWASP Top 10 risks in the running application
- Authentication, sessions and access control
- Penetration testing where in scope
- Infrastructure-as-code and pipeline settings
Self-heal. Missing labels, missing alt text and low-contrast colors come back with code fixes for your review, then the screen is re-checked.
What you get
- Issues by WCAG criterion and severity
- The exact element and screen affected
- Guidance your designers and developers can act on
Accessibility testing
Make sure everyone can complete the task.
CORE checks your screens against WCAG success criteria at levels A and AA, so people using a keyboard, a screen reader or magnification can do what everyone else can.
What CORE checks
- Color contrast and text sizing
- Keyboard navigation and focus order
- Screen-reader labels and alternative text
- Forms, error messages and announcements
- Headings, landmarks and page structure
- Motion, timing and zoom behavior
Self-heal. Rule-based data problems come with a correction script for your approval, and the checks re-run once it is applied.
What you get
- Every mismatch with the records behind it
- Counts reconciled across systems
- Sample evidence for auditors
Data integrity testing
The number on the screen should match the number in the database.
CORE follows records through your screens, APIs and database to confirm they agree, and checks the rules your data must always obey.
What CORE checks
- Values that match across screens, APIs and database
- Calculations, rounding and currency handling
- Duplicates, orphans and missing records
- Migrations and bulk imports
- Referential integrity and constraints
- Audit fields and timestamps
Self-heal. Missing timeouts, retries and fallbacks are proposed as fixes, then the failure scenario is re-run to confirm recovery.
What you get
- Failure scenarios with their outcomes
- Measured recovery times
- Recommendations ranked by risk
Non-functional testing
See what happens when things go wrong.
CORE tests how your system behaves under failure: a slow dependency, a service that goes down, a job that stops halfway. It shows whether users are protected and data is kept safe.
What CORE checks
- Slow or unavailable dependencies
- Retries, timeouts and fallbacks
- Recovery after a failed job or restart
- Resource use under sustained work
- Logging and error reporting
- Backup and restore where in scope
Coverage depends on the tools you configure, the technologies involved, your test environments and the scope you agree.
Browser and device coverage
Every combination you choose, checked.
Pick the browsers, operating systems and screen sizes your users actually have. CORE runs your journeys on each combination and compares layout and behavior side by side, so a broken button on one phone does not hide behind a passing desktop run.
| Browser | Windows | macOS | iOS | Android |
|---|---|---|---|---|
| Chrome | Covered | Covered | Covered | Covered |
| Edge | Covered | Covered | Covered | Covered |
| Firefox | Covered | Covered | Covered | Covered |
| Safari | —Not available | Covered | Covered | —Not available |
Latest browser versions, plus earlier versions on request. Safari is shown only where Apple ships it.
How a test run works
From the first question to a release decision.
Choose what to test
Start from your critical workflows, your release risk and your quality targets. Pick the categories that matter for this release.
Provide only what those tests need
A URL and test credentials for functional testing, an API specification for API testing, a target user count for load. CORE asks for nothing beyond what the chosen tests require.
CORE builds and runs the tests
Test cases are generated or configured and run in the environment you agree. Load runs from a runner inside your own hosting.
Read one answer, with detail behind it
A report for every category and a single summary that answers the question your release manager is really asking: should this ship?
Heal and re-test
Supported fixes are applied under your controls, the relevant tests re-run, and the summary updated. Anything that needs a human decision is flagged for review.
Load testing, done responsibly
Load test your application through a conversation.
Tell CORE the URL and how many users to simulate. It asks the right follow-up questions about journeys, sign-in, test data, think time and response-time targets, then runs the test from a runner deployed in your own cloud or network.
Because the runner sits next to your application and connects out rather than in, intranet and private applications can be tested without opening a single inbound port.
Authorized before anything runs
You accept a risk acknowledgement and verify you own the domain. A one-user smoke test comes first, and the full test starts only when you say so.
Stops on harm
Hard limits on users and duration, an allow-list of hosts, and automatic abort if error thresholds are crossed. You can stop the test at any moment.
A detailed PDF report
A clear verdict, the capacity you demonstrated, where response times began to degrade, findings with evidence, and recommendations tied to each one.
One platform, not nine tools
Stop stitching together a testing toolchain.
The usual way
A separate tool for every kind of test
One tool for functional tests, another for load, another for security scans, another for accessibility. Each has its own license, its own scripts to maintain and its own report. Somebody still has to read all of them and decide whether to ship.
With CORE
One run, one summary, fixes included
Choose the categories you need, provide the inputs once, and get a report per category plus one consolidated answer. Supported findings come back fixed and re-tested, and the tests keep themselves current as the application changes.
Integrations
Fits into the tools your team already uses.
No new workflow to learn. Runs start from your pipeline, results arrive in your tracker and chat, and existing tests keep their value.
Code & CI/CD
Trigger runs from your pipeline and report back on every pull request.
- GHGitHub
- GLGitLab
- BBBitbucket
- ADAzure DevOps
- JKJenkins
- GAGitHub Actions
Issue tracking & chat
Findings land where your team already works.
- JIJira
- ABAzure Boards
- SLSlack
- MTMicrosoft Teams
Test frameworks
Bring the tests you already have, or let CORE write new ones.
- SESelenium
- PWPlaywright
- CYCypress
- K6k6
- PMPostman
- OAOpenAPI
Product names are trademarks of their respective owners.
Self-heal, built into every run.
Testing that only reports problems leaves the hard half to your team. CORE closes the loop.
- Supported vulnerabilities fixed automatically
- Broken test selectors repaired when screens change
- Relevant tests re-run after every fix
- Every fix listed for review before production
Continuous, not one-off
Run it on every release, not once a year.
Schedule runs or trigger them from your pipeline. Because self-heal keeps the suite current, the tests you build for one release are still working on the next, rather than quietly rotting.
From your pipeline
Trigger runs on a merge, a nightly schedule or a release candidate.
Trends over time
Compare runs to see whether quality and performance are improving or slipping.
Questions about quality & testing
What kinds of testing does CORE Evaluate run?
Functional, regression, API and integration, load and performance, browser and device, accessibility, data integrity and non-functional testing, plus security testing with vulnerability assessment and penetration testing where it is in scope.
Which browsers and devices does CORE test on?
Chrome, Edge, Firefox and Safari on Windows, macOS, iOS and Android, across desktop, laptop, tablet and phone screen sizes. You choose the combinations that matter to your users, and CORE compares layout and behavior across them.
Does CORE work with our existing tools and tests?
Yes. Runs can start from GitHub, GitLab, Bitbucket, Azure DevOps, Jenkins or GitHub Actions, findings can go to Jira, Azure Boards, Slack or Microsoft Teams, and existing Selenium, Playwright, Cypress, k6 or Postman tests can be brought in alongside the ones CORE writes.
Where does load testing traffic come from?
From a small runner deployed in your own cloud or network, such as Azure, AWS or a Linux VM. It connects out to CORE, so you open no inbound ports, and it can test private and intranet applications.
How does CORE stop a load test from causing harm?
Before any traffic is sent you accept a risk acknowledgement and verify domain ownership. A single-user smoke test runs first. Hard limits on users and duration, a host allow-list and automatic abort thresholds are enforced, and you can stop the test at any time.
What does self-heal fix in testing?
Supported vulnerabilities such as outdated dependencies or missing rate limits, and broken tests caused by changes to screens or APIs. Each fix is applied under your controls, the relevant tests are re-run, and the change is listed for your review.
Have a release you are not sure about?
Tell us what it is and what worries you. We will tell you which tests would answer the question.