- -
- 100%
- +
И наконец – долгосрочное видение.
Команда сегодня и команда через год – это разные вещи. Если продукт планирует активный рост, QA Lead должен думать наперед.
Пример.
Сейчас хватает ручного тестирования. Но через полгода релизы будут выходить каждую неделю. Значит, уже сейчас стоит задуматься о развитии автоматизации и поиске людей с соответствующими навыками.
Формирование команды – это стратегическая работа. Это не просто закрытие вакансий. Это создание устойчивой системы, в которой:
– люди понимают свою роль,
– зоны ответственности прозрачны,
– навыки дополняют друг друга,
– команда способна расти вместе с продуктом.
И если команда собрана правильно, многие управленческие проблемы в будущем просто не возникают.
Как выбрать правильных специалистов
Выбор людей в команду – это одна из самых сильных точек влияния QA Lead. Неподходящего человека потом очень сложно «исправить» процессами. А правильный специалист может вытянуть даже несовершенную систему.
Первая ошибка, которую совершают многие – искать «идеального кандидата». Универсального бойца, который умеет все: автоматизация, нагрузка, API, безопасность, документация, коммуникация, DevOps и еще немного магии.
В реальности таких людей почти не бывает. А если бывают – они либо очень дорогие, либо быстро перерастают позицию.
Поэтому начинать нужно не с «кого бы нам хотелось», а с «что нужно продукту сейчас».
Пример.
Проект активно растет, но релизы постоянно тормозятся из-за долгой ручной регрессии. В этом случае важнее кандидат с опытом автоматизации, чем еще один сильный ручной тестировщик.
И наоборот. Если продукт новый, требования постоянно меняются, много исследовательской работы – нужен гибкий специалист с хорошим аналитическим мышлением, а не человек, который привык работать только по строгим тест-кейсам.
Второй важный момент – оценка реального мышления, а не только знаний.
На собеседовании легко проверить, знает ли человек определение регрессии или чем отличается smoke от sanity. Но гораздо важнее понять, как он думает.
Например, можно дать кейс:
«Представьте, что мы внедряем новую систему оплаты. Что бы вы проверили?»
Если кандидат начинает просто перечислять стандартные пункты без логики – это один уровень.
Если он задает уточняющие вопросы, думает о граничных значениях, отказах, безопасности, нагрузке – это другой уровень.
Хороший специалист всегда задает вопросы.
Третий аспект – отношение к ответственности.
Пример.
Вы спрашиваете: «Был ли случай, когда баг ушел в продакшен?»
Один кандидат отвечает: «Это разработчик плохо сделал, я не виноват».
Другой говорит: «Мы не учли один сценарий, после этого добавили дополнительную проверку».
Во втором случае человек думает о процессе, а не о перекладывании вины. Это важный сигнал.
Четвертый момент – способность работать в команде.
QA – это постоянное взаимодействие. Если специалист не умеет спокойно объяснять свою позицию, агрессивно реагирует на критику или не принимает обратную связь, это со временем создаст напряжение.
Простой пример из практики.
В команду взяли очень сильного автоматизатора. Технически – блестящий. Но он постоянно спорил, не принимал чужое мнение и обесценивал ручное тестирование.
Через несколько месяцев команда разделилась на «лагерь автоматизации» и «лагерь ручников». В итоге эффективность упала.
Техника важна. Но поведение – не менее важно.
Пятый аспект – потенциал роста.
Иногда лучше взять специалиста с хорошей базой и высокой мотивацией, чем «застывшего эксперта», который не хочет учиться.
Например, кандидат может честно сказать:
«Я пока не работал с CI/CD, но активно изучаю и хочу развиваться в этом направлении».
Если видно желание расти и готовность брать ответственность, такой человек может быстро усилить команду.
Еще один практический совет – учитывать баланс внутри команды.
Если в команде уже есть три спокойных, осторожных специалиста, возможно, стоит добавить более инициативного человека, который будет двигать процессы. Если наоборот – много быстрых и креативных, может потребоваться более системный и внимательный к деталям тестировщик.
Команда должна быть сбалансированной.
И наконец – не торопиться.
Иногда под давлением сроков хочется закрыть вакансию как можно быстрее. Но неправильный найм создает проблемы на годы. Лучше потратить больше времени на поиск, чем потом заниматься постоянным тушением конфликтов или исправлением системных ошибок.
Выбор правильных специалистов – это не только про навыки. Это про соответствие продукту, команде и будущему развитию.
Сильная команда начинается с осознанных решений на этапе найма. И именно QA Lead закладывает этот фундамент.
Разнообразие ролей в команде тестировщиков
Одна из типичных ошибок при построении QA-команды – считать, что все тестировщики должны быть «одинаковыми». Универсальными, взаимозаменяемыми, способными делать все подряд.
На практике сильная команда – это не клон одного идеального специалиста. Это сочетание разных ролей и сильных сторон.
Начнем с простого примера.
Проект – это интернет-магазин. Есть фронтенд, бэкенд, интеграции с платежными системами, мобильная версия, отчетность для бизнеса.
Если в команде все тестировщики сосредоточены только на UI, неизбежно пострадают:
– API-проверки,
– корректность данных в базе,
– стабильность интеграций.
Разнообразие ролей позволяет закрывать разные типы рисков.
Чаще всего в команде можно выделить несколько направлений.
Первое – ручные тестировщики, которые глубоко понимают бизнес-логику. Они сильны в исследовательском тестировании, умеют находить нетипичные сценарии и «думать как пользователь».
Пример.
При тестировании корзины интернет-магазина такой специалист проверит не только добавление товара, но и поведение при резком обновлении страницы, при смене валюты, при одновременном использовании промокода и бонусов.
Это внимательность к деталям и контексту.
Второе направление – специалисты по автоматизации. Их задача – снизить нагрузку на ручную регрессию и обеспечить стабильность повторяющихся проверок.
Например, если при каждом релизе нужно проверять авторизацию, создание заказа и оплату, автоматизатор может настроить автотесты, которые запускаются при каждом изменении кода. Это повышает скорость релизов и уменьшает человеческий фактор.
Третье – API-ориентированные тестировщики. Они глубже работают с запросами, логами, базами данных. Особенно важны в проектах с микросервисной архитектурой или сложной бизнес-логикой.
Пример.
Пользователь жалуется, что заказ отображается некорректно. UI выглядит нормально, но данные не совпадают. API-тестировщик может проверить реальные ответы сервиса и найти проблему быстрее, чем тот, кто работает только через интерфейс.
Четвертая роль – специалист, который фокусируется на процессах и качестве в целом. Иногда это сам QA Lead, иногда – старший тестировщик. Такой человек следит за регрессией, стандартами документации, метриками, анализом дефектов.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.