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

Да, у нас есть стандартные коды 400, 404, 500 и прочие популярные ошибки, но есть и куча других. Не знаю как вы, а мне периодически приходится выяснять, что значит та или иная http-ошибка и как их воспроизводить. А когда приходят задачи из категории «проверить логирование ошибок запроса ....», то иду гуглить, как их провоцировать.

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

Всем привет, коллеги‑тестировщики и интересующиеся. Я Сергей, Senior Manual QA Engineer в «Петрович‑Тех».

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

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

Всем привет! Меня зовут Сергей, я — Senior Manual QA Engineer в »Петрович‑Тех», и в этой статье я предлагаю разобрать граничные значения на практических кейсах.

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

Несмотря на то, что техника простая — она решает много проблем. Это не попарное тестирование, о котором я писал здесь, где есть куча инструментов на выбор, надо правильно составить входные данные, потом анализировать их и выдавать результат. Тут всё проще: мы руководствуемся чистой логикой.

Разберем в статье конкретные примеры использования этой техники.

Всем привет! Меня зовут Сергей Герасимов, я – Senior QA Manual Engineer (да, хвастаюсь) в компании “Петрович-Тех”.

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

Звучит просто, но что кроется за ней?

В своей прошлой статье я рассказывал о тестировании оплат, техниках тест-дизайна, которые использовал, и всячески открещивался от попарного тестирования. Но вот злой рок дошел до меня, и сегодня я расскажу о недавнем опыте использования “попарки” на практике. 

Привет, Хабр! Меня зовут Сергей, я тестировщик в “Петрович-Тех”. В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.

На всем своем профессиональном пути тестировщика я так или иначе всегда работал с оплатами (люблю деньги, что поделать). Вместе с командой Петрович-Тех успел поучаствовать во внедрении оплаты частями, добавлении СБП, полном редизайне корзины в интернет-магазине, сейчас тестирую оформление заказа.

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

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

Приступим!