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

Penso sia una generalizzazione grossolana e una semplificazione eccessiva.

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

Potresti voler dare un'occhiata alla cultura aziendale e al modo in cui i team lavorano l'uno con l'altro per trovare la tua risposta. Nella mia esperienza, se hai flussi di lavoro molto reazionari (cioè gli sviluppatori "lanciano una build sul muro per testare" e testano "restituisce bug") invece di lavorare insieme , solo da punti di messa a fuoco differenti o "vettori di attacco" poi scoprirai che entrambi i reparti in generale, non non amano l'altro.

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

modifica

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

Per noi è molto più facile rendere le vite degli sviluppatori migliori o peggiori, 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 ritengo essere una potenziale soluzione che soddisfi i vari requisiti e l'eventuale test di regressione che scriverò.

I AMORE i miei tester - mi aiutano a individuare e individuare cose che non considererei un problema, ma lo farebbero i nostri clienti. E, cosa più importante per me, mi aiutano a essere sicuro di non uccidere qualcuno con codice errato.

Perché si verificano problemi?

• Sei costantemente a giudicare che lavorano gli altri, e alcune persone non possono accettare alcun tipo di critica
• Fare un brutto lavoro spreca il tempo del tuo opposto
• Sei sotto pressione, allo stesso tempo, per la stessa cosa e nessuno vuole essere quello che tiene le cose

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

Immagino che accada perché i programmatori creino un programma e percepiscono che i tester cercano di trovare difetti in esso (anche se i tester sono in realtà una parte del miglioramento del prodotto finale). Ogni volta che qualcuno trova difetti in qualcosa in cui ci si sforza tanto, è probabilmente una reazione naturale a reagire negativamente nei loro confronti.

I modi per mitigare questo sarebbe quello di fare in modo che sviluppatori e tester visualizzino il prodotto finito come output del team intero (compresi i tester e gli sviluppatori) e fagli capire che il test non è una missione di individuazione dei guasti autonoma, ma una parte importante del processo di sviluppo . E se gli sviluppatori non pensano che il testing sia un lavoro reale , o che sia facile, fagli scrivere le matrici dei test, esegui centinaia di test case, documenta ogni singola fase e ogni singolo risultato. p>     

Conosco programmatori particolari e tester particolari a cui non piacciono a vicenda, ma non per le ragioni che hai affermato, ma piuttosto perché fanno il lavoro l'uno per l'altro.

È la natura della bestia. Alcuni dei tester particolari che conosco non si sono interessati a determinati programmatori perché ritenevano che il loro codice fosse soggetto a errori dovuti a negligenza / pigrizia / ecc. Alcuni dei programmatori che conosco, a cui non importava un particolare tester, sentivano di aver usato condizioni di test ridicolmente forzate (picking nits) o avrebbero richiesto revisioni al codice in base allo stile.

Penso che tenere fuori la personalità, e concentrandosi sul compito a portata di mano, faccia molta strada per ridurre le tensioni. Se un'organizzazione è abbastanza grande, il test in doppio cieco è una grande idea.

Un tester che può esprimere chiaramente i problemi, e i programmatori che implementano chiaramente le soluzioni sono una grande squadra.

Nelle squadre in cui ho lavorato a stretto contatto con i tester, siamo andati avanti in modo fantastico. I tester comprendono le decisioni prese nelle varie decisioni prese, sanno quali sono gli orari degli sviluppatori e un rapporto tra i due gruppi.

Nelle squadre in cui il test è una entità amorfa in mare aperto, questo non è stato il caso. I risultati dei tester sono meno rilevanti perché non sanno molto su cosa sta succedendo, gli sviluppatori iniziano a temere il diluvio di quelli che considerano dettagli irrilevanti che si trovano in parti del programma che non sono stati toccati in due mesi, il team di test si infastidisce per il fatto che nessuno dei bug archiviati viene risolto (perché il programma è fasullo 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" in contrasto con i membri del team.

Lavorare da vicino e le cose andranno bene. Qualcuno deve assicurarsi che entrambe le squadre siano coordinate e sulla stessa pagina. La mia migliore esperienza, il team di test è stato invitato a qualsiasi riunione ad alto livello a cui il team di sviluppo è stato invitato (tutti) e tutti conoscevamo il programma, avevamo un elenco di priorità unificato e gli sviluppatori e i test avevano entrambi lo stesso fino ad oggi) documento dei requisiti. La mia peggiore esperienza (oltre a nessun test) abbiamo praticamente confezionato la nostra roba, spedita oltreoceano per essere guardata, poi riavviato tutto un mese dopo con cose contrassegnate come errate che non erano nemmeno nostre (plugin di terze parti che ha incontrato il nuovo requisiti, ma non le aspettative del team di test).

Nessuno degli sviluppatori o dei test avrà successo senza l'altro. Se lavori come due metà della stessa macchina e rispetti l'altra parte tanto quanto rispetti i tuoi membri più immediati, le cose andranno bene. Comportati come due macchine separate e supponi che la tua macchina sia migliore, le cose saranno terribili.

Quando programmatori e tester non si apprezzano a vicenda, spesso è perché erroneamente immaginano che i loro obiettivi siano in conflitto.

Ho scoperto che questi problemi sono notevolmente mitigati quando tester e sviluppatori si trovano nella stessa squadra, piuttosto che un "team di test" e un "team di sviluppo". Penso che questo sia il motivo per cui, come tester, preferisco decisamente lavorare su team Agile piuttosto che sullo sviluppo di waterfall. C'è più comunicazione, il turn-around è più veloce e gli sviluppatori apprezzano maggiormente il tempo e il talento che vanno in testing quando quel lavoro è più trasparente.

Individualmente, c'è molto che può essere fatto pure. Come tester, trovo che sono in grado di ridurre questo attrito fornendo feedback positivi oltre a trovare bug. Devo ancora testare per un dev che non potrebbe insegnarmi un lotto , e trovo che gli sviluppatori apprezzino un tester che lavora davvero per capire il codice. Gli sviluppatori sono orgogliosi, come ogni buon artigiano. È importante far sapere loro che avere bug non li rende meno ammirevoli

Gli sviluppatori che ho trovato sono più facili da lavorare con una buona qualità apprezzata, e lo dimostrarono facendo uno sforzo per scrivere codice di alta qualità prima che il tester lo vedesse, compreso fare test preliminari (principalmente test di unità automatizzate e test del fumo manuale) . Questi sviluppatori hanno anche chiesto ai test di effettuare revisioni del codice per la testabilità e hanno incluso i tester nel processo il prima possibile, inclusa la presentazione dei progetti all'inizio (che consente ai tester di iniziare a pianificare le strategie di test in anticipo, quando il test ha un carico minore). Gli sviluppatori possono aiutare i tester a trovare aree deboli nel loro codice comunicando loro quali aree sono state sviluppate in fretta o quali aree sono state 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 apprezzano sia il tempo del tester che il loro. Quando gli sviluppatori fanno questo, un singolo tester può facilmente coprire il lavoro di molti sviluppatori (in questo momento, io collaudo per 4 sviluppatori e faccio poco o nessun lavoro straordinario per farlo).

Un altro problema è che il controllo qualità è spesso un ripensamento di molte aziende. Molte volte viene raccontato di progetti all'ultimo minuto ed è gravemente sottodimensionato rispetto al team di sviluppo. In alcuni punti il percorso per lo sviluppatore è il supporto tecnico, il controllo qualità e uno sviluppatore. Quindi a volte è equipaggiato con 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 tale errore, ecc ...

Nel complesso mi piacerebbe un team di controllo qualità. Penso anche che il test unitario dovrebbe essere una parte necessaria dello sviluppo del software separato dal QA. Così come il QA trova bug, i test unitari vengono cambiati per testarlo. Inoltre, ritengo che gli sviluppatori che effettuano il test unitario possano capire meglio che cosa sta rilevando il QA.

Inoltre molti team di 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 anche la creazione di GUI di script (tramite una sorta di riconoscimento di immagini sullo schermo per i pulsanti / ecc.). Poi è ancora difficile quando all'inizio ci sono grandi cambiamenti, ma poi tutto è automatizzato e sembra più divertente ...

Anche alcuni sviluppatori guardano dall'alto in basso il QA. Ancora preferirei che il QA trovasse un difetto rispetto al cliente ....

Amiamo i nostri tester qui, ma poi molti di noi ricordano com'era prima di averli. È davvero meglio avere dei tester che trovino i problemi che avere il client dopo averli messi in produzione. Non c'è uno sviluppatore attivo che non abbia creato un bug o abbia interpretato erroneamente 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.

In base a questa domanda: Tecniche o categorie di test del software Sospetto che tu abbia bisogno di un aggiustamento di 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 testavano la "cosa giusta". Implementerei una nuova funzionalità per il server del nostro prodotto e i tester avrebbero segnalato un intero mucchio di errori sull'interfaccia utente. Dato che, in quel prodotto, l'interfaccia utente era configurata non codificata , la presenza (o meno) di problemi nella nostra UI di sviluppo non aveva assolutamente alcun legame con gli utenti finali un'interfaccia utente con problemi simili. I tester lo sapevano, eppure persistevano nei bug di registrazione di aree estranee.

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

Ho anche conosciuto alcuni sviluppatori che considerano i tester come nemici - come se i tester stessero introducendo i difetti. È importante per gli sviluppatori rendersi conto che i tester non presentano mai l'errore: lo scoprono semplicemente.

Come evitare questi problemi? Che ne dici di essere gentili 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 ha bisogno di fare per realizzare questo? Scopri cosa fa ogni parte e potresti davvero apprezzare il lavoro svolto.

La testardaggine su entrambi i lati di ciò che è l'interpretazione corretta di un requisito sarebbe dove ho avuto la tendenza a vedere il conflitto tra sviluppatori e tester in generale. Mentre potrebbe esserci un'apparizione di snobismo o arroganza, è solo che ogni lato si attacca alle loro pistole e vuole avere ragione.

Un buon modo per evitare questo problema è di avere 3 parti, lo sviluppatore, il tester e qualche mediatore sia che un analista aziendale o un project manager lavorino su come devono essere gestiti i vari casi limite. Qualcosa da considerare è quale tipo di ego può sorgere in caso di disaccordo tra sviluppatori e tester.

Il brutto presentimento è solitamente 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 punti su cui ha lavorato intimamente, ma potrebbe non sapere in che modo si inseriscono nel 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 terminologia e procedure diverse per le stesse cose.

Ciò può comportare la presenza di difetti nei confronti del componente sbagliato (perché il componente risponde a un guasto a monte), o gli sviluppatori che chiudono difetti legittimi perché non riescono a riprodurre il problema nel loro ambiente (perché non capiscono come riprodurre correttamente il problema). Se questo accade molto, può mettere a dura prova le relazioni tra i gruppi.

Poi c'è la gioia di ottenere un lotto di difetti all'undicesima ora; le scadenze si profilano, le pressioni arrivano dal tuo manager immediato sulla catena, e ottieni una nuova serie di difetti su un problema che conosci che hai già risolto e che davvero non vuoi Dover prendere il tempo per passare attraverso il processo per dimostrarlo.

Un veramente buon modo per far arrabbiare il tuo team di QA è di chiudere sommariamente diverse centinaia di difetti legittimi ma a bassa priorità (principalmente archiviati contro interfacce utente brutte o incoerenti altrimenti funzionali) con il ragionamento che il tuo l'arretrato dei difetti con priorità più alta è così grande che "non arriveremo mai a quelli". Si passa dal rosso al verde sul foglio di calcolo del gestore del programma e si ottiene un attaboy da una gestione più elevata, mentre il team addetto al controllo qualità colpisce le proprie metriche per archiviare un sacco di difetti fasulli.

Bad juju.

Questo spesso deriva da tre fattori:

• Domande come queste sottolineano l'esistenza di un "folklore" nel settore che gli sviluppatori e i tester non amano l'un l'altro. Le persone cercano di trovare aspetti che lo rafforzano, anche quando tale sentimento potrebbe non esistere nella loro squadra.
• Gestori di progetti incompleti che misurano i progressi mediante metriche come il numero di bug registrati
• Una squadra disfunzionale (e una mancanza di leader che si preoccupano di abbastanza per risolverlo)

Mi piacciono i tester, ma in due casi ho riscontrato un conflitto.

1. Quando la gestione gioca a giocare con i tester e gli sviluppatori.

2. Quando vengono costantemente presentati dei problemi privi di dettagli, ad esempio "Screen x non funziona".

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

Il test è una parte piuttosto importante del ciclo di vita dello sviluppo del software (sia esso agile o meno). 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à.