Тестирование веб-сервисов *

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

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

Если вы хотите пощупать GraphQL API с ТЗ на русском языке, то добро пожаловать в мою песочницу — систему Cards.

Тут есть пользователи и их банковские карты. Можно пополнить баланс банковской карты, можно переводить деньги с одной карты на другую. Есть графический интерфейс и API. Есть даже ролевая модель! И даже ТЗ есть, хоть и не супер подробное =)

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

Конечно, сейчас уже есть инструменты на базе искусственного интеллекта, такие как GitHub Copilot, ChatGPT и Claude, которые пытаются облегчить нам жизнь. Но давайте будем честны — они также заставляют нас желать большего.

Вам когда-нибудь хотелось, когда вы активно погружались в сложный проект, чтобы ваш AI-помощник видел всю картину в целом? Например, понимал общую архитектуру, ваш стиль кодирования и специфические особенности проекта?

Вот тут-то и приходит на помощь Cursor.

Всем привет! Нагрузочные тесты за 5 минут (ну почти).

Не так давно делился историей о том, как решали проблему E2E автотестов в маленьком проекте. Продолжим историю).

Когда фича «протестировать табуретку» вызывает нервный смех у тестировщиков и недоумение у менеджеров, пора разобраться, как на самом деле работает тестирование. Привет, Хабр. Меня зовут Елизавета Лященко, я работаю тестировщиком 5 лет, из которых 1.5 года в Самолете, и сегодня разложу по полочкам весь цикл проверки — от странных требований до стресс-тестов и финального релиза. Мы узнаем, почему тестировщик задает миллион вопросов, чем его работа отличается от «я всё проверил, всё ок» и как тестирование спасает команду от хаоса. Ну и готовьтесь увидеть табуретку так, как вы ещё никогда её не видели!

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

Привет! Меня зовут Данила, я фронтенд-тимлид в KTS.

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

Разработка через тестирование (TDD) — это отличный метод, который позволяет быстро получать обратную связь по идеям дизайна и реализации, а также быстрее прийти к работающему решению.

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

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

Всем привет! Меня зовут Александр Наумов, я работаю в IT больше 12 лет, из которых последние несколько лет занимаюсь тестированием. В SM Lab я курирую тестирование в продуктовых командах. Вообще, я адепт продуктового подхода — люблю, когда команды деплоят ценности продукта в продакшн, а не просто делают задачи.

Привет! Меня зовут Ольга Инеева, я ведущий инженер по обеспечению качества в Т-Банке. Расскажу о проблемах тестирования интеграции и об инструменте для мокирования Mockingbird. Мы решили проблему сложных связанных сценариев и хотим поделиться этим знанием. Добро пожаловать под кат!

Всем привет. Меня зовут Ирек, и я в профессиональном IT с 2012 года. Прошел путь от специалиста службы поддержки до разработчика. На данный момент занимаюсь автоматизацией тестирования в компании РТК ИТ.

В статье хочу рассказать о своём опыте автоматизации тестирования websocket. О том какие грабли собрал и какой в итоге велосипед изобрёл.

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

В этой статье рассказывается про 7 самых часто встречающихся критериев качества c с примерами.

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

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

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

Меня зовут Денис Федоров, я тестировщик в команде 2ГИС ПРО, сервисе геоаналитики для бизнеса. Рассказываю, что такое гит-хуки, чем они могут быть полезны и как их можно реализовать у себя. 

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

Всем привет! Меня зовут Люба, и я инженер по тестированию в команде Ozon Partners Platform. Наша команда занимается поддержкой и развитием системы, предназначенной для развития сети пунктов выдачи Ozon. Одним из компонентов этой системы является Открытая карта.

Хочу рассказать, как мы научили автотесты находить на ней точки, подходящие для открытия нового ПВЗ.

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

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