Как да подобрим CI / CD с тестване на ляво на смяна

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

Предоставя практиките за непрекъсната интеграция, модулните тестови рамки и практиките за автоматизация на тестовете, издигнаха тази парадигма. Вместо да извършват осигуряване на качеството в края на процеса на разработка, много практики за тестване сега стартират и изпълняват изцяло по време на кодиране, интегриране и внедряване. Разработващите и гъвкавите екипи автоматизират скриптове за тестване, а CI / CD тръбопроводите призовават да стартират тестовете по време на фазите на тяхното интегриране или доставка. Нетният резултат е, че разработчиците се предупреждават, когато техните промени в кода нарушават компилацията и могат да предприемат незабавни стъпки за разрешаване на докладвания проблем.

Автоматизирането на тестване и интегрирането на скриптове за тестване в CI / CD тръбопроводи е известно като тестване на ляво на смяна. Това предполага, че могат да се направят повече практики за осигуряване на качеството във фазата на разработване, за да се уловят проблемите по-рано в графика за пускане. Автоматизираното тестване е един от приоритетите за предварителното внедряване за пъргави и отборни екипи, които искат да увеличат честотата на внедряване.

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

Тестването наляво на смяна позволява ангажираността на гъвкавите екипи към качеството

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

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

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

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

Кога да приложите тестване на ляво на смяна

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

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

Томас Дж. Суит, вицепрезидент по ИТ услуги в GM Financial, сподели с мен своите лични идеи относно границите на стратегиите за тестване на ляво на смяна. Той предлага: „Преместването наляво винаги е стратегия, освен при извършване на тестове за интеграция на доставчици на трети страни, тъй като често нямате достъп до техния изходен код. Дори когато имате вътрешни приложения с наследени монолитни архитектури, можете да започнете, като приложите основни правила за регистрация, които изискват преглед на код и сканиране за сигурност. Регистрирането трябва да бъде отхвърлено, ако сканирането включва основни предупреждения и грешки. "

Едно потенциално решение за тестване надолу по веригата с партньори за интеграция е прилагането на виртуализация на услугите. Тази техника позволява на екипите за разработка да симулират реакцията на системата надолу по веригата към различни входове. Той работи добре, когато системите надолу по веригата са добре дефинирани. Инструменти от Micro Focus, Tricentis и други позволяват тази възможност.

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

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

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

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

Тестването наляво на смяна е нарастваща практика на devops, но има своите предпоставки и предварителна инвестиция. Изискват се някои основни способности и практики.

  • Необходими са достатъчен капацитет за тестване и среди, за да се поддържа броят на компилациите и тестовете, които се изпълняват едновременно.
  • Agile екипите изискват набор от инструменти за тестване на продукти, които лесно се интегрират в CI / CD тръбопроводи и инструменти за планиране на задачи и които могат да проверят функционалността, качеството на кода, сигурността и производителността.
  • Архитекти, специалисти по инфосек, ръководители на QA и други висши членове на организацията трябва да установят стандарти за тестване и цели на ниво услуга, които формират критериите за приемане по подразбиране.
  • Когато приложенията изискват въвеждане от потребителя, екипите за тестване се нуждаят от достатъчно тестови данни и модели, за да валидират достатъчно персонали, случаи на употреба и модели на въвеждане.
  • При ангажиране със спринт или по-рано, екипите за скрам, включително инженери за автоматизация на QA теста, трябва да определят стратегия за тестване на това какви възможности се тестват, кои типове тестове се прилагат, какви процеси на автоматизация се актуализират и кой разработва тестовете.
  • Екипите на Devops трябва да измерват продължителността на пробезите на CI / CD тръбопровода и да сигнализират, когато автоматизираните стъпки за тестване влияят върху производителността. Екипите на Devops често изискват допълнителни графици за тестване извън CI / CD тръбопроводи, за да изпълняват по-продължителни тестове.
  • Екипите трябва редовно да обсъждат пропуски в своите автоматизирани тестове, особено валидации, които изискват експерти по предмета, UAT или тестване с партньори. Ако пъргавите екипи не могат да се справят с тези пропуски с автоматизация, тогава циклите на освобождаване трябва да вземат предвид режийните разходи, за да намалят рисковете и да завършат тези тестове.

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

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