Автор:

В этой серии статей я обращусь к уязвимостям из списка топ-10 OWASP, посвященного безопасности API. В каждой статье я покажу вам, как экспериментировать с API, тестируя уязвимость, и обсужу свои выводы.

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

Введение

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

Этот чек-лист я написал для себя, чтобы протестировать на проекте push-уведомления для iOS и Android, и возможно он может быть будет полезен другим тестировщикам, что бы упростить немного работу, а также уточнить или добавить этот чек-лист в комментах.

Автор:

В последнее время я экспериментирую с Vitest — фреймворком для тестирования JavaScript- и TypeScript-приложений. Я начал работать с этим инструментом недавно и был приятно удивлён его возможностями.

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

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

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

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

Автор:

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

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

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

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

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

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

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

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

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

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

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

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

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

Погнали!

Автор:

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

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

Автор:

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

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

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

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

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

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

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

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

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

В прошлый раз мы рассмотрели, чего бизнес хочет от разработки. А чего бизнес хочет от той части разработки, которую мы называем тестированием?

Иногда говорят, что бизнесу от тестирования нужна уверенность — подтверждение того, что всё в порядке. Это понятно: уверенность — приятное чувство для дизайнеров, разработчиков, менеджеров и всех остальных. Но уверенность и спокойствие — это не цель бизнеса. Цель бизнеса — ценный, беспроблемный продукт.

Как мы учимся новому:

1. Самостоятельно — читаем книги, статьи, смотрим бесплатные материалы в интернете.

2. На курсах / с ментором — помимо обучающих видео и статей идет закрепление материала в виде домашних заданий.

Но ведь теперь есть ChatGPT (и его аналоги) — искуственный интеллект (ИИ), очень много знающий. Ему можно задать любой вопрос и получить развернутый ответ. Как он изменит обучение? Заменит ли он тренера на курсах? Или будет ему помогать?

См также:

Базовая подборка аналогов ChatGPT (текстовых ИИ) — чаты, с которыми можно пообщаться

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