Hej Habr!
Imamo novu važnu temu - kvalitetan razvoj IT proizvoda. Na HighLoad++ često pričamo o tome kako učiniti zauzete usluge brzim, a na Frontend Conf-u govorimo o cool korisničkom interfejsu koji ne usporava. Redovno imamo teme o testiranju, a DevOpsConf o kombinovanju različitih procesa, uključujući testiranje. Ali o tome što se općenito može nazvati kvalitetom i kako sveobuhvatno raditi na tome - ne.
Hajde da ovo popravimo — razvijaćemo kulturu razmišljanja o kvaliteti finalnog proizvoda za korisnika u svakoj fazi razvoja. Navika da se ne fokusirate na područje vaše odgovornosti i da kvalitet povežete ne samo s testerima.
Ispod reza ćemo razgovarati sa šefom programskog komiteta, šefom testiranja u Tinkoff.Business, kreatorom QA zajednice na ruskom govornom području Anastasia Aseeva-Nguyen o stanju u QA industriji i misiji nove konferencije.
- Nastia zdravo. Recite nam nešto o sebi.
Anastasia: Upravljam testiranjem u banci, odgovoran sam za veoma veliki tim - imamo više od 90 ljudi. Imamo važnu poslovnu liniju, odgovorni smo za ekosistem za pravna lica.
Studirao sam mehaniku i matematiku i u početku sam želio postati programer. Ali kada sam dobio zanimljivu ponudu, odlučio sam da se okušam kao tester. Začudo, ispostavilo se da je ovo moj poziv. Sada vidim sav svoj rad u ovoj industriji.
Ja sam gorljivi pristaša discipline osiguranja kvaliteta. Nije mi ravnodušno kakvi proizvodi nastaju, kako se tretira kvalitet u kompaniji, u timu i, u principu, u procesu razvoja.
To mi je očigledno zajednica u ovom pravcu nije dovoljno zrela, barem u Rusiji. Ne razumijemo uvijek da osiguranje kvaliteta nije samo činjenica testiranja usklađenosti aplikacije sa zahtjevima. Voleo bih da promenim ovu situaciju.
— Koristite riječi Osiguranje kvaliteta i testiranje. U očima prosječne osobe, ova dva pojma se vrlo često preklapaju. Po čemu se razlikuju ako kopate duboko?
Anastazija: Naprotiv, ne razlikuju se. Testiranje je dio discipline osiguranja kvalitete, to je direktna aktivnost – sama činjenica da nešto testiram. Zapravo postoji mnogo vrsta testiranja, a za različite vrste testiranja odgovorni su različiti ljudi. Ali ovdje u Rusiji, kada se pojavio val vanjskih saradnika koji isporučuju testere kompanijama, testiranje je svedeno na jednu vrstu.
U većini slučajeva, ograničeni su samo na funkcionalno testiranje: provjeravaju da li je ono što su programeri kodirali u skladu sa specifikacijom i to je sve.
— Recite nam koje druge discipline za osiguranje kvaliteta postoje? Šta je još, osim testiranja, uključeno ovdje?
Anastasia: Osiguranje kvalitete je prije svega stvaranje kvalitetnog proizvoda. Odnosno, pitamo se koje atribute kvaliteta naš proizvod treba da ima. Shodno tome, ako ovo shvatimo, možemo uporediti ko utiče na ove atribute kvaliteta. nema veze, programer, menadžer projekta ili stručnjak za proizvode je osoba koja utječe na razvoj proizvoda, njegov zaostatak i njegovu strategiju.
Ispitivač postaje svesniji svoje uloge. On razumije da njegov zadatak nije samo da testira usklađenost sa zahtjevima, već i da testira zahtjeve, preispita formulacije koje dolaze od stručnjaka za proizvode i otkrije sve implicitne zahtjeve i očekivanja klijenta. Kada isporučimo novu funkcionalnost našim klijentima, moramo istinski ispuniti njihova očekivanja i riješiti njihovu bol. Ako razmislimo o svim atributima kvaliteta, klijent će biti zadovoljan i shvatiće da kompanija čiji proizvod koristi zaista brine o njegovim interesima, a ne radi po principu „samo da pustimo neku funkciju“.
— Čini se da je ovo što ste upravo opisali zadatak stručnjaka za proizvode. Ovdje se, u principu, ne radi o testiranju i ne o kvaliteti – općenito se radi o upravljanju proizvodima, zar ne?
Anastasia: Uključujući. Osiguranje kvaliteta nije disciplina za koju je odgovorna jedna određena osoba. Sada postoji popularan pravac u testiranju, pristup tzv Agilno testiranje. Njegova definicija jasno kaže da se radi o timskom pristupu testiranju, koji uključuje određeni skup praksi. Za implementaciju ovog pristupa odgovoran je cijeli tim, čak nije ni potrebno da u timu bude tester. Cijeli tim je fokusiran na isporuku vrijednosti kupcu i osiguravanje da vrijednost ispunjava očekivanja kupaca.
— Ispada da se kvalitet ukršta sa gotovo svim okolnim disciplinama, namećući okvir svemu oko sebe?
Anastasia: Tačno. Kada razmišljamo o tome kako želimo stvoriti kvalitetan proizvod, počinjemo razmišljati o različitim atributima kvalitete. Na primjer, kako provjeriti da li smo zaista napravili funkciju koja je potrebna našem klijentu.
Ovdje dolazi ova vrsta testiranja: UAT (testiranje prihvatljivosti korisnika). Nažalost, rijetko se praktikuje u Rusiji, ali je ponekad prisutan u SCRUM timovima kao demo za krajnjeg klijenta. Ovo je prilično čest tip testiranja u stranim kompanijama. Prije otvaranja funkcionalnosti svim klijentima, prvo radimo UAT, odnosno pozivamo krajnjeg korisnika koji testira i odmah daje povratnu informaciju – da li proizvod zaista ispunjava očekivanja i rješava bol. Tek nakon toga dolazi do skaliranja na sve ostale klijente.
Odnosno, fokusiramo se na posao, na krajnjeg klijenta, ali u isto vrijeme ne zaboravite na tehnologiju. Kvaliteta proizvoda također uvelike ovisi o tehnologiji. Ako imamo lošu arhitekturu, nećemo moći brzo objaviti karakteristike i ispuniti očekivanja kupaca. Može biti puno grešaka pri pokušaju skaliranja ili kada pokušavamo refaktorirati možemo nešto pokvariti. Sve ovo će uticati na zadovoljstvo kupaca.
Sa ove tačke gledišta, arhitektura treba da bude takva da možemo da napišemo čist kod koji će nam omogućiti da brzo izvršimo promene i da se ne plašimo da ćemo sve pokvariti. Tako da se revizijske iteracije ne protežu na nekoliko mjeseci samo zato što imamo toliko naslijeđa i moramo raditi duge faze testiranja.
— Ukupno su već uključeni programeri, arhitekte, naučnici za proizvode, menadžeri proizvoda i testeri. Ko je još uključen u proces osiguranja kvaliteta?
Anastasia: Sada zamislimo da smo tu funkciju već isporučili klijentu. Očigledno, kvalitet proizvoda treba pratiti čak i kada je već u proizvodnji. U ovoj fazi mogu se pojaviti situacije sa neočiglednim scenarijima, takozvanim bugovima.
Prvo pitanje je kako se nositi s ovim greškama nakon što smo već objavili proizvod? Kako, na primjer, reagiramo na stres? Klijent neće biti baš zadovoljan ako se stranici učita više od 30 sekundi.
Ovdje dolazi do izražaja eksploatacija ili, kako to sada zovu, DevOps. Zapravo, to su ljudi koji su odgovorni za rad sa proizvodom kada je već u proizvodnji. Ovo uključuje različite vrste praćenja. Postoji čak i podvrsta testiranja - testiranje u produkciji, kada sebi dozvolimo da ne testiramo nešto prije uvođenja i testiramo odmah u proizvodnji. Ovo je niz mjera sa stanovišta organizacije infrastrukture koje vam omogućavaju da brzo reagujete na incident, utičete na njega i ispravite ga.
Važna je i infrastruktura. Često se dešavaju situacije kada je tokom testa nemoguće osigurati da zaista imamo sve što bismo željeli dati klijentu. Uvodimo ga u proizvodnju i počinjemo hvatati neočigledne situacije. A sve zato što infrastruktura u testu ne odgovara infrastrukturi u proizvodnji. Ovo dovodi do nove vrste testiranja - testiranje infrastrukture. To su razne konfiguracije, postavke, migracija baze podataka itd.
Ovo postavlja pitanje - možda tim treba da koristi infrastrukturu kao kod.
Smatram da infrastruktura direktno utiče na kvalitet proizvoda.
Nadam se da će na konferenciji biti izvještaj sa pravim slučajem. Pišite nam ako ste spremni da nam iz sopstvenog iskustva kažete kako infrastruktura kao kod utiče na kvalitet. Infrastruktura kao kod olakšava provjeru svih postavki i testiranje stvari koje inače jednostavno nisu moguće. Stoga je i operacija uključena u proces razvoja kvalitetnog proizvoda.
— Šta je sa analitikom i dokumentacijom?
Anastasia: Ovo se više odnosi na sisteme preduzeća. Kada govorimo o preduzeću, ljudi poput analitičara i sistemskih analitičara odmah nam padaju na pamet. Ponekad se nazivaju tehničkim piscima. Dobiju zadatak da napišu specifikaciju i završe je, na primjer, mjesec dana.
Više puta je dokazano da pisanje takve dokumentacije dovodi do veoma dugih razvojnih iteracija i dugih iteracija usavršavanja, jer se tokom procesa testiranja identifikuju greške i počinje vraćanje. Kao rezultat toga, postoji mnogo petlji koje povećavaju troškove razvoja. Osim toga, ovo može dovesti do ranjivosti. Čini se da smo napisali referentni kod, ali onda smo napravili promjene koje razbijaju savršeno osmišljenu arhitekturu.
Krajnji rezultat je ne sasvim kvalitetan proizvod, jer su se zakrpe već pojavile u arhitekturi, kod na nekim mjestima nije dovoljno pokriven testovima, jer rokovi ističu, sve greške treba brzo zatvoriti. A sve zato što originalna specifikacija nije uzela u obzir sve točke koje je potrebno implementirati.
Programeri nisu štetočine i ne pišu namjerno kod s greškama.
Da smo u početku razmišljali o specifikaciji koja bi pokrila sve potrebne tačke, onda bi sve bilo implementirano tačno onako kako je potrebno. Ali ovo je utopija.
Verovatno je nemoguće napisati savršenu specifikaciju od 100 stranica. Zbog toga potrebno je razmisliti o alternativnim načinima pisanja dokumentacije, specifikacije, postavljanje zadataka koji bi nas približili osiguravanju da programer radi upravo ono što je potrebno.
Ovdje mi na pamet padaju pristupi iz Agile-a - korisničke priče s kriterijima prihvatljivosti. Ovo je više primjenjivo za timove koji se razvijaju u malim iteracijama.
— Što je s testiranjem upotrebljivosti, upotrebljivosti proizvoda, dizajnom?
Anastasia: Ovo je vrlo važna stvar, jer u timu su dizajneri. Najčešće se dizajneri koriste kao usluga - bilo od strane dizajnerskog odjela ili od strane dizajnera koji je angažiran na vanjskim izvršiteljima. Često postoje situacije u kojima se čini da je dizajner slušao stručnjaka za proizvode i učinio ono što je razumio. Ali kada započnemo iteraciju, ispostavilo se da ono što je zapravo urađeno nije ono što se očekivalo: dizajner je nešto zaboravio, nije do kraja promislio o ponašanju, jer nije u timu i nije u kontekstu, ili frontu -krajnji programer nije u potpunosti razumio njegov izgled. Može potrajati nekoliko iteracija samo zato što postoji problem s front-end programerom koji razumije dizajn.
Osim toga, postoji još jedan problem. Dizajn sistemi sada postaju sve popularniji. Oni su na popularnosti, ali koristi od njih nisu sasvim očigledne.
Nailazim na mišljenje da sistemi dizajna, s jedne strane, pojednostavljuju razvoj, ali s druge strane nameću mnoga ograničenja interfejsu.
Kao rezultat toga, ne pravimo onu funkciju koju klijent želi, već onu koja nam odgovara, jer već imamo određene kocke od kojih to možemo napraviti.
Mislim da je ovo tema koju vrijedi pogledati i zapitati se da li pokušavajući olakšati dizajn zapravo rješavamo bolnu točku klijenta.
— Postoji iznenađujući broj tema vezanih za osiguranje kvaliteta. Postoji li konferencija u Rusiji na kojoj se o svima može razgovarati?
Anastasia: Postoji najstarija konferencija o testiranju koja će se ove godine održati 25. put i zove se SQA Days Quality Assurance Conference. Uglavnom se raspravlja o alatima i specifičnim pristupima testiranju za funkcionalne testere. U pravilu, izvještaji na SQA Danima duboko ispituju specifične oblasti u području odgovornosti samih testera, ali ne i složene aktivnosti.
Ovo puno pomaže u razumijevanju različitih alata i pristupa, kako testirati baze podataka, API-je itd. Ali u isto vrijeme, s jedne strane, to ne motivira da se u stvaranje boljeg proizvoda uključi više od samog testiranja. S druge strane, testeri se ne uključuju više u proces razmišljanja o globalnom cilju proizvoda i njegove poslovne komponente.
Vodim veliki odjel i vodim mnogo intervjua koji zaista daju uvid u stanje industrije u cjelini. Naši momci po pravilu rade u preduzećima i imaju jasnu oblast odgovornosti. Kolege koji rade na stranim projektima koriste različite vrste testiranja: oni sami mogu raditi testiranje opterećenja, testiranje performansi, a ponekad i sigurnosno testiranje, jer zaista pomažu timu da osigura kvalitet proizvoda.
Voleo bih da i momci u Rusiji počnu da misle da se industrija ne završava funkcionalnim testiranjem.
— U tu svrhu organizujemo novu konferenciju QualityConf koja je posvećena kvalitetu kao integralnoj disciplini. Recite nam nešto više o ideji, koji je glavni cilj konferencije?
Anastasia: Želimo stvoriti zajednicu ljudi zainteresiranih za izradu kvalitetnih proizvoda. Ponudite platformu na kojoj mogu doći, saslušati izvještaje i otići nakon konferencije sa specifičnim razumijevanjem šta treba promijeniti da bi se poboljšao kvalitet.
Danas često čujem od konsultacija zahtjeve šta učiniti kada postoje problemi s testiranjem i kvalitetom. Kada počnete komunicirati s timovima, vidite da problem nije u samim testerima, već u tome kako je proces strukturiran. Na primjer, kada programeri vjeruju da su odgovorni samo za pisanje koda, njihova odgovornost prestaje tačno u trenutku kada predaju zadatak testiranju.
Ne razmišljaju svi o tome da loše napisan, nekvalitetan kod sa lošom arhitekturom prijeti velikim problemima za projekat. Ne razmišljaju o cijeni grešaka, da greške koje završe u proizvodnji mogu rezultirati velikim troškovima za kompaniju i tim. Nema kulture da se o ovome razmišlja. Želim da počnemo da ga distribuiramo na konferenciji.
Razumem da ovo nije inovacija.Edvard Deming, autor 14 principa kvaliteta, pisao je o ceni greške još u prošlom veku. Osiguranje kvaliteta kao disciplina zasnovano je na ovoj knjizi, ali, nažalost, savremeni razvoj to zaboravlja.
— Planirate li direktno dotaknuti teme o testiranju i alatima?
Anastasia: Priznajem da će biti izvještaja o alatima. Postoje prilično univerzalni alati pomoću kojih kompanije i timovi mogu utjecati na proizvod.
Sve izvještaje će globalno objediniti jedna zajednička misija: prenijeti publici da smo uz pomoć ovakvog pristupa, alata, metode, procesa, vrste testiranja utjecali na kvalitet proizvoda i poboljšali život klijenta.
Definitivno nećemo imati izvještaje o alatu radi alata. Svi izvještaji uključeni u program bit će ujedinjeni zajedničkim ciljem.
— Koga će zanimati ono o čemu pričate, koga vidite kao goste konferencije?
Anastasia: Imaćemo izveštaje za programere kojima je stalo do sudbine svog projekta, proizvoda, sistema. Isto tako, zanimaće testere i, čini mi se, posebno menadžere. Pod menadžerima mislim na ljude koji donose odluke i mogu uticati na sudbinu i razvoj proizvoda, sistema, tima takođe.
To su ljudi koji se pitaju kako poboljšati kvalitet proizvoda ili sistema. Na našoj konferenciji će se upoznati sa različitim setovima mjera i moći će razumjeti šta im sada nije u redu i šta treba promijeniti.
Mislim da je glavni kriterijum shvatiti da nešto nije u redu sa kvalitetom i želeti da utičemo na to. Vjerovatno nećemo moći doći do ljudi koji misle da će to uspjeti samo prvi put.
— Mislite li da je industrija u cjelini zrela za razgovor ne samo o testiranju, već i o kulturi kvaliteta?
Anastasia: Mislim da sam sazreo. Sada se mnoge kompanije odmiču od tradicionalnog Waterfall pristupa prema Agileu. Postoji fokus na kupca, ljudi u timovima zaista počinju razmišljati o tome kako stvoriti kvalitetan proizvod. Čak se i kompanije preusmjeravaju na poboljšanje kvaliteta.
Sudeći po broju zahtjeva koji se javljaju u zajednici, vjerujem da je vrijeme. Nisam siguran, naravno, da će ovo biti velika revolucija, ali bih volio da se ta revolucija u svijesti dogodi.
- Dogovoreno! Usadićemo kulturu i promeniti svest.
Konferencija o visokokvalitetnom razvoju IT proizvoda održat će se u Moskvi 7. juna. Znate koje faze čine visokokvalitetan proizvod, imamo slučajeve uspješnog suzbijanja grešaka u proizvodnji, testirali smo popularne metode u našoj praksi - potrebno nam je vaše iskustvo. njihovo prijave do 1. maja, a Programski odbor će pomoći fokusiranju teme za cjelokupni integritet konferencije.
Povežite se na , u kojoj raspravljamo o pitanjima kvaliteta i konferencije, pretplatite se na da budete u toku sa novostima iz programa.
izvor: www.habr.com