Sovellusten testaaminen oli aiemmin teknisesti haastavaa, aikaa vievää toimintaa, joka oli ajoitettu päiviä tai viikkoja ennen sovelluksen julkaisua. Kehitystiimeille annettiin liikkumavaraa yhdennentoista tunnin asti, ja testaajilla, jotka tekivät suurimman osan työstään manuaalisesti, ei ollut muuta vaihtoehtoa kuin tyytyä heille annettuun vähäiseen aikaan. Tuloksena oli, että monille sovelluksille tehtiin huonolaatuisia testejä, ja teknologiaryhmät joutuivat vastaamaan loppukäyttäjien ja sovellusten seurantajärjestelmien kärjistämiin tuotantokysymyksiin ja -vioihin.
Jatkuva integraatiokäytäntö, yksikkötestauskehykset ja testausautomaatiokäytännöt ovat tukeneet tätä paradigmaa. Sen sijaan, että suoritettaisiin laadunvarmistus kehitysprosessin lopussa, monet testauskäytännöt alkavat ja suoritetaan nyt täysin koodauksen, integroinnin ja käyttöönoton aikana. Devops ja ketterät ryhmät automatisoivat testauskomentosarjoja, ja CI / CD-putkijonot kutsuvat suorittamaan testejä koodin integrointi- tai toimitusvaiheissa. Tuloksena on, että kehittäjät saavat ilmoituksen, kun heidän koodimuutoksensa rikkovat rakennuksen ja voivat ryhtyä välittömiin toimiin ilmoitetun ongelman ratkaisemiseksi.
Testauksen automatisointi ja testauskoodien integrointi CI / CD-putkistoihin tunnetaan nimellä siirtyminen vasemmalta vasemmalle. Se tarkoittaa, että kehitysvaiheessa voidaan tehdä enemmän laadunvarmistuskäytäntöjä ongelmien saamiseksi aikaisemmin julkaisun aikajanalla. Testauksen automatisointi on yksi esiasennuksen painopisteistä ketterille ja hajautetuille ryhmille, jotka haluavat lisätä käyttöönottotaajuuksia.
Uuden toiminnallisuuden käyttöönotossa rakennetut testiskriptit vahvistavat uudet ominaisuudet. Nämä testit voidaan sitten automatisoida ja sisällyttää rakennus- tai käyttöönottovaiheisiin. Sen sijaan, että laadunvarmistusinsinöörit tekisivät regressiotestejä julkaisuprosessin lopussa, voit suorittaa ja vahvistaa monet näistä testeistä osana kehitystä. Nämä testit siirtyvät vasemmalle julkaisuprosessin lopusta aikaisempiin kehitys- ja koodausvaiheisiin.
Vaihto-vasen-testaus mahdollistaa ketterien joukkueiden sitoutumisen laatuun
Vaihto-vasen-testaus ei vain lisää tehokkuutta ja parantaa laatua, vaan myös luo merkittävän kulttuurimuutoksen ketterässä kehitysprosessissa.
Jotkut kehitystiimit pitävät laadunvarmistusta ja testausta esteenä koodinsa toimittamiselle tuotantoon. Kaiken kovan työn jälkeen ketterien tuotteiden omistajien tyydyttämisessä ja koodin täydentämisessä laadunvalvontaryhmän jäsenet tunnistavat luettelon korjaamista edellyttävistä virheistä. Jos laadunvalvonta löytää paljon virheitä, se voi vaikuttaa julkaisun aikajanaan niiden korjaamiseksi. Vielä pahempaa on, kun merkittävät koodin osat on suunniteltava uudelleen, koska puutteet paljastavat logiikka-, turvallisuus- tai suorituskykyongelmia. Tässä skenaariossa kehittäjät ja laadunvarmistusinsinöörit voivat olla samassa ketterässä tiimissä, mutta eivät toimi tiiminä.
Vaihto-vasen testaus antaa ketterille ryhmille mahdollisuuden siirtää laatuvastuut koko kehittäjien ja testaajien tiimille. Kun testaus suoritetaan osana CI / CD-putkistoa, se tarjoaa kehittäjille paremman mahdollisuuden puuttua laatukysymyksiin sillä hetkellä, kun he työskentelevät asiaankuuluvan koodin parissa. CI / CD-putki ilmoittaa epäonnistuneen rakennelman kehittäjälle, ja useimmat itseorganisoituvat kehitystiimit vaativat näiden ongelmien korjaamista välittömästi.
Vaihto-vasen-testaus tarjoaa myös kehittäjille ja laadunvarmistusinsinööreille mahdollisuuden automatisoida lisää testausta. Paras käytäntö on, että tiimit päättävät, kuka toteuttaa automaation, riippuen kehitetyn toiminnallisuuden edellyttämistä testityypeistä. Esimerkiksi kehittäjät ovat usein vastuussa yksikkö- ja API-testien automatisoinnista, mutta laadunvalvonta-automaatioinsinöörit kehittävät usein päästä päähän -kokemuksen testauksia ja transaktiotestejä, jotka simuloivat monivaiheisia API-kutsuja useille palveluille.
Milloin käytetään siirtymistä vasemmalle-vasemmalle
Vaihto-vasen -testi toimii parhaiten yksikkötasoisissa atomikokeissa, joilla on lyhyet suoritusajat. On olennaista, että CI / CD-putkistossa automatisoidut testit suoritetaan aina, kun kehittäjät käynnistävät koontiversion, suorittavat ne nopeasti eivätkä hidasta rakennusprosesseja.
Monimutkaisemmat ja aikaa vievät testit, kuten päätelaitteiden kokeet, tapahtumien testaus, staattisten koodien analysointi ja tietoturvatestaus, suoritetaan usein paremmin CI / CD-putkistojen ulkopuolella ja päivittäin tai useammin. Nämä testit antavat kehittäjille edelleen varhaisen palautteen laatukysymyksistä, mutta ne automatisoidaan CI / CD: n ulkopuolelle, jotta vältetään rakennusten hidastuminen tai pullonkaulat.
GM Financialin IT-palveluiden johtaja Thomas J. Sweet kertoi minulle henkilökohtaisen näkemyksensä siirtymävasen testausstrategioiden rajoista. Hän ehdottaa: "Vaihto vasemmalle on aina strategia lukuun ottamatta integrointitestien suorittamista kolmannen osapuolen toimittajien toimituksissa, koska sinulla ei usein ole pääsyä heidän lähdekoodiinsa. Vaikka sinulla olisi sisäisiä sovelluksia, joissa on vanhoja monoliittisia arkkitehtuureja, voit aloittaa noudattamalla peruskirjauskäytäntöjä, jotka edellyttävät koodin tarkistusta ja tietoturvatarkistusta. Sisäänkirjautuminen on hylättävä, jos skannaus sisältää välttämättömiä varoituksia ja epäonnistumisia. "
Yksi potentiaalinen ratkaisu loppupään testaukseen integraatiokumppaneiden kanssa on toteuttaa palvelun virtualisointi. Tämän tekniikan avulla kehitystiimit voivat simuloida loppupään järjestelmän reaktioita erilaisiin syötteisiin. Se toimii hyvin, kun loppupään järjestelmät on määritelty hyvin. Micro Focusin, Tricentiksen ja muiden työkalut mahdollistavat tämän ominaisuuden.
Rob Pociluk, erittäin kokenut laadunvarmistuspäällikkö, on ketterän kehityksen voimakkaasti kannattaja siirtymällä vasemmalle vasemmalle. "Valmius ja kyky testata pieniä koodiosia pitää QA: n joustavana ja silmukassa sprintin etenemisen aikana. Joukkueiden tulisi silti suojautua siirtymästä vasemmalle liikaa, koska voit menettää koodin tarkoituksen. "
Joten vaikka tiimit ottavat täysin käyttöön vasemmanpuoleisen testauksen, on hyviä syitä ajoittaa testausikkuna julkaisua varten tarkoitetulle koodikokoiselle koontiversioon. Se varmistaa, että kaikki automatisoidut testit suoritetaan lopullisessa koontiversiossa, mutta mahdollistaa myös täydellisen testauksen, joka vaatii täysin toimivan järjestelmän, ajoituksen.
Yksi näistä testeistä on UAT (käyttäjien hyväksyntätestaus), jossa valitut loppukäyttäjät ja aihe-asiantuntijat vahvistavat ja antavat palautetta. Osa UAT: sta voidaan tehdä kehityksen aikana, mutta ei voi olla helppoa saada ihmisiä suorittamaan tätä testausta usein tai kun toiminnot eivät ole täysin valmiita.
Edellytykset siirtyä vasemmalta vasemmalle testausstrategioihin
Vaihto-vasen testaus on kasvava devops-käytäntö, mutta sillä on edellytykset ja ennakkomainonta. Joitakin välttämättömiä valmiuksia ja käytäntöjä tarvitaan.
- Riittävää testauskapasiteettia ja ympäristöjä tarvitaan tukemaan samanaikaisesti suoritettavien koontiversioiden ja testien määrää.
- Ketterät tiimit tarvitsevat työkalupaketin testaustuotteista, jotka integroituvat helposti CI / CD-putkiin ja työn ajoitustyökaluihin ja jotka voivat vahvistaa toiminnallisuuden, koodin laadun, turvallisuuden ja suorituskyvyn.
- Arkkitehtien, infosec-asiantuntijoiden, laadunvalvontaviranomaisten ja muiden organisaation vanhempien jäsenten tulisi vahvistaa testausstandardit ja palvelutason tavoitteet, jotka muodostavat oletusarvoiset hyväksymiskriteerit.
- Kun sovellukset edellyttävät käyttäjän syöttöä, testausryhmät tarvitsevat riittävät testitiedot ja -mallit riittävän henkilöllisyyden, käyttötapausten ja syöttömallien vahvistamiseksi.
- Sprintti-sitoutumisessa tai aikaisemmin tutkintaryhmien, mukaan lukien laadunvalvonnan testausautomaatioinsinöörit, tulisi asettaa testausstrategia siitä, mitkä ominaisuudet testataan, minkä tyyppisiä testauksia toteutetaan, mitkä automaatioprosessit päivitetään ja kuka kehittää testit.
- Devops-tiimien tulisi mitata CI / CD-putkeajon kesto ja ilmoittaa, kun automaattiset testausvaiheet vaikuttavat tuottavuuteen. Devops-tiimit tarvitsevat usein ylimääräisiä testausaikatauluja CI / CD-putkistojen ulkopuolella pidempikestoisten testien suorittamiseksi.
- Joukkueiden tulisi keskustella säännöllisesti automaattisten testien aukoista, erityisesti validoinneista, jotka edellyttävät aiheen asiantuntijoita, UAT: ta tai testausta kumppaneiden kanssa. Jos ketterät joukkueet eivät pysty korjaamaan näitä aukkoja automatisoimalla, vapautusjaksojen tulisi vaikuttaa yleiskustannuksiin riskien vähentämiseksi ja näiden testien suorittamiseksi.
Lopuksi, ketterien ryhmien ja devops-organisaatioiden tulisi säännöllisesti mitata ja keskustella testien kattavuudesta. Vaihtovasen testausstrategian käyttäminen ei toimi, jos kehitystiimit ja laatuautomaatioinsinöörit eivät todellakaan toteuta, automatisoi ja integroi riittäviä testejä ongelmien havaitsemiseksi ja riskien käsittelemiseksi.
Julkaisusyklien nopeuttaminen tai jatkuvan toimituksen mahdollistaminen ilman riittävää testausautomaatiota voi johtaa merkittäviin laatuongelmiin, jotka heikentävät loppukäyttäjien kokemusta. Ketterät kehitystiimit, jotka ajavat julkaisuja liian usein, joutuvat sitten käsittelemään tuotantokysymyksiä ja -vikoja sen sijaan, että investoivat enemmän ja parempaan automaatioon.
