Hei Habr!
Meillä on uusi tärkeä aihe - IT-tuotteiden laadukas kehitys. HighLoad++:ssa puhumme usein siitä, kuinka kiireisistä palveluista saadaan nopeita, ja Frontend Confissa puhumme siististä käyttöliittymästä, joka ei hidastu. Meillä on säännöllisesti aiheita testaamisesta ja DevOpsConfista eri prosessien yhdistämisestä, mukaan lukien testaus. Mutta siitä, mitä voidaan kutsua laaduksi yleensä ja kuinka käsitellä sitä kattavasti - ei.
Korjataan tämä — Kehitämme lopputuotteen laatua koskevaa ajattelukulttuuria käyttäjälle jokaisessa kehitysvaiheessa. Tapana olla keskittymättä vastuualueeseesi ja yhdistää laatu paitsi testaajiin.
Leikkauksen alla keskustelemme ohjelmakomitean johtajan, Tinkoff.Businessin testauspäällikön, venäjänkielisen laadunvarmistusyhteisön luojan kanssa Anastasia Aseeva-Nguyen QA-alan tilasta ja uuden konferenssin tehtävästä.
- Nastia hei. Kerro meille itsestäsi.
Anastasia: Hoidan testausta pankissa, olen vastuussa erittäin suuresta tiimistä - meitä on yli 90 henkilöä. Meillä on tärkeä liiketoimintalinja, olemme vastuussa juridisten henkilöiden ekosysteemistä.
Opiskelin mekaniikkaa ja matematiikkaa ja halusin aluksi ohjelmoijaksi. Mutta kun sain mielenkiintoisen tarjouksen, päätin kokeilla itseäni testaajana. Kummallista kyllä, tämä osoittautui kutsumukseni. Nyt näen kaiken työni tällä alalla.
Olen innokas laadunvarmistusalan kannattaja. En ole välinpitämätön sen suhteen, mitä tuotteita luodaan, miten laatua kohdellaan yrityksessä, tiimissä ja periaatteessa kehitysprosessissa.
Se on minulle selvää yhteisö tähän suuntaan ei ole tarpeeksi kypsä, ainakin Venäjällä. Emme aina ymmärrä, että laadunvarmistus ei ole vain hakemuksen vaatimustenmukaisuuden testaamista. Haluaisin muuttaa tämän tilanteen.
— Käytät sanoja laadunvarmistus ja testaus. Keskivertoihmisen silmissä nämä kaksi termiä menevät hyvin usein päällekkäin. Miten ne eroavat toisistaan, jos kaivaa syvälle?
Anastasia: Pikemminkin ne eivät eroa toisistaan. Testaus on osa laadunvarmistuksen kurinalaisuutta; se on suoraa toimintaa - se tosiasia, että testaan jotain. Testaustyyppejä on itse asiassa monenlaisia, ja erilaiset ihmiset ovat vastuussa erilaisista testauksista. Mutta kun täällä Venäjällä ilmestyi ulkoistajien aalto, jotka toimittavat testaajia yrityksille, testaus rajoittui yhteen tyyppiin.
Useimmissa tapauksissa ne rajoittuvat vain toiminnalliseen testaukseen: ne tarkistavat, että kehittäjien koodaama vastaa määritystä, ja siinä kaikki.
— Kerro meille, mitä muita laadunvarmistusaloja on olemassa? Mitä muuta tähän sisältyy testauksen lisäksi?
Anastasia: Laadunvarmistus on ennen kaikkea laadukkaan tuotteen luomista. Toisin sanoen kysymme itseltämme, mitä laatuominaisuuksia tuotteellamme tulisi olla. Vastaavasti, jos ymmärrämme tämän, voimme verrata, kuka vaikuttaa näihin laatuominaisuuksiin. Ei väliä, kehittäjä, projektipäällikkö tai tuoteasiantuntija on henkilö, joka vaikuttaa tuotteen kehitykseen, sen tilauskantaan ja strategiaan.
Testaaja tulee tietoisemmaksi roolistaan. Hän ymmärtää, että hänen tehtävänsä ei ole vain testata vaatimustenmukaisuutta, vaan myös testata vaatimuksia, kyseenalaistaa tuoteasiantuntijalta tulevat formulaatiot ja paljastaa kaikki asiakkaan implisiittiset vaatimukset ja odotukset. Kun toimitamme uusia toimintoja asiakkaallemme, meidän on todella täytettävä heidän odotuksensa ja ratkaistava heidän tuskansa. Jos ajattelemme kaikkia laadun ominaisuuksia, asiakas on tyytyväinen ja ymmärtää, että yritys, jonka tuotetta hän käyttää, todella välittää hänen eduistaan, eikä toimi periaatteella "vain vapauttaakseen ominaisuuden".
— Näyttää siltä, että juuri kuvailemasi on tuoteasiantuntijan tehtävä. Tässä ei periaatteessa ole kyse testauksesta eikä laadusta - se on yleensä tuotehallinnasta, eikö?
Anastasia: Mukaan lukien. Laadunvarmistus ei ole tieteenala, josta yksi tietty henkilö on vastuussa. Nyt testauksessa on suosittu suunta, lähestymistapa nimeltään Ketterä testaus. Hänen määritelmänsä sanoo selvästi, että tämä on tiimilähestymistapa testaukseen, joka sisältää tietyn joukon käytäntöjä. Koko tiimi on vastuussa tämän lähestymistavan toteuttamisesta, eikä tiimissä tarvitse edes olla testaajaa. Koko tiimi on keskittynyt tuottamaan arvoa asiakkaalle ja varmistamaan, että arvo vastaa asiakkaan odotuksia.
— Osoittautuu, että laatu risteää lähes kaikkien ympäröivien tieteenalojen kanssa ja asettaa puitteet kaikelle ympärillä?
Anastasia: Aivan. Kun ajattelemme, kuinka haluamme luoda laadukkaan tuotteen, alamme ajatella erilaisia laadun ominaisuuksia. Esimerkiksi kuinka tarkistaa, että olemme todella tehneet asiakkaamme tarvitseman ominaisuuden.
Tässä on tämäntyyppinen testaus: UAT (käyttäjien hyväksyntätestaus). Valitettavasti sitä harjoitetaan harvoin Venäjällä, mutta se on joskus läsnä SCRUM-tiimeissä demona loppuasiakkaalle. Tämä on melko yleinen testaustyyppi ulkomaisissa yrityksissä. Ennen toiminnallisuuden avaamista kaikille asiakkaille teemme ensin UAT:n eli kutsumme loppukäyttäjän, joka testaa ja antaa heti palautetta - vastaako tuote todella odotuksia ja ratkaiseeko kivun. Vasta tämän jälkeen skaalautuu kaikkiin muihin asiakkaisiin.
Toisin sanoen keskitymme liiketoimintaan, loppuasiakkaaseen, mutta samaan aikaan älä unohda tekniikkaa. Myös tuotteen laatu riippuu suuresti tekniikasta. Jos arkkitehtuurimme on huono, emme voi nopeasti julkaista ominaisuuksia ja vastata asiakkaiden odotuksiin. Voi olla paljon bugeja, kun yritämme skaalata, tai kun yritämme heijastaa, voimme rikkoa jotain. Kaikki tämä vaikuttaa asiakastyytyväisyyteen.
Tästä näkökulmasta arkkitehtuurin tulisi olla sellainen, että voimme kirjoittaa puhdasta koodia, jonka avulla voimme tehdä nopeasti muutoksia eikä pelätä, että rikomme kaiken. Jotta versioiden iteraatiot eivät kestäisi useita kuukausia yksinkertaisesti siksi, että meillä on niin paljon perintöä ja meidän on tehtävä pitkiä testausvaiheita.
— Kaiken kaikkiaan mukana ovat jo kehittäjät, arkkitehdit, tuotetutkijat, tuotepäälliköt ja itse testaajat. Ketkä muut ovat mukana laadunvarmistusprosessissa?
Anastasia: Oletetaan nyt, että olemme jo toimittaneet ominaisuuden asiakkaalle. On selvää, että tuotteen laatua on valvottava myös silloin, kun se on jo tuotannossa. Tässä vaiheessa voi ilmaantua tilanteita, joissa on epäselviä skenaarioita, niin kutsuttuja bugeja.
Ensimmäinen kysymys on, kuinka käsittelemme näitä vikoja, kun olemme jo julkaisseet tuotteen? Miten me esimerkiksi reagoimme stressiin? Asiakas ei ole kovin tyytyväinen, jos sivun latautuminen kestää yli 30 sekuntia.
Tässä tulee esiin hyväksikäyttö tai, kuten he sitä nykyään kutsuvat, DevOps. Itse asiassa nämä ihmiset ovat vastuussa tuotteen käytöstä, kun se on jo tuotannossa. Tämä sisältää erilaisia seurantatyyppejä. Testauksella on jopa alatyyppi - testaus tuotannossa, jolloin sallimme itsellemme olla testaamatta jotain ennen käyttöönottoa ja testaamme sitä välittömästi tuotannossa. Tämä on joukko infrastruktuurin järjestämisen näkökulmasta toimenpiteitä, joiden avulla voidaan nopeasti reagoida tapaukseen, vaikuttaa siihen ja korjata se.
Myös infrastruktuuri on tärkeä. Usein tulee tilanteita, jolloin testin aikana on mahdotonta varmistaa, että meillä on todella kaikki, mitä haluaisimme antaa asiakkaalle. Otamme sen käyttöön tuotantoon ja alamme havaita epäselviä tilanteita. Ja kaikki siksi, että testin infrastruktuuri ei vastaa tuotannossa olevaa infrastruktuuria. Tämä johtaa uudenlaiseen testaukseen - infrastruktuurin testaus. Nämä ovat erilaisia kokoonpanoja, asetuksia, tietokannan siirtoa jne.
Tämä herättää kysymyksen - ehkä tiimin täytyy käyttää infrastruktuuria koodina.
Uskon, että infrastruktuuri vaikuttaa suoraan tuotteen laatuun.
Toivon, että konferenssissa on raportti todellisesta tapauksesta. Kirjoita meille, jos olet valmis kertomaan meille omasta kokemuksestasi, kuinka infrastruktuuri koodina vaikuttaa laatuun. Infrastruktuuri koodina helpottaa kaikkien asetusten tarkistamista ja sellaisten asioiden testaamista, jotka muuten eivät yksinkertaisesti ole mahdollisia. Siksi toiminta on mukana myös laadukkaan tuotteen kehittämisessä.
— Entä analytiikka ja dokumentointi?
Anastasia: Tämä koskee enemmän yritysjärjestelmiä. Kun puhumme yrityksestä, mieleen tulevat välittömästi ihmiset, kuten analyytikot ja järjestelmäanalyytikot. Heitä kutsutaan joskus teknisiksi kirjoittajiksi. He saavat tehtävän kirjoittaa spesifikaatio ja suorittaa sitä esimerkiksi kuukauden ajan.
On toistuvasti todistettu, että tällaisen dokumentaation kirjoittaminen johtaa erittäin pitkiin kehitysiteraatioihin ja pitkiin jalostusiteraatioihin, koska testausprosessin aikana havaitaan vikoja ja palautukset alkavat. Tämän seurauksena on paljon silmukoita, jotka lisäävät kehityskustannuksia. Lisäksi tämä voi aiheuttaa haavoittuvuuksia. Näyttää siltä, että olemme kirjoittaneet viitekoodin, mutta sitten teimme muutoksia, jotka rikkovat täydellisesti harkitun arkkitehtuurin.
Lopputuloksena ei ole täysin laadukas tuote, koska arkkitehtuuriin on jo ilmestynyt korjauksia, koodia ei paikoin ole riittävästi katettu testeillä, koska aikarajat ovat loppumassa, kaikki bugit pitää sulkea nopeasti. Ja kaikki siksi, että alkuperäisessä eritelmässä ei otettu huomioon kaikkia toteutettavia kohtia.
Kehittäjät eivät ole tuholaisia eivätkä kirjoita virheellistä koodia tarkoituksella.
Jos olisimme alunperin miettineet erittelyä, joka olisi kattanut kaikki tarvittavat kohdat, niin kaikki olisi toteutettu juuri tarpeen mukaan. Mutta tämä on utopiaa.
On luultavasti mahdotonta kirjoittaa täydellistä 100-sivuista eritelmää. Siksi täytyy miettiä vaihtoehtoisia tapoja kirjoittaa dokumentaatio, määritykset, tehtävien asettaminen, jotka vievät meidät lähemmäksi sen varmistamista, että kehittäjä tekee juuri sen, mitä tarvitaan.
Tässä tulevat mieleen Agilen lähestymistavat - käyttäjätarinat hyväksymiskriteereillä. Tämä soveltuu paremmin ryhmiin, jotka kehittävät pieniä iteraatioita.
— Entä käytettävyystestaus, tuotteen käytettävyys, suunnittelu?
Anastasia: Tämä on erittäin tärkeä kohta, koska tiimissä on suunnittelijoita. Useimmiten suunnittelijoita käytetään palveluna - joko suunnitteluosaston tai ulkoistetun suunnittelijan toimesta. Usein on tilanteita, joissa näyttää siltä, että suunnittelija kuunteli tuoteasiantuntijaa ja teki sen, mitä hän ymmärsi. Mutta kun aloitamme iteroinnin, käy ilmi, että se mitä todellisuudessa tehtiin, ei ollut sitä, mitä odotettiin: suunnittelija unohti jotain, ei ajatellut käyttäytymistä täysin, koska hän ei ole tiimissä eikä kontekstissa tai etupuolella -lopun kehittäjä ei täysin ymmärtänyt sen asettelua. Se voi kestää useita iteraatioita vain siksi, että käyttöliittymän kehittäjällä on ongelma suunnittelun ymmärtämisessä.
Lisäksi on vielä yksi ongelma. Suunnittelujärjestelmät ovat nyt saamassa suosiota. Ne ovat hypeissä, mutta niiden hyödyt eivät ole täysin ilmeisiä.
Olen törmännyt siihen käsitykseen, että suunnittelujärjestelmät toisaalta yksinkertaistavat kehitystä, mutta toisaalta ne asettavat paljon rajoituksia käyttöliittymälle.
Lopputuloksena emme tee asiakkaan haluamaa ominaisuutta, vaan sellaisen, joka on meille sopiva, koska meillä on jo tiettyjä kuutioita, joista voimme tehdä sen.
Mielestäni tämä on aihe, johon kannattaa tutustua ja pohtia, onko suunnittelun helpottamiseksi todellakin ratkaiseva asia asiakkaan kipupisteeseen.
— Laadunvarmistukseen liittyviä aiheita on yllättävän paljon. Onko Venäjällä konferenssia, jossa niistä kaikista voidaan keskustella?
Anastasia: Siellä on vanhin testauskonferenssi, joka järjestetään tänä vuonna 25. kerran ja jonka nimi on SQA Days Quality Assurance Conference. Siinä käsitellään pääasiassa työkaluja ja erityisiä testausmenetelmiä toiminnallisille testaajille. Pääsääntöisesti SQA Daysin raporteissa tarkastellaan syvällisesti tiettyjä alueita testaajien itsensä vastuulla, mutta ei monimutkaisia toimintoja.
Tämä auttaa paljon ymmärtämään erilaisia työkaluja ja lähestymistapoja, kuinka testata tietokantoja, API-liittymiä jne. Mutta toisaalta se ei toisaalta motivoi osallistumaan paremman tuotteen luomiseen muuta kuin vain testaamista. Toisaalta testaajat eivät lähde enemmän mukaan prosessiin pohtimaan tuotteen ja sen liiketoimintakomponentin globaalia tavoitetta.
Vedän suurta osastoa ja teen paljon haastatteluja, jotka todella antavat käsityksen alan tilanteesta kokonaisuudessaan. Kaverimme työskentelevät pääsääntöisesti yrityksissä, ja heillä on selkeä vastuualue. Ulkomaisissa projekteissa työskentelevät kollegat käyttävät erilaisia testauksia: he voivat itse tehdä kuormitustestausta, suorituskykytestausta ja joskus jopa tietoturvatestausta, koska ne todella auttavat tiimiä varmistamaan tuotteen laadun.
Haluaisin, että myös venäläiset pojat alkaisivat ajatella, että toimiala ei pääty toiminnalliseen testaukseen.
— Tätä tarkoitusta varten järjestämme uuden konferenssin, QualityConf, joka on omistettu laadulle kiinteänä tieteenalana. Kerro meille lisää ideasta, mikä on konferenssin päätavoite?
Anastasia: Haluamme luoda laadukkaiden tuotteiden valmistamisesta kiinnostuneiden ihmisten yhteisön. Tarjoa foorumi, jonne he voivat tulla, kuunnella raportteja ja lähteä konferenssin jälkeen ymmärtäen, mitä on muutettava laadun parantamiseksi.
Nykyään kuulen usein konsultilta pyynnön siitä, mitä tehdä, kun testauksessa ja laadussa on ongelmia. Kun aloitat kommunikoinnin tiimien kanssa, huomaat, että ongelma ei ole itse testaajissa, vaan prosessin rakenteessa. Esimerkiksi kun kehittäjät uskovat olevansa vastuussa vain koodin kirjoittamisesta, heidän vastuunsa päättyy juuri sillä hetkellä, kun he luovuttavat tehtävän testattavaksi.
Kaikki eivät ajattele sitä, että huonosti kirjoitettu, huonolaatuinen koodi huonolla arkkitehtuurilla uhkaa suuria ongelmia projektille. He eivät ajattele virheiden kustannuksia, että tuotantoon päätyvät bugit voivat aiheuttaa suuria kustannuksia yritykselle ja tiimille. Ei ole kulttuuria ajatella tätä. Haluan, että alamme jakaa sitä konferenssissa.
Ymmärrän, että tämä ei ole innovaatio. Edward Deming, 14 laatuperiaatteen kirjoittaja, kirjoitti virheen hinnasta jo viime vuosisadalla. Laadunvarmistus tieteenalana perustuu tähän kirjaan, mutta valitettavasti nykyaikainen kehitys unohtaa sen.
— Aiotteko koskea suoraan testaukseen ja työkaluihin liittyviin aiheisiin?
Anastasia: Myönnän, että työkaluista tulee raportteja. On olemassa varsin universaaleja työkaluja, joilla yritykset ja tiimit voivat vaikuttaa tuotteeseen.
Kaikki raportit tulee maailmanlaajuisesti yhdistämään yksi yhteinen missio: kertoa yleisölle, että tämän lähestymistavan, työkalun, menetelmän, prosessin, testaustyypin avulla olemme vaikuttaneet tuotteen laatuun ja parantaneet asiakkaan elämää.
Meillä ei todellakaan tule olemaan raportteja työkalusta työkalun vuoksi. Kaikkia ohjelmaan sisältyviä raportteja yhdistää yhteinen tavoite.
— Ketä kiinnostaa se, mistä puhut, keitä näet konferenssin vieraina?
Anastasia: Meillä on raportteja kehittäjille, jotka välittävät projektinsa, tuotteensa tai järjestelmänsä kohtalosta. Samoin se kiinnostaa testaajia ja mielestäni erityisesti johtajia. Esimiehillä tarkoitan ihmisiä, jotka tekevät päätöksiä ja voivat vaikuttaa myös tuotteen, järjestelmän, tiimin kohtaloon ja kehitykseen.
Nämä ovat ihmisiä, jotka ihmettelevät, kuinka tuotteen tai järjestelmän laatua voidaan parantaa. Konferenssissamme he oppivat erilaisista toimenpidekokonaisuuksista ja ymmärtävät, mikä heissä nyt on vialla ja mitä pitää muuttaa.
Mielestäni tärkein kriteeri on ymmärtää, että laadussa on jotain vialla, ja halu vaikuttaa siihen. Emme todennäköisesti pysty tavoittamaan ihmisiä, jotka luulevat, että tämä onnistuu vain ensimmäistä kertaa.
— Onko koko toimiala mielestänne kypsä puhumaan paitsi testauksesta myös laatukulttuurista?
Anastasia: Luulen, että olen kypsynyt. Nyt monet yritykset ovat siirtymässä perinteisestä Waterfall-lähestymistavasta kohti ketterää. Siellä on asiakaslähtöisyys, ihmiset tiimeissä alkavat todella miettiä, kuinka luoda laadukas tuote. Jopa yritysyritykset keskittyvät uudelleen laadun parantamiseen.
Yhteisössä esiintyvien pyyntöjen lukumäärän perusteella uskon, että nyt on aika. En tietenkään ole varma, että tämä tulee olemaan laajamittainen vallankumous, mutta haluaisin tämän tietoisuuden vallankumouksen tapahtuvan.
- Samaa mieltä! Istutamme kulttuuria ja muutamme tietoisuutta.
Konferenssi IT-tuotteiden laadukkaasta kehittämisestä tapahtuu Moskovassa 7. Tiedät, mistä vaiheista muodostuu korkealaatuinen tuote, meillä on tapauksia, joissa on onnistuttu torjumaan bugeja tuotannossa, olemme testanneet suosittuja menetelmiä käytännössämme - tarvitsemme kokemustasi. niiden hakemukset ennen toukokuun 1. päivää, ja ohjelmakomitea auttaa keskittymään teemaan konferenssin yleisen eheyden takaamiseksi.
Yhdistää , jossa keskustelemme laatuasioista ja konferenssista, tilaa pysyäksesi ajan tasalla ohjelmauutisista.
Lähde: will.com