Sveiki, Habr!
Turime naują svarbią temą – kokybiškas IT produktų kūrimas. „HighLoad++“ dažnai kalbame apie tai, kaip paspartinti užimtas paslaugas, o „Frontend Conf“ kalbame apie puikią vartotojo sąsają, kuri nesulėtėja. Reguliariai turime temų apie testavimą, o „DevOpsConf“ – apie skirtingų procesų, įskaitant testavimą, derinimą. Bet apie tai, ką apskritai galima vadinti kokybe ir kaip visapusiškai su ja dirbti – ne.
Pataisykime tai iki — kiekviename kūrimo etape kursime vartotojui mąstymo apie galutinio produkto kokybę kultūrą. Įprotis nesikoncentruoti į savo atsakomybės sritį, o kokybę sieti ne tik su bandytojais.
Po pjūviu kalbėsimės su programos komiteto vadovu, Tinkoff.Business testavimo vadovu, rusakalbių QA bendruomenės kūrėju Anastasija Aseeva-Nguyen apie QA pramonės būklę ir naujosios konferencijos misiją.
- Nastia labas. Prašome papasakoti apie save.
Anastasija: Vadovauju testavimui banke, esu atsakinga už labai didelę komandą – esame daugiau nei 90 žmonių. Turime svarbią verslo liniją, esame atsakingi už juridinių asmenų ekosistemą.
Studijavau mechaniką ir matematiką ir iš pradžių norėjau tapti programuotoju. Tačiau gavusi įdomų pasiūlymą nusprendžiau išbandyti save kaip testuotoją. Kaip bebūtų keista, tai pasirodė mano pašaukimas. Dabar matau visą savo darbą šioje pramonėje.
Esu aršus kokybės užtikrinimo disciplinos šalininkas. Nesu abejingas, kokie produktai kuriami, kaip su kokybe elgiamasi įmonėje, kolektyve ir iš esmės kūrimo procese.
Man tai akivaizdu bendruomenė šia kryptimi nėra pakankamai subrendusi, bent jau Rusijoje. Ne visada suprantame, kad kokybės užtikrinimas – tai ne tik paraiškos atitikties reikalavimams patikrinimas. Norėčiau pakeisti šią situaciją.
— Vartojate žodžius Kokybės užtikrinimas ir testavimas. Paprasto žmogaus akimis, šie du terminai labai dažnai sutampa. Kuo jie skiriasi, jei kasitės giliai?
Anastasija: Atvirkščiai, jie niekuo nesiskiria. Testavimas yra kokybės užtikrinimo disciplinos dalis; tai tiesioginė veikla – pats faktas, kad aš ką nors testuoju. Tiesą sakant, yra daug testavimo tipų, o už skirtingus testavimo tipus atsakingi įvairūs žmonės. Bet štai Rusijoje, kai atsirado užsakovų banga, tiekiančių testerius įmonėms, testavimas buvo sumažintas iki vieno tipo.
Daugeliu atvejų jie apsiriboja tik funkciniu testavimu: jie patikrina, ar tai, ką kūrėjai užkodavo, atitinka specifikaciją ir viskas.
— Papasakok, kokių dar yra kokybės užtikrinimo disciplinų? Kas dar, be bandymų, čia įtraukta?
Anastasija: Kokybės užtikrinimas visų pirma yra kokybiško produkto sukūrimas. Tai yra, mes klausiame savęs, kokias kokybės savybes turi turėti mūsų gaminys. Atitinkamai, jei tai suprantame, galime palyginti, kas daro įtaką šiems kokybės požymiams. Nesvarbu, kūrėjas, projektų vadovas ar produkto specialistas yra asmuo, kuris daro įtaką produkto kūrimui, jo atsilikimui ir strategijai.
Testuotojas geriau suvokia savo vaidmenį. Jis supranta, kad jo užduotis yra ne tik patikrinti atitiktį reikalavimams, bet ir tikrinti reikalavimus, kvestionuoti gaminio specialisto gaunamas formules, atskleisti visus numanomus kliento reikalavimus ir lūkesčius. Pristatydami naują funkcionalumą savo klientui, turime iš tikrųjų pateisinti jo lūkesčius ir išspręsti jų skausmą. Jei pagalvosime apie visus kokybės atributus, klientas bus patenkintas ir supras, kad įmonė, kurios produktą jis naudoja, tikrai rūpinasi jo interesais, o ne veikia principu „tik išleisti funkciją“.
— Atrodo, kad tai, ką ką tik aprašei, yra gaminių specialisto užduotis. Tai iš principo nėra susijęs su testavimu ir ne kokybe - tai paprastai susiję su produkto valdymu, ar ne?
Anastasija: Įskaitant. Kokybės užtikrinimas nėra disciplina, už kurią atsakingas vienas konkretus asmuo. Dabar yra populiari bandymų kryptis, vadinamasis metodas Agile Testing. Jo apibrėžimas aiškiai nurodo, kad tai yra komandinis bandymų metodas, apimantis tam tikrą praktikų rinkinį. Už šio požiūrio įgyvendinimą atsakinga visa komanda, net nebūtina, kad komandoje būtų bandytojas. Visa komanda yra sutelkta į vertės teikimą klientui ir užtikrinimą, kad vertė atitiktų klientų lūkesčius.
— Pasirodo, kokybė kertasi su beveik visomis aplinkinėmis disciplinomis, nustatydama rėmus viskam, kas aplinkui?
Anastasija: Teisingai. Kai galvojame, kaip norime sukurti kokybišką produktą, pradedame galvoti apie įvairius kokybės atributus. Pavyzdžiui, kaip patikrinti, ar tikrai sukūrėme funkciją, kurios reikia mūsų klientui.
Štai kur atsiranda šio tipo bandymai: UAT (vartotojo priėmimo testas). Deja, jis retai naudojamas Rusijoje, bet kartais yra SCRUM komandose kaip demonstracinė versija galutiniam klientui. Tai gana dažnas testavimo būdas užsienio įmonėse. Prieš atverdami funkcionalumą visiems klientams, pirmiausia atliekame UAT, tai yra pasikviečiame galutinį vartotoją, kuris išbando ir iš karto pateikia atsiliepimą – ar produktas tikrai pateisina lūkesčius ir išsprendžia skausmą. Tik po to įvyksta mastelio keitimas visiems kitiems klientams.
Tai yra, mes orientuojamės į verslą, į galutinį klientą, bet tuo pačiu nepamirškite apie technologijas. Gaminio kokybė taip pat labai priklauso nuo technologijos. Jei turime blogą architektūrą, negalėsime greitai išleisti funkcijų ir patenkinti klientų lūkesčius. Bandant pakeisti mastelį gali būti daug klaidų arba bandant pertvarkyti galime ką nors sugadinti. Visa tai turės įtakos klientų pasitenkinimui.
Šiuo požiūriu architektūra turėtų būti tokia, kad galėtume parašyti švarų kodą, kuris leistų greitai atlikti pakeitimus ir nebijoti, kad viską sulaužysime. Kad peržiūros iteracijos nesitęstų kelių mėnesių vien dėl to, kad turime tiek daug palikimo ir turime atlikti ilgus testavimo etapus.
— Iš viso jau dalyvauja kūrėjai, architektai, produktų mokslininkai, produktų vadybininkai ir patys bandytojai. Kas dar dalyvauja kokybės užtikrinimo procese?
Anastasija: Dabar įsivaizduokime, kad funkciją klientui jau pristatėme. Akivaizdu, kad produkto kokybę reikia stebėti net tada, kai jis jau gaminamas. Šiame etape gali atsirasti situacijų su neaiškiais scenarijais, vadinamųjų klaidų.
Pirmas klausimas – kaip kovoti su šiomis klaidomis, kai jau išleidome produktą? Kaip mes, pavyzdžiui, reaguojame į stresą? Klientas nebus labai patenkintas, jei puslapis įkeliamas ilgiau nei 30 sekundžių.
Čia atsiranda išnaudojimas arba, kaip jie dabar vadina, DevOps. Tiesą sakant, tai yra žmonės, atsakingi už gaminio valdymą, kai jis jau gaminamas. Tai apima įvairius stebėjimo tipus. Egzistuoja net testavimo potipis – testavimas gamyboje, kai leidžiame sau kažko netestuoti prieš išleidimą ir išbandome iš karto gamybos metu. Tai infrastruktūros organizavimo priemonių serija, leidžianti greitai reaguoti į incidentą, jį paveikti ir ištaisyti.
Taip pat svarbi infrastruktūra. Dažnai pasitaiko situacijų, kai testo metu negalime įsitikinti, kad tikrai turime viską, ką norėtume klientui padovanoti. Mes pradedame jį gaminti ir pradedame gaudyti neakivaizdžias situacijas. Ir viskas dėl to, kad bandymo infrastruktūra neatitinka gamybos infrastruktūros. Tai veda prie naujo tipo bandymų - infrastruktūros bandymai. Tai įvairios konfigūracijos, nustatymai, duomenų bazės perkėlimas ir kt.
Tai kelia klausimą – galbūt komandai infrastruktūrą reikia naudoti kaip kodą.
Manau, kad infrastruktūra tiesiogiai įtakoja produkto kokybę.
Tikiuosi, kad konferencijoje bus pranešimas su tikru atveju. Parašykite mums, jei esate pasirengę papasakoti mums iš savo patirties, kaip infrastruktūra kaip kodas veikia kokybę. Infrastruktūra kaip kodas leidžia lengviau patikrinti visus nustatymus ir išbandyti dalykus, kurių kitaip tiesiog neįmanoma. Todėl į kokybiško produkto kūrimo procesą įtraukiama ir eksploatacija.
– O kaip su analitika ir dokumentacija?
Anastasija: tai labiau taikoma įmonės sistemoms. Kai kalbame apie įmonę, į galvą iš karto ateina tokie žmonės kaip analitikai ir sistemų analitikai. Jie kartais vadinami techniniais rašytojais. Jie gauna užduotį parašyti specifikaciją ir ją atlikti, pavyzdžiui, mėnesį.
Ne kartą buvo įrodyta, kad tokios dokumentacijos rašymas sukelia labai ilgas kūrimo iteracijas ir ilgas tobulinimo iteracijas, nes testavimo proceso metu nustatomos klaidos ir prasideda grąžinimas. Dėl to yra daug kilpų, kurios padidina kūrimo išlaidas. Be to, tai gali sukelti pažeidžiamumą. Atrodo, kad parašėme nuorodos kodą, bet tada atlikome pakeitimus, kurie sulaužo puikiai apgalvotą architektūrą.
Galutinis rezultatas – ne visai kokybiškas produktas, nes architektūroje jau atsirado pataisų, kodas vietomis nepakankamai aprėptas testais, nes baigiasi terminai, reikia greitai uždaryti visas klaidas. Ir viskas todėl, kad pradinėje specifikacijoje nebuvo atsižvelgta į visus dalykus, kuriuos reikia įgyvendinti.
Kūrėjai nėra kenkėjai ir tyčia nerašo kodo su klaidomis.
Jei iš pradžių būtume apgalvoję specifikaciją, kurioje būtų aprėpti visi reikalingi punktai, tuomet viskas būtų įgyvendinta tiksliai taip, kaip reikia. Bet tai yra utopija.
Turbūt neįmanoma parašyti tobulos 100 puslapių specifikacijos. Štai kodėl reikia pagalvoti apie alternatyvius dokumentų rašymo būdus, specifikacijos, nustatant užduotis, kurios priartintų mus prie to, kad kūrėjas atliktų būtent tai, ko reikia.
Čia į galvą ateina „Agile“ požiūriai – vartotojų istorijos su priėmimo kriterijais. Tai labiau taikoma komandoms, kurios kuria mažas iteracijas.
— O kaip su tinkamumo naudoti testavimu, produkto tinkamumu naudoti, dizainu?
Anastasija: Tai labai svarbus momentas, nes komandoje yra dizainerių. Dažniausiai dizaineriai pasitelkiami kaip paslauga – arba projektavimo skyriaus, arba išorės dizainerio. Dažnai pasitaiko situacijų, kai atrodo, kad dizaineris įsiklausė į gaminio specialistą ir padarė tai, ką suprato. Bet kai pradedame iteraciją, paaiškėja, kad tai, kas iš tikrųjų buvo padaryta, buvo ne tai, ko tikėtasi: dizaineris kažką pamiršo, iki galo neapgalvojo savo elgesio, nes jis nėra komandoje ir ne kontekste, ar priekyje. -pabaigos kūrėjas nevisiškai suprato jo išdėstymą. Gali prireikti kelių pakartojimų vien dėl to, kad iškyla problema, kai sąsajos kūrėjas supranta dizainą.
Be to, yra dar viena problema. Dizaino sistemos dabar populiarėja. Jie yra reklamuojami, tačiau jų nauda nėra visiškai akivaizdi.
Susiduriu su nuomone, kad projektavimo sistemos, viena vertus, supaprastina kūrimą, tačiau, kita vertus, jos sąsajai nustato daug apribojimų.
Dėl to mes gaminame ne tokią funkciją, kokios nori klientas, o tokią, kuri mums patogi, nes jau turime tam tikrus kubus, iš kurių galime pagaminti.
Manau, kad tai yra tema, į kurią verta pažvelgti ir susimąstyti, ar bandydami palengvinti dizainą, iš tikrųjų sprendžiame kliento skausmo tašką.
— Yra stebėtinai daug temų, susijusių su kokybės užtikrinimu. Ar Rusijoje vyksta konferencija, kurioje būtų galima juos visus aptarti?
Anastasija: Vyksta seniausia testavimo konferencija, kuri šiemet vyks jau 25-ą kartą ir vadinasi SQA dienų kokybės užtikrinimo konferencija. Jame daugiausia aptariami funkcinių testerių įrankiai ir specifiniai testavimo metodai. Paprastai „SQA Days“ ataskaitose nuodugniai nagrinėjamos konkrečios sritys, susijusios su pačių testuotojų atsakomybe, bet ne sudėtinga veikla.
Tai labai padeda suprasti įvairius įrankius ir metodus, kaip išbandyti duomenų bazes, API ir kt. Tačiau kartu, viena vertus, tai nemotyvuoja į geresnio produkto kūrimą įtraukti daugiau nei tik bandymus. Kita vertus, bandytojai neįsitraukia į procesą, kad galvotų apie pasaulinį produkto ir jo verslo komponento tikslą.
Vadovauju dideliam skyriui ir vedu daug interviu, kurie tikrai suteikia įžvalgos apie visos pramonės būklę. Paprastai mūsų vaikinai dirba įmonėse ir turi aiškią atsakomybės sritį. Užsienio projektuose dirbantys kolegos naudoja įvairius testavimo būdus: patys gali atlikti apkrovos testavimą, veikimo testavimą, o kartais ir saugumo testus, nes jie tikrai padeda komandai užtikrinti produkto kokybę.
Norėčiau, kad vaikinai Rusijoje taip pat pradėtų galvoti, kad pramonė nesibaigia funkciniais testais.
— Šiuo tikslu organizuojame naują konferenciją „QualityConf“, kuri skirta kokybei kaip neatsiejamai disciplinai. Papasakok plačiau apie idėją, koks pagrindinis konferencijos tikslas?
Anastasija: Mes norime sukurti žmonių, kurie domisi kokybiškų produktų gamyba, bendruomenę. Pasiūlykite platformą, kur jie gali ateiti, klausytis pranešimų ir išeiti po konferencijos su konkrečiu supratimu, ką reikia keisti, kad pagerėtų kokybė.
Šiais laikais dažnai iš konsultacijos išgirstu prašymą, ką daryti, kai kyla problemų dėl testavimo ir kokybės. Kai pradedi bendrauti su komandomis, pamatai, kad problema yra ne pačiuose testuotojuose, o tame, kaip procesas sukonstruotas. Pavyzdžiui, kai kūrėjai mano, kad jie yra atsakingi tik už kodo rašymą, jų atsakomybė baigiasi tiksliai tą akimirką, kai jie perduoda užduotį testavimui.
Ne visi susimąsto apie tai, kad prastai parašytas, nekokybiškas, prastos architektūros kodas gresia didelėmis problemomis projektui. Jie negalvoja apie klaidų kainą, kad klaidos, kurios atsiduria gamyboje, gali sukelti didelių išlaidų įmonei ir komandai. Nėra kultūros apie tai galvoti. Noriu, kad konferencijoje pradėtume ją platinti.
Suprantu, kad tai ne naujovė.. Edwardas Demingas, 14 kokybės principų autorius, dar praėjusiame amžiuje rašė apie klaidos kainą. Kokybės užtikrinimas kaip disciplina yra pagrįsta šia knyga, bet, deja, šiuolaikinė plėtra apie tai pamiršta.
— Ar planuojate tiesiogiai paliesti temas apie testavimą ir įrankius?
Anastasija: Pripažįstu, kad bus pranešimų apie priemones. Yra gana universalių įrankių, kuriais įmonės ir komandos gali paveikti produktą.
Visas ataskaitas pasauliniu mastu jungs viena bendra misija: perteikti auditorijai, kad šio požiūrio, įrankio, metodo, proceso, testavimo tipo pagalba padarėme įtaką gaminio kokybei ir pagerinome kliento gyvenimą.
Tikrai neturėsime ataskaitų apie įrankį dėl įrankio. Visus į programą įtrauktus pranešimus jungs bendras tikslas.
— Kam bus įdomu, apie ką kalbate, ką matote kaip konferencijos svečius?
Anastasija: Turėsime ataskaitas kūrėjams, kuriems rūpi jų projekto, produkto, sistemos likimas. Taip pat tai bus įdomu ir testuotojams, ir, man atrodo, ypač vadovams. Vadybininkais turiu omenyje žmones, kurie priima sprendimus ir gali daryti įtaką ir produkto, sistemos, komandos likimui bei vystymuisi.
Tai žmonės, kuriems įdomu, kaip pagerinti produkto ar sistemos kokybę. Mūsų konferencijoje jie sužinos apie įvairius priemonių kompleksus ir supras, kas jiems dabar negerai ir ką reikia keisti.
Manau, kad pagrindinis kriterijus yra suprasti, kad kažkas negerai su kokybe ir norėti tai paveikti. Tikriausiai nepavyks pasiekti žmonių, kurie mano, kad tai padarys pirmą kartą.
— Kaip manote, ar visa pramonė yra subrendusi kalbėti ne tik apie bandymus, bet ir apie kokybės kultūrą?
Anastasija: Manau, kad subrendau. Dabar daugelis įmonių pereina nuo tradicinio „Waterfall“ požiūrio į „Agile“. Atsiranda dėmesys klientui, žmonės komandose tikrai pradeda galvoti, kaip sukurti kokybišką produktą. Net verslo įmonės vėl sutelkia dėmesį į kokybės gerinimą.
Sprendžiant iš bendruomenėje kylančių prašymų, manau, kad jau laikas. Žinoma, nesu tikras, kad tai bus didelio masto revoliucija, bet norėčiau, kad ši sąmonės revoliucija įvyktų.
- Sutarta! Mes diegsime kultūrą ir pakeisime sąmonę.
Konferencija apie kokybišką IT produktų kūrimą vyks Maskvoje birželio 7 d. Jūs žinote, iš kokių etapų susidaro kokybiškas produktas, turime atvejų, kaip sėkmingai kovoti su klaidomis gamyboje, išbandėme populiarius metodus savo praktikoje – mums reikia jūsų patirties. jų prašymus iki gegužės 1 d, o Programos komitetas padės sutelkti temą į bendrą konferencijos vientisumą.
Prisijungti prie , kuriame aptariame kokybės klausimus ir konferenciją, užsiprenumeruokite kad sužinotumėte apie programos naujienas.
Šaltinis: www.habr.com