Agile Test Automation Framework

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

Автоматизация във Waterfall срещу автоматизация в Agile

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

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

Как да автоматизирате в Agile методологията

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

Така можем да видим противоречие между основните фундаментални философии на гъвкавите методологии и автоматизираното тестване.

Основни точки за гъвкава автоматизация на тестовете

Така че трябва да вземем предвид някои основни моменти тук, когато става въпрос за оценка на използването на гъвкави методологии по отношение на методите и техниките за автоматизирано тестване. Следователно трябва да вземем предвид някои фундаментални моменти като време, необходимо за проектиране и кодиране, валидиране на проектираните скриптове със съществуващите тестови данни и приемането на същите за тестване (независимо дали тестовете са с функционална или регресивна цел). Така че реалният факт на всички тези събития е, че за да изпълним всички тези факти, трябва да гарантираме, че е необходимо значително време за тези задачи и в гъвкава среда, където среден спринт отнема средно 1-2 седмици, за да завърши и следователно е очевидно е твърде трудно да се обмисли предоставянето на толкова много време за автоматизиране на скриптове по такъв начин.

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

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

Инструменти за гъвкава автоматизация

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

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

Следователно основното значение на процеса трябва да бъде да се гарантира, че за да се получи качествена доставка на тестови скриптове за автоматизация в рамките на определено време, както се предоставя от гъвкавата методология; трябва да изберем нашите бъдещи тестови случаи, които ще бъдат автоматизирани по по-нюансиран начин, така че тези автоматизирани тестови скриптове да се поддават добре за бъдеща повторна употреба, както и да гарантираме, че могат да бъдат подготвени в рамките на правилната продължителност на определеното време (както необходими по време на процеса на гъвкава методология).

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

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

Тестване на автоматизацията Concepts когато се прилага към Agile