本故事纯属虚构，如有雷同，纯属巧合
今天是大毛入职的第一天。
糊里糊涂的办完入职手续，装好系统和软件，连水都没喝上一口，领导的邮件就来了。
“新员工须知的技术文档放在……，我需要你今天执行完这些测试用例，它们放在……，执行完了把结果写成邮件汇报给我，今天下午5点之前完成。”
啥是测试我都没完全搞清楚呢。大毛叹了口气，该干嘛干嘛去了。
问东问西弄明白了流程，大毛如同机器人一样执行了近500个测试用例之后，总算在时限之前完成第一天的任务，禁不住想，“今后的每天都将如此吗？”
大毛之所以成为测试人员，完全是因为得到了一个面试评价：计算机技术尚可，编程一般，算法不太熟，不如去看看测试行不行吧。
想起就有气，难不成测试是个垃圾篮，残次品都往里放来着？
一个星期之后大毛更来气了，测试用例设计得并不合理，浪费了他不少时间。周五找领导谈话的时候大毛抱怨了一通。
领导仿佛看出了他的心思，说，
“作为新人，进入角色比完成任务更重要。”
大毛一呆，刚想说话，领导先一步发问，
“如果你来设计测试用例，你会怎样设计呢？”
大毛又是一呆，他来谈话之前并没有考虑到这个。
一个星期之后，大毛又找领导，这次他滔滔不绝的说哪些地方设计得不合理，怎样设计会更好。
领导笑了一下，问道，
“你是通过什么途径发现这些地方设计得不合理的呢？”
大毛想，这不是废话吗，我对着这堆测试用例郁闷了俩星期呢。
还没回答，领导就替他回答了。
“你亲身体验了执行测试用例的过程并了解其中的问题，所以你能发现解决的办法。”
“对。”
“那么这种经验比起执行500个测试用例的任务来说，哪个更有价值？”
大毛陷入了沉思，领导拍拍他的肩膀，
“亏不能白吃，也不能让同事吃。”
又一个星期之后，大毛给领导递交了一份完整的报告。
“编号……的测试用例可以合并，准备和清理环境的工作是一致的；
“编号……的测试用例的目的相互交叉且重合，应该分离成独立的类别；
“编号……的测试用例使用过于复杂的数据，其实可以用简单且等效的数据；
“编号……的测试用例不需要这么频繁的执行，完全可以两个月才执行一次；
“编号……的测试用例压根就设计错了，不通过的时候其实不是缺陷……”
领导看完给大毛拟了个邮件的草稿，让他把这个报告发给整个测试团队，然后跟他说，
“以后你就维护这500个测试用例吧，有什么增删改归你负责，不用你来执行了。”
作者注：哪怕是微软，也有测试正式员工设计了测试用例之后从来没有亲自执行过的。现任Windows部门总裁的Steven Sinofsky有句话，没想清楚就开始写代码是犯罪，意思是垃圾代码不写出来还好，写出来还要编译、测试、维护，最后要扔掉的时候作者还跳出来百般阻拦，浪费的却是别人的时间金钱，不是犯罪是什么。同样的，设计垃圾测试用例，自己不执行却让执行的人去承受后果，同样是犯罪。
