Привет!
Мы свежеобразованная команда разработки внутренней TMS. Мы часть большой команды, которая делает инструменты для тестирования и обеспечения качества. Решили попробовать в 3 человека сфокусироваться на одном большом продукте и поделиться тем, как все будет получаться
Мы свежеобразованная команда разработки внутренней TMS. Мы часть большой команды, которая делает инструменты для тестирования и обеспечения качества. Решили попробовать в 3 человека сфокусироваться на одном большом продукте и поделиться тем, как все будет получаться
Продукт этот — внутренняя система управления тест-кейсами. Далее буду называть его «тестохранилка» или TMS. Он занимает довольно важное место в нашей инфраструктуре тестирования, связывая ручное и автоматизированное тестирование.
Зачем этот канал? Наверняка вы представляете, как идёт разработка в обычной продуктовой, либо аутсорсной компании. Но я часто встречал круглые глаза у людей, когда они видели «software engineer at quality assurance».
Первым делом я должен кинуть в вас ссылкой на наш Хабр, чтобы, если вдруг ещё не, то вы узнали о нас чуть больше — 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 автотесты.
Ставим цели на следующий квартал. Будет много щупалец. Очень много. Под все наши платформы!
Щупальца крутятся, тест-кейсы мутятся 😎👌
Щупальца крутятся, тест-кейсы мутятся 😎👌