Cos’è il test del software? 100+ Tutorial gratuiti sui test manuali

Una guida completa sui test del software con 100+ tutorial sui test manuali con definizione dei test, tipi, metodi e dettagli del processo:

Che cos’è il test del software?

Il test del software è un processo di verifica e validazione della funzionalità di un’applicazione per scoprire se soddisfa i requisiti specificati. È il processo di trovare difetti in un’applicazione e controllare se l’applicazione funziona secondo i requisiti dell’utente finale.

Che cos’è il test manuale?

Il test manuale è un processo in cui si confronta il comportamento di un pezzo di codice sviluppato (software, modulo, API, caratteristica, ecc.) con il comportamento previsto (requisiti).

Lista di tutorial sul test manuale del software

Questa è la serie più approfondita di tutorial sul test del software. Esamina attentamente gli argomenti menzionati in questa serie per imparare le tecniche di test di base e avanzate.

Questa serie di tutorial arricchirà la tua conoscenza e, a sua volta, migliorerà le tue abilità di test.

Pratica di test manuali end-to-end Formazione gratuita su un progetto dal vivo:

Tutorial #1: Fondamenti del test manuale del software
Tutorial #2: Introduzione al progetto dal vivo
Tutorial #3: Scrittura di scenari di test
Tutorial #4: Scrivere un piano di test da zero
Tutorial #5: Scrivere casi di test dal documento SRS
Tutorial #6: Esecuzione del test
Tutorial #7: Monitoraggio dei bug e firma del test
Tutorial #8: Corso di test del software

Ciclo di vita del test del software:

Tutorial #1: STLC

Web Testing:

Tutorial #1: Web Application Testing
Tutorial #2: Cross Browser Testing

Test Case Management:

Tutorial #1: Test Cases
Tutorial #2: Esempio di modello di caso di test
Tutorial #3: Matrice di tracciabilità dei requisiti (RTM)
Tutorial #4: Copertura dei test
Tutorial #5: Gestione dei dati di test

Test Management:

Tutorial #1: Strategia di test
Tutorial #2: Modello di piano di test
Tutorial #3: Stima dei test
Tutorial #4: Strumenti di gestione dei test
Tutorial #5: HP ALM Tutorial
Tutorial #6: Jira
Tutorial #7: TestLink Tutorial

Tecniche di test:

Tutorial #1: Use Case Testing
Tutorial #2: State Transition testing
Tutorial #3: Boundary Value Analysis
Tutorial #4: Equivalence Partitioning
Tutorial #5: Software testing methodologies
Tutorial #6: Agile Methodology

Defect Management:

Tutorial #1: Ciclo di vita dei bug
Tutorial #2: Segnalazione dei bug
Tutorial #3: Priorità dei difetti
Tutorial #4: Bugzilla Tutorial

Test funzionali

Tutorial #1: Unit Testing
Tutorial #2: Sanity e Smoke Testing
Tutorial #3: Regression Testing
Tutorial #4: System Testing
Tutorial #5: Acceptance Testing
Tutorial #6: Integration Testing
Tutorial #7: UAT User Acceptance Testing

Non-Functional Testing:

Tutorial #1: Non-Functional Testing
Tutorial #2: Performance Testing
Tutorial #3: Security Testing
Tutorial #4: Web Application Security Testing
Tutorial #5: Usability Testing
Tutorial #6: Test di compatibilità
Tutorial #7: Test di installazione
Tutorial #8: Test di documentazione

Tipi di test del software:

Tutorial #1: Tipi di test
Tutorial #2: Black box Testing
Tutorial #3: Database Testing
Tutorial #4: End to end Testing
Tutorial #5: Exploratory Testing
Tutorial #6: Incremental Testing
Tutorial #7: Accessibility Testing
Tutorial #8: Negative Testing
Tutorial #9: Backend Testing
Tutorial #10: Alpha Testing
Tutorial #11: Beta Testing
Tutorial #12: Alpha vs Beta Testing
Tutorial #13: Gamma Testing
Tutorial #14: ERP Testing
Tutorial #15: Static and Dynamic Testing
Tutorial #16: Adhoc testing
Tutorial #17: Test di localizzazione e internazionalizzazione
Tutorial #18: Test di automazione
Tutorial #19: White box testing

Carriera nel Software Testing:

Tutorial #1: Scegliere una carriera nel Software Testing
Tutorial #2: Come ottenere un lavoro di QA Testing – Guida completa
Tutorial #3: Opzioni di carriera per tester
Tutorial #4: Passaggio da Non-IT a Software Testing
Tutorial #5: Iniziare la tua carriera nel test manuale
Tutorial #6: Lezioni apprese da 10 anni nel test
Tutorial #7: Sopravvivere e progredire nel campo del test

Preparazione al colloquio:

Tutorial #1: QA Resume Preparation
Tutorial #2: Domande per l’intervista di test manuale
Tutorial #3: Domande per l’intervista di test di automazione
Tutorial #4: Domande per l’intervista di QA
Tutorial #5: Gestire qualsiasi intervista di lavoro
Tutorial #6: Ottenere un lavoro di test come un fresco

Test di applicazioni di dominio diverso:

Tutorial #1: Test applicazioni bancarie
Tutorial #2: Test applicazioni sanitarie
Tutorial #3: Test gateway di pagamento
Tutorial #4: Test sistema POS
Tutorial #5: Test sito eCommerce

Certificazione QA:

Tutorial #1: Guida alla certificazione Software Testing
Tutorial #2: Guida alla certificazione CSTE
Tutorial #3: Guida alla certificazione CSQA
Tutorial #4: Guida ISTQB
Tutorial #5: ISTQB Advanced

Avanzato Argomenti test manuali:

Tutorial #1: Complessità ciclomatica
Tutorial #2: Migration Testing
Tutorial #3: Cloud Testing
Tutorial #4: ETL Testing
Tutorial #5: Software Testing Metrics
Tutorial #6: Web Services

Si prepari a dare un’occhiata al 1° tutorial di questa serie di test manuali!

Introduzione al test manuale del software

Il test manuale è un processo in cui si confronta il comportamento di un pezzo di codice sviluppato (software, modulo, API, caratteristica, ecc.) con il comportamento previsto (Requisiti).

E come farai a sapere qual è il comportamento previsto? Ricorda, capire completamente i requisiti è molto molto importante.

Pensa a te stesso come un utente finale di ciò che stai per testare. Dopo questo, non siete più legati al documento dei requisiti del software o alle parole in esso contenute. Potete quindi capire il requisito principale e non solo controllare il comportamento del sistema rispetto a ciò che è scritto o detto, ma anche rispetto alla vostra comprensione e rispetto a cose che non sono scritte o dette.

A volte, può essere un requisito mancato (requisito incompleto) o un requisito implicito (qualcosa che non ha bisogno di una menzione separata ma dovrebbe essere soddisfatto), e dovete testare anche questo.

Inoltre, un requisito non deve necessariamente essere documentato. Si può benissimo avere conoscenza della funzionalità del software o si può anche indovinare e poi testare un passo alla volta. Generalmente lo chiamiamo test ad-hoc o test esplorativo.

Diamo un’occhiata in profondità:

Prima di tutto, capiamo il fatto – Se state confrontando il test di un’applicazione software o qualcos’altro (diciamo un veicolo), il concetto rimane lo stesso. L’approccio, gli strumenti e le priorità possono differire, ma l’obiettivo principale rimane lo STESSO ed è SEMPLICE, cioè confrontare il comportamento reale con il comportamento previsto.

In secondo luogo – Il test è come un atteggiamento o una mentalità che dovrebbe venire da dentro. Le abilità possono essere apprese, ma si diventa un tester di successo solo quando si hanno alcune qualità dentro di sé per default. Quando dico che le abilità di testing possono essere apprese, intendo un’educazione focalizzata e formale sul processo di testing del software.

Ma quali sono le qualità di un tester di successo? Puoi leggerle al link qui sotto:

Leggi qui =>Qualità di tester altamente efficaci

Consiglio vivamente di leggere il suddetto articolo prima di continuare con questo tutorial. Ti aiuterà a confrontare le tue caratteristiche con quelle che ci si aspetta nel ruolo del tester del software.

Per coloro che non hanno tempo di leggere l’articolo, ecco una sinossi:

“La tua curiosità, attenzione, disciplina, pensiero logico, passione per il lavoro e capacità di dissezionare le cose conta molto per essere un tester distruttivo e di successo. Ha funzionato per me e credo fortemente che funzionerà anche per voi. Se hai già queste qualità, allora deve funzionare anche per te”.

Abbiamo parlato dei pre-requisiti fondamentali per diventare un tester di software. Ora cerchiamo di capire perché il test manuale ha e avrebbe sempre una sua esistenza indipendente con o senza la crescita del test di automazione.

Perché il test manuale è necessario?

Sai qual è la cosa migliore di essere un tester, anche un tester manuale?

È il fatto che qui non puoi dipendere solo dalle competenze. Devi avere/sviluppare e migliorare il tuo processo di pensiero. Questo è qualcosa che non si può davvero comprare per pochi dollari. Dovete lavorarci voi stessi.

Dovrete sviluppare l’abitudine di fare domande e dovrete farle ogni minuto quando fate i test. La maggior parte delle volte dovresti fare queste domande a te stesso piuttosto che agli altri.

Spero che tu abbia letto l’articolo che ti ho consigliato nella sezione precedente (cioè le qualità dei tester altamente efficaci). Se sì, allora saprai che il testing è considerato un processo di pensiero e quanto successo avrai come tester dipende completamente dalle qualità che possiedi come persona.

Vediamo questo semplice flusso:

• Fai qualcosa (esegui azioni) mentre lo osservi con qualche intento (confrontandolo con l’atteso). Ora entra in gioco la tua capacità di osservazione e la tua disciplina nell’eseguire le cose.
• Voila! Cos’è stato? Hai notato qualcosa. L’hai notato perché stavi dando perfetta attenzione ai dettagli di fronte a te. Non vuoi lasciar perdere perché sei curioso. Questo non era nel tuo piano che qualcosa di inaspettato/strano accadesse, lo noterai e indagherai ulteriormente. Ma ora lo state facendo. Potete lasciar perdere. Ma non dovresti lasciar perdere.
• Sei felice, hai scoperto la causa, i passi e lo scenario. Ora lo comunicherete in modo appropriato e costruttivo al team di sviluppo e alle altre parti interessate nel vostro team. Potresti farlo tramite qualche strumento di tracciamento dei difetti o verbalmente, ma devi assicurarti di comunicarlo in modo costruttivo.
• Oops! E se lo faccio in questo modo? E se inserissi come input un numero intero corretto ma con spazi bianchi iniziali? E se? … E se? … E se? Non finisce facilmente, non dovrebbe finire facilmente. Immaginerete un sacco di situazioni & scenari e in effetti sarete tentati di eseguirli anche voi.

Il diagramma riportato di seguito rappresenta la vita di un Tester:

Rileggete ancora una volta quei quattro punti di cui sopra. Avete notato che l’ho tenuto molto breve ma ho comunque evidenziato la parte più ricca dell’essere un tester manuale? E avete notato l’evidenziazione in grassetto su alcune parole? Queste sono precisamente le qualità più importanti di cui un tester manuale ha bisogno.

Ora, pensate davvero che questi atti possano essere completamente sostituiti da qualcos’altro? E la tendenza calda oggi – può mai essere sostituita dall’automazione?

Nell’SDLC con qualsiasi metodologia di sviluppo, poche cose rimangono sempre costanti. Come tester, consumerai i requisiti, li convertirai in scenari di test/casi di test. Poi eseguirai quei casi di test o li automatizzerai direttamente (so che alcune aziende lo fanno).

Quando automatizzi, il tuo obiettivo è costante, cioè automatizzare i passi scritti.

Torniamo alla parte formale, cioè l’esecuzione dei casi di test scritti manualmente.

Qui, non ti concentri solo sull’esecuzione dei casi di test scritti, ma esegui anche molti test esplorativi mentre lo fai. Ricordate, siete curiosi? E immaginerete. E non sarai in grado di resistere, farai davvero quello che hai immaginato.

L’immagine qui sotto mostra come la scrittura dei Test Case è semplificata:

Sto compilando un modulo, e ho finito di riempire il primo campo. Sono troppo pigro per andare con il mouse a spostare il focus sul campo successivo. Ho premuto il tasto ‘tab’. Ho finito di riempire anche il prossimo e l’ultimo campo, ora ho bisogno di cliccare sul pulsante Submit, il focus è ancora sull’ultimo campo.

Ops, ho accidentalmente premuto il tasto ‘Enter’. Fammi controllare cosa è successo. O c’è un pulsante di invio, lo clicco due volte. Non sono soddisfatto. Lo clicco più volte, troppo velocemente.

L’hai notato? Ci sono così tante possibili azioni dell’utente, sia intenzionali che non intenzionali.

Non riuscirete a scrivere tutti i casi di test che coprono la vostra applicazione sotto test al 100%. Questo deve avvenire in modo esplorativo.

Continuerete ad aggiungere nuovi casi di test man mano che testate l’applicazione. Questi saranno casi di test per i bug che avete incontrato per i quali prima non c’era nessun caso di test scritto. Oppure, mentre stai testando, qualcosa ha innescato il tuo processo di pensiero e hai qualche altro caso di test che vorrai aggiungere alla tua suite di casi di test ed eseguire.

Anche dopo tutto questo, non c’è garanzia che non ci siano bug nascosti. Un software con zero bug è un mito. Si può solo mirare a portarlo vicino allo zero, ma questo non può accadere senza una mente umana che miri continuamente allo stesso, in modo simile ma non limitato al processo di esempio che abbiamo visto sopra.

Almeno ad oggi, non esiste un software che pensi come una mente umana, osservi come un occhio umano, faccia domande e risponda come un umano e poi esegua azioni previste e non previste. Anche se una cosa del genere accadesse, la mente, i pensieri e l’occhio di chi imiterà? Il tuo o il mio? Anche noi, umani, non siamo la stessa cosa. Siamo tutti diversi. Allora?

Necessità del test manuale quando c’è l’automazione:

Il test di automazione ha la sua parte di gloria in questi giorni e ne avrà ancora di più nei prossimi anni ma, semplicemente non può sostituire il test manuale QA (leggi test umano/esplorativo).

Devi aver sentito prima- ‘Non si automatizza il test, si automatizza il controllo’. Questa frase la dice lunga su dove si trovano i test manuali di QA con i test di automazione. Molti grandi nomi in tutto il mondo hanno scritto e parlato di questo argomento, quindi non sottolineerò molto su questo.

L’automazione non può sostituire il test umano perché:

• Richiede i giudizi di runtime su tutto ciò che accade davanti ai vostri occhi (mentre testate) e in pochi casi anche dietro le scene.
• Esige un’osservazione chiara e costante.
• Esige l’interrogazione.
• Richiede un’indagine.
• Richiede un ragionamento.
• Richiede azioni non pianificate come richiesto durante il test.

Il test può essere sostituito da uno strumento/macchina che sarà in grado di assorbire i dettagli, elaborarli, comandare azioni ed eseguirli come una mente umana e umana, e tutto questo a runtime e in tutti i contesti possibili. Questo strumento ancora una volta deve essere come tutti gli umani possibili.

Quindi, in breve, il test umano non può essere sostituito. Forse qualche film di fantascienza di Hollywood tra qualche anno ci assomiglierà, ma nella vita reale non lo vedo arrivare per qualche centinaio di anni, che io possa immaginare. Non lo cancellerò per sempre perché credo nelle possibilità infinite.

In una nota a parte, anche se accadesse davvero dopo qualche centinaio di anni, l’immagine che posso immaginare è quella di un mondo spaventoso di sicuro. L’era dei Transformers. 🙂

=>> Lettura consigliata – Le migliori aziende di servizi di test manuali

Come l’automazione completa i test manuali?

Ho detto prima e lo ripeto che l’automazione non può più essere ignorata. Nel mondo in cui l’integrazione continua, la consegna continua e il deployment continuo stanno diventando cose obbligatorie, i test continui non possono rimanere inattivi. Dobbiamo trovare il modo di farlo.

Il più delle volte, distribuire sempre più forza lavoro non aiuta a lungo termine per questo compito. Quindi, il Tester (Test Lead/Architect/Manager) deve decidere con cautela cosa automatizzare e cosa dovrebbe essere ancora fatto manualmente.

Sta diventando estremamente importante avere test/controlli molto precisi scritti in modo che possano essere automatizzati senza alcuna deviazione dall’aspettativa originale e possano essere usati durante il regresso del prodotto come parte del ‘Continuous Testing’.

Nota: La parola continuo del termine ‘Continuous Testing’ è soggetta a chiamate condizionali e logiche simili agli altri termini che abbiamo usato sopra con lo stesso prefisso. Continuo in questo contesto significa sempre più spesso, più velocemente di ieri. Mentre nel significato, può benissimo significare ogni secondo o Nano-secondo.

Senza avere una perfetta corrispondenza di tester umani e controlli automatizzati (test con passi precisi, risultato atteso e criteri di uscita di detto test documentati), raggiungere il Continuous Testing è molto difficile e questo, a sua volta, renderà più difficile l’integrazione continua, la consegna continua e il deployment continuo.

Ho usato volutamente il termine criteri di uscita di un test sopra. Le nostre tute di automazione non possono più essere simili a quelle tradizionali. Dobbiamo assicurarci che se falliscono, devono fallire velocemente. E per farli fallire velocemente, anche i criteri di uscita dovrebbero essere automatizzati.

Esempio:

Diciamo che c’è un difetto di blocco in cui non sono in grado di accedere a Facebook.

La funzionalità di accesso deve essere il primo controllo automatizzato e la suite di automazione non dovrebbe eseguire il controllo successivo in cui il login è un pre-requisito, come pubblicare uno stato. Sai molto bene che è destinato a fallire. Quindi fallo fallire più velocemente, pubblica i risultati più velocemente in modo che il difetto possa essere risolto più velocemente.

La prossima cosa è di nuovo qualcosa che devi aver sentito prima – Non puoi e non devi cercare di automatizzare tutto.

Seleziona i casi di test che se automatizzati porteranno considerevoli benefici ai tester umani e hanno un buon ritorno sull’investimento. Per questo, c’è una regola generale che dice che si dovrebbe cercare di automatizzare tutti i casi di test di priorità 1 e se possibile quelli di priorità 2.

L’automazione non è facile da implementare e richiede tempo, quindi si consiglia di evitare di automatizzare i casi di bassa priorità almeno fino al momento in cui si è finito con quelli alti. Selezionare cosa automatizzare e concentrarsi su di esso migliora la qualità dell’applicazione se usato e mantenuto continuamente.

Conclusione

Spero che a questo punto tu abbia capito perché e quanto sia necessario il test manuale/umano per fornire prodotti di qualità e come l’automazione lo completi.

Accettare l’importanza del test manuale QA e sapere perché è speciale, è il primo passo per essere un eccellente tester manuale.

Nei nostri prossimi tutorial sul test manuale, copriremo un approccio generico per fare il test manuale, come coesiste con l’automazione e molti altri aspetti importanti.

Sono sicuro che otterrete un’immensa conoscenza del test del software una volta che passerete attraverso l’intera lista di tutorial in questa serie.