Helló, Habr!
Új, fontos témánk van - az IT-termékek minőségi fejlesztése. Gyakran beszélünk a HighLoad++-on arról, hogyan lehet a terhelt szolgáltatásokat gyorsabbá tenni, és a Frontend Conf-on egy nagyszerű felhasználói felületről, amely nem akadozik. Rendszeresen van téma a tesztelésről, és a DevOpsConf az különböző folyamatok, beleértve a tesztelést, összevonásáról. De arról, hogy mit nevezhetünk minőségnek általában, és hogyan lehet ezzel átfogóan foglalkozni - nem beszélünk.
Javítani fogjuk — fejleszteni fogjuk a felhasználó végső termékének minőségével való gondolkodás kultúráját a fejlesztés minden szakaszában. Azok a szokások, hogy ne ragadjunk le a saját felelősségünk körén, és a minőséget ne csak a tesztelőkkel társítsuk.
A lapon beszélgetünk a programbizottság elnökével, a Tinkoff üzletág teszteléséért felelős vezetőjével, aki a orosz nyelvű QA közönséget is létrehozta. Asztal Aseeva-Nguen a QA iparág állapotáról és az új konferencia küldetéséről.
— Szia, Nasztya. Kérlek, mesélj magadról.
Asztal: A tesztelést irányítom a bankban, egy nagyon nagy csapatért felelek - több mint 90 ember vagyunk. Fontos üzleti vonalunk van, az üzleti ügyfelek számára ökoszisztémáért felelünk.
Matematikai és fizikai tanulmányokat folytattam, és eredetileg programozó szerettem volna lenni. De amikor egy izgalmas ajánlatot kaptam, úgy döntöttem, hogy kipróbálom magam tesztelőként. Furcsa módon, ez lett a hivatásom. Most az egész munkámat ebben az iparágban látom.
Elkötelezett híve vagyok a Quality Assurance (QA) diszciplínának. Nem közömbös számomra, milyen termékek készülnek, hogy a cégen belül, a csapatban és általánosságban hogyan viszonyulnak a minőséghez a fejlesztési folyamat során.
Számomra nyilvánvaló, hogy a közösség ezen a területen még nem elég érett, legalábbis Oroszországban. Nem mindig értjük, hogy a minőség biztosítása nem csak a követelményeknek való megfelelés tesztelésének ténye. Szeretném megváltoztatni ezt a helyzetet.
— Te a Quality Assurance és a tesztelés szavait használod. Ezek a két kifejezés a laikusok szemében nagyon gyakran átfedik egymást. Miben különböznek, ha mélyebben elásunk?
Asztal: Valójában nem különböznek. A tesztelés a minőségbiztosítás részét képezi, ez egy közvetlen tevékenység – az a tény, hogy tesztelek valamit. Valójában nagyon sokféle tesztelés létezik, és a különféle tesztelési típusokért a legkülönbözőbb emberek felelnek. De Oroszországban, amikor megjelentek azok az outsourcing cégek, amelyek tesztelőket biztosítanak a vállalatoknak, a tesztelés lényegében egyetlen típusra korlátozódott.
Többnyire csak a funkcionális tesztelésre korlátozódnak: ellenőrzik, hogy amit a fejlesztők kódoltak, megfelel-e a specifikációnak, és ennyi.
– Kérlek, mesélj, milyen egyéb minőségbiztosítási diszciplínák léteznek még? Mi minden tartozik még ide a tesztelésen kívül?
Asztal: A minőségbiztosítás elsősorban a minőségi termék létrehozásáról szól. Azaz azt a kérdést tesszük fel, hogy milyen minőségi attribútumokkal kell rendelkeznie a termékünknek. Ha ezt megértjük, akkor össze tudjuk hasonlítani, hogy ki befolyásolja ezeket a minőségi attribútumokat. Nem számít, fejlesztő, projektmenedzser vagy termékfejlesztő – ez az ember, aki befolyásolja a termék fejlődését, a backlogját, a stratégiáját.
A tesztelő jobban kezdi tudatosítani a szerepét. Megérti, hogy nemcsak a követelményeknek való megfelelés tesztelése a feladata, hanem a követelmények tesztelése is, megkérdőjelezni a termékfejlesztőtől származó megfogalmazásokat, felfedni minden rejtett követelményt és ügyféle várakozást. Amikor új funkcionalitást biztosítunk az ügyfélnek, valóban meg kell elégednünk az elvárásaival és meg kell oldanunk a fájdalmát. Ha minden minőségi attribútumról gondolkodunk, az ügyfél elégedett lesz, és meg fogja érteni, hogy a vállalat, amelynek a termékét használja, valóban törődik az érdekeivel, és nem csupán az a célja, hogy „csak feladjon egy fejlesztést”.
– Úgy tűnik, amit most leírtál, az a termékfejlesztő feladata. Alapvetően nem a tesztelésről és nem a minőségről szól – ez valójában a termékmenedzsmentről szól, nem igaz?
Asztal: Részben. A minőségbiztosítás nem egy olyan diszciplína, amelyért egyetlen konkrét ember felel. Jelenleg van egy népszerű irányzat a tesztelésben, egy megközelítés, amelyet Agile TestingA meghatározásában világosan szerepel, hogy ez egy csapatmegközelítés a teszteléshez, amely magába foglal egy bizonyos gyakorlatkészletet. E megközelítés megvalósításáért az egész csapat felelős, nem szükséges, hogy a csapatban tesztelő is legyen. Az egész csapat arra összpontosít, hogy értéket nyújtson az ügyfél számára, és hogy ez az érték megfeleljen az elvárásainak.
— Tehát a minőség szinte minden környező tudománnyal átfedésben van, keretet szabva mindennek?
Asztal: Helyes. Amikor azon gondolkodunk, hogy minőségi terméket szeretnénk létrehozni, elkezdünk gondolkodni a különböző minőségparamétereken. Például, hogyan ellenőrizzük, hogy valóban olyan funkciót hoztunk létre, amire szüksége van az ügyfelünknek.
Itt felmerül egy olyan tesztelési forma, mint UAT (felhasználói elfogadási tesztelés). Sajnos Oroszországban ritkán alkalmazzák, de néha előfordul a SCRUM-csapatokban, mint bemutató a végfelhasználónak. A külföldi cégeknél ez egy elég gyakori tesztelési forma. Mielőtt megnyitnánk a funkcionalitást minden ügyfél számára, először UAT-t végzünk, azaz meghívjuk a végfelhasználót, aki tesztelést végez és azonnal visszajelzést ad — valóban megfelel-e a termék az elvárásoknak és megoldja-e a problémát. Csak ezután történik a skálázás a többi ügyfélre.
Tehát mi az üzletre, a végfelhasználóra fókuszálunk, de közben nem feledkezünk meg a technológiáról. A technológiák is erősen befolyásolják a termék minőségét. Ha gyenge az architektúra, nem tudunk gyorsan új funkciókat kiadni, és megfelelni az ügyfél elvárásainak. Sok hiba léphet fel a skálázási kísérletek során, vagy a refaktorálás közben valamit tönkretehetünk. Mindez hatással lesz az ügyfélelégedettségre.
E szempontból az architektúrának úgy kell lennie, hogy tiszta kódot tudjunk írni, amely lehetővé teszi a gyors módosításokat, anélkül hogy attól kellene tartanunk, hogy mindent összetörünk. Annak érdekében, hogy a fejlesztési iterációk ne nyúljanak hónapokig, pusztán azért, mert annyi örökség áll rendelkezésünkre, és hosszan tartó tesztelési szakaszokat kell végeznünk.
— Tehát már bevonva vannak fejlesztők, architektek, termékfejlesztők, termékmenedzserek és maguk a tesztelők. Ki még szerepel a minőségbiztosítási folyamatban?
Asztal: Tegyük fel, hogy már átadtuk az ügyfélnek a funkciót. Nyilvánvaló, hogy figyelni kell a termék minőségére, amikor az már a termelésben van. Ezen a ponton előfordulhatnak olyan helyzetek, amelyek nem nyilvánvalóak, úgynevezett hibák.
Az első kérdés az, hogy hogyan foglalkozunk ezekkel a hibákkal, miután már kiadtuk a terméket? Hogyan reagálunk például a terhelésre? Az ügyfél nem fog örülni, ha az oldal betöltési ideje meghaladja a 30 másodpercet.
Ekkor lép be a képbe a működtetés, vagy ahogy most már hivatalosan hívják, DevOps. Valójában ezek azok az emberek, akik felelősek a termék működtetéséért, amikor az már a termelésben van. Ide különböző típusú megfigyelések tartoznak. Van egy külön tesztelési alfaj is - az élő tesztelés, amikor megengedjük magunknak, hogy valamit ne teszteljünk a kiadás előtt, és közvetlenül az élő rendszerben tesztelünk. Ez egy sor intézkedés a infrastruktúra szervezésének szempontjából, amely lehetővé teszi, hogy gyorsan reagáljunk egy eseményre, hatással legyünk arra, és javítsuk azt.
Az infrastruktúra is fontos. Gyakran előfordul, hogy a tesztelés során lehetetlen megbizonyosodni arról, hogy minden megvalósult, amit az ügyfélnek szeretnénk nyújtani. Kiadjuk az élő rendszerbe - és elkezdjük fogni a nem nyilvánvaló helyzeteket. Ennek az az oka, hogy a tesztinfrastruktúra nem felel meg a termelési infrastruktúrának. Így merül fel egy új tesztelési típus - az infrastruktúra tesztelése. Ezek különböző konfigurációk, beállítások, adatbázisok migrálása stb.
Ezután felmerül a kérdés - lehet, hogy a csapatnak az infrastruktúráért mint kódért kell dolgoznia.
Hiszek abban, hogy az infrastruktúra közvetlenül befolyásolja a termék minőségét.
Remélem, hogy a konferencián lesz egy előadás valós esettel. Írjon nekünk, ha kész megosztani a tapasztalatait arról, hogyan befolyásolja az infrastruktúra mint kód a minőséget. Az infrastruktúra mint kód lehetővé teszi a beállítások egyszerűbb ellenőrzését és olyan tesztelést, amely máskülönben lehetetlen lenne. Ezért a minőségi termék fejlesztési folyamatába a működtetés is bevonódik.
— És mi a helyzet az elemzéssel és a dokumentációval?
Asztal: Ez inkább az enterprise rendszerekre vonatkozik. Amikor az enterprise-ról beszélünk, azonnal olyan emberek jutnak eszünkbe, mint az elemzők és a rendszeranalitikusok. Néha technikai íróknak is nevezik őket. Ők megkapják a feladatot, hogy speciifikációt írjanak, és általában egy hónapig dolgoznak rajta.
Többször bizonyították, hogy az ilyen dokumentáció írása nagyon hosszú fejlesztési iterációkhoz és hosszú utólagos javításokhoz vezet, mert a tesztelés során hibák kerülnek elő, és visszavonások kezdődnek. Ennek következtében nagyon sok hurkot generál, amelyek növelik a fejlesztési költségeket. Ezen kívül ez sebezhetőségeket is bevezethet. Úgy tűnik, hogy írtunk egy mintakódot, de később olyan változtatásokat hajtottunk végre, amelyek tönkretették a tökéletesen megtervezett architektúrát.
A végeredmény nem egy igazán minőségi termék, mert az architektúrában már keletkeztek foltok, a kód bizonyos részei nem elégségesen vannak tesztelve, mert az idő szorít, gyorsan be kell zárni minden hibát. Mindez azért van, mert az eredeti specifikációban nem vették figyelembe az összes olyan dolgot, amelyet meg kellett volna valósítani.
A fejlesztők nem rosszindulatúak, és nem szándékosan írnak hibás kódot.
Ha kezdetben átgondoltuk volna a specifikációt, amelyben minden szükséges szempont szerepel, akkor minden pontosan úgy valósult volna meg, ahogyan kellene. De ez utópia.
Valószínűleg lehetetlen megírni a tökéletes, 100 oldalas specifikációt. Ezért el kell gondolkodnunk alternatív dokumentációs írási módszereken,a specifikálásra, a feladatkiadásra, amelyek közelítenek ahhoz, hogy a fejlesztő pontosan azt csinálja, ami szükséges.
Itt jutnak eszembe az Agile megközelítések—felhasználói sztorik elfogadási kritériumokkal. Ez inkább alkalmazható olyan csapatok számára, amelyek kis iterációkban fejlődnek.
— Mi a helyzet a használhatósági teszteléssel, a termék használatának kényelmével, a dizájnnal?
Asztal: Ez egy nagyon fontos szempont, mert a csapatban vannak tervezők. Leggyakrabban a tervezőket szolgáltatásként használják—akár egy tervezőosztály, akár egy külső tervező. Gyakran előfordul, hogy úgy tűnik, a tervező meghallgatta a termékmenedzsert, és azt csinálta, amit értett. De amikor megkezdjük az iterációt, kiderül, hogy valójában nem azt készítették el, amit vártunk: a tervező valamit elfelejtett, nem gondolta végig teljesen a viselkedést, mert nem a csapatban van, és nem is az összefüggésben, vagy a frontend fejlesztő nem értette meg teljesen a tervét. Számos iteráció szükséges lehet csupán azért, mert félreértés van a frontend fejlesztő és a design között.
Van egy másik probléma is. Jelenleg egyre népszerűbbek a dizájn rendszerek. Magas hype alatt állnak, de a belőlük származó előnyök nem teljesen nyilvánvalók.
Találkozom azzal a véleménnyel, hogy a dizájn rendszerek egyrészt megkönnyítik a fejlesztést, másrészt viszont nagyon sok korlátozást rónak az interfészre.
Ennek eredményeként nem olyan funkciót készítünk, amit az ügyfél szeretne, hanem olyat, amely nekünk kényelmes, mert már vannak bizonyos blokkjaink, amikből megvalósíthatjuk.
Úgy érzem, érdemes lenne figyelmet fordítani erre a témára és elgondolkodni, hogy valóban az ügyfél fájdalmát oldjuk-e meg a dizájn munkájának egyszerűsítésében.
— Meglehetősen sok téma merül fel a Quality Assurance körül. Oroszországban van konferencia, ahol mindezeket meg lehet beszélni?
Asztal: Van egy legrégebbi tesztelési konferencia, amely idén 25. alkalommal kerül megrendezésre, és SQA Days Quality Assurance Conference néven ismert. Főként eszközöket és specifikus megközelítéseket beszélnek meg funkcionális tesztelőknek. Általában a SQA Days előadásaiban mélyen vizsgálják a tesztelők felelősségi körébe tartozó egyes területeket, de nem komplex eseményeket.
Ez nagyon segít tisztázni a különböző eszközöket és megközelítéseket, mint a databázisok, API-k tesztelése, stb. Ugyanakkor nem motiválja arra, hogy ne csak a tesztelés, hanem más is részt vegyen a minőségi termék létrehozásában. Másrészt a tesztelők nem válnak jobban bevonódottá a folyamatba, hogy a termék globális céljaira és üzleti összetevőire gondoljanak.
Összefogom egy nagy részleg munkáját, sok interjút tartok, amelyek valójában lehetőséget adnak arra, hogy megismerjem az iparág állapotát. Szabályosan a srácaink az enterprise szektorban dolgoznak, és pontos felelősségi körük van. Azok a kollégák, akik külföldi projekteken dolgoznak, különböző tesztelési típusokat alkalmaznak: ők maguk végzik a terheléses tesztelést, a teljesítménytesztelést, és néha még a biztonsági tesztelést is, mert valóban segítenek a csapatnak a termék minőségének biztosításában.
Szeretném, ha Oroszországban a srácok is elkezdenének gondolkodni arról, hogy a funkcionális tesztelés nagyobb ipar nem fejeződik be.
— Ezért szervezzük meg az új QualityConf konferenciát, amely a minőség átfogó tudományával foglalkozik. Mesélj a koncepcióról részletesebben, mi a konferencia fő célja?
Asztal: Azt szeretnénk, hogy a minőségi termékek iránt érdeklődők közösségét hozzuk létre. Olyan platformot kínálunk, ahová eljöhetnek, meghallgathatják a bemutatókat, és a konferencia után konkrét megértéssel távozhatnak arról, mit kell megváltoztatniuk a minőség javítása érdekében.
Mostanában gyakran hallom a tanácsadói kérelem, hogy mit tegyenek, ha problémák merülnek fel a teszteléssel és a minőséggel kapcsolatban. Amikor elkezdesz beszélgetni a csapatokkal, látod, hogy a probléma nem magukban a tesztelőhibákban rejlik, hanem abban, hogy hogyan van felépítve a folyamat. Például, ha a fejlesztők úgy vélik, hogy csak a kód írásáért felelősek, a felelősségük pontosan abban a pillanatban véget ér, amikor átadják a feladatot tesztelésre.
Nem mindenki gondolkodik el azon, hogy a rosszul megírt, nem minőségi kód és a gyenge architektúra komoly problémákat okozhat a projekt számára. Nem gondolnak az hibák költségeire, arra, hogy a termelésbe került hibák jelentős költségeket eredményezhetnek a vállalat és a csapat számára. Nincs kultúrája az ilyen dolgok átgondolásának. Szeretném, ha a konferencián elkezdenénk ezt népszerűsíteni.
Tudom, hogy ez nem újítás. Edward Deming, a minőség 14 posztulátumának szerzője, már a múlt században írt a hibák költségéről. Ezen a könyven alapul a Quality Assurance mint tudományág, de sajnos a modern fejlesztés ezt elfelejti.
— Terveitek vannak a teszteléssel és az eszközökkel kapcsolatos témák érintésére?
Asztal: El tudom képzelni, hogy lesznek bemutatók az eszközökről. Vannak elég univerzális eszközök, amelyek segítségével a cégek és a csapatok befolyásolhatják a terméket.
Minden bemutató globálisan egy közös küldetés köré fog összpontosulni: közvetíteni a közönségnek, hogy ezzel a megközelítéssel, eszközzel, módszerrel, folyamattal vagy tesztelési típussal befolyásoltuk a termék minőségét és javítottuk az ügyfél életét.
Nálunk biztosan nem lesznek bemutatók az eszközök önmagukért való bemutatására. Minden olyan bemutató, ami bekerül a programba, közös céllal lesz összekötve.
— Ki érdeklődne az iránt, amiről beszélsz, kit látsz a konferencia vendégei között?
Asztal: Lesznek előadások a fejlesztők számára, akiket érdekel a projektjük, termékük, rendszerük sorsa. Hasonlóképpen érdekes lesz a tesztelők számára is, és úgy gondolom, különösen a menedzsereknek. Itt a menedzserek alatt azokat a személyeket értem, akik döntéseket hoznak, és befolyásolni tudják a termék, rendszer, csapat sorsát és fejlődését is.
Ezek olyan emberek, akik azt kérdezik, hogyan javíthatnák a termék, rendszer minőségét. A konferencián különböző intézkedési komplexumokat ismerhetnek meg, és megérthetik, hogy mi nincs rendben most, és mit kellene megváltoztatniuk.
Úgy gondolom, a fő kritérium az, hogy megértsük, hogy a minőséggel valami nincs rendben, és hajlandóak legyünk befolyásolni ezt. Valószínűleg nem sikerül elsőre elérni azokat, akik azt hiszik, hogy így is jó lesz.
— Mit gondolsz, hogy a szektor készen áll arra, hogy ne csak a tesztelésről, hanem a minőség kultúrájáról beszélgessünk?
Asztal: Úgy vélem, hogy készen áll. Jelenleg sok cég eltávolodik a hagyományos Waterfall megközelítéstől az Agile irányába. A fókusz az ügyfélre irányul, az emberek a csapatokban valóban elkezdik mérlegelni, hogyan készíthetnek minőségi terméket. Még az enterprise cégeknél is zajlik az átállás a minőség javítására.
A közösségben felmerülő kérdések mennyisége alapján azt gondolom, itt az ideje. Nem vagyok biztos benne, hogy ez egy nagyszabású forradalom lesz, de szeretném, ha ez a tudatbeli fordulat bekövetkezne.
— Egyetértettünk! Fogunk kultúrát építeni és megváltoztatni a gondolkodást.
Konferencia a minőségi IT termékfejlesztésről lesz Moszkvában, június 7-én. Tudják, hogy miből áll egy minőségi termék, van tapasztalatunk a hibák sikeres kezeléséről a termelésben, és saját tapasztalatainkkal is bizonyítottuk népszerű módszereket — szükségünk van az Önök tapasztalatára. saját jelentkezéseiket május 1-ig, és a Programbizottság segít fókuszálni a témát a konferencia általános egységessége érdekében.
Csatlakozzanak a , ahol a minőséggel és a konferenciával kapcsolatos kérdéseket beszéljük meg, iratkozzanak fel a , hogy naprakészen követhessék a program híreit.
Forrás: habr.com
