测试任务的多样性、组织人员流动以及人员技能备份、测试工作节奏等因素决定了一个测试人员不可能一直做着自己熟悉领域内的测试工作任务。一个测试人员需要经常性的接手完成你不太熟悉领域、不擅长的测试任务，如何在任务要求的截止时间内有质量的完成是一个硬实力和软实力结合的技术活。我也饱受此折磨，所以想聊下这个话题。算是吐槽吧。
通常来说，大部分任务到某个测试人员身上都是任务驱动的。可能当测试任务来的时候，熟悉该项测试工作的A同学正在投入某项紧急任务中无法投入，领导自然就会将这个测试工作安排到不熟悉或者完全不懂的B同学身上。你说B同学可以以自己不熟悉该任务拒绝吗？拒绝是不太可能的。测试工作中有太多类似的测试任务了。每个人都拒绝，活就没法干了。每个人都永远干自己熟悉的测试任务，人员技能也无法备份。。这些因素是后话不讨论。通常来说，这种不太擅长的任务你还是得接手，不仅要接手，也不要有太多的情绪，别活还得干还让领导觉得你挑肥拣瘦就得不偿失了。想办法怎么在规定时间内保证质量完成是你要考虑的问题。有事别怕事，下来想辙就是了。。心情很重要。
一个不擅长的任务接了又得把它干好，这是个技术活。这时候每个人处理的方式就不一样了。首先，接收测试任务的时候一定要先了解清楚任务的背景、任务完成时间、任务相关责任人。我就以我自己和身边所看到的同事举一两个例子。从我自己来说，这种任务没啥毛病，但是我不喜欢那种要求时间很短又很不擅长的测试任务。一个是本来就不熟悉风险无法评估、质量不可控，第二个时间紧急压力大容易出问题。但是通常这些都不是理由，还是得去完成并且保证不出问题。
好，开始干活。在了解清楚任务的背景、任务完成时间、任务相关责任人，下来就需要了解测试任务本身内容了。只有了解了测试内容，你才能相对合理评估测试工作量、识别测试风险、哪些需要提前求助、是否需要提前上升。我的方法是比较喜欢自己先琢磨这些这些测试内容，去找资料学习，在基本了解测试内容之后再去找之前熟悉这一块的内容去把风险点搞清楚。我习惯这种做法但是这种做法其实在有限的时间下是不合理的。因为没有那么多的时间允许你去慢慢了解。这样有一个明显问题，就是让上面感知你的工作进展很慢，实际上应该是拉着之前搞过这一块内容同事给你讲解这一方面的内容。事后发现这确实是一个有效的办法，但是我并不是很习惯动不动就拉着别人去给你讲上半天这种东西，在当前工作强度下，每个人的工作节奏都很快，占用了这半天时间也就意味着别人最近又得加班了。。可能是我自己想多了。但经常碍于deadline，又只能强拉。。所以这是我不喜欢的原因。但是我看到同事的方法就和我相对反着，他的习惯是先直接拉着别人对任务。让别人讲解也一样能把事情搞定下去。我不太喜欢这样的方式，所以部分时候有限时间下做这些不擅长的测试任务是你逆着自己的习惯在做，有时候也会心烦这些事情。
既然知道问题所在，任务要做也要让自己心情保持好一点。不然会经常感觉在受苦。。太苦逼了。需要改变一下自己。从个人层面来说，需要自己基本过一下测试内容，然后在规定时间内（比如不超过30分钟）让之前搞过的同事讲解一下重点、可能的风险点、之前遇到哪些问题需要提前去问、去了解的。这样基本框架就有了。下来就自己好好了解一下内容，有风险的提前上报、有疑问点的记录后面集中拉一下释疑。另外，每天及时反馈进展、反馈阻塞点、风险点，让领导知道情况。另外，从组织层面来说，如果是一个后期较长的测试任务或者外地出差的测试任务（比如半个月一个月），需要安排好测试任务相关责任人，明确问题接口责任主体和职责，遇到问题可以让测试人员及时找到求助对象，及时推动问题解决。不然所有问题让测试人员都自己临时去协调，可能找不到也可能找到了别人没时间支撑拒绝。会让测试人员很心累，次数多了，就容易出现人员稳定性问题。
另外，测试任务完成后，自己一定要注意测试经验积累，多写一些经验文档，包括环境操作、问题FAQ、测试技巧、业务逻辑、测试问题以及解决方案等等。不要觉得不重要，一个很小的问题FAQ可能就会导致后续的人阻塞很长时间。重视这些经验文档积累，对自己、对组织都是一个很重要的财富。想想自己这么痛苦搞着这件事，后续同事继续搞这些事情的时候使用这些文档就可以起到助力作用。
对我自己来说，我一般还是比较习惯针对自己不熟悉的领域、技术点写一些经验文档共享，这样起码可以保证在完成一件不擅长的任务后，有一点经验积累。下一次就相对擅长了，也可以帮助到下一个干这任务的同事。如果是你，你在领导分配给你不擅长的测试任务时候会有什么想法？有什么好的经验可以分享的可以聊聊。建议别轻易拒绝。。