创业不易,我也无意泼冷水。
至于拒绝缺陷,tapd 的处理方式是这样:
支持根据解决方法检索或统计缺陷。
中间还有哪些想抽取出来拆成不同的状态呢?
新改的那张图上还是有很明显的 bug,为了产品形象建议再看看。
最后的建议是想清楚到底是管理敏捷开发过程还是只管测试,目标用户是哪一类,他们的痛点在哪,现在定义的流程适合他们吗。
感觉你的回复暴露了更多的测试管理方面的问题,缺陷常见状态就下面这些,目前看足够覆盖所有的业务场景。
已改未确认跟已修复或者已解决有什么区别?非错未确认跟已拒绝又有什么区别?
换个表述意味着客户得重新接受一次概念,这里的风险产品经理要不要考虑?
已改/同步到测试环境这状态是想解决什么问题,测试工作产出不是针对指定版本、指定环境吗,这样是不是带来测试管理的混乱。
最后说下那张图的毛病,
1、测试任务与项目测试是通过什么维度并列展示在一起的
2、项目研发下面为什么放的是测试任务
3、如果说每一栏最上面一行想表示项目生命周期的各个阶段,缺陷跟踪怎么又和测试执行并列了
4、需求部分为什么不在敏捷测试的测试迭代里
5、需求管理下面怎么列的是维护测试模块?
1、作为产品不在细分市场寻求突破,追求全面,就有可能因为某一项赶不上别家而被全盘放弃。
2、太多的度量指标,给人的感觉是产品方自己在测试领域没有沉淀,所以就把能透出的指标都透出来,让用户自己进行选择。
3、某些概念没有采用通用标准来描述,比如缺陷状态的已改未确认,非错未确认,不太明白开发者是不知道怎么描述还是刻意寻求差异化。
4、敏捷测试管理那张图逻辑性也有待商榷,参考https://www.cnblogs.com/linkxu1989/p/6673087.html,不是说老外总结得就一定好,但现有的这张图说服不了我个人。
看看是不是请求头的设置导致返回内容不一致了
只要业务还在,你留下就是老大
吾之美食,汝之鸩毒
挺有意思,先试用下
如果研发团队已经很牛逼了,就根据团队安排的来做
如果研发团队不行,你很牛逼就搭框架,定流程,定标准,卡准入准出
如果研发团队不行,你也不太会就忘了这事
感谢分享,顺便挑个刺,
8 小时了没人回,非特殊性的问题百度,google 一下不是快得多么