Про эвристики и мнемоники

Когда я думаю о том, что же такое мышление тестировщика, первым делом вспоминаются эвристики и мнемоники. И вот почему.

Эвристика — это прошлый опыт (личный или командный), который используется при тестировании.

Есть два типа эвристик:

1. основанные на предыдущем опыте

🤩Пример: если в прошлых релизах после правок авторизации «ломалась» регистрация, то при новых изменениях в логике авторизации следует проверить и регистрацию тоже

2. основанные на информации о вероятности

🤩Пример: QA прочел статью, в которой автор уверяет, что ноль — потенциальный рассадник дефектов. Стоит это проверить!

💡 Выходит, чем больше мы работаем, тем больше эвристик собираем.

Мнемоники

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

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

Что почитать:

🤩статья на Хабре
🤩книга Ольги Назиной «Техники тест-дизайна» (целых 25 страниц по теме)
🤩доклад Владислава Романенко на SQA Days
🤩статья про эвристику для регрессионного тестирования

В этом посте собрала самые популярные эвристики и мнемоники в тестировании:

1⃣ SFDPOT (San Francisco Depot) — взгляд на продукт с разных сторон

Одна из самых известных мнемоник James Bach, где каждой букве в аббревиатуре соответствует некий аспект продукта, который можно проверять.

Structure — из чего состоит продукт?
Function — какие функции есть у продукта?
Data — какие данные он обрабатывает?
Platform — от чего продукт зависит? на каких ОС запустится?
Operations — как будет использоваться? кто будет его использовать?
Time — какие данные зависят от времени?

📍 Помогает, когда впервые видишь продукт и не понимаешь, с чего начать

2⃣ RCRCRC (3 RC) — регрессия

Recent — что изменилось в существующей функциональности?
Core — основные сценарии. что должно всегда работать?
Risk — где максимальные риски? (их и проверяем)
Configuration — на каком окружении и конфигурации должно работать?
Repaired — какую функциональность правили? ретест важных дефектов
Chronic — регресс областей, где баги были чаще всего

📍 Отличная база для регрессионного прогона

3⃣ MUTII — понимание продукта

Market — какая целевая группа пользователей?
Users — кто пользователи?
Tasks — какие задачи будет решать продукт?
Information — как продукт об этом сообщает?
Implementation — насколько удобно и надежно приложение?

📍 Универсальная эвристика для тестирования

4⃣ HEENA — работа со сложным продуктом

History — что менялось в продукте?
Explore — где и как проявляется наблюдаемая проблема?
Experiment + Experience — исследуем, опираясь на опыт
Note Taking — фиксируем информацию в заметках
Analyse — анализируем собранную информацию

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

5⃣ WWWWWH/KE — анализ требований

Who — для кого эта функция?
What — что должно быть сделано?
When — когда и кем это должно быть выполнено?
Where — где это будет использоваться? (в какой части системы, в каком окружении)
Why — зачем это нужно?
How — как это работает?
Knowledge — какие знания нужны? какие данные используются?
Experience — какой опыт нужен пользователю?

📍 Помогает не упустить важное до начала тестирования

6⃣ GRATEDED SCRIPTS — тестовая стратегия

Goals — что должно работать в продукте?
Risks — какие риски существуют?
Approach — какой подход необходимо использовать?
Tradeoffs — на какие компромиссы можно пойти? (время или покрытие тестами)
Environments — какие окружения есть?
Dependencies — какие есть зависимости?
Data — какие данные на входе?
Stakeholders — кто заказывает продукт?
Coverage — каким будет тестовое покрытие?
Resources — достаточно ли ресурсов?
Information — что нужно узнать о тестируемой задаче?
Prioritisation — что является самым важным?
Tooling — какие инструменты будут использоваться?

📍 Подойдет для написания тестовой стратегии

ставь лайк и сохраняй, чтобы не потерять 🔖

#куашная