Что такое тестирование и почему мы должны его делать? | by Alexey Pyltsyn | devSchacht
Перевод статьи Alex Jover Morales: What’s testing and why should we do it?.
В первой статье в этой серии из пяти частей о тестировании в JavaScript мы рассмотрим, что такое тестирование и почему мы должны это делать. Если вас интересует тестирование в контексте Vue.js, то обратите внимание на книгу «Тестирование компонентов Vue.js с помощью Jest».
Тестирование в области разработки программного обеспечения — это процесс оценки того, что все части приложения ведут себя так, как ожидалось.
Тесты выполняют проверки программного обеспечения, проверяя, что полученный результат соответствует спецификациям, учитывая разные входные данные. Каждая из этих проверок называется тестовым сценарием (test case). В рабочем процессе agile каждая пользовательская история должна иметь набор тестовых сценариев. Простой пример:
US-01: создание компонента ввода валютыСценарии тестирования:
– TC-01: он должен принимать только числа
1.Введите число «2». Ожидается: все должно быть в порядке
2. Введите символ «a». Ожидается: должно отображаться сообщение «Разрешены только числа»
– TC02: оно не может быть пустым
...
Введите число «2». Ожидается: все должно быть в порядкеВ тестовых сценариях проверяются требования и характеристики конкретной функциональной возможности (функционала). Они могут предоставлять определённые детали или шаги, чтобы их можно было воспроизвести.
Скорее всего, если вы читаете эту статью, вы знаете, что такое тестирование и TDD, но если вы новичок в тестировании, у вас может возникнуть вопрос, который был в своё время у всех нас:
Не занимает ли тестирование слишком много времени? Нужно ли мне тестировать всё?
В этой статье мы поговорим о плюсах и минусах тестирования, о типах тестирования, и что ещё есть кроме тестирования для обеспечения качества приложения.
Говоря о том, зачем нужно тестирование, можно упомянуть следующие его преимущества:
- Экономит деньги: без надлежащего тестирования количество времени и ресурсов, необходимых для поддержания продукта в долгосрочной перспективе, намного больше, чем инвестиции в тестирование, не говоря уже о том, что со временем что-то сломается.
- Обеспечивает безопасность кода при командной работе: приложение часто создаётся командами. Разные люди изменяют один и тот же фрагмент кода с течением времени. Наличие тестов делают этот процесс более безопасным, поскольку никто не сломает что-то, не узнав об этом. Это также относится и к будущему, тесты обеспечивает безопасность кода, когда вы вернётесь через год или два для внесения изменений.
- Помогает в создании лучшей архитектуры: когда часть приложения трудно тестировать, это обычно происходит из-за того, что оно тесно связано с другими частями или функциональность вашего приложения слишком сложна. При их тестировании вам нужно будет сделать их слабосвязанными, применить делегирование и паттерны проектирования, чтобы сделать приложение максимально простым и тестируемым.
- Улучшает качество кода: ваш продукт менее подвержен сбоям в работе поскольку тесты помогает написать более надёжный и хороший код, который менее подвержен ошибкам.
- Делает рефакторинг простым и безопасным: создание программного обеспечения — это итеративный процесс. Требования меняются с течением времени, следовательно, меняется и функциональность. Наличие хорошего тестового покрытия позволяет вам модифицировать определённый код, проверяя, что тесты все ещё успешно проходят. Если это не так, вы делаете правки в код таким образом, чтобы тесты прошли.
Требования меняются с течением времени, следовательно, меняется и функциональность. Наличие хорошего тестового покрытия позволяет вам модифицировать определённый код, проверяя, что тесты все ещё успешно проходят. Если это не так, вы делаете правки в код таким образом, чтобы тесты прошли.Надеюсь, что на данном этапе вы убедились, почему тестирование полезно для вас, вашего приложения и компании, в которой вы работаете.
Тесты делятся на разные типы. Каждый тип теста имеет свою цель (назначение) и область действия, и вам следует знать об этом. Каждый разработчик в какой-то момент пишет тест, который тестирует то, чего он не должен.
У нас есть три основных типа тестов:
- End-to-end-тесты (сокращённо — E2E) или сквозные тесты, как их называют при переводе: тестируют систему в целом, эмулируя реальную пользовательскую среду. В интернете это тесты, запущенные в браузере, имитирующие щелчки мышью и нажатия клавиш. В общем, набор таких тестов не должен быть большим, так как они дороги для обслуживания и могут легко устареть из-за тестирования системы в целом.
- Интеграционные тесты: цель данных тестов состоит в том, чтобы убедиться, что несколько зависимых друг от друга модулей кода работают вместе, и их взаимодействие работает должным образом.
- Модульные тесты: они тестируют определённую функциональность изолированно. Их легче всего создавать и обслуживать, поэтому большинство тестовых наборов — это модульные тесты.
Пирамида описывает баланс различных типов тестов. Нижняя часть — это самые быстрые, простые и самые изолированные тесты, а верхние — самые дорогие, самые медленные и охватывают всё приложение в целом.
Интеграционный слой можно даже разделить на ещё большее количество слоёв:
Хотя есть несколько разногласий по поводу количества типов тестов и их имён, наиболее распространёнными являются тесты компонентов и API. Это всего лишь особые типы интеграционных тестов. В частности, тесты компонентов — это тесты, которые мы пишем на стороне фронтенда при тестировании приложения на Vue.js.
Тесты — не единственный инструмент для обеспечения качества кода.
В наше время для JavaScript также есть инструменты статической типизации и утилиты для проверки кода (linters, далее — линтеры). Они выполняют статический анализ вашего кода для поиска несоответствий выбранному стилю кода, неправильного использования языка, ненадлежащей и плохой практики, ошибок в контракте данных и многое другое.
Контракт данных — формат данных, который будет использоваться некоторой частью приложения, например функцией. Обычно под этим понимается в каком виде будут представлены данные, например, тип входных и возвращаемых данных.
Статическая типизация делает ваш код более безопасным на основе каждого контракта. Такие инструменты, как TypeScript или Flow, позволяют определять переменные, параметры и типы возвращаемых значений. Они гарантируют, что ваши классы, функции и методы имеют определённую структуру, а остальная часть вашего кода хорошо работает в соответствии с этим. Многие компании, принявшие статическую типизацию, сразу же поймали несколько ошибок.
Давайте сравним типизированную версию и не типизированную версию функции sum:
// Нетипизированная функция
function sum(a, b) {
return a + b;
}// Типизированная функция
function sum(a: number, b: number) : number {
return a + b;
}
Версия функции без указания типов не мешает нам вызывает её со строчными входными данными, в результате возвращая нам конкатенацию строк. Например, вызов sum('1', '2') возвращает '12'. Однако, если мы используем статическую типизацию, мы получаем ошибку, такую как Argument of type '"1"' is not assignable to parameter of type 'number' (Аргумент этого типа ‘»1″‘ не может быть присвоен параметру типа ‘number’), и эта ошибка типизации предотвращает нас во время компиляции совершить вызов функции, который вернёт неверный результат, поскольку мы ожидаем сложение чисел, а не конкатенацию строк.
Линтеры — это специальные программы, цель которых анализ и проверка различных аспектов кода во время компиляции.
JavaScript не имеет преимуществ компилятора, поэтому подвержен ошибкам во время выполнения по сравнению с другими языками, где об ошибках будет сообщено на стадии компиляции. ESLint стал линтером де-факто в JavaScript, а TSLint — в сообществе TypeScript.
Линтер пытается заполнить пробел, предоставляя правила проверки ошибок синтаксиса, стиля кода и неправильного использования (проблемных паттернов). В результате он уменьшает количество ошибок и повышает качество и корректность вашего кода.
В качестве примера, если вы используете правило no-var в ESLint и напишите следующий код:
var greet = 'Эй, Китти';
Вы получите ошибку Unexpected var, используйте let или const вместо (no-var) (Неожиданный var, используйте let или const вместо него (no-var)).
В пирамиде статический анализ ещё точнее определён и проверяется быстрее (почти в режиме реального времени), чем модульные тесты, что делает его основой пирамиды:
Эта статья является первой частью серии Тестируй как профи в JavaScript.
Почему тестирование — это тупо и скучно? / Хабр
Последние дни всё чаще натыкаюсь на сообщения в блогах и форумах про то, что тестирование — это либо очень скучно, либо тупая работа и т.д.Что все эти люди делают в тестировании??
Позавчера я тестировала свой небольшой веб-проект.
За 4 часа я завела 25 дефектов.
Я очень радовалась каждой «находке», особенно если в поиске она была нетривиальной. Ещё больше радовалась каждый раз, когда удавалось точно локализовать дефект. Мне действительно нравилось их заводить, стараясь это сделать наиболее понятным способом.
«А что, если?…», «А как проверить?…», «А как бы?…» и т.д. заполняют мозг, который включается на полную мощность.
Если бы мне кто-то предложил в этот момент посмотреть фильм, поиграть в компьютерную игру или сходить в клуб, я бы ему ответила, что занята значительно более интересным занятием! Потому что это действительно очень интересно!
Это захватывает, и время пролетает очень быстро.
И я задумалась. Кто пишет про «скучно», «рутина» и «тупая работа»? Почему не всем нравится? Постаралась выписать всё, что пришло в голову.
1. «Не моё». Я обожаю тестировать и проводить тренинги, но я ненавижу звонить по телефону. НЕ МОЁ! Тестирование — это набор конкретных действий, которые мы выполняем. Кому-то нравится этот процесс, кому-то нет. Если это не ваше — ищите своё! Явно есть вещи, которые увлекут так же, как тестирование — меня.
2. «Не умею». Тестировать — это навык. Я помню, как я тестировала в начале карьеры. Тынканье на кнопки, просмотр UI… нудно и скучно. Тогда я не использовала на лету интересные техники тест-дизайна, тогда я не понимала как правильно локализовывать дефекты и вообще не понимала насколько важно (и обычно сложно) их точно локализовать. Это была и впрямь тупая работа, это было скучно. Знание методологии меняет всё! Тестирование становится творческим и значительно более интересным!
3.
«Не понимаю зачем». Когда я тестирую свой собственный проект, мне это важно и я понимаю, зачем я это делаю. Когда я участвовала в выпуске продуктов с мировым именем, которыми я гордилась и горжусь, я понимала важность тестирования для миллионов (МИЛЛИОНОВ!) пользователей. Это добавляет работе значимость и интерес. Работая в компании, в которой качество не ценится, испытывать удовольствие от тестирования сложно — оно же никому не нужно!
4. Неоправданно жёсткие процессы. Тестировать по 100 лет назад созданным тест-кейсам, повторяющимся каждый день, не просто скучно, но и бесполезно. В итоге и интереса нет, и ответственность не чувствуется. Надо уметь выбирать оптимальное соотношения исследования к документированию. Да, документы нужны. Иногда чек-листы, иногда даже тест-кейсы, иногда они даже необходимы. Но НЕ ВСЕГДА!
Может, есть ещё какие-то причины неинтереса.
Но мне кажется, что если у вас
* оптимальный процесс
* достойный продукт
* существенный багаж знаний в области методологии тестирования и вы умеете их пременять,
то либо тестирование — это мега-супер-пупер-аж-захватывает-дух интересно, либо НЕ ВАШЕ!
Тестирование — это не поиск ошибок! / Хабр
Многие считают, что тестирование ПО — это поиск ошибок.
Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.
Что такое поиск ошибок?
Я тестирую продукт. Моя задача — завести как можно больше багов. Оно и логично! Заводить баги тестировщику всегда приятно, это видимый измеримый результат работы, И чем их больше, тем больше меня ценят как тестировщика.
Какие области я буду тестировать в таком случае? В первую очередь, самые нестабильные. Зачастую они нестабильны потому, что менее приоритетны, но это неважно, значительно важнее количество багов.
Что будет, если я столкнусь со сложновоспроизводимым багом? ROI на его исследование считается в голове очень быстро. Зачем мне с ним возиться, если я за это же время смогу завести 3 менее критичных, зато простых в заведении?
Какие тесты я буду проводить в первую очередь? Конено, самые нестандартные.
Ввести в поле логина «Войну и мир», поделить на ноль, вставить в профиль фотографию в формате .exe.
Скажу по секрету — иногда на собеседованиях тестировщики в ответ на просьбу «протеструйте калькулятор» перечисляют интересные и дельные тесты, но в числе первых тридцати
Именно так выглядит поиск ошибок — не имеющий ничего общего с тестированием.
Что такое тестирование?
Я тестирую продукт. Моя задача — пропустить как можно меньше приоритетных для пользователя багов. Чем меньше багов пропущено, чем меньше недовольства клиентом выражено — тем выше я оцениваю эффективность своей работы.
Какие области я буду тестировать в этом случае? Естественно, я начну с самых приоритетных для пользователя. Даже если они стабильно и успешно работают, я всё равно буду проверять основные пользовательские сценарии, чтобы ни в коем случае не пропустить серьёзных проблем.
Что будет, если я столкнусь с трудностями? К примеру, со сложновоспроизводимым дефектом, или непониманием бизнес-процесса пользователя, или нехваткой требований? Если это важный функционал, то я буду выяснять «что не так», «как правильно».
Какие тесты я буду проводить в первую очередь? Конечно, самые-самые стандартные. Выполнение самого основного сценария в самых основных условиях, чтобы убедиться, что самый важный функционал работает. И только после этого я перейду к менее стандартным сценариям.
Результаты тестирования и поиска ошибок
В случае с поиском ошибок, в краткосрочной перспективе результаты выше: багов заводится больше и сразу.
Но в долгосрочной перспективе всё не так радужно:
- из-за отсутствия глубоких знаний о продукте, постепенно начинает расти % пропущенных дефектов
- команда разработки занята исправлением страшных-ужасных-немыслимых багов, полученных путём клика на одну и ту же кнопку 144 раза под IE в полнолуние
- в релиз попадают некоторые ужасно неприятные и очевидные для пользователя баги
- количество находимых ошибок в ДОЛГОСРОЧНОЙ перспективе падает
Как перейти от поиска ошибок к тестированию?
Чтобы тестирование было эффективным и полезным в долгосрочной перспективе, необходимо следовать простым правилам и использовать ключевые инструменты тестирования:
1.
Анализ продукта и документирование тестов Кликая на кнопки, можно завести много багов — но нельзя сказать, что было проверено. Единственное решение — документирование тестов. Подробные тест-кейсы, удручающие тестировщиков и отнимающие уйму времени, бывают нужны очень редко. А вот чек-листы с перечнем «что нужно проверить» — необходимы.
Что они дают:
- Вы анализируете продукт, выписываете основные фичи, действия, их параметры. Таким образом существенно снижается риск что-либо забыть.
- Чек-листы — отличная напоминалка «здесь надо вникнуть глубже». Есть какая-то невнятная фича с недостаточным описанием. Как её тестировать? В тестировании без тестов проще всего сказать «я вернусь к этому позже», и уже никогда не вернуться. А с тестами — у вас будет висеть тест, в котором непонятно как и что проверять, вы будете такие тесты видеть и не забудете необходимость выяснения.
- Чек-листы можно и НУЖНО согласовывать. С разработчиками, аналитиками. Вся команда включается в процесс тестирования, тестировщики узнают много нового о продукте, коллективный разум улучшает качество тестирования. И помимо однократного повышения качества отдельно взятого чек-листа, повышается качество тестирования в целом: тестировщики начинают больше учитывать в тестировании, развиваться, эти знания со временем окупаются в виде более результативного тестирования.
Вся команда включается в процесс тестирования, тестировщики узнают много нового о продукте, коллективный разум улучшает качество тестирования. И помимо однократного повышения качества отдельно взятого чек-листа, повышается качество тестирования в целом: тестировщики начинают больше учитывать в тестировании, развиваться, эти знания со временем окупаются в виде более результативного тестирования.Залог успеха в ведении тестов — создание карты, по которой вы будете идти. Цель — покрыть весь продукт. Только пожалуйста, не надо отмазок об ужасной ресурсоёмкости — я покрывала проекты с миллионами строк кода меньше чем за месяц-полтора. И в процессе написания таких тестов поднимались неожиданные вопросы и всплывали критичные ошибки, которые несмотря на наличие горе-тестеров болтались в продукте годами.
2. Оценка тестирования
Чтобы не быть слепыми котятами, необходимо оценивать эффективность тестирования. Анализировать пропущенные ошибки и причины их пропуска.
ВСЕГДА есть что улучшать, и отсутствие непрерывного процесса совершенствования — неизбежное болото.
3. Обсуждение целей тестирования с командой
Многие считают, что у тестирования есть какие-то мифические цели. И что они всегда одинаковы.
Как бы не так!
В каждом проекте, компании, команде цели свои собственные. Все ли их понимают одинаково? Проговаривали ли вы их вслух?
Чтобы приносить максимум пользы, надо хорошо понимать, в чём эта самая польза заключается. И не удивляйтесь, если мнение РМов и разработчиков не будет соответствовать вашему. Надо не переубеждать их, а подстраиваться под текущие проектные цели!
4. Понимание пользователей и их бизнес-процессов
Для меня загадка, как это возможно, но тем не менее это факт: зачастую тестировщики проверяют продукт, ничего не зная о пользователе.
- Как этот продукт используется?
- Зачем он вообще нужен, какие проблемы решает?
- Какая средняя квалификация у пользователей?
- В каких условиях работают пользователи? На каких окружениях, оборудовании?
Не надо догадок и додумок про «в среднем про отрасли»! Тестировщики должны ИДЕАЛЬНО знать СВОИХ пользователей. Часто им эту информацию не предоставляют аналитики. Одумайтесь! Не зная пользователя, тестировать продукт по-нормальному невозможно.
5. Техническая квалификация и понимание архитектуры
Для иллюстрации приведу баг, который на меня недавно завели в баг-трекере:
Зайти на сайт тестируемого продукта http://****.ru в браузере Firefox
Ввести логин и пароль
Зайти с того же компьютера в браузере Opera
Просит повторно ввести логин и пароль, автоматически не логинится.
Такие баги не просто бесполезны, они позорят тестировщиков и дискредетируют отрасль в целом! Чтобы заводить дефекты правильно, необходимо понимать платформу, на которой написан тестируемый продукт.
Если мы говорим про веб-тестирование, то можно хотя бы указать в баг-репорте возвращаемый сервером код ошибки, посмотреть подробности файрбагом, предоставить подробную информацию и сэкономить разработке массу времени!
Выводы
Очень многие разработчики не любят тестировщиков. И правильно делают!
Зато хороших тестировщиков любят и ценят все. Но тестировщиков, а не кликеров и багозаводильцев!
Учитесь узнавать, что не так, что не нравится другим участникам команды разработки. Обязательно исследуйте пропущенные ошибки и делайте всё для того, чтобы больше их не пропускать. Не гонитесь за заведением багов — вашей мантрой должны быть «счастье пользователя», «качественный продукт» и «успешный проект», а не «завести как можно больше багов» — ОЧЕНЬ часто эти 2 цели оказываются слишком далеки друг от друга.
И да пребудет с вами сила!
|
Оригинал статьи: https://dojo. Перевод: Ольга Алифанова Если бы вам пришлось ответить на вопрос «Что такое тестирование?», что бы вы сказали? Это понятие довольно трудно впихнуть в пару-тройку коротких предложений. Плюс к тому многие недопонимают, что же такое тестирование, чем занимаются тестировщики – даже среди самих тестировщиков. Тестирование как навык и как профессия постоянно развивается. В этой статье мы рассматриваем, чем тестирование является, и чем нет. Из чего состоит тестированиеРасследование Расследование определяется как «наблюдение или изучение путем близкого наблюдения и систематического изучения» [1]. Процесс тестирования должен быть расследованием. Мы не всегда знаем, что получим на выходе, но наша задача – выяснить информацию, которая поможет людям принимать решения. Это не просто сравнение работы системы со спецификацией, где прописан ожидаемый результат. Исследование Список требований всегда неполон – всегда найдутся неучтенные требования, которые опущены или предполагались по умолчанию. Вне зависимости от полноты ваших требований, они всегда будут неполны. Вы не будете заранее знать, что делает ваше приложение. И тут в игру вступает исследовательское тестирование. Исследовательское тестирование определяется как одновременное обучение, тест-дизайн и прогон тестов [2]. Тестировщик исследует приложение, узнает новую информацию, учится, находит что-то новое для тестирования по ходу дела. Он может заниматься этим в одиночку или в паре с другим тестировщиком (а может, и разработчиком). Тестирование не должно восприниматься, как прогон списка готовых тестов или тест-кейсов, дающих твердый «pass/fail’ результат. Если у вас есть юзер-стори или набор требований, конечно, важно иметь их в виду. Однако критерии приемки бывает полезно переформулировать как «критерии отказа». Когда критерии приемки не удовлетворены, продукт не принят, но если они в порядке, это не значит, что в ПО нет багов. Проверки и верификация должны совмещаться с исследованием и расследованием, а также вопросами в духе «Что будет, если…», на которые вы можете не знать ответа, пока не попробуете, и ответы на которые не покрыты вашими готовыми кейсами. Снижение рисков Одна из причин, по которой мы тестируем – это поиск дефектов, рисков и другой информации о продукте, которая позволяет нам действовать, чтобы конечный пользователь не пострадал. Мы можем:
Устранить все возможные баги, с которыми может столкнуться пользователь, просто невозможно, каким бы сложным не было ваше ПО. Однако, тестируя, мы снижаем риск того, что пользователь с ними столкнется – или серьезность последствий такого столкновения. Ценность Тестирование – это ценная часть разработки ПО, но его часто недооценивают из-за его непредсказуемой и креативной природы. Результат ежедневного труда разработчика – это код, аналитика – требования или документация, однако результаты труда тестировщика может быть довольно сложно измерить. Зачастую тестировщикам сложно рассказать о своих планах, своем прогрессе и результатах. Те, кто не разбирается в тестировании, в результате плохо понимают, что было сделано, как, и почему. В итоге понять ценность тестирования сложно. В мире множество компаний, разрабатывающих ПО вообще без тестировщиков. Отсутствие счетного результата, создаваемого тестировщиками – одна из причин, по которой некоторые предпочитают использовать тест-кейсы как способ измерения – их можно легко сосчитать. Но ценность тестирования – это намного больше, чем тест-кейсы. Исследовательское тестирование, возможно, не дает в результате набора четких кейсов, однако тестировщик находит больше интересных багов, отступая от жестких сценариев. Отчасти поэтому людям нравятся метрики, которые учитывают количество заведенных багов, написанных и пройденных кейсов, и других вещей, которые можно сосчитать. Некоторые проекты используют эти метрики, чтобы измерять качество продукта, а также качество работы разработчиков и тестировщиков. Эти метрики концентрируются на неправильных вещах и могут вас обманывать. Тестирование ценно на всех стадиях жизненного цикла разработки, не только когда пишется код. Вот что еще можно протестировать:
Задача тестировщика – задавать вопросы, исследовать, критически размышлять над этими вещами. В результате то, что могло бы стать багом в процессе разработки, можно изловить гораздо раньше. Коммуникация Коммуникация – это огромная часть работы тестировщика. Тестировщики предоставляют информацию о качестве программного продукта, поэтому очень важно передавать эту информацию точно, чтобы заинтересованные лица принимали верные решения. Человек может начать работать тестировщиком, имея слабые технические навыки, но если он силен в коммуникации и может внятно донести свою мысль – это куда важнее. Тестировщики должны использовать правильные слова и верно строить фразы, чтобы они не были противоречивыми – так снижается риск недопонимания. То, что вы хотели сказать – необязательно то, что вы в итоге сказали, и часто люди делают допущения и в результате предпринимают неверные действия, потому что коммуникация была плохой или недостаточной. Нам нужно регулярно общаться с людьми, играющими различные роли, находящимися на разных позициях и обладающих разным объемом знаний о продукте.
Письменная коммуникация важна не меньше устной. Создать блестяще написанную, обширную документацию, которая никому не нужна, легче легкого. Мы должны убедиться, что используем правильный способ общения в каждом конкретном случае, будь то человек, процесс или проект. Потенциальная бесконечность По сути, мы всегда тестируем только выборку. Каждый нетривиальный продукт обладает непредставимым количеством параметров с большим количеством возможных значений. Откуда вы знаете, что тестируете важные значения? Мы не можем протестировать все. Часть нашей работы – принятие решений о том, что тестировать, понимание последствий того, что будет протестировано только это, и способность обосновать свой выбор. Из чего тестирование не состоитПростота О тестировании часто думают как о чем-то, чем может заниматься любой. Возможно, в какой-то степени это правдиво – любой может исследовать продукт, задавать вопросы о нем, прогнать пошагово тест-кейс или проверить, соответствует ли продукт списку требований. Но чтобы делать это хорошо и систематически, нужен настоящий навык. Нам часто говорят «пишите кейсы так, чтобы их мог прогнать любой дурак», и из-за этого создается ложное впечатление, что тестировать очень просто. Мы тупо пишем тесты согласно критериям приемки, не так ли? Но тестировщики, тестирующие свободным поиском, знают, что это не так. Даже проверки – не такое-то простое дело. Мы принимаем непростые решения, где нужны эти проверки, и какие из них следует автоматизировать. Эти решения требуют понимания фреймворков автоматизации, навыка программирования, знания, как работает API, и владения инструментами вроде Selenium. Резюмируя, мы должны разбираться в приличном наборе технологий. Помимо этого, нам нужно знать, что нужно автоматизировать, а к чему автотесты подпускать нельзя. Автоматизируемость «Ручные тестировщики нам больше не нужны – мы можем автоматизировать все!» Все мы видели те или иные вариации этой фразы в Твиттере, на форумах и в статьях. Тестирование – это исследовательская, детективная деятельность, и ее невозможно заменить автоматизированными проверками. Компьютер технически не способен исследовать продукт так, как это делает человек. Мы можем автоматизировать те или иные проверки, но компьютер и человек будут прогонять их по-разному. Живой человек заметит многое из того, на что никогда не обратит внимание машина, и прислушается к своему ощущению «тут что-то не так» – и, соответственно, даст обратную связь не только по конкретной проверке, но и по всему подмеченному в процессе. Компьютер сделает только то, что ему сказано сделать. Автоматизированные проверки очень ценны для тест-стратегии, но на данный момент неспособны заменить живых тестировщиков, потому что люди и машины занимаются принципиально разными вещами. Тестировщики используют инструменты, в том числе автотесты, для поддержки своей работы. Специальные инструменты помогают нам генерировать данные, автоматизировать рутины, анализировать результаты тестов. Ими нужно владеть, чтобы облегчить себе жизнь, а не с целью заменить ручной труд полностью. Повышение качества Тестировщики не делают ничего, что бы напрямую улучшало качество продукта. Прогоняя тест, мы никак не влияем на код – следовательно, качество ПО остается неизменным. Только после того, как разработчики исправляют баги, качество продукта может измениться. Мы не можем «втестировать» качество в продукт. Тестирование – не единственная область разработки ПО, принимающая во внимание качество продукта. За ним нужно следить на всех стадиях жизненного цикла, и за него отвечают все участники команды разработки. Тестировщики могут использовать свои специфические навыки для сотрудничества с коллегами, но за качество отвечаем не только мы – это головная боль всей команды! Ни тестировщики, ни разработчики, правящие баги, не могут в результате сделать вывод, что качество продукта улучшилось. Мы не можем протестировать все, поэтому всегда вероятны сценарии, которые мы не проверяли, таящие в себе баги. Качество может ухудшиться из-за изменений или чего-то, неизвестного нам – мы даже не подозреваем, что у нас есть проблемы, пока не произойдет нечто, вскрывающее их. И даже если тестировщики могут уверенно сказать, что продукт готов к релизу, конечные пользователи могут его забраковать – например, из-за криво составленных требований. Все зависит от точки зрения. Качество определяется как «ценность для человека, чье мнение значимо». Его трудно измерить, и поэтому с определенностью заявить, что тестирование на каком бы то ни было этапе улучшает качество продукта, довольно трудно, даже невозможно. Фиксированная, не требующая воображения деятельность, подчиняющаяся строгим правилам Самые интересные баги зачастую находятся при помощи исследовательского тестирования. Прогон одних и тех же тестов раз за разом вряд ли даст вам много новой интересной информации – и, на сердце руку положа, довольно скучно гонять их вручную. Не существует лучших практик тестирования, применимых в абсолютно любых проектах. Вы должны выяснить, что лучше всего работает в вашем контексте и в вашей области. Размышления над новыми креативными способами тестирования – очень увлекательная часть нашей работы. Способность экспериментировать, искать лучшие инструменты, изучать новые навыки и технологии, и делать то, что наилучшим образом подходит нашему проекту, помогает нам постоянно совершенствоваться и держать свои навыки в форме. Жизненно необходимо для успеха продукта Проект может быть вполне успешным и без тестировщиков – тому множество примеров. Однако даже в случае отсутствия тестировщиков как таковых тестирование все же кем-то выполняется на той или иной стадии жизненного цикла. Разработчики тестируют собственный код, а заказчики – требования. Конечный пользователь иногда тестирует продукт до релиза. Люди могут тестировать, даже не отдавая себе отчета, что они этим занимаются. Никогда не заканчивается Под бесконечностью тестирования понимается невозможность протестировать все и вся в приложении. Нет реалистичных способов протестировать все комбинации, действия пользователя, внешние условия, значения данных или пути через код. В этом плане тестирование, действительно, бесконечный процесс. Следует принять как данность, что всегда останется что-нибудь непротестированное. Большинство проектов жестко ограничены временем, бюджетом и ресурсами, и тестировщики должны укладываться в эти ограничения, тестируя максимально эффективно. Часть работы тестировщика – это принятие решений, что именно тестировать, и понимание последствий этих решений и связанных с нимирисков. Тестирование завершается, когда у менеджмента достаточно информации, помогающей принять решение, готов ли продукт к релизу. Тестирование – это многое, многое другое Я перечислила только некоторые аспекты того, что же такое тестирование. Эта статья могла бы быть значительно длиннее! Нет единого определения, что подразумевается под тестированием, а впихнуть в одно предложение все то, чем занимаются тестировщики, просто невозможно! Если поискать определение тестирования в Интернете, можно наткнуться на фразы вроде «поиск багов в приложениях» – но как мы уже выяснили, это не только и не столько поиск багов. Ссылки:
Обсудить на форуме |
ministryoftesting.com/lessons/so-what-is-software-testing
Мы должны мыслить критически, задавать сложные вопросы, рисковать, подмечать то, что на первый взгляд кажется несущественным, а при тщательном анализе оказывается важным и требующим дальнейшего изучения.6 простых шагов — Академия Яндекса
A/B-тестирование — это неотъемлемая часть процесса работы над продуктом. Это эксперимент, который позволяет сравнить две версии чего-либо, чтобы проверить гипотезы и определить, какая версия лучше. Должны ли кнопки быть черными или белыми, какая навигация лучше, какой порядок прохождения регистрации меньше всего отпугивает пользователей? Продуктовый дизайнер из Сан-Франциско Лиза Шу рассказывает о простой последовательности шагов, которые помогут провести базовое тестирование.
Кому нужно A/B-тестирование
- Продакт-менеджеры могут тестировать изменения ценовых моделей, направленные на повышение доходов, или оптимизацию части воронки продаж для увеличения конверсии.
- Маркетологи могут тестировать изображения, призывы к действию (call-to-action) или практически любые другие элементы маркетинговой кампании или рекламы с точки зрения улучшения метрик.
- Продуктовые дизайнеры могут тестировать дизайнерские решения (например, цвет кнопки оформления заказа) или использовать результаты тестирования для того, чтобы перед внедрением определить, будет ли удобно пользоваться новой функцией.
Вот шесть шагов, которые нужно пройти, чтобы провести тестирование. В некоторые из пунктов включены примеры тестирования страницы регистрации выдуманного стартапа.
1. Определите цели
Определите основные бизнес-задачи вашей компании и убедитесь, что цели A/B-тестирования с ними совпадают.
Пример: Допустим, вы менеджер продукта в «компании X» на стадии стартапа. Руководству нужно добиться роста количества пользователей. В частности, компания стремится к росту количества активных пользователей (метрика DAU), определяемых как среднее количество зарегистрированных пользователей сайта в день за последние 30 дней. Вы предполагаете, что этого можно добиться либо путем улучшения показателей удержания (процент пользователей, возвращающихся для повторного использования продукта), либо путем увеличения числа новых регистрирующихся пользователей.
В процессе исследования воронки вы замечаете, что 60% пользователей уходят до завершения регистрации. Это означает, что можно повысить количество регистраций, изменив страницу регистрации, что, в свою очередь, должно помочь увеличить количество активных пользователей.
2. Определите метрику
Затем вам нужно определить метрику, на которую вы будете смотреть, чтобы понять, является ли новая версия сайта более успешной, чем изначальная. Обычно в качестве такой метрики берут коэффициент конверсии, но можно выбрать и промежуточную метрику вроде показателя кликабельности (CTR).
Пример: В нашем примере в качестве метрики вы выбираете долю зарегистрированных пользователей (registration rate), определяемую как количество новых пользователей, которые регистрируются, поделенное на общее количество новых посетителей сайта.
3. Разработайте гипотезу
Затем нужно разработать гипотезу о том, что именно поменяется, и, соответственно, что вы хотите проверить. Нужно понять, каких результатов вы ожидаете и какие у них могут быть обоснования.
Пример: Допустим, на текущей странице регистрации есть баннер и форма регистрации. Есть несколько пунктов, которые вы можете протестировать: поля формы, позиционирование, размер текста, но баннер на главной странице визуально наиболее заметен, поэтому сначала надо узнать, увеличится ли доля регистраций, если изменить изображение на нём.
Общая гипотеза заключается в следующем: «Если изменить главную страницу регистрации, то больше новых пользователей будут регистрироваться внутри продукта, потому что новое изображение лучше передает его ценности».
Нужно определить две гипотезы, которые помогут понять, является ли наблюдаемая разница между версией A (изначальной) и версией B (новой, которую вы хотите проверить) случайностью или результатом изменений, которые вы произвели.
- Нулевая гипотеза предполагает, что результаты, А и В на самом деле не отличаются и что наблюдаемые различия случайны. Мы надеемся опровергнуть эту гипотезу.
- Альтернативная гипотеза — это гипотеза о том, что B отличается от A, и вы хотите сделать вывод об её истинности.
Решите, будет ли это односторонний или двусторонний тест. Односторонний тест позволяет обнаружить изменение в одном направлении, в то время как двусторонний тест позволяет обнаружить изменение по двум направлениям (как положительное, так и отрицательное).
4. Подготовьте эксперимент
Для того, чтобы тест выдавал корректные результаты сделайте следующее:
- Создайте новую версию (B), отражающую изменения, которые вы хотите протестировать.
- Определите контрольную и экспериментальную группы. Каких пользователей вы хотите протестировать: всех пользователей на всех платформах или только пользователей из одной страны? Определите группу испытуемых, отобрав их по типам пользователей, платформе, географическим показателям и т. п. Затем определите, какой процент исследуемой группы составляет контрольная группа (группа, видящая версию A), а какой процент — экспериментальная группа (группа, видящая версию B). Обычно эти группы одинакового размера.
- Убедитесь, что пользователи будут видеть версии A и B в случайном порядке. Это значит, у каждого пользователя будет равный шанс получить ту или иную версию.
- Определите уровень статистической значимости (α). Это уровень риска, который вы принимаете при ошибках первого рода (отклонение нулевой гипотезы, если она верна), обычно α = 0.05. Это означает, что в 5% случаев вы будете обнаруживать разницу между A и B, которая на самом деле обусловлена случайностью. Чем ниже выбранный вами уровень значимости, тем ниже риск того, что вы обнаружите разницу, вызванную случайностью.
- Определите минимальный размер выборки. Калькуляторы есть здесь и здесь, они рассчитывают размер выборки, необходимый для каждой версии. На размер выборки влияют разные параметры и ваши предпочтения. Наличие достаточно большого размера выборки важно для обеспечения статистически значимых результатов.
- Определите временные рамки. Возьмите общий размер выборки, необходимый вам для тестирования каждой версии, и разделите его на ваш ежедневный трафик, так вы получите количество дней, необходимое для проведения теста. Как правило, это одна или две недели.
Пример: На существующем сайте в разделе регистрации мы изменим главную страницу — это и будет нашей версией B. Мы решаем, что в эксперименте будут участвовать только новые пользователи, заходящие на страницу регистрации. Мы также обеспечиваем случайную выборку, то есть каждый пользователь будет иметь равные шансы получить A или B, распределенные случайным образом.
Важно определить временные рамки. Допустим, ежедневно на нашу страницу регистрации в среднем приходит трафик от 10 000 новых пользователей, это означает, что только 5000 пользователей могут увидеть каждую версию. Тогда минимальный размер выборки составляет около 100 000 просмотров каждой версии. 100 000/ 5000 = 20 дней — столько должен продлиться эксперимент.
5. Проведите эксперимент
Помните о важных шагах, которые необходимо выполнить:
- Обсудите параметры эксперимента с исполнителями.
- Выполните запрос на тестовой закрытой площадке, если она у вас есть. Это поможет проверить данные. Если ее нет, проверьте данные, полученные в первый день эксперимента.
- В самом начале проведения тестирования проверьте, действительно ли оно работает.
- И, наконец, не смотрите на результаты! Преждевременный просмотр результатов может испортить статистическую значимость. Почему? Читайте здесь.
6. Анализируйте результаты. Наконец-то самое интересное
Вам нужно получить данные и рассчитать значения выбранной ранее метрики успеха для обеих версий (A и B) и разницу между этими значениями. Если не было никакой разницы в целом, вы также можете сегментировать выборку по платформам, типам источников, географическим параметрам и т. п., если это применимо. Вы можете обнаружить, что версия B работает лучше или хуже для определенных сегментов.
Проверьте статистическую значимость. Статистическая теория, лежащая в основе этого подхода, объясняется здесь, но основная идея в том, чтобы выяснить, была ли разница в результатах между A и B связана с изменениями или это результат случайности или естественных изменений. Это определяется путем сравнения тестовых статистических данных (и полученного p-значения) с вашим уровнем значимости.
Если p-значение меньше уровня значимости, то можно отвергнуть нулевую гипотезу, имея доказательства для альтернативы.
Если p-значение больше или равно уровню значимости, мы не можем отвергнуть нулевую гипотезу о том, что A и B не отличаются друг от друга.
A/B-тестирование может дать следующие результаты:
- Контрольная версия, А выигрывает или между версиями нет разницы. Если исключить причины, которые могут привести к недействительному тестированию, то проигрыш новой версии может быть вызван, например, плохим сообщением и брендингом конкурентного предложения или плохим клиентским опытом.
В этом сценарии вы можете углубиться в данные или провести исследование пользователей, чтобы понять, почему новая версия не работает так, как ожидалось. Это, в свою очередь, поможет собрать информацию для следующих тестов.
- Версия B выигрывает. A/B-тест подтвердил вашу гипотезу о лучшей производительности версии B по сравнению с версией A. Отлично! Опубликовав результаты, вы можете провести эксперимент на всей аудитории и получить новые результаты.
Заключение
Независимо от того, был ли ваш тест успешным или нет, относитесь к каждому эксперименту как к возможности для обучения. Используйте то, чему вы научились, для выработки вашей следующей гипотезы. Вы можете, например, использовать предыдущий тест или сконцентрироваться на другой области, требующей оптимизации. Возможности бесконечны.
Тестирование – это не фаза
Каждый раз, когда кто-то говорит о «фазе тестирования», я прихожу в ужас. Худшим примером, который я недавно видел, была публикация в Agile группе, в которой был задан вопрос: «Сколько дней мы должны выделить для тестирования? Если нам требуется 10 дней на разработку, хватит ли нам 10 дней для тестирования? Или лучше 15?».
Я никого не осуждаю. Каждый с чего-то начинает и делает ошибки. Но на самом деле, нам нужно разобраться с тестированием раз и навсегда. Тестирование – не фаза, и каждый должен это понимать.
В Waterfall (Водопаде) тестирование было фазой
В старые недобрые времена Водопада тестирование было большой фазой. Никто не ничего не тестировал, пока не была завершена вся разработка. Задумайтесь об этом на мгновение: никто ничего не проверял, пока вся разработка не была «закончена». Здесь, конечно, есть два больших вопроса:
- Почему не провести тестирование до того, пока вся разработка не будет закончена? Почему не протестировать что-то сразу, как только появилась возможность начать это тестировать?
- Как узнать, что разработка «закончена»? Ведь на самом деле разработка не будет закончена, пока не будут выполнены все тесты.
В результате поэтапного подхода возникали огромные проблемы:
- тестировщики были не слишком загружены работой (помимо написания больших бесполезных документов) до тех пор, пока код не был «готов к тестированию»;
- передачи работы между фазами создавали зависимости;
- работы блокировались в ожидании одобрения;
- росли задержки сроков тестировщиками, проводившими к тому же ручное тестирование вместо автоматического;
- процветал «ад интеграции» и, как следствие, отсутствовало качество и целостность.
Поэтому в Agile тестирование не должно быть фазой
- Мы должны начинать тестировать как можно раньше и как можно чаще.
- Разработка не завершена, пока разработка и тестирование не будут завершены, потому что (вот ключевой момент) тестирование является частью разработки.
Agile в значительной степени позаимствовал идеи Lean Manufacturing (который многие идеи позаимствовал у Эдварда Деминга). В Lean качество встроено в систему, а не проверяется и не исправляется в конце. Таким образом, Agile разработка программного обеспечения рассматривает тестирование как основную и неотъемлемую часть разработки, а не как быструю «проверку», которая делается в последнюю минуту.
Тестирование перестает быть фазой и становится деятельностью, возникающей параллельно с разработкой.
Начинайте тестировать как можно раньше
Agile поощряет начинать тестирование как можно раньше. Если вы придерживаетесь подхода «разработка через тестирование» (Test Driven Development), что неплохо, то тестирование фактически начинается еще до того, как вы начнете писать код. Это потому, что TDD включает в себя написание и запуск тестов до того, как будет написан код для прохождения тестов. Таким образом, тестирование – одно из самых первых ваших действий, а не последнее.
Тестируйте как можно чаще
Тестирование должно проводиться очень часто, не один раз за спринт и, определенно, не один раз за релиз. Если вы работаете с маленькими партиями задач и вносите много небольших изменений (как и должно быть), то вам следует часто интегрироваться. В идеале один или несколько раз в день. И если вы часто интегрируетесь, вам нужно будет часто тестировать.
Непрерывная интеграция подразумевает внесение множества небольших изменений в кодовую базу, и для того, чтобы это произошло без риска разрушений, вам потребуется множество автоматических тестов. И вам нужно будет запускать это множество автоматических тестов очень часто. Модульные (unit) тесты занимают микросекунды, поэтому могут и должны выполняться сотни или тысячи раз в день. Интеграционные и приемочные тесты более длительные и нестабильные, поэтому их выполняют реже, но все равно не реже одного или даже нескольких раз в день.
Осторожно, мини-водопад!
Некоторые люди, особенно новички в Agile и Scrum, просто копируют все большие фазы Водопада, сокращают их и вставляют получившийся поэтапный мини-водопад в каждый спринт:
- Анализ
- Проектирование
- Разработка
- Тестирование
Не делай этого! Вы получите все «прелести» Водопада. Тестеры будут сидеть и ждать, пока все истории будут готовы к тестированию, вместо того, чтобы тестировать с самого начала. Качество откладывается на последнюю минуту, а не будет встроено с самого начала.
Спринты не имеют фаз
Внутри спринта нет фаз. Каждый день команда должна быть сфокусирована на том, чтобы перемещать небольшие кусочки работы по системе. Качество является фундаментальной частью этого процесса и никогда не должно рассматриваться как отдельная фаза.
Автор: Leon Tranter
Источник
Еще рекомендуем
что это, как и зачем проводить
А/В-тестирование – это маркетинговый инструмент, с помощью которого можно повысить эффективность работы сайта. Его также называют сплит-тестированием (Split Testing). Данный метод предназначен для улучшения конверсии, средней величины чека, времени пребывания на сайте, снижения процента отказов и т. д.
Суть А/В-тестирования заключается в сравнении контрольной страницы А (оригинал) и ее созданного аналога В (новая страница) с внесенными изменениями. Весь трафик делится между страницами А и В. Затем сравниваются основные показатели. Если новая версия оправдала ожидания и, например, конверсия увеличилась, тогда весь трафик направляют на страницу В.
В дальнейшем, когда будут тестироваться новые изменения, улучшенная версия будет выступать в роли контрольной страницы А.
При работе со сплит-тестированием важно грамотно оценивать метрики контрольной и новой страниц, а также правильно распределять трафик (не всегда его нужно делить 50 на 50). Кроме того, для корректной работы нужно исключить влияние сегментов друг на друга, снизить воздействие внешних и внутренних факторов. Тестирование необходимо проводить параллельно и в одинаковых условиях.
А/В-тестирование не всегда используется для улучшения посадочных страниц сайта. Его возможности позволяют провести тесты и в других местах.
Как провести А/В-тестирование
Рассмотрим пример. Пользователю необходимо повысить конверсию посадочной страницы, трафик на которую идет через контекстную рекламу. Сейчас данный показатель составляет 2,5 %. Чтобы добиться увеличения, пользователь хочет изменить дизайн страницы. Он создает новую страницу В и ведет туда часть трафика. В результате на странице с новым дизайном конверсия выросла до 3 % вместо планируемых 4 %. Чтобы увеличить конверсию еще больше, можно изменить текст на странице, например придумать новый призыв к действию. Теперь в роли контрольной страницы А будет выступать страница с новым дизайном. В данном примере аналогичным образом можно попробовать изменить сами объявления КР (заголовки, тексты и т. д.), поработать над их релевантностью, так как основной трафик поступает именно оттуда. При использовании А/В-тестирования важно получить объективные данные и статистику.
Что тестировать
А/В-тестирование – это прикладной метод. Он влияет на различные метрики, поэтому выбирать, что менять, нужно на основании поставленных целей и задач.
Чаще всего тестируются следующие компоненты страниц.
- Заголовки. Шрифт, цвет, расположение, содержание, их количество – все это влияет на удержание и привлечение внимания посетителя сайта. Порой одно лишь изменение шрифта заголовка помогает улучшить внешний вид всей страницы.
- Текст. Аналогично заголовкам. Текст должен быть читабельным и визуально приятным. Количество текста, его шрифт, цвет, расположение – все это имеет не меньшее значение, чем само содержание.
- Кнопки. Как правило, кнопки являются главным элементом, который привлекает внимание пользователей. Поэтому изменение внешнего вида, их расположение, оформление могут изменить показатели в лучшую сторону.
- Изображения. Используйте качественные и красивые изображения. Не важно, будь то фото товара или фоновая картинка лендинга. Даже мельчайший сдвиг картинки может полностью изменить визуальное восприятие.
- Дизайн страницы. Плохой дизайн зачастую оказывается тем фактором, который способствует большому числу отказов. Тестируйте новые макеты, шаблоны как всего сайта, так и его отдельных элементов. Ищите наиболее продуктивный вариант.
- Бизнес-предложения и цены. Тестировать можно не только внешний вид страницы. Создать новое бизнес-предложение иногда бывает эффективнее, чем кропотливо менять дизайн, тексты, кнопки и месяцами добиваться улучшения конверсии.
Это лишь наиболее часто тестирующиеся компоненты. На практике же изменениям подвергается все, что, по мнению руководителей, способно увеличить продажи.
Сервисы
Чтобы проводить сплит-тесты, маркетологи используют следующие сервисы:
- Content Experiments,
- Optimizely,
- ABTest.ru,
- RealRoi.ru,
- Visual Website Optimizer,
- Unbounce.
Какова скорость вашего широкополосного доступа
Почему результаты тестов могут отличаться от других тестов скорости?
Интернет-тесты производительности могут давать разные результаты по разным причинам. Приложение TestIT использует инструмент диагностики сети (NDT), разработанный Measurement Labs (MLabs) для измерения скорости подключения. Ниже перечислены три основные причины различных результатов тестов:
1. Различия в расположении тестовых серверов
Каждый тест производительности состоит из двух частей:
client: Это программное обеспечение, которое запускается на машине пользователя и показывает пользователю результаты его скорости.
сервер: Это компьютер в Интернете, к которому клиент подключается для выполнения теста .
Тест генерирует данные между клиентом и сервером и измеряет производительность между этими двумя точками. Расположение этих двух точек важно с точки зрения понимания результатов данного теста.
Если сервер расположен в собственной сети вашего интернет-провайдера (также известной как «последняя миля»), это называется «внутрисетевым» измерением.Этот подход позволяет вам узнать, как ваше интернет-соединение работает внутри сети внутри вашего интернет-провайдера, но он не обязательно отражает полный опыт использования Интернета, который почти всегда включает использование межсетевых подключений (соединений между сетями) для доступа к контенту. и сервисы, размещенные где-то за пределами вашего интернет-провайдера. Результаты тестирования внутри сети часто выше, чем результаты, полученные с помощью других методов, поскольку пройденное «расстояние» обычно короче, а сеть полностью контролируется одним провайдером (вашим интернет-провайдером).
«Вне сети» измерения происходят между вашим компьютером и сервером, расположенным за пределами сети вашего интернет-провайдера. Это означает, что трафик пересекает межсетевые границы и часто перемещается на большие расстояния. Тестирование вне сети часто дает результаты ниже, чем результаты тестирования в сети.
M-Lab всегда проводит измерения вне сети. Таким образом, M-Lab может измерять производительность от компьютеров тестеров до мест, где часто размещается популярный интернет-контент.Включая в тест межсетевые соединения, тестовые пользователи получают реальное представление о производительности, которую они могут ожидать при использовании Интернета.
2. Различия в методах тестирования
Различные тесты производительности Интернета измеряют разные вещи по-разному. Тест NDT M-Lab пытается передать как можно больше данных за десять секунд (как вверх, так и вниз), используя одно соединение с сервером M-Lab. Другие популярные тесты пытаются передать как можно больше данных одновременно через несколько подключений к своему серверу.Ни один из методов не является «правильным» или «неправильным», но использование одного потока с большей вероятностью поможет диагностировать проблемы в сети, чем использование нескольких потоков. Узнайте больше о методологии неразрушающего контроля M-Lab.
Все данные неразрушающего контроля, собранные M-Lab, общедоступны в визуализированной (графической), запрашиваемой и необработанной (неанализованной) формах.
3. Изменение сетевых условий и различных тестовых путей
Интернет постоянно меняется, и результаты тестов отражают это. Результаты теста, проведенного пять минут назад, могут сильно отличаться от результатов теста, проведенного двадцать минут назад.Это может быть вызвано другой маршрутизацией тестового трафика. Например, один тест может проходить по пути со сломанным маршрутизатором, а другой — нет. Тестовый запуск сегодня может быть направлен на тестовый сервер, расположенный дальше, чем тестовый запуск вчера. Кроме того, маршруты IPv4 и IPv6 могут иметь разные физические пути. Некоторые маршруты IPv6 могут быть туннелированы через IPv4, от клиента или в любой точке после клиента в зависимости от управления локальной сетью.
Короче говоря, запуск одного теста даст вам представление о сетевых условиях в данный момент по лучшему доступному на тот момент сетевому пути к конкретному серверу, координирующему тест.Но поскольку Интернет-маршрутизация и инфраструктура меняются динамически, регулярное тестирование и просмотр данных с течением времени — гораздо более надежные способы измерения репрезентативной производительности.
Как (и почему) проверить вашу бизнес-идею
- Тестирование вашей бизнес-идеи — ключ к тому, чтобы увидеть, является ли она жизнеспособной бизнес-моделью.
- Не торопитесь запускать продукт; без тщательного рассмотрения и планирования это может стать пустой тратой критических ресурсов в случае неудачи.
- Выполните эти восемь шагов, чтобы полностью проверить свою бизнес-идею и определить рынок для нее.
- Эта статья предназначена для начинающих предпринимателей, готовящихся к открытию нового бизнеса, которым необходимо проверить свою идею.
У вас есть идея для «следующего большого дела»? Вы можете думать, что ваша идея идеальна, но разумно проверить ее, прежде чем тратить время и деньги на разработку бизнеса или продукта, для которого нет рынка. Вот восемь шагов, которые помогут вам убедиться, что идея вашего продукта — это то, чего хочет мир, прежде чем вы ее запустите.
Важность тестирования бизнес-идеи
Тестирование бизнес-идеи имеет решающее значение для ее успеха.Если вы слепо предполагаете, что идея будет иметь большой успех, вы рискуете большим количеством времени, денег и других ресурсов, вложенных в ее запуск. Компании часто пропускают этот шаг, потому что спешат выпустить свой продукт. Они не создают бизнес-план или бизнес-модель на основе своего рыночного тестирования / исследования, продолжая свой бизнес-путь без дорожной карты. Кроме того, они не могут точно определить, кто их целевая аудитория. Пока вы не протестируете свою идею, вы не узнаете, кому она пригодится.Без этой информации ваш маркетинг может остаться незамеченным и ни к чему не приведет с идеей продукта, даже если она отличная.
Ключевой вывод: Тестирование вашей бизнес-идеи — необходимый предварительный шаг для определения вашего целевого рынка и уточнения вашей бизнес-идеи с учетом их реальных потребностей.
Шаги по тестированию бизнес-идеи
Вот восемь шагов по тестированию бизнес-идеи для определения ее ценностного предложения.
1. Создайте прототип или тестовую службу.
Несмотря на то, что вы в восторге от своей новой бизнес-идеи, вы можете подождать некоторое время, прежде чем тестировать ее, сказал Грег Айзенберг, венчурный капиталист и серийный предприниматель. «После того, как я записал кучу идей, я не люблю спешить с созданием бизнес-плана или набором команды», — сказал Айзенберг. «Мне нравится подождать несколько недель, чтобы увидеть, какие идеи мне действительно нравятся».
Изенберг сказал, что он движется вперед только в том случае, если у него есть жгучее чувство, что миру действительно нужна его идея.
«Как только я справлюсь с этим, лучший способ проверить бизнес-идею — это создать прототип и показать его людям, чтобы получить честную и достоверную обратную связь», — сказал он. [Ищете бизнес-идею? Посетите нашу страницу бизнес-идей.]
2. Создайте минимально жизнеспособный продукт.
Следование модели бережливого стартапа — отличный способ развивать свой бизнес или конкретный продукт. Самое главное, вы хотите создать минимально жизнеспособный продукт (MVP).
MVP — это «простейшая форма вашей идеи, которую вы можете продать как продукт», — сказал Эрик Райс, предприниматель из Кремниевой долины и автор книги The Lean Startup (Crown Business, 2011).Используя принципы бережливого производства и шести сигм, книга Райса рекомендует иметь версию продукта для тестирования и вывода на рынок на ранних этапах процесса разработки, чтобы любые поправки или изменения происходили в ответ на реальную обратную связь от целевой аудитории.
3. Запустите его группой критиков.
Когда у вас будет готов первый прототип или тестовая услуга, представьте ее потенциальным целевым клиентам.
«Вам следует поговорить [с] и / или опросить не менее 50 потенциальных клиентов, чтобы увидеть, идентифицируют ли они свою проблему так же, как и вы», — сказал Вейд Гилкрист, консультант по стартапам и ведущий TechStartRadio.com. «Другими словами, вам нужно выяснить, является ли это реальной проблемой для большей части вашего целевого рынка или только для некоторых».
Однако, чтобы по-настоящему проверить свою новую бизнес-идею, тщательно выберите 50 потенциальных клиентов или клиентов.
«Определите людей в этой цели, которые, как вы знаете, скептически и критически настроены», — сказал Чип Белл, основатель консалтинговой фирмы The Chip Bell Group. «Эти люди могут быть разгневанными покупателями от предыдущих встреч или друзьями, которые всегда придерживаются полупустой точки зрения.«
Bell посоветовал вручную выбрать вашу тестовую группу, а затем попросить этих людей выделить ваши идеи по отдельности.
4. Настройте ее в соответствии с вашим тестовым рынком.
Изенберг применил аналогичный подход к тестированию 5by, приложения для поиска видео в Интернете он разработал и с тех пор продал. Айзенберг и его команда ездили в университетские городки и демонстрировали макеты того, как будет выглядеть продукт. Они сочли отзывы студентов бесценными в доработке первоначальной идеи.
«Мы были способен быстро оценить людей…. были разочарованы тем, что не могли открыть приложение и просто найти лучшие интернет-видео по тому, что им было интересно, одним нажатием кнопки », — сказал он.
Изенберг понял, что, хотя его первоначальная бизнес-идея и макет были хорошим началом, они нуждались в доработке.
«Мы быстро поняли, что находимся в чем-то, а затем сосредоточились на создании продукта, сборе денег и т.д.», — сказал он.
5. Создайте тестовый веб-сайт с подключениями к социальным сетям
Как только о вашем продукте или бизнесе становится известно, целевому рынку требуется место, где можно получить дополнительную информацию о нем или показать его своим друзьям.Создание простого веб-сайта с целевой страницей специально для продукта и использование социальных сетей — отличный способ предоставить информацию и отслеживать, сколько людей интересуется тем, что вы продаете.
«Вы сможете определить, понравится ли эта идея, по количеству переходов по рекламе и количеству людей, заполнивших вашу форму», — сказал Гилкрист.
6. Составьте маркетинговый план и используйте его.
Вся подготовительная работа ничего не значит, если вы не выполняете достаточно действий, чтобы получить хорошую реакцию.«Когда у вас есть жизнеспособный продукт, вам нужно действовать в соответствии с интересами к нему», — сказал Райан Клементс, консультант предпринимателей по маркетингу и стратегии продаж.
«Работая со многими стартапами — как в качестве предпринимателя, так и в качестве советника для других — мне нравится использовать правило, которое я называю 100/1000», — написал Клементс в своем блоге на IvyExec. «Составьте список из 100 вещей, которые вы можете сделать для продвижения продукта на рынок, затем выполните этот список из 100 и в процессе поговорите о продукте с 1000 человек.»
Если вы сделаете это, у вас будут данные о вашем продукте, — сказал Клементс. — Вы будете знать, кто в нем заинтересован, какие маркетинговые стратегии сработали, а какие нет, и как вы можете улучшить», — все это бесценно. Он добавил, что нужно сделать несколько шагов, чтобы воплотить свою идею и бизнес в жизнь.
7. Примите экспериментальное мышление.
Слишком многие компании боятся потерпеть неудачу, поэтому не ставят себя в такую возможность. Часто это похоже либо на отказ от реализации новых идей, либо на неспособность должным образом протестировать идею продукта перед ее запуском.
Приняв экспериментальное мышление, вы с большей охотой будете совершать ошибки и проверять множество различных идей. Ваша бизнес-модель откроет более долгосрочную ценность, так как вы дадите шанс воплощению большему количеству идей. В этом случае неудача также рассматривается как успех, поскольку позволяет лучше понять, что работает, а что нет в этом постоянно меняющемся мире бизнеса.
8. Реализуйте дизайн-мышление.
Дизайн-мышление включает когнитивные, стратегические и практические процессы разработки новых идей или продуктов.Это помогает новаторам переосмыслить проблемы и найти лучшие, более творческие решения. Другими словами, это открывает двери для новых революционных открытий и изобретений.
Чтобы внедрить эту стратегию в свой бизнес, вы хотите следовать пяти стадиям дизайнерского мышления: сочувствие (исследование / понимание потребностей клиентов), определение (обозначение проблем и потребностей ваших клиентов), придумывание (поиск уникальных решений их проблем) ), прототип (создайте решения) и, самое главное, протестируйте (попробуйте сами).
Дополнительная отчетность Марси Мартин. Некоторые интервью с источниками были проведены для предыдущей версии этой статьи.
24 самых неожиданных A / B-теста всех времен
A / B-тестирование означает «Всегда будь тестирующим», верно? Должно!
Как только вы начнете тестировать различные элементы своих маркетинговых кампаний — от текстовых объявлений PPC до целевых страниц и строк темы электронной почты — вы поймете, что «передовые методы A / B-тестирования» — это лишь приблизительный ориентир. Вы никогда не знаете, что будет работать с вашей аудиторией, пока не проведете A / B-тестирование.
Мы были в шоке — в шоке!
Когда я слышу об A / B-тесте с удивительными результатами, мне всегда хочется закончить и все протестировать. Поэтому я попросил 24 маркетологов ответить на один вопрос:
Каков самый удивительный или захватывающий результат, которого вы когда-либо достигли в тесте A / B?
Вы можете прочитать их ответы ниже. Надеюсь, вы найдете эти тесты такими же веселыми и вдохновляющими, как и я! Вот игроки:
- Аарон Леви — Тест, где ваша форма находится на целевой странице
- AJ Kohn — Небольшие A / B-тесты могут иметь огромное влияние
- Брэд Геддес — Ваши A / B-тесты не обязательно должны быть идеальными
- Брэд Шорр — Тесты показывают, что небольшие изменения формулировок имеют значение
- Крис Костецки — Больше шагов (не меньше) увеличивают коэффициент конверсии
- Кристал О’Нил — Не стоит недооценивать ценность большой прессы!
- Фрэнсис Шовлин — Тестирование новой кнопки с призывом к действию
- Грег Мейерс — Длинная форма преобразования лучше короткой формы преобразования
- Джефф Аллен — целевая страница для ПК превосходит по эффективности целевую страницу для мобильных устройств
- Джо Кершбаум — Не поддавайтесь стремлению следовать передовым методам
- Джон Доэрти — A / B-тесты могут выявить настроения посетителей
- Джон Ли — Устаревший беспорядок целевой страницы побеждает «Идеальную» страницу
- Ken Lyons — Тестовые предложения выше vs.Ниже сгиба
- Ларри Ким — A / B-сплит-тест всех аспектов вашего бизнеса!
- Matthew Umbro — Кнопки для раздельного тестирования по цвету
- Megan Leap — бросьте вызов традиционным маркетинговым знаниям
- Мишель Морган — A / B-тестирование выдуманных слов!
- Оли Гарднер — Электронная почта A / B-тестирования против Твиты
- Перри Маршалл — Самые глупые тесты — самые неожиданные
- Райан Хили — Добавление приветствия в копию объявления
- Шон Квадлин — Тестирование AB для оптимизации коэффициента конверсии
- Shawn Livengood — Размеры кнопок целевой страницы тестирования AB
- Тодд Минц — Тестирование брендированных объявлений с динамической вставкой ключевых слов
- Tom Demers — A / B-тестирование небольших изменений для больших побед
Прочтите, чтобы узнать, что вам следует тестировать, и какие безумные результаты вы можете ожидать, когда это сделаете….
и , если у вас есть собственный удивительный результат A / B-тестирования, расскажите, пожалуйста, об этом в комментариях!
A / B-тест, где ваша форма находится на посадочной странице
Многие из лучших результатов AB-тестов, которые я получал за свою карьеру в цифровом маркетинге, были получены в результате тестирования вещей, которые не обязательно соответствуют лучшим практикам. Самый захватывающий результат, который я увидел в тесте A / B, получился при простом перемещении формы на целевой странице со стандартной правой стороны в центр LP.
(Перед слева, после справа. Изображения / цвета удалены для защиты клиента.)
Существующая целевая страница уже была достаточно хорошо оптимизирована и имела коэффициент конверсии около 11%. Внеся простое изменение и переместив форму в центр, мы смогли увеличить коэффициент конверсии почти на 50%. — до 16%. Неплохо для того, чтобы идти против течения!
Аарон Леви занимается цифровым маркетингом с 2007 года, проводя дни (и много ночей) в качестве менеджера по работе с клиентами PPC в SEER Interactive, поисковом агентстве из Филадельфии.Он подрабатывает подражателем пивовара / велосипедиста / звезды хоккея и пишет в Твиттере обо всем.
Небольшие A / B-тесты могут иметь серьезные последствия
Какого самого удивительного результата я добился с помощью A / B-тестирования? Еще в 2007 году я протестировал начальное использование заглавных букв в объявлениях Google Рекламы (ранее называвшихся Google AdWords) и добился повышения CTR на 53%.
Тест был простым. Я создал два точных объявления, кроме URL. В одном я использовал стандартный www.sitename.com, в то время как другой использовал начальные заглавные буквы и выглядел как www.SiteName.com. Я повторял этот тест несколько раз, и всегда показывал положительный подъем .
К сожалению, Google исключил этот тип отображения URL. Однако в то время он подтвердил, что небольшие изменения могут иметь огромное влияние, и заинтересовал меня тем, как пользователи «смотрят» на результаты поиска.
Эй Джей Кон — владелец компании Blind Five Year Old, занимающейся интернет-маркетингом в Сан-Франциско, специализирующейся на поиске. Опытный менеджер по маркетингу с успешным опытом работы на протяжении 20 лет, AJ сочетает глубокое понимание поискового маркетинга со страстью к стратегии продукта и итеративной разработке продукта, сочетая дизайн и пользовательский опыт с количественным анализом.Следуйте за ним в Twitter на @ajkohn.
Ваши A / B-тесты не обязательно должны быть идеальными
Я работал с клиентом, у которого была ужасная целевая страница. Он был плохо спроектирован, и вам нужно было нажать кнопку, чтобы перейти на ужасную страницу формы для преобразования. Я умолял их создать новую страницу и хотя бы разместить чистую форму на целевой странице. Они вернулись со страницей, которая все еще была некрасивой, и их ужасная форма была просто встроена в страницу.
Новая версия увеличила прибыль сайта на 76%.
Именно тогда мой перфекционистский мозг понял: не обязательно быть идеальным. Чтобы добиться лучших результатов, все, что вам нужно делать, лучше, чем вы есть сейчас.
Брэд Геддес является основателем Certified Knowledge , платформы для обучения и набора инструментов PPC. Он является автором Advanced Google AdWords и официального руководителя семинара Google AdWords . Вы можете следить за @bgTheory в Twitter, чтобы быть в курсе последних новостей отрасли.
A / B-тесты показывают, что небольшие изменения формулировок имеют значение
Что касается PPC-рекламы, мы никогда не перестаем удивляться тому, как небольшие изменения в акцентах могут привести к огромному увеличению количества переходов по ссылкам. Вот показательный пример с прошлой недели. Мы тестировали эти призывы к действию AB:
A. Получите скидку 10 долларов на первую покупку. Забронируйте онлайн сейчас!
B. Получите дополнительную скидку 10 долларов. Забронируйте онлайн сейчас.
CTR удвоился до с опцией… B. (Для справки, мои деньги были на A.)
Брэд Шорр — директор по контенту и социальным сетям в Straight North , агентстве Интернет-маркетинга с полным спектром услуг, базирующемся в Чикаго. Он часто пишет о SEO, копирайтинге и контент-маркетинге. Следуйте за ним в Twitter: @bradshorr .
ТестA / B показывает, что большее количество шагов (не меньше) дает более высокие коэффициенты конверсии
Самое удивительное, что я получил в результате A / B-теста, было, когда я тестировал 2 целевые страницы.Элемент управления представил параметры продукта и добавления в корзину вместо страницы, на которой этот продукт позиционировался, но находился на расстоянии одного клика от фактического продукта. Несмотря на дополнительный шаг и больший объем языка для прохождения, он существенно превзошел более прямой путь . У него был более высокий коэффициент конверсии (+ 18% при достижении статистической значимости 95%) и более высокий AOV. Это помогло нам определить, где мы привлекали трафик в процессе покупки, и в результате мы смогли использовать полученные данные, чтобы лучше позиционировать другие продукты перед продажей.
Крис Костецки работает в поисковой системе с 2006 года, а в маркетинге с 1997 года. Он создал продукт PPC для малого бизнеса, чтобы дополнить продукт каталога Yellow Page, и до своей нынешней должности работал менеджером PPC в агентстве, обслуживающем клиентов электронной коммерции. в качестве внутреннего поискового аналитика по телефону Keurig Inc . Подпишитесь на Chris в Twitter, чтобы быть в курсе последних тенденций в поисковом маркетинге, особенно каждый вторник с 12 до 1 p.м. EST во время #PPCChat . Все взгляды, которые он выражает, являются его собственными и не обязательно отражают взгляды каких-либо организаций, с которыми он связан.
Не недооценивайте ценность большой прессы!
Один из самых удивительных результатов, которые я видел при A / B-тестировании, был при тестировании рекламы. У нас был клиент, представленный на «Доброе утро, Америка» («GMA»), поэтому, естественно, мы хотели использовать авторитет и прессу такого шоу, как GMA. Мы решили сначала провести A / B-тестирование рекламы в наших брендированных кампаниях с лозунгом «Рекомендовано на Good Morning America» vs.наше обычное объявление со слоганом «Официальный сайт». Объявления со слоганом GMA получили высокие оценки по CTR и коэффициенту конверсии. Это неудивительно — мы ожидали таких результатов, учитывая авторитет и признание GMA.
На основе этого первоначального A / B-теста мы провели аналогичные тесты A / B-рекламы для наших небрендовых кампаний. Практически во всех тестах снова побеждали объявления с пометкой «Рекомендуемые в GMA». Опять же, не слишком удивительно.
Вот что удивительно. Сегмент GMA транслировался почти 3 года назад, и после раундов, раундов и раундов (вы понимаете) A / B-тестирования варианты объявлений, содержащие «Featured on GMA», продолжают оставаться наиболее эффективными.Вот пример недавних результатов по объявлению:
Мораль этой истории A / B-теста: Не стоит недооценивать ценность и долговечность отличной печатной машины !
Кристал (Андерсон) О’Нил — руководитель подразделения контекстной рекламы в цифровом агентстве SEER Interactive из Филадельфии. Она начала свою карьеру в контекстной рекламе в начале 2006 года и управляла международными учетными записями контекстной рекламы на различных платформах и в разных отраслях, с ежемесячным бюджетом от четырех до шестизначного.Вы можете подписаться на нее в Twitter: @CrystalA .
Протестируйте новую кнопку призыва к действию
Один из самых удивительных результатов, которых я когда-либо достиг с помощью A / B-тестирования, — это возможность повысить конверсию, просто протестировав новую кнопку с призывом к действию. Для этого клиента у нас не было ресурсов для создания и тестирования всех новых страниц. Мы решили попробовать разделить трафик между двумя разными кнопками.
Мы проводили AB-тест чуть более семи недель и в итоге смогли повысить коэффициент конверсии форм на 11%.
Мой совет: никогда не считайте тестирование мельчайших элементов . Вы можете легко увеличить конверсию и доход даже при ограниченных ресурсах.
Фрэнсис Шовлин находился в поиске почти 5 лет, последние 2 года в качестве менеджера по работе с клиентами PPC в команде SEER Interactive . Самопровозглашенный «мастер 70 характеров» также любит хорошее пиво и музыку. Вы можете следить за его случайными мыслями о жизни и индустрии платного поиска в Twitter: @fmshovlin .
Длинная форма преобразованияпревосходит короткую форму преобразования
Я видел много интересных результатов A / B-тестирования на протяжении многих лет, в том числе некоторые, которые противоречили бы многим очевидным методам оптимизации, которые традиционно творили чудеса. Однако был один случай, когда «чрезмерный контент» победил «удобство использования и ориентацию на конверсию». Я обратился к одному из моих клиентов по маркетингу PPC с просьбой создать новую целевую страницу, которая будет охватывать «гибридную модель», состоящую из наиболее важных аспектов продукта, который они продают.Это было на удивление трудно продать клиенту, который сказал мне, что, хотя он понимает стратегию, его аудитория предпочла бы прочитать десятки страниц, чем иметь все это в компактном, удобном для чтения, удобном для монетизации формате. .
Конечный результат: Новая целевая страница имела более высокий показатель отказов и более низкие конверсии по сравнению с существующей. Этот опыт преподал мне один урок. Продолжайте тестирование AB и слушайте своих клиентов !!!!
Грег Мейерс — основатель Afterclicks Interactive и автор SemGeek.com .
Целевая страницадля настольных ПК превосходит по эффективности целевую страницу для мобильных устройств
Поскольку я большой поклонник мобильной контекстной рекламы и со-ведущий предстоящего вебинара Hanapin / WordStream на мобильных устройствах, наиболее удивительными результатами A / B-теста стало то, что настольная версия целевой страницы значительно превзошла целевую версию для мобильных устройств. страница в месячном A / B-тесте. Версия для ПК преобразовала трафик в потенциальных клиентов примерно на 15%, в то время как мобильная страница — примерно на 11%.Это просто доказывает, что вам нужно все тестировать, и это распространяется на внедрение лучших практик.
Джефф Аллен работает в сфере интернет-маркетинга с мая 2000 года. Он руководил разработкой проприетарной платформы электронного маркетинга, управлял более 12 миллионами потенциальных клиентов, участвовал в двух слияниях, и его работа привела к созданию нескольких компаний. Продажа агентства за миллион долларов. Сейчас он работает по адресу Hanapin Marketing в качестве директора по работе с клиентами и является ведущим автором их блога PPCHero.com.
Не поддавайтесь стремлению следовать передовым методам
Со временем я узнал, что A / B-тестирование полно сюрпризов. Вы можете создать гипотезу, основанную на многолетнем опыте и сотнях успешных тестов, но результаты невозможно предсказать, особенно когда вовлечены люди (посетители веб-сайта). Мы работали с клиентом электронной коммерции, который разработал новую целевую страницу. Эта новая страница была великолепна, и мы были на 100% уверены, что она значительно увеличит коэффициент конверсии.Однако старая страница выиграла тест A-B. На этой старой странице была плохая графика, запутанный макет, маленькая и плохо написанная копия — и это лишь некоторые недостатки страницы.
Сначала мы хотели просто перейти на новую страницу. Вот насколько мы были уверены на новой странице. Мы были рады, что не сделали этого, потому что у нас не было бы такого замечательного (и разочаровывающего) опыта обучения.
Джозеф Кершбаум — вице-президент и управляющий партнер агентства Clix Marketing, занимающегося поисковой и социальной рекламой.Джозеф регулярно выступает на конференциях по поиску и рекламе, таких как SES и SMX. Его статьи об индустрии SEM появляются в его регулярной колонке Search Engine Watch, а также в его колонках в Website Magazine и Visibility Magazine. Джозеф является соавтором книги Wiley / Sybex «SEM с оплатой за клик: один час в день».
A / B-тесты могут выявить настроения посетителей
Самые удивительные результаты, которые я когда-либо получал от A / B-теста, были при тестировании воронки конверсии на сайте. У нас была мысль, что разрешение пользователям выходить из воронки приводит к значительному падению результатов, поэтому мы хотели посмотреть, поможет ли удаление навигации людям конвертировать.
На самом деле произошло то, что пользователей почувствовали себя в ловушке, и наш показатель отказов резко вырос! Итак, на самом деле, позволив людям свободно уходить от воронки, у нас был более высокий коэффициент конверсии, чем когда мы их ограничивали! Противоинтуитивно, правда?
Джон Доэрти — руководитель офиса и старший консультант по SEO в Distilled New York City . Имея опыт написания технических статей и веб-разработки, он любит все технические и увлекательные вещи, но также является писателем и любит вести блоги на различных отраслевых сайтах, таких как Distilled, SEOmoz и на своем собственном SEO-сайте .В свободное время он катается на велосипеде по Бруклину, лазит по скалам, фотографирует и постоянно находится в поисках нового микроварен. Найдите его в Твиттере: @dohertyjf .
Ужасный, устаревший беспорядок на целевой странице побеждает в A / B-тесте над идеальной страницей
У нас есть клиент, который в течение последних нескольких лет сотрудничал с одним из наиболее авторитетных агентств по оптимизации целевых страниц. Для одного из проектов целевая страница, которая нуждалась в обновлении, была действительно плохой.Мы говорим об устаревших, плохих призывах к действию и настоящей неразберихе. Агентство по оптимизации вернулось с красивой целевой страницей, которая попала в нужное место с точки зрения дизайна, ориентированного на конверсию. Мы сравниваем две страницы друг с другом в A / B-тесте. Ужасная страница против идеальной страницы. Давид против Голиафа. Какая страница выиграла A / B-тест? Ужасный, устаревший беспорядок на целевой странице. Через несколько месяцев мы снова попробовали тест с теми же результатами.
Мораль истории? Инстинкт интуиции в этой ситуации заключался в том, чтобы просто перенести все наши объявления на новую целевую страницу без тестирования A-B.Рад, что мы этого не сделали! Хотя мы никогда точно не понимали, почему нежелательная целевая страница была победителем, это открыло мне глаза на тот факт, что вы ВСЕГДА должны тестировать — просто для уверенности.
Джон Ли — директор по обслуживанию клиентов в Clix Marketing , SEM-агентстве, и частый блогер и докладчик по всем вопросам PPC, медийной рекламы и рекламы в социальных сетях.
Предложения A / B-тестирования в конце продажи Копия по сравнению с предложением над сгибом
Один из самых удивительно успешных, но потрясающе простых результатов, которые я когда-либо видел с тестированием AB, произошел несколько лет назад, когда мы взяли то же самое предложение / CTA, которое было в конце рекламной копии на целевой странице SEO и повторил это снова над сгибом, чуть ниже вступительного абзаца. Тест AB показал увеличение коэффициента конверсии более чем на 400%. Логика эксперимента заключалась в том, что мы немедленно прерывали поток пользователя, когда он читал копию целевой страницы — которая долгое время была структурирована как актив органического трафика — и давали им возможность конвертировать раньше, а не позже. . До внесения изменения я понятия не имел, что оно будет таким же успешным, поскольку оно шло вразрез с тем, что я думал о создании качественной органической целевой страницы.Прерывание потока, даже до того, как было дано убедительное обоснование преимуществ и УТП, и повторение предложений в то время казались несколько нелогичными и деспотичными. Но тогда именно поэтому мы проводим A / B-тестирование, верно? Мы смогли воспроизвести результаты и на других страницах сайта, что только укрепило практику. Мораль истории: если пользователи готовы к конверсии, не заставляйте их ждать, потому что вы можете их потерять. Вместо этого попробуйте дать им несколько вариантов конвертации на странице.
Кен Лайонс является соучредителем компании MeasuredSEM.
Сплит-тестA / B — все аспекты вашего бизнеса!
Ооо. Мои любимые A / B-тесты. С чего начать. Их слишком много, чтобы просто выбрать один, поэтому мне придется поделиться тремя! (Могу я поделиться тремя?) Это все примеры видов A / B-тестов, о которых вы говорите, а ?! что? -это-не-может-быть-правильным-бегать-тест-дольше !! — что-то вроде A / B-теста. Хорошо, вот они в произвольном порядке:
- ЭКСТРАПОЛОГИЧЕСКИЙ А / Б ТЕСТ СОДЕРЖАНИЯ SEO: Будучи специалистом по поисковой оптимизации, я часто пытаюсь вставить много полезной информации на наши веб-страницы.Зачем говорить одним предложением, а можно сказать тремя абзацами, верно! Например, взгляните на мое бесплатное приложение AdWords Grader и прокрутите страницу вниз — вы увидите множество содержания под формой регистрации. Некоторые маркетологи из WordStream, которые очень хорошо разбираются в эстетике дизайна, пользовательском опыте и т. Д., Обнаружили, что моя контентная стратегия выглядит совершенно странно. Итак, мы протестировали удаление всего постороннего содержимого часто задаваемых вопросов, которое появляется в нижней части страницы, чтобы увидеть, как это повлияло на коэффициент конверсии при регистрации.Выиграл вариант, который содержал FAQ из 2000 слов в нижней части страницы. Мы были АБСОЛЮТНО НАПОЛЬНЫМИ.
- EXTRA SECURE LOGIN AB TEST: Говоря об AdWords Grader, этот инструмент работает так: вы просто входите в свою учетную запись Google Рекламы, и мы анализируем эффективность вашей учетной записи Google Рекламы и предоставляем вам полезную табель успеваемости, в которой показаны области силы, а также области, в которых вы можете улучшить. Недавно мы обновили механизм входа в учетную запись, чтобы использовать недавно выпущенный сверхсверхбезопасный механизм аутентификации учетных записей Google Рекламы OAUTH, полагая, что мы будем оценивать больше учетных записей Google Рекламы.Но тест A / B не прошел. Новая сверхзащищенная аутентификация Google Рекламы на основе OAUTH показала довольно плохую работу (возможно, потому, что она добавляла шаги в процесс регистрации), поэтому в итоге мы вернулись к обычному безопасному входу в Google Рекламу.
- ПРОДОЛЖИТЕЛЬНОСТЬ ИСПЫТАНИЯ ПРОДУКТА AB TEST: Моя компания продает программное обеспечение для управления PPC. Вы можете подписаться на бесплатную 7-дневную пробную версию. Мы получили несколько жалоб на то, что 7 дней недостаточно, чтобы проверить это. Поэтому мы продлили испытания на разную продолжительность, например, на 14 дней, 30 дней и т. Д.Мы измерили скорость подключения потенциальных клиентов — процент квалифицированных потенциальных клиентов, с которыми наша торговая организация может заказать демонстрацию, — и обнаружили, что скорость подключения фактически упала. Итак, мы вернулись к 7-дневной пробной модели. Может быть, они сочли длительное испытание подавляющим?
Имейте в виду, что я не говорю, что вам следует применять какие-либо из вышеперечисленных результатов теста AB для своего бизнеса. То, что сработало для нас, скорее всего, не то же самое, что работает для вашей организации.Ключ здесь — быть непредубежденным и позволить данным указывать вам, что делать, в отличие от того, чтобы слушать некоторых самопровозглашенных фальшивых гуру (или, в некоторых случаях, даже ваших потенциальных клиентов), которые говорят, что что-то должно быть сделано определенным образом. способ!
Ларри Ким — основатель и технический директор WordStream , Inc., провайдер 20-минутной рабочей недели PPC и WordStream Advisor , отмеченной наградами платформы для управления контекстной рекламы .Вы можете подписаться на него в Google+ и Twitter .
Кнопки раздельного тестирования по цвету
Мы создали кампанию ремаркетинга, нацеленную на потерянные продажи (те, кто бросил корзину покупок). Мы разработали два разных набора объявлений, которые в основном были одинаковыми. Все, включая шрифт, предложение и изображения, мы все идентичны. Единственное отличие заключалось в цвете кнопки «Купить сейчас». В одном наборе объявлений использовалась серая кнопка, а в другом — ярко-зеленая.Мы равномерно чередовали объявления в течение двух недель и были очень довольны результатами. Набор объявлений с зеленой кнопкой преобразован в три раза быстрее, чем объявлений с серой кнопкой. Кроме того, CTR объявлений с зеленой кнопкой были значительно выше, чем у объявлений с серой кнопкой. Зеленый цвет позволил рекламе выделяться больше, что позволило большему количеству потерянных продаж увидеть наше выгодное предложение. Идея выделяться в контекстно-медийной сети была полностью подтверждена в этом тесте.
Мэтью Амбро — директор по платному поиску по телефону Exclusive Concepts .Он работает в индустрии контекстной рекламы с 2007 года, работая с более чем 100 клиентами в различных отраслях, чтобы добиться прибыльной рентабельности инвестиций и улучшить привлечение потенциальных клиентов. Мэтью также является основателем PPC Chat, еженедельного чата в Twitter, где специалисты отрасли обсуждают, анализируют и обсуждают различные темы PPC с использованием хэштега #ppcchat.
Бросьте вызов традиционной маркетинговой мудрости
Один из самых удивительных результатов A / B-тестирования, который я видел, — это когда целевая страница с копией, ориентированной на выгоду, проигрывается целевой странице с копией, ориентированной на продукт.В тестах, которые я проводил, преимущества почти всегда превосходят возможности . И, как все мы знаем, сообщение, ориентированное на выгоду, является важнейшим элементом успешного маркетинга. Тем не менее, в этой кампании посетители на самом деле хотели, чтобы узнал об особенностях продаваемого нами продукта. Таким образом, в зависимости от вашей целевой аудитории, потока трафика, сообщения вашей рекламы, вашего продукта и т. Д. может действительно иметь смысл сосредоточиться на функциях, а не на преимуществах . Но вы не узнаете этого, пока не протестируете.(Если вам интересно, нашим следующим тестом были функции по сравнению с комбинированными преимуществами / функциями, и победил новый тест. A / B-тестирование FTW!)
Меган Лип отвечает за маркетинг и контент в Институте интернет-маркетинга , самом надежном источнике обучения и тренингов по цифровому маркетингу. Она является признанным экспертом в социальных сетях и контент-маркетинге, и ее работа была представлена в The New York Times, Entrepreneur Magazine, SmartBrief и других. Ранее она работала менеджером по интернет-маркетингу в MarketingProfs, где руководила их инициативами в области социальных сетей и оптимизации конверсии, и Ion Interactive, где она с нуля создавала их присутствие в социальных сетях.Она также консультировалась с ведущими брендами по вопросам стратегии в социальных сетях и управления кампаниями. Следуйте за ней в Twitter @meganleap
слов для теста A / B!
Мой самый удивительный тест AB не был результатом очень творческой стратегии. В основном это произошло из-за разочарования и упрямства. Изменение в маркетинговых законах для одного из моих клиентов, генерирующих лиды, сделало для нас незаконным использование слова «Применить» в тексте объявления, потому что на этом этапе клиенты технически не подавали заявку.В течение месяца или около того я пытался найти синоним «Применить», который работал бы почти так же хорошо, и желая украдкой вернуться к «Применить», , я решил придумать слово . Так родился PreApply. И да, я использовал эти заглавные буквы. Как ни странно, CTR и коэффициент конверсии увеличились на 27% и 11% соответственно, а цена за конверсию снизилась на 8%. Я не уверен, чувствовали ли клиенты, что они делают первый шаг поменьше, или был какой-то другой привлекательный фактор, но это сработало. В конце концов, изменение закона о рекламе фактически привело к повышению производительности и счастливому клиенту.
Мишель Морган — специалист по контекстной рекламе в Clix Marketing. Следуйте за ней в Twitter: @michellemsem.
Электронная почта для A / B-тестирования и твиты
Один из самых забавных и удивительных A / B-тестов, которые мы провели, заключался в том, чтобы предложить электронную книгу в обмен на адрес электронной почты или твит (при разделении трафика 50/50). Это был двойной тест: разделив его таким образом, мы получили потенциальных клиентов с одной страницы и продолжили вирусную экспозицию с другой (твиты отправляли людей обратно на целевую страницу, где они могли получить электронную книгу и повторить цикл).
Электронная версия конвертирована на 22% против 18% для платной версии в твиттере. Спрашивая людей с помощью встроенного опроса, какой механизм они предпочитают, 45% ответили по электронной почте, что немного сбило меня с толку, когда электронная почта выиграла тест AB.
Но это не самое интересное.
Мы решили провести третий тест, на котором у нас была одна страница с теми же двумя двумя вариантами, чтобы мы могли увидеть, как соотносятся числа, когда у людей действительно есть выбор. Несмотря на близкие результаты как в опросе, так и в первоначальном тесте A-B, результаты финального теста были шокирующими.
Результат: В новом тесте 85% людей решили указать свой адрес электронной почты.
После дальнейшего анализа мы также заметили, что люди писали твиты, а затем сразу же удаляли их из своих потоков. Вероятно, это потому, что это личный кондиционер, и они не хотят делиться ссылками на бизнес.
Извлеченный урок: Никогда не предполагайте, что даже ваши первоначальные результаты теста верны. Продолжайте пробовать новые гипотезы, пока не узнаете правду.
Оли Гарднер — соучредитель и креативный директор Unbounce, платформы DIY Landing Page.Он самоуверенный писатель, в первую очередь о целевых страницах и оптимизации коэффициента конверсии. Вы должны подписаться на него в Твиттере: @OliGardner.
Самые глупые тесты — самые неожиданные
Самым удивительным для меня в сплит-тестировании A / B было то, что я легко могу получить 10-кратный результат, делая «глупые» вещи. Например:
Единственное отличие — это реверсирование линии 2 и линии 3, вот и все.
Возможно, никто никогда не узнает точную причину, но моя теория такова, что во втором объявлении сначала ставится выгода, а не форма, в которой вы ее получаете.Для меня это имеет большой смысл.
Вот еще один пример:
Как написать книгу, быстро
14 дней от начала до конца
Уникальная пошаговая программа
Write-A-Book-Faster.com
4,40% CTR
Как быстро написать книгу
14 дней от начала до конца
Уникальная, пошаговая программа
Write-A-Book-Faster.com
4,12% CTR
Вы можете отличить эти два объявления? Эта пара рекламных объявлений Google показывает, как даже запятых между словами имеют ощутимое значение для вашей прибыли.Фактически разница составляет около 8%, что в данном конкретном примере, вероятно, составляет около 500 долларов в год.
Это имеет значение. Зачем гадать, когда можно проверить?
Чикагская компания Perry Marshall, Perry S. Marshall & Associates, консультирует как онлайн-компании, так и обычные компании по вопросам привлечения потенциальных клиентов, веб-трафика и максимизации рекламных результатов. Он один из самых востребованных консультантов по маркетингу в мире, и его работа упоминается в десятках влиятельных книг по маркетингу.Он опубликовал тысячи статей по продажам, маркетингу и технологиям, а также книги, в том числе The Ultimate Guide to Google AdWords (Entrepreneur Press, 3-е издание 2012 г.), самую популярную в мире книгу о рекламе Google, и The Ultimate Руководство по рекламе в Facebook (Entrepreneur Press, 2011). Читайте наше интервью с Перри Маршаллом здесь .
Добавление приветствия в копию объявления
Я всегда слышал, что приветствие в коммерческом сообщении может иметь большое влияние на конверсии, поэтому я решил провести A / B-тестирование на одной из моих собственных страниц продаж.Тест A B был очень простым: одна версия включала приветствие «Дорогой друг», а другая — нет.
Я ожидал небольшой разницы между двумя версиями, но не ожидал такого большого результата, как получил. Версия без «Дорогой друг» конвертировала на 28,2% лучше , чем исходная версия с приветствием.
Райан Хили — копирайтер прямого отклика. С 2002 года он работал с множеством клиентов, включая Алекса Мандоссяна, Терри Дина и Pulte Homes.Он ведет популярный блог о копирайтинге, росте бизнеса и создании продуктов .
A / B-тестирование для оптимизации коэффициента конверсии
Самый удивительный результат, с которым я когда-либо сталкивался в тесте A / B, был, когда я выполнял оптимизацию коэффициента конверсии. В то же время это был один из наименее впечатляющих результатов. Мы создали ряд различных целевых страниц для контекстной рекламы, которые имели разную компоновку: новые изображения, встроенный видеоконтент, новые заголовки, разные цвета шрифта и т. Д. Контроль выиграл все эксперименты. Мы создавали новый интересный контент, и он каждый раз вытеснялся базовой страницей, которую мы так отчаянно пытались проверить, не существует. Эту ситуацию можно описать любым количеством народных высказываний («Не сломано, не чини» сразу приходит на ум, но я уверен, что есть и другие, которые не менее применимы). Страница такая неинтересная, но надежная, как белый хлеб. На днях я смогу найти другого победителя, и мне придется обновить этот пост, рассказывая вам все о моей захватывающей целевой странице в стиле азиаго-фокачча.
Шон Квадлин — менеджер по работе с клиентами в Hanapin Marketing и автор в PPCHero.com . В настоящее время он управляет шестизначными ежемесячными расходами, в основном сосредоточенными на привлечении потенциальных клиентов для предприятий, ориентированных на потребителей. Вы можете найти его в Twitter @SeanQuadlin или провести нерабочее время в компании своего любимого TiVo.
Размеры кнопок целевой страницы A / B-тестирования
Самый удивительный результат, который я когда-либо видел в тесте A / B, связан с тестом целевой страницы, который я сделал для сайта торговой площадки, который измерял регистрацию новых участников как событие их конверсии.Все целевые страницы PPC были вручную закодированы и в основном служили входной страницей для процесса регистрации, обслуживая некоторые основные пункты о преимуществах услуги, некоторые соответствующие фотографии и кнопку «Начать работу» со ссылкой на страницу регистрации. Мы провели много тестов с текстовым содержимым и изображениями, и ничто не сдвинуло циферблат. Затем мы увеличили кнопку и увидели огромный подъем. Итак, мы сделали кнопку еще больше. Очередной успех! Мы шутили, что если мы будем продолжать в том же духе, то наша целевая страница превратится в гигантскую кнопку регистрации, на которой больше ничего не будет.
Самым удивительным в этом тесте AB было влияние макета страницы на конверсию. Мы AB протестировали множество различных предложений, формулировок и цветов макета, но безрезультатно. А затем мы сделали супер-очевидным, каким должен быть следующий шаг для завершения преобразования. Это урок, который я применил к будущему тестированию целевой страницы. Всегда убедитесь, что ваш пользователь знает, какой следующий шаг в процессе конверсии. Сделайте его более ясным, чем вы думаете, и вы увидите хорошие результаты.
Шон Ливенгуд — менеджер по интернет-маркетингу для BuildASign.com и автор блога о PPC PPC Without Pity . В своей роли менеджера по интернет-маркетингу Шон отвечает за разработку общей стратегии онлайн-маркетинга для нескольких брендов и микросайтов BuildASign.com, управление его PPC, SEO, социальными сетями, электронной почтой и каналами аффилированного маркетинга, а также поддержание и улучшение всей веб-аналитики. платформы.
Тестирование брендированных объявлений с динамической вставкой ключевых слов
В конкретном аккаунте PPC у меня была одна кампания, ориентированная на сотни брендов в вертикали продавца (для сайта, где метрикой конверсии была регистрация лидогенерации).
В заголовке объявления говорилось что-то вроде:
Скидка 50% на виджеты.
Мне не разрешалось использовать названия брендов в тексте объявления.
Урожайность кампании была настолько низкой, что я почти не видел ее.
Мы решили пройти тест A B, используя названия брендов в заголовке.
Поскольку в кампании участвовало так много брендов, я подумал, что самым быстрым способом проверить доказательство концепции было изменить заголовок для многих сотен групп объявлений на:
Скидка 50% на {KeyWord: Brand}.
В то время бюджет этой кампании практически не ограничивался до тех пор, пока я соответствовал определенным показателям CPA.
За ночь эта кампания произвела так много конверсий, что я подумал, что что-то сломалось в Google Рекламе. Кампания выросла с почти нуля до самой высокой в аккаунте примерно в 4-5 раз.
В конечном итоге мне не пришлось тратить время на настройку заголовков объявлений… в этом не было необходимости 🙂
Тодд Минц, который работает в PPC Associates с марта 2011 года, имеет более чем 10-летний опыт работы в поисковом маркетинге и использует Google Рекламу с самого начала. Он также очень заметен в пространстве социальных сетей SEM и является куратором / участником в MarketingLand .Он был одним из основателей SEMpdx (Портлендская группа поискового маркетинга), в настоящее время является членом совета директоров и регулярно пишет в их блогах.
A / B Тестирование небольших изменений для больших побед
В большинстве случаев я вижу, что более крупные структурные изменения на странице приводят к самым большим выигрышам, поэтому, когда относительно небольшая настройка дает большой подъем в конверсии, я всегда нахожу это действительно удивительным и интересным, особенно когда это побеждает более драматический вариант.
Ниже приведены некоторые грубые каркасы проведенного нами теста AB. Сначала мы увидели начальную страницу управления, которую настроил клиент, и узнали, что помимо значков доверия (как видно в журналах, ассоциациях и т. Д.) Под формой, было несколько других, которые, как мы думали, могут передавать даже больше доверия и авторитета. У клиента было относительно новое / неизвестное предложение, поэтому мы думали, что действительно загрузка символов доверия, как только посетитель достигнет страницы, поможет с конверсией, и хотели интегрировать дополнительные символы на страницу.
Сначала мы создали вариант А, в котором использовались дополнительные символы доверия над сгибом в сочетании с заявлением о выгодах, и был удален «выстрел героя», который был на его месте (который, похоже, мало что давал посетителю).
Вариант A потерял на несколько процентных пунктов по сравнению с существующей целевой страницей.
Мы по-прежнему думали, что дополнительные значки доверия могут улучшить ситуацию, если они будут реализованы должным образом, поэтому мы создали вариант B, который сохранял снимок героя выше сгиба, и вместо этого включил новые значки доверия в расширенный раздел доверия чуть ниже формы.Мы также реорганизовали значки доверия, чтобы в этом разделе были более заметны новые, более весомые значки.
Вариант B, где мы просто добавляли несколько новых значков в раздел страницы, на котором уже были некоторые из них, выиграл с 367%! Мы были удивлены результатом, но также и степенью, в которой небольшая настройка повлияла на конверсию, в то время как довольно существенное изменение страницы было не только потеряно, но и потеряно с очень небольшой разницей.
Том Демерс — соучредитель и управляющий партнер Консультации по поисковому маркетингу с оценкой SEM , специализированного агентства поискового маркетинга.G и связался с Томом напрямую по электронной почте на адрес tom на сайте measuresem.com или по телефону , подписавшись на него в Twitter .
Your Turn: Какой для вас самый неожиданный A / B-тест?
Что вы думаете о вышеуказанных A / B-тестах? Что было для вас самым неожиданным? Поделитесь своей лучшей историей A / B-тестирования в комментариях ниже!
БОЛЬШЕ: 5 советов по A / B-тестированию для компаний с ограниченным бюджетом
10 простых советов по улучшению пользовательского тестирования — Smashing Magazine
Об авторе
Ник Бабич — разработчик, технический энтузиаст и любитель UX.Последние 10 лет он проработал в индустрии программного обеспечения, специализируясь на … Больше о Ник ↬
(Это спонсируемый пост) . Тестирование — это фундаментальная часть работы UX-дизайнера и ключевая часть общего процесса UX-дизайна. Тестирование дает вдохновение, руководство и подтверждение, которые необходимы группам разработчиков для создания отличных продуктов. Вот почему самые эффективные команды делают тестирование привычкой. Юзабилити-тестирование предполагает наблюдение за пользователями, когда они используют продукт.Это поможет вам найти, где пользователи испытывают трудности и что им нравится. Есть два способа запустить тест на удобство использования:
(это спонсируемый пост) . Тестирование — это фундаментальная часть работы UX-дизайнера и ключевая часть общего процесса UX-дизайна. Тестирование дает вдохновение, руководство и подтверждение, которые необходимы группам разработчиков для создания отличных продуктов. Вот почему самые эффективные команды делают тестирование привычкой.
Юзабилити-тестирование включает наблюдение за пользователями, использующими продукт.Это поможет вам найти, где пользователи испытывают трудности и что им нравится. Есть два способа запустить тест юзабилити:
- Модерируемый, при котором модератор работает с участником теста.
- Немодерируемый, в котором участник теста завершает тест в одиночку.
Мы сосредоточимся на первом, но некоторые из упомянутых советов применимы к обоим типам тестирования.
1. Протестируйте как можно раньше
Чем раньше вы проведете тестирование, тем проще внести изменения и, следовательно, тем большее влияние окажет тестирование на качество продукта.Многие команды дизайнеров оправдываются так: «Продукт еще не готов. Мы проверим его позже », чтобы отложить тестирование. Конечно, все мы хотим, чтобы наша работа была безупречной, поэтому стараемся не показывать недоработанный дизайн. Но если вы работаете слишком долго без обратной связи, высока вероятность того, что вам придется внести существенные изменения после выпуска продукта на рынок. Это классическая ошибка: думать, что вы пользователь, и проектировать для себя. Если вы можете вкладывать энергию в обучение на ранних этапах и в первую очередь предотвращать возникновение проблем, вы сэкономите огромное количество времени позже.
Хорошая новость в том, что вам не нужно ждать, пока начнется тестирование прототипа с высокой точностью или полностью сформированного продукта. Фактически, вам следует как можно скорее начать тестирование идей. Вы можете тестировать макеты дизайна и прототипы с низкой точностью. Вам нужно будет задать контекст для теста и объяснить участникам, что от них требуется.
Пример прототипа с низкой точностью, созданного в Adobe XD.)2. Обозначьте свои цели
Перед тем, как начать тестирование удобства использования, четко сформулируйте свои цели.Подумайте, по какой причине вы хотите протестировать продукт. Чему вы пытаетесь научиться? Спросите себя: «Что мне нужно знать об этом сеансе?» Затем, как только вы это поймете, определите, по каким функциям и областям вы хотите получить обратную связь.
Вот несколько общих целей:
- Узнать, могут ли пользователи успешно выполнять указанные задачи (например, приобрести продукт, найти информацию),
- Определить, сколько времени требуется для выполнения определенных задач,
- Узнать, можно ли пользователи удовлетворены продуктом и определяют изменения, необходимые для повышения удовлетворенности.
3. Тщательно готовьте вопросы и задачи
Когда у вас есть цель, вы можете определить, какие задачи вам нужно будет проверить, чтобы ответить на ваши вопросы или проверить свои гипотезы и предположения. Цель состоит не в том, чтобы протестировать саму функциональность (это должно быть целью группы обеспечения качества), а в том, чтобы протестировать Experience с этой функциональностью.
Действующие задачи
При разработке задач делайте их реалистичными и действенными.Это могут быть определенные части продукта или прототипа, которые вы хотите, чтобы пользователи протестировали, например:
- Начало работы с продуктом,
- Завершение оформления заказа,
- Настройка продукта.
Расставьте приоритеты задач
Не вдавайтесь в подробности в своем контрольном списке юзабилити-тестирования. На проведение тестов и анализ результатов уйдет много времени. Вместо этого перечислите важные задачи в вашем продукте и отсортируйте их по приоритету.
Четкое описание задач
Тестировщикам необходимо знать, что им делать.Делай проще. Пользователи, как правило, разочаровываются, когда задачи неясны.
Имейте цель для каждой задачи
Как модератор, вы должны четко понимать цель задачи (например, «Я ожидаю, что пользователи смогут завершить оформление заказа в течение двух минут»). Однако не нужно сообщать участникам об этой цели.
Ограничение количества задач
Патрик Ниман из Usability Counts рекомендует назначать каждому участнику пять задач. Учитывая время сеанса (обычно 60 минут), оставьте время и для своих вопросов.
Предоставьте сценарий, а не инструкцию
Люди будут действовать более естественно, если вы предоставите им сценарий, а не сухие инструкции. Вместо того, чтобы спрашивать их что-то вроде: «Скачайте книгу с рецептами», вы можете сформулировать это как сценарий, например: «Вы ищете новые способы приготовления бобов. Загрузите электронную книгу с рецептами ». Сценарий предоставляет некоторый контекст и делает задачу более естественной для пользователя. Чем естественнее участники выполнят задание, тем точнее вы получите данные.
Протестируйте набор задач самостоятельно
Выполните задание несколько раз самостоятельно и продумайте соответствующие вопросы, которые нужно задать. Это тяжелая работа, но она обязательно окупится.
4. Набор представителей пользователей
Важно найти вопросы, которые вы хотите задать, но также люди, которые участвуют в вашем тесте, должны представлять вашу целевую аудиторию (личность пользователя). Нет смысла наблюдать, как люди используют ваш продукт, если они не соответствуют вашей целевой аудитории.Поэтому, как только у вас появится представление о том, что тестировать, приступайте к набору. Тщательно набирайте людей в соответствии с вашими целями. Имейте в виду: найти людей для юзабилити-тестов непросто. На самом деле рекрутинг — одна из основных причин, по которой многие компании не общаются регулярно со своими пользователями. Таким образом, приложите дополнительные усилия, чтобы найти людей, которые представляют вашу целевую аудиторию.
Анализировать существующие данные пользователей
Если у вашего продукта уже есть клиентская база, то быстрый анализ доступной информации (например, данных аналитики, заявок в службу поддержки, опросов, предыдущих сессий юзабилити) поможет вам оценить то, что вы уже знаете или не знаю о ваших пользователях.
Числа, предоставляемые аналитическим инструментом о том, как пользователь взаимодействует с продуктом (клики, время сеанса пользователя, поисковые запросы, конверсия и т. Д.), Помогут дизайнерам UX подготовиться к тестам на удобство использования. (Изображение: Ramotion) (превью в большом разрешении)Тест с пользователями, которые не только друзья или семья
Конечно, отзывы друзей и семьи лучше, чем ничего, но для лучших результатов вам понадобятся независимые и непредвзятые пользователи. тем, кто раньше не пользовался вашим продуктом. Ваши друзья и семья слишком близки к продукту, чтобы знать, как реальные люди впервые воспримут его.
Определите критерии
Перед тем, как набирать пользователей, вам нужно определиться с типом людей, которые будут тестировать ваш продукт. Определите критерии и выберите тестировщиков в соответствии с ними. Например, если вы тестируете мобильное приложение для заказа еды, скорее всего, вам понадобятся отзывы людей, которые заказывают еду регулярно. Переведите это требование в точные, измеримые критерии, чтобы вы могли использовать их для проверки потенциальных участников: людей, которые заказывают еду не реже одного раза в неделю из разных служб доставки (участники должны иметь опыт работы как минимум с тремя службами).
Помимо указания пользователей, с которыми вы хотите поговорить, подумайте о людях, которых вы не хотите видеть ни на одном из ваших сеансов. Как правило, избегайте тестирования с технически подкованными пользователями и первопроходцами, потому что такое тестирование может оказаться не таким показательным, как вам хотелось бы. Также избегайте участников, у которых есть конфликт интересов (например, тех, кто работает на конкурентов).
Создание вопросов для проверки
Затем создайте анкету для проверки, чтобы определить людей для ваших сеансов тестирования.Как и в любом хорошем опросе или анкете, избегайте наводящих вопросов. Пример вопроса, который может дать «правильный» ответ: «Нравится ли вам заказывать еду с помощью смартфона?» Большинство людей, которые хотят присоединиться к сеансу тестирования, наверняка ответят утвердительно на этот вопрос.
Вы можете подготовить список вопросов в формате анкеты и попросить потенциальных тестировщиков заполнить его. Google Forms — отличный инструмент для создания скринеров и сбора ответов в электронной таблице. Поскольку ответы попадают прямо в электронную таблицу Google, вы можете сортировать и фильтровать их.
Заставьте людей заполнить скрининг
Затем вам нужно убедить людей заполнить скринер. Один из способов добиться этого — создать описание должности со ссылкой на ваш опрос. В описании объясните свои ожидания и предложите стимул для мотивации людей прийти (например, подарочная карта Amazon на 100 долларов на 60-минутное собеседование).
Craigslist, Twitter и Facebook — наиболее очевидные места для размещения описания вакансии.
Все будет немного сложнее, когда вам нужно будет набрать очень специфических и труднодоступных типов пользователей.Но даже в этом случае это полностью разрешимо:
- Поговорите со своим отделом продаж или маркетинга, чтобы узнать, есть ли у них списки контактов, которыми они могут поделиться.
- Найдите контакты в соответствующих общественных группах и профессиональных ассоциациях.
Совет: Если ваш продукт присутствует на рынке, вы можете показать сообщение: «Хотите дать нам больше отзывов?» — где-то в пользовательском потоке, который ведет к вашей форме скрининга. Кроме того, если вы используете такую услугу, как Intercom, вы можете автоматически отправлять электронные письма новым пользователям после того, как они использовали продукт пять раз, с приглашением принять участие в тестировании.
Думайте о качестве, а не о количестве
Некоторые продуктовые группы думают, что им нужно много участников для тестирования удобства использования. Фактически, тестирование с пятью пользователями обычно выявляет 85% основных проблем с удобством использования. Самые важные проблемы легко обнаружить людям, которые плохо знакомы с вашим продуктом, и вам их трудно заметить, потому что у вас больше нет свежего взгляда. Оказывается, вы многому научитесь от первого человека, с которым поговорите, немного меньше — от следующего и так далее.
После того, как вы соберете ответы и отфильтруете список потенциальных участников на основе ваших критериев, выберите пять кандидатов, которые лучше всего соответствуют вашим критериям.
(Изображение: Nielsen Norman Group) (Просмотр большой версии)Четко проинструктируйте, как присоединиться к сеансу
При планировании тестового сеанса укажите все подробности в электронном письме с подтверждением участникам:
- Время (если вы это сделаете удаленное тестирование, укажите время в соответствующем часовом поясе),
- Местоположение (включая информацию о здании, парковке и т. д.),
- Что участники тестирования должны принести с собой (например, личный идентификатор, мобильное устройство с iOS или Android и т. д.),
- Ваш номер телефона (на случай возникновения вопросов или необходимости переноса времени).
Чтобы свести к минимуму неприятные неявки, вы можете попросить пользователей ответить для подтверждения. Например, тема письма с подтверждением может выглядеть примерно так: «Сессия по удобству использования запланирована на 14 мая в 15:00. (Пожалуйста, ответьте, чтобы подтвердить) ». Вы также можете позвонить участникам, чтобы напомнить им о встрече за день до сеанса.
5. Получите максимальную отдачу от личного тестирования
Слушание непосредственно от пользователей — один из самых быстрых способов узнать о вашем продукте и улучшить его.Наблюдая за тем, как кто-то использует ваш продукт, вы можете быстро определить области, в которых продукт недостаточно понятен.
Построение хороших отношений
Когда начинается сеанс, участник может нервничать и не знать, чего ожидать. Качество юзабилити-сессии напрямую связано с отношениями, которые вы строите с участником. Чем глубже участники доверяют модератору, тем откровеннее будет их отзыв. Проведите тест таким образом, чтобы участники чувствовали себя комфортно, давая вам честную обратную связь.
Несколько вещей, которые следует запомнить:
- В случае неудачи люди склонны винить себя, а не недостаток конструкции. Таким образом, убедитесь, что они не чувствуют, что их проверяют. (Например: «Мы не тестируем вас; мы тестируем наш дизайн. Итак, все, что вы говорите или делаете, — неправильно».)
- Вы хотите, чтобы участники были максимально откровенными. Если им что-то не нравится или они думают, что это глупо, обязательно скажите об этом. Некоторые участники не любят делиться такими мыслями, потому что боятся задеть ваши чувства.Просто скажите им что-нибудь вроде: «Ты не обидишь наши чувства. Мы вообще не участвовали в разработке этих экранов ».
- Начните с простых заданий или вопросов. Они не дадут никаких пикантных идей, но они заставят людей поговорить и помогут им расслабиться. Узнайте немного о человеке. Постарайтесь выяснить, что человеку нравится или не нравится, его хобби и технические привычки. Эта информация поможет вам лучше оценить результаты теста.
Слушай, не веди
После того, как вы представили задачу, все должно быть под руководством участника.Ваша цель на этом занятии — понять, как пользователи будут использовать продукт. Например, если участник выбрал незапланированный маршрут через ваше приложение, не исправляйте его! Подождите, чтобы увидеть, что произойдет. Это ценное обучение.
Не судите участников
Ваши участники здесь, чтобы научить вас чему-то, а не наоборот! Судить пользователей или пытаться обучать их во время теста было бы контрпродуктивно. Ваша цель — получить как можно больше информации за отведенное время и понять все с их точки зрения.
Таким образом, избегайте фраз вроде «Это было очевидно, правда?» и «Вы действительно так думаете?» поднимая брови, даже если что-то кажется очевидным. Вместо этого спросите что-нибудь вроде: «Насколько легко или сложно вам было выполнить это задание?» или «Почему ты так думаешь?» Ни в тоне, ни в языке тела не должно быть осуждения или удивления.
Не объясняй
Объясняя, как работает тестируемый продукт, вы почти наверняка внесете в тест предвзятость.В реальном мире ваш продукт будет жить сам по себе. Вы не будете сопровождать пользователей и рассказывать им, что делать и как использовать. Участники должны разбираться во всем, основываясь на описании задачи и на том, что они видят в интерфейсе.
Не прерывайте
Когда участники начинают задание, постарайтесь не прерывать их. Чем больше вы будете перебивать, тем меньше у них будет уверенности в том, что они выполнят задание. Они потеряют поток, и вы не увидите ничего похожего на естественное поведение.
Не привлекайте внимание к конкретным вопросам
Привлечение внимания к конкретным вопросам, которые вас волнуют, может заставить людей изменить свое поведение и сосредоточить свои ответы на проблемах, которые вы подчеркиваете. Эта проблема особенно часто встречается при обсуждениях дизайна пользовательского интерфейса: если вы спросите людей о конкретном элементе дизайна (например, о цвете основной кнопки с призывом к действию), они заметят его после этого гораздо чаще, чем если бы иметь иначе. Это может побудить участников изменить свое поведение и сосредоточиться на чем-то, что не имеет значения.
Используйте технику «Думай вслух»
Метод «Думай вслух» имеет решающее значение для проникновения в сознание участника. Фактически, Якоб Нильсен утверждает, что это лучший инструмент для удобства использования. Используя технику «думать вслух», модератор просит участников тестирования использовать продукт, постоянно думая вслух — просто озвучивая свои мысли, когда они перемещаются по пользовательскому интерфейсу. Используя эту технику для приложения для заказа еды, вы, скорее всего, получите ответы типа: «Хм, это похоже на приложение для заказа еды.Интересно, как заказать еду. Может быть, если я нажму здесь, я увижу форму для запроса еды ». Этот метод позволяет вам узнать, что пользователи действительно думают о вашем дизайне, и поможет вам превратить сессию юзабилити в практические рекомендации по редизайну. Ответы типа: «Ой, загружается слишком медленно», «Почему я это вижу?» а «Я ожидал увидеть Б после А» может быть преобразовано в конструктивные изменения, требующие принятия мер.
Совет: Поскольку большинство пользователей не разговаривают во время использования продукта, фасилитатор тестирования должен будет побуждать их продолжать говорить.Спросите что-нибудь вроде: «Что здесь происходит?» когда участники тестирования взаимодействуют с продуктом.
Наблюдать за поведением
Помните о различии между слушанием и наблюдением. Хотя оба метода предоставят UX-дизайнерам ценную информацию, многие UX-дизайнеры слишком много внимания уделяют слушанию. Наблюдающие пользователи могут открыть гораздо больше за гораздо меньшее время. Вы можете многому научиться, слушая людей, но вы можете узнать гораздо больше, увидев, как они реагируют на продукт.
Большинство людей хотят выглядеть умными, поэтому во время сеансов тестирования вы заметите, что участники с трудом справляются с задачей, но затем скажете, что для них это было легко.Таким образом, сосредоточьтесь на их поведении, а не на их мнении.
Если сомневаетесь, уточните
Если вы не совсем уверены, о чем говорит участник, попросите разъяснений. Простой вопрос вроде «Когда вы сказали… Вы имели в виду…?» прояснят ситуацию. Не оставляйте это до конца сеанса. Конец сеанса слишком поздно, чтобы возвращаться и выяснять, о чем кто-то говорил.
Ответьте на вопросы
Будьте готовы узнать как можно больше об опыте и перспективах пользователей.Не соглашайтесь на первый полученный ответ. Всегда копайте глубже, задавая уточняющие вопросы. Дополнительные вопросы позволят вам лучше понять, что произошло на самом деле. Люди часто не могут четко изложить свои мотивы без подсказки. Простой своевременный уточняющий вопрос обычно дает более подробное объяснение или ценный пример.
Ответьте на вопросы с вопросами
Во время занятия участники обязательно зададут вам несколько вопросов. Вот некоторые из наиболее распространенных:
- «Стоит ли мне его использовать?»
- «Как вы думаете?»
- «Что думали об этом другие?»
Не поддавайтесь искушению рассказать им все об этом! Задайте им вопрос сразу же.Это многое откроет.
6. Относитесь к дизайну как к итерационному процессу
Многие продуктовые группы думают о процессе проектирования как о линейном процессе, который начинается с исследования пользователей, имеет фазу прототипирования и заканчивается тестированием. Однако относитесь к этому как к повторяющемуся процессу.
Тестирование, как и кодирование, проектирование и сбор требований, занимает место в итеративном цикле проектирования и разработки продукта. Важно проверять на каждом интервале этого процесса, доступны ли ресурсы.
Петля обратной связи
Лучший способ избежать переделки продукта — это добавить обратную связь в процесс. Регулярная обратная связь с пользователями (не обязательно в форме тестирования юзабилити, но также в виде онлайн-опросов или анализа заявок в службу поддержки) должна быть в центре процесса проектирования UX.
(Изображение: Extreme Uncertainty) (Просмотр большой версии)7. Не ограничивайте себя личными сессиями
Личное тестирование — отличный способ понять поведение пользователя; К сожалению, это не всегда возможно.Что делать, если вам нужно протестировать только одну небольшую функцию, или ваши участники тестирования рассредоточены (например, если ваш продукт нацелен на международных клиентов), или вам нужны быстрые результаты (в идеале, сегодня)? В этом случае сосредоточьтесь на удаленном тестировании. Но как вы справляетесь с удаленными сеансами?
Использование инструментов для немодерируемых тестов
В настоящее время доступно множество инструментов для запуска удаленных немодерируемых тестов. Вот некоторые из них:
- Lookback
Этот инструмент позволяет проводить как удаленное модерируемое тестирование в реальном времени, так и немодерируемое тестирование.Живые сеансы автоматически записываются в облако — без загрузки, ожидания или управления файлами. - UserTesting
UserTesting позволяет легко удаленно тестировать удобство использования. Вы можете запустить немодерируемый тест на своем веб-сайте с заранее определенной базой пользователей. - Validately
В поле Validately выберите либо немодерируемое, либо модерируемое тестирование. Чтобы протестировать продукт, добавьте ссылку на свой сайт или прототип. Тестировщики получат URL-адрес для прохождения теста или присоединения к модерируемому сеансу. После сеанса вы получите качественный отчет и видео, которыми можно поделиться.Цена начинается от 49 долларов в месяц. - Usabilla
Собирайте качественные и количественные данные пользователей, чтобы принимать правильные дизайнерские решения. Среди результатов тестирования вы получите хорошие тепловые карты.
Проведение модерируемого удаленного тестирования
Вы можете проводить удаленные модерируемые сеансы с помощью Google Hangouts или Skype. Просто попросите пользователей показать свой экран, а затем посмотрите, как они взаимодействуют с вашим продуктом. Не забудьте записать сеанс для дальнейшего анализа.(Записывайте и видео, и аудио; без звука может быть трудно сказать, почему произошло определенное поведение.)
Избегайте «профессиональных» тестеров
Обратной стороной удаленного тестирования является то, что многие участники проходят тестирование настолько часто, что они уже научились этому. сосредоточиться на определенных аспектах дизайна. Чтобы компенсировать возможных «профессиональных» тестировщиков, вам нужно будет анализировать сеансы тестирования (например, путем просмотра видеозаписей) и исключать результаты людей, которые, похоже, не дают реальной обратной связи.
8. Вовлекайте в процесс всю команду
Вовлекайте всю команду продукта в процесс тестирования. Возможность наблюдать за пользователями поможет всей команде понять проблемы юзабилити и посочувствовать пользователям. Тестирование позволяет достичь взаимопонимания еще до того, как команда приступит к проектированию.
Обсудите стратегию тестирования с командой
Дизайн продукта — это командный вид спорта. А поскольку тестирование является неотъемлемой частью процесса проектирования, его следует обсудить со всеми участниками команды.Непосредственное участие в подготовке теста повысит интерес членов команды к этому занятию. Как человек, ответственный за исследование UX, вы должны четко указать, как ваша команда будет использовать результаты тестов юзабилити.
(Изображение: General Assembly) (Просмотр большой версии)Попросите всех посмотреть сеансы
Вы не можете ожидать, что вся команда присоединится к сеансам тестирования. В большинстве случаев необязательно, чтобы все лично наблюдали за юзабилити-тестированием (хотя это может быть желательно).Но вы можете записывать сеансы тестирования на видео и делиться им с коллегами. Видео может быть чрезвычайно полезным при обсуждении дизайна.
Попросите команду помочь с анализом
Одна вещь, которая замедляет многие формы юзабилити-тестирования, — это анализ. Извлечение результатов из данных, собранных во время сеансов тестирования, может занять несколько дней или даже недель. Но если вся команда будет следить за сессиями и делать заметки, они смогут лучше обобщить результаты и принять решение о следующих шагах.
9. Тестирование до, во время и после редизайна
Распространенный вопрос среди многих продуктовых команд: «Когда мы должны тестировать?» Ответ прост: тестируйте перед дизайном или редизайном, тестируйте во время дизайна, а затем тестируйте тоже.
- Перед проектированием или перепроектированием
Тестирование будет проводиться на этапе открытия процесса проектирования UX. Если вы планируете перепроектировать существующий продукт, тестирование удобства использования может помочь вам определить самые большие проблемы в текущей версии.Рассмотрите возможность тестирования продуктов конкурентов, чтобы сравнить результаты. - Во время редизайна
Если ресурсы есть, делайте это на каждой вехе проекта. За время, необходимое для создания и запуска нового продукта или функции, вы можете провести несколько сеансов тестирования и улучшать прототип после каждого из них. - После редизайна
Знание того, как реальные пользователи используют продукт, поможет вам сделать его лучше.
10. Не пытайтесь решить все сразу
Попытаться решить все сразу просто невозможно.Вместо этого расставьте приоритеты в своих выводах. Сначала устраните наиболее важные проблемы, а затем повторите попытку. Однако, если это невозможно (например, если проблемы слишком велики, чтобы их можно было решить), расставьте приоритеты в соответствии с их влиянием на доход.
Заключение
Вы не можете позволить себе пропустить тестирование, потому что даже простой раунд тестирования может сделать или сломать ваш продукт. Инвестиции в пользовательское тестирование — это чуть ли не единственный способ постоянно генерировать обширный поток данных о поведении пользователей.Таким образом, тестируйте раньше, тестируйте чаще .
Эта статья является частью серии UX-дизайна, спонсируемой Adobe. Инструмент Adobe XD создан для быстрого и гибкого процесса проектирования UX, поскольку он позволяет быстрее переходить от идеи к прототипу. Создавайте, создавайте прототипы и делитесь ими — все в одном приложении. Вы можете ознакомиться с другими вдохновляющими проектами, созданными с помощью Adobe XD, на Behance, а также подписаться на информационный бюллетень Adobe Experience Design, чтобы оставаться в курсе последних тенденций и идей в области дизайна UX / UI.(vf, yk, al, il)
Qiagen запускает экспресс-тест на коронавирус, который, по его словам, может использоваться в аэропортах и стадионах
Сотрудник работает в защитном костюме в лаборатории биотехнологической компании Qiagen в Германии, 8 сентября 2020 г. .
Fabian Strauch | картина альянс | Getty Images
Немецкая компания по генетическому тестированию Qiagen объявила во вторник, что планирует запустить новый тест на антиген на коронавирус, который, по ее словам, в конечном итоге может быть развернут в аэропортах и на стадионах, если он получит соответствующие разрешения.
Компания заявила, что планирует запустить две версии теста на антиген в США в конце этого года: одну версию, предназначенную для обработки в клинической лаборатории, и другую, портативную, которую можно обрабатывать на месте.Компания еще не подавала заявку на разрешение на использование в чрезвычайных ситуациях от Управления по санитарному надзору за качеством пищевых продуктов и медикаментов, но сообщила, что планирует это сделать.
Если тест, называемый тестом на антиген доступа, получит разрешение FDA для использования в местах оказания медицинской помощи, и если он не будет соответствовать требованиям поправок по улучшению клинической лаборатории, Qiagen сказал, что тест может использоваться в условиях большого объема. например, в аэропортах и на стадионах для проверки людей с симптомами. Быстрое тестирование людей с симптомами может стать все более важным осенью и зимой, поскольку сезонный грипп, вызывающий многие из тех же ранних симптомов, что и Covid-19, распространяется в Северном полушарии.
«Портативный тест предлагает новое сочетание скорости и масштаба, которое знаменует собой важный шаг к децентрализованному массовому тестированию, к которому срочно стремятся органы здравоохранения во всем мире», — говорится в сообщении компании.
Тест, разработанный в сотрудничестве с австралийской диагностической компанией Ellume, может одновременно проверять до восьми образцов мазков из носа. Администраторы теста используют небольшую цифровую платформу под названием eHub, которая была запущена в августе вместе с тестом на антитела Qiagen, для обработки мазков из носа.
Платформа может дать результаты менее чем за 15 минут, заявили в компании, и может обрабатывать в среднем около 30 образцов мазков каждый час. Qiagen добавил, что тест правильно диагностирует положительную коронавирусную инфекцию в 90% случаев и правильно диагностирует отрицательный результат в 100% случаев. Компания не уточняла методы, использованные для получения выводов о точности.
Компания еще не объявила цену теста, но генеральный директор Qiagen Тьерри Бернар назвал тесты «рентабельными».«Qiagen также не раскрыла подробностей о том, сколько тестов она сможет произвести.
В своем заявлении Бернард добавил, что тесты на антигены предназначены для дополнения, а не замены молекулярных или ПЦР-тестов, которые являются наиболее распространенными. точные тесты на рынке. Однако тесты ПЦР зависят от напряженной цепочки поставок технического лабораторного оборудования, должны обрабатываться обученными учеными и могут занять часы или дни для получения результатов.
Компания добавила, что это также будет применяться для сертификации в Европе.
«Тест на антиген доступа быстр, прост в использовании и экономичен и станет ценным инструментом для решения пока неудовлетворенных потребностей в массовом тестировании антигенов SARS-CoV-2 в ситуациях, когда время имеет существенное значение. «Бернард сказал в своем заявлении. «Он обеспечит высокоточные результаты и дополнит стандартные ПЦР-тесты, используемые для выявления активной инфекции COVID-19. ПЦР-тесты обеспечивают высокий уровень диагностической точности, но требуют времени и связаны с лабораторными исследованиями».
— CNBC Мэг Тиррелл способствовала этому отчету.
Пользовательский интерфейс TeamCity: как его протестировать?
Истории клиентов How-To’s Советы и хитростиТрудно разработать рабочую часть программного обеспечения. Как и при постройке самолета, для этого требуются талантливые люди, рабочие компоненты и среда тестирования. Ни один самолет не покидает ангар, пока все не будет готово, проверено и перепроверено.
В JetBrains мы придерживаемся той же философии при создании программного обеспечения. Тщательное тестирование помогает нам обнаруживать ошибки и проблемы до того, как готовый продукт станет готовым. Подобно построению самолета, разработка программного обеспечения — это процесс, состоящий из нескольких этапов. Хотя авторы этого поста не являются аэрокосмическими инженерами, мы будем использовать упрощенные аналогии с самолетами. Этому есть несколько причин: самолет красив, это чистая инженерия, и это показывает, что проблемы, которые мы здесь поднимаем, не относятся исключительно к программной инженерии.
Чем больше ваш продукт, тем больше в нем ступеней и модулей. Чтобы убедиться, что ваше программное обеспечение готово к запуску, каждый модуль должен быть протестирован и правильно интегрирован со всем остальным. Службы CI / CD, если они настроены правильно, помогают автоматизировать этот процесс. Самое главное, они устраняют человеческий фактор, известный тем, что одно неосторожное действие может привести к полной катастрофе.
Вопреки распространенному мнению, тестирование очень важно при разработке интерфейса. Продолжая аналогию, ваш самолет должен не только летать — он должен быть комфортным внутри! Причем его внешний вид влияет на полет самолета (аэродинамику).Возвращаясь к интерфейсу пользователя, это означает, что вам нужно протестировать не только функциональность, но и удобство использования. Это делает обязательным предварительное тестирование . В этой статье мы представим обзор тестирования пользовательского интерфейса, используемого в TeamCity. Если у вас есть какие-либо вопросы по техническим деталям — не стесняйтесь обращаться к нам.
Примечание:
Каждый раздел этого поста содержит ссылки на полезные ресурсы. Некоторые из них приводят к общедоступным конфигурациям TeamCity, где вы можете изучить, как мы тестируем интерфейсную часть.Не стесняйтесь войти в систему как гость и осмотреться.
TL; докторские диссертации:
- UI-тестирование — это не только модульные тесты. Есть скриншоты, тесты поведения, доступности, производительности, безопасности и восприятия. Каждый из них указан ниже. Системы тестирования
- и CI / CD помогают сосредоточиться на действительно важных вещах.
- TeamCity позволяет создавать сложные конвейеры для тестирования любых проблем пользовательского интерфейса.
Перехват вопросов
Давайте рассмотрим перехват вопросов.В JetBrains он работает на нескольких уровнях, и большинство из них основано на CI / CD. Каждый тест, каждый отдел, каждый уровень принимают участие во всем процессе выявления и сообщения о проблемах. Вот диаграмма, где по оси Y показано количество проблем, которые могут возникнуть в приложении. Синие полоски — актуальное количество вопросов. На оси X представлены фильтры, которые решают проблемы. Таким образом, он показывает, как разные уровни влияют на реальное количество проблем.
Каждый фильтр заботится о некоторых категориях проблем.
Например, огромное количество обнаруживаемых нами проблем пользовательского интерфейса относится к этапу Тестирование снимков экрана . Меньше задач относится к тестам ЛИНТЕР / Юнит / Рендеринг. Это не делает эти тесты бессмысленными. Напротив, это может означать, что мы работаем в этих областях достаточно хорошо, чтобы предотвратить множество проблем.
Ключевой момент, который мы хотели бы здесь показать: как видите, отдел контроля качества сталкивается только с одной третью проблем. Это означает, что , используя CI / CD, вы можете помочь своим коллегам сэкономить время на проверке проблем, которые легко предсказать , которые могут быть обнаружены хорошо организованной системой тестирования.
Диаграмма не на 100% репрезентативна, и цифры меняются от выпуска к выпуску: один уровень может устранить больше проблем, чем другой. Однако это показывает, что тестовая система очень важна, даже если отдельный тест охватывает только один случай. Количество здесь не равно качеству: тест может обнаружить «только» одну ошибку, но эта одна ошибка может привести к сбою всего приложения, если ее не заметить.
Линтеры, типизации, юнит-тесты
Во-первых, мы должны сказать, что код должен быть чистым и последовательным, но с этим есть проблема.У каждого свое понимание чистого кода. В JetBrains мы согласовали более 200 правил, которые гарантируют, что наш код остается объективно чистым. В результате мы получаем предупреждение от IntelliJ Idea всякий раз, когда линтер обнаруживает проблему. Не лишним будет упомянуть, что статическая типизация с помощью TypeScript, Flow, Kotlin или Reason необходима для сложных приложений. Мы, команда TeamCity, решили использовать Flow. Одним из первых тестов, которые мы используем для создания внешнего интерфейса, является проверка eslint / stylelint. Его цель не только для поиска проблем со стилем кода, но и для проблем с пропущенными переменными, импортом или недешевыми / безопасными операциями (например, React Hooks без зависимостей).
Конечно, есть и юнит-тесты. Это просто: мы пишем чистые атомарные функции, а затем утверждаем их результат. Если результат в порядке, TeamCity помечает их зеленым и позволяет конвейеру продолжить работу.
Подробнее:
Модульные тесты / Параметры конфигурации сборки ЛИНТЕР
JestJS — фреймворк для организации модульных тестов
Тестирование снимков экрана
Отображение согласованного пользовательского интерфейса на нескольких устройствах и платформах — одна из наших основных целей. Мы должны быть уверены, что все компоненты отображаются правильно, независимо от используемого браузера, макета или размера области просмотра.Это подразумевает тестирование того, как компоненты визуально представлены в различных конфигурациях. Тестирование снимков экрана делает именно это.
Скриншоты diff
После одного из обновлений к неавторизованным агентам добавлены разделы комментариев. Ничего страшного. Но представьте, что такой тест может выявить исчезновение элементов. Это случается время от времени, и мы считаем этот тест очень полезным. Хотя Snapshot Testing, как вы скоро познакомитесь, тоже поможет в этом случае.
Вот как мы это делаем:
- Запустить сервер, который отображает компоненты (в нашем случае Storybook).
- Подключиться к серверу с помощью WebDriver API; этот API позволяет нам взаимодействовать с веб-сайтом в автоматическом режиме — без реального пользователя.
- WebDriver вызывает соответствующие компоненты.
- Гермиона, служебный инструмент от Яндекса, подключается к Storybook с помощью WebDriver и делает несколько снимков экрана выбранной области в каждом браузере.
- Эти снимки экрана затем помещаются в папку, где Гермиона сравнивает их со снимками экрана по умолчанию с помощью Mocha.
- Если что-то изменилось, мы получаем уведомление. Отличия также подчеркнуты визуально!
Подробнее:
Ring UI Настройки конфигурации сборки Hermione
Снимок экрана Пример ложного утверждения
React и рендеринг
Мы стараемся улучшить производительность наших интерфейсов, минимизируя количество ненужных рендеров. В целом React неплохо справляется с этим. Однако есть некоторые случаи, о которых следует помнить: если вы что-то меняете в компоненте, React создает новый вместо изменения исходного компонента.
Представьте, что вы передаете компоненту новые свойства. Чтобы сэкономить ресурсы, необходимые для повторного рендеринга, React проверяет, отличаются ли переданные реквизиты от предыдущей версии. Если они совпадают, повторного рендеринга не происходит. К сожалению, многие из нас забывают, что в JavaScript два массива или объекта с одинаковым содержимым являются разными сущностями (потому что эти объекты / массивы будут иметь разные ссылки). В результате мы без надобности рендерим одинаковые компоненты.
React выделяет обновления DOM
Вы можете включить React Updates Highlighting с помощью инструментов разработчика React.Это покажет все повторные рендеры в вашем приложении. Например, есть повторные рендеры, которые происходят при наведении курсора на субкомпонент Trends Page. К счастью, все эти рендеры предназначены именно здесь. Но представьте, что добавление к этим повторным рендерам приложение сработает еще на сотню?
Подробнее:
Диаграмма жизненного цикла React
Стоит ли делать рендеринг заново?
Мы уже знаем об опасности. Тем не менее, мы решили проверить, нет ли избыточного рендеринга, с помощью метода why-did-you-render.К нашему удивлению, мы обнаружили несколько примеров неэффективности. Вот как мы это сделали:
- Мы создали фиктивное действие: оно запускает изменения в магазине.
- Если мы что-то изменим в магазине, мы заставим все компоненты (подписанные на этот магазин) снова собирать данные. Это происходит с обратным вызовом mapStateToProps .
- После сбора данных мы передаем их компоненту и запускаем функцию сравнения, чтобы проверить, были ли изменены свойства или нет.
- Между тем, мы знаем, что фиктивное действие на самом деле не изменяет никаких значений в хранилище, а это означает, что никакие новые свойства не должны передаваться компоненту.
- Если новые свойства приводят компонент к повторному рендерингу, мы знаем, что создали новый объект / массив где-то там, где не должны. Какая жалость!
TeamCity сообщает о лишних рендерах
У нас есть два совета по решению этой проблемы:
- Библиотека повторного выбора
- Неизменяемые структуры данных
Выбрать библиотеку повторно
Используя библиотеку повторного выбора, вы можете запоминать результаты, если все параметры для функции генерации остаются прежними.Если переданные параметры совпадают с предыдущими, мы получим не новые объекты, а ссылки на старые. Повторного рендеринга не происходит.
Неизменяемые структуры данных
Вы можете заранее определить объект или массив как неизменяемый, заморозив его. В следующий раз, когда вы захотите вернуть резервное значение, вы должны вернуть этот неизменяемый объект. Это гарантирует, что ссылка на этот объект всегда будет одинаковой, поэтому компонент не будет повторно отрисован.
Тестирование снимков
Тестирование моментальных снимков подтверждает, что любые изменения, внесенные в структуру важных компонентов, являются преднамеренными.Еще раз вернемся к нашей аналогии с самолетом. Представьте, что у нас есть снимок конструкции самолета: у него должен быть корпус, одно крыло и четыре реактивных двигателя. Внезапно мы решаем снять один из реактивных двигателей и заменить его турбиной. Хотя это может быть отличной идеей, она больше не подходит для нашего снимка. Следовательно, мы получим уведомление.
Иногда можно было изменить даже жестко запрограммированные элементы. Фото Энтони Ноубла.
На картинке выше изменение было намеренным, с очевидными последствиями.Теперь представьте себе снимок нашей плоскости, состоящий из сотен компонентов: отследить все взаимодействия было бы очень сложно. В этом отношении проекты JavaScript похожи. Небольшое изменение одного компонента может привести к нежелательным последствиям для структуры всего проекта.
Вы можете защитить конструкции, создав их снимки. Всякий раз, когда вы опечатываете, изменяете класс HTML или добавляете новый компонент, вы нарушаете структуру. Если вы это сделаете, снимок экрана уведомит вас.Посмотрите пример ниже:
- Создаем снимок важной конструкции. Указываем двигатели Ил-76ЛЛ:
- Нам всегда хочется сравнивать будущие самолеты со снимком, который мы сделали ранее.
- Здесь мы меняем тип двигателя с турбовинтового на турбовинтовой. Просто чтобы проверить, как это работает. Поскольку новый движок больше не соответствует нашему снимку, тест не проходит. У нас есть отчет, и наши инженеры приступают к изучению проблемы.
То же, что и для компонентов React:
Подробнее:
Storybook Structural Testing / Руководство по тестированию снимков Jest
Тесты E2E
ИспытанияE2E очень похожи на испытательные полеты.Как и в случае с самолетами, мы должны убедиться, что наш интерфейс действительно применим в реальном мире. Поскольку тысячи компонентов взаимодействуют друг с другом, вы никогда не узнаете, сможет ли ваш самолет взлететь, прежде чем пилот действительно поднимет его в воздух.
ТестыE2E предназначены для тестирования потока приложений от начала до конца. Эти тесты имитируют реального пользователя, который снова и снова проходит через один и тот же конкретный вариант использования.
E2E в действии
Так выглядит E2E-тестирование в нашем случае:
- Создайте список критических сценариев с точки зрения пользователя (пользовательские истории).
- Создайте автоматический тест для каждого из перечисленных сценариев.
- Каждый из этих тестов должен описывать, как Selenium должен взаимодействовать с пользовательским интерфейсом.
- В обязательном порядке:
- Откройте браузер.
- Войти.
- Перейти на страницу X.
- Нажмите кнопку Y.
- Убедитесь, что отображается окно Z.
- Заявительно:
- «Убедитесь, что пользователь получает окно Z после перехода на страницу X и запуска процесса Y».
- В обязательном порядке:
- Запустите контейнер Docker с последним экземпляром TeamCity.
- Запустить тесты; эти тесты подключаются к Docker с помощью Selenium и выполняют алгоритмы.
Подробнее:
Параметры конфигурации сборки E2E
Прочие испытания
Написание этой статьи заняло время. За это время мы внедрили несколько новых тестов, таких как аудит безопасности зависимостей, тесты доступности, а также обсуждаем некоторые новые категории тестов. Мы с нетерпением ждем ваших отзывов, чтобы продолжить писать статьи и глубже погрузиться в область тестирования внешнего интерфейса.
TeamCity и цепочки сборки
TeamCity позволяет создавать бесконечно сложную логику для запуска тестов и развертывания сборок. Так TeamCity отображает цепочку / временную шкалу сборок для своего собственного пользовательского интерфейса.
Как видите, TeamCity запускает тесты параллельно, и, как следствие, некоторые сборки ждут успешного завершения других. А если что-то пойдет не так, это может остановить весь конвейер — просто чтобы не тратить ресурсы на тесты, которые определенно потерпят неудачу.
И вот так TeamCity представляет себе такой же огромный проект:
Здесь важно то, что мы могли не только строить сложные конвейеры, но и делать их сложными в хорошем смысле. Например, некоторые части нашего конвейера должны быть построены на агентах OS X, некоторые — на системе Linux, а некоторые из них будут построены с использованием агентов Amazon Cloud.
Подробнее:
Цепочки сборки: смесь конвейеров TeamCity (часть 1)
Цепочки сборки: смесь конвейеров TeamCity (часть 2)
Цепочка сборки кольцевого интерфейса
Вы помните первую диаграмму? Наши автоматизированные тесты покрывают более половины этих проблем, а отдел контроля качества покрывает одну треть.Тем не менее, всегда что-то остается. В JetBrains мы широко практикуем «догонялки»: мы используем наши собственные продукты (IntelliJ, TeamCity, Space, YouTrack и т. Д.) Для разработки и создания программного обеспечения. Итак, на этом этапе все сотрудники JetBrains могут прийти к нам и поделиться отзывами. Таким образом мы получаем уведомление и исправляем ошибки, прошедшие все остальные фильтры.
В рамках нашей программы раннего доступа , вы можете узнать больше о новых функциях, которые мы создаем прямо сейчас, поделиться своими отзывами, сообщить о проблемах и попросить нас добавить некоторые новые функции, чтобы они были выпущены как можно скорее.
Надеюсь, мы разъяснили основные принципы интерфейсного тестирования. Подводя итог, можно считать это страховкой: это требует определенных усилий, но может спасти жизнь. Чтобы получить максимальную прибыль от CI / CD для небольших проектов, вы можете использовать TeamCity бесплатно. Защитите себя от дорогостоящих ошибок!
Чтобы попробовать TeamCity прямо сейчас, перейдите по этой ссылке.
С любовью,
TeamCity Team
McLaren 720S Full Test: он меняет положения о суперкарах | Инструментальный тест
Из выпуска за май 2018 г.
California State Route 243 — плохая дорога.Так много прекрасных дорог. В восьмидесяти пяти милях к востоку от Лос-Анджелеса, северный конец этого 29-мильного асфальтового лоскутного покрытия предлагает невероятные виды на слияние разломов Сан-Андреас и Сан-Хасинто. Примерно на 3000 футов выше, недалеко от южной конечной точки дороги, типичная зима сбрасывает 32 дюйма снега. Тротуар здесь получает удары сверху и снизу, и это видно.
Но в основном SR 243 потрескался и покоробился из-за многолетнего пренебрежения. Он соединяет промышленный город с населением 30 000 человек и город с населением менее 100 человек, и вы можете проехать на нем в обоих направлениях, но при этом убедитесь, что он никуда не денется.Неудивительно, что это было либо забыто, либо проигнорировано транспортными агентствами, занятыми сортировкой основных артерий SoCal, чтобы предотвратить их свертывание.
Грег Паджо Автомобиль и водитель
Эта дорога, также известная как Панорамное шоссе Banning-Idyllwild, должно быть коварным предложением для автомобиля за 378 215 долларов, который скользит по поверхности с 4,2 дюймами дорожного просвета и обвесом из углеродного волокна, свисающим с днища за полгода.Управляемый задними колесами с 710-сильным двигателем V-8, 720S — это Hellcat, воплощенный командой Формулы-1. По собственному признанию главного инженера, этот новый McLaren среднего класса проходит трассу быстрее, чем P1 за 1,2 миллиона долларов. Так что вы можете предположить, что это жестокая и бескомпромиссная вещь, настолько абсурдно быстрая, что она почти отказывается идти по этой немного улучшенной козьей тропе.
За исключением того, что это не так, и это не так. Когда в 2011 году McLaren вернулась на рынок дорожных автомобилей, его MP4-12C (позже 12C, а позже и 650S) бросил вызов итальянским домам изобилием углеродного волокна и избытком мощности с турбонаддувом.Однако лучший вклад компании в развитие суперкарда — это преимущество шасси, которое она по-прежнему доминирует над Ferrari и Lamborghini. С подвеской, которая напоминает 60-летний французский седан, 720S обеспечивает езду Mercedes S-класса с управляемостью, ну, ну, в общем, McLaren.
Интерьер 720S — образец функциональной простоты. McLaren даже не украшает свое рулевое колесо кнопками, как все суперкары других марок.Грег Паджо Автомобиль и водитель
Proactive Chassis Control II компании соединяет левый и правый демпферы с сетью гидравлических шлангов и гидроаккумуляторов, так что сжатие с одной стороны препятствует растяжению с противоположной стороны.Это позволяет инженерам увеличить жесткость крена без ущерба для вертикальной податливости, которая определяет качество езды. Изрезанная и техническая дорога, такая как 243, — идеальное место для проверки возможностей системы.
Наша поездка начинается в Баннинге, штат Калифорния, промышленном городе, оседлавшем межштатную автомагистраль 10, которую, несмотря на всю ее анонимность, можно было бы вырвать из центральной части Оклахомы. Всего в миле от города SR 243 начинает восхождение на северную оконечность гранитного образования, которое простирается до полуострова Баха и предлагает потрясающие виды на пейзаж, который уникален для Калифорнии, сочетающий выжженную пустыню, зеленые горы и заснеженные вершины.
Дорога быстро поднимается наверх благодаря серии быстрых, но неуклюжих подметально-уборочных машин. Резкий ветер поздней зимой работает против опциональных шин Pirelli P Zero Corsa 720S, которым требуется тепло протектора, прежде чем они схлестнутся с асфальтом, с полным сцеплением в поворотах 1,10 г, которое мы измерили на трассе. Требуется лихорадочный темп, чтобы шины оставались теплыми и довольными — темп, который 720S делает без усилий. В поворотах McLaren прилипает к асфальту, как будто рука Бога прижимает его к асфальту, но при этом он чувствует себя таким же легким и маневренным, как Miata.Немногие автопроизводители считают грамм так невротично, как это делает McLaren, а британцы даже не используют дифференциал повышенного трения в интересах сдерживания массы. При весе в 3161 фунт McLaren на 157 фунтов легче Porsche 911 GT3 с двойным сцеплением.
Уловка подвески 720S превращает загруженную дорогу в жидкую поверхность, а рулевое управление с фиксированным передаточным числом и электрогидравлическим усилителем точно помещает автомобиль. Несмотря на эту компетенцию, рулевое усилие на плоской поверхности постоянно нарушается, что позволяет поддерживать постоянный вес независимо от нагрузки на поворотах.Без этой подсказки трудно точно знать, где вы находитесь в пределах диапазона сублимитов. Если вы ожидаете, что тонкости рулевого управления приведут вас к пределам возможностей McLaren, вы потратите свои мили, бродя на нелегальных скоростях, которые по-прежнему намного ниже возможностей автомобиля.
Вместо этого 720S взаимодействует со старомодным ощущением рулевого управления. Колесо ерзает и щетинится, поскольку указывает на изменения развала, провалы и подъемы, которые в противном случае вы бы заметили только по движениям тела или не заметили бы вообще.На SR 243 система рулевого управления McLaren постоянно разговаривает, обеспечивая постоянный поток обратной связи, который направляет ваши руки для внесения бездумных исправлений. Используйте ладони, чтобы почувствовать интенсивность этих сигналов, и вы точно найдете пределы. Чем ближе вы приближаете 720S к краю, тем громче говорит руль.
Возможности McLaren безупречны. Его обратная связь рулевого управления — мирового класса. Но 911 GT3 или Ferrari 488GTB лучше передать чувство героизма на любой скорости.720S откажется от награды только в том случае, если вы толкнетесь глубже и с таким хорошим сцеплением, что на дороге общего пользования требуется приверженность и легкая самоотдача.
Поднимаясь на высоту 6000 футов, Маршрут 243 ненадолго разворачивается и врезается в сосновый лес. Такие прямые пробеги, как этот, дают возможность откупорить двигатель, обновленная версия старого 3,8-литрового двигателя увеличила его до 4,0 литра. Без извинения за счет турбонаддува M840T производит смехотворную мощность за счет значительной задержки на низких частотах, и он наполняет кабину шумом и шумом паровой работы.Лают ли восемь цилиндров или воют, мы не можем точно сказать, потому что ракетка мощностью 95 дБА при широко открытой дроссельной заслонке звучит в основном так, как будто дантист зацепил свой крошечный пылесос для рта вам в ухо.
Крутящий момент достигает пика при 568 фунт-фут при 5500 об / мин и начинает сильно бить только выше 3500 об / мин, поэтому вы ведете 720S, как будто он упакован в высоконагруженный безнаддувный двигатель, поддерживая высокие обороты, выдерживая инерцию и ругая себя каждый раз, когда вы пытаетесь вытащить вещь из угла на низком уровне крутящего момента. При таком приводе двигатель впечатляет, он крутится с интенсивностью, превышающей 8000 об / мин.
Вращающийся приборный щиток — единственный трюк автомобиля. Стандартный режим (слева) — это здорово. Тонкий режим (справа) труднее читать и не дает никаких преимуществ.Грег Паджо Автомобиль и водитель
И трансмиссия — это волшебство с переключением подрулевых лепестков в ручном режиме. Коробка передач такая же изящная, как и быстрая; сдвиги практически исчезают. Но инженеры McLaren также проявили немного гениальности программирования, когда повышающие передачи на высоких оборотах в режиме Track завершаются удовлетворительным ударом.Эта функция, получившая название Inertia Push, включает сцепление для следующего зубчатого колеса, при этом двигатель вращается быстрее, чем входной вал трансмиссии. Результирующий сдвиг «присоска-удар» использует инерцию вращающихся компонентов двигателя для передачи импульса крутящего момента на колеса, который, согласно McLaren, улучшает ускорение.
Чтобы получить полный эффект от тяги 720S, нажмите кнопку запуска, расположенную рядом с элементами управления радио, климатом и навигацией. Когда обе педали нажаты, стрелка цифрового тахометра колеблется около 3200 об / мин в течение четырех полных секунд, прежде чем цифровая приборная панель сообщит «Boost Ready».«McLaren не выскакивает из дыры, как полноприводный спортивный автомобиль. Запуск заднего привода 720S аналогичен запуску ракеты. Вы едете на волне резкого ускорения, когда скорость автомобиля догоняет быстрее вращающиеся задние колеса. Сжимание в груди сжимается сильнее всего, когда тахометр приближается к верхней точке первой передачи. 60 миль в час пролетает через 2,7 секунды после старта. McLaren безжалостен.
С подключенным P Zero Corsas 720S выигрывает время у менее мощных полноприводных соперников, которые превосходят его вне линейки.На скорости 5,3 секунды до 100 миль в час 720S просто обгоняет Lamborghini Huracán Performante. За 10,2 секунды четверть мили опережает McLaren почти на полсекунды над 911 Turbo S. На скорости 180 миль в час он продолжает тянуть, как будто пытается обогнать любой другой автомобиль. Это самый быстрый автомобиль с задним приводом, который мы когда-либо тестировали.
Чтобы вернуть McLaren на землю, педаль тормоза требует значительного нажатия одной ногой, прежде чем стандартные карбоново-керамические тормоза сработают. Начальный ход скучен и лишь незначительно продуктивен, после чего тормозное усилие начинает реагировать на нажатие педали.Вот как нам это нравится — педаль, чувствительная к давлению, а не настройка, зависящая от хода. Тем не менее, требуемое усилие неоправданно велико, а запрос большего замедления требует экспоненциально более сильного удара. Учитывая вес 720S, липкие шины и стандартное карбоново-керамическое оборудование, мы также ожидали более короткой остановки на скорости 70 миль в час, чем зафиксированные нами 149 футов.
И жесткая педаль тормоза, и плоское рулевое управление становятся все более привычными с милями и сознательной перекалибровкой ваших ожиданий.По мере того, как 243 входит в несколько самых крутых поворотов, мы обнаруживаем быстрый, удовлетворительный поток, прежде чем замедлиться в городе Idyllwild. По выходным эта причудливая горная деревушка привлекает столько городских жителей, что движение останавливается каждые несколько миль. Но даже короткая прогулка в темпе Prius не может испортить эту дорогу. В то время как калифорнийцы неоднозначно относятся к автострадам, водители на двухполосных дорогах постоянно бросают свои машины на выезды из гравия, чтобы уступить дорогу более быстрой машине — или, по крайней мере, Paris Blue McLaren.
720S привлекает восторженно поднятые вверх большие пальцы и протянутые вверх мобильные телефоны, даже если людям все еще приходится спрашивать, что это такое. Его дизайн настолько потусторонний, что один поклонник спрашивает: «Он электрический?» когда мы прокачиваем его через заднее крыло с октановым числом 91. Его органические линии преуменьшают то, сколько управления воздухом необходимо этой машине — чтобы создать такую неприличную мощность, чтобы предотвратить катастрофическое расплавление и не дать всему этому полететь со скоростью, близкой к заявленной максимальной скорости 212 миль в час. Отверстия и воздухозаборники есть, но вам придется внимательно присмотреться, чтобы их заметить.Через утопленные патрубки, в которых размещаются фары, воздух направляется над и под ходовыми огнями в передние радиаторы. Большинство автомобилей со средним расположением двигателя используют охлаждающие каналы позади задних дверей в качестве доминирующего элемента стиля (см. Audi R8, Ferrari 488 или Ford GT). 720S визуально растягивает колесную базу, перемещая воздухозаборники с боков на верх автомобиля. Воздух проходит по рельефным каналам вдоль плеч и вокруг купола, прежде чем попадать в боковые стороны корпуса, чтобы питать интеркулеры.Задний спойлер исчезает в кузове, пока он не развернется для увеличения прижимной силы или не встанет на передний край, чтобы действовать как воздушный тормоз.
Интерьер искусно прост. Ferrari и Lamborghini, с их рулевыми колесами с пятнистыми кнопками, могли бы взять реплику из прекрасного компонента из алькантары и углеродного волокна, который выполняет только две вещи: изменяет направление автомобиля и говорит другим, чтобы они не мешали. .
По сравнению с 650S, в 720S легче попасть в кабину благодаря более узким порогам и дверям с верхними петлями, которые при открытии захватывают с собой часть крыши.Остается нелегко подняться и перебраться через подоконник на выходе, а затем с любой грацией выпустить ноги. Но ковши Touring достаточно широкие и такие же удобные, как и сиденья с фиксированной спинкой. А обзорность во всех направлениях отличная благодаря тонким стойкам из углеродного волокна и редчайшей роскоши суперкаров со средним расположением двигателя: задним четвертным стеклам.
Оставляя Идиллуайлд в наших зеркалах, 243 продолжает свое впечатление поверхности Луны на протяжении пяти миль. Дорога заканчивается в Горном Центре — заправочной станции, кафе и кормовом магазине — где она выходит на Государственную трассу 74.
Слева или справа, 74 ведет к большему количеству горных перевалов, в том числе к некоторым достаточно гладким тротуарам. Но движение более плотное, и длинные цепочки медленно движущихся автомобилей образуют блокады. Вместо этого мы разворачиваемся и возвращаемся тем же путем, которым пришли. Великие дороги — это плохие дороги — это пустые дороги, и они становятся такими, потому что они в плохом состоянии и покрывают неумолимую местность. McLaren создает потрясающий суперкар, который может двигаться по крошащемуся асфальту, как если бы это был только что проложенный дорожный маршрут. Это суперкар, которому никогда не нужно отказываться от отличной дороги, какой бы плохой она ни была.
Конкуренты
Автомобиль и водитель
Технические характеристики
Технические характеристики:
ТИП АВТОМОБИЛЯ: со средним расположением двигателя, задний привод, 2 пассажира, 2-дверное купе
ЦЕНА ПО ТЕСТИРОВАНИЮ: 378 215 долларов (базовая цена: 288 845 долларов)
ТИП ДВИГАТЕЛЯ: V-8 с двойным турбонаддувом и промежуточным охлаждением, алюминиевый блок и головки
Рабочий объем: 244 куб. Дюймов, 3994 куб. См
Мощность: 710 л.с. при 7500 об / мин
Крутящий момент: 568 фунт-фут при 5500 об / мин
ТРАНСМИССИЯ: 7-ступенчатая автоматическая коробка передач с двойным сцеплением и ручным переключением передач
ШАССИ:
Подвеска (передняя / правая): поперечные рычаги / поперечные рычаги
Тормоза (передняя / правая): 15.Дисковые вентилируемые 4 дюйма / Дисковые вентилируемые 15,0 дюймов
Шины: Pirelli P Zero Corsa, F: 245 / 35ZR-19 (93Y) R: 305 / 30ZR-20 (103Y)
РАЗМЕРЫ:
Колесная база: 105,1 дюйма
Длина: 178,9 дюйма
Ширина: 76,0 дюйма Высота: 47,1 дюйма
Пассажирский объем: 48 куб. Футов
Грузовой объем: 13 куб. Футов
Снаряженная масса: 3161 фунт
C / D РЕЗУЛЬТАТЫ ИСПЫТАНИЙ:
От нуля до 60 миль в час: 2.7 секунд
От нуля до 100 миль в час: 5,3 секунды
От нуля до 180 миль в час: 17,5 секунды
Роторный старт, 5–60 миль в час: 3,3 секунды
Высшая передача, 30–50 миль в час: 2,3 секунды
Высшая передача, 50–70 миль в час: 2,7 сек
Стоя мили: 10,2 сек при 145 миль в час
Максимальная скорость (ограниченное сопротивление, заявленное производителем): 212 миль в час
Торможение, 70–0 миль в час: 149 футов
Удержание дороги, троллейбус диаметром 300 футов: 1,10 г
C / D ЭКОНОМИЯ ТОПЛИВА:
Наблюдаемое: 12 миль на галлон
EPA FUEL ECONOMY:
Комбинированный / город / шоссе: 18/15/22 миль на галлон
>> НАЖМИТЕ ДЛЯ СКАЧИВАНИЯ ТЕСТОВОГО ЛИСТА <<
>> НАЖМИТЕ, ЧТОБЫ СКАЧАТЬ ПОЛНЫЕ ТЕХНИЧЕСКИЕ ХАРАКТЕРИСТИКИ <<
Этот контент создается и поддерживается третьей стороной и импортируется на эту страницу, чтобы помочь пользователям указать свои адреса электронной почты.