Контроль качества ПО в разработке — это база

В Девелонике и Test IT тестировщики работают над разными проектами и продуктами, используют собственные инструменты и участвуют в разработке платформы для управления тестированием. За каждой зеленой галочкой — люди и их профессиональный путь. Мы спросили коллег, как они пришли в профессию, что в ней оказалось совсем не таким, как они ожидали, и какие вопросы о своей работе они слышат чаще всего.

Ким Дмитрий, инженер по тестированию

Как ты пришел в тестирование?

В студенческие годы мой боевой товарищ по университету в один день сказал, что в компании открылась вакансия тестировщика и это моя судьба. Я, тогда еще не знавший, что такое прод, согласился. Доверился другу — и не прогадал. Спасибо ему огромное!

Что ты представлял себе до того, как начал работать в профессии?

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

А что оказалось совсем не таким, как ожидал?

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

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

Распространенный стереотип — тестировщик просто нажимает на кнопки

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

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

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

Сотрудники единогласно сошлись во мнениях, что у профессии точно есть своя философия и собственный «вайб». Одни сравнили ее с поднятием в гору и адреналином, когда при запуске релиза и прогоне все работает как нужно. Другие признались, что после пробы карьерного трека в разработке и аналитике нашли себя именно в тестировании, потому что тут есть четкая системность, скрупулезность и перфекционизм.

Интересно то, что никогда не знаешь, где найдешь ошибку

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

Логинов Артем, старший инженер по тестированию.

Как ты обычно начинаешь проверять новую задачу?

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

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

Все чаще стал планировать и приоритизировать бытовые заботы, а еще очень часто употребляю слово «вероятно»).

За счет специфики заказной разработки в Девелонике часто нет одного продукта, одного набора задач и одного типа проверок. Инженеры по тестированию могут работать с разными проектами, технологиями и командами. Это влияет и на профессиональный рост: приходится постоянно разбираться в новых предметных областях и искать подход к разным продуктам.

Новокщенова Анна, инженер по тестированию

Какой проект или задача за последнее время запомнились тебе больше всего?

За последнее время запомнилась задача по продукту для кадрового учета: с большими сроками и очень объемным скоупом. Примерно три месяца мы занимались приемкой.

С чем было сложнее всего разобраться? А что, наоборот, оказалось неожиданно интересным?

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

Своя платформа тоже требует тестирования

С 2024 года бренд развивает платформу для управления тестированием Test IT. Часть команды Девелоники работает с продуктом, которым пользуются сами тестировщики. Получается довольно практичный цикл: специалисты знают задачи изнутри, используют платформу в работе и могут влиять на то, как она развивается.

Никифоров Сергей, Lead QA Test IT («Девелоника», акционер — ГК Softline)

Что для тебя важно в инструменте, которым ты пользуешься каждый день? Какую функциональность особенно часто используешь?

Самое страшное для руководителя — превратиться в чайку. Чайка-менеджмент портит отношения с командой, усложняет взаимодействие с коллегами и просто отравляет атмосферу в коллективе.
Я бы выделил три вещи, которые я могу благодаря платформе. Во-первых, узнать, какое тестирование планируется на каждое новое изменение продукта, потому что Test IT встроена в процесс тест-анализа. Ребята создают тест-планы, которые я вижу в асинхронном режиме, и эти тесты проходят через ревью (от меня и других QA в команде). Я спокоен и уверен, что каждая задача будет протестирована, и могу даже проверить, как именно.
Потом — гибко управлять релизным процессом, то есть видеть, в каких частях (компонентах/сервисах) были изменения, и свести их с иерархией в платформе. Не нужно прогонять каждый раз абсолютно полный регресс продукта для быстрых релизов в Cloud, что экономит ресурсы QA и не тормозит продуктовые команды в разработке новых фичей, что заметно повышает time-to-market.
Управлять изменениями. Все процессы, все изменения (как культурные, так и, например, кадровые) должны строиться на основе цифр. Благодаря нашему новому модулю аналитики и метрикам, которые там есть, я могу лучше планировать как тестирование продукта, так и изменения, которые мне нужны в команде/процессах. Отстаивать свои интересы и выбивать ресурсы можно и нужно только с конкретными цифрами, и платформа сейчас в этом помогает.
Конечно, это не все, я не упомянул ежедневные прогоны автотестов и аналитику по ним, планирование автоматизации и т. д. Платформа управления тестированием очень многими воспринимается только как БД, в которой лежат тест-кейсы, но задача хорошего lead QA — превратить это в рабочую структуру, помощь от которой ощущается на каждом этапе SDLC.

Было ли такое, что ты сам предложил изменение, которое потом появилось в продукте?

Да, есть несколько фич. И те, в рамках которых я участвовал в фокус-группе, и такие, что мы предлагали на реализацию. Лично я горжусь тем, что предложений от моей команды гораздо больше, чем от меня лично: QA в testit.software любят свой продукт и заносят в бэклог столько, сколько еще не может переварить наша разработка))
Из последнего, что я могу вспомнить, это как раз работа с «Аналитикой+». Я считаю это отличным усилением платформы, однако его явно еще нужно дорабатывать как на основе практического нашего опыта, так и на основе опыта и фидбека клиентов Test IT.

Бонус: 4 навыка обязательных в тестировании

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

1. Системное мышление
   Тестировщику важно видеть не только отдельную функцию, но и связи между требованиями, бизнес-логикой, компонентами системы и пользовательским сценарием. Поэтому работа начинается не с кнопок, а с вопросов: что должно произойти, почему именно так и что изменится, если пойти другим путем.
2. Внимательность и исследовательский подход
   Хороший тестировщик постоянно проверяет границы привычного сценария: «а что, если?..». Найти ошибку часто означает заметить небольшую деталь, сопоставить несколько фактов и проверить гипотезу, которую до этого никто не рассматривал.
3. Коммуникация
   Качество ПО зависит не только от того, что именно нашел тестировщик, но и от того, насколько точно он может это объяснить команде. Требования, дефекты, риски, результаты проверок и приоритеты нужно обсуждать с разработчиками, аналитиками, менеджерами и другими участниками проекта на одном языке.
4. Работа с ИИ и новыми инструментами
   Технологии постепенно меняют и сам процесс тестирования. ИИ помогает ускорять отдельные операции, работать с большим объемом информации, создавать тестовые сценарии и анализировать результаты. Но ценность специалиста по-прежнему определяется тем, насколько он понимает задачу и способен критически оценить полученный результат.