Парадокс пестициду та підтримка ефективності тест-кейсів
На більшості проєктів трапляються такі ситуації, коли чим більше ми тестуємо продукт, тим більший імунітет виробляється у багів, які ми намагаємося знайти, використовуючи наші тестові набори. Коли одні і ті самі тести повторюються знову та знову, то врешті-решт вони перестають знаходити нові баги. У такій ситуації, навіть детально описаний тест-кейсами, функціонал може бути не протестований досить ретельно і до користувачів можуть потрапити серйозні баги.
Так само як і у комах, у багів ПЗ, що тестується може розвинутися опір до одного і того ж пестициду, тобто сформуватися імунітет до вже існуючих тест-кейсів. Такий феномен і називається ефектом пестициду. Цей термін близько 30 років тому придумав американський інженер Борис Бейзер. Суть цього ефекту полягає в тому, що багатократне застосування однакових методів з часом стає неефективним, оскільки шкідники, що вижили, вже мають імунітет.
Чому з часом тест-кейси перестають бути актуальними?
Звичайно ж, найпростішими причинами можуть бути ситуації, коли на проєкті вносяться зміни, додається новий функціонал або ж оптимізується старий. Оновлення тест-кейсів у такому разі потрібне і без урахування ефекту пестициду. Але навіть у разі, коли проект сильно не змінюється, існує потреба оновлювати набір тестів для пошуку нових і нових багів, які, без сумніву, є у будь-якому продукті.
Існує декілька причин, чому один і той же набір тест-кейсів перестає приносити хороший улов багів.
По-перше, просто неможливо спочатку передбачити всі доступні сценарії для тестування. Навіть якщо тестоване ПЗ досить просте, написати вичерпну кількість тестів, які знайдуть всі баги, на жаль, нереально. Не кажучи вже про складні системи з величезним набором даних, що входять, залежностей і сценаріїв розвитку. Тому будь-які нові ідеї про те, як можна протестувати продукт мають бути перевірені та додані в арсенал тестувальника.
По-друге, з часом тестувальник звикає до проєкту, йому стають знайомими всі проблемні місця тестованого ПЗ і є ризик, що він може пропускати дефекти або навіть прийняти побачений дефект за обумовлену раніше особливість функціоналу. Коли тестувальник працює на проєкті півроку або більше, йому необхідно раз по раз виконувати регресійне тестування та проходити один і той же набір тестів, то зберегти свіжий погляд на продукт – нелегке завдання.
Як підтримувати тест-кейси?
Дуже важливо при тестуванні використовувати набір різних підходів і технік, щоб подивитися на ПЗ під різними кутами: з точки зору структури проекту, його функцій, даних, що ним обробляються. Важливо також розуміти, як користувачі взаємодіятимуть з ПЗ, які можливі проблеми у них можуть виникнути. Адже можна написати сотні тест-кейсів і все одно пропустити важливий баг. Існує безліч технік, які допомагають тестувальникові в ретельному дослідженні ПЗ з різних сторін.
Наприклад, є ряд мнемонік, які допомагають тестувальникам розширити кількість і ефективність проєктованих тестів. Одна з популярних мнемонік – SFDPOT (San Francisco Depot), придумана Джеймсом Бахом. Кожна буква в SFDPOT представляє аспект тестованого продукту, який треба перевірити:
- Structure – визначає з чого складається ПЗ.
- Function – що робить ПЗ, його функції.
- Data – які обробляє дані.
- Platform – на яких платформах підтримується ПЗ.
- Operations – як ПЗ використовуватиметься.
- Time – як ПЗ поведе себе залежно від часу.
Ще одна мнемоніка – I SLICED UP FUN, яка придумана Джонатаном Колом для тестування мобільних додатків, нагадує про те, що необхідно перевірити:
- Input – можливі способи передачі інформації додатку.
- Store – вимоги магазинів додатків.
- Location – місце розташування користувача.
- Interactions/interruptions – переривання роботи.
- Communication – зв'язок.
- Ergonomics – ергономіка.
- Data – оброблювані дані.
- Usability – зручність використання.
- Platform – підтримуванні платформи.
- Function – функціонал.
- User scenarios – сценарії використання.
- Network – мережа.
Існує множина інших мнемонік, наприклад:
RCRCRC (Recent – Core – Risky – Configuration sensitive – Repaired – Chronic) – для допомоги при регресійному тестуванні.
COP FLUNG GUN (Communication – Orientation – Platform – Function – Location – User Scenarios – Network – Gestures – Guidelines – Updates – Notifications) – для тестування мобільних додатків.
Завдяки погляду на продукт з різних сторін, можна придумати багато хороших тестів. Використання мнемонік допомагає зменшити ризик того, що тестувальник забуде звернути увагу на важливу частину ПЗ, дає можливість прибрати хаотичне генерування ідей для тестів і виробити більш структурований підхід до тестування і/або проєктування тестів. Виконавши список перевірок по мнемоніці, тестувальник знатиме, що головні сторони продукту протестовані та нічого не випущено. Звичайно ж, мнемоніки – це не вичерпний тест-план, але зручний помічник під час генерації ідей.
Для уникнення ситуації, коли існуючий тестовий набір не співвідноситься з поточним станом ПЗ і перестає бути актуальним, його необхідно поповнювати перевірками всякий раз, коли ПЗ змінюється та поповнюється новим функціоналом.
Наступні поради допоможуть підтримувати актуальність тест-кейсів:
- Редагуйте вже існуючі тест-кейси при зміні ПЗ.
При першому проєктуванні кейса враховуйте, що, можливо, в майбутньому вам доведеться його правити. Тому намагайтеся писати легко тест-кейси, що виправляються. Майбутній ви або ваш колега скаже вам велике спасибі за це.
- Переміщайте застарілі та непотрібні тест-кейси з актуального тестового набору.
Якщо ви бачите, що функціонал, який перевіряється тест-кейсом прибрали – переносьте цей тест в архів, де він спокійно відпочиватиме та чекатиме можливого повернення свого функціонала. Видаляти тест-кейси зовсім не рекомендується, оскільки завжди існує вірогідність того, що функціонал захочуть повернути на прохання користувачів, за бажанням менеджера або з будь-яких інших причин.
- Додайте нові тест-кейси, необхідні для перевірки нового функціоналу.
Кожного разу, коли команді тестування доручається перевірити новий функціонал, варто написати хоч би базовий набір тестів, який пізніше можна буде розширити. Звичайно, бувають ситуації, коли завдання закінчити потрібно на учора і продукт має бути протестований якнайскоріше, але і в такому разі слід записати, які сценарії ви збираєтеся протестувати, хоч би у вигляді назв тест-кейсів без заповнення всіх його атрибутів. Це допоможе вам вдумливіше підійти до тестування зараз, а пізніше, коли пожежа на проєкті вщухне, ви зможете закінчити тест-кейси.
- Додайте тест-кейси для перевірки сценаріїв пов'язаних з багами, які були знайдені командою тестування або кінцевими користувачами.
Це дозволить доповнити набір цікавими кейсами, про які не подумали раніше при проектуванні тест-кейсів.
Поповнюючи свій набір тест-кейсів, тестувальник може знаходити нові цікаві та важливі баги, подивитися на ПЗ з різних сторін і бути впевненим, що продукт буде випущений дійсно якісним. Як наслідок, тестувальник не зможе нудьгувати на проєкті, оскільки йому не доведеться проганяти всі одні і ті ж тести, які приноситимуть усе менше і менше користі.
