这套系统里的工作如何运转？
每个版本先在「计划」列建卡，划定测试范围：新功能、最高风险区域、覆盖的机型与浏览器。候选版本就绪后进入「执行」列，测试工程师按用例逐步执行并记录每条结果。发现的每个缺陷生成「缺陷」卡片，写明复现步骤、预期与实际结果、严重级别，由工程师认领修复。修复后的缺陷回到「验证」列，由另一位测试工程师复测——确认修复没有碰坏别处。当关键缺陷清零，母卡进入「放行」列并出具正式建议；数字归入「报告」列：执行了多少用例、发现多少缺陷、哪些区域缺陷集中。
聊天是测试期间的作战室：阻断发布的关键缺陷立即通报；“这是有意设计还是缺陷”的疑问与工程师一分钟说清，免得产生一张被驳回的卡片。但铁律是：聊天里敲定的结论要记回缺陷卡片——看板才是记录，记忆不是。
质量经理写「计划」、分派执行范围，掌握放行建议的决定权——只要还有关键缺陷，就是他拦下发布。测试工程师执行并按统一标准写缺陷，工程师认领修复后送回「验证」。本系统的原则是：谁写的缺陷不由谁验证修复；放行是拿数字说话的决定，不是“感觉差不多”的笼统印象。
谁负责什么？
这套系统中的运营角色，以及每个角色在日常工作中的职责——可以原样指派给你的团队，也可以按你们的实际情况调整。
质量经理
编写测试计划、分配范围，复核关键缺陷，用数字签署「放行」或叫停的建议。
测试工程师
执行计划用例，按清晰步骤与分级严重度写缺陷，在「验证」列互测同事的修复。
开发工程师
认领「缺陷」卡片并修复，送回「验证」时写明改了什么、需要回归什么。
从第一天起就为你准备好什么？
系统单元
- 任务 — 带有工作流列和执行卡片的看板
- 聊天 — 团队快速日常协调频道