Как да проектирате и изградите хипер-бърз стек за автоматизация на тестове

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

Роботизиран бегач, започващ спринт

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

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

Какво прави добър стек за тест за автоматизация?

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

1. Целта на тестовата автоматизация е да предостави хипер бърза обратна връзка на разработчиците.

„Обратна връзка“ означава потвърждаване на успеха и уведомяване за проблем. Например, грешка е вид обратна връзка, която сигнализира за проблем, обикновено се съобщава много след като разработчикът смята, че работата им е завършена. По същия начин, пробата на теста е друга форма на обратна връзка и това се случва по време на кодиране.

Защо това е толкова важно?

Поради второто ми златно правило, което се отнася до самата обратна връзка, която гласи:

2. Колкото по-дълга обратна връзка живее в една система, толкова по-скъпо е да се справите с нея.

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

В допълнение,

3. Колкото повече нерешени отзиви се натрупват в даден продукт, толкова по-ниско е качеството на самия продукт.

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

Всичко по-горе представлява моето четвърто правило, което е:

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

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

Кой трябва да проектира стека си за тестване?

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

Самите разработчици ТРЯБВА да притежават тестовия стек.

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

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

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

Помислете за това по този начин: ако шофирате някъде с GPS система и вземете грешен завой, бихте ли предпочели да ви бъдат съобщени незабавно или по-скоро ще изчакате, докато стигнете до грешна дестинация?

Защита на качеството на всяка стъпка

И така, как можете да изградите хипер бърз контур за обратна връзка?

Вие увеличавате обратна връзка на всеки етап от строителството.

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

  1. чист
    Първата стъпка е да премахнете всички файлове, генерирани от предишни компилации, като например компилирани файлове, и да стартирате жизнения цикъл на изграждане от нова база.
    Това е като да изчистите работната си маса от всички битове и парчета, преди да започнете да изграждате нещо ново.
  2. Съставете код
    Тази стъпка взема файлове с изходен код и ги превръща в изпълним код. Продуктът на тази стъпка е да създадете код за даден компонент.
    Тази стъпка е еквивалентна на производството на компонентите, необходими за изграждането на променливотока, като вентилатора, необходим за задвижване на въздуха, и двигателя, който върти вентилатора.
  3. Изпълнете тестове на единица
    Тестовете на модула са просто друго име за изпълними спецификации на компонента, които ни казват дали компонентите работят както е посочено. Ако някои компоненти не са, няма причина да продължавате да изграждате системата. Не забравяйте, че стойността се създава с помощта на компоненти, така че дефектен компонент би довел до дефектна стойност.
    В променливотоковия пример един тест на блока ще гарантира, че лопатките на вентилатора могат да задвижват въздуха при завъртане. Ако лопатките на вентилатора не работят, по-добре е първо да фиксирате лопатките на вентилатора и след това да рестартирате процеса на изграждане.
  4. Изпълнете тестове за интеграция
    След като разберем, че компонентите работят поотделно, можем да ги съберем и да проверим дали създават стойност в унисон. Това е целта на тестовете за интеграция. Тези тестове комбинират точно достатъчно единици, за да създадат стойност и, подобно на предишната стъпка, ако установим, че компонентите не работят заедно, както е посочено, няма причина да продължаваме да изграждаме системата, тъй като стойността е дефектна.
    Назад към примера за променлив ток, ако сглобим вентилатора и мотора и открием, че въздухът не се задвижва поради неподвижността на шпиндела, няма смисъл да поставяме монтажа с останалата част от променливотока.
  5. Разгърнете приложение
    Ако стигнем до този момент и имаме страхотно тестово покритие, това означава, че всички компоненти работят индивидуално и в унисон, за да създадат стойност. Това ни дава голяма увереност да сглобим пълната система. Но все още не сме 100% уверени, че ще работи, тъй като нещо друго може да се обърка в процеса на сглобяване от край до край. Ето защо трябва да направим допълнителни тестове, след като разгърнем приложението.
    С метафората на променлив ток този етап е свързан с обединяването на всички компоненти и възли и свързването му към мрежовото захранване.
  6. Изпълнете тестове от край до край
    С напълно внедрената система, сега можем да се уверим, че тя осигурява предвидената стойност за потребителя. Тези тестове гарантират, че стойностите на спецификациите са изпълнени.
    Натиснете бутона за включване, завъртете копчето за регулиране на температурата към студените настройки и се уверете, че студен въздух се задвижва.

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

Въпреки това…

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

Но с хипер бърз стек тест, получавате голяма увереност, докато всъщност пишете код!

Да! Абсолютно възможно е да давате на разработчиците пълна обратна връзка в реално време по време на разработката. Прочетете, за да разберете как.

Съпоставете своя тестов стек с техния стек

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

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

Ако не използвате Node.js

Тази статия все още трябва да е полезна, тъй като понятията са едни и същи. Просто потърсете в Google за еквивалентния инструментариум за вашия технологичен стек и ме уведомете какво ще намерите в коментарите по-долу или в Twitter.

Най-добрите продукти за хипер-бърз тестов стек

Във връзка с дефинирания по-горе процес, ето списък на моите препоръки за тестване на качеството при всяка от тези основни стъпки.

За локални тестове в реално време

Препоръчвам Wallaby.js
Wallaby.js ви казва, ако ВСЕКИ тест премине или не успее в реално време, при всяко натискане на клавиш!

С всеки натиснат клавиш Wallaby ме уведомява дали нещо се е счупило или минало. Използва много умна техника, за да знае точно кои тестове да изпълнява и ги изпълнява всички паралелно. Резултатът ще ви накара да кажете „уау!“

Видеоклип рисува милион думи (от сайта Wallaby.js):

Повече информация: https://wallabyjs.com

За тестове за интеграция в реално време локално

Препоръчвам Chimp.js
Шимпанз потвърждава логиката на вашия бизнес домейн всеки път, когато запазвате файл.

Използвам режим на тестване на домейн на Chimp. Това е инструмент, който написахме в моята компания, който наблюдава файловата система и подновява тестовете на услугите при всяка промяна. Резултатът е бърза обратна връзка за състоянието на логиката на домейна за приложения Node.js.

Повече информация: http://chimpjs.com

За локални тестове в реално време

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

Използвам режима за тестване от край до край. Вместо да провежда всички тестове от край до край за всеки запис на файл (което би отнело твърде дълго време), Chimp наблюдава конкретен маркер и рестартира маркираните тестове. Този прост трик ви държи много фокусиран върху задачата под ръка, като същевременно предоставя супер бърза обратна връзка от край до край.

Шимпанзето също работи за всяко уеб приложение - без значение за задния план.

Повече информация: http://chimpjs.com

За оркестрация

Препоръчвам Gulp.js
Гълп е диригент на оркестъра.

Да накарате всички парчета да работят безпроблемно заедно може да бъде предизвикателство и имате нужда от инструмент, който може да работи толкова бързо, колкото и вие. Тук идва Gulp.js.

Gulp.js е система за поточно изграждане, която е чудесна за оркестрация. Използвам го за изпълнение на сложни задачи локално - например: стартирайте сървъра за приложения, изчакайте съобщение и след това стартирайте Chimp. На сървъра за непрекъсната интеграция той изпълнява единични тестове, използвайки Mocha & Karma, събира покритие на код и провежда тестове за дим.

Можете също да използвате Gulp и с технологии, които не са Node.js. Наскоро използвах Gulp за контролиране на задачи Maven за проект на Java, заради превъзходната способност за гледане на файлове на Gulp.

Повече информация: http://gulpjs.com

Искате ли да знаете повече?

Тази информация е съкратен откъс от скорошната ми база от знания и ръководство „Качество по-бързо.“ В нея описвам подробно как да внедрявам тези и други технологии като част от цялостен подход с пълен пакет до по-високо качество на софтуера.

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

Елате и вижте сега.

В следващия ми пост

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

Съгласен или несъгласен?

Ако не сте съгласни с препоръките ми за инструменти или знаете за различни инструменти или техники, които смятате, че е още по-добре при хипер бърза обратна връзка, винаги искам да чуя за това! Така че, моля, уведомете ме чрез полето за коментари тук или като се свържете на Twitter в @sam_hatoum

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

Благодаря и с нетърпение очаквам да ви помогна да доставите по-бързо качествен софтуер.

Сам.

Други статии, които съм написал: