我不想等到团队认为他们知道测试所需的东西；相反，我想了解开发人员的想法，计划的功能和技术堆栈等，因此我可以开始在测试方面进行相同的可行性工作，并预见在开发过程中遇到的问题。我有机会超越他们。
我想，如果我已经以这个职位完成了几个项目，那么我会更容易地表达我的疑虑-而作为开发人员，我做到了有一些想法-但由于这是我担任从未有过的角色的第一个牛仔竞技表演，因此我很难提出自己的理由。
我实际上不太担心一旦获得真正的开发者的支持“加入”一个项目，我可能会从吸引开发人员和提出问题中学到很多东西，但是，当他们觉得为时过早时，我该如何说服项目经理相信现在加入我的公司会增加价值呢？
注意：我应该澄清“早期可行性阶段”的含义：我们小组编写的是与硬件交互的软件，而不是纯软件的产品，因此，当一个项目开始时，在编写生产代码以原型化产品之前需要做很多工作。并确定我们计划的方法是否可行。例如，我们可以使用计算机视觉在导致用户崩溃和弯曲金属之前检测出用户错误吗？如果我们对底层控制体系结构做出这样的假设，那么当我们集成其他硬件部件时，这些假设会被打破吗？
我相信关于如何测试产品，有类似的问题需要回答，这是重点这个问题。
#1 楼
我在发表评论或回答之间感到困惑，因为这里的答案已经给出了非常好的建议，但是我认为它足够长且足够有用，可以作为答案。请仅将其视为其他答案的附录。诀窍是您不能出售“测试”。为什么？因为客户不需要它。
再读一遍。这是一个邪恶且非常真实的短语。为什么如此真实？因为客户已经对什么是“测试”有了先入之见。他们可能是正确的。他们可能是错的，但他们有自己的见解，而这种见解就是他们不需要这些。他们告诉了你很多。而且，如果他们像我惯用的任何程序管理器一样，他们真的没有时间重新学习像“测试”这样的gerund意味着什么。这些人可能会被管理程序的现实所淹没。
您需要做的是找到他们确实需要和想要的东西。卖给他们，但是以一种让您有空间出售您认为是“测试”的东西的方式出售，这些东西可能已经或可能没有被“测试”给他们。
“我们还没有准备好考虑进行测试”。
如果您所销售的产品未进行测试，则不应该出现这种情况。
“我们不想浪费您的时间[使用与测试没有严格关系的一般项目内容]”
现在，这很有趣。这意味着两件事之一。一种是他们了解业务中测试的目的，重视它，并且不想浪费时间。如果是这样，那就太好了！然后，您可以向他们解释为什么不浪费您的时间（因为测试的各个方面无处不在。无论他们做什么，您都可以通过这种方式来简化“测试阶段”中的工作，“对吗？）
另一种可能性是，他们还有其他原因不邀请您加入团队。也许他们有固定的资源配置水平，如果他们从测试工程中聘请某人，就会陷入困境。也许团队中有人无法与您合作。原因很多。如果您仔细地解释了为什么不浪费时间，那么您也许可以瞥见真正的问题是什么。该问题将无法测试。这将是另外一回事。
这是我第一次担任从未有过的角色的牛仔竞技表演，我在阐述自己的观点时遇到了麻烦。
这是不出售“测试”的另一个原因。如果这是您的第一个牛仔竞技表演，您真的不知道它是什么。我的意思是，请不要误解我，我确定您已经完成测试并参加了一些课程，但是您的措辞表明您理解，在有人完成10多个成功项目之后，他们的想法有很大的不同
解决方案是推销自己，而不是“测试”。通过您的措辞“最近转为测试角色的软件工程师”，这意味着您已有一些经验。您可能拥有成功的项目。以经验丰富的开发人员来推销自己，他们愿意做“较小”的任务，并了解您将以鼓励人们将来进行“测试”的方式来完成这些任务。这几乎就像一个亏损的领导者。
最后的考虑是查看将您转换为测试角色的管理层。确实，这是一个真正愚蠢的经理，他将员工转移到公司的新职位上，却没有看到它的价值主张。他们总是有一个计划和一个理由，无论是否陈述（或者他们自己都不知道）。如果您能找出为什么管理层认为现在是担任测试工程师角色的适当时机，那么您就可以弄清楚如何使自己能够从事企业中最重要的工作：老板看起来不错。如果您可以帮助您的上司推销他们关于测试工程角色应该是什么以及为什么它对公司有帮助的想法，那么您总会遇到一个人。 （或者至少您应该这样做。我描绘出乐观的景象，因为我认为在这种情况下乐观会有所帮助）
#2 楼
在这种情况下-不幸的是-您最好的选择是缓慢而痛苦的方法。我已将其用作通用测试仪以及用于测试自动化。我采用的方法是使用以下技术：
在可能的情况下查找用例/规范中的空白-每次测试人员发现开发人员开始编码后，在用例，规格或设计文档中出现漏洞或未考虑的情况是造成返工的原因。您会发现并询问更多的问题（我发现“ X时会发生什么？”是处理这些问题的好方法，尤其是当答案通常是“哦，我没有考虑”时）。当您对正在使用的软件更加熟悉时，执行此操作会变得更加容易，但这并不意味着您无法在与AUT亲密之前找到潜在的问题。
跟踪浪费的时间-任何时候您必须寻找一种替代方法来访问需要与之交互的字段，然后跟踪该时间。一段时间后，由于开发团队忽略为您要跟踪的字段提供唯一标识符而增加的时间数将很可能导致负ROI，并且您将遇到一个很难理解的数字论证（“不到一分钟的时间就指定了ID。我需要进行3个小时的测试，证明我正确地横穿了DOM以通过自动化访问该字段。我得到的报酬不亚于开发团队的薪水。这花了公司很多钱。” -更礼貌地
跟踪本可以避免的问题-这是第一点。如果您发现开发的早期阶段发生了什么，只要发现自己制造缺陷或报告了可以避免的问题，请记录下来。管理层更喜欢硬数据，尤其是直接与金钱相关的硬数据。当您发现所引发的问题或花费大量时间进行自动化改造的原因很大一部分是由于不在开发团队循环中引起的时，您就有一个很好的论据，因为这些问题和返工是时间（因此有金钱）公司不必花钱。
永远不要自鸣得意-绝对没有“我告诉过你”这样的注释-只会引起不满。您需要始终从一个希望软件达到最佳状态的人的角度进行工作。
跟踪进度-这并不是很明显：考虑到您不是只要可以访问要测试的软件（直到相当晚），您就会在后面运行。您需要跟踪落后情况（例如，如果团队的其他成员处于第4次迭代中，但是现在您只能进行第1次迭代的自动化工作，则需要跟踪自动化落后开发3个周期以及原因）。当您因循环延迟而无法自动执行的工作被客户发现时，这些信息可能会派上用场。
从传统思维的项目经理那里获得足够的信任就可能需要很长时间，他们将测试视为在项目结束时的努力，表明他们已经完成了尽职调查。上一次我必须这样做，花了一年的时间，项目经理才意识到，每次我开始测试一项新功能时，我都会遇到很多问题，这些问题会导致返工并延迟功能。当我开始参加设计和规格会议时，这种情况会有所改善，而当我们开始采用更敏捷的工作方式时，这种情况会有所改善。
评论
凯特，一如既往的好答案。我接受Cort的回答，因为我发现它对我的特定情况最有帮助，但如果可以的话，我会接受所有答案：)
–c32hedge
18年5月1日在2:48
#3 楼
要说服普通经理，您应该承担风险，因为风险是普通经理的职责。我将使用项目的“公共”数据或您可用的数据进行快速研究。然后，我将针对您在早期阶段（乐观的情况），中期阶段（现实的情况）和后期阶段（悲观的情况）入职的情况构建三个方案，以说明项目的绩效。
当您想迫使经理支持您时，在他们选择后两种选择的情况下，我将集中描述（并强调）不利方面（我还将研究以下方面的统计数据）类似的项目，将价值添加到我的估算中）。
#4 楼
OP，您的直觉完全正确。现在就来思考质量以及如何对其进行测试就为时过早。这种思维方式上的转变甚至有一个名称：“向左移动测试”（在项目流程图中向左移动测试）活动）。
您的开发人员（甚至经理）可能熟悉测试驱动的代码单元开发。好处之一是，它允许（甚至是强制）以更易于进行单元测试的方式设计代码单元，因为以不同于内部计算的方式将功能暴露给单元测试。 br />
整个系统的工作原理完全相同，整个系统的测试驱动开发将使您的团队以有利于端到端测试的方式构建系统。因为有人会从一开始就考虑如何测试该接口，所以应该在哪里记录哪些信息，以很好地了解正在发生的事情，并确保正在发生正确的事情。
如果您愿意被迫将测试作为对现有设计的事后思考，这将是：事后思考。
质量无法获得：必须付出代价。此后无法将其添加到系统中，必须从一开始就为系统构建质量。
解决不一致或遗漏的需求的最有效方法是在代码中实现它们。需要有人负责将需求映射到测试，有人在乎测试。这将迫使开发人员提供额外的API功能进行测试，并以有益于测试的方式设计API。
如果您有使用测试驱动的开发的开发人员，则它们（或应该）存在于您的侧面。
以我的经验，负责业务/面向客户功能的分析师很少考虑如何测试它们。相反，分析师依赖开发人员。但是，如果开发人员只对实现功能有来自分析师的压力，那么他们就不必担心对其进行测试（除了单元测试之外）。这正是SET创造价值的机会：思考在哪里，什么地方以及如何回归测试系统和接口的一部分。
评论
补编或不补编，这个答案似乎最“适合”我到目前为止任何情况的细微差别。我认为问题的很大一部分确实是他们被淹没了，所以他们觉得自己的团队没有时间来招募另一个人。我追求的一种策略是与将与该团队进行交互的另一团队接触。如果我可以加入该团队，则可以利用该团队已经付出的努力来加速该团队在计划的接口点上的工作，这也将对我有所帮助，而无需进行过多的其他工作。
–c32hedge
18年4月27日在19:36