Семь раз оттесть, один раз деплой
Привет! Ищу комьюнити тестировщиков. Готовлюсь к конференции и нужна ваша помощь) Исследую вопросы формального vs исследовательского тестирования. Не могли ли бы вы пройти короткий анонимный опрос на 5 минут. Помогите собрать стату и исполнить мечту :)
Про опрос: 13 вопросов на да/нет/наверно. Он опосредован и анонимен, даже я не вижу, кто его заполнял
Представлена бесплатная платформа Pagy, которая позволяет создавать лендинги и небольшие веб-проекты за секунды. Работает в браузере и собирает сайты или визитки без привлечения дизайнера, верстальщика. Не требует никакой установки ПО. Все просто: выбираете шаблон и сразу его редактируете, пишите текст, вставляете ссылки и пикчи. Ни одной строчки кода писать не нужно, хостинг не требуется. Есть аналитика метрик сайта и сотни уже готовых дизайнов от разрабов и коммьюнити.
Сравнение производительности React-компонентов: Gravity UI vs другие библиотеки
Я core‑разработчик Gravity UI, и периодически нам в команду поступают вопросы про производительность react‑компонентов из нашей библиотеки @gravity‑ui/uikit. Я решил сделать небольшое исследование этого вопроса, и всё написанное ниже является отправной точкой для дальнейших исследований и попыткой ответа на вопрос «Почему Gravity тормозит?»
Обычно этот запрос пишут без дополнительных деталей, поэтому я исхожу из предположения, что одна (но, конечно же, не единственная) из основных проблем производительности — долгое время отрисовки. В рамках этого исследования мы рассмотрели затраты на первый рендеринг отдельных компонент каждой из библиотек в изолированной среде. Для сравнения были выбраны библиотеки @adobe/react‑spectrum, @mui/material и antd.
Методология исследования
Технический стек:
Playwright — фреймворк для автоматизации тестирования кода в разных браузерах (подробнее).
PerformanceObserver API — браузерный API для измерения производительности (подробнее).
Условия выполнения тестов:
Каждый тест запускается в отдельном контексте браузера.
Единовременно выполняется только один тест (настройка workers в конфиге Playwright), что гарантирует выделение одинакового количества ресурсов на каждый тест.
Каждый тест повторяется 50 раз.
Тесты проводятся с разным количеством нод (10, 100, 1000).
Порядок выполнения одного теста:
Открытие новой страницы в браузере.
Инициализация PerformanceObserver.
Начало сбора метрик.
Рендеринг компонентов.
Завершение сбора метрик.
Процесс измерения:
В начале каждого теста создаётся PerformanceObserver, который отслеживает события типа 'measure'. Все собранные метрики сохраняются в глобальном объекте __PERFORMANCE_METRICS__. Observer автоматически собирает данные о времени выполнения операций, включая название метрики, тип события, время начала и продолжительность. С помощью события measure мы логируем наше измерение total‑render‑time.
Результаты
Результаты замеров не содержат в себе абсолютных цифр. От окружения к окружению они, конечно же, могут варьироваться. Но этих цифр вполне достаточно, чтобы увидеть некоторые зависимости и сделать на их основании выводы:
@gravity‑ui/uikit показывает конкурентоспособные результаты:
В большинстве тестов находится в верхней части рейтинга.
Демонстрирует стабильное время рендеринга при разном количестве нод.
Особенно эффективен в компонентах Button, Checkbox и Switch.
Имеет проблемы со временем рендера компонента TextArea.
@mui/material также показывает хорошие результаты:
Лидирует почти во всех категориях (например, Text, Label) на небольшом количестве нод.
Имеет видимый рост времени рендера в зависимости от количества нод.
antd и React Spectrum:
Показывают более высокое время рендеринга в большинстве тестов.
Имеют больший разброс между минимальным и максимальным временем.
С помощью этого инструмента можно провести замеры производительности на своей локальной машине, а также добавить тесты для компонентов, которых ещё нет. Нам поможет, если вы развернёте его у себя и пришлёте в PR результат работы на своём компьютере.
В этой статье я раскрыл один из примеров, как мы работаем с библиотекой. Но нам очень важна обратная связь от сообщества: если у вас есть конкретный пример, где Gravity UI показывает себя сильно хуже других библиотек, или если вы видите ошибку в нашей методологии тестирования, приходите в комментарии к этому посту или создавайте issue, обсудим. А также не забывайте ставить звёздочки проекту!
А зачем вообще проводить исследования? А вот интересно посмотреть на сферу глазами тех самых ребят, кто каждый день работу эту самую работает, узнать, где больше всего болит и где можно усилиться — то есть в будущем предложить решение, которого ещё нет или чего мало.
Так появилось исследование тестировщиков 👇
Ещё можно углубиться в лендинг: https://qa-survey-2025.2gis.ru. Посмотреть разные цифры: собирали данные скрупулезно по профильным каналам, 1000 QA-инженеров начали опрос, 570 стойко ответили на все 45 вопросов!
К слову, и про статистику сбора данных: 37% тестировщиков проходили опрос на Android, 29% на iPhone, 23% на Windows, 9% на MacOS и даже 2% c Linux.
Заглядывайте и пишите, за что взгляд зацепился, обсудим!
OpenAI начала тайно тестировать о3 Alpha на WebArena. Эниузиасты уже попробовали и заявили, что это лучшая тулза для программирования, которая на раз-два уничтожает конкурентов типа Cursor и предыдущую о3 Pro. Умеет генерить сайты и веб-приложения, клонирует игры типа Minecraft, Flappy Bird и даже GTA с первой попытки.
Бесплатные курсы Route 256 от Ozon Tech для QA-инженеров
Route 256 — это 2 месяца онлайн-вебинаров и воркшопов от команды экспертов Ozon Tech. Программа состоит преимущественно из практики на базе реальных задач бигтеха, что помогает студентам получить уверенный опыт в автотестировании на Python.
Этим летом Route 256 открывает набор в направлении QA Automation на Python для middle- и junior-специалистов. Занятия проходят вечером, поэтому курсы удобно сочетать и с учёбой, и с работой.
3 августа состоится отборочный контест для поступления на курс. Он будет включать алгоритмические задачи и тест. Ученики middle-направления по окончании курса могут получить оффер в команду, а junior-участники — приглашение на оплачиваемую стажировку.
Если вы хотите получить знания команды разработки ведущего e-com России, заявку стоит подать уже сейчас.
Регистрация для уровня middle
Регистрация для уровня junior
Представлен обновлённый проект Awesome Black Hat Tools, где собраны все инструменты, которые когда-либо были представлены на ИБ-конференциях Black Hat. Инструменты аккуратно структурированы по странам, где проходила конференция, по годам и категориям Red Teaming, Blue Teaming, OSINT & Recon, Exploit Development, Malware Analysis, DFIR & Forensics, Threat Intelligence, ICS/IoT/SCADA и Application Security (AppSec).
Также все презентации с выступлений Black Hat, начиная с 2023 года, собраны на отдельной странице GitHub.
Спустя 26 лет чуть не истёк срок действия домена half-life3.com. Домен был создан ещё в 1999 году и раньше перенаправлял на сайт The Orange Box. Однако 28 июня домен прекращал своё существование, из-за чего некоторые фанаты начали бить тревогу и даже связались со службой поддержки Valve, которая сообщила, что домен в безопасности — его продлили некоторое время назад.
В обсуждениях тестирования микросервисов часто всплывает статья Мартина Фаулера Testing Strategies in a Microservice Architecture. Опубликованная в 2014 году, она опирается на концепцию тестовой пирамиды, сформулированную ещё в 2009-м. С тех пор ландшафт тестирования заметно изменился — в первую очередь за счёт появления и широкого распространения Docker и Testcontainers, которые существенно повлияли на практики и экономику тестирования.
Эта трансформация хорошо отражена в более современных источниках:
Сам Мартин Фаулер также в более поздней статье On the Diverse And Fantastical Shapes of Testing отмечает, что трактовка "юнит-тестов" далеко не однозначна и зависит от контекста.
В контексте вашего проекта это означает, что использование интеграционных тестов в 2025 году оказывается существенно проще, дешевле и эффективнее, чем это предполагалось в рамках модели 2009 года.
Опубликована база по веб-разработке от Microsoft. В учебном курсе от компании представлено 24 урока, где разбирается всё от основ веба, работы браузеров, сетевых протоколов до HTML, CSS и JS. Всё обучение ориентировано на практику. После каждого раздела есть тесты и интерактивные кодинг-задачи. Также есть несколько пет-проектов, которые можно реализовать после обучения и положить себе в портфолио.
Обновил сайт знакомств для айтишников
Наконец-то!
Уже 13 лет бесплатно ищет половинки. И без рекламы.
Ушел с jquery и bootstrap - перешел на alpine и tailwindcss.
Поменял дизайн на более современный и удобный, как мне кажется.
Знакомства для айтишников - просто наберите в поисковике (он всегда первый), ссылку не буду давать.
Как было раньше можно посмотреть в архиве интернета, с 2012 года.
Задача о новой фиче, которую никто не видит
Задача будет полезна разработчикам веб-приложений и сервисов.
Текст подготовил Артём Шумейко — внештатный райтер, амбассадор Selectel и автор YouTube-канала о разработке.
Условие
В компании «ГигаПост» выпустили долгожданное обновление: на сайте появилась новая кнопка «Подписаться на тему». Интерфейс готов, API поддерживает, проверено на стенде — все работает как часы.
Но после релиза начались странности. Некоторые пользователи видят кнопку, а некоторые — нет. Кто-то говорит, что она появилась через сутки. Кто-то — что только после нажатия Ctrl+F5.
Команда фронтенда уверена — код задеплоен. Бэкенд-эндпоинт отвечает корректно. На тестовом стенде все видно. Даже сам разработчик открывает сайт на своем ноутбуке — кнопка есть.
Начали подозревать баг в логике отображения, потом — переключение языка, затем подумали про авторизацию. Но фича пропадает у пользователей даже с одинаковыми условиями.
И вот тогда кто-то предложил простую мысль: а пользователи вообще видят свежую версию сайта?
Задача
Почему часть пользователей не видит новую кнопку, хотя код задеплоили? В чем может быть причина? Где в цепочке доставки может остаться старая версия?
Предлагайте свое решение в комментариях. А правильный ответ можно подсмотреть в Академии Selectel.
Как не потерять важные проверки в долгих тестах: soft-assert на практике
В длительных системных тестах, особенно для систем хранения данных, важна не только проверка, но и устойчивость самого теста. Обычные assert в Python останавливают выполнение при первой ошибке, что неприемлемо для многокомпонентных и продолжительных тестов, где важно собрать максимум информации о сбоях.
Решение — использовать soft-assert, которые не прерывают выполнение. В команде мы используем Pytest плагин pytest-check, которая позволяет писать soft-assert через контекстный менеджер with check. Это дает возможность:
продолжить тест даже при частичных ошибках,
собрать диагностику по множеству компонентов (например, контроллеры, кэши, пулы),
минимизировать потери времени при дорогостоящих прогонах.
Пример soft-assert с pytest-check:
from pytest_check import check def object_stack(): pool_stack = ExitStack() yield pool_stack for host in hosts: with check: result = None try: PoolsService.get_pools_info(host) except HostUnavailableException as err: result = err assert not issubclass(type(result), HostUnavailableException), f'Failed to get pool: {result}'
Soft-assert полезен, когда нужно получить статус всех компонентов, несмотря на сбои отдельных, одна ошибка не делает тест недействительным и тест длится часами и его повтор — затратен.
Однако soft-assert не заменяет критические проверки — в местах, где сбой должен останавливать выполнение, следует использовать assert.
О том, как устроен процесс проверки надежности СХД TATLIN.UNIFIED, рассказала Наталья Грязнова, ведущий инженер по разработке ПО в YADRO. В тексте она делится подходами, которые позволяют комплексно проверять работу систем в разных условиях — от сверхнагрузок до нестабильной среды.
Как подход Docs-as-a-code применили в создании документации для TestY TMS
Команда разработки системы управления тестами TestY объединилась с командой технических писателей, чтобы создать удобную документацию.
Для ведения документации выбрали подход Docs-as-a-code. Документация хранится вместе с кодом приложения. Для написания и сборки использовали более-менее классическое сочетание: rST-формат в связке со Sphinx.
Инженеры уверены, что такой вариант предоставляет большую гибкость, чем стандартный MD. К тому же, rST в связке со Sphinx — стандарт документации для open source-проектов.
Разработчики поддерживают документацию в актуальном состоянии, поэтому рассчитывают, что в дальнейшем любое изменение текущей функциональности, как и разработка новой, будет сопровождаться обновлением документации. Это будет одним из Definition of Done для реализации фич.
Помимо документации в релизе 2.1 появилась темная тема и другие обновления интерфейса. Читайте о них в статье →
Как вы оформляете баги?
В каждой компании, где я работал, были свои правила формализации и постановки обнаруженных багов. Чаще всего - никаких правил. Что нашел тестировщик, то отписал в комментарии к задаче (и это еще хорошо!), а иногда просто на созвоне обсудил с разрабом, тот быстро пофиксил и факт найденного бага остался между ними. Для мелких студий так работать, может, и допустимо, но рано или поздно отсутствие элементарного порядка начинает надоедать. И тут появляются вопросы:
Как оформить баг? Комментарий к задаче? Отдельная задача? Чек-лист в описании задачи?
Как отметить баг выполненным? Проверенным? Повторно проявившимся?
Какая система багтрекинга вам показалась наиболее удобной? Jira? Youtrack? Яндекс.Трекер? Битрикс24? Что-то из новомодного импортозамещения?
Какие шаблоны описания бага приняты в вашей компании? Нет правил? Шаг 1 - шаг 2 - шаг 3 - ожидание - реальность? Скриншот со стрелочками? Видеозапись с экрана?
Есть ли какая-то классификация багов? Минор / мажор? Бэк / фронт? Бэклог / критикал?
Очень интересует ваш опыт в данной теме. Буду очень признателен, если поделитесь своими знаниями в комментариях.
Тестируете сайты вручную? Ваша девушка не хочет знакомить вас с родителями? Ваши друзья-курьеры и ваша морская свинка смотрят на вас свысока?
Специально для вас наш эксперт по end-to-end тестам Даниил Дунайчук записал гайд по старту в E2E атвотестах с помощью популярного фреймворка Playwright.
GitHub репозиторий с примерами из видео
Список литературы по Playwright и TypeScript
Теперь даже ваша морская свинка разберется 🐹❤️
Google выпустила свой бесплатный генератор сайтов и приложений Stitch:
генерит простые, но стильные дизайны;
под капотом мощнейшая модель Gemini;
экспорт в Figma буквально парой кликой
есть специальная фича Copy to Figma;
любой элемент можно отредактировать.
Тестирование документации: залог успешной разработки
Когда создаётся программное обеспечение, важно не только писать код, но и грамотно описывать, что этот код должен делать. Для этого существуют требования — это такая "карта", по которой разработчики и тестировщики понимают, что именно нужно создать. Если эта карта написана с ошибками или слишком запутанно, можно приехать совсем не туда, куда планировали.
Почему важно проверять документацию заранее?
Представьте, что вы собираетесь строить дом. У вас есть план, но если он неполный или в нём ошибки, вместо уютного дома может получиться что-то с одной стеной или без крыши. В программировании примерно так же: если требования, то есть документация, составлены плохо, программа может не работать или работать неправильно.
Проверка требований до начала разработки помогает находить проблемы раньше, чем они превратятся в баги. Чем раньше найдёшь ошибку, тем меньше потом придётся исправлять. Это называется "Shift-Left Testing", что по сути означает — тестировать раньше, чтобы потом не было больно.
Вот какие проблемы можно найти на этом этапе:
Противоречия в требованиях: например, в одном месте написано "сохранить данные", а в другом — "удалить данные". Так какой из них правильный?
Неоднозначные формулировки: когда написано так, что можно понять по-разному, и каждый разработчик это понимает по-своему.
Отсутствие важных условий: что-то важное просто забыли описать, и программа не знает, что с этим делать.
Ошибки в сценариях использования: не описаны крайние случаи, например, что делать, если пользователь ввёл неправильные данные.
Как можно тестировать требования?
Есть несколько способов проверить, что в документации нет ошибок:
Формальная проверка: использование строгих правил, чтобы убедиться, что всё написано правильно.
Чтение и обсуждение: собираемся, читаем вместе, обсуждаем и находим проблемы.
Моделирование: создаём простые схемы, чтобы понять, как всё должно работать.
Анализ текста с помощью ИИ: современные программы могут сами искать ошибки в тексте требований.
Что будет дальше?
Ниже можете видеть видео, где видно, как наш инструмент TestWriter проводит проверку документации с помощью ИИ. Это пока что прототип, но уже видно, как много ошибок можно найти ещё до начала разработки.
Полезные материалы по теме:
Тестирование требований — Teamlead Roadmap: Простое объяснение, зачем проверять требования перед началом разработки.
Критерии качества требований с примерами — Habr: Примеры, как сделать документацию понятной и понятной для всех.
Тестовая документация: что учитывать при постановке эффективного процесса тестирования — Habr: Как правильно описывать требования, чтобы не возникало путаницы.
Роль формализации требований в тестировании программного обеспечения — КиберЛенинка: Почему важно прописывать требования максимально чётко.
Тестирование требований — Особенности — Quality Lab: Как работают с требованиями на практике и какие ошибки бывают.
P.S.: а вот ссылка на мой блог в Telegram: https://t.me/it_vadimqa
Как начать практиковаться в тестировании без опыта
Если вы только что окончили курсы по тестированию, знаете теорию, но не имеете реальных кейсов — это нормально. Почти каждый начинающий QA-специалист сталкивается с вопросом: «Где набраться практики, если нет опыта?».
После тренировок в песочницах следующий шаг — попробовать себя в реальном проекте. Участие в open source — отличный способ получить настоящий опыт, поработать с командой и добавить первые кейсы в портфолио. Начать тестировать WordPress можно по простому и понятному алгоритму. Шаги для старта:
Установите WordPress локально.
Самый простой способ — приложение LocalWP. Также подойдут Docker или XAMPP.
Разберитесь, как устроена работа.
Загляните на make.wordpress.org — там есть разделы для разработчиков, дизайнеров, переводчиков и тестировщиков. Обратите внимание на Test Handbook — там подробно объясняется, как тестировать, искать баги и писать отчеты.
Найдите первую задачу.
В баг-трекере Trac ищите задачи с меткой good-first-bug — они идеально подходят для старта. Прочитайте описание, повторите шаги и проверьте, воспроизводится ли баг.
Включайтесь в сообщество.
Присоединяйтесь к чату #core-test в Slack (ссылка на подключение — в make.wordpress.org/test). Там обсуждают приоритетные задачи и проводят регулярные митинги. Новичкам всегда рады!
В статье, Юлия Ковшова, руководитель группы компонентного тестирования в YADRO, делится опытом, где найти первые реальные задачи без трудоустройства. Если вы только начинаете карьеру в тестировании и застряли на этапе теории, это руководство поможет сделать уверенный шаг к практике.
Как тестировать фронтенд?
Для меня уже нет вопроса - нужны ли тесты на фронтенде? Личный опыт подсказал, что нужны, как и согласованный цельный подход к архитектуре. Тому есть несколько причин:
Без unit-тестов и автоматических e2e-тестов ручное тестирование занимает много времени. К тому же человек, скорее всего, при регрессионном тестировании что-то пропустит, и баги попадут в production. Особенно это актуально для больших проектов с большой кодовой базой.
Без автоматических тестов страшно рефакторить код. А если нет выстроенной архитектуры с соблюдением low coupling/high cohesion, то этот страх вполне оправдан. А без регулярного пересмотра кода приложение рано или поздно превратится в большой комок грязи.
У unit-тестов есть интересный побочный эффект. Если пользоваться подходом TDD и писать тесты сразу вместе с кодом (и даже перед написанием кода), то качество модулей и архитектуры в целом повышается. Это происходит, потому что с позиции написания теста мы думаем не только о том, как нам побыстрее завершить работу над модулем, но и о том, как этот модуль будет выглядеть снаружи, удобно ли будет его использовать внутри других модулей, так как тест в этом случае служит ещё и образцом вызывающего модуля.
Тесты - это дополнительная документация к коду. Причём такую документацию не получится держать в неактуальном состоянии, иначе упавшие тесты не пропустят код в production при наличии настроенного шлюза проверки качества в CI/CD пайплайне.
Это всё прекрасно и, как показывает практика, работает, как ожидается, но остаются вопросы.
Как тестировать уровень представления приложения? Например, в случае с каким-нибудь фреймворком с использованием React это будут React-компоненты, виджеты, представляющие отдельные элементы пользовательского интерфейса. Тестировать там, по сути, нужно функцию. Передали ряд аргументов (пропсов или состояний) - получили одно представление. Передали другие аргументы - другое. Зависимость результата от набора аргументов - однозначная. Чтобы это проверить, можно использовать тесты со скриншотами. Я предпочитаю snapshot-тесты, они дают больше контроля, но работают довольно медленно и могут быть хрупкими, если недостаточно грамотно отделять слой представления от логики.
А что со временем написания кода вместе с тестами? Будем ли мы вовремя успевать сдавать новые модули и радовать наших пользователей и руководство? Я думаю, что это не совсем правильные вопросы. Спрашивать надо о том, сколько будут стоить ошибки, попавшие на production из-за отсутствия тестов? Если ваше приложение - landing page с минимумом логики, то вряд ли цена ошибки будет высока. В небольшой кодовой базе её будет легко локализовать и исправить. А если вы работаете с финансами и у вас миллионы пользователей? В этом случае цена ошибки на production будет намного выше.
Как донести необходимость тестов до команды и правильно включить автоматизацию тестирования в процесс разработки? Это на самом деле серьёзный вопрос. Не все разработчики понимают, зачем вообще тесты на фронтенде и обоснование их необходимости может вылиться в не слишком продуктивный холивар. А если продавливать такое решение сверху, то без понимания и принятия командой этого решения будут попытки обойти систему и снижение мотивации. Мне когда-то в подобной ситуации помогла практика парного программирования и выстраивание инженерной культуры в команде (совместное чтение технической литературы, архитектурные встречи с использованием white board).
А какие практики для тестирования применяете вы?