Chi è responsabile della qualità?

Ehi Habr!

Abbiamo un nuovo argomento importante: lo sviluppo di alta qualità di prodotti IT. A HighLoad++ parliamo spesso di come rendere veloci i servizi impegnati e a Frontend Conf parliamo di un'interfaccia utente interessante che non rallenta. Abbiamo regolarmente argomenti sui test e DevOpsConf sulla combinazione di diversi processi, inclusi i test. Ma su ciò che può essere chiamato qualità in generale e su come lavorarci in modo completo - no.

Risolviamo questo problema QualitàConf — svilupperemo una cultura basata sulla qualità del prodotto finale per l'utente in ogni fase dello sviluppo. L'abitudine di non concentrarsi sulla propria area di responsabilità e di associare la qualità non solo ai tester.

Sotto il taglio parleremo con il capo del comitato di programma, responsabile dei test presso Tinkoff.Business, creatore della comunità di QA di lingua russa Anastasia Aseeva-Nguyen sullo stato del settore QA e sulla missione della nuova conferenza.

-Nastia ciao. Per favore, parlaci di te.

Anastasia: Gestisco i test presso una banca, sono responsabile di un team molto numeroso: siamo più di 90 persone. Abbiamo una linea di business importante, siamo responsabili dell’ecosistema per le persone giuridiche.

Ho studiato meccanica e matematica e inizialmente volevo diventare programmatore. Ma quando ho ricevuto un'offerta interessante, ho deciso di cimentarmi come tester. Stranamente, questa si è rivelata essere la mia vocazione. Ora vedo tutto il mio lavoro in questo settore.

Sono un convinto sostenitore della disciplina dell'Assicurazione della Qualità. Non sono indifferente a quali prodotti vengono creati, a come viene trattata la qualità in azienda, nel team e, in linea di principio, nel processo di sviluppo.

Per me è ovvio la comunità in questa direzione non è abbastanza matura, almeno in Russia. Non sempre comprendiamo che la garanzia della qualità non è solo il fatto di testare un'applicazione per verificarne la conformità ai requisiti. Vorrei cambiare questa situazione.

— Utilizzi le parole Garanzia di qualità e test. Agli occhi della persona media, questi due termini molto spesso si sovrappongono. In cosa differiscono se scavi in ​​profondità?

Anastasia: Piuttosto, non sono diversi. Il testing fa parte della disciplina dell'assicurazione della qualità; è un'attività diretta: il fatto stesso che sto testando qualcosa. In realtà esistono molti tipi di test e una varietà di persone è responsabile di diversi tipi di test. Ma qui in Russia, quando è apparsa un'ondata di outsourcer che forniscono tester alle aziende, i test sono stati ridotti a un unico tipo.

Nella maggior parte dei casi si limitano solo ai test funzionali: controllano che ciò che gli sviluppatori hanno codificato sia conforme alle specifiche e basta.

— Per favore, dicci quali altre discipline di garanzia della qualità esistono? Cos'altro, oltre ai test, è incluso qui?

Anastasia: La garanzia della qualità riguarda, prima di tutto, la creazione di un prodotto di qualità. Ci chiediamo cioè quali attributi di qualità debba avere il nostro prodotto. Di conseguenza, se lo comprendiamo, possiamo confrontare chi influenza questi attributi di qualità. Non importa, sviluppatore, project manager o specialista di prodotto è una persona che influenza lo sviluppo di un prodotto, il suo backlog e la sua strategia.

Il tester diventa più consapevole del suo ruolo. Capisce che il suo compito non è solo verificare la conformità ai requisiti, ma anche testare i requisiti, mettere in discussione le formulazioni provenienti dallo specialista del prodotto e rivelare tutti i requisiti e le aspettative implicite del cliente. Quando forniamo nuove funzionalità ai nostri clienti, dobbiamo veramente soddisfare le loro aspettative e risolvere i loro problemi. Se consideriamo tutti gli attributi della qualità, il cliente sarà soddisfatto e capirà che l'azienda di cui utilizza il prodotto si preoccupa davvero dei suoi interessi e non lavora secondo il principio "solo per rilasciare una funzionalità".

— Sembra che quello che hai appena descritto sia il compito di uno specialista di prodotto. In linea di principio, non si tratta di test e non di qualità: si tratta generalmente di gestione del prodotto, no?

Anastasia: Compreso. L'assicurazione della qualità non è una disciplina di cui è responsabile una persona specifica. Ora esiste una direzione popolare nei test, un approccio chiamato Test Agile. La sua definizione afferma chiaramente che si tratta di un approccio di squadra al test, che include un certo insieme di pratiche. L’intero team è responsabile dell’implementazione di questo approccio; non è nemmeno necessario che ci sia un tester nel team. L'intero team è concentrato sulla fornitura di valore al cliente e sulla garanzia che il valore soddisfi le aspettative del cliente.

— Si scopre che la qualità si interseca con quasi tutte le discipline circostanti, imponendo una struttura a tutto ciò che la circonda?

Anastasia: Giusto. Quando pensiamo a come vogliamo creare un prodotto di qualità, iniziamo a pensare ai vari attributi della qualità. Ad esempio, come verificare che abbiamo realmente realizzato la funzionalità di cui il nostro cliente ha bisogno.

È qui che entra in gioco questo tipo di test: SVS (test di accettazione da parte dell'utente). Sfortunatamente, in Russia è praticato raramente, ma a volte è presente nei team SCRUM come demo per il cliente finale. Questo è un tipo di test abbastanza comune nelle aziende straniere. Prima di aprire la funzionalità a tutti i clienti, eseguiamo prima l'UAT, ovvero invitiamo l'utente finale a testare e fornire immediatamente un feedback, se il prodotto soddisfa davvero le aspettative e risolve il problema. Solo dopo avviene il dimensionamento a tutti gli altri client.

Cioè ci concentriamo sul business, sul cliente finale, ma allo stesso tempo non dimenticare la tecnologia. La qualità del prodotto dipende molto anche dalla tecnologia. Se disponiamo di un'architettura inadeguata, non saremo in grado di rilasciare rapidamente funzionalità e soddisfare le aspettative dei clienti. Potrebbero esserci molti bug durante il tentativo di ridimensionamento o durante il tentativo di refactoring potremmo rompere qualcosa. Tutto ciò influirà sulla soddisfazione del cliente.

Da questo punto di vista, l'architettura dovrebbe essere tale da poter scrivere un codice pulito che ci permetta di apportare modifiche rapidamente e non avere paura di rompere tutto. In modo che le iterazioni di revisione non si estendano per diversi mesi semplicemente perché abbiamo così tanta eredità e dobbiamo eseguire lunghe fasi di test.

— In totale, sono già coinvolti sviluppatori, architetti, scienziati di prodotto, product manager e gli stessi tester. Chi altro è coinvolto nel processo di garanzia della qualità?

Anastasia: Ora immaginiamo di aver già consegnato la funzionalità al cliente. Ovviamente la qualità del prodotto va monitorata anche quando è già in produzione. In questa fase possono presentarsi situazioni con scenari non ovvi, i cosiddetti bug.

La prima domanda è: come affrontiamo questi bug dopo che abbiamo già rilasciato il prodotto? Come reagiamo, ad esempio, allo stress? Il cliente non sarà molto contento se la pagina impiega più di 30 secondi per caricarsi.

È qui che entra in gioco lo sfruttamento o, come lo chiamano adesso, DevOps. In realtà, queste sono le persone responsabili del funzionamento del prodotto quando è già in produzione. Ciò include vari tipi di monitoraggio. Esiste anche un sottotipo di test: il test in produzione, quando ci permettiamo di non testare qualcosa prima del lancio e di testarlo immediatamente in produzione. Si tratta di una serie di misure dal punto di vista dell'organizzazione delle infrastrutture che consentono di rispondere rapidamente a un incidente, influenzarlo e correggerlo.

Importanti sono anche le infrastrutture. Ci sono spesso situazioni in cui, durante una prova, è impossibile assicurarsi di avere davvero tutto ciò che vorremmo dare al cliente. Lo lanciamo in produzione e iniziamo a rilevare situazioni non ovvie. E tutto perché l'infrastruttura in prova non corrisponde all'infrastruttura in produzione. Ciò porta a un nuovo tipo di test: test delle infrastrutture. Si tratta di varie configurazioni, impostazioni, migrazione del database, ecc.

Ciò solleva la domanda: forse il team deve utilizzare l'infrastruttura come codice.

Credo che l'infrastruttura influisca direttamente sulla qualità del prodotto.

Spero che alla conferenza ci sarà una relazione con un caso reale. Scrivici se sei pronto a raccontarci dalla tua esperienza come l'infrastruttura come codice influisce sulla qualità. L'infrastruttura come codice semplifica il controllo di tutte le impostazioni e il test di cose che altrimenti semplicemente non sarebbero possibili. Pertanto, anche l'operazione è coinvolta nel processo di sviluppo di un prodotto di qualità.

— E che dire dell'analisi e della documentazione?

Anastasia: Questo vale maggiormente per i sistemi aziendali. Quando si parla di impresa vengono subito in mente persone come analisti e analisti di sistema. A volte sono chiamati scrittori tecnici. Ricevono l'incarico di scrivere una specifica e completarla, ad esempio, per un mese.

È stato più volte dimostrato che scrivere tale documentazione porta a iterazioni di sviluppo molto lunghe e lunghe iterazioni di perfezionamento, perché durante il processo di test vengono identificati i bug e iniziano i resi. Di conseguenza, ci sono molti loop che aumentano i costi di sviluppo. Inoltre, ciò potrebbe introdurre vulnerabilità. Sembra che abbiamo scritto il codice di riferimento, ma poi abbiamo apportato modifiche che interrompono l'architettura perfettamente congegnata.

Il risultato finale è un prodotto non del tutto di qualità, perché nell'architettura sono già comparse delle patch, il codice in alcuni punti non è sufficientemente coperto dai test, perché le scadenze stanno per scadere, tutti i bug devono essere chiusi velocemente. E tutto perché le specifiche originali non tenevano conto di tutti i punti che dovevano essere implementati.

Gli sviluppatori non sono parassiti e non scrivono codice con errori di proposito.

Se inizialmente avessimo pensato a una specifica che coprisse tutti i punti necessari, tutto sarebbe stato implementato esattamente come necessario. Ma questa è un'utopia.

Probabilmente è impossibile scrivere una specifica perfetta di 100 pagine. Ecco perché bisogno di pensare a modi alternativi di scrivere la documentazione, specifiche, impostazione di attività che ci avvicinino a garantire che lo sviluppatore faccia esattamente ciò che è necessario.

Qui vengono in mente gli approcci Agile: storie di utenti con criteri di accettazione. Questo è più applicabile ai team che si sviluppano in piccole iterazioni.

— Che dire dei test di usabilità, usabilità del prodotto, design?

Anastasia: Questo è un punto molto importante, perché ci sono dei designer nel team. Nella maggior parte dei casi, i designer vengono utilizzati come un servizio, sia da un dipartimento di progettazione che da un designer in outsourcing. Ci sono spesso situazioni in cui sembra che il designer abbia ascoltato lo specialista del prodotto e abbia fatto ciò che aveva capito. Ma quando iniziamo l'iterazione, si scopre che ciò che è stato effettivamente fatto non era quello che ci si aspettava: il designer ha dimenticato qualcosa, non ha riflettuto completamente sul comportamento, perché non è nella squadra e non nel contesto, o in prima linea -end lo sviluppatore non ne ha compreso appieno il layout. Potrebbero essere necessarie diverse iterazioni solo perché si è verificato un problema con lo sviluppatore front-end nella comprensione del progetto.

In più c'è un altro problema. I sistemi di progettazione stanno ora guadagnando popolarità. Sono in campagna pubblicitaria, ma i benefici che ne derivano non sono del tutto evidenti.

Mi imbatto nell'opinione che i sistemi di progettazione, da un lato, semplificano lo sviluppo, ma dall'altro impongono molte restrizioni all'interfaccia.

Di conseguenza, non realizziamo la funzionalità che il cliente desidera, ma quella che è conveniente per noi, perché disponiamo già di alcuni cubi da cui possiamo realizzarla.

Penso che questo sia un argomento che vale la pena dare un'occhiata e chiedersi se nel tentativo di semplificare la progettazione stiamo effettivamente risolvendo un punto dolente del cliente.

— Esiste un numero sorprendente di argomenti relativi alla garanzia della qualità. C'è una conferenza in Russia dove si possono discutere tutti?

Anastasia: Esiste la conferenza di test più antica, che quest'anno si terrà per la 25a volta e si chiama SQA Days Quality Assurance Conference. Discute principalmente strumenti e approcci di test specifici per i tester funzionali. Di norma, i resoconti degli SQA Days approfondiscono ambiti specifici nell'ambito di responsabilità dei tester stessi, ma non attività complesse.

Questo aiuta molto a comprendere diversi strumenti e approcci, come testare database, API, ecc. Ma allo stesso tempo, da un lato, non motiva a coinvolgere qualcosa di più che semplici test nella creazione di un prodotto migliore. D'altra parte, i tester non vengono maggiormente coinvolti nel processo per pensare all'obiettivo globale del prodotto e alla sua componente aziendale.

Gestisco un grande dipartimento e conduco molte interviste che forniscono davvero informazioni sullo stato del settore nel suo insieme. Di norma, i nostri ragazzi lavorano nelle imprese e hanno una chiara area di responsabilità. I colleghi che lavorano in progetti esteri utilizzano diversi tipi di test: loro stessi possono eseguire test di carico, test delle prestazioni e talvolta anche test di sicurezza, perché aiutano davvero il team a garantire la qualità del prodotto.

Vorrei che anche i ragazzi in Russia iniziassero a pensare che il settore non si esaurisce con i test funzionali.

— A questo scopo stiamo organizzando un nuovo convegno, QualityConf, dedicato alla qualità come disciplina integrale. Raccontaci di più sull'idea, qual è l'obiettivo principale della conferenza?

Anastasia: Vogliamo creare una community di persone interessate a realizzare prodotti di qualità. Offrire una piattaforma dove possano venire, ascoltare i resoconti e andarsene dopo la conferenza con una comprensione specifica di ciò che deve essere cambiato per migliorare la qualità.

Al giorno d'oggi sento spesso chiedere dalla consulenza cosa fare quando ci sono problemi con i test e la qualità. Quando inizi a comunicare con i team, vedi che il problema non sono i tester stessi, ma il modo in cui è strutturato il processo. Ad esempio, quando gli sviluppatori ritengono di essere responsabili solo della scrittura del codice, la loro responsabilità termina esattamente nel momento in cui affidano il compito al testing.

Non tutti pensano al fatto che un codice scritto male, di bassa qualità con un'architettura scadente minacci grossi problemi per il progetto. Non pensano al costo degli errori, al fatto che i bug che finiscono in produzione possono comportare grandi costi per l’azienda e il team. Non c’è cultura per pensare a questo. Voglio che iniziamo a distribuirlo alla conferenza.

Capisco che questa non sia un'innovazione. Edward Deming, l'autore dei 14 principi della qualità, scrisse sul costo di un errore già nel secolo scorso. L'assicurazione della qualità come disciplina si basa su questo libro, ma sfortunatamente lo sviluppo moderno se ne dimentica.

— Hai intenzione di toccare direttamente argomenti relativi ai test e agli strumenti?

Anastasia: Ammetto che ci saranno segnalazioni sugli strumenti. Esistono strumenti abbastanza universali con cui aziende e team possono influenzare il prodotto.

Tutti i report saranno uniti a livello globale da una missione comune: trasmettere al pubblico che con l'aiuto di questo approccio, strumento, metodo, processo, tipo di test, abbiamo influenzato la qualità del prodotto e migliorato la vita del cliente.

Sicuramente non avremo resoconti su uno strumento fine a se stesso. Tutti i report inseriti nel programma saranno uniti da un obiettivo comune.

— Chi sarà interessato a ciò di cui parli, chi vedi come ospiti della conferenza?

Anastasia: Avremo report per gli sviluppatori che hanno a cuore il destino del loro progetto, prodotto, sistema. Allo stesso modo, interesserà i tester e, mi sembra, soprattutto i manager. Per manager intendo persone che prendono decisioni e possono influenzare il destino e lo sviluppo di un prodotto, sistema, team.

Queste sono persone che si chiedono come migliorare la qualità di un prodotto o sistema. Alla nostra conferenza conosceranno diverse serie di misure e saranno in grado di capire cosa c’è che non va in loro adesso e cosa deve essere cambiato.

Penso che il criterio principale sia capire che c'è qualcosa che non va nella qualità e voler influenzarla. Probabilmente non saremo in grado di raggiungere le persone che pensano che questo andrà bene solo la prima volta.

— Pensi che il settore nel suo complesso sia maturo per parlare non solo di test, ma di cultura della qualità?

Anastasia: Penso di essere maturato. Ora molte aziende si stanno allontanando dal tradizionale approccio Waterfall verso Agile. C'è un focus sul cliente, le persone nei team stanno davvero iniziando a pensare a come creare un prodotto di qualità. Anche le aziende si stanno concentrando nuovamente sul miglioramento della qualità.

A giudicare dal numero di richieste che stanno emergendo nella comunità, credo che sia giunto il momento. Non sono sicuro, ovviamente, che questa sarà una rivoluzione su larga scala, ma vorrei che questa rivoluzione nella coscienza avvenisse.

- Concordato! Infonderemo cultura e cambieremo la coscienza.

Conferenza sullo sviluppo di alta qualità dei prodotti IT QualitàConf состоится a Mosca il 7 giugno. Sai quali fasi compongono un prodotto di alta qualità, abbiamo casi di lotta efficace contro i bug nella produzione, abbiamo testato metodi popolari nella nostra pratica: abbiamo bisogno della tua esperienza. Inviare loro domande entro il 1 maggio, e il Comitato del programma aiuterà a focalizzare il tema per l'integrità complessiva della conferenza.

Connetti a chiacchierata, in cui discutiamo di questioni di qualità e della conferenza, iscriviti a Canale Telegramper rimanere aggiornato sulle novità del programma.

Fonte: habr.com