Chi è responsabile della qualità?

Ciao, Habr!

Abbiamo un nuovo tema importante: lo sviluppo di prodotti IT di qualità. Parliamo spesso di HighLoad++ su come rendere i servizi sovraccaricati veloci, e al Frontend Conf di un'interfaccia utente fantastica che non rallenta. Affrontiamo regolarmente argomenti sul testing e a DevOpsConf sulla fusione di diversi processi, incluso il testing. Ma riguardo a cosa si può considerare qualità in generale e come lavorare su di essa in modo complesso - non se ne parla.

Correggeremo questo in QualityConf — svilupperemo una cultura di pensiero sulla qualità del prodotto finale per l'utente a ogni fase dello sviluppo. L'abitudine a non rimanere bloccati nella propria area di responsabilità e associare la qualità non solo ai tester.

Sotto parleremo con la presidente del comitato programmatorio, responsabile del testing in Tinkoff.Bussiness, fondatrice della comunità QA di lingua russa Anastasia Aseeva-Nguyen sulla situazione del settore QA e la missione della nuova conferenza.

— Ciao Nastya, raccontaci un po' di te.

Anastasia: Guida il testing in banca, sono responsabile di un team molto ampio — siamo più di 90 persone. Gestiamo una linea di business importante, ci occupiamo dell'ecosistema per le aziende.

Ho studiato matematica e informatica e inizialmente volevo diventare programmatrice. Ma quando mi è stata proposta un'opportunità interessante, ho deciso di provare il ruolo di tester. Stranamente, questo si è rivelato essere la mia vocazione. Oggi vedo il mio lavoro esclusivamente in questo settore.

Sono un'appassionata sostenitrice della disciplina Quality Assurance. Mi preoccupo di quali prodotti vengono creati, di come viene considerata la qualità all'interno dell'azienda, nel team e, in generale, nel processo di sviluppo.

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

— Usi le parole Quality Assurance e testing. Nella percezione dell'opinione pubblica, questi due termini si sovrappongono molto spesso. In cosa si differenziano, se approfondiamo?

Anastasia: In realtà, non si distinguono. Il testing è parte della disciplina Quality Assurance, è un'attività diretta — il semplice fatto di testare qualcosa. Ci sono davvero molti tipi di testing, e diverse persone sono responsabili per i vari tipi di test. Tuttavia, in Russia, con l'emergere di una nuova ondata di outsourcing che fornisce tester alle aziende, il testing si è ridotto a un'unica forma.

Nella maggior parte dei casi ci si limita solo al testing funzionale: si verifica se ciò che gli sviluppatori hanno codificato corrisponde alle specifiche e basta.

— Puoi raccontarci, per favore, quali sono le altre discipline dell'assicurazione della qualità? Cosa altro, oltre al testing, è incluso?

Anastasia: Quality Assurance riguarda, innanzitutto, la creazione di un prodotto di qualità. In altre parole, ci poniamo la domanda su quali attributi di qualità dovrebbe avere il nostro prodotto. Pertanto, se comprendiamo questo, possiamo confrontare chi influisce su questi attributi di qualità. Non importa, se è uno sviluppatore, un project manager o un product owner — è la persona che influisce sullo sviluppo del prodotto, sul suo backlog, sulla sua strategia.

Il tester inizia a comprendere meglio il proprio ruolo. Comprende che il suo compito non è solo quello di testare la conformità ai requisiti, ma anche di mettere in discussione le formulazioni provenienti dal product manager, di svelare tutti i requisiti e le aspettative non esplicite del cliente. Quando forniamo una nuova funzionalità al nostro cliente, dobbiamo davvero soddisfare le sue aspettative e risolvere il suo problema. Se consideriamo tutti gli attributi della qualità, il cliente sarà soddisfatto e capirà che l'azienda il cui prodotto utilizza si prende davvero cura dei suoi interessi, e non lavora secondo il principio del "basta rilasciare una funzione".

— Sembra che ciò che hai descritto sia il compito del product manager. In effetti, non riguarda il collaudo e nemmeno la qualità — riguarda totalmente il product management, giusto?

Anastasia: Esatto. La Quality Assurance non è una disciplina di cui è responsabile una sola persona. Ora c'è una direzione popolare nel testing, un approccio che si chiama Agile Testing. Nella sua definizione, si afferma chiaramente che si tratta di un approccio di squadra ai test, che include un certo insieme di pratiche. L'intera squadra è responsabile dell'implementazione di questo approccio, non è necessario che ci sia un tester nel team. L'intera squadra è orientata a fornire valore al cliente e a garantire che questo valore corrisponda alle sue aspettative.

— Quindi, la qualità tocca quasi tutte le discipline circostanti, imponendo limiti a tutto ciò che è intorno?

Anastasia: Esatto. Quando pensiamo a creare un prodotto di qualità, iniziamo a riflettere su diversi attributi della qualità. Ad esempio, come possiamo verificare che abbiamo effettivamente sviluppato una funzionalità che è davvero necessaria per il nostro cliente.

Qui emerge un tipo di test come UAT (user acceptance testing). Purtroppo, in Russia è raro che venga praticato, ma a volte è presente nei team SCRUM, come demo per il cliente finale. Nelle aziende estere, questo è un tipo di testing abbastanza comune. Prima di aprire la funzionalità a tutti i clienti, facciamo prima il UAT, invitando il consumatore finale che esegue il testing e fornisce immediatamente feedback — se il prodotto soddisfa davvero le aspettative e risolve un problema. Solo dopo questo avviene la scalabilità per tutti gli altri clienti.

Vale a dire, ci focalizziamo sul business, sul cliente finale, ma non dimentichiamo la tecnologia. La qualità del prodotto dipende molto anche dalle tecnologie. Se abbiamo una cattiva architettura, non saremo in grado di rilasciare rapidamente le funzionalità e soddisfare le aspettative del cliente. Possono esserci molti bug quando si cerca di scalare, o durante un tentativo di refactoring potremmo rompere qualcosa. Tutto ciò influenzerà la soddisfazione del cliente.

Da questo punto di vista, l'architettura deve essere tale da permetterci di scrivere codice pulito, che consenta di apportare modifiche rapidamente e senza temere che tutto si rompa. Affinché le iterazioni di miglioramento non si allunghino per mesi solo perché abbiamo così tanto legacy e dobbiamo effettuare lunghe fasi di testing.

— Già coinvolti sviluppatori, architetti, product manager e tester. Chi altro è coinvolto nel processo di assicurazione della qualità?

Anastasia: Immaginiamo ora di aver già consegnato una funzionalità al cliente. È ovvio che dobbiamo monitorare la qualità del prodotto anche quando è in produzione. In questa fase possono emergere situazioni con scenari non ovvi, i cosiddetti bug.

La prima domanda è: come gestiamo questi bug dopo aver già rilasciato il prodotto? Ad esempio, come reagiamo ai carichi? Il cliente non sarà molto contento se la pagina impiega più di 30 secondi a caricarsi.

Qui entra in gioco l'operatività o, come viene chiamato ora, DevOps. In sostanza, queste sono persone responsabili dell'operatività del prodotto una volta che è in produzione. Ci sono vari tipi di monitoraggio inclusi. Esiste persino una sottocategoria di test — test in produzione, dove ci permettiamo di non testare qualcosa fino al rollout e testiamo direttamente in produzione. Si tratta di una serie di attività dal punto di vista organizzativo dell'infrastruttura che consentono di rispondere rapidamente a un incidente, influenzarlo e correggerlo.

Anche l'infrastruttura è importante. Ci sono spesso situazioni in cui durante i test non è possibile accertarsi che abbiamo davvero tutto ciò che volevamo offrire al cliente. Lanciamo in produzione — e iniziamo a rilevare situazioni non evidenti. E tutto ciò accade perché l'infrastruttura in test non corrisponde a quella in produzione. Da qui nasce un nuovo tipo di test — test dell'infrastruttura. Queste includono varie configurazioni, impostazioni, migrazione di database, ecc.

Da qui sorge la domanda: forse il team dovrebbe 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. Scrivici se sei pronto a condividere la tua esperienza su 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à viene coinvolta anche l'operatività.

— E per quanto riguarda l'analisi e la documentazione?

Anastasia: Questo è più legato ai sistemi enterprise. Quando parliamo di enterprise, ci vengono in mente persone come analisti e analisti di sistema. A volte vengono chiamati anche 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 scrittura di tale documentazione porta a iterazioni di sviluppo molto lunghe e a iterazioni di rifinitura prolungate, poiché durante il processo di test emergono bug e iniziano i resi. Di conseguenza, si creano moltissimi cicli che aumentano il costo dello sviluppo. Inoltre, questo può introdurre vulnerabilità. Sembrava che avessimo scritto codice standard, ma poi abbiamo fatto cambiamenti che rompono un'architettura perfettamente elaborata.

Il risultato finale è un prodotto di qualità non del tutto soddisfacente, poiché nell'architettura sono già emerse patch, il codice in alcune aree non è sufficientemente coperto dai test, a causa di scadenze ravvicinate, bisogna chiudere rapidamente tutti i bug. E tutto ciò accade perché nella specifica iniziale non erano stati considerati tutti gli aspetti da implementare.

Gli sviluppatori non sono dannosi e non scrivono intenzionalmente codice con errori.

Se avessimo originariamente pianificato una specifica che includesse tutti gli aspetti necessari, tutto sarebbe stato implementato esattamente come richiesto. Ma questa è un'utopia.

Probabilmente scrivere una specifica perfetta di 100 pagine è impossibile. Quindi è necessario riflettere su metodi alternativi per redigere la documentazione, specificazione, assegnazione di compiti che ci avvicinano a far sì che il developer faccia esattamente ciò che serve.

Qui vengono in mente approcci da Agile — storie utente con criteri di accettazione. Questo è più applicabile per i team che crescono con piccole iterazioni.

— Cosa ne pensi dei test di usabilità, della facilità d'uso del prodotto, del design?

Anastasia: Questo è un aspetto molto importante, perché nel team ci sono designer. Spesso i designer vengono utilizzati come servizio — o un dipartimento di designer, o un designer esternalizzato. Si presentano frequentemente situazioni in cui sembrerebbe che il designer abbia ascoltato il product manager e abbia fatto ciò che ha capito. Ma quando passiamo all'iterazione, si scopre che in realtà non è stato fatto ciò che ci si aspettava: il designer ha dimenticato qualcosa, non ha pensato completamente al comportamento, perché non è nel team e non è nel contesto, o lo sviluppatore front-end non ha capito completamente il suo layout. Potrebbero essere necessarie diverse iterazioni solo a causa del malinteso del design da parte dello sviluppatore front-end.

Inoltre, c'è un altro problema. Le design system stanno diventando sempre più popolari. Sono di tendenza, ma i vantaggi non sono del tutto evidenti.

Mi capita di sentire l'opinione che le design system, da un lato, semplifichino lo sviluppo, ma dall'altro lato impongano molte limitazioni all'interfaccia.

In definitiva, non stiamo implementando una funzionalità che il cliente desidera, ma piuttosto una che è comoda per noi, perché abbiamo già a disposizione determinati componenti dai quali possiamo realizzarla.

Mi sembra che valga la pena prestare attenzione a questo argomento e riflettere se, nel tentativo di semplificare il lavoro sul design, stiamo davvero affrontando il dolore del cliente.

— Ne conseguono molte tematiche legate al Quality Assurance. In Russia c'è una conferenza dove si possono discutere tutti questi argomenti?

Anastasia: C'è la conferenza più antica sul testing, che quest'anno si svolgerà per la 25ª volta e si chiama SQA Days. Durante questo evento si discutono principalmente strumenti e approcci specifici al testing per i tester funzionali. Di solito, le presentazioni di SQA Days approfondiscono aree specifiche nelle responsabilità dei tester, piuttosto che eventi complessi.

Questo aiuta molto a capire i vari strumenti e approcci per testare database, API, ecc. Tuttavia, da un lato non motiva a coinvolgere nel creare un prodotto più qualitativo, non solo il testing. Dall'altro, i tester non diventano più coinvolti nel processo per riflettere sull'obiettivo globale del prodotto e sulla sua componente commerciale.

Dirigo un grande reparto, conduco molti colloqui che realmente permettono di comprendere lo stato dell'industria in generale. Di solito, i nostri ragazzi lavorano in ambito enterprise e hanno una chiara area di responsabilità. I colleghi impegnati in progetti internazionali usano diversi tipi di testing: possono effettuare test di carico, test delle prestazioni e, talvolta, anche test di sicurezza, perché realmente aiutano il team a garantire la qualità del prodotto.

Mi piacerebbe che anche in Russia i ragazzi iniziassero a riflettere sul fatto che il testing funzionale non rappresenta tutta l'industria.

— Per questo stiamo organizzando una nuova conferenza QualityConf, dedicata alla qualità come disciplina globale. Racconta 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 relazioni e uscire dalla conferenza con una comprensione concreta di cosa devono cambiare per migliorare la qualità.

Spesso sento parlare di richieste da parte delle aziende di consulenza riguardo a cosa fare quando ci sono problemi con i test e la qualità. Quando inizi a dialogare con i team, noti che il problema non risiede nei tester stessi, ma nel modo in cui è strutturato il processo. Ad esempio, quando gli sviluppatori credono di essere responsabili solo per la scrittura del codice, la loro responsabilità termina esattamente nel momento in cui trasferiscono il compito ai test.

Non tutti considerano che un codice scadente e mal strutturato può comportare grandi problemi per il progetto. Non riflettono sul costo degli errori, sul fatto che i bug, se arrivano in produzione, possono comportare costi elevati per l'azienda e il team. Non c'è cultura a riguardo. Vorrei che durante la conferenza iniziasse a diffondersi.

Capisco che non si tratta di un'innovazione. Edward Deming, autore dei 14 postulati della qualità, parlava del costo dell'errore già nel secolo scorso. Questo libro è alla base del Quality Assurance come disciplina, ma, sfortunatamente, la moderna sviluppo tende a dimenticarlo.

— Prevedete di trattare anche argomenti direttamente legati ai test e agli strumenti?

Anastasia: Considero che ci saranno presentazioni sugli strumenti. Ci sono strumenti abbastanza universali che le aziende e i team possono utilizzare per influire sul prodotto.

Tutte le presentazioni saranno unite da una missione comune: comunicare al pubblico che grazie a questo approccio, strumento, metodo, processo o tipo di test, abbiamo influenzato la qualità del prodotto e migliorato la vita del cliente.

Non avremo certamente presentazioni sugli strumenti per il solo piacere di farlo. Tutte le presentazioni che faranno parte del programma saranno unite da un obiettivo comune.

— A chi interessa ciò di cui parli, chi vedi come ospiti della conferenza?

Anastasia: Avremo presentazioni per sviluppatori che si prendono a cuore il destino del loro progetto, prodotto o sistema. Sarà interessante anche per i tester e, come mi sembra, soprattutto per i manager. Per manager intendo persone che prendono decisioni e possono influenzare il destino e lo sviluppo del prodotto, del sistema e del team.

Queste sono persone che si pongono la domanda su come migliorare la qualità del prodotto e del sistema. Alla nostra conferenza, scopriranno diversi complessi di attività e potranno capire cosa non va attualmente e cosa deve essere cambiato.

Penso che il criterio principale sia riconoscere che c'è qualcosa che non va con la qualità e voler avere un impatto su di essa. Probabilmente, non riusciremo a far breccia nelle persone che pensano che vada bene così al primo tentativo.

— Cosa ne pensi, l'industria è matura per parlare non solo di testing, ma di cultura della qualità?

Anastasia: Credo di sì. Attualmente, molte aziende si stanno allontanando dall'approccio tradizionale Waterfall a favore dell'Agile. C'è un orientamento verso il cliente, e le persone nei team stanno veramente iniziando a riflettere su come creare prodotti di qualità. Anche nelle aziende enterprise si sta verificando un riposizionamento verso l'aumento della qualità.

A giudicare dal numero di richieste che emergono nella comunità, penso che sia giunto il momento. Non sono sicura che si tratti di una rivoluzione su larga scala, ma mi piacerebbe che questo cambiamento di mentalità avvenisse.

— D'accordo! Promuoveremo la cultura e cambieremo la mentalità.

Conferenza sulla qualità nello sviluppo di prodotti IT QualityConf si terrà a Mosca il 7 giugno. Sapete quali fasi compongono un prodotto di qualità, abbiamo casi di successo nella lotta contro i bug in produzione e abbiamo testato pratiche popolari nella nostra esperienza — ci serve la vostra esperienza. Inviateci le vostre candidature entro il 1 maggio, e il Comitato Programmatico vi aiuterà a focalizzare il tema per una maggiore coesione della conferenza.

Collegati al chat, dove discutiamo le questioni di qualità e la conferenza, iscriviti al canale Telegram, per rimanere aggiornato sulle novità del programma.

Fonte: habr.com