sap miro_Miro的质量检查流程

sap miro

What do we do? We need to do preliminary preparation for each block of the development process: task decomposition, evaluation and planning, development itself, investigative testing, and release. This preparation does not consist of simply throwing old parts out of the process but of their adequate replacement, which increases quality.

我们做什么? 我们需要为开发过程的每个阶段做初步准备:任务分解,评估和计划,开发本身,调查性测试和发布。 这种准备工作不只是将旧零件扔掉,而是要进行适当的更换,以提高质量。

In this article, I will talk in detail about our testing process at each stage of creating a new feature and also about the introduced changes that have increased the quality and speed of development.

在本文中,我将详细讨论在创建新功能的每个阶段的测试过程,以及将提高开发质量和速度的引入的更改。

image

从瀑布到Scrum的过渡 (The transition from Waterfall to Scrum)

A few years ago, we realized that our development process, which was based on the classic waterfall model, needed to be adjusted to deliver value to users faster and more often. Scrum was great for this because it allowed us to end each sprint with an increment.

几年前,我们意识到基于经典瀑布模型的开发过程需要进行调整,以更快,更频繁地为用户提供价值。 Scrum对此非常有用,因为它允许我们以递增的方式结束每个sprint。

We introduced Scrum events and short iterations. Everything looked good in theory:

我们介绍了Scrum事件和短迭代。 理论上一切都看起来不错:

  • to make a release at the end of the week, we need to have the implemented functionality on Wednesday;

    要在本周结束时发布版本,我们需要在星期三拥有已实现的功能;
  • test it on Thursday;

    在星期四进行测试;
  • fix the bugs;

    修复错误;
  • roll it out to the production environment on Friday.

    在星期五将其发布到生产环境。

In reality, it turned out differently because we had not in fact changed the process but only put our waterfall inside a weekly sprint. As a result, the functionality was most often ready by Friday (not by Wednesday) because we could not correctly evaluate the tasks and because we were faced with new, higher priority tasks in the middle of a sprint. Testing was completely left out of the sprint process.

实际上,结果有所不同,因为我们实际上并未更改流程,而只是将瀑布放入每周的冲刺中。 结果,该功能通常在星期五(而不是星期三)准备就绪,因为我们无法正确评估任务,并且因为在冲刺过程中我们面临着更高优先级的新任务。 测试完全不在冲刺过程中。

Then we moved the preparation of acceptance scenarios to the beginning of a sprint. This immediately gave a result. Scenario preparation is approximately 60 percent of the testing time. Going through prepared scenarios is a quick process, and in addition, we learn about nonstandard cases before the start of development and can immediately take them into account in planning.

然后,我们将验收方案的准备工作移至冲刺的开始。 这立即产生了结果。 场景准备大约占测试时间的60%。 准备好场景是一个快速的过程,此外,我们在开发开始之前就了解了非标准案例,并可以在计划中立即将它们考虑在内。

质量检查流程的各个阶段 (Stages of the QA process)

开工会议,示例映射,验收方案 (Kick-off meeting, example mapping, acceptance scenarios)

Say a product manager gives the team a user story or a technical lead brings the technical story of a component’s development.

假设产品经理为团队提供了用户故事,或者技术主管带来了组件开发的技术故事。

The first thing you need to do is decompose the story. To do that

您需要做的第一件事就是分解故事。 要做到这一点

  • The team forms an understanding of the story’s requirements that is common for all participants, using, among other things, an exhaustive list of questions for the product manager. This also helps to find requirements that were not taken in

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值