Привет! Меня зовут Артём, и я занимаюсь автоматизацией тестирования. Антипаттерны в разработке — довольно популярная тема. Но ведь в тестировании тоже есть свои "плохие советы", и они довольно забавно пересекаются с разработкой. Недавно мне на глаза попалась ироничная статья про антипаттерны в тестировании. Вашему вниманию!

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

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

Ну, а если вы добрая душа и уважительно относитесь к чужому труду, то можете рассматривать эту статью как набор антипаттернов.

Итак, поехали.

Если попытаться описать прошедший Heisenbug одним словом, это будет «разнообразие». Спикеры из гигантских компаний и из юных стартапов, темы от тестирования мобильных игр до тестирования блокчейна, доклады с кучей кода и совершенно без кода; наконец, были вообще не доклады, а сессии «birds of a feather».

Наверное, лучший способ рассказывать о таком событии — не пытаться найти «общий знаменатель», а привести несколько разных примеров того, о чём можно было услышать на прошедшей конференции. Что мы и сделали под катом.

Об авторе: Хэм Фокке — разработчик и консультант ThoughtWorks в Германии. Устав от деплоя в три ночи, он добавил в свой инструментарий средства непрерывной доставки и тщательной автоматизации. Сейчас налаживает такие системы другим командам для обеспечения надёжной и эффективной поставки программного обеспечения. Так он экономит компаниям время, которое эти надоедливые людишки тратили на свои выходки.

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

Конференция: Heisenbug 2018 Piter
Дата: 17-18 мая 2018 года
Место: Санкт-Петербург, гостиница «Park Inn by Radisson Пулковская»
Посмотреть трансляцию онлайн можно по этой ссылке

Heisenbug 2018 Piter состоится уже послезавтра. Главный зал конференции будет бесплатно транслироваться на YouTube. Как попасть на трансляцию и что там будет, мы расскажем под катом.

Какие инструменты нужны тестировщику? Об этом мы сегодня порассуждаем в этой статье, в основе которой — доклад Юлии Атлыгиной с прошлого Heisenbug. Видеозапись доклада доступна по ссылке.

Введение

Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.

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

Терминология

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


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

• «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
• «Пирамида тестов» (Мартин Фаулер, 2012)
• «Блог отдела тестирования Google» (Google, 2015)
• «Пирамида тестов на практике» (Хэм Фокке, 2018)

Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта

О чём это всё

Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.

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

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

Замечали, что обычно люди, ответственные за эксперименты, в итоге говорят, что данных недостаточно для решения? Часто это действительно так, но нередко всё дело в поломках системы экспериментов и учёта пользовательской статистики.
 
В этой статье мы рассмотрим типичные поломки, которые там встречаются, и у вас появится возможность, вернувшись на рабочее место, немножко побыть data scientist'ами и найти ошибки у себя в компании. Какие-то из них там наверняка есть.

В основе материала — расшифровка доклада Романа Поборчего с нашей декабрьской конференции Heisenbug 2017 Moscow.

Разработка сервисов сейчас базируется на оценке их качества. Чтобы оценить взаимодействие пользователей с продуктом, проводятся онлайн-эксперименты, и только потом принимаются решения о запусках и обновлениях. Например, в 2015 году Google ежедневно проводил до 1000 подобных экспериментов. Растёт и число небольших компаний, которые используют AB-тестирование. На очередной встрече «Яндекс изнутри» разработчик-исследователь Алексей Друца рассмотрел современные математические методы, лежащие в основе платформ для онлайн-оценки.


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

Конференция: Heisenbug 2018 Piter
Дата: 17-18 мая 2018 года
Место: Санкт-Петербург, гостиница «Park Inn by Radisson Пулковская»

Всего две недели осталось до нашего следующего Heisenbug. Над программой и докладами была проведена колоссальная работа, о которой мы расскажем под катом.

В среде ИТ есть свои легенды, чьи имена знает сегодня чуть ли не каждый и чьи (что важнее) достижения в профессии показали другим новый путь к развитию. Одной из таких фигур для мира тестирования ПО был и остается Майкл Болтон, которого мы ждем на ближайшем Heisenbug 2018 Piter. В этой статье мы поговорим о Rapid Software Testing, о Майкле и его докладах.

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

Вроде бы о тестировании мобильных приложений есть уже тысячи материалов, так что удивить тут сложно. Но пока аспекты вроде UI уже затёрты до дыр, про тестирование геолокации рассказывают гораздо реже. И когда на нашей конференции Heisenbug Николай lamamer Козлов и Александр z3us Хозя (Badoo) поделились своим опытом, зрителей конференции доклад очень заинтересовал. Как и геолокацию получить, и телефон пользователю не разрядить? Зачем в этом тестировании селфи-палка? Насколько близко расположены лондонские пабы и что из этого следует?

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

История превью страниц.


Когда вы наводите курсор на ссылку, появляются карточки предварительного просмотра (и да, у меня на десктопе мобильный скин Википедии). Текст из статей Википедии об айсбергах и воде, CC BY-SA 3.0. Изображения слева направо, сверху вниз: #1 Ким Хансен, CC BY-SA 3.0; #2 Андреас Вайт, CC BY-SA 4.0; #3 Национальная библиотека Новой Зеландии, CC0

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

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

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

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

В связи с всем известными обстоятельствами, сервис мониторинга сайтов ХостТрекер предлагает возможность бесплатного использования наших инструментов для целей информирования общественности, сбора статистики и других интересных вещей. Цель — спасти всех. Ну или хотя бы ползти в том направлении. Что и как можно cделать, а также наши рекомендации для тех, кого это явление уже затронуло или потенциально может затронуть — под катом.

Здесь вы не увидите ни строчки кода. Мы поговорим об обычных людях — о наших пользователях, точнее о том, как сообщать им, если в системе возникла какая-то непредвиденная ситуация.


В основе статьи доклад Антонины Хисаметдиновой с Heisenbug 2017 Moscow, которая занимается проектировкой пользовательских интерфейсов в компании Собака Павлова.

Кроме того, на Медиуме есть цикл статей «Руководство по проектированию ошибок». Цикл еще не дописан до конца, но дает более полную и цельную картину по теме статьи.

Я уже делился рассказом о нашем опыте применения искусственного интеллекта в поиске на hh.ru, а сегодня хотел бы остановиться на измерении качества этого поиска поподробнее.

Для нормальной работы поиска крайне важна система метрик — локальных, A/B-тестов, очередей на проде и т. д., и эта система требует отдельного внимания и ресурсов. Неправильно думать, что достаточно просто запилить крутой ML и прикрутить все эти метрики «скотчем»; недостаточно также измерять качество работы уже работающей системы — не так уж важно, использует ли она ML или представляет собой Lucene «из коробки».

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



Сегодня мы поговорим о том,

• Как делать тестирование сложными зависимостями?
  
• Как добиться большого тестового покрытия?
  
• Как тесты влияют на дизайн?
  
• Что делать, когда много логики в базе?
  
• Как соблюсти компромисс между дизайном и «не дизайном».
  

Чтобы непрерывно улучшать большие клиентские интерфейсы, нужна мощная система автотестов. Разработчик Яндекса Дмитрий Андриянов dima117 кое-что про это знает — пару месяцев назад он поделился своим опытом на Я.Субботнике в Нижнем Новгороде.


— Сегодня я расскажу, как мы в Директе пишем модульные тесты на веб-интерфейс. Мы в целом посмотрим, чем тесты на интерфейс отличаются от других тестов. Рассмотрим два подхода к написанию тестов: с помощью Selenium и с помощью Headless-браузеров. И в конце покажу инструмент, который мы написали в Директе для запуска тестов в Headless Chrome.

Всем привет! Я работаю в Avito и занимаюсь разработкой инструментов для тестирования. Когда у нас стало много UI-тестов, мы столкнулись с проблемой масштабирования Selenium-серверов, и сейчас я расскажу, как мы ее решили.

И так как же все-таки выполнять много UI-тестов параллельно, используя Selenium Grid? К сожалению — никак.
Selenium Grid не способен выполнять большое количество задач параллельно.
Хотите зарегистрировать действительно большое количество нод? Что ж, попробуйте.
Хотите скорости? Её не будет — чем больше нод зарегистрировано на гриде, тем менее стабильно выполняется каждый тест. Как следствие — перезапуски.
Хотите отказоустойчивость на случай, если Grid перестал отвечать? Тоже нет: вы не можете запустить несколько реплик и поставить перед ними балансировщик.
Хотите обновить Grid без даунтайма и чтобы тесты, выполняющиеся в данный момент, не упали? Нет, это не про Selenium Grid.
Хотите не держать тысячи Selenium-ов разных конфигураций в памяти, а поднимать их по требованию? Не получится.
Хотите знать, как решить все эти проблемы? Тогда приглашаю вас прочитать эту статью.
*(Мой доклад с таким же названием уже звучал на Heisenbug 2017 Moscow, и, возможно, кто-то из читателей с ним знаком. Под катом — более подробная текстовая версия рассказа об инструменте).