一周一翻译 A Day in the Life of a Quality Assurance Tester

A Day in the Life of a Quality Assurance Tester
质量保障测试人员的一天


     This paper will discuss the day to day activities of being a tester and instilling quality into software. Begins with a discussion of what is software testing, what is quality assurance, how do the two relate to each other, what are the daily tasks involved in software testing and Quality Assurance, what are the pain points and areas for improvement, and how an individual tester can add value to the development process no matter what type of software development life cycle.
    这篇文将讨论测试人员日常工作，及怎样将质量灌输到软件中。我们将先讨论什么是软件测试，什么是质量保障，它们之间如何关联？软件测试和质量保障涉及到哪些日常工作，有哪些问题点和领域可改善，以及作为一个测试者，如何在任何软件开发生命周期中，都能对开发过程提供价值呢。

What is Software Testing?
什么是软件测试？

     Software testing is the systematic process by which an analyst uncovers defects in software. What are defects, you might ask? Defects are flaws in the code that cause a software application to break. While no software is completely defect- free, it is the aim of testers to reduce the number of defects found in software and to instill quality in the software application.  Software testing includes the process of validating that the software has incorporated the user requirements present in the Software Requirements Specification document and meets users’ needs.  Software testers analyze software to see if the software conforms to user expectations. Software testing is one of the activities designed to adequately assure that the software has the necessary quality required by the users.
    软件测试是分析者用来发现软件缺陷的有组织的过程。你可能会问，什么是缺陷？缺陷是代码中导致软件应用中断的问题。没有任何软件是完全无缺陷的，测试者的目标是减少在项目中找到的缺陷，并且将质量灌输到软件应用中。软件测试包括检验软件不能满足用户需求规格说明中描述的需求及不能满足用户所需的过程。软件测试者通过分析软件来获知软件是否符合用户的期望。软件测试是一种设计来适当保障软件符合用户所需质量的活动。

What is Quality Assurance?
什么是质量保障？

     Quality Assurance is the sum of all the activities designed to adequately assure that all the software processes in place have been done in an effective and efficacious manner. It involves both doing testing right and doing the right testing.  Software Quality Assurance checks that the software processes are correct and are in compliance with the standards that operate within an organization. Quality Assurance involves more than software testing and yet software testing is necessary to the Quality Assurance profession. Without it, one cannot say that a Quality Assurance process is in place.
How do the two relate to each other?
    质量保障是恰当的确保软件过程在有效的方式下，被有条不紊地被执行的所有活动的汇总。它涉及到正确的做测试和做正确的测试。软件质量保障检查软件过程是否正确且符合组织内部运作的标准。质量保障涉及到软件测试外更多的内容，但软件测试依然是质量保障专业需要的内容。缺了它，就不能称保证质量保障过程是正确妥当的。它们之间如何互相关联呢？
     As you can see, Software Testing is just one aspect of Software Quality Assurance. Software Testing is usually called Quality Control. QC is a component of a QA plan in an organization.  In some organizations, the Software Testing role is split from the Software Quality Assurance Analyst role. In such an organization, Software Quality Assurance involves completion of technical checklists and document reviews to verify that both the software and documents are in compliance with standards.
    就如你看到的，软件测试只是软件质量保障的一个方面。软件测试通常被称作为质量控制。在组织中，质量控制是质量保障计划中的一个组件。在一些组织中，软件测试角色从质量保障分析师角色中被剥离出来。在这样的组织中，软件质量保障涉及到完成技术检查列表和文档评审以检验软件和文档均能符合标准。

Daily Tasks Involved in Software Testing and Quality Assurance
软件测试和质量保障的日常任务

      Once a Software Requirements Specification (SRS) document is produced, the tester “tests” the document to make sure that the requirements are complete, correct, consistent, and testable. In an agile environment, software requirements are tested as they are written.  In a Waterfall SDLC, first the SRS is written and then testing the document occurs. On the topic of completeness, correctness, consistency, and testability: completeness is measured by whether or not the requirement tells you where to test, how to test, and what to test. Correctness implies that you know something about the application being tested. You have to know a little bit about the software to know if the requirement is correct. A consistent requirement is one that has no logical flaws. A testable requirement is one for which you can write a test case.
    软件需求规范一旦被产出，测试人员就“测试”文档确认需求是否完整、正确、一致，和可被测试。在一个敏捷的环境中，软件需求一旦编写出来就会被测试。在瀑布式的软件开发生命周期中，软件需求规范先被编写出来，然后测试它的完整性、正确性、一致性和可测试性。完整性通过需求是否能告诉你在哪里测试、如何测试及要测试什么来衡量。正确性意味着你知道要测试的应用的一些方方面面。你必须对你要测试的软件有些了解，才能知道需求是否正确。一致性是指需求中不存在逻辑缺陷。可测试的需求是指一份你可以为它编写测试案例的需求。
     Before or after the requirements review, a Master Test Plan is written which includes an Introduction, Background, Scope, Acronyms, Definitions, Features to be Tested, Features not to be Tested, Constraints, Assumptions, Risks and Contingencies, Schedules, Roles/Responsibilities, and References. The Master Test Plan is used by the test team to determine how long testing will take. Also, the tester uses the MTP as a testing plan. The Introduction, Background, Scope, Acronyms, Definitions, and References are preliminary sections in the test plan.  They outline the background of the project, the intended audience and exactly what the project definition is-what it includes and what it does not include. The Acronyms outline the abbreviations used in the test plan and the Definitions section defines any new terms that may be used in the test plan.  The References section lists the documents used to create the test plan.  Typically, they refer to the SRS and the Software Design Documents.  The “Features to be tested” section includes the list of all the functional requirements, performance requirements, usability requirements, and security requirements that will be tested in the software. The “Features not to be tested” section includes any features that will be excluded from the testing.  The Constraints and Assumptions section identifies those factors that will impact the project and the software testing effort as well as any underlying beliefs that are held regarding the project.  Constraints also represent the limitations of the software project. In the Risks and Contingencies section, all the risks along with contingency plans and mitigation strategies are presented. No one likes to discuss risks but that should be one of the first issues discussed and planned for when formalizing the project plan. Risk analysis is one way to mitigate the risks inherent in software development.  Risk analysis is a systematic process that weighs and prioritizes risks of each requirement. The Schedules section discusses the timeline for all the testing activities to take place. The Roles/Responsibilities section outlines who is responsible for what deliverable. The last section is the Appendix section. These sections are not usually in the order I have presented them in but this listing does include the major pieces of a Master Test Plan.
    在需求评审之前或之后，一个主测试计划会被编写，包括介绍、背景、范围、缩略语、定义、将被测试的特性、不被测试的特性、约束、假设、风险和意外、日程表、角色/责任、和参考。主测试计划被测试团队用来决定测试工作将被执行多长时间。测试人员也使用主测试计划作为测试计划。介绍、背景、范围、术语、定义和参考是测试计划的前序。它们简述项目的背景，预期的读者是谁及项目的确切定义是什么（包括哪些内容和不包括哪些内容）。缩略语简要描述了测试计划中使用到的缩写。定义章节定义了在测试计划中使用到的新术语。参考章节列出了建立测试计划用到的文档资料。典型情况，测试计划引用了软件需求规格和软件设计文档。“将被测试的特性”章节包括所有软件需测试的功能特性的列表、性能需求、可用性需求、和安全需求。“不被测试的特性”章节包括不会被测试的特性。约束和假设章节鉴定出有那些会影响到项目和软件测试的因素，也包括任何项目所持有的基本信念。约束也表述了软件项目所受的限制。在风险和意外章节，所有的风险和意外处理计划及缓解策略一起被表述。没有人喜欢讨论风险，但是这应该是在规范项目计划时，最先的被讨论的问题之一。风险分析是缓解软件开发固有的风险的方法之一。风险分析是处理每个需求涉及到的风险的重要性和优先级的一个系统过程。日程表章节讨论测试活动发生的时间。角色/责任章节简述了谁负责交付什么。最后的一个章节是附录章节。章节之间通常并不是按照我所描述的顺序，但列出的内容已经包括了主测试计划的最主要的那些部分。
      After the review of the SRS is done, the tester then begins writing either test cases or use cases from the SRS. Use cases document how the system interacts with various actors while test cases are much more specific. Depending on the approach, a test case or use case document is produced. Let’s assume the tester writes test cases.  In the test case document, the tester will generally put the description, test steps, expected results, actual results, the pass/fail results, and screen shots. The screen shots are a necessary addition after the testing has started to show evidence that a test case has passed. The test steps are also known as the test script. For the sake of simplicity, let’s assume a manual testing approach right now. Later, the discussion will turn to automated testing.
    在需求评审结束后，测试人员开始依照软件需求规格写测试案例或用例。用例记录系统如何和多种角色进行交互，而测试案例的编写更加具体得多。依照使用的方法，一个测试案例或者用例文档被产出。我们假设测试人员编写测试案例。在测试案例文档中，测试者通常要放入描述、测试步骤、期望的结果、实际结果、通过/失败结果和屏幕截图。在测试已经开始以后，屏幕截图是一个用于证明测试已通过的必要附件。测试步骤通常也叫做测试脚本。为了简化问题的描述，这里我们假设采用的是手工测试的方法。迟一些，我们会转向自动化测试的讨论。
     The test case document along with the Master Test Plan is then submitted for review as part of the formal review of the work product. Revisions are made based on the outcome of the review. At the review meeting, all the stakeholders are present including the requirements analyst, developers, the testers, project manager, and if there is a separate person performing an SQA Analyst role, then he/she is also asked to the review.  Each page is discussed to see if any changes need to be made or any points need to be clarified.  Once the issues are noted, the tester revises the Master Test Plan and the test cases based on the formal review. Issues are tracked to closure and a decision is made to have another meeting to approve the work product or handle the review of the work product through email.
     接下来，作为工作成果中正式评审的一部分，测试案例文档和主测试计划一起被提交评审。基于评审产生修订后的版本。所有的关系人需出席评审会议，包括需求分析师、开发人员、测试人员、项目经理。如果有一个独立的执行软件质量保障的分析师角色，他（她）也被要求参加评审。讨论每一页的文档，找到是否需要作出一些修改，或需要阐明一些问题。一旦问题被记下来，测试人员基于正式评审来修订主测试计划和测试案例。问题将被跟踪直到被关闭，并通过其它批准工作产出的会议制定决策，或者通过email处理工作产出评审。
     The tester must also produce a Traceability Matrix which ties the Software Requirements Specifications to the Software Design Document and to the Test Case document. There should be at least a one to one mapping or a one to many mapping of requirements to test cases.  In some firms, a QA Analyst/Tester must also review the Software Design Document making sure that every requirement is accounted for in the SDD. In this way, a tester can adequately assure that every test case is traceable to a requirement and every requirement is traceable to a software routine, option, or menu. Traceability is a key quality attribute of a software testing process. 
    测试人员还需要产出一个绑定软件需求规格到软件设计文档和测试案例文档的跟踪矩阵。在需求和测试案例之间最少需要建立一对一或者一对多的映射。在一些公司，质量保障分析员/测试人员还需要评审软件设计文档，确认每一个需求都已经在软件设计文档中进行了说明。用这种方法，测试人员能完全确认每一个测试案例可以跟踪到一个需求，及每一个需求可以跟踪到一个软件程序、选项，或者菜单。可跟踪性是一个软件测试过程里的关键质量属性。
     After development of the code is completed and the build is delivered to the testers then the actual testing begins. Each test case is executed against the application and pass/fail results are recorded. Screen shots are taken as well. Any defects are recorded using a defect tracking tool such as Rational ClearQuest, Mercury Quality Center, or another defect tracking tool. There should be a process in place for defect tracking and defect resolution. Typically, when the tester writes up a defect in a defect tracking tool, the points to include are the stage of testing, subject, description of the problem, the steps to repeat, and a screen shot if possible. The description of the problem should be recorded as what is the issue that needs to be corrected and where the error is rather than a recording of what is simply left out since no one would be able to determine whether that is a problem. I have seen SharePoint sites used for defect tracking. When such a site is used, it should include the stage of testing that the defect was found. Even when using Rational ClearQuest or Mercury Quality Center, the stage of testing should be noted depending on the type of SDLC that is in present in the organization.
    在代码的开发完成且构建分发到测试人员手中时，实际的测试开始了。针对应用执行每一个测试案例，成功/失败结果被记录下来。同时，用屏幕截图截取结果 。 任何缺陷都被用缺陷跟踪工具（例如Rational ClearQuest、Mercury Quality Center或其他缺陷跟踪工具）记录下来。缺陷跟踪和缺陷解决需要有一个适当的过程。典型情况下，当测试人员在测试跟踪工具中记录一个缺陷，如果可能要包括测试的阶段、主题、问题的描述、重复的步骤及屏幕截图。问题的描述需要记录需要修正的错误是什么和错误在什么地方，而不是一条讨论的记录，因为没人能去确定那是否一个问题。我曾看到SharePoint站点被用来做缺陷跟踪。当这样的一个站点被使用，当缺陷被发现时，需要记录测试的阶段。甚至当你使用Rational ClearQuest和Mercury Quality Center，也要根据组织中使用的软件生命周期的类型来确定是否记录测试的阶段。
     Depending on the severity of the defects, a new build is created to correct the defects found. The tester retests the defect to make sure it is fixed and then does a light regression around that area of functionality to make sure nothing else has broken. Once the tester notifies the team that internal testing is done, then depending on the SDLC, the code is released into production or handed off to the test sites, if any for field testing. If the test sites find defects they are reported to the development team and a new build is released which will then have to go through internal testing before being released to the test sites again. Defects are recorded as before. 
    根据缺陷的严重性，需要修正找到的缺陷，并为此建立一个新构建。测试人员重新测试缺陷来确认它已经被修正，然后在缺陷的功能区域执行一个轻量的回归测试，确认没有其它问题被引发。一旦测试人员通知团队内容测试已经完成，依赖于软件开发生命周期，代码被作为产品发布，或根据需要发布到测试网站上做现场测试。如果测试网站发现有缺陷，将缺陷报告给开发团队，新的构建将被发布，然后先经过内部测试，再发布到测试网站。缺陷像以前一样被记录下来。

Automated Testing
自动化测试

In automated testing, instead of a Master Test Plan or a along with one, an Automation Test Plan is written that will outline exactly how the automation will proceed and the approach taken. Once that is written, the creation of the automated test scripts begins and corresponds with the requirements written in the SRS o r RSD – Requirement Specification Document. After a build is delivered, the test scripts are run against the application to see what has broken. If it is a true defect, then the defect is written up using the same tools as in manual testing. Depending on the number and severity of changes, a new build is delivered and the automated test scripts are run again against the application. Once the tester has found no defects, he/she can report that testing is completed and the build is put into production.
    在自动化测试中，一份自化测试计划被编写出来，用于概述自动化将如何执行及被选中的测试方法。它可能是被用来完全替代主测试计划，又或者仅和主测试计划一起被编写。一旦文档被编写后，自动化测试脚本开始对应软件需求规格和需求研究文档中的需求进行编写。在构建被分发后，测试脚本针对应用运行来检查是否存在问题。如果确实是一个缺陷，那么缺陷被用和手工测试一样的工具记录下来。依赖修改的数量和严重程度，一个新的构建被分发，并再次针对应用运行自动化测试脚本。一旦测试人员发现已经不存在缺陷，他/她可以报告测试已经结束，构建已经可以成为产品。

Pain Points and Areas for Improvement
可改善的问题点和领域

      1. Building trust in the SQA Tester – I had a development manager tell me once that it takes a long time for a project manager to be trustful of  a tester. Fortunately, that particular situation worked in my favor but it can be hard for the development team to trust that the tester is going to perform due diligence on the testing project. That is, that he/she will find out and uncover everything there is to know about the project and the coding that can help him or her test the application thoroughly.  Often times, this can be overcome with increased communication and explanation to the project manager and developers the reasoning behind why particular actions are taken.
     1.建立对软件质量保障测试人员的信任 — 我的一个开发经理有一次告诉我，项目经理需要很长时间才会信任测试人员。幸运的是，我碰到了这种特别的情况。但是让开发团队信任测试人员将会尽职尽责去执行工作有可能是困难的。那意味着，他/她将找出或揭露所有关于项目相关的事和可以帮助他或她完全测试项目的编码。很多时候，通过增加交流，并向项目经理和开发者解释为何要执行这些特别的活动，这个问题可以被克服。
      2. Developers who do not believe in the value of Software Testing and Quality Assurance – Many times, testers are faced with a situation in which they are constantly butting heads with the developers. Usually, this comes from an antiquated belief that testers do not know what they are talking about or that anyone can test. However, testing is a skill and it takes years to finely perfect the craft of testing software. Sometimes, the only recourse a tester has is to take the issue up with a much more senior tester who has the position and the backing to tell the developer to look at the tester’s findings.
    2.开发人员不相信软件测试和质量保障的价值 — 测试人员会经常面对着和开发人员冲突的情形。 通常来说，这来自一种已过时的想法，测试人员并不知道开发人员所做的事或者没有人能测试系统。可事实是，测试是一种技能，而且人们花费了很多年来完善测试软件产品。有些时候，测试人员只有依赖于让一个有地位和背景，更资深测试人员去告诉开发人员，让他们去看测试人员发现的问题。
     3. Inadequate amount of time to test – sometimes there just isn’t enough time within the project schedule to adequately test the software.  A way to circumvent this issue is to test the requirements as they are written and build the test cases while the requirements are being written. The other thing to do here is to have people who can adequately scope out a project and the deliverable dates. Also, regular meetings with staff help to identify the status of key personnel in the software development project.
    3.测试时间不足 — 很多时候，仅仅是项目计划中没有足够的时间进行充分的测试。一个解决这个问题的办法是在需求被编写时就同时测试它，并在需求被编写时，就构建测试案例。另外要做的事是找一个能够评估项目和分发日期的人。另外，在软件开发项目中，人员常规例会有助于鉴别出关键人物。
     4. Poorly written requirements – sometimes the requirements are incorrectly captured and need to be revised as the software development project proceeds. This situation is costly to the organization as well as the test team in terms of both money and time. This situation could lead to scope creep in which the delivered code exceeds what has been written in the requirements. There is no real workaround for this issue.  The best thing to do is nip it in the bud when you see scope creep happening. One way to do this is to make a solid decision beforehand to gain user signoff on the SRS so that scope creep doesn’t happen. Another way to nip it in the bud is to have a change control board in place that approves SRS changes.  The change control board then becomes responsible for cost overruns. This avoids the project manager being blamed for scope creep.
    4.糟糕的需求撰写 - 有时候，需求没有被正确的捕捉，并在软件开发项目过程中需要修订。这种情形对于组织和测试团队的钱和时间都会有耗费。这种情形会导致范围渐增（Scope Creep），从而使分发的代码超过需求中所编写的内容。对此问题，并没有一种真正的解决方案。最好的方法是当发现范围渐增发生时就即时制止。一个方法是通过获得用户在软件需求规格上的签字，预先使得决策变得稳定，这样范围渐增就不会发生。另外一个制止它的办法是，有一个变更控制委员来批准软件需求规格变更。改由变更控制委员来对费用超支负责。这避免了项目经理由于范围渐增而遭责难。
     5. Not enough testing resources – This issue is a situation for upper management to handle. When there are not enough testing resources, it affects the schedule and could lead to burnout of the few testers that are there to test the product.
    5.没有足够的测试资源 – 这个问题是需要高层去处理的情形。当没有足够的测试资源，它会影响到时间表，并且会导致那些过少的测试项目的测试人员们筋疲力尽。
     6. Not enough training for testers – This situation could lead to testers not understanding the software under test. It affects both time required to test and the money involved in the testing effort.
    6.测试人员没有足够的培训 – 这种情形会导致测试人员不能理解正在测试的软件。它会影响到需要的测试时间和涉及到测试成果的金钱。
     7. Scheduling of future testing efforts – This problem arises when schedules for  the next release are planned for while testing is going on for the current release. It is difficult for testers to give a correct estimate of the amount of time the future testing effort will take.
    7.计划将来的测试成果 – 当正在进行当前版本的测试时，同时进行下一个计划的版本的时间制定，这个问题会浮出。对于测试人员来说，正确的评估时间和将获得测试效果是困难的。
     8. Time to discuss with developers – sometimes there isn’t enough time to discuss an issue with a developer and when this happens miscommunications occur quite regularly. It is easier to get a developer on the phone and show them the issue than it is to email them the issue and get caught up in back and forth emailing.
    8.和开发人员讨论的时间 – 有些时候 ，没有足够的时间和开发人员讨论一个问题，当这发生时，会导致经常的传达错误。给开发人员打电话，并且将问题显示给他们看，比将问题通过电子邮件发给他们，并且在反复的邮件中捕捉问题要更容易些。
     9. People challenges. Randall W. Rice and William E. Perry wrote this book called, Surviving the Top Ten Challenges of Software Testing and in that book they write that the following are some of the challenges testers face in their daily interactions:
    9.应对人的挑战。Randall W. Rice和William E. Perry写了本书叫《在软件测试的10大挑战中存活》，在这本书中他们写下了以下一些测试人员的日常交互中需要面对的挑战：

The Top Ten People Challenges Facing Testers
测试人员面对的10大来自人的挑战

Challenge #1: Having to Say No – having to say you just don’t have enough time to test another application while testing the current application.
挑战#1：必须说不 – 当你正在测试当前应用时，你必须说出你没有足够的时间去测试其它应用。

Challenge #2: Fighting a Lose-Lose Situation- this could mean many things but often refers to the internal politics of the organization and whether there is support for testing within an organization.
挑战#2：和不断失去的情形做战 – 这意味着很多事，但是经常是指组织的内部政策或是否组织对测试有支持。

Challenge #3: Hitting a Moving Target – this often refers to requirements that keep growing once a project has been started. This situation is commonly referred to as scope creep.
挑战#3：击中在移动中的目标 – 这常常指项目开始后，需求持续不断增加。这种情形通常指范围渐增。

Challenge #4: Testing What's Thrown over the Wall – often refers to testing without a process in place to prevent developers from simply giving code to test that hasn’t been unit tested or put together in a clean build.
挑战#4：测试从墙那边扔来的东西 – 这通常指没有合理的过程来防止开发人员简单的将没有经过单元测试的代码交来测试，或将这些代码放入一个干净的构建中。

Challenge #5: Making Time for Testing – this often refers to having enough time to test and goes back to what was stated earlier. You need to plan time for testing and test early and often.
挑战#5：花时间去测试 – 这通常指有充分时间去测试，回到我们先前申明的，你需要为测试计划时间，并更早和更频繁的执行测试。

Challenge #6: Communicating with Customers -- And Users – often refers to making sure that the development team including the testers deliver the right product to the customer and users and that there is ongoing support to train the customers and users in the new software product.
挑战#6：和客户及用户交流 – 通常指要确保开发团队宝库测试人员分发正确的产品给客户和用户，并为客户和用户提供不间断的培训支持。

Challenge #7: Explaining Testing to Managers- some managers simply don’t understand testing so it is the job of a test analyst to have sound reasons for why they are doing what they are doing.
挑战#7：向管理者解释测试 – 一些管理者仅是不理解测试，测试分析师的工作之一，是对为何他要做正在做的事情要有充分的理由。

Challenge #8: Testing Without Tools – The people related challenge here is to acquire adequate support for purchasing tools and demonstrating why the tools are needed. In other words, the challenge is to make a case for purchasing testing software.
挑战#8：没有工具的测试 – 这里与人相关的挑战是为购买工具获取足够的支持，及论证为什么需要工具。换句话说，挑战是如何促成购买测试软件的方案。

Challenge #9: Building Relationships with Developers – The people related challenge here is to cultivate relationships with developers since most testers work closely with the developers.
挑战#9：建立与开发人员之间的关系 – 这里与人相关的挑战是培养和开发人员之间的关系，因为多数测试人员与开发人员紧密的在一起工作。

Challenge #10: Getting Trained in Testing – in chapter 3 Rice and Perry write that, “Without training, testers are ill-equipped to meet the rigors of testing, especially in technically difficult situations. The people-related challenge of the following is to secure adequate support for training.”
挑战#10：获得测试相关的培训 – 在第3章中Rice和Perry写到：没有培训，相当于测试人员是坏掉的设备，要去适应测试的精密，特别是在技术困难的情形更是如此。后面与人相关的挑战是确保获得对于培训的足够支持。

Adding Value to the Development Process
为开发过程增添价值
Whether an organization is using Agile Development methods or the traditional Waterfall or Iterative Development approaches, a tester can add value to the organization. He/she increases the confidence of the organization that the software is built right and the right software is built. This increases the efficiency and efficacy of the organization’s software development approach. Organizations that do not have test teams or individuals testing suffer the consequences of inadequately built software, defect ridden software, and cost overruns that spill over into other areas of the organization. Simply put, the cost exceeds the benefits when you do not have a tester or test team in your organization. Most testers are detailed and thorough about their work and can find flaws that are not readily apparent, thereby adding a quality that did not exist before. In addition, most testers have good communication skills which can bridge the gap between the developers and the users. Some developers cannot effectively communicate with the user community and suffer in this regard since they cannot explain what it is they are trying to do.  Testers serve a key role here as communicators since they can conduct test site calls and organize user acceptance testing for the software development team.
      无论组织使用敏捷开发方法或者传统的瀑布式或者迭代式开发方式，测试人员都能为组织增添价值。他/她增加了组织对于软件被正确构建和构建正确的软件的自信。这增加了组织的软件开发方法的效果与效率。组织如果没有测试团队和个人测试员工会导致不合适构建的软件、被缺陷折磨的软件，及超出预算并波及到组织的其它领域。简单的总结，在组织中没有测试的团队，所花费的会超过带来的利益。大多数测试人员会仔细和彻底的对待他们的工作，并且能找到那些不轻易显现的暇疵，因此增加了以前不存在的品质。更有价值的是，多数的测试人员拥有更好的沟通技巧，可以在客户和开发人员之间搭建起桥梁。在这点上，一些开发人员不能有效的和客户的社区和员工进行交流，因为他们不能解释他们正在努力去做的事。因为测试人员可以为开发团队管理测试站点并组织用户接受测试，所以测试人员这里作为一个关键的角色为交流者们进行服务。
In conclusion, testers face many daily challenges while testing software. Some of these are inherent in the organizational culture but others are derived from misconceptions about the role of testers and what they actually do. This paper has attempted to explain different aspects of a tester’s job and how they fit into the organization. It has attempted to explain the differences between using a manual testing approach and an automated testing approach. While some similarities exist, there are some differences.  Software testers are highly valued and software testing is a very good profession within the IT industry.
最终结论，当测试软件时，测试人员每天都面对着挑战。它们其中的一些是来自企业固有的文化，但另外的来自对于测试人员的角色和他们实际工作的错误概念。这份文章试图解释测试人员工作的不同方面，及他们如何适应组织。文章试图解释了手动测试方法和自动化测试方法的不同。有一些类似性，有一些不同处。软件测试人员有很高的价值，软件测试也是IT产业很好的一个专业。