又被面试啦,简要答一下:
通用的思路:基于风险的测试。测试的本质是抽样,时间资源总是有限的。要把资源用在刀刃上。先看看那个模块是干嘛的,是不是重要,如果出问题,影响面有多大?然后具体问题具体分析。
如果是核心模块,会造成重大损失,那质量一定是不能丢的,抽调别的力量加强这块儿投入,把风险明确的传递给主要干系人,必要时延期项目。
如果是非关键模块,识别出问题,可以做:设定一个最小实现目标,砍 Feature,用运营/客服的手段补足。长效方法:自动化防护网建立,让回归的时间成本、人力投入成本低下来;
在项目的初期就要能够一定程度的识别这种风险,早加资源,别让这种事儿变成 —— 到了最后:一坨毛病,而 DeadLine 不变。QA 最大的一个价值就是:像探照灯一样很早的预期到风险,并同步给主要干系人。
其实这类问题,主要是看看你以前在项目里怎么做的。实战经验非常重要,能积累很多“土方法”。