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
I Prodotti di lavoro possono essere:
*Documenti e requisiti
*Progetti
*Codice Sorgente
*Piani di test
*Documentazione (manuale utente)
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
Inizio Vengono istruiti i revisori gli vengono forniti tutti gli strumenti
Esame Individuale: Esame Individuale dei Revisori, ci sono due tecniche Review CheckList e la Review Scenario base
Comunicazione Condivisione delle anomalie individuate per scongiurare di scanbiare una funzionalità valida con una anomalia.
Review Meeting : Discussione dei risultati e delle decisioni prese.
Verifica la qualità del prodotto
Stabilisce chi deve fare cosa
Viene fatto il Follow Up (Rendicontazione delle anomalie da risolvere)
Correzione e Report viene generato un
Defect Report è un report dove vengono degnalati i difetti nel dettaglio
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.
Promuovere: 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
Product Backlog
è una lista delle funzionalità da migliorare
Cosa sono i Test CHarter?
Sono gli obiettivi da perseguire per una attività.
Cosa sono i review Meeting?
E’ un incontro che si svolge alla fine di ogni Sprint e serve a presentare il lavoro completato e raccogliere feedback e decide il follow Up
Cosa è il Follow Up?
Il follow-up è un’attività di monitoraggio e verifica che viene eseguita successivamente a un incontro, una riunione, una discussione o un’attività specifica per assicurarsi che le azioni concordate vengano effettivamente realizzate.
Cosa è un Un Defect Report?
Per ogni anomalia cviene redatto un report , documento che descrive il problema chiaramente
Che ruolo ha l’autore nel review?
L’autore si occupa:
* Scrittura di Test Unitari
* Verifica e Debugging del Codice:
* Implementazione di Test Automatizzati:
* Test d’Accettazione e Validazione
Che ruolo ha il manager ne review?
Il manager ha un ruolo di supervisione, facilitazione e garanzia della qualità del processo
cosa è il walkthrought?
Il termine “walkthrough” deriva dall’idea di camminare attraverso un documento o una parte di un progetto, mostrando i vari dettagli e le scelte fatte, mentre gli altri partecipanti forniscono osservazioni e suggerimenti. Si tratta di un processo collaborativo, che può coinvolgere il team di sviluppo, i manager, i tester o altri stakeholder. E viene svolta dall Autore
Descrivi la Review Tecnica
Viene fatta da Rewiever tecnici
La review tecnica è un processo essenziale per garantire che il prodotto finale sia di alta qualità, conforme agli standard e privo di errori tecnici. Attraverso il coinvolgimento di esperti e l’analisi approfondita, contribuisce a migliorare l’affidabilità e l’efficienza del lavoro sviluppato, minimizzando i rischi di fallimenti futuri o problematiche di performance.
descrivi la differenza tra la Review Tecnica ed il Walkthrough
Sono entrambi processi di revisione per migliorare la documentazione o un progetto differiscono per scopo, formalità e struttura
Review Meeting: La review meeting ha lo scopo di valutare e analizzare il lavoro completato Viene utilizzata per fare un punto sullo stato di avanzamento del progetto e raccogliere suggerimenti Review Meeting: Coinvolge spesso stakeholder diversi.
Walkthrough: Il walkthrough è principalmente un processo informale di condivisione, in cui l’autore del lavoro guida i partecipanti attraverso i vari aspetti del lavoro per ottenere feedback e migliorare la comprensione tra i membri del team.
Walkthrough: coinvolge i tecnici
In breve, la review meeting è un processo formale, dettagliato e decisionale, mentre il walkthrough è un incontro più informale e collaborativo, orientato alla comprensione e alla condivisione di conoscenza.
Definizione di Test Case
Un Test Case è una descrizione dettagliata di un insieme di condizioni, input, azioni e risultati attesi che vengono utilizzati per verificare una funzionalità o un requisito specifico del software.
Cosa sono i test di accettazione?
Delle verifiche che vengono fatte sul prodotto. Assicurarsi che il software funzioni come richiesto dall utente. Si tratta dell ultima fase di test del prodotto.
