I programmatori possono aiutare i tester a progettare test?

Sono d'accordo. I programmatori possono aiutare i tester a comprendere le specifiche funzionali, a trovare risorse per la ricerca, ma non dovrebbero inquinare le menti dei tester con le loro idee su come affrontare i test.

Penso che ci sia spazio per sviluppatori e tester per coesistere pacificamente nel regno del QA. :)

Più in particolare, penso che gli sviluppatori dovrebbero essere responsabili per il primo livello di test - unit test e test di integrazione di base per assicurarsi che i loro elementi funzionino nella maggior parte dei casi prima di consegnarli ai tester.

Spetta ai tester creare test di accettazione basati su requisiti che sono completamente indipendenti da qualsiasi dettaglio di implementazione (in genere si parla di 'black box testing'). Se c'è una discrepanza nel modo in cui i tester e gli sviluppatori comprendono i requisiti, è un problema che dovrebbe essere affrontato dal project manager (se presente) o assicurandosi che tutti siano sulla stessa pagina nella fase di progettazione della funzionalità.

Penso che sia il testing che lo sviluppo siano sforzi collaborativi , quindi ovviamente (IMO), gli sviluppatori dovrebbero dare idee di prova ai tester. Non penso che li infetti o tenti affatto. Il tester, ovviamente, dovrebbe migliorare quei test con molti altri approcci di test.

Sono anche un grande fan dei tester che aiutano gli sviluppatori: ho analizzato idee di progettazione con gli sviluppatori e li ho abbinati per correggere i bug (e ho indicato bug e soluzioni suggerite) molte volte nella mia carriera, e non penso di aver mai contaminato uno sviluppatore con testate di prova.

Se non lo vedi come uno sforzo collaborativo, avrai solo il codice "gettato sul muro" da dev per testare ... e finirai con una qualità inferiore. Questa è la verità nel mio mondo, ma (ovviamente), ymmv.

Il modo in cui lo vedo è che non è compito di QA testare il mio codice. Il compito del tester è assicurarsi che il mio codice soddisfi tutti i requisiti per tale compito.

Quando passo qualcosa al QA, mi assicuro che sappiano il compito che stavo facendo, non le specifiche del mio codice. Non trasmetto mai nulla al QA che contiene bug "a testa di ossa". Quello spreca il mio tempo, il loro tempo ... e praticamente il tempo di tutti.

Nel mio ultimo lavoro, abbiamo coinvolto il controllo di qualità sin dall'inizio. Questo si è svolto nelle sessioni di raccolta dei requisiti, nelle riunioni del progetto e negli incontri di progettazione. Ascoltavano e facevano domande e mentre gli sviluppatori scrivevano codice, stavano scrivendo i loro piani di test. Ha funzionato alla grande e abbiamo riscontrato un sacco di problemi che probabilmente sarebbero sfuggiti.

Penso che tu sia del tutto sbagliato qui. Sono stato un tester e uno sviluppatore e ho tratto un grande beneficio come tester dalla guida degli sviluppatori su aree che consideravano ad alto rischio o fragili; come sviluppatore, voglio che i tester trovino i problemi che non ho approfondito.

Non c'è stato alcun "inquinamento" a meno che il tuo codice non sia un sistema fognario grezzo e ciò sarebbe dovuto a un motivo completamente diverso.

I requisiti fanno un lavoro terribile di comunicazione dei problemi tecnici a cui un professionista del controllo qualità dovrebbe interessare, perché elaborano al meglio solo ciò che gli analisti di business sono riusciti a catturare. I buoni sviluppatori saranno consapevoli che il loro codice è ottimizzato attorno al "percorso felice" e vorranno sapere cosa hanno lasciato inosservati. Avranno almeno un'intuizione di cosa potrebbe andare storto e quali aree vorrebbero che il QA sondaggi. Sanno anche quale sia il quadro generale del rischio attorno a una determinata funzione in base al loro design.

Come tester assente dal team di sviluppo, a volte mi sono imbattuto in un approccio sbagliato che generava buone segnalazioni di bug, ma non ho completamente esercitato i percorsi del codice ad alto rischio e problemi più grandi, che avrebbero potuto essere evitati attraverso una migliore collaborazione con il team di sviluppo, spedito ai clienti.

Anche se un tester non dovrebbe limitarsi a testare solo ciò che lo sviluppatore dice che è importante, non sarà danneggiato imparando quali sono le preoccupazioni degli sviluppatori riguardo al codice. A volte, possono perfezionare il loro approccio in base alla loro conoscenza dell'implementazione. Solo se un tester è particolarmente miope prenderà in considerazione l'opinione dello sviluppatore su quali sono i rischi come l'ultima parola; non elimineranno completamente le cose che lo sviluppatore identifica come a basso rischio, ma investiranno maggiori sforzi in cose che potrebbero avere un impatto maggiore sul cliente.

È probabile che il team addetto al controllo qualità veda aree con un ambito di test combinatorio grande rispetto ai raccoglitori di requisiti o agli sviluppatori di un sistema, ma potrebbero non essere a conoscenza dei componenti del sistema che presentano un tipo più sottile di fragilità che beneficia della consapevolezza della progettazione o implementazione del sistema.

Nella mia esperienza, la collaborazione tra QA e Sviluppo produce prodotti di migliore qualità. Non consiglierei mai di fare solo un passaggio al black box.

Come tester, non ho alcuna obiezione ai programmatori che suggeriscono casi di test (anche se ciò non significa che rimarrò ai soli casi di test), o che descriverò i dettagli di implementazione. A volte può essere davvero utile avere qualcuno che dice "Penso che questo bit potrebbe essere rischioso, mi piacerebbe davvero se avessi testato questo pezzo abbastanza bene". Conoscere alcuni dettagli di implementazione mi aiuta ad applicare anni di esperienza per scegliere i test che ritengo più probabili non riuscire. A volte solo una breve menzione significa che alcuni test improvvisamente ingrandiscono la mia lista delle priorità.

Mi inquina? Sono un po 'stuzzicato dall'idea dei programmatori che si battono cavallereschi per preservare la mia purezza del tester, ma in realtà - no, questo è un mito. Più informazioni di solito innescano ancora più domande per me, non meno. Immagino sia una cosa da mentalità: non trovo bug perché sono ignorante, trovo dei problemi perché sono un tipo scettico e poco fiducioso che è troppo dannatamente testardo per prendere tutto sulla fiducia. Su ogni sistema che ho provato, ho scoperto che trovo più problemi e più "interessanti", più profondamente riesco a capirlo.

Mi piace rivedere i piani di test e suggerire ulteriori casi di test a cui il controllo qualità non avrebbe potuto pensare. Non sono sicuro di come possa "infettare i tester con i miei stessi pregiudizi".

Mi sono ritrovato in questa strana posizione che ho bisogno di implementare e scrivere casi di test in Selenium in seguito, visto che siamo a corto di personale di controllo qualità. Credo che lo sviluppo basato sui test sarebbe estremamente utile ma non è ancora adattato nel mio negozio.

Una cosa che trovo utile ai test di scrittura è che trovo bug quando scrivo test. Penso in una prospettiva diversa per aiutarmi a scrivere codice più robusto. Ma è vero che la copertura del test potrebbe essere limitata. In questo caso, i QA possono sempre farci sapere cosa vorrebbero essere coperti. Oppure, possiamo aggiungere passivamente più test quando vediamo errori.

Sto facendo QA e, diversamente dalla maggior parte dei domini, sapere come usare il nostro codice è molto più difficile che imparare qualsiasi lanquage di programmazione. Quindi contiamo sugli sviluppatori per darci dei casi di prova per le loro caratteristiche di whizzbang nuove di zecca, perché non sapremmo come. In ogni caso i problemi di controllo qualità sono più utili per rilevare regressioni e cose che si infrangono rispetto alle prove originali di nuove funzionalità. In ogni caso, quando il risultato è un calcolo complesso, è difficile sapere quale sia una risposta corretta e quale sia una risposta sbagliata, o anche se una terminazione anomala è una cosa buona o cattiva.

In ogni caso, uno sviluppatore, se è onesto, probabilmente conosce qualcosa dei suoi bambini vulnerabilità. Probabilmente sa a quali valori dei parametri, deve selezionare diversi algoritmi, o domini in una ricerca tabella o qualsiasi altra cosa. Sapendo che, se è sincero nei confronti di test rigorosi, dovrebbe essere in grado di generare una serie di test di dimensioni ragionevoli che copre gran parte del codice.