Кмітливий тестувальник (#3)

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

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

До діла. Можливо, ти чув(-ла), що тестування — це пошук багів. Йдучи аналогією вище, пошук багів — це щось на кшталт отих хлібних кульок. Тож трохи почекаємо з багами. Бо зараз буде страшне. Тестування — це не пошук багів! Чому так? Тому, що хлібні кульки. Але я про все розкажу згодом, для того і з’явився «Кмітливий тестувальник». І шлях до розуміння, що таке тестування, ми починаємо вже з наступного абзацу.

Де ми ті баги шукаємо? Правильно — в софті. Як з’являється софт? Його пишуть, спираючись на вимоги. Хтось ті вимоги дає команді розробників, щоб вони розуміли, що робити. Якщо узагальнити, то баги — це невідповідність написаної програми цим вимогам. Саме про вимоги маємо поговорити спочатку, зрозуміти предмет нашого тестування, а не лізти міряти лінійкою, скажімо, вагу цистерни.

Як це буде в реальному житті? Коли ти, зелений, наче $, фахівець, почнеш працювати над своїм першим проєктом, тобі дадуть якесь завдання. Ось воно:

То це і є потрібні тобі вимоги? Частково так. Однак, нам важливо зрозуміти загальну картину. Ось таке найменше завдання видається в команду (частиною якої ти є). Воно достатньо маленьке, щоб бути зрозумілою та швидко виконаною. Наприклад: додати в редактор тексту можливість зберігати його в форматі, скажімо, pdf. Тобто, раніше такої можливості не було, тільки doc-формат був доступний для зберігання. А тепер і pdf має бути.

Важливо зрозуміти, що найменші завдання переважно є частинами чогось більшого, якихось інших частин, що ми називаємо «фіча» (від англ. feature — ознака, риса, особливість). Такою фічею в нашому редакторі буде функція зберігання документа, як таке. Адже є потреба у зберіганні документів (у різних форматах). Таким чином, разом із твоєю задачею можуть бути інші, як то можливість зберігати ще в txt та odt. Отже, тепер наше завдання має своє місце в структурі, ось вона:

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

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

Можна подумати, що вище ніж до продукту підійматися нема куди. Це не зовсім так. Бо продукти не живуть ізольовано. Вони існують поруч з іншими продуктами. Інколи буває, що інші продукти — також наші, одного розробника. Вони можуть навіть бути частиною однієї екосистеми, тобто працювати разом і впливати один на одного. Наприклад, Google. Це велика екосистема. І редактор текстів є — Google Docs. Є продукти-сусіди, як-от Google Sheets. І перші й другі знаходяться на Google Drive. Вимоги до кожного з продуктів мають бути узгоджені між собою. Наприклад, — один стиль і принцип роботи інтерфейсу — як виглядає меню, як працюють схожі функції (як-от збереження файлів) і таке інше. Знову намалюю схему, ось вона:

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

Для повної картини того, де «живуть» наші продукти, наші програми, наш софт, не вистачає ще одного рівня. Цей рівень конкурентний — місце, де «живуть» різні продукти від різних виробників. Скажімо, редактор відео DaVinci «пасеться» на одній галявині з Adobe Premier. Uber грає на тому ж полі, що й Bolt. Такі галявини можна назвати бізнес-доменами. Отож, ми дійшли до фінальної структури, ось вона:

На відміну від інших рівнів, вимоги до бізнес-домену ніхто не пише. Проте я не просто так намалював цей рівень, бо вимоги там все одно “живуть”, хоча і мають своєрідне походження. А саме — ринкове. Не будемо пірнати глибоко в тему ринку (поки що), тут варто знати, що він існує та істотно впливає на всі інші рівні, що йдуть нижче на схемі. Якщо бізнес Glovo відчуває, що потрібно додати доставляння медикаментів, або Uber хоче спробувати додати клас електроавтомобілів, то всі вони спираються на свій аналіз ринку. А ще — на конкурентів. Одним словом, саме тут, в ринковому світі бізнес-доменів, народжуються вимоги, які конкретизуються все дедалі більше у своєму русі схемою нижче. Пам’ятаєш перше завдання? Додати можливість зберігання у форматі pdf, це частина вимог до фічі. Яка є частиною вимог до продукту. Який (опціонально) є частиною вимог до екосистеми. І все це керується вимогами ринку, конкретного бізнес-домену.

Отже, можемо виділити п’ять рівнів вимог (або чотири, за умови відсутності екосистеми), які маємо розуміти, ось вони:

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

Однак важливо одразу зрозуміти, що рівень junior, як і робота на рівні вимог конкретних завдань, є тільки першим кроком до професії. Нікому не потрібні вічні джуни, які роками можуть осягнути лише рівень завдання та виконувати найелементарнішу роботу. Саме тому я одразу показав повну картину й одразу кажу — із твоїм розвитком як тестувальника ти будеш (маєш) рухатися вище по цією схемою у своїй роботі. Дивишся на завдання, а бачиш, як воно вбудовується в фічу, як на нього впливають сусідні завдання і таке інше.

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

• чи виконуються вимоги завдання?
• чи не суперечить завдання іншим сусіднім завданням і навпаки?
• чи ще виконуються вимоги для фічі, частиною якою є завдання?
• чи підтримуються вимоги до продукту (та екосистеми)?
• чи наш софт досі актуальний для бізнес-домену?

Цікаво? Тож коли кажуть, що тестування — то монотонна й проста робота, то мають на увазі лише найменші шматочки, найпростіші завдання, хлібні кульки. Ще раз — це тільки наш перший крок. Там, де простіше — менше грошей, менше розваг. Але ж ти хочеш більшого, я правильно розумію?

Тепер, коли ти знаєш загальну структуру вимог і те, що баги тісно пов’язані з вимогами, ми зможемо професійніше подивитись і на баги й на процес тестування. Тобто, ти готовий до наступного випуску «Кмітливого тестувальника», який не забариться.

Інформація «із зірочкою» для допитливих:

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

Автор: Олекса Мащиць

Редактор: Мар’яна Гірська