Ідея цієї статті виникла в мене, коли я почав працювати в новому стартапі chous.ai. Оскільки в нас об'єднано відділи ручного й автоматизованого тестування, гостро постало питання уніфікації тестової документації. Оскільки в автоматизації ми використовуємо BDD, з'явилася ідея перенести цей досвід і на ручне тестування, замінивши тест-кейси сценаріями. Не знайшовши серйозної документації з цієї теми російською мовою, я написав цю статтю, де детально описано впровадження підходів TDD і BDD до QA-процесу.
Тестування на ранній стадії, наприклад під час написання коду, — це колись інноваційна ідея, яка дедалі більше приживається в масах, адже призводить до значного підвищення якості коду. Напишіть тести заздалегідь — і ви матимете шанс виграти «кришталеву зірку» переможця галактичної першості. Крім того, можливість перевіряти роботу коду та проводити його попереднє налагодження, безсумнівно, підвищує швидкість розробки.
Але навіть знаючи все це, ми ще дуже далекі від часу, коли написання тестів перед написанням коду стане загальним стандартом. Так само як TDD стало наступним етапом еволюції екстремального програмування (eXP) і висунуло на перший план інфраструктуру для unit-тестування, наступний еволюційний стрибок було зроблено з того рівня, на якому перебуває TDD. У цьому випадку від TDD еволюціонували до його інтуїтивного родича: behavior-driven development (BDD) — розробки, заснованої на поведінці. Але розберімо все по порядку.
Розробка через тестування - TDD
Розробка через тестування (англ. test-driven development, TDD) — це сучасний стандарт розробки програмного забезпечення, який ґрунтується на повторенні дуже коротких циклів розробки: спочатку пишеться тест, що покриває бажану зміну, потім пишеться код, який дозволить цьому тесту пройти, і наприкінці проводиться рефакторинг нового коду відповідно до стандартів. Кент Бек, якого вважають винахідником цієї техніки, стверджував у 2003 році, що розробка через тестування дає змогу бути впевненим у продуктивності свого коду, що зрештою зменшує загальний час розробки. У 1999 році, коли з'явилася, розробка через тестування була тісно пов'язана з концепцією «спочатку тест» (англ. test-first), яку застосовують в екстремальному програмуванні, однак пізніше виокремилася як незалежна методологія. В її основі лежить unit-тест — програмна процедура, яка дозволяє або підтвердити, або спростувати працездатність коду. Техніку TDD легко уявити за такою схемою:
Тепер я докладніше поясню, як це працює:
1. На основі специфікації, макетів та іншої вихідної документації пишеться тест. Для програми, яку ще навіть не написано. Якщо запустити такий тест, він, звісно, впаде.
2. Програміст пише код, створює програму, а тест править за індикатор. Щойно тест пройдено — код готовий.
3. Рефакторинг. Тест доопрацьовується або переробляється внаслідок зміни вимог, за потреби додаються нові параметри. Рідко коли фічу приймають з першого разу.
Цей цикл може повторюватися n разів, доки програма не досягне бажаного стану.
Розробка, заснована на поведінці
Після того як ми дізналися, що сучасні методики розробки поєднуються з тестуванням, утворюючи TDD, TDD далі еволюціонувало в BDD (behavior-driven development), або розробку через поведінку. Найімовірніше, ці абревіатури вже вас заплутали, і все злилося в суцільне BDSM.
Але звернімося до думки експертів.
Метт Вінн, один із розробників інтерпретатора BDD для фреймворку Cucumber Limited, так передає суть технології:
«Практики BDD досліджують, виявляють, визначають, а потім втілюють цю поведінку програмного забезпечення, використовуючи спілкування, конкретні приклади й автоматизовані тести».
Після великої кількості спроб і помилок команди дійшли розуміння, що потрібен підхід, який об'єднає тестувальників, програмістів, продактів, бізнес-аналітиків, замовників і дасть їм документацію, яку використовує й розуміє кожен. Подивімося, як цей BDD інтегрується в схему TDD.
У підході BDD немає нічого революційного. Це просто еволюційне відгалуження підходу TDD, де слово «тест» замінено словом «повинен». Якщо відкласти слова вбік, багато хто знайде поняття «повинен» природнішим для процесу розробки, ніж поняття «тест». Мислення в термінах функціональності (того, що код повинен робити) приводить до підходу, коли спочатку пишуться класи для перевірки специфікації, які, своєю чергою, можуть виявитися дуже ефективним інструментом реалізації.
Як ви вже самі з'ясували, підхід BDD полягає в тому, щоб спробувати з'ясувати, чого ваш клієнт або бізнес хоче від програмного забезпечення, перш ніж почати над ним працювати. Перший спосіб зробити це — фактично співпрацювати з цими людьми.
Щойно ми налагодимо цю співпрацю, потрібно якось записати те, що матиме сенс для будь-кого, хто це переглядає, щоб будь-хто міг прийти й подивитися на це пізніше, зрозуміти, а за бажання — прокоментувати. Щоб цього досягти, потрібно використовувати загальнозрозумілу мову.
Люди часто використовують слова «Given», «When», «Then», «And» (укр. «Дано», «Коли», «Тоді», «І»), щоб побудувати ланцюжок логічних міркувань. Тож застосуймо ці слова як ключові для побудови наших тестів, зрозумілих усім.
Отже, наш тестовий документ називатиметься сценарієм і використовуватиме лише ключові фрази для кожного кроку. Спочатку ми наведемо переклад, але далі використовуватимемо тільки англійські фрази. Наш сценарій будуватиметься за такою структурою:
GIVEN <context> Дано <контекст або вихідний стан>
WHEN <event> Коли <подія>
THEN <outcome> Тоді <результат>
Як це працює:
Дано <я приводжу систему, що тестується, у вихідний стан для тесту>
Коли <я виконую дію>
Тоді <я перевіряю результат>
А тепер приклад:
GIVEN Я залогінений у систему як користувач
WHEN Я відкриваю список вхідних повідомлень
THEN Я бачу 20 останніх повідомлень.
Дякую за увагу, повнішу версію теми ви можете знайти на рівні 16 системи навчання Galaxy QA Academy. Можливе окреме придбання доступу до теми. Для цього зв'яжіться з нами.
#TDD #BDD #QA2017 #AQA #qaautomation #ТестуванняПЗ #QAAcademy #Тестуванняірозробка #Сучаснетестування #Сучаснатестоваядокументація