Blog di tester noioso: scenari di test negativi. Immagine di prova per il pensiero negativo e positivo Ha dato un risultato positivo ai prodotti testati

Durante il test prodotto software usato una quantità enorme vari tipi test. La classificazione più ampia e dettagliata è stata proposta dall'autore del libro "Dot Com Testing" Roman Savin. Ha combinato i tipi di test su basi quali l'oggetto, l'oggetto del test, il livello, la positività del test e il grado di automazione del test. La classificazione è stata integrata sulla base di fonti come il libro Software Testing di Sam Kaner e la risorsa di test online Pro Testing - Software Testing.

Secondo l'oggetto del test

· Collaudo funzionale. Il test funzionale è uno dei tipi di test più comunemente usati oggi. Il compito di tale collaudo è quello di stabilire quanto il software (SW) sviluppato corrisponda ai requisiti del cliente in termini di funzionalità. In altre parole, l'esecuzione di test funzionali consente di verificare l'abilità sistema informativo risolvere i problemi degli utenti.
· Test non funzionali. Consente di verificare la conformità delle proprietà del software ai requisiti non funzionali impostati. Pertanto, il test non funzionale è il test di tutte le proprietà del programma che non sono correlate alla funzionalità del sistema. Tali proprietà possono essere presentate caratteristiche in termini di parametri quali:
- Affidabilità (la capacità del sistema di rispondere a situazioni impreviste).
- Prestazioni (la capacità del sistema di lavorare sotto carichi pesanti).
- Convenienza (ricerca dell'esperienza dell'utente con l'applicazione).
- Scalabilità (la capacità di scalare l'applicazione sia verticalmente che orizzontalmente).
- Sicurezza (indagine sulla possibilità di interruzione dell'applicazione e furto dei dati dell'utente da parte di intrusi).
- Portabilità (la possibilità di trasferire l'applicazione su un insieme specifico di piattaforme)

E molte altre qualità.

Test interfaccia utente. Questo sta testando la correttezza della visualizzazione degli elementi dell'interfaccia utente su vari dispositivi, la correttezza della loro risposta alla commissione di varie azioni da parte dell'utente e una valutazione di come dovrebbe comportarsi il programma nel suo insieme. Tali test consentono di valutare quanto efficacemente l'utente sarà in grado di lavorare con l'applicazione e come aspetto domanda corrisponde ai documenti approvati creati dai progettisti. Durante il test dell'interfaccia utente, il compito principale del tester è identificare difetti visivi e strutturali nell'interfaccia grafica dell'applicazione, verificare la possibilità e la facilità di navigazione nell'applicazione e la correttezza dell'elaborazione dell'input da parte dell'applicazione da tastiera, mouse e altri dispositivi di input. Il test dell'interfaccia utente è necessario per garantire che l'interfaccia sia conforme ai requisiti e agli standard approvati e per garantire che l'utente possa lavorare con GUI applicazioni.
· Test di usabilità. Questo è un metodo di test che consente di valutare il grado di usabilità dell'applicazione, la velocità di apprendimento dell'utente quando si lavora con il programma e anche come gli utenti del prodotto sviluppato lo trovano comprensibile e attraente nel contesto di determinate condizioni. Tali test sono necessari per garantire l'esperienza utente più positiva quando si lavora con l'applicazione.
· Test di sicurezza. Consente di identificare le principali vulnerabilità del software in relazione a vari attacchi da parte di intrusi. Sistemi informatici molto spesso sono soggetti ad attacchi informatici al fine di interrompere l'operatività del sistema informativo o rubare dati riservati. Il test di sicurezza offre l'opportunità di analizzare l'effettiva risposta e l'efficacia dei meccanismi di difesa utilizzati nel sistema in caso di tentativo di intrusione. Durante i test di sicurezza, il tester tenta di eseguire le stesse azioni che eseguirebbe un vero cracker. Quando un tester tenta di hackerare il sistema, può essere utilizzato qualsiasi mezzo: attacchi al sistema tramite utenze speciali; tenta di apprendere accessi e password utilizzando mezzi esterni; Attacchi DDOS; generazione mirata di errori per rilevare la possibilità di penetrazione nel sistema nel processo del suo ripristino; sfruttare le vulnerabilità note del sistema senza patch.
· Test di installazione. Questo termine significa testare la correttezza dell'installazione (installazione) di un determinato prodotto software. Tali test di solito si svolgono in ambienti creati artificialmente per determinare il grado di prontezza del software per il funzionamento. I motivi principali per lo svolgimento di tali test sono legati alla necessità di verificare il corretto comportamento del prodotto software durante l'implementazione o l'aggiornamento automatizzato. Garantire che il software sia installato correttamente e stabile è un fattore molto importante nella creazione di un prodotto software, poiché consente agli utenti di iniziare a utilizzare il prodotto più velocemente e con meno sforzo, garantendo al tempo stesso che il prodotto si comporti correttamente in tutti gli ambienti software testati.
· Test di configurazione. Il test di configurazione è progettato per valutare le prestazioni del software in varie configurazioni di sistema. A seconda del tipo di prodotto software testato, il test di configurazione può avere obiettivi diversi. Di solito, si tratta di determinare la configurazione hardware ottimale che fornisce parametri prestazionali sufficienti per il funzionamento del software o di verificare una configurazione hardware specifica (o una piattaforma che include, oltre all'hardware, software di terze parti necessario per il funzionamento del programma) per verificarne la compatibilità con il prodotto in fase di test. Se noi stiamo parlando sul client-server Software, il test della configurazione viene eseguito separatamente per il server e separatamente per il client. Di solito, quando si verifica la compatibilità di un server con una determinata configurazione, il compito è trovare la configurazione ottimale, poiché la stabilità e le prestazioni del server sono importanti. Mentre durante il test di un client, al contrario, cercano di identificare i difetti del software in qualsiasi configurazione e, se possibile, eliminarli.
· Test di affidabilità e ripristino dopo guasti (stress test). Questo tipo di test viene spesso eseguito per software che funziona con dati utente preziosi, la cui continuità di funzionamento e la velocità di ripristino dai guasti sono fondamentali per l'utente. I test di errore e ripristino testano la capacità del programma di recuperare rapidamente e con successo da guasti hardware, interruzioni di rete o errori critici nel software stesso. Ciò consente di valutare le possibili conseguenze di un guasto ei tempi necessari per il successivo ripristino del sistema. Sulla base dei dati ottenuti durante i test, è possibile valutare l'affidabilità del sistema nel suo complesso e, in caso di prestazioni insoddisfacenti, possono essere adottate misure appropriate per migliorare i sistemi di ripristino.
Test di localizzazione. I test di localizzazione consentono di scoprire quanto bene il prodotto è adattato alla popolazione di determinati paesi e come corrisponde alle sue caratteristiche culturali. Di solito vengono prese in considerazione le sfumature culturali e linguistiche, vale a dire la traduzione dell'interfaccia utente, della relativa documentazione e dei file in una determinata lingua, e viene anche verificata la correttezza dei formati di valute, numeri, orari e numeri di telefono.
· Test di stress. Il test di carico consente di identificare il numero massimo di attività dello stesso tipo che il programma può eseguire in parallelo. L'obiettivo più popolare del test di carico nel contesto delle applicazioni client-server è stimare il numero massimo di utenti che possono utilizzare contemporaneamente i servizi dell'applicazione.
· Prove di stabilità. I test di stabilità controllano le prestazioni dell'applicazione durante l'uso a lungo termine a carichi medi. A seconda del tipo di applicazione, si formano determinati requisiti per la durata del suo funzionamento ininterrotto. I test di stabilità cercano di identificare i problemi dell'applicazione come perdite di memoria, picchi di carico gravi e altri fattori che possono impedire il funzionamento dell'applicazione per un periodo di tempo prolungato.
· Collaudo volumetrico. Il compito del test del volume è identificare la reazione dell'applicazione e valutare il possibile deterioramento del funzionamento del software con un aumento significativo della quantità di dati nel database dell'applicazione. In genere, questo test include:
- Misurazione del tempo di esecuzione delle operazioni relative all'ottenimento o alla modifica dei dati del database a una certa intensità di richieste.
- Individuazione della dipendenza dell'allungamento del tempo delle operazioni dalla quantità di dati presenti nel database.
- Determinazione del numero massimo di utenti che possono lavorare contemporaneamente con l'applicazione senza ritardi evidenti dal database.
Test di scalabilità. Questo è un tipo di test del software progettato per testare la capacità di un prodotto di aumentare (a volte diminuire) l'ambito di determinate caratteristiche non funzionali. Alcuni tipi di applicazioni devono essere ridimensionati facilmente e, ovviamente, rimanere funzionali e supportare un determinato carico utente.

Test relativi al cambiamento

La sanità mentale è uno dei tipi di test, il cui scopo è dimostrare le prestazioni di una particolare funzione o modulo in conformità con i requisiti tecnici dichiarati dal cliente. I test sanitari vengono spesso utilizzati quando si controlla una parte di un programma o di un'applicazione quando vengono apportate determinate modifiche da fattori ambientali. Questo tipo il test viene solitamente eseguito manualmente.
· Il test del fumo è un breve ciclo di test, il cui scopo è confermare il fatto che l'applicazione che viene installata si avvii ed esegua le funzioni dopo che il codice nuovo o modificato è stato creato. Al termine del test dei segmenti più importanti dell'applicazione, vengono fornite informazioni oggettive sulla presenza o meno di difetti nel funzionamento dei segmenti testati. Sulla base dei risultati dei test del fumo, viene presa la decisione se inviare la domanda per la revisione o se deve essere ulteriormente testata completamente.
· Test di regressione - test volti a trovare errori in aree già testate. I test di regressione verificano la presenza di bug nel prodotto che potrebbero derivare dall'aggiunta di una nuova sezione del programma o dalla correzione di altri bug. Lo scopo di questo tipo di test è assicurarsi che l'aggiornamento della build o la correzione dei bug non porti a nuovi bug.

Per livello di test

· Unit test (Unit test). Consiste nella verifica di ogni singolo modulo (elemento originario del sistema) mediante l'esecuzione di test automatizzati in un ambiente artificiale. Le implementazioni di tali test utilizzano spesso vari stub e driver per simulare il funzionamento di un sistema reale. Il test automatico delle unità è la prima opportunità per eseguire e testare il codice sorgente. La creazione di test unitari per tutti i moduli del sistema consente di identificare molto rapidamente gli errori nel codice che possono apparire durante lo sviluppo.
· Test d'integrazione. Questo è il test dei singoli moduli del sistema per la corretta interazione. L'obiettivo principale del test di integrazione è trovare difetti e identificare comportamenti scorretti associati a errori nell'interpretazione o nell'implementazione dell'interazione tra moduli.
· Collaudo del sistema. Questo è il test del programma nel suo insieme, tale test verifica la conformità del programma ai requisiti dichiarati.
· Test di accettazione. Si tratta di un test completo che determina l'effettivo livello di prontezza del sistema per il funzionamento da parte degli utenti finali. I test vengono eseguiti sulla base di una serie di scenari di test che coprono le principali operazioni di business del sistema.

Tramite l'esecuzione del codice

· Collaudo statico. Questa è l'identificazione di artefatti che compaiono durante lo sviluppo di un prodotto software analizzando i file di origine, come la documentazione o il codice del programma. Tale test viene eseguito senza eseguire direttamente il codice, la qualità dei file sorgente e la loro conformità ai requisiti vengono valutati manualmente o utilizzando strumenti ausiliari. I test statici dovrebbero essere eseguiti prima dei test dinamici, quindi i bug rilevati durante i test statici sono meno costosi. Dal punto di vista codice sorgente, il test statico è espresso nella revisione del codice. Di solito una revisione del codice singoli file viene effettuata dopo ogni modifica di questi file da parte del programmatore, la revisione stessa può essere effettuata sia da un altro programmatore, sia dal lead developer, oppure da un singolo addetto coinvolto nella revisione del codice. L'uso di test statici consente di mantenere la qualità del software in tutte le fasi di sviluppo e riduce i tempi di sviluppo del prodotto.
· Prove dinamiche. A differenza dei test statici, questo tipo di test comporta l'esecuzione del codice sorgente dell'applicazione. Pertanto, il test dinamico contiene molti altri tipi di test che sono già stati descritti sopra. Il test dinamico consente di identificare errori nel comportamento del programma analizzando i risultati della sua esecuzione. Si scopre che quasi tutti i tipi di test esistenti corrispondono alla classe di test dinamici.

Per oggetto di prova

· Test alfa. Questo test è per i più prime versioni software per computer (o dispositivo hardware). Il test Alpha viene quasi sempre eseguito dagli stessi sviluppatori di software. Durante l'alpha test, gli sviluppatori dell'applicazione trovano e correggono bug e problemi nel programma. Di solito, durante il test Alpha c'è un'imitazione del lavoro con il programma da parte di sviluppatori a tempo pieno, meno spesso c'è un vero lavoro sia di potenziali utenti che di clienti con il prodotto. Di norma, il test alfa viene eseguito nella prima fase dello sviluppo del software, tuttavia, in singoli casi può essere applicato a un prodotto finito o quasi finito, ad esempio come test di accettazione.
· Test beta. Testare un prodotto ancora in fase di sviluppo. Durante il beta test, questo prodotto viene reso disponibile a un numero limitato di utenti al fine di indagare e segnalare i problemi emergenti riscontrati dagli utenti. Tali test sono necessari per trovare errori che gli sviluppatori potrebbero aver perso. In genere, il beta testing viene condotto in due fasi: closed beta testing e open beta testing. Un beta test chiuso sta testando su una cerchia ristretta di utenti selezionati. Tali utenti possono essere sviluppatori familiari o loro colleghi che non sono direttamente correlati allo sviluppo del prodotto testato. L'open beta test riguarda la creazione e l'hosting accesso libero beta pubblica. IN questo caso Qualsiasi utente può essere un beta tester. Feedback da tali beta tester viene effettuato con l'ausilio delle recensioni sul sito e dei sistemi di analisi e registrazione delle azioni dell'utente integrati nel programma, questi sistemi sono necessari per analizzare il comportamento degli utenti e rilevare le difficoltà e gli errori che incontrano.

Secondo la positività dello scenario

· Test positivo. I test di scenari positivi testano la capacità di un programma di eseguire la funzionalità prevista. Di norma, per tali test vengono sviluppati scenari di test, durante i quali, in normali condizioni operative per il software, non dovrebbero esserci difficoltà.
· Test negativo. Il test software negativo si verifica in scenari che corrispondono a un comportamento anomalo del programma. Tali test verificano la correttezza del programma in situazioni di emergenza. Ciò consente di assicurarsi che il programma generi i messaggi di errore corretti, non danneggi i dati dell'utente e si comporti correttamente in generale in situazioni in cui non è previsto il normale comportamento del prodotto. Lo scopo principale del test negativo è testare la stabilità del sistema a varie influenze, la capacità di convalidare correttamente i dati di input e gestire le eccezioni che si verificano sia negli algoritmi software stessi che nella logica aziendale.

Per grado di automazione

· Test manuale. Il test manuale viene eseguito senza l'uso di ulteriori strumenti software, consente di testare un programma o un sito Web simulando le azioni dell'utente. In questo modello, il tester agisce come un utente, seguendo determinati scenari, mentre analizza l'output del programma e il suo comportamento in generale.
· Test automatizzati. Tali test consentono, attraverso l'uso di software aggiuntivo per l'automazione dei test, di accelerare notevolmente il processo di test. Tale software aggiuntivo consente di controllare e gestire l'esecuzione dei test e confrontare i risultati attesi ed effettivi del programma. Maggiori dettagli saranno discussi in seguito.

L'articolo è stato rivisto tenendo conto delle critiche e delle raccomandazioni ricevute nel forum.

Con questo articolo, vorrei descrivere la mia comprensione del test del software: il processo non è banale, come ho sempre pensato, e, non potevo nemmeno immaginare, molto interessante.

Sono sempre stato interessato a cosa sia il test del software. Perché assumere qualcuno per testare un prodotto software se lo sviluppatore stesso può dedicare un paio d'ore a un'attività a priorità così bassa. E infine, perché testare? Dopotutto, i programmatori sono ragazzi intelligenti: scrivono correttamente. Ma

non tutto è così semplice come mi sembrava.

Essendo passato da programmatore a tester, non avendo abbastanza teoria in seno, ho cercato a lungo di "rompere" il prodotto software, dando deliberatamente dati di input errati all'input. E, stranamente, si è rotto. È stato creato un messaggio di errore e il giorno successivo è stato considerato positivo.

Successivamente, ho iniziato ad affrontare il fatto che, indipendentemente dal numero di test eseguiti, si verificano comunque errori. Non avendo idea di cosa e come dovrebbe essere dato "in input" all'applicazione in prova, il processo di test sembrava infinito. Di conseguenza - un circolo vizioso, in cui le scadenze non rispettate per i test, il PM arrabbiato e gli sviluppatori stanchi di "sciocchezze".

E solo molto più tardi, ho individuato per me stesso una chiara sequenza di azioni che devono essere eseguite per testare il software:

Studio della specifica. Questa fase è la più importante ed è anche chiamata progettazione e/o analisi dei requisiti. A volte viene utilizzato il nome "test delle specifiche", poco dopo capiremo perché si tratta di "test". Qui è necessario leggere attentamente la documentazione (specifiche) per l'applicazione.
Test del fumo. In questa fase, è necessario verificare se il sistema funziona (funziona correttamente, "giura" correttamente se non viene elaborato correttamente, ecc.). Questo viene fatto per capire se l'applicazione è adatta per ulteriori test o non funziona affatto (non funziona correttamente).
Test "positivo". In questa terza fase, è necessario verificare l'esito dell'applicazione quando riceve i dati di input "corretti".
Test "negativo". Questa è la quarta e ultima fase del test iniziale. Qui è necessario vedere come si comporta l'applicazione, ricevendo dati "errati" come input. Questo viene fatto per determinare come si comporta l'applicazione in tal caso. Se tale opzione è descritta nelle specifiche e dovrebbe essere descritta, confrontare il risultato atteso con il risultato ottenuto.

Quindi, consideriamo tutto in ordine.

Specifiche, requisiti, SRS.

Come determinare quando e come dovrebbe funzionare l'applicazione stessa, quando e come dovrebbe "rompersi" (ovvero come il sistema o il suo modulo dovrebbe reagire a dati non validi o comportamento errato dell'utente)? Quale dovrebbe essere il risultato di una corretta elaborazione, in quali condizioni e dati di input dovrebbe avvenire una corretta elaborazione? Quale dovrebbe essere il risultato di un'errata elaborazione della domanda in esame, a quali condizioni dovrebbe avvenire?

Tutte queste domande trovano risposta nella documentazione dell'applicazione in esame. In ogni caso lui, la risposta, dovrebbe esserci, altrimenti la documentazione non è completa, il che equivale a un errore nella documentazione. Voglio fare una riserva che già in questa fase potrebbero verificarsi i primi difetti: un difetto nelle specifiche (nei requisiti) è della stessa importanza per il sistema (e talvolta più alto per priorità!) difetto. Vale anche la pena ricordare che il test dei requisiti è un tipo di test così completo, a cui viene data immeritatamente poca attenzione. I principali indicatori del successo della verifica dei requisiti sono il raggiungimento dei criteri di completezza (testabilità) e coerenza dei requisiti.

La documentazione consente di comprendere da soli i passaggi principali del controllo dell'applicazione, dove e come dovrebbe funzionare l'applicazione, dove "si rompe". E, non meno importante, Come rottura. Cosa “dire” in caso di elaborazione andata a buon fine, quali messaggi di errore possono/dovrebbero comparire durante l'elaborazione.

Avendo compreso tutta la "saggezza" dei requisiti per l'applicazione e le caratteristiche dell'implementazione di questi requisiti da parte dello sviluppatore, puoi iniziare a testare il risultato finale.

Processo di test

Questo processo può essere descritto dai seguenti passaggi:

Verificare come funziona l'applicazione quando riceve in input dati “corretti” (per sapere “cosa è bene e cosa è male” leggiamo la documentazione);
Se tutto funziona e funziona correttamente (cioè esattamente come descritto nella specifica), il passo successivo è controllare i valori limite (ovvero dove inizia il dato "corretto" e dove finisce);
Verifica del funzionamento dell'applicazione durante l'inserimento di dati non inclusi nell'intervallo di valori validi (di nuovo, vedere la specifica).

Il primo e il secondo paragrafo descrivono un processo chiamato test "positivo". Il test "positivo" sta testando dati o scenari che corrispondono al comportamento normale (regolare, previsto) del sistema sottoposto a test.

Il terzo punto descrive il processo opposto al processo "positivo" - test "negativo". Si tratta di test su dati o scenari che corrispondono a comportamenti anomali del sistema sottoposto a test: vari messaggi di errore, eccezioni, stati "oltre", ecc.

Tuttavia, i test "positivi" e "negativi" dovrebbero essere preceduti da test "fumo".

Il dizionario delle informazioni fornisce una definizione abbastanza chiara del termine "test del fumo":

una forma rudimentale di testare un prodotto software dopo averne modificato la configurazione o dopo averlo modificato (il prodotto software) stesso. Durante il processo di test del fumo, il tester controlla il software per la presenza di "fumo", vale a dire cercando qualsiasi errori critici programmi;
la prima esecuzione di un programma dopo averlo interrotto o "costruito".

Priorità nei test

Perché i test "positivi" sono considerati un ordine di grandezza più importanti dei test "negativi"?

Supponiamo che il sistema non sia troppo resistente agli input "cattivi". Questo è spaventoso? Spesso non troppo. Gli utenti prima o poi impareranno a bypassare le "trappole", a non compiere azioni "pericolose" o "non autorizzate", il servizio supporto tecnico ricorderà presto quali problemi hanno di solito gli utenti e darà consigli del tipo “in nessun caso lasciare vuoto questo campo, altrimenti...”.

Ma - tutto ciò non accadrà affatto se il sistema non soddisfa il suo scopo principale, se gli utenti (clienti) non possono risolvere i loro problemi aziendali, se fanno tutto bene, inseriscono buoni dati, ma non ottengono risultati. E non c'è niente da consigliare loro in questa situazione. E se ne vanno...

Questo è il motivo per cui il test "positivo" è molto, molto più importante del test "negativo".

Tuttavia, ciò non significa che i test "negativi" possano essere trascurati, perché. non in tutte le fasi del ciclo di vita del software, le priorità dei valori rimangono invariate.

Riepilogo

Ora, dopo aver compiuto i primi passi positivi nel testare l'applicazione e aver ricevuto un risultato positivo, puoi pensare a modi più sofisticati per testare l'applicazione, come si suol dire: "Altro - altro". Tutto dipende dalla profondità del livello richiesto di test, dal desiderio e dalla capacità di testare l'applicazione. Naturalmente, le quattro fasi sopra descritte non coprono l'intero ciclo di test dell'applicazione, ma sono obbligatorie per il test iniziale.

Noi (non è un segreto) siamo molto preoccupati per la qualità dei nostri prodotti e osserviamo con trepidazione il collasso del sistema. Questo giustifica l'esistenza di tester nel mondo. Ci fa sentire degli eroi: il grande Tester è arrivato e ha salvato i suoi utenti da terribili bug critici!

E i nostri tester non dimenticano mai i test negativi, anche se non tutti i proger ne sono contenti. Ma tali controlli non sono un capriccio dei "malvagi tester", sono causati dalla necessità di chiudere le vulnerabilità e proteggersi da hacker e bot, attacchi Dos / DDos che entrano nel sistema.

Certo, qual è la vocazione degli specialisti dei test? Bisogno di trovare problemi. Problemi a cui nessuno molto spesso ha il tempo di pensare, non vuole vederli e affrontarli. E se viene verificato non solo il corretto funzionamento del sistema, ma anche il suo comportamento anomalo, si aggiunge tensione nella squadra.

Vedi, i programmatori scrivono software mirando al risultato, al rilascio pianificato, volano sulle ali dell'ispirazione! E poi arriva la fase di verifica e numerose correzioni e modifiche del codice "ideale". Ed è tutto, nasconditi in tutte le direzioni, il sistema è in fase di test.

Per non infastidire nessuno, alcuni specialisti possono rimandare i test negativi a più tardi o ignorarli del tutto (orrore!) Per ridurre tempi e budget. Bene, perché controllare se il programma non fa nemmeno quello che dovrebbe, giusto? No.

Test positivi e negativi

Ma prima le cose principali. Quando si testa il software con casi di test, ci sono due serie di controlli: positivo e negativo. E il secondo di solito è più del primo.

test positivo- si tratta di un controllo del sistema per il rispetto del suo comportamento normale (regolare, previsto), secondo il TOR e. Cioè, qui esaminiamo se il software fa ciò che ci si aspetta da esso, se l'implementazione soddisfa i requisiti moderni, se sono supportate le linee guida dell'interfaccia utente, ecc.

UN test negativo sta testando il sistema per comportamenti anomali. Verifichiamo se il software è resistente all'immissione di dati errati, come vengono gestite le eccezioni, quali informazioni vengono visualizzate nei messaggi di errore, se è possibile interrompere il funzionamento del prodotto e/o influire sulle prestazioni della soluzione e così via.

Abbiamo già detto che alcuni esperti lasciano i test negativi per dopo o se ne dimenticano del tutto, che è quasi la stessa cosa. Sai, ciò che viene rimandato a dopo rimane quasi sempre incompiuto.

Pertanto, a nostro avviso,

I test negativi e positivi generalmente non devono essere separati e distribuiti nel tempo.

Perché possiamo dire che un sistema funziona come dovrebbe se testiamo la sua risposta solo agli input giusti?

test positivo-negativo

Quando provi, oh, quanto sono importanti l'intuizione, il sentimento, l'istinto di caccia - chiamalo come vuoi. E qui siede un tale ingegnere, ad esempio controlla il modulo di registrazione.

Controlla tutto in base alle specifiche tecniche e agli scenari di test, osserva come vengono elaborati i dati, che l'utente deve inserire nei campi (non il fatto che inserirà, tra l'altro) ed eccolo qui: intuizione! Gli sembra che se inserisci un po 'di "% adynadyn />" in questo campo di accesso e non un testo semplice, allora succederà sicuramente qualcosa. Qualcosa di oscuro e cupo non va.

E cosa? Deve dire a se stesso: “No. Ora devo fare test positivi e nient'altro. Qui ne ho uno negativo in programma per la prossima settimana, poi verrà il momento per% adynadyn />. Forse"?

Riteniamo che questo approccio ai test negativi sia inefficace, ed ecco perché:

Se conduci test positivi e negativi separatamente, sarà più lungo. Almeno perché saranno due iterazioni di test.
Tester e programmatori vivono con scadenze. E se il tempo è strettamente limitato, rimandare il test negativo per dopo aumenta il rischio che venga dimenticato del tutto. Dopotutto, più ci si avvicina al momento X, più velocemente vola il tempo, prima è necessario completare le attività, correggere i difetti, applicare i requisiti aziendali finali (che potrebbero cambiare) e completare un sacco di altre cose. Scadenza: il momento è caldo!
La separazione tra test negativi e positivi, a nostro avviso, è semplicemente contraria alla natura del tester! Dopotutto, il suo compito principale è controllare tutto nel sistema azioni possibili utente finale. E le persone sono per lo più illogiche e possono fare una varietà di cose indecenti con il software;)

Noi, come tester, siamo molto preoccupati se il sistema contiene errori sui controlli dalla categoria negativa. E soprattutto se le conseguenze di tali errori sono critiche per l'intero sistema. Ma non abbiamo paura di denunciarli. Soprattutto con un asso nella manica del genere: abbiamo tester donne nel nostro team. E chi può difendere ostinatamente l '"idealità" del codice quando riducono in mille pezzi la performance del progetto con voci gentili? È lo stesso.

Quindi quali conclusioni possiamo trarre?

Non dimenticare i test negativi, combinali con quelli positivi, riunisci specialisti esperti in una squadra e cerca di trasferire il compito di riferire sulle spalle delle ragazze! Tutto tranne l'ultimo è consigliato al 100% e il tuo project manager se ne occuperà.

E, naturalmente, assicurati di controllare il tuo prodotto, non pensare che i programmatori scriveranno immediatamente un codice pulito e bello: non puoi ancora fare a meno dei bug! Per non parlare delle numerose vulnerabilità, confermate da dati personali e riservati che trapelano regolarmente nella rete.

Perché le persone fanno test psicologici? Naturalmente, ognuno ha le proprie motivazioni. Qualcuno vuole capire se stesso e "capire cosa sono". Qualcuno è ansioso di confermare l'opinione prevalente sul proprio carattere. Qualcuno ammazza il tempo libero e si diverte. Ma tutti, anche se spesso senza rendersene conto, cioè puramente, vogliono sentire qualcosa di buono su se stessi. Per quello? Sì, e questo solleva l'umore. Il test che ti offriamo di superare ha l'unico scopo: portare una goccia di positività nel tuo stato attuale. In realtà, questo non è affatto un test, ma qualcosa come una previsione positiva. E loro, come sai, molto spesso diventano realtà!

06.10.2018 16947 +67

Vuoi sapere come le altre persone percepiscono il tuo nome? Gratuito Servizio Online L'analisi fonosemantica ti consente di scoprire come viene percepita una particolare parola a livello subconscio. Con esso, puoi, ad esempio, scegliere un nome per un bambino o un nome per un'azienda.
Scopri come ti sentirai tra un mese! In questo momento sul nostro sito puoi calcolare i tuoi bioritmi in modo assolutamente gratuito. Sulla base dei risultati del calcolo, riceverai raccomandazioni personali e un programma per modificare i bioritmi per il mese successivo.
Test psicologici popolari Un numero enorme di test psicologici popolari per tutti i gusti. Per uomo, per donna, esoterico, professionale... E tutto questo online, gratuitamente e senza registrazione!

Molto preoccupato per la qualità dei prodotti. Questo spiega la disponibilità mondiale di tester software. Fornendo, queste persone ne garantiscono la qualità.

Molti tester non dimenticheranno mai i test negativi, anche se non tutti i programmatori ne sono contenti. Tale controllo è necessario per proteggere da hacker, bot, attacchi Dos/DDos.

Qual è la vocazione dei tester? Devono trovare problemi che non sono visibili agli altri. Non procrastinare con test negativi o stai mettendo in pericolo il sistema.

Test positivi e negativi

Cominciamo dall'inizio. Ci sono 2 tipi di controllo quando i test case sono inclusi nel testing: positivo e negativo. Quest'ultimo ha il vantaggio.

test positivo è il processo di verifica del comportamento corretto secondo le specifiche e la documentazione. Viene eseguito un test positivo per garantire che il sistema faccia esattamente ciò che ci si aspetta.

Test negativo è il processo di verifica del comportamento errato. Attraverso tali test, possiamo apprendere che il sistema farà fronte a situazioni impreviste.

test positivo-negativo

Per eseguire test del software, è necessario avere intuizione o un istinto di caccia. Un tester è una persona versatile che può eseguire sia analisi aziendali che test.

I tester controllano se il processo sta funzionando correttamente: se c'è conformità con i requisiti tecnici e gli scenari di test. L'esecuzione separata di test positivi e negativi richiederà più tempo che eseguirli tutti contemporaneamente. Questo perché ci sono due iterazioni di test.

Dopotutto, più ci si avvicina all'ora X, più velocemente passa il tempo e prima è necessario completare le attività, correggere i difetti, applicare i requisiti aziendali (che possono variare) e ottenere di più. La scadenza è il momento più caldo!

Separare test negativi e positivi è semplicemente contro la natura del tester! Il suo compito è controllare il sistema per tutte le possibili azioni dell'utente finale.

Gli esseri umani sono fondamentalmente illogici e possono causare problemi nel software. I test negativi aiuteranno a evitare problemi.

Materiali tematici: