Все мы не раз сталкивались с понятием целевой аудитории. В последнее время это словосочетание все чаще используется в качестве одной из характеристик организации, товара или услуги. И действительно, в любом бизнесе действует простая и очевидная схема: для любого продукта есть свой пользователь. Несомненно, это правило затрагивает и ПО. В этой статье я предлагаю обсудить довольно сложный вопрос: чем знание целевой аудитории поможет при оценке степени несоответствия заложенных ожиданий реальным по отношению к тестируемому продукту?
Прежде всего разберемся, что же такое целевая аудитория (в дальнейшем – ЦА). В соответствии с определением из Британского бизнес-словаря, целевая аудитория (англ. target audience) – это группа людей или сегмент рынка, для которого предназначен продукт, услуга, веб-сайт, реклама, телевизионная или радио программа и т. д.
Если не вникать в суть вопроса, то может показаться, что ЦА – это некая общность потенциальных потребителей или покупателей продукта. На практике все обстоит далеко не так просто, и подтверждение тому – огромное количество несостоявшихся проектов, владельцы которых при запуске ожидали увидеть ажиотажный спрос на свое детище. Причиной провала во многих случаях являлась в том числе не соответствующая реальности оценка ЦА.
Для чего нам нужно знать целевую аудиторию проекта?
Знать и понимать ЦА важно на каждом этапе разработки программы. Может ли разработчик приложения-мессенджера, к примеру, не учесть, что продуктом могут воспользоваться слабовидящие пользователи, для которых нужны специальные возможности? Запросто!
При проектировании сайта важно не только добиться привлекательного оформления страниц, но и обеспечить пользователю простое и понятное выполнение пользовательских действий (например, сделать процесс поиска товара легким и очевидным). На этом этапе тщательное изучение ЦА является обязательным. Оно необходимо для того, чтобы понять, почему пользователь не выполняет ожидаемых от него действий и не реализует цель нахождения на сайте (или использования продукта).
Нефтепереработка все сильнее адаптируется к цифровому веку, и это приводит к большей зависимости от ПО, автоматизированных трудовых процессов и облачных технологий. Парное тестирование становится обычной практикой с целью убедиться в качестве ПО, поддерживающего нефтепереработку – например, цифровой симулятор резервуаров, геологические инструментв, и так далее. Также оно помогает комбинировать знания, использовать различные перспективы, и улучшает коммуникацию, делая процесс тестирования более эффективным. Эта статья описывает некоторые преимущества, которых можно достичь при помощи парного тестирования ПО нефтеперерабатывающей индустрии, и в большинстве случаев это применимо к другим областям и приложениям.
2. Преимущества, связанные с дележкой знаниями.
Одна из основных областей, в которых парное тестирование приносит большую пользу – это дележка знаниями. Ниже перечислены достоинства парного тестирования для нефтеперерабатывающей отрасли:
В одну команду были объединены тестировщики с разным техническим опытом (технические эксперты по нефти, математики, компьютерные инженеры, и т. д.), которые, следовательно, смогли предоставить спектр перспектив и подходов к тестированию.
В одну команду были объединены тестировщики с разным уровнем опыта. Сочетание новых инновационных взглядов со зрелыми опытными умами может дать отличные результаты в плане качества поддержки новой функциональности.
Более тесное взаимодействие с разработчиками и командами портфолио и менеджмента. Два тестировщика создают больше каналов коммуникации, чем один, позволяя знаниям эффективнее распространяться между командами и повышая эффективность разработки.
Сочетание различных практик тестирования. Процесс тестирования может быть разделен между двумя тестировщиками различными способами: одновременное тестирование одной и той же фичи, одновременное тестирование разных фич, тестирование частей одной и той же фичи и ее зависимостей, и т. д. Парное тестирование – это отличная возможность комбинировать различные практики и подходы к тестированию.
Несколько месяцев назад мой коллега Макс прислал мне заинтересовавшую его ссылку со списком когнитивных искажений человека. Читая описания разнообразных ловушек мышления, я понимала, что вижу проявления многих из них как в повседневной жизни, так и на работе. Изучив вопрос, решила поделиться с коллегами: впервые статья вышла на английском языке в журнале компании Logeek Magazine, сейчас же я хочу поделиться с более широкой аудиторией, разместив на DOU.
«You should work to reduce your biases, but to say you have none is a sign that you have many» — Nate Silver
Существует прямая связь восприятия человека с образом его мыслей, мнением относительно различных ситуаций. Не всегда мышление и мнения человека объективны — в них могут наблюдаться систематические ошибки и отклонения. При возникновении подобных отклонений видимого от реального, говорят о ловушках мышления или же, научным языком, о когнитивных искажениях.
Ловушками мышления называют стандартные, шаблонные отклонения в мышлении человека, основывающиеся на деформированных убеждениях.
Люди живут в собственной реальности, основанной на их восприятии окружающей действительности. Именно на этой реальности базируется их поведение и взаимоотношения с окружающими. Часто причиной нелогичного поведения, неверных выводов и нелогичных интерпретаций являются именно присущие людям ловушки мышления.
Программное обеспечение неизменно создается людьми, тестируется людьми и, в большинстве случаев, используется людьми. И каждый человек в этой цепочке подвержен собственным когнитивным искажениям.
Многие современные компании, разрабатывающие ПО, настолько завалены проблемами качества, что это мешает им развивать бизнес. Они демонстрируют весь спектр классических симптомов перегруженных организаций – нехватку понимания проблем, нехватку понимания, что происходит, и ряд характерных поведенческих шаблонов и ощущений. Менеджмент, возможно, не связывает подобную перегрузку и проблемы качества, проявляющиеся в крупных, сложных системах. Если это так, то все, что они делают, только вредит делу. Чтобы исцелить или предотвратить подобную болезнь, менеджменту нужно понимать системную динамику качества.
Симптомы перегрузки, связанные с плохим качеством
В работе консультанта нас часто просят спасти проекты по разработке ПО, которые каким-то образом вышли из-под контроля. Организации внезапно погрузились в постоянное состояние кризиса, а менеджменту, кажется, не удается найти первопричину всех этих симптомов. Очень часто центральная причина – это перегрузка из-за нехватки качества продукта, и нехватка качества продукта из-за перегрузки.
Наша первоначальная задача, как консультантов – изучение симптомов. Мы классифицируем симптомы перегрузки на четыре разные категории – непонимание существования проблемы, непонимание, что происходит, характерные поведенческие шаблоны и чувства. Прежде чем описать динамику этих симптомов, давайте посмотрим на некоторые из них на примере компании АБВ.
Как часто мы сталкиваемся с проблемой, что проведя аудит процесса тестирования наши рекомендации носят достаточно общий характер. А еще хуже, когда мы внедряем новые решения, подходы, но они не дают нужного нам результата, что приводит к появлению недоверия со стороны руководства к руководителям отделов тестирования или аудиторам.
Очень часто основной причиной таких проблем является неправильное понимание менеджером поставленной задачи, и как следствие, неправильный выбор подхода для проведения аудита.
Для начала мы немного опустимся в основы процессов и попробуем понять, как должен существовать любой процесс.
Любой процесс, неважно, разработка это или тестирование, сопровождение, управление качеством и т.д., всегда должен быть цикличен. Существуют 4 основных подхода к работе с процессами, и самый популярный из них, это уже общепризнанный цикл Демминга. Именно на его основе строится работа процесса и все другие методологии, такие как DMAIC (6 сигм), IDEAL, EFQM, которые всегда говорят нам о том, что нужно не только требовать выполнение процесса, но и постоянно его анализировать и непрерывно совершенствовать. Эти модели позволяют нам понять, как мы должны работать с процессом, и самое главное, мы должны всегда видеть проблемы нашего процесса и стараться их решить.
Говоря о тестировании, существуют 2 основополагающих подхода к совершенствованию процесса тестирования, это MBI и ABI.
MBI или Model Based Improvement — подход к совершенствованию процесса тестирования, который основан на референтных моделях совершенствования процесса тестирования. Модели могут быть процесcные, такие как TMMi, TPI и контекстные, такие как STEP или CTP. Эти модели позволяют нам на основе практик строить наш процесс тестирования по конкретным шагам, тем самым развивая процесс тестирования равномерно и последовательно.
Но подходят ли нам такие модели для аудитов уже существующих процессов?
Отрасль тестирования и обеспечения качества сильно эволюционировала за несколько последних десятилетий. С появлением конкуренции на рынке появилась необходимость в тестировании. Сначала это были тестировщики-мартышки, нажимающие на кнопки и нечаянно находящие некоторые ошибки в продуктах. После появились тестировщики-аналитики, создающие модели тестируемого ПО и обеспечивающие более высокие уровни тестового покрытия.
Но и этого оказалось мало для нужд рынка: стали появляться различные инженерные и процессные практики, направленные на обеспечение качества: TDD, Code Review, QA, Model-based testing, и т.д. В обеспечение качества оказалась вовлечена вся команда, а не только выделенные специалисты по тестированию.
В своём докладе я хочу рассказать о ступенях эволюции тестирования, уровнях обеспечения качества, и рассмотреть наиболее эффективные решения по обеспечению качества.
Доклад рассчитан не только на специалистов по тестированию, но и на всех вовлечённых в продуктовую разработку профессионалов. Только вместе мы делаем этот мир качественнее!
Выступление Таисии Рыбак на конференции CEE SECR “Разработка ПО”, осень 2016.
Основная проблема в переходе к CI- это неготовность людей и процессов к ускорению. В докладе рассмотрены примеры плавного перехода и внедрения процессов и приведены примеры набора инструментов, которые помогают плавно перейти от хаоса к непрерывной разработке.
Одно из преимуществ возраста – это возможность взглянуть на историческую перспективу, чего очень не хватает миру разработки программного обеспечения. Давным-давно я писал статью про опасность хороших оценок. Теперь мне интересно, сбылись ли мои предсказания.
В те времена Том ДеМарко послал мне бесплатную копию своей книги "Контроль проектов разработки: менеджмент, измерение и оценки". К несчастью, я положил ее в сумку велосипеда вместе с куском барбекю, и произошел казус. Том, щедрой души человек, подарил мне еще одну копию.
Благодаря щедрости Тома я почувствовал себя обязанным прочитать книгу, которая была довольно хороша и без дополнительного соуса. В ней Том осторожно сообщает, что разработка ПО далека от зрелости, и поэтому меня удивил выход его статьи "Разработка ПО: достижение совершеннолетия". Неужели меньше чем за год наша отрасль таки достигла зрелости?
Как оказалось, заголовок был авторской неточностью, если судить по этой цитате:
"Для того, чтобы бизнес разработки ПО достиг зрелости, нам нужно улучшить наши расчеты. В течение последних двух лет были заложены основы внятной дисциплины оценивания…"
Статья была вовсе не про зрелость разработки ПО – это был скорее обзор состояния оценок и метрик в отрасли. Проведя обзор работ Барри Боэма, Виктора Базили, Каперса Джонса и Лоуренса Патнама, ДеМарко сообщает, что эти работы:
"…описывают структуру анализа количественных параметров проектов разработки. Но ни один из этих авторов не говорит о том, как именно эта структура отвечает на практический вопрос – как мне организовать бизнес и управлять проектами, чтобы поддерживать достаточный уровень контроля за количественными параметрами?".
Как я уже говорил, Том щедрый человек, и он еще и очень умен. Если он не уверен в прогрессе мира разработки, я скорее поверю ему, чем автору заголовка. В те годы наша отрасль была далека от зрелости.
Что это вообще значит, "достичь зрелости"? Когда ты достигаешь зрелости, ты не заляпываешь соусом от барбекю свои книги. Ты также перестаешь хвастать своими способностями. Вообще если вы слышите, как кто-то похваляется собственной зрелостью, то будьте уверены, что до зрелости ему далеко. Тот же критерий можно применить и к разработке ПО, которая хвалится своей зрелостью уже более сорока лет.
Как наладить процесс тестирования при больших объемах работы? Как упорядочить свои задачи, не подвергая опасности качество продукта?
Скорее всего эти вопросы не раз задавали себе люди, тестирующие сразу несколько продуктов. Или те, кто работают с часто и быстро меняющимся продуктом. Перед ними стоит вопрос не только как успешно организовать свою работу, но и какие инструменты и техники тестирования при этом использовать.
На конференции SQA Days 19 наши коллеги делились тем, как они изменили рабочий процесс на своих проектах, чтобы добиться лучших результатов в тестировании.
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
DevOps - это не только модное слово, которое сейчас на слуху. DevOps - это подход к работе, помогающий активно взаимодействовать командам программистов, тестировщиков и админов, которые чаще всего изолированы друг от друга.
Какие проблемы решает DevOps? Чем это отличается от привычных ролей в сфере IT?
Давайте послушаем тех участников конференции SQA Days 19, кто уже на практике применил данную методологию и может поделиться результатами. Ниже вы сможете найти видео их выступлений.
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
Автор: Виктория Юркевич
Автор: Мелвин Салазар (Melvin Salazar)
Автор: Алёна Соколова
Автор: Джеральд Вайнберг (Gerald Weinberg)
Автор: Джеральд Вайнберг (Gerald Weinberg)