正式入职软件测试这行有5年了，接触了很多项目和开发人员。这些项目包含跨平台迁移、原有平台更新迭代及新类型需求开发等类型。这些开发人员中有高级开发人员，也有初入职的实习生，针对不同类型的开发人员有着因人而异的沟通方式。
跨平台迁移项目仅仅依据需求文档是不够的，还需要在原有平台熟悉业务功能点，再结合需求文档更好的把握待迁移系统的核心功能。新平台的开发有难度是肯定的，初期提交给测试人员的成果物质量很糟糕，有时候提交测试的流程根本跑不通，测试人员原本做好大展身手的准备，却被这无情的现状打击到，这时焦虑情绪就会产生。随着开发人员对新平台越来越熟悉和前期提出的bug不断的得到解决，新平台新系统的功能也越来越完善。
测试人员在顺畅测试的过程中就可以进行探索性测试，发现更多隐含的bug。一个新平台的新系统从无到有，从有很多问题，到慢慢的得到内部人员和客户的认可，作为一名测试人员，从开始测试新系统到新系统的交付，感觉像是养了一个孩子，从他呱呱坠地直到能够独立生活。这个过程真的很难。
原有平台更新迭代的项目一般是比较小的改造，但是有更新迭代频繁的特征。这类项目不但要保证新改造的功能点正常，还要顾及是否会影响历史文件。相对于跨平台迁移的项目，原有平台更新迭代的项目测试难度较小，容易出问题的地方一般是历史文件测试遗漏。
新类型需求开发项目往往是比较具有挑战性的，从需求文档分析开始，测试人员就需要介入，开始对需求进行测试。尽早将自己对需求有疑问的地方抛出来，与项目组成员一起讨论，将需求功能点明确化。测试人员根据明确化的需求文档编写测试用例，用例编写完成后，由项目组成员进行用例评审，这个过程很重要，在用例评审的过程中，会发现一些开发人员或测试人员漏想的地方。开发人员需要完善开发功能列表，测试人员则需要完善测试用例。
随着项目的进行，项目组成员讨论的次数越多，需求的功能点会越明朗。测试人员最终按照明朗的功能列表进行测试。新类型需求开发项目，测试人员每个阶段都要参与，针对测试人员和开发人员一对多的情况，开发人员只需要负责分配给自己的功能模块开发，测试人员则要掌控整个需求和整个系统，所以新类型需求开发项目的测试工作很锻炼测试人员的综合能力。
接触到的开发人员中，有的是有大局观的，考虑的比较全面，遇到这类开发人员是测试人员的幸运，跟有职业素养的开发人员打交道，沟通起来很愉快。有的开发人员则缺乏主观能动性，需要测试人员在后面催着、赶着才能解决bug，针对这类开发人员，就需要测试人员推一把，多和开发人员沟通。
还有一种开发人员是刚入职的实习生，提交的测试成果物问题很多，有时同样的错误犯好几次，作为测试人员会很恼火，这种情况下该“怼”就要“怼”一下，但要跟这类开发人员沟通说明是对事不对人，本意是希望他们能成长。事实证明，适当的“怼一怼”还是很有效的，看到实习生真的成长起来的时候，作为一名测试人员还是很欣慰的！
不同的开发人员对待bug有着不同的态度，作为测试人员也要有不同的沟通方式。有的开发人员脾气比较倔，测试人员说他开发的功能有bug就会不高兴，举个沟通过程例子如下：
我：XX，你提交的XXX功能测试完了，发现了N个bug，都记录到禅道了，你登录禅道看下吧！
开发人员：我看一下
(过了一会，开发人员走到我工位旁，表情是很生气的样子)
开发人员：你提的XXX问题也不是bug啊，需求没有提到啊，对吧！
我：这个属于易用性问题，需求虽然没明确提出，但是从客户的角度，你做成这样，用户感知不好啊！
开发人员：那我的功能是好使的吧，对吧！
(此时的我必须坚持原则)
我：功能是好使，但是易用性问题也是问题，是问题我就得出来！
以前遇到这种情况，遭到开发人员的质疑和不解时，自己内心波动会很大，有时候会觉得委屈而哭泣，还好有同组测试人员小伙伴的鼓励和安慰，自己的内心也越来越强大，可以比较从容的面对这些有脾气的开发人员。当发现以柔不能克刚时，必选换个方式，你刚我也刚！对于那些开发人员不认可，不予解决的问题，可以整理后最终由项目经理决定是否需要立即处理还是延期处理。
有的开发人员，提交测试的成果物问题很多，但是对待bug的态度很好，举个沟通过程例子如下：
我：XX，你提交的XXX功能测试完了，发现了好多bug，都记录到禅道了，你登录禅道看下吧！
开发人员：好的，我去看看都有哪些问题！
(过了一段时间，开发人员把提出bug都解决完了，笑眯眯的走到我的工位前)
开发人员：你提的bug我都解决完了，你抽空复测下吧！
我：好的！
这种情况的沟通气氛就比较融洽，你柔我也柔!
最后希望测试行业的小伙伴在工作中都能找到适合的沟通方式！
扫一扫
2180
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
