Разрабы vs. Тестеры
Вот мы делаем продукт. Все понимают: «Надо делать качественно».
Прикол в том, что это в этой фразе слово «качественно» — абстрактное понятие, которое каждый понимает по-своему.
Нипанятна. От меня вот фичу требуют, пойду лучше её запилю.
Ок, давайте наймём отдел QA. Пусть обеспечивают это самое качество. Им виднее, что это такое. На вход им дадим результат работы отдела разработки.
Наняли. Стало ли качественнее? Ну наверное. Релизы помедленнее стали выходить, вроде. Но вроде и да, багов меньше…
Как понять, что они свой хлеб не зря едят? Ну давайте KPI введем. Например, на количество найденных багов. Чем больше нашел, тем больше премия.
А программистам введем такой же KPI, только в обратную сторону. Чем больше багов, тем меньше премия.
И да начнётся битва, в которой не будет победителей! 😄
Пока разрабы дерутся с тестерами за баги, пользователи грустят в ожидании фич, а бизнес теряет бабки на эту вот внутреннюю борьбу вместо того, чтобы зарабатывать их на новой фиче.
=============================
Agile Shift Left Testing
Чем раньше баг будет найден, тем он дешевле для бизнеса. Чем раньше фича будет выкачена в прод, — тем раньше бизнес начнет на ней зарабатывать бабки.
Последние несколько лет я думаю, как можно работать с QA на ранних этапах.
Пришел в Авито, а тут оказывается уже придумали.
Agile Shift Left Testing даёт максимально раннее обнаружение багов. В одном спринте нашли баги новой фичи, починили и покатили в релиз. Таким образом сокращаем Time To Market при сохранении качества.
Концепт звучит просто: QA — часть кроссфункциональной команды, и участвует на всех этапах жизненного цикла фичи, начиная с проработки задачи.
На деле всё чуть сложнее. Сходу упираемся в то, что в кроссфункциональной команде не помещаются несколько QA. Плюс, платформ дофига: 2 мобильных, десктоп и мобильный веб, а еще бэкенды. Один QA не вытащит это всё тестить руками или покрывать тестами.
Получается, надо вовлекать разработчиков.
QA инженер с точки зрения Agile Testing — главный стекхолдер качества внутри команды, который знает ответ на вопрос «что такое качество?».
При этом основная задача QA — не тестить всё самому, а:
1️⃣ — Менторить разработчиков в написании тест-кейсов
2️⃣ — Показывать своим примером, как нужно писать e2e тесты
3️⃣ — Следить, чтобы пирамида выглядела как пирамида
В наших командах разработчики уже сейчас пишут тест-кейсы на этапе декомпозиции фичи, а часть слоев тестов зафиксированы в Definition of Done. И пишут их не только QA, а все инженеры.
KPI при этом отстутствуют. Но есть квартальные планы, которые нужно разработать с заданным в DoD уровнем качества. А еще есть Zero Bug Policy. Это когда мы либо фиксим баг в ближайшее время, либо осознанно говорим, что не будем его исправлять.
Прямо своими глазами наблюдаю, как разработчики вовлекаются в это самое качество и закладывают время внутри спринта на написание тестов, ручное тестирование после интеграции и починку всплывших багов.
Кажется, Agile Testing — это ответ. А какой был ваш вопрос? 🙂
Подробнее можно почитать в стате на хабре:
https://habr.com/ru/company/avito/blog/458940/
Вот мы делаем продукт. Все понимают: «Надо делать качественно».
Прикол в том, что это в этой фразе слово «качественно» — абстрактное понятие, которое каждый понимает по-своему.
Нипанятна. От меня вот фичу требуют, пойду лучше её запилю.
Ок, давайте наймём отдел QA. Пусть обеспечивают это самое качество. Им виднее, что это такое. На вход им дадим результат работы отдела разработки.
Наняли. Стало ли качественнее? Ну наверное. Релизы помедленнее стали выходить, вроде. Но вроде и да, багов меньше…
Как понять, что они свой хлеб не зря едят? Ну давайте KPI введем. Например, на количество найденных багов. Чем больше нашел, тем больше премия.
А программистам введем такой же KPI, только в обратную сторону. Чем больше багов, тем меньше премия.
И да начнётся битва, в которой не будет победителей! 😄
Пока разрабы дерутся с тестерами за баги, пользователи грустят в ожидании фич, а бизнес теряет бабки на эту вот внутреннюю борьбу вместо того, чтобы зарабатывать их на новой фиче.
=============================
Agile Shift Left Testing
Чем раньше баг будет найден, тем он дешевле для бизнеса. Чем раньше фича будет выкачена в прод, — тем раньше бизнес начнет на ней зарабатывать бабки.
Последние несколько лет я думаю, как можно работать с QA на ранних этапах.
Пришел в Авито, а тут оказывается уже придумали.
Agile Shift Left Testing даёт максимально раннее обнаружение багов. В одном спринте нашли баги новой фичи, починили и покатили в релиз. Таким образом сокращаем Time To Market при сохранении качества.
Концепт звучит просто: QA — часть кроссфункциональной команды, и участвует на всех этапах жизненного цикла фичи, начиная с проработки задачи.
На деле всё чуть сложнее. Сходу упираемся в то, что в кроссфункциональной команде не помещаются несколько QA. Плюс, платформ дофига: 2 мобильных, десктоп и мобильный веб, а еще бэкенды. Один QA не вытащит это всё тестить руками или покрывать тестами.
Получается, надо вовлекать разработчиков.
QA инженер с точки зрения Agile Testing — главный стекхолдер качества внутри команды, который знает ответ на вопрос «что такое качество?».
При этом основная задача QA — не тестить всё самому, а:
1️⃣ — Менторить разработчиков в написании тест-кейсов
2️⃣ — Показывать своим примером, как нужно писать e2e тесты
3️⃣ — Следить, чтобы пирамида выглядела как пирамида
В наших командах разработчики уже сейчас пишут тест-кейсы на этапе декомпозиции фичи, а часть слоев тестов зафиксированы в Definition of Done. И пишут их не только QA, а все инженеры.
KPI при этом отстутствуют. Но есть квартальные планы, которые нужно разработать с заданным в DoD уровнем качества. А еще есть Zero Bug Policy. Это когда мы либо фиксим баг в ближайшее время, либо осознанно говорим, что не будем его исправлять.
Прямо своими глазами наблюдаю, как разработчики вовлекаются в это самое качество и закладывают время внутри спринта на написание тестов, ручное тестирование после интеграции и починку всплывших багов.
Кажется, Agile Testing — это ответ. А какой был ваш вопрос? 🙂
Подробнее можно почитать в стате на хабре:
https://habr.com/ru/company/avito/blog/458940/