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

Ресурс 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, рассказал, как устроена работа инженера-верификатора, какие задачи решает команда на этапе проектирования и почему верификация — это отличный вход в профессию для тех, кто интересуется «железом» и кодом. 

Тестировщики, общий сбор!

Мы часто видим исследования про разработчиков, продактов, аналитиков… А про QA? Почти ничего. Пора это исправить.   

Мы запускаем исследование сообщества QA, чтобы разобраться:

• что нас радует и раздражает,

• какие инструменты и практики мы выбираем,

• как меняется наша роль и работа.   

Присоединяйтесь! Это важно и интересно 🔥

Пройти опрос → https://qa-25.testograf.ru

В анкете 45 вопросов, потребуется 15–20 минут времени. А среди всех участников разыграем оригинальный подарок. Доходи до конца и всё поймёшь:)

Тест на тестировщика: что в коробке?

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

Если вы знакомы с этим оборудованием или хотите с ним познакомиться, вас могут заинтересовать несколько вакансий в команде Телекома в YADRO. 

→ Некоторые из них требуют образования по специальностям Радиотехнологии или Телекоммуникации и опыта работы с системами GSM/LTE. 

Test Engineer (LTE/GSM Radio Subsystem)

Команда занимается тестированием функционала базовой станции LTE/GSM на системном уровне в лаборатории или на площадке заказчика. Специалисту нужно будет разрабатывать тестовые сценарии и готовить требования к тестам радиоподсистемы LTE/GSM. Здесь у кандидата должно быть высшее образование в области телекоммуникаций или радиотехнологий, а также знание стандартов GSM//LTE, топологии и интерфейсов мобильной сети.

Field Test Engineer (LTE/GSM) 

Команда готовит тестовые сценарии для драйв-тестов, проводит их по подготовленным тест-планам и измеряет ключевые показатели производительности базовых станций LTE/GSM с помощью измерительных комплексов. Здесь также от кандидата требуются знания принципов и законов радиосвязи, базовое понимание теории антенн и их характеристик.

→ А вот несколько вакансий, где глубокое знание телеком-технологий не является решающим фактором при отборе кандидатов. 

Test Engineer (Performance Test)

Команда занимается тестированием собственного железа и ПО. Направление создает конкурентную линейки RAN-продуктов для мобильных сетей последних поколений — базовые станции LTE/GSM и удаленные системы управления ими. Опыт работы с телекоммуникационными системами GSM/LTE будет преимуществом. 

QA Automation Engineer 

Команда ищет инженеров по автоматизированному тестированию в несколько команд в направление разработки решений для телекоммуникаций. Необходимый опыт в автоматизации с использованием Jenkins GitLab — от двух лет. Здесь ждут кандидатов с уверенным знанием Python, Linux и пониманием сетей, базирующихся на TCP/IP.

Test Engineer Manual 

Вам больше по душе ручное тестирование? Есть вакансия и для вас. Здесь ждут кандидатов с уверенным знанием теории тестирования (опыт — от трех лет), Linuх и пониманием сетей, базирующихся на TCP/IP.

О направлении 

Команда Телеком с нуля создает телекоммуникационные решения для беспроводных мобильных сетей и сопутствующих услуг. Инженеры разрабатывают первые в России базовые станции стандартов GSM/LTE, реализуя полный стек телекоммуникационных протоколов для базовых станций и элементов ядра сети, а также системы управления и мониторинга. Здесь вы будете в хорошей компании: продукт создают профессионалы с многолетним опытом, многие из них работали в ведущих мировых телекоммуникационных корпорациях.

А как тестируют функции базовой станции, читайте по ссылке → 

Друзья, ночи доброй.

Если позволите, вкратце о себе. Зовут меня Саней. Имею опыт в тестирование более 3-х лет. В послужном списке тестирования были desktop-приложения для операторов БПЛА, системы защиты информации, система кредитования физических лиц и многое другое.

В настоящий момент работаю в компании QA-специалистом и одновременно являюсь ментором для людей, решивших стать тестировщиками.

Имеется богатый опыт теории и практики в тестировании, а также есть желание поделиться с ним.

Пишу пост на Хабре впервые и хочу узнать, "стоит ли игра свеч" и будет ли кому-то это интересно. Буду раз в неделю выкладывать статью о профессии QA, делаю упор на практику, которая вам в последующем пригодится на работе. И не будем забывать о теории, чтобы успешно пройти интервью)))

Всем огромное спасибо!

ИИ-агенты в Альфа-Банке: нейросети создают автотесты без участия человека

Не фантастика, а реальность: в Альфа-Банке мы внедрили ИИ-агентов, которые проектируют, разрабатывают и проверяют автотесты. При этом полностью автономно, как настоящие QA-инженеры, но в разы быстрее и точнее. Это первый в России кейс, когда нейросети полностью закрывают цикл создания тестов — от анализа требований до пул-реквеста.

✨ Что умеют наши агенты?

🧠 Анализировать контекст из Jira и Confluence, вычленяя суть задачи.
🔍 Прогнозировать риски, зависимости и даже «пограничные» сценарии.
🛠️ Генерировать DTO для REST API и превращать ручные сценарии в Java-тесты за минуты.
✅ Сверять код с бизнес-логикой и техстандартами Альфы, защищая прод от случайных ошибок.
🌐 Создавать вариативные проверки — от позитивных кейсов до сложных негативных условий.
⚡ Автоматизировать рутину — и это лишь часть их скиллов.

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

«Одна команда ИИ-агентов экономит десятки часов работы, увеличивает скорость релизов и находит на 30% больше багов», — делится Святослав Соловьев, Директор по генеративному ИИ в ИТ Альфа-Банка.

🔜 Скоро расскажем подробнее — как устроены агенты, какие технологии behind the scene и как мы измеряем их эффективность. Оставайтесь с нами!

Дашборд — лицо системы: как сделать его удобным для команд из более 100 инженеров

Переосмысление дашборда стало одной из важных задач в процессе обновления интерфейса TMS TestY.

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

В Testy 2.0 можно выбрать, на каком языке будет работать система. Раньше интерфейс TMS был полностью англоязычным, теперь пользователям доступен русский язык — как часть плана поддержки локализации.

Добавили поиск по проектам и табличное представление, в котором доступно то же самое, что и на карточках: переходы, добавление в избранное, переключатели Only Favorites и Show Archive

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

Какие еще обновления появились в TMS с открытым исходным кодом, читайте в статье.

Зачем нужны юнит-тесты

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

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

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

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

Кстати, ИИ нынче отлично умеет писать тесты. И полезно не забывать про антипаттерны тестирования ПО.

«Слово о нагрузочном тестировании: курс на успешную миграцию»

📅 13 февраля, 16:00

А как тестируете вы?
📈13 февраля на онлайн-митапе обсудим преимущества и недостатки различных методов проведения нагрузочного тестирования. На примере реального кейса миграции СУБД представим нашу собственную методику оценки производительности информационных систем!

👨‍💻 Спикеры мероприятия:

— Роман Севрук, менеджер по развитию решений СУБД

— Александр Зубков, инженер по автоматизации нагрузочного тестирования

— Алексей Сатин, архитектор инфраструктурных решений

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

Почему совершать ошибки — полезно: рассказывают наставники Практикума

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

Тест, который не работал
Рассказывает Дарина Кухтина, наставница на курсе «Аналитик данных»

Я руковожу отделом аналитики в мобильном геймдеве. Мы запустили А/В-тест для игровых автоматов, чтобы проверить разные расстановки. Более успешные слоты поставили в начало. 3а две недели эксперимента не произошло никаких изменений. 

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

Выводы:

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

• Ошибка может быть в любом месте.

• Чем раньше заметить ошибку, тем лучше. Это экономит время, а время — деньги.

• Никому нельзя верить, даже себе.

Самокаты начали сигналить по всему городу
Рассказывает Андрей Шевченко, наставник на курсе «Инженер по тестированию»

Команда тестировала новую фичу для кикшеринга самокатов перед продакшном. Тогда мы не нашли одну из моделей самокатов и не перезапустили сервисы после доработки. 

Со следующим обновлением они перезапустились сами, в том числе единственная модель, которую мы не протестировали. Две тысячи самокатов сигналили два часа подряд. Было неприятно, но мы быстро собрались и вместе устранили проблему.

Выводы:

• Команда всегда тебя поддержит.

• Если ты где-то облажался, то облажалась вся команда.

• Окружение важно! Покройте проверками максимум.

• Перезапускайте сервисы после обновлений.

• Ошибок не допускает только тот, кто ничего не делает.

Есть ли ошибка, которая помогла вам стать лучше? Расскажите об этом в комментариях.

Последний Go-митап в этом году: как Go меняет подходы к разработке и тестированию

Уже через несколько часов, в 19:00, начнется онлайн-трансляция финального в этом году Go-митапа, где разработчики и технические лидеры сообщества обсудят инструменты кодинга на Go. В мероприятии примут участие эксперты из YADRO, Wildberries, Weborama и Ви.Tech. Регистрируйтесь на онлайн-участие. 

Программа:

Приветственное слово: Руслан Барсуков, ведущий инженер по разработке ПО в YADRO, и Виталий Левченко, технический менеджер в Wildberries, расскажут о планах Go-сообщества в Нижнем Новгороде.

«Генерация стабов для тестирования микросервисов по gRPC»

Кирилл Шувалов, разработчик дивизиона Телеком в YADRO, покажет, как с помощью Protoc стандартизировать тесты, упрощая их написание и повышая читаемость.

«Стриминг данных из Snowflake в Couchbase»

Александр Ванюшкин, разработчик в Weborama, поделится опытом создания плагина для Redpanda/Connect для оперативной обработки данных.

«Сборка проектов на Go: от Make до Mise»

Даниил Подольский, эксперт по разработке ПО в YADRO и один из лидеров внутреннего Go-сообщества, расскажет о развитии инструментов сборки и выборе оптимальных решений.

«Почему мы пилим монолит без микросервисов»

Кирилл Кузин, старший golang-разработчик, Ви.Tech, объяснит, как команда поддерживает сложную архитектуру и избегает ошибок при распиле монолита.

Пришлем ссылку на онлайн-трансляцию после регистрации на сайте →

Написание тестов и крепкие нервы

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

Тесты могут причинить немало хлопот, если нет систематизированного подхода к их написанию. Самый нашумевший из них – TDD.

TDD (Test-Driven Development)

Разработка через тестирование - этот подход имеет как минимум пару особенностей:

• Тесты пишутся до написания кода. Потом обеспечивается их прохождение и рефакторинг кода. И так по кругу.

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

Моя стратегия написания тестов, обычно, сводится к следующим двум подходам (аббревиатура из головы):

БКТ (блок кода, тест)

Использую чаще всего. Он не заставляет судорожно бегать по коду и анализировать, все ли кейсы были учтены. Минус в том, что написанное может не пригодится в итоге. Стирается код, удаляются тесты. Как итог - выкинутое в мусорку время.

ВКТ (весь код, тесты)

Сначала пишется код, потом ищутся случаи, которые нужно протестировать. Благо, если заранее, в тестовом классе, были описаны ветвления тестирования с комментариями, типа:

// API (Контроллер)
  // Запрос на получение данных
    // запрос пустой
      // ок – вернуть все данные
	// иначе
      // проверить корректность полученных данных
         // корректно – вернуть данные
      	 // иначе – сообщить об ошибке
…
// Сервис (бизнес-логика)
…
// Инфраструктурный слой (получение данных из другого сервиса, бд и пр.)
…

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

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

Все переплетено: как устроен тестовый стенд для базовой станции

Так выглядит схема тестового стенда, с помощью которого тестируют важную фичу базовой станции — handover. Handover помогает мобильным телефонам, ноутбукам и другим гаджетам «перескакивать» с одной БС на другую и не терять сигнал.

На рисунке видно, что на первой базовой станции сконфигурированы две соты, на второй — одна. Станции с разным наборов сот позволяют тестировать разные виды handover. Также здесь есть симулятор ядра сети и симулятор сотовых телефонов. На стенде тестирование проходит в идеальных радиоусловиях, какие редко бывают в реальности. 

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

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

О других особенностях тестирования handover читайте в статье → 

Дневник тестировщика. Записки разных дней.

Баг был, а теперь его нет. Куда пропал?

Я смеялась, когда они говорили: “Справимся за 2 дня.” Я плакала, когда справились.

В тестировании что главное? Правильно — не спать. А то разработчики сами всё протестируют.

Иногда, чтобы найти баг, нужно узнать, кто не писал код.

Как выпустить релиз без багов? Слёзно просить работать по процессам и перечитывать требования не помогает. Я проверяла.

— Нужно делать по правилам! — кричал зелёный QA Engineer.
— А ты попробуй, заставь! — бурчал седой разработчик.
— Вы зря пыжитесь, — ухмылялся Legacy-код.

Я думала, этот функционал тестирует мой коллега. Он думал, его тестирует третий. Третий ушёл в отпуск.

Просили фичу. Получили баг.

Как выпустить релиз без багов? Слёзно просить раскоммитить и пофиксить flaky-тесты не помогает. Я проверяла.

Тестировала, тестировала — да не вытестировала. День, когда деплой уронил продакшн.

Обожаю IT-фэнтези. Часто пишу его в тикетах.

Чем дольше я на проекте, тем проворнее баги. Эволюция?

Деплой не сошёл с ума. Он удивляет.

Красивый был баг. Жалко, что пофиксили.

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

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

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

Оценить константную нагрузку несложно:

• Сначала зарядим планшет до 100%, выдернем шнур USB и дадим планшету полежать с выключенным экраном ровно 2 часа. В нашем эксперименте планшет за два часа разрядился на 1%. Это уровень потребления устройства в состоянии покоя. Значит, все потребление энергии, которое мы измерим потом, будет скорее связано с дополнительными нагрузками.

• Затем запретим экрану выключаться, опять зарядим планшет до 100%, выдернем шнур USB и дадим планшету полежать уже с включенным экраном, тоже ровно 2 часа. На этот раз планшет разрядился на 9%. Если первая проверка, с выключенным экраном, проверяла, что нет катастрофических аномалий с железом, то эта проверка говорит, что эти 9%, собственно, накладные расходы от включенного экрана и активного CPU с запущенной на нем ОС.

Для каких экспериментов понадобилась такая константа, читайте в статье → 

Друзья, в рамках запуска комплексной программы «Fullstack-тестировщик» решили поговорить о том, как может выглядеть карьера в тестировании. 19 ноября приглашаем вас на онлайн-встречу «От ручного к Fullstack: как строить карьеру в тестировании» с Исангуловым Тимуром, ведущим инженером-тестировщиком IBS AppLine Innovation.

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

Вы можете задать Тимуру вопросы о работе QA прямо в эфире или оставляйте их в комментариях к этому посту, а ответы приходите слушать 19 ноября.

📅 Дата: 19.11.2024

⏰ Время: 16:00-17:00 (Мск)

👨‍🎓 Спикер: Исангулов Тимур — ведущий инженер-тестировщик IBS AppLine Innovation.

👉 Записаться на встречу «От ручного к Fullstack: как строить карьеру в тестировании» 👈

Не знаю на сколько это свежая новость ибо прочитал в новостях, но факт занимательный. JetBrains (опять) изменила лицензирование сделав IDE для Rust, JavaScript, C# и тестирования бесплатными для некоммерческого использования.

На сколько это следствие продвижения ИИ в средствах разработки - поди знай, но уж больно совпало по времени.

Призы для самых ловких – мы подвели итоги конкурса и готовы рассказать результаты

25 сентября у нас был День компании, и этот праздник мы отмечали с хабравчанами – вместе с Хабром собрали игру-раннер с сюрпризами и подарками для самых ловких пользователей. Розыгрыш призов уже закрыт, но игра ещё доступна, если захотите попробовать поиграть – переходите по ссылке. 

В игре было три карьерные дорожки: изобретательный Java-разработчик, вдумчивый системный аналитик и зоркий QA-тестировщик. Игроки проверяли свою ловкость, обходя препятствия и отвечая на рабочие вопросы по теме выбранной карьеры. Все, кто успел сыграть в период проведения розыгрыша и набрал более 200 очков – получил промокод на сервис Wink и попал в турнирную таблицу. Дальше среди участников таблицы при помощи рандомайзера мы разыграли 30 различных призов лично от нас – по 10 для каждого направления игры.

Имена победителей уже известны. Прикрепляем таблицу: вот ссылка. Если вы нашли свой никнейм – поздравляем, вы уже получаете промокод от Wink! Если напротив вашего никнейма написано «суперприз» – поздравляем ещё больше – вы счастливчик, выигравший отдельный приз. Мы свяжемся со всеми финалистами в личных сообщениях и расскажем, как забрать выигрыш.

Сайт, готовый ко всему — Никита Дубко / Ural Digital Weekend 2024

Опубликовали запись доклада секции «Разработка» с Ural Digital Weekend 2024.

Вспомните, где вы обычно тестируете свое веб-приложение. Скорее всего, у вас есть несколько вьюпортов, в которых вы быстро проверяете верстку и, возможно, пишете автотесты. И багов от пользователей почти нет — значит, все делаете правильно. Но как вашим сайтом пользуются на самом деле? Что нужно предусмотреть, чтобы сайт работал действительно почти везде?

В докладе вы найдете множество интересных примеров и отсылок. Заходите посмотреть!

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/NRS

Друзья, в рамках запуска комплексной программы «Fullstack-тестировщик» решили поговорить о том, как может выглядеть карьера в тестировании. 29 октября приглашаем вас на онлайн-встречу «От ручного к Fullstack: как строить карьеру в тестировании» с Исангуловым Тимуром, ведущим инженером-тестировщиком IBS AppLine Innovation.

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

Вы можете задать Тимуру вопросы о работе QA прямо в эфире или оставляйте их в комментариях к этому посту, а ответы приходите слушать 29 октября.

📅 Дата: 29.10.2024

⏰ Время: 15:00-16:00 (Мск)

👨‍🎓 Спикер: Исангулов Тимур — ведущий инженер-тестировщик IBS AppLine Innovation.

👉 Записаться на встречу «От ручного к Fullstack: как строить карьеру в тестировании» 👈

Как Duolingo добилась успеха на рынке и причем тут аналитика

Duolingo — одно из самых популярных приложений для изучения языков (№1 по скачиванию в магазинах приложений). Вместо скучных уроков оно напоминает игру: прогресс, уровни, награды, упражнения мини-игры и др.

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

Но что стоит за этим успехом?

Один из ключевых принципов компании — "Тестируй всё". Постоянные эксперименты помогают Duolingo улучшать процесс обучения и находить новые решения для роста.

В любой момент в Duolingo могут проводиться несколько сотен A/B тестов одновременно. Экспериментируют со всем: от мелких изменений интерфейса до запуска крупных функций, как Лидерборды. Для A/B тестирования компания разработала собственный сервис.

➡ Как выглядят эксперименты в Duolingo: статья.

➡ Пример A/B тестирования: формирование привычки учиться регулярно: статья.

➡ Какие аналитические инструменты использует компания для анализа данных: статья.

О других принципах успеха Duolingo и работе в этой компании писала тут.

Путь тестировщика: ошибки, опыт, деньги. Вышел новый Sravni Podcast!

В новом выпуске поговорили о сути QA, отношениях тестирования и разработки, неизбежности багов и ответственности за плохие релизы. Гость — Анна Серенькова, QA Mobile Lead Сравни.

В этом выпуске:

• Что должен уметь тестировщик и сколько ему платят?

• В чём разница тестирования в вебе и на мобильных устройствах?

• Почему в ИТ важно доказывать свою ценность, и в чём здесь отличия для женщин и мужчин?

• Право на какое количество ошибок есть у тестировщика, прежде чем его уволят?

Подкаст доступен по ссылкам:

✅ YouTube
✅ RUTUBE
✅ VK
✅ Яндекс.Музыка

Оперативно узнавать о наших новых подкастах, докладах, лекциях и других полезных ИТ-материалах, можно в тг-канале Sravni Tech.

Как в Авито устроено API-тестирование на Go?

В этом видео Глеб Дмитриев, инженер из команды Marketplace, рассказывает о проблемах, с которыми мы сталкивались на этапе выбора фреймворка для тестирования, и показывает, как работает наш собственный фреймворк на основе Testify.

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

Ранее Александр Трифанов, техлид Авито, рассказал о нашем подходе к сканированию данных в API.

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Яндекс Практикум запустил расширенный курс «Автоматизатор тестирования на Python»

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

Что будет на расширенном курсе:

• Основы Python, объектно ориентированное программирование, юнит-тестирование, UI-тестирование, тестирование API, инфраструктура и архитектура, Selenide, базы данных;

• 7 учебных проектов;

• Вебинары для разбора сложных тем каждые 2 недели;

+ дополнительный модуль «Развёртывание, настройка и запуск тестов из CI/CD»;

+ дополнительный модуль «Создание образов и работа с ними в Docker»;

+ 3 дополнительных учебных проекта в портфолио;

+ 8 индивидуальных консультаций с опытными автоматизаторами на Python по темам курса, техническому собеседованию, настройке автотестов или по любому интересующему вопросу.

Расширенный курс длится 6 месяцев, нагрузка умеренная — учёбе нужно уделять ≈14 часов в неделю. 

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

→ Узнать подробнее и начать учиться бесплатно

Как организовано нагрузочное тестирование на production в Авито

Мы сделали запуск нагрузочных тестов на проде одним из шагов процесса разработки и валидации требований. Тестами мы проверяем:

— требования по производительности к сценариям;
— запас производительности (стресс-тестирование).

Полный обзор процесса нагрузочного тестирования (регламент, проблемы, метрики, примеры реализации) — в новом выпуске avito.code с руководителем команды тестирования Игорем Стародубцевым.

А здесь вы можете узнать про эксперимент по написанию 5000 тестов и сборку генератора для тестирования: как мы к этому пришли и что это нам дало. 

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

С днём тестировщика!

Сегодня или когда бы то ни было, пусть ваша работа приносит вам радость и помогает достичь заветной цели!

Цицерон считал:

«Ни одно изобретение не может сразу стать совершенным»

Но мы ведь с вами знаем, что делать ッ

С праздником всех, кто QA и около-QA! Бывших тестировщиков не бывает ッ

Поздравляем всех тестировщиков с профессиональным праздником!

Желаем поменьше багов брыдлых,
Да побольше кода ладного.
Чтоб все хлопцы и золотинушки счастливы были,
А доля их рабочая только отраду приносила.

К празднику подготовили рассказ, как мы создавали и развивали КОТа — Школу Как Обучить Тестировщика. За несколько лет КОТ стал незаменимым помощником в деле формирования качественных кадров и слаженного комьюнити тестировщиков внутри компании.

Читать тут.

Weekend Offer для Java-разработчиков, системных аналитиков и QA-инженеров (backend)

24—25 августа проведем Weekend Offer в Нефинансовые сервисы Т-Банка сразу для трех профессий: Java-разработчиков, системных аналитиков и QA-инженеров (backend). Это самый быстрый путь к офферу: вы сможете пройти все этапы интервью за выходные.

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

Мы ждем:

— Java-разработчиков, которые владеют навыками в любой из технологий: Spring, Quarkus, Micronaut, Ktor или Vert.x.

— Системных аналитиков, которые работали с REST/gRPC/graphQL и брокерами сообщений — Kafka/RabbitMQ.

— QA-инженеров с опытом работы в тестировании бэкенда и автоматизации тестирования с использованием Java, Kotlin или JS.

Если у вас есть опыт от 3 лет — приходите и создавайте прорывные сервисы вместе с нами. Заявку можно оставить до 21 августа на сайте.

Всем привет!

Хочется сказать пару слов о практике T-Shape. Это когда помимо основной специальности - например, разработки, ты развиваешься в чем-то еще. Если рассмотреть состав типовой команды, то это аналитик или тестировщик. Может быть DevOps или НТ. Или даже сопровождение ПРОМ. Насколько я знаю, такая практика есть в Яндексе. Рассмотрим плюсы и минусы на примере разработчика-тестировщика.

Плюсы очевидны:

1. взаимозаменяемость членов команды

2. упрощение найма за счет унификации

Но есть и минусы.

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

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

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

   Итог - практика интересная, но требует высокой инженерной культуры и подвержена влиянию человеческого фактора