Pozdravljeni, Habr!
Imamo novo pomembno temo - kakovosten razvoj IT produktov. Pri HighLoad++ pogosto govorimo o tem, kako narediti zasedene storitve hitrimi, pri Frontend Conf pa govorimo o kul uporabniškem vmesniku, ki se ne upočasni. Redno imamo teme o testiranju, DevOpsConf pa o kombiniranju različnih procesov, vključno s testiranjem. Toda o tem, kaj lahko na splošno imenujemo kakovost in kako celovito delati na tem - ne.
Popravimo to do — razvijali bomo kulturo razmišljanja o kakovosti končnega izdelka za uporabnika na vsaki stopnji razvoja. Navada, da se ne osredotočate na svoje področje odgovornosti in ne povezujete kakovosti le s preizkuševalci.
Pod rezom se bomo pogovarjali z vodjo programskega odbora, vodjo testiranja pri Tinkoff.Business, ustvarjalcem rusko govoreče skupnosti QA Anastasia Aseeva-Nguyen o stanju QA industrije in poslanstvu nove konference.
- Nastia zdravo. Povejte nam prosim o sebi.
Анастасия: Vodim testiranje v banki, odgovoren sem za zelo veliko ekipo - nas je več kot 90 ljudi. Imamo pomembno poslovno področje, odgovorni smo za ekosistem za pravne osebe.
Študiral sem mehaniko in matematiko in sem sprva želel postati programer. Ko pa sem dobil zanimivo ponudbo, sem se odločil, da se preizkusim kot tester. Nenavadno se je izkazalo, da je to moj klic. Zdaj vidim vse svoje delo v tej industriji.
Sem vnet zagovornik discipline zagotavljanja kakovosti. Ni mi vseeno, kakšni izdelki nastajajo, kako kakovost obravnavajo v podjetju, v timu in načeloma v procesu razvoja.
To mi je očitno skupnost v tej smeri ni dovolj zrela, vsaj v Rusiji. Ne razumemo vedno, da zagotavljanje kakovosti ni le dejstvo testiranja skladnosti aplikacije z zahtevami. Rad bi spremenil to situacijo.
— Uporabljate besedi zagotavljanje kakovosti in testiranje. V očeh povprečnega človeka se ta dva izraza zelo pogosto prekrivata. Kako se razlikujejo, če se poglobite?
Anastazija: Nasprotno, niso nič drugačni. Testiranje je del discipline zagotavljanja kakovosti, je neposredna dejavnost – samo dejstvo, da nekaj testiram. Pravzaprav obstaja veliko vrst testiranja in različni ljudje so odgovorni za različne vrste testiranja. Toda v Rusiji, ko se je pojavil val zunanjih izvajalcev, ki podjetjem dobavljajo testerje, se je testiranje zmanjšalo na eno samo vrsto.
V večini primerov so omejeni le na funkcionalno testiranje: preverijo, ali je tisto, kar so kodirali razvijalci, skladno s specifikacijo in to je vse.
— Prosimo, povejte nam, katere druge discipline zagotavljanja kakovosti obstajajo? Kaj poleg testiranja še spada sem?
Анастасия: Zagotavljanje kakovosti je predvsem ustvarjanje kakovostnega izdelka. Se pravi, vprašamo se, katere kakovostne lastnosti naj ima naš izdelek. V skladu s tem, če to razumemo, lahko primerjamo, kdo vpliva na te atribute kakovosti. ni pomembno, razvijalec, vodja projekta ali produktni specialist je oseba, ki vpliva na razvoj produkta, njegov zaostanek in njegovo strategijo.
Preizkuševalec se bolj zaveda svoje vloge. Zaveda se, da njegova naloga ni samo preizkušanje skladnosti z zahtevami, ampak tudi preizkušanje zahtev, preizpraševanje formulacij, ki prihajajo od strokovnjaka za izdelke, in razkrivanje vseh implicitnih zahtev in pričakovanj naročnika. Ko strankam ponudimo novo funkcionalnost, moramo resnično izpolniti njihova pričakovanja in rešiti njihovo bolečino. Če pomislimo na vse atribute kakovosti, bo stranka zadovoljna in bo razumela, da podjetje, katerega izdelek uporablja, resnično skrbi za njegove interese in ne deluje po principu "samo izdati funkcijo".
— Zdi se, da je to, kar ste pravkar opisali, naloga strokovnjaka za izdelke. Tu načeloma ne gre za testiranje in ne za kakovost - na splošno gre za upravljanje izdelkov, kajne?
Анастасия: Vključno. Zagotavljanje kakovosti ni disciplina, za katero je odgovorna ena oseba. Zdaj je priljubljena smer testiranja, pristop, imenovan Agilno testiranje. Njegova definicija jasno pove, da gre za timski pristop k testiranju, ki vključuje določen nabor praks. Za izvedbo tega pristopa je odgovorna celotna ekipa, niti ni nujno, da je v ekipi preizkuševalec. Celotna ekipa je osredotočena na zagotavljanje vrednosti stranki in zagotavljanje, da vrednost izpolnjuje pričakovanja stranke.
— Izkazalo se je, da se kakovost križa s skoraj vsemi okoliškimi disciplinami in vsiljuje okvir vsemu?
Анастасия: Prav. Ko razmišljamo o tem, kako želimo ustvariti kakovosten izdelek, začnemo razmišljati o različnih lastnostih kakovosti. Na primer, kako preveriti, ali smo res naredili funkcijo, ki jo potrebuje naša stranka.
Tu nastopi ta vrsta testiranja: UAT (uporabniško sprejemljivo testiranje). Na žalost se v Rusiji redko uporablja, vendar je včasih prisoten v ekipah SCRUM kot predstavitev za končnega odjemalca. To je dokaj pogosta vrsta testiranja v tujih podjetjih. Preden funkcionalnost odpremo za vse naročnike, najprej naredimo UAT, torej povabimo končnega uporabnika, ki testira in takoj poda povratno informacijo - ali izdelek res izpolnjuje pričakovanja in rešuje bolečino. Šele po tem pride do skaliranja za vse druge odjemalce.
Se pravi, osredotočeni smo na posel, na končnega naročnika, a hkrati ne pozabite na tehnologijo. Kakovost izdelka je v veliki meri odvisna tudi od tehnologije. Če imamo slabo arhitekturo, ne bomo mogli hitro izdati funkcij in izpolniti pričakovanj strank. Pri poskusu spreminjanja velikosti je lahko veliko napak ali pa pri poskusu preoblikovanja lahko nekaj pokvarimo. Vse to bo vplivalo na zadovoljstvo strank.
S tega vidika bi morala biti arhitektura takšna, da lahko pišemo čisto kodo, ki nam bo omogočala hitro spreminjanje in se ne bo bati, da bomo vse pokvarili. Da se iteracije revizij ne raztezajo na več mesecev preprosto zato, ker imamo toliko zapuščine in moramo opraviti dolge faze testiranja.
— Skupno so že vključeni razvijalci, arhitekti, produktni znanstveniki, produktni vodje in sami preizkuševalci. Kdo je še vključen v proces zagotavljanja kakovosti?
Анастасия: Zdaj pa si predstavljajmo, da smo funkcijo že dostavili stranki. Očitno je treba spremljati kakovost izdelka, tudi ko je že v proizvodnji. Na tej stopnji se lahko pojavijo situacije z neočitnimi scenariji, tako imenovanimi hrošči.
Prvo vprašanje je, kako se spopasti s temi hrošči, potem ko smo izdelek že izdali? Kako se na primer odzovemo na stres? Stranka ne bo zelo zadovoljna, če bo nalaganje strani trajalo več kot 30 sekund.
Tukaj nastopi izkoriščanje ali, kot temu pravijo zdaj, DevOps. Pravzaprav so to ljudje, ki so odgovorni za delovanje izdelka, ko je že v proizvodnji. To vključuje različne vrste spremljanja. Obstaja celo podvrsta testiranja - testiranje v proizvodnji, ko si dovolimo, da nečesa ne testiramo pred uvedbo in to preizkusimo takoj v proizvodnji. To je niz ukrepov z vidika organizacije infrastrukture, ki vam omogočajo, da se hitro odzovete na incident, vplivate nanj in ga odpravite.
Pomembna je tudi infrastruktura. Pogosto pride do situacij, ko se med preizkusom ni mogoče prepričati, ali res imamo vse, kar bi radi dali naročniku. Uvedemo ga v proizvodnjo in začnemo loviti neočitne situacije. In vse zato, ker infrastruktura v testu ne ustreza infrastrukturi v proizvodnji. To vodi do nove vrste testiranja - testiranje infrastrukture. To so različne konfiguracije, nastavitve, selitev baz podatkov itd.
To postavlja vprašanje - morda mora ekipa uporabiti infrastrukturo kot kodo.
Menim, da infrastruktura neposredno vpliva na kakovost produkta.
Upam, da bo na konferenci poročilo z resničnim primerom. Pišite nam, če ste nam pripravljeni iz lastnih izkušenj povedati, kako infrastruktura kot koda vpliva na kakovost. Infrastruktura kot koda olajša preverjanje vseh nastavitev in testiranje stvari, ki sicer preprosto niso možne. Zato je v proces razvoja kakovostnega izdelka vključeno tudi delovanje.
— Kaj pa analitika in dokumentacija?
Анастасия: To bolj velja za poslovne sisteme. Ko govorimo o podjetju, takoj pomislimo na ljudi, kot so analitiki in sistemski analitiki. Včasih jih imenujejo tehnični pisci. Dobijo nalogo, da napišejo specifikacijo in jo izpolnjujejo na primer mesec dni.
Večkrat je bilo dokazano, da pisanje takšne dokumentacije vodi do zelo dolgih razvojnih iteracij in dolgih iteracij izpopolnjevanja, saj se med postopkom testiranja odkrijejo hrošči in začnejo se vračanja. Posledično je veliko zank, ki povečujejo stroške razvoja. Poleg tega lahko to povzroči ranljivosti. Zdi se, da smo napisali referenčno kodo, potem pa smo naredili spremembe, ki rušijo popolnoma premišljeno arhitekturo.
Končni rezultat je ne povsem kvaliteten izdelek, saj so se že pojavili popravki v arhitekturi, koda ponekod ni dovolj testirana, ker se roki iztekajo, vse hrošče je treba hitro zapreti. In vse zato, ker prvotna specifikacija ni upoštevala vseh točk, ki jih je treba izvesti.
Razvijalci niso škodljivci in ne pišejo namerno kode z napakami.
Če bi na začetku razmišljali o specifikaciji, ki bi zajemala vse potrebne točke, bi bilo vse implementirano točno tako, kot je treba. Ampak to je utopija.
Verjetno je nemogoče napisati popolno specifikacijo na 100 straneh. Zato treba razmišljati o alternativnih načinih pisanja dokumentacije, specifikacije, nastavitev nalog, ki bi nas približale temu, da bi razvijalec naredil točno to, kar je potrebno.
Tu pridejo na misel pristopi iz Agilea – uporabniške zgodbe s kriteriji sprejemljivosti. To je bolj uporabno za ekipe, ki se razvijajo v majhnih ponovitvah.
— Kaj pa testiranje uporabnosti, uporabnost izdelka, oblikovanje?
Анастасия: To je zelo pomembna točka, saj so v ekipi oblikovalci. Najpogosteje so oblikovalci uporabljeni kot storitev – bodisi s strani oblikovalskega oddelka bodisi s strani zunanjega projektanta. Pogosto pride do situacij, ko se zdi, da je oblikovalec poslušal produktnega strokovnjaka in naredil, kar je razumel. Ko pa začnemo iteracijo, se izkaže, da to, kar je bilo dejansko narejeno, ni tisto, kar je bilo pričakovano: oblikovalec je nekaj pozabil, ni popolnoma premislil o vedenju, ker ni v ekipi in ni v kontekstu ali sprednji strani -končni razvijalec ni popolnoma razumel njegove postavitve. Lahko traja več iteracij samo zato, ker obstaja težava z razvijalcem sprednjega dela, ki razume zasnovo.
Poleg tega obstaja še ena težava. Oblikovalski sistemi postajajo vse bolj priljubljeni. So na udaru, vendar koristi od njih niso povsem očitne.
Srečujem se z mnenjem, da oblikovalski sistemi po eni strani poenostavljajo razvoj, po drugi strani pa nalagajo veliko omejitev vmesniku.
Posledično ne izdelamo lastnosti, ki jo naročnik želi, ampak tisto, ki nam ustreza, saj že imamo določene kocke, iz katerih lahko to naredimo.
Mislim, da je to tema, ki si jo je vredno ogledati in se vprašati, ali s tem, ko poskušamo olajšati oblikovanje, dejansko rešujemo bolečo točko stranke.
— Obstaja presenetljivo veliko tem, povezanih z zagotavljanjem kakovosti. Ali obstaja v Rusiji konferenca, kjer bi lahko razpravljali o vseh?
Анастасия: Najstarejša konferenca o testiranju, ki bo letos potekala že 25. po vrsti, se imenuje SQA Days Quality Assurance Conference. Predvsem obravnava orodja in posebne pristope testiranja za funkcionalne preizkuševalce. Poročila na Dnevih SQA praviloma poglobljeno obravnavajo specifična področja iz področja odgovornosti samih preizkuševalcev, ne pa kompleksnih aktivnosti.
To zelo pomaga pri razumevanju različnih orodij in pristopov, kako testirati baze podatkov, API-je itd. A hkrati po eni strani ne motivira, da bi v ustvarjanje boljšega izdelka vključili več kot le testiranje. Po drugi strani pa preizkuševalci ne postanejo bolj vključeni v proces, da bi razmišljali o globalnem cilju izdelka in njegovi poslovni komponenti.
Vodim velik oddelek in opravim veliko intervjujev, ki resnično dajo občutek stanja industrije kot celote. Praviloma naši fantje delajo v podjetjih in imajo jasno področje odgovornosti. Kolegi, ki delajo v tujih projektih, se poslužujejo različnih vrst testiranj: sami lahko izvajajo obremenitveno testiranje, testiranje zmogljivosti in celo včasih varnostno testiranje, saj ekipi resnično pomagajo zagotoviti kakovost izdelka.
Rad bi, da tudi fantje v Rusiji začnejo razmišljati, da se industrija ne konča s funkcionalnim testiranjem.
— V ta namen organiziramo novo konferenco QualityConf, ki je posvečena kakovosti kot integralni disciplini. Povejte nam več o ideji, kaj je glavni cilj konference?
Анастасия: Želimo ustvariti skupnost ljudi, ki jih zanima izdelava kakovostnih izdelkov. Ponudite platformo, kjer lahko pridejo, poslušajo poročila in odidejo po konferenci s posebnim razumevanjem, kaj je treba spremeniti za izboljšanje kakovosti.
Dandanes pogosto slišim prošnjo svetovalnih podjetij, kaj storiti, ko pride do težav s testiranjem in kakovostjo. Ko začneš komunicirati z ekipami, vidiš, da ni problem v samih testerjih, ampak v tem, kako je proces strukturiran. Na primer, ko razvijalci verjamejo, da so odgovorni samo za pisanje kode, se njihova odgovornost konča točno v trenutku, ko nalogo predajo testiranju.
Vsi ne razmišljajo o dejstvu, da slabo napisana, nizkokakovostna koda s slabo arhitekturo grozi velikim težavam za projekt. Ne razmišljajo o ceni napak, da lahko napake, ki končajo v proizvodnji, povzročijo velike stroške za podjetje in ekipo. Ni kulture, da bi o tem razmišljali. Želim, da ga začnemo distribuirati na konferenci.
Razumem, da to ni inovacija. O ceni napake je že v prejšnjem stoletju pisal Edward Deming, avtor 14 načel kakovosti. Zagotavljanje kakovosti kot disciplina temelji na tej knjigi, a na žalost sodobni razvoj na to pozablja.
— Ali se nameravate dotakniti tem neposredno o testiranju in orodjih?
Анастасия: Priznam, da bodo poročila o orodjih. Obstajajo precej univerzalna orodja, s katerimi lahko podjetja in ekipe vplivajo na produkt.
Vsa poročila bo globalno združevalo eno skupno poslanstvo: občinstvu sporočiti, da smo s tem pristopom, orodjem, metodo, procesom, vrsto testiranja vplivali na kakovost izdelka in izboljšali življenje naročnika.
Vsekakor ne bomo imeli poročil o orodju zaradi orodja. Vsa poročila, vključena v program, bo povezoval skupni cilj.
— Koga bo zanimalo, o čem govorite, koga vidite kot goste konference?
Анастасия: Imeli bomo poročila za razvijalce, ki jim ni vseeno za usodo njihovega projekta, izdelka, sistema. Prav tako bo zanimivo za preizkuševalce in, se mi zdi, predvsem menedžerje. Z menedžerji mislim na ljudi, ki odločajo in lahko vplivajo tudi na usodo in razvoj izdelka, sistema, ekipe.
To so ljudje, ki se sprašujejo, kako izboljšati kakovost izdelka ali sistema. Na naši konferenci bodo spoznali različne nabore ukrepov in razumeli, kaj je z njimi zdaj narobe in kaj je treba spremeniti.
Mislim, da je glavno merilo razumeti, da je s kakovostjo nekaj narobe, in želeti na to vplivati. Verjetno ne bomo mogli doseči ljudi, ki mislijo, da bo to uspelo šele prvič.
— Ali menite, da je industrija kot celota zrela, da ne govori samo o testiranju, ampak tudi o kulturi kakovosti?
Анастасия: Mislim, da sem dozorel. Zdaj se veliko podjetij odmika od tradicionalnega pristopa Waterfall k Agile. Prisotna je osredotočenost na stranko, ljudje v ekipah res začnejo razmišljati o tem, kako ustvariti kakovosten izdelek. Tudi podjetniška podjetja se ponovno osredotočajo na izboljšanje kakovosti.
Glede na število prošenj, ki se pojavljajo v skupnosti, menim, da je čas. Seveda nisem prepričan, da bo to obsežna revolucija, vendar bi si želel, da se zgodi ta revolucija v zavesti.
- Dogovorjeno! Vcepili bomo kulturo in spremenili zavest.
Konferenca o kakovostnem razvoju IT produktov poteka v Moskvi 7. junija. Veste, katere faze sestavljajo visokokakovosten izdelek, imamo primere uspešnega boja proti hroščem v proizvodnji, v naši praksi smo preizkusili priljubljene metode - potrebujemo vaše izkušnje. njihovi prijave do 1. maja, programski odbor pa bo pomagal osredotočiti temo na splošno celovitost konference.
Poveži z , v katerem razpravljamo o vprašanjih kakovosti in konferenci, se naročite da ostanete na tekočem z novicami programa.
Vir: www.habr.com