Gli ingegneri / tester della qualità del software non si affidano a crawler e spider per testare i loro bug - Non credo che i tecnici / i tester della sicurezza delle applicazioni debbano o ...
Al contrario, gli SQE fanno molto affidamento sui framework di test di sviluppo (o sui cablaggi di test) come Selenium RC / Bromine, Watir / WatiN / Watij, Sahi, HtmlUnit o WebDriver. Alcuni scelgono strumenti QA commerciali di fascia alta come HP QTP, IBM Rational Functional Tester, TestComplete e VisualStudio Tester Edition 2010.
Gli SQE in genere non automatizzano l'esercizio di un'app per il flusso di esecuzione perché:
- I test richiedono una scoperta esplorativa, come farebbe un turista in una nuova città in cui non sono mai stati, per trarre conclusioni e determinare i risultati, soprattutto se in orario (che sono molti tester)
- Concetti come la classificazione di equivalenza possono far risparmiare ore di lavoro ai tester senza dover ripetere gli stessi errori più e più volte. I test di sicurezza sono un po 'diversi in quanto dobbiamo testare tutto, ma certamente non lo facciamo oggi e potremmo utilizzare questa tecnica, specialmente quando il time-boxing
Il problema dell'automazione dei test è che le app cambiano rapidamente e il cablaggio di test deve essere continuamente modificato per tenere il passo con queste modifiche. Nelle metodologie Agile come ICONIX, i test di robustezza sono generati dal codice di modelli di dominio e diagrammi di sequenza (di solito in UML), ma certamente ci sono molti modi per automatizzare la ricostruzione dei casi di test durante il codice churn e nuove build, tuttavia questo più che spesso probabilmente non richiede metaprogrammazione.