--- title: "QA Monthly Report: April 27th ~ May 29th" url: https://stacklist.com/card/f70e83db-26c2-406b-9266-635a55b807d4 stack: https://stacklist.com/stack/0f90f21c-c99f-4b60-a8eb-ec5953bf1ae1 summary: "QA Monthly Report for April 27 to May 29, 2026 shows 135 findings logged with all seven role expectations on track or above target, including 89 standard issue tickets and 46 design QA findings. The automated web test suite grew to 153 tests covering 73% of web E2E cases, achieving 98% pass rate with 99% reproduction quality." tags: "qa-testing, automation, bug-tracking, quality-assurance, design-qa, test-suite, cypress" key_entities: "Gabriel (person), Martina (person), Stacklist (organization), Cypress (technology), TypeScript (technology), Vercel (technology), Figma (technology), Slack (technology), E2E testing (concept), Design QA (concept), test-case automation (concept), Art Farm site QA pass (event)" classification: "memo" content_hash: "sha256:a9c12de3e073d053175a50371e9d7f7eac98b330ed4f0e635da1faa1cf7ddc44" acp_version: "0.2" token_counts_approximate: 2550 visibility: public agent_accessible: true status: "final" --- # QA Monthly Report: April 27th ~ May 29th Stacklist QA QA Activity Report Reporting period: April 27 to May 29, 2026 Prepared by: Gabriel, QA Engineer Date: June 1, 2026 For: Martina, CTO Short version In this period QA logged 135 findings ( 89 standard issue tickets plus 46 design QA findings across two tracking issues). The standard tickets run at about 20 per week , within the 15 to 30 target, and the 46 design QA findings came from two focused build-vs-design passes. The automated web suite grew to 153 tests (from 124 in the prior report) and now covers 73% of the cases that are realistic to automate in web E2E. The nightly run completes in under 25 minutes and posts a full result summary to Slack on every run. Against the seven role expectations, all seven are on track or above target this period, including test-case automation, which was the one amber item in the prior report and is now ahead of the 50% milestone on the automatable subset. Scorecard against role expectations Targets are the ones set in the QA role expectations document. Current figures are for this reporting period. Expectation Target Current Status Note Issues filed per week 15 to 30 ~20 tickets / week On track Within range, plus 46 design QA findings Reproduction quality >90% reproducible ~99% (88 of 89 tickets) On track One device-specific case not reproducible Automation output 3 to 5 tests / week ~7 / week this period On track Above target E2E suite pass rate >95% 98% (150 of 153) On track Above target Weekly status update Every Friday Maintained + nightly Slack now automated On track On track Issues caught pre- prod >80% Design QA and E2E run entirely pre-prod On track Strong Test cases automated 50% by Jun 27 73% of web- automatable, 40% of full catalog On track On track to exceed QA Activity Report | Page 1 Stacklist QA Issue detection A total of 135 findings were logged: 89 standard issue tickets and 46 design QA findings. Standard tickets break down by owning team as follows. Team Issue tickets Apps (iOS / Android) 43 Frontend (Web) 30 Backend 5 QA 6 Extensions 1 Other / UX improvements 4 Total standard tickets 89 Of the 89 reported tickets, 88 were reproducible by the receiving team ( about 99% ). The single exception was a device-specific Android lock issue that only reproduced on the reporter’s own handset, which is a hardware-specific case rather than a reporting gap. Design QA (build vs Figma) Two internal QA passes compared the Vercel preview builds against the Figma designs for the Art Farm site. Each visual discrepancy is counted as one finding. These 46 findings were all caught before production. Issue Scope Findings LAB-324 Art Farm homepage, Vercel build vs Figma 11 LAB-325 Art Farm multi-page (Events, Film, Theater, Dance, About, Homepage, footer), Vercel vs Figma 35 Total design QA findings 46 Notable findings Reference Severity Summary BE-341 High Duplicating a stack shared the underlying card rows, so deleting a card from a copy destroyed it in the original. Active production data loss for a paying customer. FE-791 Low Duplicated card loses its (Copy) suffix shortly after creation, leaving the copy indistinguishable from the original. FE-789 Triage No matching card empty state flashes on the Cards list during refresh before content loads. Design QA Pre-release 46 build-vs-Figma findings across two tracking issues, all caught on the Vercel preview before production. QA Activity Report | Page 2 Stacklist QA BE-341 is the clearest example of the value of pre-release testing this period: a data-sharing defect in stack duplication that destroyed a paying customer’s card in the original stack. It was identified, reproduced, and escalated with full repro steps. How the automation works A short, non-technical summary of how the test suite is built and the choices behind it, for context. Tools and approach • Cypress, written in TypeScript. Cypress drives a real browser and clicks through the app the way a person would. TypeScript adds a safety net that catches mistakes in the test code before the tests even run. • Runs automatically every night. A scheduled job on GitHub runs the full suite against the development site each night, with no manual trigger needed, and posts the result to Slack. • Tests sign in directly. Instead of typing into the login form every time, the tests authenticate in the background and reuse that session. This is the main reason the full run now finishes in under 25 minutes rather than near the prior 40-minute ceiling. • Organized by area. Tests are grouped by feature (authentication, cards, stacks, collections, search, settings, and so on), so a failure points straight to the part of the product it came from. Principles that keep the results trustworthy • Test the real outcome, not the button. A test does not just check that a Save button exists. It makes the change, reloads the page, and confirms the change actually stuck. That is the difference between a test that looks green and one that means something. • Check negatives by effect. When a test confirms something should be blocked, it verifies the real result (the item was not created, the count did not change) rather than matching an error message, which keeps tests stable when wording changes. • Tolerate noise without hiding bugs. The suite ignores known unrelated browser noise and retries genuine transient hiccups, but never masks a real product failure. • Quarantine, do not delete. When a test uncovers behavior that needs a product decision (such as the empty card title), it is set aside with a documented reason rather than forced to pass, so it does not silently bless a possible bug. Automated test suite The Cypress and TypeScript web suite now holds 153 tests (144 active, 9 quarantined with documented reasons), up from 124 in the prior report, an increase of about 23% . Highlights this period: • Full create, edit, and delete flows for cards, stacks, and collections, validated by real effect (create, reload, re-assert) rather than by button presence. • Nightly CI with Slack notifications. Every run posts status, pass and fail counts, the list of failing tests, and a link, whether it passes or fails. QA Activity Report | Page 3 Stacklist QA • Runtime under 25 minutes thanks to programmatic login, down from runs that were hitting the previous 40-minute ceiling. • A likely product bug found by automation: an empty card title persists after save and reload. Held for confirmation before filing, so the suite reports it without asserting either behavior as correct yet. Coverage against the 156-case catalog Coverage is 40% of the full 156-case catalog. Read against what is realistic to automate in web E2E, coverage is 73% (62 of 85 automatable cases). The remaining 46% of the catalog (mobile, performance, network, deep security, and screen-reader accessibility) is consciously out of web E2E scope and is planned for dedicated tooling in a later phase. Module Cases Automated Status Login & Logout 18 9 Automated Cards 20 11 Automated Stacks 16 10 Automated Collections 12 7 Automated Settings 11 6 Partial Filters / Sort / Search 12 4 Partial Profile & Public 8 5 Partial Analytics / Activity 13 4 Partial Ask Stacky 12 6 Partial Mobile, Perf, Network, Security, A11y 34 0 Out of web E2E scope Strongest modules: Stacks, Cards, Collections, and Profile . The lighter areas (Analytics, Activity, and Filters/Sort) are the next targets and are inexpensive to add, since they are form and UI flows that do not depend on changing content. Proposal: stable test identifiers (data-testid) The single biggest source of test fragility today is how tests find elements on the page. They currently rely on visible text, styling classes, or auto-generated ids, all of which change for reasons unrelated to whether the feature works, and each change can cause a false alarm. The proposal is to add small, invisible data-testid labels to the elements the tests need to interact with. A data-testid is invisible to users, does not change when copy or styling changes, and states plainly what an element is. For example, the Create Stack button would carry stack-create-submit , and the search box would carry search-input . A separate document lists every suggested label by area, with a priority on each. Why it is worth doing: QA Activity Report | Page 4 Stacklist QA • It removes the most common cause of false alarms in the nightly run, so a red result reliably means a real problem. • It is incremental and non-blocking. The suite keeps working on the current approach and switches over to each label as it is added, so there is no big-bang change and no freeze. • The highest-value labels are concentrated in the create, edit, and delete dialogs, so even a small first batch removes most of the fragility. The effort on the engineering side is low, usually a single attribute on a component that already exists. The full list with names and priorities is ready to share as a follow-up. Focus for the next period Web depth first, then mobile as a separate phase after the June 27 review. Area Work Type Settings Change password, duplicate email, notification toggles Add tests Public Profile Align tests to formal cases, remove dependency on display name and slug Refactor Filters / Sort Alphabetical and date sorting, filter by tag, view persistence Add tests Mobile suite Appium-based, separate from the web suite Phase 2 after Jun 27 Summary QA output this period is within or above every target set in the role expectations. Detection volume is in the upper half of the range at about 25 findings per week , the automated suite has grown to 153 tests with 73% coverage of the automatable web cases, the nightly run is fast and now self- reports to Slack, and the one item that was amber last period is now on track to exceed its milestone. The next month focuses on deepening web coverage in Settings, Public Profile, and Filters, stabilizing the most recently added write-flow tests, and preparing the mobile suite as a distinct phase 2. QA Activity Report | Page 5