Універсальність vs практичність

Привіт друзі! Нещодавно мене спитали, якими спеціалізованими тулами для тест дизайну я користуюсь. І я трохи підвис, згадуючи, а чим же я користуюсь?
І дійшов висновку, що окрім досить рідких кейсів з pairwise, моїм основним інструментом для тест дизайну є Excel/Google Sheets (не тест менеджментом єдиним 😆). Та ще іноді тули для mindmap, такі як Coggle, але то інша історія.

Я навіть не задумувався раніше – просто робив на автоматі:
перелічити границі для класів еквівалентності – Є ✅
зробити матрицю для state transition – просто ✅
таблиця рішень? – відповідь в самій назві техніки ✅

А ще постійно користуюсь формулами. Що підводить мене до теми допису – минулого року дизайнив тести для однієї складної фічі: багато об’єктів з десятками значень, з наслідуванням, сумуванням/відніманням певних значень об’єктів залежно від ієрархії, множенням на коефіцієнти і обчислення певних дат (ПЗ для банку, але не можу розповісти детальніше).
І першою моєю ідеєю було розробити універсальний тул, який би розраховував тести для всіх можливих варіантів вхідних даних. Десь за пів дня я його зробив, у вигляді html сторінки з логікою на js, і дуже собою пишався – рекурсивні проходи по деревам об’єктів, їх розгортання в списки і безліч обрахунків. Та ще й зі зручним інтерфейсом.

А потім, як то часто буває, замовник змінив вимоги. А потім ще раз. І ще…

З якоїсь ітерації підтримка коду стала забирати непристойно багато часу. Я плюнув, виділив 3-4 найбільш вживані набори даних, помістив їх в Excel та зробив всі обрахунки формулами. Без рекурсій і інших складностей – частина об’єктів статична і дерева будувати не треба. Кілька годин і тести готові. І підтримувати легко. І навіть інструкцій писати не треба – в таблицях все досить наглядно.

Як вам історія? А як ви дизайните тести для складної логіки?

Tags:
16 September 2020
Автор: 
Oleksii Ostapov

Leave a comment

Leave a Reply