Летом разработчики ТестОпса писали что интеграция с 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 инженеров в команде, которые составляют эти сценарии. Разработчикам только нужно их автоматизировать.
И третья проблема
Тут не могу прокомментировать, пока не сталкивались, возможно столкнемся
надо все документировать
Да, документировать нужно и в каком-то виде тест-кейсы мы храним + автотесты сами по себе документация.
Нет, сервера они не админят. Хотя опыт перехода целой команды разработки в инфраструктуру у нас был и разработчики стали инженерами инфраструктуры.
А можете подробнее рассказать почему должны работать по-разному мозги 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 инженеров в команде, которые составляют эти сценарии. Разработчикам только нужно их автоматизировать.
Тут не могу прокомментировать, пока не сталкивались, возможно столкнемся
Да, документировать нужно и в каком-то виде тест-кейсы мы храним + автотесты сами по себе документация.
А можете подробнее рассказать почему должны работать по-разному мозги QA, разработчика и инженера инфраструктуры, в чем разность?