SDET. Часть 2. Команда разработки в QA
Итак, мы уже разобрались: SDET — это не просто QA с джавой, а реальный разработчик с солидными навыками тестирования. SDET-ы — ребята, которые шарят и в коде, и в тестах, а это сразу выводит их на другой уровень. Но боль наступает когда их надо объединить и синхронизировать, если они раскиданы по разным командам. Обычный QA занимается багами и функционалом, а SDET больше копают в сторону автоматизации и инфраструктуры, лишь изредка влезая в продуктовые задачи, а значит генерит много велосипедов будучи без присмотра.
Да, в идеале было бы классно иметь свою Core команду, которой управлял бы только я. Но реальность такая, что приходится выкручиваться без этого, и тут на помощь и приходит модель «гильдий» от Spotify: сборка инженеров из разных юнитов, работающих на общую цель. У меня получилось что-то похожее: опытные SDET со всех команд и QA которые учатся у старших, а вся гильдия держится на нескольких ключевых ролях:
- Лид SDET, для планирования и координации.
- Арх совет для контроля ключевых решений.
- Решалы за внедрение — старшие ребята, которые пинают свои команды, чтобы новые решения быстро раскатывались.
Как выжить в SDET команде: Несколько лайфхаков
1. Работайте на бизнес и IT. Ваши задачи должны решать конкретные проблемы. Занимаетесь хренью — будьте готовы к тому, что вашу гильдию могут слить. Лучшая защита — это четкая стратегия на год, которая синхронизирована с бизнесом и IT.
2. Планируйте OKR-ы на квартал. Это помогает вам и бизнесу понимать, на что идут ресурсы и как вы будете улучшать процессы. OKR — это уже база для меня с 2017 года и без него вопросов будет гораздо больше, чем ответов.
3. Доверие важнее задач. SDET — это не совсем ваш“ресурс”, это часть своей команды. Так что дружите с Тимлидами, делайте демо, делитесь обновлениями и ходите в барчик по пятницам. Чем больше доверия у продуктовых команд, тем больше свободы у вас для внедрения ваших идей.
Зачем вообще нужна виртуальная SDET-команда?
Эта структура закрывает множество болей, которые мучают любую крупную компанию:
- Общие решения по автоматизации, которые работают для всех.
- Единая инфраструктура тестирования, чтобы всё не развалилось.
- Кросс-командные код- и тест-ревью для QA (да-да, без этого никак).
- Обмен фишками и инструментами между юнитами.
- И самое важное — обучение QA из разных команд.
Когда нет возможности создать отдельную команду, виртуальная — это не просто костыль, а настоящий драйвер. Вы получаете ресурсы для разработки, а ваши решения идут на пользу всей компании. И в целом я считаю это даже лучше, чем отдельная платформа-команда, у которой обычно мало погружения в боли продуктовых команд и они оторваны от бизнеса.
Заряжайте лайки, чтобы Даня не ленился писать еще 😀
