Первые 30 дней QA на новом проекте — как въехать и не наделать глупостей
Первый день на новом проекте выглядит одинаково почти везде: продукт незнакомый, стенды непонятные, в вики двадцать устаревших страниц, все куда-то бегут — и кто-то уже просит «глянь одним глазом вот эту фичу, ты же QA». Внутри борются два чувства: «я должен уже приносить пользу» и «я пока не знаю, где тут логин». Из этой борьбы рождаются главные глупости первого месяца — и о них ниже.
Я прошёл через несколько таких заходов и вывел для себя структуру первого месяца, которой поделюсь. Она не про «выполнить план онбординга» — она про то, чтобы через 30 дней быть полезным, а не просто «освоившимся».
Свежий взгляд — ресурс с истекающим сроком
Начну с неочевидного. В первый месяц у тебя есть суперспособность, которая потом исчезнет: ты видишь продукт глазами нового пользователя, а процессы — глазами постороннего. Через месяц-два ты привыкнешь — к кривому флоу онбординга, к стенду, который «ну да, по утрам лежит», к багу, который «это известное, не обращай внимания». Команда давно всё это не замечает; скоро перестанешь и ты.
Поэтому правило номер один: с первого дня записывай всё, что кажется странным, неудобным, непонятным. Не для того, чтобы завтра нести список претензий (об этом ниже), а потому что через месяц ты эти странности уже не увидишь. Этот список — сырьё для твоих будущих улучшений, и добыть его можно только сейчас.
Неделя 1: побудь юзером, а не тестировщиком
Соблазн первой недели — сразу зарыться в тест-кейсы и регламенты. Я делаю наоборот: первую неделю живу в продукте как пользователь. Каждый день. Пройти регистрацию (да, руками, с реального почтового ящика), основные сценарии, заплатить (на тестовом окружении — по-настоящему понять, как выглядит оплата), сломать что-нибудь об колено, как ломает обычный юзер.
Параллельно — два вопроса, ответы на которые определяют всё дальнейшее тестирование: что продукт обещает пользователю (главная ценность — если она сломана, всё остальное не важно) и на чём продукт зарабатывает (критичные пути — это деньги; их регресс всегда важнее всего). Звучит банально, но попроси нового тестировщика назвать топ-3 сценария по важности — и часто окажется, что это знание живёт только в головах старожилов.
И да — задавай вопросы. Все, даже «глупые». Первый месяц — единственное время, когда любой вопрос легитимен по умолчанию; дальше тот же вопрос будет стоить чуть дороже. Опытные люди это знают и в первый месяц выжимают из коллег максимум.
Недели 1–2: карта местности
Параллельно с продуктом собираю карту всего, с чем предстоит работать: где живут требования и макеты (и насколько они живые), как выглядит баг-трекер и — важно — как выглядит хороший баг-репорт здесь (открой десяток багов от уважаемых в команде людей и посмотри на стиль), какие есть стенды и какой из них кому принадлежит, есть ли тест-кейсы/чек-листы и насколько они актуальны, как устроен релизный цикл: как часто релизы, кто говорит «готово», что гоняется в CI.
Тут не надо ничего оценивать — только понять, как оно есть. Оценки будут позже, и они будут сильно точнее.
Карта рисков: три вопроса, которые заменяют документацию
Самое ценное, что я делаю в первые две недели, — короткие разговоры с каждым членом команды (разработчики, продакт, саппорт — особенно саппорт!) с тремя вопросами:
- Что у нас чаще всего ломается?
- Какой был последний серьёзный инцидент и из-за чего?
- Куда вы сами боитесь лезть?
Ответы — готовая карта рисков продукта, точнее любой документации: люди безошибочно помнят, где болит. «Только не трогай модуль синхронизации, его писал человек, который уволился» — это информация, которой нет ни в одной вики. Дополняю её историей багов из трекера за полгода: сортировка по модулям даёт объективный топ проблемных мест. Пересечение «страхов команды» и «статистики багов» — вот куда смотреть в первую очередь.
Недели 2–3: первые задачи — маленькие и образцовые
Первые реальные задачи я беру маленькими и довожу до конца: не «протестируй большую фичу», а баг — репорт — ретест — закрыт. Причина простая: по первым артефактам команда составит о тебе мнение, которое потом долго не изменить. Поэтому первые баг-репорты — образцовые: воспроизводимые шаги, окружение, доказательства, вменяемый severity. Один блестящий репорт в первую неделю работает на репутацию сильнее, чем десять «works fine» прогонов.
И отдельно: не критикуй процессы в первые недели. Даже если прав. Особенно если прав. «А вот на прошлой работе у нас было…» — фраза, после которой тебя перестают слушать. У половины местных странностей есть причина, которую ты пока не знаешь; у второй половины причина — усталость, и там твой аккуратный вопрос «а почему тут так?» сам подсветит проблему лучше любой критики. Свежий взгляд подают как вопросы, а не как приговоры.
Неделя 4: первые улучшения — маленькие и доведённые
К концу месяца у тебя есть список странностей (из недели 1), карта рисков и понимание процессов. Из этого выбираю одно-два маленьких улучшения и довожу их до конца: не «давайте перепишем все тест-кейсы» (это война на полгода), а «вот чек-лист смоука на релиз, я его прогнал на последних двух релизах, ловит вот это». Маленькое, законченное, с видимой пользой. Это одновременно и вклад, и заявка: я здесь не только выполнять тикеты.
И в этот же момент — разговор с лидом о взаимных ожиданиях: что от меня ждут через 90 дней? По мотивам классического эссе Рэндса о первых девяноста днях: первый месяц ты учишься, второй — встраиваешься, к концу третьего от тебя ждут самостоятельной ценности. Лучше узнать конкретику этих ожиданий на 30-й день, чем на 90-й.
Антипаттерны первого месяца
Молчать, чтобы «не мешать». Месяц тишины — и ты «тот тихий новенький, непонятно чем занят». Вопросы, заметки в общих каналах, первые репорты — видимость нужна с первой недели.
Критиковать всё подряд. Обратная крайность, см. выше. Вопросы — да, приговоры — нет.
Взять сразу большую фичу. Провалить её из-за незнания контекста — худший из возможных стартов. Маленькие законченные задачи побеждают.
Не записывать. Через месяц забудутся и вопросы, и странности, и ответы, которые тебе давали. Одна заметка, куда падает всё, — дешёвая страховка.
Делать вид, что понял. Кивнуть и уйти гуглить — можно один раз. Систематически — накапливается долг непонимания, который вскроется в худший момент.
Чек-лист первых 30 дней
- Прошёл основные пользовательские сценарии руками, каждый день пользуюсь продуктом
- Знаю, что продукт обещает юзеру и на чём зарабатывает (топ-3 критичных пути)
- Веду список «странностей» с первого дня
- Карта: требования, трекер, стенды, тест-артефакты, релизный цикл, CI
- Три вопроса каждому в команде: что ломается / последний инцидент / куда боитесь лезть
- История багов за полгода: топ проблемных модулей
- Первые баг-репорты — образцовые; первые задачи — маленькие и доведённые
- Ни одной фразы «а вот у нас было»; странности — вопросами
- Одно-два маленьких улучшения доведены и показаны
- Разговор с лидом: ожидания на 90 дней
Первый месяц — это не испытательный срок в одну сторону, как его принято переживать. Это единственный месяц, когда у тебя одновременно есть свежий взгляд, право на любые вопросы и нулевые ожидания по скорости. Дальше эти три ресурса тают — а пользоваться ими или нет, решается в первую неделю.