软件中存在bug，只要及时发现并修复，也许还不是太糟糕。但是如果需求没有控制好，没有经过较为严谨的评审，如果后面等软件开发出来才发现其中的问题，那带来的后果可能是灾难性的。
经过软件工程学习的我们，也许都知道需求对于软件项目的重要性。但因为各种原因，这一块仍然做的不够。有让才入门的开发设计人员整理需求的，有干脆借着敏捷开发的幌子干脆不要需求的，也有脱离用户或者市场调查闭门造车的，这些需求从一开始就为后面的软件的失败埋下了深深的一坑。
做软件测试的，或多或少都会遇到需求问题。如需求中出现大量的不确定的描述，如增加某个列表功能，对具体的列表项，排序方式，分页等一概不知。又如某某字段长度约束为6～10，你说的是字符长度还是字节长度呢？
我们该怎么做需求呢？我认为第一点，需求必须来源于用户或者市场严谨的调查或分析。否则软件做的再好，没有人为之买单，那也是一个孤芳自赏的作品，不能称为产品。其次，软件是应由有着相当行业背景的人员进行整理，否则会出现各种潜在的，行业通用的需求被无意识的忽略了。再次，软件需求不是可以省略的东西，我们可以通过更敏捷的方式，如带标注的UI原型展现出来。最后，需求一定要经过评审，尽可能让各方，包括用户、市场、公司负责人、开发及测试负责人达成共识。这样整理出来的需求才是可测试，可开发实现的。
软件需求需不需要测试人员参与呢？这个也是必须的，大家都知道要保证软件的质量，非常重要的一点就是让测试人员尽早的参与。需求最为软件质量最为关键的一环，当然需要测试人员参与测试。具体怎么做呢，最好就是当需求人员整理好软件需求后，抄送给测试参与人员，让测试人员尽早的熟悉需求，同时尽早的发现需求中的问题，好在需求评审中通过问题的收集集中处理。这样避免了后面测试对于需求中的问题频繁的沟通，也尽早的发现了软件中的缺陷，既保证了软件的质量，也减少了后期开发成本。
深知测试理论很多，大家也很认同。往往在执行和实践中，往往一堆的道理都成了被一口否决的大道理。不管如何，我相信只要不放弃思考，思想行动上不停步，就会不断进步。