“Lessons Learned in Software Testing” is a book. An excellent book!

《软件测试中的经验教训》是一本书。 一本好书！

Written by testing gurus James Bach, Cem Kaner, and Bret Pettichord, it is a collection of 293 lessons — nuggets of wisdom, large and small. Written in 2002, it is still very relevant today (perhaps with minor exceptions such as Lesson #266 — Learn Perl).

它是由测试大师James Bach，Cem Kaner和Bret Pettichord编写的，它汇集了293堂课程，包括大大小小的智慧。 它写于2002年，今天仍然非常相关(也许只有次要例外，例如第266课-学习Perl)。

In this article, I present you with my 10 favorite lessons. They are not sorted in the “likeability” order. Instead, they follow an approximate chronological order of how we do things as QA professionals on a new project.

在本文中，我向您介绍了我最喜欢的10个课程。 它们未按“相似性”顺序排序。 取而代之的是，他们按照时间顺序，按照我们作为质量保证专家在新项目上的工作方式进行工作。

1.与会阅读您的报告的程序员会面 (1. Meet the programmers who will read your reports)

Lesson #91. What do you do in your first several weeks on a new project with new stakeholders — managers, analysts, and most importantly — developers?

第91课 。 在与新的利益相关者(经理，分析师，最重要的是开发人员)的新项目中，您最初的几周会做什么？

You get to know them! And you do so as much as you can.

您会认识他们！ 而且您会尽力而为。

Software is built by human beings, and they have a tendency to answer your questions, “getting back to you” in emails faster, and overall being more cooperative if they had one or two informal chats with you about life in general.

该软件是由人类开发的，他们倾向于回答您的问题，可以更快地在电子邮件中“回复您”，并且如果他们与您进行一两次非正式的关于生活的非正式交谈，那么他们总体上会更加合作。

You stop being a name, or a lifeless text behind an email who annoys them by demanding something from them. Instead, you’re that person who also likes hiking, who they laughed with over a joke, or otherwise shared a pleasant conversation. Cooperation gets a 1000% boost! (a scientifically accurate measurement). Additionally, it will also help YOU write courteous and thoughtfully worded emails and reports.

您不再是电子邮件的名字或死气沉沉的文字，而是通过向他们要求某些东西来烦扰他们。 相反，您就是那个人，他们也喜欢远足，开玩笑而笑着，或者以愉快的心情聊天。 合作获得1000％的提升！ (科学准确的测量结果)。 此外，它还可以帮助您编写有礼貌且措辞周到的电子邮件和报告。

It’s a two-way street and you will tend to see each other as fallible human beings trying to do a good job rather than incompetent idiots.

这是一条双向的街道，您会倾向于把彼此看作是易犯错误的人类，他们在努力地做好工作，而不是白痴。

2.快速找到重要的错误 (2. Find important bugs fast)

Lesson #5. OK, so you’ve met people, and now it’s time to get to work. And yes, you have to hit the ground running as usual. I haven’t heard of many stories where new joiners are given ample amount of time to slowly ease themselves into the job.

第5课 。 好，您已经认识了很多人，现在该开始工作了。 是的，您必须照常运行。 我从未听说过很多故事，在这些故事中，新入职者有足够的时间慢慢地适应工作。

You’ve read all possible documentation and internal resources, you’ve familiarized yourself with the system to some extent, and the new version is out and needs testing. Given relatively little knowledge (you’re still new) and time constraints, how do you go about it?

您已经阅读了所有可能的文档和内部资源，在某种程度上已经熟悉了系统，并且新版本已经发布并且需要测试。 考虑到相对较少的知识(您仍然是新手)和时间限制，您将如何处理？

A picture is worth a thousand words, so here’s the answer in a nutshell:

一幅图片价值一千个单词，因此简而言之，这就是答案：

The picture deserves a detailed explanation:

图片值得详细说明：

• Test things that are changed before things that are the same. Makes sense, right? Fixes and updates mean fresh risk.

  在相同的事物之前测试变化的事物。 有道理吧？ 修复和更新意味着新的风险。

• Test core, high-impact functions first. If a single broken core function blocks 20 secondary functions, then which one has priority?

  首先测试核心，高影响力功能。 如果一个坏的核心功能阻止了20个辅助功能，那么哪个优先？

• Test common scenarios first. If feature A is used by thousands every day, and feature B by dozens once a week, then which one has priority?

  首先测试常见方案。 如果功能A每天有成千上万次使用，功能B每周有数十次使用，那么哪个优先？

• Test capability before reliability. Test whether each function works at all before exploring how it might behave under many different conditions.

  在可靠性之前测试能力。 在探索每个功能在许多不同条件下的行为之前，请测试每个功能是否全部正常工作。

3.所有测试均基于模型 (3. All testing is based on models)

Lesson #25. At the beginning of our careers, our testing might be just random clicking and seeing that nothing breaks. I did that, we all had to start somewhere.

第25课 。 在我们职业生涯的初期，我们的测试可能只是随机单击，而没有发现任何破裂。 我做到了，我们所有人都必须从某个地方开始。

We quickly improve and learn about boundary values, equivalence partitioning, and other concepts. Thus our testing can be eloquently expressed in this classic QA joke:

我们快速改进并了解边界值，等价分区和其他概念。 因此，我们的测试可以在这个经典的质量检查笑话中雄辩地表达出来：

A QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 99999999 beers. Orders a lizard. Orders -1 beers. Orders a uialkdsjfslk. First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.

质量检查工程师走进酒吧。 订购啤酒。 订购0杯啤酒。 订购99999999啤酒。 订购蜥蜴。 订购-1啤酒。 订购uialkdsjfslk。 第一位真正的顾客走进来，问浴室在哪里。 酒吧突然起火，杀死所有人。

Many people stop here and just repeat. This is not enough. Testing is way more complex than that. If it weren’t, then what do the dozens of books on testing talk about?

许多人在这里停下来，然后重复一遍。 这还不够。 测试要比这复杂得多。 如果不是，那么关于测试的数十本书在谈论什么呢？

As the authors themselves suggest:

正如作者自己建议的那样：

Your tests will be based primarily on your models […] A flawed model results in flawed tests. […] Study modeling. You will test better as you become more skillful in the art of modeling. Textbooks and classes about requirements analysis and software architecture can help. A wonderful way to gain skill in all kinds of modeling is to study systems thinking: See An Introduction to General Systems Thinking (Weinberg 2001).

您的测试将主要基于您的模型[…]有缺陷的模型会导致有缺陷的测试。 […]研究模型。 随着您对建模技术的熟练掌握，您将进行更好的测试。 有关需求分析和软件体系结构的教科书和课程可以提供帮助。 学习各种建模技巧的一种绝妙方法是研究系统思维：请参阅《通用系统思维导论》(Weinberg 2001)。

I’m certain that the authors are not talking about “V-Model” vs. “Agile Model” of testing, but, for example, “state-based testing” vs. “interaction testing”, or the ability to create various appropriate UML diagrams and breaking those down into scenarios. Check out this PDF document on Testing by Helsinki CS university to get a better understanding of what this lesson is talking about.

我敢肯定，作者不是在谈论测试的“ V模型”与“敏捷模型”，而是例如“基于状态的测试”与“交互测试”，或创建各种合适的功能的能力。 UML图并将其分解为场景。 请查看赫尔辛基CS大学关于测试的PDF文档，以更好地理解本课程的内容。

4.创建测试程序时，请避免使用“ 1287” (4. When you create test procedures, avoid “1287”)

Lesson #45. So you’ve used your models, and now you’re creating test scenarios with steps (actions) and expected results (outcomes).

第45课 。 因此，您已经使用了模型，现在使用步骤(动作)和预期结果(结果)来创建测试方案。

There are many tips & tricks to create a good test. For example, it must have a clear, well-defined purpose, and not just “test this, and while you’re at it, also check the other thing”.

有许多技巧和窍门可以创建一个良好的测试。 例如，它必须有一个明确的，明确定义的用途，而不仅仅是“测试它，并且在检查时，还要检查另一件事” 。

Another issue the authors decided to highlight is the usage of “1287”. In other words, the usage of a random number or other value that popped into the test creator’s head at the time of writing, but has no meaning to anyone else the next day.

作者决定强调的另一个问题是“ 1287”的用法。 换句话说，在撰写本文时突然出现在测试创建者头脑中的随机数或其他值的使用对第二天的其他任何人都没有意义。

Is this a special value? If so — why? Can I use another 4-digit number? Can I use a 5-digit number? Let me spend the next 30 minutes figuring this out or remain confused forever.

这是一个特殊的价值吗？ 如果是这样-为什么？ 我可以使用另一个4位数字吗？ 我可以使用5位数字吗？ 让我在接下来的30分钟里花点时间解决这个问题，否则请永远保持困惑。

I frequently encounter this issue too in both test scenarios and automation scripts. Here are practical tips to avoid such confusion:

在测试方案和自动化脚本中，我也经常遇到此问题。 以下是避免此类混淆的实用技巧：

• In test scenarios, don’t write “1287”, but rather “any large value up to 5 digits, for example, 1287”. This gives others clarity and freedom to choose an appropriate value during the next regression run.

  在测试方案中 ，不要写“ 1287”，而是“最多5位的任何大数值，例如1287”。 这使其他人在下一次回归运行期间可以清晰自由地选择合适的值。

• In automation scripts, use clear variable names to indicate intent:

  在自动化脚本中，使用明确的变量名称来表示意图：

int someLargeValue = 1287; // yes!

int someLargeValue = 1287; //是的！

int val = 1287; // no!

int val = 1287; //不！

5.你就是你写的 (5. You are what you write)

Lesson #55. You’ve executed your tests, and you’ve found a bug! Naturally, you write up a bug report. Listed under the “Bug Advocacy” section, the authors argue that bug reports

第55课 。 您已经执行了测试，并且发现了一个错误！ 自然，您编写了一个错误报告。 在“ Bug Advocacy”部分下列出的作者认为，错误报告

mold your readers’ perception of you. The better your reports, the better your reputation.

塑造读者对您的看法。 您的报告越好，您的声誉就越好。

Furthermore:

此外：

Weak reporting generates extra work for the programmers. If you waste enough of their time, they’ll want to avoid you and your work.

报告薄弱会给程序员带来额外的工作。 如果您浪费他们的时间，他们会避免您和您的工作。

I couldn’t agree more. If the SUT malfunctions, someone has to do the investigation into what? why? when? and where? Whatever corners you cut, the developers will have to compensate or reject the raised report if they don’t care enough.

我完全同意。 如果SUT发生故障，则必须对什么进行调查？ 为什么？ 什么时候？ 在哪里？ 无论您遇到什么困难，如果开发人员对它们的关注程度不够，他们都将不得不补偿或拒绝所提出的报告。

So make sure you put effort into your bug reports! I describe what things should go into it in the section “Your bug report is your diplomat’s face” of my other article:

因此，请确保您已将精力投入到错误报告中！ 我在另一篇文章的“您的错误报告是您的外交官的脸”部分中描述了应该包括的内容：

6.不要坚持要修复每个错误。 选择你的战斗 (6. Don’t insist that every bug be fixed. Pick your battles)

Lesson #97. I’ve certainly made an unnecessary fuss several times about rejected bugs that I reported. How could I not? It hurt my junior tester’s ego!

第97课。 对于我报告的已拒绝的错误，我肯定做过几次不必要的大惊小怪。 我怎么可能 它伤害了我的初级测试员的自我！

The mistake of fighting for every possible issue erodes the benefits of the first tip in this article — any good relationship you’ve built up with the developers over the past weeks or months can be undone within a day or two.

为每个可能的问题而战的错误侵蚀了本文第一个技巧的好处-您在过去几周或几个月内与开发人员建立的任何良好关系都可能在一两天内被撤消。

If you are certain it’s a major flaw and you’ve been misunderstood — sure, push forward as diplomatically as possible and involve other stakeholders for a second (or third) opinion. As a last resort, ask for an official email or comment on the ticket to state “this is not an issue” (and watch most people shy away from that responsibility).

如果您确定这是一个重大缺陷，并且被误解了-当然，请尽可能以外交方式推动并请其他利益相关者征求第二(或第三)意见。 作为最后的选择，要求提供正式电子邮件或在票证上注明“这不是问题” (并注意大多数人会回避这一责任)。

However, learn to let some of your bugs go:

但是，请学习放开一些错误：

• Firstly, it’s not a matter of life and death, is it? (unless you’re testing medical or aviation software).

  首先， 这不是生死攸关的问题，对吗？ (除非您正在测试医疗或航空软件)。

• Second, you’ve done your job, it’s recorded, and your back is covered. At some point, your time is better invested if you keep searching for new bugs, instead of arguing about the old ones.

  其次， 您已完成工作 ，已记录下来，并且遮住了您的背部。 在某个时候，如果您继续寻找新的错误，而不是争论旧的错误，那么您的时间将得到更好的投入。

• Lastly, it helps to remember that this is definitely not your last rejected bug.

  最后，它有助于记住这绝对不是您最后拒绝的bug。

7.当您错过了一个错误时，请检查错过是令人惊讶的还是策略的自然结果。 (7. When you miss a bug, check whether the miss is surprising or just the natural outcome of your strategy.)

Lesson #41. The bugs reported by you got fixed and retested, and the new software version was released into the wilderness of the outside world. But some users still found bugs.

第41课。 您报告的错误已得到修复和重新测试，新的软件版本已发布到外界的旷野。 但是一些用户仍然发现错误。

You will miss bugs. I might miss a bug tomorrow. This is inevitable. Testers will stop missing bugs when developers stop writing them.

您会错过错误。 我明天可能会错过一个错误。 这是不可避免的。 当开发人员停止编写错误时，测试人员将停止丢失错误。

But there’s an important question to be asked:

但是有一个重要的问题要问：

Did we miss it because we were following a good test strategy (based on well-developed test models) and just happened not to find that particular problem?

我们是否错过了它，是因为我们遵循的是良好的测试策略(基于完善的测试模型)，而恰巧没有找到该特定问题？

If the answer is “yes”, and you simply didn’t catch it because of real-world time and other constraints, then just carry on. But, if there was a major flaw in communication, requirement understanding, or other factors, take this as an opportunity to improve. Don’t let the same mistake happen again.

如果答案是“是”，并且您只是因为现实世界的时间和其他限制而没有抓住答案，那就继续吧。 但是，如果在沟通，需求理解或其他因素方面存在重大缺陷，请将其作为改进的机会。 不要让相同的错误再次发生。

“Insanity is doing the same thing over and over again and expecting different results.”

“精神错乱一遍又一遍地做着同样的事情，并期望得到不同的结果。”

— Albert Einstein

- 艾尔伯特爱因斯坦

8.旋转测试器跨功能 (8. Rotate testers across features)

Lesson #191. Let’s move on beyond the context of a single tester just doing his or her job and into team dynamics and management.

课＃191。 让我们继续超越单个测试人员的工作范围，而只是完成他或她的工作，并进入团队动态和管理。

You typically work in a team. It doesn’t matter if the size of your team is 2 or 20. What matters is to occasionally rotate teammates across features or tested systems.

您通常在团队中工作。 团队的人数是2还是20，都没有关系。重要的是，偶尔在功能或经过测试的系统之间轮换团队成员。

Let’s say there are 5 of you, and you are responsible for components A, B, and C of a larger architecture. The worst thing you can do is assign testers to specific components and keep it static, and for good reasons:

假设您有5个人，并且您负责较大体系结构的组件A，B和C。 您能做的最坏的事情是将测试人员分配给特定的组件并使其保持静态，这有充分的理由：

1. It’s boring to keep poking the same thing. Competent people desire variety or they leave.

   不断戳相同的东西很无聊 。 有能力的人渴望变化，否则他们就会离开。

2. Bus factor of 1. Imagine component B is tested solely by Bob. Bob’s a great guy, but he suddenly leaves or falls sick, and there’s a major release scheduled for next Friday (terrible idea, anyway). Now you have a major problem because there’s absolutely no way Kate, John, or Dave are going to ramp up their knowledge quickly enough to do a decent job.

   总线系数为1 。 想象一下，组件B仅由Bob进行测试。 鲍勃(Bob)是个好人，但他突然生病或生病，下个星期五定要发布一个重要唱片(无论如何，这都是可怕的想法)。 现在您遇到了一个大问题，因为凯特，约翰或戴夫绝对不可能以足够快的速度增加他们的知识来做一个体面的工作。

You can either rotate or ensure a balanced distribution of knowledge. For example, each component may have a primary tester and a secondary “backup” tester.

您可以轮换或确保知识的均衡分配。 例如，每个组件可以具有一个主测试器和一个辅助“备份”测试器。

• Component (or feature) A is mostly handled by Bob.

  组件(或功能部件)A主要由Bob处理。

• Kate is the primary tester for B, but she also works on A every other week, so she’s in the loop and could do an OK job if Bob suddenly disappears.

  凯特(Kate)是B的主要测试员，但她每隔一周还要在A上工作，因此她处于循环中，如果Bob突然消失，她可以做得很好。

• John is the primary tester for C, but he also works on B…约翰是C语言的主要测试人员，但他也从事B语言的测试。

You get the picture.

您得到图片。

Do note that some systems are quite complex and require time (6+ months sometimes) to familiarize yourself with. In such cases, it is prudent not to pull people away from their task just as they are getting the hang of it. This also leads us to the next lesson.

请注意，有些系统非常复杂，需要一定时间(有时需要6个月以上)来熟悉自己。 在这种情况下，请谨慎行事，不要让人一the不振。 这也使我们进入下一课。

9.不要期望人们能够有效地处理多个项目 (9. Don’t expect people to handle multiple projects efficiently)

Lesson #215. Multitasking is a myth. Do a quick search and be overwhelmed by the number of articles, research, and literature on the topic.

第215课。 多任务处理是一个神话 。 快速搜索，然后被该主题的文章，研究和文学数量所淹没。

I saw people work on several things at the same time (well, rather constantly switching), but I never saw any outstanding results, only mediocre ones.

我看到人们在同一时间从事多项工作(嗯，要不断地切换)，但是我从未见过任何出色的结果，只有中等水平的结果。

I don’t think I ever saw anyone working on several projects efficiently, perhaps except for Elon Musk, who works 90–120 hours a week. Good for him. The rest of us mortals should stay away from overworking and multitasking! Organize yourselves or talk to your manager, but try to work on the same thing until you feel reasonably comfortable and you can take on more.

我认为我从未见过有人高效地从事多个项目，除了埃隆·马斯克(Elon Musk) 每周工作90-120小时 。 对他有好处。 我们其余的凡人应该远离过度劳累和多任务！ 整理自己或与您的经理交谈， 但尝试做同样的事情，直到您感到相当舒适为止并且可以承担更多责任。

So don’t confuse timely rotating and balanced work assignment (#8) with constantly pulling people back and forth between tasks and projects (#9).

因此，不要将及时轮换和平衡的工作分配(＃8)与在任务和项目(＃9)之间不断拉动人员来混淆。

10.许多其他公司像您一样陷入困境 (10. Lots of other companies are as screwed up as yours)

Lesson #252. You’ve had enough! Nothing’s working, you are unappreciated, developers keep breaking things, and, of course, your boss is an idiot!

第252课。 你受够了！ 什么都没做，您不被欣赏，开发人员不断破坏事情，当然，您的老板是个白痴！

You may be right, and perhaps moving on to another job or team is the best move, but it is FAR from guaranteed. I know a software developer who, according to his words, moved from an OK company to bad and then to even worse.

您可能是正确的，也许转到另一份工作或团队是最好的举动，但这是从保证中获得的。 我认识一个软件开发人员，按照他的话， 他从一家行之有效的公司发展到糟糕，然后甚至恶化。

When the grass seems greener on the other side, try to talk to other people and get their perspective. Perhaps you will discover that your current place isn’t worse than the others. If that is the case, switching would be a wasted effort, so you don’t, but adjust your expectations and end up with a balanced perspective.

当另一侧的草看起来更绿时，请尝试与其他人交谈并取得他们的看法。 也许您会发现您的当前位置并不比其他地方差。 如果是这样的话，切换将是一种浪费的努力，所以您不必这样做，而是调整您的期望并最终获得平衡的观点。

结论 (Conclusion)

• The very fact that a book called “Lessons Learned in Software Testing” contains a whopping 297 lessons means one thing — testing, when done right, is an endeavor requiring great skill, knowledge, and experience.

  事实上，一本名为《 软件测试中的经验教训 》的书包含多达297堂课，这意味着一件事-测试，如果做得正确，是一项需要大量技能，知识和经验的努力。

• Hone your testing skills. I thoroughly recommend you get a copy of the book or check your local library to see if they have it.

  磨练您的测试技能 。 我强烈建议您获得这本书的副本，或检查您当地的图书馆是否有书。

You may also be interested in:

您也可能对。。。有兴趣：

This article is part of the “Tales of an opinionated SDET” series.

本文是“ SDET故事集”系列的一部分。

Andrejs Doronins is a professional Test Automation Engineer and a Pluralsight course author. If you wish to learn test automation — check out my courses — a free trial will give you access to them and the entire library of 7000+ other courses.

Andrejs Doronins是一名专业的测试自动化工程师，也是 Pluralsight课程的作者 。 如果您想学习自动化测试-请查看我的课程- 免费试用 将使您可以访问它们以及7000多种其他课程的整个库。