目录
Confusion in the Literature(文献中的困惑)
Tester as an Agile Team Member(测试员是敏捷团队成员)
Tester Responsibilities on an Agile Team(测试人员对敏捷团队的责任)
原链接
https://www.stickyminds.com/article/role-testers-agile-environment
翻译内容
John Stevenson - 2014年11月10日
Summary(摘要):
There are many diverse ideas about what being a tester means in agile development environments. This leads to confusion between how agile testers and agile QA “fit” into agile teams and what the QA tester responsibilities are. John Stevenson explains why there appears to be some fear and a little distrust of agile environments among some testers, then offers suggestions for dealing with their confusion.
关于敏捷开发环境中测试人员的意义，有许多不同的看法。 这带来了敏捷测试人员和敏捷QA如何“适应”敏捷团队，以及QA测试人员职责之间的混淆。 John Stevenson解释了为什么在一些测试人员中似乎有一些恐惧和对敏捷环境的一点点不信任，然后提出了应对他们疑惑的建议。
正文
At my day job we’ve been driving toward a more agile way to develop software. Just like with any other change in work style, there is some confusion and, for a few, a little bit of fear. People are being asked to step out of their comfort zones and embrace a constantly changing, dynamic way of working. And—dare I say it—testing may be the most disrupted of the software roles on agile projects.
在我的日常工作中，我们一直在以更灵活的方式开发软件。 就像工作中的任何其他变化一样，有一些混乱，并且，少数人而言，一点点恐惧。 人们被要求走出自己的舒适区，拥抱不断变化，充满活力的工作方式。 而且 - 我敢说 - 测试可能是敏捷项目中软件角色中被中断最多的。
What do we think the role of a tester is? Can we even agree?
我们认为测试人员的角色是什么？ 我们可以同意吗？
There are many diverse ideas about what being a tester means in agile development environments. This leads to confusion between how agile testers “fit” into development teams and what their role is.
关于敏捷开发环境中测试人员的意义，有许多不同的看法。 这带来了敏捷测试人员如何“适应”开发团队与他们的角色之间的混淆。
In this article, I will start by looking at my experiences to explain why there appears to be some fear and a little distrust of agile among some testers, then offer suggestions that may be of use to testers for dealing with their confusion.
在本文中，我将首先通过回顾我的经验来解释为什么有些测试人员似乎存在一些恐惧和对敏捷的一点点不信任，然后提供可能对测试人员处理他们的困惑有用的建议。
Confusion in the Literature(文献中的困惑)
One of the few things people tend to agree on is that to deliver working software quickly, teams need automation in place which leads to the “testers must code” discussion. Experts like Elizabeth Hendrickson, Rob Lambert, and Michael Larsen have suggested that coding is the next logical step for testing, but there is no overall consensus on that. James Bach’s comment to Rob Lambert’s article suggests there is more for testers to do than only learning to code:
人们倾向于同意的少数事情之一是，为了快速交付工作软件，团队需要自动化，这导致“测试人员必须编写代码”讨论。 像Elizabeth Hendrickson，Rob Lambert和Michael Larsen这样的专家建议编码是测试的接下来的合乎逻辑的步骤，但对此没有达成全面的共识。 James Bach对Rob Lambert的文章的评论表明，除了学习编码外，测试人员要做的事情还有很多：
. . . [T]elling testers that they need to learn to code will discourage interesting thinkers from becoming testers. We can’t assume that people who like to program are just like other people in every important way.
...需要学习编码的测试人员会阻止有趣的思想家成为测试人员。 我们不能假设喜欢编程的人就像其他人一样重要。
Tester as an Agile Team Member(测试员是敏捷团队成员)
Historically, testing activities have happened at the end of the development (coding) effort because a tester’s responsibilities included proving the requirements were met, ensuring the software worked, and finding bugs in the mostly finished product.
从历史上看，测试活动是在开发（编码）工作结束时发生的，因为测试人员的职责包括证明满足需求，确保软件正常工作，并发现即将完成的成品中的缺陷。
The Agile Manifesto flips around titles and roles and says to focus on individuals and interactions over processes and tools.
敏捷宣言颠倒了头衔和角色，并表示要关注个人和流程与工具之间的互动。
This means that as testers, there is a need to work as members of the team and to engage with others within the team, regardless of titles. If you see a task that needs doing and you have the skills to do that task, then just do it.
这意味着作为测试人员，无论头衔如何，都需要作为团队成员工作，并与团队中的其他人交流。 如果您看到需要执行的任务，并且您具备完成该任务的技能，那么就做吧。
Agile processes mean testers are part of the delivery team and should try to be involved from the beginning of the project. Testers should have the ability to “switch hats” and be involved to support and assist the team.
敏捷流程意味着测试人员是交付团队的一部分，并且应该尝试从项目一开始就参与其中。 测试人员应该具备“切换帽子”的能力，支持并协助团队。
The following are only a few examples of the vast number of roles you could be taking on.
以下只是您可以承担的大量角色的几个示例。
Test Architect(测试架构师)
One huge benefit of small slices of work, such as a story taking a few days to complete, is that design meetings happen all the time and can be a lot easier to get invited to. Testers can contribute to these meetings, asking “What if . . .” types of questions, such as “What if a user did this?” or “What if the server we call with the web services does not respond?”
小片工作的一个巨大好处，例如需要几天才能完成的事，是设计会议一直在进行，并且可以更容易被邀请。 测试人员可以为这些会议做出贡献，询问“如果... “类型的问题，例如”如果用户这样做会怎么样？“或”如果我们使用Web服务调用的服务器没有响应怎么办？“
During the design discussions, try to create a model of what you think the system will look like. If you find yourself being confused about the information being presented or you feel something does not seem right, this is the moment to ask questions to clarify. The answers you get could be useful for noting areas to explore at a later date. Offer suggestions about how it would be easier to test if development were completed in a certain way, and look for ways to make the system design testable.
在设计讨论期间，尝试创建一个您认为系统外观的模型。 如果您发现自己对所呈现的信息感到困惑，或者您觉得某些事情似乎不对，那么现在就是提出问题的时刻。 您获得的答案可能有助于记录以后探索的区域。如果开发已经以某种方式完成了， 提供有关如何更容易展开测试的建议，并寻找使系统设计可测的方法。
If there are uncertain areas about how a feature could or will be implemented, this would be a great area for you to explore after development. Make a note and maybe create a test charter in your test plan, perhaps using a mind map.
如果有关于如何实现或将要实现某个功能的不确定区域，这将是您在开发后进行探索的一个很好的地方。 记下来并在测试计划中创建测试章程，也许可以使用思维导图。
Consider from the information provided what could require checking and make a note of possible automation tasks. You may find yourself contributing to what checks are automated as acceptance or unit tests.
从提供的信息中考虑可能需要检查的内容，并记录可能需要自动化的任务。 您可能会发现自己有助于将那些已经自动化的检查，来验收或单元测试。
Test Automator(测试自动机)
Automating checks does not have to be your job; it might be something you do part time, as needed. You don’t always need to write code or be a skilled programmer to do automation. Many tools exist that simplify the process. Knowing how to write code might be a useful skill if you feel it will benefit the team. If you do not have an interest in learning to code, it would be a good idea to at least try to learn to read code.
自动检查不一定是你的工作; 根据需要，你可以把它当做兼职。 您并不总是需要编写代码或成为熟练的程序员来进行自动化。 存在许多简化过程的工具。如果您认为它将使团队受益，知道如何编写代码可能是一项有用的技能。 如果您对学习编码没兴趣，那么至少尝试学习阅读代码。
Some of the frameworks used extensively for test automation use English words and phrases, such as the Cucumber, Gherkin, and FitNesse frameworks.
一些广泛用于自动化的测试框架使用英语单词和短语，例如Cucumber，Gherkin和FitNesse框架。
They follow similar approaches for creating automated checks. First, create scenarios in a very high-level language that loops a bit like English; then run a parser over the scenario to automatically create “stub” functions; finally, fill in the functions with actual code.
他们遵循类似的方法来创建自动检查。 首先，用一种高级语言创建场景，这种语言有点像英语; 然后在场景上运行解析器以自动创建“桩”函数; 最后，用实际代码填写函数。
For Cucumber, step definitions can be written in many different programming languages, and the level required to write these types of definitions is not too intense.
对于Cucumber，步骤定义可以用许多不同的编程语言编写，编写这些类型的定义所需的水平不是太高。
For more information on learning to code from a testing perspective, I recommend the excellent book Java For Testers by Alan Richardson.
有关从测试角度学习编码的更多信息，我推荐Alan Richardson出版的一本优秀的书——《Java For Testers》。
Test Explorer(测试探索者)
Because of the tight timeboxes in agile, the skill of exploratory testing becomes incredibly powerful and valuable. This is where a traditional tester can shine by exploring the product to reduce risk and uncertainty.
由于敏捷项目中的时间紧迫，探索性测试的技能变得非常强大和有价值。 这里可以让传统测试人员通过探索产品来降低风险和不确定性。
Exploratory tests are one-time investigations into a specific risk, not repeatedly running the same checks over and over. Two places to pull test ideas from are those story kickoff design discussions and communicating with others within the team. Use this information to uncover where there is ambiguity in the system or areas where people have raised concerns or questions. These are strong indications that there could be issues that have yet to be uncovered.
探索性测试是对特定风险的一次性调查研究，而不是一遍又一遍地反复运行相同的检查。 获取测试灵感的地方有两处：那些故事启动设计讨论和与团队内其他人沟通。 使用此信息可以发现系统中存在歧义的地方或人们提出疑虑或问题的地方。 这些都是明显的迹象，表明了可能存在尚未发现的问题。
Being an explorer is about mapping the system as you go and then reassessing your voyage as you discover exciting and interesting bits of information. As testers, we need to uncover assumptions and incorrect or missing information. Most importantly, we need to find out what the product actually does rather than what we believe it does or how it has been documented to behave.
作为一名探索者，您可以随时随地绘制系统，然后在发现令人兴奋和有趣的信息时，重新评估您的航程。 作为测试人员，我们需要发现臆测，及不正确或缺失的信息。 最重要的是，我们需要找出产品实际上做的是什么，而不是我们相信它做什么，或者文档中记录的它的行为。
This does not mean you should approach the process in a random, unplanned, or unstructured way. Your plan does not have to be too detailed, but it should be just enough to get you started. As you uncover more about the system and update your plan with the new evidence you have, you may want to make your work more systematic and document what you tested (as opposed to what you plan to test). Session-based test management can be a great way to manage the test effort and works well in agile environments, especially with kanban-style boards.
这并不意味着您应该以随机，无计划或非结构化的方式进行该过程。 您的计划不必太详细，但它应该足以让您入门。 当您发现有关系统的更多信息，并使用您拥有的新证据更新计划时，您可能希望您的工作更加系统化，并记录您测试的内容（而不是您计划测试的内容）。 基于会话的测试管理是管理测试工作的好方法，并且在敏捷环境中运行良好，尤其是使用看板时。
Test Reporter(测试报告人)
One of the tasks I feel is most overlooked within agile development is the tester’s responsibility to share information and knowledge, which is so much more than simplistic pass/fail details. The agile tester should be reporting useful and valuable information, such as:
我认为在敏捷开发中最容易忽视的任务之一是测试人员共享信息和知识的责任，这不仅仅是简单的通过/失败细节。 敏捷测试人员应报告有用且有价值的信息，例如：
- Issues or bugs they have uncovered他们已经发行的问题或缺陷
- Areas they didn’t have time to explore他们没有时间探索的地方
- Recurring defects that could be prevented可以预防的重复缺陷
- Blocks, wait states, and other problems obstructing additional testing阻塞，等待状态和阻碍测试的其他问题
Agile testers need to be communicating as much as possible with the rest of the team, keeping them informed of what they have found. A great indication of a good test reporter is that when it comes time for the scrum meeting, there are no surprises for the rest of the team—the tester has already informed everyone about their findings.
敏捷测试人员需要尽可能地与团队的其他成员进行沟通，让他们了解已经发现的内容。 一个好的测试报告人的一个很好的迹象是，当scrum会议时，团队的其他成员并没有惊喜 - 测试人员已经告知了每个人他们的发现。
Normally these conversations are about clarifying assumptions and ambiguity, or confirming a defect really is a defect before raising it on the bug-tracking system. The tester in these situations needs to be a salesperson, a negotiator, a user advocate, a bit of a journalist, an investigator, a scientist, and a psychologist; and that’s just to start!
通常，这些对话是关于澄清臆测和模糊内容，或者确认在错误跟踪系统上提出缺陷之前，确认缺陷确实是一个缺陷。 在这些情况下，测试者需要是销售人员，谈判者，用户拥护者，记者，调查员，科学家和心理学家; 而这只是开始！
Often, testers fall into a habit of simplistic reporting about how many tests ran or what percentage is done. It is better to tell the team what has and has not been tested and base completion upon the evidence of what was uncovered.
通常，测试人员习惯于简单地报告有多少测试运行或完成了多少百分比。 最好告诉团队什么已经测试和什么尚未测试，并在已发现的证据上的完成。
Tester Responsibilities on an Agile Team(测试人员对敏捷团队的责任)
The purpose of a tester in agile environments is about getting things done rather than roles. As a tester, you should try to act as a service to the project and ask yourself, “What can I do that is best for the team or for the project?”
敏捷环境中测试人员的目的是完成工作而不是角色。 作为测试人员，您应该尝试给项目提供服务，并问自己，“我能做什么对团队或项目最好？”
There are many other roles a tester carries out during testing, such as a coach or mentor, a service provider, a sage, a confidant, and a person who is willing to listen as well as challenge others for the benefit of the team.
测试人员在测试期间还有许多其他角色，例如教练或导师，服务提供者，圣人，知己，以及愿意倾听并为团队的利益挑战他人的人。
关于作者
“The opinions expressed in any public works are my own views and not those of any company I have or do work for"
“在任何公共场合中表达的观点都是我自己的观点，而不是我所拥有或为之工作的任何公司的观点”
Having been involved in testing for over 20 years and within the IT industry for more than 24 years I am still surprised with how exciting I find it and how much I continue to learn about things that are new.
我已经有了超过20年的测试经验，及在IT行业超过24年的经验，但我仍然对我发现它的激动，以及我对新事物的持续学习程度感到惊讶。
I have a passion for learning and love to learn about new things. I have an interest in many things such as social science, psychology, photography and gardening. I keep involved within the testing community and write a testing blog (www.steveo1967.blogspot.com) and can be found regularly tweeting (@steveo1967).
我热爱学习，喜欢学习新事物。 我对很多事情很感兴趣，比如社会科学，心理学，摄影和园艺。 我一直参与测试社区并撰写测试博客（www.steveo1967.blogspot.com），并且可以定期发送推文（@ steveo1967）。
I am keen to see what can be of benefit to software testing from outside the traditional channels and as such I like to explore different domains and see if there is anything that can be linked back to testing. I care about the testing community, like to be involved and like to be social.
我希望看到传统渠道之外的软件测试有什么好处，因此我喜欢探索不同的领域，看看是否有任何可以链接回测试的东西。 我关心测试社区，喜欢参与社交。
I feel I have a wide variety of experience within testing and currently I am mentoring and training others in exploratory testing and SBTM whilst looking for opportunities to introduce approaches from other crafts such as anthropology, ethnographic research, design thinking, cognitive science and many others.
我觉得自己在测试中有各种各样的经验，目前我正在指导和培训其他人进行探索性测试和SBTM，同时寻找机会介绍其他工艺的方法，如人类学，人种学研究，设计思维，认知科学等等。
I am currently writing a book called the Psychology of Software #Testing - https://leanpub.com/thepsychologyofsoftwaretesting
我目前正在写一本名为“软件心理学”的书#Testing - https://leanpub.com/thepsychologyofsoftwaretesting