Test ad hoc
Cos'è il test ad hoc?
Quando un test del software viene eseguito senza un'adeguata pianificazione e documentazione, si dice che sia test ad hoc. Questo tipo di test viene eseguito solo una volta a meno che non scopriamo i difetti.
I test ad hoc vengono eseguiti dopo l'esecuzione del test formale sull'applicazione. I metodi ad hoc sono il tipo di test meno formale in quanto NON è un approccio strutturato. Pertanto, i difetti rilevati utilizzando questo metodo sono difficili da replicare in quanto non ci sono casi di test allineati per quegli scenari.
Il test viene eseguito con la conoscenza del tester sull'applicazione e il tester esegue i test in modo casuale senza seguire le specifiche / requisiti. Quindi il successo del test Adhoc dipende dalla capacità del tester, che esegue il test. Il tester deve trovare i difetti senza un'adeguata pianificazione e documentazione, basata esclusivamente sull'intuizione del tester.
Quando eseguire i test ad hoc?
È possibile eseguire test ad hoc quando il tempo è limitato per eseguire test esaustivi e di solito vengono eseguiti dopo l'esecuzione del test formale. I test ad hoc saranno efficaci solo se il tester ha una conoscenza approfondita del sistema sottoposto a test.
Forme di test ad hoc:
Buddy Testing: Due amici, uno del team di sviluppo e uno del team di test, lavorano reciprocamente per identificare i difetti nello stesso modulo. Buddy testing aiuta i tester a sviluppare casi di test migliori mentre il team di sviluppo può anche apportare modifiche al progetto in anticipo. Questo tipo di test si verifica in genere dopo aver completato lo unit test.
Pair Testing: A due tester vengono assegnati gli stessi moduli e condividono idee e lavorano sugli stessi sistemi per trovare i difetti. Un tester esegue i test mentre un altro tester registra le note sui risultati.
Monkey Testing: Il test viene eseguito in modo casuale senza casi di test per interrompere il sistema.
Vari modi per rendere i test ad hoc più efficaci
Preparation: Ottenendo i dettagli sui difetti di un'applicazione simile, la probabilità di trovare difetti nell'applicazione è maggiore.
Creating a Rough Idea: Creando un'idea approssimativa sul posto, il tester avrà un approccio mirato. NON è necessario documentare un piano dettagliato su cosa testare e come testare.
Divide and Rule: Testando l'applicazione parte per parte, avremo una migliore focalizzazione e una migliore comprensione degli eventuali problemi.
Targeting Critical Functionalities: Un tester dovrebbe indirizzare le aree che NON sono coperte durante la progettazione dei casi di test.
Using Tools: I difetti possono anche essere portati alla luce utilizzando profiler, debugger e persino monitor di attività. Quindi, essendo abili nell'uso di questi strumenti, è possibile scoprire diversi difetti.
Documenting the findings:Sebbene il test venga eseguito in modo casuale, è meglio documentare i test se il tempo lo consente e annotare le eventuali deviazioni. Se vengono rilevati difetti, vengono creati casi di test corrispondenti in modo che aiuti i tester a ripetere il test dello scenario.