Una dichiarazione sui valori che sono alla base dello sviluppo del software agile. I valori sono: • Individui e interazioni più di processi e strumenti • Software funzionante più di documentazione completa • Collaborazione con i clienti più di negoziazione contrattuale • Risposta al cambiamento più del rispetto di un piano.
Pratica di testing, adottata nell’ambito di un progetto che utilizzi metodologie Agile, incorporanti tecniche e metodi come la extreme programming (XP), che tratta lo sviluppo come il “cliente” del testing, enfatizzando quindi il paradigma di progettazione test-first.
Un ambiente comprendente hardware, strumentazione, simulatori, strumento software ed altri elementi di supporto necessari per condurre un test.
Analisi del codice sorgente condotta senza l’esecuzione del software stesso.
Utente o ogni altra persona od altro sistema che interagiscono col sistema in test con particolari modalità.
L’uso di software, ad esempio strumento di cattura/riproduzione, per controllare l’esecuzione dei test, per confrontare i risultati effettivi con quelli attesi, per descrivere le precondizioni e gli altri controlli dei test e per rediger rapporti.
Un metodo o una pratica innovativa che contribuisce a migliorare le performance di una organizzazione in un dato contesto. Eessi sono normalmente considerati il metodo o la pratica ‘migliore’ da altre organizzazione che operano nel medesimo contesto.
Una attività di sviluppo nella quale un sistema completo viene compilato e “linkato” ogni giorno (generalmente durante la notte) in modo che in ogni momento si possa disporre di un sistema consistente che includa tutte le ultime modifiche
Una sequenza di eventi (ad esempio istruzioni eseguibili) di un componente o sistema, da un punto di ingresso ad un punto di uscita.
Un cammino che non può essere attivato da nessun insieme dei possibili valori di input.
Un attributo di un componente o sistema specificato (o derivante) dalla documentazione dei requisiti. (per esempio affidabilità, usabilità o vincoli di progettazione)
Il periodo di tempo che inizia quando un prodotto software viene concepito e termina quando non è più disponibile per essere utilizzato. Il ciclo di vita del software tipicamente include le fasi: concettuale, requisiti, progettazione, implementazione, test, installazione, operativa, manutenzione e, a volte, il ritiro del software. Si noti che queste fasi posso sovrapporsi o essere svolte in modo iterativo.
Il grado con cui un componente on un sistema può scambiare informazioni con altri componenti o sistemi
Il grado con cui un componente o sistema ha una progettazione e/o una struttura interna che è difficile da comprendere, mantenere e verificare.
La composizione di un componente o di un sistema come definito dal numero, dalle caratteristiche e dalle interrelazioni delle sue parti (SW, HW o altro) costituenti.
Le tecniche ed attività operative, parte della gestione della qualità, focalizzate sulla soddisfazione dei requisiti di qualità.
Una rappresentazione di misure dinamiche di performance operativa per una attività od organizzazione, utilizzando metriche rappresentate con metafore visive come "quadranti","grafi" e altri dispositivi simili a quelli del cruscotto di un'automobile, in modo che gli effetti di eventi o attività possano essere facilmente compresi e correlati agli obiettivi operativi.
Una istruzione eseguibile in cui ad una variabile viene assegnato un valore.
Una azione umana che produce un risultato scorretto.
Le percezioni e le risposte di una persona derivanti dall'utilizzo o dall'utilizzo previsto di un prodotto software.
Una regola empirica generalmente accettata, che aiuta a raggiungere un certo obiettivo.
Una metodologia di ingegneria del software utilizzata all'interno dello sviluppo software “agile” , le cui pratiche fondamentali sono: la programmazione a coppie, le revisioni estese del codice, lo unit test di tutte le parti di codice e la semplicità e la chiarezza nella codifica.
Un test è considerato fallito se il suo risulta attuale non corrisponde al suo risultato atteso.
Un metodo per la gestione e la misurazione di test a sessioni, ad esempio testing sperimentale.
Un grafico visualizzato pubblicamente che raffigura lo sforzo residuo nel tempo in uno sprint (iterazione). L’asse x rappresenta normalmente la durata in giorni dello sprint, mentre l'asse y evidenzia lo sforzo residuo (espresso di solito in ore “ideal” o “story points”).
Il processo di combinazione di componenti o sistemi in aggregati più grandi
Tutti i componenti di un sistema che forniscono informazioni e controlli per l'utente per svolgere specifich e attivitàcon il sistema stesso.
Una entità in un linguaggio di programmazione, la quale è tipicamente la più piccola indivisibile unità di esecuzione.
Un diagramma utilizzato per rappresentare parole, idee, attività o altri elementi connessi e disposti intorno ad una parola chiave o idea centrale. Le mappe mentali sono utilizzate per generare, visualizzare, strutturare e classificare le idee e come aiuto nelle attività di analisi, organizzazione, risoluzione di problemi, presa di decisioni e documentazione..
Una scala di misurazione e il metodo usato per la misurazione.
Un programma di attività progettato per migliorare le performance e la maturità dei processi delle organizzazioni e il risultato di tale programma.
Il numero o la categoria assegnata ad un attributo di una entità ottenuto da una misurazione.
Un ciclo di vita dello sviluppo nel quale un progetto viene suddiviso in un numero generalmente elevato di iterazioni. Una iterazione è un ciclo di sviluppo completo che termina con un rilascio (interno od esterno) di un prodotto eseguibile ( un sottoinsieme del prodotto finale) il quale si accresce ad ogni iterazione per diventare il prodotto finale.
La attività di redazione o modifica di un piano di test.
Una tecnica di stima basata sul consenso, principalmente utilizzata per stimare lo sforzo o la dimensione relativa di storie di utente nello sviluppo software agile. È una variante del metodo Delphi a banda larga utilizzando un mazzo di carte con i valori che rappresentano le unità di stima del team.
Il livello di importanza (di business) assegnato ad un elemento, ad esempio un difetto.
Un insieme di attività correlate tra loro, le quali trasformano un input in output.
Un insieme di attività coordinate e controllate con date di inizio e di fine, intraprese per realizzare un obiettivo che sia conforme ai requisiti specificati, compresi i vincoli temporali, di costo e di risorse.
Raccolta e analisi di dati provenienti dalle attività di test e successivo loro consolidamento in un report per informare le parti interessate.
Un fattore che potrebbe avere negative conseguenze future, generalmente espresso come impatto e probabilità.
L’esito dell’esecuzione di un test. Esso include gli output, le modifiche ai dati, i report ed i messaggi di comunicazione esterni.
Un risultato di una valutazione che identifica alcuni importanti problemi o opportunità.
Una riunione alla fine di un progetto, durante la quale i membri del team valutano lo svolgimento ed i risultati del progetto e ne deducono degli insegnamenti che possono essere applicati ai progetti successivi.
Il grado con il quale un componente od un sistema può funzionare correttamente in presenza di input invalidi o di condizioni ambientali di stress.
Una metodologia incrementale ed iterativa per la gestione di progetti comunemente utilizzata nello sviluppo software “agile”.
Un periodo di tempo ininterrotto trascorso nell’esecuzione di test. Nel testing esplorativo, ogni sessione di test è focalizzata su una dichiarazione di test, ma i tester possono anche esplorare nuove opportunità durante una sessione. Il tester crea ed esegue i casi di test al volo e registra il loro avanzamento.
Il grado dell’impatto che un difetto ha sullo sviluppo o l’operatività di un componente o di un sistema.
La rappresentazione delle caratteristiche comportamentali selezionate di un sistema astratto o fisico da parte di un altro sistema.
Programmi, procedure, possibilmente con associata documentazione e dati pertinenti all’operatività del sistema informatico.
Un documento che specifica (auspicabilmente in maniera completa, precisa e verificabile) i requisiti, la progettazione, il comportamento od altre caratteristiche di un componente o sistema e, spesso, le relative procedure per determinare se queste clausole sono state soddisfatte.
Un insieme di requisiti, formali ed a volte obbligatori, sviluppati e utilizzati per prescrivere approcci coerenti al modo di lavorare o per fornire linee guida (ad esempio, norme ISO / IEC, standard IEEE e standard organizzativi).
Uno strumento di test che è in grado di eseguire test su uno specifico elemento di test e valutare gli esiti rispetto ai risultati attesi e alle postcondizioni.
Uno strumento che supporta la registrazione dei requisiti, degli attributi dei requisiti (ad esempio, priorità, responsabile del processo etc.) e di altre annotazioni, e che agevola la tracciabilità e la gestione delle modifiche dei requisiti attraverso le varie fasi del ciclo di sviluppo/modifica . Alcuni strumenti di gestione dei requisiti forniscono anche supporto per l’analisi statica, come ad esempio controlli di consistenza e violazioni a predefinite regole di specifica dei requisiti.
Una tipologia di strumenti di test, che consente di selezionare i dati da database esistenti o di crearli, manipolarli ed editarli per l’utilizzo nel testing.
Uno strumento che supporta le attività di progettazione dei test, generando input di test da una specifica, che può essere mantenuta in un archivio ( per esempio in uno strumento di gestione dei requisiti), partendo da condizioni di test detenute nello strumento stesso o dal codice.
Uno strumento che fornisce un ambiente per il testing di unità o componente nel quale un componente può essere testato in isolamento o con stub e driver. Esso fornisce di solito anche altri supporti per lo sviluppatore, ad esempio funzionalità di debugging.
Un test è considerato superato se il suo risultato effettivo corrisponde al suo risultato atteso
Un gruppo di metodologie di sviluppo software basate sullo sviluppo incrementale iterativo, in cui i requisiti e le soluzioni evolvono tramite una stretta collaborazione tra team inter-funzionali che si auto-organizzano.
Un insieme di uno o più casi di test.
Test basati sull'esperienza, sulla conoscenza e sull'intuito del tester.
Un insieme di test automatizzati che convalida l'integrità della compilazione di ogni nuova build e ne verifica la funzionalità, la stabilità e la testabilità. È una pratica comune di fronte ad un'alta frequenza di creazione di nuove build (ad es., progetti agile) che viene eseguita su ogni nuova build prima di essere rilasciata per ulteriori test.
Testing che si basa su o comporta l'uso di modelli
Una tecnica black-box di progettazione del testing nella quale i casi di test vengono selezionati, possibilmente usando un algoritmo di generazione pseudo-casuale, per corrispondere ad un profilo operativo. Questa tecnica può essere usata per il testing di attributi non-funzionali, come ad esempio affidabilità e performance,
Testing che utilizza varie tecniche per gestire il rischio di regressione ,e.g., progettando del testware riutilizzabile ed automatizzando intensamente uno o più livelli di test.
Una coppia di persone (ad esempio due tester, uno sviluppatore e un tester, oppure un utente finale ed un tester), che lavorano assieme per trovare difetti. Tipicamente, essi condividono un computer e prendono il controllo di esso durante il testing.
Tecnica di testing che risponde dinamicamente al sistema in test reale, ottenendo i relativi risultati. Esso ha normalmente un ciclo di pianificazione ridotto e le fasi di progettazione ed implementazione dei test non sono svolte sino al ricevimento del software.
Testing basato su un’analisi della struttura interna del componente o sistema.
Il tracciamento dei requisiti di un certo livello di test attraverso gli strati della documentazione disponibile (ad esempio, piano di test, specifica di progettazione dei test, specifica dei test case, specifica della procedura di test o script di test).
Conferma per esame (e attraverso la fornitura di evidenze obiettive) che i requisiti, per un uso specifico e predefinito o per una applicazione, sono stati soddisfatti.
Un elemento di memorizzazione in un computer che è accessibile da un programma software tramite un nome di riferimento.
Conferma per esame (e attraverso la fornitura di evidenze obiettive) che specifici requisiti sono stati soddisfatti.