我们组织中的质量检查经理要求我们的开发团队在设置测试环境之后,在质量检查团队开始测试之前进行烟雾测试,即他希望我们在环境和环境方面签字。可以说它足以进行测试。


我想知道这是否在许多组织中是普遍的做法。如果没有,更常见的做法是什么。


评论

经理是要自动还是手动?如果是自动的,那么具有自动部署的CI(包含已连接的测试)将大有帮助或完全解决了这一问题。如果他/她手动想要它,那么这是另一个问题。但是总而言之,哪些测试被视为由QA和Dev定义的特定烟雾测试的一部分,并且取决于以前的经验,这意味着哪种类型的缺陷阻碍了对环境的测试。

只是好奇。你们写单元测试吗?

@saifur-是的,我们愿意,但是单元测试只是故事的一半。我们的应用程序具有许多无法控制的依赖关系(WS,DB等),并且在大多数情况下,烟雾测试由于这些依赖关系而失败。

进行少量依赖关系的部署验证测试听起来不错。但是,我同意,需要开发人员对每个模块进行功能测试听起来有些过分。

过去我们有类似的政策,在发布之后,Dev不仅会进行部署以确保构建正常进行,而且还会通过检查未使用的区域来进行抽烟测试。这为他们提供了在其他领域的宝贵经验,并确保没有人为可能出现的问题而盲目。

#1 楼

我不能代表整个行业,但是在我工作过的地方,如果交付给QA的建筑往往不可靠,则开发人员启动的烟雾测试是一种常见的做法。

我曾在一个团队中担任测试负责人,该团队要求开发人员对构建进行烟雾测试。最初,这是一个痛苦的过程,占用了整个开发人员整个上午的大部分时间。最终,我们使部署自动化并编写了一些自动化烟雾测试。这为开发人员节省了一些时间,同时使质量检查团队可以了解测试最新版本是否充分利用了他们的时间。

“开发人员进行冒烟测试”政策迫使开发人员更加注意要检查的代码的质量,这当然是重点。随着时间的流逝,建筑质量不断提高,烟熏测试也变得越来越少。

评论


好的,我明白了逻辑。我对我的团队做他们(和我)认为质量保证工作的方式感到不满意,但是我现在知道这样做的好处。

– Elad Lachmi
2015年4月14日在17:29

每个人的工作都是协助制作高质量的软件。错误越早交到开发人员手中,对每个人来说越好。开发人员启动的烟雾测试有助于防止“无限缺陷方法”时间表只是等待被转化为错误的功能的清单。在验尸中,这被称为“无限缺陷方法”来源,滚动到#5

–corsiKa♦
2015年4月14日在18:21

#2 楼

我同意@ user246和@Niels van Reijmersdal,但增长的时间超过了评论。 :-)

如果允许开发人员仅将代码“扔在墙上”进行质量检查,即使基本的烟雾测试在质量检查环境中失败,他们也没有动力修复烟雾测试过程-并且最终实现了其中的大部分自动化。如果冒烟测试失败,则开发人员应该能够更快地找到原因-因此,质量检查手动测试人员尝试找出原因会更好地利用团队的时间。

评论


我真的很喜欢这个答案。这似乎暗示着,如果开发人员进行的冒烟测试足够大,以至于您认为质量保证应该这样做,那么您实际上就不再在进行冒烟测试。

–corsiKa♦
15年4月14日在22:51

#3 楼

听起来您提供了一个至少可以启动的环境,这听起来很合理。冒烟测试通常只包括检查应用程序是否启动以及某些基本功能是否正常。

我认为,最佳实践是设置一个持续集成环境,该环境应为:


构建应用程序
运行单元测试
运行一些集成测试
运行一些GUI测试
部署到测试环境

执行步骤之后5个质量检查小组就可以开始进行这项工作。

获得他们的帮助来设置集成和GUI测试,他们需要它才能开始对其进行测试。我让质量检查小组定义冒烟测试,并让开发团队将其自动化。

评论


感谢你能这么快回复。当然,我们建立了一个功能环境。问题是我们有35个(并且正在不断增加)不同的模块,他希望我们进入每个模块并检查是否存在基本功能。即使对于模块,我们也没有涉及。在我看来,这就像是质量检查工程师应该做的事情,但是我有偏见:)

– Elad Lachmi
2015年4月14日在12:03



听起来像是自动化测试应该做的事情,不要在重复的任务上浪费很多时间。测试自动化是未来:)请问为什么QA会问您这个问题,可能他们遇到了模块没有“接触”但无法启动的情况。尝试解决该问题。

– Niels van Reijmersdal
15年4月14日在12:08

#4 楼

持续集成服务器(Jenkins,Teamcity等)具有在构建之前进行的单元测试和自动功能烟雾测试的运行,是我们理想的工作流程中的选择。我们有一些开发人员检查清单,他们应该在没有Continuous Integration服务器之前在初始状态下提交到存储库之前执行这些清单。

#5 楼

在我工作的地方,开发人员应将其新功能部署到Dev环境中,并确保该功能和平台都仍处于非常基本的水平。我们经历了一段时期,很多新工作都无法签到并部署到Dev,因此立即被立即撤回。我认为应该将开发人员进行烟雾测试的水平作为功能向质量检查的过渡期。

理想情况下,其余功能应由CI覆盖,并且一旦该功能处于可测试状态,质量检查小组将选择所有新的,未覆盖的功能。

这意味着该功能上的开发人员会在将该功能部署到开发人员后对其进行测试,以测试该功能的一些最基本功能,以确保其准备好供质量检查小组使用,开发人员绝对不应花费太多进行此健全性检查需要大约20分钟以上的时间进行大多数工作:一旦认为该功能正在运行,则质量检查就可以从那里开始。