Ahoj, Habr!
Máme novú dôležitú tému – kvalitný vývoj IT produktov. Často hovoríme na konferencii HighLoad++, ako spraviť zaťažené služby rýchlymi, a na Frontend Conf – skvelé používateľské rozhranie, ktoré nezpomaluje. Pravidelne sa zaoberáme testovaním a DevOpsConf sa týka integrácie rôznych procesov, vrátane testovania. Ale o tom, čo možno nazvať kvalitou ako takou, a ako na nej komplexne pracovať – neexistuje.
Opraviť to na – budeme rozvíjať kultúru uvažovania o kvalite konečného produktu pre používateľa v každej fáze vývoja. Zvyk neuzatvárať sa na svojej zodpovednosti a spájať kvalitu nielen s testovačmi.
Pod článkom sa porozprávame s predsedníčkou programového výboru, vedúcou testovania v Tinkoff.Business, zakladateľkou ruskojazyčnej QA komunity Anastasiyou Aseevou-Nguyen o stave odvetvia QA a misii novej konferencie.
– Nastya, ahoj. Prosím, povedz niečo o sebe.
Anastasia: Vediem testovanie v banke, zodpovedám za veľmi veľký tím – máme viac ako 90 ľudí. Máme dôležitú obchodnú líniu, sme zodpovední za ekosystém pre právnické osoby.
Študovala som na mat-fyz a pôvodne som chcela byť programátorkou. Ale keď sa mi objavila zaujímavá ponuka, rozhodla som sa vyskúšať rolu testera. Ako divné, ale ukázalo sa, že to je môj osud. Teraz svoju prácu vidím presne v tejto oblasti.
Som silný zástanca disciplíny Quality Assurance. Nie je mi ľahostajné, aké produkty sa vytvárajú, ako sa spoločnosť, tím a proces vývoja vzťahujú ku kvalite.
Pre mňa je zrejmé, že spoločenstvo v tomto smere nie je dostatočne zrelé, aspoň v Rusku. Nie vždy chápeme, že zabezpečenie kvality nie je len samotný fakt testovania aplikácie na zhody s požiadavkami. Rada by som túto situáciu zmenila.
– Používaš slová Quality Assurance a testovanie. V očiach bežného človeka sa tieto dva pojmy veľmi často prelínajú. Čím sa líšia, ak to hľadíme hlbšie?
Anastasia: Naopak, v skutočnosti sa nelíšia. Testovanie je súčasťou disciplíny zabezpečenia kvality, je to bezprostredná činnosť - samotný fakt, že niečo testujem. Existuje naozaj veľa typov testovania a rôzne tipy testovania sú zverené rôznym ľuďom. No u nás na Slovensku, keď prišla vlna outsourcingu, ktorá dodáva testujúcich do firiem, sa testovanie zúžilo na jediný typ.
Vo väčšine prípadov sa obmedzujú len na funkčné testovanie: overujú, či to, čo naprogramovali vývojári, zodpovedá špecifikácii a všetko.
— Povedz mi, prosím, aké ďalšie existujú disciplíny zabezpečenia kvality? Čo ďalšie, okrem testovania, sem patrí?
Anastasia: Zabezpečenie kvality je predovšetkým o vytvorení kvalitného produktu. To znamená, že sa pýtame, akými atribútmi kvality by mal náš produkt disponovať. Ak to chápeme, môžeme porovnať, kto ovplyvňuje tieto atribúty kvality. Nie je dôležité, či ide o vývojára, projektového manažéra alebo produktového manažéra. — to je osoba, ktorá ovplyvňuje rozvoj produktu, jeho backlog a jeho stratégiu.
Testovač lepšie chápe svoju úlohu. Uvedomuje si, že jeho úloha nie je len testovať na súlad s požiadavkami, ale aj testovať samotné požiadavky, spochybňovať formulácie, ktoré prichádzajú od produktového manažéra, odhaľovať všetky implicitné požiadavky a očakávania klienta. Keď dodávame našim klientom novú funkcionalitu, musíme skutočne uspokojiť ich očakávania a vyriešiť ich problémy. Ak budeme premýšľať o všetkých atribútoch kvality, klient bude spokojný a pochopí, že spoločnosť, ktorej produkt používa, sa naozaj stará o jeho záujmy a nefunguje na princípe „len aby sme vydali funkciu“.
— Zdá sa, že to, čo si práve opísala, je úloha produktového manažéra. To, v princípe, nie je o testovaní a nie je to o kvalite - je to vôbec o riadení produktu, však?
Anastasia: Vrátane. Zabezpečenie kvality nie je disciplína, za ktorú zodpovedá konkrétny človek. Dnes je populárny prístup v testovaní, ktorý sa nazýva Agilné testovanieV jeho definícii sa jasne uvádza, že ide o tímový prístup k testovaniu, ktorý obsahuje určitú sadu praktík. Za realizáciu tohto prístupu zodpovedá celý tím, pričom nie je nevyhnutné, aby v tíme bol tester. Celý tím je orientovaný na to, aby poskytoval hodnotu klientovi a aby táto hodnota zodpovedala jeho očakávaniam.
— Takže kvalita sa prekrýva skoro so všetkými okolitými disciplínami, ukladá obmedzenia na všetko okolo?
Anastasia: Správne. Keď uvažujeme o tom, čo chceme vytvoriť kvalitný produkt, začíname premýšľať o rôznych atribútoch kvality. Napríklad, ako overiť, že sme naozaj vytvorili funkciu, ktorá je potrebná našim klientom.
Tu sa objavuje taký spôsob testovania ako UAT (testovanie akceptácie používateľom). Bohužiaľ, v Rusku sa zriedka praktizuje, ale občas sa vyskytuje v SCRUM tímach ako ukážka pre koncového klienta. V zahraničných spoločnostiach je to dosť rozšírený spôsob testovania. Predtým, ako otvoríme funkčnosť pre všetkých klientov, najprv vykonávame UAT, čiže pozývame konečného spotrebiteľa, ktorý vykonáva testovanie a okamžite poskytuje spätnú väzbu – či produkt skutočne zodpovedá očakávaniam a rieši problém. Iba po tomto prebieha rozsiahle nasadenie na všetkých ostatných klientov.
Čiže orientujeme sa na biznis, na konečného klienta, ale pritom nezabúdame na technológiu. Od technológií tiež silno závisí kvalita produktu. Ak budeme mať zlú architektúru, nebudeme môcť rýchlo vydávať funkcie a zodpovedať očakávaniam klienta. Môže byť veľa chýb pri pokuse o škálovanie, alebo pri pokuse o refaktoring môžeme niečo pokaziť. To všetko ovplyvní spokojnosť klienta.
Z tohto hľadiska by architektúra mala byť taká, aby sme mohli písať čistý kód, ktorý umožní rýchlo zavádzať zmeny a nemali by sme sa báť, že všetko rozbijeme. Aby iterácie vylepšení netrvali niekoľko mesiacov len preto, že máme príliš veľa legacy a potrebujeme robiť dlhé fázy testovania.
— Tým pádom sú už zapojení developeri, architekti, produktológovia, produktoví manažéri, sami testeri. Kto ďalší je zapojený do procesu zabezpečenia kvality?
Anastasia: Predstavme si, že sme už doručili klientovi funkciu. Je zrejmé, že kvalitu produktu je potrebné sledovať aj po jeho uvedení na trh. V tomto štádiu sa môžu objaviť situácie s nejasnými scenármi, tzv. bugy.
Prvá otázka — ako sa vyrovnávame s týmito bugmi po uvedení produktu? Ako reagujeme na zaťaženie? Klient nebude veľmi spokojný, ak sa stránka načíta viac ako 30 sekúnd.
Tu prichádza do hry údržba alebo, ako sa to dnes nazýva, DevOps. V skutočnosti sú to ľudia, ktorí sú zodpovední za údržbu produktu, keď je už na trhu. Sem patrí rôzne druhy monitorovania. Existuje dokonca podtyp testovania — testovanie na trhu, keď si dovolíme niečo netestovať pred vydaním a testujeme to priamo na trhu. Ide o množstvo opatrení z pohľadu organizácie infraštruktúry, ktoré umožňujú rýchlo reagovať na incident, ovplyvniť ho a opraviť ho.
Infraštruktúra je tiež dôležitá. Často sa vyskytnú situácie, keď počas testu nie je možné overiť, že máme naozaj všetko, čo by sme chceli poskytnúť klientovi. Uvedieme na trh — a začneme zachytávať nejasné situácie. A to všetko preto, že infraštruktúra v teste neodzrkadľuje infraštruktúru na trhu. Odtiaľ pramení nový typ testovania — testovanie infraštruktúry. Ide o rôzne konfigurácie, nastavenia, migráciu databáz atď.
Z toho vzniká otázka — možno by tím mal používať 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 s reálnym prípadom. Napíšte nám, ak ste pripravení na svojom vlastnom skúsenosti povedať, ako infraštruktúra ako kód ovplyvňuje kvalitu. Infraštruktúra ako kód umožňuje jednoduchšie kontrolovať všetky nastavenia a testovať to, čo by inak bolo jednoducho nemožné. Preto je do procesu vývoja kvalitného produktu zapojená aj údržba.
— A čo analytika a dokumentácia?
Anastasia: To sa viac týka enterprise systémov. Keď hovoríme o enterprise, na um hneď prichádzajú takí ľudia, ako sú analytici a systémoví analytici. Niekedy ich nazývajú technickými spisovateľmi. Dostanú úlohu napísať špecifikáciu a plnia ju, napríklad, mesiac.
Rôzne štúdie dokázali, že písanie takejto dokumentácie vedie k veľmi dlhým fázam vývoja a dlhému zlepšovaniu, pretože počas testovania sa odhaľujú chyby, čo vedie k vracaniu. V dôsledku toho vzniká množstvo slučiek, ktoré zvyšujú náklady na vývoj. Okrem toho to môže spôsobiť zraniteľnosti. Akoby sme napísali referenčný kód, ale potom sme urobili zmeny, ktoré rozbíjajú dokonale premyslenú architektúru.
Na konci dostaneme nie úplne kvalitný produkt, pretože v architektúre už pribudli záplaty, kód niektorých miest nie je dostatočne pokrytý testami, pretože termíny sa krčia a musíme rýchlejšie opraviť všetky chyby. A to všetko preto, že v pôvodnej špecifikácii neboli zahrnuté všetky aspekty, ktoré bolo potrebné realizovať.
Vývojári nie sú zlí a nepíšu úmyselne chybový kód.
Keby sme pôvodne premysleli špecifikáciu, v ktorej by boli osvetlené všetky potrebné aspekty, všetko by bolo realizované presne tak, ako má byť. Ale to je utópia.
Asi nie je možné napísať ideálnu špecifikáciu na 100 strán. Preto by sme mali premýšľať o alternatívnych spôsoboch písania dokumentácie, špecifikovania, zadávania úloh, ktoré by nás priblížili k tomu, aby vývojár robil presne to, čo je potrebné.
Sem prichádzajú na myseľ prístupy z Agile - používateľské príbehy s akceptačnými kritériami. To je viac platné pre tímy, ktoré sa rozvíjajú malými iteráciami.
— Čo sa týka testovania použiteľnosti, pohodlia použitia produktu, dizajnu?
Anastasia: To je veľmi dôležitý moment, pretože v tíme sú dizajnéri. Častejšie sa dizajnéri používajú ako služba - buď tím dizajnérov, alebo dizajnér na outsourcingu. Často sa stretávame s tým, že akoby dizajnér počúval produktového manažéra a urobil to, čo pochopil. Ale keď sa pustíme do iterácie, ukáže sa, že v skutočnosti nebolo urobené to, čo sme očakávali: dizajnér niečo zabudol, nedokončil premyslieť správanie, pretože nie je v tíme a nie je v kontexte, alebo front-end vývojár úplne nechápal jeho návrh. Môže si vyžadovať niekoľko iterácií len kvôli tomu, že existuje problém s pochopením dizajnu zo strany front-end vývojára.
Existuje však ešte jeden problém. V súčasnosti sa stále viac presadzujú dizajnové systémy. Sú na vrchole popularity, ale ich výhoda nie je úplne zrejmá.
Stretávam sa s názorom, že dizajnové systémy na jednej strane uľahčujú vývoj, na druhej strane však nanášajú veľa obmedzení na rozhranie.
Celkovo robíme nie funkciu, ktorú klient chce získať, ale takú, ktorá je pohodlná pre nás, pretože už máme určité prvky, z ktorých ju môžeme vytvoriť.
Myslím si, že na túto tému by sa malo podrobnejšie pozrieť a zamyslieť sa, či naozaj v snahe zjednodušiť prácu na dizajne riešime problém klienta.
— Výsledkom je neuveriteľne veľa tém súvisiacich s kvalitou zabezpečenia. Existuje v Rusku konferencia, na ktorej sa dajú všetky tieto témy prediskutovať?
Anastasia: Existuje najstaršia konferencia o testovaní, ktorá sa tento rok uskutoční už po 25-krát a nazýva sa Konferencia o zabezpečení kvality SQA Days. Predovšetkým sa na nej diskutujú nástroje a konkrétne prístupy testovania pre funkčných testerov. Zvyčajne sa v príspevkoch na SQA Days hlboko skúmajú konkrétne oblasti zodpovednosti samotných testerov, ale nie komplexné podujatia.
To veľmi pomáha rozlíšiť rôzne nástroje a prístupy, ako testovať databázy, API atď. Ale na druhej strane to nemotivuje zapájať do vytvárania kvalitnejšieho produktu nielen testovanie. A na druhej strane sa testeri nestávajú viac zapojenými do procesu, aby mysleli na globálny cieľ produktu a jeho obchodnú stránku.
Vediem veľké oddelenie, robím veľa pohovorov, ktoré v skutočnosti umožňujú získať prehľad o stave odvetvia ako celku. Zvyčajne naši ľudia pracujú v podniku a majú jasnú zodpovednosť. Kolegovia, ktorí pracujú na zahraničných projektoch, používajú rôzne typy testovania: môžu robiť záťažové testovanie, testovanie výkonu a niekedy aj testovanie bezpečnosti, pretože skutočne pomáhajú tímu udržiavať kvalitu produktu.
Rád by som, aby aj u nás v Rusku ľudia začali uvažovať o tom, že oblasť funkčného testovania nekončí.
— Pre tento účel organizujeme novú konferenciu QualityConf, ktorá sa zaoberá kvalitou ako celkovou disciplínou. Môžeš nám prerozprávať myšlienku podrobnejšie, aký je hlavný cieľ konferencie?
Anastasia: Chceme vytvoriť komunitu ľudí, ktorí sa zaujímajú o vytváranie kvalitných produktov. Ponúknuť priestor, kde môžu prísť, vypočuť si prednášky a odísť po konferencii s konkrétnym pochopením, čo je potrebné zmeniť pre zlepšenie kvality.
Často teraz počujem žiadosti od konzultantov, čo robiť, keď sú problémy s testovaním a kvalitou. Keď začneš komunikovať s tímami, vidíš, že problém nie je priamo v testeroch, ale v tom, ako je proces nastavený. Napríklad, keď vývojári považujú, že sú zodpovední len za písanie kódu, ich zodpovednosť sa končí presne v momente, keď odovzdajú úlohu na testovanie.
Nie všetci si uvedomujú, že zle napísaný nekvalitný kód so zlou architektúrou predstavuje vážne problémy pre projekt. Nezamýšľajú nad nákladmi na chyby, nad tým, že bugy, ktoré sa dostanú do produkcie, môžu viesť k vysokým nákladom pre spoločnosť a tím. Nie je tu kultúra uvažovania o tom. Chcem, aby sme na konferencii začali túto kultúru šíriť.
Chápem, že to nie je inovácia. Edward Deming, autor 14 postulátov kvality, písal o nákladoch na chyby už v minulom storočí. Na tejto knihe je založené Quality Assurance ako disciplína, no, žiaľ, moderný vývoj na to zabúda.
— A plánujete sa zaoberať aj témami priamo o testovaní a nástrojoch?
Anastasia: Predpokladám, že budú prednášky o nástrojoch. Existujú dostatočne univerzálne nástroje, pomocou ktorých môžu spoločnosti a tímy ovplyvniť produkt.
Všetky prednášky budú globálne spojené jednou spoločnou misiou: preniesť na publikum, že pomocou tohto prístupu, nástroja, metódy, procesu, typu testovania sme ovplyvnili kvalitu produktu a zlepšili život zákazníka.
Určite nebudeme mať prednášky o nástroji len pre nástroj. Všetky prednášky, ktoré sa dostanú do programu, budú spojené spoločným cieľom.
— Kto by sa zaujímal o to, o čom hovoríš, koho vidíš ako hostí konferencie?
Anastasia: Budeme mať prednášky pre vývojárov, ktorým nie je ľahostajný osud svojho projektu, produktu, systému. Rovnako to bude zaujímavé pre testerov a, ako mi pripadá, najmä pre manažérov. Pod manažérmi mám na mysli ľudí, ktorí rozhodujú a môžu ovplyvniť osud a rozvoj produktu, systému, tímu vrátane.
To sú ľudia, ktorí sa pýtajú, ako zvýšiť kvalitu produktu, systému. Na našej konferencii sa dozvedia o rôznych komplexoch aktivít a budú môcť pochopiť, čo im momentálne nefunguje, čo treba zmeniť.
Myslím, že hlavným kritériom je uvedomiť si, že s kvalitou niečo nie je v poriadku, a chcieť na to vplývať. Pravdepodobne sa nám nepodarí presvedčiť ľudí, ktorí si myslia, že dobré je aj tak, na prvý pokus.
— Ako si myslíš, zrelý je celý priemysel na to, aby sa hovorilo nielen o testovaní, ale aj o kultúre kvality?
Anastasia: Myslím, že áno. Teraz mnoho spoločností prechádza od tradičného Waterfall prístupu smerom k Agile. Je sústredenie na zákazníka, ľudia v tímoch skutočne začínajú premýšľať o tom, ako vytvoriť kvalitný produkt. Dokonca aj v enterprise spoločnostiach dochádza k preorientovaniu na zvyšovanie kvality.
Súdajúc podľa počtu dopytov, ktoré vznikajú v komunite, myslím, že už je čas. Nie som si však istá, či to bude veľká revolúcia, ale želala by som si, aby sa tento prevrat v myslení uskutočnil.
— Dohodnutí! Budeme pestovať kultúru a obracať myslenie.
Konferencia o kvalitnom vývoji IT produktov sa uskutoční v Moskve 7. júna. Viete, z akých etáp sa skladá kvalitný produkt, máme prípady úspešného boja s bugmi na produkcii, na vlastnej praxi sme overili populárne metódy — potrebujeme vašu skúsenosť. svoje prihlášky do 1. mája, a Programový výbor pomôže zamerať tému pre celkovú súdržnosť konferencie.
Pripojte sa k , v ktorom diskutujeme o otázkach kvality a konferencii, prihláste sa na , aby ste boli informovaní o novinkách programu.
Zdroj: habr.com
