Resuscitare un piano di test di 5.000 linee che ha dieci anni

Da ciò che scrivi, sembra un elenco di casi di test per test di integrazione manuale / test della GUI. Potrebbe non essere efficiente, ma qualsiasi test è migliore di nessun test e qualsiasi piano è migliore di nessun piano, quindi potresti anche iniziare con quello che hai.

Certamente dovresti rivedere il piano e aggiornarlo per coprire le modifiche apportate al software nel tempo. Ovviamente disporre di test test obsoleti per funzionalità inesistenti sarebbe controproducente.

Tieni presente che anche se questo piano di test è stato scritto pensando ai test manuali, potresti anche automatizzare il processo. Ricerca strumenti di test automatizzati disponibili per il tuo progetto / piattaforma. Se si tratta di un'applicazione web, guarda in selenio. Esistono anche soluzioni per le applicazioni desktop, ma non ho familiarità con nessuno per dare un suggerimento. Anche se può essere un compito che richiede molto tempo, automatizzando questi test, potrebbe risultare più semplice introdurre i test unitari. Potresti anche trovare utile avere questi test automatici quando sei in giro per refactoring del progetto, dato che puoi usarli per convalidare le tue modifiche mentre aggiungi i test unitari.

Poiché il test ha 10 anni e si parla di "messaggio Z visualizzato", chiamerei questo test di regressione dell'interfaccia utente - test per verificare che le modifiche recenti non abbiano interrotto la funzionalità dell'interfaccia utente precedente.

L'unico modo per scoprire se il test è ancora utile è fare del tuo meglio per testarlo! Il test dell'interfaccia automatica (non utente) è sempre una vittoria e Selenium è molto nitido, ma lo sforzo per mantenere qualsiasi test UI automatizzato è spesso uguale o maggiore dello sforzo richiesto per testare manualmente ogni release. Il vantaggio del test manuale è che (in teoria) puoi tollerare le modifiche dell'interfaccia utente su uno schermo con funzionalità invariata. In effetti, questo è esattamente ciò che vuoi testare nell'interfaccia utente e esattamente ciò che rende i test automatici i falsi positivi.

Trovo che la parte più difficile della scrittura di un test dell'interfaccia utente sia ottenere la giusta quantità di dettagli in modo che i tester rimangano attenti alle esperienze che un utente avrebbe con il sistema invece di concentrarsi così tanto sui dettagli del piano di test che gli mancano gli errori. Non ho ancora chiuso questa domanda, ma il senso che sto ottenendo è che potrebbe essere utile avere un test del selenio oltre a un test dell'interfaccia utente manuale. In modo che i dettagli siano testati da Selenium e l'esperienza complessiva è ancora testata da esseri umani che possono testarlo meglio senza essere impantanati da un piano di test troppo dettagliato.

Ogni tipo di test dell'interfaccia utente ha i suoi problemi. Non c'è sostituto per una persona interessata che vuole davvero trovare bug.

Questo assomiglia molto ai test di sistema che usavamo circa quindici anni fa. La maggior parte di quelli che usavamo non poteva essere automatizzati, perché avevano precondizioni come la configurazione di hardware specifico (questo era per gli switch di telecomunicazione) o avevano passaggi di prova come "mentre i dati sono trasferiti, applica un'onda quadra di 100mV segnale alla linea TxD e spazzare ripetutamente la frequenza da 50 a 120 Hz ".

Ti consigliamo di automatizzare il più possibile, ma non aspettarti di eliminare tutto sul piano di test. Un certo grado di test manuale dovrebbe essere fatto per qualsiasi sistema interattivo.

È ancora possibile utilizzare quel file per testare e ci sono vantaggi del test umano della parte dell'interfaccia utente dell'applicazione. Tuttavia, si può anche considerare la parte di automazione in cui si hanno scelte di coppia.

Guarderei test di input / output di file o test di oggetti alternativi , se è difficile (anche se non possibile) aggiungere test di unità al progetto ereditato. Fondamentalmente, è necessario preparare file / oggetti di test di input per alimentare il programma e confrontare l'output con quello che ha previsto i risultati. Questo meccanismo di corrispondenza potrebbe aiutare a scoprirli.

È possibile utilizzare la struttura esistente dei test per creare file o oggetti di input / output. Inoltre, poiché questo codice è vecchio di 1 anno, vorrei ricontrollare questi test con analista aziendale o l'esperto in materia per verificare i test e coprire tutti i processi aziendali importanti che l'applicazione deve fornire.

Anche se potrebbe sembrare non il miglior modo di automazione, ma è ampiamente utilizzato nei vecchi sistemi di fatturazione medica.

Questo potrebbe essere chiamato un test di "Accettazione". Se impone ciò che il programma deve fare per essere considerato "completo", allora lo chiamerei un test di "accettazione". Dipende da quando questo test si verifica nel ciclo di sviluppo sul nome che viene chiamato.