测试感悟 (2)-测试的定位
在上一篇中提到了不做保姆式的测试，那么如何从保姆式测试模式中脱离出来呢，在这篇感悟中，我根据自己的经验来浅谈一下这个问题的解决方案不同组织架构下的测试童鞋定位
我们测试自己的定位与周遭的环境有很大的关系，我先来梳理一下现在国内公司测试团队的组织架构，一般来说分为两种：
测试团队独立于开发团队
这样的团队模式我个人认为比较有利于测试童鞋自身的发展。测试本身就是独立于开发的一种岗位，他们之间的重点在于协作，而不是服务，在软件开发过程(包含了需求的对接和制定、设计方案的确定和代码的编写等)中测试其实在前期阶段(非集成测试阶段)我认为是所有角色中头脑最清晰的，他会敏锐的捕捉到软件开发中很多遗留的问题，这些问题造就的影响其实都会在最终的集成测试阶段爆发出来，而这些问题其他的角色会认可但不会去重视，例如开发缺少自测这个话题，无论什么时候拿着这个问题去找技术总监聊，他总是很认可，但不会为此技术债务买单。但是独立出来的测试团队看到这个问题就不会置之不理，在管理角度，他起码可以平起平坐去找技术负责人进行协作流程上的优化，在技术角度，团队可以去做一些工具，自测的工具、验收的工具等来推动软件开发中的问题越早的解决，我们姑且称这样的测试团队为优质土壤，因为它可以产出相对来说测试素质比较高的测试童鞋。
优质土壤团队中测试的定位
一般而言这样的组织架构是比较大的公司，测试团队都会给自己团队设定一些技术提升上的KPI，可以尝试去参与一些工具的开发辅助解决流程上出现的问题，如果没有这样的机会，在自己的工作中要多留意重复的工作，比如功能测试过程中每天都需要新建一个对象的工作，都可以考虑使用小工具自动化下来，来辅助自己的工作，提升工效；其实最重要的是在大公司里面这样的事情做的越多，在测试团队是很受待见的，晋升也会很快，因为它是鼓励提升技术能力的，它认为技术是解决一切问题的手段，所以一般而言，身处这样团队的小伙伴也是很有动力去自学很多东西，各种脚本开发，因为利益驱动一般来说是很有效的 😍
测试团队合并到开发团队，测试leader汇报给开发负责人
实话说，这样的组织架构其实是很糟糕的，不过如果你的开发负责人是有测试经验，或者是测试出身的话，他会在政策上支持测试团队在技术上有所发展，不然在很多时候他们会牺牲测试的利益来保全整体利益，造就了保姆式测试模式的形成，这个人是起到了至关重要的作用 😭 ，这样的团队土壤我们称为劣质土壤。
劣质土壤团队中测试的自我定位
一般而言这样的团队，不会把测试童鞋的技术提升作为团队的目标，他们需要的是服务好开发的测试团队，在这种团队中工作的小伙伴，找对自己的定位真的很重要，不要被整个环境牵着走，要认定自己不要单纯的做功能测试，做保姆测试。在功能测试之余，要尝试自我提升，学习一些脚本语言，写一些简单的脚本辅助自己的工作，其实可以多利用一些自己与开发的关系，多看看他们的工作，在自己的电脑上安装必要的IDE等开发工具，将被测试的代码clone到自己的本地，多看看开发写的工程，不懂的可以去问他们，这样可以让自己对代码越来越熟悉，不至于产生恐惧感，一般来说开发使用的语言，可以作为我们首选的学习语言对象，但是很悲催的是这样的事情你做了最大的好处是自身能力的提高，没有对等的利益奖励，所以很多小朋友很难坚持下去，而且这样的事情大部分是靠加班去做，自驱性需要很好哦。
最后这样的团队模式，对测试leader的要求其实也是很高的，他不仅仅要应酬软件开发的流程造就的各种弊端，说难听点是要给各种不同角色擦屁股以外，他其实还需要考虑自身团队的发展，有能力的测试leader会在忍辱负重的同时慢慢的积蓄团队成员的各种能量，去尝试推动软件流程的优化，改善自身所处的劣势环境。
写在最后
不管身处何种团队，找到自己的定位，而且这个定位一定要与自己的boss达成一致，你需要得到他的支持和鼓励，毕竟全公司最懂你的人应该是他了吧，其次一定要有很好的自驱性，利用时间管理(番茄时间管理)做好自己的学习规划，是走出保姆式测试的必经之路。
说的很好，我现在就不知道我处于哪一个阶段，对自己很迷茫，上一天班，一半时间是在做功能测试，另一半时间又在学习自动化脚本 :) 测试组织也是很关键的一部分 从技术上说，测试人员要更多的分析测试过程中最浪费时间的环节，争取把效率提上去。。。 互联网发展的时间够长 测试就会长
页:
[1]
