#1 楼
我倾向于从一开始就参与Test。在构建某些东西时，如果您不支持从一开始就对其进行测试的方法，则最终不得不将其撕碎并在以后添加。这伤害了公司。让我们讨论“测试”。
作为开发人员，我认为测试是必不可少的反馈，许多测试很重要，并且测试部门是防止错误，错误假设，错误传达等结果的基本盟友。它向客户开放。
我认为某些领域是开发人员的责任，而某些领域最好由具有不同思维模式和技能的独立人士来完成。
开发人员的责任和工具：在编辑/编译/调试循环内
永远不要告诉我开发人员不应该（或不应该）进行测试：
使用语法突出显示的编辑器时：它检查源代码并提供即时反馈以告诉我是否例如我的语法是正确的。这不是“测试”吗？
编译和链接时：编译器和链接器对代码进行高度复杂和详细的处理，除二进制文件外，还返回通过/警告/错误结果。这不是“测试”吗？
我使用TDD /单元测试，本质上是编译器代码检查的自定义扩展。我宁愿编写第二组程序（单元测试），以帮助自动化测试和调试，而不是反复手动地手动完成代码以手动调试。与重复进行手动测试相比，TDD还可以提高生产率，并更好地利用我的时间。它记住了六个月没有接触代码（或原始开发人员已经搬进去）后如何测试某些东西。
其他人最好做的事情： />系统测试
手动探索性测试
可用性测试。
问题是：我确切地知道系统应该如何工作，并且倾向于礼貌地只提供预期的输入。我可能不会敲打键盘，跳过配置设置，输入命令太快，输入外来字符，输入257个字符的名称，单击并将大文档拖到输入字段...
我构建了东西，我的时间有限。我需要别人帮助，以意想不到的方式打破它们。
#2 楼
取决于组织，新项目开发何时开始？
取决于公司，行业，开发方法等
两种常用的开发方法是Waterfall和Agile
在Waterfall中，一旦功能开发完成，就进行测试。
在Agile中，您进行*在开发之前和开发过程中进行测试。
在您的情况下，最佳的操作方法通常是与开发人员进行长时间的详细讨论，讨论哪些测试有意义，以涵盖单元，功能，用户接受和探索性测试。
*通过编写失败的测试来完成功能真正通过后，测试就会通过。
#3 楼
测试人员在项目的每个阶段（瀑布式，迭代式或敏捷状态式）均起作用：项目计划-确保适当考虑采购和设置测试体系结构，以及用于测试和解决测试期间发现的故障。
需求收集/设置-测试人员可以帮助确保准确描述和记录需求（例如“当您说您需要多个X时，我们可以量化一下这些吗？ ？“）
开发-确保存在用于单元测试，集成测试等的框架/最佳实践
测试-无需注释
部署-查找由部署或部署期间引起的故障
部署后支持-调查活动中的故障，确保正确记录并理解它们，以便可以测试任何修补程序以确保它们起作用（哦，以及对这些修补程序的测试）
项目后审查-寻找可以汲取的教训对于下一个项目-特别是关于impro检验测试元素和测试人员的参与。
#4 楼
您首先应该问自己什么是“测试”。如果您指的是对实现的手动/自动测试，那么它就无法在开发或部分开发完成之前就开始。在进行分析/制定规格时，质量保证应该已经存在，并且应该在以后的每个阶段都发挥积极作用（例如，验证体系结构，确保编写单元测试并正确运行）。 >质量保证人员应确保规范包含客户/用户要求的所有功能，并且规范中没有盲点（例如，隐藏的句子将使开发成本增加三倍）。在任何开发项目中，最大的问题之一就是开发完成时，您意识到所实现的实际上不是客户/用户想要和付钱的东西。在一个具有持续发布和用户验证的敏捷项目中，可以快速发现它，但代价仍然很高。在瀑布项目中，这可能会使您破产。
评论
您能否提供在开发开始之前无法开始自动测试的引用？
–corsiKa♦
17年11月22日在16:11
@corsiKa引文？当没有什么要测试时，您无法进行测试。
–苏丹
17年11月22日在16:14
整个过程都说您的自动化测试应该在开发开始之前完成，否则开发人员会浪费时间编写无关紧要的代码。尽管周期是有目的的，所以在进行过多开发之前您不必编写过多的测试，但是在开始开发所述代码之前，仍然应该对第一段代码进行测试。 en.wikipedia.org/wiki/Test-driven_development
–corsiKa♦
17年11月22日在16:25
@corsiKa是的，但是它是测试还是开发？通常，TDD与单元测试有关，单元测试被认为是开发的一部分，而不是测试的一部分。我从未听说过TDD，其中的测试人员就是编写测试的人员。但是，的确，开发人员和测试人员之间的差异有时并不十分严格。您必须首先定义“测试”一词才能获得有意义的答案。
–苏丹
17-11-22在16:33
我肯定同意你的最后声明。但是，您还会看到更多的情况，传统角色混合在一起，甚至大型组织也组成了小团队，所有参与者都戴着帽子，谁是测试员，谁是开发人员没有区别。这仅取决于他们的行为。
–corsiKa♦
17年11月22日在16:39
#5 楼
当组织中的新项目开始时，测试角色何时出现？这绝对取决于。如果你问我，常常为时已晚。在我的世界中，理想的时机正好在项目开始时。越早越好。可能不会花很多时间过早，但它们可能非常有价值。测试角色可以帮助使需求成为可测试的。该角色还将允许及时准备测试环境。经验丰富的测试负责人也许能够预测测试将花费的成本，例如，开发时间的10％和日历时间的10％。这将使项目向后工作以找到关键的里程碑。顺便说一句，至少在我的经验中，瀑布式开发和敏捷开发都是如此。空间探测器。
还有一些项目，甚至根本没有做任何测试。以我的经验，这不是一个好主意。
评论
测试将完成，好的。如果您的客户最终成为进行测试的客户，那么他们将不会对您感到满意...
–技术爱好者
17年11月22日在23:28
#6 楼
在项目引入期间，我希望每个专业团队的成员在场，还有一个具有软件质量和测试背景的人。因此，我对您的问题的回答是：在项目识别阶段的开始。如今，“测试优先”似乎已经成为一种普遍做法，因此您需要有能力教/指导测试的人无论如何，从项目开始就开始实践。
您需要多少手进行手动测试应取决于项目类型，但是对于大多数常见的业务项目，我会尝试从一开始，因为我认为不断地交付会极大地增加寻找最有价值功能的反馈周期。
测试不再意味着测试
困惑吗？我们可以想象！测试的目的过去很明确-“测试是出于发现错误的目的而执行程序的过程” [Meyers79]。这在采用敏捷和精益开发时会发生变化。
并行工程需要并行化工作。专门的跨职能团队鼓励单身专家扩大他们的专业知识。这些导致常规开发活动（例如测试）的目的发生了变化。
有关更多信息，请访问：https://less.works/less/technical-excellence/thinking-about- testing.html
评论
什么时候和什么时候应该是两个非常不同的问题。一个人询问当前的行业状况，另一个人询问如何确定最佳时机。这不是sqa.stackexchange.com/questions/5041/…的副本吗？