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

Если вы ежедневно работаете с API-тестированием и используете Postman, то наверняка сталкиваетесь с повторяющимися задачами: ручное получение и обновление токенов авторизации, изменение параметров запросов для разных сред разработки, копирование данных из ответов для использования в следующих запросах. Эта рутина отнимает время и силы, а также увеличивает вероятность ошибок. Что если большую часть этих действий можно автоматизировать?

В этой серии из двух статей мы пошагово разберем 10 самых полезных pre-request и 10 post-request скриптов, которые, по моему опыту, являются наиболее востребованными при тестировании API, особенно для начинающих QA инженеров. В этой и следующей статьях выполнено ранжирование этих скриптов по их важности и частоте использования, чтобы вы могли сразу осваивать и применять на практике самые необходимые из них. Каждый из 20 скриптов будет сопровождаться простым, понятным примером кода на JavaScript, готовым к применению, а также примерами из практики.

Когда в одной из купленных для нашей ИТ-библиотеки книг начали попадаться забавные терминологические ляпы — вроде «жирных клиентов» и «микрослужб», — нам стало понятно: переводчик явно не из отрасли. Чтобы избежать таких «фейлов» и помочь сделать техническую литературу понятнее, в КРОК появился Read IT Club — команда рецензентов и экспертов, которые добровольно и безвозмездно правят и переводят книги по ИТ.

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

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

В конце — промокод на 25% скидку от наших друзей из издательства Питер. 

Как настроить автоматизацию так, что протокол собирался за одну минуту, а тесты шли без участия инженера? Можно ли организовать такую систему отчетности, чтобы она была полезна не только инженерам, но и представителям бизнеса? И главное: в какой TMS лучше управлять тестированием?

На QA-митапе опытные автоматизаторы из YADRO, Avito.Tech и Т-Банка, а также создатели тест-менеджмент системы TestY обсудили, как вести отчетность в тестировании без лишнего напряжения и какие инструменты должны стать «лучшими друзьями QA-инженера».

Всем доброго дня! Я Святослав Ященко, работаю в СберТехе, лидирую команду QA Platform V Kintsugi — это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Развивается вместе с СУБД Pangolin — целевой в Сбере и не только.

У нашего продукта микросервисная архитектура и Web UI. Часто при тестировании фронтенда я имею дело с ещё не дописанной функциональностью API, или же с ситуациями, когда в контракте API есть расхождения с ожиданиями фронтенда.

Хорошо, когда можно заносить моки в окружение или использовать снифферы с возможностью подмены трафика. Но, по разным причинам, не всегда бывает такая возможность. Что остаётся? Ждать, пока разработчик приведёт API в порядок? Но ведь фронтенд-часть готова уже сейчас и ждёт своего тестировщика...

Решение нашлось под рукой — в моём браузере Chrome. Если вы пользуетесь Chrome, то, вероятно, открываете DevTools. Чаще всего нам хватает вкладок Elements, Console, Network и Application. Но так ли прост DevTools? С этой статьи я начинаю цикл коротких руководств, посвящённых скрытым, но крайне полезным фичам Chrome. И начну с подмены входящего трафика.

Прошу под кат.

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

Привет, меня зовут Андрей и я автоматизатор (остальные в кругу хлопают в знак сочувствия) в hh.ru. В статье расскажу, как мы ввели карантин автотестов, повысив стабильность релизов и скорость доставки.

Сегодня в нашем CI ежедневно запускается более 5 000 автотестов, которые проверяют всё: от корректности скриншотов панели до скорости отклика API. Это не просто тулза в пайплайне, а часть инженерной культуры команды, которая помогает нам выпускать изменения быстро и с уверенностью.

Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud.

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

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

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

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

Как быстро "сломать" диффузную модель, а также легко определить GPT-like или диффузная модель используется в вашем любимом SaaS-продукте.

31 мая Госуслуги предложили интересную концепцию – проверку знаний ИТ-специалистов и подтверждение их навыков.

Для меня вопрос
“Можно ли доверять таким сертификатам”
является весьма актуальным, так как я участвую в подборе кадров.

Пришлось немного покопаться "под капотом" всей этой затеи с тестами и как итог родилась идея для статьи.

Аз есмь

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

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

Документация есть, тесты написаны, проверки закончили, даже QA не выгоревший. И всё равно за день до выкладки что-то ломается. Мы собрали истории — из больших и не очень команд — о том, как баги всплывают в последний момент и что с этим делать, если вы не Google, а просто хотите выкатиться без боли.

Привет, Хабр! Меня зовут Наталия, и я руковожу отделом тестирования в группе компаний Экзон. Начала карьеру в IT 7 лет назад с позиции стажера автоматизатора, работала фулл-стек тестировщиком, тех-лидом и имею опыт построения команд тестирования с нуля.

Когда я пришла на проект, у нас было 9 тестировщиков, из которых только двое умели писать автотесты. Остальные работали вручную, а покрытие автотестами составляло 30% на двух модулях из шести. Регресс длился вечность, баги вылезали в продакшене, а команда мечтала о волшебной кнопке “Протестировать всё”. Но вместо поиска магии мы выбрали стратегию, которая сократила время регресса и жизнь багов. И да, мы не нанимали дорогих аутсорс-гуру и не продавали душу рекрутерам.

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

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

Привет, Хабр. На связи Даниил Кобылкин (@danilkkk) и Тимофей Тимошевский (@timhok17). Мы фронтенд-разработчики в Одноклассниках.

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

Рассказываем в статье, какие инструменты и подходы для генерации юнит‑тестов существуют, и как мы научились генерировать юнит‑тесты в своем проекте.

Всем привет. Меня зовут Татьяна Цикунова. Я системный аналитик в компании МойСклад. В этой статье расскажу о том, как организовать оперативный обмен информацией между участниками проекта и поддерживать документацию в актуальном состоянии Отдельное внимание уделю работе с таск‑трекерами — подробно опишу шаблон тикета, который успешно используется в нашей компании. Однако — если вы работаете без трекера задач, например, в ворд‑файлах, суть от этого не меняется ‑такой подход работает и с другими инструментами.

Я документирую системы больше 3 лет, и за это время успела поработать в разных сферах.. Начинала в финтехе, где успела поработать в разных командах. Потом перешла в МойСклад — здесь углубилась в e‑commerce направление. Сейчас вместе с командой делаем интеграции с интернет‑магазинами и маркетплейсами. За годы работы я убедилась, что не существует единого стандарта ведения документации — каждая компания и даже отдельные команды внутри одной организации вырабатывают свои подходы. маркетплейсами. В разных компаниях свой подход к ведению документации, даже в разных командах одной компании бывают разные подходы.

Однажды в МоемСкладе мы задумались: почему бы не начать системно собирать важные данные, которые появляются на разных этапах разработки? Ведь эти сведения могли бы стать отличной основой для обновления документации к реализованному ПО. Так и появились требования и рекомендации по описанию тикета.

Когда я вижу очередную статью или видеоурок про тестирование кода, я почти уверен, что мне опять расскажут про моки.

Создаётся впечатление, что это самый лучший и правильный способ писать тесты, и вообще, невозможно обойтись без моков. Это не так! Можно писать тестируемый код без моков. Более того, использование моков следует избегать и использовать их только в специфичных случаях.

Когда-то мой чек-лист «готова ли фича» выглядел как молитва джуна: открыть браузер, нажать пару кнопок, убедиться, что в консоли нет красного цвета (желтое — это нормально, да?), и смело делать merge.

В те времена React был еще зеленым, Backbone уходил в архив, а модные парни на конференциях говорили про какое-то тестирование. Я слушал их как индеец — много слов, мало понимания.

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

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

Последние месяцы Model Context Protocol (MCP) — буквально из каждого утюга.
YouTube, Twitter, конференции, доки — все жужжат:

MCP — это прорыв, новый стандарт дебага, интеграция AI в тесты нового поколения и прочее.

Звучит круто. Но, как это часто бывает, — всё сложно, перегружено и на птичьем языке.

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