Questions tagged «qa»

我知道这听起来很像已经提出的其他问题，但实际上略有不同。似乎通常认为程序员并不擅长于测试应用程序。例如： Joel谈软件- 没有测试人员的前五（错误）原因（强调我的意思） 甚至不要想告诉大学CS毕业生他们可以为您工作，但是“每个人都必须在QA工作一段时间，然后再进行编码”。我已经看到了很多。程序员不能成为优秀的测试人员，并且您将失去一个优秀的程序员，而后者很难被替换。 在这个问题中，最受欢迎的答案之一是（再次强调）： 开发人员可以成为测试人员，但他们不应该成为测试人员。开发人员倾向于无意/无意识地避免以可能破坏应用程序的方式使用该应用程序。那是因为他们编写了它，并且主要以应使用的方式对其进行了测试。 所以问题是程序员不好测试吗？有哪些证据或论点支持这一结论？程序员是否只擅长测试自己的代码？有没有证据表明程序员实际上擅长测试？ 我所说的“测试”是什么意思？我并不是说单元测试或任何被软件团队用来编写软件的方法论的一部分。我的意思是在构建代码并将其部署到软件团队称为“测试环境”的任何位置之后使用的某种质量保证方法。

36 testing  qa 

在我的工作中，所有解决错误的开发人员都必须添加一个新的单元测试，以警告此类错误（如果再次出现这种情况）。如果无法进行单元测试（例如，网页设计问题），则质量检查部门必须创建一个测试用例以手动检查它。 其背后的想法是，如果在产品发布之前未检测到缺陷，是因为没有适当的单元测试来检测它。因此，开发人员必须添加它。 问题是：这在任何软件开发方法中都常见吗？这个技术有名字吗？我想了解更多有关它的信息，但是我需要一些信息来开始它。

35 unit-testing  issue-tracking  qa 

我是正在研究BE（CS）的学生，我的问题如下： 是否需要在软件领域进行测试？ 如果我们非常谨慎地创建软件，那么为什么要进行测试？ 经过测试，我们是否可以确定已经实现了该目标（产品/软件按预期工作），因为我们已经对其进行了测试？可能吗？ 我的问题：是否需要测试软件？

33 testing  quality  validation  qa  verification 

我公司中的某人最近提出了对核心产品的更改，经理们认为这些更改应触发我认为我公司认为完整的质量检查周期（即，从头开始测试整个产品套件）。显然，我们的质量检查需要12周才能完成产品的完整质量检查周期。我的问题是我们正在尝试进行敏捷开发（尽管在我看来，这大多是半估的）。我们将完成一整套冲刺，然后发布，我想质量检查将永远花费那一次。问题是，如果我们的质量检查要花12周才能完成工作，我们是否就应该放弃尝试敏捷开发？在这种情况下尝试敏捷的意义何在？

24 agile  qa 

我们是一个庞大的团队（10-12个开发人员和4个质量保证团队），他们使用同一个git存储库处理多个项目。它是一个基于Spring Boot的后端Web服务。我们正在寻找一个好的git分支和部署策略。我们还有一个质量保证团队，可以确保我们的功能能够按预期运行（一定程度上没有错误）。 看了几篇文章后，我感到Gitflow模型对我们来说很好用。我的问题来了。 我们的质量检查团队应该在哪里测试我们的功能？ 如果他们在功能分支上进行测试，他们将在这里提出错误，开发人员将对其进行修复，一旦通过质量检查，我们将合并以进行开发。然后质量检查人员将再次在开发分支中进行整数测试。 我们是否应该合并所有功能（在经过单元测试和开发人员的基本测试之后）以开发分支，然后从那里进行质量检查。修复和测试也将在开发中进行。 我很想知道哪种方法对其他人有效。

23 testing  git  branching  qa  gitflow 

如果直到冲刺结束才完成全部或大部分编码，如何在与编码相同的冲刺中处理测试？（我指的是冲刺中单个PBI的“汤对坚果”开发和测试。） 我在网上看到的大多数答案都涉及QA自动化，但这实际上是不可能的，因为您通常需要功能性UI来记录或创建自动化测试。我只有故事板随着我开发功能和发现新需求而不断发展。 就我而言，我正在开发一个新的桌面应用程序。桌面应用程序通常无法很好地进行自动化测试。我有一些自动化的单元测试，但它们不是QA专业人员执行的手动功能/集成测试。 因此，我现在的状态是明天的sprint结束，我仍然需要完成编码，而且我的质量检查人员还没有要测试的东西，也不知道如何测试如果不握住我的手给我的东西。 我确定我不是第一个遇到这种困境的人。 过去，我做过一个管道：在当前的sprint中，测试团队测试在上一个sprint中已实现的功能。在我目前的工作中，PM将这种方法称为“瀑布”，因此是不可接受的。

22 agile  testing  unit-testing  scrum  qa 

在我目前的职位上，质量检查已成为瓶颈。不幸的是，当前版本中没有保留功能，因此QA可以完成测试。这意味着开发人员继续进行开发后，可能需要2-3周才能对已完成开发的功能进行测试。随着开发人员加快质量检查的进度，这个时间差距只会越来越大。 我一直翻阅我的Code Complete副本，寻找“ Hard Data”片段，该片段表明修复缺陷的时间越长，其成倍增长。有人能指出我一些支持该概念的研究吗？我试图说服质量保证瓶颈比他们想象的要昂贵得多。

18 development-process  qa 

在创建工单时间估算时，应在工单估算中包括测试人员（QA）花费的时间吗？以前，我们一直在估计没有测试人员的时间，但是我们正在谈论总是将其包括在内。对于我们当前的sprint（发布前的最后一个）而言，这很有意义，因为我们需要知道一星期后的总时间。 我一直都知道估算只是为了开发人员时间，因为这往往是团队中的限制资源。一位同事说，无论在测试人员时间之前在哪里工作，也都包括在内。 需要明确的是，这是针对开发人员编写覆盖面广的单元测试，集成测试和UI测试的过程。

17 agile  scrum  estimation  qa 

在我的公司中，我们成功地采用了敏捷实践，但没有使用迭代。主要原因是我们找不到在迭代周期中适合QA的干净方法。 我们认为质量检查是对特定版本（候选版本）进行额外验证的一部分，然后再将其部署到客户。关键是要避免单个恶意提交会损坏整个发行版。由于您永远都不知道它是哪一个，因此质量检查人员必须等到该版本的所有功能/提交都在构建中。（不允许使用著名的最后一句话“这只是微小的变化”。） 如果质量检查人员在候选发行版中发现错误，则开发人员会在相应的发行分支中修复这些错误（并将其合并到主干中）。修复所有错误后，将部署新版本以进行质量检查以进行重新测试。仅当在某个发行候选版本中未发现错误时，才将其提供给客户进行验证。 每次发布通常需要大约2-3个候选人，大约一周。编写修补程序的时间通常比测试工作要少得多。因此，为了让开发人员忙，他们在版本N + 1上工作，而质量检查则在N上工作。 不使用迭代，这没问题，因为我们可以将版本N和N + 1的工作重叠。但是，据我了解，这与Scrum或XP等基于迭代的方法不兼容。他们要求在迭代结束时发布一个迭代，并将所有测试工作都包含在迭代中。 我发现这必然导致以下不良结果之一： （A）开发人员在迭代结束时处于闲置状态，因为质量检查需要时间来验证发布候选版本，并且错误修复工作并未完全使开发人员处于忙碌状态。 （B）质量保证在准备好第一个候选版本之前就已经开始工作。这是Stack Exchange上最推荐的方法。但这不是我公司所理解的质量检查，因为没有经过测试的特定候选发布版本。破坏一切的“微小变化”仍然可以被忽略。 （C）错误将继续进行下一次迭代。在Stack Exchange上也建议这样做。我认为这根本不是解决方案。从根本上讲，这意味着我们永远不会获得经过验证的内部版本，因​​为只要进行了错误修复，就会将未经验证的新提交也添加到同一分支中。 有没有办法摆脱这种困境？

17 agile  teamwork  qa  sdlc 

我们都看到了无数带有“最低系统要求”的软件示例，如下所示： Windows XP / Vista / 7 1GB内存 200 MB储存空间 一般如何确定这些？显然，有时会有特定的限制（如果程序在磁盘上占用200 MB，则这是一个硬要求）。除了那些情况之外，对于RAM或处理器之类的东西很多次都发现，没有硬性约束的情况下，更多/更快更好。如何确定这些？开发人员只是编造看起来合理的数字吗？质量检查人员是否经过严格的流程测试，以测试各种要求，直到找到性能可接受的最低设置？我的直觉说应该是后者，但实际上通常是前者。

17 documentation  requirements  qa 

按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 索尼最近遭到SQL注入攻击，其用户的密码以纯文本格式存储。这些是菜鸟的错误。在这么大的公司中，这如何通过质量检查？他们怎么没有更好的团队呢？ 被黑客入侵的公司的绝对规模使情况有所不同。它影响到我们所有人，因为我们都有一天可能会发现自己在一支负责此类事情的团队中，然后我们得到了斧头。那么，导致这种情况的因素是什么，我们如何防止它们呢？

15 security  qa  mistakes 

更新/说明我的客户了解他们进行内部测试的必要性，并且他/他们总是发誓他们会“做得更好”（即做某事），但那没有发生。他们没有外部测试的预算。我想我正在（模糊地，我​​承认）问什么可以灌输“尽早测试，经常测试，对目标机器的精神进行测试？ 问题：如何鼓励用户花时间明确测试和报告新版本的问题，而不是在生产项目中“按需测试”。 背景：我有一个小客户，为此我编写了一套多媒体演示工具。他们是一个很好的客户，我们有着良好的关系。该项目正在进行中，并随着我们的进行添加了功能。 我有两个问题： 功能定义通常是通过电话即时进行的，可能会进行更改，修订和撤销。（有点像肯尼迪的“我们将登月并做其他事情” –我一直对其中的“其他事情”感到很开心） 实际上，最终没有进行质量检查测试。 我可以或多或少地处理＃1。这个客户甚至不会在会议前阅读规范，更不用说撰写规范了。我习惯了。这是我遇到的问题的项目2：他们不测试或不会测试新版本。他们所做的是将其用于生产，因此，当出现错误时，他们要么找到解决方法而不报告，要么急着着手进行该项目，从而使错误报告模糊不清。 关于这一切，我们进行了很多讨论，但是我只能稍微推翻一下（例如，我们使用github进行问题跟踪-尽管我大多使用它）。根本原因有两个：它们是一家小型咨询公司，没有（或认为没有）测试资源（也没有预算将其外包）。和文化的：尽管他们认为自己是“开发人员”，但实际上他们只是多媒体软件包的用户。（例如，他们对“真实”开发人员的细节没有强迫症）。 如您所料，这会影响到我：没有反馈，我无法告诉您功能是否完整（请参阅＃1），或者是否还有其他后果。这也让我有点懒。

14 client-relations  qa 

如果使用BDD进行项目并通过自动验收测试覆盖100％的用户案例，那么测试人员/质量保证人员的角色是什么？ 我想我正在想象开发人员将与产品负责人一起编写验收测试，让我知道这似乎是一个愚蠢的假设。

13 testing  team  qa  bdd  acceptance-testing 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我相信是。为什么？ 我遇到了许多软件工程师，他们认为它们在某种程度上优于QA工程师。我认为，如果他们在一段时间内担任质量检查工程师的工作，并且意识到这是一种独特而有价值的技能，可能会有助于打破这种信念。 软件工程师测试自己的程序的能力越强，在整个软件开发生命周期中进行代码时所花费的时间成本就越少。 软件工程师花更多的时间思考程序如何崩溃，他们在开发它们时会更多地考虑这些情况，从而减少最终产品中的错误。 软件工程师对“完整”的定义总是很有趣的……如果他们花时间担任质量检查工程师，那么这个定义可能会与软件设计者更加接近。 请注意，我在上面的建议中只考虑了很小的时间范围，因为我知道有人在某个职位上工作而不是被雇用，这绝对是失去该开发人员的秘诀。 你们怎么想

12 code-quality  skills  qa 

我即将参加与管理层的讨论，以衡量我们作为质量保证组织的测试效率。这背后的主要原因是我们的团队有一半被外包出去了，我们的业务想提供一些关于我们效率/效率的指标，以便我们有基础数据可用来与承包商的服务协议进行合同参数谈判。 我已经提出了一些建议，并且我在该主题上发现的大多数意见都围绕着开发人员的效率：代码行，交付的故事点，引入的缺陷等。 但是测试人员呢？我们的测试主要是基于需求的，并且混合了手动，半自动和自动测试（不是因为我们还没有自动完成所有工作，而是因为某些事情在我们的测试系统中无法实现自动化）。

11 testing  efficiency  qa  metrics