Perché tester e programmatori non si piacciono? [chiuso]

Durante la mia carriera di programmatore ho visto vari programmatori e tester, e molti di loro non si sono piaciuti. Voglio dire, i programmatori pensano che il lavoro di un tester non sia un lavoro "reale", e i tester pensano che i programmatori siano troppo "orgogliosi".

È questa la decisione giusta presa da me, perché lo è e cosa possiamo fare per evitare questi problemi gentili?

Penso che sia una grossolana eccessiva generalizzazione e eccessiva semplificazione.

Sono attualmente un tester, scrivo quasi tutto il codice che ho scritto come un dev (dipende dalla fase di test) e il mio migliore amico in azienda è un dev e andiamo tutti d'accordo.

Potresti dare un'occhiata alla cultura aziendale e al modo in cui i team lavorano l'uno rispetto all'altro per trovare la tua risposta. Nella mia esperienza, se hai flussi di lavoro molto reazionari (ad es. Devs "lancia una build sul muro per testare" e testare "restituisce bug") invece di lavorare insieme , solo da punti di messa a fuoco diversi o "vettori di attacco", allora " Scoprirò che entrambi i dipartimenti in generale non apprezzeranno l'un l'altro .

Dove lavoro, ogni team di funzioni o team di progettazione ha quasi tanti tester quanti sviluppatori lavorano insieme per produrre risultati. Tale output è un codice di produzione che soddisfa i requisiti stabiliti dal codice di test.

modificare

Inoltre, penso che l'onere sia sul tester più che sullo sviluppatore per supportare la relazione tra i due.

È molto più facile per noi migliorare o peggiorare la vita degli sviluppatori, ma l'obiettivo non è semplicemente "trovare bug" ma anche trovare potenziali soluzioni. Se non posso, allora non posso, e lavorerò con chiunque venga assegnato il bug a quel punto per trovare una soluzione. Ma se si tratta di una soluzione semplice, fornirò quella che credo sia una potenziale soluzione che soddisfi i vari requisiti e l'eventuale test di regressione che scriverò.

Io AMO il mio tester - mi aiutano a risolvere i problemi e macchio cose che non avrei pensare come un problema, ma i nostri clienti. E, cosa più importante per me, mi aiutano a non uccidere qualcuno con un codice errato.

Perché compaiono i problemi?

• Stai costantemente giudicando a vicenda il lavoro, e alcune persone non possono prendere alcun tipo di critica
• Fare un brutto lavoro fa perdere tempo al tuo opposto
• Siete entrambi sotto pressione, allo stesso tempo, per la stessa cosa e nessuno vuole essere colui che regge le cose

La combinazione di quanto sopra con la natura delle posizioni significa che è davvero facile prendere le tue rabbia e frustrazioni attuali l'una sull'altra, se cadi in quella trappola smetti di lavorare insieme e inizi a lavorare l'uno contro l'altro. È difficile uscirne e non fa bene a nessuno.

Immagino che accada perché i programmatori creano un programma e percepiscono che i tester cercano quindi di trovare dei difetti (anche se i tester fanno effettivamente parte del miglioramento del prodotto finale). Ogni volta che qualcuno trova difetti in qualcosa in cui fai molti sforzi, è probabilmente una reazione naturale reagire negativamente nei loro confronti.

Modi per mitigare questo sarebbe quello di far sì che gli sviluppatori e i tester vedano il prodotto finito come l'output dell'intero team (inclusi tester e sviluppatori) e far loro capire che i test non sono una missione autonoma di ricerca guasti ma una parte importante di il processo di sviluppo . E se gli sviluppatori non pensano che il test sia un vero lavoro o che sia facile, chiedi loro di scrivere le matrici di test, eseguire centinaia di casi di test, documentare ogni singolo passaggio e ogni singolo risultato.

Conosco programmatori e tester particolari a cui non piacciono, ma non per i motivi che hai dichiarato, ma piuttosto perché si fanno lavorare l'uno per l'altro.

È la natura della bestia. Alcuni dei tester specifici che conosco non si sono preoccupati di programmatori particolari perché hanno ritenuto che il loro codice fosse soggetto a errori dovuti a disattenzione / pigrizia / ecc. Alcuni dei programmatori particolari che conosco, a cui non importava particolari tester, pensavano che usassero condizioni di test ridicolmente inventate (raccogliendo nits) o che avrebbero richiesto revisioni al codice in base allo stile.

Penso che tenere lontane le personalità e concentrarsi sul compito da svolgere sia molto utile per ridurre le tensioni. Se un'organizzazione è abbastanza grande, i test in doppio cieco sono un'ottima idea.

Un tester in grado di esprimere chiaramente i problemi e programmatori che implementano chiaramente le soluzioni sono un'ottima squadra.

Nei team in cui ho lavorato a stretto contatto con i tester, siamo andati d'accordo in modo fantastico. I tester comprendono le decisioni che sono state prese nelle varie decisioni prese, sanno come sono i programmi degli sviluppatori e si crea un rapporto tra i due gruppi.

Nei team in cui il test è un'entità amorfa al largo, non è stato così. I risultati dei tester sono meno rilevanti perché non sanno molto di quello che sta succedendo, gli sviluppatori iniziano a temere il diluvio di quelli che considerano dettagli irrilevanti che sono in parti del programma che non sono stati toccati in due mesi, il team di test si infastidisce che nessuno dei bug archiviati sia stato corretto (perché il programma è rovinato e gli sviluppatori sono impegnati a prepararsi per le dimostrazioni o aggiungere funzionalità richieste, ecc.), e in generale entrambi i gruppi si vedono come antagonisti "altri" rispetto ai membri del team.

Lavora da vicino e le cose andranno bene. Qualcuno deve assicurarsi che entrambi i team siano coordinati e sulla stessa pagina. La mia migliore esperienza, il team di test è stato invitato a qualsiasi riunione di alto livello a cui è stato invitato il team di sviluppo (tutti) e tutti conoscevamo il programma, avevamo un elenco di priorità unificato, e gli sviluppatori e i test avevano lo stesso (up- ad oggi) documento dei requisiti. La mia peggiore esperienza (oltre a nessun test) abbiamo praticamente impacchettato le nostre cose, spedite all'estero per essere guardate, poi abbiamo recuperato tutto un mese dopo con cose contrassegnate come sbagliate che non erano nemmeno nostre (plugin di terze parti che incontravano il nuovo requisiti, ma non le aspettative del team di test).

Nessuno sviluppatore o test avrà esito positivo senza l'altro. Se lavori come due metà della stessa macchina e rispetti l'altra parte tanto quanto rispetti i membri del tuo team più immediati, le cose andranno bene. Comportati come due macchine separate e presumi che la tua macchina sia migliore, le cose saranno terribili.

Quando programmatori e tester non si piacciono, spesso è perché pensano erroneamente che i loro obiettivi siano in conflitto.

Ho scoperto che questi problemi sono notevolmente mitigati quando tester e sviluppatori fanno parte dello stesso team, piuttosto che un "team di test" e un "team di sviluppo". Penso che sia per questo che, come tester, preferisco fortemente lavorare sui team Agile piuttosto che sullo sviluppo delle cascate. C'è più comunicazione, il turn-around è più veloce e gli sviluppatori apprezzano maggiormente il tempo e il talento che vanno alla prova quando quel lavoro è più trasparente.

Individualmente, c'è anche molto da fare. Come tester, trovo di essere in grado di ridurre questo attrito fornendo feedback positivi e trovando bug. Devo ancora provare un dev che non mi ha insegnato molto e trovo che gli sviluppatori apprezzino un tester che lavora davvero per capire il codice. Gli sviluppatori sono orgogliosi, come ogni bravo artigiano. È importante far loro sapere che avere dei bug non li rende meno ammirevoli

Gli sviluppatori che ho trovato più facili da lavorare con apprezzata buona qualità, e l'hanno dimostrato facendo uno sforzo per scrivere codice di alta qualità prima che il tester lo vedesse, incluso fare test preliminari (principalmente test di unità automatizzati e test manuali del fumo). Questi sviluppatori hanno anche chiesto ai test di fare revisioni del codice per verificabilità e hanno incluso i tester nel processo il più presto possibile, inclusa la presentazione precoce dei progetti (che consente ai tester di iniziare a pianificare le strategie di test in anticipo, quando il test ha un carico più leggero). Gli sviluppatori possono aiutare i tester a trovare aree deboli nel loro codice dicendo loro quali aree sono state sviluppate in fretta o quali aree erano difficili da testare. In generale, tutto ciò che gli sviluppatori possono fare per rendere più semplice il lavoro di un tester è apprezzato e dimostra che valorizzano il tempo del tester e il proprio. Quando gli sviluppatori fanno questo,

Un altro problema è che il QA è spesso ripensato da molte aziende. Molte volte si parla di progetti all'ultimo minuto ed è fortemente a corto di personale rispetto al team di sviluppo. In alcuni punti il ​​percorso per gli sviluppatori è il supporto tecnico, il controllo qualità e quindi uno sviluppatore. Quindi a volte è composto da persone che desiderano essere sviluppatori ... E poi quando trovano un difetto il loro atteggiamento è come può quella persona essere uno sviluppatore e non io non farei mai un errore del genere, ecc ...

Nel complesso, mi piacerebbe un team di controllo qualità. Inoltre, penso anche che i test unitari dovrebbero essere una parte necessaria dello sviluppo del software separata dal QA. Quindi, man mano che il QA rileva dei bug, i test unitari vengono cambiati per testarlo. Inoltre, penso che gli sviluppatori che effettuano unit test possano capire meglio cosa sta riscontrando il QA.

Inoltre, molti team addetti al controllo qualità devono fare le cose manualmente, nel qual caso si tratta di un lavoro davvero noioso. In alcuni punti il ​​QA scrive script e utilizza programmi di automazione che consentono persino le GUI di script (attraverso una sorta di riconoscimento delle immagini sullo schermo per pulsanti / ecc.). Quindi è ancora difficile quando si verificano cambiamenti importanti all'inizio, ma poi tutto è automatizzato e sembra più divertente ...

Inoltre alcuni sviluppatori guardano dall'alto in basso il QA. Preferirei piuttosto che il QA trovasse un difetto rispetto al cliente ...

Adoriamo i nostri tester qui, ma poi molti di noi ricordano com'era prima di averli. È molto meglio che i tester trovino problemi piuttosto che farli trovare dal cliente dopo essere passati alla produzione. Non esiste uno sviluppatore vivo che non abbia creato un bug o interpretato male un requisito.

La chiave è trattare tutti i professionisti con gentilezza e rispetto se fanno quello che fai o no. Una volta che inizi a pensare che il tuo lavoro sia migliore o più importante del loro, allora hai perso.

Sulla base di questa domanda: tecniche o categorie di test del software Ho il sospetto che abbiate bisogno di un aggiustamento dell'atteggiamento nei confronti dei tester e dei test in generale.

Come sviluppatore, ho sperimentato la mia parte di tensione con i tester.

In un lavoro, i tester raramente testerebbero la "cosa giusta". Implementerei una nuova funzionalità per il server del nostro prodotto e i tester segnalerebbero un mucchio di errori sull'interfaccia utente. Poiché, in quel prodotto, l'interfaccia utente era configurata non codificata , la presenza (o meno) di problemi nella nostra interfaccia utente di sviluppo non aveva assolutamente alcun legame con il fatto che gli utenti finali avrebbero avuto un'interfaccia utente con problemi simili. I tester lo sapevano, ma persistevano nel registrare bug su aree estranee.

Detto questo, i buoni tester valgono il loro peso in oro - scambierei uno sviluppatore schifoso con un buon tester in un istante. Un buon tester è un partner nella fornitura di un prodotto di qualità.

Ho anche conosciuto alcuni sviluppatori che trattano i tester come nemici - come se i tester stessero introducendo i difetti. È importante che gli sviluppatori si rendano conto che i tester non introducono mai l'errore: lo scoprono e basta.

Come evitare questi problemi? Che ne dici di essere gentile l'uno con l'altro? Uno ha bisogno dell'altro per ottenere un'applicazione software di qualità, quindi perché non rispettare ciò che ciascuna parte deve fare per raggiungere questo obiettivo? Scopri cosa fa ciascuna parte e potresti davvero apprezzare il lavoro coinvolto.

La testardaggine su entrambi i lati della corretta interpretazione di un requisito sarebbe quella in cui tendevo a vedere il conflitto tra sviluppatori e tester in generale. Mentre può esserci un'apparizione di snobismo o arroganza, è solo che ogni parte si attacca alle loro pistole e vuole avere ragione.

Un buon modo per evitare questo problema è far sì che 3 parti, lo sviluppatore, il tester e un mediatore, un analista aziendale o un project manager, lavorino su come gestire vari casi limite. Qualcosa da considerare è che tipo di ego può sorgere in caso di disaccordo tra sviluppatori e tester.

Il cattivo feeling è generalmente il risultato di una cattiva comunicazione, che di solito è il risultato dei programmatori e dei tester che hanno diverse prospettive del codice. Il programmatore conosce i bit su cui ha lavorato in modo intimo, ma potrebbe non sapere come si adattano al sistema generale (al di là di ciò che le specifiche gli dicono). I tester vedono il quadro generale, ma non conoscono il codice in dettaglio. I gruppi possono utilizzare una terminologia e procedure diverse per le stesse cose.

Ciò può comportare la presentazione di difetti contro il componente errato (perché il componente risponde a un errore a monte) o lo sviluppo da parte degli sviluppatori di difetti legittimi perché non riescono a riprodurre il problema nel loro ambiente (perché non capiscono davvero come riprodurre il problema correttamente). Se ciò accade molto, può mettere a dura prova le relazioni tra i gruppi.

Poi c'è la gioia di ottenere una serie di difetti all'undicesima ora; le scadenze sono imminenti, la pressione ti sta arrivando dal tuo diretto manager lungo la catena e ottieni una nuova serie di difetti su un problema che sai di aver già risolto e che davvero non vuoi prendere il tempo per andare attraverso il processo per dimostrarlo.

Un davvero buon modo per pisciare fuori il vostro team QA è quello sommariamente vicino diverse centinaia di difetti legittimi ma a bassa priorità (principalmente presentate contro interfacce utente brutti o incoerenti che erano altrimenti funzionale) con la motivazione che il difetto di backlog con priorità più alta è così grande che " non arriveremo mai a quelli ". Passa dal rosso al verde sul foglio di calcolo del gestore del programma e ottieni un attaboy da un management superiore, mentre il team QA prende un colpo sulle loro metriche per archiviare un sacco di difetti fasulli.

Bad juju.

Ciò deriva spesso da tre fattori:

• Domande come queste indicano l'esistenza di un "folklore" nel settore che non piace a sviluppatori e tester. Le persone cercano di trovare aspetti che lo rafforzano, anche quando un tale sentimento potrebbe non esistere nella loro squadra.
• Responsabili di progetto incompetenti che misurano i progressi in base a metriche come il numero di bug registrati.
• Una squadra disfunzionale (e una mancanza di leader che si preoccupano abbastanza per risolverlo).

Mi piacciono i tester, ma in due casi ho trovato conflitti.

1. Quando la gestione gioca tester e si scambiano reciprocamente.

2. Quando vengono costantemente inviati problemi che mancano di dettagli, ad esempio "La schermata x non funziona".

Penso che se questo è davvero il caso, è un segno di immaturità. A volte potresti parlarne come uno scherzo. Ma se tu (sviluppatori e tester che lavorano allo stesso progetto) non ti senti una squadra, il risultato sarebbe un disastro.

I test sono una parte piuttosto importante del ciclo di vita dello sviluppo del software (che sia agile o no). Quindi non dovresti pensare ai tester come a persone che vivono per infastidirti con i bug, ma piuttosto come un compagno di squadra che ti aiuta a spedire software di qualità.