自学是一门手艺_错误报告是一门科学

自学是一门手艺

I’m a former molecular microbiologist who made a career change into tech and landed a job as a mobile application software tester. When I began my job I knew nothing about app development or how to test. But, little did I know, my skills as a research scientist would help me be a better bug finder and reporter. Today, I’m going to explain how bug reporting is a science and why testers should consider adopting a scientific thought process.

我是一位前分子微生物学家，他的职业转变为技术，并找到了移动应用软件测试员的工作。 当我开始工作时，我对应用程序开发或测试一无所知。 但是，我几乎不知道，我作为研究科学家的技能将帮助我成为一个更好的错误发现者和报告者。 今天，我将解释错误报告是一门科学，为什么测试人员应该考虑采用科学的思维过程。

1.科学家很好奇 (1. Scientists are curious)

Working for a company that creates various and diverse app technologies presents an amazing opportunity to be exposed to many different products, but the need to quickly switch between projects can be tricky to manage. The time we can devote to developing extensive test suites is limited, so it’s important to prioritise and know when to leverage exploratory testing. During testing, if I see behaviour that isn’t exactly what I expect, I drill down to find out more. Our team may not have time to write out every negative test and edge case that exists, so during testing I think of creative angles to cover all the weird and wacky ways a user may use the product.

在一家创建了多种多样的应用程序技术的公司工作，提供了接触许多不同产品的绝佳机会，但是在项目之间快速切换的需求可能很难管理。 我们可以投入大量时间来开发广泛的测试套件，因此，确定优先级并知道何时利用探索性测试非常重要。 在测试过程中，如果我发现行为与我所期望的不完全相同，那么我将深入研究以了解更多信息。 我们的团队可能没有时间写出每个存在的负面测试和边际案例，因此在测试期间，我想到了创造性的角度来涵盖用户可能会使用该产品的所有奇怪和古怪的方式。

Corentin Penloup, edit by unknown Corentin Penloup的原创漫画，由未知编辑

You’d be hard pressed to find a scientist who isn’t interested in the ‘why’, and this is an attribute that will set testers apart from the pack. Finding bugs always excites me — I’ve found something that the developer missed and this is what I’m employed to do. But a tester’s job shouldn’t end there. When I find a defect, I then think about the why — why has this bug occurred? Is it due to a newly developed feature, or has it been flying under the radar in previous releases? Does the problem lie with the backend or frontend? Does it affect multiple operating platforms and devices?

您很难找到对“为什么”不感兴趣的科学家，而这是一个使测试人员与众不同的属性。 发现错误总是让我兴奋—我找到了开发人员错过的东西，而这正是我受雇的工作。 但是测试人员的工作不应就此结束。 当我发现缺陷时，我会思考原因 -为什么会发生此错误？ 是由于新开发的功能，还是在以前的版本中飞速发展？ 问题出在后端还是前端？ 它会影响多个操作平台和设备吗？

If a tester is able to raise a bug report with answers to questions like these, not only will it save the developer time, but it will direct them where to start, and they will therefore be more likely to pick up the bug report and resolve it.

如果测试人员能够提出带有此类问题的答案的错误报告，不仅可以节省开发人员时间，还可以将他们定向到哪里开始，因此他们更有可能选择错误报告并解决问题。它。

2.科学家了解并运用科学方法 (2. Scientists understand and apply the scientific method)

Most of us learned the scientific method, or experimental methodology, years ago in high school, and that’s where we left it. But for scientists it’s a process ingrained in our day-to-day work. The scientific method can be boiled down into a few steps:

我们大多数人几年前在高中就学习了科学方法或实验方法，这就是我们留下的地方。 但是对于科学家来说，这是我们日常工作中根深蒂固的过程。 科学方法可以归纳为以下几个步骤：

1. Make an observation
   观察一下
2. Ask a question
   问一个问题
3. Form a hypothesis
   形成假设
4. Test the hypothesis
   检验假设
5. Iterate — if the hypothesis fails, form a new one and test it. (Wash, rinse, repeat)
   进行迭代-如果假设失败，请形成一个新的假设并进行测试。 (洗涤，冲洗，重复)

xkcd XKCD

So, how can we apply this to testing? Imagine you’re testing a mobile app where users are able to make a booking. But when the Submit Booking button is tapped, the app crashes.

那么，我们如何将其应用于测试？ 假设您正在测试一个移动应用程序，用户可以在此进行预订。 但是，当点击“提交预订”按钮时，该应用程序将崩溃。

Some testers may immediately write up a bug report, “Submitting booking causes crash” but if we apply the scientific method we may be able to add valuable information to that report. Let’s break it down.

一些测试人员可能会立即写出一个错误报告“提交预订会导致崩溃”，但是如果我们采用科学的方法，我们可能能够在该报告中添加有价值的信息。 让我们分解一下。

Observation: App crashes when Submit Booking is tapped

观察：点击提交预订时，应用程序崩溃

Question: Does this occur for all users? The app allows bookings to be made as a logged-in user and a guest user

问题：是否对所有用户都这样？ 该应用程序允许以登录用户和访客用户身份进行预订

Hypothesis: Given this test failed as a logged-in user, the bug will only occur for logged-in users

假设：鉴于此测试以登录用户身份失败，因此该错误仅会在登录用户中发生

Test: Complete a booking as a guest user. This should not cause the crash

测试：以访客用户身份完成预订。 这不应该导致崩溃

So we run the above test and discover that our hypothesis is correct. Great! Now our bug report can be more specific, “Logged-in user — submitting bookings causes crash”. Okay. Can we provide more information? Of course! There are many other questions that we can ask, running through the above process to narrow down the exact cause of the crash.

因此，我们进行了上述检验，发现我们的假设是正确的。 大！ 现在，我们的错误报告可以更具体：“登录用户-提交预订会导致崩溃”。 好的。 我们可以提供更多信息吗？ 当然！ 在上述过程中，我们还有很多其他问题要问，以缩小崩溃的确切原因。

3.科学家了解相关性因果关系 (3. Scientists understand that correlation ≠ causation)

xkcd XKCD

As I mentioned earlier, scientists are naturally curious and constantly ask questions in an attempt to answer the why, but they also know what kind of questions to ask. We’ve all heard it before, but it’s important to understand exactly what is meant by ‘correlation does not imply causation’. In terms of testing, this means not raising a bug report for “Booking — logged-in user submitting booking causes crash” without first confirming that this defect does not also occur for guest users.

正如我前面提到的，科学家天生好奇，并不断提出问题以试图回答“ 为什么” ，但他们也知道要提出什么样的问题。 我们以前都听过，但是重要的是要准确地理解“相关并不意味着因果关系”的含义。 在测试方面，这意味着在未先确认来宾用户也不会发生此缺陷的情况下，不会针对“预订-登录的用户提交预订导致崩溃”提出错误报告。

To determine the root cause of an observation, the scientist (or tester) should have a good idea of all the variables involved. Having a thorough understanding of the product is necessary, and knowledge of the underlying code is a huge benefit. At Adapptor, the test team works closely with the developers and are able to brainstorm possible causes when testers hit a roadblock.

为了确定观察的根本原因，科学家(或测试人员)应该对所有涉及的变量有一个很好的了解。 对产品有透彻的了解是必要的，并且对底层代码的了解是巨大的好处。 在Adapptor，测试团队与开发人员紧密合作，并能够在测试人员遇到障碍时集思广益。

Let’s examine some potential variables in our booking example.

让我们在预订示例中检查一些潜在变量。

First consider the main system variables:

首先考虑主要系统变量：

• Is it operating system related? If the bug is occurring on an iPhone, run the same test on an Android device
  它与操作系统有关吗？ 如果错误发生在iPhone上，请在Android设备上运行相同的测试
• If it is operating system specific, could it be related to the OS version? Run the test across devices with varied OS versions
  如果是特定于操作系统的，是否可以与OS版本相关？ 在具有不同OS版本的设备上运行测试

Now think about the app:

现在考虑一下该应用程序：

• Does the issue occur for all user types?
  是否针对所有用户类型都会出现此问题？
• Could it be related to the type or place of a booking?
  可能与预订的类型或地点有关吗？
• If it is only occurring for logged-in users, does it occur for users with different booking histories?
  如果仅发生在已登录用户上，是否发生在具有不同预订历史记录的用户上？
• Might the cause be the backend fetching previous booking data to prevent overlapping bookings?
  原因可能是后端获取以前的预订数据以防止预订重叠吗？
• Is the booking still processed? Does it appear under upcoming bookings?
  预订仍在处理吗？ 它会出现在即将到来的预订中吗？

These are just a few of the many variables that could be involved. When working my way through them, I always start with the simplest explanation and then proceed down the list.

这些只是可能涉及的许多变量中的几个。 在研究它们的过程中，我总是从最简单的解释开始，然后继续列出。

4.科学家知道什么时候该退出 (4. Scientists know when to call it quits)

A situation familiar to many scientists: you’ve dedicated a large amount of time to an experiment but it won’t work. There comes a point in time where regardless of the effort applied it’s not viable to proceed. The concept of sunk cost highlights this perfectly. A good scientist will be continually evaluating if their methodology is worth continuing, or if it’s time to explore a new process.

许多科学家都熟悉的情况：您已经花费了大量时间进行实验，但无法进行。 到了某个时间点，无论付出什么努力，都无法继续进行。 沉没成本的概念完美地突出了这一点。 一个好的科学家将不断评估他们的方法是否值得继续，或者是否该探索一个新的过程。

I’ve explored the importance of investigating and gathering sufficient data to aid bug fixing. But testers need to be aware of the time spent doing this. The simplest way to do this is time-boxing—allocating time for exploratory testing and bug investigation.

我探讨了调查和收集足够的数据以帮助修复错误的重要性。 但是测试人员需要注意花费的时间。 执行此操作的最简单方法是装箱-为探索性测试和错误调查分配时间。

Exploratory testing should always have purpose and scope, also known as a charter. Once a charter is designed, testers are able to assign it priority, based on how important the features involved are, and then allocate a time limit.

探索性测试应始终具有目的和范围，也称为章程 。 设计了章程后，测试人员可以根据所涉及功能的重要性来为其分配优先级，然后分配时间限制。

When investigating a bug, either within an exploratory or scripted test, a similar process can be applied. First, determine the severity of the bug. Then, consider the complexity and diversity of variables. Finally, decide how much time should be spent on investigation.

在探索性测试或脚本测试中调查错误时，可以应用类似的过程。 首先，确定漏洞的严重性。 然后，考虑变量的复杂性和多样性。 最后，决定应花费多少时间进行调查。

5.科学家了解没有结果仍然是结果 (5. Scientists understand that no result is still a result)

I recall a research project where I was certain I knew the reason behind my observation, but after more than a year’s worth of work, my research did not support my original hypothesis — it couldn’t tell me what had caused my original observation. Disheartened, I told a fellow researcher that I’d wasted a year with nothing to show for it. They told me I was wrong, I had stacks of research, it just told a different story to the one I’d set out to prove.

我记得一个研究项目，我确定自己知道观察的背后原因，但是经过一年多的工作，我的研究不支持我的原始假设-它无法告诉我是什么原因导致了我的原始观察。 令我沮丧的是，我告诉一位研究员，我浪费了一年没有什么可证明的。 他们告诉我我错了，我进行了大量研究，它讲述的故事与我打算证明的故事不同。

Mr. Lovenstein, edit by unknown Lovenstein先生的原创漫画，未知编辑

I see the same scenario repeated in my current work. I’ll find a bug, identify and test all variables I can think of, but none of them will explain why the bug is occurring. It’s times like that you must remember, providing the developer with a bug report which has ruled out all these variables is leagues better than just identifying the bug and passing it on.

我在当前的工作中看到了相同的情况。 我会找到一个错误，识别并测试我能想到的所有变量，但是它们都无法解释该错误的发生原因。 有时候，您必须记住，向开发人员提供一个排除了所有这些变量的错误报告比仅仅识别错误并将其继续传递要好得多。

6.训练有素的科学家以简明而详尽的方式进行报告 (6. Scientists are trained to report in a concise, yet detailed manner)

Scientific writing is tough but once you grasp it, it becomes second nature. When reporting findings, it is crucial to present only the information which directly relates to your research. Repetition, unrelated details, and wordy phrasing are beaten out of you as supervisors return red-marked drafts over and over.

科学写作很难，但是一旦掌握了它，它就会成为第二本性。 报告结果时，仅提供与您的研究直接相关的信息至关重要。 主管们一遍又一遍地用红色标记草稿，重复，无关的细节和冗长的措辞被击败。

Using these learned skills means when I raise a bug report, I aim to create a title that conveys the issue in as few words as possible, outline how to reproduce the bug in terms developers will understand, and explain the different variables examined and the results of those tests.

利用这些学到的技能，当我提出错误报告时，我的目标是创建一个标题，以尽可能少的文字传达问题，概述如何以开发人员可以理解的术语重现该错误，并解释所检查的不同变量和结果这些测试中。

It’s great to practise thorough testing in an effort to determine the root cause of a bug, but there is no point if that information is not conveyed to the developer. Say you’ve now determined that the booking bug occurs only for logged-in users with a booking history, on iOS only, and the booking is not processed as it does not appear as an upcoming booking. Make sure this information is clearly laid out in your report. It is also critical to convey to the developer that you tried the alternatives and they did not cause the issue. Simply stating, “System information: iOS”, does not convey that the bug occurs across different OS versions, but not on Android.

进行彻底的测试来确定错误的根本原因非常好，但是如果没有将信息传达给开发人员则毫无意义。 假设您现在确定预订错误仅发生在具有预订历史记录的登录用户(仅在iOS上)，并且未处理预订，因为它不会显示为即将进行的预订。 确保在您的报告中清楚地列出了这些信息。 将开发人员尝试过的替代品并没有引起问题的信息传达给开发人员也很重要。 简单地说“系统信息：iOS”并不能说明该错误是在不同的OS版本上发生的，但不是在Android上发生的。

不要让开发人员筛选不必要的细节 (Don’t make developers sift through unnecessary details)

On the flip side, don’t write up a bug report with so much information that it’s difficult to understand the actual issue. Testers can end up running hundreds of scenarios to determine the cause of a bug and it is a skill to determine which results are important to include in a report, and what is unnecessary.

另一方面，不要编写包含太多信息的错误报告，以致于难以理解实际问题。 测试人员最终可能会运行数百种场景来确定错误的原因，这是一种技巧，可以确定将哪些结果包括在报告中是重要的，以及哪些是不必要的。

Using precise language is also important. When writing titles, avoid using full sentences and stick to key words. The titles below contain the same amount of information, but the latter is more concise and easier to read:

使用精确的语言也很重要。 撰写标题时，避免使用完整的句子并坚持使用关键词。 以下标题包含相同数量的信息，但后者更为简洁且易于阅读：

“Logged in users on iOS with previous booking history causes the app to crash when making a booking”

“使用以前的预订历史记录在iOS上登录的用户导致应用程序在预订时崩溃”

“[iOS] Booking — Logged in user with booking history — submission causes crash”

“ [iOS]预订-登录具有预订历史记录的用户-提交会导致崩溃”

考虑一下您如何呈现数据 (Think about how you’re presenting the data)

Screenshots are an incredibly useful tool and at times can mean the developer doesn’t need to reproduce the bug to visualise the problem or be sure it has been reproduced correctly.

屏幕截图是一个非常有用的工具，有时可能意味着开发人员不需要重现该错误以可视化该问题或确保已正确重现了该错误。

Sometimes it’s useful to provide comparisons of different builds. Rather than simply adding the screenshots as an attachment to your report, think about how you’d want the reader to view these images. It’s far more meaningful, and easier to view, if these images are presented side-by-side, rather than as two separate attachments.

有时提供不同内部版本的比较很有用。 与其简单地将屏幕截图作为附件添加到报告中，还不如考虑您希望读者如何查看这些图像。 如果这些图像并排显示，而不是作为两个单独的附件显示，那将更有意义且更易于查看。

Utilise text formatting, tables, and lists to present your data so that developers can quickly comprehend the bug.

利用文本格式，表格和列表来显示您的数据，以便开发人员可以快速理解该错误。

综上所述 (In summary)

Testing goes far beyond writing and executing scripts. As testers, we know our products inside and out and therefore are the best people to be diagnosing the cause of the defects we identify. I enjoy breaking things. There is always a thrill in finding a bug, but let’s be accountable for finding the cause. That’s what working in a team is all about, right?

测试远远超出编写和执行脚本的范围。 作为测试人员，我们从内到外都知道我们的产品，因此是诊断我们发现缺陷原因的最佳人选。 我喜欢破东西。 寻找错误总是很激动的，但是让我们对找到原因负责。 这就是团队工作的全部内容，对吧？

翻译自: https://medium.com/adapptor/bug-reporting-is-a-science-c5ab87f4e17a

自学是一门手艺