Немного про тестовые эвристики

Майкл Болтон Читатель, сегодня мы с тобой поговорим о тестовых эвристиках.

Будучи человеком любознательным и встретившись впервые (в какой-то англоязычной статье, посвященной непрекращающемуся развитию тестировщика) с термином “тестовая эвристика”, я, что естественно, сразу же обратился за помощью к поисковику. И обнаружил, что русскоязычных статей по тестовым эвристикам не очень много. Те, что удалось найти, упоминали их, в основном, вскользь.

К концу этой блогозаписи, обещаю, ты познакомишься с тестовыми эвристиками и решишь, интересны они лично тебе или нет.

Зачем нужны тестовые эвристики?

Вместо вступления

Симпатичный мужчина в шляпе на фотографии выше - это Майкл Болтон. Человек незаурядный, имеет собственный, весьма интересный взгляд на тестирование, продвигает исследовательское тестирование, проводит курсы по Rapid Software Testing. В его блоге я и окунулся, в первый раз в своей жизни, в мир тестовых эвристик.

Словосочетание это я слышал и на SQADays, и в блогах коллег-тестировщиков. Упоминания были “вскользь”, без подробностей, практически без личного опыта (быть может, я слушал в пол-уха, прошу кинуть ссылкой, если так).

Это вводная в мир тестовых эвристик статья. Если буду продолжать использовать их - буду писать ещё (:

Союзника нужно знать в лицо

Тестирование при помощи эвристик - это тестирование алгоритмов, программ или любых других видов проектов, при котором стратегия тестирования основывается на предыдущем опыте и информации о вероятности различных событий. Проще говоря, мы знаем, где и при каких условиях часто возникали ошибки раньше - и, руководствуясь этими знаниями, планируем дальнейшее тестирование.

На первый взгляд, всё просто и понятно.

В чём выгода?

О, создание и использование тестовых эвристик может дать несколько весьма заманчивых преимуществ:

  1. Эвристики не дают забыть контекст, в котором используется тестируемое приложение. В моём случае, при тестировании кассовой программы, эвристики учитывают специфику монотонной работы кассира и малоадекватной, но предсказуемой реакции на различные события.
  2. Краткость. Эвристики отлично зарисовываются в mindmap, пишутся в небольшом текстовом файле или просто на листе бумаги. Для запоминания эвристик могут использоваться мнемоники.
  3. Эвристики бесценны, если вдруг вам стало непонятно, с чего начать тестирование нового софта. Помогают начать и более полно провести исследовательское тестирование приложения.
  4. С ними проще избежать повторения ошибок, допущенных в аналогичных ситуациях и при тестировании похожего ПО. Тестовые эвристики создают “напоминания” на основе предыдущего опыта - личного или опыта других тестировщиков.

Подожди, друг, а что такое эти твои “мнемоники”?

Мнемоники - это очень полезная (не только по отношению к тестовым эвристикам) штука. Как говорит всезнающая Википедия: Мнемоника - совокупность правил и приёмов, помогающих запоминать нужные сведения.

От этого определения и будем отталкиваться.

Чтобы не забыть в таких мучениях составленную и очень полезную тестовую эвристику, можно попробовать, например, выписать первые буквы её ключевых слов и посмотреть на них. Возможно, где-то внутри прячется слово, которое будет просто вспомнить, а по первым буквам восстановить в памяти и всю тестовую эвристику. Метод действенный - сам проверял!

Не стоит, друг, создавать мнемоники, которые не сможешь запомнить - это путь вникуда (:

Немного примеров

Эвристика и соответствующая ей мнемоника для регрессионного тестирования - RCRCRC

  • Recent - Недавние
  • Core - Основные
  • Risky - Рискованные
  • Configuration - Зависящие от настроек
  • Repaired - Починенные
  • Chronic - Хронические

Думаю, что здесь всё понятно без особых пояснений. Конечно, опытные товарищщи воскликнут - “Все эти вещи очевидны!”

Да, это так. Но к эвристикам нужно относиться не как к чеклисту или набору пунктов для проверки. Это, скорее, подсказка и средство, что может подтолкнуть к дополнительным проверкам, которые сразу на ум не приходят.

Я изначально тоже был достаточно скептически настроен в отношение эвристик. Они казались, да и сейчас, временами, кажутся изрядно притянутыми за уши. Но свою основную функцию - “дергать” за ниточки в голове, заставляя мозги шевелится и разглядывать продукт под другим ракурсом, эвристики успешно выполняют.

Особенно здорово работают domain-specific тестовые эвристики, рекомендую попробовать создать несколько для своего продукта.

Ну а пока, ещё одна эвристика от известного в мире тестирования господина James Bach. Насколько я понимаю, эвристика эта одна из самых известных и широко применяемых. Также является солидной основой для создания своих эвристик. Называется SFDPOT. Расшифровывается так:

  • Structure - структура приложения, проверка составляющих его частей
  • Function - функциональность приложения, проверка того, что приложение делает
  • Data - работа с данными, проверка того, как приложение работает с данными
  • Platform - платформа, проверка того, как приложение взаимодействует с платформой, на которой запущено
  • Operations - использовани, проверка сценариев использования приложения
  • Time - время, проверка того, как приложение ведёт себя в зависимости от времени

Такая вот любопытная штука. Разнообразие сторон, с которых можно тестировать приложение, после обдумывания данной эвристики немного пугает. Но суровые тестировщики трудностей не боятся, правда?

Как использовать настолько общую эвристику? Это несложно. На первое время можно распечатать несколько широко используемых эвристик (особенно их много для мобильных приложений) и держать перед собой в процессе исследовательского тестирования или продумывания тестовой стратегии. Будучи постоянно на виду, эвристика поможет вам не забыть разнообразные важные аспекты в процессе тестирования, позволит взглянуть на продукт шире и с разных сторон. А некоторая размытость определений позволяет адаптировать эвристики к тестированию практически любого программного продукта.

Как создавать свои тестовые эвристики

Не бывает двух одинаковых программ. Простая истина.

Не бывает двух одинаковых подходов к тестированию программ. Более сложная, но тоже истина.

Рано или поздно придётся адаптировать тестовые эвристики под свои нужды. Это совсем не трудно. Вот какие мысли по этому поводу есть у меня:

  • Бери чужие эвристики и не стесняйся их менять - добавляй новое и выбрасывай ненужное
  • Обращай внимание на шаблоны в процессе тестирования, подмечай общее в найденных ошибках
  • Ищи и запоминай удачные и неудачные решения в процессе тестирования, старайся обозначить их контекст
  • Не бойся признавать упущенные и не проверенные аспекты работы приложения
  • Обращай внимание, какие действия позволяют находить больше ошибок в продукте
  • Анализируй ошибки, обнаруженные конечным пользователем продукта
  • Придумывай мнемоники для своих эвристик - так легче запоминать (но не переусердствуй!)

Вместо заключения

В этой небольшой заметке я кратко рассказал о тестовых эвристиках, что смог.

Эвристики - это не в коем случае не серебряная пуля. Это лишь инструмент для стимуляции мозговой активности тестировщика (:

Главное, что можно сказать об эвристиках - попытка их использования не несёт почти никаких материальных и временных затрат.

Ничто не мешает попробовать и решить для себя, несут ли они для тебя практическую пользу или нет. Изучая различные эвристики, мы можем значительно расширить свои взгляды на возможные проблемы тестируемого продукта, открыть для себя новые грани тестирования или просто последить за мысленными процессами человека, эвристику создававшего.

Заманчиво, не правда ли?

И не нужно забывать делиться своим опытом использования эвристик в комментариях.

P.S. По ссылке доступен PDF с некоторыми известными тестовыми эвристиками.

Удачи!


comments powered by Disqus