Публикувано на 29 юли 2022 г.*Текстът е предоставен от Ciklum
Автоматизацията на тестването е съществена част от всеки мащабен IT проект. Тя дава възможност по-бързо и уверено да пускате новите функции и намалява времето, необходимо за тестването им. Звучи перфектно, нали? На практика обаче не винаги е толкова лесно и безпроблемно. Ако автоматизацията не е изпълнена правилно, това може бързо да затрудни целия екип. Затова, ако искаме да извлечем максимална полза от нашия проект за автоматизация, трябва да знаем и прилагаме най-добрите практики.
В тази статия ще споделя две от тези практики, които използваме и в Ciklum. Въпреки ползите от тях, те рядко се обсъждат и прилагат на практика. Продължете да четете, за да ги научите и се пригответе да издигнете своите умения по автоматизация на следващото ниво!
Съвет 1: Пишете прогресивни тестове, вместо да работите с регресивни
Представете си екип, в който няколко инженери по автоматизация тестват потребителски/приложно-програмен интерфейс (UI/API) чрез регресия. Те обикновено вземат ръчни тестови случаи и ги пренаписват като автоматични такива. Едновременно с това екипът активно разработва и добавя нови функции.Инженерите по автоматизирано осигуряване на качеството (AQA) обикновено не участват в този процес и разработчиците не чакат да се извършат автоматизирани тестове. Функциите се добавят към най-новата версия след ръчно тестване. Какъв е проблемът с този подход?
Регресията е по-малко полезна от тестовете, написани за функции в процес на активно разработване (наричани още „прогресивни тестове“). Прогресивните тестове се създават паралелно с процеса на разработване и са част от критериите за готовност (DOD) за потребителските истории. По този подход не пускаме нови функции, които не са автоматично тествани.
Проблеми с регресията
В типична ситуация инженерът по AQA получава покана да участва в проект и му се възлага да автоматизира ръчни тестови случаи за съществуваща функционалност. Мениджърът или ръководителят по QA очаква обемът работа по регресивно тестване да е ограничен: в даден момент някой инженер ще я завърши и ще продължи да работи по нови функции.
На практика това не се случва много често – с изключение на ситуациите, когато разработването е почти завършено и автоматизацията е въведена в процеса на късен етап. При активно разработване е почти невъзможно да „наваксаме“: докато пишем тестове за съществуващата функционалност, приложението постоянно се актуализира и се добавят нови функционалности. Пускат се нови функции, които не се тестват автоматично, а само ръчно, така че все по-голям брой ръчни тестови случаи ще трябва да бъдат автоматизирани в бъдеще. Така на инженерите по AQA непрекъснато се натрупва технически дълг.
Ето как изглежда това:
GIF илюстрация: (https://tenor.com/view/hamster-wheel-run-gif-10746499)
А ако има изход от този безкраен цикъл? Можем да спрем да натрупваме технически дългове и да направим така, че всички нови функции да се пускат само след въвеждането на автоматизирани тестове. В оставащото време инженерите по AQA все още могат да работят по регресивното тестване.
Звучи добре, нали? Но какво да направите, ако просто не остава достатъчно време за регресивно тестване? Обикновено има по-малко инженери по AQA, отколкото разработчици, така че може да е трудно да сте в крак с разработването, особено ако трябва да извършите и регресивното тестване. Но дори да нямате достатъчно време и за двете, трябва да дадете приоритет на прогресивното. Това изобщо не означава, че трябва да зарежете регресивното тестване. Просто първо трябва да напишете тестове за новите функции, докато все още са в процес на разработване. А какво правим с регресивното тестване тогава? Ще обсъдим това малко по-късно, а засега нека се съсредоточим върху предимствата на прогресивното тестване.
Предимства на прогресивните тестове
По прогресивния подход не затваряме потребителската история, докато не бъде обхваната от автоматизирани тестове. Това носи редица ползи:
● От самото начало кодът е написан по начин, съобразен с автоматизацията. Всички необходими автоматизационни идентификатори се добавят веднага (ако става дума за тестове на UI). Откриваме всички потенциални недостатъци на ранен етап, по време на разработването, когато те са много по-лесни за отстраняване.
● Тестовете на всички нива ни помагат да открием проблеми в архитектурата на приложението и допринасят за цялостния по-добър дизайн на кода. Това е много явно на ниво модулно тестване: ако имате „спагети код“, просто няма как да напишете добри модулни тестове за него. Следователно самото наличие на модулни тестове в проекта подобрява дизайна на кода като страничен ефект. Но това, което хората обикновено пропускат, е, че същият принцип работи на всяко ниво на тестване, включително тестове от по-високо ниво. Тестовете на API или UI може да ви помогнат да откриете проблеми с архитектурата на високо ниво за цялото приложение. Например, ако приложението не е снедобър дизайн, ще е трудно неговите компоненти да се тестват самостоятелно. Този проблем може бързо да бъде разкрит с автоматизация на тестовете – но ако работим само с регресия, ще разберем за него твърде късно, когато ще бъде трудно да направим значими промени.
● С прогресивно тестване откриваме повече бъгове и в резултат на това имаме повече доверие във функциите, които пускаме. Само се замислете: къде ще намерите най-много дефекти? В части на приложението, които са в процес на активно разработване и се променят постоянно, или в части, които вече са пуснати и не се актуализират редовно?
● Не губим време да автоматизираме по-стари ръчни тестови случаи. Ръчните тестови случаи рядко се пишат по начин, съобразен с автоматизацията, защото са написани за хора. Не е толкова лесно да ги конвертирате в код. Много често се налага да се свързвате с тестера, който ги е написал, да изяснявате подробностите, да разделяте един голям случай на няколко малки и т.н. Всички тези процеси отнемат допълнително време и усилия.
● Можем бързо да отстраним всички бъгове, които могат да ни попречат да автоматизираме функцията. Например може да има някакъв незначителен дефект в потребителския интерфейс с много нисък приоритет, който всъщност не засяга крайния потребител, но може да създаде известни трудности за автоматизацията. В този случай обикновено трябва да изчакаме, докато разработчикът има възможност да го поправи, или да изчакаме дефектът да бъде въведен в спринта. Но ако работим по същата функционалност като разработчиците, всички незначителни проблеми ще бъдат коригирани бързо, тъй като кодът е все още „свеж“ и разработчикът не трябва да прави превключване на контекста. Вместо бъг, той просто се превръща в задача от същата потребителска история и се отстранява много по-бързо.
Друг важен момент: работата в екип става изключително неефективна, ако не работим с разработчиците по едни и същи функции. Моят опит показва, че тестерите обикновено живеят на собствен изолиран остров. Комуникацията между разработчиците и инженерите по AQA е минимална или дори не съществува. Обикновено се осъществява само когато открием дефект и искаме да бъде поправен от разработчик. Освен това, ако не си сътрудничим тясно с разработчиците в ежедневната работа, шансовете да ги включим в автоматизацията са минимални. Ще обсъдим защо това участие е толкова важно в следващия раздел.
Съвет 2: Включете разработчиците в автоматизацията
Помните ли дилемата от последния раздел: какво да правите, когато няма достатъчно време за прогресивно и регресивно тестване? Решението е участието на разработчиците в процеса на автоматизация. Когато екипът е достатъчно зрял и има добра комуникация, можем и трябва да поверим създаването на прогресивни тестове на разработчиците (разбира се под надзора на инженерите по AQA), а ние самите да се фокусираме върху регресивното тестване. Ако сте успели да постигнете това – поздравления, вашият проект ще има много голям шанс за успех. Обикновено, когато хората чуят това за първи път, стават малко скептични, така че дайте ми възможност да отговоря на вашите съмнения и притеснения.
Loading …
София
Fully Remote
Кажете „не“ на прекомерното тестване и „да“ на тестовата пирамида.
Предполагам, че всички сме чували за тестовата пирамида:
Основната идея е, че повечето тестове трябва да бъдат написани на по-ниско ниво, защото ще бъдат по-бързи и надеждни. Но ако разработчиците и тестерите не си сътрудничат редовно, как да спазваме това правило? Невъзможно е. В проектите, където инженерите по AQA „живеят на собствен остров“, практически няма комуникация между разработчиците и инженерите по AQA. Това постоянно води до „прекомерно тестване“: тестовите случаи, които могат да бъдат написани на по-ниски нива, обикновено се изпълняват на най-високо ниво – тестове на API или UI. А те са много по-бавни и по-малко надеждни.
Когато автоматизацията е съвместен проект на целия екип, този проблем няма как да възникне. Трябва да решим като цял екип на кое ниво е най-добре да тестваме дадено изискване. Например инженерът по AQA може да създаде тестови случаи за дадена история и да реши заедно с разработчика какво трябва да бъде обхванато в модулни/интеграционни тестове и какво – в тестове на UI/API. Обикновено повечето бизнес логики трябва да бъдат обхванати на по-ниски нива, а тестовете на по-високо ниво се запазват за тестване на интеграцията между компонентите и цялостния бизнес поток. Имайте предвид, че това е много по-лесно за постигане по подхода за прогресивно тестване, който обсъдихме по-горе. Ако работим само с регресивно тестване, ще трябва постоянно да прекъсваме разработчиците и да ги молим да се върнат към старите модулни тестове и да ги актуализират. Интуицията ми подсказва, че те няма да бъдат много възприемчиви към нашите искания.
В идеалния случай в зрелия екип границата между инженерите по AQA и разработчиците се размива с времето и реално целият екип работи по автоматизацията. Това не означава, че разграничението между разработчик и инженер по AQA е изчезнало. Просто всеки в екипа става отговорен за целия продукт, включително автоматизацията. Ако искате вдъхновяващ пример как проектът VSTS на Microsoft успешно е приложил това, ето връзка към статията. Но не е нужно да бъдете наети в Microsoft, за да можете да направите това. В моя професионален опит бях благословен да работя по проекти, в които се прилагаше този подход. Излишно е да казвам, че това са проектите, при които автоматизацията донесе най-голяма стойност.
Значението на използването на един и същи език за програмиране
Както може би вече се досещате, има много по-голям смисъл да използвате един и същ език за програмиране на автоматизираните тестове и back-end на приложението. За съжаление, често съм срещал тестови мениджъри, които са решили да използват различен език за програмиране на автоматизацията по погрешно обосновани причини. Например мениджърът решава да избере Python за автоматизация (когато back-end-ът е написан на напълно различен език), защото се предполага, че е по-лесно да се пишат тестове на Python или има повече инженери по AQA, запознати с него на работния пазар.
Но тези хора не осъзнават, че просто създават повече проблеми за себе си в дългосрочен план. Всяка въображаема полза от това решение бързо се стопява. Ето какво се случва, ако изберем друг език за програмиране на тестовете:
● Имаме по-малко шансове да включим разработчиците в писането на тестовете. Те няма да са запознати с технологията и може да нямат интерес да я научат.
● Не споделяме най-добрите практики и опит помежду си. Освен това разработчиците обикновено не могат да участват в нашите прегледи на кода.
● Изчезват всички възможности за споделяне на общ код, модели, помощни програми, клиенти за API, споделени библиотеки и т.н.
● Разработчиците няма да се противопоставят на инсталирането на друга интегрирана среда за разработка (IDE) за локално изпълнение на тестовете, преди да се ангажират. Да, винаги имаме конвейер за непрекъсната интеграция (CI) за това. Но все пак на практика локалното провеждане на набор от тестове преди ангажирането им спестява много време и усилия, особено ако тестовете се изпълняват само след внедряването, а не като част от готовата версия на програмата. По този начин ще имате много по-бърза обратна връзка, ако нещо се обърка.
Психологически граници от двете страни и начини за тяхното преодоляване
Да кажем, че вече имате по-малко съмнения относно полезността на този подход и искате да го приложите във вашия екип. Може да имате късмет и разработчиците да се окажат ентусиазирани от вашата идея. Невинаги обаче е така и може да срещнете известни съмнения или груба съпротива.
„Не отговаряме за това.“
„Значи искаш да го направим сами? Изпълнението и тестването? А ти какво ще правиш в такъв случай?”
Подгответе се да чувате тези фрази в началото – това е напълно нормално. Хората не са най-големите фенове на промените и „допълнителните“ отговорности (или неща, които се възприемат като такива). Опитайте се да си представите себе си в тяхната ситуация: това наистина може да звучи доста извън зоната ви на комфорт. Затова вашата задача е спокойно, уверено и настойчиво да представите на целия екип ползите от този подход.
Това може да отнеме известно време и затова трябва да имате търпение. През това време:
● Повдигайте тази тема редовно по време на ретроспективните срещи. Не забравяйте да подчертавате ползите, които целият екип ще получи от това. Обсъдихме ги подробно в тази статия, така че вече разполагате с добри аргументи в тази посока.
● Помолете разработчиците за помощ, ако срещнете трудности при автоматизацията или ако нямате време. Обикновено хората ще ви помогнат, ако ги помолите – това може да се окаже добра отправна точка за бъдещо сътрудничество.
● Поемете инициатива и помолете разработчиците да поемат някои от вашите тестови случаи в модулни тестове, за да можете да намалите количеството функционални тестове.
● Изберете най-непредубедения разработчик и се опитайте първо да включите него в писането на автоматизирани тестове. Рано или късно останалите ще го последват.
● Задавайте следните въпроси спокойно, без да натрапвате мнението си на екипа:
„Какво правим като инженери по AQA, когато разработването върви много по-бързо от тестването и нямаме достатъчно време да сме в крак?“
„Как ще успеем, ако не работим по автоматизацията като цял екип?“
Ако правите това правилно, в един момент някой разработчик ще предложи да ви помогне и ще се включи.
Ако не убедите екипа си веднага, трябва да бъдете търпеливи и да продължите да следвате по-традиционните и добре познати най-добри практики в автоматизацията – стабилни и добре написани тестове, добра изолация на тестовете, редовно изпълнение на тестове на CI и т.н. С течение на времето и с всеки нов бъг, открит от автоматизираните тестове, вашият екип ще осъзнава още повече стойността им. Съвместната инвестиция в автоматизацията вече няма да изглежда толкова радикална и ще бъде добре оправдана.
Заключение
В тази статия обсъдихме два по-малко известни съвета, които ще ви помогнат да извлечете максимална полза от автоматизацията: писане на „прогресивни тестове“ и включване на разработчиците в автоматизацията. Дори когато се използват самостоятелно, те носят много ползи за проекта. Но ако ги приложите заедно, ще имате много мощен инструмент в ръцете си, който ще издигне вашето автоматизирано тестване на следващото ниво. Късмет!
