На этой неделе наша основная цель — добить историю с щупальцами web авто-тестов, чтобы на следующей неделе забороть API и подвигать квартальные цели.

Конечно, не обошлось и без багов. Тот пятничный баг не починился до планирования, а мы еще и планирование подвинули на час раньше. Еще у нас в монолите есть скрипт, который проставляет статусы автоматизации в TMS и он сбривал автоматизацию всем «щупальцевым» тестам. Неприятно.

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

В общем, во всяком случае на этой неделе нет внезапных праздников, про которые мы забыли, поэтому есть надежда все успеть. Даже то, что было докинуто.

И вы тут, если что, задавайте вопросы всякие, на что акцент сделать, чего рассказать и всякое такое.

Что-то я затянул с постом в этот канал, хотя уже давно всё запостил в твиттере, исправляюсь.

Цель спринта спасена! Теперь я расскажу вам про ветки.

У нас в тестохранилке с ветками довольно просто — есть master, который представляет собой «состояние на проде», а есть «другие» ветки, которые, соответственно, представляют собой либо состояние продуктовой задачи, либо какой-то рефакторинг тест-кейсов. То есть мы всегда можем зайти и посмотреть, как что работает на проде.

Немного про ”кишки” веток. Это такой типа Git на MySQL с пачкой упрощений. Предотвращая ваши вопросы — создавать ветки можно только из мастера и мержить только в мастер.
Создаешь ветку, в базе появляется новая запись о ветке, у которой инкрементится branch_timeline_id, это у нас что-то типа ревизий. Когда переходишь на страницу ветки, на ней загружаются все кейсы, которые привязаны к текущему branch_timeline_id и все оставшиеся из мастера.
Благодаря этому при создании ветки тест-кейсы не копируются из мастера в ветку. Они копируются только при редактировании. Бесплатным бонусом это дает фичу «прозрачное автоподмерживание мастера».
Т.е. все тест-кейсы, которые не редактировались, в ветке всегда отображаются свеженькими, даже если в мастер что-то вмержилось после создания текущей рабочей ветки.

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

Новая неделя — новый спринт. За эту неделю хотим добить всякий разный техдолг. А самое главное — сделать одно из последних важных щупалец для монолита, которое будет собирать API автотесты.

Ставим цели на следующий квартал. Будет много щупалец. Очень много. Под все наши платформы!

Щупальца крутятся, тест-кейсы мутятся 😎👌

Маленькие приятности работы в платформенной команде — вы только собрались что-то делать в следующем квартале, а соседняя платформенная команда уже всячески вам с чем-то помогает (возможно, не нарочно).
Например, с щупальцами для компонентных тестов фронта 🙂

Пятница, конец третьего спринта.
Вот что мы сделали.
- Для монолита есть щупальца для всех типов тестов, кроме юнитов.
- Сделали автоматическую генерацию tmsExternalID в монолите (об этом попозже).
- Добавили на пулл-реквесты линтер tmsExternalID

Всем привет! Я вернулся из отпуска и продолжаю писать.
На прошлой неделе мы таки научились выгружать e2e тесты iOS, а ещё прикрутили к щупальцам mypy и прочие линтеры.

На этой неделе сделаем то же самое и для Android.

Еще на этой неделе я постараюсь подробнее рассказать вам о щупальцах: как они работают, почему именно они и вообще всё-всё, что с ними связано. А то пишу про них очень много, но подробностей никаких.

На нашем медиуме подъехала статья про тестохранилку

У нас в Авито есть собственная система для управления тест-кейсами.

В чём её отличия от других тестохранилок:
🎋 ветки — это такой легкий Git на MySQL;
🅰 API для управления тест-кейсами и проверки статуса автотестов;
🌴 бесконечное дерево фич.
К тому же, система оптимизирована для кросс-функциональных команд.

В англоязычной статье на Медиуме Вадим Шашин рассказывает о том, как она устроена → http://bit.ly/2XRn3mv

Так-с. Кажется, я обещался написать про щупальца.

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

Так вот. Зачем делать работу два раза, если можно ее сделать однажды? Подумали мы и начали размышлять, как что-то выкинуть из этого процесса.
Первое, что пришло в голову, — генерация автотестов. Очень уж это красиво и, кажется, что тестировщикам придётся писать меньше кода.

Короче говоря, идея провалилась. Слишком оверинжиниринг оказалась.

В чём была идея: сделать «разделяемые шаги», чтобы в разных тест-кейсах использовались одинаковые шаги по мере возможности.
Так мы могли бы автоматизировать шаг тест-кейса один раз и использовать его дальше в разных автотестах.
По факту получился большой монстр в виде огромного орграфа и сложной модели подсказки следующего шага тест-кейса.
Ведь нельзя просто так взять и использовать шаги в случайной последовательности.

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

Было решено: исследовать историю с «тест-кейсами в коде».
Если быть честным, сначала я был крайне скептически настроен к этой идее. Было непонятно, как держать синхронизированными деревья тестовой модели и сами тест-кейсы в разных репозиториях.
Думали над тем, чтобы сделать просмотрщик тест-кейсов, который бы брал автотесты из репозитория и наглядно отображал их.
В итоге мы сделали что-то похожее: если у нас есть уже работающая тестохранилка, которая дает свои бонусы, то почему бы не использовать ее? Тем более, что кто-то наверняка захочет продолжать вручную создавать тест-кейсы.

Так и родилась история с щупальцами. Это такие штуки, которые парсят автотесты (слегка особым образом размеченные) и загружают их в тестохранилку.
Логично, что автотесты из щупалец предоставляются только для чтения. Редактировать их через интерфейс тестохранилки — нельзя.

В итоге те команды, которые отказались от использования тестохранилки, потратили примерно час на разметку автотестов (чтобы проставить идентификаторы фичей), и их кейсы появились в ТМС.
Сейчас мы все еще продолжаем наращивать «щупальцевую массу». Наша текущая цель — «любая проверка в Авито должна быть в тестохранилке и сматчена на тестовую модель».

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