Как стать автором
Обновить

QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде

Блог компании MiroТестирование IT-системТестирование веб-сервисовТестирование мобильных приложенийУправление разработкой
Всего голосов 16: ↑16 и ↓0+16
Просмотры14K
Комментарии 14

Комментарии 14

Поэтому разработчики занимается ручным тестированием

Инновационно!

Спасибо, что поделились опытом.
Есть два вопроса по последней части. Что значит слово «отвечает» (дизайнер/разработчик и т.п.) и почему этот глагол отсутствует у продакт-менеджера?
Отвечает, значит каждый знает об этом, и знает что за них это никто не сделает. Каким образом знает? Это вопрос сложнее, и тут надо сказать, что наши инструкции и формальности зачастую опаздывают, потому что мы изменения производим через эксперименты, и что-то начинает работать раньше, чем это «утверждается». Тут нам во многом помогает культура компании
В случае с продактом этот глагол отсутствует, потому что у нас достаточно высока «власть» продакта и уровень его отвественности. Продакт в целом отвечает, за то, ЧТО делает команда, и с него спрос за это с разных сторон. Без описанной части связанной с качеством, продакт не может закрыть более глобальные вещи в нашей продуктовой компании. Это в какой то степени — само собой разумеющееся, в нашем случае
Понятно, спасибо.

Спасибо за статью! Однозначно полезная и схема в миро крутанская.


Есть вопросик:


В статье расскажу подробно о нашем процессе тестирования на каждом этапе создания новой фичи и о внедрённых изменениях, которые повысили качество и скорость разработки.

C помощью каких метрик вы оценили прирост скорости разработки и качества продукта? Не увидел в статье сравнения до-после. Было бы особенно интересно увидеть показатели и их динамику в промежуточных шагах перехода к новому процессу.

Крутой вопрос, и я соглашусь, что это упущение этой статьи.
Этот процесс внедрялся в нескольких командах последовательно, мы пробовали, измеряли, и выводы учитывали в следующей команде. Было минимум 4 крупных эксперимента — 4 крупных функционала, где мы мерили: lead time, количество багов найденных в процессе разработки, количество багов найденных в фиче на проде, количество итераций разработки, NPS новой фичи. Был пример, когда одна и та же команда разрабатывала очень схожий функционал, при это не реиспользовала код предыдущей фичи, такое хорошее сравнение при прочих равных. И получилось так:
Разработка по старому процессу:
130 багов в общем
13 — выпускалось с таким количеством багов
После релиза заведено 15 багов
Lead time ~ 6 month
По новому процессу:
26 багов в общем
8 — выпускалось с таким количеством багов
После релиза за 3 месяца заведено 7 багов:
Lead time ~ 3 month
->Да, выглядит как некоторые дистиллированные результаты, но не на одном примере они были такими

Спасибо за ответ!

Спасибо за статью, очень интересно.
Несколько вопросов.
1. Какой длительности у вас спринты?
2. Шаг 4 у вас возникает в конце каждого спринта? или только тогда когда фича полностью готова? те, например, если фича делается в течение 3 спринтов, то шаг 4 возникнет только в конце 3-го спринта?
3. Если шаг 4 возникает тогда когда готова фича, то не возникает ли проблем с тем, что если задача крупная, то PO довольно поздно проверит, что все реализовано так как он задумывал и вообще что то что он задумал — правильно? (по-моему опыту довольно много косяков еще на уровне постановки задачи PO и плохо, когда этот шаг откладывается)
4. Если на шаге 4 у вас PO видит какие-то улучшения/косяки, то что вы делаете? откладываете их на следующий спринт? или фиксите сразу?
5. Вы пишете, что по сути ручного тестирования нет. Разработчик знает, что за ним никто не перетестирует. Насколько вы уверены, что после выпуска очередного спринта система не рухнет? как вы добились этой уверенности?
6. Зачем вам вообще спринты? если у вас хорошо развиты инженерные практики — автотесты/фича флаги и тд, то может стоит переходить на непрерывную поставку?

1. В разных командах по разному, 1 или 2 недели
2. Все верно, не в конце каждого спринта
3. Да, хорошее замечание, но у нас вовлеченность PO хорошая, и таких проблем сейчас обычно не возникает
4. Фиксим сразу, и может сформироваться еще один спринт на доработки
5. Гарантия — это тесты. Бывают баги с таким подходом, и даже критичные для функционала, но что это влияет на всю систему так она рухнет, это невозможно, потому что каждый мастер перед релизом проходит большие автоматизированные регрессионные проверки, где покрыт базовый функционал. Ну и до этого, при сборке, другие тесты это также контролируют
6. А что вы имеете ввиду?
6. Я так понял, что у вас используются фича флаги + автотесты + скорее всего вы часто мержите в мастер и за счет качественных автотестов гарантируете, что мастер всегда в стабильном состоянии. Зачем вам итерации? просто релизьте мастер тогда когда это потребуется… или даже просто автоматически каждый день или вообще «непрерывно» после каждого мержа. В этом случае куча скрамовских ритуалов уходит за ненадобностью…
Очень крутая статья, спасибо большое.

Спасибо за статью. Подскажите а с помощью каких инструментов реализуется механизм фиче галочек?

Реализация внутри нашего кода
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.