Да, согласен что решение не идеальное. Мы тоже похавали на нем всяких субстанций, но на момент перехода это было лучшее решение из доступных. Возможно конкуренты сейчас не отстают или даже обгоняют, а может и нет, надо смотреть исследовать, пока не до этого)
Летом разработчики ТестОпса писали что интеграция с Kaiten готова. Занимались на тот момент документацией. Я посмотрел сейчас в разделе Интеграции - там ничего нет про Kaiten. В общем ждем, надеемся и верим.
Комнанды разработки разделены по продуктам. Одна команда владеет 1-2-3 сервисом. По количествую людей разные, от 3-10 человек команды. По функции у них - полная ответственность за сервис. За его создание, его работу, тестирование, документацию, проработку новых фичей, ревью PR от других команд и т.д.
Тестировщик прикреплен к команде, да. Но не во всех командах есть тестировщики.
Все зависит от многих факторов: состава команды, зрелости процессов и разработчиков. В каких-то командах да, тестирует тестировщик. В другой команде тестируют разработчики, а в третьей команде разработчики написали автотесты, сделали быстрый откат, хороший мониторинг и никто ничего не тестирует.
К сожалению или к счастью, мы не пользуемся Jira. У нас kaiten. А у TestOps пока нет интеграции с kaiten. Но скоро должна появиться и вот тогда, будем интегрироваться. Но пока даже нет идей как выстраивать процесс и как интегрироваться. Будем думать когда будет интеграция.
Есть способы такие проблемы решать. Например, техника feature toogles/feature flags. Посмотрите эту статью, там прям такой случай и рассматривается, что сложная задача на несколько недель, несколько команд работающих над одним сервисом...
Да, это все правильно. Единственное что мне сразу бросается в глаза это время жизни ветки. 1-2 недели это долго. На trunkbaseddevelopment.com есть раздел "short-lived-feature-branches" и там они пишут "One key rule is the length of life of the branch before it gets merged and deleted. Simply put, the branch should only last a couple of days. Any longer than two days, and there is a risk of the branch becoming a long-lived feature branch (the antithesis of trunk-based development)."
Короткий ответ — нет, нельзя.
Более развернутый ответ — в dev ветку у нас нет MR, мы сразу мержим и оптимистично считаем что все мержат релизопригодный код. Если пайплайн падает, то бот призывает авторов, и они чинят тесты.
Этот же пайплайн гоняется и на релизной ветке. Релизную ветку мы сначала раскатываем на prod. На прод с красными тестами не релизим, сначала зеленим пайплайн, потом катим. А потом уже мержим PR в master.
Возможно компаниям проще залить эту проблему деньгами (людьми), чем выстраивать процессы, потому что чем больше людей участвуют в изменениях, тем сложнее эти изменения внедрить и сохранить работающими.
У нас есть Slack-бот, который смотрит в TeamCity, GitHub, Kaiten… и видит кто коммитил в конкретный билд и призывает их в тредах к сообщению.
Подробнее об этом боте можно почитать в статье Один бот от всех забот
Не совсем. Критичные сценарии, которые мы проверяли, покрыли, остальное перестали регрессить. Если всплывают какие-то сценарии которые тогда были не критичными, а сейчас становятся критичными или мы о них не подумали, тоже автоматизируем.
Мы отказались от ручного регресса, автоматические тесты с покрытыми критичными сценариями из регресса ходят после каждого коммита в общую ветку. Т.е. от самого регресса мы не отказывались, а свели его к прохождению автотестов.
У нас есть канал в слаке, куда падают уведомления о том, что пайплайн красный, в комментах автоматически тегаются люди, чьи коммиты были в этой версии кода и они идут чинить пайплайн.
Задал вопрос своей команде ответил пока один человек, поэтому процитирую его ответ
Тесты от unit- и до интеграционных, не покидающих кода сервиса (in-memory репозиторий — да, sqlite вместо mysql — нет) у нас часто пишутся по TDD, поэтому оценить временные затраты сложно — нет отдельной таски. Бывает, что для теста нужно написать 100500 строк тупого кода вроде DSL, бывает, что нужно выносить дублирующийся код из самих тестов в какие-то отдельные конструкции. Я бы сказал, что отношение времени чистой разработки к написанию unit-тестов — 50/50 с легким уклоном в тесты.
Тесты, работающие с SUT как с black-box (хоть по HTTP API или шине, хоть через UI), тоже бывают разные. Где-то нужно переиспользовать готовые шаги и чуть-чуть поменять when'ы, а где-то нужно писать целые PageObject'ы (и иногда вносить изменения в сервис, потому что тот не готов тестироваться автоматически). Относительное время я точно не скажу, а по абсолютному — от полудня до двух-трех дней плюс-минус трамвайная остановка (большой разброс)
Я очень рад, что вам было интересно почитать)
По поводу того, кто должен писать тесты ответил в комменте выше
Отсюда вторая проблема
Проблему неумения разработчиков составлять исчерпывающие сценарии мы решаем наличием QA инженеров в команде, которые составляют эти сценарии. Разработчикам только нужно их автоматизировать.
И третья проблема
Тут не могу прокомментировать, пока не сталкивались, возможно столкнемся
надо все документировать
Да, документировать нужно и в каком-то виде тест-кейсы мы храним + автотесты сами по себе документация.
Ага, мы сами фиксили пару проблем в проекте
Да, согласен что решение не идеальное. Мы тоже похавали на нем всяких субстанций, но на момент перехода это было лучшее решение из доступных. Возможно конкуренты сейчас не отстают или даже обгоняют, а может и нет, надо смотреть исследовать, пока не до этого)
Летом разработчики ТестОпса писали что интеграция с Kaiten готова. Занимались на тот момент документацией. Я посмотрел сейчас в разделе Интеграции - там ничего нет про Kaiten. В общем ждем, надеемся и верим.
Здравствуйте. Спасибо за вопросы:
Комнанды разработки разделены по продуктам. Одна команда владеет 1-2-3 сервисом. По количествую людей разные, от 3-10 человек команды. По функции у них - полная ответственность за сервис. За его создание, его работу, тестирование, документацию, проработку новых фичей, ревью PR от других команд и т.д.
Тестировщик прикреплен к команде, да. Но не во всех командах есть тестировщики.
Все зависит от многих факторов: состава команды, зрелости процессов и разработчиков. В каких-то командах да, тестирует тестировщик. В другой команде тестируют разработчики, а в третьей команде разработчики написали автотесты, сделали быстрый откат, хороший мониторинг и никто ничего не тестирует.
Системных аналитиков у нас нет. Но если бы были, они бы тоже ходили в гембу))
В целом в компании подход такой, что поощряются все движения в сторону сближения с бизнесом.
К сожалению или к счастью, мы не пользуемся Jira. У нас kaiten. А у TestOps пока нет интеграции с kaiten. Но скоро должна появиться и вот тогда, будем интегрироваться. Но пока даже нет идей как выстраивать процесс и как интегрироваться. Будем думать когда будет интеграция.
Есть способы такие проблемы решать. Например, техника feature toogles/feature flags.
Посмотрите эту статью, там прям такой случай и рассматривается, что сложная задача на несколько недель, несколько команд работающих над одним сервисом...
https://martinfowler.com/articles/feature-toggles.html
Да, это все правильно. Единственное что мне сразу бросается в глаза это время жизни ветки. 1-2 недели это долго. На trunkbaseddevelopment.com есть раздел "short-lived-feature-branches" и там они пишут
"One key rule is the length of life of the branch before it gets merged and deleted. Simply put, the branch should only last a couple of days. Any longer than two days, and there is a risk of the branch becoming a long-lived feature branch (the antithesis of trunk-based development)."
Можешь рассказать что такое LT/US? И как вы приоритизируете эти задачи и трекаете их выполнение?
Более развернутый ответ — в dev ветку у нас нет MR, мы сразу мержим и оптимистично считаем что все мержат релизопригодный код. Если пайплайн падает, то бот призывает авторов, и они чинят тесты.
Этот же пайплайн гоняется и на релизной ветке. Релизную ветку мы сначала раскатываем на prod. На прод с красными тестами не релизим, сначала зеленим пайплайн, потом катим. А потом уже мержим PR в master.
Подробнее об этом боте можно почитать в статье Один бот от всех забот
По поводу того, кто должен писать тесты ответил в комменте выше
Проблему неумения разработчиков составлять исчерпывающие сценарии мы решаем наличием QA инженеров в команде, которые составляют эти сценарии. Разработчикам только нужно их автоматизировать.
Тут не могу прокомментировать, пока не сталкивались, возможно столкнемся
Да, документировать нужно и в каком-то виде тест-кейсы мы храним + автотесты сами по себе документация.