Mama Llama’s Food Cart Adventure - Embedded QA Case Study
🧾 Project Overview
- Game: Mama Llama’s Food Cart Adventure
- Studio: Loom & Lore Interactive Games
- Role: Embedded QA Tester
- Testing dates: 14-15 May 2026, followed by fix validation and regression checks
- Release date: 24 May 2026
- Platforms: PC and Google Play
Introduction
This case study covers my embedded QA work on Mama Llama’s Food Cart Adventure, a portrait-mode food-cart match-3 game by Loom & Lore Interactive Games.
Unlike my public QA mini-passes, this was not a one-off external test of a demo. I worked directly with the developer during release preparation, using structured test planning, daily handovers, evidence capture, fix validation, and regression testing to support the final release.
This page focuses on the workflow and QA process rather than exposing internal bug details. The aim is to show how I worked with the developer, how I decided what to test, and how the QA work supported release readiness.
| Game | Role | Release |
|---|---|---|
| Mama Llama’s Food Cart Adventure | Embedded QA Tester | Released 24 May 2026 on PC and Google Play |
Studio Feedback
“Releasing a high-quality game is vital for a new studio. Kelina made sure our Google Play Store launch for Mama Llama went smoothly. She caught critical UI/UX and code bugs before release. Her delivery was highly organized. Every report included thorough documentation, reproducible steps, and helpful screenshots. Kelina handles QA with the finesse of a master.”
🎯 My QA Role
My role was to provide structured QA support during the final stage of development before release. The project was close to launch, so the priority was not broad exploratory wandering or deep compatibility coverage. The priority was identifying player-facing risks, reporting them clearly, supporting the developer with actionable feedback, and validating fixes quickly.
I worked as part of a small two-person QA and development workflow: the solo developer building and updating the game, and me providing structured QA support through private Discord channels, daily reports, a shared workbook, and linked evidence.
🧭 QA Focus
- Onboarding and tutorial clarity
- Mobile portrait usability
- Readability and UX friction
- Player feedback clarity
- Accessibility risk observations
- Progression and frustration points
📄 Reporting
- Google Sheets QA workbook
- Test charters
- Session log
- Bug and UX observation log
- Daily Google Docs handovers
- Screenshot and video evidence links
🔁 Validation
- Fix validation after developer updates
- Regression checks around affected systems
- Release-readiness support
- Player-facing risk review
- Communication through QA Discord channels
🛠️ Workflow & Communication
Communication happened daily through private structured Discord channels, including QA and devlog update channels. This kept the workflow lightweight and appropriate for a solo-dev project. For this team size, Jira would have added unnecessary overhead, so I used a shared Google Sheets Bug Log and daily Google Docs handovers instead.
The developer could review the end-of-day handover for overall testing progress, then refer separately to the shared Google Sheets bug log for detailed findings, screenshots, and linked video evidence.
| Workflow Area | How It Worked |
|---|---|
| Communication | Daily communication through private Discord channels, including QA updates and devlog information. |
| Planning | I created the test plan from scratch using the current build state, devlog context, release priorities, and player-facing risk areas. |
| Reporting | Findings were organised in a Google Sheets workbook with charters, session logs, bug and UX logs, and linked evidence. |
| Handovers | At the end of each testing day, I produced a Google Docs handover summarising what was tested, what mattered, and what needed attention. |
| Evidence | I captured Android gameplay through scrcpy and OBS, edited clips in Microsoft Clipchamp, and shared unlisted YouTube links for easy review. |
| Fix Validation | After developer updates, I retested fixes and checked surrounding systems for regressions. |
🧠 How I Decided What to Test
Because the project was so close to release, I prioritised areas that could affect first impressions, mobile usability, player understanding, frustration, and release readiness. I used the developer’s available devlog context and the live build behaviour to design the test plan myself.
The first priority was understanding how the game would feel to a new player. From there, testing expanded into pressure states, longer sessions, progression pacing, recovery systems, visual fatigue, and accessibility-related readability risks.
Fresh-Player Testing
I tested early onboarding, menu clarity, How To Play information, order readability, swipe interaction understanding, fail-state communication, and whether the core loop made sense without over-explaining itself.
Stress & Long-Session Testing
I also tested higher-pressure gameplay, repeated losses, low-match board states, recovery windows, long-session visual fatigue, and whether frustration affected retry motivation or return motivation.
📈 Testing Lifecycle
The work followed a release-focused lifecycle. I started with first-session clarity and basic usability, then moved into deeper progression, pressure states, retention friction, and accessibility risk observations.
| Stage | Focus | Purpose |
|---|---|---|
| 1. Onboarding and first session | Tutorial clarity, How To Play information, early gameplay understanding, order readability, and fail-state communication. | Check whether new players could understand the game quickly and start playing without major confusion. |
| 2. Core gameplay readability | Board readability, food recognition, customer orders, match feedback, combo clarity, and special tile communication. | Check whether the match-3 loop stayed understandable during active play. |
| 3. Pressure and progression | Escalating customer pressure, repeated failures, recovery windows, order size, low-match board states, and retry motivation. | Identify where challenge became frustration and where player agency started to feel reduced. |
| 4. Mobile usability | Portrait layout, one-handed play, touch input, edge interactions, screen readability, and UI hierarchy. | Check whether the game worked comfortably as a portrait mobile experience. |
| 5. Accessibility risk observations | Colour contrast, warning-state visibility, eye strain, visual scanning fatigue, and attention load during pressure states. | Surface practical readability risks without turning the pass into a formal accessibility audit. |
| 6. Fix validation and regression | Retesting developer changes and checking nearby systems after updates. | Confirm fixes worked and did not create new issues around connected systems. |
🔍 QA Areas Covered
The QA work covered more than functional bug finding. A large part of the value was identifying how the game communicated with players during active mobile play, especially under pressure.
Player Understanding
- Onboarding clarity
- How To Play discoverability
- Core loop comprehension
- Fail-state communication
Mobile Readability
- Portrait UI hierarchy
- Food icon recognition
- Customer order readability
- Visual scanning fatigue
Gameplay Pressure
- Progression pacing
- Recovery windows
- Retry motivation
- Fairness perception
Interaction Reliability
- Touch responsiveness
- Swipe accuracy
- Invalid swap feedback
- Cascade stability
Accessibility Risks
- Text contrast concerns
- Peripheral warning visibility
- Low-vision readability risks
- Long-session eye strain
Release Support
- Fix verification
- Regression checks
- Prioritised handovers
- Release-readiness feedback
🤝 Working With the Developer
Because this was a small indie workflow, the reporting needed to be structured without becoming heavy. The goal was to give the developer clear information that could be acted on quickly.
I avoided dumping raw observations without context. Instead, I grouped findings by player impact, explained why they mattered, and separated functional issues from UX observations, accessibility risks, progression concerns, and positive validation.
This meant the developer could see not just what was wrong, but what was working well, what was worth preserving, and where fixes or tuning would have the highest release impact.
The focus of this work was structured release support: identifying player-facing risks, explaining them clearly, validating fixes, and helping the developer prepare the game for release.
🧰 Tools & Evidence Workflow
| Tool | Used For |
|---|---|
| Google Sheets | QA workbook containing charters, session logs, bug and UX logs, notes, and structured tracking. |
| Google Docs | Daily end-of-day QA handovers summarising what was tested, what was found, and what needed developer attention. |
| Discord | Private QA communication with the developer, including sharing reports, clarifying updates, and posting handovers. |
| scrcpy | Android screen capture from the test device. |
| OBS Studio | Recording gameplay evidence during mobile testing. |
| Microsoft Clipchamp | Editing clips into shorter evidence videos for easier developer review. |
| YouTube Unlisted | Private evidence storage and easy sharing through report links. |
🚀 Release Outcome
The QA pass identified enough relevant player-facing risks for the developer to make targeted fixes and judge the build ready for release after validation.
After the developer pushed fixes, I retested the relevant areas and performed regression checks around connected systems. The game then released on PC and Google Play on 24 May 2026.
I was also credited in the released game, which reflects my direct QA contribution to the project.
✅ What This Case Study Shows
- Designed a release-focused QA plan from scratch using devlog context, current build state, and release priorities.
- Worked directly with a solo indie developer without overcomplicating communication or workflow structure.
- Translated gameplay observations into structured handovers covering bugs, UX friction, accessibility risks, and positive validation.
- Tested from both fresh-player and stress-testing perspectives across onboarding, progression, and long-session gameplay.
- Validated developer fixes and performed regression checks around affected systems after updates.
- Supported release readiness without introducing unnecessary production overhead for a two-person workflow.
Need QA Support for Your Game?
If you have a demo, early build, update, or release candidate that needs structured QA support, message me with the platform, build, and what you need checked.
📎 Disclaimer
This page documents credited QA work completed by Kelina Cowell for portfolio and recruitment purposes. I am not the developer or publisher of Mama Llama’s Food Cart Adventure. All trademarks, logos, screenshots, clips, and game assets remain the property of their respective owners. Internal QA details, bug logs, and private developer communications are not published here. If anything needs to be removed or credited differently, please contact me and I’ll update it promptly.