На главную

Бюджетное тестирование облачных приложений: Testcontainers и LocalStack

barancev@gmail.com (Administrator) — Wed, 03 Jun 2026 20:00:00 +0000

Автор: Фернандо Тексейра (Fernando Teixeira)
Оригинал статьи
Перевод: Ольга Алифанова

Облачные приложения: текущая ситуация

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

Сегодня вы можете построить приложение, на 100 процентов работающее в облаке. Наиболее популярны сейчас облачные провайдеры AWS, Google Cloud и Azure. Именно эти трое во многом обеспечивают работу большинства облачных приложений. В 2023 году компании потратили примерно 270 миллиардов долларов США на облачную инфраструктуру — на 45 миллиардов больше, чем годом ранее.

Большинство облачных провайдеров взимают плату в зависимости от объёма использования сервисов. Чем больше вы используете сервисы провайдера, тем серьезнее будет счёт в конце месяца. Как правило, провайдеры всё ещё предлагают бесплатный тариф, но при превышении определённого лимита вам всё равно придётся платить. Проблема в том, что многие компании сильно зависят от этих сервисов и активно их используют, из-за чего сложно оставаться в рамках лимитов. 49 процентов компаний испытывают трудности с контролем затрат на облако, а 33 процента превышают бюджет на облако на 40 процентов.

Как мы создали новый тестовый фреймворк, адаптируемый к росту проектов

barancev@gmail.com (Administrator) — Sun, 31 May 2026 20:00:00 +0000

Меня зовут Анатолий Бобунов, и в EXANTE я SDET — Software Development Engineer in Test. В последние несколько лет я развивал тестовую архитектуру для бэкенд‑сервисов компании.

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

Со временем такие решения начали накапливаться. Разные сервисы использовали разные паттерны для HTTP‑клиентов, ретраев, подготовки данных и валидации ответов. Общие абстракции постепенно размывались, а направление зависимостей становилось менее очевидным. Дополнительно ситуацию усиливали срочные задачи, которые требовали быстрых изменений без полноценного архитектурного пересмотра. Это приводило к появлению временных решений, которые затем становились постоянными.

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

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

Полезные навыки тестировщиков, юз-кейсы внедрения ИИ и TestContainers, принципы и инструкции для успешной автоматизации, и многое другое: самые интересные новости тестирования за февраль-май 2026

barancev@gmail.com (Administrator) — Thu, 28 May 2026 12:14:35 +0000

Опубликован выпуск рассылки за декабрь-январь.

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

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

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

Не просто «ручное тестирование»: ценные навыки тестировщиков

barancev@gmail.com (Administrator) — Mon, 25 May 2026 20:00:00 +0000

Автор: Эди Стоукс (Ady Stokes)
Оригинал статьи
Перевод: Ольга Алифанова

Почему я это пишу

Если вы какое-то время работаете тестировщиком ПО или в разработке, вы, скорее всего, сталкивались с термином «ручное тестирование». Это выражение может вызывать бурные споры.

И дело не только в разных мнениях. Сам термин часто искажает суть тестирования. В худшем случае «ручное тестирование» создает вредный водораздел, обесценивая вклад человека и чрезмерно возвышая автоматизацию. В лучшем — умаляет значимость вдумчивых усилий тестирования.

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

Почему интуиция вас подводит: 5 ловушек теории вероятностей в IT

barancev@gmail.com (Administrator) — Wed, 20 May 2026 20:00:00 +0000

Автор: Александр Заплавный

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

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

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

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

Как организовать bug bash: руководство для тестировщиков

barancev@gmail.com (Administrator) — Mon, 18 May 2026 20:00:00 +0000

Автор: Парвин Хан (Parveen Khan)
Оригинал статьи
Перевод: Ольга Алифанова

Что такое bug bash?

Вам когда-нибудь хотелось превратить тестирование в вечеринку? Bug bash как раз позволяет это сделать! Ну, не всё там сводится к веселью и играм: обычно самый крепкий напиток — это чёрный кофе, и вряд ли вам захочется нанимать диджея – но при этом можно неплохо провести время и заодно узнать важные вещи о продукте и качестве.

Bug bash укрепляет сотрудничество, даёт возможность выслушать разные точки зрения и помогает формировать и укреплять культуру качества. Обычно bug bash выглядит примерно так:

Вы приглашаете кросс-функциональную команду: тестировщиков, разработчиков, продакт-оунеров, дизайнеров, стейкхолдеров. Иногда это просто продуктовая команда, а иногда — люди, которые обычно не ходят на ваши встречи – например, юристы или маркетологи. Важно пригласить и тех, кто ещё не пользовался продуктом (или не пробовал новые фичи).
Вы задаёте общие правила тестирования продукта. Как и на обычной вечеринке, хороший хозяин должен обозначить ожидания и рамки.
Веселитесь! Геймифицируйте тестирование (несколько идей ниже).
В течение нескольких часов или даже нескольких сессий по паре часов команда сосредоточенно тестирует продукт, следуя заданным правилам.
Обязательно заложите время на перерывы.
Закуски и напитки тоже всегда приветствуются.

Как ускорить автотесты на Python в Pytest в 8,5 раз

barancev@gmail.com (Administrator) — Wed, 13 May 2026 20:00:00 +0000

Автор: Анатолий Бобунов

Меня зовут Анатолий Бобунов, я работаю SDET в компании EXANTE. Однажды я пришел на проект, на котором выполнение некоторых тест-сьютов занимало больше часа, настолько медленно, что запускать их на каждый merge request (MR) было просто нереально. Мы хотели запускать автотесты на каждый коммит в MR, но с такой скоростью это было невозможно. В результате мне удалось, за счёт серии небольших, но точных изменений добиться 8,5-кратного ускорения - без переписывания тестов с нуля. В статье расскажу, какие проблемы у нас возникли и как мы их решали.

10 мощных тестов с Chrome DevTools

barancev@gmail.com (Administrator) — Mon, 11 May 2026 20:00:00 +0000

Автор: Кастури Раджаманиккам (Kasturi Rajamanikkam)
Оригинал статьи
Перевод: Ольга Алифанова

Знаете ли вы, что Chrome DevTools предназначены не только для разработчиков, но и для тестировщиков? Для QA-специалиста важно не просто находить баги — понимание первопричин их появления и умение предложить возможные решения выводит тестирование на новый уровень.

Если вы не пользуетесь Chrome, аналог Chrome DevTools с похожим функционалом можно найти в любом современном браузере, так что вы можете выполнять эти проверки в браузере по своему выбору.

Чтобы максимально эффективно использовать Chrome DevTools, тестировщикам стоит иметь базовые знания HTML, CSS, DOM, JavaScript и уметь читать сетевые ответы.

Первый месяц в Bug Bounty: итоги, цифры и выученные уроки

barancev@gmail.com (Administrator) — Wed, 06 May 2026 20:00:00 +0000

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

Мой путь в ИБ начался с нуля - у меня не было опыта работы и образования в айти в целом, будь это системное администрирование или программирование. Я просто планомерно учился и сдавал сертификации. За три года у меня собрался определенный стек: OSCP, HTB CWES, CRTP, PNPT, PJPT, PJOR, CompTIA A+, Network+ и Security+.

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

Основная цель была простой получить опыт и проверить свои знания в бою, а не в лабораторной среде. Ну и, конечно, был интерес заработать репутацию практика и получить первые выплаты.

Когда тестировщик в отпуске, команда справится!

barancev@gmail.com (Administrator) — Sun, 03 May 2026 20:00:00 +0000

Автор: Эмили О’Коннор (Emily O’Connor)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Внедряем Testcontainers за два дня или как перестать бояться рефакторинга и начать доверять своим тестам

barancev@gmail.com (Administrator) — Tue, 28 Apr 2026 20:00:00 +0000

Автор: Леонид Сухин

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

Подход, который я долгое время использовал массово - написание юнит-тестов с использованием Mockito. В заглушки превращается любой сторонний сервис, используемый тестируемым классом. Тесты супер-быстрые, все зеленое, все супер!

Со временем я заметил, что этот подход начал изрядно напрягать. Часто на две строчки кода приходилось писать не менее 10-20 строк теста. Огромное количество переопределений поведения заглушек. Проверки, что тот или иной метод сторонних сервисов более не вызывался или вызывался не более определенного количества раз. Без преувеличения, огромное количество бойлер-плейт кода в тестах.

Дальше - больше. Множество зеленых галочек, появляющееся на экране при запуске тестов, не могло не радовать. Но вот ты решаешь сделать минимальный рефакторинг, оптимизировать какой-то метод. В этот момент все разваливается на куски. Куча красных тестов! Как, почему? Да просто во внутренней реализации ты перешел на использование другого метода, добавил в метод еще один параметр или что-то подобное. В результате куча тестов перестала работать. И теперь, поменяв одну строчку в процессе рефакторинга, надо поменять еще 30 строк в тестах. В какой-то момент начинаешь ловить себя на мысли - “Ни в коем случае, никаких рефакторингов больше!”

10 способов тестировать iOS-приложения: состояния и стадии жизненного цикла

barancev@gmail.com (Administrator) — Sun, 26 Apr 2026 20:00:00 +0000

Автор: Борис Добрецов (Boris Dobretsov)
Оригинал статьи
Перевод: Ольга Алифанова

В этой статье я расскажу о жизненном цикле и состояниях приложений для iPhone и iPad. Но подождите — зачем вам вообще это знать? Сейчас объясню.

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

Декарт, Поппер и баг в продакшене, или почему самый полезный предмет в моей карьере не имел отношения к ИТ

barancev@gmail.com (Administrator) — Thu, 23 Apr 2026 20:00:00 +0000

Автор: Дюжев Михаил

"Небо над Берлином" (Der Himmel über Berlin, 1987), режиссёр Вим Вендерс

Вдохновлено Михаилом Ивановым, коллегой и товарищем, который напомнил про "Мир искусства"

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

Прямое. Но не потому, что я умею "понимать людей" или "находить подход к разработчикам". Дело в другом предмете из учебного плана.

На третьем курсе нам читали философию науки: Декарт, Поппер, Лакатос, Кун, принцип фальсифицируемости, бритва Оккама. Три семестра о том, как человечество училось отличать знание от заблуждения. Тогда это казалось красивой, но бесполезной абстракцией. Ну зачем практикующему психологу знать, как Карл Поппер спорил с венскими позитивистами, а Имре Лакатос уточнял его идеи?

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

Оказалось, философия науки - это не про философию. Это операционная система для мозга, который работает с неопределённостью. И эту статью я вынашивал не один год, чтобы наконец объяснить, почему.

Уроки TDD глазами тестировщика

barancev@gmail.com (Administrator) — Tue, 21 Apr 2026 20:00:00 +0000

Автор: Арун Вишуанатан (Arun Vishwanathan)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Мы пробили новое дно: change request-ы и баг-репорты, которые никто не понимает

barancev@gmail.com (Administrator) — Sun, 19 Apr 2026 20:00:00 +0000

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

Мы, кажется, пробили новое дно.
И что особенно удивительно, Карл! – аккуратно, без паники, с хорошей формулировкой и абзацами.

Я сначала не понял, что стало происходить. Было ощущение странного дежавю: читаю change request или баг-репорт, киваю, вроде всё логично... но что-то не так, как будто где это уже читал. Слова правильные. Причинно-следственные связи на месте. Термины употреблены верно. Пытаюсь понять в чём проблема – ноль. Как будто читаешь инструкцию к микроволновке, а не описание реальной проблемы. Пытаюсь прочитать ещё раз и ещё раз - с трудом продираюсь через текст с каким-то смутным понимаем того, что написано.

И тут до меня доходит - как обухом по голове.

Как распутаться: руководство для застрявших тестировщиков

barancev@gmail.com (Administrator) — Tue, 14 Apr 2026 20:00:00 +0000

Автор: Эди Стоукс (Ady Stokes)
Оригинал статьи
Перевод: Ольга Алифанова

Почему я написал эту статью

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

Быть «работником умственного труда» непросто. Требуются усилия, дисциплина и практика, чтобы думать за деньги. Но именно на это подписывались тестировщики, и именно это нам и предстоит делать.

Давайте поговорим о «затыках» на работе. Что это такое на самом деле, почему это происходит и что мы можем сделать, чтобы продвинуться дальше?

Лучшие практики автоматизации тестирования: 9 принципов стабильных автотестов

barancev@gmail.com (Administrator) — Sun, 12 Apr 2026 20:00:00 +0000

Автор: Никита Филонов, автор курса «Автоматизация тестирования UI + API с Python»
Оригинальная публикация

Представьте утро. Вы открываете ноутбук, заходите в Allure — и видите красное море.

Падает половина автотестов, часть — «временно», часть — «иногда». Почти каждый день начинается с одних и тех же починок, дебага и «вроде теперь стабильно».

Знакомо? Скорее всего да, иначе вы бы не открыли эту статью.

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

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

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

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

Четыре причины прекратить тестирование: правильный баланс качества ПО

barancev@gmail.com (Administrator) — Tue, 07 Apr 2026 20:00:00 +0000

Автор: Штефан Дирнштофер (Stefan Dirnstorfer)
Оригинал статьи
Перевод: Ольга Алифанова

Для сокращения усилий тестирования или полного прекращения тестирования какой-то области может быть множество причин.

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

Но даже самое тщательное тестирование не может покрыть все – некоторые участки продукта остаются непротестированными. Итак, что же выкинем за борт? Когда разумно прекращать тестировать? И как решить, какие компоненты не заслуживают излишнего рвения?

Перенос тест-кейсов из Яндекс Трекера в Allure TestOps одной командой с Cursor + MCP

barancev@gmail.com (Administrator) — Sun, 05 Apr 2026 20:00:00 +0000

Автор: Олег Малышев, телеграмм-канал автора про QA,QA Auto, AI, Вайбкодинг

Всем привет! Я один из лидеров стека тестирования в компании ТехВилл. Продолжаем разговор про то, как применять AI в работе так, чтобы он реально экономил время. В прошлой статье я рассказывал, как мы внедряем AI-ревью ручных тест-кейсов. А сегодня --ещё один не самый типичный кейс для Cursor: перенос тест-кейсов из Яндекс Трекера в Allure TestOps буквально одной командой.

Проблема: тест-кейсы живут в ЯТ, а должны жить в TestOps

Исторически так сложилось, что одна большая команда вела все свои тест-кейсы и чек-листы в Яндекс Трекере. А дальше случилось неизбежное: появилась потребность перевести всё в Allure TestOps, потому что:

Это «правильно» (единая TMS),
это «модно-молодёжно» (аналитика, связи, артефакты),
можно нормально связать с автотестами и CI/CD,
и главное — вся остальная компания уже живёт в TestOps, или почти вся.

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

Уроки качества: работа с Cursor и Windsurf

barancev@gmail.com (Administrator) — Wed, 01 Apr 2026 20:00:00 +0000

Автор: Марк Уинтерингэм (Mark Winteringham)
Оригинал статьи
Перевод: Ольга Алифанова

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

Какое влияние эти инструменты окажут на качество работы разработчиков и создаваемых ими продуктов? Я решил исследовать этот вопрос, создав проект с использованием двух популярных ИИ-IDE для разработки — Cursor и Windsurf. Ниже – то, чему я научился, и мои наблюдения, как эти всё более популярные инструменты могут повлиять на нашу работу как инженеров по качеству.

1 тест = 1 проверка. Чем хорош принцип атомарности в автотестах в Postman

barancev@gmail.com (Administrator) — Sun, 29 Mar 2026 20:00:00 +0000

Автор: Ольга Назина (Киселёва)

Принцип атомарности (объект или операцию нельзя разделить на части, не нарушив их целостность или смысл) применяется в как в разработке кода ПО, так и в разработке кода автотестов.

И в автотестах Postman он особенно хорош! Давайте разберемся на примерах, почему лучше писать небольшие автотестики, «один тест, одна проверка», чем «много проверок в одном тесте».

Метаморфические и антагонистические стратегии тестирования ИИ-систем

barancev@gmail.com (Administrator) — Tue, 24 Mar 2026 20:00:00 +0000

Автор: Амрута Панде (Amruta Pande)
Оригинал статьи
Перевод: Ольга Алифанова

ИИ стремительно захватывает технологический мир, и крупные языковые модели (LLM) находятся в авангарде этого движения. Но при создании приложений с поддержкой ИИ качество всё так же остаётся ключевым фактором.

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

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

Cursor AI для ревью ручных тест-кейсов в TestOps

barancev@gmail.com (Administrator) — Sun, 22 Mar 2026 20:00:00 +0000

Автор: Олег Малышев, телеграмм-канал автора про QA,QA Auto, AI, Вайбкодинг

Всем привет! Я один из лидеров стека тестирования в компании «ТехВилл» (в простонародье — Head QA). Моя цель простая: снимать рутину с QA-инженеров с помощью AI-инструментов.

В идеальном мире мы «скармливаем» модели, требования, ссылки на Figma, ветки в Git и прочие артефакты через MCP, а она помогает:

1) писать тест-кейсы по контексту,

2) а затем — генерировать автотесты на базе этих кейсов.

Про генерацию тест-кейсов из Swagger и автотестов на API по тест-кейсам через Cursor (на реальном проекте) я уже записывал большой гайд про «вайбкодинг/вайбтестинг». В этом гайде я в том числе показал свой подход вайбкодинга через вспомогательные файлы типа roadmap.md, progress.md, refactor.md, context.md и т. д. В таком подходе мне удалось завайбкодить два своих микропродукта на JS, у одного из которых более 60 000 weekly users (при том, что я ни разу не программист и JS «не знаю совсем»).

Тестируй не дольше, а с умом: стратегия шифт-вниз

barancev@gmail.com (Administrator) — Mon, 16 Mar 2026 20:00:00 +0000

Автор: Маниш Саини (Manish Saini)
Оригинал статьи
Перевод: Ольга Алифанова

Введение в тестирование «shift-вниз»

Исследуя тестирование программного обеспечения, часто слышишь про два подхода: shift left (сдвиг тестирования на более ранние этапы разработки) и shift right (расширение тестирования до прода). Оба подхода полезны, как проверка дома во время строительства и после него. Однако существует ещё одно измерение, которое заслуживает внимания — сдвиг вниз, ближе к фундаменту кода.

Представьте, что вы строите дом. Разве вы начнёте украшать стены до того, как убедитесь, что фундамент прочен? Схожим образом в тестировании ПО (хоть мы зачастую сосредотачиваемся на проверке того, что видят конечные пользователи, на стенах и декоре) тщательное тестирование фундамента приносит огромную пользу. Здесь и приходит на помощь сдвиг тестирования вниз.

Плохой промпт vs хороший: как контекст меняет тесты ИИ

barancev@gmail.com (Administrator) — Sun, 15 Mar 2026 20:00:00 +0000

Автор: Екатерина Гаврилова

Всем привет! Меня зовут Катя и я QA Tech lead в MD Audit.

В прошлой статье я рассказала, какой подход помог мне сделать ИИ напарником по тестированию и поделилась формулой хорошего промпта для QA.

Но остаётся вполне логичный вопрос — А какая вообще разница? Ну попрошу я написать ИИ тесты без контекста. Что изменится в полученном результате?

Ведь где-то внутри всегда сидит ленивая версия нас и шепчет «И так сойдет».

В этой статье я покажу, почему, зная формулу «Роль → Задача → Контекст → Формат», нужно использовать именно её, как бы ни хотелось отправить ИИ что-то в духе: «Напиши тесты для логина, пожалуйста» и надеяться на лучшее.