到底哪些事情属于测试人员的职责？

最近两天看了不少关于测试价值，该如何做测试，该如何参与开发过程的文章，再加上我自身的一些经历，有感而发，聊下自己的价值观。

文章一——T-Shaped Testers and their role in a team

这实际是一篇老文章，但里边的观点——测试应该做些什么，我是很是赞同。以下是节选并附上简单翻译（如果想看完整版，请点击文章标题）：

I've never been comfortable with the concept of a separate test team and associated "phases" of testing.
我太不喜欢“不同的测试团队”和“不同的测试阶段”的概念。

I believe that finding bugs is just one aspect of a testers role.
I don't think finding bugs is just the responsibility of the tester either.
测试不仅仅是找到BUG。

I also believe that testers should use their skills in other parts of the project cycle, whether that cycle is two weeks or two months or two years.
One person capable of fulfilling a few roles reasonable well seems like good value and a good asset to delivering value. Even in traditional environments with more structured roles T-shaped people can be found serving multiple roles.
测试应该更多参与到项目生命周期，做更多的事情。

Sadly, many people (not just testers) are pigeon holed in to their role, despite having a lot more to offer.
杯具的是大部分人被限制在他们角色中。
I believe that testers, actually – anyone, can contribute a lot more to the business than their standard role traditionally dictates. The tester's critical and skeptical thinking can be used earlier in the process. Their other skills can be used to solve other problems within the business. Their role can stretch to include other aspects that intrigue them and keep them interested.

I believe testing is more than finding bugs; it's about exploring the product, discovering what the product needs to be, discovering the market needs (i.e. A/B Testing), discovering what the product actually does, working out whether the product is suitable for the context of use, questioning the process, improving the process, helping to design the product, improving the product, helping to support it, helping to promote it and ultimately working with the team to deliver value.
我认为测试远不止是寻找BUG，测试应该去探索产品，探寻产品应该做成什么样子，探查市场的需求，看看产品真正能做到什么，看看产品是否合适当前的要求，质疑流程，改善流程，帮助设计产品，改善产品，帮忙支持产品，帮忙推进产品，并始终和团队一起交付有价值的产品。

我们测试人员应该关注得更多，不仅仅停留来找BUG上，停留在测试执行，设计或者管理上。

文章二——On Testing Purpose and Documented Requirements

作者分享了，他为什么要跟BA谈跟商务(Business)谈，当他去测试一个软件的时候。以下是节选并附上简单翻译（如果想看完整版，请点击文章标题）：

"But isn't that what the BA is supposed to do?"

Oh, excellent question.

Certainly a good BA can gain that information and pass it on to the team. However, with each layer or remove introduced in the information flow, something changes. Information may be lost. Other things may be added. The "clarification" may critically change part of the message. If I can get as close to the people doing the work as I can, I often learn stuff that is important to me as a tester that other people shrug off as unimportant.
信息会在沟通过程丢失。

If I can understand their needs better, I can exercise the software more efficiently. If the tests I write and run do not explicitly exercise "the requirements" are they really required? Are they interpretations of something?
如果我能更好地理解他们需求，我就能更加有效地运用这个软件。

就我个人而言，很难想象一个不了解商业需求的测试人员，会做得很好，即使是初级测试人员，只是在执行测试用例。知道一个软件、一个功能的目的，知道它是用来解决什么样子的问题，更多的业务知识会为测试人员带来很多的灵感。

文章三——The Value of Testing & Test Teams

原文作者提到了测试能带来价值的5种方式，以下是节选并附上简单翻译（如果想看完整版，请点击文章标题）：

Each time a tester questions about an ambiguous, incomplete or missing requirement, she is adding value by questioning the process.
测试质疑模糊，不完成或缺少需求时，就是带来价值。
Each time a tester questions the testability of a requirement or even a product, she is adding value by questioning the product requirements.
测试质疑需求或者产品的可测试性时，就是带来价值。
When a tester reviews a design and questions the validity of the design, she is adding value by blocking a faulty design being built in to a faulty product.
测试审查设计，并质疑设计的有效性时，就是带来价值。
Each time a tester questions the code, she adds value by stopping defects seeping into the next phase of product development. You might say,”Not every tester reviews the code.” True, but isn’t it common to have entry criteria for testing that requires evidence of code review or unit testing? If you are a developer-tester, you know how to peer-review the code.
测试质疑代码时，就是带来价值。
When a tester finds even a single defect, she is adding value by exposing the hole in the product. The product owner may delay or defer the fix for it for product delivery timelines, but they cannot ignore the existence of a defect in the product.
测试发现BUG时，就是带来价值。

测试不应该只把眼睛放在具体的产品上，就应该考虑整个软件开发过程中每个环节上去，看看是不是能发现BUG。只要能带来价值都是好事情。

个人观点

测试不仅需要测试产品，而且需要测试需求、设计等各个环节以及过程本身。关注如何做对的事情，减少不必要浪费。

我们都知道一个观点，越早发现BUG，修改的代价会越低。测试就需要尽早参与到开发过程的每一个环节中去。
我不知道目前国内公司的普遍情况，测试能做些什么事情，但我知道的确有些“大”公司，流程分得较细，传统的测试加入较晚，参与的阶段有限，比如，需求文档创建时的Review就不会参与；限制传统测试人员做UAT的事情，因为还有专人在专门的UAT阶段做UAT。说句题外话，真不建议应届生加入这种公司，过程过僵化，测试能接触得东西过少，能学习到就过少。

这里想说得是，如果流程分得细，阶段明显，代价会更大，需要招更多的人，知识传递更费时费事；需求阶段，设计阶段Review的人，如果没有带着一些测试思维来做Review，效果很可能有些折扣。就个人的眼光看来，还不如直接让测试更多地更早地参与项目，为整个过程服务，不仅仅为产品测试服务。对公司，减少了消耗，对员工，增强了技能，开拓了道路。

敏捷倡导跨功能的团队，各种角色的成员尽量都坐在一块。其目的之一，使各个角色更好的协作，也使各个角色间的界线有些“模糊”，比如，现在蛮出名的DevOps角色，就是开发和运维的混合体。我目前期待能够出一个测试和分析师（BA）或者领域专家的混合体，一个能分析、判断业务，能和商务沟通，能做用户代表，能测试、能检查设计和产品，保持测试思维，持续关注价值的角色。姑且先东施效颦，仿造一个合体词出来，TestAnal或者Testlyst。