有得到修复的bug
+S,a
y#^6?'iK051Testing软件测试网'm+jyi&UT{依靠用户特殊的需要产生的市场,应用程序中严重性高的bug可能被延期,而小的那些bug却得到修复。要记住的是修复一个bug是一种商业决定,测试人员应该尽可能站在组织的角度来理解用户工作流。51Testing软件测试网/r@"p}oIRP4}
51Testing软件测试网UWoJ3n{h2Dk 51Testing软件测试网O+E*kvwnvdf$d+?A-}
51Testing软件测试网i2w#E[#p5qmGx.B今天无意中看了一篇关于BUG有效沟通的文章,里面这段话给我的感触比较大.
&Y.d7Y:]y~]bU#D051Testing软件测试网u\ iuYw"X测试人员应该尽可能站在组织的角度来理解用户工作流
-Mpu2m%k f;g0@4{:y
jO
uh(o q*m0测试人员每测试一个项目的时候有条件的没条件的都希望通过软件的需求说明书进行入手对软件进行测试,而真正能理解多少用户的需求呢?一开始有了解清楚用户的组织架构\人员角色\日常工作流程\希望通过软件进行改进的管理方法吗?这些都是最原始的最基本的需要在一个项目或系统测试之前要了解清楚的,不了解清楚将来所生成的那些BUG基本都是一些无关痛痒的程序员的问题,而真正需要我们测试人员发掘的是那些一开始项目经理\设计人员\程序员没了解清楚容易产生分歧的BUG,这些BUG相对于之前的BUG价值更大,更容易影响到项目的进展\成本及最终的成败.
_ STn8?(f&X051Testing软件测试网6lF5XXG|/| 51Testing软件测试网;xEKW9w^
hO$vc#H0作为测试人员,我们要时刻问自己一句话:我是在构想客户的需求吗?这个确实是客户想要的吗?51Testing软件测试网+f+G9Nc*j
~,}mr^$H0问完后就要用实践去检验,去查找需求设计文档,如果模糊的尽可能直接与项目经理设计人员进行沟通确认,以及及时的修改相应的文档.