Bok, Habr!
Imamo novu važnu temu – kvalitetnu izradu IT proizvoda. Često govorimo na HighLoad++ o tome kako učiniti opterećene servise bržima, a na Frontend Conf o izvrsnim korisničkim sučeljima koja ne usporavaju. Redovito imamo teme o testiranju, a DevOpsConf se bavi integracijom različitih procesa, uključujući testiranje. Međutim, o tome što se može nazvati kvalitetom u cjelini i kako na njemu sveobuhvatno raditi – ne razgovaramo.
Ispravimo to na – razvijat ćemo kulturu razmišljanja o kvaliteti konačnog proizvoda za korisnika u svakoj fazi razvoja. Naviknuti se ne fiksirati na svoju zonu odgovornosti i povezati kvalitetu ne samo s testerima.
U nastavku ćemo razgovarati s predsjednicom programskog odbora, voditeljicom testiranja u Tinkoff.Biznisu, osnivačicom ruskog QA zajedništva Anastasijom Aseevom-Nguen o stanju industrije QA i misiji nove konferencije.
– Nastja, zdravo. Ispričaj nam malo o sebi.
Anastasija: Vodim testiranje u banci, odgovaram za vrlo veliku ekipu – nas je više od 90 osoba. Imamo važnu poslovnu liniju, odgovorni smo za ekosustav za pravne osobe.
Studirala sam na matematičkom fakultetu i prvotno sam htjela postati programer. No kada se pojavila zanimljiva ponuda, odlučila sam se okušati u ulozi testera. Kako god zvučalo čudno, to se pokazalo mojim pozivom. Sada cijelu svoju karijeru vidim upravo u ovoj industriji.
Strastvena sam zagovornica discipline Quality Assurance. Nije mi svejedno koji se proizvodi stvaraju, kako se u tvrtki, timovima i općenito u procesu razvoja odnose prema kvaliteti.
Za mene je očito da zajednica u ovom području nije dovoljno zrela, barem ne u Rusiji. Ne razumijemo uvijek da osiguranje kvalitete nije samo sam čin testiranja aplikacije na usklađenost s zahtjevima. Željela bih promijeniti tu situaciju.
– Ti koristiš izraze Quality Assurance i testiranje. U očima običnog čovjeka ta dva termina vrlo često se prepliću. Kako se razlikuju, ako se duboko iskopava?
Anastasija: Uglavnom se ne razlikuju. Testiranje je dio discipline osiguravanja kvalitete, to je neposredno djelovanje – sama činjenica da nešto testiram. U stvarnosti postoji jako mnogo vrsta testiranja, a različiti ljudi su odgovorni za različite vrste testiranja. Međutim, kod nas u Hrvatskoj, kada je došla val outsourcinga koji isporučuje testere u tvrtke, testiranje se svodilo na jedinstvenu vrstu.
U većini slučajeva ograničavaju se samo na funkcionalno testiranje: provjeravaju da li je ono što su programeri kodirali u skladu sa specifikacijom i to je sve.
– Molim te, reci mi, koje još discipline postoje u osiguravanju kvalitete? Što se još osim testiranja ovdje uključuje?
Anastasija: Osiguranje kvalitete, prije svega, odnosi se na stvaranje kvalitetnog proizvoda. Dakle, postavljamo pitanje, kakve atribute kvalitete naš proizvod treba imati. Stoga, ako to razumijemo, možemo identificirati tko utječe na te atribute kvalitete. Nije važno, programer, projekt menadžer ili produktolog – to je osoba koja utječe na razvoj proizvoda, na njegov backlog, na njegovu strategiju.
Tester bolje počinje shvaćati svoju ulogu. Shvaća da njegova zadaća nije samo testirati sukladnost zahtjevima, već i testirati zahtjeve, preispitivati formulacije koje dolaze od produktologa, otkrivati sve neizravne zahtjeve i očekivanja klijenta. Kada isporučujemo novu funkcionalnost našem klijentu, moramo zaista zadovoljiti njegova očekivanja i riješiti njegov problem. Ako razmišljamo o svim atributima kvalitete, klijent će biti zadovoljan i razumjet će da tvrtka čijim proizvodom se koristi stvarno brine o njegovim interesima, a ne radi po principu "samo da se izbaci nova funkcija".
– Čini se da je ono što si sada opisala, zadaća produktologa. To zapravo nije o testiranju i kvalitete – to su inficirano s product managementom, zar ne?
Anastasija: Uključujući to. Osiguranje kvalitete nije disciplina za koju je odgovorna jedna određena osoba. Sada postoji popularan pristup u testiranju koji se naziva Agile Testing. Njegova definicija jasno naglašava da je to timski pristup testiranju koji obuhvaća određeni skup praksi. Za realizaciju ovog pristupa odgovara cijeli tim, čak i nije nužno da u timu bude tester. Cijeli tim je usmjeren na to da pruži vrijednost klijentu i da ta vrijednost odgovara njegovim očekivanjima.
— Dakle, kvaliteta se prepliće gotovo sa svim okolnim disciplinama, postavljajući okvire za sve oko nas?
Anastasija: Točno. Kada razmišljamo o tome što želimo stvoriti kvalitetan proizvod, počinjemo razmišljati o različitim atributima kvalitete. Na primjer, kako provjeriti da smo doista stvorili funkcionalnost koja je potrebna našem klijentu.
Tu se javlja vrsta testiranja known as UAT (testiranje prihvaćanja korisnika). Nažalost, u Hrvatskoj se rijetko prakticira, ali ponekad se pojavljuje u SCRUM timovima kao demo za krajnjeg klijenta. U inozemnim kompanijama to je prilično uobičajen oblik testiranja. Prije nego što otvorimo funkcionalnost za sve klijente, prvo radimo UAT, to jest pozivamo krajnjeg korisnika koji provodi testiranje i odmah daje povratne informacije — da li proizvod ispunjava očekivanja i rješava problem. Tek nakon toga dolazi do skaliranja na sve ostale klijente.
Dakle, fokusiramo se na poslovanje, na krajnjeg klijenta, ali pritom ne zaboravljamo na tehnologiju. Od tehnologija također uvelike ovisi kvaliteta proizvoda. Ako imamo lošu arhitekturu, nećemo moći brzo isporučivati funkcionalnosti i ispunjavati očekivanja klijenta. Mogu biti mnoge greške pri pokušaju skaliranja, ili možemo nešto slomiti prilikom refaktoringa. Sve to će utjecati na zadovoljstvo klijenta.
S te točke gledišta, arhitektura bi trebala biti takva da možemo pisati čist kod koji će omogućiti brzo uvođenje promjena i ne bojati se da ćemo sve srušiti. Da iteracije dorade ne trajaju nekoliko mjeseci samo zato što imamo previše naslijeđa i trebamo provoditi dugotrajne faze testiranja.
— Dakle, već su uključeni programeri, arhitekti, produkt menadžeri, sami testeri. Tko još sudjeluje u procesu osiguravanja kvalitete?
Anastasija: Sada zamislimo da smo već isporučili funkcionalnost klijentu. Očito je da je potrebno pratiti kvalitetu proizvoda, čak i kada je već u produkciji. U ovoj fazi mogu se pojaviti situacije s nejasnim scenarijima, takozvani bugovi.
Prvo pitanje je – kako radimo s tim bugovima nakon što je proizvod već objavljen? Kako reagiramo na opterećenje? Klijent neće biti previše zadovoljan ako se stranica učitava duže od 30 sekundi.
Tu uglavnom ulaze operacije ili, kako se sada nazivaju, DevOps. U stvari, to su ljudi koji su odgovorni za operacije proizvoda kada je on već na produkciji. Ovo uključuje različite tipove monitoringa. Postoji čak i podvrsta testiranja – testiranje na produkciji, kada si dopustimo da nešto ne testiramo prije objave i odmah to testiramo na produkciji. Ovo je niz aktivnosti s aspekta organizacije infrastrukture, koje omogućuju brzo reagiranje na incident, njegov utjecaj i ispravku.
Infrastruktura je također važna. Često se javljaju situacije kada tijekom testiranja nije moguće osigurati da imamo stvarno sve što bismo željeli dati klijentu. Objavljujemo na produkciji – i počinjemo hvatanje nejasnih situacija. A sve zato što infrastruktura u testiranju ne odgovara infrastrukturi na produkciji. Odavde proizlazi nova vrsta testiranja – testiranje infrastrukture. To su različite konfiguracije, postavke, migracije baza podataka itd.
Odavde se pojavljuje pitanje – možda bi tim trebao koristiti infrastrukturu kao kod.
Vjerujem da infrastruktura izravno utječe na kvalitetu proizvoda.
Nadam se da će na konferenciji biti prezentacija s istaknutim primjerom. Javite nam se ako ste spremni podijeliti svoje iskustvo o tome kako infrastruktura kao kod utječe na kvalitetu. Infrastruktura kao kod omogućuje lakšu provjeru svih postavki i testiranje onoga što inače jednostavno ne bi bilo moguće. Stoga se u proces razvoja kvalitetnog proizvoda uključuje i operacije.
— A što je s analizom i dokumentacijom?
Anastasija: To se više odnosi na enterprise sustave. Kada govorimo o enterprise-u, odmah na pamet padaju takve osobe kao što su analitičari i sistemski analitičari. Ponekad ih nazivamo tehničkim piscima. Oni dobiju zadatak za pisanje specifikacije i izvršavaju ga, na primjer, mjesec dana.
Višekratno je dokazano da pisanje takve dokumentacije dovodi do vrlo dugih razvojnih iteracija i dugotrajnih revizija, jer se tijekom testiranja otkrivaju greške što dovodi do povratka. Kao rezultat, pojavljuje se mnogo petlji koje povećavaju troškove razvoja. Osim toga, to može uvesti ranjivosti. Naizgled smo napisali referentni kod, ali smo zatim unijeli promjene koje narušavaju savršeno osmišljenu arhitekturu.
Na kraju dolazimo do nekvalitetnog proizvoda, jer su u arhitekturi već nastale zakrpe, kod nije dovoljno pokriven testovima na nekim mjestima jer vremenski rokovi pritišću, potrebno je brže riješiti sve greške. A sve zato što u izvornoj specifikaciji nisu uzeti u obzir svi aspekti koji trebaju biti implementirani.
Programeri nisu štetočine i ne pišu namjerno kod s greškama.
Da smo izvorno razmislili o specifikaciji koja bi obuhvatila sve potrebne aspekte, onda bi sve bilo implementirano kako treba. No, to je utopija.
Vjerojatno je nemoguće napisati savršenu specifikaciju od 100 stranica. Stoga moramo razmisliti o alternativnim načinima pisanja dokumentacije, specifikacije, postavljanja zadataka koji bi nas približili tome da programer radi upravo ono što je potrebno.
Tada nam padaju na pamet pristupi iz Agile-a — korisničke priče s kriterijima prihvaćanja. Ovo je više primjenjivo za timove koji se razvijaju kroz manje iteracije.
— A što je s testiranjem uporabljivosti, jednostavnošću korištenja proizvoda, dizajnom?
Anastasija: To je vrlo važna stvar, jer u timu postoje dizajneri. Najčešće se dizajneri koriste kao servis — ili odjel dizajnera ili dizajner na outsourcingu. Često se javljaju situacije u kojima se čini da je dizajner slušao produktologa i učinio ono što je shvatio. No, kada krenemo u iteraciju, ispostavlja se da zapravo nije učinjeno ono što smo očekivali: dizajner je nešto zaboravio, nije do kraja razradio ponašanje, jer nije u timu i nije u kontekstu, ili frontend programer nije do kraja razumio njegov dizajn. Moguće je da će biti potrebno nekoliko iteracija samo zbog toga što postoji problem s razumijevanjem dizajna od strane frontend programera.
Postoji još jedan problem. Dizajnerske sisteme sada postaju sve popularnijim. Na vrhuncu su, ali korist od njih nije baš očigledna.
Srećem se s mišljenjem da dizajnerski sistemi, s jedne strane, olakšavaju razvoj, dok s druge strane nameću brojne ograničenja na interfejs.
U konačnici, ne radimo funkcionalnost koju klijent želi, već onu koja nam je zgodna, jer već imamo određene komponente od kojih je možemo napraviti.
Mislim da treba obratiti pažnju na ovu temu i razmisliti da li pokušajem pojednostavljenja rada na dizajnu zaista rešavamo klijentovu bol.
Postoji izuzetno mnogo tema vezanih za osiguranje kvaliteta. Da li u Rusiji postoji konferencija na kojoj se to može raspraviti?
AnastasijaPostoji najstarija konferencija o testiranju koja se ove godine održava po 25. put i zove se - Konferencija o osiguravanju kvaliteta SQA Days. Na njoj se prvenstveno raspravljaju alati i konkretni pristupi testiranju za funkcionalne testere. Kao pravilo, u izlaganjima na SQA Days duboko se razmatraju konkretne oblasti u domenu odgovornosti samih testera, ali ne i kompleksne aktivnosti.
To stvarno pomaže da se shvate različiti alati i pristupi, kao što su testiranje baza podataka, API-a itd. Međutim, s jedne strane, ne motiviše uključivanje u kreiranje kvalitetnijeg proizvoda ne samo kroz testiranje. A s druge strane, testeri ne postaju više uključeni u proces, kako bi razmišljali o globalnoj svrsi proizvoda i njegovoj poslovnoj komponenti.
Vodim veliki odeljak, vodeći mnogo intervjua, koji zapravo pomažu u predstavljanju stanja industrije u celini. Kao pravilo, naši ljudi rade u preduzećima i imaju jasnu odgovornost. Kolege koje rade na stranim projektima koriste različite vrste testiranja: sami mogu raditi opterećenjsko testiranje, testiranje performansi, pa čak i ponekad testiranje sigurnosti, jer zaista pomažu timu da obezbedi kvalitet proizvoda.
Voleo bih da i kod nas u Rusiji ljudi počnu razmišljati o tome da se industrija ne završava na funkcionalnom testiranju.
— Za to organiziramo novu konferenciju QualityConf, koja je posvećena kvaliteti kao cjelovitoj disciplini. Možeš li detaljnije objasniti koncept, koja je osnovna svrha konferencije?
Anastasija: Želimo stvoriti zajednicu ljudi koji su zainteresirani za izradu kvalitetnih proizvoda. Pružiti platformu na kojoj mogu doći, poslušati izvješća i nakon konferencije otići s konkretnim razumijevanjem što trebaju promijeniti kako bi poboljšali kvalitetu.
Često čujem zahtjev od konzultantskih firmi što učiniti kada postoje problemi s testiranjem i kvalitetom. Kada počneš razgovarati s timovima, vidiš da problem nije u samim testerima, već u tome kako je proces organiziran. Na primjer, kada programeri smatraju da su odgovorni samo za pisanje koda, njihova odgovornost prestaje točno u trenutku kada su zadatak predali na testiranje.
Nisu svi svjesni da loše napisani, nekvalitetni kod s lošom arhitekturom može izazvati velike probleme za projekt. Ne razmišljaju o troškovima grešaka, o tome da bagovi koji dospiju u produkciju mogu rezultirati velikim troškovima za kompaniju i tim. Nema kulture razmišljanja o ovome. Želim da tijekom konferencije počnemo širiti tu kulturu.
Razumijem da ovo nije inovacija. Edward Deming, autor 14 postulata kvalitete, pisao je o trošku greške još u prošlom stoljeću. Na ovoj knjizi se temelji Quality Assurance kao disciplina, ali, nažalost, moderna razvojna praksa to zaboravlja.
— Hoćete li se doticati tema koje se izravno odnose na testiranje i alate?
Anastasija: Pretpostavljam da će biti predavanja o alatima. Postoje dovoljno univerzalni alati koji mogu pomoći kompanijama i timovima da utiču na proizvod.
Sva predavanja će globalno biti povezana jednom zajedničkom misijom: prenijeti publici da smo uz pomoć ovog pristupa, alata, metode, procesa ili vrste testiranja utjecali na kvalitetu proizvoda i poboljšali život klijenta.
Sigurno nećemo imati predavanja o alatima radi alata. Sva predavanja koja će ući u program bit će povezana zajedničkim ciljem.
— Kome će biti zanimljivo to o čemu pričaš, koga vidiš kao goste konferencije?
Anastasija: Imamo rasprave za programere kojima nije svejedno sudbina njihovog projekta, proizvoda, sistema. Također će biti zanimljivo i testera, a čini mi se, posebno menadžerima. Pod menadžerima mislim na ljude koji donose odluke i mogu utjecati na sudbinu i razvoj proizvoda, sistema, tima uključujući.
To su ljudi koji se pitaju – kako povećati kvalitetu proizvoda, sistema. Na našoj konferenciji saznat će o raznim skupovima aktivnosti i moći će razumjeti što trenutno nije u redu, što treba promijeniti.
Mislim da je glavni kriterij razumjeti da s kvalitetom nešto nije u redu i željeti na to utjecati. Vjerovatno, prvi put neće biti lako doprijeti do ljudi koji misle da je sve u redu.
— Kako misliš, je li industrija u cjelini sazrela za razgovor ne samo o testiranju, već i o kulturi kvalitete?
Anastasija: Smatram da jest. Sada mnoge kompanije odmiču se od tradicionalnog Waterfall pristupa prema Agileu. Postoji orijentacija na klijenta, ljudi u timovima zaista počinju razmišljati kako stvoriti kvalitetan proizvod. Čak i u enterprise kompanijama događa se ponovno usmjeravanje na podizanje kvalitete.
Sudeći prema broju zahtjeva koji se javljaju u zajednici, mislim da je već došlo vrijeme. Naravno, nisam sigurna da će to biti velika revolucija, ali voljela bih da do tog preokreta u svijesti dođe.
— Dogovoreno! Radit ćemo na usvajanju kulture i preokretu svijesti.
Konferencija o kvalitetnoj izradi IT proizvoda održat će se u Moskvi 7. juna. Znate li iz kojih se faza sastoji kvalitetan proizvod, imamo primjere uspješne borbe protiv bugova na pro, na vlastitom iskustvu provjerili popularne metode — potrebna nam je vaša iskustva. svoje prijave do 1. maja, a Programski odbor pomoći će usmjeriti temu za cjelovitost konferencije.
Priključite se , u kojem raspravljamo o pitanjima kvalitete i konferenciji, prijavite se na , kako biste bili u toku s programskim vijestima.
Izvor: habr.com
