一个常见的错误是让一个团队负责特定的产品，而不是一个一般性的问题。产品是问题的解决方案。解决方案的寿命可能很短，并且产品可以被更好的解决方案替代。不过，一个问题如果选得好的话能够经久不衰。
将团队身份固定到特定的解决方案（“我们是管理 Git 仓的团队”）会随着时间的推移导致各种焦虑。如果很大比例的工程师想切换到新的版本控制系统，该怎么办？团队很可能会“严防死守”，捍卫其解决方案，并抵制变化，即使这不是组织的最佳路径。团队会盲目地固执己见，因为解决方案已经成为团队身份和自我价值的一部分。
如果团队变成了负责一个问题（例如，“我们是向公司提供版本控制的团队”），那么随着时间的推移，团队就可以腾出手去尝试不同的解决方案。
- 摘自《谷歌软件工程》p126
在我读上面这段文字的时候，我意识到这是一个很深的思维转变，但是我没办法应用到我的质量思维中，于是我求助了gemini，得到了下面的知识。
一句话总结：
不要爱上你的测试用例或工具，要爱上“挖掘真相并保障交付质量”这个挑战。 这样，你才能在技术迭代中永远立于不败之地。
警惕“工具人”陷阱：不要定义自己为“某个工具的使用者”
- 文中的错误： “我是负责管理 Git 仓的团队”。
- 测试的映射： “我是写 Selenium 脚本的”、“我是做 JMeter 压测的”、“我是负责维护这套自研自动化框架的”。
- 启示： 如果你把自己定义为“Selenium 专家”，当 Playwright 或 Cypress 等更高效的工具出现时，你可能会下意识地抵触，因为新技术威胁到了你的“身份地位”。
- 建议： 你的身份应该是**“交付质量保障者”**。工具只是实现目标的手段。当更好的方案出现，你应该主动拥抱，而不是守着旧工具“严防死守”。
2. 关注“问题”而非“过程”：测试的本质是解决什么？
- 文中的观点： “产品（方案）是问题的解决方案，寿命可能很短；而问题能够经久不衰”。
- 测试的映射：
-
- 方案（易变）： 手工用例、自动化脚本、特定的测试环境、Bug 管理流程。
- 问题（恒久）： “如何让产品发布更稳、更快？”、“如何降低线上故障率？”、“如何让开发在写代码时就发现逻辑错误？”。
- 启示： 不要沉迷于“我今天写了多少条脚本”，而要思考“这些脚本真的解决了软件质量不可控的问题吗？”。如果有一天不写脚本也能保障质量（比如通过更高级的静态分析或可观测性手段），你应该感到高兴，因为你解决了核心问题。
3. 避免“领地意识”：不要让你的测试资产变成沉没成本
- 文中的警示： 团队会为了捍卫自己的方案而“抵制变化”。
- 测试的映射： 你是否遇到过这样的情况：某个老旧的自动化套件维护成本极高，测出的 Bug 却很少，但因为是你亲手写的，你就不舍得废弃它？或者当开发提出想自己写端到端测试时，你觉得他们侵犯了你的“领地”？
- 启示： 这种固执会让你成为组织的阻碍。这段话告诉你， “解决质量问题”是大家共同的目标。如果开发写单元测试、推行 DevOps 能够更有效地解决质量问题，测试工程师应该腾出手来去尝试更深层次的质量挑战（如稳定性工程、全链路压测），而不是死守着那几行脚本。
4. 提升你的职业“护城河”
- 职业焦虑的根源： 很多测试工程师感到焦虑，是因为他们负责的是“特定产品/特定工具”，一旦产品下线或工具过时，价值就归零了。
- 转型的逻辑：
-
- 如果你负责“测这个 App 的功能”，App 没了你就失业了。
- 如果你负责“解决复杂分布式系统的可靠性问题”，无论公司做什么产品，无论用什么技术栈，你永远是核心人才。
