Prime Time: Slime Time - QA Case Study

🧾 Project Overview

🎯 My QA Role

As Head of QA for Loom & Lore Interactive Games, I provided QA support for Prime Time: Slime Time during its Android closed-testing development period. My role focused on evaluating the game from a player-facing perspective while identifying functional, usability, readability, input, progression, and performance issues across successive builds.

Testing began with broad exploratory coverage of onboarding, combat readability, mobile controls, upgrade systems, pickups, progression flow, and run-state stability. As development continued, my testing shifted into targeted regression and devlog-driven validation, allowing reported fixes and newly implemented systems to be checked against the specific changes introduced in each build.

My responsibilities included exploratory QA, regression testing, mobile usability testing, performance validation, input and joystick testing, progression and economy validation, new feature testing, gameplay smoke testing, player-facing risk assessment, evidence capture, and structured reporting. Repeated regression passes were also used to track issues across builds and distinguish successful fixes from remaining or newly introduced concerns.

🛠️ Workflow & Communication

Testing was planned around the current Android build, recent developer changes, previously reported issues, and the player-facing risks identified during earlier passes. Initial exploratory testing established the main usability and gameplay concerns, while later passes became increasingly targeted as fixes and new systems were introduced.

Test passes included player-focused exploratory gameplay, targeted regression, devlog-driven validation, gameplay smoke testing, mobile usability checks, and extended performance testing. Where performance issues affected reliable validation, testing was stopped or marked as blocked rather than treating incomplete coverage as a pass or failure.

Findings were documented through structured QA reports covering test scope, build situation, observed behaviour, player impact, passed areas, remaining concerns, and verification limitations. Video evidence was used where useful to demonstrate gameplay behaviour, while later builds were used to retest fixes and track how previously reported issues changed across development.

🎮 QA Coverage & Testing Timeline

Testing evolved across successive Android builds as Prime Time: Slime Time moved through closed testing. Initial coverage focused on first-time-player experience, mobile controls, gameplay readability, progression, and run stability. Later passes shifted toward targeted regression, new feature validation, economy systems, and repeated investigation of performance under sustained gameplay load.

Coverage included onboarding, joystick and touch input, combat readability, pickups, upgrades, progression, run-state behaviour, economy and reward systems, mobile UI, new features, and extended performance testing. Previously reported issues were revisited across later builds to verify fixes and track remaining behaviour.

✓ Tested during this period    — Not tested or not a focus during this period

📱 Mobile Input & Performance Testing

A major part of testing focused on mobile input stability and gameplay performance during increasingly demanding combat states. Early testing identified severe joystick instability that caused rapid directional snapping and loss of movement control, alongside performance degradation that became increasingly noticeable as runs progressed.

I tested movement under different gameplay conditions, including rapid direction changes, persistent weapon and environmental effects, increasing enemy density, overlapping visual effects, and longer runs. Following updates, targeted regression passes were used to determine whether previously reproduced input problems remained present and whether performance improvements held under sustained gameplay load.

Input behaviour and performance were evaluated separately where possible. This helped distinguish direct control problems, such as unwanted directional snapping, from reduced responsiveness caused by falling frame rates. Where performance degradation made other gameplay systems unreliable to assess, those tests were recorded as blocked or incomplete rather than being treated as valid pass or fail results.

Repeated testing showed measurable improvement across builds. The severe joystick snapping identified during early testing was no longer reproduced after subsequent fixes, while later performance testing showed the game progressing from sustained late-run degradation to intermittent FPS drops with recovery. A later build successfully completed a full 30-minute run under sustained gameplay load, while remaining performance concerns were documented for further investigation.

⚠️ Key Player-Facing Risk Areas

The areas below summarise the types of player-facing risk identified and evaluated during testing without publishing private bug reports or internal development information.

🤝 Working With the Developer

Testing priorities were shaped around the developer's current build changes, devlog updates, known issues, and areas requiring focused validation. This allowed each QA pass to concentrate on the systems most affected by recent development work rather than repeatedly covering the entire game.

Testing evolved in response to the project's needs. Early passes focused heavily on first-time-player experience, mobile controls, gameplay readability, onboarding, and progression clarity. Later passes became increasingly regression-focused, covering fixes and newly implemented systems such as joystick behaviour, pickup visibility, upgrade communication, the Gift Shop economy, Reroll and Banish functionality, mobile scrolling, and late-run performance.

Findings were separated according to their purpose and player impact. Functional defects, performance problems, usability concerns, readability issues, blocked verification, and areas requiring further monitoring were documented separately so that confirmed failures were not confused with observations or systems that could not yet be fully validated. Video evidence and gameplay observations were provided where useful for reproduction and investigation.

QA support continued across multiple updated Android builds, including targeted retesting after fixes and follow-up investigation of recurring performance and input concerns. Development is currently paused, so the case study represents the testing completed during the project's active development period.

🧰 Tools & Evidence Workflow

✅ What This Case Study Shows

• Player-focused exploratory testing across multiple Android closed-test builds.
• Targeted regression testing to verify fixes, new features, UI changes, and gameplay systems across successive updates.
• Reproduction and follow-up investigation of a severe mobile input issue affecting joystick stability and player control.
• Performance testing across extended gameplay sessions, including tracking late-run FPS degradation and improvement between builds.
• Evaluation of onboarding, gameplay readability, pickup visibility, upgrade communication, survivability feedback, and mobile usability.
• Validation of progression and economy systems including upgrades, persistent currency, reward payouts, Reroll, Banish, and Gift Shop behaviour.
• Clear separation of confirmed defects, usability concerns, performance risks, passed regressions, blocked tests, and areas requiring continued monitoring.
• Evidence-based reporting using gameplay recordings and structured QA summaries to support developer investigation and fix validation.
• Adaptation of test scope as the project evolved, moving from broad first-time-player testing into increasingly targeted regression and performance validation.