5 Do's

1. Write testable code; test first：TDD 在编码前定义失败条件，支持重构、文档和长期维护。
2. Automate regression testing：重复验证交给自动化，让人处理 exploratory work 与复杂判断。
3. Use fit-for-purpose cloud environments：以可扩展环境覆盖设备、浏览器、OS、负载、data residency 与恢复需求。
4. Use low-code where it fits：复用测试资产、降低入门门槛，但保留高级情境的代码能力与维护责任。
5. Plan a testing strategy / pyramid：大量快速 unit tests，中层 integration tests，少量高成本 E2E tests；比例按项目风险调整。

5 Don'ts

1. 不要排除 stakeholder 与技术团队的共同决策：业务变更必须同时披露回归风险、时间与质量代价。
2. 不要把“零 bug”当作脱离情境的目标：以 severity、用户暴露概率、可复现性和 fix ROI 做风险优先级。
3. 不要选择不适合团队和产品的技术：评估技能、维护成本、应用类型、集成与可持续性。
4. 不要让 developers 与 quality engineers 成为孤岛：QE 应从 requirements、acceptance criteria 和 sprint planning 就参与。
5. 不要把 manual 与 automation 当成二选一：自动化负责可重复反馈，人负责探索、体验与判断。

Testing pyramid 的含义

• Unit：快、便宜、定位精确，适合大量运行。
• Integration：验证 database、file system、service 与 component 的真实协作。
• E2E / UI：最接近用户路径，但较慢、昂贵且可能 flaky，应聚焦关键旅程。

批判性阅读

IE Project 决策

• 绘制自己的 test pyramid，并写明每层覆盖什么风险。
• 选择 1 个适合自动化与 1 个必须人工探索的场景。
• 用 proof of concept 比较工具，而不是只看“免费”或功能数量。
• 记录 stakeholder 同意承担的 residual risk。