Case study · Healthcare · Web, mobile and API testing
A year of QA for a platform families rely on
Rootines is a patient engagement and remote patient monitoring platform for parents and clinicians supporting children with developmental and behavioural health conditions such as Autism Spectrum Disorder and ADHD. A small remote team was building it with no QA function at all. testology became that function: three engineers, embedded for a year, testing the product the way its parents and clinicians would use it.
- Client
- Rootines, a paediatric behavioural health platform
- Engagement
- Embedded QA team of three, one year
- Focus
- API, security, role-based, web and mobile testing across parent and clinician profiles
- Delivery
- Test plans and cases, tooling selection and setup, reproducible defect reports, regression coverage
The challenge
The client described itself as a small but mighty team of remote workers across Europe and North America, building life-changing software for the autism community. They wanted QA that would take ownership of quality rather than tick boxes: review requirements before code existed, choose the tooling, plan the testing, and see every bug through to a verified fix.
Two audiences, one product
Parents use a mobile app in the moment, often distracted and often on a poor connection. Clinicians use a web application to review what parents recorded and to act on it. The same feature has to be right from both sides, and a permission model sits between them that must never leak.
Starting from zero tooling
There was no test management tool, no automation and no agreed process when the engagement began. The brief was explicit about it: recommend the software, set it up, and build the QA practice around it while the product kept shipping.
What the brief asked for
- Review requirements, specifications and technical designs before the build, and give timely feedback
- Write structured test plans and test cases for a product that had none
- Recommend, set up and configure testing software, as the team was not using any
- Design and run automated tests alongside exploratory testing
- Regression, usability, cross-browser and accessibility (WCAG) testing
- Report issues in Jira and verify each one is actually fixed
What testology delivered
Five workstreams ran across the year, each tested from the point of view of the people using it. Repeated checks went into the regression runs; exploratory sessions covered whatever was new.
API testing
The parent app and the clinician side share one backend. We tested the endpoints directly: status codes, response shape, validation of bad input, and what happened when a record was edited on one side while the other was reading it.
Security testing
Health data about children sets the bar. We tested authorisation boundaries between roles, session handling, and whether one family's data could ever be reached from another family's account, and reported anything that crossed a line as a blocker.
User profile testing
Parents, clinicians and the people administering the platform see different screens and hold different permissions. Every feature was tested as each profile, not just as the account the developer happened to be logged in with.
Web application testing
The .NET web application used by clinicians and parents, tested across the browsers the users actually had, with accessibility checks against WCAG, because some of the parents using it rely on a screen reader.
Mobile application testing
The parent-facing mobile app, tested on real devices for the moments that matter: logging an incident mid-tantrum, a notification arriving while the app is in the background, a poor connection in a waiting room.
The approach
Read before it's built
Requirements and design documents were reviewed as they were written. Questions raised at that stage cost a conversation; the same questions after release cost a hotfix.
Set up the QA basics
The team had no test tooling when we joined. We chose and configured it, wrote the first test plans, and agreed with the developers what a good bug report looked like.
Test as every user
Each release was checked as a parent, as a clinician and through the API, on web and on mobile. Regression covered the flows that had broken before; exploratory sessions covered what was new.
Close the loop
Bugs went into Jira with reproduction steps, severity and evidence, and were retested when fixed. Suggestions that went beyond bugs were raised too, and the client's review later singled those out.
The outcome
A year of testing still left bugs in the product, as a year of testing always does. What changed is that the ones reaching parents and clinicians became rarer and smaller, and the team ended up with a QA practice that did not depend on any one person being online.
We've had the pleasure of working with [testology] for over a year. With them on your team you get so much more than just “someone to do QA”. Great attention to detail and very insightful suggestions. Both creativity and innovation shine through in their work. They truly understand the mission of an unquestionably complex product and provide invaluable work.
Releases the team could stand behind
Over a year, the product went out with defects found and fixed before parents and clinicians met them, and with regression coverage that grew with every release.
A QA process from nothing
Tooling, test plans, severity rules and a bug workflow now exist where none did, in a shape a small remote team across Europe and North America could keep running.
QA as a second pair of eyes
Testing every feature as each user profile surfaced usability and design gaps, not just bugs. The client's feedback singled out the suggestions as much as the defects.
Building software people depend on?
Health, care and anything else where a silent failure hurts a real person. We test it as your users would, from the API up to the phone in their hand. We find it before your users do.