ISTQB Foundation Level - 2 Il Testing all’interno del Ciclo di Vita dello Sviluppo Software Flashcards
(116 cards)
1
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Cos’è un modello del ciclo di vita dello sviluppo software?
A
Un modello che descrive le attività eseguite in ogni fase di un progetto di sviluppo software e come si relazionano tra loro in modo logico e cronologico.
2
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Qual è il principio del testing anticipato?
A
Iniziare le attività di test nelle prime fasi del ciclo di vita dello sviluppo software per individuare e risolvere i problemi il più presto possibile.
3
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Cosa descrive il modello a cascata (Waterfall)?
A
Un modello di sviluppo sequenziale in cui le attività di sviluppo (analisi dei requisiti, progettazione, codifica, testing) vengono completate in sequenza, una dietro l’altra.
4
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
In cosa consiste il V-Model?
A
Un modello di sviluppo sequenziale che implementa il principio del testing anticipato, integrando il processo di test nel processo di sviluppo e associando un livello di test alla corrispondente fase di sviluppo.
5
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Cos’è lo sviluppo incrementale?
A
Un modello di sviluppo in cui le attività di definizione dei requisiti, progettazione, sviluppo e testing di un sistema vengono eseguite in parti, con una crescita incrementale delle funzionalità software.
6
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Cos’è lo sviluppo iterativo?
A
Un modello di sviluppo in cui gruppi di funzionalità vengono specificati, progettati, sviluppati e testati insieme, in una serie di cicli spesso di durata fissa.
7
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Che cos’è Scrum?
A
Un modello di sviluppo iterativo con iterazioni di breve durata che produce incrementi di funzionalità piccoli e frequenti.
8
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Che cos’è Kanban?
A
Un modello di sviluppo che può essere implementato con o senza iterazioni di durata fissa, rilasciando singole funzionalità complete o miglioramenti, oppure raggruppando un insieme di funzionalità in un unico rilascio.
9
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
In che modo i modelli del ciclo di vita dello sviluppo software devono essere adattati al contesto del progetto?
A
Devono essere selezionati e adattati in base all’obiettivo del progetto, al tipo di prodotto da sviluppare, alle priorità di business e ai rischi di prodotto e di progetto identificati.
10
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Qual è un esempio di combinazione di modelli del ciclo di vita dello sviluppo software?
A
Utilizzare il V-Model per lo sviluppo e il testing dei sistemi di back-end e un modello Agile per lo sviluppo e il testing dell’interfaccia utente (UI) di front-end e delle funzionalità.
11
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Quali sono i due tipi principali di modelli del ciclo di vita dello sviluppo software?
A) Sequenziali e iterativi
B) Anticipati e tardivi
C) Modulari e monolitici
D) Waterfall e Agile
A
A) Sequenziali e iterativi
12
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Qual è il vantaggio principale dell’adozione di un modello Agile per lo sviluppo software?
A) Richiede meno tempo per lo sviluppo
B) Migliora la qualità del codice
C) Consente una maggiore adattabilità ai cambiamenti
D) Riduce i costi di sviluppo
A
C) Consente una maggiore adattabilità ai cambiamenti
13
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Quale modello del ciclo di vita dello sviluppo software è basato su un approccio sequenziale e prevede il testing anticipato?
A) Waterfall
B) V-Model
C) Scrum
D) Kanban
A
B) V-Model
14
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Quale di queste metodologie utilizza una serie di “sprint” per lo sviluppo e il rilascio di funzionalità incrementali?
A) Waterfall
B) V-Model
C) Scrum
D) Kanban
A
C) Scrum
15
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
In quale modello del ciclo di vita dello sviluppo software le attività di sviluppo e testing vengono eseguite in parallelo?
A) Waterfall
B) V-Model
C) Incrementale
D) Iterativo
A
D) Iterativo
16
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Quale modello del ciclo di vita dello sviluppo software è più adatto a progetti con requisiti stabili e ben definiti?
A) Waterfall
B) V-Model
C) Scrum
D) Kanban
A
A) Waterfall
17
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Quale di queste metodologie Agile prevede la gestione del flusso di lavoro attraverso una “tabella Kanban”?
A) Waterfall
B) V-Model
C) Scrum
D) Kanban
A
D) Kanban
18
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
In quale modello del ciclo di vita dello sviluppo software il prodotto viene sviluppato in parti, con una crescita incrementale delle funzionalità software?
A) Waterfall
B) V-Model
C) Incrementale
D) Iterativo
A
C) Incrementale
19
Q
2.1 Modelli del Ciclo di Vita dello Sviluppo Software
Qual è un esempio di un modello di sviluppo sequenziale?
A) Scrum
B) Kanban
C) Waterfall
D) Agile
A
C) Waterfall
20
Q
2.2 Livelli di Test
Cos’è il test dei componenti?
A
È un tipo di test di sviluppo che verifica la correttezza e la robustezza dei singoli componenti di un sistema.
21
Q
2.2 Livelli di Test
Qual è l’obiettivo principale del test di integrazione?
A
Verificare la correttezza e la robustezza delle interazioni tra i componenti di un sistema.
22
Q
2.2 Livelli di Test
Quali sono gli oggetti di test nel test di sistema?
A
Il sistema completo, le interfacce esterne e le configurazioni.
23
Q
2.2 Livelli di Test
Qual è lo scopo degli User Acceptance Test (UAT)?
A
Validare l’idoneità all’utilizzo del sistema da parte degli utenti previsti.
24
Q
2.2 Livelli di Test
Cosa si intende per Operational Acceptance Test (OAT)?
A
È un tipo di test di accettazione che verifica gli aspetti operativi del sistema, come backup, disaster recovery e sicurezza.
25
# **2.2** Livelli di Test
**Qual è l'obiettivo del testing di accettazione contrattuale?**
**Verificare** la **conformità** del **sistema** ai **requisiti contrattuali** **specificati**.
26
# **2.2** Livelli di Test
**Che cosa sono gli Alpha test e Beta test?**
Sono **tipi di test** di **accettazione** **utilizzati** per **raccogliere** **feedback** dagli **utenti** **potenziali** o **esistenti**, dai **clienti** e dagli **operatori**.
27
# **2.2** Livelli di Test
**Cosa si intende per "base di test"?**
Sono i **prodotti** di **lavoro** **utilizzati** come **riferimento** per la **creazione** e l'**esecuzione** dei **test case**.
28
# **2.2** Livelli di Test
**Quali sono alcuni difetti tipici nel test di sviluppo?**
**Errori di logica**, **errori di interfaccia**, **problemi di comunicazione** e **problemi di integrazione**.
29
# **2.2** Livelli di Test
**Quali sono alcuni difetti tipici nel test di accettazione?**
**Workflow** di **sistema** non **conformi** ai **requisiti**, **regole** di **business** **non** **implementate** **correttamente**, **requisiti contrattuali** o **normativi** **non soddisfatti**, **failure non-funzionali**.
30
# **2.2** Livelli di Test
**Quali sono gli obiettivi del test di sistema?**
## Footnote
**A)** Verificare il backup dei dati
**B)** Verificare le interazioni tra i componenti
**C)** Verificare che il sistema soddisfi i requisiti funzionali e non funzionali
**D)** Validare l'idoneità all'utilizzo del sistema da parte degli utenti
**C)** Verificare che il sistema soddisfi i requisiti funzionali e non funzionali
31
# **2.2** Livelli di Test
**Quali prodotti di lavoro sono tipicamente utilizzati come base di test per il test di accettazione?**
## Footnote
**A)** Processi di business
**B)** Specifiche dei componenti
**C)** Modelli di progettazione
**D)** Codice sorgente
**A)** Processi di business
32
# **2.2** Livelli di Test
**In quale fase del ciclo di vita di sviluppo si svolge tipicamente il test di accettazione?**
## Footnote
**A)** Prima del test di sistema
**B)** Durante il test di sistema
**C)** Dopo il test di sistema
**D)** Contemporaneamente al test di sistema
**C)** Dopo il test di sistema
33
# **2.2** Livelli di Test
**In quali situazioni è tipico svolgere il test di accettazione normativo?**
## Footnote
**A)** Quando si devono rispettare specifiche normative governative o legali
**B)** Quando si verifica la correttezza delle interazioni tra componenti
**C)** Quando si esegue un test per verificare la robustezza del sistema
**D)** Quando si testano le funzionalità di un sistema
**A)** Quando si devono rispettare specifiche normative governative o legali
34
# **2.2** Livelli di Test
**Cosa si intende per "oggetti di test"?**
## Footnote
**A)** I documenti di progetto utilizzati per creare i test case
**B)** Gli strumenti utilizzati per eseguire i test
**C)** Gli elementi specifici del sistema che vengono testati
**D)** I risultati dei test precedentemente eseguiti
**C)** Gli elementi specifici del sistema che vengono testati
35
# **2.2** Livelli di Test
**Qual è uno degli obiettivi principali degli Alpha e Beta test?**
## Footnote
**A)** Identificare errori di logica nel codice sorgente
**B)** Verificare la correttezza delle interazioni tra componenti
**C)** Aumentare la fiducia nella capacità degli utenti di utilizzare il sistema in condizioni normali
**D)** Verificare la conformità ai requisiti contrattuali
**C)** Aumentare la fiducia nella capacità degli utenti di utilizzare il sistema in condizioni normali
36
# **2.2** Livelli di Test
**Qual è l'obiettivo principale del testing di accettazione?**
## Footnote
**A)** Verificare la conformità ai requisiti di sistema
**B)** Testare la robustezza dei singoli componenti
**C)** Stabilire confidenza sulla qualità del sistema completo
**D)** Identificare errori di logica nel codice sorgente
**C)** Stabilire confidenza sulla qualità del sistema completo
37
# **2.2** Livelli di Test
**Quali sono alcuni esempi di difetti tipici nel test di sistema?**
**A)** Errori nei processi di business
**B)** Requisiti non funzionali non soddisfatti
**C)** Errori di interfaccia tra componenti
**D)** Errori di logica nel codice sorgente
**B)** Requisiti non funzionali non soddisfatti
38
# **2.2** Livelli di Test
**Qual è l'obiettivo principale del testing di accettazione contrattuale e normativo?**
## Footnote
**A)** Aumentare la fiducia che sia stata raggiunta la conformità contrattuale o normativa
**B)** Identificare errori di logica nel codice sorgente
**C)** Verificare la correttezza delle interazioni tra componenti
**D)** Testare la robustezza dei singoli componenti
**A)** Aumentare la fiducia che sia stata raggiunta la conformità contrattuale o normativa
39
# **2.2** Livelli di Test
**Qual è uno degli obiettivi principali del testing di sistema?**
**Verificare che il sistema soddisfi i requisiti funzionali e non funzionali**
40
# **2.3** Tipi di Test
**Cos'è il testing del software?**
Il **processo** di **valutazione** delle **funzionalità** di un **software** per **garantire** che **soddisfi** i **requisiti** di **qualità**.
41
# **2.3** Tipi di Test
**Qual è lo scopo del testing del software?**
**Identificare** e **risolvere** **problemi**, **errori** e **difetti** nel **software**.
42
# **2.3** Tipi di Test
**Quali sono i due tipi principali di testing del software?**
**Testing funzionale** e **non funzionale**.
43
# **2.3** Tipi di Test
**Cos'è il testing funzionale?**
Il testing che **verifica** se il **software** **soddisfa** i **requisiti** **specificati**.
44
# **2.3** Tipi di Test
**Cos'è il testing non funzionale?**
Il testing che **valuta** **attributi** come **prestazioni**, **sicurezza** e **usabilità**.
45
# **2.3** Tipi di Test
**Qual è la differenza tra testing manuale e automatico?**
Il **testing** **manuale** viene **eseguito** da **persone**, mentre il **testing** **automatico** utilizza **strumenti** e **script** per eseguire test.
46
# **2.3** Tipi di Test
**Cosa significa l'acronimo "ISTQB"?**
**International Software Testing Qualifications Board**.
47
# **2.3** Tipi di Test
**Qual è il vantaggio del testing automatico rispetto al testing manuale?**
**Maggiore efficienza**, **precisione** e **velocità** nell'**esecuzione** dei **test**.
48
# **2.3** Tipi di Test
**Cos'è un caso di test?**
Un **insieme** di **condizioni** o **variabili** **utilizzate** per **determinare** se un **sistema soddisfa** i **requisiti**.
49
# **2.3** Tipi di Test
**Qual è lo scopo di un piano di test?**
**Definire** l'**approccio**, le **risorse** e il **programma del testing**.
50
# **2.3** Tipi di Test
**Quali sono gli obiettivi del testing del software?**
## Footnote
**A)** Trovare errori
**B)** Garantire la qualità
**C)** Validare le funzionalità
**D)** Tutte le risposte sono corrette
**D)** Tutte le risposte sono corrette
## Footnote
Trovare errori, Garantire la qualità e Validare le funzionalità
51
# **2.3** Tipi di Test
**Quali sono i due tipi di testing non funzionale?**
## Footnote
**A)** Sicurezza e prestazioni
**B)** Sicurezza e funzionalità
**C)** Funzionalità e prestazioni
**D)** Funzionalità e usabilità
**A)** Sicurezza e prestazioni
52
# **2.3** Tipi di Test
**Che cosa è il test di regressione?**
## Footnote
**A)** Testare nuove funzionalità
**B)** Testare le prestazioni del software
**C)** Testare la sicurezza del software
**D)** Verificare che le modifiche non abbiano introdotto nuovi errori
**D)** Verificare che le modifiche non abbiano introdotto nuovi errori
53
# **2.3** Tipi di Test
**Qual è l'obiettivo del test di accettazione?**
## Footnote
**A)** Valutare la funzionalità del software
**B)** Valutare la sicurezza del software
**C)** Valutare la qualità del software
**D)** Valutare la soddisfazione del cliente
**D)** Valutare la soddisfazione del cliente
54
# **2.3** Tipi di Test
**Qual è la finalità del test di sistema?**
## Footnote
**A)** Verificare le singole componenti del software
**B)** Valutare l'integrazione delle componenti del software
**C)** Testare l'intero sistema come un'entità unica
**D)** Valutare la sicurezza del software
**C)** Testare l'intero sistema come un'entità unica
55
# **2.3** Tipi di Test
**A cosa serve il test di integrazione?**
## Footnote
**A)** Testare singole componenti del software
**B)** Valutare la combinazione di componenti del software
**C)** Testare l'intero sistema come un'entità unica
**D)** Valutare la sicurezza del software
**B)** Valutare la combinazione di componenti del software
56
# **2.3** Tipi di Test
**In quale fase del ciclo di vita del software il testing viene solitamente eseguito?**
## Footnote
**A)** Analisi dei requisiti
**B)** Progettazione
**C)** Implementazione
**D)** Manutenzione
**C)** Implementazione
57
# **2.3** Tipi di Test
**Qual è l'obiettivo del test unitario?**
## Footnote
**A)** Verificare le singole componenti del software
**B)** Valutare l'integrazione delle componenti del software
**C)** Testare l'intero sistema come un'entità unica
**D)** Valutare la soddisfazione del cliente
**A)** Verificare le singole componenti del software
58
# **2.3** Tipi di Test
**Cos'è un bug tracking system?**
## Footnote
**A)** Un sistema per monitorare le prestazioni del software
**B)** Un sistema per gestire e tenere traccia degli errori nel software
**C)** Un sistema per gestire i casi di test
**D)** Un sistema per pianificare i test del software
**B)** Un sistema per gestire e tenere traccia degli errori nel software
59
# **2.3** Tipi di Test
**Cosa indica il termine "test coverage"?**
## Footnote
**A)** La quantità di codice testato
**B)** La qualità del testing
**C)** La velocità del testing
**D)** Il grado di soddisfazione del cliente
**A)** La quantità di codice testato
60
# **2.4** Testing di Manutenzione
**Cos'è il testing di manutenzione?**
Il testing di manutenzione è **eseguito** per **valutare** il **successo** delle **modifiche** **implementate** e per **verificare** **eventuali** **side-effect** (regressioni) in **parti** del **sistema** rimaste **invariate**.
61
# **2.4** Testing di Manutenzione
**Quando è necessaria la manutenzione del software?**
La manutenzione è **necessaria** per **correggere** **difetti**, **aggiungere** **nuove** **funzionalità**, **eliminare** o **modificare** **funzionalità** esistenti e **preservare** o **migliorare** le **caratteristiche** di **qualità** **non-funzionali** del software.
62
# **2.4** Testing di Manutenzione
**Quali sono i due tipi di rilasci di manutenzione?**
**Rilasci pianificati** e **rilasci non pianificati** (hot fix).
63
# **2.4** Testing di Manutenzione
**Quali sono i trigger principali per la manutenzione del software?**
**Modifica**, **migrazione** e **ritiro**.
64
# **2.4** Testing di Manutenzione
**Quali sono alcuni esempi di test operativi durante la migrazione di un software?**
**Test operativi** nel **nuovo** **ambiente** e **test di conversione** dei **dati**.
64
# **2.4** Testing di Manutenzione
**Quali attività di test potrebbero essere necessarie durante il ritiro di un software?**
**Test** di **migrazione** dei **dati**, test di **archiviazione** dei **dati**, test delle **procedure** di **retrieve/restore** dei **dati** e **regression** **testing**.
65
# **2.4** Testing di Manutenzione
**Cosa si intende per analisi degli impatti nel contesto del testing di manutenzione?**
L'analisi degli impatti **valuta** le **modifiche** **apportate** in un **rilascio** di **manutenzione** per **individuare** le **conseguenze** **attese**, i possibili **side-effect** e le **aree del sistema impattate dalle modifiche**.
66
# **2.4** Testing di Manutenzione
**Perché l'analisi degli impatti può essere difficile?**
L'analisi degli impatti può essere **difficile** a causa di **specifiche** **non** **aggiornate** o **mancanti**, **test case non documentati** o **non aggiornati**, **tracciabilità bidirezionale** **non mantenuta**, **supporto degli strumenti debole** o **inesistente** e **scarsa conoscenza** del dominio o del sistema.
67
# **2.4** Testing di Manutenzione
**In quali situazioni l'analisi degli impatti può essere svolta prima che venga apportata una modifica?**
L'analisi degli impatti può essere **svolta** **prima** dell'**implementazione** di una **modifica** per **aiutare** a **decidere** se la **modifica** **debba** **essere** **implementata**, in base alle **potenziali** **conseguenze** in **altre** **aree** del **sistema**.
68
# **2.4** Testing di Manutenzione
**Quali aspetti del testing di manutenzione sono particolarmente importanti per i sistemi Internet of Things (IoT)?**
Il testing di manutenzione per i sistemi IoT pone particolare **enfasi** sul **testing di integrazione** a **differenti** **livelli** e sugli **aspetti** di **sicurezza**, in particolare quelli **relativi** ai **dati personali**.
69
# **2.4** Testing di Manutenzione
**Qual è lo scopo principale del testing di manutenzione?**
## Footnote
**A)** Valutare il successo delle modifiche implementate
**B)** Verificare eventuali side-effect
**C)** Testare le nuove funzionalità
**D)** Migliorare le prestazioni del software
**A)** Valutare il successo delle modifiche implementate
70
# **2.4** Testing di Manutenzione
**Quali caratteristiche di qualità non-funzionali possono essere preservate o migliorate tramite la manutenzione del software?**
## Footnote
**A)** Efficienza delle prestazioni
**B)** Compatibilità
**C)** Affidabilità
**D)** Tutte le opzioni precedenti
**D)** Tutte le opzioni precedenti
71
# **2.4** Testing di Manutenzione
**Quali tipi di manutenzione possono comportare rilasci non pianificati?**
## Footnote
**A)** Miglioramenti pianificati
**B)** Modifiche correttive
**C)** Aggiornamenti del sistema operativo
**D)** Hot fix
**D)** Hot fix
72
# **2.4** Testing di Manutenzione
**Perché potrebbe essere necessario il regression testing durante il ritiro di un'applicazione?**
## Footnote
**A)** Per verificare la conversione dei dati
**B)** Per testare le procedure di retrieve/restore dei dati
**C)** Per garantire il corretto funzionamento delle funzionalità ancora in servizio
**D)** Per identificare side-effect nelle aree del sistema impattate
**C)** Per garantire il corretto funzionamento delle funzionalità ancora in servizio
73
# **2.4** Testing di Manutenzione
**Quali sono i principali livelli di integrazione testati nel testing di manutenzione per i sistemi IoT?**
| **Piu di una esatta**
## Footnote
**A)** Livello applicativo
**B)** Livello di rete
**C)** Livello di sistema
**D)** Livello funzionale
A e B
## Footnote
Livello applicativo e Livello di rete
74
# **2.4** Testing di Manutenzione
**Qual è uno dei principali ostacoli all'analisi degli impatti?**
## Footnote
**A)** Mancanza di comunicazione tra i membri del team
**B)** Tracciabilità bidirezionale tra test e base di test non mantenuta
**C)** Scarsa qualità del software
**D)** Mancanza di strumenti di testing adeguati
**B)** Tracciabilità bidirezionale tra test e base di test non mantenuta
75
# **2.4** Testing di Manutenzione
**Quali sono gli obiettivi dell'analisi degli impatti?**
| **Piu di una esatta**
## Footnote
**A)** Valutare il successo delle modifiche implementate
**B)** Individuare le conseguenze attese e i possibili side-effect delle modifiche
**C)** Identificare le aree del sistema impattate dalle modifiche
**D)** Verificare la presenza di difetti nei requisiti
**B e C**
## Footnote
Individuare le conseguenze attese e i possibili side-effect delle modifiche e Identificare le aree del sistema impattate dalle modifiche
76
# **2.4** Testing di Manutenzione
**Quali tipi di test potrebbero essere necessari durante la migrazione di un software?**
| **Piu di una esatta**
## Footnote
**A)** Test operativi nel nuovo ambiente
**B)** Test di conversione dei dati
**C)** Test di funzionalità
**D)** Test di velocità
**A e B**
## Footnote
Test operativi nel nuovo ambiente e Test di conversione dei dati
77
# **2.4** Testing di Manutenzione
**In che modo l'analisi degli impatti può aiutare a decidere se una modifica debba essere implementata?**
## Footnote
**A)** Valutando le conseguenze in altre aree del sistema
**B)** Identificando l'impatto della modifica sui test esistenti
**C)** Verificando la presenza di side-effect nelle aree del sistema impattate
**D)** Valutando la qualità del software modificato
**A)** Valutando le conseguenze in altre aree del sistema
78
# **2.4** Testing di Manutenzione
**Perché l'analisi degli impatti può essere difficile se le specifiche non sono aggiornate o mancanti?**
| **Piu di una esatta**
## Footnote
**A)** Rende difficile individuare le conseguenze attese delle modifiche
**B)** Impedisce di identificare le aree del sistema impattate dalle modifiche
**C)** Rende difficile valutare il successo delle modifiche implementate
**D)** Rende difficile indentificare le funzionalità nascoste
**A e B**
79
Definisci **Alpha testing**:
**L'Alpha testing è un tipo di test eseguito internamente da sviluppatori e tester interni per identificare e correggere bug prima di passare alla fase successiva del testing, il Beta testing.**
80
Definisci **Ambiente di test**:
**L'ambiente di test è un insieme di hardware, software e configurazioni di rete utilizzato per eseguire test su un'applicazione o un sistema, simulando condizioni simili a quelle dell'ambiente di produzione.**
81
Definisci **Analisi degli impatti**:
**L'analisi degli impatti è un processo che valuta le modifiche apportate a un software per identificare le conseguenze attese, i possibili side-effect e le aree del sistema impattate dalle modifiche.**
82
Definisci **Base di test**:
**La base di test è l'insieme di documenti, requisiti, specifiche e casi d'uso che forniscono la base per la progettazione e l'esecuzione dei test case.**
83
Definisci **Beta testing**:
**Il Beta testing è un tipo di test eseguito da un gruppo limitato di utenti esterni in un ambiente reale, al fine di ottenere feedback sugli eventuali problemi riscontrati e valutare l'usabilità del prodotto.**
84
Definisci **COTS (Commercial Off-The-Shelf)**:
**I COTS sono prodotti software preconfezionati e pronti all'uso, sviluppati e venduti sul mercato per soddisfare esigenze comuni, anziché essere realizzati su misura per un singolo cliente.**
85
Definisci **Livello di test**:
**Il livello di test si riferisce alla fase specifica del processo di test in cui si eseguono test su un'applicazione o un sistema, come il testing di componente, il testing di integrazione, il testing di sistema e il testing di accettazione.**
86
Definisci **Modello di sviluppo sequenziale**:
**Il modello di sviluppo sequenziale è un approccio alla creazione di software che segue una serie di fasi in ordine sequenziale, come l'analisi dei requisiti, la progettazione, l'implementazione, il testing e la manutenzione.**
87
Definisci **Obiettivo del test**:
**L'obiettivo del test è lo scopo specifico per cui un test viene eseguito, come identificare difetti, verificare la conformità ai requisiti, valutare le prestazioni o misurare la qualità del software.**
88
Definisci **oggetto di test**:
**L'oggetto di test si riferisce alla parte del sistema o dell'applicazione che viene testata. Questo può includere singoli componenti, il sistema nel suo complesso o una specifica funzionalità del sistema.**
89
Definisci **regression testing**:
**Regression testing è un processo di testing del software eseguito dopo le modifiche apportate al sistema o all'applicazione per assicurarsi che le modifiche non abbiano introdotto nuovi errori o causato problemi a funzionalità precedentemente funzionanti.**
90
Definisci **test case** (caso di test):
**Un test case, o caso di test, è una specifica delle attività di test da eseguire su una parte del sistema o dell'applicazione. Un test case può includere informazioni come i dati di input, le aspettative di output e le procedure di test.**
91
Definisci **testing basato sulle modifiche**:
**Il testing basato sulle modifiche è un processo di test del software che si concentra sul test delle funzionalità del sistema che sono state modificate o aggiunte. Questo tipo di testing è importante per garantire che le modifiche apportate al sistema non abbiano introdotto nuovi errori o causato problemi a funzionalità precedentemente funzionanti.**
92
Definisci **testing di accettazione**:
**Il testing di accettazione è un processo di testing del software eseguito per determinare se il sistema o l'applicazione soddisfa i requisiti specificati dal cliente o dall'utente finale.**
93
Definisci **testing di accettazione contrattuale**:
**Il testing di accettazione contrattuale è un processo di testing del software che verifica se il sistema o l'applicazione soddisfa tutti i requisiti specificati nel contratto tra il fornitore e il cliente.**
94
Definisci **testing di accettazione normativo**:
**Il testing di accettazione normativo è un processo di testing del software che verifica se il sistema o l'applicazione soddisfa tutti i requisiti normativi e di conformità.**
95
Definisci **testing di accettazione operativo**:
**Il testing di accettazione operativo è un processo di testing del software che verifica se il sistema o l'applicazione soddisfa tutti i requisiti operativi, come la disponibilità e le prestazioni.**
96
Definisci **testing di accettazione utente**:
**Il testing di accettazione utente è un processo di testing del software eseguito dagli utenti finali o dai rappresentanti degli utenti finali per verificare se il sistema o l'applicazione soddisfa le loro esigenze e aspettative.**
97
Definisci **testing di componente**:
**Il testing di componente è un processo di testing del software che si concentra sulle singole unità o componenti di un sistema o di un'applicazione.**
98
Definisci **testing confermativo**:
**Il testing confermativo è un processo di testing del software eseguito per verificare se il sistema o l'applicazione soddisfa i requisiti specificati.**
99
Definisci **testing funzionale**:
**Il testing funzionale è un tipo di testing del software che si concentra sulle funzionalità del sistema o dell'applicazione. Questo tipo di testing verifica se il sistema o l'applicazione funziona come previsto, eseguendo test sulle funzionalità specificate nei requisiti.**
100
Definisci **testing di integrazione**:
**Il testing di integrazione è un processo di testing del software che si concentra sulla verifica dell'integrazione tra i vari componenti del sistema o dell'applicazione. Questo tipo di testing verifica se i componenti funzionano correttamente insieme come previsto.**
101
Definisci **testing di integrazione dei componenti**:
**Il testing di integrazione dei componenti è un processo di testing del software che si concentra sulla verifica dell'integrazione tra i singoli componenti del sistema o dell'applicazione. Questo tipo di testing verifica se i componenti funzionano correttamente insieme come previsto.**
102
Definisci **testing di integrazione dei sistemi**:
**Il testing di integrazione dei sistemi è un processo di testing del software che si concentra sulla verifica dell'integrazione tra i diversi sistemi che compongono il sistema o l'applicazione. Questo tipo di testing verifica se i sistemi funzionano correttamente insieme come previsto.**
103
Definisci **testing di manutenzione**:
**Il testing di manutenzione è un processo di testing del software eseguito durante la fase di manutenzione del sistema o dell'applicazione. Questo tipo di testing verifica se le modifiche apportate al sistema o all'applicazione per correggere problemi o migliorare le prestazioni non hanno introdotto nuovi errori.**
104
Definisci **testing di sistema**:
**Il testing di sistema è un tipo di testing del software che verifica il sistema o l'applicazione come un insieme completo, verificando il funzionamento delle sue funzionalità come se fosse in uso reale.**
105
Definisci **testing non-funzionale**:
**Il testing non-funzionale è un tipo di testing del software che verifica i requisiti non-funzionali del sistema o dell'applicazione, come le prestazioni, la sicurezza e l'usabilità.**
106
Definisci **testing relativo a modifiche**:
**Il testing relativo a modifiche è un processo di testing del software eseguito dopo le modifiche apportate al sistema o all'applicazione per verificare che le modifiche siano state implementate correttamente e non abbiano introdotto nuovi errori.**
107
Definisci **testing white-box**:
**Il testing white-box è un tipo di testing del software in cui il tester ha conoscenza della struttura interna del sistema o dell'applicazione, inclusi i codici sorgente e le logiche di programmazione. Questo tipo di testing verifica il funzionamento interno del sistema o dell'applicazione.**
108
Ricordare: **Spiegare le relazioni tra attività di sviluppo software e attività di test nel ciclo di vita dello sviluppo software.**
**Le attività di sviluppo software e di test sono strettamente correlate nel ciclo di vita dello sviluppo software. Il testing viene eseguito per verificare che il software sviluppato soddisfi i requisiti specificati e funzioni correttamente. Pertanto, il testing viene eseguito durante ogni fase del ciclo di vita del software, a partire dalla fase di analisi dei requisiti fino alla fase di manutenzione.**
109
Comprendere: **Identificare le ragioni per cui i modelli del ciclo di vita dello sviluppo software devono essere adattati al contesto del progetto e alle caratteristiche del prodotto.**
**I modelli del ciclo di vita dello sviluppo software devono essere adattati al contesto del progetto e alle caratteristiche del prodotto perché ogni progetto e prodotto è unico e ha esigenze diverse. Ad esempio, un progetto che richiede un rilascio rapido potrebbe richiedere un modello di sviluppo agile, mentre un progetto con requisiti critici per la sicurezza potrebbe richiedere un modello di sviluppo a cascata. L'adattamento dei modelli del ciclo di vita consente di sviluppare il software in modo efficiente e di ottenere un prodotto di alta qualità.**
110
Comprendere: **Confrontare i diversi livelli di test dal punto di vista di obiettivi, basi di test, oggetti di test, difetti e failure tipici, approcci e responsabilità.**
**I diversi livelli di test includono il testing di componente, il testing di integrazione, il testing di sistema e il testing di accettazione. Ogni livello di test ha obiettivi specifici, basi di test, oggetti di test, difetti e failure tipici, approcci e responsabilità. Il testing di componente si concentra sulla verifica delle singole unità di codice, il testing di integrazione verifica l'integrazione tra le unità, il testing di sistema verifica il sistema nel suo complesso e il testing di accettazione verifica se il sistema soddisfa i requisiti del cliente.**
111
Comprendere: **Confrontare il testing funzionale, il testing non-funzionale e il testing white-box.**
**Il testing funzionale si concentra sulla verifica delle funzionalità del software, mentre il testing non-funzionale si concentra sulla verifica dei requisiti non funzionali, come la performance, la sicurezza e l'usabilità. Il testing white-box si concentra sulla verifica della logica interna del software, utilizzando la conoscenza del codice sorgente.**
112
Ricordare: **Riconoscere che i test funzionali, non funzionali e white-box si svolgono a qualsiasi livello di test.**
**I test funzionali, non funzionali e white-box possono essere eseguiti a qualsiasi livello di test, a seconda degli obiettivi specifici del livello di test.**
113
Comprendere: **Confrontare lo scopo del testing confermativo e del regression testing.**
**Il testing confermativo si concentra sulla verifica che il software soddisfi i requisiti specificati e funzioni come previsto. Il regression testing si concentra sulla verifica che le modifiche apportate al software non abbiano introdotto nuovi errori o non abbiano causato il fallimento delle funzionalità precedentemente funzionanti. Entrambi i tipi di test sono importanti per garantire la qualità del software.**
114
Comprendere: **Riepilogare i trigger per il testing di manutenzione.**
**Il testing di manutenzione può essere attivato da diversi trigger, come l'introduzione di nuove funzionalità, la correzione di bug o la modifica dell'ambiente operativo. Il testing di manutenzione è importante per garantire che le modifiche apportate al software non abbiano introdotto nuovi errori e che il software funzioni correttamente anche dopo le modifiche.**
115
Comprendere: **Descrivere il ruolo dell'analisi degli impatti nel testing di manutenzione.**
**L'analisi degli impatti è un'attività importante nel testing di manutenzione che si concentra sulla valutazione degli effetti delle modifiche apportate al software. L'analisi degli impatti aiuta a identificare i rischi potenziali delle modifiche, come la rottura di funzionalità esistenti o l'introduzione di nuovi bug. Inoltre, l'analisi degli impatti aiuta a identificare le aree del software che richiedono il testing e a pianificare le attività di testing di conseguenza.**
