发表于: 2017-12-14 23:07:01
2 978
QA要有以下三大能力:
专业:你必须有项目的开发和管理经验,以及知识,这样你才清楚项目当前所处阶段、状态,分析出项目可能存在的问题和风险,不然你永远被项目经理牵着鼻子走。
沟通:QA的终极目的是根据项目实施过程,判断并发现项目潜在的风险,而你要将让项目经理接受你的建议,必须有良好的沟通表达能力,不然你和项目组永远处在冲突中。
客观:QA是公司研发制度的执法者,必须客观、公正的评价项目的状态,分析发现的问题和风险。
简而言之,QA要警察的客观公正,教师的平易近人,和医生的洞察力。
敏捷测试:
1、强调从客户的角度,即是从使用系统的用户的角度,来测试系统。
2、重点关注持续迭代的测试新开发的功能,而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试,一旦系统某个层面可测,比如提供了模块功能,就要开始模块层面的单元测试,同时随着测试深入,持续进行回归测试保证之前测试过内容的正确性。
然后在说一下什么人不适合敏捷QA:
不爱说话?别做敏捷QA了
如果你之前是安安静静专心找软件缺陷的工作模式,那么进入敏捷团队你可能会经历很长时间的不适应。
因为敏捷QA不能被动地等待软件完成交到你手里再做测试,不能发现缺陷后不管不顾等着开发人员自发地去修复。你需要从软件的源头开始介入,在软件的整个生命周期中全程参与。
敏捷软件开发强调质量内建,在用户故事的生命周期中,作为质量保障的主要负责人,你需要在每个阶段跟不同的角色反复确认和验证,确保团队对需求理解一致,还要保证跟质量相关的活动发生。
比如确保开发人员添加了相关的自动化测试等,所以你需要和团队的每一个成员以及客户有非常多的交流,而最直接有效的方式就是说话,沉默寡言是行不通的。
所以,如果你不喜欢说话,那么Tester也许比敏捷QA更适合你
心态不好?趁早放弃(aaa~其实我心态也很脆弱)
不知道你是否经历过这样的场景,在某些小餐厅等位严重的情况下,你需要站在某个快要结束用餐的客人边上等空位,而有些人却可以在用餐结束后无视旁边焦急等待的人群一直占着座位专注地聊天。
虽然这种行为不是很好但也无可厚非,换个角度想,这种人的心理是非常强大的,因为很少有人能够不顾及别人而我行我素。而这种“能力”对敏捷QA是非常有用的。
比如在故事验收环节,这个阶段就是业务分析师、开发人员和QA三种角色一起在开发人员的机器上验证用户故事是否被正确地实现。当然任何角色都可以主导这个环节,但效果最好的是由QA来主导,因为可以提前发现缺陷并快速修复。
但是因为这个阶段所有角色都会参与,大家关注点又有所不同,所以心态不好难免就会有各种顾虑,比如,自己会不会太慢了?会不会耽误太多人的时间了?别人会不会很着急?
太多顾虑就会影响你做验收测试,尤其验收阶段的探索性测试。从而使你不能充分发挥QA的作用,而这个环节对于敏捷开发模式下的质量保障来说非常重要,这时候如果具备前面提到的强大的心理素质,就能专注地按照你的想法测试你的场景,当然可以配合一些解释让别的角色了解你的思路,而不是左顾右盼思前想后影响这个阶段的发挥。
所以,如果没有强大的心理素质,也许应该考虑趁早放弃做敏捷QA。
对业务、代码没兴趣?敏捷QA不适合你
相信很多人进入测试这个行业,是因为对测试领域的技术和方法论有浓厚的兴趣,但是对于敏捷QA来说,仅仅对测试感兴趣是不够的。
敏捷QA需要对整个系统以及业务足够熟悉,这样才能从QA的视角帮助业务分析师和团队发现业务不合理或者缺失的部分(可以在故事审查或者启动阶段帮团队澄清需求)。
另外如果可以具备一些编码能力,对于做敏捷QA也是非常有帮助的。当然,术业有专攻,并不要求每个QA都会写代码,但是要对代码有一定的兴趣,愿意听开发人员讲解他们的逻辑和实现,并通过提问题了解他们的思路,至少了解他们编写的测试代码。
因为在验收阶段,敏捷QA会通过审查开发人员的自动化测试是否合理和全面,来帮助团队建立对自动化的信心。
如果对业务、代码没有丝毫兴趣,那么也许敏捷QA不太适合你。
然后然后,其实想做就不存在合不合适,只有努不努力
评论