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

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

Команда 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 с запущенной на нем ОС.

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