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

　　文章一——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?

　　如果我能更好地理解他们需求，我就能更加有效地运用这个软件。

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