我知道一些没有测试人员会失去的东西的例子：她输入了密码。因此，无论是在编码还是在测试时，她都可能会忽略相同的错误。这使得很难发现缺陷。
程序员必须在编程（他渴望做的）和测试（吸引力较小）之间分配时间。程序员很容易将测试称为“完成”，因此他可以继续进行下一个有趣的编程任务。在专门的测试人员中不存在这种冲突。
测试人员具有在职业生涯中磨练的测试技能。我缺少很多这些技能。
我们如何填补这些空白？我们如何仍然可以与现有人员一起生产高质量的软件？
#1 楼
您的第一个项目符号假设您在编写测试之前已经编写了代码。这是一个普遍的假设，但请注意，您可以选择是否正确。如果改变了假设，如果在编写代码之前先编写测试，就可以戴上“测试帽”，而不必（完全）不受编写代码的偏见。您可以这样做在两个方面：整个功能的规模较大，而您编写的每种方法和类的规模较小。
在整个功能的规模上，验收测试驱动开发（ATDD）帮助。当您采用一项新功能时，在编写任何代码之前，要做的第一件事就是编写实际使用该功能的示例。如果每个动作都写清楚，并且示例集相当全面，那么它们可以作为您开发的指南。您可以使它们自动化。通过下一个自动化测试可以很好地了解进度。如果过去通过的测试不及格，则可以快速表明您损坏了某些东西。快速的反馈意味着您花更少的时间弄清楚如何破解它。您编写了一个小小的测试。然后，编写代码以通过该测试。然后您清理。然后，您再编写一个小测试。然后，代码通过该测试以及所有现有测试。然后您清理。重复进行，直到通过所有自动化测试为止。
#2 楼
您可能要做的最大的事情就是让别人来测试您的代码。如果您无法进行测试驱动或测试优先的开发，那么请给另一个程序员您的代码，接口，并让他们编写单元测试。然后再找其他人测试集成软件。这里的部分问题是古老的测试之一，它被认为比编程的“有价值”要小。它们是相互依存的：经过良好测试和测试的程序员可以摆脱没有测试人员的困扰，但是如果没有测试，他们就无法摆脱困境（或者如果他们尝试了，他们最终就要付出代价）。另一面是技能集的必然差异。程序员善于寻找使事情正常进行的方法。测试人员善于发现程序员在使其工作时并未想到的事情。真正优秀的测试人员这样做的方式不会使程序员感到不满意。
您还可以做一些其他事情：
公开测试版：当您认为它已经准备就绪时，让愿意冒险的用户可以使用该软件。如果您在软件中添加一些额外的日志记录，这也将使您更清楚地了解该软件的使用方式。
像UTest这样的众包测试（显然并非对所有人和所有人都可行，像Dale建议的那样，从喜欢测试的人员那里获得新的视角。）
按照Dale的建议构建测试。
使尽可能多的测试自动化-如果您的团队正在编写测试代码的代码（需要注意的是，没有人可以测试他们编写的代码），比起尝试进行他们不熟悉的手动探索性测试，他们更有可能享受测试方面的乐趣。需要注意的是要弄清楚应该自动执行的操作：我建议从钢螺纹上绘制一个清单，然后扩展到可能的错误情况，以及人们过去曾经咬过的东西。希望有帮助。
#3 楼
对于具有GUI的应用程序，请进行内部用户测试。引入一些“业务用户”（您选择的无辜虚拟用户，而不是付费客户的真实代表），向他们展示该应用程序，然后他们将在第一个演示中几乎立即发现重大错误。 （我想知道这种现象是否有特殊的名称或行话。）
最好带一些您选择的虚假用户，然后再去向客户展示演示，最后尴尬。
我知道这不能代替自动化测试，但这始终是一个很好的现实检查。
#4 楼
我认为没有万能的灵丹妙药可以克服测试人员的不足。您需要遵循与拥有测试员时相同的过程，只是在测试周期中，部分或全部人将需要停止编写代码。你们中有些人会比其他人更好地进行测试。您获得成功的程度将取决于您集体愿意花时间去做一些您不喜欢做的事情的事情。 。我们需要更多的测试人员，因此一个测试人员编写了一个高级测试计划，并将其分配给开发人员。结果并不好，但比将整个工作交给一个人要好。随着资金的到来，我们最终为测试团队配备了人员。#5 楼
不久前，我根据一些敏捷团队的经验写了一些关于该主题的博客，他们在寻找合适的测试人员时遇到了问题，最终让开发人员执行测试任务。第一篇文章是为什么开发人员不能成为优秀的测试人员？并讨论了您上面列出的大多数要点（此处没有消息），第二个被称为“教学程序员”进行测试，它涵盖了我们为使该团队加快测试速度所做的一些事情。
我基本上认为，如果大多数程序员仅以专业的方式进行此操作，他们就可以进行下降测试，问题是他们中的大多数对如何做到这一点一无所知，最终在他们想到的情况下运行了一些方案简而言之，您首先需要了解开发人员在测试（a）代码时的局限性，这很像新测试人员在没有任何培训或指导的情况下所做的。 ，以及（b）任何代码。如果这样做，那么至少您不会盲目地从事这项工作。
然后确保您的开发人员对测试过程有更多了解-他们每个人可以测试什么，如何计划测试，预先定义一些方案（使用任何类型的头脑风暴/头脑） -mapping会话等）。
在测试过程中，请确保您的开发人员专注于他们的任务，而不仅仅是按“完成”。定义测试会话以及如何确定何时“感觉”到他们没有其他要测试的时间，等等。
最后，我认为这主要是关于心态和专业地进行测试。如果您想进行认真的测试，则可以在代码中找到问题，但是，如果您将测试视为负担和时间的浪费，那么您将尝试完成“肮脏的任务”，并且一定会甚至会错过产品中一些最琐碎的问题。
无论如何，祝您好运！
#6 楼
请遵循以下过程：设计检查
TDD
代码检查
基本迭代可能如下所示：
阅读要求，
编写设计（从大屁股文档到类和方法列表的所有内容），
查看您的设计，
让某人检查您的设计，
编写单元测试，
审查单元测试，
让某人检查您的单元测试，
编写代码，
审查代码，
使某人检查您的单元测试代码。例如，PSP / TSP坚持将“写”步骤和“审阅”步骤之间的分隔严格，这意味着您：
写设计/测试/代码，
停下来声称已完成，
然后散步/淋浴/午睡/午餐，自己返回并查看，
修复发现的问题，
将结果提供给其他开发人员进行检查。
花点时间进行检查和检查非常重要，例如每页30分钟以上，具体取决于内容ts的复杂性。
不要忘记在项目进度表中预留时间进行审查/检查（PSP / TSP建议将其保留为〜50％）。
评论
@joelmonte，测试人员更便宜，并且在某些时候，您将开始教会开发人员如何做（黑盒）兼职测试，而不是雇用一些专职的质量工程师来开始亏本。
– Misha Akovantsev
2012年1月23日在1:17
#7 楼
我基本上只是在增强之前所说的内容（例如Dale和knb的建议）：首先进行测试-将自动检查内置到软件中，以帮助确保您开发出东西正确
同伴们互相检查代码/配对程序
经常进行代码回顾，以确保所有程序员都在同一页面上参与？要么将它们带入UAT环境中，要么将其发布到生产中，但数量有限。的用户可以访问（例如AB测试）？
评论
相关：sqa.stackexchange.com/questions/695/…如果您没有专职的测试人员，是否可以在短期内引入探索性测试人员？
我认为，即使是糟糕的测试也比没有测试要好。让某些开发人员至少试用一下应用程序。