что такое артефакт в тестировании
21. Перечислите основные артефакты тестирования ПО.
Тестовые артефакты — это используемые или создаваемые во время тестирования документы, модели и т.п. Например, вот основные из них:
1. План тестирования. Определяет стратегию тестирования на каждой итерации. Т.е. описывает цели и задачи тестирования, перечни тестов, метрики и критерии тестирования.
2. Сценарий тестирования (тестовый кейс или тестовый случай). Основной документ тестировщика, содержащий краткое описание входных данных, условий и последовательностей выполнения действий и ожидаемого результата.
3. Тестовые данные. Наборы тестовых входных данных и ожидаемых результатов.
4. Тестовый скрипт. Программная реализация теста или же описание ручного тестирования.
5. Набор тестов. Это сценарии тестирования, объединённые в наборы или пакеты. Используются как способ группировки тестов с похожими задачами или как набор сценариев, которые должны выполняться по порядку, так как, последующий использует результаты предыдущего сценария.
6. Список идей тестов. Используется в RUP для анализа и проектирования системы сценариев, существенно упрощая разработку необходимых наборов тестов. В основном смысл в том, чтобы проверить каждый сценарий различными способами. В RUP список идей тестов, представлен как документ группы тестирования, где каждый может внести изменение.
7. Результаты тестирования. Все результаты тестирования проведённых по ходу работы над всем проектом. На основе анализа этих результатов и сравнений с ожидаемыми результатами, выполняется оценка качества тестируемого продукта.
8. Дефекты. Важные артефакты процесса тестирования, которые описывают найденные ошибки и инициализируют процессы исправления
Что такое артефакт в тестировании
Что пишут в блогах
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Доклад рассматривает подход к процессу тестирования исходя из реалий жизни небольшой софтверной аутсорсной компании. От каких документов можно отказаться в процессе тестирования? Что стоит делать в первую очередь и на что обращать внимание. Какой принцип ложится во главу угла, когда тестировщики определяются с объемом работы на проекте.
Особенность доклада – присутствие практической составляющей. Можно много говорить о том, что нужно делать, но лучше один раз показать, как это делают другие.
Доклад не лишен спорных вопросов, автор намеренно призывает задуматься над тем, что обычно воспринимается как «нужное» априори.
Основные определения и понятия тестирования ПО
Чтобы с головой погрузиться в новую профессиональную область, важно изучить язык, на котором говорят её представители. Ведь специальная лексика не только описывает инструменты или процессы, с которыми тестировщики работают ежедневно, но и облегчает общение с коллегами на около рабочие темы.
К примеру, вы уже могли слышать фразу «это не баг, а фича». Объяснить её далёкому от информационных технологий собеседнику не так просто: в отличие от бага, который является ошибкой, фича ― это не дефект, а заранее и сознательно придуманная опция, которая служит изюминкой. Слишком долго, не так ли?
Использование подобных словечек поможет вам проявить свои знания на собеседовании и найти общий язык с HR, уже работающим в ИТ-индустрии человеком. Итак, какие же понятия и определения будут полезны каждому начинающему QA-специалисту?
Базовые термины
Баг (bug) ― это ошибка или дефект программного обеспечения. Он проявляется, когда фактическое поведение системы отличается от ожидаемого. Дефекты могут быть критическими и влиять на использование ПО или незначительными, когда их присутствие незаметно для пользователя.
Тестирование (testing) ― это исследование поведения программного продукта, основной целью которого является выявление багов. Понятия контроль качества (quality control, QC) и обеспечение качества (quality assurance, QA) часто используются в качестве синонимов, но это ошибка. Ведь тестирование нацелено на поиск ошибок в уже готовом ПО, а обеспечение качества задаёт условия, в которых дефекты появляться не будут.
Подробно об отличиях данных явлений мы рассказали в нашей статье.
Тестовое покрытие (test coverage) ― это совокупность тестов, которые проявляют работоспособность той или иной функциональности ПО. Чем больше проверок, тем шире тестовое покрытие, тем больше возможностей отследить поведение системы в различных условиях и выявить критические или незначительные дефекты.
Верификация (verification) ― оценка ПО или его компонентов с точки зрения соответствия всем заявленным к нему требованиям.
Валидация (validation) ― это проверка работоспособности функциональности приложения.
Релиз (release, RTM) ― выпуск программного продукта на рынок, например, размещение мобильного приложения в App Store или Google Play.
Артефакты ― это документы, которые используют в процессе тестирования. Подробнее о том, какими они бывают, расскажем далее.
Артефакты
Спецификация (specification, спек) ― детализированное описание работы приложения, которое включает технические свойства.
Баг-репорт (bug report, отчёт об ошибке) ― описание действий или условий, которые привели к выявлению дефекта. О принципах составления безупречного баг-репорта мы уже рассказали в одной из наших статей.
Подобные отчёты создают в баг-трекинговой системе (bug tracking system, система отслеживания ошибок). Это программа для описания и контроля дефектов. Наиболее распространённой является Jira. Новичку привыкнуть к работе в этой системе непросто, но освоить азы вы сможете с поддержкой опытного преподавателя-практика на базовом курсе от QA Academy.
План тестирования (test plan) ― в этом документе содержатся все данные о проводимой проверке: описание программного продукта, стратегия тестирования, сроки выполнения поставленных задач, используемые в процессе инструменты и оборудование, оценка потенциальных рисков и прочее.
Чек-лист (checklist, контрольный список) ― перечень параметров, которые нуждаются в проверке.
Тест-кейс (test case, тестовый случай) ― своего рода сценарий или описание последовательности шагов при проведении тестирования.
Тестовый набор (test suite) ― несколько тест-кейсов, которые объединены по типу тестирования или другим признакам.
Типы тестирования
Мануальное (ручное) ― непосредственная проверка работы ПО тестировщиком.
Автоматизированное ― оценка качества программного продукта с применением программных средств (автотесты).
Тестирование производительности (performance testing) ― анализ работы приложений под различными нагрузками.
Функциональное тестирование (functional testing) ― проверка возможности ПО в заданных условиях решать необходимые пользователю задачи.
Тестирование безопасности (security testing) ― определение безопасности ПО: защищено ли оно от атак хакеров, несанкционированного доступа к данным и т. д.
UX-тестирование (usability testing, юзабилити-тестирование) ― исследование логики и удобства использования ПО.
Подробнее о различных подходах оценки качества ПО вы узнаете из нашего материала по классификации видов тестирования.
Ещё несколько полезных слов
Фиксить (от англ. to fix — исправлять) — вносить правки, исправлять ошибки.
Локаль (от англ. locale — место) — региональные настройки или параметры ПО.
Билд (от англ. to build — строить) — финальный вариант программного продукта или его элемента, который готов к тестированию.
Асайнить (от англ. to assign — назначать) — закреплять за кем-то задачу или часть работы.
В аттаче (от англ. to attach — приложить) — добавлять к письму или сообщению документ. Например, отправить на почту письмо с CV в аттаче означает, что было отправлено письмо с приложенным к нему резюме.
Букать (от англ. to book — бронировать) — резервировать.
Бэкапить (от англ. backup — дублирование) — создавать резервные копии документов или данных на случай их потери или удаления.
Дебаджить, дебажить (от англ. to debug — отлаживать) — настраивать или регулировать работу.
Тул (от англ. tool — инструмент) — программа, которая используется при тестировании.
Фича (от англ. feature — особенность) — некий аспект ПО, который служит его характерной особенностью.
Резюмируем
Мы постарались собрать самые важные слова и понятия, которые будут полезны на старте карьеры в QA. Они облегчат понимание профильной литературы и общение с коллегами. Поможет обогатить лексику регулярное чтение статей про тестирование, тематические блоги и литература.
Но быстрее всего пополнить словарик вы сможете в процессе живого общения во время рабочего процесса. Чтобы уже через несколько месяцев вы смогли реализоваться в QA, записывайтесь на курсы Академии сегодня!
Немного о простом. Тест-дизайн. Часть 1
Сегодня тестирование ПО, один из ключевых процессов создания продукта. Неважно, какую Вы используете методологию, подход, процесс, тестирование ПО так или иначе всегда существует в Вашем процессе. В последние годы (да даже наверное десятилетие) тестирование ПО сформировалось в отдельную область ИТ, которая постоянно развивается в мировом сообществе.
И да, сегодня мы поговорим именно об обычных ручных (функциональных) тестировщиках, без уклона в автоматизацию, нагрузку и другие технические виды тестирования!
Сейчас профессия ручного тестировщика – это одна из самых востребованных процессий ИТ и один из самых простых способов попасть в ИТ.
Потому что тестировщики ничего не делают, им не нужны знания. Тестировать может каждый!
Потому что профессия ручного тестировщика на начальном этапе не требует специфических знаний и умений. Основное «знание» для тестировщика – это умение «разрушать» и аналитическое мышление. А главное – иметь нестандартный склад ума, находить нетривиальные решения поставленных задач. Некий монстр, умеющий крушить и ломать:)
Hard skills всегда можно научить, а вот soft skills к сожалению научить очень сложно, потому что это характер человека, его отношение к чему-либо и т.д. Обычно я косо смотрю на руководителей, которые набирают себе специалистов по ручному тестирования по hard skills. Зачем Вы это делаете. (ответы можете оставить в комментариях) Ну да ладно, продолжим:)
Если рассматривать технические особенности тестирования, которые должен знать ручной тестировщик, то их можно поделить на 2 основных части возможно многие со мной не согласятся, будут кричать как же так, ты не прав, тестирование это очень сложно – это подготовка к тестированию и выполнение тестирования.
Мы с вами рассмотрим самую интересную и увлекательную часть тестирования – подготовку к тестированию. Именно от этой части процесса тестирования зависит то, насколько качественно и правильно вы выполните само тестирования, найдете необходимые дефекты и обеспечите довольное лицо Заказчика (ну или продукт овнера) качество задачи после внедрения.
Многие из вас, кто занимался тестированием, так или иначе, занимался подготовкой к тестированию. Отличие обычно лишь в том, насколько вы этот этап процесса тестирования формализуете. Если вы занимаете исследовательским тестированием, не пишите тестовые сценарии, вам дают систему и вы сразу кидаетесь в бой, все равно, вы готовитесь к тестированию. Зачастую, на несложных проектах, тестировщик может не замечать этого, потому что этап аналитики и подготовки к тестированию проходит у вас на бессознательном уровне. Но даже если так, он все равно есть.
И в этом цикле статей поговорим об этом.
У себя на работе я часто провожу обучения для ручных тестировщиков, и сталкиваюсь с ситуациями, что вроде все слышали о техниках тест дизайна, но в работе их никто не применяет.
Первое, когда тестировщиков учат на курсах по тестированию (или самообучение по книгам и статьям), то им рассказывают, как применять техники тест-дизайна на элементарных примерах. И главная проблема такого обучения, что тестировщики не могут перенести полученные знания на свои реальные задачи. То есть использовать техники тест-дизайна в повседневной работе.
Второе, при обучении техникам тест-дизайна, данный процесс очень формализуется, что выглядит, как необходимость тестировщику в своей работе все формализовать. А обычно это никому не надо времени на это ни у кого нет.
Если говорить простыми словами, то техники тест-дизайна – это совокупность правил, позволяющих правильно определить список проверок для тестирования. И самое важное, это использовать эти правила всегда и везде 🙂 уметь на интуитивном уровне применять данные правила. Именно умение «проводить аналитику в голове» отличает хорошего тестировщика!
В моей организации, как и общепринятых стандартах и практиках, задачами тест-дизайна являются:
А начнем мы с самого простого, а именно о 2-х основных техниках тест-дизайна, про которые все слышали, и я уверен, применяли, но скорее всего на интуитивном уровне в своей работе.
Это классы эквивалентности и граничные значения.
Что же такой классы эквивалентности?
Класс эквивалентности (Equivalence class) – это набор входных (или выходных) данных ПО, которые обрабатываются программой по одному алгоритму или приводят к одному результаты.
То есть, это некое множество значений, которое вы можете подставлять в программу и получать один и тот же результат. Результатом можем быть не только конкретные значения, действия программы, но и просто область применения. Поэтому, самые простые классы эквивалентности, на которые делятся проверки, это 2 основных класса: позитивные и негативные сценарии.
Они есть всегда. Каждый тестировщик делит проверки на эти классы, но не каждый тестировщик знает, почему он это делает. Ответ – классы эквивалентности.
Далее, каждый класс эквивалентности можем разделить на дополнительные классы и т.д. до того момента, пока проверки не будут приводить к точечным и конкретным результатам тестирования.
Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя из его возраста, который вводится в форму:
Позитивными сценариями будут все значения, которые приводят к получению результата, негативными сценариями – значения, результаты которых не описаны, как ожидаемый результат.
Далее мы делим класс позитивных сценариев 3 класса вводимых значений 18-24, 25-44 и 45 +
В классе негативных сценариев мы формируем значения, исходя из необходимости проверки отказов программы, поэтому мы имеем 0, 1-17, отрицательные значения, ввод символов и т.д.
Результатом данного разбиения будет значение или диапазон значений, в котором нам необходимо выполнить всего одну проверку с любым значением из диапазона данных. Могут возникнуть такие ситуации, как одно значение в диапазоне. Это тоже отдельный класс эквивалентности и тоже требует проверки.
Еще одна особенность классов эквивалентности – это их применение. Я выделяю 3 уровня применения техник тест-дизайна для подготовки к тестированию.
Классы эквивалентности в большей степени относятся к 1-му уровню и применяются для проверки элементов программы. Но идеологически, данный подход можно применять и для других уровней.
Неотъемлемой часть проверки любого элемента является другая техника – граничные значения.
Граничные значения дополняют эквивалентные классы, тем самым полностью покрывая проверки элемента ПО.
Граничные значения – техника тест-дизайна, которая дополняет классы эквивалентности дополнительными проверками на границе изменения условий.
Вернемся к нашему примеру ранее.
Система скорринга рассчитывает процентную ставку по кредиту для клиента исходя из его возраста, который вводиться в форму:
Если вы подумали о длине поля на страничке Хабры, или об отпуске в теплых странах, хочу вас расстроить, это не так 🙂
Что определить граничные значения нужно нечто иное. А именно, определить, какие значения являются начальным и конечным для нашего класса. И самое важное. Годы исследований в области тестирования показали, что бОльшая часть дефектов находится тестировщиками именно на стыке значений, которые меняют условия работы программы.
Поэтому, помимо граничного значения мы используем для тестирования дополнительно 2 значения, значение перед границей и значение после границы.
Границы наших классов: 17, 18, 19, 24, 25, 26, 44, 45, 46 и max.
Далее исключаем повторяющиеся значения, и получаем значения для проверки элемента ввода данных.
-1, 0, 1, 17, 18, 19, 24, 25, 26, 44, 45, 46, max.
Значение max обычно уточняется у Заказчика или аналитика. Если не могут предоставить, то следует бросить его и не проверять необходимо подобрать значение, соответствующее здравому смыслу (вряд ли кто-то придет за кредитов в возрасте 100 лет).
Следующий шаг, это наложить граничные значения на значения классов эквивалентности, исключить лишние проверки, пользуясь правилом «достаточно одного значения для проверки одного класса» и финализировать список.
Если ранее у нас были 3 значения для 3-х классов, 19, 30 и 48, то после определения граничных значений, мы можем исключить из списка значения 30 и 48 и заменить их предграничными значениями, такими как 26 (вместо 30) и 46 (вместо 48).
Граничные значения определяются не только для числовых значений, но и для буквенных (например, границы алфавита и кодировки), даты и времени, смысловых значений. Граница числовых значений зависит от формата ввода, если у вас целые числа, например, 2, то граничные значения будут 1 и 3. Если дробные значения, то границы для числа 2 уже будут 1,9 (1,99) или 2,1 (2,01) и т.д.
Техники тест-дизайна 1-го уровня достаточно просты и понятны. Я думаю, вы скажете, да это легко, но зачем досконально проверять каждый элемент. И будете правы.
Чаще всего их применяют при разработке нового ПО, потому что единожды после проверки элементов системы при разработке они в дальнейшем не часто подлежат изменению на уровне работы элемента. Не нужно постоянно проверять каждое значение элемента в каждом экране вашей программы, но имейте ввиду, что если изменяется логика обработки данных в элементах программы, необходимо повторно убедиться в правильности обработки значений элемента.
Что ж, слишком легко. Сейчас начнем разбирать более сложные техники, готовьтесь.
Техники тест-дизайна 2-го уровня отвечают за вариативность и комбинаторику данных при проверке ПО.
Основной техникой тест-дизайна parwise testing (попарное тестирование). Суть техники заключается в минимизации вариативности комбинаций проверок, достаточных для обеспечения высокого качества ПО.
Простыми словами, в данной технике применяется правило Парето, 80 % качества можно достичь всего 20% проверок комбинаций данных.
Данная техника была выведена путем более 15-тилетнего исследования IEEE в области анализа причин возникновения дефектов в системе. Результаты исследования показали, что 98% всех дефектов возникают при конфликте ПАР входных данных или ОДНОГО входного параметра.
Почему же была выбрана пара? Погрузимся в дебри математической статистики и теории вероятности, чтобы найти ответ.
Конечно мы туда не пойдем нынче теория вероятности слишком сложна для простых ИТшников, все просто, возьмем обычную игру в кубик с 6-ю гранями.
Пусть выпадение значения 2 – это дефект, тогда вероятность появления дефекта при кидании кубика равна 1/6=0,167.
Если мы бросаем 2 кубика, то вероятность выпадения 2-х двоек (2 дефекта) становиться ниже и равна 0,167*0,167 = 0,028, для 3-х уже 0,005 и т.д.
Получается, что вероятность возникновения дефекта при комбинации 3-х и более параметров настолько мала, что ее можно отбросить.
Когда мы с вами тестируем программу, всегда есть n количество элементов, которые влияют на результат, например, форма заполнения данных по кредитной заявке. Там есть n количество полей, которые в совокупности дают результат. Именно комбинаторику данных при заполнении полей мы проверяем с помощью попарного тестирования.
Давайте рассмотрим на примере функциональности дистанционного оформления карты в банке.
Если мы внимательно посмотрим, то увидим с Вами пять полей заполнения данных:
Очень ВАЖНО, при использовании техники попарного тестирования, мы не говорим о результате тестирования. Нам важно проверить вариативность данных при заполнении заявки.
Поле ФИО может принимать значения (классы):
Идем дальше, дата рождения, также как и мобильный телефон, серия и номер паспорта можем иметь тоже 3 состояния:
Чтобы проверить все комбинации данной формы нам бы понадобилось сделать свыше 1000 тестов, но используя попарное тестирование нам достаточно всего 9 тестов!
Магия, не думаю:)
Следующий шаг – составление ортогонального массива с комбинациями данных. Самым простым способом составления массива является попарное заполнение данными, начиная с элементов, имеющих наибольшее количество значений и далее по убыванию. Так как в нашем примере есть 4 элемента с одинаковым количеством значений, то мы можем выбрать любую пару.
Мы берем ФИО и серия номер паспорта. Наша задача – перебрать все значения данной пары между собой:
После перебора одной пары, мы создаем другую пару и начинаем перебирать значения (например номер мобильного телефона)
Подключаем следующий элемент и так далее до полного заполнения всей таблицы, которая будет выглядеть так:
Таким образом мы получаем 9 тестов с конкретными классами эквивалентности, которые мы можем вводить для проверки работы вариативности данных для формы. Классы мы можем заполнять конкретными значениями, которым мы получаем с вами используя 1 уровень техник тест-дизайна.
В заключении данной статьи скажу, что рассмотренные техники тест-дизайна покрывают только часть проверок для тестирования программы, а именно проверка корректности работы элементов программы и результата их комбинаций в процессе ее работы. Во второй части мы перейдем к техникам тест-дизайна, позволяющим творить чудеса тестирования тестировать логику работы программы и процессы. Это очень важная составляющая ручного тестирования, и именно ее зачастую Вы тестируете на своей работе!
Артефакты для UX-ёров и команды: что это, зачем нужны и как выбрать
Зачем нужно это знать?
Я UX-дизайнер в большой продуктовой компании, и я очень не люблю правки, а вы уже пролистываете дальше, потому что «так нельзя, ты не художник» и «ничего нового, никто не любит». Я ценю своих коллег, заказчиков и пользователей. Но 10 этапов согласования макетов, где каждый участник высказывается о том, что ему не нравится в дизайне — это не только сложно, но и нерезультативно. Вместо того, чтобы обсуждать продукт, почему им будут пользоваться, а почему — нет, что важно для пользователя, а что — наши собственные домыслы, мы часто уходим в холивары и обсуждение наших вкусов и предпочтений. Это нормальная история для больших компаний: заинтересованных в продукте лиц много, все хотят сделать что-то достойное или принять участие.
Как при этом дизайнеру выдать качественный результат, не растягивать сроки, не обозлиться на весь мир и не сойти с ума?
Мне помогают эвристики Нильсена, пользовательские исследования, интервьюирование заказчика и UX-артефакты. Об артефактах я вам и расскажу. Мой путь скорее подойдёт UX-ёрам в продуктовых компаниях с большим количеством стейкхолдеров, чем веб-дизайнерам из маленьких студий.
В работе над продуктом у нас участвует от 8 до 20 человек: заказчик (часто несколько представителей клиента), продакт оунер, руководитель проекта, бизнесовый и системный аналитики, верстальщик, фронтэнд и бэкэнд разработчики, тестировщики. Все они имеют свой взгляд на то, над чем они работают: хотят сделать как-то классно (у разных людей понятие «классно» отличается), руководители проектов хотят выдержать сроки и бюджет проекта, продакт оунеры хотят повышения всех метрик сразу, разработчики — писать чистый код.
Какова вероятность, что ваше видение продукта совпадёт с видением всех этих людей? Нулевая.
Если вы думаете, что вы дизайнер, и внешний вид продукта — это только ваша вотчина, вы ошибаетесь. Пара неудачных проектов и проблем в общении с командами и заказчиками приведут вас в чувство или помогут понять, что лучше применить свои навыки в какой-то другой сфере.
В нашей компании обязанность дизайнера — удостовериться, что команда и клиент договорились об ожиданиях. Желательно сделать это до того, как появятся макеты. По макетам разбираться в том, как должен выглядеть и работать продукт бывает уже поздно и больно.
Макеты — это всего лишь вершина айсберга и часть работы дизайнера. За ними лежит ещё очень много вопросов, о которых нужно договориться всей команде.
Артефакты — это решение проблемы: с их помощью мы обсуждаем бизнес-цели и пользовательский опыт, дизайнер может опираться на них при защите проекта как на зафиксированные договорённости. По артефактам могут работать другие дизайнеры и члены команды, потому что в основном артефакты говорят на понятном, человеческом языке, а не на языке графики, бизнес-аналитики или кода. Я изучала артефакты в БВШД и по блогу UX-дизайнера Насти Щебровой (спасибо, Настя!) и активно применяю их в своей работе. Их использование спасло мне много нервов и ускорило разработку многих продуктов (хотя кажется, что должно быть наоборот).
Что такое артефакт?
Артефакт — описание продукта с определённой точки зрения по заданному формату. Он помогает договориться всем участникам процесса, но его не увидит конечный пользователь.
Какие бывают артефакты?
Не все артефакты генерирует дизайнер: часть артефактов делает продакт оунер или другие члены команды. Всё, что не является готовым продуктом, — это артефакт, в том числе и макеты в Фигме, и ТЗ.
Хороший UX-ёр работает с такими артефактами
Не все существующие артефакты могут и должны применяться на проекте. Задача в том, чтобы затратив минимум усилий, максимально прояснить картину для всех участников проекта. С опытом вы сможете оценить, какие артефакты нужно использовать для конкретной задачи. Классно попробовать все: вы поймёте, с чем вам комфортно работать, сколько времени и сил занимает составление того или иного артефакта.
Тем, кто пока не сталкивался с артефактами, я предлагаю схему, которую разработала для себя: составляю персонажа или карту эмпатии, прописываю его сценарии, объединяю сценарии в карты сценариев (если продукт новый) или раскладываю на карте путешествия пользователя (если продуктом уже пользуются). По ним рисуем прототипы, тестируем их, снова прототипируем и тестируем до тех пор, пока не будем довольны результатом.
Персонажи
Описывать персонажей можно по-разному, но как правило они состоят из:
Персонажей делают, чтобы:
Как создать персонаж:
Сколько времени занимает
Если вам удастся быстро собрать респондентов и провести с ними интервью, то на это уйдёт 1-2 рабочих дня дизайнера.
Подводные камни
Есть проекты, которые направлены на очень широкую аудиторию. Тогда у них либо слишком много персонажей, либо их сложно выделить. Для таких проектов лучше использовать карту эмпатии или джобз ту би дан (дальше расскажу, чем они отличаются).
Метод персонажей хорошо работает, когда вы работаете с понятной аудиторией и рынком. Но когда нужно придумать передовой продукт, открывать новые рынки и делать то, что до вас ещё не делали, метод персонажей приведёт вас к созданию более быстрых лошадей вместо автомобиля.
Если вы не проверяете персонажей и другие свои гипотезы, вы рискуете очень сильно просчитаться. Помните, что любая непроверенная гипотеза — это лишь плод вашего воображения.
«Мужчины и женщины от 16 до 65 с высоким достатком, которым непременно нужен наш продукт» — это не персонаж, это копипаста плохого маркетолога.
Джобз ту би дан
Невозможно строить продукты будущего, ориентируясь только на запросы и ожидания пользователей от существующего продукта. Хорошие метрики и продажи — это лишь состояние рынка на текущий момент. На какие цифры смотрела компания Эпл, когда убирала кнопки клавиатуры со своих телефонов? На что опирался Генри Форд, когда захотел сделать автомобиль в то время, когда все вокруг просили быстрых лошадей? Люди любили лошадей и кнопочные телефоны, но они больше никому не нужны. Чтобы искать прорывные решения, можно использовать джобз ту би дан.
Что такое джобз ту би дан
В джобз ту би дан не думают о пользователях и их желаниях, не проводят ретроспективные исследования. Это проверка бизнес-гипотезы: сейчас этого нет, мы создаём новый рынок. Продукт, который вы создаёте, решает проблему пользователя — «выполняет работу». Пользователи покупают, то есть «нанимают на работу» ваш продукт, чтобы он сделал их жизнь немного счастливее. Условный Иван Васильевич покупает не телефон с кнопками, а возможность быть на связи с близкими, если копнуть поглубже — то и со всем внешним миром.
Зачем нужны джобз ту би дан:
Формула джобз ту би дан:
Когда (описание ситуации),
Я хочу (мотивация),
Чтобы (результат).
Пример джобз ту би дан
Познакомьтесь с Олегом Ивановым. Ему 28 лет, он один из двух дизайнеров мобильных приложений под Айос в небольшой продуктовой компании. Каждое утро он пьёт кофе, садится за свой Макбук и делает макеты (хотя сначала, конечно, продумывает персон). Иногда работает в кофейне, 3 раза в год ездит в отпуск. Он знает основы Свифта, учился в Британке. Носит крутые свитшоты и цветные носки, ходит на митапы, а по выходным занимается каллиграфией.
И вот Олег покупает себе Фигму для макетов и Миро для дорожной карты продукта. Почему именно такой набор? Почему не Фотошоп или Скетч плюс Люсидчарт? Повлияла ли на его выбор любовь к кофе, цветным носкам и митапам? Нет, скорее повлияло то, что в Фигме и Миро можно работать командно вместе с коллегой. Вот это «работать командно и одновременно онлайн» — и есть джоб ту би дан.
Если мыслить глобальнее, то дизайнер Олег Иванов покупает себе не просто возможность работать командно над макетами и дорожной картой, а возможность быстро получать обратную связь от коллег и работать удалённо из любой точки мира, а не в офисе — то есть более удобные условия работы.
Пример джоб ту би дан
Как создать джобз ту би дан
Так же, как персонажей:
Подводные камни
Джоб ту би дан лучше всего делать на инноваторских продуктах, когда у них есть большая степень неизвестности, или когда персонажей не удаётся выделить или их слишком много.
Карта эмпатии
Карта эмпатии — инструмент визуализации идей, позволяющий поставить себя на место пользователя, взглянуть на проблему его глазами.
Может быть использован как в качестве альтернативы персонажам, так и как дополнение к ним. Карта эмпатии представляет собой схему, в центре которой размещается представитель определенного пользовательского сегмента, по разные стороны от него — 4 блока («думаю и чувствую», «говорю и делаю», «вижу», «слышу»). Выводы приводятся в двух дополнительных блоках: «проблемы и болевые точки» и «ценности и достижения».
Пример карты эмпатии
Зачем использовать
Как создать карту эмпатии
Выводы
Буду очень рада, если вы попробуете поработать с артефактами на практике и поделитесь со мной своими результатами в комментариях.