Что общего у кулинарии и автоматизации тестирования?

Автор:

После многих лет работы в тестировании программного обеспечения можно с уверенностью сказать: почти никто не любит писать документацию. Даже люди, которым нравится писать (как мне), могут полагать, что есть дела и поинтереснее – например, создание тест-планов или автоматизации тестов. Но документация крайне важна! В этой статье я расскажу о пяти причинах этого, а также поделюсь пятью стратегиями, которые помогут вашей команде или компании иметь качественную документацию.

Введение

Если вы автоматизируете на Java или Kotlin, вы не могли не слышать о Gradle. Одни его хвалят за скорость и гибкость, другие ругают за сложность конфигурации. Что же это за инструмент и почему всё больше проектов переходят на него с Maven? В этой статье мы разберем Gradle, чтобы вы могли уверенно использовать его в своих проектах для автоматизации тестирования, а так же спокойно ответить на вопросы на собеседовании.

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

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

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

Автор:

Большинство тестировщиков программного обеспечения знает, как проводить граничных значений: например, зная, что текстовое поле должно принимать не более 20 символов, тестировщик проверит ввод 19 символов, 20 символов и 21 символа, а возможно, даже 100 символов. Но я часто сталкивалась с ситуациями, когда тестировщик не проводил тестирование границ, если в критериях приёмки не было явно указано ограничение. Это опасно!

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

Меня зовут Екатерина Кияшева, и я занимаюсь оптимизацией тестирования. Хорошее тестирование начинается с продуманного тест-дизайна. QA важно выстроить проверки так, чтобы тесты действительно были полезными. В этой статье расскажу, как промпт-инжиниринг помогает улучшать качество тест-дизайна, и поделюсь неожиданным открытием об ИИ, вдохновившем на заголовок. Тем, кто хочет сразу к промпту, жать сюда.

Автор:

Обычно, когда я изучаю что-то новое, например язык программирования или новый инструмент автоматизации, мне нравится проходить полный курс. Курсы структурированы для логичного, постепенного обучения. Но иногда, когда я хочу выучить что-то быстро, я использую то, что называю «Методом удаления кода». Не знаю, делает ли так кто-то ещё, но мне хотелось бы думать, что название придумано мной!

Метод удаления кода предполагает работу с проектом, написанным кем-то другим, с целью его понимания путём постепенного удаления строк кода, пока не останется только базовая функциональность. Вот как это работает:

За 8+ лет работы в тестировании я сталкивалась с разными подходами ведения базы знаний для тестировщиков на проектах. Где-то на проектах статей в базе знаний было так много, что глаза разбегались от количества информации, которую нужно было изучить на входе в проект. Но чаще попадались проекты, где базу знаний вели редкими набросками или не вели совсем. И это вызывало чувство безысходности в первые месяцы работы на проекте, так как информацию приходилось собирать буквально по крупинкам и не один месяц.

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

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

Автор:

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

К сожалению, у нас не всегда есть чёткий язык для описания измеряемого. Возможно, вы слышали, как менеджер говорил о достижении «100% тест-покрытия». Но что именно он имеет в виду под этим утверждением? Вот несколько вариантов, что это может означать, и один вариант, чего это значить ни в коем случае не может.

Привет! Я Максим Кузьмин, старший инженер по автоматизации в команде Т-Путешествий. Строю и развиваю процессы автоматизации и разрабатываю инструменты тестирования.

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

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

Автор:

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

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

Поскольку тесты использовали Playwright на TypeScript и были сильно ориентированы на работу с графическим интерфейсом, мы решили начать строить структуру на основе Page Object для ключевого компонента их приложения.

Автор: Ященко Святослав

Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA‑команды Platform V Kintsugi — это графическая консоль для сопровождения PostgreSQL и Postgres‑like СУБД. Ранее я писал о том, как тестировать производительность через вкладку Performance. Материала набралось так много, что мне пришлось разбить его на две статьи. Сегодня мы поговорим об утилите Performance monitor, инструменте Chrome Task Manager и о том, как вывести FPS сайта на экран.

Автор:

Когда я разрабатываю и выпускаю новые функции или исправления ошибок для RestAssured.Net, я сильно полагаюсь на приёмочные тесты, которые постепенно писал. Помимо того, что они служат живой документацией для библиотеки, я запускаю эти тесты как локально, так и при каждом пуше на GitHub для разных версий .NET, чтобы убедиться, что ничего по случайности не сломал.

Но насколько на самом деле надёжны эти тесты? Могу ли я верить, что они будут проходить успешно и падать именно тогда, когда нужно? Покрыл ли я все важные моменты?

Я регулярно говорю и пишу об этом, а также обучаю важности тестирования своих тестов, поэтому логично начать применять это на практике и получить больше понимания о качестве набора тестов RestAssured.Net. Один из подходов к изучению качества тестов — это техника, называемая мутационным тестированием.

Когда я говорю о тестировании тестов, я демонстрирую это с применением мутационного тестирования (недавнюю лекцию можно посмотреть здесь), но до сих пор я в основном использовал PITest для Java. Поскольку RestAssured.Net — библиотека на C#, я не могу использовать PITest, но слышал много хорошего о Stryker.NET – это был идеальный шанс наконец испробовать его в деле.

Дорогие читатели, тестировщики и тестировщицы, сеньоры и джуниоры, ручники и автоматизаторы, а также менеджеры и разработчики -- мы поздравляем всех с наступающим Новым Годом и Рождеством! Пусть в Новом Году исполнятся все ваши профессиональные и личные мечты! Пусть ваши релизы будут стабильными, пользователи и заказчики - довольными! Желаем вам всегда находить баги как можно раньше, и не пропускать на прод ни одного.

С новым 2026 годом!

Привет! Я Павел Лобач из команды инфраструктуры тестирования Т-Банка. Расскажу, как у нас организована инфраструктура для запуска E2E браузерных тестов, как она развивалась и как в итоге вылилась в открытый проект Selebrow. 

Будет много технических подробностей и ни слова про ИИ!

E2E-тесты и как их запускают

E2E-тесты (end-to-end, или сквозные, тесты) занимают вершину пирамиды тестирования. E2E — наиболее комплексные и ресурсоемкие тесты, которые проверяют всю систему от начала до конца, включая взаимодействие всех компонентов и пользовательский интерфейс. 

Суть E2E-тестов в том, чтобы взаимодействовать с тестируемым приложением так, как это делал бы пользователь, и оценивать результат. А пользователь взаимодействует с веб-сервисами, используя браузер, поэтому идея запустить из кода тестов браузер и как-то его заставить автоматически взаимодействовать со страницей кажется здравой. 

Автор:

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

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

Итак, две части про локализацию и её тестирование позади (раз, два), пришло время для третьей.

Как и обещал, сегодня про подробности интеграции в процесс тестирования, чеклист и другие полезности.

С чего стоит начинать интеграцию тестирования в разработку? Правильно, как и любое другое важное дело — с планирования. Причём чем раньше вы всё это дело запланируете, тем будет лучше. 

Автор:

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

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

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

Обратите внимание, что всякий раз, когда я использую слово «тест» в оставшейся части этой статьи, я имею в виду автоматизированный тест / проверку, которая подтверждает или опровергает ожидания относительно поведения нашего продукта. Не думаю, что эта модель так же хорошо применима к исследовательскому тестированию (но буду рад, если меня опровергнут).

Автор: Ященко Святослав

Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA-команды Platform V Kintsugi. Это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Ранее я писал о том, как подменить трафик в DevTools. Сегодня покажу, как тестировать производительность web-приложения, не выходя из Chrome. 

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