其他分享
首页 > 其他分享> > 无需求文档,保障测试质量的可行性做法

无需求文档,保障测试质量的可行性做法

作者:互联网

这篇文章,主题是:无需求文档的情况下,作为一个测试人员,应该如何做 ,才能保障测试质量不出问题,以及如何不背锅 ?

001 没有需求文档3种可能情况 :

1、公司都没产品经理,开发人员的意识不足,收到的客户需求,直接开干(写需求文档 ?不可能的) 。
2、项目进度紧张,需求变动大,一直在变,产品偷懒,没更新原始需求文档 。
3、项目是从原有老项目上进行迭代开发,开发人员认为不需要需求文档 。

对于,如上情况,理论上的做法,如下 :

1、测试负责人,应该要坚持自己的原则:没需求文档,一律不接受测试
2、需求文档要进行评审,评审做会议记录,并有专门人员对需求文档进行修改、更新、确认;

但是,实际情况是 。

很多时候,如上理论,无法落地(当然,能落地更好,而且,也应该落地;此文,主要针对那些,无法落地需求文档持续更新的情况下的可行性建议) 。
1、测试团队,在公司,完全无话语权,想推动产品写需求,难 。
2、而且,很多时候,整个技术团队,都是服务于业务,时间紧、任务重,需要每个人多主动点 。所以,如上的理论情况,实际落地,难。

没有需求文档,对于编写测试用例来说,太难(保障最终上线质量,就更难了) 。

作为测试人员,在没有测试需求文档情况下,别傻乎乎的等着,应该主动点,尽可能去多了解项目的一些情况,多知道一点,对测试用例就能多写点。

002 无需求情况下,落地做法

如下,是IDO老徐 ,根据自己的经验,给的可行性做法,供参考 :
1、尽量去找找其他相关文档,如原始碎片需求会议讨论纪要、策划书、开发文档、市场调研书、可行性分析报告 等
2、尽可能多的参加内部讨论会议(需求、设计、计划 ),参加讨论过程,进一步理解需求
3、咨询相关人员:项目、市场、业务、研发、客户
4、如果是基于旧版本开发的,多去使用旧版本,自己摸索需求(也可以看看历史Bug库、用例库)
5、参考同行或竞争对手的类似产品(其实,产品经理,规划原始需求,也是类似方式参考的)6、最后,根据如上了解到的,梳理出你理解后的需求点,召集相关人员,碰一下(项目、开发、产品、市场、业务 等),查漏补缺,以及更正你的某些错误的需求理解 。
7、接下来的事,测试同学,都应该知道了:根据自己整理的,已确定的需求,去整理出一份评审过的测试需求点,最后进行测试用例设计。

总之,一个原则:没有需求文档的情况下,自己多主动,去了解,去梳理,去反向推动 。

003 很多时候,需求来自于客户

客户反馈给市场人员(或者 客服人员),公司内部无产品经理岗位,需求拿过来后,全凭自己的脑补,直接开干(这是小作坊,小团队,典型的玩法)。如果是需要客户回复的模糊需求,要么测试直接对接,要么把疑问点,梳理清楚,由市场人员对接(保持公司内部,原有的对外流程,最好别乱越级流程)。
至于方式,可以很灵活,比如(邮件、微信群 等,线下约见,也是可以的)。

004 对于质量保障,还有一些可行的做法

1、开发自测
2、产品提测后的需求还原度,让产品经理,加入,一起确认,一起验收 。
3、产品提测后的设计还原度,让设计师,加入,一起确认,一起验收 。

至于,如上,如何落地,这个得内部,把此项加入到常规的研发流程 。可以让质量Leader ,或者 研发Leader ,或者技术VP来推进 。这事,具备可行性,且可落地 。
有具体问题,留言,交流 。


这篇文章,老徐,给一些可行性做法 。如文章有用 ,留言让我知道 。

原创不易,所有持续分享、持续输出价值的,都值得敬佩 。

标签:需求,落地,可行性,测试,文档,产品
来源: https://blog.51cto.com/idotest/3036435