软件测试工程师除了技术，还要求具有否定性的创造力；探测技巧；总体理解产品的能力；用客户的眼光进行评估；怀疑的而不是敌意的态度；能经受得住坏消息而保持目标；拥抱新技术的热望等特征。
否定性的创造力。一个软件工程师不能怕引起一个产品的瘫痪或烧毁。在软件测试中，边界意味着被超越而不是被遵从。如果一个程序对某个值的极限为10(例如，可以在一时间被打开的最大文件数)，测试工程师的第一想法应当是“如果我把那个值取11，或0，或10.1，甚至不设这个值会如何？”
在我的早期的工作生涯中，有一次我测试一个开发和QA工程师遗漏下来的PC数据库。有问题的数据库是2.01版。这本身就说明产品有问题。2.0版没解决1.0版的所有缺陷吗？或者2.0版又加入了新的缺陷？很遗憾因为时间紧我没有调查这些，只是证实了最后的缺陷修复后就告捷了。
这是很大的错误。我应当重测开发人员所谓“没有变化”的所有产品功能。2.0版本中的缺陷确实复修了，但在修复的过程中，有人破坏了请求。事实就是如此，在数据库里不能搜索数据了，第一个收到这项产品的beta客户发现了这个缺陷。
我宣布以前的测试无效，要求对产品进行全面测试。找到几个缺陷之后，我发现这个数据库读取写保护文件或写保护了的磁盘的时候就会引起瘫痪。开发人员很吃惊我会试着写保护一个数据库。他们的反应就是：“没人会这么干的！”产品的市场经理很快用他们的方式承认了错误。
探测技巧。在一个理想的世界中，软件测试应当在一个经常更新的写得很清楚的功能与设计说明文件(一般被称为specifications”)中被完整而精确地描述。不幸的是，这一完善被开发程序每一方面文件的任务，包括记录在开发中对程序不可避免的改变，要花很多的时间和精力以至于人们无法完成编程。而且花费也太大。
正式与非正式的信息源 正式系统 要求文件 功能说明书 设计说明书
非正式系统 用户文件 与其他开发人员的交流 与软件支持人员的交流
有关产品的文件 有关产品的缺陷 从工作于相关或早期版本产品获得的“局部知识”
因为我们不是在理想世界里编程，测试工程师应当能够自己找出工作的方式。典型的是，总会有一些设计和功能说明书让测试工程师用于开始他的研究。这些文件能看成为描述被测试软件的“正式”系统。测试工程师应当能用更广大的“非正式”系统的信息来扩展“正式”系统的信息。同时，在项目周期的任何一个点，任何文件都可能是正确或不正确的，所以测试工程师必须根据对软件工作模式的观察，与开发人员和其他项目人员的交谈，或对有关或看上去不那么相关文件的审核，来确定文件的精确性。
总体理解产品。在一个程序项目是，软件开发工程师主要把他们的精力和注意力集于自己的项目部分。结果当这些项目部分组合在一起进行测试的时候，就会碰到兼容性的问题。到产品寄给一个客户之前，唯一能见到整个产品的就是测试工程师。因此测试工程师必须能够对整个产品的操作与使用保持一种“系统”的眼光。
测试工程师对产品的任何一部分的操作可能不是最好的专家，但他必须是产品整体操作的专家。例如，如果被测的产品是一个类似于Microsoft Office的由文字处理、扩展页和其他有关程序组成的办公室自动组件，测试工程师必须了解每个程序的操作，各个程序之间的相互作用和客户其他的软件硬件和软件环境。
用客户的眼光进行评。测试工程师必须是客户的拥护者。被测程序有可能运行可靠满足所有的设计要求，但在客户的软件环境中未必能够用。产品被送到客户之前的测试之一就是要证实产品达到了客户的要求与期望。在这项测试中，测试工程师必须模拟用户的软件环境，把自己放到他们的位置上。
关于软件功能“正确”而不能满足客户需要的一个悲剧性的例子就是美国航空公司965航班1995年在哥伦比亚卡利市的一次失事。在飞行着陆时，空中信号控制系统指示机组人员朝一个叫“Rozo”的航空信号灯飞。这个信号灯在航空图中标为R。机组人员把R输入到飞行管理计算机中，看到了明显是由近到远列出的六个航空信号灯。机组人员选了第一个信号灯，以为这就是Rozo。但那不是。自动驾驶仪把飞机向左转了九十度，撞到了山上。
什么地方出错了呢？当航空表里把Rozo列为R的时候，飞行管理计算机要求机组人员输入信号灯的全名调出它的方位。同时，计算机只显示了信号灯的编码字母和方位。计算机功能“正确”，但不满足用户的需求。
要求变化。项目刚开始时的要求与最终项目完成时的要求一致的情况是极少见的。有时技术变化了，产品必须改变以适应于技术。有时竞争对手的产品具有你的产品所没有的功能。很多情况下，客户的或潜在客户的要求需要变化。这些因素合在一起的一个例子就是目前Microsoft Internet Explorer和Netscape的竞争。
随着计算机首次用户的迅速增加，今天的测试工程师比以往更需要把自己置于客户的位置上。这些新的非技术用户不愿意接受缺陷，对缺陷的解释或理性思考，或通过“升级”修正缺陷。他们只希望他们所买产品的软件和硬件都是能工作的。
怀疑的而不是敌意的态度。测试工程师不能按表面值接受事物，必须执着地对一切提出疑问直到被证实。工程师必须用一种与项目的其他的人合作精神来平衡这种怀疑性与执着性。测试部门与其有关部门的关系可能会变得紧张，特别是在大量缺陷被发现后，或者在每个找出的缺陷会潜在地延迟产品的发货时间而延迟了项目时。测试工程师应当记住要攻击程序的整体性，而不是程序员。
经受得住坏消息而保持目标的能力。一个测试工程师必须忠实地汇报产品中的缺陷。这一信息应当被项目组欢迎，因为每一个测试工程师遇到的问题(除非加入新的问题)都意味着减少客户会面临的问题。但不幸的是很多人不想听到有问题，特别是在程序项目的后期。
测试工程师应当能处理因为工作做得太好而引起责备的情况。这对有些人来说是很难做到的，会严重地影响斗志与自尊。
看起来常常是测试工程师阻挠了向客户交货。客观的项目经理才能感觉到测试工程师是在对项目提供有价值的服务。我清楚地记得一个项目经理举起他的手求我他要的是：“解决方案，不是问题！”(他不明白解决方案的实现有时要求一个问题的解决。)有时项目经理在项目计划不方便的时候对于因为发现缺陷而打折是有压力的。在这些情况下，测试工程师应当能基于他对产品的经验和知识进行辩护，但他不应表现为象是他个人受到了威胁。
如何避免这些情形呢？就测试的内容、时间及如何更新测试结果和缺陷信息，设定其他项目组成员的期望。我曾经为一个希望延迟产品发送日期的QA经理工作过。他的目的不是为了产品成功，而是政治权力的操纵。他确信自己能被提升，把一些为他工作的工程师指定为“manager”，开始自称为“director”，还要大楼管理人员把他的办公隔间加宽一英尺。(当然，“director”没有实现，只是他的座位有了更多伸脚的余地。)
拥抱新技术的热望。对多数人来说，年龄越大越难学习。在商业世界里，人员越往公司的食物链高处走，越远离他们所建立的技术基础。这一部分是因为他们需要把精力集中于其他的经营和指导其下属的任务中。有时也是因为他们不幸地认为自己已不需要进行实践的技术工作了。互联网增加了技术变化的速度。不继续学习或跟着发展就无法做出商务与技术的决断。
从前的一个经理给我树立了如何对待新技术的榜样。我跟他工作的时候他年近六十，但他象新手一样地热心于学习新技术。他大量地获取信息，不断补充在网络服务器、防火墙、和Perl或Expect等新语言的知识。他还重视做QA或测试组织的工作。他的最初背景是软件开发和开发管理，但他并不认为做QA经理是在降低他的声望。他明白一个独立的测试或QA组所进行的完整测试能使开发经理的工作变得多简化。
