软件缺陷描述是在软件测试过程中不可避免遇到的一件工作。作为一名测试工程师，要必须做到对软件缺陷进行清晰、完整、简洁地进行描述，否则就不能称为一名优秀的测试人员。

　　我们知道，在测试过程中，之所以对软件缺陷进行描述，是希望开发人员看到描述后知道软件出现了什么问题，明白缺陷的发生过程，必要时能根据缺陷描述将问题再现。但很多时候，测试工程师往往只站在自己的角度来描述，将很多细节忽略，总以为别人理解，殊不知，这样一来，外人读起文字描述就会摸不着头脑。举一个缺陷描述例子：

　　“模块：组织机构维护

　　缺陷详细描述：单位编码、单位简称、拼音码不可以修改，其他的信息内容可以修改。”

　　本缺陷描述的本意是想告诉大家：在组织机构维护主页面上，单位编码、单位简称、拼音码不可以修改。但是工程师想当然认为只要说出“单位编码、单位简称、拼音码不可以修改”这句话，别人自然就会知道会在哪个页面出现的问题，但实际上，“组织机构维护”模块可能会产生很多子窗口，也可能在多个窗口中都会出现“单位编码、单位简称、拼音码”等信息，这样一来，开发人员在看到这个缺陷描述时，就无法很顺利地将问题再现，即便经过口头交流弄清问题的真相，也浪费了彼此的时间。因此我个人的看法是，在描述问题时，需要尽可能遵循“在什么页面，做了什么操作，出现什么样的结果”这样一种描述模式。

　　有时即便我们将问题的发生过程清楚地描述出来，仍然不够完整，需要再作补充说明。再举一个例子，假如一个缺陷这样描述：“用A-B，结果等于C”。这句话读起来很容易明白，但开发人员初始看时可能一头雾水，不知问题出在哪，但如果改为“用A-B，结果等于C，但实际上应该为D”，开发人员可能就会恍然大悟。

　　另外，需要强调的是，描述清晰并不意味着文字越多越清晰，在进行描述时，如果能用一句话描述清楚的，就坚决不要用两句话。还以第一个例子做说明，“在组织机构维护主页面上，单位编码、单位简称、拼音码不可以修改”这句话已经说明了问题，如果将之更改为：“以用户名**及密码**登录**系统，单击**按钮，进入‘组织机构维护’主页面，在该页面上，发现单位编码、单位简称、拼音码不可以修改”，就显得句子太过于罗嗦。