Из спецкоров — в тимлиды: как Роман Яковлев за год прошел путь от новичка до руководителя группы тестирования

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

— Роман, до «Нанософт» вы работали в сфере журналистики. Как решили сменить профессию?

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

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

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

В конце июня 2024 года пришел в «Нанософт» на позицию ручного тестировщика продуктов для землеустройства. Осваивать программы помогали справочные материалы и более опытные коллеги.

— Как появилась возможность возглавить группу? Вы сами к этому стремились?

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

В «Нанософт» я довольно быстро стал предлагать идеи. Еще будучи рядовым тестировщиком, видел, что они находят отклик у руководства. Постоянно, скажем так, наводил определенную суету. Возможно, это тоже заметили.

Назначение я воспринял как большой аванс доверия: все произошло достаточно быстро, примерно за год.

— Какие продукты тестирует ваша группа и как распределены задачи?

Мы тестируем продукты отдела перспективных разработок. В зоне ответственности группы — модуль «Топоплан» в составе Платформы nanoCAD, приложение nanoCAD Землеустройство с конфигурациями «Топография», «Трассы» и «Сети», а также nanoCAD Облака точек с конфигурациями «Метрология» и «Геотехнический мониторинг». Кроме того, проверяем веб-продукты PointCloudVault и nanoView.

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

— Какую из ваших инициатив удалось реализовать?

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

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

В TMS можно вести и упорядочивать тестовую документацию, составлять тест-планы и назначать проверки сотрудникам. Есть открытый API, возможности настройки и подключения плагинов. Результаты автотестов можно собирать через API или с помощью Allure-отчетов.

Руководство одобрило идею. Через некоторое время к департаменту присоединился коллега с большим опытом разработки инструментов тестирования. Он тоже поддержал инициативу, и TMS быстро вошла в работу.

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

— Что нужно понимать в работе инженера, чтобы тестировать его инструменты?

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

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

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

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

— Был ли случай, когда команда формально выполнялась, но тестировщики из вашей группы замечали неверный результат?

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

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

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

— Вы также подготовили внутренний курс. Зачем он понадобился и чему учит?

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

Он называется «Академия тестировщиков». Пока существует в текстовом виде, и мы используем его внутри группы. В нем собраны основные темы и ссылки на дополнительные материалы. Коллеги самостоятельно изучают материалы. Если у них возникают вопросы, мы созваниваемся и разбираем их вместе.

Курс охватывает работу в TMS, основы тестирования, веб и клиент-серверное взаимодействие, API, REST и gRPC, инструменты Postman, Bruno и DevTools. Есть практические задания и итоговое тестирование.

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

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