Useimmat tiimit eivät epäonnistu agenttipohjaisessa testauksessa teknologian puutteiden vuoksi. Ne epäonnistuvat, koska ottavat sen käyttöön kuin työkalun, vaikka se käyttäytyy kuin uusi työntekijä. Et arvioisi uutta QA-insinööriä hänen ensimmäisenä aamunaan, antaisi hänelle nollaa kontekstia tuotteestasi ja palaisi kaikessa hiljaisuudessa vanhaan prosessiin, kun hän esittää kysymyksen. Silti suunnilleen näin monet autonomisen testauksen arvioinnit toteutetaan – ja sitten hylätään.
Rakennamme QA.tech-alustaa, joka on agenttipohjainen QA-alusta, jossa autonomiset QA-agentit testaavat verkkosivustoja, pull requesteja ja mobiilisovelluksia luonnollisella kielellä annettujen tavoitteiden perusteella, ja olemme nyt vieneet satoja tiimejä tämän käyttöönottoprosessin läpi. Olemme myös kirjoittaneet aiheesta laajasti: kenttäoppaamme Pullonkaulan yli käsittelee sitä, miten voit selvittää, missä QA todella hidastaa organisaatiotasi, ja Agenttipohjaisen testauksen käyttöönotto: suunnitelma käy läpi koko käyttöönoton konseptin toimivuuden osoittamisesta tuotantoon. Tämä artikkeli on näiden molempien tiivistetty versio: toimiva etenemisjärjestys, onnistuneet käyttöönotot pysähtyneistä erottava kurinalaisuus sekä yleisimmät virheet, joita näemme.
Vaihe 0: Mittaa pullonkaula ennen kuin ostat mitään
Ensimmäinen vaihe tapahtuu ennen tuotteeseen tutustumista. Ennen kuin otat QA.techin käyttöön, hanki rehelliset luvut siitä, missä todentaminen tällä hetkellä todella aiheuttaa kustannuksia. Kolme mittausta ovat tärkeimmät.
Ensinnäkin ylläpitokuormitus: kuinka monta insinöörityötuntia sprintissä kuluu olemassa olevien testien korjaamiseen uusien testien kirjoittamisen tai ominaisuuksien julkaisemisen sijaan? Toiseksi kattavuusviive: kun ominaisuus yhdistetään, kuinka kauan kestää, ennen kuin sillä on merkityksellinen testikattavuus – tunteja, päiviä vai "kun joku ehtii käsitellä tiketin"? Kolmanneksi julkaisujen kitka: kuinka usein julkaisu odottaa QA:ta ja kuinka usein QA:n aikaa puristetaan julkaisupäivän saavuttamiseksi?
Näillä luvuilla on kaksi tehtävää. Ne kertovat, kannattaako agenttipohjaista testausta ylipäätään ottaa käyttöön – tiimillä, jonka ylläpitokuormitus on kevyt ja julkaisutahti sopiva, on heikommat perusteet muutokselle. Samalla niistä tulee vertailukohtasi, koska yhdeksänkymmenen päivän kuluttua haluat osoittaa muutoksen samoilla mittareilla. Ilman vertailukohtaa tehdyt käyttöönottotoimet päätyvät mutu-tuntumaan, eikä mutu-tuntuma kestä budjettitarkastelua.
Yhtä tärkeää on päättää, mitä lopetat tekemästä. Jokainen käyttöönoton aikana hauraan skriptin paikkaamiseen käytetty tunti tukee prosessia, jonka olet korvaamassa. Valitse testikokonaisuudet, joista luovut, ja päätä milloin se tapahtuu.
Vaihe 1: Rajaa konseptikokeilu, joka voi todella osoittaa jotain
Hyvä QA.tech-konseptikokeilu on pieni, tarkasti rajattu ja rehellinen. Kolme rajausta koskevaa päätöstä määrittävät suurimman osan lopputuloksesta.
Valitse tuskalliset työnkulut. Houkutus on aloittaa puhtaimmasta onnistumispolusta. Vastusta sitä. Ota mukaan vähintään yksi työnkulku, joka todella aiheuttaa tällä hetkellä ongelmia – paljon käyttöoikeuksia vaativa, datasta riippuvainen tai sellainen, jonka regressiotestaamista tiimisi salaa inhoaa. Jos alusta käsittelee vaikeimman tapauksesi, helpot tapaukset ovat muodollisuus. Jos se ei pysty siihen, haluat tietää sen ensimmäisellä viikolla etkä kolmannessa kuussa.
Ota koko tiimi mukaan. Yhden innostuneen insinöörin toteuttama konseptikokeilu antaa vääristyneen kuvan. Eri ihmiset ohjeistavat QA-agentteja eri tavoin – QA-vetäjäsi, tuotepäällikkö ja taustajärjestelmäinsinööri muotoilevat tavoitteet kaikki omalla tavallaan, ja sinun on tiedettävä, että alusta toimii tiimisi jokapäiväisessä kielessä, koska yhden puolestapuhujan hiotut kehotteet todistavat hyvin vähän.
Kirjoita lopetuskriteerit ennen aloittamista. Luotettavat tulokset kriittisillä poluillasi, siedettävä väärien positiivisten tulosten määrä, toimiva vetopyyntö-integraatio ja koko tiimin osoitettu käytettävyys muodostavat hyvän perusjoukon. Sovi niistä tiimisi kanssa aloituskokouksessa ja pidä molemmat osapuolet niistä vastuussa.
Want to learn more about QA.tech?
Vaihe 2: Rakenna kymmenen vankkaa testiä ennen kuin kasvatat määrän sataan
Tämä on ainoa käyttöönotoissa havaitsemamme yksittäinen parhaiten ennustava toimintatapa – ja se, jonka tiimit ohittavat useimmin. Kun alusta pystyy luomaan testejä minuuteissa, vaistona on luoda kaikki ensimmäisellä viikolla. Älä tee niin. Määrä ennen ymmärrystä tuottaa kasan pinnallisia testejä, meluisan tulossivun ja tiimin, joka menettää luottamuksensa tuloksiin.
Rakenna sen sijaan noin kymmenen tärkeää testiä ja tee niistä todella vankkoja. Suorita ne toistuvasti. Kun agentti ymmärtää jotakin väärin – ja alussa niin tapahtuu – kerro sille, miksi se oli väärin, sen sijaan että korjaisit tuloksen kaikessa hiljaisuudessa; korjaus siirtyy kaikkeen, mitä se tekee myöhemmin. Kymmenen syvästi luotettavaa testiä opettavat alustalle tuotteesi ja tiimillesi alustan. Tästä perustasta sadan testin määrään kasvattaminen on nopeaa, ja nämä sata testiä perivät kymmenen testin laadun.
Seurattava kehityssuunta näiden viikkojen aikana on kysymyskäyrä. Terve käyttöönotto näyttää siltä, että uusi kollega pääsee vähitellen vauhtiin: ensimmäisellä viikolla kysymyksiä on paljon, toisella viikolla niitä esitetään satunnaisesti ja kolmannella harvoin, koska alustan tuotetta koskeva tietämys kasautuu. Jos kysymysten määrä ei vähene, ota asia esiin tiimisi kanssa sen sijaan, että jatkaisit väkisin – syynä on yleensä puuttuva tuotteen konteksti, jonka toimittaminen on nopeaa.
Vaihe 3: Liitä se putkeen ja luovu vanhasta prosessista
Kun perustestit ovat luotettavia, käyttöönotosta tulee integrointitehtävä. Yhdistä repositorio niin, että QA.tech käsittelee jokaisen pull-pyynnön. Kokoa regressio- ja savutestit testisuunnitelmiksi, jotka suoritetaan julkaisurytmisi mukaisesti. Ohjaa tulokset sinne, missä tiimisi työskentelee jo ennestään – itse pull-pyyntöön, Slackiin tai tehtävienhallintajärjestelmään.
Sitten tulee vaihe, joka vaatii todellista johtajuutta: rinnakkaisen prosessin poistaminen käytöstä. Tiimit, jotka pitävät vanhaa skriptattua testikokoelmaa käynnissä "varmuuden vuoksi" loputtomiin, maksavat kahdesta järjestelmästä eivätkä luota kumpaankaan. Aseta poistumiskriteerien perusteella päivämäärä, jolloin agenttipohjaisesta kerroksesta tulee kattamiensa työnkulkujen järjestelmärekisteri – ja pidä siitä kiinni. Koko 90 päivän etenemismalli, mukaan lukien se, missä järjestyksessä testikokoelmat siirretään uuden järjestelmän vastuulle, käsitellään Blueprint-oppaassa perusteellisesti.
Vaihe 4: Määrittele QA:n rooli tietoisesti uudelleen
Agenttipohjainen testaus muuttaa QA-työn luonnetta, ja asian teeskentelemättä jättäminen synnyttää hiljaista vastarintaa, joka kaataa käyttöönotot sisältäpäin. Käsittele asiaa suoraan.
Skriptien kirjoittaminen ja ylläpito jäävät pois – työt, joista useimmat QA-ammattilaiset kertovat nauttivansa vähiten. Niiden tilalle tulee ohjaaminen: päätetään, mikä ansaitsee kattavuuden, annetaan agenteille sellaista tuotetietoa, jota kenelläkään muulla ei ole, tarkastellaan arviointiraportteja ja viedään testaus alueille, joita ei aiemmin katettu, koska aikaa ei koskaan ollut. QA-vetäjästä, joka käytti torstait valitsimien korjaamiseen, tulee henkilö, joka kysyy alustalta "millaisilla arvokkailla työnkuluilla ei tällä hetkellä ole kattavuutta?" ja toimii vastauksen perusteella samana päivänä.
Tee muutos selväksi käyttöönoton ensimmäisellä viikolla, ennen kuin epävarmuus ehtii kasvaa. Tiimeissä, joissa QA-ammattilaisista tulee alustan aktiivisia käyttäjiä, käyttöönotto juurtuu.
Käyttöönottoja lyhyesti hidastavat virheet
Perustason määrittämättä jättäminen, jolloin kukaan ei pysty osoittamaan parannusta. Aloittaminen sadalla generoidulla testillä kymmenen vankan testin sijaan. POC:n toteuttaminen yhden puolestapuhujan varassa. Ensimmäisen viikon kysymysten pitäminen epäonnistumisena perehdytyksen sijaan. Vanhasta testikokoelmasta kiinni pitäminen loputtomiin. Ja QA-tiimin roolin muutoksen jättäminen sanomatta. Jokainen näkemämme pysähtynyt käyttöönotto on palautunut vähintään yhteen näistä syistä – ja kaikki kuusi voidaan välttää yllä kuvatulla etenemisjärjestyksellä.
FAQ
Kuinka kauan agenttipohjaisen testauksen käyttöönotto kestää?
QA.techin kaltaisella tekoälytestaustyökalulla ensimmäiset toimivat testit valmistuvat minuuteissa, koska käyttöön ei tarvitse määrittää testauskehystä; luotettavan perustan rakentaminen kestää kahdesta neljään viikkoa, ja täysi tuotantokäyttöönotto – PR-integraatio, regressiosuunnitelmat ja vanhojen testikokoelmien poistaminen – valmistuu tyypillisesti 90 päivän kuluessa.
Pitäisikö agenttipohjaista testausta suorittaa nykyisen testikokoelman rinnalla?
Kyllä, siirtymävaiheen ajan – mutta määritä päättymispäivä. Molempien järjestelmien jatkuva käyttäminen kaksinkertaistaa kustannukset ja hajauttaa luottamuksen; määritä luovutuskriteerit jokaiselle testikokoelmalle ja poista vanha prosessi käytöstä suunnitelmallisesti.
Kenen pitäisi vastata agenttipohjaisen testauksen käyttöönotosta?
Tekniikan johtaja toimii hankkeen sponsorina, mutta päivittäinen vastuu kannattaa antaa QA:lle – sillä on agenttien tarvitsema tuotetuntemus, ja käyttöönotto onnistuu, kun QA-ammattilaisista tulee alustan aktiivisia käyttäjiä.
Mitä meidän pitäisi mitata osoittaaksemme käyttöönoton onnistuneen?
Samaa perustasoa, jonka määritit ennen aloittamista: ylläpitoon käytettyjä tunteja sprinttiä kohden, yhdistämisestä kattavuuteen kuluvaa aikaa sekä QA:n vuoksi viivästyneitä julkaisuja. Vertaa tuloksia 90. päivänä.
Valmis käynnistämään käyttöönoton? Aloita diagnoosista Pullonkaulan jälkeen tai ota yhteyttä tiimiimme, niin näet, miten alan johtavat kehitystiimit julkaisevat nopeammin QA-agenttien validoidessa jokaisen julkaisun.
