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

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

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

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

Ръчно срещу автоматизирано - Тестване срещу проверка

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

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

Автоматизирайте регресионните тестове

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

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

Тестове за проектиране преди автоматизирането им

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

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

Също така, не намалявайте обхвата на тестването, само за да накарате теста да работи или да премине успешно.

Премахнете несигурността от автоматизираните тестове

Един от ключовите моменти на автоматизираното тестване е способността да се дават последователни резултати, така че да сме сигурни, че нещо всъщност се е объркало, когато тестът се провали.

Ако автоматизиран тест премине в едно изпълнение и се провали в следващия, без никакви промени в тествания софтуер, не можем да сме сигурни дали отказът се дължи на приложението или на други фактори, като проблеми с тестовата среда или проблеми в самият тестов код.

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

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

Прегледайте автоматизираните тестове за валидност

Ще бъдете разтревожени от огромния брой автоматични тестове, които са остарели, просто не проверявайте за нищо или не проверявате най-важните проверки!

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

Винаги имайте колега, който да прегледа автоматизираните тестове за валидност и разумност. Уверете се, че тестовете са актуални.

Не автоматизирайте нестабилната функционалност

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

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

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

Не очаквайте магия от автоматизацията на тестовете

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

Не очаквайте автоматизацията да открие много грешки . Всъщност броят на грешките, открити от автоматизацията, винаги е много по-малък от ръчното и изследователското тестване.

Не разчитайте само на автоматизацията - пазете се от преминаване на тестове

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

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

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

Стремете се към бърза обратна връзка

Бързата обратна връзка е една от целите на автоматизираните тестове, тъй като разработчиците искат да знаят дали разработеното от тях работи и не е нарушило текущата функционалност.

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

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

Разберете контекста

Тестовете могат да бъдат автоматизирани на всеки слой, Unit, API, Service, GUI. Всеки слой служи за различна цел за тестване.
Unit Tests гарантират, че кодът работи на ниво клас, че се компилира и логиката е според очакванията. Тестовете на този слой са повече проверка, отколкото проверка.

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

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

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

На ниво потребителски интерфейс ние автоматизираме сценарии, а не истории.

Не автоматизирайте всеки тест

100% покритие на теста не е възможно, тъй като може да има милиони комбинации. Винаги изпълняваме подмножество от възможни тестове. Същият принцип важи и за автоматизираното тестване.

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

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

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

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

Използвайте тестови техники в тестовата автоматизация

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

Не автоматизирайте хаоса

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

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

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

Имате ли съвети за автоматизация на теста, които да бъдат добавени към този списък?