Навіщо ми створили цю перевірку

Переклад. Ольга Алифанова

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

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

Але чому ця чудова, добре складена і зрозумілі перевірка взагалі є? Чому вона існує? Чому з усіх варіантів перевірок була обрана саме вона? Я можу її прочитати (як я вже говорив, вона добре написана), я бачу, що саме вона перевіряє, але цим інформація про неї вичерпується. Як я зрозумію, що кроки і умови перевірки відповідають її первісної мети? Що саме в цій перевірці або цю поведінку системи зробило їх гідними кандидатами на автоматизацію? Я не знаю.

Чому нас повинен хвилювати питання "навіщо потрібна ця перевірка"? З моєї точки зору, результати Автотест впливають на хід нашого тестування, особливо в командах, які працюють по безперервній інтеграції. Перед тим, як почати ручне тестування (припустимо для зручності, що воно стартує, як тільки готовий код), ми проганяє Автотест, і вони повідомляють, "хороший" вийшов білд або "поганий". Я узагальнюю, так як все ще роздумую над цим, але якщо білд "поганий", ми миттєво концентруємося на проблемах і прагнемо зробити його "хорошим". Ми дивимося на інші перевірки в проблемних областях, щоб дізнатися, що ще було вкрите, і потім створюємо і проганяє нові тести, щоб дізнатися більше. Після цього ми переходимо до нових завдань. Якщо білд "хороший", то, як правило, ми фокусуємося на нових завданнях відразу ж. Як я вже сказав, я узагальнюю, я знаю, що так відбувається не завжди, але думаю, ідея зрозуміла.

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

Ось кілька способів вказівки мети створення перевірки:

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