Запознати ли сте с жизнения цикъл на гъвкавото тестване (ATLC)? Това е процес, използван от екипите за разработка на софтуер, за да гарантират, че техните приложения са тествани правилно и ефективно.
Тази публикация ще ви преведе през всичко, което трябва да знаете за ATLC, включително неговите предимства, стъпки, включени в процеса, планиране на практическа тестова стратегия, изпълнение на тестове, базирани на събиране на изисквания и проследяване на грешки, тестове за приемане от потребителя (UAT) и непрекъснати интеграция и автоматизация на тестове.
След като прочетете това ръководство, ще разберете по-добре как да използвате гъвкавото тестване като част от жизнения цикъл на разработката на вашия софтуер!
Ако сте пъргав разработчик, тестер или продуктов мениджър, който търси по-добър начин за доставяне на вашите продукти, тогава тази статия ще обясни включените етапи заедно с необходимите действия, които да предприемете.
Съдържание
Преглед на жизнения цикъл на гъвкавото тестване
Не е тайна, че тестването е изключително важно в света на гъвкавото развитие. Но въпреки това често се подценява дейността в рамките на гъвкавата доставка. Причината са, разбира се, парите във връзка с времето за доставка на продукцията.
Но без подробно тестване няма да има гаранция за качество или надеждност за всеки продукт, който вашият екип разработва. Ето защо е изключително важно да разберете жизнения цикъл на гъвкавото тестване – от идентифицирането на работни елементи до разбирането какъв тип тест трябва да се използва във всяка фаза.
Гъвкавият цикъл на тестване изисква разработчиците и тестерите да участват във всеки един спринт. Правенето му добре позволява автоматизиране на теста на всеки етап, което помага за по-ранното и по-често откриване на грешки, намалявайки времето за отстраняване на неизправности по-късно.
Гъвкавото тестване също помага за ранното валидиране на изискванията и, като страничен ефект, подобрява удовлетвореността на клиентите чрез доставяне на качествен продукт.
Какво е гъвкаво тестване и неговите предимства
Agile Testing е иновативна методология за тестване на софтуер, която използва автоматизация за създаване на итеративен процес на тестване. Този ориентиран към автоматизацията подход помага на екипите бързо да анализират всякакви несъответствия или проблеми в кода и след това да тестват модификации въз основа на тази обратна връзка.
Така че основните предимства на този процес изглеждат очевидни:
- гарантира, че тестването има необходимото въздействие,
- това води до по-ефективни времена за разработка,
- разработената система има като цяло по-бързи нива на разрешаване на грешки,
- и удовлетворението на клиентите се подобрява.
Качеството и скоростта са решаващи фактори тук, тъй като спринтът се определя като малък период от време (обикновено 2 до 4 седмици). Колкото повече екипът може да разчита на качеството, включено в тестовете за спринт, толкова по-висока увереност и по-бърз напредък в развитието може да постигне екипът.
Фокусът върху автоматизацията трябва да бъде основната цел на всеки гъвкав екип. Това позволява на екипите да намалят риска от скъпоструващ провал и позволява повече време, посветено на създаването на ново съдържание, вместо да коригира това, което вече е в производство.
Друга странична полза е по-добрата оценка на разходите и графика на проекта. Тъй като продуктът е много по-зрял и предвидим, има по-малко ситуации, в които екипът трябва да се справя с неочаквани проблеми, повдигнати по време на спринта, без предварително да е изчислил подобни усложнения.
Стъпки на жизнения цикъл на гъвкавото тестване
Жизненият цикъл на гъвкавото тестване се състои от четири отделни етапа.
Единични тестове
Това са тестовете, извършвани от разработчиците, след като кодът е готов от гледна точка на разработката. Изпълнява се изолирано в среда за разработка, без да включва други части на системата.
Единичните тестове се провеждат за тестване на кода и могат да се извършват ръчно и автоматично.
Ако се изпълнява ръчно, разработчикът изпълнява своите тестови случаи спрямо кода. Това бързо се разбира, но отнема повече време от спринта, посветен на развитието, особено от дългосрочна гледна точка.
Алтернатива на това е създаването на автоматизиран код за тестване на единица, който основно ще провери кода на функцията само като го изпълни. Това означава, че разработчикът трябва да отдели време не само за разработване на новата функция, но и за разработване на тестовия код на модула, който ще тества тази функция.
И въпреки че това може да изглежда като по-голямо усилие от краткосрочна гледна точка, това спестява време за проекта като цяло, тъй като такива модулни тестове са лесни за повторно използване и в по-късните етапи на спринт тестването. Те дори могат да бъдат включени в редовни регресионни тестови случаи, което след това спестява още повече време.
И накрая, колкото по-голямо е покритието на кода чрез автоматизирани тестове на единица, толкова по-добри показатели за надеждност на кода могат да бъдат показани на клиента.
Функционални тестове
Функционалните тестове са предназначени да определят колко добре работи функция на дадено приложение. Този тип тестване се използва, за да се гарантира правилната функционалност на кода, а не технически аспекти (които са били основно част от тестването на модула), както и да се оцени дали той отговаря или не на нуждите и очакванията на потребителите.
С други думи, функционалните тестове се използват, за да се провери дали разработеното отговаря на изискванията, зададени от бизнес потребителите.
Добра практика е да се съберат важни тестови случаи предварително и от съответните заинтересовани страни (или от собственика на продукта, или дори от крайните потребители) и да се направи списък на всички такива тестови случаи, необходими за съдържанието в спринта.
Автоматизирането на функционалните тестове включва повече усилия от страна на разработването на тестове, тъй като това са сложни процеси, които трябва да бъдат проверени, включително различни части на системата заедно. Най-добрата стратегия в този случай е да се създаде специален екип само за разработване на функционални тестове по линията, в която основният екип за разработка разработва нови функции.
Разбира се, за проекта това означава увеличени разходи за поддържане на отделен екип, но също така има голям потенциал да спести пари на проекта в дългосрочен план. Само ръководителите на проекти трябва да обяснят и изчислят конкретно ползите и спестяванията, за да направят солиден аргумент пред бизнес потребителите, който ще доведе до такова увеличение на одобрението на разходите по проекта.
От друга страна, ако се извършва ръчно, тази дейност може да се извърши от много малък екип (в някои случаи дори от един човек). Ще са необходими обаче постоянна ръчна и повтаряща се дейност на всеки един спринт. С течение на времето, тъй като наборът от функции на системата се разширява, може да бъде по-трудно да се навакса изоставането със стабилно функционално тестване спринт след спринт.
Регресионни тестове
Целта на регресионния тест е да гарантира, че всичко, което е работило до момента, ще работи и след следващото издание. Трябва да се проведат регресионни тестове, за да се гарантира, че няма проблеми със съвместимостта между различните модули.
Тестовите случаи за регресионни тестове са най-добри, ако се поддържат редовно и се преразглеждат преди всяко издание. Въз основа на конкретните специфики на проекта, най-добре е те да бъдат прости, но да покриват по-голямата част от основните функционалности и важни потоци от край до край, преминаващи през цялата система.
Обикновено всяка система има такива процеси, които засягат много различни области и те са най-добрите кандидати за регресионни тестови случаи.
Ако има съществуващи автоматизирани единични тестове и функционални тестове, създаването на автоматизация в регресионно тестване е много лесна задача. Просто използвайте повторно това, което вече имате за най-важната част от системата (напр. за процесите, използвани най-често в производството).
Тестове за приемане от потребителя (UAT)
Не на последно място, UAT потвърждава, че приложението отговаря на необходимите изисквания за производствено внедряване. Този подход работи най-добре при често тестване на част от софтуера в кратки и интензивни цикли.
UAT тестът трябва да се изпълнява само от хора извън гъвкавия екип, в идеалния случай от бизнес потребители в специална среда, която е възможно най-близо до бъдещото производство. Като алтернатива, собственикът на продукта може да замени тук крайните потребители.
Във всеки случай, това трябва да е чист, функционален тест от гледна точка на крайния потребител, без никаква връзка с екипа на разработчиците. Резултатите от тези тестове са тук, за да вземем най-важното решение за пускане / не за пускане в производство.
Планиране на ефективна тестова стратегия
Планирането е важна част от гъвкавото тестване, тъй като свързва цялата стратегия. Той също така трябва да определи ясни очаквания за времевата линия в контекста на спринтовете.
Чрез ефективно управление на гъвкавото планиране на тестване, екипите могат да създадат ясна посока, която води до ефективно използване на ресурсите в рамките на спринт. Очевидно се очаква по-голямо сътрудничество между тестери и разработчици.
Трябва също така да бъде създаден цялостен план, който да начертае кога тестване на единица, функционално тестване или тестване за приемане от потребителя се случва в рамките на всеки спринт за разработка. Следователно всеки знае точно кога е необходимо участието му за успешен гъвкав старт.
Как да създадете плана може да бъде след допълнително обсъждане и споразумение. Най-важното обаче е да го превърнете в процес и да се придържате към него. Създайте периодичност, която ще бъде надеждна и предвидима.
Не се отклонявайте от процеса. В противен случай реалността ще бъде точно обратната – хаос и непредсказуеми издания към продукцията.
Изпълнение на тестове въз основа на събиране на изисквания
Тестовете трябва да бъдат изпълнени спрямо изискванията на всеки етап. След това билетите се отварят, когато се открие грешка или проблем и се възлагат на екипа за разработка, който след това ще може да разбере какво трябва да се поправи или промени за кода. След като всички грешки бъдат коригирани, изпълнението на гъвкаво тестване може да продължи, докато всички тестове преминат.
Преглед на резултатите и проследяване на грешки
Ефективният преглед на резултатите и стабилният процес на проследяване на грешки са от съществено значение. Процесът трябва да включва всички съответни заинтересовани страни, от ръководители на проекти и тестери до разработчици, и в крайна сметка екипи за поддръжка, но също и клиенти за събиране на обратна връзка.
Това трябва да е достатъчно цялостна дейност, така че проблемите да могат да бъдат идентифицирани бързо и отстранени преди вече планираната дата на пускане да е изложена на риск.
Изборът на инструмент отново зависи от екипа. Но веднъж избрана, всяка тестова дейност трябва да включва надеждни процеси за проследяване на грешки, за да наблюдава проблемите, да ги приоритизира според зависимостите, да докладва актуализации на състоянието от разработчиците при разрешаване или прехвърляне за по-нататъшно разследване и след това да затваря тикетите, след като бъдат разрешени.
Прегледът помага на гъвкавите тестери да разберат поведението на своята система, идентифицирайки грешки на всяка стъпка, а не по-късно в процеса. Редовните прегледи също така позволяват на гъвкавите екипи да идентифицират тенденции и области, които се нуждаят от подобрение, което им позволява непрекъснато да актуализират своята рамка за тестване и да създават по-бързо продукти с по-добро качество.
Финализиране на пускането на продукта с производствен тест за дим
За да се постигне максимален успех на версията, един от начините за получаване на повече увереност е пускането на Smoke Test спрямо продукцията (точно след пускането).
Този тест се състои от набор от дейности само за четене в производствената система, които няма да създават нови произволни данни, но все пак ще проверяват основната функционалност на системата от гледна точка на крайните потребители.
Включването на правилните заинтересовани страни в процеса помага да се осигури съответствие и отчетност, като същевременно повишава увереността, че целите са постигнати. В крайна сметка тези тестове гарантират успешно издаване.
Непрекъснато интегриране и автоматизиране на тестове за подобряване на ефективността
Непрекъснатата интеграция и автоматизацията на тестовете се възприемат все повече от компаниите, за да изведат гъвкавите процеси на следващото ниво.
Ако екипът може да внедри автоматизация в няколко етапа, както е описано по-горе, тогава те могат да бъдат комбинирани и свързани в специален тръбопровод за тестване, който всъщност е напълно автоматизиран партиден процес, извършващ по-голямата част от дейностите по тестване независимо и без участието на друг екип член.
С течение на времето такъв всеобхватен тръбопровод за тестване ще съкрати общото време, необходимо за всички фази на тестване. В крайна сметка това може да доведе до наистина бързо нарастващо производство след края на всеки спринт. Въпреки че това е идеален сценарий, в действителност е трудно да се постигне с всички включени стъпки за тестване. Автоматизацията е единственият начин да стигнете до там.
Разлика между Agile тестване и водопадно тестване
Гъвкавите стратегии за тестване се различават от традиционните стратегии за каскадно тестване по няколко начина, като периодичност, паралелност или отделено време за всяка дейност.
Но най-забележителната разлика е фокусът на всеки подход:
- Гъвкавото тестване се фокусира върху постоянни, бързи итерации на разработката и вериги за обратна връзка за идентифициране на проблеми и бързо подобряване на продукта. Итеративен процес, фокусиран върху сътрудничеството с клиентите, непрекъснатата интеграция и адаптивното планиране.
- От друга страна, традиционното каскадно тестване набляга на линеен процес, в който всеки етап се разрешава отделно и в последователен ред, оставяйки обратната връзка за цялото решение само за последния етап от проекта и много близо до датата на окончателното производство.
Очевидно е, че колкото по-рано проблемите бъдат идентифицирани от основните заинтересовани страни, толкова по-добра е ситуацията за проекта. В това отношение гъвкавата методология определено има по-голям шанс за успех.
Заключение
Въпреки че жизненият цикъл на гъвкавото тестване може да изглежда по-кратък от водопада, в действителност не е така. Целият процес е непрекъснат и продължава до датата на пускане на продукта. В зависимост от наличния бюджет и време за всеки спринт, ще трябва да определите приоритет кои тестове да се извършват по време на този конкретен спринт.
Добре планираната тестова стратегия ви помага да изберете кои функции или модули изискват повече внимание от други. Автоматизацията ще позволи включването на няколко етапа на тестване в един и същи спринт, повишавайки цялостната надеждност на системата от спринт до спринт.
Сега можете да разгледате някои от най-добрите практики при тестване на скръм.