Какво е Agile тестване?
AGILE TESTING е практика за тестване, която следва правилата и принципите на гъвкавата разработка на софтуер. За разлика от метода Waterfall, Agile Testing може да започне в началото на проекта с непрекъсната интеграция между разработка и тестване. Методологията на Agile Testing не е последователна (в смисъл, че се изпълнява само след фаза на кодиране), а непрекъсната.
В тази статия ще обсъдим
- Пътен план за изпитване.
- Страхотни стратегии за тестване.
- Подвижният тестващ квадрант.
- QA предизвикателства с гъвкава разработка на софтуер.
- Риск от автоматизация в пъргав процес.
Пътен план за изпитване
Продължителният план за тестване включва видове тестове, извършени в тази итерация, като изисквания за тестови данни, инфраструктура, тестови среди и резултати от теста. За разлика от модела водопад, в пъргав модел се изготвя и актуализира план за тестване за всяко издание. Типични планове за изпитване в пъргави включва
- Обхват на тестване
- Нови функционалности, които се тестват
- Ниво или Видове тестване въз основа на сложността на характеристиките
- Тестване на натоварване и производителност
- Разглеждане на инфраструктурата
- План за смекчаване или рискове
- Ресурсиране
- Резултати и основни етапи
Страхотни стратегии за тестване
Пъргавият тестов жизнен цикъл обхваща четири етапа
а) Итерация 0
По време на първия етап или итерация 0 изпълнявате първоначални задачи за настройка. Включва идентифициране на хора за тестване, инсталиране на инструменти за тестване, планиране на ресурси (лаборатория за тестване на използваемостта) и др. Следващите стъпки са определени за постигане в Iteration 0
а) Установяване на бизнес аргументи за проекта
б) Установяване на граничните условия и обхвата на проекта
в) Очертайте ключовите изисквания и случаи на употреба, които ще доведат до компромиси при проектирането
г) Очертайте една или повече кандидат архитектури
д) Идентифициране на риска
е) Оценка на разходите и изготвяне на предварителен проект
(б) Строителни повторения
Втората фаза на гъвкавата методология на тестване е Construction Iterations, по-голямата част от тестването се извършва по време на тази фаза. Тази фаза се наблюдава като набор от итерации за изграждане на нарастване на решението. За да направи това, в рамките на всяка итерация, екипът прилага хибрид от практики от XP, Scrum, Agile моделиране и гъвкави данни и т.н.
В итерацията на строителството пъргавият екип следва практиката на приоритетните изисквания: С всяка итерация те вземат най-съществените изисквания, останали от стека на работните елементи, и ги изпълняват.
Итерацията на конструкцията се класифицира на две, потвърждаващо тестване и тестване за разследване. Потвърждаващото тестване се концентрира върху проверка дали системата отговаря на намеренията на заинтересованите страни, както е описано на екипа до момента, и се извършва от екипа. Докато разследващото тестване открива проблема, който потвърждаващият екип е пропуснал или пренебрегнал. При разследващото тестване тестерът определя потенциалните проблеми под формата на истории за дефекти. Разследващото тестване се занимава с често срещани проблеми като интеграционно тестване, тестване на натоварване / стрес и тестване на сигурността.
Отново за потвърждаващо тестване има два аспекта тестване за разработчици и пъргаво тестване за приемане . И двете са автоматизирани, за да позволят непрекъснато тестване на регресия през целия жизнен цикъл. Потвърждаващото тестване е пъргавият еквивалент на тестването на спецификацията.
Agile тестовете за приемане е комбинация от традиционни функционални тестове и традиционни тестове за приемане като екип за разработка и заинтересованите страни го правят заедно. Докато тестването за разработчици е комбинация от традиционно модулно тестване и традиционно тестване на интеграция на услуги. Тестването за разработчици проверява както кода на приложението, така и схемата на базата данни.
(c) Освобождаване на крайна игра или фаза на преход
Целта на „Release, End Game“ е да внедри успешно вашата система в производството. Дейностите, включени в тази фаза, са обучение на крайни потребители, поддръжка на хора и оперативни хора. Също така включва маркетинг на пускането на продукта, архивиране и възстановяване, финализиране на системната и потребителска документация.
Последният етап на тестване на гъвкава методология включва цялостно тестване на системата и тестове за приемане. За да завършите последния си етап на изпитване без никакви препятствия, трябва да тествате продукта по-стриктно, докато е в строежи. По време на крайната игра тестерите ще работят по историите за дефектите.
(г) Производство
След етапа на освобождаване продуктът ще премине към производствения етап.
Подвижните квадранти за тестване
Подвижните тестови квадранти разделят целия процес на четири квадранта и помагат да се разбере как се извършва пъргавото тестване.
а) Agile Quadrant I - Вътрешното качество на кода е основният фокус в този квадрант и се състои от тестови случаи, които се управляват от технологията и са внедрени в подкрепа на екипа, той включва
1. Единични тестове
2. Тестове на компоненти
б) Agile Quadrant II - Той съдържа тестови случаи, които се ръководят от бизнеса и са внедрени в подкрепа на екипа. Този квадрант се фокусира върху изискванията. Видът тест, извършен в тази фаза, е
1. Тестване на примери за възможни сценарии и работни потоци
2. Тестване на потребителския опит като прототипи
3. Тестване на двойки
в) Agile Quadrant III - Този квадрант осигурява обратна връзка на квадранти едно и две. Тестовите случаи могат да се използват като основа за извършване на тестове за автоматизация. В този квадрант се извършват много кръгове от итерационни прегледи, които изграждат доверие в продукта. Видът тестване, направен в този квадрант, е
1. Тестване на използваемостта
2. Изследователско тестване
3. Тестване на двойки с клиенти
4. Съвместно тестване
5. Тестване за приемане от потребителя
г) Agile Quadrant IV - Този квадрант се концентрира върху нефункционалните изисквания като производителност, сигурност, стабилност и др. С помощта на този квадрант приложението е направено, за да достави нефункционалните качества и очакваната стойност.
1. Нефункционални тестове като стрес и тестове за ефективност
2. Тестване на сигурността по отношение на удостоверяване и хакерство
3. Изпитване на инфраструктурата
4. Тестване на миграцията на данни
5. Тестване на скалируемост
6. Тестване на товара
QA предизвикателства с гъвкава разработка на софтуер
а) Шансовете за грешка са по-гъвкави, тъй като на документацията се дава по-малък приоритет и в крайна сметка оказва по-голям натиск върху екипа за осигуряване на качеството
б) Новите функции се въвеждат бързо, което намалява наличното време за тестовите екипи да идентифицират дали най-новите функции отговарят на изискването и дали наистина отговаря на бизнес костюмите
в) Тестерите често се изискват, за да играят ролята на полуразработчик
г) Циклите на изпълнение на теста са силно компресирани
д) Много по-малко време за изготвяне на план за изпитване
е) За регресионно тестване те ще имат минимално време
ж) Промяна в ролята им от вратар на качеството към партньор в качеството
з) Промените и актуализациите на изискванията са присъщи на гъвкавия метод, който се превръща в най-голямото предизвикателство за QA
Риск от автоматизация в пъргав процес
- Автоматизираният потребителски интерфейс осигурява високо ниво на доверие, но те са бавни за изпълнение, крехки за поддръжка и скъпи за изграждане. Автоматизацията може да не подобри значително производителността на теста, освен ако тестерите не знаят как да тестват
- Ненадеждните тестове са основна грижа при автоматизираното тестване. Поправянето на неуспешни тестове и решаването на проблеми, свързани с чупливи тестове, трябва да бъде основен приоритет, за да се избегнат фалшиви положителни резултати
- Ако автоматизираният тест се стартира ръчно, а не чрез CI (Непрекъсната интеграция), тогава съществува риск те да не се изпълняват редовно и следователно може да доведе до неуспех на тестовете
- Автоматизираните тестове не са заместител на изследователско ръчно тестване. За да се получи очакваното качество на продукта, е необходима комбинация от видове изпитвания и нива
- Много налични в търговската мрежа инструменти за автоматизация предоставят прости функции като автоматизиране на заснемането и възпроизвеждането на ръчни тестови случаи. Такъв инструмент насърчава тестването чрез потребителския интерфейс и води до присъщо чупливи и трудни за поддържане тестове. Също така съхраняването на тестови случаи извън системата за контрол на версиите създава ненужна сложност
- За да се спести време, много пъти планът за тестване на автоматизацията е зле планиран или непланиран, което води до неуспех на теста
- Процедурите за настройка и разрушаване на тестове обикновено се пропускат по време на автоматизацията на тестовете, докато при ръчно тестване процедурите за настройка и разрушаване звучат безпроблемно
- Показатели за производителност, като например брой тестови случаи, създадени или изпълнявани на ден, могат да бъдат ужасно подвеждащи и да доведат до големи инвестиции в провеждането на безполезни тестове
- Членовете на пъргавия екип за автоматизация трябва да бъдат ефективни консултанти: достъпни, кооперативни и находчиви, или тази система бързо ще се провали
- Автоматизацията може да предложи и достави решения за тестване, които изискват твърде много текуща поддръжка спрямо предоставената стойност
- При автоматизираното тестване може да липсва опит, за да се създадат и доставят ефективни решения
- Автоматизираното тестване може да бъде толкова успешно, че да им свършат важни проблеми за решаване и по този начин да се обърнат към маловажни проблеми.
Заключение
Agile методологията при тестване на софтуер включва тестване възможно най-рано в жизнения цикъл на разработката на софтуер. Той изисква голямо участие на клиентите и тестване на кода веднага щом стане наличен. Кодът трябва да е достатъчно стабилен, за да го отведе на системно тестване. Може да се направи обширно регресивно тестване, за да се гарантира, че грешките са отстранени и тествани. Главно комуникацията между екипите прави успешен тест за пъргав модел !!!