Чи вбиває план креативність тестувальника? Peak, trough і recovery у щоденній QA-рутині

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Під час однієї з підготовчих лекцій до екзамену ISTQB Test Analyst я нарешті задала питання, яке мене бентежило деякий час (та, напевно, не тільки мене): чи вбивають аналітичні техніки креативне мислення?

З коментарів у чаті відповідь ніби очевидна — ні. Але чи всі з цим погоджуються? І головне — чи відчувається це так на практиці?

Мене часто питають, як я можу жити за графіком. Коли календар розписаний, коли все заплановано, хіба не зникає спонтанність? Хіба не зникає творчість? У моєму випадку — ні, бо я, здається, планую навіть творчість. ))) Жартую. Або не жартую.

Давайте по порядку.

Деніел Пінк у книжці «When: The Scientific Secrets of Perfect Timing» говорить про три стани: пік (peak), спад (trough) і відновлення (recovery). Деніел Канеман у «Мисленні, швидкому і повільному» згадує про потік (flow) і посилається на Міхая Чіксентміхаї. В якийсь момент мене осяяло: справа не в плані, а в стані, в якому ти працюєш.

Напевно, у кожного тестувальника це було:

— відкриваєш ноут
— береш тікет
— тестуєш
— пишеш уточнення
— по ходу занотовуєш кроки, які потім можна оформити в тест-кейси

Все, задача зроблена. Дивишся на годинник, а три години хтось просто... з’їв. Як так? Оце для мене і є flow. І тут я почала накладати прочитане на тестування.

Можливо, коли ти в стані recovery, ти можеш:

— генерувати ідеї
— думати про підходи
— планувати тестування

Коли ти в trough:

— просто йдеш по тест-кейсах
— робиш рутину
— не витрачаєш зайву енергію

А от коли ти на peak:

— займаєшся exploratory testing
— робиш ad-hoc
— пробуєш нестандартні сценарії
— перевіряєш «а що, якщо...»

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

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

І ось друга — явно про peak, а отже, техніки тест-дизайну починають виглядати інакше. Не як щось, що «стискає мозок», а як щось, що:

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

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

Я для себе це пояснюю дуже просто. Мозок — це такий самий м’яз, як і решта у людському тілі. Хто тренується, то й знає: без балансу між навантаженням і відпочинком діла не буде.

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

І от тоді виходить цікава штука.

Ти:

— не втрачаєш креативність
— не жертвуєш задачами
— і ще й тренуєш дивергентне мислення

Тому питання «чи вбивають техніки креативність?» для мене зараз звучить інакше: чи правильно я використовую техніки відповідно до свого стану?

І, мабуть, не випадково ту лекцію ми закінчили фразою Рекса Блека: «Software testing is in many ways similar to playing the piano, cooking a meal, or driving a car... until you have practiced, you know very little about how to do it.» Перегукується зі статтею, яку я нещодавно опублікувала.

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

Спостерігайте за собою, пробуйте, помиляйтесь, коригуйте, щоб зрозуміти, що працює саме для вас.

А як у вас: exploratory testing — на свіжу голову чи коли як? Чи помічали ви за собою, що різні тестові активності «просять» різного стану? Діліться в коментарях — коли ми обмінюємось досвідом, збагачуємо і себе, і інших.

P.S. Стаття вперше була опублікована на LinkedIn. Можна також почитати на Medium.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі