Что делает тестировщик на работе: один рабочий день

Утро: почта, календарь и доска задач

Мой день начинается с почты. Туда приходят уведомления из рабочих инструментов: разработчик перевёл задачу в тестирование, баг исправлен и ждёт проверки, появилась новая встреча или приглашение на обучение. Лишние уведомления лучше сразу отключить в настройках каждого инструмента, обычно на вкладке Notifications, иначе важное теряется среди сотни писем о чужих комментариях на GitHub.

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

Дальше календарь, где видно, какие встречи сегодня, и доска задач в Jira: что на каком статусе и за что можно браться. Рабочий день обычно восьмичасовой с часом на обед, а начало во многих компаниях гибкое. Подстраиваться приходится под встречи команды, пропускать их не принято.

Встречи спринта и что на них делает тестировщик

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

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

• Стендап (daily scrum)

  Каждый день, 15 минут. Каждый рассказывает, что сделал вчера, что делает сегодня и что мешает. Если мешает, например, застрявшее ревью кода, из-за которого тестировщик не получает сборку, здесь договариваются, кто поможет.

• Планирование спринта

  Из бэклога продукта отбирают задачи в бэклог спринта и ставят цель спринта. Задачи оценивают в стори-поинтах, относительных единицах сложности, часто по ряду Фибоначчи. В покере планирования оценки показывают одновременно, и если они сильно разошлись, участники с крайними оценками объясняют свои доводы, а затем голосуют снова.

• Обсуждение требований (refinement)

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

• Разбор багов (bug triage)

  Когда дефектов накопилось много и их число не уменьшается, их разбирают вместе: расставляют приоритеты, дополняют описания, зовут владельца продукта, если требование успело измениться. О такой встрече стоит самому попросить скрам-мастера, если баги лежат без движения.

• Демонстрация и обзор спринта

  Сделанное показывают заказчику и получают обратную связь. На обзоре смотрят и метрики команды: скорость (velocity), число найденных дефектов, график сгорания задач (burndown chart).

• Ретроспектива

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

• Встреча один на один (one-on-one)

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

• СтатьяAgile, Scrum и Kanban для тестировщика
• ШпаргалкаScrum для тестировщика

Пример: путь одной задачи по доске

Статусы на доске на каждом проекте свои. Ниже сборный вариант, который я показываю в учебной Jira, и то, что делает тестировщик на каждом шаге.

• Нужны требования

  Пользовательская история лежит в бэклоге продукта, требования к ней ещё дописывают. Тестировщик уже читает её: есть ли критерии приёмки (acceptance criteria), открываются ли ссылки на макеты, не противоречит ли текст макету. Если аналитик описывает исключительные случаи (exception cases), из них сразу получаются негативные проверки.

• Готово к разработке

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

• В работе и ревью кода

  Разработчик пишет код и отправляет его на ревью другому разработчику. Пока ревью не пройдено, задача в тестирование не попадает.

• Тестирование

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

• Готово к релизу и Done

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

• СтатьяТестирование требований: как их проверять
• СтатьяЧек-лист и тест-кейс: разница и пример

Сборка, окружения и баги

Код задачи живёт в своей ветке в GitHub. После ревью ветку сливают в основную через pull request, и на некоторых проектах эту кнопку нажимает тестировщик, когда проверка пройдена. Сборку на нужном окружении собирает Jenkins. На моём проекте тестировщик отправляет ветку командами Git, и задание (job) в Jenkins запускается само. Если сборка упала, причину ищут в логе задания и идут с ним к разработчику, а если код ни при чём, к DevOps-инженеру.

Окружений обычно несколько. На локальном работает разработчик, на тестовом (QA) тестировщики проверяют новые задачи, а stage, или pre-release, – последняя проверка перед релизом, и там всё должно работать стабильно. На prod работают пользователи, и выкладку туда делают разработчики или DevOps под руководством релиз-менеджера.

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

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

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

• СтатьяТестовые окружения: Local, Dev, Stage, Prod
• СтатьяРегрессионное и смоук-тестирование
• СтатьяБаг-репорт: из чего состоит и как написать

Инструменты, с которыми проходит день

Набор зависит от проекта и даже в одной компании за несколько лет может смениться. Бывает, что подобрать замену поручают самому тестировщику, особенно если он один на проекте. Новый инструмент советую учить по официальной документации и только потом смотреть видео: интерфейсы меняются, и ролики устаревают первыми.

• Почта, календарь и мессенджер

  Часто это одна среда, например Outlook и Teams от Microsoft, чтобы письма, встречи и переписка были в одном месте.

• Jira или другой трекер

  Доска задач, бэклог, спринты и баги. Вместо Jira встречаются YouTrack, Azure DevOps и другие системы.

• TestRail

  Система управления тестированием: тест-кейсы, прогоны и отчёты. Её связывают с Jira, и тогда в задаче видны привязанные к ней кейсы и результаты прогонов.

• Figma

  Макеты дизайнеров. У каждого элемента видны размеры, шрифт, цвет и отступы, а те же значения на странице показывает панель стилей в DevTools, и их сравнивают элемент за элементом. К макету можно оставлять комментарии ещё на этапе требований.

• GitHub или GitLab

  Хранилище кода с ветками и запросами на слияние (pull request), к которым привязаны задачи из трекера.

• Jenkins или другая система CI

  Сборка и выкладка на окружения. Настраивают её обычно DevOps-инженеры, а тестировщик запускает задание и читает лог, если оно упало.

• Базы данных, Postman, эмуляторы

  В базе проверяют, что сохранилось на самом деле, в Postman отправляют запросы к API. На моём проекте база нереляционная, MongoDB, и запросы к ней пишут не на SQL. Тем, кто тестирует мобильные приложения, добавляются эмуляторы и симуляторы.

• Все вместе на одном баге

  В приложении доставки после отмены заказа на экране остаётся статус "Готовится". Тестировщик открывает в DevTools вкладку Network и смотрит, какой статус вернул сервер. Если сервер вернул отмену, а экран показывает старый статус, ошибка во фронтенде, а если старый статус хранят и ответ, и база, то в бэкенде. Запрос, ответ и скриншот уходят в баг-репорт в Jira, а проверка отмены попадает в кейсы TestRail и дальше в регресс.

• СтатьяСистемы управления тестированием и баг-трекеры
• СтатьяDevTools для тестировщика
• СтатьяCI/CD для тестировщика

Видеоуроки, шпаргалки и задания

Свой рабочий день я показываю в ролике "Что делает тестировщик на работе?" на YouTube. В более раннем ролике я рассказываю о дне на продуктовом проекте, от утренней почты до регрессии перед релизом. В бесплатном базовом курсе по тестированию тема идёт уроком "Один день из жизни тестировщика".

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

• Урок курсаЭтот урок – бесплатно
• Мой видеоурокчто делает тестировщик на работе
• Мой видеоурокодин рабочий день из жизни тестировщика
• ШпаргалкаScrum для тестировщика
• Шпаргалкапрогон билда от сборки до релиза
• Шпаргалкажизненный цикл бага
• Тренажёрситуационные кейсы
• СтатьяАутсорс, аутстаф или продукт: где работать тестировщику

Курсы по теме

• бесплатный

  Тестирование ПО с нуля. Теория + Практика. Базовый уровень

  Первое рабочее место тестировщика

  89 уроков113 441

Вопросы и ответы