Евристики і мнемоніки в тестуванні: що це і як застосовувати

Мій досвід в тестуванні — близько двох років. Я людина допитлива і захоплений своєю справою, тому намагаюся постійно займатися самонавчанням — підтягую знання і навички в новій для мене професійній сфері.

Вперше я зіткнулася з терміном «тестова евристика», коли мені на очі попався James баха добре s Blog . Саме з нього почався мій інтерес до тестових евристикам і мнемоникам. На сьогоднішній день найбільш актуальна частина матеріалів по тестуванню представлена як раз таки англомовним контентом.

Прочитавши цю статтю, ви ознайомитеся з основними тестовими евристиками і мнемониками, дізнаєтеся, навіщо і для чого вони застосовуються, в чому їх переваги і недоліки, побачите реальні приклади їх практичного застосування та зможете дізнатися, як створити свою евристику. Я поділюся з вами власної евристикою, яку я використовую для приймального тестування, і розповім про її переваги.

Порівняно з іншими методами, метод евристичної оцінки простіше, легше і швидше. Він дозволяє виявити основні проблеми тестованого продукту в найкоротші терміни і з мінімальними матеріальними і тимчасовими витратами. Вивчаючи різні евристики і мнемоніки, тестувальник зможе значно розширити свої погляди на можливі проблеми досліджуваного продукту, а також відкрити для себе нові методи і підходи до самого процесу тестування. Навички використання тестових евристик можуть значно підвищити ефективність процесу тестування продукту.

Що таке евристики і мнемоніки

Тестування за допомогою евристик — це тестування алгоритмів, програм або будь-яких інших видів проектів, при якому стратегія тестування ґрунтується на попередньому досвіді та інформації про ймовірність різних подій.

Мнемоніка — сукупність правил і прийомів, які допомагають запам'ятовувати потрібну інформацію і дані.

Переваги тестових евристик:

Евристики не дають забути контекст, в якому використовується досліджуване додаток.
Стислість. Евристики зручно накидати в mindmap, записати в невеликому текстовому файлі або просто на аркуші паперу. Для запам'ятовування евристик можуть використовуватися мнемоніки.
Евристики допомагають провести дослідницьке тестування програми в більш детальному і повному форматі.
Вони допомагають уникнути повторення помилок, допущених в аналогічних ситуаціях при тестуванні схожого. Тестові евристики створюють «нагадування» на основі попереднього досвіду — особистого чи досвіду інших тестувальників.

Однак евристика — недосконалий метод. Основний недолік тестових евристик полягає в тому, що оскільки евристична оцінка не передбачає тестування і аналізу поведінки реальних користувачів, що її результати можуть бути необґрунтованими і досить суб'єктивними.

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

Евристика відноситься до техніки тест-дизайну, заснованому на досвіді, і допомагає у вивченні, дослідженні та вирішенні певної задачі.

Евристичний метод найчастіше використовується з метою як можна швидше прийняти рішення, яке буде найбільш близько до правильного, «оптимального».

Евристичний алгоритм — це алгоритм пошуку рішення задачі, правильність якого для всіх можливих випадків не доведена, але який дає найбільш правильне рішення в більшості випадків використання.

У кожного тестувальника є свій набір евристик, щодня застосовуваних у процесі тестування. Вони виробляються з досвідом, і щоб дізнатися про евристиках більше, потрібно зрозуміти, як мислять інші люди, і зуміти описати власний розумовий процес.

Евристики і мнемоніки допомагають нам описувати процес нашого тестування.

Відмінність евристики від мнемоніки

Мнемоніка — це інструмент, що дозволяє запам'ятовувати інформацію більш простим і доступним способом. Зазвичай мнемоніка працює як основний ключ до того, що ви хочете запам'ятати, але не говорить нічого про те, що саме ви намагаєтеся запам'ятати.

Евристика — це так зване «правило великого пальця або часткового оракула», що використовується для швидкого вимірювання чого-небудь. У тестуванні вона зазвичай використовується для вивчення поведінки програм з метою швидко знайти потенційні проблеми.

Очевидно, що головна причина їх взаємодії полягає в тому, що мнемоніка часто потрібна для того, щоб нагадати про евристиці.

Все, що ми робимо і використовуємо в тестуванні, є евристичним. Всі моделі, оракули і методи тестування — евристика.

Використовуючи мнемоніку, можна генерувати ідеї для тестування продукту, який, у свою чергу, може призвести до використання евристики.

Мнемоніка — це корисний інструмент, що допомагає згадати схеми різних моделей тестування, які згодом можна використовувати в ході роботи.

Евристика — це алгоритм, який допомагає орієнтуватися в просторі рішень конкретної задачі.

Коли ідеї для тестування закінчуються, завжди є під рукою евристики, які підкажуть, що ще можна зробити. Можна і потрібно використовувати досвід інших тестувальників. Ось кілька прикладів широко відомих евристик:

Test Heuristics Cheat Sheet (Елізабет Хендріксон);
Heuristic Test Strategy Model (Джеймс Бах).

Розуміння, як мислять інші тестувальники, допомагає урізноманітнити власний підхід до тестування.

SFDPOT & CRUCSPIC STMP

Кожен фахівець з тестування рекомендує використовувати різні інструменти і мнемонічні схеми. Вони фокусують і направляють тестові роботи.

З їх допомогою тестувальники можуть швидше виявити критичні помилки в різних областях програмного забезпечення, ніж коли покладаються тільки на свою інтуїцію і досвід.

Деякі експерти в області забезпечення якості часто використовують мнемонічний схему SFDPOT, розроблену Джеймсом Бахом. Вони стверджують, що це ефективний інструмент для генерації тестових ідей.

SFDPOT (Structures, Functions, Data, Platforms, Operations, Time):

S tructure — структура програми, перевірка його складових частин. На даному етапі розробляються тестові ідеї та сценарії, пов'язані зі структурою програми.
F unction — функціональність програми, перевірка того, що додаток робить. На цьому етапі розробляється функціональне тестування програмного продукту.
D ata — робота з даними; перевірка того, як програма працює з даними. Тестувальники повинні дізнатися, з якими даними працює система, і розробити тести, що перевіряють, як система отримує, обробляє і видає різні види даних.
P latform — платформа; перевірка того, як додаток взаємодіє з платформою, на якій запущено. Тестувальники повинні визначити, на яких платформах виконувати ручне та автоматизоване тестування.
O perations — використання, перевірка сценаріїв використання програми. У цьому пункті тестувальники повинні з'ясувати, хто кінцеві користувачі досліджуваного програмного продукту, для яких завдань користувачі збираються його використовувати.
T ime — час, перевірка того, як додаток поводиться в залежності від часу.

Карен Н. Джонсон (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

Регрессионное тестування — це тестування, призначене для повторної перевірки властивостей програми або програмного продукту з метою переконатися в тому, що після внесення змін або додавання нового функціоналу програма працює коректно.

Щоб не забути ті аспекти, які слід взяти до уваги при плануванні регресійного тестування, Карен Н. Джонсон створила евристику, що складається з шести частин:

R ecent — Нещодавнє
C ore — Основне
R isky — Ризикове
C onfiguration sensitive — Чутливе до конфігурації
R epaired — Виправлене
C hronic — Хронічне

Мета даної евристики — допомогти у вивченні різних аспектів досліджуваного програми і виділити або виявити області для регресійного тестування.

Для запам'ятовування цієї евристики можна використовувати абревіатуру, що складається з перших літер — RCRCRC: Recent-Core-Risky-Configuration sensitive-Repaired-Chronic.

1. Recent (Нещодавнє)

Що було недавно додано в додаток? Недавні зміни — від очевидних до ледь помітних — можлива причина появи дефектів. Очевидні зміни включають в себе нові функціональні можливості або оновлення існуючої функціональності.

Теоретично повинен існувати набір регресійних тестів, які можуть бути виконані вручну або автоматично, щоб переконатися в тому, що недавні зміни не створили нових проблем і що існуючі функціональні можливості і раніше, працюють коректно. На практиці ж може не бути достатньо часу для повторного запуску всіх регресійних тестів, і замість цього потрібно вибрати деякий підмножина тестів з повного набору на підставі того, що змінилося у складанні або релізі, який тестується.

2. Core (Основне)

Регрессионное тестування призначене для того, щоб запобігти випуск продукту з новими проблемами у функціональних можливостях, які існували в попередніх релізах. Необхідно визначити області додатки, які зобов'язані працювати «в будь-якому разі» — таким чином можна отримати ключові функціональні можливості.

3. Risk (Ризикове)

Для фахівця, тестуючого продукт, неважко згадати області підвищеного ризику в додатку — будь то нові функціональні можливості або старі. Якщо відомо, де були проблеми в минулому, буде легше визначити область ризику в сьогоденні. Можна використовувати систему контролю помилок для акцентування уваги на тих областях продукту, які в минулому мали найбільше проблем.

4. Configuration sensitive (Чутливе до конфігурації)

Код, який залежить від параметрів оточення, тобто чутливий до конфігурації, більш вразливий. Облік таких особливостей додатка допомагає приймати рішення про необхідність повторного тестування конкретних функціональних можливостей — і про те, в якому оточенні необхідно це робити.

5. Repaired (Виправлене)

Деякі функції програми ніяк не вдається реалізувати або поправити з першої спроби. Їх постійно супроводжує шлейф дефектів, для усунення яких доводиться випускати декілька внутрішніх релізів. Необхідно повторно протестувати відсутність знайдених помилок і повторно тестувати функціональні можливості, щоб переконатися в тому, що складні функції готові до випуску.

6. Chronic (Хронічне)

Деякі області продукту, здається, переслідує закон Мерфі: якщо щось може зламатися, воно обов'язково зламається. Чим довше працює фахівець із продуктом, тим більше він знає про те, де проблеми були, де вони є зараз і де їх можна чекати у майбутньому. Інша перевага тривалої роботи з продуктом — це швидкість, з якою він може перевірити всі проблемні точки для отримання впевненості в його якості.

Резюме

З діаграмою функціональних можливостей продукту або контрольним списком у руках, спеціаліст з забезпечення якості продукту готовий розпочати роботу. Регрессионное тестування, найімовірніше, не виявить нових проблем, тому можна швидко пройти весь список, навіть якщо він виглядає досить довгим. Найкраще планування регресійних тестів виростає з хорошого знання програми. Але для того, щоб уникнути шаблонного тестування одних і тих же областей та пропуску інших, має сенс використовувати евристику RCRCRC, щоб окинути поглядом всю картину відразу.

CIDTESTD

C ustomers — Користувачі
I nformation — Дані
D eveloper relations — Взаємодія розробників
T eam — Команда
E quipment & Tools — Обладнання та інструменти
S chedule — Графік тестування
T est items — Тестові об'єкти
D eliverables — Очікувані результати

Ця евристика використовується для високорівневого планування процесу тестування, допомагає сфокусуватися на тестуванні перш за все логічно. Це, в свою чергу, допомагає встановити контекст і об'єкти тестування.

CRUSSPICSTMPL

C apability — Можливість
R eliability — Надійність
U sability — Зручність використання
S ecurity — Забезпечення надійності
S calability — Масштабованість
P erformance — Продуктивність
I nstallability — Можливість установки
C ompatibility — Сумісність
S upportability — Можливість підтримки системи
T estability — Тестування
M aintainability — Зручність обслуговування
P ortability — Переносимість
L ocalisability — Локализуемость

Ця евристика являє собою повний та необхідний перелік якісних характеристик системи. Карен Н. Джонсон вважає за краще користуватися ISO 9126 (міжнародний стандарт, що визначає оціночні характеристики якості ПЗ), але CRUSSPICSTMPL дає чудове покриття основного функціоналу системи. А закінчення «ity» в кінці майже кожного слова евристики допомагає зосередитися на QualITY (якість) продукту.

FDSFCURA

F unction Testing — Функціональне тестування
D omain Testing — Тестування доменних імен
S tress Testing — Стрес-тестування
F low Testing — Тестування потоків
S cenario Testing — Тестування сценаріїв
C laims Testing — Тестування вимог
U ser Testing — Користувальницьке тестування
R isk Testing — Тестування ризиків
A utomatic Testing — Автоматизація

Ця евристика являє собою перелік всіх типів тестування, які необхідно застосовувати для перевірки системи. Вона показує, що існує безліч тестів, якими ми можемо перевірити продукт, для того, щоб зрозуміти, що і як ми повинні тестувати.

Оракул — це евристичний механізм, який допомагає визначити проблему. Прикметник «евристичний» вказує на те, що цей механізм, як і будь-яка інша евристика, схильний до помилок. Тобто він допомагає, але не завжди. Зате його порівняно легко використовувати — ще одна властивість, характерна для евристики.

Інше визначення оракула говорить про те, що це спосіб генерації очікуваного результату тесту.

Ці два визначення схожі, вони обидва пов'язані з визначенням результату тесту і розпізнаванням правильного і неправильного поводження продукту. Але є в них і принципове розходження: перше в основному використовується в контексті виявлення проблем, друге — в контексті розробки тестів.

HICCUPPSF

HICCUPPS(F) — це оракул, який допомагає запам'ятати евристику послідовності принципів і механізмів, за допомогою яких можна швидко й у короткі терміни виявити проблеми в досліджуваній системі. HICCUPPS(F) представлений у вигляді збірника універсальних типів оракулів для виявлення проблем.

H istory (Історія) — нинішня версія системи відповідає попередніх версій продукту.
I mage (Зображення) — зовнішній вигляд продукту відповідає макету системи замовника.
C omparable Products (Аналогічні продукти) — система відповідає аналогічним системам. Вони включають в себе інші продукти в одній і тій же лінійці продуктів; конкурентоспроможні продукти, послуги або системи; або продукти, які не відносяться до однієї і тієї ж категорії, але обробляють одні і ті ж дані; або ж альтернативні процеси і алгоритми.
C laims (Вимоги) — продукт відповідає вимогам замовника.
U sers' Expectations (Очікування користувачів) — система відповідає потребам кінцевих користувачів.
P roduct (Продукт) — кожен елемент системи (або продукту) буде відповідати порівнянних елементів в одній і тій же системі.
P urpose (Мета) — система відповідає явним і неявним цілям і потребам користувачів.
S tatutes (Закони) — система відповідає законам і правилам, які описують даний продукт і його використання.
F amiliarity (Обізнаність) — «F» означає «Familiar problems» (схожі проблеми). Іншими словами, система не відповідає жодній з проблем, з якими стикався раніше тестувальник.

MAC RUSS — евристика автора статті для приймального тестування

Приймальне тестування — це формальний процес тестування, який перевіряє відповідність системи вимогам і проводиться, щоб визначити, чи задовольняє система приймальним критеріям та замовник або інша уповноважена особа вирішила, приймається додаток чи ні.

Щоб спланувати приймальне тестування і почати його з основних особливостей, що я створила евристику, яка складається з наступних частин:

M aintainability — Зручність супроводу
A vailability — Доступність
C onfigurability — Здатність до конфігурації
R eliability — Надійність
U sability — Зручність використання
S ecurity — Безпека/забезпечення надійності
S calability — Масштабованість

Для запам'ятовування цієї евристики можна використовувати абревіатуру, що складається з перших букв 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 Johnson N.
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 & Мнемоніка , by Karen Johnson N.
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 Johnson N.
The Big Exploratory Testing Rolling Strategy Dice , by Shmuel Gershon
Heuristic Evaluation: How to Conduct a Heuristic Evaluation , by Euphemia Wong
Testing Мнемоніка , 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
Мнемоніка in Software testing , by Rishi Arora
Testing Мнемоніка — Desktop Download , by Del Dewar
Heuristics Testing , techopedia
Евристичний алгоритм , wiki
Mnemonic != Heuristic , Ministry of Testing

Блоги

Satisfice blog, Heuristic , James баха добре s blog
Thoughts from the test eye , blog
Testing Мнемоніка , i'm tester blog
Jonathan Kohl , blog
, Ash winter's blog

Опубліковано: 29/06/18 @ 10:28
Розділ Блоги

SEO Блог