Il test delle unità è il test delle più piccole parti testabili del codice dell'applicazione (chiamate unità), come moduli, funzioni o frammenti di codice. I test di unità sono spesso eseguiti in un processo automatizzato perché frequenti test di unità possono identificare rapidamente problemi o conflitti di codice.
I test di accettazione controllano l'accettazione dei risultati rispetto ai criteri di accettazione della storia dell'utente (requisiti di business).
Questi test potrebbero essere per controllare il risultato di un requisito specifico, una specifica o i requisiti del contratto.
I test esplorativi si aggiungono ai test "scriptati" (ad esempio, i test unitari). Nei test esplorativi, il tester esplora il sistema al volo per trovare problemi e comportamenti inaspettati nel sistema.
Il test di usabilità è una tecnica per valutare l'interazione dell'utente con il sistema in condizioni realistiche o impostazioni controllate. Lo scopo del test di usabilità è scoprire quanto bene gli utenti rispondono al sistema? Quanto è facile usare il sistema? Quali miglioramenti sono necessari in termini di usabilità?
L'integrazione continua (CI) sta automatizzando l'integrazione di codici nuovi o modificati nel repository del codice. L'integrazione continua aiuta a identificare i conflitti o il codice incompatibile il più presto possibile e a correggerli quando si verificano. I repository del codice permettono agli sviluppatori di tornare alle versioni precedenti.
L'integrazione continua comporta:
Codice sorgente sistema di controllo - controllo di versione
Costruire strumenti - costruire strumenti per compilare il codice
Strumenti di test - test unitari per assicurare che la funzionalità funzioni come previsto
Schedulatori o trigger - avvia le costruzioni su un programma o in base alle condizioni
Notifiche - e-mail o messaggi istantanei che riportano i risultati della costruzione
Nel Test-Driven Development, i test sono scritti prima che il codice sia sviluppato.
Lo sviluppatore passa attraverso le fasi Red-Green-refactor (pulite) fino a quando il codice è finito:
Rosso - I test scritti inizialmente falliscono perché il codice non è scritto o è incompleto.
Verde - Il codice è stato scritto e ha superato i test.
Refactor - Lo sviluppatore lavora alla pulizia e alla rifattorizzazione del codice funzionante.
Nello sviluppo guidato dai test di accettazione (ATDD), il focus dei test sono i requisiti di business e il comportamento desiderato dal sistema. I test sono scritti in base ai criteri di accettazione delle user stories che il team di sviluppatori trasforma in test di accettazione che possono essere memorizzati negli strumenti di test. I test falliscono inizialmente perché sono scritti prima che le funzionalità desiderate del software siano sviluppate e funzionino.
Il Behavior-Driven Development (BDD) è una tecnica di testing agile che mira a validare scenari e comportamenti del sistema. Segue il linguaggio Gherkin che utilizza il formato "Dato, quando, allora" per descrivere il comportamento desiderato del sistema, ovvero cosa dovrebbe accadere nell'applicazione.
La programmazione in coppia è una pratica fondamentale del framework XP che permette ai membri del team di imparare l'uno dall'altro, aumentare la produttività e trovare i bug scrivendo, dirigendo e rivedendo il codice in coppia. Il pilota scrive il codice mentre un'altra persona, il navigatore (aka. osservatore), rivede ogni linea di codice inserita. Le coppie (due membri) cambiano i ruoli (cioè, conducente e navigatore) frequentemente. Il navigatore guarda i principali problemi ed errori e prende appunti e condivide idee su possibili passi successivi o ostacoli.
Il Pair Programming si fa meglio quando i membri del team sono nello stesso posto.
I professionisti di Agile Testing e Quality Control hanno un livello fondamentale di comprensione dell'integrazione delle pratiche di marketing in SMART Agile.
I generalisti SMART Agile certificati hanno conoscenza e comprensione del ruolo di Development Team Member in Agile.
