Роман Яковлев работал специальным корреспондентом, а в июне 2024 года пришел в «Нанософт» ручным тестировщиком. Вскоре он начал предлагать изменения в рабочих процессах. Руководство поддержало его предложение внедрить систему управления тестированием, а примерно через год после прихода в компанию он возглавил группу. Поговорили с Романом о том, как упорядочить тысячи тестов, замечать ошибки, для поиска которых нужен инженерный опыт, и помогать сотрудникам осваивать теорию и практику тестирования.
— Роман, до «Нанософт» вы работали в сфере журналистики. Как решили сменить профессию?
Я работал в молодежной политике, затем в маркетинге, а перед переходом в ИТ был специальным корреспондентом. Сотрудничал с изданиями и телеканалами, недолго руководил небольшим филиалом областного телеканала в своем городе.
В какой-то момент почувствовал, что хочу попробовать себя в другой сфере. Посоветовался со знакомыми, которые работают в информационных технологиях, и начал самостоятельно учиться.
При этом техническая область не была для меня совершенно новой. По образованию я инженер геоинформационных систем.
В конце июня 2024 года пришел в «Нанософт» на позицию ручного тестировщика продуктов для землеустройства. Осваивать программы помогали справочные материалы и более опытные коллеги.
— Как появилась возможность возглавить группу? Вы сами к этому стремились?
Специально руководящую должность я не просил, но и на предыдущих работах рано или поздно начинал заниматься организацией процессов и взаимодействием с людьми.
В «Нанософт» я довольно быстро стал предлагать идеи. Еще будучи рядовым тестировщиком, видел, что они находят отклик у руководства. Постоянно, скажем так, наводил определенную суету. Возможно, это тоже заметили.
Назначение я воспринял как большой аванс доверия: все произошло достаточно быстро, примерно за год.
— Какие продукты тестирует ваша группа и как распределены задачи?
Мы тестируем продукты отдела перспективных разработок. В зоне ответственности группы — модуль «Топоплан» в составе Платформы nanoCAD, приложение nanoCAD Землеустройство с конфигурациями «Топография», «Трассы» и «Сети», а также nanoCAD Облака точек с конфигурациями «Метрология» и «Геотехнический мониторинг». Кроме того, проверяем веб-продукты PointCloudVault и nanoView.
В группе восемь сотрудников, включая меня. Тестировщики закреплены за определенными продуктами, хотя при необходимости подключаются и к другим направлениям. Я организую работу, помогаю коллегам развиваться и определяю, какие инструменты нам нужно осваивать дальше.
— Какую из ваших инициатив удалось реализовать?
Я предложил внедрить систему управления тестированием. Продуктов становилось больше, и было все сложнее ориентироваться в существующих тестах. Отдельной системы для работы с ними не было: тестировщики пользовались только багтрекинговой системой, в которой хранятся описания ошибок. Это удобный инструмент, но мне не хватало структуры тестовой документации и отчетов, которые помогали бы понять, что можно улучшить в работе над качеством.
Сначала я сам развернул в тестовом окружении готовую систему управления тестированием с открытым исходным кодом, разработанную сторонней инженерной компанией. Изучил ее возможности и понял, что она нам подходит.
В TMS можно вести и упорядочивать тестовую документацию, составлять тест-планы и назначать проверки сотрудникам. Есть открытый API, возможности настройки и подключения плагинов. Результаты автотестов можно собирать через API или с помощью Allure-отчетов.
Руководство одобрило идею. Через некоторое время к департаменту присоединился коллега с большим опытом разработки инструментов тестирования. Он тоже поддержал инициативу, и TMS быстро вошла в работу.
Система помогла упорядочить проверки: стало проще распределять задачи, отслеживать их выполнение и анализировать результаты. Сейчас в TMS хранятся десятки тысяч тестов. Системой пользуются почти во всех отделах департамента разработки.
— Что нужно понимать в работе инженера, чтобы тестировать его инструменты?
Важно знать, зачем человеку программа и что он собирается в ней делать. Тестировщику нужно понимать основные пользовательские сценарии и уметь оценивать результат.
Например, при проверке инструментов для землеустройства мы создаем топографический план, размещаем условные знаки, добавляем подписи. В продуктах для работы с облаками точек — данными трехмерного сканирования — проверяем загрузку, обработку и классификацию этих данных. За каждой задачей стоят свои требования и особенности.
У многих сотрудников нашей группы есть профильное образование и практический опыт. Если человек сам занимался изысканиями, геодезией или работал на строительных объектах, ему будет проще заметить нюансы.
Этот опыт помогает и в обсуждениях с разработчиками: коллеги могут объяснить, зачем инженеру нужна определенная функция и как он будет с ней работать. Ведь важно убедиться не только в том, что инструмент исправен, но и в том, что он решает задачу пользователя.
— Был ли случай, когда команда формально выполнялась, но тестировщики из вашей группы замечали неверный результат?
Да, например, при проверке команды «Создание трассы по вершинам» в конфигурации «Трассы» приложения nanoCAD Землеустройство. Если пользователь вводит некорректные значения, программа должна предупредить его о проблеме. На первых двух иллюстрациях показан такой вариант: приложение сообщает о неверной длине переходных кривых и о том, что они не будут добавлены.
Но в одном из обновлений опытные профильные тестировщики обнаружили другой случай. При некорректных исходных данных предупреждение не появлялось, а команда формально выполнялась. При этом самой трассы на чертеже не было — вместо нее создавался набор «пустых» объектов.
Коллеги обсудили ситуацию с разработчиком и решили добавить понятные подсказки для пользователя. Они должны объяснять, что построение не удалось из-за введенных значений, а не потому, что сама функция не работает. Эти пояснения внесли и в справку, где можно подробнее узнать об особенностях команды.
— Вы также подготовили внутренний курс. Зачем он понадобился и чему учит?
Иногда в команду приходят люди, которые хорошо понимают инженерную сторону продукта, но пока не знакомы с теорией тестирования. У них другой профессиональный опыт, и курс помогает восполнить недостающие знания.
Он называется «Академия тестировщиков». Пока существует в текстовом виде, и мы используем его внутри группы. В нем собраны основные темы и ссылки на дополнительные материалы. Коллеги самостоятельно изучают материалы. Если у них возникают вопросы, мы созваниваемся и разбираем их вместе.
Курс охватывает работу в TMS, основы тестирования, веб и клиент-серверное взаимодействие, API, REST и gRPC, инструменты Postman, Bruno и DevTools. Есть практические задания и итоговое тестирование.
Среди других практических тем — выбор тестов для автоматизации, Code Review для тестировщика и подготовка итогового отчета. Также предусмотрены сквозная задача и самостоятельный мини-проект.
Планирую дополнять курс новыми разделами. В повседневной работе видно, какие вопросы повторяются. Если собрать объяснения и примеры в одном месте, новичкам будет проще освоиться, а опытным коллегам не придется каждый раз разбирать одно и то же с нуля.
