Мой опыт в тестировании — около двух лет. Я человек любознательный и увлекающийся своим делом, поэтому стараюсь постоянно заниматься самообучением — подтягиваю знания и навыки в новой для меня профессиональной сфере.
Впервые я столкнулась с термином «тестовая эвристика», когда мне на глаза попался James Bach’s Blog. Именно с него и начался мой интерес к тестовым эвристикам и мнемоникам. На сегодняшний день наиболее актуальная часть материалов по тестированию представлена как раз таки англоязычным контентом.
Прочитав эту статью, вы ознакомитесь с основными тестовыми эвристиками и мнемониками, узнаете, зачем и для чего они применяются, в чем их преимущества и недостатки, увидите реальные примеры их практического применения и сможете узнать, как создать свою эвристику. Я поделюсь с вами собственной эвристикой, которую я использую для приемочного тестирования, и расскажу о ее преимуществах.
По сравнению с другими методами, метод эвристической оценки проще, легче и быстрее. Он позволяет выявить основные проблемы тестируемого продукта в кратчайшие сроки и с минимальными материальными и временными затратами. Изучая различные эвристики и мнемоники, тестировщик сможет значительно расширить свои взгляды на возможные проблемы тестируемого продукта, а также открыть для себя новые методы и подходы к самому процессу тестирования. Навыки использования тестовых эвристик могут значительно повысить эффективность процесса тестирования продукта.
Что такое эвристики и мнемоники
Тестирование при помощи эвристик — это тестирование алгоритмов, программ или любых других видов проектов, при котором стратегия тестирования основывается на предыдущем опыте и информации о вероятности различных событий.
Мнемоника — совокупность правил и приёмов, которые помогают запоминать нужные сведения и данные.
Преимущества тестовых эвристик:
- Эвристики не дают забыть контекст, в котором используется тестируемое приложение.
- Краткость. Эвристики удобно набросать в mindmap, записать в небольшом текстовом файле или просто на листе бумаги. Для запоминания эвристик могут использоваться мнемоники.
- Эвристики помогают провести исследовательское тестирование приложения в более детальном и полном формате.
- Они помогают избежать повторения ошибок, допущенных в аналогичных ситуациях при тестировании похожего ПО. Тестовые эвристики создают «напоминания» на основе предыдущего опыта — личного или опыта других тестировщиков.
Однако эвристика — несовершенный метод. Основной недостаток тестовых эвристиксостоит в том, что поскольку эвристическая оценка не предполагает пользовательского тестирования и анализа поведения реальных пользователей, ее результаты могут быть необоснованными и весьма субъективными.
Сценарное и исследовательское тестирование — две стороны одного и того же процесса тестирования. Поэтому квалифицированные тестировщики-исследователи не могут полагаться только лишь на исследовательскую составляющую. После эвристического механизма, с помощью которого можно быстро и в короткие сроки выявить проблемы в тестируемой системе, необходимо пройти заранее написанные тестовые сценарии и чеклисты.
Эвристикаотносится к технике тест-дизайна, основанном на опыте, и помогает в изучении, исследовании и решении определенной задачи.
Эвристический методчаще всего используется с целью как можно быстрее принять решение, которое будет наиболее близко к правильному, «оптимальному».
Эвристический алгоритм — это алгоритм поиска решения задачи, правильность которого для всех возможных случаев не доказана, но который дает наиболее верное решение в большинстве случаев использования.
У каждого тестировщика есть свой набор эвристик, ежедневно применяемых в процессе тестирования. Они вырабатываются с опытом, и чтобы узнать об эвристиках больше, нужно понять, как мыслят другие люди, и суметь описать собственный мыслительный процесс.
Эвристики и мнемоники помогают нам описывать процесс нашего тестирования.
Отличие эвристики от мнемоники
Мнемоника — это инструмент, позволяющий запоминать информацию более простым и доступным способом. Обычно мнемоника работает как основной ключ к тому, что вы хотите запомнить, но не говорит вам ничего о том, что именно вы пытаетесь запомнить.
Эвристика — это так называемое «правило большого пальца или частичного оракула», используемое для быстрого измерения чего-либо. В тестировании она обычно используется для изучения поведения приложений с целью быстро найти потенциальные проблемы.
Очевидно, что главная причина их взаимодействия заключается в том, что мнемоника часто нужна для того, чтобы напомнить об эвристике.
Все, что мы делаем и используем в тестировании, является эвристическим. Все модели, оракулы и методы тестирования — эвристика.
Используя мнемонику, можно генерировать идеи для тестирования продукта, который, в свою очередь, может привести к использованию эвристики.
Мнемоника — это полезный инструмент, помогающий вспомнить схемы различных моделей тестирования, которые можно впоследствии использовать в ходе работы.
Эвристика — это алгоритм, который помогает ориентироваться в пространстве решений конкретной задачи.
Когда идеи для тестирования заканчиваются, всегда есть под рукой эвристики, которые подскажут, что еще можно сделать. Можно и нужно использовать опыт других тестировщиков. Вот несколько примеров широко известных эвристик:
- Test Heuristics Cheat Sheet (Элизабет Хендриксон);
- Heuristic Test Strategy Model (Джеймс Бах).
Понимание, как мыслят другие тестировщики, помогает разнообразить собственный подход к тестированию.
SFDPOT & CRUCSPIC STMP
Каждый специалист по тестированию рекомендует использовать разные инструменты и мнемонические схемы. Они фокусируют и направляют тестовые работы.
С их помощью тестировщики могут быстрее обнаружить критические ошибки в различных областях программного обеспечения, чем когда полагаются только на свою интуицию и опыт.
Некоторые эксперты в области обеспечения качества часто используют мнемоническую схему SFDPOT, разработанную Джеймсом Бахом. Они утверждают, что это эффективный инструмент для генерации тестовых идей.
SFDPOT (Structures, Functions, Data, Platforms, Operations, Time):
- Structure — структура приложения, проверка составляющих его частей. На данном этапе разрабатываются тестовые идеи и сценарии, связанные со структурой приложения.
- Function — функциональность приложения, проверка того, что приложение делает. На этом этапе разрабатывается функциональное тестирование программного продукта.
- Data — работа с данными; проверка того, как приложение работает с данными. Тестировщики должны узнать, с какими данными работает система, и разработать тесты, проверяющие, как система получает, обрабатывает и выдает различные виды данных.
- Platform — платформа; проверка того, как приложение взаимодействует с платформой, на которой запущено. Тестировщики должны определить, на каких платформах выполнять ручное и автоматизированное тестирование.
- Operations — использование, проверка сценариев использования приложения. В этом пункте тестировщики должны выяснить, кто конечные пользователи тестируемого программного продукта, для каких задач пользователи собираются его использовать.
- Time — время, проверка того, как приложение ведет себя в зависимости от времени.
Карен Н. Джонсон (Karen N. Johnson), эксперт в сфере тестирования программного обеспечения, ссылаетсяна данный эвристический метод и называет его San Francisco Depot (SFDPOT). Он позволяет понять окружение, в котором вы будете тестировать, с точки зрения объема, ресурсов и времени — вершин треугольника качества. Это важная часть тестирования, которая часто выпадает из поля зрения тестировщика.
Многие специалисты по обеспечению качества используют SFDPOT и CRUCSPIC STMP для исследования объекта тестирования. Например, Джеймс Бах — известный эксперт, который постоянно выступает на престижных конференциях, один из тех, кто стоит за исследовательской концепцией тестирования и школой Context-Driven Testing, его блог бьет все рекорды популярности по всему миру. SFDPOT описывает составляющие продукта, а CRUCSPIC STMP — атрибуты системы. Эти способы эффективны для определения объектов и целей тестирования, а также они эффективно взаимодействуют между собой.
Оба метода (SFDPOT и CRUCSPIC STMP) весьма разнообразны и могут ссылаться друг на друга. SFDPOT может быть частью Capabilities — «возможностей», а CRUCSPIC STMP может быть частью Operations — «использования» (часто интерпретируется как «риск»). Схема взаимодействия этих методов:
Рикард Эдгрен (Rikard Edgren), автор статьио взаимодействии этих методов, рекомендует использовать оба метода как отдельные виды деятельности — они стимулируют мышление тестировщика в разных аспектах тестируемого продукта. А также комбинировать их и применять при тестировании именно там, где они будут наиболее необходимы и полезны.
RCRCRC
Регрессионное тестирование — это тестирование, предназначенное для повторной проверки свойств приложения или программного продукта с целью убедиться в том, что после внесения изменений или добавления нового функционала приложение по-прежнему работает корректно.
Чтобы не забыть те аспекты, которые следует принять во внимание при планировании регрессионного тестирования, Карен Н. Джонсон создала эвристику, состоящую из шести частей:
- Recent — Недавнее
- Core — Основное
- Risky — Рисковое
- Configuration sensitive — Чувствительное к конфигурации
- Repaired — Исправленное
- Chronic — Хроническое
Цель данной эвристики — помочь в изучении различных аспектов тестируемого приложения и выделить или обнаружить области для регрессионного тестирования.
Для запоминания этой эвристики можно использовать аббревиатуру, состоящую из первых букв — RCRCRC: Recent-Core-Risky-Configuration sensitive-Repaired-Chronic.
1. Recent (Недавнее)
Что было недавно добавлено в приложение? Недавние изменения — от очевидных до едва заметных — возможная причина появления дефектов. Очевидные изменения включают в себя новые функциональные возможности или обновление существующей функциональности.
Теоретически должен существовать набор регрессионных тестов, которые могут быть выполнены вручную или автоматически, чтобы убедиться в том, что недавние изменения не создали новых проблем и что существующие функциональные возможности по-прежнему работают корректно. На практике же может не быть достаточно времени для повторного запуска всех регрессионных тестов, и вместо этого нужно выбрать некоторое подмножество тестов из полного набора на основании того, что поменялось в сборке или релизе, который тестируется.
2. Core (Основное)
Регрессионное тестирование предназначено для того, чтобы предотвратить выпуск продукта с новыми проблемами в функциональных возможностях, которые существовали в предыдущих релизах. Необходимо определить области приложения, которые обязаны работать «в любом случае» — таким образом можно получить ключевые функциональные возможности.
3. Risk (Рисковое)
Для специалиста, тестирующего продукт, нетрудно вспомнить области повышенного риска в приложении — будь то новые функциональные возможности или старые. Если известно, где были проблемы в прошлом — будет легче определить области риска в настоящем. Можно использовать систему контроля ошибок для акцентирования внимания на тех областях продукта, которые в прошлом имели больше всего проблем.
4. Configuration sensitive (Чувствительное к конфигурации)
Код, который зависит от параметров окружения, то есть чувствительный к конфигурации, более уязвим. Учет таких особенностей приложения помогает принимать решения о необходимости повторного тестирования конкретных функциональных возможностей — и о том, в каком окружении необходимо это делать.
5. Repaired (Исправленное)
Некоторые функции приложения никак не удается реализовать или поправить с первой попытки. Их постоянно сопровождает шлейф дефектов, для устранения которых приходится выпускать несколько внутренних релизов. Необходимо повторно протестировать отсутствие найденных ранее ошибок и повторно тестировать функциональные возможности, чтобы убедиться в том, что сложные функции готовы к выпуску.
6. Chronic (Хроническое)
Некоторые области продукта, кажется, преследует закон Мёрфи: если что-то может сломаться, оно обязательно сломается. Чем дольше специалист работает с продуктом, тем больше он знает о том, где проблемы были, где они есть сейчас и где их можно ждать в будущем. Другое преимущество длительной работы с продуктом — это скорость, с которой он может проверить все проблемные точки для получения уверенности в его качестве.
Резюме
С диаграммой функциональных возможностей продукта или контрольным списком в руках, специалист по обеспечению качества продукта готов начать работу. Регрессионное тестирование, вероятнее всего, не обнаружит новых проблем, поэтому можно быстро пройти весь список, даже если он выглядит достаточно длинным. Самое лучшее планирование регрессионных тестов произрастает из хорошего знания приложения. Но для того, чтобы избежать шаблонного тестирования одних и тех же областей и пропуска других, имеет смысл использовать эвристику RCRCRC, помогающую окинуть взглядом всю картину сразу.
CIDTESTD
- Customers — Пользователи
- Information — Данные
- Developer relations — Взаимодействие разработчиков
- Team — Команда
- Equipment & Tools — Оборудование и инструменты
- Schedule — График тестирования
- Test items — Тестовые объекты
- Deliverables — Ожидаемые результаты
Эта эвристика используется для высокоуровневого планирования процесса тестирования, помогает сфокусироваться на тестировании прежде всего логически. Это, в свою очередь, помогает установить контекст и объекты тестирования.
CRUSSPICSTMPL
- Capability — Возможность
- Reliability — Надежность
- Usability — Удобство использования
- Security — Обеспечение надежности
- Scalability — Масштабируемость
- Performance — Производительность
- Installability — Возможность установки
- Compatibility — Совместимость
- Supportability — Возможность поддержки системы
- Testability — Тестируемость
- Maintainability — Удобство обслуживания
- Portability — Переносимость
- Localisability — Локализуемость
Эта эвристика представляет собой полный и необходимый список качественных характеристик системы. Карен Н. Джонсон предпочитает пользоваться ISO 9126 (международный стандарт, определяющий оценочные характеристики качества ПО), но CRUSSPICSTMPL дает превосходное покрытие основного функционала системы. А окончание «ity» в конце практически каждого слова эвристики помогает сосредоточиться на QualITY (качестве) продукта.
FDSFCURA
- Function Testing — Функциональное тестирование
- Domain Testing — Тестирование доменных имен
- Stress Testing — Стресс-тестирование
- Flow Testing — Тестирование потоков
- Scenario Testing — Тестирование сценариев
- Claims Testing — Тестирование требований
- User Testing — Пользовательское тестирование
- Risk Testing — Тестирование рисков
- Automatic Testing — Автоматизация
Эта эвристика представляет собой перечень всех типов тестирования, которые необходимо применять для проверки системы. Она показывает, что существует огромное множество тестов, которыми мы можем проверить продукт, для того, чтобы понять, что и как мы должны тестировать.
Оракул — это эвристический механизм, который помогает определить проблему. Прилагательное «эвристический» указывает на то, что этот механизм, как и любая другая эвристика, подвержен ошибкам. То есть он помогает, но не всегда. Зато его сравнительно легко использовать — еще одно свойство, характерное для эвристики.
Другое определение оракула говорит о том, что это способ генерации ожидаемого результата теста.
Эти два определения похожи, они оба связаны с определением результата теста и распознаванием правильного и неправильного поведения продукта. Но есть в них и принципиальное различие: первое используется в основном в контексте обнаружения проблем, второе — в контексте разработки тестов.
HICCUPPSF
HICCUPPS(F) — это оракул, который помогает запомнить эвристику последовательности принципов и механизмов, с помощью которых можно быстро и в короткие сроки выявить проблемы в тестируемой системе. HICCUPPS(F) представлен в виде сборника универсальных типов оракулов для обнаружения проблем.
- History (История) — нынешняя версия системы соответствует предыдущим версиям продукта.
- Image (Изображение) — внешний вид продукта соответствует макету системы заказчика.
- Comparable Products (Аналогичные продукты) — система соответствует аналогичным системам. Они включают в себя другие продукты в одной и той же линейке продуктов; конкурентоспособные продукты, услуги или системы; или продукты, которые не относятся к одной и той же категории, но обрабатывают одни и те же данные; или же альтернативные процессы и алгоритмы.
- Claims (Требования) — продукт соответствует требованиям заказчика.
- Users’ Expectations (Ожидания пользователей) — система соответствует потребностям конечных пользователей.
- Product (Продукт) — каждый элемент системы (или продукта) будет соответствовать сопоставимым элементам в одной и той же системе.
- Purpose (Цель) — система соответствует явным и неявным целям и нуждам пользователей.
- Statutes (Законы) — система соответствует законам и правилам, которые описывают данный продукт и его использование.
- Familiarity (Осведомленность) — «F» означает «Familiar problems» (похожие проблемы). Другими словами, система не соответствует ни одной из проблем, с которыми сталкивался ранее тестировщик.
MAC RUSS — эвристика автора статьи для приемочного тестирования
Приемочное тестирование — это формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится, чтобы определить, удовлетворяет ли система приемочным критериям и заказчик или другое уполномоченное лицо решило, принимается приложение или нет.
Чтобы спланировать приемочное тестирование и начать его с основных особенностей, я создала эвристику, которая состоит из следующих частей:
- Maintainability — Удобство сопровождения
- Availability — Доступность
- Configurability — Способность к конфигурации
- Reliability — Надежность
- Usability — Удобство использования
- Security — Безопасность / обеспечение надежности
- Scalability — Масштабируемость
Для запоминания этой эвристики можно использовать аббревиатуру, состоящую из первых букв MAC RUSS: Maintainability-Availability-Configurability-Reliability -Usability-Security-Scalability.
1. Maintainability (Удобство сопровождения)
Это легкость, с которой ПО можно анализировать, тестировать, изменять для исправления дефектов, реализации новых требований, облегчения дальнейшего обслуживания и адаптации к окружению.
2. Availability (Доступность)
Имеется ввиду требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему объекту или устройству. Как правило, чем более критичен ресурс — тем выше уровень доступности должен быть.
3. Configurability (Способность к конфигурации)
Специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т. д.).
4. Reliability (Надежность)
Способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты этой характеристики — завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость.
Это процесс тестирования, исследующий надежность программного продукта.
5. Usability (Удобство использования)
Юзабилити-тестирование проводится с целью определения степени и уровня комфорта в применении, обучаемости, доступности, понятности, легкости в изучении и использовании, привлекательности программного продукта для конечного пользователя при условии использования в заданных условиях эксплуатации.
6. Security / Securability (Безопасность / обеспечение надежности)
Стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
7. Scalability (Масштабируемость)
Часть комплекса нефункционального тестирования. Предназначена для проверки его способности по увеличению и уменьшению масштаба любых его нефункциональных возможностей. При этом приложение должно быть способно выполнять пользовательскую нагрузку, поддерживать необходимое количество транзакций и объем данных.
Резюме
Приемочное тестирование — это комплексное тестирование, необходимое для определения уровня готовности системы к последующей эксплуатации. Тестирование проводится на основании набора тестовых сценариев, покрывающих основные бизнес-операции системы.
Использование опытными тестировщиками данной эвристики сократит время на подготовку к тестированию и позволит повысить качество и надежность проводимых испытаний.
Ключевые преимущества применения эвристики MAC RUSS:
- Позволяет обнаружить системные нарушения в короткие сроки.
- Позволяет обнаружить дефекты, связанные с удобством и простотой использования.
- Использование опытными компетентными специалистами этой техники позволяет грамотно, качественно и в заданные сроки провести процесс приемки тестирования.
Практическое применение и использование тестовых эвристик и мнемоник
Понимание, как мыслят другие тестировщики, помогает специалисту варьировать его собственный подход к тестированию. Вместо того, чтобы искать одни и те же баги, он может расширять горизонты своего мышления.
Термин «эвристика» можно также трактовать как «некая устоявшаяся практика», и для Context-Driven Testing School этот термин уже давно прижился сам по себе.
Путем накопления опыта и методом проб и ошибок опытные тестировщики вырабатывают собственные методики и техники тестирования. Но многие тестировщики даже не осознают, что существуют навыки исследовательского тестирования, которые они могут развить у себя и которые им помогут приносить больше пользы команде.
Один из показателей эффективности работы тестировщика — квалифицированное исследовательское тестирование. Опытные квалифицированные специалисты выработали аналитические и исследовательские навыки, которые позволили им быть уверенными в использовании самого мощного инструмента тестирования, который есть в нашем распоряжении — человеческого мышления. Исследовательское тестирование таково, что тестировщики невольно в него вовлекаются естественным образом, но будучи противоположностью сценарного тестирования, оно недооценивается и из-за этого иногда не одобряется. В компаниях, где поощряются сценарные процессы тестирования, многие тестировщики не осознают, что существуют другие способы тестирования, нежели написание и последовательное выполнение тест-кейсов.
Как говорит Кем Канер (Cem Kaner, автор книги «Testing Computer Software»), «тестирование — это исследовательская деятельность, которая предоставляет информацию, связанную с качеством программного обеспечения». Собирая различного рода информацию, мы должны быть открыты к интерпретациям, чтобы иметь возможность оценить проблему с разных сторон.
Кроме того, проекты по разработке ПО сопряжены с определенными рисками, и исследовательское тестирование позволяет мгновенно адаптироваться к новым рискам.
Тестировщики, которые научились использовать свой творческий потенциал и интеллект во время тестирования, разработали способы управления своим мыслительным тестировочным процессом. Квалифицированные тестировщики-исследователи используют умственные хитрости, чтобы сохранить своё мышление острым и последовательным. Две хитрости, используемые тестировщиками для резкого разгона мозгов, — это эвристика (подходы к решению проблем) и мнемоника (тренировка памяти).
Каждая буква мнемоники помогает не только придерживаться последовательности в тестировании, но и вся аббревиатура помогает быстро разрабатывать и выполнять много тестов на всех тестируемых участках. Также возможно использовать другие мнемоники и эвристики по ходу тестирования, если обнаруживаются области для исследований другого плана.
Пример использования мнемонических схем SFDIPOT и CRUSSPIC STMPL
Шмуэль Гершон (Shmuel Gershon) в своем блоге (статья «The Big Exploratory Testing Rolling Strategy Dice») описывает практическое применение мнемонических схем в исследовательском тестировании.
Шмуэль Гершон предлагает комбинировать две тестовые эвристики: SFDIPOT (Structures, Functions, Data, Platforms, Operations, Time) — эвристика тестовой стратегии Джеймса Баха и CRUSSPIC STMPL (Operational Criteria — CRUSSPIC: Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility; Development Criteria — STMPL: Supportability, Testability, Maintainability, Portability, Localizability) — эвристика качественных характеристик продукта.
Например, для того чтобы выбрать первый элемент для тестирования, нам нужно подбросить кубик SFDIPOT, и, предположим, выпала грань «Platform» (платформа — проверка того, как приложение взаимодействует с платформой, на которой запущено). Чтобы определить, с какой точки зрения следует изучать тестовую платформу в первую очередь, подбросим кубик CRUSSPIC STMPL — допустим, выпадет грань «Testability» (тестируемость продукта). Теперь взглянем на наш продукт с точки зрения этих двух характеристик — стратегии и качества. Как и каким образом мы можем протестировать нашу платформу? Какие особенности платформы могут быть на системном уровне тестирования? Какие интерфейсы этой платформы могут быть? И какие баги, связанные с этим, мы можем найти?
После того, как мы исследовали нашу платформу на тестируемость, можно подкинуть кубики еще раз. Например, нам выпадет грань «Function» (функциональность приложения — проверка того, что именно приложение делает) и «Reliability» (надежность, качество). Здесь нам нужно будет взглянуть на функциональность продукта с точки зрения надежности. Как мы сможем протестировать функции программы на надежность использования? Какие функциональные характеристики вызывают доверие пользователя? Какие функции могут привести к сбоям в системе?
Шмуэль Гершон предложил быстрый и удобный метод тестирования продукта, который можно использовать в качестве дополнительного инструмента в повседневном тестировании. Этот метод также можно назвать Poker Testing.
Что говорят украинские эксперты
Егор Максимчук, Senior Software Engineer в SoftServe Ukraine
В IT я работаю с 2010 года. Кроме работы в SoftServe, преподаю в qastudy.online, был судьей на Dev Challenge 12 и веду телеграм-канал @QAStudy.Online.
Термин «тестовая эвристика» я узнал давно — на SQA Days и в блогах по тестированию. Лично я люблю совмещать два эвристических метода тестирования: SFDPOT и CRUCSPIC STMP. Они эффективны для определения объектов и целей тестирования, а их взаимодействие отлично покрывает большинство возможностей и рисков тестируемой системы. Я считаю, что особенно бесценны эвристики для новичков в области тестирования: если вдруг стало непонятно, с чего начать процесс тестирования нового софта. Они помогают начать и достаточно полноценно провести исследовательское тестирование приложения.
Для более «продвинутых» QA-специалистов эвристики и мнемоники помогают удержать в голове все аспекты, которые нужно учесть при тестировании новой фичи приложения. С ними легче избежать повторения ошибок, допущенных в аналогичных ситуациях и при тестировании похожего продукта другими специалистами.
Самым удобным инструментом для оформления эвристик считаю mindmaps, например, xmind.
Чекановский Александр, QA lead в Aurora Technologies
Четвертый год занимаюсь ручным и автоматизированным тестированием веб- и моб-приложений, а также платежных систем.
С таким понятиями, как мнемоника и эвристика, сталкиваюсь довольно часто во время работы. Использование эвристик структурирует процесс тестирования и особенно полезно при включении в новый проект. Они помогают быстро и на хорошем уровне разобраться в тестируемой системе, а также локализовать часть проблемных моментов.
Как по мне, каждый проект вырабатывает свою индивидуальную эвристику тестирования, которая все время совершенствуется. Найти абсолютно универсальную эвристику, которая подходит под любой продукт, — сложная задача. Проще взять за основу один или несколько популярных подходов и адаптировать их под свой продукт.
На текущем проекте используем частичную комбинацию SFDPOT и HICCUPPSF.
Я бы назвал ее FUC*IT:
- Functional
- User ex
- Claims
- *Platform
- Image
- Target
Вячеслав Сахаров, QA Team Lead в COI Marketing & Software
Работаю в IT практически 6 лет. Самые трудные были первые два года работы единственным тестировщиком в Design Cont`d. Затем этот опыт самостоятельной работы помог мне работать QA Team Lead в компаниях Tallium, Customertimes, Helsi. Сейчас работаю в COI Marketing & Software — занимаюсь организацией, контролем и управлением работы QA команды, а также определением процессов, процедур и методик тестирования программного продукта; принимаю участие в создании регламентов и процедур разработки.
В своей работе я часто пользуюсь принципом, что любая задача должна быть раскрыта с нескольких сторон и рассматриваться под разными углами. Тут, кроме стандартных техник, тест-дизайна очень помогают мнемонические схемы.
При получении в работу нового объемного функционала, сразу же после анализа требований и документации, я перехожу к исследовательскому тестированию. И в этом мне очень помогает мнемоническая схема SFDPOT, разработанная Джеймсом Бахом. Это очень эффективный инструмент для генерации тестовых идей, когда передо мной стоит задача: максимально быстро и в кратчайшие временные сроки найти и описать очевидные баги новой фичи.
Также использую, правда, реже, эвристику Карен Н. Джонсон для регрессионного тестирования — RCRCRC. Она помогает избежать шаблонного тестирования одних и тех же областей и пропуска других, дает возможность окинуть взглядом всю картину сразу и выделить важные аспекты в процессе тестирования.
При подходе к тестированию с точки зрения эвристики я знаю, где и при каких условиях часто возникали баги раньше — и, руководствуясь этими знаниями, планирую свою дальнейшую стратегию тестирования.
Резюме
Использование мнемоник и эвристик помогает быть последовательным в тестировании, но нельзя позволять им управлять вашими действиями. Очень просто переключаться между мнемониками и эвристиками в свободное тестирование и возвращаться обратно, либо вообще рабоать с высокоструктурированными тестами. Исследовательское тестирование помогает адаптировать мышление и действия, основываясь на том, как продукт «отвечает». Это самый значительный принцип исследовательского тестирования. Специалист может использовать возможности, как только их обнаружит. К тому же, он может быстро адаптироваться к рискам проекта, выявлять и исследовать новые.
Тестирование использует чистое наблюдение, и метод проб и ошибок может быть эффективным. Но он гораздо эффективнее, если есть система, в которую он вписывается.
Разнообразное исследовательское тестирование может быть важнейшим из способов мышления в тестировании.
«Квалифицированное исследовательское тестирование — это еще один эффективный мыслительный инструмент в репертуаре тестировщика». (Jonathan Kohl, основатель и главный консультант по программному обеспечению Kohl Concepts, Inc., ведет свой блог)
Список полезных ресурсов
Статьи
- «Немного про тестовые эвристики», Родион Горицков
- «Эвристики ХРОНИЧеского регрессионного тестирования», Карен Н. Джонсон
- «Как проводить эвристическую оценку?», Армен Газарян
- «Как проводить эвристическую оценку», Якоб Нильсен
- A software expert’s heuristic for regression testing, by Karen N. Johnson
- Heuristic Test Strategy Model, by James Bach
- Test Heuristics Cheat Sheet, by Elisabeth Hendrickson
- Testing Heuristics — Thinking like a tester, by Shane Hastie
- Software Testing Heuristics & Mnemonics, by Karen N. Johnson
- Software Quality Characteristics, by Rikard Edgren
- Intertwined SFDPOT & CRUCSPIC STMP, by Rikard Edgren
- Tester Diaries — Applying SFDPOT Heuristic, by Ridha, KnowledgeTester blog
- Applying the SFDPOT heuristic to mobile testing, by Karen N. Johnson
- The Big Exploratory Testing Rolling Strategy Dice, by Shmuel Gershon
- Heuristic Evaluation: How to Conduct a Heuristic Evaluation, by Euphemia Wong
- Testing Mnemonics, by Sneha Bhat
- Exploratory Testing: Finding the Music of Software Investigation, by Jonathan Kohl
- How Do You Spell Testing?, by James Bach
- Blog: Transpection Transpected, by Michael Bolton
- Mnemonics in Software testing, by Rishi Arora
- Testing Mnemonics — Desktop Download, by Del Dewar
- Heuristics Testing, techopedia
- Эвристический алгоритм, wiki
- Mnemonic != Heuristic, Ministry of Testing
Блоги
- Satisfice blog, Heuristic, James Bach`s blog
- Thoughts from the test eye, blog
- Testing Mnemonics, I`m tester blog
- Jonathan Kohl, blog
- Testing is Believing, Ash Winter`s blog