Первым делом я должен кинуть в вас ссылкой на наш Хабр, чтобы, если вдруг ещё не, то вы узнали о нас чуть больше — habr.com/company/avito
Habr
AvitoTech, Москва - У нас живут ваши объявления / Articles
No articles from AvitoTech company authors
Здесь я буду рассказывать о нашей рутине, о жизни платформенных юнитов внутри продуктовой компании, о планах нашей команды, о ежедневных решениях. Иногда я буду копипастить итоги стендапов 😜
Как раз завтра у нас будет конец первого спринта (которые у нас длятся неделю). Расскажу о довольно важной для нас фиче, которую мы запилили (если успеем до демо, конечно 😶)
Итак, пятница. В 13:30 демо, потенциальные пользователи приглашены. Мы даже что-то сделали, но наш бёрндаун какой-то не очень бёрн. Ещё и багуля повисла в воздухе.
Успеем ли?
Успеем ли?
Прошло демо. К нам пришли ребята из нескольких юнитов. Собственно, что мы им показали:
- щупальца для автотестов;
- упрощенное создание тест-кейса.
Про каждую фичу расскажу в отдельном треде попозже.
- щупальца для автотестов;
- упрощенное создание тест-кейса.
Про каждую фичу расскажу в отдельном треде попозже.
Итак, щупальца! Что это такое? И почему так называются?
Сначала про название. Нашу тестохранилку мы нежно называем Ктулху. Она как исполинская махина из рассказов Лавкрафта может всюду пробраться и достать кого или что угодно.
Щупальца — это механизм, который ходит по репозиториям и собирает из них все автотесты, превращая их в тест-кейсы в Ктулху
Зачем оно нам?
Далеко не всегда имеет смысл сначала писать тест-кейс, а затем автоматизировать его, особенно, если это тесты на API. Но представлять текущую ситуацию с покрытием нужно.
Причем не процент покрытия кода, а покрытие фичи разными тестами. Это большая история про agile testing и весь этот ваш shift left.
Сначала про название. Нашу тестохранилку мы нежно называем Ктулху. Она как исполинская махина из рассказов Лавкрафта может всюду пробраться и достать кого или что угодно.
Щупальца — это механизм, который ходит по репозиториям и собирает из них все автотесты, превращая их в тест-кейсы в Ктулху
Зачем оно нам?
Далеко не всегда имеет смысл сначала писать тест-кейс, а затем автоматизировать его, особенно, если это тесты на API. Но представлять текущую ситуацию с покрытием нужно.
Причем не процент покрытия кода, а покрытие фичи разными тестами. Это большая история про agile testing и весь этот ваш shift left.
Так-так, что у нас дальше? Упрощённое создание тест-кейса.
Полный путь выглядит так: зайти на главную, выбрать проект/платформу, создать ветку (вписать номер задачи из JIRA, скопировать заголовок из неё же), дождаться загрузки страницы ветки, перейти на экран создания тест-кейса.
Многовато.
Мы просто добавили в шапку маленький контрол, вызываемый по хоткею, где в два удара головой по клавиатуре можно выбрать платформу, ветку (если ветка не существует, она будет прозрачно создана и все подтянется из JIRA) и оказаться сразу на странице создания тест-кейса.
Конечно же, так как мы супер фронтендеры, у этого компонента оказался баг, создающий лишние ветки с кривым названием, когда его об этом не просят 😂
Надо бы в понедельник до планирования починить.
Что такое ветки, откуда они взялись в тестохранилке и почему их так любят наши тестировщики я обязательно как-нибудь расскажу
Полный путь выглядит так: зайти на главную, выбрать проект/платформу, создать ветку (вписать номер задачи из JIRA, скопировать заголовок из неё же), дождаться загрузки страницы ветки, перейти на экран создания тест-кейса.
Многовато.
Мы просто добавили в шапку маленький контрол, вызываемый по хоткею, где в два удара головой по клавиатуре можно выбрать платформу, ветку (если ветка не существует, она будет прозрачно создана и все подтянется из JIRA) и оказаться сразу на странице создания тест-кейса.
Конечно же, так как мы супер фронтендеры, у этого компонента оказался баг, создающий лишние ветки с кривым названием, когда его об этом не просят 😂
Надо бы в понедельник до планирования починить.
Что такое ветки, откуда они взялись в тестохранилке и почему их так любят наши тестировщики я обязательно как-нибудь расскажу
На этой неделе наша основная цель — добить историю с щупальцами web авто-тестов, чтобы на следующей неделе забороть API и подвигать квартальные цели.
Конечно, не обошлось и без багов. Тот пятничный баг не починился до планирования, а мы еще и планирование подвинули на час раньше. Еще у нас в монолите есть скрипт, который проставляет статусы автоматизации в TMS и он сбривал автоматизацию всем «щупальцевым» тестам. Неприятно.
Ну и до кучи мы на планировании забыли взять одну жирную таску про «мета-ручку», куда щупальце сможет засылать полотно тест-кейсов, а тестохранилка уже сама решит, что удалять, а что обновлять.
В общем, во всяком случае на этой неделе нет внезапных праздников, про которые мы забыли, поэтому есть надежда все успеть. Даже то, что было докинуто.
И вы тут, если что, задавайте вопросы всякие, на что акцент сделать, чего рассказать и всякое такое.
Конечно, не обошлось и без багов. Тот пятничный баг не починился до планирования, а мы еще и планирование подвинули на час раньше. Еще у нас в монолите есть скрипт, который проставляет статусы автоматизации в TMS и он сбривал автоматизацию всем «щупальцевым» тестам. Неприятно.
Ну и до кучи мы на планировании забыли взять одну жирную таску про «мета-ручку», куда щупальце сможет засылать полотно тест-кейсов, а тестохранилка уже сама решит, что удалять, а что обновлять.
В общем, во всяком случае на этой неделе нет внезапных праздников, про которые мы забыли, поэтому есть надежда все успеть. Даже то, что было докинуто.
И вы тут, если что, задавайте вопросы всякие, на что акцент сделать, чего рассказать и всякое такое.
Что-то я затянул с постом в этот канал, хотя уже давно всё запостил в твиттере, исправляюсь.
Цель спринта спасена! Теперь я расскажу вам про ветки.
У нас в тестохранилке с ветками довольно просто — есть master, который представляет собой «состояние на проде», а есть «другие» ветки, которые, соответственно, представляют собой либо состояние продуктовой задачи, либо какой-то рефакторинг тест-кейсов. То есть мы всегда можем зайти и посмотреть, как что работает на проде.
Немного про ”кишки” веток. Это такой типа Git на MySQL с пачкой упрощений. Предотвращая ваши вопросы — создавать ветки можно только из мастера и мержить только в мастер.
Создаешь ветку, в базе появляется новая запись о ветке, у которой инкрементится branch_timeline_id, это у нас что-то типа ревизий. Когда переходишь на страницу ветки, на ней загружаются все кейсы, которые привязаны к текущему branch_timeline_id и все оставшиеся из мастера.
Благодаря этому при создании ветки тест-кейсы не копируются из мастера в ветку. Они копируются только при редактировании. Бесплатным бонусом это дает фичу «прозрачное автоподмерживание мастера».
Т.е. все тест-кейсы, которые не редактировались, в ветке всегда отображаются свеженькими, даже если в мастер что-то вмержилось после создания текущей рабочей ветки.
Внутри есть древний маленький баг — если тест-кейс редактируется одновременно в двух разных ветках, то после мержа обеих в мастере будет точно такой, какой был в последней вмерженной ветке.
Раньше, когда у нас в компании была вертикальная структура, это был довольно досадный баг, он редко стрелял, но было обидно.
Сейчас же, как мы разделились на юниты, проблема сошла на нет, т.к. каждый юнит, каждая команда в нем владеет своим конкретным куском тестовой модели и не лезет к чужим тест-кейсам.
За последние несколько кварталов я не могу вспомнить ни одного подобного инцидента.
Цель спринта спасена! Теперь я расскажу вам про ветки.
У нас в тестохранилке с ветками довольно просто — есть master, который представляет собой «состояние на проде», а есть «другие» ветки, которые, соответственно, представляют собой либо состояние продуктовой задачи, либо какой-то рефакторинг тест-кейсов. То есть мы всегда можем зайти и посмотреть, как что работает на проде.
Немного про ”кишки” веток. Это такой типа Git на MySQL с пачкой упрощений. Предотвращая ваши вопросы — создавать ветки можно только из мастера и мержить только в мастер.
Создаешь ветку, в базе появляется новая запись о ветке, у которой инкрементится branch_timeline_id, это у нас что-то типа ревизий. Когда переходишь на страницу ветки, на ней загружаются все кейсы, которые привязаны к текущему branch_timeline_id и все оставшиеся из мастера.
Благодаря этому при создании ветки тест-кейсы не копируются из мастера в ветку. Они копируются только при редактировании. Бесплатным бонусом это дает фичу «прозрачное автоподмерживание мастера».
Т.е. все тест-кейсы, которые не редактировались, в ветке всегда отображаются свеженькими, даже если в мастер что-то вмержилось после создания текущей рабочей ветки.
Внутри есть древний маленький баг — если тест-кейс редактируется одновременно в двух разных ветках, то после мержа обеих в мастере будет точно такой, какой был в последней вмерженной ветке.
Раньше, когда у нас в компании была вертикальная структура, это был довольно досадный баг, он редко стрелял, но было обидно.
Сейчас же, как мы разделились на юниты, проблема сошла на нет, т.к. каждый юнит, каждая команда в нем владеет своим конкретным куском тестовой модели и не лезет к чужим тест-кейсам.
За последние несколько кварталов я не могу вспомнить ни одного подобного инцидента.
Новая неделя — новый спринт. За эту неделю хотим добить всякий разный техдолг. А самое главное — сделать одно из последних важных щупалец для монолита, которое будет собирать API автотесты.
Ставим цели на следующий квартал. Будет много щупалец. Очень много. Под все наши платформы!
Щупальца крутятся, тест-кейсы мутятся 😎👌
Щупальца крутятся, тест-кейсы мутятся 😎👌
Маленькие приятности работы в платформенной команде — вы только собрались что-то делать в следующем квартале, а соседняя платформенная команда уже всячески вам с чем-то помогает (возможно, не нарочно).
Например, с щупальцами для компонентных тестов фронта 🙂
Например, с щупальцами для компонентных тестов фронта 🙂
Пятница, конец третьего спринта.
Вот что мы сделали.
- Для монолита есть щупальца для всех типов тестов, кроме юнитов.
- Сделали автоматическую генерацию tmsExternalID в монолите (об этом попозже).
- Добавили на пулл-реквесты линтер tmsExternalID
Вот что мы сделали.
- Для монолита есть щупальца для всех типов тестов, кроме юнитов.
- Сделали автоматическую генерацию tmsExternalID в монолите (об этом попозже).
- Добавили на пулл-реквесты линтер tmsExternalID
Всем привет! Я вернулся из отпуска и продолжаю писать.
На прошлой неделе мы таки научились выгружать e2e тесты iOS, а ещё прикрутили к щупальцам mypy и прочие линтеры.
На этой неделе сделаем то же самое и для Android.
Еще на этой неделе я постараюсь подробнее рассказать вам о щупальцах: как они работают, почему именно они и вообще всё-всё, что с ними связано. А то пишу про них очень много, но подробностей никаких.
На прошлой неделе мы таки научились выгружать e2e тесты iOS, а ещё прикрутили к щупальцам mypy и прочие линтеры.
На этой неделе сделаем то же самое и для Android.
Еще на этой неделе я постараюсь подробнее рассказать вам о щупальцах: как они работают, почему именно они и вообще всё-всё, что с ними связано. А то пишу про них очень много, но подробностей никаких.
На нашем медиуме подъехала статья про тестохранилку
Forwarded from AvitoTech
У нас в Авито есть собственная система для управления тест-кейсами.
В чём её отличия от других тестохранилок:
🎋 ветки — это такой легкий Git на MySQL;
🅰 API для управления тест-кейсами и проверки статуса автотестов;
🌴 бесконечное дерево фич.
К тому же, система оптимизирована для кросс-функциональных команд.
В англоязычной статье на Медиуме Вадим Шашин рассказывает о том, как она устроена → http://bit.ly/2XRn3mv
В чём её отличия от других тестохранилок:
🎋 ветки — это такой легкий Git на MySQL;
🅰 API для управления тест-кейсами и проверки статуса автотестов;
🌴 бесконечное дерево фич.
К тому же, система оптимизирована для кросс-функциональных команд.
В англоязычной статье на Медиуме Вадим Шашин рассказывает о том, как она устроена → http://bit.ly/2XRn3mv
Так-с. Кажется, я обещался написать про щупальца.
Раньше происходило что-то такое: сначала пишется тест-кейс, затем он автоматизируется. Ну и вся поддержка и актуализация тоже двухэтапная.
Я бы не сказал, что мы были рады этому. Особенно, когда тестировщик сам автоматизировал свои тест-кейсы. Не удивительно, что у нас очень много тестировщиков ударились в написание автотестов.
Так вот. Зачем делать работу два раза, если можно ее сделать однажды? Подумали мы и начали размышлять, как что-то выкинуть из этого процесса.
Первое, что пришло в голову, — генерация автотестов. Очень уж это красиво и, кажется, что тестировщикам придётся писать меньше кода.
Короче говоря, идея провалилась. Слишком оверинжиниринг оказалась.
В чём была идея: сделать «разделяемые шаги», чтобы в разных тест-кейсах использовались одинаковые шаги по мере возможности.
Так мы могли бы автоматизировать шаг тест-кейса один раз и использовать его дальше в разных автотестах.
По факту получился большой монстр в виде огромного орграфа и сложной модели подсказки следующего шага тест-кейса.
Ведь нельзя просто так взять и использовать шаги в случайной последовательности.
В общем, мы отказались от этой идеи, так и не реализовав ее. Немного погрустили и придумали другой подход.
Мы заметили, что некоторые команды отказываются от использования ТМС, чтобы сэкономить своё время, пусть и жертвуя наглядностью своей тестовой модели.
Было решено: исследовать историю с «тест-кейсами в коде».
Если быть честным, сначала я был крайне скептически настроен к этой идее. Было непонятно, как держать синхронизированными деревья тестовой модели и сами тест-кейсы в разных репозиториях.
Думали над тем, чтобы сделать просмотрщик тест-кейсов, который бы брал автотесты из репозитория и наглядно отображал их.
В итоге мы сделали что-то похожее: если у нас есть уже работающая тестохранилка, которая дает свои бонусы, то почему бы не использовать ее? Тем более, что кто-то наверняка захочет продолжать вручную создавать тест-кейсы.
Так и родилась история с щупальцами. Это такие штуки, которые парсят автотесты (слегка особым образом размеченные) и загружают их в тестохранилку.
Логично, что автотесты из щупалец предоставляются только для чтения. Редактировать их через интерфейс тестохранилки — нельзя.
В итоге те команды, которые отказались от использования тестохранилки, потратили примерно час на разметку автотестов (чтобы проставить идентификаторы фичей), и их кейсы появились в ТМС.
Сейчас мы все еще продолжаем наращивать «щупальцевую массу». Наша текущая цель — «любая проверка в Авито должна быть в тестохранилке и сматчена на тестовую модель».
Раньше происходило что-то такое: сначала пишется тест-кейс, затем он автоматизируется. Ну и вся поддержка и актуализация тоже двухэтапная.
Я бы не сказал, что мы были рады этому. Особенно, когда тестировщик сам автоматизировал свои тест-кейсы. Не удивительно, что у нас очень много тестировщиков ударились в написание автотестов.
Так вот. Зачем делать работу два раза, если можно ее сделать однажды? Подумали мы и начали размышлять, как что-то выкинуть из этого процесса.
Первое, что пришло в голову, — генерация автотестов. Очень уж это красиво и, кажется, что тестировщикам придётся писать меньше кода.
Короче говоря, идея провалилась. Слишком оверинжиниринг оказалась.
В чём была идея: сделать «разделяемые шаги», чтобы в разных тест-кейсах использовались одинаковые шаги по мере возможности.
Так мы могли бы автоматизировать шаг тест-кейса один раз и использовать его дальше в разных автотестах.
По факту получился большой монстр в виде огромного орграфа и сложной модели подсказки следующего шага тест-кейса.
Ведь нельзя просто так взять и использовать шаги в случайной последовательности.
В общем, мы отказались от этой идеи, так и не реализовав ее. Немного погрустили и придумали другой подход.
Мы заметили, что некоторые команды отказываются от использования ТМС, чтобы сэкономить своё время, пусть и жертвуя наглядностью своей тестовой модели.
Было решено: исследовать историю с «тест-кейсами в коде».
Если быть честным, сначала я был крайне скептически настроен к этой идее. Было непонятно, как держать синхронизированными деревья тестовой модели и сами тест-кейсы в разных репозиториях.
Думали над тем, чтобы сделать просмотрщик тест-кейсов, который бы брал автотесты из репозитория и наглядно отображал их.
В итоге мы сделали что-то похожее: если у нас есть уже работающая тестохранилка, которая дает свои бонусы, то почему бы не использовать ее? Тем более, что кто-то наверняка захочет продолжать вручную создавать тест-кейсы.
Так и родилась история с щупальцами. Это такие штуки, которые парсят автотесты (слегка особым образом размеченные) и загружают их в тестохранилку.
Логично, что автотесты из щупалец предоставляются только для чтения. Редактировать их через интерфейс тестохранилки — нельзя.
В итоге те команды, которые отказались от использования тестохранилки, потратили примерно час на разметку автотестов (чтобы проставить идентификаторы фичей), и их кейсы появились в ТМС.
Сейчас мы все еще продолжаем наращивать «щупальцевую массу». Наша текущая цель — «любая проверка в Авито должна быть в тестохранилке и сматчена на тестовую модель».
Тем временем мы плавно переключаемся на тест-планы, которые на данный момент очень слабо удовлетворяют потребности регресса. Чуть позже постараюсь сделать большой тред про то, что они представляют из себя сейчас и что будет потом.
А еще мы задолбались жить с недельными спринтами, не такая уж и волатильная обстановка вокруг нас. И первый наш двухнедельный спринт посвятим этим самым тест-планам.
А еще мы задолбались жить с недельными спринтами, не такая уж и волатильная обстановка вокруг нас. И первый наш двухнедельный спринт посвятим этим самым тест-планам.