Эвристики и мнемоники
Эвристики - это быстрые, недорогие способы решения проблемы или принятия решения. В мире тестирования ПО мы можем использовать эвристики как выведенные опытным путём подсказки для принятия решений и решения проблем в ходе тестирования. Они могут быть особенно полезными для генерации предположений, если мы не уверены, как начать тестирование, или исчерпали идеи, что делать дальше.
Мнемоника - это тип эвристики, набор правил и приемов, которые помогают эффективно запоминать необходимые сведения (информацию), обычно это слово-аббревиатура или фраза. Например, все помнят детскую мнемонику “каждый охотник желает знать где сидит фазан”, в которой по первым буквам каждого слова можно вспомнить порядок цветов радуги.
Множество известных тест-эвристик использует мнемоники и широко распространено заблуждение, что у эвристик должна быть мнемоника, или что это одно и то же. Это не так. Эвристики не требуют мнемоник, они просто создаются таким образом, чтобы их было легче запомнить.
Эвристики и мнемоники могут быть придуманы, модифицированы и скрещены как удобно автору для своих нужд. Вот наиболее известные:
I SLICED UP FUN: Для тестирования мобильных приложений;
COP FLUNG GUN: Еще одна;
MOBILE APP TESTING: И еще одна;
SPIES: Для тестирования локализации;
PAOLO: Тестирование мобильных приложений и смены ориентации экрана;
GO DaRE=M: Для составления тест-плана;
PAPAS BE @ SFO: Мнемоника для API-тестов функционала;
DEED HELP GC: Еще одна мнемоника по API-тестам;
DVLA PC: Для поддержки API-тестов;
ICE OVER MAD!: Мнемоника по тестированию API;
INVEST: Атрибуты хорошей юзер-стори;
CIRCUS MATTA: Для ревью пользовательских историй;
CAN I USE THIS: Для тестирования Usability;
SAQSII meeting: Для улучшения эффективности любого собрания;
SFPDO & SFDIPOT: Для знакомства с продуктом, новых тест-идей и т.п.;
RCRCRC: Для регрессионного тестирования;
CRUSSPIC STMPL: Эвристика качественных характеристик системы;
FEW HICCUPS: Тестовые оракулы;
RIMGEA: Для описания багов;
MOCHA: Описывает стиль собеседований для найма тестировщиков
HEENA: Для тестирования сложных продуктов;
SCAMPER: Для того, чтобы задать вопросы по продукту, которые принесут креативные идеи и кейсы;
DUFFSSCRA: Для техник тестирования;
MCOASTER: Для составления баг-репортов;
FAILURE: Для составления грамотных сообщений об ошибке;
W5HE (WWWWWH/KE): Для анализа требований;
PROOF: Для написания тестового отчета после сессионного тестирования;
GRATEDD SCRIPTS & B GRADED SCRIPTTS: Для тестовой стратегии;
CIDTESTD: Для высокоуровневого планирования процесса тестирования;
MAC RUSS: Для приемочного тестирования;
SACKED SCOWS: Для обучения;
MR.Q COMP GRABC R&R: Для проведения исследовательского тестирования;
FCC CUTS VIDS: Эвристика тестовых туров;
SLIME: Эвристика приоритетов для тестирования;
CCD IS EARI: Основные принципы нагрузочного тестирования;
IVECTRAS: Классификация нагрузочных тестов;
FIBLOTS: Модель нагрузки для нагрузочного тестирования;
RSTLLL: Эвристика тестирования сообщений, отправляемых приложением;
MUTII: Эвристика для тестирования;
Расшифровка, больше вариантов и дополнительные ссылки в первом источнике.
Эвристики окончания тестирования (когда пора прекратить тестировать продукт):
Эвристика «Время вышло!». Для многих специалистов по тестированию это наиболее распространенная эвристика: мы останавливаем тестирование, когда заканчивается выделенное на него время. Получили ли мы информацию, которую нам требуется знать о продукте? Не слишком ли высок риск прекращения тестирования? Не был ли срок искусственным, произвольным? Будет ли выполняться дополнительная разработка, которая потребует дополнительного тестирования?
Эвристика пиньяты (The Piñata Heuristic). Мы прекращаем ломать программу, когда начинают выпадать конфеты - мы останавливаем тестирование, когда видим первую достаточно серьезную проблему. Не застряло ли в ноге пиньяты еще несколько конфет? Является ли первая серьезная проблема самой важной? Единственной, о которой стоит беспокоиться? Не найдем ли мы другие интересные проблемы, если продолжим тестирование? Что если наше ощущение «серьезности» ошибочно и проблема не столь грандиозна?
Эвристика «мертвой лошади» (The Dead Horse Heuristic). В программе слишком много ошибок, так что продолжение тестирования не имеет смысла. Мы знаем, что все изменится настолько, что сведет на нет результаты текущего тестирования. Здесь мы предполагаем, что уже найдено много интересного и важного. Если мы сейчас остановимся, не пропустим ли мы что-то еще более важное или более интересное?
Эвристика «Задание выполнено» (The Mission Accomplished Heuristic). Мы останавливаем тестирование, когда найдены ответы на все поставленные вопросы. В процессе нашего тестирования могут возникнуть новые вопросы. Это приводит нас к эвристике Рамсфелда (Rumsfeld Heuristic): «Есть то, про что мы знаем, что мы это не знаем, и есть то, про что мы не знаем, что мы этого не знаем». Достаточно ли неизвестных переместило наше тестирование в область известного? Обнаружило ли наше тестирование новые неизвестные? И сложный для разбора, но важный вопрос: удовлетворены ли мы тем, что мы переместили достаточно неизвестных неизвестных в область известного или по крайней мере сделали их известными неизвестными.
Эвристика «Отмена задания» (The Mission Revoked Heuristic). Наш клиент сказал нам: «пожалуйста, прекратите тестирование». Это может произойти по причине перерасхода бюджета, или вследствие отмены проекта, и по любой другой причине. Какова бы ни была причина, нам поручили остановить тестирование. (На самом деле эвристика «Время вышло!» может быть частным случаем более общей «Отмены задания», в том случае, если предпочтительнее, чтобы не мы сами, а заказчик принял решение о том, что время вышло.) В достаточной ли степени наш клиент осознает ценность продолжения тестирования или риски прекращения? Если мы не согласны с клиентом, то в достаточной ли мере мы осознаем бизнес-причины приостановки тестирования?
Эвристика «Я зашел в тупик!» (The I Feel Stuck! Heuristic). По какой бы то ни было причине мы останавливаемся, поскольку обнаруживаем некое препятствие. У нас нет информации, которая нам требуется (например, многие люди заявляют, что не могут тестировать без достаточного количества спецификаций). Имеется блокирующая ошибка, и таким образом мы не можем перейти в ту область продукта, которую необходимо протестировать, у нас нет необходимого оборудования или инструментария, у команды нет квалификации, требуемой для выполнения некоторых специальных тестов. Существует масса способов выйти из тупика. Может быть, нам нужна помощь, а может быть нам просто надо сделать перерыв (смотрите ниже). Может быть, продолжение тестирования позволит нам получить требуемые знания. Может быть, вся цель тестирования и заключается в исследовании продукта и получении недостающей информации. Возможно, имеется путь, позволяющий обойти блокирующую ошибку; возможно инструменты и оборудование имеются, но мы просто не знаем о них или никогда не задавали правильных вопросов тем, кому надо; возможно имеются доступные для нас эксперты - в команде тестирования, среди программистов или на стороне бизнеса - и мы этого просто не знаем. Есть разница между ощущением тупика и нахождением в тупике.
Эвристика «освежающей паузы» (The Pause That Refreshes Heuristic). Вместо прекращения тестирования мы приостанавливаем его на некоторое время. Мы можем остановить тестирование и сделать перерыв, когда мы устали, когда нам стало скучно или пропало вдохновение. Мы можем сделать паузу на то, чтобы выполнить некоторые исследования, разработать планы, поразмыслить над тем, что мы делали в прошлом и понять, что делать дальше. Идея заключается в том, что нам требуется определенный перерыв, после которого мы сможем вернуться к продукту со свежим взглядом или свежими мыслями. Также есть и другой вид паузы: мы можем остановить тестирование какой-либо функции, поскольку в настоящий момент другая имеет более высокий приоритет. Конечно, мы можем чувствовать себя уставшими, нам может быть скучно, но не нужно ли проявить упорство и продолжить двигаться вперед? Не получится ли изучить требуемое в процессе работы с программой, вместо того, чтобы делать это отдельно? Не найдется ли тот критичный бит информации, которого нам не хватает, благодаря лишь еще одному тесту? Является ли функция с «более высоким приоритетом» действительно более приоритетной? Готова ли она к тестированию? Не протестировали ли мы ее и так уже достаточно?
Эвристика «Отсутствие продвижения» (The Flatline Heuristic). Что бы мы ни делали, мы получаем тот же самый результат. Это может происходить в случае, когда программа падает определенным способом или перестает отвечать, но также мы можем не продвигаться, когда программа в основном ведет себя стабильно: "выглядит хорошо!" Действительно ли приложение упало или, возможно, оно восстанавливается? Не является ли отсутствие отклика само по себе важным результатом тестирования? Включает ли в себя понятие «что бы мы ни делали» достаточное разнообразие вариантов или нагрузок, чтобы покрыть потенциальные риски?
Эвристика Привычного завершения (The Customary Conclusion Heuristic). Мы останавливаем тестирование тогда, когда мы обычно останавливаем тестирование. Имеется протокол, задающий определенное количество идей для тестирования, или тест-кейсов, или циклов тестирования, или как вариант - имеется определенный объем работ по тестированию, который мы выполняем и после этого останавливаемся. Agile-команды, например, часто применяют такой подход: «когда выполнены все приемочные тесты, мы знаем, что продукт готов к поставке». Эвальд Руденриджс (Ewald Roodenrijs) приводит в своем блоге пример этой эвристики в статье «Когда прекращать тестирование». Он говорит, что он останавливается, «когда выполнено определенное количество тестовых циклов, включая регрессионное тестирование». Отличие от эвристики «Время вышло!» в том, что временные ограничения могут изменяться более гибко, чем некоторые другие. Поскольку в большинстве проектов главенствует именно график проекта, и у меня и у Джеймса заняло некоторое время осознание того, что эта эвристика также очень распространена. Иногда мы можем слышать фразы типа «один тест на требование» или «один положительный и один отрицательный тест на требование», в качестве соглашения для определения «достаточно хорошего» тестирования. (Конечно же, мы не согласны с этим, но мы слышим это). Достаточно ли мы задумываемся о том, почему мы всегда останавливаемся на этом? Не должны ли мы на самом деле провести дополнительное тестирование? Или наоборот наше тестирование избыточно? Нет ли у нас информации - например, от службы технической поддержки, от службы продаж, от внешних рецензентов - которая подсказала бы, как нам изменить наши шаблоны? Рассмотрели ли мы все прочие эвристики?
Больше нет интересных вопросов (No more interesting questions). В этот момент мы решаем, что не осталось вопросов, ответы на которые были бы достаточно ценными, чтобы оправдать стоимость продолжения тестирования, и поэтому мы останавливаемся. Эта эвристика используется в основном как дополнение к другим эвристикам, помогая принять решение о том, есть ли какие-то вопросы или риски, которые отменяют действие этих эвристик (примеры таких вопросов я привожу после каждой эвристики). Кроме того, если одна эвристика советует нам прекратить тестирование, следует проверить, нет ли интересных вопросов или серьезных рисков в других областях, и если они есть, то мы скорее продолжим тестирование, чем остановимся. Что мы думаем о наших моделях рисков? Нет ли опасности недооценки или наоборот переоценки риска, не случилось ли так, что мы не заметили Чёрного лебедя (а может быть даже Белого лебедя)? Достигли ли мы достаточного покрытия? Достаточно ли тщательно мы проверили свои оракулы?
Эвристика уклонения/безразличия (The Avoidance/Indifference Heuristic). Иногда людей не интересует дополнительная информация, либо они не хотят знать, что происходит в программе. Тестируемое приложение может быть первой версией, которую, как мы знаем, скоро заменят. Некоторые люди прекращают тестирование по причине лени, злого умысла или отсутствия мотивации. Иногда бизнес-критичность выпуска нового релиза настолько высока, что никакая мыслимая проблема не остановит выход программы, и поэтому никакие новые результаты тестирования не будут иметь значения. Если это безразлично нам сейчас, то почему мы вообще тестировали? У нас сменились приоритеты? Если кто-то закончил работу, то почему? Иногда компанию меньше беспокоит незнание о существовании проблемы, чем знание и отсутствие действий по ее устранению - не может ли это быть нашим случаем?
Дополнение: Кем Канер (Cem Kaner) предложил еще одну эвристику: «Отказ от выполнения задания» (Mission Rejected), в которой тестировщик сам отказывается от продолжения тестирования.
Источники:
Доп. материал:
Last updated