这是一个残酷的世界,无论我们多么努力,结果可能还是不如意。这一点,软件人深有体会,不管我们多么认真地编码,多么仔细地测试,仍然无法抵挡Bug顽强地冒出来。
如果Bug被发布出去了,谁将为此背锅负责?
谁失职谁负责! --开发说
测试团队的职责就是测试,保证软件产品质量,如果产品的bug没有被及时发现,给用户造成了损失,这就是测试工作没有做到位,理应为结果负责。
Bug是我写的吗? --测试问
测试角色的职责是测试,但是软件产品的设计实现并不是由测试团队负责的,Bug的出现,最根本的原因是软件本身的设计和实现出了问题,测试不应该为此负主要责任。
如果丢球就是守门员的错,那么, 奥利弗-卡恩以门将身份获得2002年世界杯金球奖,是因为他没有丢过球吗?!
如果我的代码没有Bug,那要测试做什么呢? --开发问。
我们总是对自己做的东西有着迷之自信,但是,人总有考虑不周的时候,有犯错的时候,有脑子进水的时候,我们深知这一点,所以,才需要专门的测试角色,以独立的眼光审视和检查,发现我们没有察觉的问题。
我们是最后一环,不是唯一一环 --测试说。
正如开发过程会出Bug,测试过程也会出”Bug“。测试工作中的”Bug“之一,就是未能及时发现软件产品的Bug,使产品缺陷直接影响到了用户。
软件研发是一个系统工程,大家的职责分工有侧重点,但是参与其中的每一个角色都应该为项目负责。守门员无疑是把守球门的最后一道闸,但在最后的防线之前,还有10人!如果前锋软脚蟹,中场闲庭信步,后腰用目光防守,在球门线上供上布冯也无济于事啊。
测试不就是鼠标点点点嘛,这也做不好? --开发说。
开发是软件研发的核心团队,是真正实现客户需求的力量,我们开发人员要懂编程语言,懂面向对象,懂前端后端,懂消息队列,懂数据库,懂业务逻辑,懂颈椎病的防治。。。你们测试只要用鼠标在UI上点点点就可以了,这么简单的事情也做不好?
雷声阵阵,大战在即。双方都充满怨气,这么聊下去,免不了刀光剑影。这是在现实中经常出现的情况,对此,我想对测试团队给出几点建议。
1
怼回!
如果说测试的工作就是用鼠标点点点,开发的工作不也就是用键盘敲敲敲嘛,你们自己也是一身绿毛,有什么资格说我是妖怪?
所以,更重要的,是到底用键盘敲下了什么,用鼠标点击验证了什么。大家都可以往纸上涂墨,但不是所有人都是书法家。
2
反思!
但是,我们必须清醒地认识到,怼回去只是为了不堵心,逞口舌之快并不能解决问题。
凭心而论,开发的工作比测试更重要,这是事实。我见过很多中小软件公司没有专职的测试职位,但是我还没有见过哪家开发的工作是其他角色兼任的。事实上,很多测试工程师确实技术水平不够高,这让测试工作的质量和效率徘徊在一个低位水平,也让测试在与开发的冲突中屡处下风,相当被动。
所以,测试工程师需要拿出行动来,改变这种局面。
3
行动!
身为测试工程师,我们先扪心自问:我们做测试,是因为技术水平不如开发,做不了开发工作,只能做测试么?
不得不承认,很多情况下是这样的!虽然也有很多情况是个人选择,守城的并不一定弱,也可以是因为愿意守城、擅长守城,
但是,即使最开始是因为“被选择”做的测试工作,开始了鼠标“点点点”的软件测试职业生涯,我们也应该着力突破,除了提高测试设计等能力之外,我们还应该尝试学习自动化测试。
理由非常简单:软件是用代码来解决现实世界的问题,作为软件从业人员,我们用代码来解决自己工作中的问题,不是自然而然的思路吗?作为先锋队,开发已经拿着代码的加特林在突突突了,作为后防,测试还拿着木棒守城?
是时候了,扔掉木棒捡起枪,从这本书开始!
这本书,是关于软件自动化测试,但是它不会直接给出“正确”的终极解决方案(我自己也没有),而是演示如何从基础出发,发现问题,探索方向,解决问题,迭代和改进方案,重点在“渔”,而不在“鱼”。这是软件测试的应有思路。
本书的内容按难易程度组织成入门、进阶和高阶三个层级,内容设计前后衔接,互相呼应,读者可以清晰地看到细节打磨的过程。不同技术水平的读者,都可以在相应的层级看到精心设计的内容和范例,可行的工程实践,以及上升到更高层级需要的技能和思考方向。
戳这里,买一本码农徐西宁的新书:
《软件自动化测试实战解析-基于Python3编程语言》
友情提示:出版社特别提供了额外的粉丝限时福利(2021年8月有效),有更多优惠哦:
* 本书的范例代码提供免费下载, 请关注公众号,发送消息“代码”,即可得到下载地址 *