CAP03 Flashcards
Fondamenti del Testing Statico
Il testing statico verifica la qualità del software senza eseguirlo. Vengono esaminati manualmente o con strumenti il codice, le specifiche e altri documenti di lavoro, per rilevare difetti e valutare aspetti come leggibilità e consistenza. Questo tipo di testing, usato sia per la verifica che per la validazione, coinvolge tester, rappresentanti di business e sviluppatori che collaborano per garantire che le user story siano chiare e contengano criteri di accettazione testabili.
L’analisi statica, spesso integrata nei framework di Continuous Integration, rileva problemi nel codice prima del testing dinamico e richiede meno sforzo, poiché non necessita di test case. Oltre a identificare difetti, è utile per valutare la manutenibilità e la sicurezza del codice.
Prodotti di Lavoro che possono essere esaminati dal Testing Statico
Quasi tutti i documenti e componenti di progetto, come requisiti, codice sorgente, piani di test e documentazione, possono essere esaminati con il testing statico. Qualsiasi cosa leggibile e comprensibile può essere sottoposta a review. Tuttavia, l’analisi statica richiede una struttura definita, come nel caso di codice o modelli formali
Valore del Testing Statico
Il testing statico rileva i difetti già nelle prime fasi dello sviluppo, aiutando a identificare problemi che il testing dinamico non può trovare, come codice inutilizzabile o difetti in documenti non eseguibili.
Differenze tra Testing Statico e Testing Dinamico
Il testing statico e il testing dinamico sono tecniche complementari usate per rilevare difetti, ma con differenze chiave. Il testing statico esamina il codice senza eseguirlo, individuando direttamente difetti in documenti, requisiti e codice inaccessibile, mentre il testing dinamico rileva i difetti attraverso l’esecuzione e l’analisi dei failure. Il testing statico è ideale per prodotti non eseguibili e per valutare qualità come la manutenibilità; il testing dinamico, invece, misura aspetti legati all’esecuzione, come l’efficienza. Difetti come ambiguità nei requisiti, inefficienze di progettazione e vulnerabilità alla sicurezza sono spesso rilevabili in modo più economico con il testing statico.
Vantaggi di un Feedback Anticipato
Un feedback anticipato e frequente consente di identificare problemi di qualità in tempo, evitando che il prodotto finale non soddisfi le aspettative degli stakeholder.
Attività del Processo di Review
Lo standard ISO/IEC 20246 descrive un processo di review strutturato e adattabile, che può essere personalizzato a seconda del livello di formalità richiesto. Il processo include diverse fasi:
Pianificazione: Definisce obiettivi, ambito, prodotto di lavoro, qualità da valutare, criteri di uscita e risorse necessarie.
Inizio della review: Garantisce che tutti i partecipanti comprendano il loro ruolo e abbiano accesso ai materiali di review.
Review individuale: I revisori esaminano il prodotto per identificare difetti, raccomandazioni e domande.
Comunicazione e analisi: Le anomalie vengono discusse in un meeting per determinarne la validità e assegnare eventuali azioni.
Correzione e reporting: Viene creato un report sui difetti trovati e, se i criteri di uscita sono soddisfatti, la review è completata.
Ruoli e Responsabilità nelle Review
Manager: Decide cosa deve essere sottoposto a review e fornisce risorse (staff e tempo).
Autore: Crea e corregge il prodotto di lavoro da revisionare.
Moderatore (Facilitatore): Garantisce l’efficacia dei review meeting, gestendo il tempo e creando un ambiente di discussione aperto.
Scribe (Recorder): Raccoglie le anomalie e memorizza le informazioni durante il meeting.
Reviewer: Esamina il prodotto, che può essere un membro del team, un esperto o un altro stakeholder.
Review Leader: Responsabile complessivo della review, organizza i dettagli e decide chi coinvolgere.
Tipi di Review
Esistono vari tipi di review, che vanno da quelle informali a quelle formali. Il livello di formalità dipende da fattori come il ciclo di vita dello sviluppo, la maturità del processo, la complessità del prodotto
Ogni tipo di review ha un livello di formalità diverso e viene scelto in base agli obiettivi, alle risorse disponibili, e alla criticità del prodotto da revisionare.
Review informale: Senza un processo definito e senza risultati documentati, l’obiettivo è trovare anomalie.
Walkthrough: Condotto dall’autore, l’autore guida i revisori attraverso il prodotto, spiegando le scelte fatte.
Review tecnica: Condotta da esperti, ha come scopo risolvere problemi tecnici, rilevare anomalie, e migliorare la qualità.
Ispezione: La review più formale, mirata a trovare il maggior numero di anomalie, Identificare problemi tecnici, migliorare la qualità del prodotto, prendere decisioni sui problemi tecnici, generare idee per miglioramenti e valutare la qualità del prodotto.
Fattori di Successo per le Review (60)
Il successo delle review dipende da diversi fattori chiave:
Obiettivi chiari: Definire obiettivi e criteri di uscita misurabili, senza concentrarsi sulla valutazione dei partecipanti.
Tipo di review appropriato: Scegliere il tipo di review adatto in base al prodotto, ai partecipanti e al contesto del progetto.
Review in piccole parti: Suddividere le review in sezioni per mantenere alta la concentrazione dei partecipanti.
Formazione: Fornire formazione adeguata ai partecipanti sul loro ruolo.
Facilitazione: Gestire efficacemente il review meeting.
cosa è la checklist-based?
E’ un docmento tecnica di revisione dove sono elencate con una lista di check degli aspetti critici del prodotto
Cosa è il Review scenario-based
In questo tipo di review, il revisore simula scenari realistici di utilizzo dell’applicazione per identificare problemi di usabilità, bug e incongruenze nel flusso, esplorando azioni tipiche dell’utente.
Cosa è il Definition Of Ready
il DoR è una sorta di checklist che garantisce che un elemento sia sufficientemente chiaro, completo e pronto per essere lavorato.
Cosa Sono i Criteri Di Accettazione
I criteri di accettazione (Acceptance Criteria) sono un insieme di condizioni che una User Story, un’attività o una funzionalità deve soddisfare per poter essere considerata completata e accettabile dal Product Owner o dagli stakeholder
Cosa sono le User Story?
La User Story è una breve descrizione di una funzionalità o di una caratteristica dal punto di vista dell’utente finale. L’obiettivo di una User Story è di descrivere in modo semplice e comprensibile il valore che una determinata funzionalità porterà all’utente.
Cosa è il Test Plan?
Pianificazione su come fare test in generale
