Il QA dovrebbe essere testato da una prospettiva rigorosamente black-box?

Question

Supponendo che i test unitari vengano gestiti dallo sviluppo, c'è qualche motivo per il QA di conoscere i dettagli di come funziona un prodotto? Voglio dire, devono sapere cosa sta succedendo in background e dovrebbero testare segmenti di un prodotto senza usare la normale interfaccia utente? Ad esempio, sarebbe logico che un tester entrasse in un database e modificasse manualmente i valori per vedere cosa accadrà?

MODIFICARE:
Supponiamo che stiamo lavorando con un'applicazione che deve essere utilizzata da non sviluppatori, non stiamo lavorando a qualcosa con un'API collegata.

Answer 1

Dipende dall'approccio e dal tipo di software che stai scrivendo. Esistono diversi tipi di QA. Se il software deve essere tollerante ai guasti, il controllo qualità dovrebbe simulare i guasti. Inoltre, sapere come funziona un prodotto può aiutare il QA a pensare a casi potenzialmente problematici e testarli in modo più approfondito.

D'altra parte, sapere come funziona un prodotto potrebbe impedire al QA di testare completamente dal punto di vista dell'utente. Quindi forse prima i test di base dovrebbero essere progettati senza conoscere gli interni, quindi test più approfonditi basati su potenziali problemi.

Answer 2

Sicuramente dipende dall'architettura. Ho lavorato a un progetto in cui il livello db è stato sviluppato, gestito e testato da un team completamente separato in un altro edificio. Il loro QA si è sicuramente confuso con i dati per vedere se le procedure, le query e simili sono state eseguite in una serie di condizioni di test.

Se sei alla fine dell'interfaccia utente, ci sono due livelli, uno è un semplice test funzionale per il quale il QA non ha bisogno di alcuna conoscenza pratica dell'applicazione (e tutto ciò dovrebbe essere probabilmente automatizzato) e poi c'è il QA che dice se l'app fa quello che dovrebbe fare. Per il secondo tipo, aiuta davvero se il team addetto al controllo qualità sa come funziona. Risparmia molto tempo nel rifiutare bug stupidi per iniziare, ma soprattutto devono comportarsi come utenti e avere casi d'uso end-to-end che provano alcuni scenari di sovrapposizione più complessi. Per progettare tali test devono avere una buona conoscenza dell'applicazione.

Answer 3

È assolutamente logico che i tester sappiano quanto più possono sull'implementazione del software. Ciò li aiuterà a testare meglio.

Il test black-box è una tecnica utile e necessaria, ma sapere un po 'di ciò che sta accadendo sotto il cofano rende più semplice la definizione di casi di test davvero interessanti.

Il problema di fare affidamento sui test unitari degli sviluppatori per tutte le vostre esigenze di test in white box è che gli sviluppatori, nel complesso, non sono tester molto approfonditi, specialmente quando si tratta di codice che hanno scritto.

Answer 4

Sui progetti in cui sono stato coinvolto, il QA è stato testato dal punto di vista dell'utente e i suoi test erano dal punto di vista dei requisiti richiesti. Il loro test era il test della scatola nera. Gli sviluppatori hanno testato la scatola bianca. Non ci saremmo mai aspettati che un addetto al controllo qualità potesse aprire uno strumento di query DB e modificare manualmente i valori. Questa era la responsabilità dei test unitari dello sviluppatore.

Answer 5

Penso che dipenda dal ruolo che il tuo team addetto al QA svolge in un determinato progetto. Penso che si possa argomentare che le situazioni derivanti da valori specifici presenti nel database dovrebbero essere rappresentate da casi di test e, se possono essere rappresentati in quel modo, gli sviluppatori dovrebbero scrivere (dovrebbero aver scritto) unit test per quelle situazioni .

Se hai anche utilizzato le ispezioni del codice per identificare e correggere i difetti, potrebbe non essere necessario esporre il QA a qualsiasi cosa dietro le quinte. Suppongo che ci siano progetti in cui potrebbe essere utile per loro testare il codice al di fuori dell'esperienza dell'utente, ma probabilmente userò un team di controllo qualità per i test in black box piuttosto che in white box o in chiaro.

Answer 6

Penso che un approccio ibrido funzioni bene. Se si utilizza una combinazione di test in white box (unit test) e test in black box, si ottiene una migliore copertura. Ognuno ha i suoi pro e contro, ma in parte coprono i punti deboli dell'altro.

Comprendere il funzionamento interno del codice ti farà testare in un certo modo, che non è sempre il modo migliore per scoprire alcuni problemi.

Answer 7

Direi che ci sono tutte le ragioni per cui una persona addetta al QA non non abbia una conoscenza approfondita del funzionamento dell'applicazione. Il personale addetto al controllo qualità dovrebbe avere quasi lo stesso livello di competenza informatica del tuo pubblico di destinazione.

La ragione di ciò è semplice: più una persona addetta al controllo qualità sa come è costruita l'applicazione, più è probabile che evitino i normali problemi di usabilità in cui si imbatteranno gli utenti normali.

Il QA non riguarda solo il test del funzionamento dell'applicazione. Dovrebbe anche essere testare se è comprensibile per l'utente medio e quindi effettivamente utilizzabile.

Aggiorna
Stava diventando troppo lungo per essere inserito in una casella di commento.

Per quanto riguarda le domande di @ testerab.

Definisco il QA come la persona o il gruppo responsabile di garantire 1. che i requisiti aziendali siano soddisfatti; e 2. le funzioni dell'applicazione rispetto a tali requisiti sono prive di errori. Da qui il moniker "Quality Assurance". Un terzo elemento che credo appartenga al QA è semplicemente l'usabilità.

Devono avere una comprensione dei requisiti aziendali, il che significa che dovrebbero lavorare di pari passo con gli analisti aziendali e gli utenti finali (se disponibili). I migliori membri del QA con cui ho lavorato sono stati assunti da quelle aree. I peggiori membri del QA che ho visto erano stati sviluppatori o formati come tali. Le persone che sono passate dal supporto tecnico tendono anche a fare buoni membri del controllo qualità poiché sanno esattamente il tipo di immondizia che un utente finale proverà.

Esistono molte diverse classi di applicazioni. Di gran lunga il più comune dei quali è l'inserimento di dati glorificato. Ci sono alcune schermate in cui vengono inserite le informazioni e vengono premuti i pulsanti. Le informazioni vengono quindi archiviate e / o instradate verso qualsiasi destinazione. Tutto, da MS Word a CRM, rientra in questa categoria.

Pertanto, il compito di un addetto al QA è innanzitutto assicurarsi che l'app accetti gli input desiderati ed esegua le funzioni desiderate. Un passaggio secondario consiste nell'inviare input errati e verificare che l'app risponda nel modo desiderato. per esempio. non esplode e non consente il passaggio di informazioni errate. Gli strumenti di test automatizzati funzionano perfettamente in questi casi. Un'ultima parte è decidere se questa funzione debba essere seppellita a tre livelli di menu o è qualcosa che dovrebbe essere più facile da raggiungere.

Nessuna delle precedenti richiede che la persona QA legga il codice o la modifica con i bit.

Alcuni sistemi non hanno un componente UI. Per questi è lo sviluppatore fornire un cablaggio di prova che consentirà a un team di controllo qualità di inviare i dati e rivedere i risultati. Questo riguarda i servizi web e qualsiasi tipo di EDI che tu possa immaginare.

Altri sistemi sono API in sé. Questi richiedono una persona con QA sufficientemente informata per implementare tali chiamate API stesse o che gli sviluppatori possano fornire modi per chiamarle facilmente e registrare i risultati. In questo caso è preferibile che il team addetto al controllo qualità possa fare la propria programmazione ma, ancora una volta, non avere accesso al codice sottostante.

Il problema con la revisione del codice reale è che tende a far sì che una persona si concentri solo su ciò che sta vedendo. Questo non va bene. Invece dovrebbero essere mentalmente liberi da quei limiti artificiali in modo che possano digitare ciecamente "ABC". in una casella di testo che prevede l'immissione numerica.

---

Per quanto riguarda " vedere " il codice per sapere cosa testare, questo è un problema completamente diverso e uno che è meglio risolto da sviluppatori esperti in un'impostazione di revisione del codice. Lo scopo qui è identificare possibili errori, migliori pratiche, guasti alla sicurezza, ecc. Le persone con QA raramente sono in grado di eseguire questo livello di analisi in quanto richiede che qualcuno sia uno sviluppatore attivo.

---

Riguardo agli SDET: se il tuo prodotto ha, o è, un'API o una fondazione che gli sviluppatori usano per costruire altre cose, allora potresti volere una o più persone dedicate all'implementazione del software attorno a esso per supportare il normale gruppo QA. Sono sulla soglia della necessità di questo ruolo e credo che potrebbe essere un progetto per decisione del progetto.

Credo che ci siano due gruppi più qualificati per testare le API. Questi sono gli utenti finali che stanno già implementando e altri sviluppatori dell'azienda che lo hanno creato. Il cibo per cani è ormai una pratica comune ed è molto conveniente. Dopotutto, se non funziona, puoi essere sicuro che verrà risolto rapidamente. Per gli utenti finali, purché lo vedano come una vera conversazione in cui il team di sviluppo è reattivo, saranno felici di "testare". per te.

Sono stato in tutte e tre le situazioni e come utente finale sento di avere accesso agli sviluppatori originali per risolvere i problemi. Soprattutto quando usano anche il prodotto. La quantità di errori di traduzione nei confronti delle persone con QA normalmente associate a questi progetti è semplicemente orribile.

---

In sintesi, ho lavorato con tutti i tipi di addetti al controllo qualità. Da quelli che ti sei chiesto come sono riusciti a guidare a lavorare verso le superstar che erano molto abili nel trovare quei casi angolari che hanno causato il soffocamento delle app.

I tratti dei migliori erano: 1. non erano mai programmatori; 2. capito il business; 3. capito esattamente cosa hanno fatto gli utenti finali su base giornaliera. 4. CURA onestamente di coloro che sono soggetti al software.

Tratti dei peggiori includevano: 1. erano stati programmatori o pensavano che lo fossero; 2. non ha capito il business; 3. non ha mai incontrato un utente finale; 4. ha usato la parola "idiota" troppo spesso; 5. impegnato nella meccanica di come ha funzionato invece che se fosse persino utilizzabile.