Kuinka suorittaa laadunvarmistusagentteja jokaisessa vetopyynnössä QA.techin avulla (ilman ainuttakaan testikomentosarjaa)

Jos tiimisi on ottanut käyttöön tekoälypohjaiset koodaustyökalut, tiedät jo epämukavan matematiikan. Insinööritiimit, jotka toimittivat aiemmin kourallisen vetopyyntöjä viikossa, toimittavat nyt viisikymmentä, sata, joskus enemmänkin – suuren osan niistä kirjoittavat koodausagentit, koodintarkistusagentit tarkistavat ja ne yhdistetään tahtiin, johon mitään manuaalista laadunvarmistusprosessia ei ole suunniteltu. Yksi tiimi, jonka kanssa keskustelimme hiljattain, oli juuri saanut päätökseen ensimmäiset viisikymmentä kokonaan agenttien kirjoittamaa PR:ää ja esitti meille ilmeisen kysymyksen: mikä varmistaa kaiken tämän?

Perinteinen vastaus – kirjoita lisää testiskriptejä – ei kestä tällaisen PR-määrän käsittelyä. Skriptien laatiminen ja ylläpito vievät enemmän aikaa kuin agenttien kirjoittaman koodin tuottaminen, joten testikokoelma jää jälkeen heti ensimmäisenä päivänä eikä saa koskaan etumatkaa kiinni.

Tässä oppaassa käydään läpi QA.techissä rakentamamme vaihtoehto: QA-agenttien yhdistäminen repositorioosi niin, että jokainen vetopyyntö käynnistää tavoitepohjaiset testit, jotka johdetaan itse siitä, mitä muuttui. Ei testikoodia, ei valitsimia eikä ylläpitojonoa. Näin määrität sen ja tätä voit odottaa jokaisessa vaiheessa.

Vaihe 1: Anna agentin tutustua sovellukseesi ensin

Ennen kuin PR-integraatio voi tehdä mitään hyödyllistä, agentin on tunnettava tuotteesi. Kun yhdistät QA.techin testi- tai hiekkalaatikkoympäristöösi, se suorittaa alustavan läpikäynnin: se tutkii sovellusta huolellisen uuden työntekijän tavoin, seuraa jokaista löytämäänsä polkua ja toimintoa ja kokoaa niistä tietämysverkon, joka kuvaa tuotteesi rakenteen.

Satojen käyttöönottojen perusteella kaksi käytännön huomiota. Ensinnäkin, jos sovelluksesi on kirjautumisen takana, määritä kirjautumisprosessi edeltäväksi testitapaukseksi – agentti suorittaa sen ensin ja käy sitten läpi kaiken sen takana olevan. Toiseksi sinä hallitset läpikäynnin syvyyttä. Pintapuolinen läpikäynti (yksi tai kaksi askelta syvälle kussakin käyttäjäpolussa) on nopea ja yleensä riittävä aloittamiseen; voit syventää sitä tärkeimpien toimintokulkujen osalta sen sijaan, että kartoittaisit kaiken tyhjentävästi heti alussa.

Tämä vaihe on koko syy siihen, miksi PR-integraatio toimii. Koska agentti tuntee sovelluksen jokaisen nurkan, se voi päätellä, mihin tietty muutos saattaa vaikuttaa – juuri tätä harkintaa hyvä laadunvarmistusinsinööri käyttää päättäessään, mitä ennen julkaisua on tarkistettava.

Vaihe 2: Yhdistä repositorio

GitHub-integraatio vie vain muutaman minuutin: valtuuta sovellus, valitse repositoriot ja määritä, milloin testit käynnistyvät – tyypillisesti vetopyynnön luonnin tai päivityksen yhteydessä. GitLabin yhdistämispyynnöt noudattavat samaa kaavaa. Tästä eteenpäin testaus on osa putkeasi eikä sen jälkeen tapahtuva vaihe.

Vaihe 3: Avaa vetopyyntö ja seuraa, mitä tapahtuu

Kun PR avataan, agentti lukee, mitä lisättiin ja muutettiin, vertaa sitä tietämysverkkoonsa ja luo kyseisen muutoksen edellyttämät testitapaukset – tavallisesti neljä tai viisi rutiininomaiselle PR:lle, enemmän silloin, kun muutokset koskevat jaettuja toimintokulkuja. Sen jälkeen se suorittaa testit välittömästi oikeassa selaimessa ja käyttää päivitettyä koontiversiota visuaalisesti täsmälleen käyttäjän tavoin.

Tämä on se osa, joka yllättää CI:n käynnistämiin skriptikokoelmiin tottuneet tiimit: kukaan ei kirjoittanut noita testitapauksia. Ne johdettiin itse muutoksesta ja suhteutettiin kaikkeen siihen, minkä agentti jo tietää tuotteestasi. Lisää kojelautaasi uuden suodattimen, ja agentti testaa suodattimen sekä ne kojelaudan toimintokulut, joiden sisällä se toimii. Kenenkään ei tarvinnut muistaa lisätä kattavuutta.

Vaihe 4: Lue tulokset siellä, missä insinöörisi työskentelevät jo ennestään

Onnistuminen tai epäonnistuminen näkyy itse vetopyynnössä. Jokaisesta suorituksesta agentti tuottaa arviointiraportin: tavoitteen, odotetun tuloksen, sen, mitä todella tapahtui, suoritusvideon, vaiheittaiset kuvakaappaukset sekä taustalla olevat konsoli- ja verkkolokit. Epäonnistuminen ei ole punainen X, jonka syy pitää selvittää käänteisesti – se on kirjallinen selitys siitä, mitä agentti odotti näkevänsä ja mitä se sen sijaan näki.

Koska agentti testaa käyttöliittymän kautta, se raportoi epäonnistumiset tuotetasolla – se kertoo, ettei alennuskoodi enää toimi kassalla, ja liittää mukaan todisteet. Juuri tätä tuotetason kontekstia insinöörisi – tai koodausagenttisi – tarvitsevat syyn paikantamiseen ja korjaamiseen. Agenttipohjaisia kehityssilmukoita käyttävät tiimit syöttävät arviointiraporttimme suoraan koodausagenteilleen korjauksen epäonnistumiskontekstiksi – ja MCP-integraation avulla kyseiset koodausagentit voivat käynnistää testiajoja itse työskentelyn aikana.

Vaihe 5: Lisää regressiotestaus PR-testauksen päälle

PR:n käynnistämät testit varmistavat muutoksen. Regressiosuunnitelmat varmistavat kaiken muun. QA.techissä ryhmittelet testitapaukset suunnitelmiksi – savutestisarjaksi jokaista käyttöönottoa varten ja täydelliseksi regressiotestiksi ennen merkittäviä julkaisuja – ja suoritat ne julkaisuprosessiisi sopivalla aikataululla.

Koska testit suoritetaan rinnakkain, seinäkellon mukaan mitattu aika on vain murto-osa siitä ajasta, jonka sama kattavuus vaatisi manuaalisesti. Äskettäinen täydellinen regressiosuunnitelma, jonka suoritimme, kattoi testausmäärän, joka pitäisi manuaalisen testaajan kiireisenä päivän tai kaksi; se valmistui noin kahdessakymmenessä minuutissa. Juuri tämä ero tekee "täydellisen regression suorittamisesta jokaisessa julkaisussa" todellisen käytännön pelkän tavoitteen sijaan.

Vaihe 6: Kysy agentilta, missä testikattavuutesi on puutteellinen

Koska tietämysgraafi yhdistää jokaisen indeksoinnin löytämän työnkulun, alusta tietää eron sen välillä, mitä tuotteesi sisältää ja mitä testisi kattavat. Voit kysyä suoraan keskustelussa: "Mitkä ovat arvokkaimmat työnkulut, joita emme tällä hetkellä kata testeillä?" Agentti vastaa tuotteesi kartan perusteella ja voi luoda puuttuvat testit saman tien.

Tämä kääntää tavanomaisen kattavuusdynamiikan päälaelleen. Sen sijaan, että kattavuus olisi vuosien aikana tikettivetoisen testien kirjoittamisen myötä kertynyttä sisältöä, siitä tulee kysymys, jonka voit esittää ja jonka perusteella toimia saman iltapäivän aikana.

Miltä tämä näyttää kuukauden kuluttua

Tiimien keskuudessa näkemämme toimintamalli on johdonmukainen. Ensimmäiseen viikkoon kuuluu jonkin verran edestakaista keskustelua – agentti esittää kysymyksiä, tarvitsee toisinaan kontekstia tuotteesi erityispiirteistä, ja sinä korjaat sen käsitystä. Toisella viikolla kysymyksiä esitetään harvoin. Kolmannella viikolla ne ovat pääosin loppuneet, koska tietämysgraafi on omaksunut, miten tuotteesi toimii. Sen jälkeen testaus etenee pull requestiesi tahdissa, ja mukana olevat ihmiset tarkastelevat tuloksia komentosarjojen ylläpitämisen sijaan. Jos haluat nähdä koko käyttöönottojärjestyksen konseptin todentamisesta vanhojen testisarjojen käytöstä poistamiseen, olemme julkaisseet sen käytännön oppaana: Agenttivetoisen testauksen käyttöönotto: suunnitelma.

Tiimeille, jotka ovat siirtyneet agenttien kirjoittamaan koodiin, tämä sulkee puuttuneen kehän: koodin generointi, koodikatselmointi ja verifiointi tapahtuvat kaikki koneen nopeudella, ja insinöörisi ohjaavat järjestelmää sen sijaan, että syöttäisivät sille tietoa.

Katso, mitä QA-agentit luovat seuraavaa pull requestiasi varten – yhdistä repositorio QA.techiin ja suorita ensimmäinen testi muutamassa minuutissa.