Þessi titill lýsir vel því umhverfi sem hugbúnaðargerð er að glíma við i dag. Flestir ef ekki allir eru að hanna og forrita veflæg kerfi sem þurfa að geta sinnt allskonar endabúnaði á hverskyns netum. Á sama tíma þurfa þessi kerfi að keyra í „skýinu“ og þurfa að geta annað miklu álagi og skilað góðum afköstum. Einnig krefjast notendur sífellt styttri „afgreiðslutíma“ á nýjungum og/eða lagfæringum.

Agile aðferðafræðin er án efa algengasta nálgun í hugbúnaðargerð í dag, en álags og afkastaprófanir hafa hefðbundið verið einn síðasti verkþátturinn áður en kerfi var sett í rekstur sem er í mikillri andstöðu við hugsunargang Agile verkefna.  Myndin hér fyrir neðan sýnir þennan mun á hvenær þessar prófanir fara fram.

Það er ekki verið að gera meiri prófanir en í staðinn verða álags og afkastaprófanir að vera samofið hugbúnaðarferlinu í hverjum spretti.

Það skal tekið fram að hér er ekki verið að fjalla um almennar prófanir (functional testing) því það er hluti af almennu Agile ferli og er oft nefnt „prevent bugs“ í stað þess að „find bugs“ sem er það sem hið hefðbundna hugbúnaðarferli snérist oft meira um.

Með öðrum orðum þá þarf að samþætta álags og afkastaprófanir í Agile ferlið strax frá upphafi. Til að skýra betur hvernig við náum fram þessari samþættingu er litið til eftirfarandi þátta.

Skýr og mælanleg afkasta og álagsmarkmið:
Til að geta framkvæmt mælingar þarf að vita hvað skal mæla, eða réttara sagt hvað er það sem hagsmunaaðilar (e. Stakeholders) telja að skipti máli. Er það t.d. að „hámarkstími við að skrá vörupöntun sé 0,2 sek ef það séu 500 samtímanotendur“, eða er það kannski að „í snjallsíma á 3g neti sé forsíðan ekki lengur en 10ms að hlaða því sem nauðsynlegt er“ og svona mætti lengi telja. En með því að setja fram þessi markmið strax við upphaf verkefnis þá geta forritarar tekið mið að þeim og byrjað að prófa hvort kerfið standis þessar kröfur strax frá fyrstu sprettum.

Aðgangur að raunkerfum eins fljótt og hægt er:
Þar sem kerfin munu flest ef ekki öll þurfa að verða sett upp í hýsingarumhverfi með tilheyrandi búnaði þá er mikilvægt að koma upp slíku sem fyrst í ferlinu til að álags og afkastaprófanir fari fram á umhverfi sem er eins líkt endanlegu rekstrarumhverfi og hægt er.  Oft hafa tæknihindranir í eldveggjum, vefgáttum og netbúnaði valdið mikilum vandamálum þegar kerfi fara í rekstur á búnaði og uppsetningu sem hefur aldrei verið prófuð.  Að sama skapi er mikilvægt að notendur taki þátt í þessum prófunum og þá er það best gert á raunumhverfi. Þótt að þessu geti fylgt nokkur kostnaður þá telja flestir að þessi nálgun sé betri en að vera með prófunarumhverfi sem er gjörólíkt endanlegu raunuhverfi.  Prófunargögn af raunumhverfi skila sér oftast í betri kerfum.

Undirbúningur prófunargagna:
Þar sem sprettir eru stuttir þá þarf að nota greiningartímabilið og byrjun hugbúnaðargerðarinnar til að útbúa góð prófunargögn, ekki er verra ef LOB (Line of Business) hagsmunaaðilar séu uppspretta slíkra gagna til að tryggja að verið sé að herma notkun (álag) sem endurspeglar hina ætluðu notkun kerfisins.  Því fyrr sem þessi vinna hefst því betra.

Stöðug bæting:
Ef álags- og afkastaprófanir eru gerðar strax frá upphafi þá mun það skila sér í stöðugri bætingu í öllu ferlinu því að alltaf er verið að mæla þá þætti sem hagsmunaaðilar telja vera mikilvægasta og því alltaf til grunnviðmið frá síðasta spretti til að meta hvort viðbætur hafi góð eða slæm áhrif á mælingar. Ef áhrifin eru slæm er auðvelt að staðsetja hvað veldur því ljóst er í hverjum spretti hvað er nýtt eða endurbætt.  Með því að setja fram mælingar þar sem tilhneiging (e. Trend) er skýrt tilgreind þá má fljótlega sjá hvort þróun sé í rétta átt eða ekki.

Hlutaprófanir (stubbing)
Ljóst er að flest kerfi tengjast ytri kerfum eða gagnalindum og oftar en ekki þá eru slíkar tengingar ekki til staðar í upphafi forritunar eða að eigendur slíkra kerfa leyfa ekki álagsprófanir á móti sínum raunkerfum.  Þar sem mikilvægt er að prófanaferlið sé nær alltaf það sama þá verður oft að forrita mótstykki fyrir slíkar þjónustur (stubbing) sem herma þá virkni sem þar er. Æskilegast er þó að fá aðgang að amk. prófunarkerfum (gagnalindum) til að álags og afkastaprófanir reyni á þær nettengingar sem liggja á milli slíkra kerfa.

Sjálfvirkar prófanir:
Með því að hanna eins mikið af prófunum sem sjálfvirkar prófanir (scriptur eða ferli sem má endurtaka aftur og aftur) þá má nýta tíma utan venjulegs vinnutíma til að keyra prófanir og vinna úr niðurstöðum þeirra staðlaðar skýrslur til að auðvelda forriturum og öðrum að fylgjast með framvindu og einnig að þegar nær dregur afhendingu þá styttist oft tími til prófana þar sem forritarar þurfa þá oft að vinna lengur en þeir gerðu í upphafi og í lokin er kerfið orðið sem næst fullbúið og því líklegt að prófanir taki einnig lengri tíma en í upphafi.

Allt virðist þetta vera nokkuð sjálfgefið en í raunveruleikanum er það ærið verkefni að ná að tengja álags og afkastaprófanir inn í Agile ferlið. Eitt af því sem er orsakaþáttur þar er sú staðreynd að í flestum tilvikum hérlendis þá eru forritunarteymin það lítil að í raun eru ekki til staðar sérstakir starfsmenn til að sinna þessum prófunum heldur þarf sérhver forritari í raun að vera í því hlutverki samhliða almennri forritun og þeim prófunum sem þar fara fram.

En ef við náum að samþætta álags- og afkastaprófanir inn í okkar Agile ferli þá hefur reynslan sýnt að það skilar sé í mun betri hugbúnaði og ekki síst mun betri notendaupplifun sem oftar en ekki er lykilþáttur í ánægju með upptöku á nýju kerfi.

Höfundur: Ágúst Valgeirsson, Advania