Из Junior в Middle: как расти в QA

Главная мысль этой статьи: «Чтобы быстрее получить повышение, тебе нужно проявлять больше активности и брать на себя больше ответственности». Вводить метрики, отчётности, организовывать процессы, писать инструкции, обучать новичков.

Мы написали несколько конкретных советов о том, как это сделать

Пиши много документации

Вокруг тебя будет очень много новой информации. Будь губкой, которая впитывает всё новое. Записывай всё на вики (конфлюенс). Затем прибирайся, систематизируй и создавай удобную для каждого вики. Попробуй добиться репутации, что ты лучше и аккуратнее всех умеешь работать с документацией :)

Примеры типичных инструкций, которые ты можешь создать сам:

Как настроить тестовое окружение
Про оплаты на тестовой среде
Список всех мониторингов
Культура передачи в тестирование
Факап (инструкция: что делать, если сервис сломался в нерабочее время)
Список всех продуктов и окружений (ссылки на все сервисы и админки + их адреса в тестовом окружении)

Отдельный совет: подпишись на изменения всей вашей вики. Так ты на почту получишь уведомление, что кто-то изменил текущую документацию или добавил что-то новое.

Сделай страничку на вики с аббревиатурами, а в будущем — даже телеграм-канал

Пиши больше в общих чатах

Вообще, общаться в общих чатах полезно — каждый может увидеть, что у тебя есть вопрос, и прочитать на него ответ. А ещё ты примелькаешься и получишь репутацию активного тестировщика 💪

Будь всегда в контексте (Shift-left подход к тестированию)

Так бывает, что тебе в тестирование приходит задача в последний момент, когда уже всё готово, а ты вообще не понимаешь, как она работает.

Попроси явно всех менеджеров при постановке задачи определять не только исполнителя, но и тестировщика. И добавлять его во все задачи наблюдателем, во все встречи и чатики.

Прокачайся работе с почтой

Нет, мы не общаемся в почте, но на неё приходит до 500 отбивок в день. И это очень полезно: изменения на вики, новые комментарии в задаче, смена статуса задачи и т.п. Рекомендуем метод Zero Inbox.

Начинай свой день с просмотра аналитики и мониторингов

Собери в одном месте (на одной страничке в вики): мониторинги по бекенду (например, количество пятисоток); дашборды продуктовых метрик (например, выручка или количество заказов в день); обращения support и отзывы пользователей из сторов.

Каждое утро изучай эти графики. Если видишь какие-то необычные вещи — пиши в общие чаты.
• Если что-то крутое, напиши: «Ого, смотрите, мы вчера побили рекорд!»
• Если что-то пошло не так, напиши: «Гайз, вижу, ночью было много 500-ок. Мы там ничего не выкатывали?»

Пример работы с факапом

В работе бывают ошибки — это окей. Важно показать, что ты точно сделал выводы и такого больше не повторится:

Когда проблему устранили, создать задачу-инцидент и описать: «Что можно сделать, чтобы ситуация не повторилась?» Например добавить новый алерт, добавить новый тест-кейс или написать в этом месте автотест.

Проводи расследования

Если ты не находишь баги в текущих задачах — попробуй сам поискать в проде. Начни с базы данных или данных по аналитике. Найди, например, неуспешные оплаты и попробуй разобраться, почему эти оплаты не прошли.

Ставь задачи на редакторов, если видишь, что текст неудачный

Пример ситуации: если пользователю отказывают в Сплите по итогу внутренней проверки (это называется: «клиент не прошёл скоринг»), то текст говорит — данные не прошли проверку. Примерно 50% пользователей после такого сообщения идут в саппорт с уверенностью, что это у вас там что-то сломалось.

Что можно написать редактору:

Юля (она — редактор), привет!

У меня есть теория, что текущий текст ошибки говорит: «У них там чего-то сломалось, надо скорее написать в поддержку, чтобы починили!»

Может быть, у тебя получится написать текст, прочитав который, пользователь поймёт наш посыл: «О, я понял, что мне отказали, потому что считают меня потенциальным неплательщиком. И писать в поддержку мне не нужно, мне всё и так понятно».

При этом, как ты понимаешь, текст должен быть нейтральным — без конкретной причины отказа.

Работай с support

Пиши для техподдержки инструкции о работе микросервисов, за которые ты отвечаешь.
Обучи ребят из Support базовым инструментам (SQL, Postman) — так они смогут закрывать некоторые тикеты без обращения к тебе.
Если у тебя больше 10 обращений на одну проблему от пользователей (саппорта), это признак того, что проблема может быть массовой —подними её приоритет и попробуй разобраться с ней в первую очередь.

Прокачайся работе с таск-трекером на своём проекте (Yandex Tracker, Jira)

Научись создавать доску или фильтровать нужные себе задачи. Например, настрой фильтр, который показывает все задачи в Ready For Test.
Настрой автоматизацию. Например, если завели к вам новый баг, то в followers автоматом добавляются все тестировщики.
Заведи себе шаблоны баг-репортов.
Чтобы быть в курсе всего, можно назначить автоматизацию такую — на каждую новую задачу добавлять автоматом себя в followers, но это жёстко :)

Попробуй настроить несколько инструментов для упрощения жизни

Полезного телеграм-бота (например, который генерит номер банковской карты для оплаты в тестовой среде).
Погугли про интеграции Telegram + Таск-трекер на своём проекте.

Например:

создали новую задачу в Jira с типом release — приходит сообщение в Telegram
отмечай критичные тикеты тегом, и потом по этому тегу пусть приходит сообщение в канал раз в неделю

Создавай встречи сам

Заведи встречу раз в три недели — QA Retro, на которой каждый тестировщик может честно и без купюр рассказать, что наболело и что раздражает больше всего. И всем вместе подумать, как это можно исправить (существует платный сервис для проведения ретро). Но первое время можно и просто голосом.

Экологично попроси коллег поделиться знаниями

Если ты видишь, что аналитик умеет читать логи, или разработчик умеет классно читать мониторинги, то заведи встречу, на которой попросишь провести мастер-класс — как смотреть логи или читать мониторинги.

Важно донести ценность такой встречи — зачем тебя этому обучать. Например, чтобы тебе быстрее локализовать проблему. А ещё пообещай, что после встречи создашь классную доку, чтобы любой мог ей пользоваться.

Пример сообщения коллеге:

Я получил жалобу от support и хотел попробовать в ней разобраться: {{ссылка_на_задачу_из_jira}}
Но в коде как это сделать я не нашёл, сходу разобраться не смог 😔
Саша, пожалуйста, покажи нам мастер класс на 20 минут, как команде тестирования самим дебажить такие кейсы и не отвлекать разработку :)

С меня дальнейшая инструкция.

Будь активнее на встречах (планирование, дейлики)

Задавай вопросы:

Что планируете отдать в тестирование на этой неделе?
Там есть три критичных бага — может быть, возьмем в этот спринт?
В саппорт много пишут о проблеме N, может быть, нужно это доработать?

Поговори со своим руководителем

Именно твой руководитель будет решать, дать ли тебе повышение. Важно найти к нему подход.

Спроси прямо: можешь ли ты как-то ему помочь?
Попроси его поставить вам встречи 1-to-1 раз в две-три недели, чтобы неформально обсудить текущие проблемы и ваши цели.
По-хорошему, лучше заранее сообщить, что у тебя есть амбиции и желание получить повышение, и прямо задать вопрос — есть ли для этого возможность и что тебе необходимо сделать, чтобы его получить.

Разбирай раз в пару недель список всех заведённых багов

Делай подборку самых критичных и присылай в общий чат с командой разработчиков.
Пример сообщения:

Парни, выбрал список самых критичных и неприятных багов в проде. Запланируйте в работу, пожалуйста, как будет время:

1. Ссылка на задачу
2. Ссылка на задачу
3. Ссылка на задачу

Проводи обучения для коллег-тестировщиков

Пример сообщения:

Ребята, я за последний месяц научился редактировать и выкатывать новые версии email писем, узнал, как работает новый бэкенд, и научился запускать автотесты. Давайте запланируем встречу, и я передам вам эти знания тоже

Проводи собеседования

Скажи HR-отделу, что ты хотел бы проводить собеседования.
Не обязательно проводить собесы сразу в одного. Первое время можно просто присутствовать слушателем, пока собеседование проводит более опытный коллега.

В будущем ты сможешь проводить собесы один, и это будет новой строчкой в твоём резюме и поводом, чтобы ты получил повышение.

Улучшай процессы

Хорошее тестирование — это прозрачные процессы и хорошая документация. Предлагай, как можно улучшить культуру передачи в тестирование. Например, вместо того чтобы выкатывать один большой релиз раз в месяц, можно релизиться чаще, но меньшим количеством фичей.
Пробуй забрать на себя процесс релизов (насколько это возможно в рамках твоего проекта). Обоснуй это тем, что ты можешь освободить у разработчика много времени. А ещё ты сразу после релиза можешь посмотреть все мониторинги и обращения в саппорте и прогнать смоук- тестирование. Пусть тебя научат, как выкатывать. И как, в случае чего, откатывать.
Делай подробное и простое описание релиза в Телеграм после того, как он выкатился в прод.

Например:

Доставили релиз вебвью v0.95.1
Ссылка на релизный тикет
Экраны со спиннерами теперь умеют показывать кнопку рефреша (кроме, спиннера ожидания ссылки от траста)
Добавлен экран ошибки при подтверждении плана
Добавили логов на экран ошибки и вечные лоадеры
Если блекбокс возвращает статус NEED_RESET, наш флоу больше не ломается

+ рефакторинг

Планируй свои активности

Создай отдельную доску и запиши список ваших планов на ближайший отрезок времени (суперспринт, квартал или полугодие). Конечно, сама доска — это ещё не повод для твоего повышения. Но она поможет тебе не потерять и не забыть свои достижения за последние полгода и позволит держать фокус.

Пример конкретной просьбы о повышении

Для того, чтобы попросить повышение, тебе нужно будет написать письмо руководителю.

Например:

Макcим, привет! У меня зарплата 80 000 рублей, и с момента прихода в этот проект роста не было. Хочу обсудить это с тобой. Я вкладываю много сил в стабильность проекта и скорость релизов. Беклог пустой, багов пропущенных нет, автотесты пишутся, алерты настроены. А повышения зп нет — это демотивирует.

Мне нравится текущая команда (предполагаю, это взаимно), и есть желание продолжать развивать проект.

Ниже мои заслуги за последние полгода:

Автоматизация
— В нашем проекте, в первом и единственном из всех, совместно командой завезли автотесты в CI.

Юнит тесты и аналитика
— Новые тесты я также пишу самостоятельно (ссылка на коммит).
Что это нам дало: тратим меньше человеко-часов на тестирование руками. Релизы проходят быстрее и более предсказуемо.

Алерты
— Завёл алерты из ErrorCounter в Telegram (первые и единственные на всех проектах).
— Написал документацию, как это сделать для любого вебапа.
Что это дало нам: моментально реагируем на проблемы в релизах в продакшене, как клиента, так и сервера.

Саппорт
— Скорость обработки обращений выросла с 30 минут до 23 минут. Я обучил сотрудников работе с postman и базой данных — это позволило поддержке закрывать часть запросов самим.
— Добавил дашборды, которые показывают статистику по обращениям.
— Улучшили инструкцию для коллцентра, количество входящих обращений упало с 500 до 390 в день.
Что это нам дало: сотрудники техподдержки и коллцентра сами могу быстрее обрабатывать многие обращения, а клиенты быстрее получают решение своих проблем.

Организационно
— Переехали бекендом на новую очередь для релизов (qa → backend) и поставили на поток общий процесс релизов.

Прокидываем Fix Version из bb в стартрек
Что это нам дало: qa не тратит времени на подготовку и сбор релиза. В тестирование переходит уже готовая qa-ветка с mr в мастер.

Большие релизы
— Шторка фильтров в проде.
— Подписки в эксперименте.
— СКУ и баркод раскачен на сотрудников.
— Много улучшений в проде (в т.ч. отказ от старого датапрода).
Что это нам дало: подписки — хотелка номер один среди пользователей. Даёт потенциал для платной подписки.

Помимо этого:
— Научился заводить эксперименты.
— Научился заводить события аналитики в новую схемату.
— Связывался и дебажил проблему белого экрана с клиентом напрямую.
— Завожу ачивки для мотивации сотрудников тестировать ранние релизы.
— В целом, все задачи тестируются в темпе, и беклог из готовых задач не копится.
Что это нам дало: QA может взять задачу в тест, и сам добавить события в схемату, и выкатить в эксп. Меньше разделения работы среди коллег, и быстрее релизы фич.

Попроси себе маленький проект проект, который ты будешь оунить

В айти никогда не будет такого, что нет работы. Всегда не хватает рук. Расскажи, что у тебя есть время и желание чем-то помочь в плане продукта.
Например:

Можно пересмотреть все наши коммуникации и завести задачи на редактора, чтобы их обновить.
Или провести анализ конкурентов.
А ещё всегда не хватает документации. Спроси, какой не хватает, — и предложи красиво оформить и поддерживать. Например, описания всей аналитики на проекте в одном месте :)

Под эту активность назначь встречу раз в неделю для обсуждения статуса. С твоим руководителем или тем, кому это важно)

Продолжай развиваться сам

Автотесты, нагрузочные тесты, тестирование безопасности.
Пусть это будет видеокурс Udemy или какой-то мастер-класс. Начни с простого: SQL или базового курса по языку программирования. В идеале, чтобы знания можно было применить на практике в твоей работе (например, join или автотесты).

Кстати, можно попросить работодателя оплатить твоё обучение :)

Устраивай раз в три-четыре недели встречи QA_learn_team

Это онлайн встречи (условно в зуме), где вы будете смотреть полезные доклады по тестированию, а после этого обсуждать, что можно применить на вашем текущем проекте. Можно придумать, как выбирать тему: по очереди или голосовашкой.

Это одновременно полезная и интересная активность, которую мы можешь организовать сам.

Напиши пару публичных статей по теме QA

Можно на VC, Тинькофф Журнал или Habr. Не обязательно очень крутые статьи. Можно написать про любой инструмент или ресурс, которым ты пользуешься. Можно взять иностранную статью и перевести её (явно указать, что это перевод) или поделиться своим опытом, даже негативным — такие рассказы об ошибках часто вызывают эмпатию.