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

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

Так появилось исследование тестировщиков 👇

Ещё можно углубиться в лендинг: https://qa-survey-2025.2gis.ru. Посмотреть разные цифры: собирали данные скрупулезно по профильным каналам, 1000 QA-инженеров начали опрос, 570 стойко ответили на все 45 вопросов!

К слову, и про статистику сбора данных: 37% тестировщиков проходили опрос на Android, 29% на iPhone, 23% на Windows, 9% на MacOS и даже 2% c Linux.

Заглядывайте и пишите, за что взгляд зацепился, обсудим!

Ozon Tech открыл сразу несколько вакансий для QA mobile

Если хотите тестировать продукт, которым пользуются миллионы, — этот пост для вас. 

У нас несколько сильных команд, и вы можете выбрать ту, где ваш опыт даст максимум результата:

1. Приложение Курьер и Работа

Будете тестировать сразу два приложения:

• Ozon Курьер Express помогает курьерам и водителям принимать экспресс-заказы и зарабатывать.

• Ozon Job — приложение для соискателей, где можно найти склад, записаться на смену, посмотреть выплаты и тарифы.

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

2. Приложение Ozon

То самое, которым пользуетесь вы, ваши друзья и соседи. Через него проходит >90% заказов. Вы будете тестировать UI, логику, аналитику и пуши, следить за стабильностью релизов и качеством пользовательских сценариев. У нас отлаженная инфраструктура: автоматизация, фермы с эмуляторами, симуляторами и реальными девайсами.

3. Мобильная платформа

Фундамент всех приложений Ozon: библиотеки авторизации, аналитики, performance-метрики.  Вы будете проверять их стабильность, писать автотесты и автоматизировать процессы. Команды Ozon используют эти библиотеки каждый день — и от их качества зависит работа всей мобильной разработки.

Что общего во всех командах:

— Кроссплатформенная автоматизация на Python и Appium. 

— Сложные, нетривиальные задачи — как в ручном тестировании, так и в автоматизации. 

— Фичи, которые вы тестируете, видят миллионы пользователей — включая ваших друзей и родных. 

Выбирайте продукт и откликайтесь на сайте. 

🔗 Другие вакансии в Ozon Tech

Использование случайностей в функциональном тестировании

Для кого эта статья?

• Инженеры по автоматизации и разработчики тестов — вам точно будет интересно.

• Обычные разработчики, если вы заинтересованы в качестве продукта, а не считаете тесты "расплатой за грехи" или "прихотью менеджмента" — тоже.

А кого, возможно, не заинтересует

Если у вас постоянно есть падающие тесты, и никто не разбирается в причинах, а просто смотрят на процент "зелёных" и "красных", — эта статья может показаться бесполезной.

Откуда вообще эта идея?

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

На первый взгляд — всё логично. Но на практике:

• увеличивается время прогона (особенно для UI-тестов);

• растёт вероятность нестабильности (flaky-тесты);

• тесты зачастую дублируют поведение друг друга.

Наглядный пример

Допустим, у нас есть UI-тест, проверяющий переходы по меню на сайте. Стартовая страница содержит меню для перехода на страницы A, B, C, D.

Сценарий теста:

1. Открываем стартовую страницу.

2. Выбираем пункт в меню.

3. Проверяем, что оказались на нужной странице.

Что делает большинство:

• Пишут четыре теста: переход на A, на B, на C и на D.

• Или параметризуют тест: гоняют один и тот же сценарий с разными входными.

Но по сути, мы проверяем одну и ту же функциональность перехода по меню. Зачем гонять одни и те же шаги с разными данными?

Проблема

Если тест проверяет функциональность, то логично оставить один вариант— переход на страницу A. Экономите ресурсы, всё стабильно и функциональность проверяется. Но однажды приходит тимлид с вопросом:

Почему тесты не поймали баг с переходом на страницу D?

В этом случае экономия не оправдалась

Что делать?

Тест — это тоже код. Он может быть не стабильным. И чем чаще он запускается, тем быстрее мы понимаем, стабилен он или нет.

А теперь возвращаемся к примеру с меню:

Что, если каждый раз случайным образом выбирать один из пунктов (A, B, C, D)?

• Экономим ресурсы: запускается один тест вместо четырёх.

• С течением времени мы случайным образом "покроем" все пункты.

• Чем чаще прогоняются тесты, тем быстрее мы обнаружим баг (например, если страница C не открывается).

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

Это не ноу-хау

Такой подход давно известен — он называется property-based testing.

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

Что важно помнить

• Использование случайности не должно усложнять тест. Логика должна быть понятна и читаема.

• Если тест упал, он должен сообщить, что именно пошло не так, даже если данные были сгенерированы случайно.

• Рандомизация — всего лишь один из способов сделать тесты более эффективными, но это не универсальное решение

• Иногда стоит логировать/фиксировать сгенерированные данные, особенно при падении теста — чтобы потом воспроизвести баг

Итог

Рандомизация в тестировании — мощный инструмент:

• помогает экономить ресурсы;

• расширяет покрытие;

• стимулирует стабильность и надёжность тестов.

Но применять её стоит с умом: понимать, зачем, где, и в каком объёме.

А как у вас это устроено? Используете ли вы property-based подход в тестах? Или всё ещё параметризуете всё подряд? Буду рад услышать ваши мнения, кейсы и даже критику.

One Day Offer для разработчиков, аналитиков, тестировщиков 1С от Ozon Tech

Сразу 9 команд в поиске специалистов, которые уже проектировали и внедряли 1С-решения в крупных IT-компаниях. Получить оффер в Ozon Tech можно всего в 3 шага.
1С в Ozon — не просто ещё одна платформа. Это система учёта ведущего e-com России с охватом в 10 стран. В ней всё — от тарифов для селлеров из Еревана до графика работы ПВЗ в Караганде. 

Кто нам нужен? 
Опытные специалисты с глубокой экспертизой — разработчики, тестировщики, аналитики.
Вакансии открыты в 9 команд, и во всех — нешаблонные задачи на пределе возможностей 1С.
Подать заявку до 15 июля. 

Как всё пройдёт?
Онлайн и по расписанию. Даты интервью можно изменить по договорённости.
17.07 — знакомство с командами в формате презентации и Q&A — до 30 минут.
18.07 — техническое интервью, основанное на реальных задачах — 60-90 минут.
19.07 — финальное интервью с тимлидом — до 60 минут.

Почему стоит участвовать?
Во-первых, потому что мы — Ozon Tech, наши проекты вдохновляющие и перспективные, а условия — на высшем уровне бигтеха.

Во-вторых, в таком формате вы получаете максимум результата при минимальных затратах, как временных, так и эмоциональных: мы сократили 1 этап интервью и с оффером вернемся в день проведения финального интервью. 

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

Присылайте его сюда, как закончите: https://s.ozon.ru/WfnJy67

Два «крита» в Windows: как эксперты Positive Technologies спасли мир миллионы устройств

Лето 2025 года началось с неприятного сюрприза для пользователей Windows — Microsoft экстренно выпустила патчи для двух опасных уязвимостей, найденных исследователями из Positive Technologies. Обе баги могли привести к серьезным последствиям: от краха системы до полного захвата контроля над компьютером. 

VHD-файл как билет в админ-клуб 

💥 Недостаток безопасности CVE-2025-49689 получил оценку 7,8 балла по шкале CVSS 3.1. 

Сергей Тарасов, руководитель группы анализа уязвимостей в экспертном центре безопасности Positive Technologies (PT Expert Security Center, PT ESC) Positive Technologies обнаружил, что злоумышленник может получить полный контроль над вашим компьютером, если вы откроете специально подготовленный виртуальный диск (VHD). 

📌 Как это работает? Вам присылают «безобидный» VHD-файл (например, якобы архив с документами). Вы его открываете — и вуаля, злоумышленник уже админ в вашей системе.

📌 Где прячется угроза? В драйвере файловой системы NTFS. Затронуты Windows 10, 11 и серверные версии.

Статистика страха: Таких уязвимых устройств в сети — 1,5+ миллиона, больше всего в США и Китае. 

У Сергея есть подробная статья на эту тему в блоге команды PT SWARM.

📌 Что делать? 

• Срочно обновиться. 

• Не открывать VHD-файлы от неизвестных отправителей. 

Один клик — и система падает

💥 Уязвимость CVE-2025-49686 получила 7,8 балла по шкале CVSS 3.1 и затронула 17 операционных систем

Марат Гаянов (эксперт из PT ESC) нашел другую проблему: если запустить вредоносную программу, можно положить всю систему. 

📌 Суть бага: Ошибка в сетевом драйвере приводит к краху Windows. 

📌 Чем опасно? Представьте: сотрудник открывает «документ», и вся корпоративная сеть ложится. 

 ⚠️ Особо опасен для компаний — атака не требует прав админа. 

📌 Что делать? 

• Опять же — обновить Windows. 

• Использовать средства защиты для управления уязвимостями и EDR-решения для обнаружения атак. 

Positive Technologies vs Microsoft: из истории борьбы с багами 

Это не первый случай, когда российские эксперты помогают Microsoft закрывать дыры: 

• 2019 — обнаружили две критические уязвимости, дающие доступ к данным (CVE-2019-0726 и CVE-2019-0697). 

• 2024 — нашли баг, позволяющий стать админом (CVE-2024-43629).  

Вывод

Если вы еще не обновили Windows — сделайте это прямо сейчас. А если ваш IT-отдел говорит «и так сойдет», покажите им эту статью. 😉 

P.S. Интересно, сколько еще таких багов плавает в Windows?..

Бесплатные курсы 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

Присоединяйтесь к публичной программе Bug Bounty Альфа-Банка на платформе BI.ZONE

Теперь у багхантеров есть возможность протестировать сервисы Альфа-Банка на предмет уязвимостей и получить вознаграждение. Размер вознаграждения зависит от критичности найденной уязвимости.

Максимальная сумма вознаграждения составляет 400 тысяч рублей.

Альфа-Банк выплачивает вознаграждение за выявление разных уязвимостей, таких как:

• удалённое выполнение кода (Remote Code Execution, RCE),

• проблемы контроля доступа (Broken Access Control, IDOR, Broken Session Management), 

• ошибки аутентификации и авторизации (Missing Authorization, Improper Authorization), 

• захват учётной записи (Account Takeover), 

• раскрытие конфиденциальной информации (Sensitive Data Exposure) и многих других.

Для исследования доступны веб- и мобильные приложения сервисов Альфа-Онлайн, Альфа-Инвестиции, Альфа-Бизнес и другие ресурсы.

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

Ресурс Counterpoint Research раскрыл, как Apple тестирует свои гаджеты в различных условиях, включая климатические тесты, водные тесты, краш‑тесты и вибрационные тесты.

Климатические тесты проводятся, чтобы устройства выдерживали разные погодные условия. В лаборатории Apple их подвергают воздействию соли в течение 100 часов, яркого света, а также пыли из пустыни Аризоны, чтобы проверить, как песок влияет на динамики или порты зарядки. Для AirPods даже создают искусственный пот и ушную серу, чтобы смоделировать реальные условия.

Водные испытания Apple проводит для проверки защиту от воды и пыли по стандартам IP. Например, iPhone 16 Pro имеет рейтинг IP68 — это высший уровень защиты, который означает полную устойчивость к пыли и способность работать после погружения в воду на глубину до 6 метров в течение часа.Тесты начинаются с простого сымитированного «дождя», затем устройства обливают водой под давлением и погружают в воду в специальных резервуарах. Apple также тестирует устройства на устойчивость к другим жидкостям, например, газировке, сокам, солнцезащитному крему и духам.

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

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

Представлен обновлённый проект 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.

Как не потерять важные проверки в долгих тестах: 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 появилась темная тема и другие обновления интерфейса. Читайте о них в статье →

🤖 Кибербезопасность и ИИ: почему нельзя сливать данные за контур банка

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

🛑 Главная угроза — утечка данных

Когда разработчики или тестировщики используют облачные AI-сервисы, часто без одобрения ИБ, они могут неосознанно отправить чувствительные данные за контур банка. Даже если это фрагмент кода с маской клиента или лог, содержащий номер счёта — это уже нарушение политики информационной безопасности.

📌 Реальные инциденты

• Samsung, 2023 — сотрудники случайно слили внутренний код и конфиденциальные данные через ChatGPT, используя его для дебага. Позже компания запретила использование ИИ-сервисов.
  🔗 Сотрудники Samsung раскрывали конфиденциальные данные, общаясь с ChatGPT

• Американский банк JPMorgan ещё в 2023 году ограничил доступ сотрудников к ChatGPT, чтобы не допустить утечки данных.
  🔗 Bank of America, Citigroup, Deutsche Bank, Goldman Sachs Group, Wells Fargo и JPMorgan Chase запретили в работе ChatGPT

• В России — в 2024 году Ростелеком опубликовал отчёт, где указал, что более 30% утечек в ИБ инцидентах связаны с несанкционированным использованием облачных AI-сервисов.
  🔗 «Ростелеком»: утечка данных была в инфраструктуре подрядчика, пользователям рекомендуется сбросить пароли и включить 2FA

🔍 Что делать в банке

• Использовать внутренние или локальные решения ИИ, работающие в изолированной среде.

• Обучать команды тестирования и разработки по теме: "какие данные можно и нельзя передавать ИИ".

• Применять анонимизацию данных при генерации тестов.

• Развивать политику «zero trust» при работе с внешними API и сервисами.

💡 Дополнительные материалы

• 🔗 Статья «ИИ и безопасность» — Хабр

• 🔗 «Риски ИИ и кибербезопасности» от Malwarebytes
  Обзор угроз, связанных с использованием ИИ в кибербезопасности, включая атаки и методы защиты.

• 🔗 «Как ИИ меняет мир кибербезопасности – защита или угроза?»
  Анализ плюсов и минусов использования ИИ в кибербезопасности, включая перспективы развития.

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

📌 Подписывайтесь на мой Telegram-канал про тестирование, AI и IT в целом! — там делюсь мыслями, новостями и практическими примерами из жизни!

Приглашаем на QA Meetup 28 мая! Спикеры от Garage Eight, МТС, Островок.

Если ты тестировщик, QA-инженер или просто неравнодушен к качеству продуктов — приходи в гости в петербургский офис международной продуктовой IT-компании Garage Eight 28 мая в 19:00.

В программе три выступления от крутых спикеров:
> Алина Матлахова, QA Guild Lead, Островок – Zero Bug Policy: работа с багами и их превентированием.
> Лена Федорова, QA, Garage Eight – Мир, дружба, тестирование: как QA и Dev могут работать вместе на высшем уровне.
> Андрей Ганин, Chief Quality Officer, МТС – Что убивает качество?

А ещё будет:
— QA-викторина с призами;
— Пицца, напитки и живое общение;
— Экскурсия по нашему красивому офису (если ты у нас ещё не был — самое время заглянуть!);
— Немного развлечений — плойка, кикер, кайфовая атмосфера.

Где: Санкт-Петербург, офис Garage Eight (Новгородская улица, 17)

Участие бесплатное, но количество мест ограничено. Обязательно зарегистрируйся по этой ссылке.

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

И подписывайся на нас в telegram, чтобы не пропускать будущие митапы!

Тяжела и неказиста жизнь простого программиста статических анализаторов кода

Команда PVS-Studio, содействуя разработке методики испытаний статических анализаторов под руководством ФСТЭК, составляла некоторые синтетические тесты. Писать синтетические тесты сложнее, чем кажется, и с их достоверностью всегда масса нюансов. Я никогда не любил синтетические тесты и продолжаю их не любить. Но что делать, они тоже нужны, когда речь заходит о необходимости подтвердить, что в анализаторах реализован определённый набор технологий.

Даже зная и понимая нюансы составления синтетических тестов, мы всё равно наступили на собственные грабли! Переиграли сами себя :)

Есть составленные нами тесты, в которых в функцию srand или её аналог передаётся константное значение. Это приводит к тому, что функция rand каждый раз будет генерировать одинаковую последовательность псевдослучайных чисел. Такой код, согласно ГОСТ Р 71207-2024, п. 6.3.г, может являться ошибкой некорректного использования системных процедур и интерфейсов, связанных с обеспечением информационной безопасности (шифрования, разграничения доступа и пр.).

Когда тесты подготавливались в Compiler Explorer, всё работало: PVS-Studio выдавал предупреждение V1057. А сейчас, когда код мило и скромно лежит в файлах, не работает. На Compiler Explorer работает, а вне — нет. Магия. Уже собрались баг в анализаторе искать.

Ах нет, всё просто. Файлы с тестами называются test_err_*.cpp. И в детекторе срабатывает исключение N4: "Находимся в файле, содержащем в названии слова check/test/bench". Тьфу. Причём получается, что анализатор прав: это действительно тест, а не настоящий баг :) Вот оно, несовпадение реальности и синтетических проверок в действии. Выкрутимся как-нибудь, но решил описать, так как случай интересный.

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

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

Был рад поведать немного интересного из жизни разработчиков статических анализаторов кода. А если хочется послушать что-то ещё, приглашаю на подкаст "Статический анализ по серьёзному" с моим участием 27 мая в 19:00 по Москве.

Тестирование документации: залог успешной разработки

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

Почему важно проверять документацию заранее?

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

Проверка требований до начала разработки помогает находить проблемы раньше, чем они превратятся в баги. Чем раньше найдёшь ошибку, тем меньше потом придётся исправлять. Это называется "Shift-Left Testing", что по сути означает — тестировать раньше, чтобы потом не было больно.

Вот какие проблемы можно найти на этом этапе:

• Противоречия в требованиях: например, в одном месте написано "сохранить данные", а в другом — "удалить данные". Так какой из них правильный?

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

• Отсутствие важных условий: что-то важное просто забыли описать, и программа не знает, что с этим делать.

• Ошибки в сценариях использования: не описаны крайние случаи, например, что делать, если пользователь ввёл неправильные данные.

Как можно тестировать требования?

Есть несколько способов проверить, что в документации нет ошибок:

• Формальная проверка: использование строгих правил, чтобы убедиться, что всё написано правильно.

• Чтение и обсуждение: собираемся, читаем вместе, обсуждаем и находим проблемы.

• Моделирование: создаём простые схемы, чтобы понять, как всё должно работать.

• Анализ текста с помощью ИИ: современные программы могут сами искать ошибки в тексте требований.

Что будет дальше?

Ниже можете видеть видео, где видно, как наш инструмент TestWriter проводит проверку документации с помощью ИИ. Это пока что прототип, но уже видно, как много ошибок можно найти ещё до начала разработки.

Полезные материалы по теме:

• Тестирование требований — Teamlead Roadmap: Простое объяснение, зачем проверять требования перед началом разработки.

• Критерии качества требований с примерами — Habr: Примеры, как сделать документацию понятной и понятной для всех.

• Тестовая документация: что учитывать при постановке эффективного процесса тестирования — Habr: Как правильно описывать требования, чтобы не возникало путаницы.

• Роль формализации требований в тестировании программного обеспечения — КиберЛенинка: Почему важно прописывать требования максимально чётко.

• Тестирование требований — Особенности — Quality Lab: Как работают с требованиями на практике и какие ошибки бывают.

P.S.: а вот ссылка на мой блог в Telegram: https://t.me/it_vadimqa

Как начать практиковаться в тестировании без опыта

Если вы только что окончили курсы по тестированию, знаете теорию, но не имеете реальных кейсов — это нормально. Почти каждый начинающий QA-специалист сталкивается с вопросом: «Где набраться практики, если нет опыта?».

После тренировок в песочницах следующий шаг — попробовать себя в реальном проекте. Участие в open source — отличный способ получить настоящий опыт, поработать с командой и добавить первые кейсы в портфолио. Начать тестировать WordPress можно по простому и понятному алгоритму. Шаги для старта:

1. Установите WordPress локально.
   Самый простой способ — приложение LocalWP. Также подойдут Docker или XAMPP.

2. Разберитесь, как устроена работа.
   Загляните на make.wordpress.org — там есть разделы для разработчиков, дизайнеров, переводчиков и тестировщиков. Обратите внимание на Test Handbook — там подробно объясняется, как тестировать, искать баги и писать отчеты.

3. Найдите первую задачу.
   В баг-трекере Trac ищите задачи с меткой good-first-bug — они идеально подходят для старта. Прочитайте описание, повторите шаги и проверьте, воспроизводится ли баг.

4. Включайтесь в сообщество.
   Присоединяйтесь к чату #core-test в Slack (ссылка на подключение — в make.wordpress.org/test). Там обсуждают приоритетные задачи и проводят регулярные митинги. Новичкам всегда рады!

   

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

Как тестируют функцию Circuit Switched Fallback, которая помогает общаться с родственниками

Представим, что вы звоните семье со смартфона в 4G-сети. В вашей сети нет (или временно недоступна) поддержка голосового звонка через сеть 4G. Не имеет значения, в какой сети находится второе устройство.

Что происходит в сети оператора при таком звонке:

• Телефон отправляет на базовую станцию (eNB) вызов.

• Базовая станция связывается с ядром сети (MME) и запрашивает процедуру CSFB для исходящего звонка, дожидается от ядра сети подтверждения о возможности такого перехода.

• После этого отправляет телефону информацию о новом подключении к 2G-сети, которое он должен установить.

• После этого базовая станция завершает обслуживание абонента в 4G-сети, обслуживание переходит к станции 2G.

• Голосовой вызов осуществляется через 2G-сеть.

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

Симулятор позволяет автоматизировать этот этап тестирования и увеличить скорость тестов и повторяемость результатов. CSFB — это базовая функциональность, поэтому проверка проходит регулярно.

Для успешной проверки CSFB задачу декомпозируют, разделяют на уровни. О двух других ступенях «пирамиды» — тестировании в GSM-сети и системном тестировании — рассказала инженер YADRO Анастасия Беднова в своей статье.

Оплачиваемая стажировка Cloud.ru Camp — успей подать заявку до 12 мая 📢

Присоединяйся к Cloud.ru Camp — оплачиваемой стажерской программе, которая поможет студентам и начинающим специалистам прокачать скиллы и с головой погрузиться в IT-сферу. 

Ты можешь выбрать направления:

• Продуктовая разработка: DevOps или Golang.

• Кибербезопасность: мониторинг событий и автоматизация или сертификация программных продуктов.

• Команда внедрения: QA.

• Технические продажи: технический менеджер клиентов.

Что тебя ждет:

• оплачиваемая стажировка,

• работа в реальных проектах,

• поддержка наставников и экспертов,

• регулярная обратная связь.

А у лучших стажеров будет возможность попасть в штат Cloud․ru.

Прием заявок открыт до 16 мая включительно, а для прошедших все этапы отбора стажировка начнется 16 июня. Пройти стажировку можно очно в офисе Cloud.ru в Москве, а также удаленно из любой точки РФ. График гибкий — от 20 часов в неделю.

📬 Подать заявку на Cloud.ru Camp

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

Как тестировать фронтенд?

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

• Без unit-тестов и автоматических e2e-тестов ручное тестирование занимает много времени. К тому же человек, скорее всего, при регрессионном тестировании что-то пропустит, и баги попадут в production. Особенно это актуально для больших проектов с большой кодовой базой.

• Без автоматических тестов страшно рефакторить код. А если нет выстроенной архитектуры с соблюдением low coupling/high cohesion, то этот страх вполне оправдан. А без регулярного пересмотра кода приложение рано или поздно превратится в большой комок грязи.

• У unit-тестов есть интересный побочный эффект. Если пользоваться подходом TDD и писать тесты сразу вместе с кодом (и даже перед написанием кода), то качество модулей и архитектуры в целом повышается. Это происходит, потому что с позиции написания теста мы думаем не только о том, как нам побыстрее завершить работу над модулем, но и о том, как этот модуль будет выглядеть снаружи, удобно ли будет его использовать внутри других модулей, так как тест в этом случае служит ещё и образцом вызывающего модуля.

• Тесты - это дополнительная документация к коду. Причём такую документацию не получится держать в неактуальном состоянии, иначе упавшие тесты не пропустят код в production при наличии настроенного шлюза проверки качества в CI/CD пайплайне.

Это всё прекрасно и, как показывает практика, работает, как ожидается, но остаются вопросы.

• Как тестировать уровень представления приложения? Например, в случае с каким-нибудь фреймворком с использованием React это будут React-компоненты, виджеты, представляющие отдельные элементы пользовательского интерфейса. Тестировать там, по сути, нужно функцию. Передали ряд аргументов (пропсов или состояний) - получили одно представление. Передали другие аргументы - другое. Зависимость результата от набора аргументов - однозначная. Чтобы это проверить, можно использовать тесты со скриншотами. Я предпочитаю snapshot-тесты, они дают больше контроля, но работают довольно медленно и могут быть хрупкими, если недостаточно грамотно отделять слой представления от логики.

• А что со временем написания кода вместе с тестами? Будем ли мы вовремя успевать сдавать новые модули и радовать наших пользователей и руководство? Я думаю, что это не совсем правильные вопросы. Спрашивать надо о том, сколько будут стоить ошибки, попавшие на production из-за отсутствия тестов? Если ваше приложение - landing page с минимумом логики, то вряд ли цена ошибки будет высока. В небольшой кодовой базе её будет легко локализовать и исправить. А если вы работаете с финансами и у вас миллионы пользователей? В этом случае цена ошибки на production будет намного выше.

• Как донести необходимость тестов до команды и правильно включить автоматизацию тестирования в процесс разработки? Это на самом деле серьёзный вопрос. Не все разработчики понимают, зачем вообще тесты на фронтенде и обоснование их необходимости может вылиться в не слишком продуктивный холивар. А если продавливать такое решение сверху, то без понимания и принятия командой этого решения будут попытки обойти систему и снижение мотивации. Мне когда-то в подобной ситуации помогла практика парного программирования и выстраивание инженерной культуры в команде (совместное чтение технической литературы, архитектурные встречи с использованием white board).

А какие практики для тестирования применяете вы?

Проверяй, пока не поздно: функциональная верификация в жизненном цикле СнК

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

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

Время, необходимое для прохождения жизненного цикла СнК, зависит от команды и применяемых технологий. В индустрии считается, что эффективная работа означает выпуск нового тейп-аута (tape-out) раз в полгода. Это говорит о том, что процессы налажены и команда работает с высокой скоростью.

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

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