Переклад. Ольга Алифанова
"Я знаю, як вимовити" банан "по буквах, але я не знаю, коли мені зупинитися", як сказала одна маленька дівчинка.
Принадність ідеально "сценарних" завдань в тому, що ми завжди знаємо, коли нам зупинитися. Остання нота, останній рядок діалогу в сценарії, останній шматочок порожнього місця на полотні означають, що кінець роботи близько. Якщо ви використовуєте сценарний підхід до тестування, то ви зупиняєтеся, якщо помітили проблему, або якщо у вас з'явилися питання / цікаві ідеї.
Якщо ви досліджуєте продукт, сказати, коли потрібно зупинитися, не так-то просто. На джем-сейшенах музиканти сигналізують один одному за допомогою очей і музики, коли потрібно затихнути або зупинитися зовсім. Для людини недосвідченого причини, що впливають на рішення закінчити роботу, можуть бути незрозумілими або незримими. Навіть в середовищі артистів менш досвідчені люди можуть бути не в змозі пояснити, чому все зупинилися, але у майстри своєї справи з поясненнями ніяких труднощів не буде.
Як нам визначити, коли потрібно зупинитися?
Перший крок на цьому шляху - це усвідомлення, що ми не можемо бути впевнені, що ми завершили свою роботу. Будь-яка спроба знайти відповідь на питання, коли потрібно зупинитися - це евристика. Евристики - швидкий і дешевий метод прийняття рішень. Вони ненадійні - можуть спрацювати, а можуть і ні. Вони абстрактні і можуть бути схожими один на одного. Вони залежні від контексту - передбачається, що ними буде користуватися досить компетентний і досвідчений чоловік. Вони схожі на лампочки на приладовій панелі вашої машини. Коли якась із них загоряється, вам потрібно вирішити, а не зупинитися чи до того моменту, поки вона знову не стане зеленою - але, можливо, важливіше ігнорувати її і продовжувати рух?
Я склав список евристик для зупинки тестування, а також навів причини для сумнівів в кожній з них.
1. Час вийшов! Найпоширеніша причина закінчити тестування: наш час, відведений на нього, минув.
Чи отримали ми потрібну інформацію? Наскільки високий ризик, пов'язаний з припиненням тестування прямо зараз, може, потрібно його продовжувати? Наш дедлайн нав'язаний штучно? Може, він обраний випадково? Чи ведеться ще розробка, чи знадобиться тестувати продукт надалі?
2. Піньята. Ми перестаємо лупити продукт палицями, коли з нього починають сипатися цукерки - ми закінчуємо тестувати, як тільки виявляємо першу досить серйозну проблему.
Може, частина цукерок застрягла в нозі піньята? Знайдена нами "перша серйозна проблема" найзначніша, або єдина, гідна уваги? Чи можемо ми знайти інші цікаві проблеми, якщо продовжимо? Що, якщо ми неправильно сприймаємо серйозність знайденої, і насправді вона не так вже й критична?
3. Дохла кінь. Програма надто забагована, щоб подальше тестування мало сенс. Ми розуміємо, що все може змінитися настільки сильно, що результати нашого тестування перетворяться на гарбуз.
Ми опираємося на припущенні, що ми вже знайшли порядно цікавих і важливих багів. Якщо ми зупинимося зараз, ми точно не упустимо що-небудь ще більш важливе і цікаве?
4. Місія виконана. Ми закінчуємо тестування, коли знайшли відповіді на всі поставлені нами запитання.
Наше тестування могло викликати нові питання. Це призводить нас до евристики Румсфельда - "існує відоме невідоме і невідоме невідоме". Чи достатньо "відоме невідоме" зрушила в бік відомого завдяки нашому тестуванню? Розкрили ми щось нове і значуще з "відомого невідомого"? І важкий, але важливе питання - чи задоволені ми тим, як ми просунули "невідоме невідоме" в область відомого (або хоча б "відомого невідомого")?
5. Місія скасована. Наш клієнт попросив нас припинити тестування. Можливо, ми вийшли за рамки бюджету, або проект скасували, або що завгодно ще було тому причиною. Незалежно від приводу, ми зобов'язані зупинитися (евристика "Час вийшов" може бути особливим випадком "Скасування місії", якщо рішення про те, що час вийшов, приймає клієнт, а не ми).
Чи добре наш клієнт усвідомлює цінність тестування, якщо воно буде тривати, або ризики припинення його прямо зараз? Якщо ми з ним не згодні, чи достатньо ми знаємо про бізнес-причини зупинити тестування?
6. Я застряг! Ми зупиняємося, тому що нам щось заважає. У нас немає потрібної інформації (багато хто скаржиться, що не можуть тестувати без специфікації, наприклад). В системі блокуючий баг, і ми не можемо дістатися до тієї області, яку хочемо протестувати. У нас немає потрібного обладнання або необхідних інструментів. Нам не вистачає досвіду, щоб виконати спеціалізований тест.
Вибратися з глухого кута можна безліччю способів. Можливо, нам потрібна допомога, а можливо, просто перепочинок (див. Нижче). Може бути, якщо ми продовжимо тестування, ми дізнаємося те, що нам необхідно. Може, мета тестування - це саме дослідження продукту в пошуках якої бракує інформації. Може, блокер можна обійти, може, обладнання та інструменти нам доступні, просто ми нічого про це не знаємо чи не запитали потрібних людей правильним чином. Можливо, всередині команди, або серед розробників, або на бізнес-стороні є експерти, які можуть нам допомогти, але ми цього не усвідомлюємо. Між відчуттям, що ви застрягли, і реальним застреванием є деяка різниця.
7. Пауза для відпочинку. Ми не зупиняємо тестування - ми припиняємо його. Ми беремо паузу, тому що ми втомилися, або занудьгували, або нас покинуло натхнення. Можливо, пауза потрібна, щоб щось з'ясувати чи спланувати, а може, щоб поміркувати про те, що ми вже зробили, з метою з'ясувати, що нам робити далі. Основна ідея в тому, що нам потрібна перерва, і пізніше ми повернемося до продукту відпочили і зі свіжим поглядом.
Є й інший тип паузи - ми можемо призупинити тестування, тому що інша функціональність на даний момент має більш високий пріоритет.
Звичайно, ми можемо занудьгувати або втомитися, але може, важливіше продовжувати тестувати, не дивлячись ні на що? Може, ми більш ефективно вивчимо продукт саме зараз? Може, важливий шматок інформації знаходиться всього лише в одному тесті від нас? Більш пріоритетне завдання дійсно більш пріоритетна? Інша функціональність готова до передачі в тестування? Може, ми вже досить добре протестували її?
8. Плато. Що б ми не робили, результат однаковий. Може, додаток краш або перестає відповідати, але однакові результати можна отримати і в разі, коли додаток особливо стабільно - "ну, ніби все ок".
Додаток дійсно звалилося з кінцями, або намагається відновитися? Відсутність відгуку само по собі - важливий результат тесту? Ми дійсно перепробували все-все-все і включили в свої тести досить варіацій і різне навантаження?
9. Так прийнято. Ми припиняємо тестувати, як зазвичай. У нас є правила щодо певної кількості тест-ідей, кейсів або циклів тестування, і коли певна кількість роботи виконано, ми зупиняємося. Кажуть, Agile-команди діють саме так - "коли пройдені всі приймальні випробування, ми готові до релізу".
Ця евристика відрізняється від "Час вийшов" - час більш еластично. Цей підхід досить широко поширений - ми часто чуємо, що досить гарне тестування вважається тим, де є хоча б один тест на кожну вимогу (або хоча б один негативний і один позитивний тест на кожну вимогу). Я не згоден, звичайно ж, але це поширена точка зору.
Критично ми підходимо до питання, чому ми завжди зупиняємося саме тут? Чи не потрібно протестувати продукт додатково? Може, потрібно тестувати його менше? Чи є доступна нам інформація - наприклад, від відділу продажів, служби підтримки або зовнішніх спостерігачів - яка сигналізує, що нам варто відійти від звичних шаблонів? Розглянули ми інші евристики?
10. Цікавих питань не залишилося. Ми вирішили, що ніякі питання більш не виправдовують ціну пошуку відповідей на них, і ми завершуємо тестування. Ця евристика інформує, що якщо будь-яке питання або ризик досить важливі, ми продовжимо тестувати.
Чи впевнені ми в своєму моделюванні ризиків? Чи немає небезпеки влетіти в "чорного лебедя" (або білого лебедя, який був проігнорований)? Чи досягли ми достатнього покриття? Чи надійні наші оракули?
11. Байдужість. Іноді людям все одно, чи отримають вони додаткову інформацію, або вони просто не хочуть знати, що відбувається в додатку. Додаток може бути першим начерком, який скоро буде замінений. Іноді люди припиняють тестувати, бо вони ліниві, мають погані наміри, або не мотивовані. Іноді бізнес-причини для релізу настільки важливі, що жодна уявлені проблема не скасує реліз, тому що б ми не знайшли, це не має значення.
Якщо нам стало все одно, навіщо ми взагалі починали тестувати? Чи не забули ми про свої пріоритети? Якщо хтось перестав тестувати - чому він це зробив? Іноді бізнесу простіше не знати про проблему, ніж знати про неї і нічого не зробити - може, це якраз той випадок?
12. Відмова від місії. Ми припиняємо тестувати, якщо результатом продовження тестування стане проблема - наприклад, етична - для конкретної людини.
Чи будете ви продовжувати тест, якщо він дасть фальшиві результати? Спричинить за собою брехня? Збиток для цінного обладнання? Збиток для людини, як в експерименті Мілграма або Стенфордському експерименті. Може, жертвою буде не піддослідний, а клієнт - чи будете ви продовжувати, якщо витрати на тестування (включаючи вашу зарплату) непропорційні цінності від тестів? Може, жертва - ви самі? Зупиніться ви, якщо вам недостатньо платять?