Comunicazione Tester-Sviluppatore

Il modo più semplice per migliorare la comunicazione è lavorare insieme con i tuoi sviluppatori (e designer e architetti ecc.) e abbattere lentamente quei ruoli sciocchi e alla fine renderci conto che tutti sono tester, tranne che alcuni di noi hanno più esperienza di altri.

Per essere agili, fallo "dal libro". I tester fanno parte del team e non solo di un'entità esterna a cui consegnare le informazioni quando è terminata. La tua preziosa esperienza viene utilizzata durante lo sviluppo intero . Innanzitutto, quando crei le storie degli utenti, contribuisci a generare test di accettazione e a renderli automatizzati. Questi test vengono quindi utilizzati dagli sviluppatori nel loro lavoro. Inoltre, trascorri del tempo ogni giorno con i test esplorativi del lavoro parziale e completato e parla con l'OP per chiarire e migliorare continuamente i tuoi test.

Questo è ciò che intendo quando parlo di "lavorare insieme". Sono completamente sicuro che questo è il modo in cui la comunicazione in una squadra dovrebbe funzionare. Questo articolo lo spiega molto bene tra l'altro.

Di fronte a questo, molte organizzazioni amano gestire lo sviluppo mettendo tutti i tester (e DBA, progettisti e programmatori) in reparti separati. Questo funziona contro la comunicazione e serve solo a cementare l'idea dello sviluppo graduale. Cercare di migliorare la comunicazione in una situazione del genere è possibile, ma i piccoli miglioramenti che puoi aspettarti non valgono lo sforzo. Almeno non paragonato a mettere effettivamente le persone nella stessa stanza e creare team interfunzionali.

Credo fermamente in QUALSIASI tipo di comunicazione tra dev e test.

Troppe volte ho visto scontri tra una squadra e l'altra, piccoli avanti e indietro ("chiuso dal progetto", seguito da "riaperto" ecc.)

Dico sempre ai tester con cui lavoro di venire a parlare con me se hanno qualche dubbio.

Una cosa che odio veramente, sono gli sviluppatori che ottengono tutto l'arrogante test e parlano di questo, quindi tutto ciò che posso fare per promuovere buoni rapporti con i team di test, cerco di fare.

Un tester dovrebbe essere molto chiaro e preciso con gli sviluppatori quando comunica sugli errori e sui test. Un elenco dettagliato di passaggi per riprodurre l'errore, schermate se necessario ... Le descrizioni vaghe di errori che non possono essere riprodotti o che hanno passaggi poco chiari da riprodurre possono inasprire rapidamente la relazione tra sviluppatori e tester.

Non ho mai creduto che ci sia sempre un livello di disaccordo tra sviluppatore e tester, ma ho dovuto affrontare questa situazione quando uno dei miei migliori amici ha ottenuto il ruolo di tester nella società che stavo lavorando e con mia sorpresa gli è stato assegnato lo stesso modulo per testare che stavo sviluppando e quindi era vero FUN lavorare con lui e devo dire che è molto importante capire l'opinione di altre persone in tale situazione e avere il controllo sul proprio ego, questo mi ha aiutato molto e noi i ragazzi si adattano bene ai nostri impegni professionali e al livello di amicizia personale.

Dato che hai dichiarato di essere un tester unico in un ambiente Agile (assumendo Scrum), forse è utile sfruttare la riunione retrospettiva come un forum aperto per definire il processo di comunicazione.

Come sapete, la riunione restrospettiva deve affrontare le rughe all'interno del processo Scrum. Questi potrebbero essere elementi come consentire agli sviluppatori di X-Y ore ininterrotte, comunicazioni e-mail solo il lunedì e verbali per il resto della settimana, qualunque sia il team TUO ; poiché la comunicazione non è mai un approccio adatto a tutti.

Come sviluppatore apprezzo un tester che mostra l'iniziativa. Non disegnano linee ... vogliono che il difetto sia risolto; indipendentemente dalla causa principale. Gli sviluppatori e i tester devono separare i sentimenti dagli affari. I difetti fanno parte del business dal momento che gli esseri umani sono coinvolti. L'approccio migliore alla risoluzione dei difetti è una squadra allineata per risolvere i difetti in modo olistico. Quando le linee iniziano a emergere e i bordi sono disposti; la comunicazione si interromperà.

Approfitta delle tue riunioni quotidiane di stand-up. Essere coinvolti il più possibile; non solo con i test ma con il prodotto nella sua interezza. Alla fine della giornata uno sviluppatore e un tester stanno lavorando su un obiettivo e dovrebbero sempre tenerlo a fuoco.

Preferisco vedere i tester come parte della stessa squadra. A tale riguardo non vi è alcun problema di comunicazione.

Ogni volta che un tester deve parlare con uno sviluppatore o viceversa, vieni e facciamo una chiacchierata. Solo una routine di tutti i giorni.

Tuttavia, entrambe le parti devono rispettarsi a vicenda e svolgere il proprio lavoro correttamente.

I tester devono fornire dettagli approfonditi sulle condizioni del bug e non riportare qualcosa come un bug mentre è di progettazione. Soprattutto quando serve solo per chiedere al ragazzo laggiù qualcosa che sembra sospetto di una caratteristica.

Gli sviluppatori devono prendere sul serio una segnalazione di bug e investigare approfonditamente non solo chiudere il problema se non si riproduce il bug in cinque clic.

L'attitudine professionale è sufficiente.

Lo strumento numero 1 che ho trovato che io, come tester (SDET), posso sfruttare per migliorare i rapporti dev-test è l'adulazione onesta, specialmente nella forma di ricerca di mentori da parte degli sviluppatori.

Spero che gli sviluppatori con cui lavoro siano gli sviluppatori migliori di me. Non sono perfetti, o non avrei un lavoro, ma ci sono molte cose che sanno meglio di me. Sono stati di puro sviluppo, mentre la mia attenzione è parzialmente concentrata sui test. Prendo atto di quelle cose che fanno meglio, e le menziono spesso. Quando leggo il loro codice, noto dettagli eleganti o usi accurati dei modelli di progettazione e li porto in conversazione. Imitiamo gli sviluppatori, usando convenzioni di codifica simili quando possibile, e integrando i componenti dalla produzione nei miei strumenti di test quando appropriato (ad esempio, la registrazione). Riconosco la loro esperienza e, di conseguenza, sono felice di riconoscere il mio. Intendiamoci, se penso che ci sia un modo migliore di fare le cose, ne parlo in assoluto, ma mirano a dare più feedback positivi che negativi, in generale. In generale, cerco di esprimere feedback negativi più formali e impersonali (ad es. Segnalazioni di bug) e feedback positivi meno formali e più personali (ad es. Conversazioni di persona).

Fornire feedback positivi sulla qualità e feedback negativi e chiedere consigli cambia il rapporto dall'essere contenti all'essere sul lavoro di squadra e sull'apprendimento reciproco e ridurre la difensività. Gli sviluppatori sanno che possono fidarsi di me per dire sempre più cose positive che negative, quindi si sentono a loro agio ascoltandomi. Inoltre, fare domande approfondite sullo sviluppo fa sorgere la loro opinione su di me e rompe lo stereotipo "SDETs failed fails" (dove ancora esiste).

Sono fermamente convinto che una buona comunicazione tra sviluppatori e tester sia fondamentale. Per quanto riguarda il modo migliore di fare sono sicuro che ci sono molti approcci buoni ma qui è quello che ha funzionato meglio per me.

Comunicazione diretta / personale! Ho trovato che la comunicazione personale, non e-mail, funziona sempre meglio. Permette allo sviluppatore e al tester di formare una relazione personale. Una volta che hai le cose sembrano funzionare meglio e tendono a fluire. Non hanno mai problemi a eseguire un test speciale o fare il miglio supplementare per te. Lo stesso vale per lo sviluppatore e mi prendo sempre il tempo in più per esaminare le cose su cui hanno bisogno di aiuto o che hanno un problema. Secondo la mia esperienza, i problemi di risoluzione sono più rapidi, c'è meno tempo perso.