I programmatori dovrebbero aiutare i tester nella progettazione dei test?

Quanto i programmatori dovrebbero aiutare i tester nella progettazione dei test?

Non penso che dovrebbero aiutare affatto. La mia preoccupazione è che se aiutano i tester a progettare test per il proprio codice, "infetteranno" i tester con i loro pregiudizi e punti ciechi su quel codice.

Ritengo che i requisiti dovrebbero essere sufficienti per fornire le informazioni necessarie ai tester per creare i loro test. Se c'è una parte dell'implementazione che i programmatori trovano preoccupante, allora penso che sia loro dovere implementare unit test per testare quella parte o persino eseguire i propri test di sistema informali per testare quella parte.

Non tutti quelli che conosco sono d'accordo con questo (e capisco alcuni dei loro punti in una certa misura). Cosa ne pensano gli altri di questo? È discusso in letteratura da qualche parte?

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 proprie idee su come affrontare i test.

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

Più specificamente, penso che gli sviluppatori dovrebbero essere responsabili del primo livello di test: test unitari e test di integrazione di base per assicurarsi che le loro cose funzionino nella maggior parte dei casi prima di consegnarle ai tester.

Spetta ai tester creare test di accettazione basati su requisiti che sono completamente agnostici rispetto a tutti i dettagli di implementazione (questo è generalmente definito "test black box"). Se c'è una discrepanza nel modo in cui tester e sviluppatori comprendono i requisiti, è un problema che dovrebbe essere risolto dal project manager (se presente) o assicurandosi che tutti siano sulla stessa pagina nella fase di progettazione della funzione.

Penso che sia i test che lo sviluppo siano sforzi collaborativi , quindi ovviamente (IMO), gli sviluppatori dovrebbero dare idee di test ai tester. Non credo che li infetti o contesti i tester. 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 fatto un brainstorming di idee di design con gli sviluppatori e mi sono abbinato a loro per correggere bug (e ho sottolineato i bug e le soluzioni suggerite) molte volte nella mia carriera, e non credo che ' ho mai contaminato uno sviluppatore con cooties tester.

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

A mio modo di vedere, non è compito del 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 l'attività che stavo facendo, non i dettagli del mio codice. Non passo mai nulla al QA che contenga bug "a testa d'osso". Ciò spreca il mio tempo, il loro tempo ... e praticamente il tempo di tutti.

Nel mio ultimo lavoro, abbiamo avuto il controllo qualità dall'inizio. Ciò avveniva anche nelle sessioni di raccolta dei requisiti, nelle riunioni del progetto e nelle riunioni di progettazione. Hanno ascoltato e posto domande e mentre gli sviluppatori scrivevano codice, stavano scrivendo i loro piani di test. Ha funzionato alla grande e abbiamo riscontrato molti problemi che probabilmente sarebbero sfuggiti.

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

Non vi è stato alcun "inquinamento" a meno che il codice non sia costituito da acque reflue grezze, e ciò sarebbe dovuto a un motivo completamente diverso.

I requisiti fanno un lavoro terribile nel comunicare i problemi tecnici che un professionista della qualità dovrebbe interessare, perché elaborano al meglio solo ciò che gli analisti aziendali sono riusciti a catturare. I buoni sviluppatori saranno consapevoli che il loro codice è ottimizzato in base al "percorso felice" e vorranno sapere cosa hanno lasciato senza considerazione. Avranno almeno un'intuizione di cosa potrebbe andare storto e di quali aree vorrebbero sondare il QA. Sanno anche quale sia il quadro generale per il rischio relativo a una particolare funzionalità in base al loro design.

In qualità di tester assente dal team di sviluppo, a volte ho adottato un approccio sbagliato che ha generato buone segnalazioni di bug, ma non ha esercitato completamente 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.

Sebbene un tester certamente non dovrebbe limitarsi a testare solo ciò che lo sviluppatore ritiene importante, non verrà danneggiato imparando quali sono le preoccupazioni degli sviluppatori riguardo al codice. A volte, possono mettere a punto il loro approccio in base alla loro conoscenza dell'implementazione. Solo se un tester è particolarmente miope, considererà l'opinione dello sviluppatore su quali siano i rischi come ultima parola; non escluderanno completamente le cose che lo sviluppatore identifica come a basso rischio, ma investiranno più sforzi in cose che potrebbero avere un impatto maggiore sul cliente.

È probabile che il team addetto al QA veda aree che hanno un ampio ambito di test combinatori rispetto ai raccoglitori di requisiti o agli sviluppatori di un sistema, ma potrebbero non essere a conoscenza dei componenti del sistema che hanno un tipo più sottile di fragilità che beneficia della consapevolezza del progetto 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 handoff di scatola nera.

Come tester, non ho alcuna obiezione ai programmatori che suggeriscono casi di test (anche se ciò non significa che mi atterrò solo a quei casi di test) o descrivono i dettagli dell'implementazione. A volte può essere davvero utile che qualcuno dica "Penso che questo bit potrebbe essere rischioso, mi piacerebbe davvero se lo avessi testato abbastanza accuratamente". Conoscere alcuni dettagli dell'implementazione mi aiuta ad applicare anni di esperienza per scegliere i test che ritengo più probabili fallire. A volte solo una breve menzione significa che alcuni test improvvisamente ingrandiscono il mio elenco di priorità.

Mi sporca? Sono un po 'solleticato dall'idea che i programmatori si sforzino cavallerescamente di preservare la purezza del mio tester, ma davvero - no, questo è un mito. Più informazioni di solito fanno scattare ancora più domande per me, non meno. Immagino sia una cosa di mentalità - non trovo bug perché sono ignorante, trovo problemi perché sono un tipo scettico, poco fiducioso, che è semplicemente troppo testardo per prendere completamente tutto sulla fiducia. Su ogni sistema che ho testato, 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 ai quali il QA potrebbe non aver pensato. Non sono sicuro di come "contagiare i tester con i miei pregiudizi".

Mi sono trovato in questa strana posizione in cui ho bisogno di implementare e scrivere casi di test in Selenium in seguito poiché siamo a corto di personale addetto al controllo qualità. Credo che lo sviluppo guidato dai test sarebbe estremamente utile, ma non è ancora adattato nel mio negozio.

Una cosa che trovo utile scrivere i test è che trovo dei bug quando scrivo i test. Penso in una prospettiva diversa per aiutarmi a scrivere codice più solido. 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 il QA e, a differenza della maggior parte dei domini, sapere come usare il nostro codice è molto più difficile che apprendere qualsiasi programma di programmazione. Quindi contiamo sugli sviluppatori per fornirci casi di test per le loro nuovissime funzionalità whizzbang, perché non sapremmo come farlo. In ogni caso, i problemi di QA riguardano più le regressioni e le cose che si rompono rispetto ai test 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 anormale è una cosa buona o cattiva.

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