Hej Habr!
Ni havas novan gravan temon - altkvalitan disvolviĝon de IT-produktoj. Ĉe HighLoad++ ni ofte parolas pri kiel rapidigi okupatajn servojn, kaj ĉe Frontend Conf ni parolas pri bonega uzantinterfaco, kiu ne malrapidiĝas. Ni regule havas temojn pri testado, kaj DevOpsConf pri kombinado de malsamaj procezoj, inkluzive de testado. Sed pri tio, kio povas esti nomata kvalito ĝenerale, kaj kiel labori pri ĝi amplekse - ne.
Ni riparu ĉi tion per — ni disvolvos kulturon de pensado pri la kvalito de la fina produkto por la uzanto en ĉiu etapo de evoluo. La kutimo ne fokusigi vian respondecon, kaj asocii kvaliton ne nur kun testantoj.
Sub la tranĉo ni parolos kun la estro de la programkomitato, estro de testado ĉe Tinkoff.Business, kreinto de la ruslingva QA-komunumo Anastazio Aseeva-Nguyen pri la stato de la industrio de QA kaj la misio de la nova konferenco.
- Nastia saluton. Bonvolu rakonti al ni pri vi mem.
Anastasia: Mi gvidas testadon ĉe banko kaj respondecas pri tre granda teamo—ni estas pli ol 90 homoj. Ni havas gravan komercan linion; ni respondecas pri la ekosistemo por juraj entoj.
Mi studis mekanikon kaj matematikon kaj komence volis fariĝi programisto. Sed kiam mi ricevis interesan oferton, mi decidis provi min kiel testilo. Sufiĉe strange, tio montriĝis esti mia voko. Nun mi vidas mian tutan laboron en ĉi tiu industrio.
Mi estas fervora adepto de la Kvalita Asekuro. Mi zorgas pri kiaj produktoj estas kreitaj, kiel kvalito estas traktata en la firmao, en la teamo, kaj, principe, en la evoluprocezo.
Estas evidente al mi tio la komunumo en tiu ĉi direkto ne estas sufiĉe matura, almenaŭ en Rusio. Ni ne ĉiam komprenas, ke kvalita certigo ne estas nur la fakto testi aplikaĵon por konformeco al postuloj. Mi ŝatus ŝanĝi ĉi tiun situacion.
— Vi uzas la vortojn Kvalita certigo kaj testado. En la okuloj de la averaĝa homo, ĉi tiuj du terminoj tre ofte interkovras. Kiel ili diferencas se vi fosas profunde?
Anastazio: Prefere, ili ne estas malsamaj. Testado estas parto de la Kvalita Asekuro, ĝi estas rekta agado - la fakto mem, ke mi testas ion. Fakte ekzistas multaj specoj de testado, kaj diversaj homoj respondecas pri malsamaj specoj de testado. Sed ĉi tie en Rusio, kiam aperis ondo da subkontraktantoj, kiuj provizas testilojn al kompanioj, testado reduktiĝis al unuopa tipo.
Plejofte, ili estas limigitaj nur al funkciaj provoj: ili kontrolas, ke tio, kion la programistoj kodis, konformas al la specifo kaj jen ĝi.
— Bonvolu diri al ni, kiaj aliaj disciplinoj pri kvalito-certigo ekzistas? Kio alia, krom testado, estas inkluzivita ĉi tie?
Anastasia: Kvalita Asekuro estas, unue kaj ĉefe, pri kreado de kvalita produkto. Tio estas, ni demandas nin, kiajn kvalitajn atributojn nia produkto devus havi. Sekve, se ni komprenas ĉi tion, tiam ni povas kompari, kiu influas ĉi tiujn kvalitajn atributojn. Ne gravas, programisto, projektestro aŭ produktospecialisto estas homo, kiu influas la disvolviĝon de produkto, ĝian restaron kaj ĝian strategion.
La elprovilo iĝas pli konscia pri sia rolo. Li komprenas, ke lia tasko estas ne nur testi pri plenumo de postuloj, sed ankaŭ testi postulojn, pridubi la formulojn, kiuj venas de la produkta specialisto, kaj malkaŝi ĉiujn implicajn postulojn kaj atendojn de la kliento. Kiam ni liveras novajn funkciojn al nia kliento, ni devas vere renkonti iliajn atendojn kaj solvi ilian doloron. Se ni pensas pri ĉiuj atributoj de kvalito, la kliento estos kontenta kaj komprenos, ke la kompanio, kies produkton li uzas, vere zorgas pri siaj interesoj kaj ne laboras laŭ la principo "nur liberigi funkcion".
— Ŝajnas, ke tio, kion vi ĵus priskribis, estas tasko de produkta specialisto. Ĉi tio principe ne temas pri testado kaj ne pri kvalito - ĝenerale temas pri produkta administrado, ĉu ne?
Anastasia: Inkluzive. Kvalita Asekuro ne estas disciplino pri kiu respondecas unu specifa persono. Nun estas populara direkto en testado, nomita aliro Lerta Testado. Ĝia difino klare deklaras, ke ĝi estas teama aliro al testado, kiu inkluzivas certan aron de praktikoj. La tuta teamo respondecas pri efektivigo de ĉi tiu aliro; eĉ ne necesas, ke estu testilo en la teamo. La tuta teamo koncentriĝas pri liverado de valoro al la kliento kaj certigi, ke tiu valoro renkontas klientajn atendojn.
— Montriĝas, ke kvalito intersekcas kun preskaŭ ĉiuj ĉirkaŭaj fakoj, trudante kadron al ĉio ĉirkaŭ?
Anastasia: Ĝuste. Kiam ni pensas pri tio, ke ni volas krei kvalitan produkton, ni komencas pensi pri la malsamaj atributoj de kvalito. Ekzemple, kiel kontroli, ke ni vere faris la funkcion, kiun nia kliento bezonas.
Jen kie ĉi tiu speco de provoj envenas: UAT (provado de akcepto de uzantoj). Bedaŭrinde, ĝi malofte estas praktikata en Rusio, sed foje ĉeestas en SCRUM-teamoj kiel demo por la fina kliento. Ĉi tio estas sufiĉe ofta speco de testado en eksterlandaj kompanioj. Antaŭ malfermi la funkciecon al ĉiuj klientoj, ni unue faras UAT, tio estas, ni invitas la finuzanton testi kaj tuj doni komentojn pri ĉu la produkto vere plenumas atendojn kaj solvas la doloron. Nur post tio okazas skalo al ĉiuj aliaj klientoj.
Tio estas, ni koncentriĝas pri komerco, pri la fina kliento, sed samtempe ne forgesu pri teknologio. La kvalito de la produkto ankaŭ multe dependas de teknologio. Se ni havas malbonan arkitekturon, ni ne povos rapide liberigi funkciojn kaj renkonti klientajn atendojn. Eble estas multaj eraroj kiam oni provas grimpi, aŭ kiam oni provas refaktori, ni eble rompas ion. Ĉio ĉi influos klientan kontenton.
El ĉi tiu vidpunkto, la arkitekturo devus esti tia, ke ni povas skribi puran kodon, kiu permesos al ni rapide fari ŝanĝojn kaj ne timi, ke ni rompos ĉion. Por certigi, ke reviziaj ripetoj ne etendiĝas dum pluraj monatoj simple ĉar ni havas tiom da heredaĵo, ni devas fari longajn testajn stadiojn.
— Entute, programistoj, arkitektoj, produktsciencistoj, produktmanaĝeroj kaj testistoj mem jam estas implikitaj. Kiu alia partoprenas en la procezo pri kvalito-certigo?
Anastasia: Nun ni imagu, ke ni jam liveris la funkcion al la kliento. Evidente, la kvalito de la produkto devas esti monitorita eĉ kiam ĝi jam estas en produktado. En ĉi tiu etapo, situacioj kun neevidentaj scenaroj, tiel nomataj cimoj, povas aperi.
La unua demando estas kiel ni traktas ĉi tiujn cimojn post kiam ni jam liberigis la produkton? Kiel ni, ekzemple, reagas al streso? La kliento ne estos tre feliĉa se la paĝo ŝarĝas pli ol 30 sekundojn.
Ĉi tie eniras ekspluatado, aŭ kiel ili nomas ĝin nun. DevOps. Fakte, ĉi tiuj estas la homoj, kiuj respondecas pri funkciigado de la produkto kiam ĝi jam estas en produktado. Ĉi tio inkluzivas diversajn specojn de monitorado. Ekzistas eĉ subspeco de testado - testado en produktado, kiam ni permesas al ni ne testi ion antaŭ liberigo kaj testi ĝin tuj dum produktado. Ĉi tio estas serio de agadoj el la vidpunkto de organizado de infrastrukturo, kiuj permesas vin rapide respondi al okazaĵo, influi ĝin kaj korekti ĝin.
Infrastrukturo ankaŭ estas grava. Ofte estas situacioj kiam, dum testo, estas neeble certigi, ke ni vere havas ĉion, kion ni ŝatus doni al la kliento. Ni ruliĝas ĝin al produktado kaj komencas kapti ne-evidentajn situaciojn. Kaj ĉio ĉar la infrastrukturo en la testo ne respondas al la infrastrukturo en produktado. Ĉi tio kondukas al nova speco de testado - provado de infrastrukturoj. Ĉi tiuj inkluzivas diversajn agordojn, agordojn, datumbazmigradojn, ktp.
Ĉi tio petas la demandon - eble la teamo bezonas uzi infrastrukturon kiel kodon.
Mi kredas, ke infrastrukturo rekte influas la kvaliton de la produkto.
Mi esperas, ke en la konferenco estos raporto kun vera kazo. Skribu al ni se vi pretas rakonti al ni laŭ via propra sperto, kiel infrastrukturo kiel kodo influas kvaliton. Infrastrukturo kiel kodo faciligas kontroli ĉiujn agordojn kaj testi aferojn, kiuj alie simple ne eblas. Tial, operacio ankaŭ estas implikita en la procezo de evoluigado de kvalita produkto.
— Kio pri analizo kaj dokumentado?
Anastasia: Ĉi tio validas pli por entreprenaj sistemoj. Kiam ni parolas pri entrepreno, homoj kiel analizistoj kaj sistemanalizistoj tuj venas al la menso. Ili estas foje nomitaj teknikaj verkistoj. Ili ricevas taskon verki specifon kaj kompletigi ĝin, ekzemple, dum monato.
Oni plurfoje pruvis, ke verkado de tia dokumentado kondukas al tre longaj evoluiteroj kaj longaj ripetoj de plibonigo, ĉar dum la testadprocezo cimoj estas identigitaj kaj revenoj komenciĝas. Kiel rezulto, estas multaj cikloj, kiuj pliigas la koston de disvolviĝo. Krome, ĉi tio povas enkonduki vundeblecojn. Ni ŝajne skribis referenckodon, sed poste ni faris ŝanĝojn, kiuj rompas la perfekte pripensitan arkitekturon.
Rezulte, la rezulto ne estas tre altkvalita produkto, ĉar diakiloj jam aperis en la arkitekturo, la kodo kelkloke ne estas sufiĉe kovrita de provoj, ĉar limdatoj finiĝas, ĉiuj cimoj devas esti fermitaj pli rapide. Kaj ĉio ĉar la origina specifo ne enkalkulis ĉiujn punktojn, kiuj devas esti efektivigitaj.
Programistoj ne estas plagoj kaj ne intence skribas kodon kun eraroj.
Se ni komence pripensus specifon, kiu kovris ĉiujn necesajn punktojn, tiam ĉio estus efektivigita ĝuste laŭbezone. Sed ĉi tio estas utopio.
Verŝajne estas neeble skribi perfektan 100-paĝan specifon. Tial bezonas pensi pri alternativaj manieroj verki dokumentadon, specifoj, taskodeklaroj, kiuj proksimigus nin al certigi, ke la programisto faras ĝuste tion, kion oni bezonas.
Ĉi tie venas en menso Agile aliroj - uzantrakontoj kun akceptaj kriterioj. Ĉi tio estas pli aplikebla por teamoj kiuj evoluas en malgrandaj ripetoj.
— Kio pri uzeblotestado, produkta uzebleco, dezajno?
Anastasia: Ĉi tio estas tre grava punkto, ĉar estas dezajnistoj en la teamo. Plej ofte, projektistoj estas uzataj kiel servo - ĉu de dezajnsekcio aŭ de subkontraktita dezajnisto. Ofte estas situacioj, kie ŝajnas, ke la dezajnisto aŭskultis la produktan scienciston kaj faris tion, kion li komprenis. Sed kiam ni komencas la ripeton, rezultas, ke tio, kio estis efektive farita, ne estis tio, kion oni atendis: la dezajnisto forgesis ion, ne plene pripensis la konduton, ĉar li ne estis en la teamo kaj ne en la kunteksto, aŭ en la fronto. -end programisto ne plene komprenis ĝin aranĝo. Eble necesas pluraj ripetoj nur ĉar estas problemo kun la kompreno de la antaŭfina programisto pri la dezajno.
Krome estas unu plia problemo. Dezajnaj sistemoj nun akiras popularecon. Ili estas furiozaj, sed la avantaĝoj de ili ne estas tute evidentaj.
Mi alfrontas la opinion, ke dezajnaj sistemoj, unuflanke, simpligas disvolviĝon, sed aliflanke ili trudas multajn limigojn al la interfaco.
Kiel rezulto, ni ne faras la funkcion, kiun la kliento volas, sed tiun, kiu estas oportuna por ni, ĉar ni jam havas certajn kubojn el kiuj ni povas fari ĝin.
Mi pensas, ke indas atenti ĉi tiun temon kaj scivoli, ĉu provante simpligi projektan laboron ni efektive solvas klientan doloron.
— Estas surpriza nombro da temoj rilataj al Kvalita Asekuro. Ĉu estas konferenco en Rusio, kie oni povas priparoli ĉiujn?
Anastasia: Estas la plej malnova konferenco pri testado, kiu okazos la 25-an fojon ĉi-jare kaj nomiĝas la Kvalita Garantio-Konferenco SQA-Tagoj. Ĝi ĉefe diskutas ilojn kaj specifajn testajn alirojn por funkciaj elproviloj. Kiel regulo, la raportoj ĉe SQA Days profunde ekzamenas specifajn areojn en la areo de respondeco de la testantoj mem, sed ne kompleksajn agadojn.
Ĉi tio multe helpas kompreni malsamajn ilojn kaj alirojn, kiel testi datumbazojn, APIojn, ktp. Sed samtempe, unuflanke, ĝi ne instigas impliki pli ol nur testadon en la kreado de pli bona produkto. Aliflanke, testantoj ne pli engaĝiĝas en la procezo por pensi pri la tutmonda celo de la produkto kaj ĝia komerca komponanto.
Mi administras grandan fakon kaj faras multajn intervjuojn, kiuj vere donas sciojn pri la stato de la industrio entute. Kiel regulo, niaj infanoj laboras en entrepreno, kaj ili havas klaran respondecon. Kolegoj, kiuj laboras en eksterlandaj projektoj, uzas malsamajn specojn de testado: ili mem povas fari ŝarĝtestadon, rendimentotestadon, kaj eĉ foje sekurectestadon, ĉar ili vere helpas la teamon certigi la kvaliton de la produkto.
Mi ŝatus, ke la uloj en Rusio ankaŭ komencu pensi pri tio, ke la industrio ne finiĝas per funkciaj provoj.
— Tiucele ni organizas novan konferencon, QualityConf, kiu estas dediĉita al kvalito kiel integra disciplino. Rakontu al ni pli pri la ideo, kio estas la ĉefa celo de la konferenco?
Anastasia: Ni volas krei komunumon de homoj interesitaj pri produkti kvalitajn produktojn. Proponu platformon, kie ili povas veni, aŭskulti raportojn kaj forlasi la konferencon kun specifa kompreno pri tio, kion ili bezonas ŝanĝi por plibonigi kvaliton.
Nuntempe mi ofte aŭdas peton de konsultado pri kion fari kiam estas problemoj pri testado kaj kvalito. Kiam vi komencas komuniki kun teamoj, vi vidas, ke la problemo ne estas kun la testantoj mem, sed pri la maniero kiel la procezo estas strukturita. Ekzemple, kiam programistoj kredas, ke ili respondecas nur pri skribado de kodo, ilia respondeco finiĝas ĝuste en la momento, kiam ili transdonas la taskon al testado.
Ne ĉiuj pensas pri tio, ke malbone skribita, malaltkvalita kodo kun malbona arkitekturo minacas grandajn problemojn por la projekto. Ili ne pensas pri la kosto de eraroj, ke cimoj, kiuj finiĝas en produktado, povas rezultigi grandajn kostojn por la kompanio kaj teamo. Ne ekzistas kulturo por pensi pri tio. Mi volas, ke ni komencu disdoni ĝin ĉe la konferenco.
Mi komprenas, ke tio ne estas novigo.Edward Deming, la aŭtoro de la 14 principoj de kvalito, skribis pri la kosto de eraro jam en la lasta jarcento. Kvalita Asekuro kiel disciplino baziĝas sur ĉi tiu libro, sed, bedaŭrinde, moderna evoluo forgesas pri ĝi.
— Ĉu vi planas tuŝi temojn rekte pri testado kaj iloj?
Anastasia: Mi konfesas, ke estos raportoj pri iloj. Estas sufiĉe universalaj iloj per kiuj kompanioj kaj teamoj povas influi la produkton.
Ĉiuj raportoj estos tutmonde kunigitaj de unu komuna misio: transdoni al la spektantaro, ke helpe de ĉi tiu aliro, ilo, metodo, procezo, tipo de testado, ni influis la kvaliton de la produkto kaj plibonigis la vivon de la kliento.
Ni certe ne havos raportojn pri ilo pro ilo. Ĉiuj raportoj inkluzivitaj en la programo estos kunigitaj per komuna celo.
— Kiu interesiĝos pri tio, pri kio vi parolas, kiujn vi vidas kiel gastoj de la konferenco?
Anastasia: Ni havos raportojn por programistoj, kiuj zorgas pri la sorto de sia projekto, produkto, sistemo. Same, ĝi interesos testantojn kaj, ŝajnas al mi, precipe al administrantoj. Per administrantoj, mi celas homojn, kiuj faras decidojn kaj povas influi la sorton kaj evoluon de produkto, sistemo, teamo, interalie.
Ĉi tiuj estas homoj, kiuj scivolas kiel plibonigi la kvaliton de produkto aŭ sistemo. En nia konferenco, ili lernos pri diversaj aroj de mezuroj kaj povos kompreni kio estas malbona ĉe ili nun kaj kio devas esti ŝanĝita.
Mi pensas, ke la ĉefa kriterio estas kompreni, ke io misas kun la kvalito kaj volas influi ĝin. Ni verŝajne ne povos atingi homojn, kiuj pensas, ke tio faros la unuan fojon.
— Ĉu vi opinias, ke la industrio entute estas matura por paroli ne nur pri testado, sed pri kulturo de kvalito?
Anastasia: Mi kredas, ke mi maturiĝis. Nun multaj kompanioj foriras de la tradicia Akvofala aliro al Agile. Estas fokuso sur la kliento, homoj en teamoj vere komencas pensi pri kiel krei kvalitan produkton. Eĉ entreprenaj kompanioj refokusiĝas al plibonigo de kvalito.
Juĝante laŭ la nombro da petoj, kiuj aperas en la komunumo, mi kredas, ke estas tempo. Kompreneble, mi ne certas, ke ĉi tio estos grandskala revolucio, sed mi ŝatus, ke ĉi tiu revolucio en la konscio okazu.
- Konsentis! Ni ensorbigos kulturon kaj ŝanĝos konscion.
Konferenco pri altkvalita disvolviĝo de IT-produktoj okazos en Moskvo la 7-an de junio. Vi scias, kiaj stadioj konsistigas altkvalitan produkton, ni havas kazojn de sukcese kontraŭbatali cimojn en produktado, ni testis popularajn metodojn en nia propra praktiko - ni bezonas vian sperton. ilia aplikaĵoj ĝis la 1-a de majo, kaj la Programa Komitato helpos enfokusigi la temon por la ĝenerala integreco de la konferenco.
Konekti al , en kiu ni diskutas kvalitajn aferojn kaj la konferencon, abonas por esti ĝisdatigita kun programaj novaĵoj.
fonto: www.habr.com