Home

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

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

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

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

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

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

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова 

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

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

Автор: Михаил Кургузов

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

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

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Михаил Кургузов

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

Возможные проблемы

1. Плохое знание продукта и некорректное тестирование

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

2. Отсутствие консистентности на разных версиях оборудования