Menu

Che cos'è il test del software? Oltre 100 tutorial gratuiti sui test manuali

what is software testing

Prova Il Nostro Strumento Per Eliminare I Problemi

Una guida completa al test del software con oltre 100 tutorial sui test manuali con definizione, tipi, metodi e dettagli del processo di test:

Che cos'è il test del software?

Il test del software è un processo di verifica e convalida della funzionalità di un'applicazione per scoprire se soddisfa i requisiti specificati. È il processo di individuazione dei difetti in un'applicazione e verifica del funzionamento dell'applicazione in base ai requisiti dell'utente finale.

Cos'è il test manuale?

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

Cosa imparerai:

Elenco dei 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 apprendere le tecniche di test di base e avanzate.

Questa serie di tutorial arricchirà le tue conoscenze e, a sua volta, migliorerà le tue capacità di test.

Pratica formazione gratuita di test manuali end-to-end su un progetto live:

Tutorial n. 1: Nozioni di base sul test manuale del software
Tutorial n. 2: Introduzione al progetto dal vivo
Tutorial n. 3: Scrittura di scenari di prova
Tutorial n. 4: Scrivi un documento del piano di test da zero
Tutorial n. 5: Scrittura di casi di test dal documento SRS
Tutorial # 6: Esecuzione del test
Tutorial # 7: Tracciamento dei bug e firma del test
Tutorial n. 8: Corso di test del software

Ciclo di vita del test del software:

Tutorial n. 1: STLC

Test web:

Tutorial n. 1: Test di applicazioni Web
Tutorial n. 2: Test su più browser

Gestione dei casi di test:

domande e risposte dell'intervista al centro qualità

Tutorial n. 1: Casi test
Tutorial n. 2: Modello di test case di esempio
Tutorial n. 3: Matrice di tracciabilità dei requisiti (RTM)
Tutorial n. 4: Copertura del test
Tutorial n. 5: Test Data Management

Gestione dei test:

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

Prove tecniche:

Tutorial n. 1: Usa case test
Tutorial n. 2: Test di transizione di stato
Tutorial n. 3: Analisi del valore limite
Tutorial n. 4: Partizionamento di equivalenza
Tutorial n. 5: Metodologie di test del software
Tutorial # 6: Metodologia Agile

Gestione dei difetti:

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

Test funzionali

Tutorial n. 1: Test unitario
Tutorial n. 2: Sanità e test del fumo
Tutorial n. 3: Test di regressione
Tutorial n. 4: Test di sistema
Tutorial n. 5: Test di accettazione
Tutorial # 6: Test d'integrazione
Tutorial # 7: Test di accettazione utente UAT

Test non funzionali:

Tutorial n. 1: Test non funzionali
Tutorial n. 2: Test delle prestazioni
Tutorial n. 3: Test di sicurezza
Tutorial n. 4: Test di sicurezza delle applicazioni web
Tutorial n. 5: Test di usabilità
Tutorial # 6: Test di compatibilità
Tutorial # 7: Test di installazione
Tutorial n. 8: Test della documentazione

Tipi di test del software:

Tutorial n. 1: Tipi di test
Tutorial n. 2 : Test della scatola nera
Tutorial n. 3: Test di database
Tutorial n. 4: Test end to end
Tutorial n. 5: Test esplorativi
Tutorial # 6: Test incrementali
Tutorial # 7: Test di accessibilità
Tutorial n. 8: Test negativo
Tutorial n. 9: Test di backend
Tutorial n.10: Alpha Testing
Tutorial n. 11: Beta test
Tutorial n. 12: Alpha vs Beta Testing
Tutorial n.13: Test gamma
Tutorial n. 14: Test ERP
Tutorial # 15: Test statici e dinamici
Tutorial n. 16: Test ad hoc
Tutorial n. 17: Localizzazione e test di internazionalizzazione
Tutorial n. 18: Test di automazione
Tutorial n. 19: Test della scatola bianca

Carriera nel test del software:

Tutorial n. 1: Scegliere una carriera nel test del software
Tutorial n. 2: Come ottenere un lavoro di prova QA - Guida completa
Tutorial n. 3: Opzioni di carriera per i tester
Tutorial n. 4: Passaggio da test non IT a software
Tutorial n. 5: Inizia la tua carriera di test manuale
Tutorial # 6: Lezioni apprese da 10 anni di test
Tutorial # 7: Sopravvivi e progredisci nel campo dei test

Preparazione dell'intervista:

Tutorial n. 1: Preparazione del curriculum QA
Tutorial n. 2: Domande di intervista di prova manuale
Tutorial n. 3: Domande di intervista sul test di automazione
Tutorial n. 4: Domande per l'intervista QA
Tutorial n. 5: Gestisci qualsiasi colloquio di lavoro
Tutorial # 6: Ottieni lavoro di prova come un più fresco

Test di diverse applicazioni di dominio:

Tutorial n. 1 : Test di applicazioni bancarie
Tutorial n. 2: Test di applicazioni sanitarie
Tutorial n. 3: Test del gateway di pagamento
Tutorial n. 4: Sistema di test Point of Sale (POS)
Tutorial n. 5: Test di siti Web eCommerce

Test della certificazione QA:

Tutorial n. 1: Guida alla certificazione del test del software
Tutorial n. 2: Guida alla certificazione CSTE
Tutorial n. 3: Guida alla certificazione CSQA
Tutorial n. 4: Guida ISTQB
Tutorial n. 5: ISTQB Advanced

Argomenti del test manuale avanzato:

Tutorial n. 1: Complessità ciclomatica
Tutorial n. 2: Test di migrazione
Tutorial n. 3: Test del cloud
Tutorial n. 4: Test ETL
Tutorial n. 5: Metriche di test del software
Tutorial # 6: Servizi web

Preparati a dare un'occhiata al primo 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, funzionalità, ecc.) Con il comportamento previsto (Requisiti).

E come saprai qual è il comportamento previsto?

Lo saprai leggendo o ascoltando attentamente i requisiti e comprendendolo completamente. Ricorda, comprendere completamente i requisiti è molto molto importante.

tecniche di test white box con esempi

Pensa a te stesso come un utente finale di ciò che stai per testare. Dopodiché, non sei più vincolato al documento dei requisiti software o alle parole in esso contenute. È quindi possibile comprendere il requisito fondamentale e non solo controllare il comportamento del sistema rispetto a ciò che viene scritto o detto, ma anche contro la propria 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 devi testare anche per questo.

Inoltre, un requisito non deve essere necessariamente documentato. Puoi benissimo conoscere le funzionalità del software o puoi persino indovinare e quindi testare un passaggio alla volta. Generalmente lo chiamiamo test ad hoc o test esplorativo.

Diamo uno sguardo approfondito:

Innanzitutto, capiamo il fatto: Sia che tu stia confrontando il test di un'applicazione software o qualcos'altro (diciamo un veicolo), il concetto rimane lo stesso. Approccio, strumenti e priorità potrebbero differire, ma l'obiettivo principale rimane lo STESSO ed è SEMPLICE, ovvero confrontare il comportamento effettivo con il comportamento previsto.

In secondo luogo - Il test è come un atteggiamento o una mentalità che dovrebbe provenire dall'interno. Le abilità possono essere apprese, ma diventerai un tester di successo solo quando avrai alcune qualità dentro di te per impostazione predefinita. Quando dico che le abilità di test possono essere apprese, intendo un'istruzione mirata e formale intorno al processo di test del software.

Ma quali sono le qualità di un tester di successo? Puoi leggere su di loro al link sottostante:

Leggilo qui => Qualità di tester altamente efficaci

Consiglio vivamente di leggere l'articolo sopra prima di continuare con questo tutorial. Ti aiuterà a confrontare le tue caratteristiche con quelle previste nel ruolo di Software Tester.

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 analizzare le cose sono molto importanti per essere un tester distruttivo e di successo. Ha funzionato per me e credo fermamente che funzionerà anche per te. Se hai già queste qualità, allora davvero deve funzionare anche per te. '

Abbiamo parlato dei prerequisiti fondamentali di diventare un tester di software. Ora capiamo perché il test manuale ha e avrebbe sempre avuto la sua esistenza indipendente con o senza la crescita del test di automazione.

Perché è richiesto il test manuale?

Sai qual è la cosa migliore dell'essere un Tester, anche quello un Tester manuale?

È il fatto che qui non puoi dipendere solo dallo skillset. Devi avere / sviluppare e migliorare il tuo processo di pensiero. Questo è qualcosa che non puoi davvero comprare per pochi dollari. Tu stesso devi lavorarci sopra.

Tu dovrai sviluppare l'abitudine di fare domande e dovrai chiederglielo ogni minuto durante il test. La maggior parte delle volte dovresti porre queste domande a te stesso che agli altri.

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

Vediamo questo semplice flusso:

  • Fai qualcosa ( eseguire azioni ) mentre lo osservi con un certo intento (confrontandolo con il previsto). Adesso tuo osservazione abilità e disciplina per eseguire le cose entra in scena qui.
  • Ecco! Che cos 'era questo? Hai notato qualcosa. L'hai notato perché stavi dando perfetto attenzione ai dettagli davanti a voi. Non lo lascerai andare perché lo sei curioso . Non era nel tuo piano che succedesse qualcosa di inaspettato / strano, lo noterai e lo indagherai ulteriormente. Ma ora lo stai facendo. Puoi lasciarlo andare. Ma non dovresti lasciarlo andare.
  • Sei felice, hai scoperto la causa, i passaggi e lo scenario. Ora lo comunicherai in modo corretto e costruttivo al team di sviluppo e agli altri stakeholder del tuo team. Potresti farlo tramite uno strumento di tracciamento dei difetti o verbalmente, ma devi assicurarti di esserlo comunicandolo in modo costruttivo .
  • Ops! E se lo facessi in questo modo? Cosa succede se inserisco il numero intero corretto come input ma con spazi bianchi iniziali? Cosa succede se? … Cosa succede se? … Cosa succede se? Non finisce facilmente, non dovrebbe finire facilmente. Desideri immaginare un sacco di situazioni e scenari e in effetti sarai tentato di eseguirli anche tu.

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

Vita di un tester

Leggi ancora una volta quei quattro punti elenco menzionati sopra. Hai notato che l'ho tenuto molto breve ma ho comunque evidenziato la parte più ricca dell'essere un tester manuale? E hai notato l'evidenziazione in grassetto su poche parole? Queste sono precisamente le qualità più importanti di cui ha bisogno un tester manuale.

Ora, pensi davvero che questi atti possano essere completamente sostituiti da qualcos'altro? E la tendenza attuale oggi: potrà mai essere sostituita dall'automazione?

In SDLC con qualsiasi metodologia di sviluppo, poche cose rimangono sempre costanti. In qualità di tester, utilizzerai i requisiti e li convertirai in scenari di test / casi di test. Quindi eseguirai questi casi di test o li automatizzerai direttamente (so che alcune aziende lo fanno).

Quando lo automatizzi, la tua attenzione è costante, ovvero l'automazione dei passaggi scritti.

Torniamo alla parte formale, ovvero 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. Ricorda, sei curioso? E immaginerai. E non sarai in grado di resistere, farai davvero quello che immaginavi.

L'immagine di seguito mostra come la scrittura del test case è semplificata:

Scrittura di casi di test semplificata

Sto compilando un modulo e ho finito di riempire il primo campo. Sono troppo pigro per fare in modo che il mouse sposti il ​​focus sul campo successivo. Ho premuto il tasto 'tab'. Ho finito di riempire anche il prossimo e l'ultimo campo, ora devo fare clic sul pulsante Invia, il focus è ancora sull'ultimo campo.

Oops, ho premuto per sbaglio il tasto 'Invio'. Fammi controllare cosa è successo. OPPURE c'è un pulsante di invio, farò doppio clic su di esso. Non soddisfatto. Lo clicco più volte, troppo velocemente.

Hai notato? Ci sono così tante possibili azioni dell'utente, sia intenzionali che non intenzionali.

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

Continuerai ad aggiungere i tuoi nuovi casi di test mentre provi l'applicazione. Questi saranno casi di test per bug che hai riscontrato per i quali in precedenza non era stato scritto alcun caso di test. Oppure, mentre stai testando, qualcosa ha attivato il tuo processo di pensiero e hai altri casi di test che vorresti aggiungere alla tua suite di casi di test ed eseguire.

Anche dopo tutto questo, non c'è garanzia che non ce ne siano bug nascosti . Il software senza bug è un mito. Puoi mirare solo a portarlo vicino a Zero, ma ciò non può accadere senza una mente umana che prenda continuamente di mira lo stesso, simile ma non limitato al processo di esempio che abbiamo visto sopra.

Almeno ad oggi, non esiste software che pensi come una mente umana, osserverà come un occhio umano, farà domande e risponderà come un essere umano e quindi eseguirà azioni intenzionali e non intenzionali. Anche se succedesse una cosa del genere, quale mente, pensieri e occhi imiteranno? Tuo o mio? Anche noi umani non abbiamo lo stesso diritto. Siamo tutti diversi. Poi?

Necessità di test manuali quando l'automazione è in giro:

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 di QA (leggi test umano / esplorativo).

Devi aver sentito prima- ' Non automatizzi il test, automatizzi il controllo '. Questa frase parla molto di dove si trova il test manuale del QA con i test di automazione in giro. Molti grandi nomi in tutto il mondo hanno scritto e parlato di questo argomento, quindi non lo sottolineerò molto.

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

  • Richiede giudizi in fase di esecuzione su tutto ciò che accade davanti ai tuoi occhi (mentre provi) e in pochi casi anche dietro le quinte.
  • Richiede un'osservazione chiara e costante.
  • Richiede interrogatorio.
  • Richiede un'indagine.
  • Richiede 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. Anche questo strumento deve essere come tutti gli esseri umani possibili.

Quindi, in breve, i test umani non possono essere sostituiti. Forse qualche film di fantascienza di Hollywood tra qualche anno gli sembrerà simile, ma nella vita reale, non riesco a vederlo arrivare per qualche centinaio di anni, che posso immaginare. Non lo cancellerò per sempre perché credo nelle infinite possibilità.

In una nota a parte, anche se succede davvero dopo poche centinaia di anni, l'immagine che posso immaginare è sicuramente quella di un mondo spaventoso. Age of Transformers. :)

= >> Letture consigliate - Le migliori società di servizi di test manuali

In che modo l'automazione complimenta i test manuali?

L'ho detto prima e lo ripeto di nuovo che l'automazione non può più essere ignorata. Nel mondo in cui l'integrazione continua, la consegna continua e l'implementazione continua stanno diventando cose obbligatorie, i test continui non possono rimanere inattivi. Dobbiamo trovare dei modi su come farlo.

La maggior parte delle volte, la distribuzione di sempre più forza lavoro non aiuta a lungo termine per questo compito. Quindi, il Tester (Test Lead / Architetto / Manager) deve decidere con cautela cosa automatizzare e cosa dovrebbe ancora essere 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 utilizzati durante la regressione del prodotto come parte del 'Test continuo'.

Nota: La parola continua dal termine 'Test continuo' è 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ù veloce di ieri. Anche se nel significato, può benissimo significare ogni secondo o Nano-secondo.

Senza avere una perfetta corrispondenza di Human Testers e controlli automatizzati (test con passaggi precisi, risultato atteso e criteri di uscita di detto test documentati), il raggiungimento del Test Continuo è molto difficile e questo, a sua volta, renderà integrazione continua, consegna continua e distribuzione continua più difficile.

Ho volutamente usato 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, dovrebbero 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 quindi essere il primo controllo automatico e la suite di automazione non deve eseguire il controllo successivo in cui l'accesso è un prerequisito, come la pubblicazione di uno stato. Sai benissimo 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 dovresti provare ad automatizzare tutto.

Seleziona i casi di test che, se automatizzati, trarranno notevoli vantaggi a Human Testers e ha un buon ritorno sull'investimento. Del resto, esiste una regola generale che dice che dovresti provare ad automatizzare tutti i tuoi casi di test con priorità 1 e, se possibile, con priorità 2.

L'automazione non è facile da implementare e richiede tempo, quindi si consiglia di evitare di automatizzare i casi a bassa priorità almeno fino a quando non si è terminato con quelli ad alta. Selezionare cosa automatizzare e concentrarsi su di esso migliora la qualità dell'applicazione se utilizzata e mantenuta continuamente.

Conclusione

Spero che a questo punto abbiate capito perché e quanto male i test manuali / umani siano necessari per fornire prodotti di qualità e come l'automazione li complimenti.

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

Nelle nostre prossime esercitazioni sui test manuali, tratteremo un approccio generico per eseguire il test manuale, come coesisterà con l'automazione e molti altri aspetti importanti.

Sono sicuro che acquisirai un'immensa conoscenza del test del software dopo aver esaminato l'intero elenco di tutorial di questa serie.

coda doppia c ++

Ci piacerebbe avere tue notizie. Sentiti libero di esprimere i tuoi pensieri / suggerimenti nella sezione commenti qui sotto.

Lettura consigliata

^