How to test a kids app
Direct answer
Shipped untested, a kids app sends a child's precise location or advertising ID to a bundled third-party SDK before a parent passes the consent screen, and lets voice or text chat switched on by default connect adult strangers to a child. 8 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with end-to-end functional tests: every purchase, chat and outbound link must sit behind the parental gate, and chat must stay off on a new child profile until a parent turns it on.
8 mandatory testsfirst: end-to-end functional tests
What counts as a kids app
A kids app here is an iOS or Android app aimed at children under 13, listed under store family or Kids Category rules and subject to COPPA, including companion apps for connected toys. It covers the parental gate, parent consent, bundled SDKs and their data, in-app purchases, chat between players and play on shared family tablets. Language learning apps for mixed ages and games rated for general audiences are out of scope.
Adjacent product types not covered here
- language learning app: A language learning app serves adults and children, so voice recordings from speaking drills and trial renewals lead instead of family store rules for every SDK in the build.
- mobile game: A mobile game for general audiences runs live events and loot boxes, so launch-day load and loot box odds replace a Kids Category build carrying no third-party analytics.
- smart home or IoT app: An IoT companion app controls a home device for an adult owner, so camera account takeover and a vendor cloud outage lead instead of parent consent before a toy's SDK collects a child's location.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Physical or psychological harm to a user user-harm | harm | primary | Voice or text chat switched on by default lets adult strangers contact a child player, the default the FTC tied to children being harassed. | |
| Money leaves or fails to arrive money-loss | money | primary | A child taps buy on gems right after a parent typed the password, and the parent is charged for purchases they never approved. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | A child's precise location or advertising ID reaches a third-party SDK bundled in the app before a parent has passed the consent screen. | |
| Personal or sensitive data exposed data-breach | data | practitioner single incident, no second source | A toy's companion app ships an SDK that collects the child's geolocation for a third party abroad, outside anything the parent agreed to. | |
| App rejected or removed by a store store-rejection | distribution | secondary by design analysis | A Kids Category build includes third-party analytics, or a purchase or outbound link sits outside a parental gate, and review rejects or removes it. |
Mandatory tests (8)
Step 1: release smoke tests
Why:store-rejection
Done when: On the release build, a child opens the app, plays the first activity, and any purchase or link asks for the parental gate.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 2: end-to-end functional tests
Done when: Every purchase, chat and outbound link asks for the parental gate, and chat is off on a new child profile until a parent turns it on.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 3: exploratory testing
Why:user-harm
Done when: A tester posing as an adult stranger cannot find, message or voice-chat a child profile, and a child cannot send their name or location in free text.
Tool class: test management. Who usually runs it: QA engineer.
Step 4: payment and money-flow testing
Why:money-loss
Done when: In the store sandbox, each purchase asks for a fresh parent approval and produces one charge, and a second tap within a minute does not buy again.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 5: compliance checks
Why:regulatory-penaltystore-rejection
Done when: A reviewer confirms the SDK list matches the store declarations, contains no third-party analytics or ad SDK outside the families-certified list, and the parent consent step comes before any personal data leaves the device.
Tool class: test management. Who usually runs it: product manager.
Step 6: analytics and event tracking tests
Why:regulatory-penaltydata-breach
Done when: A network capture from install through first play shows no advertising ID, location or device serial sent to any third-party domain.
Tool class: proxy. Who usually runs it: QA engineer.
Step 7: security scanning
Why:data-breach
Done when: The dependency report names every SDK in the build and flags none that requests location or contacts a domain outside the approved list.
Tool class: dependency scanner. Who usually runs it: security specialist.
Step 8: device and browser compatibility
Why:store-rejection
Done when: The app installs and plays on each supported tablet and phone model and OS version, including shared family devices with parental controls on, and the parental gate appears before any purchase or link on each.
Tool class: device cloud. Who usually runs it: QA engineer.
Recommended and optional tests
regression suiterecommended
Becomes mandatory when an SDK update ships with a release.
usability testingrecommended
Becomes mandatory when parents report they cannot find the controls.
accessibility testingrecommended
Becomes mandatory when the app is sold to schools.
offline and poor-network testingrecommended
Becomes mandatory when progress loss appears in reviews.
unit testsoptional
May help where gate logic is custom.
performance and load testingoptional
May help on low-memory family tablets.
Not needed and why
Not needed: one team owns the app and its backend. Becomes recommended when partners consume the API.
Not needed: chat messages are not stored after delivery and no child account holds personal fields. Becomes mandatory when child accounts or chat history are stored server-side.
resilience and failure testing
Not needed: activities play on the device, and a server outage stops only chat. Becomes recommended when play requires a server.
Order of work
First release
- release smoke tests: On the release build, open the app as a child, play the first activity and confirm any purchase or link asks for the parental gate.
- end-to-end functional tests: Confirm every purchase, chat and outbound link asks for the parental gate and chat is off on a new child profile until a parent turns it on.
- exploratory testing: Pose as an adult stranger and try to find, message or voice-chat a child profile, then try to send a child's name or location in free text.
- payment and money-flow testing: In the store sandbox, confirm each purchase needs a fresh parent approval and produces one charge, and that a second tap right after does not buy again.
- compliance checks: Compare the SDK list with the store declarations and the families-certified list, and confirm the parent consent step comes before any personal data leaves the device.
- analytics and event tracking tests: Capture network traffic from install through first play and confirm no advertising ID, location or device serial reaches any third-party domain.
- security scanning: Produce a dependency report naming every SDK in the build and flag any that requests location or contacts a domain outside the approved list.
- device and browser compatibility: Install and play on each supported tablet and phone model and OS version, including shared family devices with parental controls on, and confirm the parental gate appears before any purchase or link on each.
Ongoing cadence
- release smoke tests: On every build before store submission.
- security scanning: On every build, and whenever an SDK is added or updated.
- analytics and event tracking tests: When an SDK is added or updated, before the build goes to review.
- compliance checks: When store family rules or COPPA guidance change, and before each store declaration update.
- payment and money-flow testing: When a new in-app item or purchase screen ships.
- regression suite: On every release that ships an SDK update.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of kids app (ios, android). Not recommendations.
release smoke tests
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
end-to-end functional tests
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
- EspressoAndroid UI testing framework from Google. androidopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- MaestroMobile UI flows written in YAML. iosandroidfreemium
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- XCTestApple's framework for unit and UI tests. iosopen-source
payment and money-flow testing
- Adyen test environmentTest cards and scenarios for Adyen integrations. webapiiosandroidcommercial
- Stripe test modeTest cards and scenarios for Stripe integrations. webapiiosandroidfreemium
analytics and event tracking tests
- AvoTracking plan and event validation. webiosandroidfreemium
- Segment ProtocolsTracking plan validation for Segment events. webiosandroidcommercial
security scanning
device and browser compatibility
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
regression suite
accessibility testing
- Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
offline and poor-network testing
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- Network Link ConditionerApple tool for simulating poor network conditions. iosopen-source
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for kids app has the same 8 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the kids app is accepted when a child can open the app and play the first activity, while every purchase, chat and outbound link asks for the parental gate and chat stays off until a parent turns it on. A network capture from install through first play shows no advertising ID, location or device serial sent to a third-party domain, and the SDK list matches the store declarations. Each purchase needs a fresh parent approval and produces one charge.
Brief
# Test brief: kids app Product type: kids app. An app aimed at children under 13 with COPPA and store family rules. Risk map and evidence: https://howtotestaproduct.com/how-to-test/kids-app/ Printable checklist: https://howtotestaproduct.com/checklists/kids-app/ Run these 8 mandatory tests in this order. A test is done only when its done condition is true on the build you will release. 1. release smoke tests (risks: store-rejection). Tool class: mobile automation. Usually run by: QA engineer. Done when: On the release build, a child opens the app, plays the first activity, and any purchase or link asks for the parental gate. 2. end-to-end functional tests (risks: money-loss, user-harm). Tool class: mobile automation. Usually run by: QA engineer. Done when: Every purchase, chat and outbound link asks for the parental gate, and chat is off on a new child profile until a parent turns it on. 3. exploratory testing (risks: user-harm). Tool class: test management. Usually run by: QA engineer. Done when: A tester posing as an adult stranger cannot find, message or voice-chat a child profile, and a child cannot send their name or location in free text. 4. payment and money-flow testing (risks: money-loss). Tool class: mobile automation. Usually run by: QA engineer. Done when: In the store sandbox, each purchase asks for a fresh parent approval and produces one charge, and a second tap within a minute does not buy again. 5. compliance checks (risks: regulatory-penalty, store-rejection). Tool class: test management. Usually run by: product manager. Done when: A reviewer confirms the SDK list matches the store declarations, contains no third-party analytics or ad SDK outside the families-certified list, and the parent consent step comes before any personal data leaves the device. 6. analytics and event tracking tests (risks: regulatory-penalty, data-breach). Tool class: proxy. Usually run by: QA engineer. Done when: A network capture from install through first play shows no advertising ID, location or device serial sent to any third-party domain. 7. security scanning (risks: data-breach). Tool class: dependency scanner. Usually run by: security specialist. Done when: The dependency report names every SDK in the build and flags none that requests location or contacts a domain outside the approved list. 8. device and browser compatibility (risks: store-rejection). Tool class: device cloud. Usually run by: QA engineer. Done when: The app installs and plays on each supported tablet and phone model and OS version, including shared family devices with parental controls on, and the parental gate appears before any purchase or link on each. Acceptance criteria wording: A release of the kids app is accepted when a child can open the app and play the first activity, while every purchase, chat and outbound link asks for the parental gate and chat stays off until a parent turns it on. A network capture from install through first play shows no advertising ID, location or device serial sent to a third-party domain, and the SDK list matches the store declarations. Each purchase needs a fresh parent approval and produces one charge. Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file). Licence: CC BY 4.0.
For founders: what to forward and what to ask back. For product managers: turning this page into tickets.
Questions about testing a kids app
What testing does a kids app need?
8 tests are mandatory, each tied to one of the 5 risks in the map, such as a child's location reaching a third-party SDK before parent consent, adult strangers reaching a child through chat and purchases a parent never approved. They include exploratory sessions where a tester poses as an adult stranger. Regression, usability, accessibility and offline tests are recommended, each with the event that makes it mandatory.
What gets a kids app rejected by an app store?
The map marks store rejection as a by design analysis risk: a Kids Category build with third-party analytics, or a purchase or outbound link outside a parental gate, is rejected or removed. Compliance checks compare the SDK list with the store declarations and the families-certified list, and the release smoke check confirms the parental gate on every build.
What is the minimum testing for a kids app at MVP stage?
The minimum is the 8 mandatory tests, because their conditions hold from the first release: the app targets children, ships third-party SDKs, sells in-app items and runs on phones and tablets. Unit and performance tests are optional. Contract, penetration and resilience tests are not needed until the conditions on the page change.
When is test automation worth it for a kids app?
The release smoke check and the SDK dependency report run on every build. The regression suite of gate, purchase, chat and SDK checks becomes mandatory when an SDK update ships with a release.
Which tests in a vendor test plan for a kids app are not needed?
Contract tests are not needed while one team owns the app and its backend, until partners consume the API. Penetration testing is not needed while chat messages are not stored after delivery and no child account holds personal fields, and becomes mandatory when child accounts or chat history are stored server-side. Resilience testing is not needed while activities play on the device and a server outage stops only chat.
Evidence
ev-0036regulatorprimary
Age appropriate design: a code of practice for online services (Children's code), Information Commissioner's Office
The UK Children's code sets 15 standards, including high-privacy defaults, for online services likely to be accessed by children.
published undated · verified 2026-10-07
ev-0263court-or-fineprimary
Fortnite Video Game Maker Epic Games to Pay More Than Half a Billion Dollars over FTC Allegations of Privacy Violations and Unwanted Charges, Federal Trade Commission
Children and teens have been bullied, threatened, harassed, and exposed to dangerous and psychologically traumatizing issues such as suicide while on Fortnite.
Supports user-harm for a kids app with chat or multiplayer: the FTC tied harm to children to voice and text chat being on by default, tied unwanted charges to confusing purchase buttons, including purchases triggered when waking the game from sleep, on a loading screen or while previewing an item, and found personal information collected from children under 13 without notifying parents or getting their consent.
published 2022-12-19 · verified 2026-10-07
ev-0264court-or-fineprimary
Apple Inc. Will Provide Full Consumer Refunds of At Least [amount] to Settle FTC Complaint It Charged for Kids’ In-App Purchases Without Parental Consent, Federal Trade Commission
Supports money-loss for a kids app with in-app purchases: the FTC found parents were not told that entering a password also allowed further purchases by their children without another approval.
published 2014-01-15 · verified 2026-10-07
ev-0003store-guidelineprimary
Designing apps for children and families, Google Play
Google Play Families policy sets extra requirements (ads, data collection, SDKs) for apps whose target audience includes children.
published undated · verified 2026-10-07
ev-0024regulatorprimary
Children's Online Privacy Protection Rule (COPPA), U.S. Federal Trade Commission
COPPA requires verifiable parental consent before collecting personal information from children under 13 on sites and apps directed to children or with actual knowledge.
published undated · verified 2026-10-07
ev-0262court-or-fineprimary
Apitor (FTC case), Federal Trade Commission
The FTC reached a settlement with Apitor Technology over allegations that its app enabled a third party in China to collect geolocation information from children without parental consent.
Supports regulatory-penalty and data-breach for a kids app: the companion app of a children's toy let a third party collect children's location without parental consent.
published undated · verified 2026-10-07
ev-0281court-or-fineprimary
Edmodo, LLC, U.S. v., Federal Trade Commission
Supports regulatory-penalty for a learning management system used by schools and for a kids app: the FTC order covers collecting children's data without parental consent, using it for advertising and pushing COPPA consent duties onto schools.
published undated · verified 2026-10-07
ev-0001store-guidelineprimary
App Review Guidelines, Apple
Apple reviews every iOS, iPadOS and macOS App Store submission against these guidelines, including crashes and bugs at review, privacy disclosures, in-app purchase rules and extra rules for medical, financial and kids apps, and apps with user-generated content must let users report offensive content and block abusive users (guideline 1.2), and apps offering loot boxes or similar mechanisms must disclose the odds of each item type before purchase (guideline 3.1.1).
published undated · verified 2026-10-07
Disclaimer
This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.