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

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

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

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

Я руковожу отделом аналитики в мобильном геймдеве. Мы запустили А/В-тест для игровых автоматов, чтобы проверить разные расстановки. Более успешные слоты поставили в начало. 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, она сложнее и поэтому интереснее. Отсюда риск, что на тестирование будет выделяться меньше времени. Вопрос в уровне инженерной культуры и дисциплине, но это снова человеческий фактор.

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