Процессы тестирования часто деградируют незаметно.
Сначала регресс чуть дольше, потом случаются баги в проде, а потом уже никто не может точно сказать, что вообще проверялось перед релизом.
В этой статье — 5 признаков, что процесс тестирования в вашей команде пошел не туда.
Если вы узнаете хотя бы один из них, это сигнал пересмотреть систему QA:
Сначала регресс чуть дольше, потом случаются баги в проде, а потом уже никто не может точно сказать, что вообще проверялось перед релизом.
В этой статье — 5 признаков, что процесс тестирования в вашей команде пошел не туда.
Если вы узнаете хотя бы один из них, это сигнал пересмотреть систему QA:
1) Частые критические баги в проде
Когда вся система или ее часть не работает, это всегда потеря денег. Чем чаще она не работает, тем больше теряет бизнес. Поэтому критические баги в проде это большая проблема. Да и не только критические. Дефекты вообще это влияние на репутацию и NPS (Net Promoter Score - индекс готовности рекомендовать продукт друзьям).
Механика такая:
Много дефектов →
Низкое качество →
Продуктом пользоваться неприятно →
Клиенты ушли к конкурентам :(
Причины:
- Низкое качество тестирования: учитываются не все сценарии
- Регресс не ловит поломок или его вообще нет
- На тестирование не хватает времени
- Виновато вообще не тестирование, а инфраструктура
- Нет “работы над ошибками” в процессах
Это неполный список, но основные причины — здесь.
2) Регресс занимает очень много времени
Понятие “много” у каждого проекта свое. Для одних два дня — это уже долго, для других месяц — очень быстро. В любом случае долгий регресс = поздняя доставка нового функционала клиентам, а значит — потеря денег. Сам по себе регресс — это тоже издержки, ведь все это время команда могла делать новые классные фичи.
Спойлер от капитана Очевидность: почти все косяки в процессах так или иначе — потеря денег.
Причины:
- Отсутствие автоматизации (не всегда плохо, но часто причина)
- Неоптимальная автоматизация (плохой фреймворк, инфраструктура, процессы)
- Неактуальные тест-кейсы или их отсутствие
- Плохое знание системы тестировщиками (а иногда — всей командой)
3) Большая часть автоматизированных тестов сломана и не прогоняется
Вы потратили время и деньги на написание автотестов — а теперь они лежат и не приносят пользы. Может показаться, что так даже лучше: не тратится время на поддержку. Может быть. Но, скорее всего, те автотесты, что пишутся сейчас, через время постигнет та же участь.
Автоматизаторы стоят дорого — значит, на это стоит обратить внимание.
Автоматизаторы стоят дорого — значит, на это стоит обратить внимание.
Причины:
- Ненастроенные процессы
- Преждевременная автоматизация
- Неправильный отбор тестов
4) Никто точно не может сказать, что проверялось перед релизом, а что нет
Тестирование — это всегда про минимизацию рисков. Но если команда не знает, что проверяется, о какой минимизации может идти речь? Это серьезный звоночек обратить внимание на процессы. Непредсказуемые поставки и релизный хаос — вестники других всадников апокалипсиса.
Причины:
- Проблемы в аналитике и разработке
- Слабое планирование
- Незрелость тимлидов или проджектов
5) Тестировщики не жалуются на разработку и аналитиков
Это мой персональный пунктик)
Довольные тестировщики — плохие тестировщики. Хорошие тестеры — занудные перфекционисты, которым дай подушнить.
Разработчики разрабатывают плохо. А если хорошо, то могли и лучше. Аналитики требования пишут хуже некуда. Сваггер у них не актуальный, контракты с соседней командой не согласованы. А проджект... ну, вы поняли :)
Довольные тестировщики — плохие тестировщики. Хорошие тестеры — занудные перфекционисты, которым дай подушнить.
Разработчики разрабатывают плохо. А если хорошо, то могли и лучше. Аналитики требования пишут хуже некуда. Сваггер у них не актуальный, контракты с соседней командой не согласованы. А проджект... ну, вы поняли :)
Причины:
- Очень зрелый проект и все процессы уже отлажены
- Ошибка найма (тестеры без инженерной искорки)
- Отсутствие инженерной культуры (ценности, миссия, видение)
Плохо это потому, что тестировщики перестают стремиться к изменениям. Без изменений качество продукта не растет.
Нет изменений — начинается деградация.
Нет изменений — начинается деградация.
Что делать, если вы узнали свою команду?
Если любой из этих признаков вам знаком — проведите “расследование”.
Скорее всего, вы обнаружите целую цепочку связанных проблем: в планировании, коммуникациях, документации.
И это хорошо!
Потому что осознанная проблема — уже половина решения.
Скорее всего, вы обнаружите целую цепочку связанных проблем: в планировании, коммуникациях, документации.
И это хорошо!
Потому что осознанная проблема — уже половина решения.
Качество — это система.
Если вы чувствуете, что процессы буксуют — это не провал, а сигнал.
Quality Trek помогает командам выстроить тестирование так, чтобы качество стало предсказуемым и системным.
