Ок

а можно ссылку? спасибо!

спасибо!

не совсем про автоматизацию, ближе к управлению процессами и devops. но думаю будет интересно. много букв про Progressive Delivery одной западной игровой компании
-----------
Некоторые вводные
1. Клиент распространяется через огромное кол-во площадок (AppStore, Google Store, Xbox, Micrsofot UWP, наш лаунчер и т.д.)
2. Почти никакие площадки мы не контролируем и изменения доходят до реальных пользователей с разной задержкой (от дней до недель)
3. Если в такой структуре из-за бага что-то будет крашить это означает, что в худшем случае несколько недель игра будет недоступной (падать), что неприемлемо
4. 99.999% контента это UGC (User-generated content) и мы его протестировать с покрытием хотя бы 1% не можем (это миллионы часов нужно играть)
примерные цифры:
    а) миллионы инсталляций на платформе (всех тайтлов)
    б) миллион+ PCCU
5. Количество различного железа и контента настолько большое, что получается невозможно гарантировать покрытие даже на 1% (и при этом нельзя допускать критических багов)
6. Контента который делаем мы внутри не очень много
7. Контент не бандлится с клиентом а хранится в облаке и клиент его скачивает по запросу (т.е. все версионированно и т.д.)

теперь значит как при этом живет фича, кто и как ее делает, немного организационных подробностей

1. фичу делают всегда в ветке (в транк никто комитать не может)
2. перед мержем фичи в транк, нужно попросить бота CI протестировать твою ветку (бот проверит сборку по миллиард платформ и запустит миллиард тестов)
3. обязательное код-ревью минимум 2-х человек на любое изменение (даже однострочное)
4. есть code-ownership, если потрогал код то владелец кода тоже должен быть в ревью (большое изменение может ревьювить 8-12 человек)
5. все изменения должны быть под флагом
  if (myNewFeatureEnabled) {
      новый код
   } else
   {
       старый код
   }
5. если бот тестер и ревьюверы ок, это попадает в транк
6. все флаги по умолчанию выключены

дальше у фичи есть несколько жизненных циклов
1. в разработке в ветке
2. в транке
3. в стейбле
4. на продакшене, но выключена
5. на продакшене, но включена
6. на продакшене и без флага (флаг удален)

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

дальше когда фича доезжает до продакшена (отключенная)
есть глобальное расписание включения фичей (слоты по 15 минут)
разработчик должен зарезервировать себе слот включения своей фичи
включение фичей никогда не пересекается по времени

далее в заданный тайм-слот фичу включают на проде
и разработчик + QA из лайвопс мониторят реалтайм графики
если все ок (10 минут), то фича остается включенной
если не ок, то ее выключают
если будут жалобы от пользователей, служба поддержки умеет сказать список подозреваемых в баге фичей
по времени обращения и т.д.
и тогда если это массовые жалобы то фичу выключают тоже
если жалоб нет и фича включена 4+ недель, то флаг удаляют и фича становится монолитной
т.е. флаги долго не живут

кстати, из за того что мы не контролируем площадки на проде живет большое кол-во версий клиентов одновременно
и иногда прежде чем включать фичу на проде, нужно подождать пока оно везде распространится
флагом реально нужно покрывать любое изменение
например если делаешь большую переделку, то надо физически прямо весь код/классы скопировать и переделывать уже копию
и соответственно от флага создавать либо новый либо старый класс

Кто-то знает или сталкивался сам с реалиями, когда  тима юзает один язык программирвоания, а тесты написаны на другом? Web Development

Проект на плюсах, юниты и интеграция на плюсах, системные тесты на пайтоне

Правда не web, embedded

мне кажется таких большинство)

а как называется продукт?

сталкивался. продукт написан на куче языков, а тесты на питоне.

в моих реалиях прогеры юзают php, сам считаю вход в automation через php+selenium диким трешом) т.к мало инфы/гайдов/не официальная библиотека. но ТЛ оперирует тем что сможет подсказать в каких то моментах и не хочет плодить тезнологии. Сам начал изучать пайтон

Какие трудности в принципе связанные с этим могут быть?)

Трудности будут если начнёшь что-то на php  лабать.

Я думаю запроса в гугле php pointers и быстрому просмотру должно хватить чтобы отказаться от идеи учить пыху в 2019 :)

продуктов там много - игры разнообразные, в основном с
User-generated content. Компанию просили не называть

А что с этим не так?

python тогда лучше учить в нагрузку к изучению qa для будущей автоматизации?

а что не так с PHP?

все ок, но для автоматизации думаю это жоска