Home

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

Меня зовут Эдвард. В сфере обеспечения качества я с 2012 года. Последние 7 лет работаю в Т-Банке, начинал со старшего специалиста по тестированию бэкэнда и работал в Т-Инвестициях. А сейчас занимаю позицию QA Head управления разработки социальных платформ.

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

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

Если вы провели последние несколько лет в бункере, вы, вероятно, заметили этот колоссальный всплеск применения искусственного интеллекта (ИИ) практически ко всем текущим задачам — в тестировании программного обеспечения, в разработке и вообще в жизни.

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

Сегодня почти любая техническая новинка с намёком на «ИИ» мгновенно объявляется «прорывом», чтобы на следующей неделе уступить место следующему «ключевому» и «революционному» «решению».

Автор: Екатерина Ступкина

Представьте, что аутентификация — это ключ от дома, а авторизация — список комнат, в которые этот ключ открывает дверь. В современных приложениях простой ключ-пароль заменяется сложными системами: токенами, OAuth 2.0 и OIDC.

Я, Екатерина, QA Lead в «Лиге Ставок», покажу, как с помощью инструментов тестирования проводить базовые проверки: тестировать валидность токенов, отслеживать их обновление и проверять корректность прав доступа.

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

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

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

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

Привет! На связи разработчик Максим и инженер по качеству Евгения из Т-Банка. Как-то мы задумались о переходе на TBD (Trunk Based Development), чтобы избежать develop-ветки со всеми вытекающими. 

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

В этой статье мы поделимся опытом перехода на TBD: планом внедрения и вопросами, с которыми мы столкнулись.

Cтатья пригодится инженерам уровня middle и ниже и тимлидам. Для senior-инженеров статья не будет откровением, но надеемся, что станет местом для обсуждения нюансов внедрения или возможностью посмотреть на процесс с точки зрения QA. 

Погнали!

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

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

В этой статье мы рассмотрим три эффективных метода автоматизации слайдеров: перетаскивание (drag-and-drop), взаимодействие с помощью клавиатуры и прямой ввод значения. Каждый из этих подходов обладает своими плюсами и минусами, и мы подробно разберём, как их реализовать, а также в каких случаях каждый метод будет наиболее полезен.

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

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

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

Привет! Я Наталья, QA в команде инкассации. Моя система умеет планировать маршруты для инкассаторов T-Банка. Поделюсь докладом моего коллеги — архитектора Boxy SDK Дмитрия Кузнецова, — который услышала на конференции Heisenbug. 

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

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

Тестирование — это наука не о том, чтобы доказать, что программа работает корректно, а о том, чтобы доказать, что она работает НЕкорректно. И если доказать это не удалось, то с какой-то вероятностью программа работает корректно. Остается некоторый пробел. Давайте рассмотрим, что за это за пробелы, откуда берутся и как можно их минимизировать.