Мени

Како су тестери укључени у ТДД, БДД и АТДД технике

how testers are involved tdd

Испробајте Наш Инструмент За Елиминисање Проблема

Преглед ТДД, БДД и АТДД техника:

ТДД, БДД и АТДД су појмови који су револуционисали свет тестера у Агилеу, а такође су добили замах. Промена начина размишљања тестера такође захтева учење нових вештина и што је још важније, промену става и начина рада.

За разлику од изолованог рада, тестери морају да сарађују и раде заједно са програмерима, што значи

  • Дељење тест случајева
  • Учествовање у писању критеријума прихватања прича
  • Пружање континуираних повратних информација заинтересованим странама
  • Сарадња ради решавања недостатака на време.
  • Дајте предлоге и доприносе за побољшање квалитета резултата
  • Аутоматизација

Тестери укључени у агилност

Пре него што уђем у расправу о укључености тестера у ове праксе, покушајмо прво да разумемо концепте који стоје иза ових термина:

Шта ћете научити:

Тест Дривен Девелопмент

Размотрите традиционални приступ развоју софтвера где се код прво напише, а затим тестира. Развој вођен тестом или ТДД је приступ који је тачан ОБРТАК традиционалног развоја. У овом приступу прво се врши тестирање, а затим се записује код.

Збуњен? !!

Како можемо тестирати део софтвера који тек треба да се развије?

Да!! То је тест-дривен развој или ТДД.

ТДД ради у малим корацима где:

  • Прво је написан тест
  • Тест се извршава - који неће успети (из очигледних разлога)
  • Код је написан (или преправљен) само да би тест прошао
  • Тест се поново извршава
  • Ако тест прође, пређите на следећи тест ЕЛСЕ, поново напишите / измените код да би тест прошао

Покушаћу да објасним кроз дијаграм тока:

ТДД дијаграм тока

Сада морамо схватити чињеницу да ТДД не говори о тестирању које раде тестери. Уместо да овај приступ заправо говори о тестирању које програмери раде.

Да!! Добро сте погодили !! То је јединствено тестирање.

Тест који је написан први није тест који пишу тестери, већ је јединични тест који програмери пишу. Дакле, преформулисао бих кораке као:

  • Прво се пише УНИТ тест
  • Извршен је УНИТ тест - који неће успети (из очигледних разлога)
  • Код је написан (или преправљен) само да би тест прошао
  • УНИТ тест се поново изводи
  • Ако тест прође, пређите на следећи тест ЕЛСЕ, поново напишите / измените код да би тест прошао

Сада се поставља питање које се поставља овде - ако је ТДД посао програмера, која је улога тестера у овом приступу?

Па, кад смо рекли да је ТДД посао програмера, то не значи да тестери нису укључени у то. Тестери могу да сарађују делећи сценарије тестирања који се састоје од:

Оно што мислим да кажем је - тестери би требало да учествују у дефинисању сценарија јединичног тестирања и сарађују са програмерима да би применили исти. Испитивачи би требало да дају своје повратне информације о резултатима испитивања.

Ако желимо да применимо ТДД, тестери морају да надограде своје вештине. Морају бити технички више усредсређени на побољшање својих аналитичких и логичких вештина.

Испитивачи такође треба да се потруде да разумеју технички жаргон који програмери користе, и ако је могуће, морају имати птичји поглед на код. На сличан начин, програмери морају стати на место тестера и покушати да смисле софистицираније сценарије који ће јединствено тестирање учинити робуснијим и солиднијим.

И програмери и тестери морају да кроче једни другима, за разлику од старог традиционалног приступа где програмери нису придавали велику тежину јединственим тестовима јер су се ослањали на тестере за проналажење грешака и недостатака, а тестери нису желели да се препусте себи у учење техничких ствари јер мисле да им се посао завршава након проналаска недостатака.

Развој вођен понашањем

Развој вођен понашањем или БДД је продужење за Тест Дривен Девелопмент.

БДД, као што и само име говори, илуструје методе развоја особине засноване на њеном понашању. Понашање се у основи објашњава примерима на врло једноставном језику који могу да разумеју сви у тиму који су одговорни за развој.

Неке од кључних карактеристика БДД-а су следеће:

  • Језик који се користи за дефинисање понашања врло је једноставан и у једном формату у којем га могу разумети сви - и технички и нетехнички људи који су укључени у примену
  • Даје платформу која омогућава тројици пријатеља (програмера, тестера и ПО / БА) да сарађују и разумеју захтеве. Одређује заједнички образац за документовање
  • Ова техника / приступ разматра коначно понашање система или како систем треба да се понаша, а НЕ говори о томе како систем треба дизајнирати или применити
  • Наглашава оба аспекта квалитета:
    • Испуните захтев
    • Погодан за употребу

Зашто БДД?

Па, знамо да је отклањање квара / буг у каснијој фази било ког развојног циклуса прилично је скупо. Отклањање производних недостатака не утиче само на код, већ и на дизајн и његове захтеве. Када радимо РЦА (анализа основног узрока) било којег недостатка, најчешће закључујемо да се недостатак заправо своди на погрешно схваћене захтеве.

То се у основи дешава зато што сви имају различите склоности да разумеју захтеве. Стога технички и нетехнички људи могу различито тумачити исти захтев, што може довести до неисправне испоруке. Стога је пресудно да сви у развојном тиму разумеју ИСТИ захтев и да га протумаче на ИСТИ начин.

Морамо бити сигурни да су целокупни развојни напори усмерени и усмерени ка испуњавању захтева. Да би се избегла било каква врста недостатка „захтев - пропусти“, цео развојни тим мора да их усклади како би разумео захтев који је погодан за употребу.

БДД приступ омогућава развојном тиму да: -

  • Дефинисање стандардног приступа за дефинисање захтева на једноставном енглеском језику
  • Пружање дефинисања примера који објашњавају захтеве
  • Обезбедити интерфејс / платформу која техничким (програмери / тестери) и нетехничким (ПО / БА / купац) омогућава да сарађују и окупљају се и буду на истој страници да разумеју и примене захтеве

Како применити БДД?

На тржишту постоји много алата за примену БДД-а. Овде именујем неколико:

  • Краставац
  • Фитнесс
  • Цонцордион
  • ЈБехаве
  • Спец Флов

Пример:

Покушајмо да разумемо БДД на примеру. За мој случај користим корнишон (краставац):

Размотримо једноставан случај у којем желимо да дозволимо само ауторизованим корисницима да уђу на КСИЗ локацију.

Датотека Гхеркин (датотека са карактеристикама) била би следећа:

Одлика: Портал за регистрацију теста

Преглед сценарија: Важећи корисник пријављен

Дато: Купац отвара портал за регистрацију

Када: корисник уноси корисничко име као “”, а лозинку као “”

Онда: купац треба да може да види образац.

Примери :

| корисник | лозинка |

| усер1 | пвд1 |

| усер2 | пвд2 |

Можемо видети како се одређени захтев документује једноставним енглеским језиком. Три амиго-а могу заједно радити на дизајнирању датотека карактеристика, а специфични подаци о тестирању могу се документовати у одељку примера. БДД пружа медиј за спајање програмера, тестера и предузећа за један сто и успостављање заједничког разумевања карактеристика које треба применити.

БДД приступ штеди напор и трошкове и проверава да ли има било каквих недостатака након примене производње, јер је сарадња купаца и програмера била током развојног циклуса функције.

Развојни тимови могу користити ове датотеке карактеристика и претворити их у извршне програме за тестирање одређене функције.

Како?

Па, за то треба научити краставац / фитнес !!

Развој вођен тестом прихватања

Развој вођен тестом прихватљивости или АТДД је техника у којој читав тим сарађује како би дефинисао критеријуме прихватања епске приче / приче пре него што примена заиста започне. Ови тестови прихватања поткрепљени су одговарајућим примерима и другим потребним информацијама.

Најчешће се БДД и АТДД користе наизменично. АТДД приступ се такође може применити користећи формат дато-када-тада, баш као и како пишемо функције у БДД приступу.

Покушајмо брзо да резимирамо разлике између 3 приступа:

  • ТДД је више технички и написан је на истом језику на којем је функција имплементирана. Ако је функција имплементирана у Јави, пишемо ЈУнит тест случајева . Док су БДД и АТДД написани на једноставном енглеском језику
  • ТДД приступ фокусира се на примену неке функције. Док се БДД фокусира на понашање обележја, а АТДД фокусира на хватање захтева
  • Да бисмо применили ТДД, морамо имати техничко знање. Док БДД и АТДД не захтевају никаква техничка знања. Љепота БДД / АТДД лежи у чињеници да и технички и нетехнички људи могу учествовати у развоју функције
  • Будући да је ТДД развијен, он даје простор за добар дизајн и фокусира се на аспект квалитета „Испуњавање захтева“; док се БДД / АТДД фокусирају на 2ндаспект квалитета који је „Погодан за употребу“

Све ове технике у основи говоре о приступу „тест-фирст“, за разлику од „тест-ласт“ приступа који се користи у традиционалним методологијама развоја.

Како су тестови прво написани, тестери играју веома важну улогу. Не само да тестери морају да имају широк домен и пословно знање, већ морају да поседују добре техничке вештине како би могли да додају вредност у мозгању током три амигос дискусије.

Са концептима попут ЦИ (континуирана интеграција) и ЦД (континуирана испорука), тестери морају добро сарађивати са програмерима и подједнако допринети развоју и оперативном подручју.

Питања и одговори за интернетске услуге

Дозволите ми да резимирам ову дискусију са чувеном испитном пирамидом у агилном:

Тестирајте пирамиду у окретном

Најнижи слој ове пирамиде састоји се од слоја за испитивање јединице. Овај слој је темељни слој; стога је императив да је овај слој чврст. Већину тестова треба гурнути у овај слој. Овај најнижи слој се фокусира само на ТДД.

У Окретан света, нагласак је стављен на то да овај слој пирамиде постане јачи и робуснији и наглашава се да се већина испитивања постиже на овом слоју.

Алати који се користе у овом слоју пирамиде су сви Ксунит алати.

Средњи слој пирамиде је сервисни слој, објашњавајући тестове нивоа услуге. Овај слој делује као мост између корисничког интерфејса апликације и јединице / компоненте нижег нивоа. Овај слој се углавном састоји од АПИ-ја који прихватају захтеве од корисничког интерфејса и враћа одговор. Приступ БДД и ТТДД активан је у овом слоју пирамиде.

Алати који се користе у средњем слоју пирамиде су - Фитнессе, Цуцумбер и Робот Фрамеворк .

Највиши слој пирамиде је стварни кориснички интерфејс, што показује да би овај слој требало да садржи најмањи број тестова, или бих требао рећи да би напор тестирања на овом одређеном слоју требао бити минималан. Већина испитивања својства требало је да буде завршено када дођемо до горњег слоја пирамиде.

Алати који се користе у горњем слоју су - Селен , КТП и РФТ.

Пошто радимо у малим корацима у Сцрум (под називом Спринтс), ручна примена свих ових приступа није изведива. Ови приступи захтевају аутоматизовану интервенцију. У овом случају, аутоматизација је врло битна.

У ствари, ови приступи се заправо изводе аутоматизацијом. На крају сваког спринта додају се нове функције, па постаје важно да претходно примењена функција ради како се очекивало; стога, Аутоматизација овде постаје ХЕРОЈ.

Закључак

На крају чланка морали сте научити о томе како су испитивачи укључени у ТДД, БДД и АТДД технике.

У трећем делу серије фокусираћу своју расправу на аутоматизацију у окретном свету.

О аутору: Овај чланак је написао аутор СТХ Схилпа. Она ради на пољу тестирања софтвера последњих 10 и више година у доменима попут Интернет оглашавања, инвестиционог банкарства и Телекома.

Наставите да гледате овај простор за још много новости.

Препоручено читање

^