Chi è un tester? [duplicare]

Il termine "tester" viene applicato a tutta una serie di professioni che fanno tutti un lavoro leggermente diverso. Ciò che i tester hanno in comune è che loro

• prova a rompere quel bel pezzo di codice che hai appena scritto
• cerca casi limite e interazioni impreviste tra i requisiti
• fornisce la propria interpretazione, indipendente e non influenzata, dei requisiti
• cerca le reazioni inaspettate e / o scomode del sistema

Alcuni tipi di tester sono:

• I tecnici dell'automazione di prova sono i "programmatori" sotto i tester. Generalmente scrivono script in varie lingue per eseguire test automatici su un sistema. Di solito, il sistema nel suo complesso è testato come una scatola nera, ma a volte gli script di test sono più su un livello di integrazione o di test unitario con un sistema white-box.
• I testisti scrivono "script di test" che devono essere eseguiti a mano, da soli o dai tester manuali. Questi script dovrebbero essere basati sui requisiti e / o sui problemi precedentemente segnalati.
• I tester manuali sono quelli che eseguono principalmente script di test (manuali) e giocano con il sistema come una sorta di power user.

Tradizionalmente, non ci si aspetta che i tester abbiano conoscenze di programmazione e qualsiasi test che lo richiede (come test di unità o integrazione) rientra nell'ambito dei programmatori e i tester vengono visualizzati solo quando non è necessario programmare strumenti per interagire con il sistema in prova.

Con l'automazione del test, i tester potrebbero entrare più a fondo nel codice, ma è improbabile che inizieranno a lavorare fianco a fianco con un programmatore su un pezzo di codice, perché ciò comprometterebbe la loro visione indipendente sul requisiti troppo. Questa visione indipendente è importante, perché porterà ad ipotesi infondate e requisiti poco chiari o ambigui da illuminare in precedenza.

I really don't see any use of this. I wish I could just tell them what I coded and they would just write the tests.

Beh, non è il mondo in cui vivi. Inoltre, non tutto può essere fatto nei test automatici. Inoltre, i "tester manuali" sono spesso persone con una conoscenza del dominio molto migliore rispetto agli sviluppatori. Ascoltale e potresti imparare alcune cose su perché il tuo sistema ha i requisiti che stai implementando.

I also have seen some brilliant software developers being testers at tech companies (Google, Microsoft etc.). Why do these developers want to become testers? Are their developer skills actually being used? If so, by how?

Di solito hanno il titolo di lavoro "Software Engineer in Testing" o simile. E sì, le loro abilità di sviluppatore sono utilizzate nella scrittura di test tanto quanto i tuoi sono usati nella scrittura di applicazioni. La creazione di un'infrastruttura di test per un sistema su larga scala può di per sé comportare un sistema di test complesso.

I write the code and they write the tests...

Sicuramente questo succede in alcune delle migliori aziende tecnologiche come google e facebook, dove hanno a tempo pieno ingegneri di qualità altamente qualificati che hanno un backgfround di programmazione come quello che descrivi.

Ora per l'altro 99% del mondo di programmazione ("reale"): la maggior parte dei tester sta eseguendo la maggior parte dei test eseguendo suite di test unitari, eseguendo test manuali e scrivendo alcuni test automatici, tuttavia questo è ancora nella sua infanzia e di solito non al livello "per ticket". Spesso più come test del fumo per consentire il mocking e lo stub nei test unitari.

Vorrei ammonire che non stanno aggiungendo valore come tester manuali.
(dopo essermi trasferito da Dev. per testare dopo decenni di sviluppo.)

Il test manuale continua a svelare una grande quantità di problemi, tra cui:

• diversi modelli e approcci di utilizzo
• problemi di integrazione
• diversi dispositivi
• diversi browser
• diverse versioni del browser
• diverse dimensioni della finestra
• Problemi di usabilità
• problemi temporali
• problemi di larghezza di banda in circostanze reali
• risposte agli input non validi

Per il tuo esempio: "un po 'inutile per loro testare un po' di funzionalità (cioè questo pulsante invia una richiesta post all'end point xyz e invia questi valori)."

• Cosa succede se inseriscono valori diversi?
• Quanto è grande il pulsante su un iPhone?
• Il pulsante ha un testo visibile su un Samsung 5 con Anndroid?
• Il pulsante e il testo del pulsante hanno contrasto per aiutare gli utenti daltonici?
• Lo sviluppatore ha seguito gli standard aziendali per le dimensioni di carattere e carattere?
• Cosa succede se la rete non funziona quando provano a fare l'invio?
• Che cosa succede se il pulsante è un'immagine dal CDN e il CDN non funziona, funzionerà ancora?
• Com'è formattato il POST, sta usando il nuovo tipo PATCH ed è quello accettato sul server?

Penso che il problema qui sia che stai confondendo un particolare sottoinsieme di test "unit test" con il set di test molto più ampio generalmente accettato come "testing".

Il test delle unità viene generalmente eseguito dal team di programmazione. Potrebbe essere manuale, ma molto spesso utilizza un framework di test automatizzato come Junit.

In generale, il team di test non si preoccupa dei test unitari, il cui unico compito è quello di verificare se il sistema funziona secondo le specifiche. Non hanno bisogno di sapere come è stato costruito, quali strutture linguistiche sono state usate etc. etc. per stabilire se funziona o meno.

I test oltre ai test delle unità si dividono in diverse categorie:

• Test del fumo: avvia il sistema e verifica se può rimanere attivo per un giorno, quindi
• Test funzionali: il programma fa ciò che dice la specifica.
• Test di integrazione - il programma funziona bene con gli altri componenti nell'ambiente più grande.
• Requisiti non funzionali - il programma soddisfa qualsiasi NFR nelle specifiche (tempi di risposta, velocità effettiva, requisiti hardware, impronte di memoria ecc.)
• Test di accettazione degli utenti: fai in modo che gli utenti reali lo usino, confermi che il sistema è utilizzabile e fa ciò che gli sponsor aziendali vogliono davvero.

È quasi impossibile scrivere codice senza introdurre bug. Peggio ancora, è quasi impossibile specificare correttamente un modulo.

Quindi, a meno che il tuo nome non sia "Bill Joy", introduci bug quando esegui il codice. Anche se si codifica precisamente per specificare il modulo finito, si può ancora sbagliare.

Tutti i bravi programmatori che conosco ritengono che i programmi siano pieni di bug non chiazzati, e sanno che i cuori che sanno importa quanto siano attenti avranno fatto qualcosa di sbagliato. I casi limite possono essere un incubo da codificare correttamente (se un ciclo viene eseguito n volte o n - 1 volta). Le specifiche di interfaccia possono essere complete e ambigue; leggi i documenti ma in realtà non sai che cosa accadrà quando chiami l'API.

Il test è fondamentale per il processo di sviluppo del software, se il 50% del tempo del progetto non è dedicato al testing di vari tipi, quindi il codice fallirà subito dopo la distribuzione. I fallimenti potrebbero essere banali, potrebbero essere profondamente imbarazzanti o, potrebbero essere disastrosi.

Quindi impara ad amare i tuoi tester! Rallegrati quando trovano un bug, ti hanno appena salvato il culo!