android-qa-verification

polaralias's avatarfrom polaralias

This skill is used to verify Android features against acceptance criteria, catch regressions and define tests that reflect real device behaviour.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 27, 2025

When & Why to Use This Skill

This Claude skill automates and enhances Android application quality assurance by transforming product acceptance criteria into robust, behavior-driven test plans. It specializes in identifying critical Android-specific edge cases—such as lifecycle events, process death, and configuration changes—to ensure high-performance stability and prevent regressions across real devices and emulators.

Use Cases

  • Feature Validation: Automatically converting product requirements and acceptance criteria into detailed test cases for new Android implementations.
  • Regression Testing: Systematically identifying, reproducing, and suggesting targeted fixes for suspected bugs across UI, ViewModel, and repository layers.
  • Lifecycle & Edge Case Analysis: Verifying app stability during complex Android events like screen rotations, theme changes, and background process recreation.
  • Database Migration Auditing: Planning and validating data integrity during version upgrades to ensure existing user data is preserved and new fields function correctly.
  • Hybrid Test Strategy: Designing a multi-layered testing approach that combines Unit tests for logic, Instrumentation tests for UI flows, and manual steps for hardware-dependent features.
nameandroid-qa-verification
descriptionThis skill is used to verify Android features against acceptance criteria, catch regressions and define tests that reflect real device behaviour.

Android QA and Verification Skill

Purpose

Ensure implemented Android features behave correctly, survive lifecycle changes and match acceptance criteria on real devices and emulators.

When to Use

Use this skill after implementation work or when bugs or regressions are suspected.

Outputs

  • Behaviour-based test plan
  • Unit, instrumentation and UI test ideas
  • Edge-case scenarios
  • Reproduction steps
  • Focused fix suggestions

Procedure

  1. Take the acceptance criteria from product shaping and turn each into one or more test cases.
  2. Identify Android-specific edge conditions:
    • Configuration changes (rotation, theme change).
    • Process death and recreation.
    • Timezone changes and daylight saving shifts if times are involved.
    • App backgrounding and resuming.
  3. Plan tests at appropriate levels:
    • Unit tests for repositories and ViewModels.
    • Instrumentation or UI tests for flows through Composables and navigation.
    • Manual test steps where automation is difficult (for example notifications).
  4. Validate migrations:
    • Describe steps to upgrade from an old database version to the new one.
    • Confirm existing data is preserved and new fields behave as expected.
  5. For each bug:
    • Provide a minimal, deterministic reproduction path.
    • Map the likely layer (UI, ViewModel, repository, database, platform integration).
    • Suggest a targeted change, not a refactor.

Guardrails

  • Do not propose architectural rewrites.
  • Do not rely on brittle UI tests that mirror implementation details closely.
  • Focus on user-visible behaviour, data integrity and stability across lifecycle events.