Дійсно іноді це може залежати від регуляцій, навіть зовнішніх. В такому випадку ТОП менеджменту треба працювати в сторону перегляду цих аспектів, якщо їм звісно доцільне пришвидшення доставки змін. Доволі часто може допомогти не автоматизація, а перегляд процесів.

Все вірно, надійність це доволі коштовний аспект і він має бути доречним.

Під блекфрайдей дійсно робимо кодфріз, але це більше під навантажувальне тестування, щоб в продукті не було змін які не потрапили в період проведення навантажувального тестування, та потім вилізли якісь unexpected речі.

Довгий кодфріз призводить до накопичення змін, що сприяє інтенсифікації релізів в короткий проміжок часу після нього і відповідно підвищенню ризиків. Кодфріз норм штука під конкретні періоди, але з ним також треба бути дуже обережним.

Деплоймент навіть у понеділок не гарантує відсутності дефекту наступної суботи, або навіть через тиждень. В принципі зміни — це завжди ризик, але часто ваші зміни можуть мати відтермінований ефект, але ж це не означає що треба припинити розробку продукту.
Хоча звісно треба оцінювати масштаб ваших змін та як ви забезпечуєте їх працездатність, а це дійсно може сильно варіюватися від величезної купи факторів.

Ви хочете купити пропелери для FPV на одному сайті, там не пройшла оплата — ви ідете на інший сайт і купуєте там пропелери. Далі вам будуть приходити листи від сайту з іншими товарами, або навіть з тими самими пропелерами і ви знову їх купите на тому сайті де пройшла оплата раніше.
Або користувач робить імпульсивну покупку підписочного продукту, він не впевненний на 100% що воно йому треба — але він наважився, зайшов на сайт і робить оплату — оплата не пройшла — він подумав: «ну і ладно» і не повернувся до цієї покупки. Ось ви втратили користувача який ще приніс би непогано коштів в майбутньому.

Якщо оцінювати втрати виключно за свою комісію — вам не будуть довіряти клієнти, та будуть шукати собі більш стабільніше рішення.

Дякую усім хто прийняв участь та не посоромився викласти свої тести!
Хочу також поділитися — ми провели внутрішній челендж в рамках нашої команди.

Силами 10 наших розробників — було написано понад 1500 юніт, та функціональних тестів які уже знаходяться в нашому пайплайні та допомагають нам кожного дня!

Ооо, є коментарі!) Красавчікі Хлопці!)

На попередньому тижні також додав трохи тестів для дебагу інтеграції з репортером testomat.io

Частина тестів спеціально не проходять щоб подивитися як фейли в репорті відображаються)

1. Сервера, либо облачные решения которые вы упомянули в 4м пункте. Количество связок зависит от требований вашего продукта.
2. Делать упор на снимки элементов, а не страниц. Так же можно просто периодически «переснимать» заново все эталонные снимки. (После запланированных изменений).
3. Кол-во скриншотов зависит от пункта 1.
Про «пауков» не понял, можно поподробнее ?)
Фоновая информация — вырезаться \ игнорируется. Если нужно тестировать ее — можно написать отдельный набор тестов для этих вещей (но не уверен насчет целесообразности данного действа)
4. Вопрос довольно философский) «такая» автоматизация не отличается от «обычной» — все метрики и затраты — будут ровно такими-же как и при написании и поддержании тестов «не для верстки». Сложность поддержки тестов зависит от знаний человека который пишет эти тесты.
По поводу ROI вспомнилось обсуждение — automated-testing.info/t/roi/1608

Да, живут вместе)
Да, переиспользуются + много «другого» кода из проекта используется в этих тестах.
TestNG параллелит на ура)

На толковом проекте и CEO и даже рядовой программист будут тестировать свой сайт.
В стремлении сделать качественный продукт — нет ничего зазорного.
Суть не в лейблах и количестве опыта, а в команде и продукте который она делает.

Основная суть автоматизации тестирования именно в автоматизации тестирования)
Так конечно применений много можно придумать, ваш вариант тоже подойдет. Но если мы говорим о тестах, а тем более о автотестах — то хотелось бы максимально этот процесс автоматизировать)
+ Как уже писали ниже — если очень много скриншотов то человеку будет тяжко с таким количеством справится, а так же мелкие ошибки глазом бывает гораздо сложнее заметить.

Не сталкивался с этом инструментом. Но думаю в нем есть пару но:
1. Работает только с веб страницами, в отрыве от них таким инструментом не попользуешься.
( например для мобильных или десктоп приложений, флеша )
2. У нас весь код проекта с тестами написан на джаве и львиную долю написанного кода можно использовать и для тестов верстки, соответственно нет заморочек с логированием, репортингом, элементами на страницах и т.д.

Поправил)