Мнемоники в тестировании

Мнемоника — слово или фраза, которая помогает нам что-то запомнить. Самая известная мнемоника — «каждый охотник желает знать, где сидит фазан», помогающая запомнить цвета радуги.

В тестировании они тоже применяются. За рубежом очень активно, там понимают, как это здорово и полезно!

Американцы вообще любят придумывать мнемоники. Примеры:

• SFPDO (San Francisco Depot)
• RCRCRC
• FCC CUTS VIDS
• FAILURE
• CCD IS EARI

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


Да-да, придуманные на ходу! Почему бы и нет? Даже те мнемоники, что сейчас получили известность (типа San Francisco Depot), исходно были придуманы кем-то для личных нужд. Для своего проекта, своей команды. А потом автор понимал, что мнемоника пригодится не только ему, вот и делился с общественностью!

Лично вам чужая мнемоника может подойди, а может и нет. Она может не подойти под вашу систему, под ваши процессы или что-то еще. И на самом деле нет ничего такого плохого и зазорного в том, чтобы взять и написать свою мнемонику. Которая будет под вас, под вашу команду, под ваши особенности, под ваши процессы.

Наши мнемоники

БМВ

Б — большой
М — маленький
В — в самый раз

Мнемоника для поиска граничных значений (подробнее см тут). Я в свое время придумала эту мнемонику ради студентов. Чтобы не забывали про самое важное, про границы!

Считаю ее очень крутой и полезной, стараюсь активно пиарить. Чем больше людей узнает и начнет применять, тем лучше станет мир 

Ну как минимум студентам всем рассказываю, в книге вот о ней написала. Ведь она правда полезная, кучу багов находит! Однако других русскоязычных мнемоник, увы, не знаю...


Сборник от студентов

Мнемоники моих студентов

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

Многие из этих мнемоник можно использовать на работе. Особенно новичку. А те, кто смог их придумать, наверняка и на реальной работе продолжат применять такой метод!



SAQSII meeting

Мнемоника SAQSII предназначена участникам любых обсуждений для снижения временных затрат и превращения каждого собрания в эффективное. Подробнее см в блоге Tjupka.

• Subject — тема собрания оглашается его Ведущим и дублируется в приглашениях
• Aim — цель совещания оглашается Организатором.
• Questions — третья часть собрания состоит из вопросов.
• Suggestions — часть советов от Экспертов Организатору. Каждый Эксперт высказывает своё мнение о проблеме и её возможном решении
• Information for Implementing - Ведущий формулирует устно итоги, исправляет и дописывает (время и ответственные в планировании, описание тех.задания, приоретизация, декомпозиция и т.д.) исходную задачу в баг-трекинговой системе или спринт-листе

Иностранные мнемоники

SFPDO (San Francisco Depot) 

Мнемоника от James Bach

• Structure — Структура: Что это за продукт?
• Function — Функционал: Что этот продукт делает?
• Data — Информация: Что продукт обрабатывает?
• Platform — Платформа: От чего продукт зависит
• Operations — Операции: Как продукт будет использоваться?

SFDIPOT (San Francisco Depot) 

Тестовая эвристика от James Bach и Michael Bolton. Немного улучшенная версия SFPDO, видимо, Болтон ее и улучшил:

Structure, Function, Data, Integrations, Platform, Operations, Time.
Структура, Функционал, Данные, Интеграция, Платформа, Операции, Время.



RCRCRC

Эвристика для регрессионного тестирования от Karen N. Johnson

Recent, Core, Risk, Configuration, Repaired, Chronic

• Recent — Какие новые функции были добавлены в текущей итерации, что было изменено из уже существующего функционала.
• Core — Основные сценарии. Что должно ВСЕГДА работать?
• Risk — Какой функционал имеет максимальные риски? Его и проверяем.
• Configuration — На каких окружениях и в каких конфигурация должно работать?
• Repaired — Какой функционал мы чинили в релизе? Ретест багов, как минимум самых важных
• Chronic — Регрессия областей с хроническими болезнями (где чаще всего находились баги ранее)

См также:
Регрессионное тестирование используя RCRCRC — отличный перевод + mindmap мнемоники

CRUSSPIC STMPL 

Эвристика качественных характеристик системы от James Bach

Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility, Supportability, Testability, Maintainability, Portability, Localizability

• Capability — Возможность
• Reliability — Надежность
• Usability — Удобство использования
• Security — Обеспечение надежности
• Scalability — Масштабируемость
• Performance — Производительность
• Installability — Возможность установки
• Compatibility — Совместимость
• Supportability — Возможность поддержки системы
• Testability — Тестируемость
• Maintainability — Удобство обслуживания
• Portability — Переносимость
• Localisability — Локализуемость

FEW HICCUPS

Тестовые оракулы от Michael Bolton, описаны в блоге автора тут. 

Familiarity, Explainability, World,  History, Image, Comparable Product, Claims, User Expectations, Product, Purpose, Standards and Statutes.

• Familiarity (Осведомленность) — Мы ожидаем, что в системе нет известных нам ошибок.
• Explainability (Объяснимость) — Мы ожидаем, что система будет понятна, что мы сможем членораздельно объяснить ее поведение.
• World (Реалистичность) — Мы ожидаем, что система соответсвует законам природы и внешнего мира.
• History (История) — Нынешняя версия системы соответствует предыдущим версиям продукта.
• Image (Изображение) — Внешний вид продукта соответствует макету системы заказчика.
• Comparable Products (Аналогичные продукты) — система соответствует аналогичным системам. Они включают в себя другие продукты в одной и той же линейке продуктов; конкурентоспособные продукты, услуги или системы; или продукты, которые не относятся к одной и той же категории, но обрабатывают одни и те же данные.
• Claims (Требования) — Продукт соответствует требованиям заказчика.
• Users’ Expectations (Ожидания пользователей) — Система соответствует потребностям конечных пользователей.
• Product (Продукт) — Каждый элемент системы (или продукта) будет соответствовать сопоставимым элементам в одной и той же системе.
• Purpose (Цель) — Система соответствует явным и неявным целям и нуждам пользователей.
• Statutes (Законы) — Система соответствует законам и правилам, которые описывают данный продукт и его использование.

См также:

Эвристики и оракулы — тут есть отсылка к мнемонике

Эвристики и мнемоники в тестировании — тут есть перевод мнемоники

FEW HICCUPPS — описание в блоге автора (оригинал)

RIMGEA

Мнемоника для описания багов от Cem Kaner.

Replicate it, Isolate it, Maximize it, Generalize it, Externalize it, And Say it Clearly and Dispassionately.

Воспроизведи его, изолируй его, увеличь до максимума, обобщи, сделай вывод, скажи о баге максимально ясно и четко. 

MOCHA

Эта мнемоника описывает стиль собеседований для найма тестировщиков от Maria Kedemo

Meta, Open, Closed, Hypothetical, Audit

• Meta questions — Вопросы про вопросы. Автор может спросить что-то типа «О чем я забыла спросить вас?», это поможет узнать, что кандидат считает важным.
• Open questions — Обязательно должны быть и открытые вопросы, на которые не отделаешься ответом «Да / нет / не знаю». Лучше пусть расскажет в подробностях какой-то случай: «Расскажите, как вы проводите нагрузочное тестирование в своей компании?»
• Closed questions — Закрытые вопросы тоже могут быть. Например, чтобы выяснить факты: «Работали ли на Java?». Или можно уточнить «Были ли вы в такой-то ситуации... ?», если был, то переходим на открытые вопросы.
• Hypothetical questions — Гипотетические вопросы. Тут или представляем ситуацию, в которой кандидат не бывал, «но вдруг бы так случилось?». Или используем проекции: спрашиваем про других людей, а узнаем о кандидате. «Коллега систематически опаздывает. Как думаете, почему?»
• Auditions — Прослушивание, оно же тестирование. Надо дать кандидату небольшую задачку, иначе как понять, на что он правда способен? Главное: не создавать стрессовую ситуацию, помочь кандидату расслабиться.

См также:

Открытые и закрытые вопросы — подробнее о том, что это такое

Искусство подбора персонала. Светлана Иванова — отличная книга про подбор персонала. Там же автор рассказывает, что такое проекции

HEENA

• History — История
• Explore — Исследование
• Experiment — Эксперимент
• Experience — Опыт
• Note Taking — Заметки
• Analyse — Анализ

Мнемоника хороша при тестировании сложных продуктов.

Если продукт сложный, то мы постоянно натыкаемся на сложновоспроизводимые баги. И тут нам помогает буева Н (History). Понимание того, что недавно менялось в продукте, может помочь обнаружить истоки проблемы.

Наблюдаемая проблема может возникнуть один раз, или повторяться потом. Поэтому мы исследуем (Explore) тенденцию ее возникновения. Например, области, в которых проблема наблюдается, или количество случаев в определенной области.

Во время экспериментов (Experiment) нам помогает наш опыт (Experience) в какой-либо области, знание продукта или технологии.

Заметки (Note Taking) очень важны, если проблема воспроизведется снова. Тогда нам придется вернуться назад и вспомнить, как она воспроизводилась ранее. Чем хуже заметки, тем сложнее понять первопричину. В сложных багах даже стоит вкладывать видео воспроизведения в баг-трекер. Пригодится!

Как только мы собрали всю необходимую информацию, ее надо проанализировать (Analyse). Как сделать так, чтобы баг не всплывал в дальнейшем? 

См также:

Ретроспективный анализ ошибки — подробнее про Analyse в мнемонике.

SCAMPER

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

Substitute — Замена: Какие ресурсы можно заменить для улучшения продукта? Какие еще продукты или процессы можно использовать? Можно ли использовать продукт как-то иначе или заменить что-то еще?

Combine — Комбинация: Что будет, если скомбинировать наш продукт с другим? Что, если скомбинировать цели разных продуктов?

Adapt — Адаптация: Как можно приспособить продукт для других целей? Кому еще может понравиться твой продукт? Какие другие продукты или идеи можно использовать, адаптировав к нашим реалиям?

Modify — Изменение: Как можно изменить внешний вид или содержание продукта? Что можно добавить в продукт? Изменить в нем?

Put to Another Use — Использование в других целях: Можно ли использовать продукт где-то еще, например, в другой индустрии? Кто еще мог бы использоватьп продукт? Как продукт будет вести себя при других настройках?

Eliminate — Исключение: Как можно упростить продукт? Какие функции можно выкинуть? Как можно сделать его меньше, легче и интереснее?


Reverse — Перемена: Что будет, если кардинально изменить процесс создания продукта? Как можно его реорганизовать?

См также:
SCAMPER — подробнее о мнемонике



DUFFSSCRA

Эвристика техник тестирования от James Bach.

• Domain — доменное тестирование (не уверена, что это название надо переводить, его произносят на английском);
• User — пользовательское тестирование;
• Function — функциональное тестирование;
• Flow — поток данных;
• Stress — стрессовое, нагрузочное тестирование
• Scenario — тестирование сценариев использования;
• Claims — тестирование требований;
• Risk — тестирование на основе рисков;
• Automatic — автоматическое тестирование.

См также:

What is Domain Testing in Software Testing? (with Example)




MCOASTER

Эвристика для составления баг-репортов (Test Reporting Heuristics) от Michael D Kelly. Подробнее см тут.

• Mission — Миссия
• Coverage — Покрытие
• Obstacles — Препятствия
• Audience — Аудитория
• Status — Статус
• Techniques — Техники
• Environment — Окружение
• Risk — Риски

FAILURE

Эвристика для составления грамотных сообщений об ошибке от Ben Simo. Подробнее см тут.

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

Так и родилась мнемоника о том, как перехватывать ошибки.

• Functional — Функционал. Перехват ошибки работает? Ошибки репортятся (например, бывает автописьмо разработчику)? Окно с текстом ошибки отображается как положено? Кнопки все работают?
• Appropriate — Соответствие. Целевая аудитория получает точные и своевременные описания ошибок? Об ошибках собщают, как только они встретились? Пользователю не приходится тратить время и силы только для того, чтобы узнать, что его информация сохраняться не будет (самый эпик — когда ты заполнил 20 полей, где-то ошибившись, и все поля очистились)? Точен ли текст сообщения об ошибке? Он написан в мире пользователя, а не разработчика?
• Impact — Воздействие. Пользователь точно понял из сообщения об ошибке все последстия? Или там слишком мало информации, чтобы понять, почему именно система дала сбой? Есть ли в сообщении ненужная информация, которая только отвлекает?
• Log — Логирование. Нужно ли логировать информацию для суппорта, разработки или тестирования? Не пропадут ли логи, если пользователь не сразу свяжется с поддержкой? Стандартизированы ли логи, чтобы автоматически доставать всю информацию оттуда? Понятно ли из них, что произошло? Не перегружены ли они информацией?
• UI — Пользовательский интерфейс. Пользователь увидел, что его попытка что-то сделать была неудачной? Сообщение об ошибке написано в мире пользователя? Нужно ли пользователю кликать вне области окна, чтобы его закрыть? Является ли диалоговое окно лучшим выбором?
• Recovery — Восстановление. Говорит ли сообщение об ошибке о том, что именно надо исправить?  Система облегчает восстановление данных (сохраняет черновик или все обнуляет)? Есть ли контактная информация поддержки на случай необходимости?
• Emotions — Эмоции. Какие эмоции вызовет это сообщение об ошибке? Информация в сообщении успокоит пользователя или расстроит еще больше?

См также:

Сообщения об ошибках — тоже документация, тестируйте их!

У вас некорректное выражение, найдите его (ребенок) — примеры для буквы R, Recovery.

W5HE (WWWWWH/KE)

Мнемоника для анализа требований от Darren McMillan. Подробнее см тут.

Тестировщику часто надо оценить первичный набросок требований. А ведь так легко что-то упустить...

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

Даррен придумал простую мнемонику  «WWWWWH/KE». Запомнил ее потому, что она напоминает слово «wiki»

This stands for who, what, when, where, why & how combined with my knowledge and experience.
Она основана на вопросах «кто, что, когда, где, почему» & как это все комбинируется с моим опытом и знаниями.

What is this for? — Для чего это?
When & by whom is it to be done? —Когда и кем это будет использоваться?
Where is it being done? (Location code/team) — Где это будет делаться? (Расположение кода / команды)
Why is it being done? (What problem does it solve?) — Зачем это нужно делать? Какую проблему это решает?
How is it being achieved? — Как можно это сделать? (осуществимость с технической точки зрения)
What questions does my knowledge of this or related products/systems produce? — Какие вопросы вызывают мои знания этого или схожего продукта/системы?
What questions does my experience of this or other related products/systems produce? — Какие вопросы вызывает мой опыт этого или похожего продукта/системы?

Если сформулировать кратко, получится так:

• Who 
• What
• When
• Where
• Why
• How
• Experience

PROOF

Мнемоника для написания тестового отчета после сессионного тестирования, от Jon Bach

• Past — Прошлое. Что происходило во время сессии тестирования?
• Results— Результаты. Чего мы достигли во время сессии, что проверили?
• Obstacles — Препятствияю. Что помешало качественному тестированию?
• Outlook — Перспектива. Что еще нужно сделать?
• Feelings — Чувства. Что тестировщик думает обо всем этом?

См также:
Session-Based Test Management — там же и мнемоника упоминается




GRATEDD SCRIPTS

Мнемоника для тестовой стратегии от Jared Quinert. Подррбнее см тут.

• Goals – Цели. Что должно работать в продукте?
• Risks – Риски. Какие риски есть в продукте?
• Approach – Подход. Какой подход мы должны использовать при тестировании этого продукта?
• Tradeoffs – Компромисс. На какие компромиссы нам надо пойти? (время или покрытие тестами)
• Environments – Окружения. Какие окружения у нас есть и какие мы планируем использовать во время тестирования?
• Dependencies – Для тестирования нам надо знать про все внешние и внутренние зависимости системы.
• Data – Какие данные будут на входе?
• Stakeholders – Заказчики. Нужно понимать, кто заказывает проект
• Coverage – Покрытие. Подумайте, как сделать тестовое покрытие очевидным и понятным для Заказчиков.
• Resources – Достаточно ли нам ресурсов для тестирования функционала?
• Information needs – Информация. Что нам нужно узнать о тестируемой задаче?
• Prioritisation – Приоритезация. Что является самым важным?
• Tooling – Инструменты. Какие инструменты мы планируем использовать во время тестирования? Будут ли они нам доступны?

Про последний пункт стоит подумать заранее, если тестировать будете не на своей территории, а после разворачивания системы на стенде Заказчика!


Другая вариация мнемоники — B GRADED SCRIPTTS.

Budget, Goals, Risks, Approach, Dependencies, Environments, Data, Stakeholders, Coverage Models, Resources, Information, Prioritization, Tradeoffs, Tooling, Schedule.

То есть в начало добавляется Budget (бюджет), а в конец — Schedule (график).

CIDTESTD

Эта эвристика используется для высокоуровневого планирования процесса тестирования, помогает сфокусироваться на тестировании прежде всего логически.

• Customers — Пользователи
• Information — Данные
• Developer relations — Взаимодействие разработчиков
• Team — Команда
• Equipment & Tools — Оборудование и инструменты
• Schedule — График тестирования
• Test items — Тестовые объекты
• Deliverables — Ожидаемые результаты

Но, как по мне, GRATEDD SCRIPTS полезнее в этом плане.




MAC RUSS

Эвристика для приемочного тестирования от Антонины Тараненко. Подробнее см тут.

• Maintainability — Удобство сопровождения
• Availability — Доступность
• Configurability — Способность к конфигурации
• Reliability — Надежность
• Usability — Удобство использования
• Security — Безопасность / обеспечение надежности
• Scalability — Масштабируемость

SACKED SCOWS 

Эвристика для обучения от James Bach. Подробнее см тут

• Scouting Obsessively — Изучай одержимо, погрузись в задачу. Горящие глаза очень важны! (…я ищу источники и инструменты, которые мне пригодятся)
• Authentic Problems — Подлинные проблемы. (...любая вещь становится главной задачей, важнейшей проблемой, захватывающей мой ум)
• Cognitive Savvy — Здравый смысл.
• Knowledge Attracts Knowledge — Знание привлекает Знание (… чем больше я знаю, тем легче я учусь)
• Experimentation — Экспериментирование (… делает изучение направленным)
• Disposable Time — Доступное Время (… позволяет мне попробовать новые вещи)
• Stories — Истории (... правдивая история запоминается проще и воспринимается лучше)
• Contrasting Ideas (Skepticism, Critical thinking, Lateral thinking) — Критическое мышление (… приводит в лучшим идеям)
• Other Minds — Другие умы (... нанять эксперта в помощь. Наставничество это лучше, чем унылая школа и быстрее, чем самостоятельное обучение)
• Words and Pictures — Слова и Картинки (… как оформить презентацию для Заказчика — это очень важно, правильно подобрать слова и картинки)
• Systems Thinking — Системное мышление (... помогает взглянуть на процесс целиком)

См также:
Secrets of a buccaneer-scholar. James Marcus Bach — книга, из которой взяли мнемонику




MR.Q COMP GRABC R&R

Тактика для проведения исследовательского тестирования от Jon Bach. Подробнее см тут

• Modeling — моделирование
• Resourcing — определение ресурсов
• Questioning — умение задавать вопросы
• Chartering — умение думать о системе, а не только применять серебряную пулю (конкретные шаги, не универсальные, подходящие только для данной системы)
• Observing — наблюдение
• Manipulating — манипуляция
• Pairing — комбинирование
• Generating/Elaborating — создание / разработка
• Refocusing — перефокусировка
• Alternating — альтернативное мышление
• Branching/Backtracking — разделение специалистов по направлениям
• Conjecturing — умение делать предположения
• Recording — запись
• Reporting — составление отчета

FCC CUTS VIDS

Эвристика тестовых туров от Michael D Kelly. Подробнее см тут.

Feature tour
Complexity tour
Claims tour

Configuration tour
User tour
Testability tour
Scenario tour

Variability tour
Interopeability tour
Data tour
Structure tour

А теперь подробнее:

• Feature tour — Тур по фичам (функционалу). Пройдитесь по приложению и познакомьтесь со всем функционалом, который вам попадется.
• Complexity tour — «Сложный» тур. Найдите пять наиболее сложных вещей, которые умеет делать приложение и проверьте их.
• Claims tour — Тур по требованиям. Найдите всю информацию в продукте, которая рассказывает нам, что этот продукт делает. 
• Configuration tour — Тур по конфигурациям. Найдите все возможные способы изменить конфигурацию продукта, которую система потом сохранит.
• User tour — Тур пользователя. Представьте пять разных пользователей продукта и подумайте, какой функционал был бы для них в приоритете.
• Testability tour — Тур на тестируемость. Найдите все фичи, которые помогут вам в тестировании и / или найдите все интрументы, которые вам в этом помогут.
• Scenario tour — Тур по сценариям. Представьте пять реалистичных сценариев, как пользователи из тура пользователя использовали бы продукт.
• Variability tour — Тур изменений. Посмотрите на то, что ты можешь изменить в приложении — и попробуй изменить!
• Interopeability tour — Тур взаимодействий. С чем приложение взаимодействует?
• Data tour — Тур данных. Определите главные данные, которые есть в приложении.
• Structure tour — Тур структуры. Найдите все, что физически входит в продукт (код, интерфейс, программное обеспечение, файлы, итд)

См также:
Исследовательские туры от James A. Whittaker




SLIME

Эвристика приоритетов для тестирования от Adam Goucher. Подробнее см тут

• Security — Безопасность
• Languages — Локализация (многоязычность)
• RequIrements — Требования
• Measurement — Оценка (будущих задач)
• Existing functionality — текущий функционал

CCD IS EARI

Основные принципы нагрузочного тестирования (Performance Testing) от Scott Barber. Подробнее см тут.

• Context — Контекст. Это основа успешного нагрузочного тестирования.
• Criteria — Критерии. Критерии успешного выполнения теста с точки зрения бизнеса, проекта, системы. Пользовательские критерии.
• Design — Дизайн. Тест-дизайн, определение ключевых метрик, планирование и дизайн тестов.
• Install — Установка. Установите и подготовьте все необходимые инструменты и средства мониторинга.
• Script — Скрипт. Разработайте скрипт для тестирования, не забыв про тест-дизайн!
• Execute — Выполнение. Прогоните тесты, проверьте сами тесты, их данные и результат.
• Analyze — Анализ. Проведите анализ результатов самостоятельно и с командой.
• Report — Отчет. Соберите вместе результаты, адаптируйте под аудиторию и расшарьте их заинтересованным лицам
• Iterate — Повторить по необходимости.

IVECTRAS

Классификация нагрузочных тестов от Scott Barber. Подробнее см тут.
Чтобы спроектировать нагрузочные тесты, задайте себе вопросы:

INVESTIGATION or VALIDATION
of END-TO-END or COMPONENT
response TIMES and/or RESOURCE consumption
under ANTICIPATED or STRESSFUL conditions

В переводе

Исследование или Валидация?
Конечный продукт или отдельный компонент?
Время ответа и / или потребление ресурсов?
Ожидаемая нагрузка или стрессовое тестирование?




FIBLOTS

Модель нагрузки для нагрузочного тестирования от Scott Barber. Подробнее см тут.

Скотт долгое время использовал данные с продакшена для того, чтобы создать модель нагрузки. Но при этом экспериментировал, чтобы получить «хорошую модель» для тестирования без обращения к логам прода.

Так и получилась мнемоника, которая помогает решить, что включить в модель нагрузки.

• Frequent — Наиболее часто используемый функционал
• Intensive — Действия, требующие максимум ресурсов.
• Business Critical — Бизнес-критичный функционал. Даже если он встречается редко и нет рисков
• Legal — Функционал, который если перестанет работать, вы не получите денег. Или получите иск
• Obvious — Функционал, который если перестанет работать, заработает негативные отзывы в прессе.  
• Technically Risky — Технические риски. Новые технологии, старые технологии, места, в которых были баги ранее.
• Stakeholder Mandated — Функционал, который попросил заказчик. Не спорьте с боссом!

RSTLLL

Эвристика тестирования SMS, отправляемых приложением, от Karen N. Johnson. Подробнее см тут.

• Reply — Ответ. Могу ли я ответить отправителю?Получит ли он мое сообщение?
• Sender — Отправитель. Кто отправитель? Есть ли информация о нем? Если отправитель уже добавлен в адресную книгу, его имя должно отображаться. Если это человек, то это должно быть ФИО, такое, как хранится в адресной книге. Или может у вашего приложения есть название? Как информация об отправителе отображается в телефоне?
• Timestamp — Время. Каким временем отмечено сообщение? Какой часовой пояс используется? Это часовой пояс, который указывает само приложение, или который выяставляем телеком-компания при отправке сообщения?
• List — Список. Сообщение отправляется одному пользователю или списку лиц? Если рассылка идет на список пользователей, получит ли каждый это сообщение?
• Links — Ссылки. Содержит ли сообщение ссылки? Рабочие они или битые?
• Language — Язык. На каком языке отправлено сообщение? Что насчет Unicode символов? Что насчет не-латиницы?
• Length — Длина. Сообщение вмещает 160 символов. Получу ли я полное сообщение? Что, если ссылка внутри сообщения попадает на конец сообщения, будет ли она обрезана?

MUTII

Эвристика для тестирования от Jonathon Kohl. Подробнее в оригинале от автора, либо вот перевод статьи

• Market (рынок) -- целевая группа пользователей. Например, финансовый отдел или бухгалтерская контора среднего пошиба.
• Users (пользователи) -- реальные пользователи, которые будут использовать приложение. Кто они? Что делают? Какие у них мотивы использовать наш продукт?
• Tasks (задачи) -- для решения каких задач пользователь будет использовать продукт? Каковы его типичные рабочие задачи?
• Information (информация) -- как продукт расскажет мне о задачах, которые он автоматизирует, и как я смогу выполнить их?
• Implementation (реализация) -- легко ли использовать продукт первый раз? Он надежный? Могу ли я легко выполнить свои задачи с учетом дизайна продукта и предоставляемой им информации?

I SLICED UP FUN

Самая известная мнемоника для тестирования мобильных приложений! От Jonathon Kohl. Подробнее см тут.

• Inputs — Входные данные (вводимые с клавиатуры или набираемые пальцем).
• Store — Хранилище. Android Market, например.
• Location — Расположение (ошибки гео-координат, движение, быстрая остановка).
• Interactions/Interruptions — Взаимодействие / Прерывания. Сворачивание приложение, когда играет музыка, например.
• Communications — Входящий звонок, смс, уведомление...
• Ergonomics — Мелкие детали напрягают глаза, ищите такие проблемы
• Data — Данные. Все, что приложение обрабатывает.
• Usability — Удобство использования.
• Platform — Для каких платформ выпущено ПО, где будет работать?
• Function — Функционал.
• User Scenarioes — Пользовательские сценарии.
• Network — Сеть.

См также:
SQA Days 21. Эвристики и мнемоники для тестирования мобильных — там в том числе и эта мнемоника.
Тур по метро. The Metro Tour — про тестирование сети.
Тестирование игр на мобильных телефонах - Курс молодого бойца — слегка устарело, но не все!

COP FLUNG GUN

Еще одна похожая мнемоника для тестирования мобильных приложений:

• Communication — Коммуникация
• Orientation — Ориентация (горизонтальная, вертикальная)
• Platform — Платформа, OS
• Function — Функционал
• Location — Месторасположение, опредение гео-координат
• User scenarios — Пользовательские сценарии
• Network — Сеть
• Gesture — Жесты, как реагирует на работу пальцами
• Guidelines — Соответствует ли гайдлайнам
• Updates — Обновления
• Notifications — Уведомления

MOBILE APP TESTING

Мнемоника по тестированию мобилок от Daniel Knott. Автор ранее использовал «I SLICED UP FUN», а теперь готов показать свою версию. Подробнее см тут

Mobile Device — симуляторы и эмуляторы это все хорошо, но лучше тестировать на реальных устройствах. И выбор делать по целевой аудитории.

Orientation — Ориентация. Ну что тут посоветовать? Поворачивать девайс с горизонтали на горизонталь (переворот на 180 градусов), или с горизонтали на вертикаль (90 градусов).

Mobile Browsers — Мобильные браузеры. Как и обычные, проверяем разные браузеры, разрешения экрана, плотность пикселей. А еще переход из браузера в приложение и обратно.

Interrupts — Прерывания. Очень важная тема, еще со времен моего тестирования мобилок  живет. И до сих пор актуально! И самый простойтип прерывания — прозвон. Запускаете приложение и звоните на этот телефон с другого. Или шлете смс. А сейчас можно и в телеграмм написать, включив пуш-уведомления от него. Что будет по возвращении в ПО после разговора? Если там идет игра на время, таймер будет приостановлен на время разговора или нет?

Look — Внешний вид. Красивые скриншотики никто не отменял, однотипных приложений много и выбирают то, что симпатичнее смотрится.

Energy Consumption — Потребление батареи. Сколько энергии жрет приложение в активном состоянии? А в пассивном?


Automation — Автоматизация. Используйте Appium, Calabash, Espresso, XCUITest, Earlgrey, или любые другие инструменты, которые упростят вам жизнь!

Performance — Производительность. Что стоит проверять:

• Сколько времени приложение запускается
• Сколько времени ему надо, чтобы отрисовать первый экран после логина
• Перфоманс скролирования
• Переходы между окнами

Personas aka Users — Разрабатывая приложения, нужно понимать, для кого мы это делаем. Подумать о целевой аудитории, их проблемах или желаниях. И задавать себе вопрос «а делаю ли я то, что им будет нужно?»


Time & Date — Дата и время. Если ПО завязано на них, нужно проверить, как оно отреагирует на изменение параметра.

Ergonomics — Дизайн приложения очень важен! Если размер шрифта слишком мелкий или цвет слишком бледный, то приложением будет очень сложно пользоваться. Надо обращать внимание на эргономичные действия типа двойного тапа для поиска

Security — Безопасность очень важна. Если хакеры украдут данные пользователя, он никогда уже не вернется.

Tracking — Сейчас почти в каждом приложении есть сборщик данных. Чтобы разработчики понимали, как вообще пользователи используют их ПО, они собирают информацию. Это все должно работать автоматически.

Inputs — В мобилках есть несколько интерфейсов, куда пользователь может. Самый распространенный — тач скрин. Пользователь одним или несколькими пальцами «тапает» экран для ввода данных. А еще есть кнопки, камера и микрофон, не забывайте об этом!

Network — Проверка сети. Wi-fi, 3G, 4G. А что, если переключаться с одной на другую и обратно. А если сеть пропала и снова появилась. А если очень медленная...

Platform Guidelines — Это тоже про дизайн. Если дизайн перегружен элементами, пользователю сложно в нем разобраться. Так что используйте гайдлайны для своей платформы, чтобы убедиться в том, что дизайн неплох.

См также:
Мнемоника Mobile App Testing — перевод статьи автора

SPIES

Мнемоника для тестирования локализации (интернациональное ПО) от Nancy Kelln. Подробнее см тут

• Special Characters — Специальные символы. French, German, Spanish — в каждом языке есть свои особенные символы. Надо убедиться, что ваше приложение их поддерживает.
• Pages & Content — Страницы и контент. Нормально ли все отображается? Хорошо переведено? Влезает в отведенное место?
• Integrations — Интеграции. Окажут ли наши изменения негативные влияния на текущие интеграции?
• Error & Warning Messages — Сообщения об ошибках и предупреждения. Правильно ли переведены? Вообще переводили ли их?)) Влезают ли они в окно ошибки или место под строкой? На разных языках одна и та же фраза будет разной длины!
• Special Formats — Специальные форматы. Дата, время, таймзона, дробная часть числа — в разных языках это все может выглядеть по разному.

PAOLO

Тестирование мобильных приложений и смены ориентации экрана (горизонтальное — вертикальное) от Maik Nogens. Подробнее см тут

• Portrait —Есть ли разные режимы для разных поворотов экрана? 
• Audio — Поддерживается ли аудио? А беззвучный режим? Аудио настраивается по стандартному ползунку или в приложении собственные настройки громкости? Что, если потянуть ползунок двумя пальцами?
• Objects — Тут автор думает про структуру кода, устанавливаемые на устройство файлы и все такое.
• Landscape — Аналогично с Portrait, просто для красоты слова нужна была буквы L =)
• Overlay — Это поп-ап сообщение от вашего приложение, вылезающее, когда вы в другом приложении. Поддерживает ли приложение overlay? Если этот поп-ап вылезет, не потеряет ли пользователь данные? Что будет, если пользователь проигнорирует его? Есть ли у него таймаут? Что произойдет после таймаута? Сообщение пропадет навсегда или вернется через Х минут?

SEED NATALI

Мнемоника шагов для автоматизации GUI (графического интерфейса) от Albert Gareev.

• Synchronize — Синхронизация
• Exists — Наличие элементов на странице
• Enabled — Кликабельность (элементы доступны на редактирование)
• Displayed — Отображение элементов
• Number of Arguments — Количество аргументов
• Type of Arguments — Тип аргументов
• Log — Логи
• Investigate — Исследование

SPIFFy

Мнемоника микротеста от Industrial Logic

• Small — Маленький
• Precise — Точный
• Isolated — Изолированный
• Fast — Быстрый
• Frequently Run — Часто запускаемый

TERMS

Мнемоника для автоматизированных тестов от Albert Gareev.

• Tools & Technology — Выбор инструментов и технологий
• Execution — Запуск тестов
• Requirements & Risks — Анализ требований и рисков
• Maintenance — Поддержка тестов
• Security — Тестирование безопасности

CRUMBS

Еще одна Мнемоника для автоматизированных тестов от Albert Gareev.

• Confirmation, Coverage Criteria & Complexity — Критерии покрытия тестами и их сложность
• Risk, Robustness & Reliability — Риски, надежность и устойчивость
• Usefulness & Usability — Полноценность и юзабилити
• Maintainability & Manual Effort — Обслуживание тестов и затраты на ручной прогон
• Basis & Bias — Основные тесты и не сильно важные
• Span, Separation, & Security — Разделение и безопасность

GO DaRE=M

Мнемоника для составления тест-плана от Carsten Fielberg. Подробнее см тут

• Go as in “Go for Goal” — «Иди к цели!»
• Deliverables — результаты
• Activities — активности
• Resources — ресурсы
• Estimates — планируемое время
• Represents Balance — планируемые затраты (репрезентативные) 
• Milestones — этапы тестирования

PAPAS BE @ SFO

Мнемоника для API-тестов функционала от Anand Ramdeo

• Paging — страницы (например, просмотр всех страниц)
• Authentication — идентификация
• Parameters / Query Strings — параметры строки
• Authorisations — авторизация
• Security — безопасность
• Behave — поведение
• Error Handling — перехват ошибок
• State — состояние
• Filter — фильтрация
• Order — сортировка

DEED HELP GC

Еще одна мнемоника по API-тестам от Anand Ramdeo

• Domain Specific Names — понятные имена, специфичные для теста
• Examples — примеры
• Easy to Learn — простота изучения
• Documentation — документация
• Hard to Misuse — сложность неправильного использования
• Easy to Use — простота использования
• Lead to Readable Code — читабельный код, «говорящий»
• Principle of Least Astonishment / Surprise — меньше сюрпризов, больше предсказуемости
• Guessability — тесты можно оценить
• Consistency — консистентность

DVLA PC

Мнемоника для поддержки API-тестов от Anand Ramdeo.

• Diagnostic — диагностика (сложно ли понять, почему именно упал тест?)
• Versioning — версионирование (сохраняются ли версии тестов?)
• Logging — логирование (есть ли логи по прогону?)
• Accessibility — доступность (легко ли их понять?)
• Purpose — цель (достигает ли тест цели?)
• Consumer — потребитель (значимый ли тест?)

ICE OVER MAD!

Мнемоника по тестированию API от Ash Winter. Подробнее см тут.

• Integration – Интеграция. Как пользователи будут интегрироваться с сервисом? Через API или графический интерфейс?
• Consumers – Кто является потребителем сервиса? Конечный пользователь — человек или машина? Какие проблемы пользователя решает сервис?
• Endpoints – Какие у нас есть endpoint (даже не знаю, стоит ли переводить, это что-то типа ссылки, по которой подключается API, точка доступа)? Он единственный или есть разные варианты? Если их несколько, идет ли подключение через балансировщик? Какой уровень защиты нужно обеспечить?

• Operations – Какие операции выполняет бизнес через сервис? Есть ли аналогичные функции в пользовательском интерфейсе? У функции понятное название?
• Volume – Какой объем запросов к нам придет? Это будет постоянная нагрузка или редкие запросы с большим объемом данных? Какой объем одной транзакции? Архитектура кластерная или нет?
• Error Handling – Как сервис обрабатывает ошибки на серверной стороне? А на клиентской? Информативны ли сообщения?
• RESTful – Обладает ли сервис характеристиками RESTful сервиса? 

• Modularity – Модульность. Как разделены компоненты сервиса? Как они взаимодействуют между собой?
• Authentication – Какая аутентификация используется? Какой уровень защищенности? Шифруется ли информация или отправляется в открытом виде?
• Definitions – Что описывает данные на входе и выходе сервиса, что у нас есть? WSDL, WADL, XSD, XSLT? Какие HTTP-методы используются?

INVEST

Атрибуты хорошей юзер-стори (пользовательской истории):

• Independent — независимая
• Negotiable — обсуждаемая (cмысл в том, что история не является контрактом, а является кратким описанием функциональности, детали которой обсуждаются)
• Valuable to purchaser or customer — ценная для покупателя или пользователя
• Estimatable — оцениваемая (по ней ведь пишут код)
• Small — небольшая
• Testable — тестируемая

CIRCUS MATTA

Ревью пользовательских историй. Они должны обладать качествами:

• Completeness — полнота
• Independent — независимость
• Realisable — реализуемость
• Consistency — консистентности
• Unambiguity — однозначность
• Specific — специфика заказчика
• Measurable — измеримая
• Acceptable — приемлемая
• Testable — тестируемая
• Traceable — трассируемая (можно проставить взаимосвязи)
• Achievable — достижимая

CAN I USE THIS

Мнемоника для тестирования Usability от David Greenless

• Comparable Products — сравнение с аналогичными продуктами
• Accessibility — доступность
• Navigation — навигация
• Intuitive — интуитивно понятный интерфейс
• Users — пользователи, чего они ждут от ПО? Решаем ли мы их проблемы?
• Standards — соответствие стандартам
• Emotional Response — какие эмоции вызывает продукт
• Trunk Test — основные тесты
• Heuristic Evaluation — оценивание
• Instructions & Help Text — инструкции и текст из Help
• Satisfaction — удовлетворение

Список для чтения

Материалы в оригинале

Списки:

• Mnemonics and Heuristics, Maria Kedemo
• Testing Mnemonics, Sneha Bhat
• Testing Mnemonics, Ravnbak.net
• Software testing mnemonics, Ngyen H
• The Power of Mnemonics, Parimala Hariprasad
• KNJohnson-2012-heuristics-mnemonics.pdf (презентация), Karen Nicole Johnson

Отдельные мнемоники

• SFPDO (San Francisco Depot), James Bach
• Test Mobile Applications with I SLICED UP FUN!
• FEW HICCUPPS, Michael Bolton
• “Wiki” (WWWWWH/KE) requirements testing mnemonic, Darren McMillan
• Hiring Testers, Part 1: How about a cup of MOCHA?, Maria Kedemo
• SCAMPER, The Mind Tools Content Team
• MCOASTER, Michael D Kelly
• Failure Usability, Ben Simo
• PROOF, Jonathan Bach
• GRATEDD SCRIPTS, Jared Quinert
• SACKED SCOWS, мнемоника от James Bach
• Heuristics for Rapid Test Management (MR.Q COMP GRABC R&R), Jon Bach
• Touring Heuristic, Michael D Kelly
• SLIME, Adam Goucher
• Performance Testing Core Principles: CCD IS EARI, Scott Barber
• Classify Performance Tests: IVECTRAS, Scott Barber
• Model Workloads for Performance Testing: FIBLOTS, Scott Barber
• Testing SMS texting applications: Key steps and considerations, Karen N. Johnson
• Exploratory Testing: Finding the Music of Software Investigation (MUTII), Jonathon Kohl 
• International SPIES in Testing, Nancy Kelln
• PAOLO heuristic for iPad, Maik Nogens
• Go DaRE=M - a heuristic for testing plans, Carsten Fielberg
• Johnny Mnemonic - ICEOVERMAD, Ash Winter
• Mobile App Testing Mnemonic, Daniel Knott

Материалы на русском

Списки:

• Эвристики и мнемоники в тестировании: что это и как применять
• Эвристики и оракулы
• Мнемоники (видео)
• SQA Days 21. Эвристики и мнемоники для тестирования мобильных

Отдельные

• Регрессионное тестирование используя RCRCRC
• Исследовательское тестирование: В поисках музыки исследования ПО (MUTII)
• Мнемоника Mobile App Testing 

Еще про мнемоники:

• Тестирование мобильных приложений: подсказки и идеи для новичков

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков