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

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，测试应该去探索产品，探寻产品应该做成什么样子，探查市场的需求，看看产品真正能做到什么，看看产品是否合适当前的要求，质疑流程，改善流程，帮助设计产品，改善产品，帮忙支持产品，帮忙推进产品，并始终和团队一起交付有价值的产品。

"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?
如果我能更好地理解他们需求，我就能更加有效地运用这个软件。

1. Each time a tester questions about an ambiguous, incomplete or missing requirement, she is adding value by questioning the process.
   测试质疑模糊，不完成或缺少需求时，就是带来价值。
2. Each time a tester questions the testability of a requirement or even a product, she is adding value by questioning the product requirements.
   测试质疑需求或者产品的可测试性时，就是带来价值。
3. 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.
   测试审查设计，并质疑设计的有效性时，就是带来价值。
4. 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.
   测试质疑代码时，就是带来价值。
5. 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时，就是带来价值。