因此,这听起来像是“抱怨”的帖子,但实际上并非如此。但是通常我会交给一个项目,比方说一个网站。然后被告知给它一个“全面运行”的方法。并在每个浏览器中都进行操作。

我不可避免地会找到一些东西,通常很多。但是之后,客户通常会遇到“设计”问题。 IE浏览器需要在右边填充75x像素,或者该图像需要拉伸等。但是,只要有时间(又一次)...我想我总是对这类事情感到难过。

所以我的问题是: >如果您一次通过一次正确检查,那么事情会漏掉吗?我没有在谈论很多主要的东西。但是事情不多(尤其是在大型网站上)。我怎么不为此而烦恼呢?
您该如何设计?希望质量检查人员注意到这些事情吗? (特别是没有参考)。就像我会注意到的,例如,给出一个样机时,标题应该是蓝色而不是红色,或者文本应该这样说。但是填充/等...我不太确定是对是错....我如何自己修改或改进它?


#1 楼


如果只给您一次正确的答案,那么事情就会漏掉吗?我没有在谈论很多主要的东西。但是事情不多(尤其是在大型网站上)。我怎么不为此而烦恼?


是的。有无数的质量级别,每个级别的错误都会漏掉。考虑以下级别:


是否可以使用该网站来执行开发人员认为需要做的事情?
是否可以使用该网站来执行项目的工作经理要求这样做吗?
是否可以使用网站来执行项目经理实际想要的工作?可以吗?
可以使用网站来做用户想要的事情吗?
网站可以理解吗?
网站是否易于使用?
网站可以吗?真正帮助企业实现其目标吗?
企业是否满足所有者的目标?

等等。您从事这项工作的时间越长,您将看到的级别越多,问题就会越多。您永远无法抓住或解决所有问题。

因为没有实现无法实现的目标而使自己筋疲力尽是没有意义的。一种更有生产力的生活方式是关注您的工作,诚实地观察结果并乐于接受变化。这种迭代方法可以带您逐步改善。


您可以对设计事物做些什么?希望质量检查人员注意到这些事情吗? (特别是没有参考)。就像我会注意到的,例如,给出一个样机时,标题应该是蓝色而不是红色,或者文本应该这样说。但是填充/等...我不太确定是对是错....我如何自己修改或改进它?


您的组织必须决定是否希望质量检查注意到这些问题。有时,设计问题显然是错误的,但是通常,您只有在用户经历设计问题后才知道设计问题。您可以通过与外界接触来进行测试。参见例如UserTesting.com。

#2 楼

处于那种情况,远远超出了我的期望。尽管我们希望客户提供完整且严格的要求,但从来没有(而且我的意思是从来没有)发生过。好吧,除非您将人们射入太空。我听说他们做得很透彻。

对于我们其他人来说,这通常是一个连续体。就您所需要的程度而言,您并不需要多少,您将不得不依靠经验并进行有根据的猜测。显然,您知道异常,500个错误,超时和登录失败是很糟糕的。

我看过“没有要求我根本无法测试!”口头禅,是布布基人。你可以测试一下。但是从任何意义上说,都不会对其进行“全面测试”。 :-)

我发现一开始就勾勒出自己的假设有助于指导我的测试,并且使我对如何确定工作的优先顺序/时间安排有了一个很好的了解。这在“测试黑暗”时尤其重要。

这些(总是)是我要提出的一些核心问题。如果需求能够解决问题,那就太好了!如果不是,请做出最好的猜测。

该工具/程序试图帮助谁? (目标受众)
试图帮助人们实现目标的工具是什么?这不仅仅是他们使用工具“做什么”,而是“在网站上获取照片”和“与家人共享照片”之间的区别……区别有时很细微,但非常重要。它做到了吗? (这涵盖了大部分幸福的道路)
很容易吗? (这涵盖了基本的UI)

一旦出现故障,随着测试的进行,您(当然)将需要更多信息。我发现以下方法有助于获得上述答案...

“那么,它是否更像是一种假定的功能,还是一定程度的经验?” <-适当地替换示例。

“我认为此功能应以这种方式工作...是这样,还是我缺少了什么?”

“如果我做X,您能帮我澄清一下吗,我应该看到Y或Z发生吗?否?但是Q永远不应该发生,对吧? />我同意100%以上的100%评论。没有经过完全测试的应用程序。

你不是“质量的守门员”……那是垃圾。您的工作是尽最大努力让那些做出决定的人知道应用程序的状态。这项工作受时间限制。给我更多时间,我会给您一个更自信的答案。给我更少的时间,我会确定优先级并尽我所能,但是它不会那么深入。

这是对荒谬的“完全通过”请求的解释……我通常会给出一个沿着这样一条路线挥舞着:

有一天,我可以达到20%的基本功能,但只能验证到5%的深度。
给我一周,我可以像40%的最常用功能,但深度更接近10%。
一个月内,我可以达到75%的功能,深度达到40%。

需要注意的是:发现了更多的错误并延长了修复时间,因此需要调整这些数字。工程师需要拧紧灯泡吗?“

呃....

”没有。我们只报告它是黑暗​​的。“

是的,但是我要添加“但我们将告诉您何时熄灯,熄灭的频率,熄灭时开关的状态,是否可以在哪个房间重复点亮?我们nt,还有谁最后碰过它”

打起精神-祝你好运!

评论


是的,我的意思是,即使没有要求,我仍然可以测试一切(我已经做了一段时间了哈哈)。但是我想我更多是在谈论别人的期望。

– Merfh
16年4月15日在19:06

管理他人的期望很难〜而且他们常常以某种方式认为质量保证是他们可以在周期结束时在产品上发布的灵丹妙药,它将弥补糟糕的计划。

–亚伦·B。
16年5月9日在14:32

AND ..即使在规模较小的网站上,事情也会顺利进行。即使是一个团队也无法捕捉到全部……显然,如果您独自飞行,您将无法捕捉所有。我们谁都不能。从事质量检查已有18年了,我仍然很想念东西。不要为小东西流汗...真的,不要。没关系。关于设计〜是的,请注意颜色已关闭。记录下来。他们可以选择修复或不修复。对齐〜同一件事。 “看来X和Y不能对齐...这是设计使然,还是CSS错误?”或通常类似的方法。谦虚地问:“不确定...这是否符合预期?”走很长的路要走。

–亚伦·B。
16年5月9日在14:40

#3 楼

如果您没有得到要求,那么它将使测试变得非常困难。您还会很高兴听到不可能进行详尽的测试(请参阅软件测试原理)。

在设计要求方面,您可以向产品设计师或业务分析师寻求反馈/在进行过程中进行确认,因为需求经常变化-特别是在敏捷环境中。

在开始执行任何测试之前,应花几个小时进行测试计划。然后,测试计划可以由客户批准,并且他们有效地签署了要进行测试的范围,更重要的是,超出了范围的范围。

我的一般经验法则是;如果与您期望的不同,则提出缺陷。这样可以防止业务中的任何人走“你为什么不说什么?”或“您是怎么想念它的?” -但是您已经背叛了缺陷,并签署了缺陷的测试计划:)

评论


Cem Kaner的视频很好,描述了完全测试(或详尽测试)不可能的基础:testingeducation.org/BBST/foundations/…。

–克里斯·肯斯特(Chris Kenst)
16年4月13日在23:16

#4 楼

1)请记住,不可能进行100%的测试,这是基本的测试原理,每个人都知道这一点。

2)GUI错误对于客户端很重要,因此您应该专注于这些错误,因为它们将是第一个被发现的错误。但是px bug可以通过chrome F12进行检查。

另外请注意:花费您的时间,应在开发时间的40%内进行质量检查。

评论


您是如何提出40%的问题的?

–IAmMilinPatel
16年4月13日在16:05

#5 楼


Q1。如果只给您一次一次正确的消息,事情就会漏了吗?我没有在谈论很多主要的东西。但是几乎没有什么(尤其是在大型网站上)。我如何不为自己打败自己?


A1。接受你不能完美。确保您有出口要记下并记录发现的错误,以便将其解决。尽可能多地了解业务领域,以便您的反馈与之相关。确保覆盖了不同的数据,不同的设备,喜怒无常的路径,不同的连接性等,如果您没有“一次通过”覆盖它们,请确保已声明。请记住,您可以在本地使用Safari,Chrome,Android Studio(以及在Mac,iOS手机模拟器和用于其他浏览器(例如IE)的Parallels)上,也可以使用http://browsershots.org/、http:/ /browserstack.com或http://saucelabs.com


Q2。您可以如何设计事物?要求质量检查人员注意这些
吗?


A2。是的,这是通过探索性测试以及您的大脑看一切是否正常来涵盖的。这也是您对表单和链接进行大量自动测试的原因之一,这使您腾出时间来手动查看外观并尝试外观来检测问题。

#6 楼


如果只给了一次一次正确的答案,事情就会漏掉了吗?我没有在谈论很多主要的东西。但是几乎没有什么(尤其是在大型网站上)。我怎么不击败自己呢?


我总是说我可以在任何时间测试任何东西。给我更多的时间,我可以做得更好。但是,即使我没有时间,我仍然可以做一些好事-只是不那么好。

在开始测试之前,请仔细考虑。由于我有X个小时的时间进行测试,因此该怎么办才能产生最大的影响?

例如,也许您正在太多的浏览器上进行测试。如果时间紧迫,我可能会跳过用户数量不多的浏览器,以便专注于最常用的浏览器。或者,我可能不会打扰任何负面测试,直到我我有信心这条快乐的道路会奏效。您将能够告诉自己,您已尽其所能在X个小时内尽了最大努力。而且您会知道,如果事情从裂缝中掉出来,那是由于时间原因,而不是无效的测试。希望质量检查人员注意到这些
吗? (特别是没有参考)。就像我会注意到的那样,例如给定一个
样机,标题应该是蓝色而不是红色,或者
文本应该不是这样。但是padding / etc ...我不是真的
确定什么是对还是错....我该如何为自己修改或改进它?


与往常一样,这要取决于情况。 />
当然,您应该注意到该特定应用程序内部的任何内部不一致之处。

有时候,您只能做自己能做的事情。而且,如果样机没有告诉您足够的信息,就不能指望您读书。

这可能会有所帮助:
http://www.allthingsquality.com/2010/04 /there-are-always-requirements.html

#7 楼

在我深入研究之前,请注意:我们做Scrum,所以这取决于您公司使用的项目方法,这对您可能有用也可能没有用。

背景:

我们有利益相关者的初步要求。利益相关者是我们的客户,主题专家,产品所有者,主管和经理的组合。我们向他们提供了预期的最终结果。如果没有其他事情,这是在主题专家和产品所有者对项目进行梳理之后。我们有一个所谓的Scrum团队,由Scrum主管,我们的业务分析师,QA和技术人员组成。我们作为一个团队聚集在一起,审查项目以及他们在培训会议中提供的详细信息。我们确保我们了解他们想要成为最终产品的情况。然后,我们召开会议来生成BDD(业务驱动开发),它大致提出了需要测试的所有可能事物的测试场景,包括任何回归测试,以确保我们不会破坏现有功能。技术是此过程的一部分。进行BDD带来了巨大的变化,不仅使质量检查人员对所有需要测试和验证的事情负责,而且使测试更加彻底。需求确实会发生变化。在测试时,您可能会发现客户没有提到的差距。您提出来。然后,他们决定是将其吸收到该项目中,还是基本上将其变成该项目的另一个阶段。我只是想让您知道,质量保证的真正支持是将整个团队包括在内,以确保尽可能地测试项目。我意识到您可能无法做到。如果不是这样,那么您将只能由一个人进行测试和验证。

正如其他人所说,没有全面,完整,完美的测试。这是最大的努力,真诚的努力,尽可能多地进行测试。而且正如有人指出的那样,您应将大量时间分配给实际测试。我曾与QA一起工作过,并且知道他们的工作有多么艰巨(我是一名软件工程师),并且尊重他们因测试而承受的重担对于为客户提供优质产品至关重要。尽力而为,不要打败自己,随着时间的流逝,它将变得更加容易。老实说,这是经验是您最佳资产的那些职业之一。所以知道它将变得更加容易。