目录
The basic idea behind testing 测试背后的基本思想
Common types of testing 常见的测试类型
Other forms of testing 其他形式的测试
How Testing Works on Agile Teams 测试如何在敏捷团队中发挥作用
Testing and You, the Developer 测试和你，开发人员
翻译内容
One of my first official jobs in the software development industry was that of a tester.
我在软件开发行业的第一份正式工作之一就是测试人员。
My job entailed looking at stacks of papers that were printed out by a new printer we were testing at HP, and comparing them to the “master” printouts produced by older printers.
我的工作包括查看由我们在惠普测试的新打印机打印出来的纸叠，并将它们与旧打印机生成的“主”打印输出进行比较。
I didn’t actually do the comparison of the pages myself; instead I would execute the tests, someone else would compare the printouts, and I’d look at the differences they flagged.
我自己并没有真正对页面进行比较; 相反，我会执行测试，其他人会比较打印输出，我会看看他们标记的差异。
With each difference, I would review and decide, based on the test, whether the result was a true failure or defect. If it was the latter, I’d write up a defect report for a developer to look at—and possibly fix.
根据每个差异，我会根据测试来审核并决定结果是真正的失败还是缺陷。 如果是后者，我会为开发人员编写一份缺陷报告，以便查看并可能修复。
Later in my career, I took on a different testing role as a testing lead for a multi-function printer.
在我职业生涯的后期，我作为多功能打印机的测试负责人担任了不同的测试角色。
I’d decide what should be tested, how it should be tested, and then I’d come up with a testing plan and run the tests to verify the printer worked how it was supposed to.
我决定应该测试什么，应该如何测试，然后我会提出一个测试计划并运行测试以验证打印机是如何工作的。
It was through those experiences that I learned that most developers have no clue about how testing is actually done, and how valuable this understanding can be for developers who really want to excel in their careers.
通过这些经验，我了解到大多数开发人员都不知道测试是如何实际完成的，以及这种理解对于真正想要在职业生涯中表现出色的开发人员有多么宝贵。
I owe a large amount of the success I have had in my career as a software developer to my background in testing.
作为一名软件开发人员，我所取得的巨大成功归功于我在测试背景方面的成功。
That background caused me to look at the code I was writing a little differently and to realize that my job as a software developer wasn’t just to implement features and fix bugs, but to make the software I was writing work correctly and as intended.
这个背景使我看到我编写的代码有点不同，并意识到我作为软件开发人员的工作不仅仅是实现功能和修复缺陷，而是使我正在编写的软件正常工作并按预期工作。
Seems like a simple and obvious idea, but if you don’t at least know the basics of testing, you probably aren’t going to have the best idea of what “working correctly and as intended” actually means.
看起来像一个简单而明显的想法，但如果你一旦不知道测试的基础知识，你可能不能很好地了解“正常工作和预期”的实际意义。
The basic idea behind testing 测试背后的基本思想
Often new programmers don’t understand testing. They don’t think it necessary.
通常，新程序员不了解测试。 他们认为没有必要。
At the surface level it can seem a bit extraneous. 在表面层面，它看起来有点无关紧要。
Do we really need to test that code? I ran it on my machine and it worked perfectly, so let’s just ship it.
我们真的需要测试该代码吗？ 我在我的机器上运行它并且它工作得很好，所以让我们发布吧。
Testing, at its core, is really about reducing risk. 测试的核心是降低风险。
The goal of testing software is not to find bugs or to make software better. It’s to reduce the risk by proactively finding and helping to eliminate problems which would most greatly impact the customer using the software.
测试软件的目标不是发现缺陷或使软件更好。 通过主动发现并帮助消除对使用该软件的客户产生最大影响的问题来降低风险。
Impact can happen with the frequency of an error or undesired functionality, or it can be because of the severity of the problem.
影响可能发生在错误或不期望的功能的频率上，或者可能是由于问题的严重性。
If you had a bug in your accounting software which caused it to freeze up for a second or two whenever a value higher than $1,000 was entered, it would not really have a huge impact; but that would be a high enough frequency to be very annoying to the customer.
如果你的会计软件中有一个缺陷，导致它在输入高于1,000美元的价值时冻结了一两秒，那么它就不会产生巨大的影响; 但这对于客户来说是非常烦人的事情。
On the other hand, if you had a bug in the accounting software that caused all of the data to become corrupted every 1,000th time the data was saved, that would be huge impact, but very low frequency.
另一方面，如果您的会计软件中存在一个缺陷，导致所有数据在每1000次保存数据时被破坏，那将会产生巨大影响，但频率非常低。
The reason I define software testing in this way is because—as any tester will tell you—you can never find all the bugs or defects in a piece of software and you can never test every possible input into the software. (For any non-trivial application.)
我以这种方式定义软件测试的原因是因为 - 正如任何测试人员都会告诉你的那样 - 你永远无法找到软件中的所有错误或缺陷，而且你永远无法测试软件中的每一个可能的输入。 （对于任何非平凡的应用程序。）
So, the idea is not to find every single possible thing that is wrong, or even to verify the software against a spec—as some people like to define software testing—because both are impossible.
因此，我们的想法不是找到每一个可能出错的地方，甚至不是根据规范验证软件 - 因为有些人喜欢定义软件测试 - 因为两者都是不可能的。
Oh, also if you ever find a complete spec of any application in your experience as a software developer, let me know.
哦，如果您在软件开发人员的经验中找到任何应用程序的完整规范，请告诉我。
Instead, the focus and main idea behind software testing is reducing the risk that the customer is greatly impacted in a negative manner using the software.
相反，软件测试背后的重点和主要思想是降低客户使用软件以负面方式受到严重影响的风险。
Typically this is achieved by first prioritizing what areas of the software are likely to have the biggest impact (i.e. risk), and then deciding on a set of tests to run which verify the desired functionality.
通常，这是通过首先优先考虑软件的哪些区域可能具有最大影响（即风险），然后决定要运行的一组测试来验证所需功能来实现的。
When the actual functionality deviates from the desired functionality, a defect is usually logged and those defects are prioritized based on severity.
当实际功能偏离所需功能时，通常会记录缺陷，并根据严重性确定缺陷的优先级。
Some defects get fixed, other defects are low enough impact that they are just noted and left in the system.
一些缺陷得到修复，其他缺陷影响很小，只是它们被记录下来并留在系统中。
Common types of testing 常见的测试类型
The world of testing and quality assurance is huge. 测试和质量保证的世界是巨大的。
Just like the development world has many concepts and methodologies for creating software, there are many ways to think about an executing testing and the field is changing all the time.
就像开发世界有许多用于创建软件的概念和方法一样，有许多方法可以考虑执行测试，并且该领域一直在变化。
Even in name. 甚至在名字中。
Early in my career it could be perceived as a slight or insult to call someone who worked in testing a tester, they preferred to be called QA (or quality assurance) professionals.
在我的职业生涯早期，可能会认为成测试领域中的人为测试人员有一些轻视或侮辱，他们更喜欢被称为QA（或质量保证）专业人士。
Just a year or two ago, I attended a testing conference and I made the mistake of calling someone a QA person. They corrected me and said that tester was the prefered term.
就在一两年前，我参加了一个测试会议，我犯了一个错误，称某人是QA人。 他们纠正了我并说测试者是首选术语。
You can’t win them all. 你无法赢得所有人。
Anyway, let’s talk about the different kinds of testing, so you can get a general idea of what someone is talking about when they throw around these terms—which you will hear plenty often in the software development world.
无论如何，让我们来谈谈不同类型的测试，这样你就可以大致了解某人在谈论这些术语时所谈论的内容 - 你会在软件开发世界中经常听到这些内容。
This is not an exhaustive list by any means. 无论如何，这不是一个详尽的清单。
Black box testing 黑盒测试
One of the most common forms of testing—and really a way to describe a whole category of testing—is black box testing.
最常见的测试形式之一 - 实际上是描述整个测试类别的方法 - 是黑盒测试。
Black box testing is simply testing as if the software itself was a black box.
黑盒测试只是测试软件本身就像一个黑盒子。
When you do black box testing, you are only concerned with inputs and outputs. You don’t care how the actual outputs are derived.
进行黑盒测试时，您只关心输入和输出。 您不关心实际输出是如何输出的。
You don’t know anything about the code or how it works, just that for a given set of inputs into the software, a given set of outputs should be produced.
您对代码或其工作方式一无所知，只是对于软件的给定输入集，应该生成一组给定的输出。
Most testing is done in this fashion, because it is largely unbiased. It either works or it doesn’t.
大多数测试都是以这种方式完成的，因为它基本上没有偏见。 它既可以运行，也可以不运行。
White box testing 白盒测试
White box testing is pretty much the opposite of black box testing. 白盒测试几乎与黑盒测试相反。
With white box testing, you have at least some idea of what is going on inside the software.
通过白盒测试，您至少可以了解软件内部的情况。
Often unit testing is called white box testing, but I disagree. Unit testing is not testing at all—we’ll talk about that more in an upcoming chapter.
通常，单元测试称为白盒测试，但我不同意。 单元测试根本没有测试 - 我们将在即将到来的章节中讨论更多内容。
Instead real white box testing is when you understand some of the internals of the system and perhaps have access to the actual source code, which you use to inform your testing and what you target.
相反，真正的白盒测试是指您了解系统的某些内部结构，并且可能访问实际的源代码，您可以使用这些源代码来指导您的测试以及您的目标。
For example, if you looked at the code that did complex calculations for some accounting software, and you saw that there was a section of the code that did one set of calculations for values above a certain amount and another set of calculations for any other values, you’d be able to create tests that target both of those scenarios.
例如，如果您查看为某些会计软件执行复杂计算的代码，并且您看到代码中有一部分对超过一定数量的值执行了一组计算，而对另一个值执行了另一组计算 ，您将能够创建针对这两种方案的测试。
Acceptance testing 验收测试
Acceptance testing goes by many different names. 验收测试有许多不同的名称。
Sometimes it’s called user acceptance testing. 有时它被称为用户验收测试。
Sometimes it’s called system testing. 有时它被称为系统测试。
The basic idea of acceptance testing though is that you have some tests which test the actual requirements or expectations of the customer, and other tests that run against the system as a whole.
验收测试的基本思想是，您有一些测试可以测试客户的实际要求或期望，以及其他针对整个系统运行的测试。
What I mean by this is that you don’t just test one part of the software in isolation.
我的意思是你不要孤立地测试软件的一部分。
This kind of testing could be testing the functionality of the system or it could be testing the usability, or both.
这种测试可能是测试系统的功能，也可能是测试可用性，或两者兼而有之。
The idea is that acceptance testing tests what is expected versus what actually happens.
这个想法是验收测试，测试预期与实际发生的情况。
Automated testing 自动化测试
This is another broad kind of testing which can take many forms and has many definitions, but I define automated testing as any testing in which the execution of the test and the verification of the results is automated.
这是另一种广泛的测试，可以采用多种形式并有许多定义，但我将自动化测试定义为测试执行和结果验证自动化的任何测试。
So, you might automate the testing of a web application by running scripts which open up a web page, input some data, push some buttons and then check for some results on a page.
因此，您可以通过运行打开网页的脚本，输入一些数据，按下某些按钮然后检查页面上的某些结果来自动化Web应用程序的测试。
You could also automate the testing of an API by writing scripts which call out to the API with various data and then check the results that are returned.
您还可以通过编写使用各种数据调用API的脚本来自动测试API，然后检查返回的结果。
More and more of testing is moving towards automated testing, because manually running through test cases over and over again can be tedious, error prone and costly–especially in an Agile environment where the same set of tests may need to be run every two weeks or so to verify nothing has broken.
越来越多的测试正朝着自动化测试的方向发展，因为一次又一次地手动运行测试用例可能会非常繁琐，容易出错并且代价高昂 - 尤其是在敏捷环境中，可能需要每两周运行一组相同的测试或者 所以要验证没有破坏。
Regression testing 回归测试
That brings us to regression testing, which is basically testing which is done to verify that the system still works the way it did before.
这使我们进行回归测试，这基本上是测试以验证系统是否仍然像以前那样工作。
The purpose of regression testing is to make sure the software doesn’t regress in functionality.
回归测试的目的是确保软件不会在功能上后退。
This is extremely important with Agile development methodologies–more on that in a future chapter–where software is developed incrementally and there is a constant potential that adding new features could break existing ones.
对于敏捷开发方法而言，这一点非常重要 - 在未来的章节中将会更加重要 - 软件是逐步开发的，而且添加新功能可能会破坏现有功能。
Most automated tests are regression tests. 大多数的自动化测试都是回归测试。
In fact, you could really make the argument that all automated tests are regression tests, since the whole purpose of automating a test is so that it can be run multiple times.
实际上，你可以真正地提出所有自动化测试都是回归测试的论点，因为自动化测试的整个目的是它可以多次运行。
Functional testing 功能测试
Functional testing is another broad term used in the testing world to refer to testing activities where what is being tested is the actual functionality of the system.
功能测试是测试领域中使用的另一个广义术语，指的是测试活动，其中测试的是系统的实际功能。
This might seem obvious. 这看起来很明显。
You might be thinking “duh, what else would you test if you didn’t test the functionality of the system.”
你可能会想“呃，如果你不测试系统的功能，你会测试什么？”
But, it turns out that you can test all kinds of things that aren’t related to functionality, like performance, usability, resilience, security, scalability–I could go on and on, believe me.
但是，事实证明，你可以测试与功能无关的各种事情，比如性能，可用性，弹性，安全性，可扩展性 - 我可以继续，相信我。
So, functional testing the kind of testing where you are really concerned with if the system does what it is supposed to do given from a functional perspective.
因此，功能测试是指您真正关心的测试类型，系统从功能角度看执行应该执行的操作。
If I put in this input and push this button, do I get this expected output?
如果我这样输入，并按下此按钮，我是否获得此预期输出？
I don’t care how long it takes. I don’t care if the screen flashes bright read and the computer starts to smoke, do I get my result?
我不在乎需要多长时间。 我不在乎屏幕是否闪烁，电脑开始冒烟，只在乎我能得到我的结果吗？
Exploratory testing 探索性测试
I like to make fun of exploratory testing and call it “lazy ass testing.”
我喜欢拿探索性测试开玩笑，并将其称为“懒惰测试”。
It really pisses testers off when I do that. 当我这样做时，真的很讨厌测试人员。
But, there is definitely some legitimacy to the idea of exploratory testing and perhaps I am a bit too harsh and judgemental.
但是，探索性测试的想法肯定有一些合法性，也许我有点过于苛刻和判断。
The idea behind exploratory testing–when done correctly–is that you have some guidelines and basic plan of areas of the application you are going to test and ways you are going to test it.
探索性测试背后的想法 - 如果正确完成 - 是您有一些指导方针和您要测试的应用程序领域的基本计划以及您将要测试它的方式。
Then, you go about without actual test cases and explore the application, looking for things that might be wrong or behaviour that is unexpected.
然后，在没有实际测试用例的情况下，进行操作并探索应用程序，查找可能出错的内容或意外行为。
Often exploratory testing sessions are recorded, so that if an error is found, the problem can be reproduced by retracing the steps taken by the exploratory tester.
通常会记录探索性测试会话，因此如果发现错误，可以通过回溯测试人员采取的步骤来重现问题。
While, I’m generally not a huge advocate of this kind of testing, I do have to acknowledge its merits as exploratory testing can often uncover bugs which no rational test case would have ever been designed to exploit.
虽然，我通常不是这种测试的大力倡导者，但我必须承认它的优点，因为探索性测试通常可以发现理性测试用例可能没有覆盖到的缺陷。
Other forms of testing 其他形式的测试
Truly we’ve only scratched the surface of all the different types and classifications of testing there are.
实际上，我们只是触及了所有不同类型和测试分类的表面。
Many other forms of testing exist including load testing, to see how an application performs under a heavy load, performance testing, to test performance of the application based on certain scenarios, recovery testing, to test recovery from error conditions or hardware issues, security testing, to test the security of the system, stress testing, usability testing… the list goes on and on.
存在许多其他形式的测试，包括负载测试，查看应用程序如何在高负载下执行，性能测试，基于特定方案测试应用程序的性能，恢复测试，测试从错误条件或硬件问题中恢复，安全测试 ，测试系统的安全性，压力测试，可用性测试......列表一直在继续。
I just wanted to cover some of the basics here which you’ll hear about and see in everyday conversations as a software developer.
我只是想介绍一下一些基础知识，这些是作为软件开发人员在日常会话中，可能会听到和看到的。
The Testing Process 测试过程
Different organizations are going to have very different ideas of how testing should be done and what process should be followed.
不同的组织对如何进行测试以及应该遵循的过程有不同的看法。
You’ll also see plenty of formal specification of what is the “testing process” out there put out by various testing organizations.
您还会看到各种测试组织提出的“测试过程”的大量正式规范。
So, again, like a large amount of what I said about testing, the idea here is not to be prescriptive or to perfectly model the perfect testing process, but rather to give you an idea of what the testing process is like in general and what it entails.
所以，再次，就像我说的关于测试的大量内容一样，这里的想法不是规定性的，也不能完美地模拟测试过程，而是让你了解一般的测试过程是什么样的。
I like the pragmatic approach to life. 我喜欢务实的生活方式。
Testing usually begins with the development of some kind of a test plan.
测试通常从开发某种测试计划开始。
How will things be tested? 将如何测试？
What is our strategy for testing? 我们的测试策略是什么？
What kind of testing are we going to do?我们将要进行什么类型的测试？
What features are we going to test? 我们将要测试什么功能？
What is the schedule? 时间表是什么？
These are all questions that are generally answered in the test plan or if the test plan is not a formal document the planning of testing for a project.
这些都是通常在测试计划中需要回答的问题，或者如果测试计划不是正式文档，在项目测试计划开始就需要回答的。
Next, the tests are usually designed at a high level based on the requirements or functionality of the system.
接下来，测试通常根据系统的要求或功能进行高级别设计。
So, at this stage a tester might be coming up with a list of general test cases which will be run, what kinds of conditions will be tested, and coming up with what will be needed to perform the tests.
因此，在这个阶段，测试人员可能会提供一系列将要运行的一般测试用例，将测试哪种条件，以及提供执行测试所需的内容。
After that, the tests are usually actually created and executed.
之后，通常会实际创建和执行测试。
Sometimes this occurs as a single step. 有时这作为单独的一步执行。
Sometimes tests are written in a test management software first and executed later.
有时，测试首先在测试管理软件中编写，然后执行。
The results from the test execution are recorded and evaluated and any bugs or defects are usually logged into some kind of bug tracking system.
记录和评估测试执行的结果，并且通常将任何错误或缺陷记录到某种错误跟踪系统中。
Bugs are prioritized and sent to developers to fix.
错误被优先排序，并发送给开发人员进行修复。
Fixed bugs are retested and this cycle continues until the software meets the quality standards where it is decided it is shippable code.
修复了缺陷进行复检，这个循环一直持续到软件符合质量标准，并确定它是可发布的代码。
And that’s basically it. 这基本上就是它。
Plan how to test, design the tests, write the tests, execute the tests, find bugs, fix bugs, release software.
规划如何测试，设计测试，编写测试，执行测试，查找缺陷，修复缺陷，发布软件。
How Testing Works on Agile Teams 测试如何在敏捷团队中发挥作用
The standard process of testing tends to run into some problems on Agile teams where new features are being coded and implemented every couple of weeks or so.
标准的测试过程往往会遇到敏捷团队的一些问题，每隔几周左右就会对新功能进行编码和实施。
Many teams try to either strictly follow the standard testing process or completely throw it out the window instead of working it into the Agile lifecycle of software development.
许多团队都试图严格遵循标准测试流程，或者完全将其抛到窗外，而不是将其用于软件开发的敏捷生命周期。
Both of these approaches are wrong. 这两种方法都是错误的。
Instead, the focus really has to change on developing the test cases and test scenarios up front, before any code is even written and simply shrinking the test process into a smaller iteration, just like we do when we develop software in an Agile way.
相反，在开始编写测试用例和测试场景之前，在编写任何代码之前，只需将测试过程简化为较小的迭代，就像我们以敏捷方式开发软件时一样，重点必须改变。
This just means that we have to chop things up into smaller pieces and have a bit of a tighter feedback loop.
这只意味着我们必须将事情分解成更小的部分，并且有一些更严格的反馈循环。
Instead of spending a large amount of time upfront creating a testing plan for the project and intricately designing test cases, teams have to run the testing process at the feature level.
团队必须在功能级别运行测试过程，而不是花费大量时间预先为项目创建测试计划，并错综复杂地设计测试用例。
Each feature should be treated like a mini-project and should be tested by a miniature version of the testing process, which begins before any code is even written.
每个功能都应该像迷你项目一样对待，并且应该通过测试过程的微型版本进行测试，该版本在编写任何代码之前开始。
In fact, ideally, the test cases are created before the code is written at all–or at least the test design, then the development of both the code and the test cases can happen simultaneously.
事实上，理想情况下，测试用例是在编写代码之前或至少在测试设计中创建的，然后代码和测试用例的开发可以同时进行。
Another major consideration with Agile testing is automation.
敏捷测试的另一个主要考虑因素是自动化。
Since new software is released on very short iterations, regression testing becomes more and more important, thus automated testing becomes even more critical.
由于新软件在非常短的迭代中发布，因此回归测试变得越来越重要，因此自动化测试变得更加重要。
In my perfect world of Agile testing, automated tests are created before the code is actually written to implement the features–truly test driven development–but, this rarely happens in reality.
在完美的敏捷测试世界中，自动化测试是在实际编写代码之前创建的，以实现功能 - 真正的测试驱动开发 - 但这在现实中很少发生。
Testing and You, the Developer 测试和你，开发人员
What about you, the software developer, what is your role in all this testing stuff?
你，软件开发人员，你在所有这些测试中的角色是什么？
Do you even have one? 你有一个吗？
Yes. Definitely. 是。当然。
One of the big failings of software development teams is not getting developers involved enough or taking enough ownership for testing and the quality of their own code.
软件开发团队的一个重大缺陷就是没有让开发人员参与其中，也没有为自己代码的测试和质量获得足够的所有权。
As a software developer, you should be concerned with quality more than anyone else.
作为软件开发人员，您应该比其他任何人更关注质量。
You can not have the mindset that QA will find the bugs in your code.
您不能拥有QA在代码中找缺陷的心态。
Instead, you should absolutely make it your responsibility to find and fix the bugs before your code goes to testing.
相反，在代码进行测试之前，您绝对应该负责找到并修复缺陷。
The reason is fairly simple. The further along in the development of software a bug is found, the more expensive it is to fix.
原因很简单。 在软件开发中发现缺陷的时间越晚，修复起来就越昂贵。
Think about it this way. 这样想吧。
If you test your own code thoroughly before you check it in and hand it over to QA and find a bug in that code, you can quickly fix that bug and perhaps it costs an extra hour of time.
如果您在检查之前彻底测试自己的代码，并将其移交给QA并找到该代码中的缺陷，您可以快速修复该缺陷，并且可能需要额外花费一小时的时间。
If you take that same bug, and you don’t take the time to find it yourself and fix it, the process might go something like this:
如果您实现中有一个相同的缺陷，并且您没有花时间自己找到并修复它，那么这个过程可能会是这样的：
A tester runs a test which finds the bug in your code.
测试人员运行测试，找到代码中的缺陷。
The tester re-runs the test to make sure the bug is valid.
测试人员重新运行测试以确保缺陷有效。
The tester files a defect in the bug tracking software.
测试人员在错误跟踪软件中记录缺陷。
A development manager decides that the bug is severe enough for you to work on and the bug is assigned to you.
开发经理确定该错误足够严重，并将缺陷分配给您。
You try to recreate the defect, but it seems to work on your machine.
您尝试重新创建缺陷，但它似乎在您的计算机上运行正常。
Tester reproduces the bug and puts more detailed steps in the bug report.
测试人员重现该缺陷，并在缺陷报告中添加更详细的步骤。
You finally are able to reproduce the bug and you fix it.
您最终能够重现该缺陷并修复它。
You update the bug report with the fix.
您修复程序后，更新缺陷报告。
The tester goes back and checks that the bug is actually fixed and marks the defect as resolved.
测试人员返回，并检查缺陷是否已实际修复，并将缺陷标记为已解决。
So, perhaps you should take that extra 10 minutes to test your own code before checking it in.
因此，在检查之前，您可能需要花费额外的10分钟来测试自己的代码。
You won’t catch everything, but if you can even catch 10% of the bugs that would otherwise make it to QA, you’ll be saving quite a bit of time, don’t you think?
你不会抓住所有东西，但是如果你可以捕获10％的缺陷，防止它流转给QA，你会节省相当多的时间，你不觉得吗？
关于作者
John Sonmez
John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."
John Sonmez是Simple Programmer的创始人，也是软件开发人员的生活教练。 他是“软技能：软件开发人员生活手册”一书的畅销书作者。
原链接
https://simpleprogrammer.com/software-developers-know-testing-qa/