Ciao, Habr!
Abbiamo un nuovo argomento importante: lo sviluppo di prodotti IT di qualità. Parliamo spesso su HighLoad++ di come rendere i servizi sovraccarichi rapidi, e su Frontend Conf di come avere un'interfaccia utente fantastica che non rallenti. Abbiamo regolarmente argomenti sul testing, e DevOpsConf sull'unione di diversi processi, incluso il testing. Ma riguardo a ciò che potremmo definire qualità nel complesso, e come lavorarci in modo integrato, non ne parliamo mai.
Correggiamo questo in — svilupperemo una cultura che considera la qualità del prodotto finale per l'utente in ogni fase dello sviluppo. L'abitudine a non limitarsi alla propria zona di responsabilità e a associare la qualità non solo ai tester.
Dopo il salto parleremo con la presidente del comitato programmatico, responsabile del testing in Tinkoff.Business, creatrice della community QA di lingua russa Anastasia Aseeva-Nguyen sullo stato dell'industria QA e sulla missione della nuova conferenza.
— Ciao, Nastya. Raccontaci un po' di te.
Anastasia: Guida il testing in banca, responsabile di un team molto grande: siamo più di 90 persone. Abbiamo una linea di business importante, ci occupiamo dell'ecosistema per le persone giuridiche.
Ho studiato matematica e fisica e inizialmente volevo diventare programmista. Ma quando ho ricevuto un'offerta interessante, ho deciso di provare a farmi strada come tester. Stranamente, mi sono ritrovata in questo ruolo. Ora vedo tutto il mio lavoro proprio in questo settore.
Sono un'appassionata sostenitrice della disciplina Quality Assurance. Mi importa quali prodotti vengono creati, come si affronta la qualità in azienda, nel team e, in generale, nel processo di sviluppo.
Per me è evidente che la comunità in questa direzione non è abbastanza matura, almeno in Russia. Non sempre comprendiamo che garantire la qualità non significa solo testare l'applicazione per verificarne la conformità ai requisiti. Vorrei cambiare questa situazione.
— Usando i termini Quality Assurance e testing. Nella mente del pubblico, questi due termini spesso si sovrappongono. Qual è la loro differenza, se ci si approfondisce?
Anastasia: In realtà, non si distinguono. Il testing è parte della disciplina del Quality Assurance, è un'attività diretta: il fatto stesso che io stia testando qualcosa. Ci sono in realtà molti tipi di testing, e diversi tipi di testing sono gestiti da persone molto diverse. Ma in Russia, quando è emersa la moda dei fornitori di servizi, che forniscono tester alle aziende, il testing si è ridotto a un'unica tipologia.
Nella maggior parte dei casi ci si limita solo al testing funzionale: si verifica che ciò che i programmatori hanno codificato corrisponda alle specifiche, e basta.
— Puoi raccontarmi, per favore, quali altri sono i settori della qualità? Cosa altro, oltre al testing, è coinvolto?
Anastasia: Il Quality Assurance riguarda, innanzitutto, la creazione di un prodotto di qualità. In altre parole, ci poniamo la domanda su quali attributi di qualità debba possedere il nostro prodotto. Di conseguenza, se lo comprendiamo, possiamo confrontare chi influisce su questi attributi di qualità. Non importa, sviluppatore, project manager o product owner — è una persona che influisce sullo sviluppo del prodotto, sul suo backlog, sulla sua strategia.
Il tester inizia a comprendere meglio il proprio ruolo. Capisce che il suo compito non è solo testare in base ai requisiti, ma anche testare i requisiti stessi, mettere in discussione le formulazioni provenienti dal product owner, rivelare tutti i requisiti impliciti e le aspettative del cliente. Quando forniamo una nuova funzionalità al nostro cliente, dobbiamo realmente soddisfare le sue aspettative e risolvere i suoi problemi. Se consideriamo tutti gli attributi di qualità, il cliente sarà soddisfatto e comprenderà che l'azienda il cui prodotto sta utilizzando si prende davvero cura dei suoi interessi, e non sta semplicemente seguendo il principio di "far uscire una funzionalità a tutti i costi".
— Sembra che ciò che hai descritto sia il compito del product owner. In sostanza, non riguarda il testing e non riguarda la qualità, riguarda davvero il product management, giusto?
Anastasia: In parte. Il Quality Assurance non è una disciplina di cui si occupa una singola persona. Ora c'è un approccio popolare nel testing, che si chiama Agile Testing. Nella sua definizione si afferma chiaramente che si tratta di un approccio di squadra ai test, che include un insieme specifico di pratiche. La responsabilità dell’implementazione di questo approccio ricade su tutta la squadra, non è necessario che ci sia un tester nel team. Tutta la squadra è focalizzata sul fornire valore al cliente e assicurarsi che questo valore soddisfi le sue aspettative.
— Risulta quindi che la qualità si interseca quasi con tutte le discipline circostanti, imponendo dei limiti a tutto ciò che ci circonda?
Anastasia: Esatto. Quando ci pensiamo, vogliamo creare un prodotto di qualità, iniziamo a riflettere su diversi attributi della qualità. Ad esempio, come verificare che abbiamo realmente sviluppato una funzionalità che sia necessaria per il nostro cliente.
Qui emerge un tipo di test, come UAT (user acceptance testing). Sfortunatamente, in Russia è raramente praticato, ma a volte è presente nei team SCRUM, come demo per il cliente finale. Nelle aziende estere è un tipo di test piuttosto comune. Prima di aprire la funzionalità a tutti i clienti, prima facciamo l'UAT, cioè invitiamo il consumatore finale, che effettua i test e fornisce immediatamente un feedback — se il prodotto corrisponde alle aspettative e risolve i problemi. Solo dopo avviene la scalabilità per tutti gli altri clienti.
Quindi ci orientiamo verso il business, verso il cliente finale, ma nel frattempo non dimentichiamo la tecnologia. Anche la tecnologia influisce notevolmente sulla qualità del prodotto. Se abbiamo una cattiva architettura, non saremo in grado di rilasciare rapidamente funzionalità e soddisfare le aspettative del cliente. Possono sorgere molti bug durante il tentativo di scalare, o durante un tentativo di refactoring possiamo rompere qualcosa. Tutto questo influenzerà la soddisfazione del cliente.
Da questo punto di vista, l'architettura deve essere tale da permetterci di scrivere codice pulito, in grado di apportare rapidamente modifiche e senza paura di rompere tutto. Affinché le iterazioni di sviluppo non si protraggano per mesi semplicemente perché abbiamo così tanto legacy e sono necessari lunghi periodi di test.
— In sintesi, sono già coinvolti sviluppatori, architetti, product manager, product owner, e stessi tester. Chi altro è coinvolto nel processo di assicurazione della qualità?
Anastasia: Ora immaginiamo che abbiamo già consegnato la funzionalità al cliente. È ovvio che dobbiamo tenere sotto controllo la qualità del prodotto, anche quando è in produzione. A questo punto possono manifestarsi situazioni con scenari non evidenti, i cosiddetti bug.
La prima domanda è: come gestiamo questi bug dopo che abbiamo rilasciato il prodotto? Come rispondiamo, ad esempio, al carico? Il cliente non sarà molto soddisfatto se la pagina ci mette più di 30 secondi a caricarsi.
Qui entra in gioco l'operatività o, come la si chiama adesso, DevOps. In effetti, queste sono le persone responsabili dell'operatività del prodotto quando è già in produzione. Ciò include vari tipi di monitoraggio. Esiste persino un sottotipo di testing, il testing in produzione, quando ci permettiamo di non testare nulla prima del rilascio e testiamo direttamente in produzione. Queste sono una serie di misure dal punto di vista dell'organizzazione dell'infrastruttura, che consentono di reagire rapidamente a un incidente, influenzarlo e correggerlo.
Anche l'infrastruttura è importante. Ci sono spesso situazioni in cui durante il test non possiamo essere certi che abbiamo davvero tutto ciò che vorremmo dare al cliente. Rilasciamo in produzione e iniziamo a catturare situazioni non evidenti. E tutto ciò accade perché l'infrastruttura nel test non corrisponde a quella in produzione. Da qui emerge un nuovo tipo di testing — il testing dell'infrastruttura. Include diverse configurazioni, impostazioni, migrazioni di database, ecc.
Da qui sorge la domanda: forse il team ha bisogno di utilizzare l'infrastruttura come codice.
Credo che l'infrastruttura influisca direttamente sulla qualità del prodotto.
Spero che alla conferenza ci sarà una presentazione con un caso reale. Scriveteci se siete pronti a raccontare dalla vostra esperienza come l'infrastruttura come codice influisce sulla qualità. L'infrastruttura come codice consente di controllare più facilmente tutte le impostazioni e testare ciò che altrimenti sarebbe semplicemente impossibile. Pertanto, nel processo di sviluppo di un prodotto di qualità è coinvolta anche l'operatività.
— E per quanto riguarda l'analisi e la documentazione?
Anastasia: Questo è più pertinente ai sistemi enterprise. Quando parliamo di enterprise, ci vengono subito in mente persone come analisti e analisti di sistemi. A volte sono chiamati scrittori tecnici. Ricevono l'incarico di scrivere una specifica e lo portano a termine, ad esempio, in un mese.
È stato dimostrato più volte che la redazione di una tale documentazione porta a iterazioni di sviluppo molto lunghe e iterazioni estese di perfezionamento, poiché durante il processo di test emergono bug e hanno inizio i ritorni. Di conseguenza, si generano molti cicli che aumentano il costo dello sviluppo. Inoltre, questo può introdurre vulnerabilità. Sembrerebbe che abbiamo scritto codice di riferimento, ma poi abbiamo apportato modifiche che rompono un'architettura perfettamente concepita.
Ne risulta un prodotto di qualità non del tutto soddisfacente, poiché nell'architettura sono già apparse toppe, il codice in alcune parti non è adeguatamente coperto da test, perché le scadenze sono pressanti e bisogna risolvere più rapidamente tutti i bug. E tutto ciò accade perché nella specifica iniziale non sono stati considerati tutti gli aspetti da realizzare.
Gli sviluppatori non sono malintenzionati e non scrivono volontariamente codice con errori.
Se avessimo pensato inizialmente a una specifica che includesse tutti i punti necessari, tutto sarebbe stato implementato esattamente come doveva essere. Ma questa è una utopia.
Probabilmente, scrivere una specifica ideale di 100 pagine è impossibile. Pertanto è necessario riflettere su metodi alternativi di redazione della documentazione, specificazione e definizione di compiti che ci avvicinino a far sì che lo sviluppatore faccia precisamente ciò che è necessario.
Qui vengono in mente approcci che derivano dall'Agile: user stories con criteri di accettazione. Questo è maggiormente applicabile a team che crescono attraverso piccole iterazioni.
— Cosa ne pensi del testing di usabilità, della facilità d'uso del prodotto e del design?
Anastasia: Questo è un aspetto molto importante, poiché nella squadra ci sono designer. Spesso i designer sono considerati come un servizio: o un reparto design o un designer in outsourcing. Spesso si verificano situazioni in cui sembra che il designer abbia ascoltato il product manager e abbia fatto ciò che ha capito. Ma quando iniziamo l'iterazione, si scopre che in realtà non è stato fatto quello che ci aspettavamo: il designer ha dimenticato qualcosa, non ha pianificato completamente il comportamento, perché non è parte del team e non è nel contesto, o lo sviluppatore frontend non ha capito a pieno il suo layout. Potrebbero essere necessarie diverse iterazioni solo a causa del fatto che c'è un problema con la comprensione del design da parte dello sviluppatore frontend.
In aggiunta, c'è un altro problema. Al momento i sistemi di design stanno guadagnando popolarità. Sono molto in voga, ma i benefici non sono del tutto evidenti.
Mi confronto con l'opinione secondo cui i sistemi di design, da un lato, semplificano lo sviluppo, ma dall'altro impongono molte restrizioni all'interfaccia.
Di conseguenza, non realizziamo esattamente la funzionalità che il cliente desidera, ma quella comoda per noi, perché abbiamo già dei componenti definiti da cui possiamo crearla.
Credo che sia importante prestare attenzione a questo tema e riflettere se, nel tentativo di semplificare il lavoro sul design, stiamo realmente risolvendo i problemi dei clienti.
— Si presenta sorprendentemente molti temi legati alla Quality Assurance. In Russia c'è una conferenza dove si possono discutere tutti?
Anastasia: C'è la conferenza più antica nel campo del testing, che quest'anno si terrà per la 25ª volta e si chiama proprio così — Conferenza sulla qualità SQA Days. Principalmente si discutono strumenti e approcci specifici per il testing per i tester funzionali. Di solito, nelle presentazioni degli SQA Days si esaminano approfonditamente aree specifiche nelle responsabilità dei tester stessi, ma non eventi complessivi.
Questo aiuta molto a comprendere i vari strumenti e approcci su come testare i database, le API, ecc. Tuttavia, da un lato, non motiva a coinvolgere nella creazione di un prodotto di maggiore qualità non solo il testing. E dall'altro, i tester non diventano più coinvolti nel processo per pensare all'obiettivo globale del prodotto e alla sua componente commerciale.
Dirigo un grande reparto, svolgo molti colloqui che in realtà consentono di rappresentare lo stato del settore nel suo complesso. Di solito, i nostri ragazzi lavorano in ambito enterprise, e hanno un'area di responsabilità chiara. I colleghi che lavorano a progetti internazionali utilizzano diversi tipi di testing: possono effettuare test di carico, test di prestazione e a volte anche test di sicurezza (security testing), perché contribuiscono realmente a garantire la qualità del prodotto.
Mi piacerebbe che anche in Russia i ragazzi cominciassero a riflettere sul fatto che nel testing funzionale il settore non si esaurisce.
— Per questo stiamo organizzando una nuova conferenza QualityConf, dedicata alla qualità come disciplina olistica. Raccontami di più sull'idea, qual è l'obiettivo principale della conferenza?
Anastasia: Vogliamo creare una comunità di persone interessate a realizzare prodotti di qualità. Offrire uno spazio dove possano venire, ascoltare le relazioni e uscire dalla conferenza con una comprensione chiara di cosa devono cambiare in loro stessi per migliorare la qualità.
Spesso sento ora la richiesta da parte del consulting su cosa fare quando ci sono problemi con i test e con la qualità. Quando inizi a parlare con i team, vedi che il problema non è nei tester stessi, ma nel modo in cui è strutturato il processo. Ad esempio, quando i programmatori pensano di essere responsabili solo per la scrittura del codice, la loro responsabilità finisce esattamente nel momento in cui consegnano il compito al testing.
Non tutti riflettono sul fatto che un codice mal scritto e di scarsa qualità con una cattiva architettura può portare a grandi problemi per il progetto. Non riflettono sul costo degli errori, sul fatto che i bug che arrivano in produzione possono generare grandi spese per l'azienda e per il team. Non c'è una cultura di pensare a questo. Voglio che durante la conferenza iniziamo a diffonderla.
Capisco che non si tratta di innovazione. Edward Deming, autore dei 14 principi di qualità, scriveva del costo degli errori già nel secolo scorso. Questa idea è alla base del Quality Assurance come disciplina, ma, sfortunatamente, lo sviluppo moderno se ne dimentica.
— Intendete toccare anche temi direttamente legati ai test e agli strumenti?
Anastasia: Ammetto che ci saranno relazioni sugli strumenti. Ci sono strumenti abbastanza universali grazie ai quali le aziende e i team possono influenzare il prodotto.
Tutte le relazioni saranno globalmente unite da una comune missione: comunicare al pubblico che grazie a questo approccio, strumento, metodo, processo, tipo di test abbiamo influenzato la qualità del prodotto e migliorato la vita del cliente.
Non avremo sicuramente relazioni su strumenti per il gusto di avere strumenti. Tutte le relazioni che entreranno nel programma saranno unite da un obiettivo comune.
— A chi sarà interessante ciò di cui parli, chi vedi come ospiti della conferenza?
Anastasia: Avremo relazioni per sviluppatori che si prendono cura del destino del loro progetto, prodotto o sistema. Sarà interessante anche per i tester e, a mio avviso, soprattutto per i manager. Con manager intendo quelle persone che prendono decisioni e possono influenzare il destino e lo sviluppo del prodotto, del sistema e del team incluso.
Queste sono persone che si chiedono come migliorare la qualità del prodotto e del sistema. Alla nostra conferenza, scopriranno vari complessi eventi e potranno capire cosa non va al momento e cosa deve essere cambiato.
Penso che il criterio principale sia comprendere che c'è qualcosa che non va con la qualità e voler influenzare questo. Probabilmente non riusciremo a farci ascoltare al primo tentativo da chi pensa che vada bene così.
— Cosa ne pensi, l'industria è pronta per parlare non solo di testing, ma anche di cultura della qualità?
Anastasia: Penso di sì. Al momento molte aziende si stanno allontanando dall'approccio tradizionale Waterfall verso Agile. C'è un'orientamento verso il cliente, e le persone nei team stanno realmente iniziando a riflettere su come creare un prodotto di qualità. Anche nelle aziende enterprise si sta avviando una ri-orientazione al miglioramento della qualità.
A giudicare dal numero di richieste che emergono nella comunità, credo sia arrivato il momento. Non sono sicura che sarà una rivoluzione su larga scala, ma mi piacerebbe che questo cambiamento di mentalità avvenisse.
— D'accordo! Lavoreremo per instillare la cultura e cambiare la mentalità.
Conferenza sulla sviluppo qualitativo dei prodotti IT si svolgerà a Mosca il 7 giugno. Sapete quali fasi compongono un prodotto di qualità, abbiamo casi di successo nella lotta contro i bug in produzione, nella nostra pratica abbiamo testato tecniche popolari — abbiamo bisogno della vostra esperienza. le tue candidature entro il 1 maggio, e il Comitato Programmatico aiuterà a focalizzare il tema per l'unità complessiva della conferenza.
Collegati al , dove discutiamo questioni di qualità e la conferenza, iscriviti a , per rimanere aggiornato sulle novità del programma.
Fonte: habr.com
