На главную

Не вредит ли качеству вашего ПО тестирование через страх?

2025-08-25T20:00:00Z

Автор: Хосе Каррера (Jose Carrera)
Оригинал статьи
Перевод: Ольга Алифанова

Что такое тестирование, управляемое через страх?

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

Такое поведение может быть вызвано разными причинами: давлением со стороны бизнеса, нехваткой знаний в предметной области, жёсткими сроками и т.д. Ещё один важный аспект — это восприятие качества внутри команды и бизнеса:

Разделяется ли ответственность за качество между всеми участниками команды?
Где находятся контрольные точки качества (quality gates)?

Если процесс построен так, что QA-инженеры становятся единственными "хранителями качества", без полноценного участия других специалистов, это приводит к тому, что тестирование превращается в деятельность, движимую страхом — страхом быть обвинёнными в том, что баг не был обнаружен до выхода в продуктив.

Как в Postman использовать данные из файла

2025-08-19T20:00:00Z

Автор: Ольга Назина (Киселёва)

В Postman есть возможность загружать данные из файла — указал в запросе «возьми имя из файла», сделал файл на 100 имен, и вуаля! Запускаешь 1 запрос, а он выполняется 100 раз с разными данными.

Так удобно готовить тестовые данные. Заранее прикинул классы эквивалентности, и создал всё одним махом. Нужно исправить? Вот он, файлик, в формате csv или json — легко читается, легко исправляется.

А вот что с этим файликом делать дальше? Как сказать постману, что мы хотим подставить эти данные в запрос или в автотест? Где какой синтаксис использовать? Об этом и поговорим в статье на примере системы Users.

Я выложила файлы и запросы, используемые в статье, на гитхаб — можно скачать и использовать «на пробу», так как Users открытая бесплатная система, все запросы будут работать.

Когда данные переезжают: практические советы по тестированию миграции данных

2025-08-18T20:00:00Z

Автор: Константин Сахчинский (Konstantin Sakhchinskiy)
Оригинал статьи
Перевод: Ольга Алифанова

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

Нефункциональные проверки мобильных приложений

2025-08-17T20:00:00Z

Меня зовут Алексей, я работаю тестировщиком в компании «Совкомбанк Технологии». Хочу поговорить о нефункциональном тестировании мобильных приложений на платформах Android и iOS.

Нефункциональные проверки играют ключевую роль в обеспечении качества, удобства использования и стабильности продукта. В сети можно найти множество чек-листов и статей на эту тему, но зачастую проверки, описанные в них, либо избыточны, либо устарели. Более того, редко где объясняется, зачем проводить те или иные тесты и какие процессы происходят «под капотом» приложения.

В этой статье я не только разберу основные нефункциональные проверки, но и расскажу, что происходит с приложением в моменты, когда, например, вы сворачиваете его или выключаете экран – не взаимодействуете с телефоном. Часть тестов применима к обеим платформам, а некоторые актуальны только для Android или iOS. Примеры всех багов взяты из личного опыта тестирования.

Четыре фрейма тестирования, часть 2: четыре типа рисков

2025-08-12T20:00:00Z

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

В первой части этой серии статей я рассказал о двух ключевых вещах, которых бизнес хочет от разработки: это продукт с высокой ценностью и низкой стоимостью. Чтобы бизнес получил продукт с высокой ценностью, мы должны представить себе успешный результат, чтобы начать к нему стремиться.

Вебинар от команды LearnQA «Нагрузочное тестирование с Python и Locust»

2025-08-11T20:00:00Z

Освойте нагрузочное тестирование: создавайте тесты с нуля, имитируйте высокую нагрузку и выявляйте узкие места.

Вебинар поделен на две части общей продолжительностью 5 часов!
Начало: 09 и 11 сентября в 20:00 (UTC+3)

Промокод на скидку для наших подписчиков: LGALDPNA

✍️ Какие темы разберём:

✔ Основы нагрузочного тестирования и ключевые метрики.
✔ Установка и настройка Locust.
✔ Создание тестовых сценариев и пользователей.
✔ Ramp-up, разные типы нагрузок и планирование тестов.
✔ Анализ результатов и поиск узких мест.
✔ Подготовка отчётов для команды и заказчиков.
✔ Интеграция нагрузочного тестирования в CI/CD.

✍️ Кому будет полезен этот вебинар:

✔ QA-инженерам, которые хотят освоить нагрузочное тестирование.
✔ Автоматизаторам, которые хотят добавить в свой стек навыки по performance-тестированию.
✔ Разработчикам, которые хотят проверить, как их сервисы ведут себя под нагрузкой.
✔ Руководителям, которым важно понимать, как оценивать и контролировать производительность продукта.

Видеозапись будет доступна всем зарегистрированным участникам. Если не получится присоединиться в прямом эфире, вы сможете посмотреть запись в удобное время. Главное — не забудьте зарегистрироваться!

Промокод на скидку для наших подписчиков: LGALDPNA

Узнать больше и записаться на вебинар можно по ссылке:
https://www.learnqa.ru/load_python_webinar?erid=2SDnjcxPSN2

Реклама: ИП Батыров Арсений Георгиевич, ИНН 370207708748, erid:2SDnjcxPSN2

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

2025-08-10T20:00:00Z

Оригинальная публикация

Меня зовут Саша – я ведущий исследователь пользовательского опыта в операционных продуктах ecom.tech, @ecom_tech_channel). На наших технологиях работают Самокат и Мегамаркет. В этой статье расскажу, как я оказалась на огромных складах и как мои исследования помогли разработать собственную систему управления складами. Внутри вас ждёт этнография, много тестирования и живые фото. Поехали!

Все о куках приложения для тестировщиков

2025-08-05T20:00:00Z

Автор: Мирза Сизич (Mirza Sisic)
Оригинал статьи
Перевод: Ольга Алифанова

Что (и зачем) тестировщикам нужно знать о куки-файлах (cookies) приложений?

Cookies приложений за 30 секунд или меньше

Важность куки приложений сейчас возрастает. Они способны обеспечить более удобный и плавный пользовательский опыт, но при этом вызывают множество проблем с безопасностью, которые необходимо учитывать при тестировании.

Чтобы правильно тестировать браузерные куки, сначала нужно понять, что такое куки и в каких контекстах они используются. Знание того, как тестировать куки (и различных способов манипулирования ими) может быть очень полезным и ценным навыком для тестировщика ПО.

Идеальное соотношение – сколько тестировщиков нужно команде проекта?

2025-08-04T20:00:00Z

Всем привет! На связи Андрей – QA-лид из Совкомбанк Технологий.

Наверное, все ИТ-специалисты сталкивались с ситуацией, когда непонятно, почему именно столько человек работает над проектом. Или почему связка тестировщиков и разработчиков не работает как слаженный механизм?

В этой статье разберем сколько QA-инженеров нужно проекту, от чего это зависит и есть ли корреляция количества тестировщиков с количеством разработчиков.

Эта статья будет полезна тестировщикам, разработчикам, проектным менеджерам и руководителям команд, чтобы определить нужны ли команде проекта новые люди.

В статье рассмотрим:

Оптимальное соотношение QA-инженеров и разработчиков
Соотношения, которые существуют в реальных проектах и их особенности
Параметры, которые нужно учитывать, чтобы вывести оптимальное соотношение
Вывод идеальной формулы

Цель статьи – найти идеальный баланс количества людей в команде, отталкиваясь от сути проекта.

Падаем с изяществом: руководство по культуре ошибок для тестировщика

2025-08-03T20:00:00Z

Автор: Штефан Дирнштофер (Stefan Dirnstorfer)
Оригинал статьи
Перевод: Ольга Алифанова

Зачем тратить время на продумывание сообщений об ошибках?

Перед моей последней поездкой я попытался зарегистрироваться онлайн. Пользовательский путь, который проходил через утомительную серию полей формы, внезапно завершился кратким сообщением об ошибке: HTTP_400_BAD_REQUEST.

Для любого тестировщика обнаружение ошибки — это заманчивый опыт. В этом конкретном случае мне было бы неплохо обойтись без неё, но у меня было больше причин, чем обычно, оценить, как была обработана ошибка.

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

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

Синдром самозванца у QA-инженера: кто виноват и что делать

2025-07-29T20:00:00Z

Оригинальная публикация

Как ощущается синдром самозванца. pic by kiilnawul

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

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

Щелкаем выключателем: автоматизация тестирования фича-флагов

2025-07-28T20:00:00Z

Автор: Green Report
Оригинал статьи
Перевод: Ольга Алифанова

Флаги-функции (feature flags) – это мощный инструмент контролируемого выпуска новых возможностей, проведения A/B-тестирования и экспериментов. Однако для инженеров по автоматизации тестирования такие фичи, скрытые за флагами, представляют собой отдельную проблему. Как обеспечить полное тестовое покрытие функциональности, которая может быть отключена в одной среде и включена в другой? В этой статье мы рассмотрим стратегии автоматизации тестирования фичей, скрытых за фича-флагами, включая настройку тестов с учётом флагов, проверку как включённого, так и отключённого состояния, и программное управление флагами для упрощения тестирования.

«В ногу со временем»: разбор развития трендов и подходов QA

2025-07-27T20:00:00Z

Оригинальная публикация

Представим ситуацию. 2010 год, вы сидите за компьютером и играете в Counter Strike или Call of Duty. В самый ответственный момент игра начинает подвисать или вы застреваете в текстурах, из‑за чего сливаете миссию. Обидно, но такое бывает по 10 раз в день, поэтому вы смиренно начинаете снова. А теперь представим ту же ситуацию в 2025 году. Очевидно, что сейчас большинство пользователей, столкнувшись с нерешаемой проблемой в игре, в итоге просто забросят ее. Потому что паттерны людей и их требования к продукту меняются. Соответственно, должны меняться и подходы к обеспечению качества ИТ‑продуктов.

Меня зовут Алексей Петров. Я директор по качеству в ОК. В этой статье я в легкой исторической перспективе рассмотрю основные тренды и подходы, которые использовались в недавнем прошлом и актуальны сейчас.

Тестирование как искусство

2025-07-23T20:00:00Z

Автор: Лидия Барканова (Lidia Barkanova)
Оригинал статьи
Перевод: Ольга Алифанова

Креативность в изобразительном искусстве и тестировании

Сколько себя помню, меня всегда интересовало изобразительное искусство. Особенно я любила рисовать, используя разные материалы — от угля до масла. Я умоляла маму записать меня в художественную школу, но этого не случилось… по крайней мере, пока я была ребенком. Вместо этого я стала IT-специалистом, и сейчас работаю инженером по качеству. Ни капли не жалею! Однако моя любовь к изящным искусствам не угасала — и в прошлом году я наконец записалась на уроки рисования.

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

Где набраться практики начинающему тестировщику: от учебных полигонов до open source

2025-07-22T20:00:00Z

Автор: Юлия Ковшова
Оригинальная публикация в блоге YADRO на Хабре

Начать карьеру в тестировании — задача не из простых, особенно когда за плечами только теория и пройденные курсы, а в портфолио нет ни одного реального проекта. Большинство вакансий требуют опыт, которого у новичка еще нет, и именно на этом этапе часто возникает ступор: где взять кейсы, если тебя еще никуда не взяли.

Я Юлия Ковшова, руководитель группы компонентного тестирования защиты данных в YADRO, поделюсь идеями, где получить опыт, если вы недавно в тестировании и хотите дополнить портфолио практическими работами. В статье есть блок и для более уверенных в себе специалистов — сможете почерпнуть пару практик для развития в профессии.

Четыре фрейма тестирования, часть 1: начало

2025-07-20T20:00:00Z

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Разговоры о тестировании повсеместно и довольно давно идут наперекосяк. Как любил подчеркивать Джерри Вайнберг, слово «тестирование» перегружено смыслами и сваливает в одну кучу множество идей и видов деятельности. Это слово применяется к различным действиям, выполняемым разными людьми, работающими в разных контекстах, выполняющими разные задачи с различными приоритетами, в разные моменты процесса разработки. Неудивительно, что люди из настолько разных парадигм говорят, не слыша друг друга.

Эти различия и перегруженность могут приводить к разногласиям. Если не учитывать разницу в контекстах и контекстуальных факторах, не улучшатся ни разговоры, ни тестирование. Возможно, какие-то разногласия можно разрешить, вернувшись к исходным принципам, распаковав, разъединив идеи о тестировании и прояснив, о чем мы, собственно, говорим. В этой довольно длинной серии статей я попробую сделать именно это.

Как я понимаю «компонентное тестирование»

2025-07-15T20:00:00Z

Автор: Никонов Владислав

Почитываю книжку Искусство Agile-тестирования и наткнулся в ней на такую штуку как "компонентное тестирование" (КТ). Я уже не первый раз натыкаюсь на этот термин, в первый раз я поискал инфу об этом, как то не очень понял и забил. Но с каждой последующей встречей у меня все больше подгорало.

Картинка из интернета

В пирамиде тестирования, КТ стоит сразу после модульного. И если unit-тесты это участь разработчиков, то КТ это уже, якобы, зона ответственности тестировщика, отсюда необходимость хоть как то в этом разобраться.

Начнем с определений. Самое крутое (тут сарказм), которое я нашел это - "Компонентное тестирование программного обеспечения - это тестирование отдельных компонентов программного обеспечения". Да и вообще, во многих статьях определение пропускается и пишется, что-то вроде "компонентное тестирование это вид тестирования который следует сразу после модульного и до интеграционного". Еще варианты:

Руководство по критическому мышлению для начинающих

2025-07-14T20:00:00Z

Автор: Джитеш Госай (Jitesh Gosai)
Оригинал статьи
Перевод: Ольга Алифанова

Критическое мышление – отличный инструмент для лучшего понимания ситуации и решения сложных проблем. Однако развитие этой способности – это не просто освоение пары-тройки техник. Тут нужен целый ряд навыков и умений, работающих взаимозависимо, и в них всегда есть, что улучшить. Это путь длиною в жизнь, а не конечная точка, до которой нужно просто дотянуться.

Этот путь может казаться пугающим, но это необязательно так. Ряд ключевых областей может помочь всем и каждому начать развиваться. Простое для запоминания определение – хорошая стартовая точка.

Left Shift Testing: как выстроить процесс, чтобы тесты реально помогали

2025-07-13T20:00:00Z

Автор: Никита Филонов
Оригинальная публикация

Вступление

В этой статье я хочу поделиться взглядом на то, каким может быть оптимальный процесс автоматизации тестирования. Мы разберём, зачем он нужен, почему именно такой подход может считаться эффективным, а также какие плюсы и минусы он несёт. Важной частью статьи станет анализ рисков, к которым может привести нарушение или игнорирование этих процессов. Кроме того, мы ответим на частый вопрос: когда и какие тесты стоит запускать на CI/CD, чтобы это было максимально эффективно и стабильно.

Сразу хочу подчеркнуть: в этой статье мы будем говорить исключительно о концепции процесса, а не о технической реализации. Здесь не будет примеров кода, конфигураций CI/CD, или привязки к конкретным инструментам и фреймворкам. Цель статьи — описать качественную архитектуру процесса автоматизации, которая может быть адаптирована под любой технологический стек.

Ведь в каждой компании свои инструменты, процессы, команды и особенности CI/CD. Универсального "рецепта" не существует — но существует направление движения и принципы, к которым стоит стремиться. Если же вас интересуют технические детали, реализация автотестов или настройка пайплайнов, рекомендую ознакомиться с другими моими статьями:

Также важно отметить, что описанный здесь процесс — это обобщённая концепция. В зависимости от специфики проекта, команды или компании он может меняться. Это не жёсткий шаблон, а скорее ориентир, позволяющий построить стабильную, понятную и эффективную систему автоматизации. Подходите к нему критически и адаптируйте под свои условия — но старайтесь двигаться в этом направлении.

Контрактное тестирование API – визуальное руководство

2025-07-09T20:00:00Z

Автор: Питер Томас (Peter Thomas)
Оригинал статьи
Перевод: Ольга Алифанова

В последнее время интерес к контрактному тестированию растет – появляется все больше и больше инструментов, постов и статей. Но мне всегда казалось, что этот термин несколько недопонят. Такие термины, как «контрактное тестирование, управляемое потребителем», могут сбить с толку новичков тест-автоматизации. К тому же многие материалы, продвигающие контрактное тестирование, упускают ряд важных деталей. Эта статья нацелена на то, чтобы помочь командам понимать и обсуждать ключевые концепции – а также прояснить, что же это такое, и чем оно не является.

Мой опыт говорит мне, что контрактное тестирование – это довольно трудно, и оно требует очень хорошей дисциплины в команде и компании. Команды не должны хвататься за него, не добившись определенного уровня зрелости.

От релиз-менеджера до разработчика: почему я ушел из QA и не жалею

2025-07-08T20:00:00Z

Автор: Николай Алешин (Nikolay Aleshin)

2007-й год не вернуть: профессия QA-инженера, которая ещё недавно была престижной и высоко ценилась, сегодня стремительно теряет влияние, превращая опытного эксперта в «универсального бойца», которому можно спихнуть любую работу. Эта статья — моя личная история, в которой я разбираю, почему профессия больше не ценится и что сделать, чтобы она не попала в красную книгу как исчезнувший вид.

За моим плечами — двенадцатилетний опыт работы в QA, который я начал с должности рядового тестировщика, трансформировавшись по ходу роста компетенции до руководящего QA-лида. Под моим начинанием работала не одна команда, я выстраивал автоматизацию и релизные процессы, улучшая десятки цифровых продуктов как в России, так и в международных компаниях. В какой-то момент мой доход превысил миллион рублей в год, и казалось, что я наконец стал востребованным экспертом. Но, увы, реальность готовила мне не слишком приятный сюрприз.

Даже при наличии опыта, глубокого понимания процессов и бизнес-контекста, квалифицированные QA-инженеры уже не так востребованы, как раньше. Компании по-прежнему нанимают людей на эту должность, но не понимают, зачем она им нужна. Роль QA размыта до предела — теперь это что-то между тестировщиком, аналитиком, DevOps-инженером и ещё бог знает кем.

Последний год поиска работы стал для меня настоящим шоком. Я увидел, как QA-индустрия мутировала в нечто неопределённое: требования нереалистичны, зарплаты мизерные, а доверие к профессии почти исчезло. Это заставило меня переосмыслить свой путь и сделать трудное, но необходимое решение — уйти из QA.

Введение в пайплайны непрерывной интеграции (CI) и непрерывной поставки (CD) для тестировщиков

2025-07-07T20:00:00Z

Автор: Эди Стоукс (Ady Stokes)
Оригинал статьи
Перевод: Ольга Алифанова

Введение

Тестировщики, слыша фразу «пайплайн CI/CD», обычно реагируют двумя способами. Те, кто тесно работал с пайплайнами или занимался автоматизацией, видят в этом возможность. Однако те, кто от автоматизации далек, часто пугается. Я видел, как люди говорили или писали что-то вроде:

Я не очень в этом разбираюсь, это какая-то автоматизация.
Я ручной тестировщик и не участвую в пайплайнах.
Я не пишу код, мне не нужно об этом знать.
Этим занимаются специально обученные люди – это не ко мне.

Пайплайны CI/CD – это, безусловно, часть автоматизации, но это не только и не столько это. В этой статье я расскажу, что это такое, почему тестировщикам надо понимать, как это работает, и почему это важно для них. Начнем с начала – разберемся, что это.

Тестирование почты, Redis, совместимости, составление ИПР, TDD и BDD, AI для автотестов: самые интересные новости тестирования за второй квартал 2025 года

2025-07-03T08:47:08Z

Опубликован выпуск рассылки за 2 квартал 2025 года.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Как мы упростили развертывание почтового сервиса для тестирования или сказ про Mailpit — он же сервис fakemail\mailtrap

2025-07-01T20:00:00Z

Автор: Астапов Святослав, системный инженер
Оригинальная публикация

Привет! В нашей команде возникла задача — развернуть почтовый сервер для удобства тестирования. Цель — проверять, как различные сервисы осуществляют рассылку писем клиентам. В этой статье хочу поделиться нашим опытом, каким решением мы воспользовались и почему оно может быть полезно и вам.

Как справиться с падениями ChromeDriver в Kubernetes: история об устойчивой автоматизации

2025-06-30T20:00:00Z

Автор: Дэн Бурлаку (Dan Burlacu)
Оригинал статьи
Перевод: Ольга Алифанова

Зачем тестировать в Kubernetes?

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

Веб-приложение запускается, как отдельная K8S (Kubernetes) копия для каждой клиентской компании, на отдельном кластере K8S, где ресурсы этой конкретной копии сгруппированы в пространства. UI-тесты автоматически запускаются перед крупными обновлениями версий веб-приложения, а также сразу после, чтобы проверить, что обновление не повредило работе приложения. Это было достигнуто через контейнеризацию кода UI-тестов в образ Docker, его отправку в репозиторий организации и использование задачи K8S для деплоя тестов в конкретном пространстве копии перед обновлением и сразу после него.

Образ Docker, разворачивающийся на сотнях ресурсов, должен быть легким, поэтому тесты запускались в окружении Linux. Запуск в Linux без поддержки дисплея означал, что тесты не могли открыть обычны браузер и вынуждены были использовать режим без графического интерфейса. Вся разработка и тестирование в компании проводятся в Chrome, и поэтому я, естественно, использовал ChromeDriver для запуска настройки Chromium в деплое контейнера. Сервер, отслеживающий расписание обновлений, использовался для запуска тестов в конкретной копии веб-приложения, а тесты возвращали на сервер JSON-отчет о результатах.