Как создать систему управления тестированием для себя, а затем масштабировать это для коммерции

Автор: Никита Любимов, тестировщик в ИТ-компании QTIM

Личные проекты для разработчиков являются отдушиной при коммерческой разработке.

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

Во-вторых, разработчик сам решает, что и как ему писать, в таких проектах он не ограничен бизнес-требованиями.

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

Так, в свое время мне не нравилось, что для adb (android debug bridge) нет графического интерфейса на примере консоли в macOS, и приходилось в консоли использовать команды, для того чтобы отследить pid процесса, а после собирать из него логи. Поэтому я написал первый проект, который мне пригодился в работе. Это была графическая оболочка для adb (Gadb). Gadb написан на python c использованием tkinter, что позволяет ему взаимодействовать напрямую с командной строкой и создавать потоки для бесшовного обновления данных, что упростило мою работу. При этом стек технологий позволяет собрать его под любую платформу.

Так как первое время я работал на linux и macOS, со временем я понял, что мне не хватает скриншотера, который будет сразу выгружать скриншот в Яндекс.Диск и сразу представлять прямую ссылку на изображение. Мириться с этим я не особо хотел. Так был написан проект pyshooter для linux, также на python + tkinter. Это позволило мне создавать скриншоты, загружать их на Яндекс.Диск и получать публичную ссылку.

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

После того, как наш отдел пополнился, все это вести на смежных проектах стало еще труднее. Особенно ведение чек-листов под проект и тест-сценариев.

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

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

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

Сказано — сделано! Через неделю у меня уже был backend, реализованный на python + fastapi + tortoise OEM, который имел пространство и чек-листы для ручного тестирования. Для отображения в браузере (frontend) я выбрал vue 3 за его реактивность, поддержку и наличие очень большого количества фреймворков для расширений.

Изначально это выглядело как просто набор пространств (space) и падов (pad).

Также сразу были добавлены раны (run), которые создаются на основе чек-листов, и их элементы нельзя менять. Это нужно для просмотра истории, что и когда тестировалось, а также для просмотра статистики тестирования по проекту.

После чего она была локально протестирована на некоторых проектах, и я понял, что vtpad имеет право на свое существование.

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

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

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

Как оказалось, open telemetry очень хорошо дружит с python, fastap и postgresql. Поэтому буквально после семи строчек кода получилось собрать трассировку с сервиса.

После увиденных первых запросов и метрики можно сказать, что если вы думаете, что вам не нужен jaeger, то вам нужен jaeger! Почему же он может помочь в оптимизации приложения, не только построенного на микросервисах, но и монолита?! Все просто. Он показывает длительность ваших запросов и длительность запросов к сторонним сервисам. То есть, если у вас монолит, и вы правильно настроили jaeger, то он покажет:

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

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

В ближайшее время мы внедрим диаграмму Ганта и дашборды.

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

Для удобства коллег управление реализовано через горячие клавиши.

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