How to become an author
Search
Write a publication
Pull to refresh

Comments 31

Ребята, спасибо за статью. Вы круты и делаете реально крутые вещи и что самое главное делитесь опытом с другими. С нетерпением жду новой какой-то интересной статьи.
Total votes 7: ↑7 and ↓0+7
Вам спасибо! Когда я выступаю с докладом или пишу статью и это кажется полезным хотя бы одному человеку (а тем более если это побуждает его к каким-либо созидательным действиям), то я знаю, что работа была сделана не напрасно. Думаю, мои коллеги придерживаются того же мнения.
Total votes 5: ↑5 and ↓0+5
Я очень люблю ваши статьи и доклады. Спасибо!
Total votes 5: ↑5 and ↓0+5
Рады стараться! (:
Total votes 1: ↑1 and ↓0+1
Слегка оффтоп, но все же спрошу. На недавней конференции в Баду рассказывали про техническое ревью, когда разработчик-исполнитель описывает в тикете, как он понял постановку задачи. То есть по сути переводит с менеджерского на разработческий. И далее это ревью проверяется командой на корректность.

Можете немного подробнее рассказать, как это реализовано, всегда ли оно выполняется и тд.
Total votes 2: ↑2 and ↓0+2
Надеюсь, я правильно понял ваш вопрос, если нет — уточните, пожалуйста.

Ревью задачи/проекта у нас выглядит так:

1. Когда PRD готово оно проходит ревью команды продукта: разработчик PRD проводит презентацию и все участники продукт-команды обсуждают все кейсы, вопросы за и против и так далее.
2. После проведения данного ревью, идет почтовая рассылка, в которой каждый заинтересованный может оставить свой фидбэк.
3. Также есть техническая API-команда, которая тесно содействует с продуктом при написании протокола (то есть также проводит процесс ревью).
4. Kick off внутри команды разработки. Совещание, которое проводится до начала разработки проекта, где как раз обсуждаются все кейсы, продукты рассказывают про проект, а тех отдел делает свое ревью по данному проекту. До проведения kick-off'a все участники проекта знакомятся с PRD.
5. По выполнении задачи она отправляется на код-ревью, где коллеги-разработчики могут проверить детали реализации и подходы к решению той или иной проблемы.
6. После прохождения код-ревью разработчик составляет сообщение для отдела QA, в котором рассказывает, как с технической точки зрения был реализован проект, чтобы мы при изучении задачи могли понять ход его мысли.

И на каждом из этих этапов в PRD могут вноситься различные поправки и дополнения, чтобы проект ушё на продакшн максимально проработанным и развитым.
Total votes 1: ↑1 and ↓0+1
Соответственно, это только для новых продуктов или при заметной переработке существующих, так? Для багфиксов и мелких улучшений это будет выглядеть бюрократией, имхо
This comment wasn’t rated yet0
Да, багфиксы и мелкие исправления логики обычно даже не проходят полноценный этап PRD, а начинают жизнь уже в задаче в JIRA — в таком быстроразвивающемся проекте как наш иначе жить было бы невозможно
This comment wasn’t rated yet0
Огромное спасибо за статью. Тулзы и подход к автоматизации вдохновляют.
Есть вопросы:
— как работает Selenium manager?
— как Вы обнаруживаете «тикет виновник»?
— сохранили ли у Вас отдельную должность автоматизатора или этими задачами занимаются девелоперы?
Total votes 1: ↑1 and ↓0+1
Дождёмся автора Selenium Manager'а с больничного и отпишем развёрнутый ответ, может быть даже полноценную статью :)

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



Насчёт автоматизаторов: разработчики пишут только интеграционные и юнит-тесты. В нашем отделе QA есть три специалиста, занимающиеся поддержкой Selenium и smoke-тестов фулл-тайм, они же занимаются поддержкой инфраструктуры, Selenium-grid фермы и всего такого. Все остальные QA-инженеры занимаются разработкой тестов наравне с непосредственным тестированием задач.
Total votes 1: ↑1 and ↓0+1
Спасибо за ответ. Буду ждать еще отдельной статьи.
Total votes 2: ↑2 and ↓0+2
Илья все верно написал про Selenium Manager. От себя могу только добавить, что на работе с шотами его функционал не заканчивается.

В целом я писал веб-интерфейс для простого запуска тестов «в один клик», без необходимости ставить локально selenium server, знать ключи для запуска тестов и вообще каким-либо образом «смотреть под капот».

Изначально он умел запускать один тест для указанного окружения, затем научился запускать несколько тестов параллельно. После добавилась система инвестигейтов (почти как в ТимСити) к тестам: если какой-то тест не работает по известной причине (оформленной в виде задачи), он заносится в эту систему и при запуске тестов со специальным ключом, с которым мы гоняем их для шотов и стейджинга, автоматически скипается, чтобы не засорять лог заведомо известными ошибками. И так далее…

В итоге получился довольно удобный и расширяемый инструмент. Обязательно соберусь написать о нем в следующем году. :)
Total votes 1: ↑1 and ↓0+1
На гитхаб не планируете выкладывать?
This comment wasn’t rated yet0
На данный момент нет: большая часть функционала Selenium Manager'а завязана на нашем флоу и наших проектах.

Я оформлю статью в виде туториала, в котором постараюсь разделить бизнес-логику с реализацией непосредственно самого запуска тестов и манипуляцией данных — всякого рода инвестигейтов, дашбордов и прочего.

В идеале получится пример, который можно будет скопировать лишь частично, внося изменения по своему вкусу, но, в конечном итоге, описывающий суть инструмента.
Total votes 1: ↑1 and ↓0+1
Ух! Разрекламировал так, что теперь от статьи точно не отмазаться. Пошел рефакторить код… :)
Total votes 1: ↑1 and ↓0+1
Сначала подумала, что вот, очередная реклама, а нет, статья, на мой взгляд, стоит прочтения. Спасибо, что поделились опытом.
Total votes 4: ↑3 and ↓1+2
Отличная статья, взял на заметку к чему надо стремится =)
Total votes 1: ↑1 and ↓0+1
Отличная статья, мне лично особенно полезны идеи для pre-receive hooks, вот прямо сейчас отправился реализовывать на своем проекте.

Расскажите пожалуйста подробнее, как вы решаете проблему совместимости задач (когда отдельные задачи, успешно протестированные в своих шотах, «ломают» друг друга в совместном билде)?
Насколько я понял, Selenium manager позволяет покопаться в тестах каждого отдельного тикета + мастер, но не комбинации тикетов.

И как выглядит откатывание тикета на практике? Откат мастера до прошлого релиза + повторный мердж всех тикетов кроме подозреваемого «виновника», или есть более умные решения?
Total votes 1: ↑1 and ↓0+1
Как бы хорош не был Selenium Manager, он позволяет в автоматическом режиме обнаружить только часть проблем. Если же проблема возникает только в комбинации задач — да, сидим и проверяем различные комбинации руками, либо всё же по текстам ошибок и симптомам пытаемся сразу обнаружить виновников — всё таки редко из 20 задач более двух затрагивают один и тот же компонент. Не представляю, как это можно было бы эффективно и дёшево автоматизировать.

По поводу отката вам лучше ответит кто-нибудь из наших релиз-инженеров, постараюсь прикастовать кого-нибудь из них в эту ветку (:
This comment wasn’t rated yet0
Вот тут мы в свое время выкладывали статью о том, как работает наш gitflow в целом и система отката в частности: https://habrahabr.ru/company/badoo/blog/169417/
Там много интересного, советую ознакомиться на досуге.

Ответ на ваш вопрос:
«Если с задачей в релизе что-то не так, то мы откатываем ветку с ней при помощи git rebase. Эта функция используется не случайно: нам не подходит revert, так как после отката релизная ветка сольётся в master, а ветки с задачами постоянно из него обновляются. В итоге, когда разработчик проблемной задачи обновит свою ветку, его код пропадёт, и придётся делать revert на коммит revert.»
Total votes 1: ↑1 and ↓0+1
Касательно отката задач

На самом деле, была целая статья про автоматизацию: https://habrahabr.ru/company/badoo/blog/169417/

Если лень читать, вот ответ именно на ваш вопрос: мы используем git-rebase и с помощью него убираем коммиты, которые относятся к задаче, включая различные правки (патчи). Есть альтернативный вариант с git-revert, но он кажется нам менее удобным :)

Я не очень понял про «откат мастера» в вопросе. На всякий случай уточню, что мы собираем билд в виде отдельной ветки, которая попадет в мастер только после всех проверок, в т.ч. на production окружении.
Total votes 2: ↑2 and ↓0+2
Теперь понятно, спасибо.
По поводу отката, я неясно выразился – конечно же, откат ветки билда до текущего мастера (предполагая, что предыдущие билды уже были смерджены в мастер).
This comment wasn’t rated yet0
Весьма! Автору большой спасибр за техинсайд, обязательно пишите ещё, очень полезно и познавательно новичкам вроде меня.
Total votes 1: ↑1 and ↓0+1
Сами удивились. Изначально сценарии «на коленке» написал для себя один из наших разработчиков, а потом выложил это дело в общий доступ (вообще многие наши qa-инструменты имеют подобный жизненный цикл).

А сам он выбрал lua потому что он прост как две копейки, наши сценарии на нём выглядят почти человекопонятными фразами, да ещё и в php он встраивается простым расширением.

Так что ответ на ваш вопрос — «Так получилось»
Total votes 1: ↑1 and ↓0+1
Я правильно понял, что степень покрытия кода тестами проверяется вручную при code review? Может ли быть такое, что изменение в одном куске кода (попавшее в ревью) вынесло из покрытия другой кусок (не попавший в ревью — он же не изменился), и никто об этом не узнает?
This comment wasn’t rated yet0
В полностью автоматическом режиме — да, об уменьшении покрытия какого-то конкретного места мы не узнаем. Но мы дважды в день собираем полный каверидж по всему проекту — и по уменьшившемуся покрытию компонента можно будет узнать, что что-то не так. А на плохо покрытые тестами места у нас регулярно заводятся тикеты.
This comment wasn’t rated yet0
Это хуже, чем автоматическая проверка 100% покрытия при прогоне автотестов (у нас так), но все же неплохо — особенно
на плохо покрытые тестами места у нас регулярно заводятся тикеты.

Спасибо!
This comment wasn’t rated yet0
Мы однажды писали статью о том, как мы фантастически увеличили скорость сборки кавериджа: https://habrahabr.ru/company/badoo/blog/192538/

С тех пор всё стало ещё лучше, но все равно полная сборка кавериджа занимает чуть более часа и порядочно нагружает машину. Делать это на каждый тикет (ещё раз повторю — до 40 тикетов релизится в день) несколько затруднительно :)
Total votes 1: ↑1 and ↓0+1
Спасибо за статью. Было бы интересно узнать как происходит тот же процесс на проектах mobile клиентов.
Total votes 1: ↑1 and ↓0+1
Думаю, в скором времени появится и такая статья, тут в двух словах не объяснить
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr