Евристики та мнемоніки
Евристики – це швидкі, недорогі способи вирішення проблеми чи прийняття рішення. У світі тестування програмного забезпечення ми можемо використовувати евристики як виведені досвідченим шляхом підказки для прийняття рішень та вирішення проблем під час тестування. Вони можуть бути особливо корисними для створення припущень, якщо ми не впевнені, як почати тестування, або вичерпали ідеї, що робити далі.
Мнемоніка - це тип евристики, набір правил і прийомів, які допомагають ефективно запам'ятовувати необхідну інформацію (інформацію), зазвичай це слово-абревіатура чи фраза. Наприклад, всі пам'ятають дитячу мнемоніку "кожен мисливець бажає знати де сидить фазан", в якій за першими буквами кожного слова можна згадати порядок кольорів веселки.
Безліч відомих тест-евристик використовує мнемоніки і широко поширена помилка, що у евристик має бути мнемоніка, або що це те саме. Це не так. Евристики не вимагають мнемоніки, вони просто створюються таким чином, щоб їх було легше запам'ятати.
Евристики та мнемоніки можуть бути придумані, модифіковані та схрещені як зручно автору для своїх потреб. Ось найвідоміші:
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