Привет! Я Александр Зырянов, проектный менеджер TestY и QA-менеджер в департаменте контроля качества YADRO. Тест-менеджмент системе TestY, которая доступна в open source любой команде и компании, скоро два года. Мы готовим крупный релиз 2.0 с масштабными изменениями, в том числе дизайна интерфейса.

А пока в качестве «аппетайзера» я расскажу про последние обновления к релизу 1.3.4. Среди них — bulk-операции, пуш-уведомления пользователей, доработка кастомных атрибутов и статусов. Подробнее о каждом — под катом. Устанавливайте TestY и испытайте в работе нашу открытую систему. 

Всем привет! Меня зовут Роман Кабаев, я инженер в отделе разработки инструментов тестирования компании YADRO. Вместе с коллегами мы разрабатываем собственную тест-менеджмент систему с открытым исходным кодом TestY.

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

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

Спойлер: камнем преткновения для нас стали CPU-bound задачи с большим количеством данных, о том, как я это выяснил, расскажу ниже. Изучив, как можно ускорить выполнение таких задач в Python, я протестировал несколько решений и нашел оптимальное. Если вы разрабатываете веб-приложение на Django или Python и так же, как я, хотите ускорить работу сервиса, читайте эту статью.

В конце прошлого года мы представили TestY, тест-менеджмент систему с открытым исходным кодом, которую разработала команда YADRO на замену TestRail.

Сегодня на связи я, Александр Зырянов, QA-менеджер в департаменте контроля качества YADRO и проектный менеджер TMS TestY. После первого текста о нашей системе вы обращались к нам с вопросами и пожеланиями. Некоторые предложения мы уже планировали в новый релиз, но были и те, что мы взяли в работу именно благодаря вашей обратной связи. В этой статье расскажу о фичах, вышедших в релизе 1.3, и отвечу на вопросы о TestY в комментариях.

Привет! Меня зовут Никита Гуцалов, я инженер в компании YADRO и занимаюсь разработкой ПО для системы хранения данных TATLIN.UNIFIED. Вообще с системами хранения данных (СХД) я работаю уже много лет и люблю эту тему, поскольку она постоянно бросает новые вызовы, заставляя решать довольно сложные и нестандартные проблемы, что очень увлекательно само по себе, а удачные решения приносят огромное удовлетворение.


В статье я попытаюсь погрузить читателя в проблемы, с которыми нам, инженерам YADRO, приходится сталкиваться при отладке программного обеспечения СХД. Также покажу особенности работы с такими системами. Расскажу, какие инструменты, а иногда и решения, которые мы пишем сами, приходится для этого применять. А еще постараюсь сформулировать условия, которые необходимы для нахождения причин возникновения ошибок обработки данных в системе.

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

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

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

Всем привет! Меня зовут Александр Волков, я занимаюсь интеграционным и компонентным тестированием в YADRO. В числе продуктов компании есть системы хранения данных и, говоря о тестировании, я буду иметь в виду в первую очередь работу с СХД. Однако описанные подходы пригодятся всем, кто ищет инструменты для создания тестового фреймворка и расширения его возможностей под свои задачи. 

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

В прошлом году TestRail прекратил предоставлять и продлевать лицензии компаниям из России, поэтому мы в YADRO решили разработать собственную тест-менеджмент систему TestY. Опирались на опыт работы с другими сервисами, чтобы добавить тот функционал, которого не хватало нашим командам тестирования. За несколько месяцев написали core-часть системы и выложили ее в open source, чтобы другие компании и разработчики, для которых актуален вопрос лицензионной чистоты используемого софтай, пользовались решением и развивали его.

В этой статье рассказываем об отличиях TestY от других TMS и преимуществах нашей системы для команд любого размера. Спойлер: в TestY могут одновременно работать 300 тестировщиков — система справляется. Для тех, кто хочет опробовать TestY в своей команде, в конце статьи есть короткая инструкция, как ее развернуть.