软件测试质量过程检测文档_如何编写实际上有效的质量检查文档

软件测试质量过程检测文档

A software product is like an airplane: it must undergo a technical check before launch.

软件产品就像飞机：必须在发射前经过技术检查。

Quality Assurance is a necessary step towards launching a successful software product. It is just a small part of all the project work, but nobody said it would be simple.

质量保证是启动成功软件产品的必要步骤。 这只是所有项目工作的一小部分，但没有人说这会很简单。

There are so many types of software testing – automated and manual, exploratory and functional, compatibility, UI/UX,  regression, unit, API, and performance testing. Good luck wrapping your head around all of them!

软件测试的类型很多，包括自动化和手动，探索性和功能性，兼容性，UI / UX，回归，单元，API和性能测试。 祝你好运，把头围住！

What is common for all these types, however, is that each requires you to write thorough QA testing documentation. The quality of test documents defines whether your work will prove useful or go in vain.

但是，所有这些类型的共同点是，每种类型都需要您编写详尽的QA测试文档。 测试文件的质量决定了您的工作将证明有用还是徒劳。

I've written this article to make your life a bit easier. So here it is, your ultimate guide on how to write software QA documentation that will work.

我写这篇文章是为了让您的生活更轻松。 因此，这是您如何编写有效的软件质量检查文档的最终指南。

制定测试计划和测试进度报告 (Make a Test Plan and a Test Progress Report)

The test plan is a guiding document which outlines the bigger picture of the QA process, and includes a to-do list, strategy, resources, and schedule.

测试计划是一个指导性文件，概述了质量检查过程的总体情况，并包括待办事项列表，策略，资源和时间表。

Before creating a QA plan document, ask yourself “What is the purpose of the software solution?” and “What features need to be tested?”. Do not rush into testing every single part of your software. You need to decide what methodologies, technologies, and tools you will use.

在创建质量检查计划文档之前，请问自己“软件解决方案的目的是什么？” 和“需要测试哪些功能？”。 不要急于测试软件的每个部分。 您需要确定将使用的方法，技术和工具。

The test plan will help you understand the following:

测试计划将帮助您了解以下内容：

• What are the acceptance criteria?
  接受标准是什么？
• What resources do you need? What operating systems, how many copies, and  with what license? Do you need any technical consultants?
  您需要什么资源？ 什么操作系统，多少副本以及具有什么许可证？ 您需要任何技术顾问吗？
• Are your roles and responsibilities well-designated?
  您的角色和职责是否经过适当设计？
• What are testing timeframes?
  什么是测试时间表？

The test progress report is another part of the QA documentation, which is similar to the test plan but with added data on the current progress. This document lets you and your development team monitor project progress and identify organizational issues, if any.

测试进度报告是质量检查文档的另一部分，与测试计划相似，但是增加了有关当前进度的数据。 本文档使您和您的开发团队可以监视项目进度并确定组织问题(如果有)。

创建测试用例 (Create Test Cases)

Once you've clarified the set of functions that need to be tested in your test plan, you need to create a test case for each part of your software.

在明确了测试计划中需要测试的功能集之后，您需要为软件的每个部分创建一个测试案例。

Test cases are pretty simple – this QA documentation consists of 7 sections: ID, Test Case, Testing Steps, Expected Result, Status, Actual Result, and Comments.

测试用例非常简单–此质量检查文档包含7个部分：ID，测试用例，测试步骤，预期结果，状态，实际结果和注释。

1. ID is a unique number assigned to your test case.

   ID是分配给您的测试用例的唯一编号。

2. In the Test Case section, you point out the requirement(s) you will be testing and provide a link to it in the specifications document.

   在“ 测试用例”部分中，指出要测试的需求，并在规格文档中提供指向该需求的链接。

3. In the Testing Steps section, you list all the actions needed to complete a test case.

   在“ 测试步骤”部分中，列出了完成测试用例所需的所有操作。

4. In the Expected Result section, you summarize the outcome of a particular test if it is successful.

   在“ 预期结果”部分中，您总结特定测试的结果(如果成功)。

5. In the Status section, you indicate if a particular step passed or failed testing.

   在状态部分中，您可以指示特定步骤是否通过测试或失败。

6. In the Actual Result section, you explain the outcome of a failed test.

   在“ 实际结果”部分中，您将解释测试失败的结果。

7. The Comments section is not obligatory, but you can add it to leave some additional notes.

   “ 注释”部分不是强制性的，但您可以添加它以留下一些其他注释。

编写缺陷报告 (Write a Defect Report)

The defect report is an important element of QA documentation. It registers any unwanted issue with your program. It is a crucial element of the project documentation, which navigates you towards getting a bug-free software solution.

缺陷报告是质量检查文档的重要组成部分。 它会在程序中注册任何不需要的问题。 它是项目文档中的关键元素，可引导您获得无错误的软件解决方案。

Sounds simple, right? Yes, but only until you start documenting. Here, you can see an example of a typical defect report:

听起来很简单，对吧？ 是的，但仅在开始记录之前。 在这里，您可以看到典型缺陷报告的示例：

The defect report consists of the following sections: identifier, summary, description, steps to reproduce, reproducibility, severity, priority, environment, and attachments.

缺陷报告包括以下部分：标识符，摘要，描述，重现步骤，可再现性，严重性，优先级，环境和附件。

1. Each particular software issue is assigned a unique number – the identifier. It optimizes navigation through QA documents and facilitates communication between developers, testers, and PMs.

   每个特定的软件发行都分配有一个唯一的编号- 标识符 。 它优化了质量检查文档的导航，并促进了开发人员，测试人员和PM之间的通信。

2. In the summary section, you provide a concise answer to three simple questions: what happened, where, and under what circumstances.

   在摘要部分中，您将提供对三个简单问题的简要答案：发生了什么，在哪里发生以及在什么情况下发生。

3. In the description section, you describe the bug in detail. You should tell about the actual results and the expected ones. It's useful to provide a link to your software requirements.

   在描述部分中，您将详细描述该错误。 您应该告知实际结果和预期结果。 提供指向您的软件要求的链接很有用。

4. Then, you write about the steps to reproduce (STR). This shows developers exactly how to reproduce the issue. Don't miss a step or your report may return to you.

   然后，编写重现步骤(STR) 。 这向开发人员确切说明了如何重现该问题。 不要错过任何一步，否则您的报告可能会退还给您。

5. In the reproducibility section, you clarify if the bug appears every time you follow the STR. You should use numbers to show approximate chances, for example 7 times out of 10.

   在“可再现性”部分，您确定每次遵循STR时是否都出现错误。 您应该使用数字来显示大概的机会，例如10中的7次。

6. In the severity section, you explain how much harm the bug may bring to the project. In other words, it shows the technological degree of influence of the defect on the entire system. Even a small issue may badly affect the entire application.

   在“ 严重性”部分中，您将解释该错误可能对项目造成的危害。 换句话说，它显示了缺陷对整个系统的技术影响程度。 即使是很小的问题也可能严重影响整个应用程序。

7. Priority shows how important a particular defect report is. Priority can be denoted with the help of  letters – “A” for the most urgent and “Z” for the least urgent, numbers – “1” for the most urgent and “9” for the least urgent, or simply words  like “high”, “medium”, or “low”.

   优先级显示特定缺陷报告的重要性。 优先级可以通过字母来表示–“ A”表示最紧急，“ Z”表示最紧急，“ 1”表示最紧急，“ 9”表示最紧急，或者简单地表示为“高” ”，“中”或“低”。

8. In the environment section, you should define which operating systems or browser versions were affected.

   在环境部分，您应该定义受影响的操作系统或浏览器版本。

9. Finally, the attachments include the list of videos, screenshots, or console logs files added to the defect report.

   最后， 附件包括添加到缺陷报告中的视频，屏幕截图或控制台日志文件的列表。

保留这些有用的技巧，以确保缺陷报告的编写 (Keep These Useful Tips for Defect Report Writing in Mind)

1. Write a sufficient and adequate summary. It does not matter if it is long or short. What matters is that it should be clear.
   编写足够的摘要。 多头或空头都没有关系。 重要的是应该清楚。
2. Have a look at the summary and the description. Do they look pretty much the  same? You must have forgotten to outline expected and actual results in the description and to add the link to requirements.
   查看摘要和说明。 他们看起来差不多吗？ 您必须忘记在描述中概述预期结果和实际结果，并将链接添加到需求中。
3. Capture the issue with the help of a screenshot. It may save you and the development team a lot of time. Sometimes, one glance at the picture is just enough to understand the situation.
   借助屏幕快照捕获问题。 它可以为您和开发团队节省大量时间。 有时，只看图片就足以了解情况。
4. Before reporting the issue, try to reproduce it at least 3 times to be sure that it exists.
   在报告问题之前，请尝试至少重现3次以确保存在。
5. Report the issue ASAP and notify your project manager or product owner if the issue is major.
   如果问题严重，请尽快报告此问题，并通知您的项目经理或产品所有者。
6. Check for grammar mistakes in your QA documentation so you're not taken down by the grammar police.
   检查您的质量检查文档中的语法错误，这样您就不会被语法警察逮捕。
7. However comical it sounds, make sure that the issue is not a feature – review the documentation again!
   无论听起来多么可笑，请确保该问题不是功能-再次查看文档！
8. Do not miss any important information in your Steps to Reproduce.
   在复制步骤中不要错过任何重要信息。

提交缺陷报告 (Submit a Defect Report)

Defect reports go through a lifecycle – from the moment you report an issue to the moment the issue is closed.

缺陷报告贯穿整个生命周期-从报告问题到关闭问题。

The first step is to compile and submit the defect report. At this point, the Project Manager or a tech lead decides whether to assign it to a developer or to decline it on the grounds of insufficiency or inadequacy.

第一步是编译并提交缺陷报告。 此时，项目经理或技术负责人将决定是否将其分配给开发人员，还是以供不应求或不充分为由予以拒绝 。

After the assigned developer has fixed the bug, you as a QA have to double-check and verify it has been fixed. If yes, you can close the defect report. The best practice is to close it in a week or two.

在指定的开发人员修复了该错误之后，您作为质量检查人员必须仔细检查并确认它已修复。 如果是，则可以关闭缺陷报告。 最佳做法是在一两个星期内将其关闭。

If the bug is not fixed, you reopen the defect report and send it back to the assigned developer. The bug-fixing process can be a long one, but you have to stay strong until all the defect reports are finally closed.

如果错误未修复，请重新打开缺陷报告，然后将其发送回指定的开发人员。 错误修复过程可能很漫长，但是您必须保持强大，直到最终关闭所有缺陷报告为止。

总结 (To Wrap Up)

Quality Assurance is a process you simply cannot avoid. Each airplane prior to departure undergoes a technical check. If there is any issue, the aircraft is grounded until the problem is solved.

质量保证是您无法避免的过程。 每架飞机在起飞前都要经过技术检查。 如果有任何问题，则将飞机停飞直至问题解决。

Similarly, each software product needs to be checked before launch. You cannot afford to deploy buggy software because users will not give your app a second chance.

同样，每个软件产品都需要在启动之前进行检查。 您无力部署错误的软件，因为用户不会给您的应用第二次机会。

您需要提高软件质量吗？ (Do you need to improve the quality of your software?)

My company KeenEthics provides solid development and quality assurance services. In case you need an estimate for a similar project, feel free to get in touch.

我公司KeenEthics提供扎实的开发和质量保证服务 。 如果您需要对类似项目的估算，请随时与我们联系 。

If you have enjoyed the article, you should continue with What Is Prototyping and Why Do We Need It and Minimum Viable Product: Between an Idea and the Product.

如果您喜欢这篇文章，则应该继续阅读“ 什么是原型”以及“为什么我们需要它和最低可行产品：介于想法和产品之间” 。

聚苯乙烯 (P.S.)

The original article posted on KeenEthics blog can be found here: How to Write QA Documentation That Will Work?

可在以下位置找到发布在KeenEthics博客上的原始文章： 如何编写有效的质量检查文档？

翻译自: https://www.freecodecamp.org/news/how-to-write-qa-documentation-that-will-work/

软件测试质量过程检测文档