Тестирование в IT от первого лица

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

Представьте, что кто-то выпекает пироги для продажи.

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

Разбираемся с Алиной Илюхиной, QA Engineer в FoodTech, 7+ лет опыта в ручном тестировании

Кто такой тестировщик и зачем он нужен команде разработки?

Однажды на собеседовании меня спросили: «Как бы емко вы охарактеризовали тестировщика?» Я подумала и ответила: «Тестировщик — это многорукий Шива».

Для меня и вправду эта роль — многозадачна. Тестировщику приходится одновременно управлять множеством процессов. А еще цикл разработки чаще всего — хаос. И тестировщики прилежно превращают хаос в порядок.

Я думаю, главная задача тестировщика — проинформировать команду о текущем состоянии системы: насколько продукт отвечает требованиям бизнеса. Еще одной важной целью тестирования является подсвечивание рисков. Тестировщик, опираясь на свои опыт и насмотренность, помогает предотвратить ситуации, когда баги вызывают серьёзные проблемы для пользователей или бизнеса, особенно в финансовых, медицинских и других ответственных сферах. На основе этой информации команда принимает решение — выпускать обновление системы или нет. Мне не нравятся формулировки типа: «тестировщик ищет баги» или «цель тестирования — сломать систему». Я убеждена, наша профессия гораздо шире таких представлений о ней.

Какими задачами занят тестировщик? В идеале - как выглядит работа тестировщики глазами самого тестировщика? Потому у многих (далеких от айти) по описаниям из интернета складывается впечатление, что ручные тестировщики просто тыкают на кнопки в приложениях и смотрят, что они работают)

Глобально я бы разделила работу тестировщика на 3 этапа:

🔘 Планирование тестирования

🔘 Проектирование тестов

🔘 Выполнение тестов

1. Планирование тестирования

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

2. Проектирование тестов

Процесс проектирования тестов состоит из двух частей:

✅ Тест-анализ

На этом этапе нужно попытаться ответить себе на вопрос: что именно предстоит тестировать? Из требований мы понимаем, как приложение должно работать. А изучив макеты, становится понятно как оно должно выглядеть. Цель — найти как можно больше информации об объекте тестирования из всех доступных источников. Помимо требований, источниками могут выступать: база знаний проекта, тестовая документация, аналитики/дизайнеры/разработчики.

✅ Тест-дизайн

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

3. Выполнение тестов

Мы подготовили все необходимое — время выполнять проверки

Если в ходе прохождения тестов были выявлены дефекты, то это следует задокументировать — подробно описать в комментарии к задаче все проблемные сценарии, приложить скриншоты, логи и прочую информацию, важную для воспроизведения ошибки. Разработчик исправит проблему и вернет задачу на ретест. И так до тех пор, пока все не будет исправлено :)

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

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

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

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

Знакомлюсь с описанием задачи. Оцениваю ее в несколько часов с запасом. В это время закладываю: сбор недостающей информации + проектирование тестов + подготовка тестового окружения + тестирование.

Проектирование тестов. Тест-анализ

В тест-анализе есть несколько подходов. Один из которых называется декомпозиция. Это когда тестировщик разбивает крупные объекты тестирования на более мелкие. Так проще проектировать проверки. Требования декомпозируют до атомарного уровня: так, чтобы поделить их ещё раз было уже нельзя. Приведу простой пример: в требованиях сказано, что поле "Имя" формы предзаказа принимает только русские и английские буквы от 2 до 20 символов. Декомпозиция требований будет выглядеть так:

🟡 буквы русского алфавита

🟡 буквы английские алфавита

🟡 количество символов ->

〰 меньше 2

〰 от 2 до 20

〰 больше 20

Это и есть атомарный уровень: разбить требование ещё раз не получится. Еще один хороший способ разложить все по полочкам — визуализация. В этом подходе создается диаграмма связей — mindmap. Техника хороша тем, что у тестировщика буквально все перед глазами — меньше риск упустить что-то важное.

Из требований я выделила объект тестирования, теперь его нужно разложить до атомарного уровня. Готово!

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

В ходе тест-анализа обнаружила несколько «серых зон», которые требуют уточнения у аналитика. На все вопросы получаю ответы. Движемся дальше!

Проектирование тестов. Тест-дизайн

Вся необходимая информация у меня на руках — время проектировать проверки. В этот раз мне предстоит тестировать функциональность, которая имеет несколько параметров и у каждого параметра также может быть несколько значений. Принимаю решение протестировать изолированно каждый параметр, вторым этапом — сочетание параметров. Здесь мне пригодилась одна из техник тест-дизайна — таблица принятия решений. Оформляю тестовую документацию: пишу чек-листы и тест-кейсы в Qase (облачная система управления тестированием). Готово! Функционал покрыт тестами 🕺

Подготовка тестового окружения

Следующим этапом необходимо подготовить тестовый стенд, на котором будут проводиться проверки.

Приложение в сыром виде — это просто набор файлов. Чтобы превратить их в работающий проект, нужно выполнить сборку. Сборка — это процесс, во время которого код компилируется, собираются все зависимости (библиотеки и модули) и получается готовая версия приложения. У нас на проекте этот процесс автоматизирован:

Сборка готова. Теперь её нужно установить на виртуальную машину, на которой развернут мой тестовый стенд. Для этого я подключаюсь к виртуальной машине через SSH, затем в консоли выполняю команду, которая запускает установку нужной мне версии. Прописываю необходимые настройки, подключаюсь к базе данных. Выполнено.

Переходим к священному этапу!

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

Аналитическая работа позади, стенд готов, значит, самое время приступать к тестированию приложения 😎

Провожу Smoke Testing. Это базовая проверка системы, чтобы убедиться — приложение запускается, а основные функции работают. Его главная цель — определить, стоит ли проводить дальнейшее, более глубокое тестирование. Тест не выявил проблем, приступаю к основным проверкам.

Проверяю функциональность по чек-листам и тест-кейсам. Поведение системы соответствует ожидаемому результату. Фиксирую итоги в задаче в Jira (платформа для управления проектами) и отправляю ее в статус Merge. Затем разработчику предстоит замерджить задачу, то есть «слить» свой код в общую ветку проекта. В некоторых командах есть правило делать ретест задачи после мерджа. Затем ее закрывают. На этом работа над задачей завершается.

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

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

Тестирование по-прежнему считается легким входом в IT. Однако мои знакомые junior-специалисты рассказывают, что рынок найма остаётся сложным для новичков из-за большого количества кандидатов и возросших требований со стороны работодателей. Компании всё чаще ожидают от джуниоров понимания основ автоматизации тестирования, API, Docker, CI/CD, а также практического опыта, чаще от 1 года. Чтобы соответствовать этим ожиданиям, многие начинающие специалисты работают на пэт-проектах, получая таким образом практический опыт. Несмотря на сложности, мои собеседники убеждены — новичку реально найти работу, если подходить к процессу поиска системно: активно нарабатывать навыки, проявлять инициативу, быстро адаптироваться к требованиям рынка и, конечно, не отчаиваться.

Есть советы для ребят, которые только изучают область и собираются на первые собеседования?

На интервью кандидата оценивают с точки зрения hard skills и soft skills — это два типа навыков, которые важны для работы в любой профессии. Харды — они же жесткие навыки — это технические знания кандидата. Софты — или мягкие навыки — это личные качества, связанные с общением и работой в команде. Они помогают взаимодействовать с людьми и адаптироваться к разным ситуациям.

Мы уже обсудили, что рынок найма сильно изменился и к новичкам отныне выдвигают серьезные требования по хардам. Также список требований зависит от доменной области, специфики приложения, предпочтений работодателя. Я думаю, самый верный способ определить релевантные требования к позиции — это выбрать несколько компаний, в которых хочется работать, и, опираясь на эту информацию составить список технических навыков. Но, что по-прежнему остается неизменным, так это требования к софтам. Основываясь на собственном опыте, я думаю, тестировщик должен обладать следующими soft skills:

✅Быть внимательным, ответственным и честным

✅Уметь выстраивать коммуникацию с коллегами

✅Быть самостоятельным

✅Иметь тягу к самообразованию

✅Грамотно писать и ясно изъясняться

Самое интересное, что я хотела спросить - не надоело ли тебе ручное тестирование за столько лет? Существует стереотип, что это монотонная и рутинная работа.

Для меня тестирование — это интеллектуально нагруженная деятельность с высоким уровнем ответственности и большой ценой ошибки. Вместе с тем, в тестировании много творчества. Без креативного мышления невозможно придумать нетипичные пользовательские сценарии :) Нам постоянно приходится осваивать разные инструменты и технологии. Да, в нашей работе много рутины и одновременно много захватывающих сюжетов в борьбе за качество. Поэтому уверенно заявляю: за 7+ лет работы в профессии я люблю ее как в первый раз 🐞❤