Comunicazione tester-sviluppatore

Mentre molto è scritto su comunicazioni sviluppatore-sviluppatore, sviluppatore-cliente, responsabile del team di sviluppo, non sono riuscito a trovare alcun testo che fornisca linee guida sulla comunicazione e la relazione tester-sviluppatore.

Che tester e sviluppatori siano team separati o nello stesso gruppo (nel mio caso, sono un tester solitario in un progetto di sviluppo agile), ho la convinzione che il modo in cui i tester sono percepiti è estremamente importante affinché i test siano ben accettati e per raggiungere il suo obiettivo nel migliorare la qualità del progetto (ad esempio, non dovrebbero essere visti come una forza di polizia).

Qualche consiglio o studio su come un tester dovrebbe comunicare con gli sviluppatori?

Aggiornamento : grazie a tutti per le risposte. Tutti hanno confermato ciò che avevo in mente. Per ora, il mio team è stato molto ricettivo nei miei confronti e alla fine abbiamo fatto progressi reali. Avrei potuto scegliere più di uno come risposta, ma ho dovuto prendere la mia decisione.

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

Per agile, basta farlo "dal libro". I tester fanno parte del team e non solo qualche entità esterna alla quale consegnate roba quando è finita. Le tue preziose competenze vengono messe a frutto durante l' intero sviluppo. Innanzitutto, quando crei le storie degli utenti, aiuti a ricavare i test di accettazione e a renderli automatici. Questi test vengono quindi utilizzati dagli sviluppatori nel loro lavoro. Passi anche del tempo quotidianamente con i test esplorativi di lavoro parziale e completato e parli con l'OP per chiarire e migliorare continuamente i tuoi test.

Questo è ciò che intendo quando parlo di "lavorare insieme". Sono completamente sicuro che dovrebbe funzionare la comunicazione in un team. Questo articolo lo spiega molto bene a proposito.

Di fronte a questo, molte organizzazioni amano gestire lo sviluppo mettendo tutti i tester (e DBA, designer e programmatori) in reparti separati. Questo funziona contro la comunicazione e serve solo a cementare l'idea di uno sviluppo graduale. Cercare di migliorare la comunicazione in una situazione del genere è possibile, ma i miglioramenti minori che ci si può aspettare non valgono lo sforzo. Almeno non rispetto al mettere effettivamente le persone nella stessa stanza e creare team interfunzionali.

Sono fermamente convinto di QUALSIASI tipo di comunicazione tra dev e test.

Troppe volte ho visto lotte tra panini tra ogni squadra, meschino avanti e indietro ("chiuso secondo il disegno", seguito da "riaperto" ecc.).

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

Una cosa che odio veramente, sono gli sviluppatori che diventano arroganti per i test e ne parlano, quindi tutto ciò che posso fare per favorire buoni rapporti con i team di test, provo a fare.

Un tester dovrebbe essere molto chiaro e preciso con gli sviluppatori quando comunicano errori e test. Un elenco dettagliato di passaggi per riprodurre l'errore, schermate se necessario ... Vaghe descrizioni di errori che non possono essere riprodotti o che presentano passaggi poco chiari per la riproduzione peggioreranno molto rapidamente la relazione sviluppatore-tester.

Non ho mai creduto che ci fosse 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 nell'azienda in cui lavoravo e con mia sorpresa gli è stato assegnato lo stesso modulo per testare che stavo sviluppando e quindi è stato davvero FUNlavorare 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 ragazzi geliamo bene sul nostro professionista impegni e livello di amicizia personale.

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

Come sapete, l'incontro restrittivo è quello di affrontare le rughe all'interno del processo Scrum. Questi potrebbero essere elementi come consentire agli sviluppatori ore XY di tempo ininterrotto, comunicazioni via e-mail solo il lunedì e verbale per il resto della settimana, qualunque cosa si adatti al VOSTRO team; poiché la comunicazione non è mai uguale per tutti gli approcci.

Come sviluppatore apprezzo un tester che mostra iniziativa. Non tracciano linee ... vogliono che il difetto sia risolto; indipendentemente dalla causa principale. Sviluppatori e tester devono separare i sentimenti dalle imprese. I difetti fanno parte del business poiché sono coinvolti gli umani. L'approccio migliore alla risoluzione dei difetti è un team allineato impostato 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 in piedi. Partecipa 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 tal proposito, 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 correttamente il proprio lavoro.

I tester devono fornire dettagli dettagliati sulle condizioni dei bug e non segnalare qualcosa come bug durante la progettazione. Soprattutto quando basta chiedere al ragazzo laggiù qualcosa che sembra sospettosamente una caratteristica.

Gli sviluppatori devono prendere sul serio una segnalazione di bug e indagare a fondo non solo per chiudere il problema se non si riproduce il bug in cinque clic.

L'atteggiamento professionale è tutto ciò che serve.

Lo strumento numero 1 che ho scoperto che io, come tester (SDET), posso sfruttare per migliorare le relazioni dev-test è un'onesta adulazione, soprattutto sotto forma di ricerca di tutor da parte degli sviluppatori.

Spero che gli sviluppatori con cui lavoro siano sviluppatori migliori di me. Non sono perfetti, o non avrei un lavoro, ma ci sono molte cose che sanno meglio di me. Sono stati un puro sviluppo, mentre la mia attenzione è parzialmente focalizzata 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 motivi di design e li porto in conversazione. Imito gli sviluppatori, usando convenzioni di codifica simili quando possibile e integrando i componenti della produzione nei miei strumenti di test quando appropriato (ad esempio, la registrazione). Riconosco la loro esperienza e, di conseguenza, sono felici di riconoscere la mia. Intendiamoci, se penso che ci sia un modo migliore di fare le cose, allora devo assolutamente parlare, ma ho l'obiettivo di dare un feedback più positivo che negativo, complessivamente. In generale, provo a rendere il feedback negativo più formale e impersonale (ad es. Segnalazioni di bug) e il feedback positivo meno formale e più personale (ad es. Conversazioni di persona).

Dare un feedback positivo sulla qualità e un feedback negativo e chiedere consigli cambia la relazione dall'essere controversi al lavoro di squadra e all'apprendimento reciproco e riduce la difesa. Gli sviluppatori sanno di potersi fidare di me per dire sempre più cose buone che cattive, quindi si sentono a loro agio ad ascoltarmi. Inoltre, porre domande approfondite sullo sviluppo solleva la loro opinione su di me e rompe lo stereotipo "Gli SDET sono falliti dev" (dove esiste ancora).

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 buoni approcci, ma ecco cosa ha funzionato meglio per me.

Comunicazione diretta / personale! Ho scoperto che la comunicazione personale, non tramite e-mail, funziona sempre meglio. Permette allo sviluppatore e al tester di stabilire una relazione personale. Una volta che le cose sembrano funzionare meglio e tendono a fluire. Non hanno mai problemi a eseguire un test speciale o fare il possibile per te. Lo stesso vale per lo sviluppatore e mi prendo sempre il tempo extra per esaminare le cose su cui hanno bisogno di aiuto o con cui hanno problemi. Nella mia esperienza, la risoluzione dei problemi è più veloce, c'è meno tempo perso.