Čau Habr!
Máme novú dôležitú tému - kvalitný vývoj IT produktov. V HighLoad++ často hovoríme o tom, ako zrýchliť zaneprázdnené služby, a vo Frontend Conf hovoríme o skvelom používateľskom rozhraní, ktoré sa nespomalí. Pravidelne máme témy o testovaní a DevOpsConf o kombinovaní rôznych procesov vrátane testovania. Ale o tom, čo sa dá nazvať kvalitou vo všeobecnosti a ako na tom komplexne pracovať - nie.
Poďme to opraviť — vytvoríme kultúru myslenia o kvalite konečného produktu pre užívateľa v každej fáze vývoja. Zvyk nezameriavať sa na oblasť svojej zodpovednosti a spájať kvalitu nielen s testermi.
Pod strihom sa porozprávame s vedúcim programového výboru, vedúcim testovania v Tinkoff.Business, tvorcom rusky hovoriacej komunity QA Anastasia Aseeva-Nguyen o stave odvetvia QA a poslaní novej konferencie.
- Nastia ahoj. Povedzte nám o sebe.
Anastasia: Vediem testovanie v banke a som zodpovedný za veľmi veľký tím – máme viac ako 90 ľudí. Máme dôležitú obchodnú líniu, zodpovedáme za ekosystém pre právnické osoby.
Vyštudoval som mechaniku a matematiku a pôvodne som sa chcel stať programátorom. Ale keď som dostal zaujímavú ponuku, rozhodol som sa vyskúšať ako tester. Napodiv sa ukázalo, že toto bolo moje povolanie. Teraz vidím všetku svoju prácu v tomto odvetví.
Som horlivým zástancom disciplíny zabezpečenia kvality. Záleží mi na tom, aké produkty vznikajú, ako sa s kvalitou zaobchádza vo firme, v tíme a v zásade aj v procese vývoja.
Je mi to jasné komunita v tomto smere nie je dostatočne vyspelá, aspoň v Rusku. Nie vždy chápeme, že zabezpečenie kvality nie je len testovanie aplikácie na zhodu s požiadavkami. Chcel by som túto situáciu zmeniť.
— Používate slová Zabezpečenie kvality a testovanie. V očiach bežného človeka sa tieto dva pojmy veľmi často prelínajú. Ako sa líšia, ak kopnete hlboko?
Anastasia: Skôr nie sú rozdielne. Testovanie je súčasťou disciplíny Quality Assurance, je to priama činnosť – samotný fakt, že niečo testujem. V skutočnosti existuje veľa typov testovania a za rôzne typy testovania sú zodpovední rôzni ľudia. Ale tu v Rusku, keď sa objavila vlna outsourcingov, ktorí dodávajú testery firmám, testovanie sa zredukovalo na jeden typ.
Vo väčšine prípadov sa obmedzujú iba na funkčné testovanie: kontrolujú, či to, čo vývojári nakódovali, je v súlade so špecifikáciou a to je všetko.
— Povedzte nám, aké ďalšie disciplíny zabezpečenia kvality existujú? Čo iné, okrem testovania, je tu zahrnuté?
Anastasia: Zabezpečenie kvality je v prvom rade o vytvorení kvalitného produktu. To znamená, že si kladieme otázku, aké kvalitatívne atribúty by mal mať náš produkt. Podľa toho, ak tomu rozumieme, potom môžeme porovnávať, kto tieto atribúty kvality ovplyvňuje. Nevadí, vývojár, projektový manažér alebo produktový špecialista je osoba, ktorá ovplyvňuje vývoj produktu, jeho nevybavené položky a jeho stratégiu.
Tester si viac uvedomuje svoju úlohu. Chápe, že jeho úlohou nie je len testovať súlad s požiadavkami, ale aj testovať požiadavky, spochybňovať formulácie, ktoré pochádzajú od produktového špecialistu, a odhaľovať všetky implicitné požiadavky a očakávania klienta. Keď zákazníkovi dodávame novú funkcionalitu, musíme skutočne splniť jeho očakávania a vyriešiť jeho bolesť. Ak sa zamyslíme nad všetkými atribútmi kvality, klient bude spokojný a pochopí, že spoločnosti, ktorej produkt používa, skutočne záleží na jeho záujmoch a nepracuje na princípe „len vydávať vlastnosť“.
— Zdá sa, že to, čo ste práve opísali, je úlohou produktového špecialistu. Toto v zásade nie je o testovaní a nie o kvalite - je to všeobecne o riadení produktu, nie?
Anastasia: Počítajúc do toho. Zabezpečenie kvality nie je disciplína, za ktorú je zodpovedná jedna konkrétna osoba. Teraz je populárny smer v testovaní, prístup tzv Agilné testovanie. Jeho definícia jasne hovorí, že ide o tímový prístup k testovaniu, ktorý zahŕňa určitý súbor praktík. Za implementáciu tohto prístupu je zodpovedný celý tím, dokonca nie je potrebné, aby bol v tíme tester. Celý tím sa zameriava na poskytovanie hodnoty zákazníkovi a zabezpečenie toho, aby hodnota spĺňala očakávania zákazníkov.
— Ukazuje sa, že kvalita sa prelína takmer so všetkými okolitými disciplínami a vnucuje rámec všetkému okolo?
Anastasia: Správny. Keď sa zamyslíme nad tým, že chceme vytvoriť kvalitný produkt, začneme premýšľať o rôznych atribútoch kvality. Napríklad, ako skontrolovať, či sme skutočne vytvorili funkciu, ktorú náš klient potrebuje.
Tu prichádza tento typ testovania: UAT (užívateľské akceptačné testovanie). Žiaľ, v Rusku sa praktizuje len zriedka, ale niekedy sa vyskytuje v tímoch SCRUM ako demo pre koncového klienta. Ide o pomerne bežný typ testovania v zahraničných firmách. Pred otvorením funkcionality všetkým zákazníkom najskôr urobíme UAT, to znamená, že koncového používateľa pozveme na test a okamžite poskytneme spätnú väzbu, či produkt skutočne spĺňa očakávania a rieši bolesť. Až potom je možné škálovanie na všetkých ostatných klientov.
To znamená, že sa zameriavame na biznis, na koncového klienta, ale zároveň nezabudnite na techniku. Kvalita produktu tiež veľmi závisí od technológie. Ak máme zlú architektúru, nebudeme schopní rýchlo vydať funkcie a splniť očakávania zákazníkov. Pri pokuse o škálovanie sa môže vyskytnúť veľa chýb alebo pri pokuse o refaktorovanie môžeme niečo pokaziť. To všetko ovplyvní spokojnosť zákazníkov.
Z tohto pohľadu by architektúra mala byť taká, aby sme vedeli písať čistý kód, ktorý nám umožní rýchlo robiť zmeny a nebáť sa, že všetko pokazíme. Aby sme zabezpečili, že iterácie revízií nebudú trvať niekoľko mesiacov len preto, že máme toľko dedičstva, musíme vykonať dlhé testovacie fázy.
— Celkovo sú už zapojení vývojári, architekti, produktoví vedci, produktoví manažéri a samotní testeri. Kto ďalší sa podieľa na procese zabezpečenia kvality?
Anastasia: Teraz si predstavme, že sme funkciu už doručili klientovi. Je zrejmé, že kvalitu produktu je potrebné sledovať, aj keď je už vo výrobe. V tejto fáze sa môžu objaviť situácie s nezrejmými scenármi, takzvané bugy.
Prvá otázka znie, ako sa vysporiadame s týmito chybami, keď sme už produkt vydali? Ako reagujeme napríklad na stres? Klienta veľmi nepoteší, ak sa stránka načítava dlhšie ako 30 sekúnd.
Tu vstupuje do hry vykorisťovanie, alebo ako to teraz nazývajú. DevOps. V skutočnosti sú to ľudia, ktorí sú zodpovední za prevádzku produktu, keď je už vo výrobe. To zahŕňa rôzne typy monitorovania. Dokonca existuje aj podtyp testovania – testovanie na produkcii, kedy si dovolíme niečo netestovať pred vydaním a otestujeme to hneď vo výrobe. Ide o sériu aktivít z pohľadu organizácie infraštruktúry, ktoré umožňujú rýchlo reagovať na incident, ovplyvniť ho a opraviť.
Dôležitá je aj infraštruktúra. Často dochádza k situáciám, keď sa pri testovaní nedá uistiť, že máme naozaj všetko, čo by sme klientovi chceli dať. Zavedieme to do výroby a začneme zachytávať neočividné situácie. A to všetko preto, že infraštruktúra v teste nezodpovedá infraštruktúre vo výrobe. To vedie k novému typu testovania - testovanie infraštruktúry. Patria sem rôzne konfigurácie, nastavenia, migrácie databáz atď.
To vyvoláva otázku - možno tím potrebuje použiť infraštruktúru ako kód.
Verím, že infraštruktúra priamo ovplyvňuje kvalitu produktu.
Dúfam, že na konferencii bude správa so skutočným prípadom. Napíšte nám, ak ste pripravení nám z vlastnej skúsenosti povedať, ako infraštruktúra ako kód ovplyvňuje kvalitu. Infraštruktúra ako kód uľahčuje kontrolu všetkých nastavení a testovanie vecí, ktoré inak jednoducho nie sú možné. Do procesu vývoja kvalitného produktu sa preto zapája aj prevádzka.
— A čo analytika a dokumentácia?
Anastasia: Týka sa to skôr podnikových systémov. Keď hovoríme o podnikaní, okamžite sa nám vybavia ľudia ako analytici a systémoví analytici. Niekedy sa im hovorí technickí autori. Dostanú úlohu napísať špecifikáciu a dokončiť ju napríklad mesiac.
Opakovane sa dokázalo, že písanie takejto dokumentácie vedie k veľmi dlhým iteráciám vývoja a dlhým iteráciám zlepšovania, pretože počas testovacieho procesu sú identifikované chyby a začínajú sa návraty. V dôsledku toho existuje veľa slučiek, ktoré zvyšujú náklady na vývoj. Okrem toho to môže spôsobiť zraniteľnosť. Zdá sa, že sme napísali referenčný kód, ale potom sme urobili zmeny, ktoré narúšajú dokonale premyslenú architektúru.
Výsledkom je, že výsledkom nie je príliš kvalitný produkt, pretože v architektúre sa už objavili záplaty, kód miestami nie je dostatočne pokrytý testami, pretože sa míňajú termíny, všetky chyby treba rýchlejšie uzatvárať. A to všetko preto, že pôvodná špecifikácia nezohľadňovala všetky body, ktoré je potrebné implementovať.
Vývojári nie sú škodcovia a zámerne nepíšu kód s chybami.
Ak by sme na začiatku premysleli špecifikáciu, ktorá by pokrývala všetky potrebné body, všetko by bolo implementované presne podľa potreby. Ale toto je utópia.
Napísať dokonalú 100-stranovú špecifikáciu je asi nemožné. Preto treba uvažovať o alternatívnych spôsoboch písania dokumentácie, špecifikácie, úlohy, ktoré by nás priblížili k tomu, aby vývojár urobil presne to, čo je potrebné.
Tu prichádzajú na myseľ agilné prístupy – príbehy používateľov s kritériami prijatia. Toto je vhodnejšie pre tímy, ktoré sa vyvíjajú v malých iteráciách.
— A čo testovanie použiteľnosti, použiteľnosť produktu, dizajn?
Anastasia: Toto je veľmi dôležitý bod, pretože v tíme sú dizajnéri. Najčastejšie sú dizajnéri využívaní ako služba – buď dizajnovým oddelením alebo externým dizajnérom. Často sú situácie, keď sa zdá, že dizajnér počúval produktového vedca a robil to, čomu rozumel. Keď však začneme s iteráciou, ukáže sa, že to, čo sa v skutočnosti urobilo, nebolo to, čo sa očakávalo: dizajnér na niečo zabudol, úplne nepremyslel správanie, pretože nebol v tíme a nebol v kontexte, alebo vpredu. -koncový vývojár úplne nerozumel jeho rozloženiu. Môže to trvať niekoľko iterácií len preto, že existuje problém s pochopením dizajnu front-end vývojárom.
Plus je tu ešte jeden problém. Dizajnové systémy v súčasnosti získavajú na popularite. Sú na humbuku, ale výhody z nich nie sú úplne zrejmé.
Stretávam sa s názorom, že dizajnové systémy na jednej strane zjednodušujú vývoj, no na druhej strane kladú veľa obmedzení na rozhranie.
Výsledkom je, že nerobíme funkciu, ktorú chce klient, ale takú, ktorá je pre nás výhodná, pretože už máme určité kocky, z ktorých to vieme vyrobiť.
Myslím, že stojí za to venovať tejto téme pozornosť a zamyslieť sa, či pri pokuse o zjednodušenie dizajnérskej práce vlastne riešime klientovu bolesť.
— Existuje prekvapivý počet tém súvisiacich so zabezpečením kvality. Existuje v Rusku konferencia, kde by sa o nich dalo diskutovať?
Anastasia: Je tu najstaršia konferencia o testovaní, ktorá sa tento rok bude konať už po 25. krát a volá sa Quality Assurance Conference SQA Days. Rozoberá hlavne nástroje a špecifické testovacie prístupy pre funkčných testerov. Správy na SQA Days spravidla do hĺbky skúmajú konkrétne oblasti v oblasti zodpovednosti samotných testerov, nie však komplexné činnosti.
To veľmi pomáha pochopiť rôzne nástroje a prístupy, ako testovať databázy, API atď. No zároveň to na jednej strane nemotivuje zapojiť do tvorby lepšieho produktu viac ako len testovanie. Na druhej strane, testeri sa viac nezapájajú do procesu uvažovania o globálnom cieli produktu a jeho obchodnej zložky.
Vediem veľké oddelenie a vediem množstvo rozhovorov, ktoré skutočne poskytujú pohľad na stav odvetvia ako celku. Naši chlapci spravidla pracujú v podniku a majú jasnú oblasť zodpovednosti. Kolegovia, ktorí pracujú v zahraničných projektoch, využívajú rôzne typy testovania: sami môžu robiť záťažové testovanie, testovanie výkonu a niekedy aj testovanie bezpečnosti, pretože skutočne pomáhajú tímu zabezpečiť kvalitu produktu.
Bol by som rád, keby aj chlapci v Rusku začali myslieť na to, že toto odvetvie nekončí funkčným testovaním.
— Za týmto účelom organizujeme novú konferenciu QualityConf, ktorá sa venuje kvalite ako integrálnej disciplíne. Povedzte nám viac o myšlienke, čo je hlavným cieľom konferencie?
Anastasia: Chceme vytvoriť komunitu ľudí, ktorí majú záujem vyrábať kvalitné produkty. Ponúknite platformu, kde môžu prísť, vypočuť si správy a odísť z konferencie s konkrétnym pochopením toho, čo potrebujú zmeniť, aby zlepšili kvalitu.
V súčasnosti často počúvam z poradní požiadavku, čo robiť, keď sú problémy s testovaním a kvalitou. Keď začnete komunikovať s tímami, uvidíte, že problém nie je v samotných testeroch, ale v spôsobe, akým je proces štruktúrovaný. Keď sa napríklad vývojári domnievajú, že sú zodpovední len za písanie kódu, ich zodpovednosť končí presne v momente, keď úlohu prenesú do testovania.
Nie každý sa zamýšľa nad tým, že zle napísaný, nekvalitný kód so zlou architektúrou hrozia projektu veľké problémy. Nemyslia na cenu chýb, na to, že chyby, ktoré skončia vo výrobe, môžu mať za následok veľké náklady pre spoločnosť a tím. Neexistuje žiadna kultúra, ktorá by o tom premýšľala. Chcem, aby sme to začali distribuovať na konferencii.
Chápem, že to nie je inovácia.“ Edward Deming, autor 14 princípov kvality, písal o cene chyby už v minulom storočí. Zabezpečovanie kvality ako disciplína vychádza z tejto knihy, no, žiaľ, moderný vývoj na ňu zabúda.
— Plánujete sa priamo dotknúť tém o testovaní a nástrojoch?
Anastasia: Pripúšťam, že správy o nástrojoch budú. Existujú celkom univerzálne nástroje, pomocou ktorých môžu firmy a tímy ovplyvniť produkt.
Všetky správy bude globálne spájať jedno spoločné poslanie: sprostredkovať publiku, že pomocou tohto prístupu, nástroja, metódy, procesu, typu testovania sme ovplyvnili kvalitu produktu a zlepšili život klienta.
Určite nebudeme mať správy o nástroji pre nástroj. Všetky správy zahrnuté v programe budú spájať spoločný cieľ.
— Koho bude zaujímať, o čom hovoríte, koho vidíte ako hostí konferencie?
Anastasia: Budeme mať reporty pre vývojárov, ktorým záleží na osude ich projektu, produktu, systému. Rovnako to bude zaujímať testerov a zdá sa mi, že najmä manažérov. Manažérmi mám na mysli ľudí, ktorí rozhodujú a môžu okrem iného ovplyvňovať osud a vývoj produktu, systému, tímu.
Sú to ľudia, ktorí sa pýtajú, ako zlepšiť kvalitu produktu alebo systému. Na našej konferencii sa dozvedia o rôznych súboroch opatrení a budú vedieť pochopiť, čo im teraz nejde a čo treba zmeniť.
Myslím si, že hlavným kritériom je pochopiť, že niečo nie je v poriadku s kvalitou a chcieť to ovplyvniť. Pravdepodobne sa nám nepodarí osloviť ľudí, ktorí si myslia, že sa to podarí na prvýkrát.
— Myslíte si, že odvetvie ako celok je zrelé na to, aby hovorilo nielen o testovaní, ale aj o kultúre kvality?
Anastasia: Verím, že som dospelý. Teraz veľa spoločností ustupuje od tradičného prístupu Waterfall k Agile. Je tu zameranie na klienta, ľudia v tímoch naozaj začínajú premýšľať o tom, ako vytvoriť kvalitný produkt. Dokonca aj podnikové spoločnosti sa zameriavajú na zvyšovanie kvality.
Súdiac podľa množstva žiadostí, ktoré sa v komunite objavujú, verím, že je čas. Samozrejme, nie som si istý, či to bude rozsiahla revolúcia, ale bol by som rád, keby k tejto revolúcii vo vedomí došlo.
- Súhlasím! Vštepíme kultúru a zmeníme vedomie.
Konferencia o kvalitnom vývoji IT produktov sa uskutoční v Moskve 7. júna. Viete, z akých fáz sa skladá kvalitný produkt, máme prípady úspešného boja proti chybám vo výrobe, vyskúšali sme populárne metódy v našej vlastnej praxi - potrebujeme vaše skúsenosti. ich prihlášky do 1. májaa programový výbor pomôže zamerať tému na celkovú integritu konferencie.
Pripojte sa k , v ktorej diskutujeme o otázkach kvality a konferenciu, prihláste sa na odber aby ste mali prehľad o novinkách v programe.
Zdroj: hab.com