— «... ну вот опять, снова вернулась ко мне задача из тестирования, сколько можно уже?» — Вася зло прокомментировал появившееся уведомление о новом письме.
Привет, меня зовут Вася и я fullstack-разработчик. Сегодня я расскажу вам историю, как в одной маленькой команде мы попытались отказаться от ручного тестирования — почему понадобилось, что делали, что получили.
Конечно же, история будет полна героических подвигов, внезапных сюжетных поворотов, тяжелых предательств и настоящей любви.
Кому будет интересна статья:
Руководителям команд/направлений, ищущим способы ускорить/удешевить разработку;
Ручным тестировщикам, желающим начать заниматься Quality Assurance;
QA, как «ещё один успешный кейс улучшения процессов в команде»;
Разработчикам, неравнодушным к процессам в команде.
Пролог. История кнопки всевластия — “Reopen”
В давние незапамятные времена, земли одной компании были поделены между Гильдиями, назовем их кратко, по виду боевых искусств, которыми они владели их участники — C#, Python, JS.
За всеми Гильдиями присматривала каста предприимчивых управленцев, пользующаяся их услугами и продававшая результаты работы во Внешний Мир. Наместником их был СТО (Самый Трудолюбивый Организатор). Задачей СТО было повысить эффективность Гильдий.
Для помощи Гильдиям, СТО создал ещё несколько гильдий, более малых, использовав незанятые просторы компании. Состав пополнился:
Гильдией Администрирования (SRE);
Гильдией Обеспечения Качества (QA);
Гильдией Сопровождения Разработки (DevOps).
Для каждой новосозданной гильдии, СТО назначил своих наместников — их задачей была работа по интеграции гильдий друг с другом.
Шло время, компания (и её гильдии) развивалась, продажи росли, всё было прекрасно, пока на одной встрече руководителей гильдий, представитель Обеспечения Качества не высказал желание укрепить влияние своей гильдии над остальными гильдиями.
С помощью руководителя Сопровождения Разработки были выкованы золотые кнопки “Reopen”, по одной для каждого инженера Обеспечения Качества — их способности позволяли контролировать выполнение задачи на всех этапах разработки, что давало неописуемую власть над проектами. По договоренности с гильдиями SRE и DevOps, инженеры QA не могли вмешиваться в их дела — кнопки были бессильны на их землях. Но одна кнопка, выкованная втайне от всех, всё же имела власть на всех землях Компании, и конечно же, она досталась...
Часть I. Тесты сгущаются
<52 часа до релиза>
— «Ало, восемь утра, почему так рано? ... Как так, Катя заболела? У нас релиз через два дня, что мы делать будем без Кати?» — Вася не мог поверить в происходящее. Возмущение от того, что его посмели так рано разбудить сменилось растерянностью — кто будет проводить интеграционное тестирование перед релизом, если не Катя?
Приехав на работу, Вася вместе с командой начали искать артефакты, оставшиеся от Кати. По логам в конфлюенсе было найдено священное писание — чеклист интеграционного тестирования проекта.
<50 часов до релиза>
С найденным чеклистом, ребята поспешили к руководителю QA отдела.
— «Паш, привет, ты наверное слышал уже, что Катя заболела? У нас релиз фичи новой послезавтра, можешь кого-то из ребят найти, кто свободный, чтобы нам Катю заменить?» — ворвался Вася в кабинет к Паше.
— «Простите, ребята, сразу так никого не подскажу — все у нас заняты. Может быть Артем может с чем-то помочь, но только чуть-чуть, потому что у него тоже завал» — развел руками Паша.
После недолгих поисков Артема в офисе и последующей беседы с ним, был сформирован план действий:
тестирование отдельных задач проводится самими разработчиками;
Артем помогает придумать сценарии для проверки задач, насколько позволяет его знание продукта (Артем работает в другой команде, поэтому не знает всех тонкостей нашей фичи);
интеграционное тестирование распределяется на всех участников команды одинаковыми частями (спасибо заранее готовому чеклисту от Кати).
Часть II. Возвращение QAроля
<72 часа после релиза>
— «... мы без тебя не можем, давай больше никогда-никогда не расставаться, Кать?» — с грустью в голосе сказал Вася прибывшей с больничного Кате.
Катя же, обсудив с Артемом её отсутствие в предыдущие дни, заручилась поддержкой Паши и приготовилась выполнять зловещий план, состоящий из следующих пунктов:
Провести интервью с каждым разработчиком о том, как он тестировал свои собственные задачи — общие впечатления от процесса, ощущения от работы с Артемом в формате придумывания сценариев тестирования;
Собрать метрики по задачам, протестированным разработчиками самостоятельно — как быстро такие задачи проходят тестирование, как много багов связанных с этими задачами.
Отрывок из интервью с Васей:
Мне понравилось в таком формате с Артемом работать, он мне подсказывал некоторые штуки, о которых я забывал — пользователи с разными ролями, объекты разных типов. С легаси когда работаешь, бывает нет тестов на этот компонент, поэтому облажаться там можно легко. А Артем он умный, много знает про продукт — очень удобно с ним генерировать идеи для тестов.
Максимум один раз задачу переоткрывали, я сразу всё фиксил и необходимые тесты дописывал. Времени конечно же больше тратится на такую работу, потому что сначала многое упускал и мы придумывали сценарии вдвоем — отличается от того, что "кинул задачу в тестирование и ушел заниматься другой задачей".
Проведя интервью со всеми участниками, дополнительно заручившись поддержкой тимлида, на ретро команды было объявлено — самостоятельному тестированию задач разработчиками быть.
Часть III. Подсчет эффективности
Результатами нашей истории стало:
Небольшое увеличение ТТМ в начале «самотестирования» разработчиками, вызванное необходимостью обсуждений тестовых сценариев;
Разработчики команды увеличили свои знания о продукте и теперь способны тестировать задачи, не привлекая QA для помощи в составлении сценариев;
Незначительное снижение TTM для задач и проектов/фичей в целом — после переходной стадии с обсуждением тестовых сценариев, избавление от пинг-понга задачами пошло на пользу;
Увеличен bus-factor для тестирования, более нет потребности в ручном тестировании до стадии интеграционного тестирования (интеграционное тестирование на QA остается, как необходимость просмотра "чистым взглядом" проекта — при желании можно и его размазать на команду разработки);
И далеко не последнее по значимости — отсутствие роста багов по задачам с самотестированием. Количество их и не уменьшилось, и не увеличилось, но это и не было целью данного исследования.
Что же до ответа на вопрос «Сколько стоит избавиться от ручного тестирования?» — с одной стороны, зарплаты пришлось повысить, потому что Катя ушла в автоматизацию, а разработчики стали делать больше вещей. С другой стороны, у нас теперь есть хорошая прокачанная команда, способная доставлять качественный продукт быстрее.
