Ehi Habr!
Avemu un novu tema impurtante - u sviluppu di alta qualità di i prudutti IT. À HighLoad ++ spessu parlemu di cumu fà i servizii occupati veloci, è in Frontend Conf parlemu di una interfaccia d'utilizatore fresca chì ùn rallenta micca. Avemu regularmente temi nantu à a prova, è DevOpsConf nantu à cumminà diversi prucessi, cumprese a prova. Ma nantu à ciò chì pò esse chjamatu qualità in generale, è cumu travaglià in modu cumpletu - no.
Fixemu questu - Svilupperemu una cultura di pensà à a qualità di u pruduttu finali per l'utilizatori in ogni stadiu di u sviluppu. L'abitudine di ùn fucalizza micca in a vostra zona di rispunsabilità, è associà a qualità micca solu cù i testatori.
Sottu à u tagliu parlemu cù u capu di u cumitatu di u prugramma, capu di teste in Tinkoff.Business, creatore di a cumunità QA di lingua russa. Anastasia Aseeva-Nguyen circa u statu di l'industria QA è a missione di a nova cunferenza.
- Salutu Nastia. Per piacè dicci di sè stessu.
Anastasia: Gestisce a prova in un bancu, sò rispunsevuli di una squadra assai grande - simu più di 90 persone. Avemu una linea di cummerciale impurtante; simu rispunsevuli di l'ecosistema per e persone giuridiche.
Aghju studiatu a meccanica è a matematica è inizialmente vulia diventà un programatore. Ma quandu aghju avutu un'offerta interessante, decisu di pruvà à mè stessu cum'è testatore. Curiosamente, questu hè diventatu a mo vocazione. Avà vede tuttu u mo travagliu in questa industria.
Sò un ardente aderente di a disciplina di Assicuranza di Qualità. Ùn sò micca indifferenti à quali prudutti sò creati, cumu a qualità hè trattata in a cumpagnia, in a squadra è, in principiu, in u prucessu di sviluppu.
Hè evidenti per mè chì a cumunità in questa direzzione ùn hè micca abbastanza maturu, almenu in Russia. Ùn avemu micca sempre capitu chì l'assicuranza di qualità ùn hè micca solu u fattu di pruvà una applicazione per u rispettu di i requisiti. Vogliu cambià sta situazione.
- Aduprate e parolle Assicuranza di qualità è teste. In l'ochji di l'omu mediu, sti dui termini si superponu assai spessu. Cumu si differenzianu s'ellu scavà in profonda?
Anastasia: Piuttostu, ùn sò micca diffirenti. A prova hè parte di a disciplina di Assicuranza di a Qualità; hè una attività diretta - u fattu stessu chì aghju pruvatu qualcosa. Ci hè veramente assai tippi di teste, è una varietà di persone sò rispunsevuli di diversi tipi di teste. Ma quì in Russia, quandu una onda di outsourcers apparsu chì furnisce i teste à l'imprese, a prova hè stata ridotta à un solu tipu.
In a maiò parte di i casi, sò limitati solu à e teste funziunali: verificanu chì ciò chì i sviluppatori anu codificatu cumpletu cù a specificazione è questu hè tuttu.
— Per piacè diteci chì altre discipline di assicurazione di qualità ci sò ? Chì altru, in più di teste, hè inclusu quì?
Anastasia: Assicuranza di qualità hè, prima di tuttu, di creà un pruduttu di qualità. Vale à dì, ci dumandemu quale attributi di qualità deve avè u nostru pruduttu. Per quessa, se capiscenu questu, pudemu paragunà quale influenza questi attributi di qualità. Ùn hà micca impurtanza, sviluppatore, project manager o specialista di produttu hè una persona chì influenza u sviluppu di un pruduttu, u so backlog, è a so strategia.
U tester diventa più cuscente di u so rolu. Capisce chì u so compitu ùn hè micca solu di pruvà à u rispettu di i requisiti, ma ancu di pruvà i bisogni, interrogà e formulazioni chì venenu da u specialista di u produttu, è palesanu tutte e esigenze è aspettative implicite di u cliente. Quandu furnimu una nova funziunalità à i nostri clienti, duvemu veramente risponde à e so aspettative è risolve u so dulore. Se pensemu à tutti l'attributi di qualità, u cliente serà cuntentu è capisce chì a cumpagnia chì u so pruduttu usa veramente cura di i so interessi, è ùn travaglia micca nantu à u principiu di "solu per liberà una funzione".
- Sembra chì ciò chì avete appena descrittu hè u compitu di un specialista di produttu. Questu, in principiu, ùn hè micca di teste è micca di qualità - hè generalmente di gestione di u produttu, nò?
Anastasia: Inclusu. L'Assicuranza di Qualità ùn hè micca una disciplina per quale una persona specifica hè rispunsevule. Avà ci hè una direzzione populari in a prova, un approcciu chjamatu Test Agile. A so definizione dichjara chjaramente chì questu hè un approcciu di squadra à a prova, chì include un certu settore di pratiche. L'intera squadra hè rispunsevuli di implementà stu approcciu; ùn hè ancu necessariu chì ci sia un tester in a squadra. L'intera squadra hè focu annantu à furnisce u valore à u cliente è assicurendu chì u valore risponde à e aspettative di i clienti.
— Risulta chì a qualità s’incruciate cù quasi tutte e discipline circundante, impone un quadru à tuttu ciò chì circundava ?
Anastasia: Diritta. Quandu pensemu à cumu vulemu creà un pruduttu di qualità, cuminciamu à pensà à e diverse attributi di qualità. Per esempiu, cumu per verificà chì avemu veramente fattu a funzione chì u nostru cliente hà bisognu.
Questu hè induve vene stu tipu di teste: UAT (prova di accettazione di l'utilizatori). Sfortunatamente, hè raramente praticatu in Russia, ma hè qualchì volta presente in i squadre SCRUM cum'è una demo per u cliente finale. Questu hè un tipu abbastanza cumuni di teste in cumpagnie straniere. Prima di apre a funziunalità à tutti i clienti, facemu prima UAT, vale à dì, invitemu l'utente finale chì prova è immediatamente dà feedback - se u pruduttu risponde veramente à l'aspettattivi è risolve u dulore. Solu dopu à questu hè a scala à tutti l'altri clienti.
Vale à dì, focalizemu nantu à l'affari, nantu à u cliente finale, ma à u stessu tempu ùn vi scurdate di a tecnulugia. A qualità di u pruduttu dipende ancu assai di a tecnulugia. Se avemu una mala architettura, ùn pudemu micca liberà rapidamente funzioni è risponde à l'aspettattivi di i clienti. Ci ponu esse assai bugs quandu pruvate à scala, o quandu pruvate di refactor, pudemu rompe qualcosa. Tuttu chistu affetterà a satisfaczione di u cliente.
Da questu puntu di vista, l'architettura deve esse cusì chì pudemu scrive un codice pulito chì ci permetterà di fà rapidamente cambiamenti è ùn avè micca paura chì avemu da rompe tuttu. Allora chì l'iterazioni di rivisione ùn si stendenu più di parechji mesi solu perchè avemu tantu legatu, è avemu bisognu di fà tappe di teste longu.
- In tuttu, i sviluppatori, l'architetti, i scientisti di u produttu, i gestori di i prudutti è i testatori stessi sò digià implicati. Quale altru hè implicatu in u prucessu di assicuranza di qualità?
Anastasia: Ora imaginemu chì avemu digià furnitu a funzione à u cliente. Ovviamente, a qualità di u pruduttu deve esse monitoratu ancu quandu hè digià in produzzione. In questu stadiu, ponu appare situazzioni cù scenarii micca evidenti, cusì chjamati bugs.
A prima quistione hè cumu si tratta di questi bug dopu chì avemu digià liberatu u pruduttu? Cumu avemu, per esempiu, reagisce à u stress? U cliente ùn serà micca assai felice se a pagina piglia più di 30 seconde per carica.
Hè quì chì a sfruttamentu entra in ghjocu o, cum'è a chjamanu avà, DevOps. In fatti, queste sò e persone chì sò rispunsevuli di uperà u pruduttu quandu hè digià in produzzione. Questu include diversi tipi di surviglianza. Ci hè ancu un sottotipu di teste - teste nantu à a pruduzzione, quandu ci permettemu micca di pruvà qualcosa prima di u lanciu è pruvà immediatamente in a produzzione. Questa hè una seria di misure da u puntu di vista di l'urganizazione di l'infrastruttura chì permettenu di risponde rapidamente à un incidente, influenzallu è currettu.
L'infrastruttura hè ancu impurtante. Ci sò spessu situazioni quandu, durante una prova, hè impussibile di assicurà chì avemu veramente tuttu ciò chì vulemu dà à u cliente. U rollu in a produzzione è cuminciamu à catturà situazioni micca evidenti. È tuttu perchè l'infrastruttura in a prova ùn currisponde micca à l'infrastruttura in a pruduzzione. Questu porta à un novu tipu di teste - prova di l'infrastruttura. Quessi sò diverse cunfigurazioni, paràmetri, migrazione di basa di dati, etc.
Questu pone a quistione - forsi a squadra hà bisognu di utilizà l'infrastruttura cum'è codice.
Credu chì l'infrastruttura influenza direttamente a qualità di u pruduttu.
Spergu chì ci sarà un rapportu à a cunferenza cù un casu veru. Scriviteci se site prontu à dìci da a vostra propria sperienza cumu l'infrastruttura cum'è codice afecta a qualità. L'infrastruttura cum'è codice rende più faciule per verificà tutte e paràmetri è pruvà cose chì altrimenti ùn sò micca pussibule. Dunque, u funziunamentu hè ancu implicatu in u prucessu di sviluppà un pruduttu di qualità.
- E l'analisi è a documentazione?
Anastasia: Questu hè più appiicatu à i sistemi di l'impresa. Quandu parlemu di l'impresa, persone cum'è analisti è analisti di sistemi venenu immediatamente in mente. A volte sò chjamati scrittori tecnichi. Ricevenu un compitu per scrive una specificazione è compie, per esempiu, per un mesi.
Hè statu pruvucatu ripetutamente chì a scrittura di tali documentazioni porta à iterazioni di sviluppu assai longu è iterazioni longu di raffinamentu, perchè durante u prucessu di teste sò identificati i bug è i ritorni cumincianu. In u risultatu, ci sò assai cicli chì aumentanu i costi di sviluppu. Inoltre, questu pò intruduce vulnerabilità. Semu avè scrittu codice di riferimentu, ma dopu avemu fattu cambiamenti chì rompenu l'architettura perfettamente pensata.
U risultatu finale hè un pruduttu micca sanu d'alta qualità, perchè i patches sò digià apparsu in l'architettura, u codice in certi lochi ùn hè micca abbastanza coperto da e teste, perchè i termini sò sbulicati, tutti i bug deve esse chjusu rapidamente. È tuttu perchè a specificazione originale ùn hà micca cunsideratu tutti i punti chì deve esse implementatu.
I sviluppatori ùn sò micca pesti è ùn scrive micca codice cù errori apposta.
Sè avemu avutu prima pensatu à una specificazione chì averia coperta tutti i punti necessarii, allora tuttu hè statu implementatu esattamente cum'è necessariu. Ma questu hè una utopia.
Hè prubabilmente impussibile di scrive una specificazione perfetta di 100 pagine. Hè perchè bisognu di pensà à modi alternativi di scrive a documentazione, specificazioni, stabilisce i travaglii chì ci portanu più vicinu à assicurà chì u sviluppatore faci esattamente ciò chì hè necessariu.
Eccu l'avvicinamenti da Agile venenu in mente - storie d'utilizatori cù criteri di accettazione. Questu hè più applicabile per i gruppi chì si sviluppanu in picculi iterazioni.
- Chì ci hè a prova di usabilità, usabilità di u produttu, u disignu?
Anastasia: Questu hè un puntu assai impurtante, perchè ci sò diseggiani in a squadra. A maiò spessu, i diseggiani sò usati cum'è serviziu - sia da un dipartimentu di designu sia da un designer outsourcing. Ci sò spessu situazione induve pare chì u designer hà intesu u specialista di u produttu è hà fattu ciò chì hà capitu. Ma quandu avemu principiatu l'iterazione, risulta chì ciò chì hè statu fattu in realtà ùn era micca ciò chì era aspittatu: u designer hà scurdatu di qualcosa, ùn hà micca pensatu cumplettamente à u cumpurtamentu, perchè ùn hè micca in a squadra è micca in u cuntestu, o in fronte. -end sviluppatore ùn hà micca capitu cumplettamente u layout. Puderà piglià parechje iterazioni solu perchè ci hè un prublema cù u sviluppatore front-end chì capisce u disignu.
In più, ci hè un prublema più. I sistemi di design sò avà guadagnatu pupularità. Sò in hype, ma i benefizii da elli ùn sò micca completamente evidenti.
Aghju trovu l'opinione chì i sistemi di cuncepimentu, da una banda, simplificà u sviluppu, ma da l'altra banda, imponenu assai restrizioni à l'interfaccia.
In u risultatu, ùn facemu micca a funzione chì u cliente vole, ma quella chì hè cunvenuta per noi, perchè avemu digià certi cubi da quale pudemu fà.
Pensu chì questu hè un tema chì vale a pena di piglià un ochju è di dumandassi s'ellu circhendu di fà u disignu più faciule, risolvemu in realtà un puntu di dolore di u cliente.
- Ci hè una quantità sorprendente di temi ligati à l'Assicuranza di Qualità. Ci hè una cunferenza in Russia induve tutti ponu esse discututi?
Anastasia: Ci hè a cunferenza di prova più antica, chì si terrà per a 25a volta questu annu è hè chjamata SQA Days Quality Assurance Conference. Discute principalmente arnesi è approcci di prova specifichi per i tester funzionali. In regula, i rapporti in SQA Days esaminanu in profondità e aree specifiche in l'area di rispunsabilità di i testatori stessi, ma micca attività cumplesse.
Questu aiuta assai à capisce diverse arnesi è approcci, cumu pruvà e basa di dati, API, etc. Ma à u listessu tempu, da una banda, ùn hè micca motivatu à involucrà più di una prova in a creazione di un pruduttu megliu. Per d 'altra banda, i testatori ùn sò micca più implicati in u prucessu per pensà à u scopu globale di u pruduttu è u so cumpunente cummerciale.
I dirigenu un grande dipartimentu è cunduce assai interviste chì veramente furnisce una visione di u statu di l'industria in generale. In regula, i nostri picciotti travaglianu in imprese, è anu un spaziu chjaru di rispunsabilità. I culleghi chì travaglianu in prughjetti stranieri utilizanu diversi tipi di teste: elli stessi ponu fà teste di carica, teste di rendiment, è ancu qualchì volta teste di sicurezza, perchè aiutanu veramente a squadra à assicurà a qualità di u pruduttu.
Mi piacerebbe chì i ragazzi in Russia cumencianu ancu à pensà chì l'industria ùn finisci micca cù teste funziunali.
— Per questu scopu, urganizemu una nova cunferenza, QualityConf, chì hè dedicata à a qualità cum'è una disciplina integrale. Diteci più nantu à l'idea, quale hè u scopu principale di a cunferenza?
Anastasia: Vulemu creà una cumunità di persone interessate à fà prudutti di qualità. Offre una piattaforma induve ponu vene, ascolta i rapporti è partenu dopu à a cunferenza cù una cunniscenza specifica di ciò chì deve esse cambiatu per migliurà a qualità.
Oghje aghju intesu spessu una dumanda di cunsultà nantu à ciò chì fà quandu ci sò prublemi cù teste è qualità. Quandu avete principiatu à cumunicà cù e squadre, vi vede chì u prublema ùn hè micca cù i testatori stessi, ma cù cumu u prucessu hè strutturatu. Per esempiu, quandu i sviluppatori crèdenu chì sò solu rispunsevuli di scrive u codice, a so rispunsabilità finisce esattamente u mumentu chì trasmettenu u compitu à a prova.
Micca tutti pensanu à u fattu chì u codice pocu scrittu, di bassa qualità cù una architettura povera minaccia grossi prublemi per u prugettu. Ùn pensanu micca à u costu di l'errori, chì i bug chì finiscinu in a pruduzzione pò esse risultati in grandi costi per a cumpagnia è a squadra. Ùn ci hè micca cultura per pensà à questu. Vogliu chì principiemu a distribuzione à a cunferenza.
Aghju capitu chì questu ùn hè micca una innuvazione. Edward Deming, l'autore di i principii 14 di qualità, hà scrittu annantu à u costu di un errore in u seculu passatu. L'Assicuranza di Qualità cum'è una disciplina hè basatu annantu à stu libru, ma, sfurtunatamenti, u sviluppu mudernu si scurda di questu.
- Pensate à tuccà temi direttamente nantu à e teste è l'arnesi?
Anastasia: Admettu chì ci saranu rapporti nantu à l'arnesi. Ci sò arnesi abbastanza universali cù quale cumpagnie è squadre ponu influenzà u pruduttu.
Tutti i rapporti seranu uniti globalmente da una missione cumuna: per trasmette à l'audienza chì cù l'aiutu di questu approcciu, strumentu, metudu, prucessu, tipu di teste, avemu influenzatu a qualità di u pruduttu è migliurà a vita di u cliente.
Di sicuru, ùn averemu micca rapporti nantu à un strumentu per un strumentu. Tutti i rapporti inclusi in u prugramma seranu uniti da un scopu cumunu.
— Quale sarà interessatu da ciò chì parlate, quale vede cum’è invitati di a cunferenza ?
Anastasia: Averemu rapporti per i sviluppatori chì curanu u destinu di u so prughjettu, pruduttu, sistema. Di listessa manera, serà di interessu à i testatori è, mi pare, soprattuttu à i gestori. Per amministratori, vogliu dì e persone chì facenu decisioni è ponu influenzà u destinu è u sviluppu di un pruduttu, sistema, squadra ancu.
Quessi sò persone chì si dumandanu cumu migliurà a qualità di un pruduttu o sistema. À a nostra cunferenza, amparanu nantu à diversi insemi di misure è puderanu capisce ciò chì ci hè sbagliatu avà è ciò chì deve esse cambiatu.
Pensu chì u criteriu principale hè di capisce chì qualcosa hè sbagliatu cù a qualità è vulete influenzallu. Probabilmente ùn pudemu micca ghjunghje à e persone chì pensanu chì questu farà a prima volta.
- Pensate chì l'industria in generale hè matura per parlà micca solu di teste, ma di una cultura di qualità ?
Anastasia: Pensu chì aghju maturatu. Avà parechje cumpagnie si alluntananu da l'approcciu tradiziunale di Cascata versu Agile. Ci hè un focusu di u cliente, e persone in squadre cumincianu veramente à pensà à cumu creà un pruduttu di qualità. Ancu l'imprese di l'imprese si cuncentranu à migliurà a qualità.
A ghjudicà da u nùmeru di dumande chì si sviluppanu in a cumunità, crede chì hè u tempu. Ùn sò micca sicuru, sicuru, chì questu serà una rivoluzione à grande scala, ma mi piacerebbe chì sta rivoluzione in a cuscenza accade.
- D'accordu ! Instilleremu a cultura è cambià a cuscenza.
Cunferenza nantu à u sviluppu di alta qualità di i prudutti IT duverà in Mosca u 7 di ghjugnu. Sapete chì fasi custituiscenu un pruduttu d'alta qualità, avemu casi di cummattimentu successu di bug in a produzzione, avemu pruvatu metudi populari in a nostra pratica - avemu bisognu di a vostra sperienza. i so applicazioni prima di u 1 di maghju, è u Cumitatu di u prugramma aiuterà à fucalizza u tema per l'integrità generale di a cunferenza.
Cunnette vi , in quale discutemu di prublemi di qualità è a cunferenza, abbonate per stà infurmatu cù e nutizie di u prugramma.
Source: www.habr.com