Меню

Как тестерите се включват в TDD, BDD и ATDD техники

how testers are involved tdd

Преглед на TDD, BDD и ATDD техниките:

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

За разлика от изолираната работа, тестерите трябва да си сътрудничат и да работят заедно с програмистите, което означава

  • Споделяне на тестовите случаи
  • Участие в написването на критериите за приемане на историите
  • Предоставяне на непрекъсната обратна връзка на заинтересованите страни
  • Сътрудничество за отстраняване на дефектите навреме.
  • Дайте предложения и информация за подобряване на качеството на резултатите
  • Автоматизация

Тестери, участващи в Agile

пример за сортиране на избор c ++

Преди да вляза в дискусията за участието на тестера в тези практики, нека първо се опитаме да разберем концепциите зад тези термини:

Какво ще научите:

Разработване с тест

Помислете за традиционния подход при разработването на софтуер, при който кодът се пише първо и след това се тества. Тестваното развитие или TDD е подход, който е точно ОБРАТНОТО на традиционното развитие. При този подход първо се извършва тестване и след това се записва кодът.

Объркан? !!

Как можем да тестваме софтуер, който тепърва ще бъде разработен?

Да !! Това е разработено чрез тест или TDD.

TDD работи на малки стъпки, когато:

  • Тестът се пише първо
  • Тестът се изпълнява - което ще се провали (по очевидни причини)
  • Кодът е написан (или реконструиран) само за да премине тестовия случай
  • Тестът се изпълнява отново
  • Ако тестът премине, преминете към следващия тест ELSE, пренапишете / променете кода, за да направите теста успешно

Нека се опитам да го обясня чрез блок-схема:

TDD блок-схема

Сега трябва да разберем факта, че TDD не говори за тестването, което тестващите правят. По-скоро този подход всъщност говори за тестването, което програмистите правят.

Да !! Правилно се досетихте !! Това е модулното тестване.

Тестът, който е написан първо, не е тестът, който тестерите пишат, но това е единичен тест, който програмистите пишат. И така, бих префразирал стъпките като:

  • Първо се пише UNIT тест
  • Изпълнява се UNIT тест - който ще се провали (по очевидни причини)
  • Кодът е написан (или реконструиран) само за да премине теста
  • Тестът UNIT се изпълнява отново
  • Ако тестът премине, преминете към следващия тест ELSE, пренапишете / променете кода, за да направите теста успешно

Въпросът, който възниква тук, е - ако TDD е работа на програмист, каква е ролята на тестера в този подход?

Е, след като казахме, че TDD е работа на програмист, това не означава, че тестерите не участват в нея. Тестерите могат да си сътрудничат, като споделят тестовите сценарии, състоящи се от:

Това, което искам да кажа, е - тестерите трябва да участват в дефинирането на сценариите за модулни тестове и да си сътрудничат с програмистите, за да внедрят същото. Тестерите трябва да предоставят обратна връзка за резултатите от теста.

Ако искаме да приложим TDD, тестерите трябва да надградят своите умения. Те трябва да бъдат по-технични и да се фокусират върху подобряването на своите аналитични и логически умения.

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

И програмистите, и тестерите трябва да стъпят един в друг, за разлика от стария традиционен подход, при който програмистите не придаваха много тежест на модулните тестове, тъй като разчитаха на тестерите за откриване на грешки и дефекти, а тестерите не искаха да се отдадат на себе си в изучаването на технически неща, защото смятат, че работата им свършва след намиране на дефектите.

Развитие на поведението

Разработено от поведението или BDD е разширение на Test Driven Development.

BDD, както подсказва името, илюстрира методите за разработване на функция, базирана на нейното поведение. Поведението основно се обяснява чрез примери на много прост език, който може да бъде разбран от всеки в екипа, който отговаря за развитието.

Някои от основните характеристики на BDD са както следва:

  • Езикът, използван за определяне на поведението, е много прост и в един формат, в който може да бъде разбран от всички - както технически, така и нетехнически хора, участващи в изпълнението
  • Дава платформа, която позволява на трите амиго (програмист, тестер и PO / BA) да си сътрудничат и да разберат изискването. Определя общ шаблон за документиране
  • Тази техника / подход обсъжда окончателното поведение на системата или как системата трябва да се държи и НЕ говори за това как системата трябва да бъде проектирана или внедрена
  • Подчертава и двата аспекта на качеството:
    • Изпълнете изискването
    • Годен за употреба

Защо BDD?

Е, ние знаем, че отстраняването на дефект / буболечка на по-късния етап от всеки цикъл на развитие е доста скъпо. Поправянето на производствените дефекти влияе не само върху кода, но и върху дизайна и неговите изисквания. Когато правим RCA (анализ на основната причина) за всеки дефект, през повечето време заключаваме, че дефектът всъщност се свежда до неразбрани изисквания.

По принцип това се случва, защото всеки има различни възможности да разбере изискванията. Следователно технически и нетехнически лица могат да тълкуват едно и също изискване по различен начин, което може да доведе до неправилна доставка. Следователно е от решаващо значение всички в екипа за разработки да разберат СЪЩОТО изискване и да го интерпретират по СЪЩИЯ начин.

Трябва да се уверим, че цялостните усилия за развитие са насочени и насочени към изпълнение на изискванията. За да се избегне всякакъв вид дефект „изискване - пропуск“, целият екип за разработка трябва да ги подреди, за да разбере изискването, годно за употреба.

Подходът BDD позволява на екипа за разработка да направи това чрез: -

  • Определяне на стандартен подход за определяне на изискването на прост английски език
  • Предоставяне на дефиниращи примери, които обясняват изискванията
  • Осигурете интерфейс / платформа, която позволява на техническите (програмисти / тестери) и нетехническите (PO / BA / клиент) да си сътрудничат и да се събират и да бъдат на една и съща страница, за да разберат и изпълнят изискванията

Как да приложим BDD?

На пазара има много инструменти за внедряване на BDD. Тук назовавам няколко:

  • Краставица
  • Фитнес
  • Конкордион
  • JBehave
  • Spec Flow

Пример:

Нека се опитаме да разберем BDD с пример. За моя случай използвам корнишон (краставица):

Помислете за прост случай, в който искаме да позволим само на удостоверени потребители да влизат в сайта на XYZ.

Файлът от корнишони (файл с функции) ще бъде както следва:

Особеност: Портал за регистрация на тестове

Сценарий: Валиден потребител, влязъл в системата

Дадено: Клиентът отваря портала за регистрация

Кога: потребителят въвежда потребителското име като “” и паролата като “”

Тогава: клиентът трябва да може да види формуляра.

Примери :

| потребител | парола |

| потребител1 | pwd1 |

| потребител2 | pwd2 |

Можем да видим как се документира конкретно изискване, като се използва прост английски. Трите амиго могат да работят заедно, за да проектират файловете на характеристиките и конкретни данни от теста могат да бъдат документирани в примерния раздел. BDD предоставя среда, която да събере програмисти, тестери и бизнес на една маса и да установи общо разбиране за функциите, които ще бъдат внедрени.

Подходът BDD спестява усилия и разходи и проверява дали има някакви дефекти след внедряването на производството, тъй като сътрудничеството на клиентите и разработчиците беше през целия цикъл на разработка на функцията.

Екипите за разработка могат да използват тези функционални файлове и да ги конвертират в изпълними програми, за да тестват определена функция.

Как

Е, за това трябва да научите Краставица / Фитнес !!

Развитие, управлявано от тест за приемане

Развитието, управлявано от тест за приемане или ATDD е техника, при която целият екип си сътрудничи, за да определи критериите за приемане на епос / история, преди действителното започване на действието. Тези тестове за приемане са подкрепени с подходящи примери и друга необходима информация.

През повечето време BDD и ATDD се използват взаимозаменяемо. Подходът ATDD може също да бъде реализиран, използвайки формата Даден-кога-тогава, точно както пишем функции в подхода BDD.

Нека се опитаме бързо да обобщим разликите между трите подхода:

  • TDD е по-техничен и е написан на същия език, на който е реализирана функцията. Ако функцията е внедрена в Java, ние пишем JUnit тестови случаи . Докато BDD и ATDD са написани на прост английски език
  • Подходът TDD се фокусира върху прилагането на функция. Докато BDD се фокусира върху поведението на функцията, а ATDD се фокусира върху улавянето на изискванията
  • За да приложим TDD, трябва да имаме технически познания. Докато BDD и ATDD не изискват никакви технически познания. Красотата на BDD / ATDD се крие в този факт, че както технически, така и нетехнически хора, могат да участват в разработването на функцията
  • Тъй като TDD е разработен, той дава възможност за добър дизайн и се фокусира върху аспекта на качеството „Среща на изискванията“; като има предвид, че BDD / ATDD се фокусират върху 2ndаспект на качеството, който е „годен за употреба“

Всички тези техники основно говорят за подхода „тест-първи”, за разлика от подхода „тест-последен”, използван в традиционните методологии за развитие.

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

С концепциите като CI (Непрекъсната интеграция) и CD (Непрекъсната доставка) тестерите трябва да си сътрудничат добре с програмистите и да допринасят еднакво в областта на разработката и операциите.

Позволете ми да обобщя тази дискусия с известната Тестова пирамида в Agile:

Тествайте пирамидата в Agile

Най-ниският слой на тази пирамида се състои от слоя за единичен тест. Този слой е основният слой; следователно е имперско този слой да е твърд. Повечето от тестовете трябва да бъдат вкарани в този слой. Този най-нисък слой се фокусира само върху TDD.

В Пъргав свят, се набляга на това да се направи този слой на пирамидата по-здрав и здрав и се подчертава, че по-голямата част от тестовете се постигат на този слой.

Инструментите, използвани в този слой на пирамидата, са всички инструменти на Xunit.

Средният слой на пирамидата е сервизният слой, обясняващ тестовете за ниво на услугата. Този слой действа като мост между потребителския интерфейс на приложението и модула / компонента от по-ниско ниво. Този слой се състои предимно от API, които приемат заявки от потребителския интерфейс и изпраща обратно отговора. Подходът BDD и TTDD е активен в този слой на пирамидата.

Инструментите, използвани в средния слой на пирамидата, са - Fitnesse, Cucumber и Robot Framework .

Най-горният слой на пирамидата е действителният потребителски интерфейс, който показва, че този слой трябва да съдържа най-малък брой тестове, или трябва да кажа, усилията за тестване на този конкретен слой трябва да бъдат минимални. Повечето от тестовете на функцията трябваше да са завършени, когато достигнем най-горния слой на пирамидата.

Инструментите, използвани в горния слой са - Селен , QTP и RFT.

Тъй като работим на малки стъпки в Scrum (наричани Sprints), ръчното прилагане на всички тези подходи не е осъществимо. Тези подходи изискват автоматизирана намеса. В този случай автоматизацията е много важна.

Всъщност тези подходи всъщност се изпълняват чрез автоматизация. В края на всеки спринт се добавят нови функции, така че става важно предварително внедрената функция да работи според очакванията; следователно, Автоматизация става ХЕРОЙ тук.

Заключение

До края на статията трябва да сте научили за начина, по който тестерите се включват в TDD, BDD и ATDD техниките.

В третата част от поредицата ще фокусирам дискусията си върху автоматизацията в Agile свят.

За автора: Тази статия е от STH Автор Шилпа. Тя работи в областта на софтуерното тестване през последните 10+ години в области като интернет реклама, инвестиционно банкиране и телеком.

Продължавайте да гледате това пространство за много повече актуализации.

Препоръчително четене

^