大家好，今天想分享几个工作中遇到的问题，而这些问题又暴露出很多新的问题，让我们一起想办法解决吧。因为我做过两年的测试，所以即便转岗后，对测试相关的事项也会经常关注，同时因为测试的工作经验为我后续的工作提供了很多帮助，而且我所在的团队，测试人员的价值也是远超功能测试本身，所以当遇到下面这个问题时，会有很多话想说。今天文章较长，但都是实战总结，请各位耐心阅读![]()
第一类：前段时间和一个做测试的朋友聊天，他向我吐槽测试这个岗位的尴尬境地，比如在团队内部话语权缺失，经常被开发“嫌弃”，提出的bug开发时常不愿意改，甚至背后被吐槽等，这些可能在测试工作中常见的问题。然后问我可不可以转岗需求或产品，转岗之后会不会好一些。
这些问题相信很多项目组或多或少都会遇到，原本2小时能完成的上线任务，愣是搞到后半夜。
这些问题在表象上可能都是一些细节问题，或者态度问题，就像我们上学时习惯说的“我马虎了，没仔细检查”。当年我也是这样安慰自己。
但现在来看，每一个小问题的背后都反映出团队管理、流程制度、工作意识或工作态度等方面的问题。如果要解决这些问题，只针对表象处理，不仅无法根治，还可能会暴露出其他的更严重的问题。所谓“治标不治本”，“扬汤止沸，不如釜底抽薪”。
我的解法和想法
比如第一个测试话语权和认可度的问题，我当时的回复如下：之后我在想，如果这件事发生在自己的团队要如何解决？大致有如下几个思路：项目负责人首先要有质量意识，如果一个团队自上都不注重测试与质量，那后面的结果一定是惨不忍睹。
同时项目负责人要提高团队每个人的质量意识，通过宣导、举例等客观的方式阐述交付质量的重要性，顺理成章的提升大家对测试工作的支持。这里我强调的是质量的重要性，而不是测试的重要性。因为质量很重要，所以我们需要测试人员协助我们达成高目标。这个因果关系是需要注意的。因为对于很多开发人员来说，可能对测试就是不重视，我们直接树立测试重要的理念，对方也许会不认可。但是质量的重要性相信每一位从业者都会认可，只是在日复一日的工作中逐渐遗忘罢了。
如果要解决上述问题，测试人员本身的能力提升一定是基础，否则其他方式都会适得其反。关于如何提升测试人员的综合能力，展开说会有很多方式方法，在此仅罗列几个关键点。相信大家都有自己的见解，希望我们能互通有无，共同探讨。还可以点击链接查看之前的一篇推文《如何提升测试阶段的工作效率》- 端正自己的态度，设立更高的目标。我看到很多测试人员竟然只把自己定位为“点点点”，没有更进一步的要求，无论从工作、团队还是职业发展上都是不可取的。无论在哪个团队、团队是否有问题，首先要做的是我们自己不能放弃进步；
- 提升沟通能力，讲究沟通方法和技巧。去年我和一位测试同事专门分享了关于“测试与开发和谐相处”的技巧，后续我会整理出来。其实很多情绪的爆发都是源于沟通及态度，所以技巧很重要；
- 提升自身业务能力。尤其是功能测试人员，对业务的理解能够在设计阶段为开发提供支持，在测试阶段对交付质量提供更合理的建议与保障。如果能够兼顾需求、或者协助需求，那证明业务能力已经获得团队的认可；
- 学会权衡和“抓大放小”。其实这一点有些偏向于沟通技巧，但是因为比较重要所以单独列出来。重要问题、原则问题要据理力争，但是有些不重要的，或者可以妥协的也要适度妥协，给足对方面子，照顾对方情绪；
- 对技术和软件工程有基础的了解。这样在平日的工作中才能够和开发平等沟通，不容易被开发踢皮球或者“忽悠”，而且能够协助自身准确定位问题；
- 提bug要全面、有理有据。如果能给出合理的修改建议或修改过程中需要注意的关联功能，那开发一定会另眼相待；
- 对项目现状足够了解，对业务的处理逻辑足够了解。因为功能测试中大部分的缺陷都是业务理解不透彻、逻辑处理不严谨引起的。有时提出一个很难被发现的bug也会引得大家竖大拇指。
- 其他的一些工作之外、工作之余的磨合、沟通。其实大部分开发人员都是很单纯的，所以有情绪就会表现出来，表现出来的情绪反而要比积压的情绪更容易解决，关键在于我们是否愿意多花心思来解决这些问题，从而让自己的工作更顺心呢？
项目负责人要细心、留心，比如当发现开发与测试针对工作有情绪时，及时纠偏或打圆场。或者作为支持者一起进行问题讨论与分析，对事不对人，客观解决问题。之后如果双方仍有情绪，还需要单独疏导。其实很多问题都是日积月累的，当我们在萌芽阶段就能注意并解决时，不仅团队会更加稳定，大家协同的效率也会更高。
尤其是当听到开发吐槽测试，或测试吐槽开发时，不要做和事佬，一定要重视这些细节性问题，客观及时解决。因为大多数人说出来5分不满，可能内心会有10分不满。千万不要因为听到5分不满，自认为只有3分不满，从而为后期留下隐患。
寻找一些团队内部的小契机，让测试人员“冒头”（此技巧同样适用于其他有类似诉求的岗位）。
比如新员工来了，可以安排测试人员为其讲解业务，或介绍团队、现状等等。我相信这会是一个很有效的办法，让测试在新员工（尤其是开发人员）这里有更好的印象。而且后续的一些疑问都会向测试人员请教，那之后再沟通缺陷时，就会更加容易认同。基于这个角度，可以再看看团队中还有哪些可以提供的机会，让他们逐渐承接下来。
比如加强测试用例评审过程，在评审用例时需要对应模块的开发人员一同参加，这样开发会知道自己要做的功能需要考虑哪些异常情况，在提升开发质量的同时，也能对测试人员思维的全面性产生认可。
比如测试人员参与设计评审，在设计评审过程中，针对功能的实现逻辑，测试人员也可以在会上提出自己的想法。在前期针对一些可能产生分歧的内容达成一致，从而减少后续的争执。尤其测试人员作为对系统现状最了解的人，在更新迭代过程中的很多建议，或者风险预知都是非常重要的，当我们能为开发或其他岗位提供帮助时，认可度自然会提升。
所以我们可以发现，虽然是解决测试的问题，但只有第二条和测试人员自身相关，其他的方法都需要领导、团队、制度来配合。这就是我想表达的方法2为治标，方法1-5为治本。读到一半，点个关注![]()
![]()
当然，现在的测试领域，很多测试人员尤其是功能测试人员在能力上确实有差距，尤其是很多半路转行的人，选择测试是因为门槛低，工作过程中也没有确立持续进阶的目标，因此无法真正为团队赋予更多的价值，也使得大家对测试产生很多无谓的认知。这些现实情况确实让人无力。
最后，我把这件事分享给了一位很有经验的项目经理，他的回复如下：![]()
其实测试本是非常重要的岗位与角色，或者说每一个岗位都是非常重要的，做好了还能在其他层面发光发热。所谓“XX岗不重要”之类的行业现状也在逐渐纠正，过程很漫长，不仅需要领导层提高意识、建立规范，更需要每位人员找到更好的进阶方法，付出更多的努力，同时主动寻求解决而不是被动或等待、或抱怨，相信坚持的力量，逐渐展现岗位及自身的价值，才能让大家更加坚定，更加认可。
关于第二类问题，所有的现象都指向了管理制度不规范，人员风险意识不够强，负责人对制度规范的执行力不足。
其实会有很多人没有真正重视这些，尤其是在工作压力较大，加班较频繁的时候，大家都在忙着工作、忙着解决突发性问题，没有重视和推进相关管理规范的执行。最终造成我们后期会花费更多的精力来解决前期产生的隐患，从而形成恶性循环。“紧急性的暴政”引发了优先权稀释综合症，优先权稀释导致我们忽略了重要不紧急的事情
我们正是这种总在处理紧急的事情，而忽略了重要的事情。
因为我本身项目管理经验并不丰富，很多经验也是在项目组和平时的交流复盘中总结的，所以不展开讨论，以免显得“教条化、理论化”。但是我始终坚信，忙不能成为持续不做改进的借口，我们切勿变成“长期救火队员”。每次总结大家都在说流程不规范，要加强各类评审、设计、风险排查、制度等等，但是真正到了执行层面，又有多少人能真正坚持呢？
比如：大家都知道设计评审很重要，设计完成评审通过再进行开发，但是真的项目进度很紧张时，还有人认真做设计、评设计吗？其实回头来看，很多后期的缺陷、风险又消耗了团队10分的精力，我们提前拿出3分来时间提前设计好，真的不可以吗？像代码评审、走查可能需要花费较多的时间，但是我们在解决bug时，或者排查一些疑难杂症时，顺手把对应的重点内容走查一遍是否可行呢？做一点、总比不做有效果吧。
而且这些评审不一定是要组织会议，占用大家的时间来进行。现在远程协同越来越规范，我们通过协作文档做好登记与同步，相关人员根据自己的时间进行安排，也是一种可尝试的方法，只不过对负责人的跟踪、执行能力又是一个新的考验。团队内其他人员风险意识不够强，是否也需要采取一定措施来提高呢？负责人没有精力跟进的事项，是否可以从中选出可培养的人，借此机会给予锻炼呢？同理作为想要更进一步、快速成长的小伙伴，是否可以主动请缨承担更多的责任呢？一个拥有良好战斗力的团队，一定是大家相互认同、相互扶持，目标一致又充满能量。
还有很多其他常见的问题
工作交接不清楚，尤其是连续交接的情况（张三交接给李四，李四刚接手又交接给王五），没有规范的产出，信息同步不及时、不完整；
文档编写不规范。这里的文档泛指项目管理过程中各个阶段的文档，尤其是非需求阶段，由技术人员编写的文档，从格式到内容再到排版、用词，无法体现团队的专业性；
诸如此类的问题，单独来看都是小问题，但联合起来就是大问题，同时反映出管理上更大的问题。
理想很丰满，现实很骨感，在我们解决这些问题时，虽然能想出很多方法，但在执行过程中势必会困难重重，还极有可能被一些“不可抗因素”耽误或者搁置。但是不能将这些问题视而不见不去着手处理，因为一旦此刻躺平，那后面等待你的可能会是暴风骤雨。
愿我们每个人都有精力、有能力、有意愿做一个更优制度的创造者；ps：后续将单独整理产品工作中常见的问题及应对方式，比如优先级排期总被变化、研发资源无法倾斜、交付周期紧张、功能设计不全面等等。敬请关注![]()