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

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

Документация есть, тесты написаны, проверки закончили, даже 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: без зауми, с примерами и аналогиями, которые реально помогают врубиться в тему.

Всем привет! Снова на связи Александр, автор проекта Peakline. Несколько дней назад я опубликовал здесь статью о своем «швейцарском ноже» для анализа тренировок, который я пилил в свободное время. Я ожидал пары конструктивных комментариев и, может быть, нескольких новых пользователей.

Я жестоко ошибался.

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

До этого мы неделями обсуждали, где разместить форму, когда показывать оффер, как быть ненавязчивыми. А потом всё сломалось — и начало работать лучше.

Вот что случилось и какие выводы я из этого сделал.

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

Облако — большой и сложный продукт, поэтому и процесс тестирования может растянуться… Всем привет! На связи Галина Чупрова, главный инженер по тестированию Облака Рег.ру. В какой-то момент мы с командой поняли, что чем раньше начать тестирование — тем меньше багов получим на выходе. В статье расскажу про этапы, которые помогут устранить «узкие горлышки» в процессе проверки качества продукта и подключить команду с первых шагов проекта. Будет полезно тем, кто начинает путь в тестировании или хочет по-новому взглянуть на процессы в своих командах. Поехали проходить этот квест!

Автоматизация тестирования API — задача, с которой сталкиваются даже опытные инженеры, но многие всё ещё предпочитают полагаться на ручные запросы в Postman, а затем переносят их в код — и так годами. Но можно ли избежать этого лишнего шага? В этой статье мы покажем, как настроить эффективную автоматизацию тестов API с Postman и Newman, интегрируя их в процессы CI/CD, чтобы избежать ошибок и повысить производительность.

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

В этой статье рассказываю, как мы автоматизировали процесс A/B-тестирования CRM-рассылок, встроили Trisigma в процессы, и почему маркетологи теперь могут делать всё сами.

Привет, тестировщики и кодеры! Представь: пишешь автотесты для UX, всё красиво, запускаешь — и каждый тест начинает с нуля: логин, пароль, кнопка. Как будто у тестов амнезия! Это бесит, тормозит и превращает код в копипасту. Давай разберёмся, как выкинуть повторный логин на свалку и ускорить всё с Playwright и Python.

Платформа Lovable, позиционируемая как low‑code решение для создания веб-приложений и сайтов, где основное взаимодействие с системой происходит через чат с искусственным интеллектом, столкнулась с критической уязвимостью, связанной с RLS-политиками. Она позволила получать и изменять данные без аутентификации — сотни проектов оказались под угрозой.

Всем приветы! Меня зовут Антон, я Tech Lead DevSecOps в местной биг-тех компании. Хочу начать с кратенького предисловия, почему я решил написать что-нибудь про DevSecOps. Я довольно-таки часто сталкиваюсь с непониманием, что же автоматизируют и для чего нужны DevSecOps инженеры, где их место в компании и в современном ИБ. Да и что далеко ходить, многие коллеги DevOps, сами считают, что с добавлением trivy или sonarqube в пайплайны, ты уже носишь гордое звание DevSecOps.

Поэтому в этой статье поговорим о том, как должны выглядеть DevSecOps пайплайны, чтобы они трансформировались во что-то зрелое. В Security Gate!

Не только рэп и андеграунд рождаются в Газгольдере — теперь там соберутся и те, кто «качает» процессы тестирования. Как инженерный подход помог создать востребованный инструмент для QA-команд, можно ли с нуля построить автоматизацию оборудования на Bash и почему отчетность — это не про таблицы, а про доверие к процессу? Об этом и не только поговорим 19 июня на QA-митапе от YADRO в Газгольдер Event Hall — живо, с практикой и участием экспертов из Avito, Т-Банка и YADRO. Регистрируйтесь и присоединяйтесь — онлайн или оффлайн.

Скептики часто говорят:
«Юнит‑тесты? Это же лишняя морока.»
«Код всё равно придётся менять — зачем тестировать то, что всё равно устареет?»
«У нас нет времени на это.»

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

Давайте разберёмся с популярными мифами.