确保软件开发无错误的 5 个技巧

已发表: 2017-10-24

您的软件应用程序有错误吗? 当然会,因为所有可用的软件程序都存在问题,而没有错误的软件故事是一个神话。 但是,通过遵循一些书呆子但实用的缩减技术,仍然可以显着减少错误、错误和安全问题。

当涉及到错误跟踪时,涉及到很多纪律,因为它需要鼓励每个人都遵守规则。 尤其是在初创企业和创意驱动的行业中,很难阻止任何非正式的交流。 事实上,在许多情况下,人们并没有将“错误跟踪”列为项目中最关注的部分。

错误跟踪到底是什么?

What is bug-tracking really about?

根据 Technopedia 的说法:“错误跟踪是质量保证人员和程序员用来跟踪软件问题和解决方案的过程。

因此,错误跟踪系统管理有关报告错误的所有信息并跟踪每个错误的状态。 在跟踪问题时,您肯定会看到需要大量信息。 提供足够的数据不仅需要大量的时间,还需要软件开发领域的丰富技能。

错误分类

软件缺陷分为三类:

  • 规格不正确
  • 实施缺陷
  • 缺少规范

这些错误类型中的任何一个都可以轻松归类为关键问题(或重新归类为改进)。 前面提到的是 Xolv.io 的创始人 Sam Hatoum 使用的一些重新分类指南。

  • 不正确的规格是否会给我们带来损失? 例如,规范说明跟踪点击次数,何时应该跟踪支出重新分类错误。
  • 执行缺陷可以忽略吗? 例如,网络字体在应该嵌入软件时被安装。
  • 缺少的规范是否意味着新功能? 例如,用户无法在社交网络上分享和编辑他们的个人资料详情。

由于指示开发团队将错误优先于所有其他工作,因此产品经理需要对错误进行有效分类。 在删除所有错误之前,开发人员不会工作或其他任何事情。

形成团队质量标准

当设计和开发团队决定是否可以将应用程序病毒重新分类为改进时,该决策过程隐含地说明了团队的质量标准。 例如,强调高质量视觉效果的品牌所有者可能对设计差异的容忍度较低。 相反,他们会将这些问题重新归类为错误。

一致的重新分类系统使您能够不断调整期望与现实,同时保持将您的团队质量标准放在首位的结构化交付方法。

错误失败

最近的研究声称,几乎 40% 的系统故障是由软件错误引起的,而其他安全问题和程序漏洞占 60%,由常见的内存和并发相关问题引起。 减少应用程序中的软件错误是提高软件安全性、稳定性和可靠性的最佳方式。

确保无错误软件开发的提示

在日志工具 SmartInspect 的开发过程中,开发人员使用了许多方法来保持系统的高质量。 前面提到的列表包含他们使用的一些技术。

1. 创造交流空间

Creating room for communication

检测和报告错误需要识别相关信息的技能,然后将这些信息添加到每个问题报告中。 有许多错误跟踪和质量保证工具,例如 Usersnap,它们提供了自动附加所需信息的能力。 然而,总会有遗漏或误解信息的空间,因此需要进行适当的沟通。

在某些测试场景中,开发人员和测试人员之间没有这种披露的余地。 像这样的问题:“我怎样才能联系到负责的专家?” 或“可以通过电话或电子邮件征求反馈意见吗?” 需要在错误跟踪过程开始时回答。

为了避免代表测试人员和开发人员的误解,请尝试让每个人都在同一页面上,并创建一种以反馈为导向的文化,让双方的工作以同样的方式得到尊重。

2.保持一对一

避免在项目会议上讨论错误。 现在不要误会我的意思。 作为一个团队工作,重现和修复错误并没有什么不好。 但不要在与整个内阁的长时间会议中讨论问题。 根据 Usersnap.com 的技术博主 Thomas Peham 的说法,报告错误然后在下一个开发“重新测试”阶段讨论它们是一种相当缓慢的方法。

确实,保持一对一的效率更高。 正如 Yegor 在他关于 bug 跟踪 5 条原则的文章中所写,每个 bug 报告都与两个人相关联——说明者和问题解决者。 无论有多少人参与该过程,解决报告的问题只有两个主要职责(具有两个不同的角色)。

3. 确保团队的支持

如果您的整个团队都不使用它,那么一个好的错误跟踪数据库将是无效的。 最好先让所有利益相关者(客户服务、质量保证、项目经理和开发人员)评估工具并尝试共同做出决定; 使用同一系统以一致的方式记录和解决缺陷。

如果您正在努力让人们加入,这就是您可以做的;

对于开发人员,制定通过个人数据库而不是任何其他方法接受错误报告的法律。 当测试人员向您发送带有反馈的电子邮件时,只需要求他们将报告扔到信息系统中即可。 除了确保事情保持井井有条之外,这还通过提供所有必要的信息和定义必要的字段来帮助报告。

创建更有效流程的另一种方法是进行 QA,或支持验证来自客户的错误,并在开发人员收到通知之前将确切的步骤添加到数据库中。 有效地跟踪您的软件问题是拥有可靠且一致的项目管理框架的最重要方面之一。

  • 一个好的调试器

Visual Studio

如果您使用像 Visual Studio 或 Delphi 这样的系统,您已经可以访问一个非常强大的调试器,您应该使用它。 在脚本环境中,开发人员经常尝试通过反复试验来消除错误,该过程不仅成为识别和解决问题的繁琐方式,而且如果您不完全理解您的代码并且无法用调试器逐步完成它。 帮自己一个忙,为您的团队提供一个好的调试平台——几乎所有东西都有调试器。

4. 知道“关闭”的错误是什么意思

您是否参与过关于关闭错误的讨论? 好吧,恭喜,您已经处于可能发生的最糟糕的错误跟踪情况中。

如果您发现自己正在讨论“错误状态”,请考虑退后一步,问自己以下问题:

  • 接受结果是谁的责任?
  • 验收标准是什么?
  • 谁负责下达命令?

看看“关闭”的含义。 在大多数开发团队中,修复错误的人会关闭错误。 Peham 建议关闭报告问题的人的错误报告。 一旦开发者提出某个 bug 的解决方案,应该要求报告者关闭报告。 这将确保反馈是解决软件混乱的充分解决方案。

5. 虚拟机

为了尽可能在许多不同的操作系统和环境上测试您的软件是否存在错误,您应该使用带有 Virtual PC 或其他可用虚拟化软件等工具的虚拟机。 您可以通过这种方法节省大量时间,因为您可以轻松复制、共享和重置虚拟机,从而允许您在各种配置上测试您的软件。

最好为您定期测试的所有操作系统创建各种标准映像并将它们放在文件服务器上。 当您需要高度特定的配置来测试某些东西时,您可以从其中一个基本映像开始,而无需安装操作系统、所需的软件和驱动程序等。

这不是一个新概念

当 Hatoum 提出这个概念时,他发现零缺陷软件的想法并不是一个新概念。 事实上,它自 1960 年代就已经存在,就像许多被遗忘的老派哲学一样。

传奇的质量专家菲利普克罗斯比在马丁公司或现在称为“洛克希德马丁公司”工作时发明了“零缺陷”一词,据报道,他们“在政府审计下实现了 54% 的硬件缺陷缺陷减少”。

最初,零缺陷技术在 60 年代用于航空航天制造,然后在 1990 年代应用于汽车制造。 制造业和软件交付之间有许多相似之处。

例如,流行的敏捷管理模式看板起源于丰田生产系统。 这基本上告诉我们的是,我们可以轻松地研究这些制造过程,以获得软件或应用程序开发中的技术灵感,而零缺陷就是其中的灵感之一。

然而,达到标准的极高成本是对零缺陷方法的主要批评之一。 如果实施不正确,这确实是真的。 在零缺陷方法中,Hatoum 直接通过将缺陷重新分类为功能和重大改进来处理这个问题,从而通过团队的质量标准来控制成本。

从今天开始

作为技术用户和开发人员,您可以使用上述系统开始检查所有现有故障并对其进行分类。 如果您认为自己有数十万个问题,那么这可能是积压它们并重新开始的好时机。 不用担心,您可以随时根据需要将错误从存档移动到当前域。

开发团队不一定要等到整个分类工作完成后才开始消除错误; 一旦分类了一些错误,他们就可以开始使用。 在所有项目都“消除错误”或重新分类之前,团队不得开始处理积压工作中的任何其他项目。 正是这条规则迫使产品经理正确地确定新工作的优先级。

总结一下

项目中报告的每个错误都需要额外的时间来修复。 因此,错误跟踪需要跟踪错误的人员具有出色的沟通技巧,以及修复错误的人员的敏感性。 通过上述跟踪黑客,您的团队可以在报告任何类型的技术或安全障碍时尝试提高工作效率。