初创公司应该在流程的早期有专门的 QA。通常,QA 是在相当晚的时候添加的。
我的两部分问题是:
- 什么时候应该首先将专门的质量检查作为启动工作的一部分,为什么?
- 第一个 QA 成员应该具备哪些技能(创建和执行测试脚本、使用常用工具进行测试自动化、编写单元测试、计划和执行复杂的负载和稳定性测试等)?
初创公司应该在流程的早期有专门的 QA。通常,QA 是在相当晚的时候添加的。
我的两部分问题是:
我将提供一个非常规的观点:
初创公司的第一批 QA 成员应该有能力在他们没有充分指定项目时告诉开发团队(并帮助他们实现这个目标)。
对我来说,质量保证不仅仅是测试。测试是质量控制 (QC)。但是如果你不知道它应该做什么,你就不能为一个产品设计测试。这种情况在创业环境中非常普遍——编码人员在一个项目上狂奔而没有决定他们正在构建什么。
质量保证过程在编码之前开始:
这就是为什么我说第一个 QA 活动应该包含在需求规范阶段。
我坚信敏捷和精益软件开发。请在神话般的 Mary Poppendieck 关于缺陷的一些引述之后在这里找到:
最后一个:
所以,为了回答你的问题,我的观点如下:
作为初创公司的唯一开发人员,让我提供我的意见:
通常,直到 1.0 之后才需要 QA,并且该产品具有收入来源。
它只需要“工作”。
作为一名专业的 QA 工程师,我会说,在你能动的时候就拥有专门的 QA 是件好事。在最初的开发周期中,QA 将为功能规划带来不同的视角——这应该以多快的速度运行?它的规模有多高?一个安装可以同时支持多少个用户?
优秀的 QA 工程师会不断寻找新的方法来打破常规。从一开始就关注总比在流程后期引入 QA 更好,这让那些认为自己做得很好的开发人员士气低落,直到新的 QA 人员在他们身上堆积数百个错误报告,然后需要对这些错误报告进行分类(是这甚至是一个错误?如果质量保证从一开始就参与其中,他们会知道这是预期的行为!等等)然后实际修复。
而且,老实说……如果我们谈论的是一家初创公司,他们不会编写测试计划或产生有用的自动化。一旦你有一个稳定的产品并且你有一些保证整个 UI 不会改变,测试计划是很棒的,并且自动化非常适合捕捉回归,但是在初始开发期间,不会有任何回归,因为你没有' t 运送任何尚未回归的东西。
确实,优秀的 QA 工程师需要的重要技能是沟通、固执和快速跟上进度的能力。如果 QA 发现了一个 bug,但无法清楚简洁地解释它是如何发生的、他们在做什么以及如何重现它,那么它们的用处就会迅速减少。
QA 可能会有所帮助,但在您有资金确保产品完成之前,添加一个仅用于测试的主体是有风险的。如果添加新的开发人员有助于确保在资金用完之前完成产品,那么您可能需要更改优先级并获得新的开发人员。
开发人员可能需要进行 QA,但如果是这种情况,那么为某个功能进行开发的人不应该对其进行测试。
例如,您可能希望您的 QA 人员也负责持续集成构建,因此他可能需要戴几顶帽子,因为团队中的每个人也将戴几顶帽子。找一个可以非常灵活的人,这样他们就可以帮助开发人员腾出时间来进行开发。
在我看来,答案如下:
关于第一个问题,QA 应该参与需求分析。通过这种方式,QA 可以与程序员坐在一起与系统工程师讨论,以彻底了解需求。在这个过程中,QA 将对需求有一个清晰的认识,从而在程序员进行编码时编写测试用例。
因此,程序员和 QA 将同时完成各自的工作。
关于第二个问题,QA 应该对他必须工作的环境、测试方法以及自动化测试的基本知识有相当的了解。如果这是一个启动项目,他将有时间从事自动化工作,从而自动化回归和健全性测试用例。因此,这将为管理层交付产品节省时间和精力以及金钱。
我工作过的大多数初创公司都很少有全职的 QA/Test 人员。
如前所述,一种选择是找一个可以戴多顶帽子的人。
另一种选择是在需要时雇用他们作为承包商或自由职业者。
如果适合您的业务模式,还有众包测试的想法可以考虑或寻找可以远程工作的人。
这里有一个很棒的想法的日志。我同意最好尽快开始 QA。关于一些战术,我同意 Snehal Mohite 并会添加 Q3。
Q3) 将您的 QA 构建为敏捷并尽可能多地自动化手动工作。确保您拥有“行业工具”,以帮助较小的团队更轻松地完成任务。例如,添加 Applitools Eyes 之类的工具以在功能测试的同时启用可视化测试。这可以帮助您事半功倍。让您的团队开始使用正确的工具有助于为您和您的客户奠定坚实的基础。
只要您的公司有足够的规模和盈利能力,就可以进行专业化。
大多数小公司都要求员工是通才,并且不只戴一顶帽子。
这里没有神奇的答案,但对于小企业来说,关键是每个人的收入都必须高于他们的收入;倍数比增量好。这是一个事实,无论 IT 多么需要独立的测试人员。
我想小公司可能必须要有创意,做一些事情,比如请朋友测试 alpha 版本的礼品卡而不是金钱,或者与值得信赖的客户合作。
有大量关于 QA、测试人员等的可用资源,而您的问题(一个非常好的问题)没有简单的答案。对于他们何时、有多少、在哪里以及多早参与这个过程等,没有什么神奇的公式。
可能您首先应该弄清楚的是您的实际需求是什么。大多数人(不幸的是)将 QA 等同于测试。测试只是 QA 团队的一个方面。大多数人在成长为拥有“真正的” QA 团队之前,都是从专门的测试人员开始的。
质量保证更多的是关于预防性维护,而测试更多的是关于事实调查。
你是在追求测试人员还是更多?
关于测试人员的技能,排名第一的技能是成为产品领域的专家。其他一切都是次要的。
在进行 QA 之前,您有一个具有远见和组织的产品经理,并且您有开发。在你雇佣你的第一个 QA 人员之前,产品经理应该戴上 QA 的帽子,并且能够定义需求并使用初始测试框架进行操作。然后,随着项目的起步阶段,您可以聘请 QA 开始从项目经理那里承担项目管理任务。重要的是聘请足够熟练的 QA 和产品经理,这样开发就不需要戴上 QA 或设计的帽子。
什么时候应该首先将专门的 QA 作为启动工作的一部分,为什么?
Ans:我自己是一名 QA,我认为 QA 应该从启动开始就一直参与,因为这是质量保证的问题。QA 需要了解整个过程,以及产品中涉及的每个组件的行为。
QA的主要任务如下:
a) 从客户那里收集要求。
b) 了解需求并了解需求,因为它说“客户为王”。
c) 根据收集的信息设计测试计划、测试用例、工作量估计等。
d) 最后测试和bug归档(注意:把bug归档清楚,提到测试重现)。
上述几点清楚地解释了为什么需要从启动阶段就参与 QA。
Q2) 第一个 QA 成员应该具备哪些技能(创建和执行测试脚本、使用常用工具进行测试自动化、编写单元测试、计划和执行复杂的负载和稳定性测试等)?
1) QA 应该具备的最重要的技能是“了解客户的要求”以及产品中涉及的整个产品行为和功能。
2)基于需求编写基本的UI和功能相关的测试用例。
3) QA 还应该能够区分测试范围内的内容和不在测试范围内的内容。
4) 根据截止日期,应该能够过滤出 P1 优先级测试用例并首先执行这些测试用例。