Тестовата автоматизация, когато се направи правилно, може да има много предимства и да бъде много полезна за проекта и организацията. Има обаче някои подводни камъни или недостатъци на автоматизацията на тестовете, за които трябва да сме наясно.
Какви са предимствата на тестовата автоматизация?
Автоматизираните проверки са чудесен начин да се потвърди, че приложението все още функционира правилно след направени промени в него.
Възможно е, когато към дадено приложение се добави нова функция или е коригирана грешка, това се отразява на функционалността на работещия софтуер, т.е. се въвежда регресивна грешка.
Чрез стартиране на набор от автоматизирани регресионни проверки, когато приложението се актуализира, можем да идентифицираме всички нови грешки, въведени в резултат на промените.
Ключовата информация тук е да стартирате автоматизирани проверки толкова често, колкото приложението се надгражда.
Няма нужда да изпълнявате пълния набор от автоматизирани проверки. Бърза опаковка за регресия на дим трябва да е достатъчна, за да решите всички основни проблеми.
Друго голямо предимство на автоматизираните проверки е бързата обратна връзка, която получаваме при актуализиране на приложението. В идеалния случай екипът за разработка трябва да отстрани всички грешки веднага щом възникнат, преди да премине към други задачи.
Моля обърнете внимание че тази бърза обратна връзка може да бъде постигната само с модулни тестове и API тестове. Ако тестваме функционалността от потребителския интерфейс или на системно ниво, тестовете могат да отнемат много време, за да завършат.
Автоматизираните проверки могат да отнемат известно време за скрипт. Когато обаче ги изпълним, те обикновено са бързи и могат да преминат през различни стъпки много по-бързо от човек. Следователно те помагат с предоставянето на бърза обратна връзка на екипа за разработка.
Това е особено вярно в случай на сценарии, управлявани от данни.
Най-доброто използване на автоматизираните проверки са регресионните тестове.
Автоматизирането на регресионните тестове ни освобождава времето на тестерите, така че те могат да се фокусират повече върху изследователското тестване на нови функции.
По същия начин, когато се прилагат правилно, автоматизираните проверки могат да се изпълняват автоматично с минимален или никакъв надзор или ръчна намеса.
Автоматизираните проверки обикновено се пишат на същия език като тестваното приложение. Поради тази причина отговорността за написването, поддържането и изпълнението на тестовете се превръща в споделена отговорност.
Всеки от екипа за разработки може да допринесе, не само тестери.
Какви са недостатъците на тестовата автоматизация?
Пазете се от преминаване на тестове! Това е особено важно при проверка на функционалността на ниво потребителски интерфейс или система.
Автоматичната проверка проверява само това, което е програмирано да проверява.
Всички автоматизирани проверки в тестов пакет могат да преминат с радост, но може да има неоткрити големи недостатъци. Причината за това е, че автоматичната проверка не е била кодирана, за да „търси“ тези грешки.
Решение: се уверете, че сте проектирали добри тестови сценарии, преди да ги автоматизирате. Автоматизираната проверка е толкова добра, колкото и дизайна на теста. Също така допълнете автоматизираните проверки с ръчно / изследователско тестване.
Автоматизираните проверки могат да се провалят поради много фактори. Ако автоматизираните проверки продължават да се провалят поради проблеми, различни от истински грешки, те могат да предизвикат фалшиви аларми.
Например автоматизираните проверки могат да се счупят поради промяна на потребителския интерфейс, прекъсване на услугата или проблеми с мрежата.
Тези проблеми не са директно от тестваното приложение, но могат да повлияят на резултата от автоматизираните проверки.
Решение: Когато е възможно / приложимо, използвайте заглушители. Stubs преодоляват проблеми с свързаността или промени в системите на трети страни. Следователно автоматизираните проверки ще бъдат независими от всякакви неизправности.
За съжаление много хора бъркат „Тестова автоматизация“ с тестване.
След като разполагат с инструментите за автоматизиране на тестването, те искат да „автоматизират всички тестове“. Те искат да се отърват от всички „ръчни тестери“.
Истината е, че тестването е проучвателно упражнение. Тестването изисква познания в областта, фокусиран ум и желание да се научи приложението.
Тестването не е просто изпълнение на набор от предварително дефинирани тестови стъпки и сравняване на действителните резултати с очакваните резултати. Това е работата на автоматизираните проверки.
За правилното тестване на приложение винаги е необходим човешки интелект.
Решение: Разберете, че за успешна доставка на проект се изискват както автоматизирано, така и ръчно тестване.
Едното не е заместител на другото; допълнете автоматизираните проверки с ръчно / изследователско тестване.
Трябва да приемете факта, че автоматизираните тестове изискват поддръжка. Тъй като приложението, което се тества, се развива и автоматичните проверки.
Автоматизираните проверки са краткотрайни. Ако пакетите за регресия не се актуализират, започвате да виждате всякакви откази.
Може би някои проверки вече не са от значение. Или може би проверките не са истинско представяне на новите реализации.
Тези повреди могат да замърсят резултатите от теста.
Влизането в автоматизацията на тестовете не е еднократно усилие. За да извлечете максимума от автоматизираните проверки, те трябва да бъдат актуализирани и подходящи. Това изисква много време, усилия и ресурси.
Решение: Тъй като факторът за поддръжка е постоянна дейност, инвестирайте време в създаването на добра рамка. Използвайте модули за многократна употреба, отделете тестовете от рамката и използвайте добри принципи на проектиране, за да облекчите усилията по поддръжката.
Когато дадена функционалност е готова за тестване, през повечето време е по-бързо да направите ръчна проверка.
Проблемът е, че автоматичните проверки могат да отнемат много време за скриптове в зависимост от сложността на теста. Следователно извършването на ръчна проверка дава по-бърза обратна връзка от скриптове, стартиране и проверка на резултатите.
Също така, по отношение на тестването на потребителския интерфейс и на системно ниво, автоматизираните проверки могат да отнемат много време за попълване и докладване. Следователно, ако има истинска грешка, може да не сме наясно, докато всички тестове не приключат.
Решение: Опитайте се да автоматизирате тестовете заедно с разработката, така че когато разработката завърши, можете да стартирате автоматизираните тестове спрямо новата функционалност.
Освен това отделете автоматизираните проверки в различни пакети.
Пакетът за регресия на дим трябва да бъде супер бърз. Тестовете трябва само да проверят дали приложението може да бъде стартирано и достъпно.
След това можете да имате функционален пакет за регресия, който да проверява основните функционалности.
Друг пакет за регресия може да включва всички тестове от край до край и задълбочени тестове. Тези проверки могат да се изпълняват за една нощ.
Пример за нощно бягане са автоматичните проверки на различни браузъри. Те обикновено отнемат много време, за да се изпълнят във всички браузъри.
По-голямата част от грешките изглежда са открити по „случайност“ или при извършване на изследователски тестове.
Това вероятно е така, защото във всяка сесия за изследователско тестване бихме могли да тестваме приложението по различни начини.
Автоматичните проверки на регресията, от друга страна, винаги следват даден път. Понякога със същия набор от тестови данни. Това намалява шанса за намиране на нови дефекти в приложението.
Също така броят на грешките в регресията изглежда е по-малък от грешките с нови функции.
Решение: Опитайте се да изградите произволност в сценария и данните. Опитването на различни пътища с различни данни всеки път може да разкрие потенциални проблеми.
В тази публикация разгледахме някои от предимствата и недостатъците на автоматизираното тестване. Когато участваме в автоматизиране на тестове, трябва да вземем предвид горните точки, за да извлечем максимална полза.