toss·Jan 20, 2026Original article

Toss Income QA Platform: The Beginning (opens in new tab)

Toss's QA team developed an internal "QA Platform" to solve the high barrier to entry associated with using Swagger for manual testing and data setup. By transforming complex, multi-step API calls into a simple, button-based GUI, the team successfully empowered non-QA members to perform self-verification. This shift effectively moved quality assurance from a final-stage bottleneck to a continuous, integrated part of the development process, significantly increasing product delivery speed. ### Lowering the Barrier to Test APIs * Existing Swagger documentation was functionally complete but difficult for developers or planners to use due to the need for manual JSON editing and sequential API execution. * The QA Platform does not create new APIs; instead, it provides a GUI layer over existing Swagger Test APIs to make them accessible without technical documentation. * The system offers two distinct interfaces: "Normal Mode" for simplified, one-click testing and "Swagger Mode" for granular control over request bodies and parameters. ### From Manual Clicks to Automation and Management * Phase 1 focused on visual accessibility, allowing users to trigger complex data states via buttons rather than manual API orchestration. * Phase 2 integrates existing automation scripts into the platform, removing the need for local environment setups and allowing anyone to execute automated test suites. * The final phase aims to transition into a comprehensive Test Management System (TMS) tailored to the team's specific workflow, reducing reliance on third-party external tools. ### Redefining Quality as a Design Choice * By reducing the time and mental effort required to run a test, verification became a frequent, daily habit for the entire product team rather than a chore for the QA department. * Lowering the "cost" of testing replaced guesswork with data-driven confidence, allowing the team to move faster during development. * This initiative reflects a philosophical shift where quality is no longer viewed as a final checklist item but as a core structural element designed into the development lifecycle. The primary takeaway for engineering teams is that the speed of a product is often limited by the friction of its testing process. By building internal tools that democratize testing capabilities—making them available to anyone regardless of their technical role—organizations can eliminate verification delays and foster a culture where quality is a shared responsibility.

Quality AssuranceTest AutomationApi TestingTest Management+3

toss·Nov 3, 2025Original article

Working as a QA in a (opens in new tab)

Toss Place implements a dual-role QA structure where managers are embedded directly within product Silos from the initial planning stages to final deployment. This shift moves QA from a final-stage bottleneck to a proactive partner that enhances delivery speed and stability through deep historical context and early risk mitigation. Consequently, the organization has transitioned to a culture where quality is viewed as a shared team responsibility rather than a siloed functional task. ### Integrating QA into Product Silos * QA managers belong to both a central functional team and specific product units (Silos) to ensure they are involved in the entire product lifecycle. * Participation begins at the OKR design phase, allowing QA to align testing strategies with specific product intentions and business goals. * Early involvement enables accurate risk assessment and scope estimation, preventing the "shallow testing" that often occurs when QA only sees the final product. ### Optimizing Spec Reviews and Sanity Testing * The team introduced a structured flow consisting of Spec Reviews followed by Q&A sessions to reduce repetitive discussions and information gaps. * All specification changes are centralized in shared design tools (such as Deus) or messenger threads to ensure transparency across all roles. * "Sanity Test" criteria were established where developers and QA agree on "Happy Case" validations and minimum spec requirements before development begins, ensuring everyone starts from the same baseline. ### Collaborative Live Monitoring * Post-release checklists were developed to involve the entire Silo in live monitoring, overcoming the limitations of having a single QA manager per unit. * This collaborative approach encourages non-technical roles to interact with the live product, reinforcing the culture that quality is a collective team responsibility. ### Streamlining Issue Tracking and Communication * The team implemented a "Send to Notion" workflow to instantly capture messenger-based feedback and ideas into a structured, prioritized backlog. * To reduce communication fragmentation, they transitioned from Jira to integrated Messenger Lists and Canvases, which allowed for centralized discussions and faster issue resolution. * Backlogs are prioritized based on user experience impact and release urgency, ensuring that critical bugs are addressed while minor improvements are tracked for future cycles. The success of these initiatives demonstrates that QA effectiveness is driven by integration and autonomy rather than rigid adherence to specific tools. To achieve both high velocity and high quality, organizations should empower QA professionals to act as product peers who can flexibly adapt their processes to the unique needs and data-driven goals of their specific product teams.

Quality AssuranceDatabase DesignJiraNotion+4

figma·Jan 25, 2022·3 min readCurated summary

Little Big Updates: Dispatches from Quality Week | Figma Blog

Figma’s Quality Weeks dedicate focused time to bugs, edge cases, and features that technically work but feel broken. The post argues that software quality is not defined only by code correctness: browser behavior, user expectations, perceived responsiveness, and inconsistent support can all make a product feel buggy. Small fixes—sometimes only a few lines of code—can therefore have disproportionately large effects. ## Quality Week and the macOS Accent-Menu Bug - Figma periodically holds Quality Weeks to address forgotten bugs, oddities, and issues outside normal feature work. - A macOS accent-menu problem caused letters to repeat or fail to appear. - The issue involved the complex sequence of keyboard and text-input events handled by the operating system and browser before Figma received them. - Molly developed a fix of fewer than ten lines that worked in Firefox and Safari and supported both keyboard and mouse input. - Chrome, Figma’s most widely used browser, still exhibited the problem, showing that a technically correct fix may not solve the user-facing issue for most customers. - She also reported the underlying browser issue to Chrome developers for a possible future fix. ## The Difference Between a Technical Bug and a Real Bug - In theory, a bug consists of: - How the software is supposed to behave. - How its current behavior differs. - Real-world systems make those definitions ambiguous: - Intended behavior may not be clearly defined. - A perfect fix may be impractical or impossible. - Some problems require choosing a new, less-buggy direction rather than restoring the old one. - Historical examples such as Y2K, the Pentium FDIV error, and the Mars Climate Orbiter failure demonstrate that identifying a problem and knowing its cause does not automatically make it easy to resolve. - Figma treats issues as worthy of attention when they materially affect users, even if they do not fit a strict engineering definition of “bug.” ## When Missing Support Feels Like a Bug - HEIC image support illustrates the difference between “never implemented” and “broken” from a user’s perspective. - Figma’s inconsistent handling of HEIC files—especially images dragged from iPhones and iPads—made the product feel unreliable. - Sawyer added support in 98 lines of code. - The new support exposed a second usability problem: large, high-resolution HEIC files could take many seconds to process, during which the canvas appeared to ignore the drop. - Jackie identified that a loading state could communicate progress and prevent users from assuming the feature had failed. - The example shows that fixing one problem can reveal another, and that perceived responsiveness is part of product quality. Figma’s approach is to prioritize issues based not only on technical correctness but also on how users experience the product. Quality work should address the small inconsistencies that make software feel unreliable, particularly when a modest implementation can remove substantial frustration.

Read original(opens in new tab)

Quality AssuranceFigmaFigjamMacos+3

figma·Jan 24, 2018·2 min readCurated summary

Bug Bashing Party at Figma During Quality Week | Figma Blog

Figma’s Quality Week is a company-wide pause from new feature development to focus on fixing accumulated bugs and polishing existing functionality. The initiative reflects Figma’s belief that small usability problems compound for designers who spend hours in the product. By making quality work a recurring tradition, Figma aims to deliver a smoother, more reliable professional tool while also giving employees opportunities to explore unfamiliar parts of the codebase. ## A Company-Wide Focus on Quality - Figma launched its first official Quality Week in early 2017. - Engineers and designers temporarily paused their regular projects to address: - Annoying but non-critical bugs - Broken or incomplete features - Improvements to existing workflows - The company found that focused maintenance work could be as valuable as continuously shipping new features. - Quality improvements are especially important because users spend long periods working in Figma, making small imperfections increasingly disruptive. ## Quality Week 2018 Improvements - Two engineering teams collaborated on a broad set of bugs and prioritized issues that affected Figma’s professional quality. - Notable fixes included: - **Figma Mirror:** Improved stability and reduced crashes in the mobile mirroring app. - **Sketch import:** Added drag-and-drop importing into the editor and improved text-import accuracy. - **Chromebook support:** Enabled users to hold the search key and drag to duplicate objects. - **Layer panel behavior:** Made it easier and more intuitive to nest layers into groups and frames. - Figma acknowledged that the product was not bug-free, but planned to continue focused quality efforts throughout the year. ## Benefits for the Team - Quality Week helped developers and designers work in parts of the codebase outside their usual areas. - The event encouraged collaboration across teams and made otherwise routine maintenance work enjoyable. - Figma celebrated achievements with awards, including recognition for fixing the company’s oldest known bug—an issue affecting Windows users since 2015. ## Feedback and Ongoing Support - Many bugs addressed during Quality Week were reported by Figma’s user community. - Figma encouraged users to submit feedback through: - The in-product Help menu - Twitter - The community forum - Email support - The company emphasized an all-hands support model, where users might interact with engineers or even the CEO. Figma’s approach shows that dedicated time for bug fixing and product cleanup can complement innovation rather than compete with it. Regular quality-focused periods, combined with continuous user feedback, help maintain a reliable and polished product as it evolves.

Read original(opens in new tab)

Quality AssuranceFigmaDesign ToolsWindows+4