我们有时需要处理一些潜在客户要求我们进行某些工作并想知道我们如何进行测试的要求。通常,我们听到的是一个高级声明(或一个特定的衬里),例如:


应用程序x正在从平台x移植到y,我们想知道您的测试策略。
我们正在着手开发移动应用程序,并想知道
如何为我们提供优质的服务。

我觉得这么多的信息不足以获取在接近战略或计划的任何地方。
我通常倾向于通过准备问题清单来与潜在客户进行对话,具体取决于我可以从周围的人(现阶段涉及到的人)和我自己的人那里收集到多少信息经验。我尝试了解这种工作的业务案例,技术堆栈,业务领域及其复杂性,测试目标以及其他一些内容。
这些问题的答案提出了更多的问题,并且这种情况持续了一段时间。而。

有什么更有效的方法来处理这种情况?过去,我们尝试以有限的成功尝试来准备一个通用策略,以便在这种情况下可以使用(解释我们的流程和工具,并使它们与任何业务案例无关),但是我真诚地认为,每个此类请求都有其自己的上下文并且答复需要牢记这一背景,而不是依赖一套准则(即使在组织内部,我们的战略,工具以及在一定程度上根据项目类型而有所不同的过程)。问题是,我们开始使用的信息非常有限,有时前景不愿等待信息交换周期。有任何想法/建议吗?

#1 楼

我建议您的潜在客户本身并不需要详细的“测试策略”,他们可能会要求的是贵公司的能力以及可能的扩展能力。例如,从手机到手机应用程序测试我想知道您是否能够在仿真器和设备上运行测试,是否可以在仿真器和设备上自动进行这些测试(性能,压力,电池测试),要测试的设备有哪些?您是否参与了不同的MO,您是否有一个法拉第笼,或者如何模拟低带宽/无带宽等?

当然,应用程序不同,产品所有者对质量也有自己的解释。但是,某些类型的应用程序(例如游戏,实用程序,文字处理器等)之间也存在一些共性。您可能会考虑在较高级别上解释您的能力,以测试应用程序的类型和使用的一般方法,然后跟进有关其应用程序的独特性,对质量的期望以及他们对业务投入的期望的特定问题。

评论


+1 @Bj非常喜欢您的答案,它确实接近我认为应该是正确的答案。尽管我们确实通过文档进行了解释,但并没有很好地解释通用方法。

–拉杰涅什(Rajneesh)
2011年7月21日在15:24



Doc可能会吸引潜在的客户,但是在开会时那些客户不想阅读准备好的文档。我怀疑您的客户想要“听到”您的声音(而不是固定的答复),以便获得信心和信任,您可以完成他们期望的工作。我遗漏的一件事;您可能还会描述您过去成功完成的类似项目的示例以及它们的执行方式(如果在NDA中未提及具体细节)。

– Bj Rollison
2011年7月21日在16:07

#2 楼

听起来像是您可以通过快速软件测试课程学习的方式

,它为您提供了提出相关问题的工具,以评估产品并向客户提供有关该产品的信息。

幻灯片可在James Bach和Michael Bolton网站上找到,但最大的好处是可以参加课程。

基本上,您使用一组启发式方法(指南)来指导您的提问,以便获取所需的信息。

将思维导图映射到思维导图上,然后帮助您了解更大的图景和关系。

同意您的观点,一般策略可能不是由于上下文不同,最合适。