Какво е Agile тестване? Процес и жизнен цикъл

Какво е Agile тестване?

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

Принципи на гъвкавото тестване

Ето основните принципи на гъвкавото тестване:

В този модел на Agile тестване работещият софтуер е основната мярка за напредък.
Най-добър резултат могат да постигнат самоорганизиращите се екипи.
Ранното и непрекъснато предоставяне на ценен софтуер е наш най-висок приоритет.
Разработчиците на софтуер трябва да действат, за да се събират ежедневно по време на проекта.
Подобряване на гъвкавостта чрез непрекъснато техническо подобрение и добър дизайн.
Agile Testing гарантира, че крайният продукт отговаря на очакванията на бизнеса, като предоставя постоянна обратна връзка.
В процеса на Agile Test трябва да изпълним процеса на тестване по време на внедряването, което намалява времето за разработка.
Процесът на тестване в Agile трябва да работи върху последователно темпо на разработка
Осигурете редовни размишления за това как да станете по-ефективни.
Най-добрите архитектури, изисквания и проекти възникват от самоорганизиращите се екипи.
Всеки път, когато екипът се събира, той преразглежда и коригира поведението си, за да стане по-ефективен.
Разговорът лице в лице с екипа за разработка е най-ефективният и ефикасен метод за предаване на информация в екипа.

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

Жизнен цикъл на гъвкаво тестване

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

Ето стъпките за тестване на процеса Agile:

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

Фаза 2: Планиране на гъвкаво тестване: Това е втората фаза от жизнения цикъл на Agile тестване, където всички заинтересовани страни се събират, за да планират графика на процеса на тестване и резултатите.

Фаза 3: Готовност за издаване: На този етап преглеждаме функциите, които са разработени/внедрени, готови ли са за пускане на живо или не. На този етап също се решава кой трябва да се върне към предишната фаза на разработка.

Фаза 4: Ежедневни Scrums: Този етап включва всяка сутрешна среща, за да наваксате състоянието на тестването и да си поставите целта за целия ден.

Фаза 5: Тествайте ловкостта Revаз: Последната фаза от жизнения цикъл на Agile е Agile Review Среща. Това включва седмични срещи със заинтересованите страни за редовна оценка и оценка на напредъка спрямо целите.

Гъвкав тестов план

Гъвкав тестов план включва видове тестове, извършени в тази итерация, като изисквания за тестови данни, инфраструктура, тестови средии резултатите от тестовете. За разлика от водопадния модел, в гъвкавия модел се пише тестов план и се актуализира за всяко издание. Типичните тестови планове в agile включват

Обхват на тестване
Нови функционалности, които се тестват
Ниво или видове тестване въз основа на сложността на характеристиките
Тестване на натоварването и производителността
Разглеждане на инфраструктурата
План за смекчаване или рискове
Resourcing
Резултати и етапи

Стратегии за гъвкаво тестване

Жизненият цикъл на Agile тестване преминава през четири етапа

Итерация 0

По време на първия етап или итерация 0 изпълнявате задачи за първоначална настройка. Това включва идентифициране на хора за тестване, инсталиране на инструменти за тестване, планиране на ресурси (лаборатория за тестване на използваемостта) и т.н. Следните стъпки са зададени за постигане в Итерация 0

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

Строителни итерации

Втората фаза на методологията за гъвкаво тестване е Итерации на конструкцията, по-голямата част от тестването се извършва по време на тази фаза. Тази фаза се наблюдава като набор от итерации за изграждане на увеличение на решението. За да направите това, в рамките на всяка итерация, екипът изпълнява хибрид от практики от XP, Scrum, Agile моделиране и гъвкави данни и т.н.

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

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

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

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

Пуснете Крайна игра или Преходна фаза

Целта на „Освобождаване, край на играта“ е да внедрите успешно вашата система в производство. Дейностите, включени в тази фаза, са обучение на крайни потребители, поддържащи хора и оперативни хора. Също така включва маркетинг на пускането на продукта, архивиране и възстановяване, финализиране на системна и потребителска документация.

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

производство

След етапа на освобождаване продуктът ще премине към етапа на производство.

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

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

Гъвкав квадрант I

Вътрешното качество на кода е основният фокус в този квадрант и се състои от тестови случаи, които са технологично задвижвани и са внедрени в подкрепа на екипа, включва

Единични тестове
Тестове на компоненти

Гъвкав квадрант II

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

Тестване на примери за възможни сценарии и работни процеси
Тестване на потребителски опит като прототипи
Тестване по двойки

Гъвкав квадрант III

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

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

Гъвкав квадрант IV

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

Нефункционални тестове като тестове за стрес и ефективност
Тестване на сигурността по отношение на заверка и хакване
Тестване на инфраструктурата
Тестване на миграцията на данни
Тестване на скалируемост
Тестване на натоварването

QA предизвикателства с гъвкавото разработване на софтуер

Вероятностите за грешка са по-големи в гъвкавостта, тъй като на документацията се дава по-малък приоритет, което в крайна сметка оказва по-голям натиск върху QA екипа
Новите функции се въвеждат бързо, което намалява наличното време за тестовите екипи, за да установят дали най-новите функции са в съответствие с изискванията и дали наистина отговарят на бизнес костюмите
От тестващите често се изисква да играят ролята на полуразработчик
Циклите за изпълнение на теста са силно компресирани
Много по-малко време за изготвяне на тест план
За регресионно тестване те ще имат минимално време
Промяна в ролята им от пазачи на качеството към партньори в качеството
Промените и актуализациите на изискванията са присъщи на един гъвкав метод, превръщайки се в най-голямото предизвикателство за QA

Риск от автоматизация в Agile процес

Автоматизираният потребителски интерфейс осигурява високо ниво на увереност, но те се изпълняват бавно, крехки са за поддръжка и са скъпи за изграждане. Автоматизацията може да не подобри значително производителността на теста, освен ако тестерите не знаят как да тестват
Ненадеждните тестове са основен проблем при автоматизираното тестване. Коригирането на неуспешни тестове и решаването на проблеми, свързани с крехки тестове, трябва да бъде основен приоритет, за да се избегнат фалшиви положителни резултати
Ако автоматизираният тест се инициира ръчно, а не чрез CI (непрекъснато интегриране), тогава съществува риск те да не се изпълняват редовно и следователно могат да причинят неуспех на тестовете
Автоматизираните тестове не са заместител на проучвателното ръчно тестване. За да се получи очакваното качество на продукта, е необходима комбинация от видове и нива на изпитване
Много налични в търговската мрежа инструменти за автоматизация предоставят прости функции като автоматизиране на улавянето и повторното възпроизвеждане на ръчни тестови случаи. Такъв инструмент насърчава тестването през потребителския интерфейс и води до присъщо крехки и трудни за поддържане тестове. Също така, съхраняването на тестови случаи извън системата за контрол на версиите създава ненужна сложност
За да спестите време, много пъти тестовият план за автоматизация е лошо планиран или непланиран, което води до неуспех на теста
Процедурите за настройка и разрушаване на теста обикновено се пропускат по време на автоматизацията на теста, докато извършването на ръчно тестване, процедурите за настройка и разрушаване на теста звучи безпроблемно
Показателите за производителност като брой създадени или изпълнени тестови случаи на ден могат да бъдат ужасно подвеждащи и могат да доведат до правене на големи инвестиции в провеждането на безполезни тестове
Членовете на екипа за гъвкава автоматизация трябва да бъдат ефективни консултанти: достъпни, кооперативни и находчиви, или тази система бързо ще се провали
Автоматизацията може да предложи и достави решения за тестване, които изискват твърде много текуща поддръжка спрямо предоставената стойност
На автоматизираното тестване може да липсва експертен опит, за да създаде и предостави ефективни решения
Автоматизираното тестване може да бъде толкова успешно, че да изчерпят важните проблеми за решаване и по този начин да се обърнат към маловажни проблеми.

Заключение

Гъвкавата методология в софтуерното тестване включва тестване възможно най-рано в жизнен цикъл на разработка на софтуер. Това изисква голямо участие на клиентите и тестване на кода веднага щом стане наличен. Кодът трябва да е достатъчно стабилен, за да го вземете за системно тестване. Може да се направи обширно регресионно тестване, за да се гарантира, че грешките са коригирани и тествани. Основно комуникацията между екипите прави успешното тестване на гъвкав модел!!!