Test del Prodotto (con Erin Hess di Crema)

Michael Luchen

Si parla tanto di come costruire un prodotto, ma che dire del testare un prodotto? Quali sono gli approcci, le posture e le discipline che garantiscono che un prodotto sia sottoposto a test approfonditi così da supportare realmente gli utenti per cui è stato creato? Oggi, insieme a noi, c’è un’esperta di test engineering, per approfondire che cosa definisce questo ruolo fondamentale all’interno di un team di prodotto, come collabora con i product manager e perché probabilmente può essere una delle figure chiave per l’empatia nel team di prodotto. Restate con noi.

Questo è il podcast The CPO Club — le voci della comunità che sta scrivendo le regole della gestione prodotto, dello sviluppo e della strategia. Siamo sponsorizzati da Crema, un’agenzia di prodotti digitali che aiuta persone e aziende a prosperare grazie a creatività, tecnologia e cultura. Per saperne di più visita crema.us. Continua ad ascoltare per consigli pratici e autentici che ti aiutino ad avere successo nel mondo del product management.

Ciao a tutti. Sono davvero felice oggi di dare il benvenuto a Erin Hess. Ho il piacere personale di conoscere Erin, che ha portato il suo talento nel nostro team a Crema come Senior Test Engineer. Erin possiede un insieme unico di competenze creative e tecniche maturate in 12 anni di esperienza attraverso diversi ruoli nello sviluppo e nell’ingegneria del software.

Ha iniziato la sua carriera come rappresentante del supporto clienti, diventando poi sviluppatrice autodidatta e appassionandosi al testing del software. Da sempre dalla parte dell’utente, tra i punti di forza di Erin ci sono empatia, visualizzazione e la capacità di anticipare i comportamenti e la comunicazione. Erin ama creare mappe di processi e immaginare potenziali punti critici. Camminando nelle scarpe degli altri, guardando i problemi da più prospettive e immaginando le conseguenze a lungo termine delle azioni di oggi, Erin è riuscita a migliorare ogni team e prodotto cui ha partecipato.

Erin aiuta anche le organizzazioni ad adottare pratiche di design inclusivo, sensibilizzando sulle barriere universali di usabilità. È una promotrice dell’accessibilità e contribuisce costantemente con materiali e risorse alle community online dedicate al testing.

Ciao Erin, benvenuta nel nostro show.

Erin Hess

Grazie mille per questa bellissima introduzione, Michael. Sono felice di essere qui.

Michael Luchen

Fantastico. Devo dire che sono davvero emozionato per questa discussione. Una delle particolarità del rapporto tra test engineer e product manager è che può portare risultati straordinari, anche se spesso se ne parla troppo poco.

Sei pronta per iniziare?

Erin Hess

Oh, assolutamente.

Michael Luchen

Bene. Vorrei partire da una panoramica generale, magari per chi ci ascolta e non ha mai avuto un test engineer in squadra e vuole davvero capire il ruolo. Ci puoi dire quali sono le tue attività preferite come test engineer?

Erin Hess

Oh, certo. Ci sono tantissime cose di cui potrei parlare all’infinito. Sono molte le attività che puoi svolgere come tester. Una delle mie attività preferite in assoluto è costruire relazioni e conoscere i team con cui lavoro: sviluppatori, designer, product manager, altri ingegneri, supporto clienti, a volte perfino marketing.

E, su progetti particolari, lavorando in progetti di collaborazione, conoscendo anche le risorse lato cliente. Ho trovato la mia nicchia nella redazione di documentazione tecnica. Apprezzo davvero avere tempo e spazio per fornire la giusta quantità di dettagli e spiegazioni, con utili supporti visivi.

Se posso essere creativa e aggiungere una foto di un gatto davanti al computer, lo faccio volentieri! Amo imparare nuovi strumenti e lavorare insieme agli altri ingegneri. È una delle cose che mi entusiasma di più.

Michael Luchen

Fantastico. Come approcci la costruzione di relazioni con i team, specialmente partendo dalla prospettiva unica di un test engineer?

Erin Hess

Sono molto aperta e so che ogni persona è diversa; non avrò la stessa conversazione con un designer rispetto a uno sviluppatore o a un product owner. Cerco sempre di mantenere una mentalità aperta e lasciare ampio spazio ed empatia per il team.

Michael Luchen

Come trovi l’equilibrio tra creare questo spazio di empatia, considerando che ognuno ha diverse competenze e discipline da portare al team di prodotto?

Erin Hess

Per me la disciplina si traduce in pazienza e pratica: imparare, concedere a me stessa e al mio team dei momenti di retrospettiva su come ci siamo presi cura l’uno dell’altro durante lo sprint, cosa è stato difficile, non solo sotto l’aspetto lavorativo ma anche umano, dando spazio ai colleghi di aprirsi con me e affrontare queste conversazioni.

Michael Luchen

Fantastico. Torniamo un attimo a una visione un po' più ampia.

Quali sono le attività tipiche di un test engineer in un team di prodotto? Sicuramente non è solo — e lo dico scherzando — dare il via libera alla release, giusto?

Erin Hess

Oh, no! Non sono qui solo con un timbro con scritto "passato" o "fallito". C'è molta complessità, molte più relazioni di quanto pensi anche se è un ruolo tecnico. Lavorare e collaborare con le varie parti del team significa per esempio affiancarsi agli sviluppatori per migliorare nelle pull request, collaborare con il product manager per chiarire e definire i criteri di accettazione, impostare lo standard e le aspettative.

Tutte le user story e le funzionalità vanno valutate non solo dai designer e dagli sviluppatori ma anche dagli stakeholder; il test engineer fa parte di tutto ciò. Devi comunicare con tutti, altrimenti rischi di perdere informazioni e aumentare i rischi che il prodotto non risponda ai requisiti.

Michael Luchen

Interessante. Credo che questo si colleghi a quanto dicevi sulla documentazione tecnica: ti aiuta a raccogliere tutto il contesto, giusto?

Erin Hess

La uso anche come la mia seconda memoria. Non posso ricordare tutto, ma so che la mia documentazione è eccellente e posso consultarla quando serve, anche per gli altri.

Michael Luchen

In riferimento a questa "seconda memoria", posso dire di aver visto che tieni tutta la documentazione accessibile a tutto il team di prodotto, giusto?

Erin Hess

Sì.

Michael Luchen

Ecco, scusa, vai pure avanti.

Erin Hess

È tutto lì, non è nascosto o bloccato dietro un paywall o altro. È a disposizione del team. E ogni volta che creo qualcosa, lo condivido subito.

Michael Luchen

Ottimo. La documentazione trasparente è fondamentale nei team di prodotto, non solo per il test engineering ma per tutte le discipline, perché porta contesto, e il contesto aiuta il tuo ruolo a prosperare.

Per chi ascolta e magari è nuovo al ruolo di test engineer, qual è il momento migliore per cominciare la collaborazione con il team di prodotto? Dopo l’avvio? Verso la fine? Altro?

Erin Hess

Ho imparato che prima si coinvolge il test engineer, meglio è. In alcune aziende si pensa che sia solo qualcuno da inserire in corsa per fare i test, ma chi vuole davvero un buon test engineer, portatore di valore aggiunto, deve coinvolgerlo già prima della partenza del progetto, nella settimana di contesto, per fargli vedere tutto ciò che lo aspetta e permettergli di immaginare e contribuire già da subito a progettazione per testabilità, sviluppo, accessibilità, non relegando quest’ultima a un pensiero finale.

Michael Luchen

Concordo pienamente. Se vedo un team partire senza un test engineer già dall’inizio, per me è un grosso rischio, perché il contesto che si raccoglie da subito è fondamentale.

All’interno di uno sprint, quali sono secondo te le cose da tenere a mente come test engineer?

Erin Hess

Buona domanda. Ho diversi punti: Primo, non sai quello che non sai, quindi non aver paura di chiedere aiuto o chiarimenti alla squadra, anche se il dubbio ti sembra piccolo. Spesso le piccole preoccupazioni portano a miglioramenti significativi. Inoltre, parlare subito può ridurre tempi e costi di sistemazione di un problema che altrimenti arriverebbe in produzione.

E poi ricordati che nello sviluppo prodotto non c’è un “io”, proprio come nel team: non sei solo, fai parte di una squadra. Quindi, il peggio che puoi fare è aspettare la fine dello sprint per dire che qualcosa non va. Parla subito.

Michael Luchen

Esattamente, soprattutto dal lato product management, questo aiuta a individuare rischi nello sprint. All’inizio stimiamo i rischi, ma da test engineer potresti evidenziare qualcosa che cambia tutta la dinamica dello sprint in positivo.

Erin Hess

Esatto.

Michael Luchen

Passiamo ora a qualche consiglio su come impostare una collaborazione efficace tra test engineer, designer e sviluppatori. Quali sono le pratiche migliori?

Erin Hess

È utilissimo che designer e devs lavorino insieme ai test engineer già nella fase di progettazione e sviluppo delle user story, ogni volta che è possibile.

Dall’esperienza, ci sono opportunità di collaborare con design e sviluppo già dall’inizio dei progetti: così ottengo informazioni per preparare scenari di test, casi di test, scrivere script di automazione. Ora sto migliorando i criteri di accettazione inserendo Gherkin, così quando parte l’automazione, gran parte del lavoro è già fatto.

Michael Luchen

Hai citato vari concetti come scenari di test. Cosa sono? Sono legati ai criteri di accettazione del PM o sono più dettagliati?

Erin Hess

È entrambe le cose. Si parte dai criteri di accettazione definiti con il team e il PM, poi con gli scenari di test si simulano utenti con diversi device, azioni fatte, aspettative, rischi e possibili usi impropri. Si creano flussi end-to-end di tutto ciò che l’utente può fare durante il test.

Michael Luchen

Quando un prodotto viene rilasciato, ci sono tanti contesti di utilizzo: browser, risoluzioni, device e altro. Attraverso gli scenari di test vuoi proprio metterlo alla prova, giusto? Come scegli dove concentrarti tra tutte le possibilità?

Erin Hess

Ho imparato che si può eccedere con i test. Si può strafare con i test di accessibilità su pagine che magari non ne hanno bisogno. Serve esperienza, riflessione e selezione: si valuta il tipo di progetto, se è una web app, nativa, solo iPhone, ecc. Così si eliminano i test inutili e si costruiscono le matrici di test necessarie per device, browser e tipologia utente.

Michael Luchen

Quando scegli su cosa focalizzare gli scenari di test, guardi regolarmente le statistiche sull’uso dei browser o dei dispositivi? Adatti il testing a cosa è più rilevante per il progetto?

Erin Hess

Noi test engineer abbiamo tantissime risorse che ci aiutano a scegliere su cosa concentrare i test: statistiche di utilizzo di browser e device, informazioni su quante persone veramente usano certi strumenti. Così definiamo le priorità: sicuramente testare Safari e Chrome, iOS e Android, e magari a tempo perso testare browser meno importanti come Edge o Netscape, solo per curiosità.

Michael Luchen

Molto interessante. Usi anche test con utenti o sondaggi per informare le tue scelte?

Erin Hess

Non ho lavorato molto con i sondaggi, però mi piace rispondere quando capita. Sarebbe interessante ricevere feedback dagli utenti reali. Intanto considero sempre qual è l’esperienza media attesa e parto da lì.

Michael Luchen

Prima di andare avanti, vorrei chiederti della scrittura di script di automazione. Qual è il valore dell’automazione e quando va introdotta?

Erin Hess

Ottima domanda. Dipende! Se il progetto è a lungo termine, con un team stabile e senza una fine prossima, vale la pena investire nell'automazione: si parte dai test manuali, si classifica per rischio e funzionalità, poi si valuta quale framework usare — anche soluzioni low code esistono. Si pensa cosa abbia senso automatizzare prima, specie se il progetto parte da zero. Già in fase di progettazione e sviluppo si può scrivere codice o script di automazione, per esempio, per i tag di accessibilità dei componenti, così si risparmia tempo dopo e si pianifica meglio. L’automazione aggiunge un ulteriore livello di complessità ma permette di accelerare e rendere più stabile il testing. Prima si inizia, meglio è, ma va fatta al bisogno, anche per velocizzare e stabilizzare i processi di test.

Michael Luchen

Molto interessante. Cambiando prospettiva: come gestisci la collaborazione con i product manager?

Erin Hess

Mi piace molto! Come dicevo, punto sulle relazioni, non sulla gerarchia: mi interessa che tutto il team collabori davvero. Lavoro con i PM quanto con sviluppatori e designer. Collaboriamo su criteri di accettazione, ricerche, raccolta informazioni, valutiamo insieme i diversi approcci ai test. Se posso aiutare il PM con qualcosa, lo faccio volentieri.

Michael Luchen

Da PM lo confermo: il rapporto tra PM e test engineer ha un enorme impatto, specialmente nella definizione dei criteri di accettazione e nella validazione prima della release. Collaborare fin da subito permette di definire meglio i risultati attesi per l’utente e coprire ogni dettaglio, lasciando spazio alla creatività del team e garantendo qualità. Concordi?

Erin Hess

Sono pienamente d’accordo. Ho lavorato su progetti in cui il test engineer viene coinvolto tardi e ora apprezzo davvero essere coinvolta fin dall’inizio.

Michael Luchen

Sì, cambia tutto quando manca il test engineer: la differenza è netta!

Una cosa di cui hai già parlato è il tuo essere un’accanita sostenitrice dell’accessibilità. Ci puoi spiegare cosa significa?

Erin Hess

Certo. Ora va molto di moda, la si chiama anche "A11Y" (cioè 11 lettere tra A e Y in accessibility). Essere advocate significa fare da voce per tutti gli utenti finali, promuovere funzionalità e sviluppo di prodotti accessibili a tutti. Vuol dire inclusione, dialogo e capire dove posso far sentire la mia voce per aiutare qualcun altro.

Michael Luchen

A volte, però, conosco stakeholder che non danno priorità all’accessibilità. Come rispondi?

Erin Hess

Ho usato diversi approcci, ma quello che funziona di più è mostrare i numeri sul rischio economico per l’azienda di non essere compliant (rischio di cause legali, danni d’immagine, clienti persi). Spesso non si tratta di non curarsi degli utenti, ma questa sarà la percezione.

Michael Luchen

Puoi parlare di più dell’empatia come fondamento del testing?

Erin Hess

Certo. Avete presente il detto “mettersi nei panni degli altri”? È empatia: la capacità di comprendere o sentire cosa prova qualcun altro dal suo punto di vista. Ho anche fatto una presentazione su questo tema (alla conferenza TestBash di Ministry of Testing) con la mia amica Jenny Bramble. Abbiamo parlato di come empatia e testing siano spesso intrecciati: non puoi conoscere le aspettative degli altri se non conosci la loro esperienza. Testare significa mettersi nei panni degli utenti, pensare a temi come high contrast, font specifici, e tutto ciò che riguarda l'accessibilità.

Michael Luchen

Molto interessante! Da questa chiacchierata emergono alcuni temi: advocacy per l’accessibilità, empatia in tutto il lavoro del test engineer e, ovviamente, l’importanza della collaborazione col team di prodotto.

Prima di chiudere, ti farei qualche domanda personale a raffica. Pronta?

Erin Hess

Vai pure!

Michael Luchen

Quale tua abitudine personale ha contribuito di più al tuo successo?

Erin Hess

Direi sicuramente la mia capacità di strutturare e organizzare grandi quantità di informazioni, sviluppata nel tempo. È una delle mie "superpoteri", nata dalla passione per l’organizzazione e per la scrittura di documentazione utile e dettagliata.

Michael Luchen

Strumento preferito che usi regolarmente?

Erin Hess

Assolutamente Chrome DevTools, soprattutto la funzione Device Mode per simulare dispositivi mobili, testare la responsività e varie viste. Uso molto il pannello Network per analizzare difetti, e Lighthouse e Axe per i test di accessibilità.

Michael Luchen

Infine, che consiglio daresti a chi è all’inizio del suo percorso nel mondo prodotto?

Erin Hess

Siate aperti a imparare da chiunque, che sia uno sviluppatore, un designer o un product manager: ogni occasione è una possibilità di apprendimento!

Michael Luchen

Davvero ben detto. Ho imparato molto oggi. Grazie mille Erin per essere stata con noi.

Erin Hess

Grazie a voi. Mi ha fatto davvero piacere e spero di parlare ancora di accessibility testing e test engineering.

Michael Luchen

Non vedo l’ora! Per chi vuole conoscere meglio Erin, trovate il suo lavoro su crema.us o su LinkedIn e Twitter (@QueenTester).

Se vi è piaciuto questo episodio, scoprite anche la nostra pubblicazione "the QA lead", dove esploriamo tutte le novità su automazione e test: theqalead.com.

Ancora grazie, Erin. È stato un episodio fantastico. Grazie a tutti per averci ascoltato. Lasciate una recensione e unitevi alla nostra community su theproductmanager.com. Grazie.