code refactoring what you need know about it
Capire il refactoring del codice: la prospettiva di un tester
Il termine 'Refactoring' viene utilizzato principalmente per indicare la pulizia / riprogettazione del codice richiesta.
In questo tutorial, comprenderemo la definizione di refactoring, discuteremo la necessità di refactoring del codice e esamineremo l'impatto del refactoring del codice sui vari membri del team di progetto. Discuteremo anche la risposta alla domanda più importante: In qualità di tester, perché è necessario conoscere il refactoring?
Inoltre, discuteremo anche alcuni casi di studio per chiarire il concetto.
Cosa imparerai:
- Introduzione al refactoring
- Necessità di refactoring del codice
- Perché un QA deve sapere sul refactoring?
- Casi studio
- Conclusione
- Lettura consigliata
Introduzione al refactoring
Per cominciare, dobbiamo prima capire cosa sia effettivamente il refactoring.
Il refactoring è essenzialmente una pratica o un processo per migliorare il codice e / o il database mantenendo le funzionalità esistenti. L'idea è di trasformare il codice inefficiente e troppo complicato in codice più efficiente, preferibilmente più semplice e facile.
Anche il refactoring del codice ha acquisito slancio con più team ora seguendo l'approccio Agile Software Development. I team di progetto hanno spesso un tempo limitato per implementare nuove o estendere la funzionalità delle funzionalità esistenti e del codice pulito. Il codice che è facile da capire e mantenere fa sicuramente molto per rispettare la scadenza dell'iterazione.
Necessità di refactoring del codice
Se stiamo mantenendo la funzionalità originale dell'applicazione o del modulo, sorge una domanda come perché ci preoccupiamo anche del refactoring? Bene, ci sono numerosi motivi per cui potrebbe essere necessario refactoring di un particolare modulo o parte di codice, come:
- Il codice puzza
- Debito tecnico
- Approccio agile allo sviluppo di software, ecc.
Discuteremo questi punti in dettaglio nelle sezioni seguenti.
# 1) Odori di codice:
Possiamo tutti capire che quando il cibo inizia a puzzare indica che molto probabilmente sta diventando cattivo - questo vale anche per il codice! Gli odori di codice indicano che potrebbe esistere un problema molto serio nel codice.
Di seguito sono riportati alcuni odori di codice comuni:
- Presenza di codice ridondante o identico.
- Una variabile dichiarata che non viene utilizzata da nessuna parte nel resto del codice.
- Progettazione del codice estremamente complicata.
- Classe di codice che fa troppo poco e non giustifica l'esistenza della classe definita. Tali classi sono note come lazy class o freeloader.
- L'esistenza di troppe condizioni e loop che hanno il potenziale per essere scomposti e semplificati.
- Il codice viene compilato in modo tale che una modifica in una parte del codice richieda l'implementazione della modifica anche negli altri punti.
Gli odori di codice diventano più evidenti con il passare del tempo. Man mano che l'applicazione o il sistema cresce, alla fine questi odori di codice iniziano a influenzare lo sviluppo del codice, la manutenzione e persino le prestazioni del sistema in scenari estremi.
# 2) Debito tecnico:
Durante lo sviluppo di un software, durante il tempo e le risorse disponibili limitati, spesso possiamo prendere scorciatoie per ottenere i risultati desiderati.
Considera una funzionalità che deve essere aggiunta a un modulo esistente. Dopo la discussione, il team restringe 2 approcci per aggiungere questa funzionalità. L'approccio A, che richiede 2 sprint per essere realizzato, sarà l'approccio a lungo termine approvato. L'approccio B richiede solo 5 giorni per essere consegnato è un hack codificato e disordinato progettato per riparare il modulo a breve termine.
Se il team è sotto pressione per fornire la funzionalità entro un tempo limitato, può accettare di seguire l'approccio B per ora e aggiungere l'approccio A nel backlog per il futuro. In questo modo, questa squadra si è semplicemente creata il debito tecnico.
In termini semplici, il debito tecnico nello sviluppo del software si riferisce alla rielaborazione aggiuntiva o al sovraccarico richiesto per mettere in atto le correzioni appropriate o fare le cose nel 'modo giusto'.
I sistemi legacy tendono ad acquisire un enorme debito tecnico nel tempo, il che a sua volta può rendere l'applicazione suscettibile di guasti e difficile da supportare e mantenere.
Per saperne di più=> Cos'è l'ufficio tecnico
# 3) Seguendo un approccio di sviluppo software agile:
L'approccio di sviluppo software agile sostiene lo sviluppo incrementale. Senza un codice pulito, ben strutturato e di facile manutenzione, non sarebbe possibile per i team estendere il codice esistente a ogni iterazione. Se il codice viene modificato senza un adeguato refactoring, può contribuire a creare odori di codice o al debito tecnico.
Questa relazione è illustrata nel diagramma seguente
Lettura consigliata => I migliori strumenti di analisi del codice
Perché un QA deve sapere sul refactoring?
Qualunque cosa abbiamo discusso fino ad ora in questo tutorial sembra essere correlata alla codifica e sembra il tipo di cose di cui uno sviluppatore dovrebbe preoccuparsi.
Allora, perché stiamo discutendo di questo concetto non correlato nella comunità di assistenza per il test del software? Continua a leggere il resto di questo tutorial per trovare la risposta a questa domanda.
# 1) Per unit tester / sviluppatori
Durante il refactoring del codice, quando viene inserito un nuovo codice, le vecchie classi vengono aggiornate, vengono aggiunte nuove classi e gli unit test esistenti potrebbero non riuscire. Inoltre, per i sistemi legacy, potrebbero non essere implementati test unitari. Questi nuovi test unitari dovranno essere creati e impostati da zero nella maggior parte dei casi.
# 2) Per i tester
Quando una funzionalità è in fase di refactoring (considerando che non stiamo aggiungendo alcuna nuova funzionalità), è chiaro che dopo aver apportato le modifiche richieste, la maggior parte delle funzionalità per l'utente finale dovrebbe rimanere la stessa.
- In qualità di tester, il refactoring del codice si traduce approssimativamente in = test approfondito + test di regressione. I test approfonditi devono includere tutti i flussi utente esistenti per garantire che tutte le funzionalità funzionino come prima. Test di regressione dell'intera applicazione (o delle aree interessate) è necessario per garantire che l'aggiornamento di un modulo non interrompa involontariamente la funzionalità degli altri moduli.
- I test di accettazione dell'utente saranno importanti e questi test devono essere superati prima che la build possa essere dichiarata pronta per il rilascio.
- Inoltre, qualsiasi altro test richiesto come i test di carico, test di sicurezza ecc. dovrebbe anche essere implementato come richiesto.
# 3) Ingegneri di test di automazione
Il refactoring del codice può causare il fallimento degli script di automazione funzionali e non funzionali.
Ciò può verificarsi per i seguenti motivi:
- Se gli oggetti della pagina cambiano come parte dello sforzo di refactoring e se i tuoi script di automazione Selenium si basano sugli oggetti della pagina, gli script falliranno e dovrebbero essere aggiornati.
- Se ci fossero modifiche minori, reindirizza quelle che sono state aggiunte o rimosse durante il refactoring e gli script di automazione esistenti non funzionerebbero e dovrebbero essere aggiornati
Si consiglia di impostare i test di automazione funzionale solo una volta che una funzionalità è stabile, altrimenti risulterà in molte rielaborazioni man mano che la funzionalità si evolve.
Essendo uno sviluppatore di test di automazione, anche gli ingegneri dei test di automazione devono pensare come uno sviluppatore e mirare a creare un codice pulito e di facile manutenzione. La maggior parte degli IDE come IntelliJ IDEA, Eclipse ecc. Includono un menu di refactoring integrato con metodi di refactoring comunemente usati per una facile consultazione.
Di seguito è riportato uno screenshot del menu di refactoring in IntelliJ IDEA (Community Edition).
domande e risposte avanzate di intervista sql pdf
# 4) Per i cavi di test / QA
- Ai responsabili del test / QA potrebbe essere richiesto di collaborare con il resto del team, inclusi gli sviluppatori, l'analista del prodotto e forse anche le parti interessate per garantire che la pianificazione dei test per tali progetti sia eseguita con attenzione.
- È importante comprendere la funzionalità esistente. Sulla base della funzionalità esistente, è necessario documentare i casi aziendali, i flussi degli utenti e i test di accettazione degli utenti. Quando un codice refactoring viene testato, tutti questi scenari devono essere convalidati, insieme al test di regressione delle aree interessate.
- Sii proattivo durante la pianificazione dell'approccio di prova e piani di test . Se prevedi il requisito di più ambienti di test o nuovi strumenti di test, invia la richiesta in anticipo per evitare ritardi una volta iniziata la fase di test.
- Non esitate a coinvolgere membri del team esterno al progetto o utenti finali per contribuire ai test.
Casi studio
Discuteremo ora alcuni casi di studio di vita reale in cui ho avuto l'opportunità di lavorare direttamente o di contribuire indirettamente.
Caso di studio n. 1
Compito: Refactoring di un modulo per sostituire i valori hard-coded con variabili e aggiungere commenti per il nuovo strumento di generazione di documentazione tecnica automatizzata.
Sfide :Nessuna sfida importante. Il modulo era nuovo, aveva requisiti funzionali e di accettazione dell'utente documentati, flussi di utenti e casi di test. I test unitari sono stati impostati durante il lancio iniziale stesso.
Approccio alla prova :Sono stati eseguiti i casi di test per il modulo in fase di refactoring e le aree interessate relativamente note. Eventuali difetti sono stati segnalati e risolti prima del rilascio.
Caso di studio n. 2
Compito :Effettuare il refactoring della stored procedure esistente per facilitare la scalabilità verticale dell'applicazione.
La stored procedure in questo scenario era una stored procedure precedente progettata alcuni anni fa, tenendo presente il requisito che l'applicazione utilizzava la propria stored procedure come un'applicazione interna con meno di 10 sessioni simultanee.
Ora l'azienda voleva commercializzare questa applicazione come Software as a Service (SaaS), con il volume previsto di 300 sessioni simultanee inizialmente.
Il team ha eseguito alcuni test di carico iniziali e ha concluso che il sistema si interrompe con un carico di 25 sessioni simultanee. Il team ha esaminato il codice e consigliato il refactoring di una stored procedure di base esistente che consentirebbe all'applicazione di espandersi e supportare fino a 500 sessioni simultanee senza interruzioni.
Alcuni problemi identificati con questa procedura memorizzata erano più sottoquery all'interno di una singola query, join pesanti con viste invece di tabelle, uso di select * invece di selezionare una colonna specifica, ecc. A causa di questi problemi di codifica, l'applicazione stava recuperando più dati di quelli era davvero necessario, causando così il rallentamento dell'applicazione e alla fine il crash.
Sfide:
# 1) Project Manager / Analista di prodotto
- Raccolta dei requisiti - Poiché questa procedura memorizzata era un codice legacy, non c'erano requisiti documentati per esso quando il modulo è stato progettato per la prima volta. Anche per le iterazioni fatte negli ultimi anni, non c'era alcun registro delle modifiche per indicare le regole di business e la logica aggiunte o rimosse dal modulo.
- Programma del progetto - Poiché i requisiti non erano chiaramente definiti e le dipendenze del codice non erano ancora completamente identificate, era difficile comunicare la pianificazione provvisoria.
# 2) Per gli sviluppatori
- Mancanza di requisiti chiari e regole aziendali.
- Pulire il codice senza perdere la sua funzionalità.
- Aree interessate sconosciute e / o dipendenze del codice.
- Impossibile fornire stime concrete dei tempi di sviluppo.
- È necessario creare nuovi test unitari.
# 3) Per i tester
- La mancanza di requisiti chiari e regole aziendali influisce sulla pianificazione dei test.
- Pianificazione dei test di impatto delle aree interessate sconosciute, in particolare per i test di regressione.
- Impossibile fornire stime di prove concrete.
# 4) Stakeholder
- Mancanza di requisiti documentati chiari e / o flussi di utenti + scadenze ravvicinate = maggior rischio di fallimento.
L'approccio seguito dal team per mitigare i rischi e aggirare le sfide :
(i) Il team ha seguito un approccio collaborativo per raccogliere i requisiti : Project Manager / Analista di prodotto e tester hanno lavorato a stretto contatto con gli utenti finali interni per comprendere e documentare le principali funzionalità e il flusso degli utenti.
Gli sviluppatori hanno anche esaminato il codice e aggiunto informazioni pertinenti al documento dei requisiti. Questo è stato fatto prima del giorno di inizio dello sprint.
(ii) L'ambiente di test alternativo è stato creato per testare la modifica implementata : Chiamiamo questi ambienti come Gamma e Phi. Gamma avrebbe il vecchio codice e Phi avrebbe sempre implementata l'ultima stored procedure refactoring.
Avere 2 ambienti di test in parallelo, quasi ricreando prima e dopo l'approccio, ha permesso al team di fare test più approfonditi ed esplorativi confrontando il comportamento in questi 2 ambienti di test, sono stati in grado di identificare i probabili bug.
Il team ha fornito i requisiti per un ambiente di test alternativo fornito prima della data di inizio dello sprint.
(iii) Utenti finali e parti interessate coinvolte nella fase iniziale dei test : Eventuali problemi evidenti sono stati individuati e segnalati in anticipo, consentendo più tempo al team per distribuire e testare la correzione richiesta.
(iv) Definire i criteri di uscita e rispettarli: I criteri di uscita sono stati definiti nelle fasi iniziali di pianificazione: 80% dei flussi di utenti testati, nessun bug critico irrisolto, demo e firma degli stakeholder prima del rilascio.
(v) Impostazione di una data di rilascio provvisoria: Stabilire una data di rilascio allineata e motivare il team a lavorare verso un endpoint comune. In base allo scopo del progetto, il team ha raccomandato di seguire uno sprint di 3 settimane invece di uno sprint regolare di 2 settimane per consentire al team di avere tempo sufficiente per eseguire il progetto.
Conclusione
Per riassumere, il refactoring del codice è un processo per pulire / semplificare il design di un modulo senza modificarne la funzionalità. Il processo di refactoring può essere semplice, come l'aggiunta di commenti, l'aggiunta di rientri corretti, la rimozione di una variabile statica, ecc. O può essere complicato per sistemi legacy complessi.
Un particolare modulo o parte di codice potrebbe dover essere refactoring a causa di odori di codice, debiti tecnici o seguendo un approccio di sviluppo software agile.
Per i tester, il refactoring del codice si traduce approssimativamente in = test approfondito + test di regressione.
Sono necessari test approfonditi per testare tutti i flussi utente esistenti per garantire che tutte le funzionalità funzionino come prima. Il test di regressione dell'intera applicazione (o delle aree interessate) è necessario per garantire che l'aggiornamento di un modulo non interrompa involontariamente la funzionalità degli altri moduli.
Ai responsabili del test / QA potrebbe essere richiesto di collaborare con il resto del team, inclusi gli sviluppatori, l'analista del prodotto, in particolare per i progetti legacy. Sii proattivo durante la pianificazione dell'approccio e dei piani di test. Se prevedi la necessità di più ambienti di test o nuovi strumenti di test, invia la richiesta in anticipo per evitare ritardi una volta iniziata la fase di test.
Circa l'autore: Questo tutorial informativo è stato scritto da Neha B. Attualmente lavora come Quality Assurance Manager ed è specializzata nella guida e nella gestione di team QA interni e offshore.
Hai lavorato a un progetto impegnativo che prevedeva il refactoring del codice o di un modulo / applicazione? Se sì, sentiti libero di condividere le tue esperienze nella sezione commenti da cui i nostri colleghi tester possono imparare.
Lettura consigliata
- Migliori strumenti di test del software 2021 [Strumenti di automazione del test QA]
- TOP 40 strumenti di analisi del codice statico (migliori strumenti di analisi del codice sorgente)
- La chiave per un test unitario di successo: in che modo gli sviluppatori testano il proprio codice?
- I 10 migliori strumenti di revisione del codice più popolari per sviluppatori e tester
- Lavoro freelance di scrittore di contenuti tecnici di test del software
- Download dell'eBook Testing Primer
- 11 migliori strumenti di automazione per testare applicazioni Android (strumenti di test per app Android)
- Le differenze tra test unitari, test di integrazione e test funzionali