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

Кои са най-често срещаните предизвикателства при пъргавото тестване, пред които са изправени тестерите на софтуер или QA в гъвкави проекти? Какво е да си QA в пъргав отбор?

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

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

Предизвикателства при пъргавото тестване

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

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

Промяна на изискванията / промени в последната минута

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

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

Как да се преодолее:

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

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

Няма достатъчно информация за историята

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

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

Как да се преодолее:

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

Непрекъснато тестване

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

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

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

Как да се преодолее:

Уверете се, че всяка история има адекватни критерии за приемане и че контекстът на историята е добре разбран от всички, преди да започнете работа по разработката.

Започнете да създавате тестове (автоматизирани или ръчни) възможно най-скоро, така че когато функцията е достъпна за тестване, можете да започнете веднага.

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

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

Технически умения / Автоматизация на тестовете

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

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

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

Как да се преодолее:

Започнете с изучаването на няколко езика за скриптове или програмиране, като Ruby и Java - това са най-популярните езици в общността за техническо тестване.

Ако вече сте запознати с програмирането и закъсате, потърсете помощ от разработчиците.

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

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

Множество браузъри / множество устройства

В днешно време архитектурата на много уебсайтове се състои от „back-end“ и „front-end“. Предната част се основава до голяма степен на JavaScript и CSS, които потенциално могат да се държат по различен начин, когато се гледат от различни браузъри или устройства.

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

Как да се преодолее:

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

Можете да използвате Selenium Grid с Докер за да управлявате и стартирате вашите автоматизирани тестове паралелно на множество браузъри.

Друг чудесен инструмент за тестване на множество браузъри е BrowserSync .

Комуникация

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

Как да се преодолее:

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

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