how implement efficient test automation agile world
Автоматизацията в Agile е много важна.
Помислете за многото функции, които се добавят и доставят във всеки Sprint. Трябва да има начин да се уверите, че новодобавената функция не засяга съществуващата функционалност.
Поради ниската продължителност на спринта е практически невъзможно да се изпълни целия костюм всеки път, когато продуктът се увеличава в края на спринта. Наличието на автоматизиран тестов костюм определено ще играе по-голяма роля тук.
Въвеждането и узряването на автоматизацията обаче определено ще отнеме известно време. Първоначалната инвестиция в планирането и проектирането на дейността по автоматизация определено би се отплатило в дългосрочен план.
В тази 3-та част от напредналата серия Agile Testing се опитвам да цитирам няколко насоки, които да разгледам въз основа на моя опит, тъй като внасяте автоматизация във вашия проект.
Също така, прочетете част 1 и част 2 първо за по-добро разбиране на темата.
Какво ще научите:
Какво да автоматизирате в Agile?
Винаги, когато планираме да въведем автоматизация в нашите проекти, повечето от нас незабавно гласуват или „Костюмът за димни тестове“, или „Регресионният тестов костюм“ да бъде най-добрият кандидат за автоматизация . Разбира се, че са, но когато мислим за пирамидата на теста за автоматизация, можем да заключим, че става дума само за най-горния слой на пирамидата.
Освен горния слой, все още имаме сервизен слой и единичен слой които са по-важни.
как да стартирам .swf
И така, какви тестове, освен тестове за дим и регресия, могат да бъдат добри кандидати за автоматизация?
# 1) Компилации и внедряване
В традиционните среди имаме предварително дефинирани компилации, които могат да бъдат седмични, двуседмични или понякога дори месечни. Една от причините е, че тези внедрявания отнемат време. Проблемът с този подход е, че трябва да изчакаме предварително дефинираните дати, за да отстраним грешките или да приложим новите функции, така че има забавяне.
Втората причина беше - докато тестерите приключат с тестването и измислят грешки и дефекти, програмистите са преминали към различни части на изпълнението и имат по-малък интерес от разрешаването на грешките на по-старото приложение. Този подход също забавя времето за предоставяне на функцията, достъпна в производството.
Изграждането и внедряването са обекти, които се повтарят и понякога са скучни. Също така може да отнеме часове за внедряване на компилация, което забавя тестването и в крайна сметка обратната връзка. Като повтаряща се задача, внедряванията се превръщат в добър кандидат за автоматизация.
Прочетете също=> Процес на управление на пускане и внедряване
Някои от предимствата на автоматизираното внедряване на компилация са:
- Няма шанс за допускане на грешки при внедряване (могат да бъдат избегнати човешки грешки като копиране на неправилен файл или копиране на файл на неправилното място)
- Грешки / функции са достъпни за тестване веднага след като бъдат коригирани
- Тестерите получават повече време за тестване
- Функцията е готова за преместване в производство за по-малко време
- Бърза обратна връзка
# 2) Тестове за единица / Тестове на компоненти
Вече говорих за важността на автоматизирането на единичния слой с помощта на TDD подход в последния ми урок .
Това образува най-ниския слой на пирамидата, следователно основата и всяка основа трябва да са твърди. Екипът за разработка трябва да си сътрудничи и да работи заедно, за да побере по-голямата част от теста в този слой.
# 3) API / тестване на уеб услуги
Уеб услугите са носителят, в който две приложения обменят данни или информация по отношение на заявка и отговор, без да се занимават с основната архитектура или технология. С по-прости думи - даването на заявка и валидирането на отговора е това, което обикновено правим при тестване на уеб услуги.
шлюзът по подразбиране не е наличен постоянно
Тестване на уеб услугите включва писане на програми за извикване на тези методи на уеб услуга и валидиране на стойността / стойностите, които тя връща. Можем дори да тестваме услугите за различни пермутации и комбинации. Имайте всички тестови данни в Excel листа и вашата програма може да прочете данните и да се обади на проверяемата услуга, като предаде тестовите данни като параметър и потвърди резултатите.
Това специално тестване е част от средния слой на пирамидата. Повечето от функционалните тестове могат да бъдат натиснати в този слой. Отстраняването на дефекти, възникващи в този слой, става лесно за отстраняване и те не се отлагат, докато потребителският интерфейс не е наличен.
# 4) Тестване зад GUI
Автоматизирането на тестването зад GUI е сравнително по-лесно от автоматизирането на действителния GUI. Друго предимство е, че независимо от промените в потребителския интерфейс, функционалността остава непокътната. Дори ако някой от потребителския интерфейс е променен, функционалността на функцията не се променя. Тази техника се фокусира основно върху бизнес логиката и правилата.
Тестовите случаи са написани най-вече в табличен формат или в електронна таблица и са написани приспособления / кодови фрагменти, които приемат входа от тези таблици и връщат резултатите. Резултатите се генерират незабавно и осигуряват чудесна платформа за нетехническите заинтересовани страни да проведат тези тестове и да получат очакваните резултати. Един от инструментите, използвани за постигане на тази техника е Фитнес .
# 5) Нефункционално тестване
Това нефункционална техника на тестване основно включва тестване на натоварване, производителност и стрес. На пазара има различни инструменти, които могат да се използват за автоматизиране на тези тестове.
# 6) Сравнение на данните
Много от нашите тестове изискват да сравняваме файлове с данни, включително текстови файлове, CSV или Excel файлове
- Тези файлове могат да се сравняват с базовите линии за проверка на данните
- Сравненията могат да бъдат от едни и същи данни, но от различен формат. По принцип това се случва, когато имаме два еднакви файла, генерирани от два различни източника
Тези сравнения могат да бъдат повтарящи се, следователно автоматизирани.
# 7) Търсене
Търсенето на конкретна същност от голям куп файлове също може да бъде досадно и Бог ни помага, ако това е повтаряща се задача. Един пример е търсенето в лог файлове. Ако това също е досадна и повтаряща се задача, трябва да помислим за нейната автоматизация.
# 8) Повтарящи се задачи
Всяка задача, започваща с взаимодействие с крайните потребители или писане на истории, за да се разработи, ако е повтаряща се, трябва да се има предвид при автоматизацията. Трябва да разберем, че правенето на автоматизация не означава, че в нея трябва да има сложен инструмент / технология. Това може да бъде обикновен VB макрос или Java програма с Javascript за решаване на целта.
Къде да започна?
Няма точки или ръководство стъпка по стъпка, което казва къде да започнем автоматизацията. Стартирането на автоматизацията за екипа изисква от вас мозъчна атака и прилагане на дълбоки мисли за това кои аспекти искате да автоматизирате или каква е крайната цел на автоматизацията?
Можете да започнете с:
- Идентифициране на повтарящите се задачи,
- Идентифициране на зоните на болка от приложението
- Идентифициране на предизвикателствата при тестване
Ако нямате автоматизация в туропроекта / екипа, тогава вероятно можете да изберете многопластов подход, при който първо да се насочат единичните тестове за автоматизация. Това би ви осигурило най-високата възвръщаемост на инвестициите.
Едновременно с това тестерите могат да започнат да работят върху димния тестов костюм и след това върху регресията. След като екипът натрупа уменията и се почувства комфортно, постепенно преминете към автоматизиране на останалите повтарящи се задачи.
Не се впускайте директно в закупуването на нов инструмент, без да оценявате вашите нужди. Както казах по-рано, обикновена програма или макрос може да реши вашата цел за автоматизиране на някои от повтарящите се задачи. Така че, преди да решите да си купите инструмент, направете POC и преценете дали този инструмент би бил ефективен за използване.
Моля, прегледайте тези документи, където предоставих повече подробности за това как да изберете правилни тестови случаи за автоматизация и някои прозрения за оценка на усилията за автоматизация в следващите статии ръководство за автоматизация на процеса на тестване предизвикателства и тестова оценка на проект за автоматизация на селен.
След като обхватът на автоматизацията и инструмента е финализиран, следващото е проектирането на рамката.
Не забравяйте, че в Agile рамката е разработена. НЕ се насочвайте първо към проектиране на цялата рамка и след това към внедряване. Проектирайте и внедрете MVP (Минимален жизнеспособен продукт) и след това подобрете съществуващата рамка, за да включите повече функции. Също така трябва да приложите добра практика за кодиране и разработка, ако искате вашият пакет за автоматизация да бъде стабилен.
Някои най-добри практики
- Не се насочвайте към автоматизиране на 100% наведнъж. Започнете от малко. Не забравяйте, че това е развиващ се процес
- Следвайте същите Agile практики, които следвате за всяка разработка на софтуер. Автоматизацията също изисква правилно планиране и проектиране. Не бихте искали да увеличавате техническите си дългове, когато автоматизирате
- Създайте изоставането си за автоматизация на тестове. Това изоставане може да варира от внедряване на нова функция до подобряване на съществуваща функция. Дайте исторически точки на вашите идентифицирани елементи и ги присвойте съответно. Занесете тези предмети на вашия Sprint и ги проследете с помощта на дъска Kanban
- Напишете критериите за приемане на вашите истории за автоматизация. Тези критерии за приемане могат да включват:
- Интеграция на тестовия пакет с CI
- Пренасяне на костюма на централизирано място
- Изпратете резултатите по имейл
- Осигуряване на изпращане на регистрационни файлове за грешки, когато тестът се провали
- Всички други критерии ...
- Не прекарвайте много време в оценяване на нов инструмент. Можете да създадете приоритетен контролен списък на всичко, което искате от новия инструмент, и да определите времева линия за оценяването му. Ако не видите резултатите си в определеното време, преминете към следващия
- Вземете разумно решение какво да автоматизирате. Не всяка част от автоматизацията е ефективна и дава положителна възвръщаемост на инвестициите. Не автоматизирайте само заради автоматизацията
- Използвайте подходящата среда за развитие. Не съхранявайте кода на вашия местен. Имайте хранилище, за да запазите кода си и да си създадете навик да проверявате кода си в края на деня
- По подобен начин се опитайте да изпълните автоматизираните си тестове от централизирано място. Направете го независим от човека. Трябва да бъде, че всеки от екипа може да задейства скриптовете от своята машина и резултатите се получават по имейл
Какви са Agile принципите, които могат да бъдат приложени към автоматизацията?
Някои много прости съвети:
- Поддържайте нещата прости. Направете необходимото. Виждал съм много случаи, когато доставяме захарно покритие, което прави автоматизацията ненужно сложна. Нека избягваме нещата, които не са необходими
- Правенето на прости неща не означава да правите най-лесните неща. Това означава да предприемете бебешки стъпки, за да постигнете целите си за автоматизация. Може да се заемете с проста функция за автоматизация, но може да се случи, че внедряването на автоматизация се окаже сложна
- Приложете подхода на целия екип . Вярвам, че всички са изпитатели в пъргав екип. Нека не ограничаваме работата по автоматизация нито само с тестерите, нито само с разработчиците. Всяка от дисциплините трябва да влезе в обувките на другия, за да постигне автоматизация на проекта. Този подход би бил ефективен и за разрешаване на всеки технически проблем, който идва с изпълнението
- Рамката е разработена в Agile . Не се опитвайте да предоставяте твърде много функции, които могат ненужно да направят частта от автоматизацията сложна
- Отделете време да го направите правилно. Отделете малко време, за да го проектирате правилно, за да избегнете техническите дългове
- Получавайте чести отзиви
- Прилагайте правилни стандарти за кодиране и практика. Дизайнът трябва да бъде опростен, прилагайте концепциите на OOPS и се опитайте да запазите тестовете независими един от друг. Помислете за фактори като „поддръжката“ на тестовия костюм
Виждам ли някакви предизвикателства, докато автоматизирам в Agile?
Автоматизацията в Agile света идва с собствените си предизвикателства :
- Трябва да планираме наистина добре. Решаването на подходящия тестов пакет, инструмент, рамка и подход се нуждае от подходяща стратегия. Трябва обаче да не забравяме да НЕ прекаляваме. Имайте предвид MVP (минимално жизнеспособен продукт)
- Компрометирайки качеството на кода, защото искаме да доставим бързо: Трябва да помним, че техническите дългове се държат добре и в автоматизацията
- Екипът през повечето време отборите не следват „Цялостен екип-подход“ и оставят цялата отговорност за кодирането и поддържането на автоматизирания пакет за тестерите, което добавя към отговорността на тестерите
- Автоматизирането на функционалните тестове е по-трудно от автоматизирането на потребителския интерфейс
Сред всички тези предизвикателства най-важното предизвикателство е да се подобрят уменията на тестерите.
Извършването и поддържането на автоматизацията за екип е почти като програма (разработка) дейност, която програмистите (разработчиците) правят. Важно е не само внедряването, но и интегрирането на автоматизирания костюм към CI и изисква тестерите да учат и усвояват нови умения и да усвояват нови инструменти и технологии.
Някои инструменти с отворен код, които се вписват в Agile
- Селен WebDriver - За потребителски интерфейс
- Решетка от селен - За паралелно изпълнение
- Краставица - За BDD
- JMeter - За тестване на производителността
- САПУН - За уеб услуги
- WireMock - Тестване на уеб услуги, когато уеб услугата не е налична.
- Епохи - за мобилни устройства
Позволете ми да завърша с известните тестови квадранти Agile:
най-добър ssd софтуер за клониране windows 10
Квадрант 1 е модулът и тестът на компонентите, които могат да бъдат автоматизирани с TDD подход.
Квадрант 2 говори за тестване на функционалността, където можем да приложим BDD подхода.
Квадрант 3 е единственият квадрант, който има обхват на ръчно тестване.
Квадрант 4 основно говори за тестването, което може да се постигне с някои инструменти. Това се грижи за тестовете за натоварване, стрес тестовете, тестовете за обем и тестовете за сигурност.
Заключение
Има много обхват на автоматизация, освен тестовете за дим и регресията. Следователно трябва да се освободим от концепцията за ограничаване на автоматизацията само до тези видове тестване, което от своя страна означава, че наборът от умения на тестера в Agile изисква повече от просто намиране на грешки и дефекти.
Тестерите трябва да бъдат по-съвместни и да изострят своите умения за програмиране / автоматизация. Ако все повече тестове се автоматизират, това ще даде на тестерите повече време да се включат в по-сложни и предизвикателни задачи.
За автора: Тази статия е на член на екипа на STH Шилпа. Тя работи в областта на софтуерното тестване през последните 10+ години в домейни като интернет реклама, инвестиционно банкиране и телеком.
Моля, споделете вашите коментари и мисли по-долу.
Препоръчително четене
- Урок за AutoIt - AutoIt Изтегляне, инсталиране и основен скрипт за AutoIt
- Тестерите губят ли сцеплението си при тестване поради автоматизация?
- Предизвикателства при ръчно тестване и автоматизация
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Процес на автоматизирано тестване от 10 стъпки: Как да започнете тестване на автоматизация във вашата организация
- Вие сте експерт по ръчно тестване или автоматизация? Работете на непълно работно време за нас!
- 11 най-добри инструменти за автоматизация за тестване на приложения за Android (инструменти за тестване на приложения за Android)
- Топ 10+ най-добри книги за тестване на софтуер (книги за ръчно тестване и автоматизация)