Teoriassa testiautomaatio-ohjelmien tai -työkalujen on tarkoitus helpottaa testaajien toimintaa, säästää aikaa ja tarjota meille ylimääräinen rentoutumispeite arviointimme kattavuuteen.
Ja niin monet organisaatiot eivät pysty toteuttamaan skaalautuvaa, vahvaa ja hyvää Test Automation -infrastruktuuria, joka palauttaisi investoidut resurssit ja voisi säästää niitä. Jotkut "heitä pois" kirjoitetut testiautomaatiotyöt ja toiset jatkavat jatkuvaa taistelua tavoitteidensa kanssa ansaita vakaa automaatiopaketti.
Vuosien varrella olen havainnut, että monet yritykset yrittävät toteuttaa automatisointityötään, olen havainnut kirjallisia projekteja, jotka on heitetty pois, kehyksiä vaihdettu ja johtajat irtisanottu, koska he eivät toimittaneet luvattua tai asetettua tavoitetta.
Epäonnistumiseen on monia syitä, vaikka automaatio on pitkällä tähtäimellä järkevää, meidän on kuitenkin ymmärrettävä, että se on paljon vaikeampi kuin miltä näyttää.
Seuraavassa on muutamia syitä, joista sinun on tiedettävä, ennen kuin siirryt eteenpäin ja aloitat testausautomaatioprojektin rakentamisen:
Analysoi ja kysy kysymyksiä: Testiautomaatio-työ on työ, kuten mikä tahansa muu sovellusprojekti, ja sitä tulisi kohdella samalla tavalla; Kuinka käsittelet ohjelmistoprojektin suunnittelua? Anna tämän idean ohjata sinua ajatellessasi Test Automation -projektisi toteuttamista. Kenen valitsisit työhön? Kuka käyttää tuotettua tuotetta? Mikä kieli tai kehys sopii parhaiten työhön? Ymmärrätkö haasteista ja niiden ohjeista ja kurkistatko? Säveltäisitkö sellaisen arkkitehtuurin, josta et tiedä mitään, vai soittaisitko neuvonantajaan neuvomaan muutamalla ajatuksella?
Kaikki nämä kysymykset ovat yksinkertaisesti tämän jäävuoren huippu siitä, mitä sinun pitäisi kysyä itseltäsi, ennen kuin kirjoitat yhden koodirivin tai edes testitilanteen.
Riittämätön taitosarja: Anna minun kysyä teiltä kysymys. Sallitko huonomman tai kokematon ohjelmoijan, jonkun, joka ei ymmärrä, miten säveltää hyvä puhdas haettava koodi - tyylitä sovelluksesi muotoilu ja kirjoita se tyhjästä? Mielestäni vastaus on ei. Joten miksi niin monet yritykset ajattelevat, että joku Evaluation Automation -infrastruktuuri voisi toteuttaa laadun ilman kokemusta ja taitoja? Jos omistautuneella henkilökunnalla ei ole kokemusta ja tietoa etkä aio palkata jotakuta, sinun tulee miettiä koodittomien automaatiotyökalujen käyttöä.
Epärealistiset odotukset / lähestymistapa: Jaan sen kahteen osaan. Ensimmäinen on virheellinen käsitys testausautomaation ROI: sta (investoinnin tuotto) ja toinen osa on epärealistisia odotuksia per aikakehys. On olemassa yhtä hyvä työ kuin sinä teet, etkä voi odottaa jotain tuottamatta arvoa tuottamatta aikaa. Olen puhunut laadunvarmistusinsinöörin kanssa, joka kertoi saaneensa kuusi tuntia viikossa säveltämään infrastruktuurin. Mitä sinun pitäisi odottaa hänen saavuttavan 6 tuntia?
Tämän työn tekemiseksi sinun on tiedusteltava:
- Mitkä ovat tavoitteet, jotka haluat saavuttaa yhdessä testausautomaation kanssa?
- Mitä pidettäisiin fantastisena arvona ponnisteluille / ajalle?
- Mitkä ovat saavutuksen kriteerit?
- Kuinka paljon aikaa / rahaa olet valmis käyttämään, jotta se tapahtuu?
Automaatio ei ole "Käynnistä ja unohda" -tehtävä. Haluat ymmärtää, että se on jatkuva prosessi, joka vaatii ylläpitoa, ryhmätyötä ja etenemistä.
Minun on tunnustettava, että valitettavasti sen perusteella, mitä olen nähnyt, jotkut yritykset kokevat QA-insinöörille salaisen työn tarjoamisen vain keinona säilyttää työntekijä tai lisätä " maustetta " hänen viikkorutiiniinsa. Älä ymmärrä minua väärin, en sano, että meidän ei pitäisi säästää työntekijöitämme tai antaa heille aikaa oppia ja edetä, sanon vain, että sen tulisi olla yhdenmukainen odotusten kanssa, jotka ovat realistisia ja läpinäkyviä työntekijää kohtaan, itse .
Riittämätön suunnittelu: Upea automaatioprojekti on aloitettava korkean tason suunnitelmalla ja suunnitelmalla, josta kehittyy kattava tekninen tyyli. Jopa "Yksi koko sopii kaikille" -strategia voi olla katastrofaalinen menestyksellesi. Se, mikä toimi erinomaisesti yhdellä yrityksellä, ei välttämättä tarkoita, että se tekisi työn puolestasi. Tämä ilmoitus voi olla totta instrumentin valinnasta. Aina, kun sinun ei todellakaan tarvitse käyttää kyseistä tekniikkaa, se nousee ylös. Tämä on erittäin tärkeää huomata. Siellä on suuri määrä avoimen lähdekoodin ja kaupallisia työkaluja, jotka voivat tuottaa hyvää vastinetta rahalle ja ottamatta edes huomioon vaihtoehtoja ja näiden työkalujen tarjoamia etuja / vaihtoehtoja. Valitse työkalu, joka vastaa tarpeitasi. Tässä ovat kaksi senttiäni - on paljon parempi maksaa ratkaisusta kuin tuhlata paljon kertoja (Se tulee olemaan huomattavasti kalliimpi kuin ohjelman kustannuslappu).
Nyt, kun keskustelemme edelleen suunnittelumme suunnittelusta, meidän on mietittävä kaikkialla olevaa teknistä arkkitehtuuriamme ja liiketoimintavaatimuksiamme. Tässä on vain joitain näkökohtia, jotka sinun tulisi ottaa huomioon:
- Kuvittele työpaikat, moduulit, liiketoimintavirrat, joita ihmiset tutkivat?
- Mikä on suunniteltu toteutusvaihe? (Sanity, regressio, CI / CD-paketti?)
- Mitkä ovat tärkeimmät jaetut / yhteiset / toistuvat virrat / toiminnot?
- Kuinka suunnitellaan jokainen testi lyhyelle itsenäiselle esineelle? (SetUp ja TearDown, riippuvuus ulkopuolisista tiedoista luotujen arviointitietojen sijaan, mitä on suoritettava ennen jokaista testiä, sarja luokka?)
- Kuinka estämme yhden arvioinnin "rikkomasta" toista, jos ne suoritetaan samanaikaisesti?
- Kuinka voimme luoda hyvän skaalautuvan, puhtaan ja sopivan ilmapiirin? (Mock-palvelimet, tietokantatapaukset, siivouskomentosarja, selainasetukset, ruudukko- / palvelinmääritykset, asennus ja uudelleenjärjestäminen, virtuaalinen ympäristö tai telakointiasiat
- Mitä rakentaa työkaluja, jos käytämme?
- Kuinka riippuvuuttamme voitaisiin hallita?
- Missä projektimme varastoidaan?
- Kuinka monta insinööriä työskentelee projektissa ja miten varianttien hallintaa hallitaan?
- Mitkä CI-työkalut ovat parhaita suorittamaan rakennuksemme?
- Aiotko toteuttaa CI / CD-työnkulun?
- Missä suoritat testisi ja resursseja, joita voit käyttää oman toteutusalustasi suunnittelussa? (Onko sinulla varoja pilviratkaisulupien ostamiseen? Onko sinulla työkaluja tai tukea oman Selenium Server -infrastruktuurin luomiseen?)
- Millaiset testit ovat pian automaattisia? (API, Visual Concepts, palvelinprosessit, verkko- / käyttöliittymien automatisointi, mobiili - Android / IOS).
- Onko olemassa suuria tietokokoelmia, pitkiä virtauksia, monimutkaisia prosesseja, integraatioita, jotka edellyttävät lisäarviointia?
- Mitä meidän pitäisi testata graafisen käyttöliittymän kautta ja mikä voisi olla turvallisempaa tarkistaa API: n kautta?
- Mitä lokeja, raportointimekanismeja, käsittelijöitä ja kuuntelijoita meidän on toteutettava, jotta perussyiden arviointi ja virheenkorjaus olisi yksinkertaisempaa? (Mikä on yhden tunnin automaatiopaketti, jos omistat päivän ymmärtämisen lopputuloksesta?)
- Mitä mittareita / raporttia / lähtöä ajojen tulisi tarjota?
- Mitä integraatioita todella haluamme? (Raportointiohjelmat, ALM-työkalut, Vikaseurannat, Arvioinnin hallintaohjelmat).
- Kuka voi luoda infrastruktuurin ja kenen on tarkoitus toteuttaa testit? (Voiko molempien välillä olla jopa haara?)
- Kenen on tarjottava automaatioinsinööreille liiketoimintavirrat / testitapaukset / liiketoimintalogiikan, jonka oletetaan olevan automaattinen?
- Onko tulevaisuuden tavoitteiden määrittämiseksi määritelty POC (Proof of concept) -vaiheet?
Se on vain joitain kysymyksiä pähkinänkuoressa, ja mitä sinun pitäisi ottaa tästä on se
Sopiva työkaluvaihtoehto, ylivoimainen suunnittelu / suunnittelu todennäköisesti tuottaa eron epäonnistumisen ja onnistumisen välillä.
Kaikkien automatisointi : Tärkeä huomioitava seikka on, ettei se, mikä voi olla tai on oltava automaattista. Toisinaan käsitys tai väärät hallintopäätökset automatisoimme kaiken, mikä tulee testaajan päähän, tai muuntelemme sokeasti sokeasti komentosarjoja. Ensinnäkin kaikki arvioinnit eivät ole sopivia automatisointiin. Toiseksi, itse testitapaukset eivät ole hyväksyttäviä työhön. Tämä loppuu kestämättömään automaattisten testien joukkoon, jota on mahdotonta pitää, ja valitettavasti suurin osa tapauksista johtaa merkittävään suureen osaan kirjallista työtä. Automaatiolla ei ole mitään lisäarvoa, jos yritykselläsi ei ole varoja ylläpitää automaatioryhmiä kymmeniätuhansia testiesimerkkejä, jotka tarkistavat toisinaan samaa liiketoimintalogiikkaa.
Meidän on myös laadittava selkeä suunnitelma siitä, mitä jokaisen automaatiorakenteen on ylläpidettävä. Mitä regressiomme sisältää? Mitä sanotaan terveydeksi? Mikä on tarpeeksi turvallinen ja luotettava pääsemään CI / CD-putkistoon?
Test-Automation vaatii vankkaa suunnittelua, ymmärrystä, sitoutumista ja omistautumista tuottamaan asianmukaista arvoa.
Puute taitoja / asianmukaista opetusta, väärä työkaluvalinta, riittämättömät resurssit, riittävän valmistelun puute, epärealistinen ennakointi, mikä kaikki voi saada projektin epäonnistumaan.
Toivon, että tällä mietinnöllä on myönteinen vaikutus ja se auttaa muutamia teistä seuraamaan tuottavaa ajattelutapaa.