有得到修复的bug
j;_6C0Y:V*h0LCf0
KR8X4l-O1A$JsX;J0依靠用户特殊的需要产生的市场,应用程序中严重性高的bug可能被延期,而小的那些bug却得到修复。要记住的是修复一个bug是一种商业决定,测试人员应该尽可能站在组织的角度来理解用户工作流。
7ok#c_]b4X0P1]R s8i0 51Testing软件测试网*E{zJkB Nf6B'W
51Testing软件测试网:Wy[
ZU%@|今天无意中看了一篇关于BUG有效沟通的文章,里面这段话给我的感触比较大.51Testing软件测试网,la!uL
V%|)\W2T
51Testing软件测试网Whf/Z cmpB测试人员应该尽可能站在组织的角度来理解用户工作流
YNHlh3{03R.Ut$I;y
ou5@pn0测试人员每测试一个项目的时候有条件的没条件的都希望通过软件的需求说明书进行入手对软件进行测试,而真正能理解多少用户的需求呢?一开始有了解清楚用户的组织架构\人员角色\日常工作流程\希望通过软件进行改进的管理方法吗?这些都是最原始的最基本的需要在一个项目或系统测试之前要了解清楚的,不了解清楚将来所生成的那些BUG基本都是一些无关痛痒的程序员的问题,而真正需要我们测试人员发掘的是那些一开始项目经理\设计人员\程序员没了解清楚容易产生分歧的BUG,这些BUG相对于之前的BUG价值更大,更容易影响到项目的进展\成本及最终的成败.
8E+lu%t Es0e0gbrJt
DR2^P0 51Testing软件测试网'I"Fbx&|m"N,_
51Testing软件测试网s&v^a7h"N4O7n7[作为测试人员,我们要时刻问自己一句话:我是在构想客户的需求吗?这个确实是客户想要的吗?
?4Y Ug9Ew
}1F,lQMW0'M%elbD0问完后就要用实践去检验,去查找需求设计文档,如果模糊的尽可能直接与项目经理设计人员进行沟通确认,以及及时的修改相应的文档.