真正的换位思考-我做测试人员的一天

      昨天一个偶然的机会，临时充当了下软件测试的角色，体会很深！也让我对软件测试人员有了更多了了解和理解，并对自己（开发者）也提高了要求。

      开发、测试不分家，心在一起，劲往一处用就可以大大改变产品的质量。这个道理大家谁都明白，但是我们是做到了60分，还是90分呢？这是值得我们深思的！

情景1：

      我拿到一个产品，让我测测，我首先根据自己的理解来测试这个产品，保证链接的正确，数据不敢保证，随着测试的逐渐深入，我发现，有些功能根本不知道是做什么用的。

感想：一个产品如果没有需求文档，就算有使用文档，那又有何意义呢？

情景2：

      我找到了需求文档，对里面的内容进行查看，多多少少还是帮助了我理解了这个产品的功能，但是好多页面展现，无从考究！例如一些展现的关系图，是根据什么绘出来的？箭头代表什么？等等等等！总之给我的感觉就是功能依照使用手册会用了，但是不知道是用来做什么的！顿时你会想到，这些都是什么做什么用的？为什么文档没有写清楚？难道还要我逐条写下来，依依的问？

感想：情景2做到了60分，因为有了需求文档，但是这份需求文档，有跟没有差别不大，主要是解决了有、无问题。对于根本性的问题还是没有解决。

          这时候想想我们自己做开发的时候，是不是以为这个很简单，我们组内都清楚，就没有写在需求里呢？现在想想，开发觉得自己明白的东西，往往别人是不明白的！看来以后写文档的时候，我们需要转换一个角度来写这个文档。逐渐达到70分！

情景3：

      找到开发问了这个功能，开发简述一遍，是简述哦！大体知道这个功能是干啥的了，也能看到展现，但是展现的对错与否，谁又知道呢？

感想：测试点很重要，我们的展现对错，是要考虑测试人员对这个系统的理解，如果我们能够在文档中，写清楚测试点，那么测试人员就会更有依据来判断展现的内容是否正确了，如果做到这点，我相信应该可以打80分了！

情景4：

      随着时间的推移，我烦躁了起来，感觉能用，不知道为什么用，每个功能都可用，但是如何串联在一起呢？看了产品的SPD，使用手册，没有对各个模块串联着用的一个概览，这让我和恼火，我当时心里只有一个想法，这咋测？没有需求评审吗？双方之前没沟通吗?

后来得知沟通过，需求是因为项目多，开发没时间，只是简略的说做了什么，没有说做到什么程度，什么效果！

感想：看来对需求的沟通事值得我们深思的，开会了、沟通了，依然没有解决问题。所以我觉得只要是会议，一定要双方达成一致，且一定要形成结论，不然那就是扯淡！话糙理不糙！就是这么个道理！



本以为这一天的时间是浪费了，其实不然，通过这一天的实际换位，真正的达到了换位思考的效果，理解了测试人员的苦衷，也了解了一些作为测试人员最需要的是什么样的文档，需要的是开发怎么的配合。同时自己身为开发人员的我，觉得在今后的开发中，一定要落实文档，积极配合测试人员！当然开发人员也有苦衷！但是我们需要先从自身找原因，解决掉自身问题，也许很多难题会迎刃而解也说不定呢？

注：一些感触，只对事，不对人。如有雷同纯属巧合！请勿对号入座！

楼主的认识我赞同，但是，实际执行时，每个人总会有私念，在开发的高强度，复杂，单调的环境下，开发人员总是会慢慢失去了曾经的认识！所以说，这个世界上最难的事情就是坚持！

测试人员如果换位来开发 不知道怎么样

看了之后，感触颇深，场景如此吻合

投你一个“良好”；
但是感觉文档也不一定就是解决这些问题的良药，或者说至少传统的文档形式不足以解决问题。
因为传统文档本身的维护成本很高、无法保证其完整性与正确性，而且传统文档不支持多人协作撰写，更加剧了这个矛盾——维护文档的工作出现瓶颈，
wiki是一个不错的方式，写用户手册还是不错的，但它在需求管理方面还不够强。

还有就是开发和测试人员如果能更紧密配合，会不会也能一定程度解决这些问题呢。
所谓紧密配合，是指像敏捷倡导的“全功能团队”那样，不要把开发和测试天然的区分的太清楚，
两者要坐在一起，经常讨论、沟通，而不是等开发好了再把信息转移给测试，那样会有很多“信号衰减”和“信号失真”。

这个问题有点意思，我想从事几年软件工作的娃应该都有点想法吧
LZ这种情况其实很普遍，一般一个公司测试人员比较少，并且同时要关注很多项目，所以对于每个项目的需求不会特别的明细，例如我目前所在公司，测试人员的测试用例都是根据开发提供的需求文档撰写的，开发测试一起评审过以后，就开测了.......所以需求文档、跟测试用例的review就比较重要了（否则后面测试提BUG能淹没了你，并且很多的BUG让你抓狂，因为那都是测试没有理解需求提的，等着老大找你吧）
但其实，我也有遇到过公司，项目需求阶段，测试就介入了，后续测试用例的确认啊什么的，就省心了很多，归根到底这还是一个成本的问题
另，每个人都跟我说，开发跟测试拧成一股绳才能保证软件质量，但其实，从工作的角度来看，开发跟测试其实是很对立的（BUG越多，他的工作越到位，绩效就好，对应的，就说明开发的工作有问题，绩效低），遇到那种让你很抓狂的测试不是所有人都能淡定的。还有，产品上线了，如果还有一些问题，大家都骂开发：开发做的啥烂玩意！没有人会说：测试咋测试的！产品设计咋设计的！程序猿真伤不起........

开发和测试其实是相辅相成的，没有什么真正的区别，没有对立的意思。如果一个公司将开发和测试的关系搞成对立的话（特别是以bug数来考核开发和测试的话），那么这个公司估计整天都要吵架了。
真正想产品好的话，我觉得有以下几点：
1. 开发测试真正做到多沟通，特别是从需求开始的时候就应该一起去评审需求文档，一起讨论项目的实施，包括如何开发，如何测试。
2. 尽量使用敏捷开发，及时发现问题，即使有些问题无法解决，但是也要知道有该问题的存在，另外，如果开发和测试在某个细节上真的出现理解不一致的话，那么就得找项目经理或者是产品经理或者是客户对该问题进行讨论，并定出解决方案。
3. 不要可以存在开发和测试人员的区别，都是一个项目的，尽量做到和谐。

当然，如果产品上线后出问题了，开放测试其实都有责任的。