质量保证 (QA) 部门大约是一群测试人员整天揭穿你的应用程序,为发布开绿灯,处理 Alpha / Beta 程序。以及更多。
但是,如果软件公司没有 QA 部门,现场就会经常出现问题,而且解决问题的成本会更高。然而,大多数公司都是从车库开始的,只有一名员工是你自己,然后发展成为一家软件公司。
你什么时候说要创建这样的部门?与公司的规模、遇到的问题有关吗?
质量保证 (QA) 部门大约是一群测试人员整天揭穿你的应用程序,为发布开绿灯,处理 Alpha / Beta 程序。以及更多。
但是,如果软件公司没有 QA 部门,现场就会经常出现问题,而且解决问题的成本会更高。然而,大多数公司都是从车库开始的,只有一名员工是你自己,然后发展成为一家软件公司。
你什么时候说要创建这样的部门?与公司的规模、遇到的问题有关吗?
只要你能负担得起。如果没有质量保证部门,您将永远不会拥有比有质量保证部门更可靠的产品。程序员不会成为优秀的 QA 人员,最好有第二个人(或更多人)来审查应用程序的工作方式。
所有优秀的软件公司,以及拥有优秀 IT 部门并创建程序的组织都有质量保证团队。这对软件开发至关重要。
作为一家成功的软件公司的前 QA 经理,我会说在你发布你的第一个程序后立即发展它。(之前,如果可能的话)。真的,只要你能负担得起。但是,作为开发人员,您应该在整个开发周期中自己进行大量测试,而不仅仅是在最后。QA 的工作(取决于您阅读的书)是处理大量遗留测试、SMOKE 测试、回归测试、真实世界测试,以及编写自动化测试程序、流程和计划等。
临时测试只是 QA 应该做的一小部分。QA 有两个主要关注领域。1) 软件是否做它应该做的事情,并以客户可用的方式满足要求,以及 2) 软件是否没有做它不应该做的事情。
计划的、程序的和临时的测试是质量保证的基础。我发现如果您只进行一种或另一种类型的测试,您将不会有一个成功的 QA 周期。
我在自己工作时发布了没有 QA 的软件,但我可以告诉你,无论我对其进行多少测试,它总是更容易出错。对于软件来说,第二双眼睛是最好的选择。
只要确保你的团队是由 ADD 保持肛门的计算机极客组成的。这样你会得到最好的结果。:) 当他们可以使某人的软件蓬勃发展时感到自豪的人......呵呵......(开玩笑......我认识很多没有 ADD 的 QA 测试人员)......
质量保证 (QA) 部门大约是一群测试人员整天揭穿你的应用程序
我很困扰您将 QA 视为“一群揭穿您的应用程序的测试人员”,就像 QA 是最终产品的障碍一样。这让我觉得你过去在 QA 方面的经历很糟糕。相反,请尝试查看 QA 为您的公司带来的价值。您希望最终用户能够从一开始就依赖您的产品。如果最终用户发现问题或缺陷,并对您的应用程序或网站感到沮丧,他们就会越来越不信任您的应用程序。QA 应该降低用户对您的应用失去信任的风险。如果 QA 不这样做,那么他们就不会带来任何应用程序必须具备的价值。那时,您需要新的 QA。不仅仅是按钮按钮。与开发人员一样了解应用程序的 QA。
最后一点是开发人员不是 QA。开发人员只应在绝对需要时戴上 QA 帽子。这对于只有 1 或 2 名开发人员的小公司来说是很困难的。所以我同意其他人的观点,他们说尽快进行 QA。在我为一家大型软件开发公司工作的现场,开发人员只有在我们有严格的最后期限需要满足并且 QA 时间非常宝贵时才戴上 QA 帽子。即使他们确实戴上了 QA 帽子,测试过程也会由该开发团队的一位主要 QA 审查,以确保开发人员正在全面有效地测试应用程序。只有在 QA 负责人对已进入开发人员测试的部分的测试级别感到满意之前,QA 负责人才会在该部分签字。
扮演魔鬼的拥护者:“QA 部门”是一条红鲱鱼,在许多情况下是一种逃避。
让我们先处理红鲱鱼。“部门”是组织结构的表述,谁向谁汇报;那是次要的。“QA”是一个总称,没有特别的含义。(不相信我?这是一个测试——你不想“保证质量”吗?当然不是。每个人都想要那个。)
那么你真正想要的是什么?您想在用户之前了解软件的故障模式。
如果您的软件在该领域存在“问题”,那么,这意味着找出故障模式的工作还没有完成,您可能想聘请有能力的人来做这件事。
我碰巧相信开发人员的职位描述至少应该包括其中的一部分。如果我聘请测试人员,我希望他们必须努力寻找失败模式。如果应用程序在测试人员把手放在它的几秒钟内崩溃,开发人员将直接听到它。我想到了“严重缺陷”这个词。
到了警察局。事实是,您不能在事后将质量放入产品中。但是“我们应该雇佣一些测试人员”是许多开发人员的呐喊,他们被抓到当场交出远低于可接受质量水平的代码。(我知道——我就是其中之一。)
因此,如果您确实雇用了具有测试经验的人,恕我直言,正确的做法是让他们与开发人员一起工作。向同一位经理报告。有着同样的使命:首先让它正确。
我们是一家只有一个开发人员的小型初创公司。每当我们谈论添加额外资源时,我的第一反应是聘请我一个 QA 人员!
我猜你会有机地发展一个 QA 部门:即使你是一个单独的程序员,你也应该做一些QA 人所做的工作。
例如,如果一个人将 10% 的时间花在 QA 活动上,那么一旦你有 10 个人,你就可以让一个人专门从事 QA。
这取决于。如果你是一家小公司,团队效率不高,而且你的错误率很低,这可能不是你需要解决的最大问题。
如果市场迫使您加快生产速度,开发人员的数量正在增长,并且错误率开始损害您的客户关系,那么您可以考虑通过使其更加正式来修复流程。
在小公司生存的诀窍是只实施流程,当它的价值为自己买单时。如果您雇用人员以提高质量,则必须为自己付出很大的代价,这意味着在此之前,质量必须非常差(并且会损害业务)。
通常,更好的支持流程更为重要,因为即使是最好的 QA 团队也会偶尔让错误出现。如果您处理好修复程序/补丁程序,客户将会对您印象深刻(他们不会注意到错误的显着减少,除非以前的版本都非常糟糕)。
保罗。
好吧 - 您需要编写代码测试的程序员以外的其他人。这并不意味着您需要 QA 部门。在许多商店中,业务分析师也会进行更经济的测试,因为您只能在构建的后期进行测试,而不是在需求分析和设计期间进行测试。在一家很小的商店里,你可能甚至不会使用业务分析师这个词,但你知道我的意思——不编码的产品或设计人员。即使在非常大的公司中,这种模式也有其优势。测试小组可以拥有自己的生活。
一旦代码库变得如此之大,以至于一个人无法了解所有细节。
这背后的原因是,90% 的回归是因为程序员没有意识到整个情况以及他们的代码对系统其余部分的可能副作用。在这种情况下,您甚至不知道您永远不应该提供 -1 作为年龄参数或类似的东西。在大多数情况下,界面应该是清晰的并且有错误检查,但在大型代码库中它会滑倒,当你急于赶上最后期限或长时间工作时,注意力会下降。
因此,尽管即使您是单人秀,您也应该进行基本测试,但只要代码增长到足以让您(或可能与您合作的任何其他人),就应该使用单元测试和类似的自动化测试工具之类的东西无法在头脑中掌握整个系统。
它应该在没有 QA 的情况下工作,但有
我目前正在经营一家车库创业软件公司,现在我用家人和朋友代替问答部门,我打电话给他们或让他们过来喝几杯啤酒并为我试驾我的产品。
到目前为止,这种“走廊”测试效果很好,但我的产品又不是针对技术熟练的用户,如果是的话,我可能会更难找到测试人员。
如果您没有现成的家人和朋友,我建议您在当地的分类广告或 craigslist 中投放广告,应该很难找到一些学生或测试最低工资的人。
至于何时聘请全职 QA 人员,我想说完全取决于公司的财务状况。
当您有一个两个人的公司雇用测试员时,可能会矫枉过正。尝试花一些时间自己测试。或者请朋友开发者(不在团队中)玩一段时间的应用程序。或者问一个朋友(非开发人员)——就像用户验收测试一样。
当你开始销售软件,当你有 3 个或更多开发人员,当你有两个要做测试的时候雇佣(我的意思是真正测试不是“它在我的机器上启动”,而是“我已经一直试图粉碎它几个小时,但它仍然有效。也许我应该变得很有创意?')。