Agile тестване: ключът към висококачествено разработване на софтуер

Готови ли сте да научите повече за Agile тестването?

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

А ако сте част от Agile екип, трябва да тествате всичко.

Подобно на Рик Санчес, научният гений от сериала „Рик и Морти“.

Ето защо в тази статия ще използваме примери от Rick and Morty, за да ви помогнем да разберете Agile тестването.

Ще научите основите на всички 4 типа Agile тестване, Agile тестовите квадранти и как лесно да управлявате процеса на Agile тестване!

Да започнем!

Какво е Agile?

Забележка: Тази секция е за читатели, които искат да научат повече за основите на Agile методологията. Ако вече сте запознати с нея, кликнете тук , за да преминете към секцията за тестване.

Agile управлението на проекти помага на екипите да създават по-добри, по-ориентирани към клиента продукти в по-кратки цикли на разработка, за разлика от традиционните методи за управление на проекти.

Agile методът по принцип е подходящ за бързомислещи гении като Рик.

Защо?

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

Ето един пример, който ще ви помогне да разберете как работи Agile методът:

Да предположим, че Рик иска да създаде приложение, което проследява местоположението на внука му (Морти), когато двамата са на приключение. Това не само ще помогне на Рик да намери Морти в паралелни измерения, но и ще помогне на родителите на Морти да следят местонахождението на сина си.

В края на краищата, знаем колко Рик мрази своя зет Джери, който се оплаква от техните приключения.

Ако Рик използва традиционни методи за управление на проекти, той ще разработи продукта от начало до край без никакъв принос от страна на Джери. Това може да отнеме години и дори да доведе до краен продукт, който Джери мрази, тъй като никога не е бил консултиран!

Ако обаче Рик използва Agile метода, той ще създаде приложението в няколко кратки „спринта” и ще го тества след всеки спринт. След тестването ще попита Джери за обратна връзка и след това ще я приложи в следващия спринт, като в крайна сметка ще създаде окончателното приложение точно така, както Джери го иска!

Тъй като тези спринтове включват много тестване, Agile екипът разчита на набор от сложни и всеобхватни методи за тестване.

Нека да научим всичко за тях...

Забележка: Въпреки че Agile методологията може да се адаптира за всякакъв вид проект, в тази статия ще обсъдим нейното приложение в софтуерни проекти.

Какво е Agile Testing Framework?

Методът за тестване, базиран на Agile ценностите и принципите, е известен като Agile тестване.

В резултат на това тя следва някои насоки от Agile методологията за разработка, като:

Въз основа на тези насоки, Agile екипът използва 4 вида Agile тестови техники:

(Кликнете върху тях, за да преминете към разделите, посветени на всеки от видовете тестване. )

Но защо един Agile екип използва свой собствен метод за тестване?

Това е като да се чудите защо Рик създава свои собствени неща, вместо просто да ги купи!

Защото е много по-готино!

Но това не е единствената причина, разбира се.

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

Нека видим как Agile тестващите техники се различават от традиционното тестване.

Разликата между традиционните и Agile техники за тестване

1. Честота на тестването

В традиционните методологии за управление на проекти, като тестването Waterfall, продуктът се тества едва след приключване на цикъла на разработка. Но тъй като обхватът на тестването би се увеличил експоненциално до края на проекта, екипът или забавя пускането на продукта, или пести от тестването на софтуера.

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

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

2. Характер на екипа за тестване

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

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

Всички екипи работят заедно за постигане на желаните резултати и няма нужда от отделен QA екип.

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

И така, кой е Agile тестиращ?

Всеки член на Agile екипа може да бъде тестиращ и никой не е нает само за тази работа.

Но в съответствие с убежденията на Рик за експертизата, един Agile тестиращ трябва да бъде вещ в няколко неща:

4-те типа Agile тестване

Сега, когато вече знаете основите на Agile тестването, ще научим за 4-те типа тестване и как се провеждат.

Нека се гмурнем в това ново измерение!

Тип № 1: Разработка, базирана на поведението (BDD)

Помните ли как Рик избяга от затвора с максимална сигурност на Галактическата федерация?

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

И така той успя да обърне цялата игра!

Разработката, базирана на поведението или BDD следва донякъде подобен процес.

Защото продуктът е предназначен да не издържи теста!

Защо?

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

Как се провежда?

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

Те са написани в синтаксиса Gherkin: Given/When/Then

Пример за тестов случай за приложението на Рик за проследяване на Морти може да бъде:

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

Екипът за тестване допълнително усъвършенства стъпките и процесите, които продуктът ще използва, за да отговори на тази ситуация.

И тъй като тестването се извършва едновременно с Agile разработката, продуктът трябва да се провали в тези сценарии!

Успоредно с теста, разработчиците създават функции, които ще помогнат на продукта да премине BDD теста.

Те тестват продукта, докато той не започне да работи, като го усъвършенстват с всеки спринт.

Подобно на това как Рик, Морти и сестра му Съмър намериха начин да разделят времето, за да правят нещата едновременно!

Въпреки това, точно както има правила за пътуване във времето (които Рик почти винаги спазва), трябва да имате предвид някои неща, когато провеждате BDD тестове.

Някои от най-добрите практики за BDD тестване включват:

Тип № 2: Разработка, базирана на тестове за приемане (ATDD)

ATDD или тестване за приемане е много подобно на BDD тестването.

И двата следват един и същ процес:

Напишете критерии за тестване –> Тествайте продукта –> Неуспешно тестване –> Създайте функции, за да преминете теста –> Тествайте отново –> Преминете теста

Въпреки това, само защото те изглеждат подобни, не означава, че са такива.

Подобно на това как Рик и Морти забелязаха „незначителни разлики” между безкрайните вселени в безкрайните измерения.

По същия начин BDD и Acceptance Testing се различават по две основни точки:

Това допълнително премахва натиска върху разработчиците да разбират (или да предполагат) нуждите на клиентите си. Те просто могат да ги включат и да ги попитат по време на процеса!

Пример за сценарий AcceptanceTest за тракера на Rick’s Morty може да бъде:

Въвеждане на Джери, който не е запознат с науката за пътуването във времето.

И макар това да няма нищо общо с техническите характеристики на продукта, то е от решаващо значение за преживяването на клиента при използването му. Затова Рик ще включи Джери в тестването на приложението и определянето на неговата използваемост.

Ето някои добри практики, които да следвате при тестването за приемане:

Следвайте всички тези съвети и може би, само може би, ще успеете да спасите Джери от самия него!

Тип № 3: Изследователско тестване

Помните ли как междуизмерната кабелна мрежа (която Рик и Морти обичат толкова много) изглежда, че няма сценарий?

Но ето защо го обичаме толкова много, нали?!

А ако сте фен на импровизираните телевизионни сериали като „Рик и Морти“, ще харесате експлораторното тестване, защото и то не следва сценарий!

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

Въпреки това, в тази лудост има метод!

Докато тестват продукта, проучвателните тестери:

Това прави процеса научен, забавен и приключенски… точно това, от което се нуждаете, за да привлечете това динамично дуо!

За да направите проучвателното тестване ефективно, ето няколко най-добри практики, които можете да следвате:

Тип № 4: Тестване на базата на сесии

Сесийно базираното тестване е подобно на експлораторното тестване, когато става въпрос за прилагане на творческо и свободно тестване.

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

Ето тук на помощ идва тестването на базата на сесии.

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

Този метод на тестване е идеален за екипи, които се сблъскват с предизвикателства при приспособяването към темпото на експлораторното тестване. Но той може да бъде и трамплин за екипа по тестване, за да следва по-отворен подход към тестването.

А за да извлечете максимална полза от тестването на базата на сесии, ето някои добри практики, които можете да следвате:

Какво представляват квадрантите на Agile тестването?

Добре е да знаете всичко за различните видове тестове.

Но трябва да научите как да приложите тези знания, иначе ще създадете нещо напълно безполезно като това.

И така, кои тестове трябва да използвате и кога?

По-важното е, кога трябва да включите автоматизираното тестване в Agile стратегията за тестване?

Квадрантите на Agile тестването дават отговор и на двата въпроса и ето как изглеждат:

(Не се притеснявайте, ако ви изглежда объркващо, ще ви обясним всичко!)

Квадрантите са изведени според следните спецификации:

Това води до 4 различни типа тестване, които могат да бъдат обобщени в следните квадранти:

Agile тестване квадрант 1: Автоматизирани тестове

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

Agile тестване квадрант 2: Автоматизирано тестване и ръчно тестване

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

Agile тестване квадрант 3: Ръчно тестване

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

Agile тестване квадрант 4: Инструменти

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

Тъй като Agile тестването следва Agile ценностите и принципите, то не препоръчва никакви строги и бързи правила за тестване. Вместо това, то ви насърчава да направите правилния избор въз основа на изискванията на вашия екип.

Или, както казва Рик:

Например, въпреки че квадрантите са номерирани, не е необходимо да следвате същия ред.

Можете да изберете тип тест въз основа на текущите изисквания на вашия продукт.

Ето няколко въпроса, които можете да си зададете, преди да създадете план за тестване:

Бонус: Квадрант на технологичния дълг

В крайна сметка, единственият въпрос, на който трябва да отговорите, е:

Какво можете да направите, за да създадете продукт, ориентиран към клиента, и как Agile тестването ще ви помогне да го постигнете?

Как да управлявате процеса на Agile тестване?

Помните ли защо Галактическата федерация и милиони наемници от цялата вселена преследваха Рик заради неговото портално оръжие?

Това е променящата живота сила на наистина добър инструмент!

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

В процеса на тестване може да се сблъскате с някоя от следните пречки:

И, разбира се, най-голямото предизвикателство за всеки Agile екип: непрекъснато тестване, без значение какво.

За щастие, има начин да решите всички тези проблеми!

Имате нужда от „порталното си оръжие”: мощен софтуер за управление на Agile проекти.

За щастие, има само един всеобхватен софтуер за управление на Agile проекти, от който се нуждаете: ClickUp!

Какво е ClickUp?

ClickUp е водещият в света инструмент за управление на проекти, който се използва от най-продуктивните екипи в света – от стартиращи компании до технологични гиганти – за лесно управление на техните Agile проекти.

С голямо разнообразие от Agile софтуерни разработки и функции за сътрудничество, той разполага с всичко необходимо, за да подкрепи всеки Agile или Scrum екип!

Нека разберем как този portal-gun-of-a-software може да ви помогне да управлявате процеса на Agile тестване:

A. Оптимизирайте процеса на тестване и разработване с задачи, подзадачи и списъци за проверка

Разбира се, Рик е гений, но не винаги можеш да му се довериш за малки, прости задачи.

Просто погледнете тази бележка за речта му като кум!

Вашият Agile екип (дори и да са по-добри в воденето на бележки от Рик) също ще се нуждае от подкрепа за управление на процеса на тестване и разработка.

Задачите, подзадачите и списъците за проверка на ClickUp ще ви помогнат да оптимизирате тестването, като го разделите на малки, изпълними елементи.

Ето как можете да го направите:

Освен това можете да опростите процеса си още повече с помощта на следните функции:

Б. Записвайте всяка подробност в Docs

Понякога просто трябва да запишете нещата, нали?

Но благодарение на функцията Docs на ClickUp, няма да се нуждаете от нереални, паразитни извънземни, които да ви помагат да си водите бележки!

Можете да създадете документи, за да запишете:

Можете също да използвате Docs, за да създадете своя собствена вътрешна уики страница за вашата Agile тестваща методология!

Най-хубавата част?

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

А писането в ClickUp Docs е супер забавно благодарение на функции като:

C. Проследяване на времето с Native Time Tracking

Управлението на времето е трудно и почти е изкушаващо да се върнем назад във времето, за да довършим нещо.

Но не бива да се излагате на риск от „полицията за пътуване във времето“:

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

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

Но ако вече използвате трета страна за проследяване на времето като Time Doctor, Hubstaff или Toggl, можете лесно да я интегрирате с ClickUp.

По този начин можете да следите използването на времето и да планирате по-добре тестовата си сесия, без да се налага да пътувате във времето!

D. Споделяне на персонализирани права за достъп със заинтересованите страни

Не забравяйте, че Agile екипът трябва да работи с всички заинтересовани страни, за да достави добър продукт.

За да ви помогне в това, ClickUp ви позволява да споделяте персонализирани права за достъп с тях. Можете да споделяте файловете, папките и списъците със задачи от вашия проект с всеки в и извън вашата мрежа.

Но все пак можете да контролирате какво могат да правят, след като влязат в работното ви пространство, като зададете техните „разрешения “.

Ето няколко примера за разрешения, които можете да зададете:

Това ще ви помогне да включите клиентите в процеса на ATDD тестване.

Но чакайте, има още!

Точно като броя на г-н Мийсикс, събрани да служат на Джери, списъкът с функциите на ClickUp е безкраен!

За разлика от тях обаче, тези функции наистина ще успеят да задоволят вашите нужди от Agile тестване!

Някои от невероятните Agile функции, които ClickUp предлага на вашия екип, включват:

Заключение

Разбирането на методологията на Agile тестването може да бъде от полза за вашия екип.

В крайна сметка, вашата Agile тестова стратегия е сърцевината на Agile метода.

Колкото по-целенасочени и точни са тестовете ви, толкова по-добри ще бъдат продуктите ви.

Но доброто тестване изисква повече от просто знания и умения.

Ще ви са необходими и прецизни инструменти, които да ви помогнат да провеждате непрекъснати тестове.

За щастие, не се нуждаете от лабораторията на Рик, за да създадете такава.

Всичко, от което се нуждаете, е ClickUp!

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

Регистрирайте се в ClickUp още днес и се насладете на приключенията си в Agile управлението на проекти, точно като Рик и внуците му!