测试之家
研发效能
如何拆解任务
社区
问答
招聘
社区学堂
新
开源项目
活动
Wiki
注册
登录
研发效能
如何拆解任务
刘晓光
·
2020年03月25日
· 最后由
刘晓光
回复于
2020年03月25日
· 3920 次阅读
目标: 把研发任务拆解为 “可测试” 的交付物。
如何理解 “可测试”?
摒弃 “可以做端到端的测试才叫可测试” 的观念。
接口可以测试
方法/函数可以测试
业务需求逻辑可以测试
拆分后,尽量提供可端到端测试的测试物。
这一点和上一点并不矛盾,因为早晚要做端到端的测试。
如何拆解?
做好排期
做好排期,是做好拆解的基础。
双周的排期是一个非常合适的排期工作的周期。
对自己团队的交付能力有比较清晰的认识(可以通过过去的迭代总结不断看清楚)
所有干系人参与排期(项目经理,需求,开发,测试,运营),不然对不齐。
留出一定的富余量。
在排期会上,对排期内的任务进行分解,测试和开发人员均应该在场,对任务进行评估。
做好可测性分析
一定要达成一个 “可测” 的协议。
尽可能的按照业务功能去拆解,而不是按照技术层次去拆解。
如果采用了"用户故事"的方法,按照用户故事去拆分
最好对应一个完整的功能。例如增、删、改、读功能同时具备。
基于功能的垂直式开发模式优先。
拆解的粒度:能够每天交付被测物,是非常理想的状态,如果做不到,可以先从拆解到 2~3 天做起。只要愿意花心思拆解,过一段时间以后,你就会发现,根本不难。
如果功能仍旧过大,不能拆成 2~3 天交付,可以拆解成 “半成品”,如一些接口,一些方法。
考虑架构和设计对任务拆分的影响
好的解耦设计才能拆开。反模式:大面积违反迪米特原则。正向案例:面向接口编程
如果联调的成本高,提前考虑 mock。mock 是基础设施,要投入精力建设。
如果可以低成本不 mock,则可以考虑不 mock,这项能力也应该投入精力建设。
架构应该是面向服务的(现代架构基本如此,不要乱搞就行)。
「原创声明:保留所有权利,禁止转载」
共收到
2
条回复
时间
点赞
打杂的大叔
#1
·
2020年03月25日
这更适合测试只参与一个项目的情况。。。
刘晓光
#2
·
2020年03月25日
Author
对
打杂的大叔
回复
并不是。适合研发自测承担起大部分质量工作的情况。QA 可以高度并行。
需要
登录
后方可回复, 如果你还没有账号请点击这里
注册
。
刘晓光
@skytraveler
7 个赞
共收到
2
条回复
有新回复!
点击这里立即载入