Виды тестовой документации
Создание тестовой документации является вторым этапом жизненного цикла ПО.
Тестовая документация включает в себя:
- тест план;
- тестовая стратегия;
- чек-лист;
- тестовый сценарий;
- тестовый комплект;
- пользовательская история (User Story);
- отчет о дефекте.
Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Хороший тест план должен описывать следующее:
- Что надо тестировать? Описание объекта тестирования: системы, приложения, оборудования.
- Что будете тестировать? Список функций и описание тестируемой системы и её компонент в отдельности.
- Как будете тестировать? Стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования.
- Когда будете тестировать? Последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки.
Критерии начала тестирования:
- готовность тестовой платформы (тестового стенда);
- законченность разработки требуемого функционала;
- наличие всей необходимой документации.
Критерии окончания тестирования — результаты тестирования удовлетворяют критериям качества продукта:
- требования к количеству открытых багов выполнены;
- выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF);
- выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB).
Преимущества тест плана:
- Возможность приоритезации задач по тестированию.
- Построение стратегии тестирования, согласованной со всей командой.
- Возможность вести учет всех требуемых ресурсов (как технических, так и человеческих).
- Планирование использования ресурсов на тестирование.
- Просчет рисков, возможных при проведении тестирования.
Составляющей частью планирования тестирования (как отдельного документа или же процесса планирования в целом) является стратегия тестирования. Стратегия может быть:
- Частью общего тест-плана.
- Отдельным документом.
Тестовая стратегия определяет то, как мы тестируем продукт. Это набор мыслей и идей, которые направляют процесс тестирования.
В стратегии тестирования описывают:
- Тестовую среду.
- Анализ рисков проекта.
- Инструменты, которые будут использовать, чтобы провести автоматизированное тестирование и для других целей.
- План действий при непредвиденных обстоятельствах.
Стратегия может быть представлена как в виде традиционно расписанного документа, так и в более наглядном формате, например, используя таблицу:
В общем, план тестирования устанавливает цели процесса тестирования, он определяет, что будет проверяться, а стратегия тестирования описывает, как достичь целей, поставленных в плане тестирования.
Пользовательские истории
Пользовательские истории (User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований.
User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
Пользовательская история фиксирует короткую формулировку функции на карточке или, возможно, с помощью онлайн-средства.
Примеры:
- Залогиниться в мой портал мониторинга энергопотребления.
- Посмотреть ежедневный уровень потребления.
- Проверить мой текущий тариф.
Несмотря на то, что стори играют в огромной степени роль, ранее принадлежавшую спецификациям требований (SRS), сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов:
- Они не являются детальным описанием требований (то-есть того, что система должна бы делать), а представляют собой скорее обсуждаемое представление намерения (нужно сделать что-то вроде этого).
- Они являются короткими и легко читаемыми, понятными разработчикам, стейкхолдерам и пользователям.
- Они представляют собой небольшие инкременты ценной функциональности, которая может быть реализована в рамках нескольких дней или недель.
- Они относительно легко поддаются эстимированию, таким образом, усилия, необходимые для реализации, могут быть быстро определены.
- Они не занимают огромных, громоздких документов, а скорее организованы в списки, которые легче упорядочить и переупорядочить по ходу поступления новой информации.
- Они не детализированы в самом начале проекта, а уже более детально разрабатываются «точно в срок», избегая таким образом слишком ранней определенности, задержек в разработке, нагромождения требований и чрезмерно ограниченной формулировки решения.
- Они требуют минимум или вовсе не требуют сопровождения и могут быть безопасно отменены после имплементации.
Структура юзер стори
Текст самой юзер стори должен объяснять роль/действия юзера в системе, его потребность и профит, который юзер получит после того как история случится.
К примеру: Как, , я , .
Правила на написание User Story
- Есть один actor.
- Есть одно действие.
- Есть одна ценность / value / impact.
Actor
Вы выделили персоны, или у вас есть роли, и вы легко их вписываете в начало истории. Есть одна проблема. Убери часть истории про актера. Если история ничего при этом не потеряла — значит эта часть бесполезна.
Джеф Паттон предлагает следующее:
- Разделите всех актеров на группы. Целевая группа, важная группа, менее важная группа и тп.
- Дайте уникальные названия актерам в этих группах. Даже если в системе у них будет одинаковые роли «Пользователя системы».
- Пишите истории с точки зрения этих актеров указывая их уникальные названия.
- В результате вы сможете визуально увидеть какие истории необходимы для актеров целевой группы, какие — для каждой группы и тп. Вы не просто можете использовать это при разборе истории и выстраивания анализа вокруг указанного актера. Вы сможете более правильно выстроить приоритет, так как истории актеров целевой группы для нас более важны.
Действие
Это суть истории, «что нужно сделать». Что можно улучшить. Действие должно быть одно — основное. Нет смысла описывать» авторизуется и выполняется поиск» или «указывает параметры поиска и выполняет поиск». Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне «ЧТО?» делает, а не «КАК?». Это главное в истории. Опишите проблему, а не ее решение. Лучше вы потом с командой это обсудите и найдете более оптимальное «КАК» — решение.
Ценность
Главная проблема с User Story. Вы всегда знаете первую часть истории, но всегда сложно указать для чего это делается. Но это Scrum, все должно быть указано как User story согласно шаблону, и потому вы пишите «чтобы …».
Уберите эту часть из истории. Если ничего не потеряли — значит формализация ценности в истории была бесполезна. Что же можно сделать?
Отказаться от формулировки «чтобы». Для каких-то историй можно указать ценность истории в таком формате, но не для большинства.
Перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на кого актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.
Представим что вы создали историю — «Как инвестиционный аналитик я получаю отчет №17 об инвестициях чтобы БЫСТРЕЕ принять решение».
У меня Аcceptance Сriteria — это метрика на value в US. Как померить такой value? Как понять что аналитик принял решение быстрее? Как вы поймете в конце что история выполнена?
Переделаем историю на влияние — «Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ». То есть сейчас этот отчет формируется за 60 сек. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика.
Практические советы по написанию пользовательских историй
- Лучше написать много историй поменьше, чем несколько громоздких.
- Каждая история в идеале должна быть написана избегая технического жаргона — чтобы клиент мог приоритезировать истории и включать их в итерации.
- Истории должны быть написаны таким образом, чтобы их можно было протестировать
- Тесты должны быть написаны до кода.
- Как можно дольше стоит избегать UI. История должна выполняться без привязки к конкретным элементам.
- Каждая история должна содержать оценку.
- История должна иметь концовку — т.е. приводить к конкретному результату.
- История должна вмещаться в итерацию.
Пример юзер стори:
продолжение:
Источник
Как сделать хороший тест: 10 правил
А еще примеры и шаблоны
Содержание
Как только у вас родилась идея теста, сформулируйте черновой заголовок. Во-первых , если короткий и понятный заголовок не будет получаться, то это признак, что с вашей идеей что-то не так или тема для теста слишком сложная, — это повод доработать идею. Во-вторых , так вам будет проще понять, о чем именно будет тест. Это поможет определиться с тем, как лучше всего выстроить тест с точки зрения логики, какие именно нужны вопросы и результаты, и отсечь все лишнее. Лучше всего, когда в заголовке есть вопрос и читатель хочет узнать на него ответ. Еще лучше, когда заголовок касается конкретно человека и мы предлагаем узнать читателю что-то о себе: все любят узнавать себя.
Наверняка вы не хотите делать тест ради теста. А хотите чего-то большего:
- донести до читателей определенную мысль;
- достичь своих целей.
С первым все ясно: читатель должен пройти тест и узнать что-то новое или о чем-то задуматься. Например, о своих личных предпочтениях или о том, как на самом деле устроена жизнь вокруг:
Со вторым тоже все просто. Цель может быть прикладной — например, мы хотим ненавязчиво рассказать о нашем курсе по инвестициям. Тут все понятно: на заголовок кликают люди, которые интересуются темой и хотят узнать про себя что-то новое. Получают развлекательный контент и в конце узнают о курсе.
Или, наоборот, цель может быть более призрачной — например, нам важно писать про бизнес. У нас есть целый раздел про это, мы хотим подогревать интерес к теме разными способами: тот, кому пока скучно читать длинный текст, возможно, клюнет на что-то развлекательное. Скорее всего, человеку выпадет хороший результат, мы заложим в его голову идею, и, вероятно, в следующий раз он уже созреет для более серьезных форматов.
Чтобы результаты теста выглядели убедительно, нужно придумать, на чем именно будут основаны ваши расчеты. Вам может казаться, что вы делаете максимально шуточный тест и придумывать какое-то обоснование необязательно. Но чаще всего это заметно, и у читателей возникнут вопросы:
В некоторых тестах результат можно выдавать рандомно. Подумайте, насколько такое решение уместно в конкретном тесте: оно должно выглядеть как фича, а не баг.
Примеры разных видов логики:
- «Какой вы миллиардер из кино?» — мы взяли список богатейших выдуманных персонажей «Форбса», выбрали из них киногероев, изучили их биографии, нашли пересекающиеся моменты и спрашиваем у человека, какая из описанных ситуаций больше похожа на его. В результатах рассказываем читателю краткую сводку о персонаже, с чьей биографией было больше всего пересечений, сумму его состояния и выделяем положительные свойства характера.
- « Относитесь ли вы к среднему классу?» — лучше всего, когда тест опирается на проверенный источник, будь то соцопрос или список «Форбса». В этом случае мы взяли несколько исследований, посвященных среднему классу, и сделали из них тест. Еще в тестах с такой логикой можно предлагать читателю проверить, насколько хорошо он разбирается в какой-то теме. Например, в зарплатах россиян или их мнениях по самым разным поводам.
- « Знаете ли вы, как супермаркеты нарушают ваши права?» — пример полезного теста на тему конкретной проблемы. Мы собрали случаи супермаркетного произвола, нашли законодательные акты, регулирующие эти ситуации, и предлагаем читателям рассказать, как бы в этих ситуациях они себя повели, и заодно узнать, на чьей стороне закон.
- «Финансовые предсказания: что вас ждет в следующем году?» — здесь результаты как раз распределяются более-менее рандомно, цель таких тестов — порадовать читателя, сказать ему что-то приятное, подбодрить. Но логика в распределении результатов все равно присутствует.
Бывают тесты, в которых главное — результаты. Бывают тесты, в которых главное — вопросы. Здесь важно продумать, как правильно расставить акценты, чтобы и читатель был доволен, и вы рассказали людям все, о чем хотели.
- «Насколько хорошо вы питаетесь по сравнению с другими россиянами?» — в этом тесте важны вопросы. По сути, мы интерактивным способом рассказываем человеку о том, что известно статистике о пищевых пристрастиях россиян. Поэтому после ответа на вопрос мы даем уточняющую расшифровку и ссылку на источник. Обязательно собирайте все пруфы!
- «Какой страны вы достойны?» — а в этом тесте интереснее результат. Мы собрали 5 профайлов разных стран, основываясь на статистике, реальных ценах и культурных особенностях. Спрашиваем читателей об их предпочтениях, вкусах и привычках и делаем вывод, где условия для всего этого благоприятнее.
10 вопросов всегда лучше, чем 15, а 7 — лучше, чем 10. Можно пойти еще дальше и сделать тест из двух вопросов — и даже из одного! Все зависит от цели и от того, что в вашем тесте главное, — не стоит прятать это слишком далеко.
Также старайтесь соблюдать баланс: если вопросов много, то пусть и вопросы, и варианты ответов будут максимально короткими. Если вопросов мало, то можно себе позволить сделать вопросы или варианты ответов подлиннее. Варианты с картинками выбирать проще, даже если на этих картинках написан текст. Конечно, это не всегда возможно. Просто помните об этом и стремитесь к идеалу.
Старайтесь формулировать вопросы емко, убирайте лишние подробности. Избегайте длинных придаточных и громоздких фраз. Ваш вопрос должен быть понятным и конкретным.
В идеальном мире текст результата всегда должен отвечать на вопрос в заголовке. Человек заинтересовался вопросом в заголовке и хочет получить на него ответ. А если ответа нет, то, вполне вероятно, человека постигнет разочарование. Это не те эмоции, которые нужно получать от тестов.
Желание увидеть результат — это главное, почему человек проходит наш тест. Проходить тест трудно. Нужно думать, читать и нажимать на кнопки. Кнопок бывает много: узнать правильный ответ, перейти к следующему вопросу, узнать результат. Это активное потребление контента. Поэтому в тестах результат — это награда. Если человек получит слишком короткий или неинтересный результат, он также будет разочарован. У него останется ощущение, что результат не стоил затраченных усилий. Поэтому к результатам надо отнестись внимательно и сделать их с любовью.
Если человек получил удовольствие от прохождения теста и от его результата, он становится довольно лояльным пользователем и благосклонно отнесется к нашему предложению продолжить вечеринку. Поэтому при создании теста мы сразу думаем о том, что еще предложить читателю. Мы можем предложить пройти еще один тест или прочитать текст по теме. В каждом результате может быть что-то уникальное: например, если человек показал слабый уровень знаний по какому-то предмету, мы можем отправить его читать про азы, а если высокий — проходить более сложный тест. Или во всех результатах может быть ссылка на что-то одно. Все зависит от цели.
- «Какой ваш финансовый возраст?» — здесь в каждом из восьми вариантов результатов читателю предлагаются разные тесты в зависимости от контекста.
- «В какую теплую страну вам пора переехать?» — здесь мы сопроводили каждый результат ссылкой на статью про конкретную страну.
- «Какой вы модератор Т—Ж ?» — здесь тоже восемь вариантов результатов, но в рекомендациях — один и тот же тест.
Тесты — это развлекательный формат. Возможно, читателю скучно и он хочет развлечь себя. Возможно, у читателя был тяжелый день и он хочет отвлечься. Но он точно не хочет прочитать что-то неприятное про себя. Поэтому старайтесь даже в самых плохих результатах описывать недостатки мягко, упоминайте возможные сильные стороны и добавляйте во все это самоиронии и дружеского подмигивания.
Помните, что и механики тестов, и сама концепция таких тестов построены на допущениях — мы даем очень приблизительный результат. Кроме того, продумать абсолютно все довольно тяжело и весьма вероятно, что где-то в вашей логике найдется слабое место. Поэтому нужно максимально застраховать себя от провалов. Если вы сами чувствуете, что халтурите или чересчур притягиваете нечто за уши, убирайте: это однозначно заметят.
Используйте слова: «возможно», «вероятно», «кажется» и так далее. Старайтесь не упоминать в результатах конкретные вещи, если механика теста не гарантирует вам, что читатель выбрал определенный результат. Зачастую бывает так: один из вариантов ответа — «обожаю хот-доги», читатель фыркает про себя, выбирает другой ответ, но по ответам в других вопросах оказывается, что он должен основать компанию по производству сосисок. Поэтому результат нужно завуалировать таким образом, чтобы даже тем, кто не любит хот-доги, было понятно, почему им выпал такой результат. Добавляйте в описание результата примеры не из вопросов, а другие, из жизни, которые расширяют картину.
Помните, что правила созданы, чтобы их нарушать. Если вы понимаете, что какое-то правило противоречит вашей идее или цели, и вы знаете, как сделать лучше, — делайте. Но сначала согласуйте все с редактором: возможно, он уже сталкивался с подобным и знает, как поступить, или просто поможет найти решение.
Виды тестов
Тесты-квизы: с правильными и неправильными ответами:
Источник
