Меню

Як залучають тестери до методів TDD, BDD та ATDD

how testers are involved tdd

Спробуйте Наш Інструмент Для Усунення Проблем

Огляд методів TDD, BDD та ATDD:

TDD, BDD і ATDD - це терміни, які революціонізували світ тестувальника в Agile і теж набрали обертів. Зміна мислення тестувальників також вимагає засвоєння нових навичок і, що ще важливіше, зміни ставлення та способу роботи.

На відміну від роботи ізольовано, тестувальникам потрібно співпрацювати та працювати разом із програмістами, а значить

  • Обмін тестовими кейсами
  • Участь у написанні критеріїв прийняття оповідань
  • Надання постійного зворотного зв'язку зацікавленим сторонам
  • Співпраця для своєчасного усунення дефектів.
  • Надайте пропозиції та пропозиції щодо покращення якості результатів
  • Автоматизація

Тестери, задіяні в Agile

Перш ніж перейти до обговорення участі тестувальника у цих практиках, спершу спробуємо зрозуміти поняття, що лежать в основі цих термінів:

Що ви дізнаєтесь:

Тестова розробка

Розглянемо традиційний підхід до розробки програмного забезпечення, коли код пишеться спочатку, а потім перевіряється. Тестова розробка або TDD - це підхід, який є точним ЗВЕРНЕННЯМ традиційного розвитку. При такому підході спочатку проводиться тестування, а потім пишеться код.

Розгублений? !!

Як ми можемо протестувати програмне забезпечення, яке ще не розроблено?

Так!! Це тестова розробка або TDD.

TDD працює з невеликими кроками, де:

  • Тест пишеться спочатку
  • Виконано тест - який не вдасться (зі зрозумілих причин)
  • Код пишеться (або реконструюється) лише для того, щоб пройти тест
  • Тест виконується знову
  • Якщо тест пройде, перейдіть до наступного тесту ІНШЕ, перепишіть / змініть код, щоб тест пройшов

Дозвольте мені спробувати пояснити це за допомогою блок-схеми:

Блок-схема TDD

Тепер ми повинні зрозуміти той факт, що TDD не говорить про тестування, яке проводять тестери. Швидше такий підхід фактично говорить про тестування, яке проводять програмісти.

Так!! Ви правильно вгадали !! Це модульне тестування.

Тест, який написаний першим, не є тестом, який пишуть тестувальники, але це модульний тест, який пишуть програмісти. Отже, я б переформулював кроки як:

  • Спочатку пишеться тест UNIT
  • Виконується тест UNIT - який не вдасться (зі зрозумілих причин)
  • Код пишеться (або реконструюється) лише для того, щоб пройти тест
  • Тест UNIT виконується знову
  • Якщо тест пройшов, перейдіть до наступного тесту ELSE, перепишіть / змініть код, щоб тест пройшов

Тепер виникає запитання - якщо TDD - це робота програміста, яка роль тестувальника в цьому підході?

Що ж, сказавши, що TDD - це робота програміста, це не означає, що тестувальники до цього не залучені. Тестери можуть співпрацювати, обмінюючись сценаріями тесту, що складаються з:

Я маю на увазі сказати, що тестувальники повинні брати участь у визначенні сценаріїв модульних тестів і співпрацювати з програмістами, щоб реалізувати те саме. Тестери повинні надати свої відгуки про результати тестування.

Якщо ми хочемо впровадити TDD, тестувальникам потрібно оновити свої набори навичок. Вони повинні бути більш технічними та зосередженими на вдосконаленні своїх аналітичних та логічних навичок.

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

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

Розроблений поведінкою розвиток

Behaviour Driven Development (BDD) - розширення тестової керованої розробки.

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

Деякі ключові особливості BDD:

  • Мова, що використовується для визначення поведінки, дуже проста і в єдиному форматі, в якому її може зрозуміти кожен - як технічні, так і нетехнічні люди, що беруть участь у реалізації
  • Дає платформу, яка дозволяє трьом аміго (програмісту, тестувальнику та PO / BA) співпрацювати та розуміти вимоги. Визначає загальний шаблон для його документування
  • Цей метод / підхід обговорює остаточну поведінку системи або те, як повинна поводитися система, і НЕ говорить про те, як система повинна бути спроектована або впроваджена
  • Наголошує на обох аспектах якості:
    • Виконайте вимогу
    • Придатний для використання

Чому BDD?

Ну, ми знаємо, що виправлення дефекту / помилка на пізньому етапі будь-якого циклу розвитку є досить дорогим. Виправлення виробничих дефектів впливає не тільки на код, але і на конструкцію та її вимоги. Коли ми робимо RCA (аналіз основних причин) будь-якого дефекту, більшу частину часу ми робимо висновок, що дефект насправді зводиться до неправильно зрозумілих вимог.

В основному це відбувається тому, що кожен має різні здібності розуміти вимоги. Отже, технічні та нетехнічні працівники можуть тлумачити одну і ту ж вимогу по-різному, що може призвести до неправильної доставки. Тому надзвичайно важливо, щоб усі в команді розробників розуміли ЖИВУ вимогу та тлумачили її ТАКОЖ.

Потрібно переконатись, що всі зусилля з розвитку спрямовані та зосереджені на задоволенні вимог. Щоб уникнути будь-якого дефекту 'вимога - пропустити', вся команда розробників повинна їх вирівняти, щоб зрозуміти вимогу, яка придатна для використання.

Підхід BDD дозволяє команді розробників робити це шляхом: -

  • Визначення стандартного підходу до визначення вимоги простою англійською мовою
  • Надання прикладів, що пояснюють вимоги
  • Надайте інтерфейс / платформу, яка дозволяє технічним (програмісти / тестувальники) та нетехнічним (PO / BA / Замовник) співпрацювати та об’єднуватися та знаходитись на одній сторінці для розуміння та реалізації вимог.

Як впровадити BDD?

На ринку доступно багато інструментів для впровадження BDD. Я називаю тут декілька:

  • Огірок
  • Фітнес
  • Злагода
  • JBehave
  • Потік специфікації

Приклад:

Спробуємо зрозуміти BDD на прикладі. Для мого випадку я використовую огірок (огірок):

Розглянемо простий випадок, коли ми хочемо дозволити лише автентифікованим користувачам заходити на сайт XYZ.

Файл огірків (файл особливостей) буде таким:

Характеристика: Портал реєстрації тестів

Контур сценарію: Увійшов дійсний користувач

Дано: Клієнт відкриває портал реєстрації

Коли: користувач вводить ім'я користувача як '', а пароль як ''

Потім: клієнт повинен мати можливість переглянути форму.

Приклади :

| користувач | пароль |

| користувач1 | pwd1 |

| користувач2 | pwd2 |

Ми бачимо, як конкретна вимога документується за допомогою простої англійської мови. Три аміго можуть спільно розробляти файли функцій, а конкретні дані тесту можна задокументувати у прикладі. BDD забезпечує засіб для об’єднання програмістів, тестувальників та бізнесу за єдиним столом та створення загального розуміння функцій, які слід впровадити.

Підхід BDD економить зусилля та витрати та перевіряє наявність дефектів після розгортання виробництва, оскільки співпраця клієнтів та розробників тривала протягом циклу розробки функції.

Команди розробників можуть використовувати ці файли функцій і конвертувати їх у виконувані програми для тестування певної функції.

Як?

Ну, для цього вам потрібно вивчити огірок / фітнес !!

Розробка керованого тестування

Розробка, що керується випробувальним тестом або ATDD - це техніка, коли вся команда співпрацює, щоб визначити критерії прийняття епопеї / історії до того, як реалізація насправді розпочнеться. Ці приймальні випробування підтверджені належними прикладами та іншою необхідною інформацією.

Здебільшого BDD і ATDD використовуються як взаємозамінні. Підхід ATDD також може бути реалізований із використанням формату Дано-Коли-Тоді, подібно до того, як ми пишемо функції в підході BDD.

Давайте швидко спробуємо узагальнити відмінності між 3 підходами:

  • TDD є більш технічним і написаний тією ж мовою, на якій реалізована функція. Якщо функція реалізована на Java, ми пишемо JUnit тестові кейси . Тоді як BDD та ATDD написані простою англійською мовою
  • Підхід TDD фокусується на реалізації функції. Тоді як BDD фокусується на поведінці функції, а ATDD фокусується на ухваленні вимог
  • Для впровадження TDD нам потрібно мати технічні знання. Тоді як BDD та ATDD не вимагають ніяких технічних знань. Краса BDD / ATDD полягає в тому, що як технічні, так і нетехнічні люди можуть брати участь у розробці функції
  • Оскільки TDD еволюціонував, це дає можливість для гарного дизайну і зосереджує увагу на аспекті якості 'Вимоги до задоволення'; тоді як BDD / ATDD зосереджені на 2йаспект якості, який є 'Придатним для використання'

Усі ці методи в основному говорять про підхід «тест-перший», на відміну від підходу «тест-останній», що використовується в традиційних методологіях розробки.

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

З такими концепціями, як CI (Безперервна інтеграція) та CD (Безперервна доставка), тестери повинні добре співпрацювати з програмістами та в рівній мірі сприяти розробці та роботі.

Як повернути масив назад

Дозвольте підсумувати це обговорення з відомою Тестовою пірамідою в Agile:

Перевірте піраміду в Agile

Найнижчий шар цієї піраміди складається з одиничного тестового шару. Цей шар є фундаментним шаром; тому імператорським є те, що цей шар твердий. Більшість тестів слід вкласти в цей шар. Цей найнижчий рівень фокусується лише на TDD.

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

Інструменти, що використовуються в цьому шарі піраміди, - це всі інструменти Xunit.

Середній шар піраміди - це сервісний рівень, що пояснює тести рівня обслуговування. Цей рівень діє як міст між користувальницьким інтерфейсом програми та блоком / компонентом нижчого рівня. Цей рівень здебільшого складається з API, які приймають запити від інтерфейсу користувача і надсилають відповідь. У цьому шарі піраміди активний підхід BDD і TTDD.

Інструментами, що використовуються в середньому шарі піраміди, є - Fitnesse, Cucumber і Robot Framework .

Самий верхній шар піраміди - це власне користувальницький інтерфейс, який показує, що цей шар повинен містити найменшу кількість тестів, або я повинен сказати, що зусилля тестування на цьому конкретному шарі повинні бути мінімальними. Більшість випробувань ознаки мали бути завершені, коли ми дійдемо до верхнього шару піраміди.

Інструментами, що використовуються у верхньому шарі, є - Селен , QTP та RFT.

Оскільки ми працюємо з невеликими кроками в Scrum (так звані Спринти), ручна реалізація всіх цих підходів неможлива. Ці підходи вимагають автоматизованого втручання. У цьому випадку автоматизація є дуже важливою.

Насправді ці підходи фактично виконуються за допомогою автоматизації. В кінці кожного спринту додаються нові функції, тому стає важливим, щоб раніше впроваджена функція працювала, як очікувалося; отже, Автоматизація стає тут ГЕРОЄМ.

Висновок

Наприкінці статті ви, мабуть, дізналися про те, як тестери залучаються до методів TDD, BDD та ATDD.

У третій частині серії я зосереджу свою дискусію на питаннях автоматизації у спритному світі.

Про автора: Ця стаття написана автором STH Шилпою. Вона працює в галузі тестування програмного забезпечення протягом останніх 10 років у таких сферах, як Інтернет-реклама, Інвестиційний банкінг та Телеком.

Продовжуйте переглядати цей простір, щоб отримати набагато більше оновлень.

Рекомендована література

^