• QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде
    +1
    1. В разных командах по разному, 1 или 2 недели
    2. Все верно, не в конце каждого спринта
    3. Да, хорошее замечание, но у нас вовлеченность PO хорошая, и таких проблем сейчас обычно не возникает
    4. Фиксим сразу, и может сформироваться еще один спринт на доработки
    5. Гарантия — это тесты. Бывают баги с таким подходом, и даже критичные для функционала, но что это влияет на всю систему так она рухнет, это невозможно, потому что каждый мастер перед релизом проходит большие автоматизированные регрессионные проверки, где покрыт базовый функционал. Ну и до этого, при сборке, другие тесты это также контролируют
    6. А что вы имеете ввиду?
  • QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде
    0
    Реализация внутри нашего кода
  • QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде
    +2
    Крутой вопрос, и я соглашусь, что это упущение этой статьи.
    Этот процесс внедрялся в нескольких командах последовательно, мы пробовали, измеряли, и выводы учитывали в следующей команде. Было минимум 4 крупных эксперимента — 4 крупных функционала, где мы мерили: lead time, количество багов найденных в процессе разработки, количество багов найденных в фиче на проде, количество итераций разработки, NPS новой фичи. Был пример, когда одна и та же команда разрабатывала очень схожий функционал, при это не реиспользовала код предыдущей фичи, такое хорошее сравнение при прочих равных. И получилось так:
    Разработка по старому процессу:
    130 багов в общем
    13 — выпускалось с таким количеством багов
    После релиза заведено 15 багов
    Lead time ~ 6 month
    По новому процессу:
    26 багов в общем
    8 — выпускалось с таким количеством багов
    После релиза за 3 месяца заведено 7 багов:
    Lead time ~ 3 month
    ->Да, выглядит как некоторые дистиллированные результаты, но не на одном примере они были такими
  • QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде
    +1
    Отвечает, значит каждый знает об этом, и знает что за них это никто не сделает. Каким образом знает? Это вопрос сложнее, и тут надо сказать, что наши инструкции и формальности зачастую опаздывают, потому что мы изменения производим через эксперименты, и что-то начинает работать раньше, чем это «утверждается». Тут нам во многом помогает культура компании
    В случае с продактом этот глагол отсутствует, потому что у нас достаточно высока «власть» продакта и уровень его отвественности. Продакт в целом отвечает, за то, ЧТО делает команда, и с него спрос за это с разных сторон. Без описанной части связанной с качеством, продакт не может закрыть более глобальные вещи в нашей продуктовой компании. Это в какой то степени — само собой разумеющееся, в нашем случае
  • Достоверный нагрузочный тест с учётом непредвиденных нюансов
    0
    Спасибо за коммент! Мы вообще не сильно привязаны к инструменту в данный момент и планируем в ближайшее время сделать research, может быть выберем другой инструмент. Может быть gatling для более удобной работы с ws, а может быть и траффик генератор, рассмотрим IXIA и Spirent