what are iq oq pq 3 q s software validation process
Introduzione a IQ-OQ-PQ:
IQ, OQ e PQ costituiscono le 3Q del processo di convalida del software.
Come tester sappiamo tutti che il team di sviluppo software sviluppa il software internamente secondo la specifica dei requisiti software (SRS), la specifica funzionale e successivamente il team di test verifica l'implementazione a diversi livelli di test in vari ambienti di test, dal più semplice al più fascia alta, che replica così l'ambiente di produzione.
Con questo approccio di SDLC, il team di sviluppo software generalmente si lava via le mani consegnando il software completo (sviluppato e verificato) al team operativo. Inoltre, è il team operativo (generalmente denominato Ops Team) che si occupa di distribuirlo in un ambiente di produzione e renderlo pronto per essere utilizzato dagli utenti finali.
Ora, qui sta la vera sfida per il Team Operativo di rendere il software funzionale sull'ambiente di produzione, perché durante le fasi di sviluppo del software, lo sviluppo e la verifica è stato fatto in un ambiente simulato, e molto raramente vicino all'ambiente live, solo in caso di disponibilità di dati e configurazioni dell'ambiente di produzione.
È qui che entra in gioco la convalida del software. Una volta che la verifica è stata completata e il software è stato firmato dal team Programma / Prodotto, il Team Ops svolgerà una serie di attività prima di accettare il software da distribuire alla produzione, per dimostrare che il software si sta comportando come previsto, il che non è altro che le attività di convalida.
Cosa imparerai:
Verifica vs convalida
Qui vediamo chiaramente la differenza tra le attività di 'Verifica' e 'Convalida'. ' Verifica 'È valutare il software rispetto al dato insieme di requisiti e specifiche che viene fatto internamente nel sito di sviluppo del software dagli sviluppatori e dai tester.
Mentre ' Validazione 'È un insieme di controlli di garanzia della qualità che vengono eseguiti dai clienti esterni, proprietari, fornitori sul prodotto che viene loro consegnato, per verificarne l'idoneità prima di accettare o acquistare il prodotto. Le attività di validazione sono prevalentemente svolte presso il sito produttivo.
Quindi, in caso di Sviluppo Applicazioni, è il Team Ops che sta svolgendo le attività di Validazione del software.
Leggi anche:
https://www.softwaretestinghelp.com/difference-between-verification-vs-validation/
Fasi del processo di convalida
In generale, il processo di convalida di qualsiasi prodotto si riferisce al ciclo di vita completo di un prodotto dallo sviluppo all'uso e alla manutenzione. E quindi il processo di convalida è suddiviso in 5 fasi.
Le 5 fasi del processo di convalida sono:
Questo approccio in 5 fasi del processo di convalida viene seguito in molti settori come quello manifatturiero, medico, farmaceutico, ecc. Qui la convalida verrà eseguita dal cliente finale prima di acquistare i macchinari, le attrezzature o il prodotto.
Gli elementi costitutivi delle attività di convalida di un software sono dimostrare che 'il software è pronto per il consumo da parte degli utenti' e principalmente verificare la corretta installazione del software seguita dalla funzionalità e operabilità.
Approccio 3Q: IQ-OQ-PQ
Tuttavia, nel contesto del software, il Approccio 3Q, IQ-OQ-PQ è seguito come parte della convalida e sarà eseguito dal team operativo, che è in ultima analisi responsabile della distribuzione del software alla produzione.
Di seguito è riportato il diagramma di flusso del processo di convalida:
Il modello, il piano e qualsiasi altro documento che viene fornito per eseguire le 3Q, sarà stabilito dal Team del software per il loro software e include l'approccio dettagliato, i compiti / attività / test da condurre come parte di queste qualifiche insieme con i risultati del test.
I rapporti di riepilogo verranno consegnati al team operativo durante la consegna del software insieme ai file binari e ad altri risultati finali.
Ad alto livello,
Nel complesso, lo scopo di eseguire IQ, OQ e PQ è garantire che il software possa essere distribuito con successo e tutte le funzionalità possano essere utilizzate senza colli di bottiglia.
Idealmente, IQ, OQ e PQ sono le attività sequenziali, che devono essere eseguite nell'ordine. A meno che non venga eseguita l'installazione, una funzionalità del software non può essere verificata e, a meno che la funzionalità non sia provata, non ha senso misurare le prestazioni. A volte a causa del vincolo di tempo, la PQ può iniziare parallelamente alla OQ, una volta stabiliti gli aspetti chiave della OQ.
Ora, cerchiamo di capire di più su ciascuna di queste 3 fasi in dettaglio.
Qualificazione dell'installazione (IQ)
Qualificazione dell'installazione indicata anche come 'QI' , è il processo di convalida se il software fornito (binari, script, ecc.) può essere installato con successo nell'ambiente specificato con le configurazioni specificate e per verificare come questi passaggi di installazione sono registrati nel documento chiamato 'Guida all'installazione'.
I seguenti elementi vengono forniti dal team di sviluppo insieme al pacchetto software consegnato e vengono utilizzati dal team operativo per eseguire il QI.
1) Documento 'Guida all'installazione', che documenta le fasi di installazione negli ambienti selezionati.
Due) Documento 'Guida alla configurazione' per impostare la configurazione del software. A volte questo documento diventa parte del documento stesso della Guida all'installazione.
3) Pacchetto software e script di installazione, preferibilmente script automatici.
La fase di qualificazione dell'installazione del software è considerata la più cruciale e in genere molti problemi Aperto durante questa fase.
Perché:
per) L'ambiente di sviluppo non avrà un ambiente in tempo reale al 100% disponibile per verificare i problemi di installazione e quindi una differenza nell'ambiente contribuisce a diversi problemi.
b) A causa di vari motivi, potrebbe non esserci una collaborazione e un coordinamento sufficienti tra lo sviluppo e il team operativo durante le fasi iniziali dello sviluppo del software per gestire i problemi con largo anticipo.
c) Potrebbero verificarsi alcuni problemi di documentazione durante la registrazione dei passaggi di installazione effettivi nel documento, che potrebbero non corrispondere esattamente nell'ambiente di produzione.
In questi giorni, l'intera procedura di installazione del software sarà automatizzata il più possibile tramite una serie di script. In caso di problemi con l'installazione, l'installazione automatica non riesce a causa di una mancata corrispondenza nelle configurazioni e sono necessari un intervento manuale per risolvere tali problemi.
Poiché il team operativo esegue il QI seguendo rigorosamente le istruzioni fornite dal team del software nella Guida all'installazione, è molto importante e anche responsabilità del team del software assicurarsi che la 'Guida all'installazione' sia scritta in modo tale che le fasi di installazione corrispondono all'ambiente in tempo reale.
Ed è responsabilità dei tester garantire che il processo di 'installazione' sia verificato internamente insieme alla verifica del documento per la sua completezza e identificare eventuali mancate corrispondenze con i passaggi effettivi da eseguire sul sistema rispetto ai passaggi documentati nel Guida d'installazione.
I seguenti punti devono essere tenuti presenti durante la scrittura di una Guida all'installazione e la verifica interna, al fine di ridurre al minimo i problemi durante l'installazione del software in produzione.
| SNO | Punti della guida all'installazione |
|---|---|
| 7 | Il tempo tipico impiegato per installare il software deve essere menzionato nella Guida all'installazione affinché il team operativo abbia un'idea dei tempi approssimativi di installazione per pianificare le proprie attività di conseguenza. |
| 1 | Essenziale e fondamentale, la 'Guida all'installazione' deve essere scritta in un linguaggio semplice e facile da seguire. |
| Due | È necessario assicurarsi che non si esaurisca in lunghe, più di 5 pagine. Dovrebbe essere breve e pulito. |
| 3 | È necessario fornire i numeri di serie per ogni fase di esecuzione al fine di monitorarne lo stato. |
| 4 | Automatizza i passaggi il più possibile e raggruppali tutti in un unico script. |
| 5 | Un modello standard dovrebbe essere utilizzato per scrivere la procedura di installazione. |
| 6 | I prerequisiti dovrebbero essere chiaramente menzionati per evitare la mancata corrispondenza e devono essere forniti i passaggi per verificarli. In caso di mancata corrispondenza, dovrebbero essere fornite le istruzioni per portarli al livello previsto o per installare quei pacchetti. |
| 8 | I servizi che devono essere disattivati durante l'installazione, come disattivarli, l'impatto dell'abbattimento devono essere chiaramente menzionati nella guida. |
| 9 | Si dovrebbe evitare di fornire collegamenti ad altri documenti e di passare da un documento all'altro. Ogni informazione necessaria dovrebbe essere resa disponibile nello stesso documento. Se è necessario riferire documenti aggiuntivi, fornirli insieme al pacchetto software e, a loro volta, farli riferimento nei documenti principali. |
| 10 | È necessario assicurarsi che il nome dello script menzionato nel documento sia lo stesso di quello impacchettato insieme al binario. |
| undici | Dovrebbe assicurarsi che tutti gli script a cui si fa riferimento nel documento della Guida all'installazione siano forniti insieme al file binario. |
| 12 | Assicurarsi che tutti i parametri di configurazione siano chiaramente menzionati nella Guida all'installazione / Guida alla configurazione insieme ai valori predefiniti e ad altri valori supportati. |
| 13 | Dovrebbero essere forniti test automatizzati per eseguire i test di verifica della build dopo che l'installazione del software è stata completata. Devono essere in numero minimo e importanti per verificare che la build sia stata installata correttamente. |
| 14 | È necessario fornire i 'test di fumo' per garantire che la connettività end-to-end del sistema sia perfetta e che tutti i componenti del sistema stiano parlando tra loro come previsto. |
| quindici | In caso di fallimento dell'installazione del software, gli script di rollback vengono forniti insieme al pacchetto e la procedura di rollback è chiaramente scritta nella Guida all'installazione per eseguire il rollback e ripristinare il sistema con successo. |
Con tutti i punti di cui sopra da prendere in considerazione, è una buona pratica automatizzare il processo di installazione del software con il minimo intervento umano per evitare errori umani.
Se vengono rilevati problemi durante la fase di convalida del QI, verranno segnalati al team del software, dopo averli risolti, il test del fumo e costruire test di verifica verrà effettuato per verificare il buon esito dell'installazione del software.
Quindi la fase IQ include l'installazione del pacchetto software seguita dalla conduzione della verifica della build e dei test del fumo.
Quindi, il completamento con successo della fase IQ è molto importante poiché un'installazione corretta e corretta di un software garantisce che la maggior parte dei problemi relativi ai guasti di funzionalità vengano annullati.
Qualificazione operativa (OQ)
Qualifica operativa, chiamata anche come CHE COSA è l'attività successiva del processo di convalida del software dopo il completamento con successo di IQ.
L'attività di qualificazione operativa comprende t i test da eseguire per verificare che il software sia operativamente idoneo per essere distribuito ai consumatori. Idealmente, le funzionalità chiave del software vengono verificate come parte di questo processo di convalida.
Un piano OQ per eseguire la convalida OQ deve essere preparato dal team software (tester) che dovrebbe coprire tutti gli aspetti del test OQ che deve essere eseguito, inclusi i dettagli come il n. di test, pianificazione dei test, metodologia, strumenti, impatto sul servizio, sequenza di esecuzione dei test, metodo di segnalazione dei problemi e SLA per risolverli, approccio Triage dei difetti ecc.,
I test di qualificazione operativa eseguiti come parte di OQ, vengono nuovamente forniti dal team del software insieme ai risultati del software. Questi test di qualificazione operativa sono una raccolta di test importanti progettati sulla base del documento 'Specifiche dei requisiti funzionali' per garantire che l'intero sistema software funzioni secondo le aspettative.
Questo documento di specifica del test OQ è preparato dagli ingegneri del test in base al documento di specifica dei requisiti funzionali. Spesso questo documento sarà il sottoinsieme del documento di specifica del test di sistema preparato e verificato durante la fase di test del sistema dell'SDLC.
I test possono essere modificati o aggiornati per soddisfare i requisiti del team operativo e le condizioni del sito in cui verranno eseguiti.
Pertanto, è necessario prestare ulteriore attenzione durante la selezione dei test che fanno parte dell'OQ per garantire che tutte le funzionalità chiave e i principali flussi di lavoro aziendali siano inclusi come parte di questa verifica.
Di seguito sono riportati i suggerimenti per i tester durante la preparazione del documento con le specifiche del test OQ.
| Sno | Suggerimenti per i tester durante la preparazione del documento di specifica del test OQ |
|---|---|
| 7 | I casi di test relativi al valore limite non devono essere inclusi, il che verifica i valori estremi, ma utilizza i valori più comuni utilizzati quotidianamente come input, ove richiesto. |
| 1 | Assicurarsi che i test di funzionalità chiave per dimostrare che le funzioni del software come previsto siano scelte e incluse e quindi la tracciabilità necessaria per ciascuno dei casi di test scritti sia disponibile nel documento OQ Test Spec. |
| Due | Assicurati che i test siano scritti in modo ordinato con azioni passo passo, siano autoesplicativi e possano essere compresi da un uomo comune. |
| 3 | Non fare riferimento o evitare l'uso di termini tecnici nei casi di test il più possibile, poiché l'utente di questo documento potrebbe non essere a conoscenza di tali terminologie e che i dati di test utilizzati non esistono già sul sistema. Fornire più set di dati, nel caso in cui l'utente desideri eseguire i casi di test più di una volta. |
| 4 | Indicare chiaramente i prerequisiti obbligatori e facoltativi per ciascuna delle prove. |
| 5 | Includere la maggior parte dei casi di test positivi per verificare la funzionalità. |
| 6 | Includere pochissimi casi di test negativi per garantire che il comportamento del software sia quello previsto in caso di input irrilevante e che il sistema sia in grado di gestire i casi negativi con successo. |
| 8 | Indicare i valori di configurazione da impostare, se necessario modificarli rispetto ai valori di default. |
| 9 | Fornire i casi di test automatizzati da eseguire, ove disponibili. Assicurarsi prima di tutto che quegli script di automazione possano essere eseguiti sul sistema in cui si sta pianificando l'OQ. |
| 10 | Assicurati che ogni caso di test abbia i risultati chiari 'Attesi' e 'Effettivi' come riferimento. E aggiungi eventuali commenti, se necessario, per spiegare il risultato effettivo. |
| undici | È inoltre necessario includere i 'Criteri di accettazione' per ciascuno dei casi di test. I criteri di accettazione potrebbero essere lo stato del sistema dopo l'esecuzione dei casi di test. |
| 12 | Fornire i 'dati del test' da utilizzare per ciascuno dei test in modo accurato. Prova a fornire i dati più comuni dal vivo. E anche pochi dati eccezionali, per garantire che il sistema possa gestire anche i casi eccezionali. Verificare che i dati di test utilizzati non siano già presenti nel sistema. Fornire più set di dati, nel caso in cui l'utente desideri eseguire i casi di test più di una volta. |
| 13 | Se più utenti operativi eseguono i test da diverse posizioni in parallelo, fornire le istruzioni per eseguire i test di conseguenza con diversi set di dati. |
| 14 | Fornire elenchi di controllo ove necessario per garantire che tutte le configurazioni, i prerequisiti siano impostati come previsto prima di eseguire i test. |
| quindici | Continua a monitorare i log, quando i test sono in esecuzione, se l'accesso è disponibile per il sistema. |
| 16 | Se possibile e richiesto, fornire un supporto per l'esecuzione agli utenti operativi durante l'esecuzione di questi casi di test. |
| 17 | Spiegare il metodo di segnalazione dei problemi rilevati durante l'esecuzione. È meglio utilizzare lo strumento di tracciamento dei bug per tenere traccia dei problemi. Monitora attentamente ogni problema e portalo alla chiusura secondo gli SLA concordati. |
| 18 | Esegui 'Triage dei difetti' coinvolgendo i soggetti interessati dei diritti per comprendere i problemi critici e gravi e fornire frequentemente aggiornamenti su tali problemi. |
| 19 | Fornire il modello finale del 'Rapporto di riepilogo dell'esecuzione del test OQ' per pubblicare i risultati finali dopo il completamento dell'esecuzione. |
Pertanto, il Piano OQ e la Specifica di prova così preparati dovrebbero essere accuratamente esaminati e approvati dalle parti interessate per garantire principalmente che la copertura non sia troppo o troppo bassa e tutte le funzionalità chiave siano coperte.
Il completamento con successo di OQ dimostra che il software funzionerà secondo le sue specifiche operative nell'ambiente selezionato ed è la fase di passaggio del software verso la sua produzione ed è il segnale per andare avanti con l'attività successiva del processo di convalida che è PQ .
Qualificazione delle prestazioni (PQ)
Dopo aver assicurato un IQ di successo, il completamento OQ l'attività successiva nel processo di convalida è garantire che il prodotto / software soddisfi gli aspetti prestazionali specificati sotto il carico previsto in modo coerente senza causare alcun collo di bottiglia nell'ambiente di produzione.
L'aspetto chiave di PQ è garantire che un software, una volta installato sul sistema previsto, può gestire il carico in tempo reale e rispettare il tempo di risposta previsto e non si blocca sotto i picchi di carico e di stress durante la gestione di utenti simultanei.
Quindi PQ serve principalmente a garantire se i criteri di prestazione specificati per un software vengono raggiunti in un periodo di tempo (forse una settimana) su base affidabile con condizioni di carico variabili, come è il modello dal vivo. Quindi questi test devono essere eseguiti ogni giorno per monitorare il comportamento del sistema software e quindi il completamento di PQ richiederà un po 'di tempo finché non sarà garantito che il sistema sia dimostrato per le sue prestazioni.
Idealmente, la convalida PQ viene eseguita dopo il completamento dell'OQ, in cui viene garantita la funzionalità del software e può procedere con la verifica dell'aspetto delle prestazioni del prodotto o del software. A volte a causa di vincoli di tempo, la PQ può iniziare parallelamente all'OQ, in base alla confidenza sulla percentuale di completamento OQ.
È l'ideale per eseguire questi test delle prestazioni sul sistema live con il sistema a pieno carico o in condizioni simili a live e assicurarsi che non ci siano colli di bottiglia sugli aspetti prestazionali.
I seguenti test vengono generalmente eseguiti come parte della qualificazione delle prestazioni. E la scelta dei test varia da software a software.
# 1) Test di disponibilità: Per garantire che il software sia sempre disponibile senza crash o interruzioni.
# 2) Test di accessibilità: Per garantire che il software sia facilmente accessibile da ogni posizione con la velocità delle prestazioni prevista senza problemi.
# 3) Test di carico: Per misurare il comportamento del sistema sotto il carico giornaliero previsto e anche le condizioni di carico di punta.
# 4) Stress Test: Per misurare il punto di interruzione del sistema in condizioni di carico estreme.
# 5) Test delle prestazioni di throughput: Per misurare il tempo di risposta del sistema e per misurare TPS (transazioni al secondo)
# 6) Test di scalabilità: Il sistema può scalare per gestire gli utenti simultanei previsti.
Gli scenari di test delle prestazioni e gli script automatizzati corrispondenti vengono preparati in base ai requisiti relativi alle prestazioni specificati nei documenti 'Specifiche dei requisiti dell'utente'.
Analogamente a un piano OQ, un piano PQ dettagliato che dichiari chiaramente l'approccio, la strategia, il piano e il programma del test insieme agli strumenti, dovrebbe essere preparato ed eseguito con gli esecutori PQ.
Lo strumento di test e monitoraggio delle prestazioni deve essere installato nell'ambiente in cui viene eseguito il PQ per misurare e segnalare le metriche delle prestazioni.
Di seguito sono riportati i suggerimenti per i tester per consentire al team operativo di eseguire con successo il PQ.
| Sno | Suggerimenti per i tester per abilitare il team operativo |
|---|---|
| 7 | Guida, supporta e forma il team operativo per eseguire il test delle prestazioni del sistema. |
| 1 | Preparare i principali scenari aziendali specifici per eseguire i test delle prestazioni basati sull'URS. |
| Due | Assicurarsi che siano inclusi test per dimostrare che il sistema soddisfa le aspettative di tempo di risposta, velocità, scalabilità e stabilità in varie condizioni di carico. |
| 3 | Assicurarsi che sia disponibile il carico specificato o che il metodo e gli strumenti per generare il carico richiesto siano chiaramente menzionati nei rispettivi casi di test. |
| 4 | Indicare chiaramente i prerequisiti per ciascuno scenario, come le condizioni di precarico che dovrebbero esistere sul sistema, il numero di utenti simultanei ecc. |
| 5 | Strumenti di menzione consigliati da utilizzare per eseguire il test delle prestazioni specifico per ciascuna categoria di test e per ogni test. |
| 6 | Assicurarsi che il processo per monitorare le metriche delle prestazioni sia menzionato chiaramente. |
Dopo aver completato con successo il PQ, soddisfare i requisiti di prestazione è molto importante in quanto qualsiasi deviazione relativa alle prestazioni può causare un'enorme perdita di business creando disagio per l'utente e la fiducia nel software da utilizzare andrà persa portando al fallimento del software.
In poche parole, t La tabella sottostante riassume le attività IQ-OQ-PQ.
| IQ | CHE COSA | PQ | |
|---|---|---|---|
| Che cosa | Per verificare il processo di installazione del software e come viene documentato il processo | Per verificare il corretto funzionamento del sistema | Clienti, proprietari, fornitori, team operativo |
| Oms | Clienti, proprietari, fornitori, team operativo | Clienti, proprietari, fornitori, team operativo | Clienti, proprietari, fornitori, team operativo |
| Dove | Presso il sito dei proprietari, l'ubicazione del team operativo, il sito live, l'ambiente simile al prodotto | Presso il sito del proprietario, l'ubicazione del team operativo, il sito live, l'ambiente simile al prodotto | Presso il sito del proprietario, l'ubicazione del team operativo, il sito live, l'ambiente simile al prodotto |
| quando | Quando il software viene ricevuto dal team del software, prima di OQ e PQ. | Prima di rilasciare il sistema per l'uso e dopo aver completato con successo il QI | Prima di mettere in funzione il sistema e dopo aver completato con successo IQ, OQ |
La tabella seguente spiega i vari input per ciascuna delle fasi di convalida.
| genere | Ingresso |
|---|---|
| IQ | 1. Documento delle specifiche di progetto 2. Binari del software e altri script di installazione 3. Documento Guida all'installazione 4. Documento guida alla configurazione 5. Crea documento di verifica e test del fumo |
| CHE COSA | 1. Documento delle specifiche funzionali 2. Documento del piano OQ 3. Documento di prova di qualificazione operativa 4. Modello di rapporto di riepilogo del test OQ 5. IQ completato con successo |
| PQ | 1. Documento URS (User Requirement Specification) 2. Documento Piano PQ 3. Documento di prova di qualificazione delle prestazioni 4. Modello di rapporto di riepilogo del test PQ 5. IQ e OQ sono stati completati con successo |
Conclusione
Anche se il prodotto / software ha superato tutte le fasi di verifica e non riesce a dimostrare nessuno di IQ-OQ-PQ, il risultato può essere disastroso e comporterà un costo enorme. Quindi il completamento con successo di IQ-OQ-PQ da solo è il trasferimento con successo del prodotto dal sito di sviluppo al sito di produzione.
Nel complesso, il completamento con successo del processo di convalida IQ-OQ-PQ non solo dà fiducia nel software, ma offre anche tranquillità al cliente, al proprietario, agli sviluppatori di software e ai tester.
quali dispositivi funzionano allo strato di osi 2
L'esecuzione di IQ-OQ-PQ riduce anche il rischio di implementarlo per vivere, senza eseguire test e riduce il costo del guasto e mitiga il rischio di richiamo dei prodotti.
Quindi, ragazzi, sviluppatori di software e tester, nessuna celebrazione dopo aver completato lo sviluppo e il test internamente e aver rilasciato il software al team operativo. La celebrazione è solo quando completa con successo IQ-OQ-PQ e il software è attivo sul sistema mirato.
Quindi il successo di un software dipende dal completamento con successo di IQ-OQ-PQ e quando il software è attivo e pronto per il consumo da parte degli utenti finali.
Circa l'autore: Questo articolo è stato scritto da un membro del team STHGayathri Subrahmanyam. Ha più di 2 decenni di esperienza nel campo del test del software. Durante la sua carriera di test, ha svolto molte valutazioni TMMI, lavori di industrializzazione di test, configurazioni TCOE oltre a gestire consegne di test e implementato pratiche DevOps per un enorme impegno. Ma secondo lei, l'apprendimento non si ferma mai ...
Condividi le tue esperienze sull'esecuzione del processo di convalida e facci sapere se hai domande su questo articolo.
Lettura consigliata
- Corso di test del software: quale istituto di test del software dovrei iscrivermi?
- Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
- Lavoro assistente QA test software
- Scegliere il test del software come carriera
- Lavoro freelance di scrittore di contenuti tecnici di test del software
- Alcune interessanti domande di intervista sul test del software
- Feedback e recensioni sul corso di test del software
- Software Testing Help Affiliate Program!