Ahoj, Habr!
Máme nové důležité téma – kvalitní vývoj IT produktů. Často hovoříme na HighLoad++ o tom, jak zrychlit přetížené služby, a na Frontend Conf o skvělém uživatelském rozhraní, které nezpomaluje. Pravidelně se zabýváme testováním, a na DevOpsConf o spojení různých procesů, včetně testování. Ale o tom, co lze nazvat kvalitu jako celek, a jak na ní komplexně pracovat – o tom se nemluví.
Opraveno na – budeme rozvíjet kulturu přemýšlet o kvalitě konečného produktu pro uživatele v každé fázi vývoje. Zvyk neuzavírat se do své zóny odpovědnosti a asociovat kvalitu nejen se testery.
Pod článkem si pohovoříme s předsedkyní programového výboru, vedoucí testování ve Tinkoff.Biz, tvůrkyní ruského QA společenství Anastasijí Aseevou-Nguen o stavu odvětví QA a misi nové konference.
– Nasty, ahoj. Prosím, řekni něco o sobě.
Anastasia: Vedla jsem testování v bance, odpovídám za velmi velký tým – nás je víc než 90. Máme důležitou obchodní linii, zodpovídáme za ekosystém pro právnické osoby.
Studovala jsem na mechmatě a původně jsem chtěla být programátorkou. Ale když se mi objevila zajímavá nabídka, rozhodla jsem se vyzkoušet si roli testera. Jak překvapivé, ukázalo se, že je to moje posláním. Nyní vidím svou práci právě v tomto odvětví.
Jsem vášnivou zastánkyní disciplíny Quality Assurance. Záleží mi na tom, jaké produkty se vytvářejí, jak se v rámci firmy, týmu a v průběhu vývoje vztahují k kvalitě.
Pro mě je jasné, že komunita v této oblasti není dostatečně vyspělá, alespoň v Rusku. Ne vždy chápeme, že zajištění kvality není jen fakt testování aplikace na shodu s požadavky. Ráda bych tuto situaci změnila.
– Používáš slova Quality Assurance a testování. V očích laika se tyto dva termíny často překrývají. Jak se liší, pokud se do toho ponoříme?
Anastasia: Spíše se neliší. Testování je součástí disciplíny Quality Assurance, což je přímá činnost — samotný fakt, že něco testuji. Druhů testování je ve skutečnosti velmi mnoho a za různé typy testování odpovídají zcela různí lidé. Ale u nás v Rusku, když se objevila vlna outsourců, kteří dodávají testery do společností, se testování zúžilo na jediné.
Ve většině případů se omezují pouze na funkční testování: kontrolují, že to, co naprogramovali vývojáři, odpovídá specifikaci a všemu.
— Řekni mi prosím, jaké další disciplíny zajištění kvality existují? Co dalšího kromě testování sem spadá?
Anastasia: Quality Assurance je především o vytváření kvalitního produktu. Tedy se ptáme, jaké atributy kvality by měl náš produkt mít. Pokud tomu rozumíme, můžeme také zjistit, kdo ovlivňuje tyto atributy kvality. Není důležité, zda je to vývojář, projektový manažer nebo produktový manager. — To je osoba, která ovlivňuje rozvoj produktu, jeho backlog a jeho strategii.
Tester si začíná lépe uvědomovat svou roli. Chápe, že jeho úkolem není pouze testovat shodu s požadavky, ale také testovat požadavky, zpochybňovat formulace, které vycházejí od produktového manažera, odhalovat všechna nejasná požadavky a očekávání zákazníka. Když dodáváme novou funkčnost našemu klientovi, musíme skutečně splnit jeho očekávání a vyřešit jeho problémy. Pokud budeme myslet na všechny atributy kvality, zákazník bude spokojen a bude chápat, že společnost, jejíž produkt používá, se skutečně stará o jeho zájmy, a nepracuje na principu "jen vydat funkci".
— Zdá se, že to, co jsi teď popsala, je úkol produktového manažera. To vlastně není o testování a ne o kvalitě — to je vlastně o managementu produktu, že?
Anastasia: Částečně. Quality Assurance není disciplína, za kterou odpovídá jeden konkrétní člověk. Nyní existuje populární směr v testování, přístup, který se nazývá Agile TestingV jeho definici se přímo uvádí, že se jedná o týmový přístup k testování, který zahrnuje určitý soubor praktik. Za realizaci tohoto přístupu nese odpovědnost celý tým, není ani nutné, aby v týmu byl tester. Celý tým se zaměřuje na to, aby dodal hodnotu zákazníkovi, a aby tato hodnota odpovídala jeho očekáváním.
— Takže kvalita se překrývá téměř se všemi okolními disciplínami, klade rámce na vše kolem?
Anastasia: Správně. Když přemýšlíme o tom, co chceme vytvořit kvalitní produkt, začínáme uvažovat o různých aspektech kvality. Například jak ověřit, že jsme skutečně vytvořili funkci, která je našemu zákazníkovi potřeba.
Zde se objevuje takový typ testování, jako UAT (testování akceptace uživateli). Bohužel, v Rusku se zřídka praktikuje, ale někdy se vyskytuje v SCRUM týmech jako demonstrace pro koncového zákazníka. V zahraničních firmách je to dost rozšířený typ testování. Před tím, než zpřístupníme funkcionalitu všem zákazníkům, nejprve provádíme UAT, což znamená, že pozveme koncového uživatele, který provádí testování a okamžitě poskytuje zpětnou vazbu — zda produkt skutečně odpovídá očekáváním a řeší problém. Teprve poté probíhá škálování pro všechny ostatní zákazníky.
Takže se zaměřujeme na byznys, na koncového zákazníka, ale přitom nezapomínáme na technologie. Na kvalitě produktu také výrazně závisí technologie. Pokud budeme mít špatnou architekturu, nebudeme moci rychle uvolňovat funkce a splňovat očekávání zákazníka. Mohou se objevit mnohé chyby při pokusu o škálování, nebo při pokusu o refactoring něco můžeme rozbít. To všechno ovlivní spokojenost zákazníka.
Z tohoto hlediska by architektura měla být taková, abychom mohli psát čistý kód, který umožní rychlé změny a strachovat se o to, že všechno rozbijeme. Aby iterace vylepšení nebyly roztaženy na několik měsíců jen proto, že máme tolik legacy a je potřeba provádět dlouhé testovací fáze.
— A už jsou zapojeni vývojáři, architekti, produktoví manažeři, sami testeři. Kdo další je zapojen do procesu zajištění kvality?
Anastasia: Představme si, že jsme již doručili funkci klientovi. Je samozřejmé, že je třeba sledovat kvalitu produktu, i když je již v produkci. V této fázi se mohou objevit situace s nejasnými scénáři, takzvané chyby.
První otázka je, jak pracujeme s těmito chybami poté, co jsme produkt již vydali? Jak například reagujeme na zátěž? Klient nebude příliš spokojen, pokud se stránka načítá déle než 30 sekund.
Zde vstupuje do hry provoz, nebo jak se nyní říká, DevOps. Ve skutečnosti jsou to lidé, kteří odpovídají za provoz produktu, když už je na produkci. Sem spadají různé druhy monitorování. Existuje dokonce podtyp testování - testování v produkci, kdy si dovolujeme něco netestovat před nasazením a testujeme to přímo v produkci. Jedná se o řadu opatření z pohledu organizace infrastruktury, která umožňují rychle reagovat na incident, ovlivnit ho a opravit.
Infrastruktura je také důležitá. Často se stává, že během testu není možné ověřit, že máme skutečně to, co bychom chtěli dát klientovi. Nasadíme na produkci a začneme chytat nejasné situace. A to všechno proto, že infrastruktura v testu neodpovídá infrastruktuře na produkci. Odtud vzniká nový typ testování - testování infrastruktury. To zahrnuje různé konfigurace, nastavení, migraci databází atd.
Odtud vyvstává otázka - možná by tým měl použít infrastrukturu jako kód.
Věřím, že infrastruktura výrazně ovlivňuje kvalitu produktu.
Doufám, že na konferenci bude přednáška s reálným příkladem. Napište nám, pokud jste ochotni sdílet zkušenosti o tom, jak infrastruktura jako kód ovlivňuje kvalitu. Infrastruktura jako kód umožňuje snadnější kontrolu všech nastavení a testování toho, co jinak není možné. Proto se do procesu vývoje kvalitního produktu zapojuje také provoz.
— A co analytika a dokumentace?
Anastasia: To se více týká enterprise systémů. Když mluvíme o enterprise, hned nás napadnou lidé jako analytici a systémoví analytici. Někdy se jim říká technické spisovatelé. Dostávají úkol na sepsání specifikace a plní ho, například měsíc.
Bylo opakovaně prokázáno, že vytváření takové dokumentace vede k velmi dlouhým iteracím vývoje a dalším dlouhým iteracím úprav, protože během testování se objevují chyby, které je třeba vracet. V důsledku toho se objevuje spousta smyček, které zvyšují náklady na vývoj. Navíc to může vést k zranitelnostem. Jakoby jsme napsali referenční kód, ale následné změny mohou rozbít dokonale promyšlenou architekturu.
Výsledkem je tedy produkt, který není zcela kvalitní, protože v architektuře se již objevily záplaty, kód není v některých místech dostatečně pokryt testy, protože se tlačí na čas, je potřeba rychle vyřešit všechny chyby. A to všechno proto, že v původní specifikaci nebyly brány v úvahu všechny aspekty, které je nutné realizovat.
Vývojáři nejsou škůdci a nepíšou úmyslně chybový kód.
Kdybychom původně promysleli specifikaci, která by pokryla všechny potřebné aspekty, realizovali bychom vše tak, jak je potřeba. Ale to je utopie.
Možná je nemožné napsat ideální specifikaci na 100 stranách. Proto je třeba přemýšlet o alternativních způsobech psaní dokumentace, specifikování, formulování úkolů, které by nás přiblížily k tomu, aby vývojář dělal přesně to, co je potřeba.
Přicházejí na mysl přístupy z Agile – uživatelské příběhy s akceptačními kritérii. To je více aplikovatelné pro týmy, které postupují malými iteracemi.
– Co se týče testování použitelnosti, komfortu používání produktu, designu?
Anastasia: To je velmi důležitý moment, protože v týmu jsou designéři. Nejčastěji se designérům využívá jako služby – buď designérský tým, nebo designér na outsourcingu. Často se stává, že designér vyslechne produktového manažera a udělá to, co pochopil. Ale když přijdeme k iteraci, ukáže se, že ve skutečnosti nebylo uděláno to, co jsme očekávali: designér na něco zapomněl, nedokonale promyslel chování, protože není v týmu a nemá kontext, nebo front-end vývojář nepochopil jeho návrh. Možná bude potřeba několik iterací jen kvůli tomu, že je problém s pochopením designu front-end vývojářem.
Existuje také další problém. V současnosti získávají na popularitě designové systémy. Jsou v kurzu, ale přínosy z nich nejsou zcela zřejmé.
Setkávám se s názorem, že designové systémy na jedné straně usnadňují vývoj, na druhé straně však kladou mnoho omezení na rozhraní.
Nakonec nevytváříme takovou funkci, kterou si klient přeje, ale takovou, která je pohodlná pro nás, protože již máme určité bloky, ze kterých ji můžeme vytvořit.
Myslím, že by stálo za to zamyslet se nad tím, zda si skutečně v úsilí o zjednodušení práce na designu odstraňujeme bolest klienta.
— Vzniká překvapivě hodně témat týkajících se zajištění kvality. Existuje v Rusku konference, kde se o nich všechno může prodiskutovat?
Anastasia: Existuje nejstarší konference o testování, která se letos koná po 25. a nazývá se jednoduše – Konference o zajištění kvality SQA Days. Hlavně se na ní diskutují nástroje a konkrétní přístupy k testování pro funkční testery. Obvykle se na SQA Days hlouběji zkoumá konkrétní oblasti v rámci odpovědnosti samotných testerů, ale nikoli komplexní akce.
To opravdu pomáhá porozumět různým nástrojům a přístupům, jak testovat databáze, API atd. Ale na druhé straně to nemotivuje zapojit do vytváření kvalitnějšího produktu nejen testování. Na druhou stranu se testeři nestávají více zapojenými do procesu, aby přemýšleli o globálním cíli produktu a jeho obchodní složce.
Vedou velký tým, vedu mnoho pohovorů, které v podstatě umožňují představit stav odvětví. Obvykle naši lidé pracují v enterprise a mají jasnou zónu odpovědnosti. Kolegové, kteří pracují na zahraničních projektech, využívají různé druhy testování: mohou provádět zátěžové testování, testování výkonu a dokonce i občas testování bezpečnosti, protože skutečně pomáhají týmu zajistit kvalitní produkt.
Rád bych, aby se i naši lidé v Rusku začali zamýšlet nad tím, že na funkčním testování odvětví nekončí.
— Pro to jsme uspořádali novou konferenci QualityConf, která se věnuje kvalitě jako celkové disciplíně. Můžeš podrobněji popsat, o co jde, jaký je hlavní cíl konference?
Anastasia: Chceme vytvořit komunitu lidí, kteří mají zájem vyvíjet kvalitní produkty. Poskytnout prostor, kam mohou přijít, poslechnout si přednášky a po konferenci odejít s konkrétním pochopením toho, co je třeba změnit ve svém přístupu ke zlepšení kvality.
Často nyní slyším dotazy od konzultantů, co dělat, když existují problémy s testováním a kvalitou. Když začnete komunikovat s týmy, vidíte, že problém není ve samotných testerech, ale v tom, jak je proces nastaven. Například když vývojáři považují, že jsou odpovědní pouze za psaní kódu, jejich odpovědnost končí přesně v okamžiku, kdy předali úkol k testování.
Ne všichni přemýšlejí o tom, že špatně napsaný nekvalitní kód se špatnou architekturou hrozí velkými problémy pro projekt. Nerozvažují náklady na chyby, to, že chyby, které se dostanou do produkce, mohou způsobit značné náklady pro společnost a tým. Neexistuje kultura zabývat se tímto. Chci, aby na konferenci jsme začali tuto kulturu šířit.
Chápu, že to není novinka. Edward Deming, autor 14 postulátů kvality, psal o nákladech na chybu už v minulém století. Tento princip je základem Quality Assurance jako disciplíny, ale, bohužel, současný vývoj na to zapomíná.
— A plánujete také se dotknout témat přímo souvisejících s testováním a nástroji?
Anastasia: Předpokládám, že budou přednášky o nástrojích. Existují dostatečně univerzální nástroje, pomocí kterých mohou společnosti a týmy ovlivnit produkt.
Všechny přednášky budou globálně spojeny jednou společnou misí: předat publiku, že pomocí tohoto přístupu, nástroje, metody, procesu nebo typu testování jsme ovlivnili kvalitu produktu a zlepšili život klienta.
Určitě nebudeme mít přednášky o nástroji pro nástroj. Všechny přednášky, které se dostanou do programu, budou spojeny společným cílem.
— Kdo by měl zájem o to, o čem mluvíš, koho vidíš jako hosty konference?
Anastasia: Na naší konferenci budou prezentace pro vývojáře, kterým není lhostejný osud jejich projektu, produktu nebo systému. Bude to zajímat také testery a zejména manažery. Pod manažery mám na mysli ty, kteří přijímají rozhodnutí a mohou ovlivnit osud a rozvoj produktu, systému či týmu.
Jsou to lidé, kteří si kladou otázku, jak zvýšit kvalitu produktu a systému. Na naší konferenci se dozvědí o různých souborech aktivit a budou moci pochopit, co mají nyní špatně, co je potřeba změnit.
Myslím, že hlavním kritériem je uvědomit si, že s kvalitou není něco v pořádku, a chtít na to mít vliv. Asi se nám nepodaří oslovit lidi, kteří si myslí, že to takhle stačí, na poprvé.
— Jak si myslíš, je už odvětví dostatečně vyspělé na to, abychom hovořili nejen o testování, ale o kultuře kvality?
Anastasia: Myslím, že už je. Mnoho firem nyní odchází od tradičního přístupu Waterfall směrem k Agile. Je kladen důraz na zákazníka a lidé v týmech skutečně začínají přemýšlet o tom, jak vytvořit kvalitní produkt. I ve velkých podnicích probíhá přesměrování na zvyšování kvality.
Soudě podle množství dotazů, které se objevují ve společenství, si myslím, že už je na čase. Samozřejmě si nejsem jista, že to bude rozsáhlá revoluce, ale ráda bych, aby k této změně v myslích došlo.
— Dohodnuto! Budeme šířit kulturu a měnit myšlení.
Konference o kvalitní vývoji IT produktů se uskuteční v Moskvě 7. června. Víte, z jakých etap se skládá kvalitní produkt, máme případy úspěšného boje s chybami na produkci, a na vlastní praxi jsme otestovali populární metody — potřebujeme vaše zkušenosti. své přihlášky do 1. května, a Programový výbor pomůže zaměřit téma pro celkovou soudržnost konference.
Připojte se k , kde diskutujeme otázky kvality a konferenci, přihlaste se k odběru , abyste byli v obraze o novinkách programu.
Zdroj: habr.com
