Привет!
Мы свежеобразованная команда разработки внутренней TMS. Мы часть большой команды, которая делает инструменты для тестирования и обеспечения качества. Решили попробовать в 3 человека сфокусироваться на одном большом продукте и поделиться тем, как все будет получаться

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

Зачем этот канал? Наверняка вы представляете, как идёт разработка в обычной продуктовой, либо аутсорсной компании. Но я часто встречал круглые глаза у людей, когда они видели «software engineer at quality assurance».

Будем расгруглять обратно 🙃

Первым делом я должен кинуть в вас ссылкой на наш Хабр, чтобы, если вдруг ещё не, то вы узнали о нас чуть больше — habr.com/company/avito

Здесь я буду рассказывать о нашей рутине, о жизни платформенных юнитов внутри продуктовой компании, о планах нашей команды, о ежедневных решениях. Иногда я буду копипастить итоги стендапов 😜

Как раз завтра у нас будет конец первого спринта (которые у нас длятся неделю). Расскажу о довольно важной для нас фиче, которую мы запилили (если успеем до демо, конечно 😶)

Итак, пятница. В 13:30 демо, потенциальные пользователи приглашены. Мы даже что-то сделали, но наш бёрндаун какой-то не очень бёрн. Ещё и багуля повисла в воздухе.
Успеем ли?

Прошло демо. К нам пришли ребята из нескольких юнитов. Собственно, что мы им показали:
- щупальца для автотестов;
- упрощенное создание тест-кейса.
Про каждую фичу расскажу в отдельном треде попозже.

Итак, щупальца! Что это такое? И почему так называются?

Сначала про название. Нашу тестохранилку мы нежно называем Ктулху. Она как исполинская махина из рассказов Лавкрафта может всюду пробраться и достать кого или что угодно.

Щупальца — это механизм, который ходит по репозиториям и собирает из них все автотесты, превращая их в тест-кейсы в Ктулху

Зачем оно нам?
Далеко не всегда имеет смысл сначала писать тест-кейс, а затем автоматизировать его, особенно, если это тесты на API. Но представлять текущую ситуацию с покрытием нужно.
Причем не процент покрытия кода, а покрытие фичи разными тестами. Это большая история про agile testing и весь этот ваш shift left.

Так-так, что у нас дальше? Упрощённое создание тест-кейса.
Полный путь выглядит так: зайти на главную, выбрать проект/платформу, создать ветку (вписать номер задачи из JIRA, скопировать заголовок из неё же), дождаться загрузки страницы ветки, перейти на экран создания тест-кейса.
Многовато.

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

Что такое ветки, откуда они взялись в тестохранилке и почему их так любят наши тестировщики я обязательно как-нибудь расскажу

Итак, новая неделя, новый спринт.
Предыдущий спринт закончился с 25 сторипоинтами из 55 из-за слегка недоделанной большой таски, которая на этой неделе сделала нам такое.