Haai Habr!
Ons het 'n nuwe belangrike onderwerp - hoë-gehalte ontwikkeling van IT-produkte. By HighLoad++ praat ons dikwels oor hoe om besige dienste vinnig te maak, en by Frontend Conf praat ons van 'n koel gebruikerskoppelvlak wat nie stadiger word nie. Ons het gereeld onderwerpe oor toetsing, en DevOpsConf oor die kombinasie van verskillende prosesse, insluitend toetsing. Maar oor wat kwaliteit in die algemeen genoem kan word, en hoe om omvattend daaraan te werk - nee.
Kom ons maak dit reg deur — ons sal 'n kultuur van dink oor die kwaliteit van die finale produk vir die gebruiker in elke stadium van ontwikkeling ontwikkel. Die gewoonte om nie op jou verantwoordelikheidsgebied te fokus nie, en om kwaliteit nie net met toetsers te assosieer nie.
Onder die snit sal ons praat met die hoof van die programkomitee, hoof van toetsing by Tinkoff.Business, skepper van die Russiessprekende QA-gemeenskap Anastasia Aseeva-Nguyen oor die stand van die QA-industrie en die missie van die nuwe konferensie.
- Nastia hallo. Vertel ons asseblief van jouself.
Anastasia: Ek bestuur toetsing by 'n bank, ek is verantwoordelik vir 'n baie groot span - ons is meer as 90 mense. Ons het 'n belangrike sakelyn; ons is verantwoordelik vir die ekosisteem vir regsentiteite.
Ek het meganika en wiskunde studeer en wou aanvanklik 'n programmeerder word. Maar toe ek 'n interessante aanbod kry, het ek besluit om myself as 'n toetser te probeer. Vreemd genoeg was dit my roeping. Nou sien ek al my werk in hierdie bedryf.
Ek is 'n vurige aanhanger van die Gehalteversekering-dissipline. Ek is nie onverskillig oor watter produkte geskep word, hoe kwaliteit hanteer word in die maatskappy, in die span en, in beginsel, in die ontwikkelingsproses nie.
Dit is vir my duidelik die gemeenskap in hierdie rigting is nie volwasse genoeg nie, ten minste in Rusland. Ons verstaan nie altyd dat gehalteversekering nie net die feit is om 'n aansoek te toets vir voldoening aan vereistes nie. Ek wil graag hierdie situasie verander.
— Jy gebruik die woorde Gehalteversekering en toetsing. In die oë van die gemiddelde mens oorvleuel hierdie twee terme baie dikwels. Hoe verskil hulle as jy diep delf?
Anastasia: Hulle is eerder nie anders nie. Toetsing is deel van die Gehalteversekering-dissipline; dit is 'n direkte aktiwiteit - die feit dat ek iets toets. Daar is eintlik baie tipes toetse, en 'n verskeidenheid mense is verantwoordelik vir verskillende tipes toetsing. Maar hier in Rusland, toe 'n vlaag uitkontrakteerders verskyn wat toetsers aan maatskappye verskaf, is toetsing tot 'n enkele tipe verminder.
In die meeste gevalle is hulle net tot funksionele toetsing beperk: hulle kyk of dit wat die ontwikkelaars gekodeer het aan die spesifikasie voldoen en dit is al.
— Vertel ons asseblief watter ander gehalteversekeringsdissiplines daar is? Wat anders, behalwe toetsing, is hier ingesluit?
Anastasia: Gehalteversekering gaan eerstens daaroor om 'n kwaliteitproduk te skep. Dit wil sê, ons vra onsself af watter kwaliteitseienskappe ons produk moet hê. Gevolglik, as ons dit verstaan, kan ons vergelyk wie hierdie kwaliteitseienskappe beïnvloed. Maak nie saak nie, ontwikkelaar, projekbestuurder of produkspesialis is 'n persoon wat die ontwikkeling van 'n produk, sy agterstand en sy strategie beïnvloed.
Die toetser word meer bewus van sy rol. Hy verstaan dat sy taak nie net is om te toets vir voldoening aan vereistes nie, maar ook om vereistes te toets, die formulerings wat van die produkspesialis kom te bevraagteken en al die implisiete vereistes en verwagtinge van die kliënt te openbaar. Wanneer ons nuwe funksionaliteit aan ons kliënte lewer, moet ons werklik aan hul verwagtinge voldoen en hul pyn oplos. As ons aan al die eienskappe van kwaliteit dink, sal die kliënt tevrede wees en sal verstaan dat die maatskappy wie se produk hy gebruik regtig omgee vir sy belange, en nie werk op die beginsel van "net om 'n kenmerk vry te stel nie."
— Dit blyk dat wat jy sopas beskryf het die taak van 'n produkspesialis is. Dit gaan in beginsel nie oor toetsing nie en nie oor kwaliteit nie - dit gaan oor die algemeen oor produkbestuur, nie waar nie?
Anastasia: Insluitend. Gehalteversekering is nie 'n dissipline waarvoor een spesifieke persoon verantwoordelik is nie. Nou is daar 'n gewilde rigting in toetsing, 'n benadering genoem Agile toetsing. Sy definisie stel dit duidelik dat dit 'n spanbenadering tot toetsing is, wat 'n sekere stel praktyke insluit. Die hele span is verantwoordelik vir die implementering van hierdie benadering; dit is nie eers nodig dat daar 'n toetser op die span is nie. Die hele span is daarop gefokus om waarde aan die kliënt te lewer en om te verseker dat waarde aan kliënte se verwagtinge voldoen.
— Dit blyk dat kwaliteit byna alle omliggende dissiplines kruis, wat 'n raamwerk op alles rondom afdwing?
Anastasia: Reg. Wanneer ons dink oor hoe ons 'n kwaliteit produk wil skep, begin ons dink aan die verskillende eienskappe van kwaliteit. Byvoorbeeld, hoe om te kyk of ons werklik die kenmerk gemaak het wat ons kliënt benodig.
Dit is waar hierdie tipe toetsing inkom: UAT (gebruikersaanvaardingstoetsing). Ongelukkig word dit selde in Rusland beoefen, maar is soms teenwoordig in SCRUM-spanne as 'n demo vir die eindkliënt. Dit is 'n redelik algemene tipe toetsing in buitelandse maatskappye. Voordat ons die funksionaliteit vir alle kliënte oopmaak, doen ons eers UAT, dit wil sê ons nooi die eindgebruiker wat toets en dadelik terugvoer gee – of die produk werklik aan verwagtinge voldoen en die pyn oplos. Eers hierna vind skaal na alle ander kliënte plaas.
Dit wil sê, ons fokus op besigheid, op die eindkliënt, maar terselfdertyd moenie van tegnologie vergeet nie. Die kwaliteit van die produk hang ook grootliks af van tegnologie. As ons 'n slegte argitektuur het, sal ons nie vinnig kenmerke kan vrystel en aan kliënte se verwagtinge voldoen nie. Daar kan baie foute wees wanneer ons probeer skaal, of wanneer ons probeer om te herfaktor ons kan iets breek. Dit alles sal klanttevredenheid beïnvloed.
Vanuit hierdie oogpunt moet die argitektuur so wees dat ons skoon kode kan skryf wat ons in staat sal stel om vinnig veranderinge aan te bring en nie bang te wees dat ons alles sal breek nie. Sodat hersieningsiterasies nie oor 'n paar maande strek bloot omdat ons soveel nalatenskap het, en ons lang toetsfases moet doen nie.
— In totaal is ontwikkelaars, argitekte, produkwetenskaplikes, produkbestuurders en toetsers self reeds betrokke. Wie anders is betrokke by die gehalteversekeringsproses?
Anastasia: Kom ons stel ons nou voor dat ons reeds die kenmerk aan die kliënt gelewer het. Uiteraard moet die kwaliteit van die produk gemonitor word selfs wanneer dit reeds in produksie is. Op hierdie stadium kan situasies met nie-vanselfsprekende scenario's, sogenaamde foute, verskyn.
Die eerste vraag is hoe ons hierdie foute hanteer nadat ons reeds die produk vrygestel het? Hoe reageer ons byvoorbeeld op stres? Die kliënt sal nie baie gelukkig wees as die bladsy meer as 30 sekondes neem om te laai nie.
Dit is waar uitbuiting ter sprake kom of, soos hulle dit nou noem, DevOps. Trouens, dit is die mense wat verantwoordelik is vir die bedryf van die produk wanneer dit reeds in produksie is. Dit sluit verskeie tipes monitering in. Daar is selfs 'n subtipe toets - toetsing op produksie, wanneer ons onsself toelaat om nie iets te toets voor ontplooiing nie en dit dadelik op produksie te toets. Dit is 'n reeks maatreëls uit die oogpunt van die organisering van infrastruktuur wat jou in staat stel om vinnig op 'n voorval te reageer, dit te beïnvloed en dit reg te stel.
Infrastruktuur is ook belangrik. Daar is dikwels situasies wanneer dit tydens 'n toets onmoontlik is om seker te maak dat ons regtig alles het wat ons graag aan die kliënt wil gee. Ons rol dit uit in produksie en begin om nie-vanselfsprekende situasies op te vang. En dit alles omdat die infrastruktuur in die toets nie ooreenstem met die infrastruktuur in produksie nie. Dit lei tot 'n nuwe tipe toetsing - infrastruktuurtoetsing. Dit is verskeie konfigurasies, instellings, databasismigrasie, ens.
Dit laat die vraag ontstaan - miskien moet die span infrastruktuur as kode gebruik.
Ek glo dat infrastruktuur die kwaliteit van die produk direk beïnvloed.
Ek hoop daar sal 'n verslag by die konferensie wees met 'n werklike saak. Skryf vir ons as jy gereed is om ons uit jou eie ervaring te vertel hoe infrastruktuur as kode kwaliteit beïnvloed. Infrastruktuur as kode maak dit makliker om alle instellings na te gaan en dinge te toets wat andersins eenvoudig nie moontlik is nie. Daarom is bedryf ook betrokke by die proses om 'n kwaliteit produk te ontwikkel.
— Wat van analise en dokumentasie?
Anastasia: Dit geld meer vir ondernemingstelsels. Wanneer ons oor onderneming praat, kom mense soos ontleders en stelselontleders dadelik in gedagte. Hulle word soms tegniese skrywers genoem. Hulle kry 'n taak om 'n spesifikasie te skryf en dit byvoorbeeld vir 'n maand te voltooi.
Dit is herhaaldelik bewys dat die skryf van sulke dokumentasie lei tot baie lang ontwikkelingsiterasies en lang herhalings van verfyning, want tydens die toetsproses word foute geïdentifiseer en terugkeer begin. As gevolg hiervan is daar baie lusse wat ontwikkelingskoste verhoog. Daarbenewens kan dit kwesbaarhede veroorsaak. Dit lyk asof ons verwysingskode geskryf het, maar toe het ons veranderinge aangebring wat die perfek deurdagte argitektuur breek.
Die eindresultaat is 'n nie heeltemal hoë gehalte produk nie, want pleisters het reeds in die argitektuur verskyn, die kode word op sommige plekke nie voldoende deur toetse gedek nie, omdat sperdatums uitloop, al die foute moet vinnig gesluit word. En dit alles omdat die oorspronklike spesifikasie nie al die punte wat geïmplementeer moet word, in ag geneem het nie.
Ontwikkelaars is nie peste nie en skryf nie doelbewus kode met foute nie.
As ons aanvanklik deur 'n spesifikasie gedink het wat al die nodige punte sou dek, dan sou alles presies geïmplementeer gewees het soos nodig. Maar dit is 'n utopie.
Dit is waarskynlik onmoontlik om 'n perfekte 100-bladsy spesifikasie te skryf. Dis hoekom moet dink oor alternatiewe maniere om dokumentasie te skryf, spesifikasies, opstel van take wat ons nader sal bring om te verseker dat die ontwikkelaar presies doen wat nodig is.
Hier kom benaderings van Agile na vore - gebruikersverhale met aanvaardingskriteria. Dit is meer van toepassing op spanne wat in klein iterasies ontwikkel.
— Wat van bruikbaarheidstoetsing, produk bruikbaarheid, ontwerp?
Anastasia: Dit is 'n baie belangrike punt, want daar is ontwerpers in die span. Ontwerpers word meestal as 'n diens gebruik - hetsy deur 'n ontwerpafdeling of deur 'n uitgekontrakteerde ontwerper. Daar is dikwels situasies waar dit lyk asof die ontwerper na die produkspesialis geluister het en gedoen het wat hy verstaan het. Maar wanneer ons die herhaling begin, blyk dit dat wat eintlik gedoen is nie was wat verwag is nie: die ontwerper het iets vergeet, nie heeltemal deur die gedrag gedink nie, want hy is nie in die span nie en nie in die konteks, of die voorkant nie. -end ontwikkelaar het dit nie ten volle verstaan nie. Dit kan verskeie herhalings neem net omdat daar 'n probleem is met die front-end ontwikkelaar wat die ontwerp verstaan.
Boonop is daar nog een probleem. Ontwerpstelsels word nou gewild. Hulle is op hype, maar die voordele daarvan is nie heeltemal voor die hand liggend nie.
Ek kom teë op die mening dat ontwerpstelsels aan die een kant ontwikkeling vereenvoudig, maar aan die ander kant lê dit baie beperkings op die koppelvlak.
Gevolglik maak ons nie die kenmerk wat die kliënt wil hê nie, maar die een wat vir ons gerieflik is, want ons het reeds sekere kubusse waaruit ons dit kan maak.
Ek dink dit is 'n onderwerp wat die moeite werd is om na te kyk en te wonder of ons in 'n poging om ontwerp makliker te maak, eintlik 'n kliënt se pynpunt oplos.
— Daar is 'n verbasende aantal onderwerpe wat met Gehalteversekering verband hou. Is daar 'n konferensie in Rusland waar almal bespreek kan word?
Anastasia: Daar is die oudste toetskonferensie, wat vanjaar vir die 25ste keer gehou word en die SQA Days Quality Assurance Conference genoem word. Dit bespreek hoofsaaklik gereedskap en spesifieke toetsbenaderings vir funksionele toetsers. As 'n reël ondersoek die verslae by SQA Days spesifieke areas op die gebied van verantwoordelikheid van die toetsers self, maar nie komplekse aktiwiteite nie.
Dit help baie om verskillende gereedskap en benaderings te verstaan, hoe om databasisse, API's, ens. Maar terselfdertyd, aan die een kant, motiveer dit nie om meer as net toetsing in die skepping van 'n beter produk te betrek nie. Aan die ander kant raak toetsers nie meer betrokke by die proses om na te dink oor die globale doelwit van die produk en sy besigheidskomponent nie.
Ek bestuur ’n groot departement en voer baie onderhoude wat werklik insig gee in die stand van die bedryf as geheel. As 'n reël werk ons ouens in ondernemings, en hulle het 'n duidelike verantwoordelikheidsgebied. Kollegas wat in buitelandse projekte werk, gebruik verskillende tipes toetse: hulle kan self lastoetsing, prestasietoetsing en selfs soms sekuriteitstoetse doen, want hulle help regtig die span om die kwaliteit van die produk te verseker.
Ek wil graag hê die ouens in Rusland moet ook begin dink dat die bedryf nie eindig met funksionele toetsing nie.
— Vir hierdie doel organiseer ons 'n nuwe konferensie, QualityConf, wat toegewy is aan kwaliteit as 'n integrale dissipline. Vertel ons meer oor die idee, wat is die hoofdoel van die konferensie?
Anastasia: Ons wil 'n gemeenskap skep van mense wat daarin belangstel om kwaliteit produkte te maak. Bied 'n platform waar hulle kan kom, na verslae kan luister en na die konferensie kan vertrek met 'n spesifieke begrip van wat verander moet word om kwaliteit te verbeter.
Deesdae hoor ek gereeld 'n versoek van konsultante oor wat om te doen wanneer daar probleme met toetsing en kwaliteit is. Wanneer jy met spanne begin kommunikeer, sien jy dat die probleem nie by die toetsers self lê nie, maar by hoe die proses gestruktureer is. Byvoorbeeld, wanneer ontwikkelaars glo dat hulle net verantwoordelik is vir die skryf van kode, eindig hul verantwoordelikheid presies die oomblik wat hulle die taak aan toetsing oorgee.
Nie almal dink daaraan dat swak geskrewe kode van lae gehalte met swak argitektuur groot probleme vir die projek bedreig nie. Hulle dink nie aan die koste van foute nie, dat foute wat in produksie beland, groot koste vir die maatskappy en die span tot gevolg kan hê. Daar is geen kultuur om hieroor na te dink nie. Ek wil hê ons moet dit by die konferensie begin versprei.
Ek verstaan dat dit nie 'n innovasie is nie. Edward Deming, die skrywer van die 14 beginsels van kwaliteit, het in die vorige eeu geskryf oor die koste van 'n fout. Gehalteversekering as 'n dissipline is op hierdie boek gebaseer, maar ongelukkig vergeet moderne ontwikkeling daarvan.
— Beplan jy om onderwerpe direk oor toetsing en gereedskap aan te raak?
Anastasia: Ek gee toe dat daar verslae sal wees oor gereedskap. Daar is redelik universele instrumente waarmee maatskappye en spanne die produk kan beïnvloed.
Alle verslae sal wêreldwyd verenig word deur een gemeenskaplike missie: om aan die gehoor oor te dra dat ons met behulp van hierdie benadering, instrument, metode, proses, tipe toetsing die kwaliteit van die produk beïnvloed het en die lewe van die kliënt verbeter het.
Ons sal beslis nie verslae oor 'n instrument hê ter wille van 'n hulpmiddel nie. Alle verslae wat by die program ingesluit is, sal verenig word deur 'n gemeenskaplike doelwit.
— Wie sal belangstel in waaroor jy praat, wie jy as gaste van die konferensie sien?
Anastasia: Ons sal verslae hê vir ontwikkelaars wat omgee vir die lot van hul projek, produk, stelsel. Net so sal dit van belang wees vir toetsers en, lyk dit my, veral vir bestuurders. Met bestuurders bedoel ek mense wat besluite neem en die lot en ontwikkeling van 'n produk, stelsel, span ook kan beïnvloed.
Dit is mense wat wonder hoe om die kwaliteit van 'n produk of stelsel te verbeter. By ons konferensie sal hulle van verskeie stelle maatreëls leer en sal hulle kan verstaan wat nou daarmee fout is en wat verander moet word.
Ek dink die hoofkriterium is om te verstaan dat iets fout is met kwaliteit en dit te wil beïnvloed. Ons sal waarskynlik nie mense kan bereik wat dink dit sal net die eerste keer doen nie.
— Dink jy die bedryf as geheel is ryp om nie net oor toetsing te praat nie, maar oor 'n kultuur van kwaliteit?
Anastasia: Ek dink ek het volwasse geword. Nou beweeg baie maatskappye weg van die tradisionele Waterval-benadering na Agile. Daar is 'n kliëntfokus, mense in spanne begin regtig dink oor hoe om 'n kwaliteit produk te skep. Selfs ondernemingsmaatskappye fokus weer op die verbetering van gehalte.
Te oordeel aan die aantal versoeke wat in die gemeenskap opduik, glo ek dat dit tyd is. Ek is natuurlik nie seker dat dit 'n grootskaalse rewolusie sal wees nie, maar ek wil graag hê dat hierdie rewolusie in bewussyn moet plaasvind.
- Ooreengekom! Ons sal kultuur inboesem en bewussyn verander.
Konferensie oor hoë-gehalte ontwikkeling van IT-produkte sal plaasvind in Moskou op 7 Junie. U weet watter stadiums 'n produk van hoë gehalte uitmaak, ons het gevalle van suksesvolle bekamping van foute in produksie, ons het gewilde metodes in ons praktyk getoets - ons het u ervaring nodig. hul aansoeke voor 1 Mei, en die Programkomitee sal help om die tema vir die algehele integriteit van die konferensie te fokus.
Koppel aan , waarin ons gehaltekwessies en die konferensie bespreek, onderskryf om op hoogte te bly van programnuus.
Bron: will.com