В Ozon хорошо развита инфраструктура и Go-сообщество. В большинстве случаев мы пишем микросервисы как раз на Go, и если тесты написаны на другом языке, разработчики не могут внести в них свой вклад или отревьюить их. Поэтому внутри Ozon активно развивается Go-сообщество QA: копим экспертизу, пишем собственные фреймворки и опенсорс-библиотеки, делимся экспертизой на бесплатных курсах.
Немного контекста
Нагрузки
Хайлоад для нас не пустое слово: 90 млн уникальных пользователей, в распродажи выдерживаем 5к заказов в минуту, а сейчас готовимся к новым таргетам. При таком масштабе мы тестируем релиз за пять минут и делаем больше сотни релизов в день.
О QA в Ozon
Немного о нашем стеке: браузерные тесты пишем на TypeScript, бэкенд-тесты — на Go, Python, C#.
В Mobile QA Automation используем Appium и Python.
Почему тестируем на Go?
QA-инженеры работают в одной среде с разработчиками.
Разработчики чаще обращаются к тестам, потому что их легче запускать, а при необходимости можно починить и исправить.
В тестах мы стали использовать подходы и библиотеки наших разработчиков.
За счет гибкого использования параллельности в тестах, увеличилась скорость выполнения тестов. Go сам по себе быстро компилируемый и исполняемый язык разработки.
Низкий порог входа: Go прост в изучении и применении, особенно если разработчик рядом.
Ложка дёгтя: минусы
Не всегда есть привычный инструментарий. При написании тестов мы столкнулись с некоторыми проблемами, в итоге разработали инструменты для тестирования микросервисов. Например, сервис QAAPI или опенсорс-библиотеку Allure-Go.
Недостаток готовых специалистов на рынке. Найти тестировщика со знанием Go достаточно тяжело, поэтому мы делимся эскпертизой с разработчиками и тестировщиками на наших курсах Route 256.
В программе
Сергей Макаров
Старший Go-разработчик, Ozon
Go, Allure и HTTP, или Как мило тестировать HTTP-сервисы на Go
Расскажу, как мы решили облегчить тяготы наших тестировщиков и создать инструмент для тестирования HTTP-сервисов с проверкой отчётов в Allure, который в итоге перерос в опенсорс-библиотеку.
Василий Юдин
Инженер в команде Авито
Как подружить QA и разработку через применение практики хранения тестов в коде
Заводить руками тест-кейсы в тестохранилках долго и уныло. А ещё есть много юнит-тестов, которые пишут разработчики, и не всегда понятно, что они покрывают и как пересекаются с E2E-тестами.
Эти две проблемы мы решили комплексно, сделав систему, которая ищет и выгружает все-все-все тесты из кода приложений и агрегирует в понятное покрытие тестируемой системы. Расскажу также, как этот подход не только сократил трудозатраты и дублирование работы, но помог сделать некоторые культурные сдвиги.
Круглый стол «Профессия QA»
Спикеры из Ozon, Авито, Skyeng и Mirantis
Обсудим, как войти в профессию автотестирования и построить карьерный путь.
Вести и модерировать встречу будет Игорь Любин @ilyubin (Ozon).
Встречаемся 13 июля 18:00, онлайн и оффлайн.
➡️ Регистрируйтесь, приходите в гости в Москва Сити или подключайтесь онлайн.
Если не успеете — ищите запись на Youtube.
Бонус: дайджест полезных статей о QA в Ozon Tech
Автоматизация тестирования микросервисов: плюсы и минусы тестов на Go
Go, Allure и HTTP, или Как мило тестировать HTTP-сервисы на Go
Приходите на бесплатные курсы от экспертов Ozon:
Комментарии (7)
stopper79
08.07.2022 19:02Тесты нужно писать, на ЯП на котором написан код, я понимаю, что тесты можно писать на все, что угодно, но когда автоматзатор уходит(например, в отпуск) будет некомфорт
DimaKolesnik
08.07.2022 19:03+1Мы стараемся максимально автоматизировать нашу работу. Как раз когда QA инженер уходит в отпуск тесты продолжают работать. Также из-за того, что тесты написаны на языке разработки - сами разработчики могут поддерживать тесты
stopper79
08.07.2022 19:19А вот тут, у вас проблема, у вас нет разделения тестировщик и разработчик. Это в корне неверно, по моему опыту, разраб говорит на моей машине все ОК, но нормальный тестировщик проверит в изоляте.
stopper79
08.07.2022 19:22Да и еще, разрабы не будут поддерживать тесты, ну может кроме unit, это не их работа, на PET проекте возможно, но он будет тратить время тесты вместо кода :)
stopper79
08.07.2022 19:40Ну и напоследок, делите бэк, фронт, мобайл на микросервисы которые больше всего подходят под задачи, и покрываются тестами на их ЯП
toolateitsme
Просто интересно, зачем вам такой зоопарк языков в отделе QA? Как вы работаете с бас-фактором? Как наращиваете компетенции сотрудников в таком большом разбросе по технологиям?
Не завидую сотруднику QA отдела в OzonTech, которому, потенциально, внезапно придется переключить контекст подобного рода
DimaKolesnik
Привет! Я руковожу группой разработки инструментов тестирования.
В нашей компании нет выделенного отдела QA, мы работаем в кросс-функциональных командах. В нашем масштабе тяжело назвать это зоопарком: в компании 3800+ специалистов. К тому же, мы можем набирать специалистов с разным опытом.
Также не могу сказать, что у нас сильно выражен бас-фактор: мы много времени уделяем документации, в командах есть технические писатели. Компетенции сотрудников развиваем через наставничество и обучение (есть внутренние курсы и также отправляем на внешние курсы по запросы).