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).
А какие практики для тестирования применяете вы?
Тестировщики, общий сбор!
Мы часто видим исследования про разработчиков, продактов, аналитиков… А про QA? Почти ничего. Пора это исправить.
Мы запускаем исследование сообщества QA, чтобы разобраться:
что нас радует и раздражает,
какие инструменты и практики мы выбираем,
как меняется наша роль и работа.
Присоединяйтесь! Это важно и интересно 🔥
Пройти опрос → https://qa-25.testograf.ru
В анкете 45 вопросов, потребуется 15–20 минут времени. А среди всех участников разыграем оригинальный подарок. Доходи до конца и всё поймёшь:)
Друзья, ночи доброй.
Если позволите, вкратце о себе. Зовут меня Саней. Имею опыт в тестирование более 3-х лет. В послужном списке тестирования были desktop-приложения для операторов БПЛА, системы защиты информации, система кредитования физических лиц и многое другое.
В настоящий момент работаю в компании QA-специалистом и одновременно являюсь ментором для людей, решивших стать тестировщиками.
Имеется богатый опыт теории и практики в тестировании, а также есть желание поделиться с ним.
Пишу пост на Хабре впервые и хочу узнать, "стоит ли игра свеч" и будет ли кому-то это интересно. Буду раз в неделю выкладывать статью о профессии QA, делаю упор на практику, которая вам в последующем пригодится на работе. И не будем забывать о теории, чтобы успешно пройти интервью)))
Всем огромное спасибо!
Представлен проект Scroll Buddy — анимация на полосе прокрутки.
«Вместо скучной полосы прокрутки я подумал, что было бы забавно иметь анимированную фигурку, которая ходит вверх и вниз по краю страницы, когда вы прокручиваете. Это первый прототип, который я сделал. Собираюсь сделать скейтбордиста, скалолаза или белку следующим», — пояснил авто проекта.
Разница между масштабирование и зумом в CSS. Зум работает так же, как и масштабное преобразование, но в отличие от масштабирования, он влияет на макет страницы. Другими словами, макет страницы пересчитывается с учётом нового размера масштабируемого элемента.
