Product & Engineering department
Software testing and QA, run as a standing function
Testing squeezed into the last two days before a release finds bugs too late to fix properly. Nexoryl runs quality assurance as a managed department: test planning, manual and automated testing, regression and release checks, working remotely in your repositories, CI pipelines and issue tracker.
The first button opens an email to info@nexoryl.com.
You bring
- Your product, environments and test data
- Your backlog and release calendar
- Access to repos, CI and the issue tracker
Nexoryl runs
- Test strategy
- Manual testing
- Test automation
- Regression
- Release checks
You get
- Defects found before customers find them
- A regression suite that runs on every build
- A clear go/no-go for each release
- Operating model
- A standing QA function with a test strategy, release criteria and a defect review cadence. Not a contractor brought in at the end.
- Delivery model
- Remote. Testing runs against your environments, with automation in your repositories and CI.
- Usual starting scope
- A QA assessment, then regression coverage for your most critical user journeys.
- Typical roles
- A QA lead, QA analysts for manual and exploratory testing, and automation engineers.
- Runs inside
- Your repositories, CI pipeline, test management and issue tracking tools.
- Engagement
- Assessment first, then a monthly retainer aligned with your release cadence.
Overview
What is software quality assurance?
Software quality assurance is the planned work of checking that software does what it should, keeps doing it after changes, and is ready to release, through test planning, manual and automated testing and clear release criteria.
QA works best when it runs alongside development rather than after it. Test cases written from acceptance criteria catch misunderstandings before code exists, and automated regression catches breakages on every build.
Nexoryl model
What does Nexoryl's Quality Assurance department do?
It runs testing as a standing function: planning by risk, testing stories as they're built, automating regression, reporting defects engineers can act on, and supporting a clear go/no-go before each release.
Defects are fixed by your engineers or Nexoryl's Software Engineering department. Pipelines and environments are shared with DevOps & Cloud.
- Responsible for
- Test strategy and plans, test cases, manual and exploratory testing, automated tests, regression suites, defect reporting and release sign-off support.
- Not included
- Fixing defects in production code, penetration testing, and testing that needs physical presence at your site.
- Connects to
- Software Engineering, DevOps & Cloud, Product Operations and Security & GRC.
Types of testing
What gets tested, when, and how.
Different risks need different tests. The mix is set in the test strategy, based on what would hurt most if it broke.
| Test type | What it checks | When it runs | Manual or automated |
|---|---|---|---|
| Functional | Features behave as specified | Every story | Both |
| Regression | Existing features still work after a change | Every build or release | Mostly automated |
| Exploratory | Unscripted use that finds what scripts miss | Each release | Manual |
| Cross-browser and device | The product works on the browsers and devices you support | Before release | Both, using cloud device services |
| API | Endpoints return the right data and errors | Every build | Automated |
| Performance | Response times under expected load | Before major releases | Automated |
| Accessibility | Keyboard use, contrast and screen reader basics | Each release | Both |
Where quality slips
Four reasons bugs reach customers.
Most escaped defects aren't hard to find. They're found too late, by the wrong process, or ignored.
Testing only at the end
- Shows up as
- Bugs found the day before release, with no time to fix them properly.
- We look at
- When testing starts relative to development.
- What changes
- Testing alongside development, with test cases written from acceptance criteria.
Flaky automation
- Shows up as
- Tests fail at random, so the team learns to ignore red builds.
- We look at
- Test stability, test data and environment dependencies.
- What changes
- Stable suites, where a failing build actually means something.
Bug reports engineers can't act on
- Shows up as
- Tickets that say “it doesn't work”.
- We look at
- How defects are reported and triaged today.
- What changes
- Reproducible reports with steps, environment, evidence and severity.
No release criteria
- Shows up as
- Releases go out because the date arrived.
- We look at
- Whether any quality gates exist.
- What changes
- Agreed release criteria and a sign-off report for each release.
What the department covers
Software testing services.
Manual testing finds what users would find. Automation makes sure it stays fixed.
Test strategy
Testing planned around risk.
- Risk-based test plans
- Acceptance criteria reviews
- Test environment and data planning
- Release criteria
Manual and exploratory testing
People using the product the way customers will.
- Functional testing
- Exploratory sessions
- Cross-browser and device testing
- User acceptance testing support
Test automation
Repeatable checks in your pipeline.
- UI automation with Playwright, Cypress or Selenium
- API test automation
- CI pipeline integration
- Test maintenance
Regression
Confidence that changes didn't break anything.
- Regression suite design
- Smoke tests
- Release regression runs
- Flaky test triage
Specialist testing
The checks most teams skip.
- Performance and load testing
- Accessibility checks
- Localisation testing
- Data migration checks
Defect management
Bugs reported so they get fixed.
- Reproducible bug reports
- Severity and priority triage
- Defect trend reporting
- Release sign-off reports
How remote delivery works
How a QA engagement runs.
Coverage grows from the journeys that matter most, rather than trying to test everything at once.
Step 1: Assess
Current testing, defect history, environments and release process reviewed.
Step 2: Plan
Test strategy, critical journeys and release criteria agreed.
Step 3: Build coverage
Test cases written and the first automated regression suite added to CI.
Step 4: Test continuously
Stories tested as they're built; regression runs on every build.
Step 5: Sign off and report
A release report against the criteria, plus defect trends each month.
Automated tests live in your repositories and run in your CI, so they keep working if the engagement ends.
Scope and boundaries
What's included, and what stays with you.
QA finds, reports and verifies. Fixing is engineering's job.
Included
- Test strategy and release criteria
- Manual and exploratory testing
- UI and API test automation
- Regression suites in CI
- Performance and accessibility checks
- Defect reporting and release sign-off
Not included
- Fixing defects in your code (Software Engineering can)
- Penetration testing and security audits
- Testing that needs physical presence at your site
- Certifying compliance with regulations
What you provide
- Test environments and test data
- Access to repositories, CI and the issue tracker
- Acceptance criteria or specifications
- Your supported browsers and devices
Tools and platforms
Where the work happens.
Frameworks are chosen to fit your stack. Device coverage comes from cloud device services, not a physical lab.
- UI automation
- PlaywrightCypressSeleniumAppium
- API and load
- PostmanREST Assuredk6
- CI
- GitHub ActionsGitLab CIJenkinsAzure DevOps
- Devices and tracking
- BrowserStackSauce LabsJiraTestRail
Named as examples of tools we work in. They don't imply a partnership or certification.
Measurement
How a QA department is measured.
Fewer escaped defects is the goal. These measures show whether the function is getting there.
Defects
- Escaped defect rate
- Defects found before release
- Reopen rate
Coverage
- Requirements with test cases
- Automated regression coverage
- Critical journeys covered
Speed
- Regression run time
- Time to test a story
- Time from bug found to bug reported
Stability
- Flaky test rate
- Build pass rate
- Environment downtime affecting testing
These are measurement categories, not promised figures.
Who does the work
The people testing your product.
The balance between manual and automation roles shifts as regression coverage grows.
QA Lead
Owns the test strategy, release criteria and sign-off reporting.
QA Analysts
Run functional and exploratory testing and write reproducible bug reports.
Automation Engineers
Build and maintain UI and API test suites in your CI.
A good fit when
- Bugs regularly reach customers after releases
- Developers test their own work under deadline pressure
- Your automated tests are flaky or ignored
- There's no agreed definition of ready to release
Probably not the right fit when
- You need a penetration test or security audit
- You need testers on site at your premises
- You want a one-off test with no follow-up
Ways to start
Three ways to begin.
The assessment shows where defects are escaping before a single test is written.
QA assessment
Testing practice, defect history and release process reviewed, with a prioritised plan.
Automation build
A regression suite for your critical journeys built and wired into CI as a scoped project.
Managed QA department
Ongoing manual and automated testing on a monthly retainer, aligned with your releases.
Fees depend on product size, release cadence and automation scope, and are agreed after the assessment.
Questions
Questions about software testing and QA.
If your question isn't here, email us. The right test mix depends on your product and release cadence.
What does a QA department actually do?
It plans testing around risk, tests new work as it's built, automates regression, reports defects so engineers can act on them, and supports a go/no-go decision before each release.
Do you do manual or automated testing?
Both. Manual and exploratory testing finds problems users would hit; automation makes sure fixed problems stay fixed. The balance is set in the test strategy.
Which automation frameworks do you use?
Playwright, Cypress, Selenium and Appium for interfaces, and Postman, REST Assured and k6 for APIs and load, chosen to fit your stack.
Can testing be done remotely?
Yes. Testing runs against your environments over secure access, automation lives in your repositories and CI, and device coverage comes from cloud device services.
Do you fix the bugs you find?
No. QA reports reproducible defects and verifies fixes. Fixing is done by your engineers or Nexoryl's Software Engineering department.
Do you do security or penetration testing?
No. Penetration testing needs a specialist security firm. Security & GRC can help manage remediation and evidence afterwards.
How do you handle flaky tests?
Flaky tests are quarantined, investigated and fixed or removed, so a failing build means something. The flaky test rate is tracked monthly.
What do you need from us to start?
Test environments and data, access to your repositories, CI and issue tracker, and the acceptance criteria or specifications for the product.
Next step
Stop finding bugs the day before release.
Tell us how testing works today and where defects are escaping. We'll assess it and show you where coverage should start.