Čau Habr!
Máme nové důležité téma - kvalitní vývoj IT produktů. V HighLoad++ často mluvíme o tom, jak zrychlit zaneprázdněné služby, a ve Frontend Conf mluvíme o skvělém uživatelském rozhraní, které se nezpomaluje. Pravidelně máme témata o testování a DevOpsConf o kombinování různých procesů, včetně testování. Ale o tom, co lze obecně nazvat kvalitou a jak na tom komplexně pracovat - ne.
Pojďme to opravit — rozvineme kulturu myšlení o kvalitě konečného produktu pro uživatele v každé fázi vývoje. Zvyk nezaměřovat se na svou oblast odpovědnosti a spojovat kvalitu nejen s testery.
Pod sestřihem budeme hovořit s vedoucím programového výboru, vedoucím testování v Tinkoff.Business, tvůrcem rusky mluvící komunity QA Anastasia Aseeva-Nguyen o stavu odvětví QA a poslání nové konference.
- Nastio ahoj. Řekněte nám o sobě.
Anastasia: Řídím testování v bance, zodpovídám za velmi velký tým - je nás více než 90 lidí. Máme důležitou obchodní linii, zodpovídáme za ekosystém pro právnické osoby.
Vystudoval jsem mechaniku a matematiku a původně jsem se chtěl stát programátorem. Ale když jsem dostal zajímavou nabídku, rozhodl jsem se vyzkoušet jako tester. Kupodivu se ukázalo, že to bylo moje povolání. Nyní vidím veškerou svou práci v tomto odvětví.
Jsem horlivým přívržencem disciplíny Quality Assurance. Není mi lhostejné, jaké produkty vznikají, jak se s kvalitou zachází ve firmě, v týmu a v zásadě i v procesu vývoje.
To je mi jasné komunita v tomto směru není dostatečně zralá, alespoň v Rusku. Ne vždy chápeme, že zajištění kvality není pouze faktem testování aplikace z hlediska shody s požadavky. Rád bych tuto situaci změnil.
— Používáte slova Quality Assurance and testing. V očích běžného člověka se tyto dva pojmy velmi často překrývají. Jak se liší, pokud kopnete hluboko?
Anastasia: Spíše se neliší. Testování je součástí disciplíny Quality Assurance, je to přímá činnost – samotná skutečnost, že něco testuji. Ve skutečnosti existuje mnoho typů testování a za různé typy testování je zodpovědná celá řada lidí. Když se ale tady v Rusku objevila vlna outsourcingů, kteří firmám dodávají testery, testování se zredukovalo na jediný typ.
Ve většině případů se omezují pouze na funkční testování: zkontrolují, zda to, co vývojáři nakódovali, odpovídá specifikaci a je to.
— Řekněte nám prosím, jaké další disciplíny zajišťování kvality existují? Co dalšího, kromě testování, je zde zahrnuto?
Anastasia: Zajištění kvality je především o vytvoření kvalitního produktu. To znamená, že si klademe otázku, jaké kvalitativní atributy by náš produkt měl mít. Pokud tomu tedy rozumíme, můžeme porovnávat, kdo tyto atributy kvality ovlivňuje. Nevadí, vývojář, projektový manažer nebo produktový specialista je člověk, který ovlivňuje vývoj produktu, jeho nevyřízené položky a jeho strategii.
Tester si více uvědomuje svou roli. Chápe, že jeho úkolem není pouze testovat shodu s požadavky, ale také testovat požadavky, zpochybňovat formulace, které pocházejí od produktového specialisty, a odhalovat všechny implicitní požadavky a očekávání klienta. Když dodáváme nové funkce našemu zákazníkovi, musíme skutečně splnit jeho očekávání a vyřešit jeho bolest. Zamyslíme-li se nad všemi atributy kvality, bude klient spokojený a pochopí, že společnost, jejíž produkt používá, se opravdu zajímá o jeho zájmy a nepracuje na principu „jen vydat funkci“.
— Zdá se, že to, co jste právě popsal, je úkolem produktového specialisty. Toto v zásadě není o testování a ne o kvalitě - je to obecně o řízení produktu, ne?
Anastasia: Počítaje v to. Quality Assurance není disciplína, za kterou je odpovědná jedna konkrétní osoba. Nyní existuje populární směr testování, přístup zvaný Agilní testování. Jeho definice jasně říká, že se jedná o týmový přístup k testování, který zahrnuje určitý soubor praktik. Za implementaci tohoto přístupu je zodpovědný celý tým, není dokonce nutné, aby v týmu byl tester. Celý tým se zaměřuje na poskytování hodnoty zákazníkovi a zajištění toho, aby hodnota odpovídala očekáváním zákazníků.
— Ukazuje se, že kvalita se prolíná téměř se všemi okolními disciplínami a vnucuje rámec všemu kolem?
Anastasia: Že jo. Když přemýšlíme o tom, jak chceme vytvořit kvalitní produkt, začneme přemýšlet o různých atributech kvality. Například jak zkontrolovat, že jsme skutečně vytvořili funkci, kterou náš klient potřebuje.
Zde přichází na řadu tento typ testování: TAO (testování přijetí uživatele). Bohužel se v Rusku málokdy praktikuje, ale někdy je přítomen v týmech SCRUM jako demo pro koncového klienta. Jde o poměrně běžný typ testování v zahraničních firmách. Než funkcionalitu zpřístupníme všem klientům, nejprve uděláme UAT, to znamená, že pozveme koncového uživatele, který testuje a okamžitě dává zpětnou vazbu - zda produkt skutečně splňuje očekávání a řeší bolest. Teprve poté dojde ke škálování na všechny ostatní klienty.
To znamená, že se zaměřujeme na obchod, na koncového klienta, ale zároveň nezapomeňte na techniku. Kvalita produktu také velmi závisí na technologii. Pokud budeme mít špatnou architekturu, nebudeme schopni rychle uvolnit funkce a splnit očekávání zákazníků. Při pokusu o škálování může být spousta chyb nebo při pokusu o refaktorování můžeme něco rozbít. To vše ovlivní spokojenost zákazníků.
Z tohoto pohledu by architektura měla být taková, abychom mohli psát čistý kód, který nám umožní rychle provádět změny a nebát se, že vše rozbijeme. Aby se iterace revizí neprotahovaly na několik měsíců jednoduše proto, že máme tolik dědictví a musíme provést dlouhé testovací fáze.
— Celkově jsou již zapojeni vývojáři, architekti, produktoví vědci, produktoví manažeři a samotní testeři. Kdo další se podílí na procesu zajišťování kvality?
Anastasia: Nyní si představme, že jsme funkci již dodali klientovi. Je zřejmé, že kvalitu produktu je třeba sledovat, i když je již ve výrobě. V této fázi se mohou objevit situace s nesrozumitelnými scénáři, tzv. bugy.
První otázkou je, jak se vypořádáme s těmito chybami poté, co jsme již produkt vydali? Jak reagujeme například na stres? Klient nebude moc rád, když se stránka načte déle než 30 sekund.
Zde vstupuje do hry vykořisťování nebo, jak tomu nyní říkají, devops. Ve skutečnosti jsou to lidé, kteří jsou zodpovědní za provoz produktu, když je již ve výrobě. To zahrnuje různé typy monitorování. Existuje dokonce podtyp testování – testování ve výrobě, kdy si dovolíme něco netestovat před rolloutem a otestovat to hned ve výrobě. Jedná se o sérii opatření z hlediska organizace infrastruktury, která vám umožní rychle reagovat na incident, ovlivnit jej a opravit.
Důležitá je také infrastruktura. Často dochází k situacím, kdy se při testu nelze ujistit, že máme opravdu vše, co bychom klientovi chtěli dát. Zavádíme to do výroby a začínáme chytat nesrozumitelné situace. A to vše proto, že infrastruktura v testu neodpovídá infrastruktuře ve výrobě. To vede k novému typu testování - testování infrastruktury. Jedná se o různé konfigurace, nastavení, migraci databáze atp.
To vyvolává otázku - možná tým potřebuje použít infrastrukturu jako kód.
Věřím, že infrastruktura přímo ovlivňuje kvalitu produktu.
Doufám, že na konferenci bude zpráva se skutečným případem. Napište nám, pokud jste připraveni nám z vlastní zkušenosti sdělit, jak infrastruktura jako kód ovlivňuje kvalitu. Infrastruktura jako kód usnadňuje kontrolu všech nastavení a testování věcí, které jinak prostě nejsou možné. Proto je do procesu vývoje kvalitního produktu zapojen i provoz.
— A co analytika a dokumentace?
Anastasia: To platí spíše pro podnikové systémy. Když mluvíme o podnikání, okamžitě se vybaví lidé, jako jsou analytici a systémoví analytici. Někdy se jim říká techničtí spisovatelé. Dostanou úkol napsat specifikaci a splnit ji třeba měsíc.
Opakovaně bylo prokázáno, že psaní takové dokumentace vede k velmi dlouhým iteracím vývoje a dlouhým iteracím zdokonalování, protože během testovacího procesu jsou identifikovány chyby a začnou se vracet. V důsledku toho existuje spousta smyček, které zvyšují náklady na vývoj. Navíc to může představovat zranitelnosti. Zdá se, že jsme napsali referenční kód, ale pak jsme provedli změny, které narušují dokonale promyšlenou architekturu.
Konečným výsledkem je ne úplně kvalitní produkt, protože v architektuře se již objevily záplaty, kód místy není dostatečně pokryt testy, protože běží termíny, je potřeba rychle uzavřít všechny chyby. A to vše proto, že původní specifikace nezohledňovala všechny body, které je třeba implementovat.
Vývojáři nejsou škůdci a nepíší kód s chybami záměrně.
Pokud bychom na začátku promysleli specifikaci, která by pokryla všechny potřebné body, pak by bylo vše implementováno přesně podle potřeby. Ale to je utopie.
Napsat dokonalou 100stránkovou specifikaci je asi nemožné. Proto je třeba přemýšlet o alternativních způsobech psaní dokumentace, specifikace, nastavení úkolů, které by nás přiblížily k tomu, aby vývojář udělal přesně to, co je potřeba.
Zde přicházejí na mysl přístupy od Agile – uživatelské příběhy s kritérii přijetí. To je více použitelné pro týmy, které se vyvíjejí v malých iteracích.
— A co testování použitelnosti, použitelnost produktu, design?
Anastasia: Toto je velmi důležitý bod, protože v týmu jsou designéři. Nejčastěji jsou designéři využíváni jako služba – buď designovým oddělením, nebo externím designérem. Často dochází k situacím, kdy se zdá, že designér poslouchal produktového specialistu a dělal to, čemu rozuměl. Ale když začneme iteraci, ukáže se, že to, co se ve skutečnosti udělalo, nebylo to, co se očekávalo: designér na něco zapomněl, plně nepromyslel chování, protože není v týmu a není v kontextu, nebo vepředu -end vývojář plně nerozuměl jeho rozložení. Může to trvat několik iterací, protože existuje problém s vývojem front-endu, který rozumí návrhu.
Navíc je tu ještě jeden problém. Designové systémy nyní získávají na popularitě. Jsou na humbuku, ale výhody z nich nejsou úplně zřejmé.
Setkávám se s názorem, že designové systémy na jednu stranu zjednodušují vývoj, ale na druhou stranu hodně omezují rozhraní.
Tím pádem neděláme funkci, kterou chce klient, ale takovou, která se nám hodí, protože už máme určité kostky, ze kterých to můžeme vyrobit.
Myslím, že toto je téma, které stojí za to se na něj podívat a zamyslet se nad tím, zda ve snaze zjednodušit design skutečně řešíme problém klienta.
— Existuje překvapivý počet témat souvisejících se zajišťováním kvality. Existuje v Rusku konference, kde by se o nich dalo diskutovat?
Anastasia: Je tu nejstarší testovací konference, která se letos bude konat již po 25. a jmenuje se SQA Days Quality Assurance Conference. Pojednává především o nástrojích a konkrétních testovacích přístupech pro funkční testery. Zprávy na SQA Days zpravidla hluboce zkoumají konkrétní oblasti v oblasti odpovědnosti samotných testerů, nikoli však komplexní činnosti.
To hodně pomáhá pochopit různé nástroje a přístupy, jak testovat databáze, API atd. Ale zároveň to na jednu stranu nemotivuje zapojit do tvorby lepšího produktu víc než jen testování. Na druhou stranu se testeři nezapojují více do procesu uvažování o globálním cíli produktu a jeho obchodní složky.
Vedu velké oddělení a vedu mnoho pohovorů, které skutečně poskytují vhled do stavu odvětví jako celku. Naši kluci zpravidla pracují v podnicích a mají jasnou oblast odpovědnosti. Kolegové, kteří pracují v zahraničních projektech, používají různé typy testování: sami mohou dělat zátěžové testování, testování výkonu a někdy i testování bezpečnosti, protože skutečně pomáhají týmu zajistit kvalitu produktu.
Přál bych si, aby si i kluci v Rusku začali myslet, že funkčním testováním průmysl nekončí.
— Za tímto účelem pořádáme novou konferenci QualityConf, která se věnuje kvalitě jako nedílné disciplíně. Přibližte nám myšlenku, co je hlavním cílem konference?
Anastasia: Chceme vytvořit komunitu lidí se zájmem vyrábět kvalitní produkty. Nabídněte platformu, kam mohou přijít, vyslechnout si zprávy a po konferenci odejít se specifickým pochopením toho, co je třeba změnit, aby se zlepšila kvalita.
V dnešní době často slýchám z poradny požadavek, co dělat, když jsou problémy s testováním a kvalitou. Když začnete komunikovat s týmy, uvidíte, že problém není v samotných testerech, ale v tom, jak je proces strukturován. Když se například vývojáři domnívají, že jsou zodpovědní pouze za psaní kódu, jejich odpovědnost končí přesně v okamžiku, kdy úkol předají testování.
Ne každý přemýšlí o tom, že špatně napsaný, nekvalitní kód se špatnou architekturou hrozí projektu velké problémy. Nemyslí na cenu chyb, na to, že chyby, které skončí ve výrobě, mohou mít za následek velké náklady pro společnost a tým. Neexistuje žádná kultura, která by o tom měla přemýšlet. Chci, abychom to začali distribuovat na konferenci.
Chápu, že to není inovace.“ Edward Deming, autor 14 principů kvality, psal o ceně chyby již v minulém století. Quality Assurance jako disciplína vychází z této knihy, ale moderní vývoj na ni bohužel zapomíná.
— Plánujete se dotknout přímo témat o testování a nástrojích?
Anastasia: Uznávám, že zprávy o nástrojích budou. Existují celkem univerzální nástroje, kterými mohou firmy a týmy ovlivnit produkt.
Všechny zprávy budou globálně spojovat jedno společné poslání: sdělit publiku, že pomocí tohoto přístupu, nástroje, metody, procesu, typu testování jsme ovlivnili kvalitu produktu a zlepšili život klienta.
Rozhodně nebudeme mít zprávy o nástroji kvůli nástroji. Všechny zprávy zahrnuté v programu budou spojeny společným cílem.
— Koho bude zajímat, o čem mluvíte, koho vidíte jako hosty konference?
Anastasia: Budeme mít reporty pro vývojáře, kterým záleží na osudu jejich projektu, produktu, systému. Stejně tak to bude zajímat testery a zdá se mi, že především manažery. Manažeři mám na mysli lidi, kteří rozhodují a mohou ovlivnit osud a vývoj produktu, systému, týmu.
Jsou to lidé, kteří přemýšlí, jak zlepšit kvalitu produktu nebo systému. Na naší konferenci se seznámí s různými soubory opatření a budou schopni pochopit, co jim nyní vadí a co je třeba změnit.
Myslím, že hlavním kritériem je pochopit, že něco není v pořádku s kvalitou a chtít to ovlivnit. Pravděpodobně se nám nepodaří oslovit lidi, kteří si myslí, že se to povede jen napoprvé.
— Myslíte si, že průmysl jako celek je zralý na to, aby hovořil nejen o testování, ale o kultuře kvality?
Anastasia: Myslím, že jsem dospěl. Nyní se mnoho společností odklání od tradičního přístupu Waterfall k Agile. Je tam zaměření na zákazníka, lidé v týmech opravdu začínají přemýšlet, jak vytvořit kvalitní produkt. I podnikové společnosti se znovu zaměřují na zlepšování kvality.
Soudě podle počtu žádostí, které se v komunitě objevují, věřím, že je čas. Nejsem si samozřejmě jistý, že to bude revoluce velkého rozsahu, ale byl bych rád, kdyby k této revoluci ve vědomí došlo.
- Souhlas! Budeme vštěpovat kulturu a měnit vědomí.
Konference o kvalitním vývoji IT produktů držený v Moskvě 7. června. Víte, z jakých fází se skládá vysoce kvalitní produkt, máme případy úspěšného boje s chybami ve výrobě, otestovali jsme oblíbené metody v naší praxi - potřebujeme vaše zkušenosti. jejich přihlášky do 1. květnaa Programový výbor pomůže zaměřit téma na celkovou integritu konference.
Připojit k , ve kterém diskutujeme o otázkách kvality a konferenci, přihlaste se k odběru abyste byli informováni o programových novinkách.
Zdroj: www.habr.com