Tag: Continuous Testing

Dopo il successo del 2019, ecco le registrazioni dei webinar effettuati:

07-28 Marzo: Requisito Perfetto (da cui il video-corso) 

21 Maggio: Verifica e Validazione del Software Automotive con ISO-26262 
  
04 Luglio: Presentazione Metodo M.E.D.S. 25 Luglio: Il grande inganno del Test Software

19 Dicembre: Modellazione e Simulazione dei Requisiti Software

Sappi che ho voluto pianificare altri 5 incontri per la prima metà del 2020, dedicati ad approfondire gli argomenti da voi più richiesti.

DI SEGUITO, LE DATE DEI PROSSIMI WEBINAR:

• 16/01: Metriche e KPI

• 20/02: Focus e Positioning per aziende Software

• 19/03: Team Management e Cultura Aziendale

• 16/04: Strategie Avanzate di Testing e Continuous Integration

• 25/06: Approfondimento su Requisito Perfetto
  

A CHI SONO RIVOLTI I MIEI WEBINAR?    

– IMPRENDITORI che hanno a che fare con il software, direttamente o all’interno dei prodotti che creano

– MANAGER che gestiscono un gruppo di lavoro che scrive o integra del software

– TECNICI che vogliono imparare delle metodologie avanzate che migliorano la qualità e velocizzano il lavoro di scrittura del software

TI ASPETTO AI PROSSIMI INCONTRI!  

Registrati al canale YouTube di SOFTWARE SICURO per guardare gli altri video:

Canale YouTube SOFTWARE SICURO

Clicca invece qui per conoscere meglio CHI SONO IO E QUALI SONO I MIEI PROGETTI RICONOSCIUTI SIA A LIVELLO NAZIONALE SIA INTERNAZIONALE!
Per ogni tuo dubbio, perplessità e curiosità, scrivi pure a:
assistenza@softwaresicuro.it
Massimo

Il software è stato inizialmente visto come qualcosa che poteva essere scritto una volta e usato molte volte senza mai “rompersi”. Tuttavia, quell’illusione svanì quando iniziarono ad apparire problemi, in ultima analisi causati da uno sviluppo continuo senza i giusti processi di controllo della qualità. Ciò era in genere dovuto a pressioni aziendali incredibili per rilasciare nuovi prodotti e funzionalità in un tempo compresso per essere sul mercato.

Questi problemi hanno portato ad applicazioni software che trasportano un’enorme quantità di problemi che hanno un nome ben preciso:

DEBITO TECNOLOGICO

Una metafora dei difetti latenti introdotti durante l’architettura, la progettazione o lo sviluppo del sistema. La difettosità accumulata quando le organizzazioni adottano queste scorciatoie di progettazione e test, al fine di raggiungere gli obiettivi a breve termine, alla fine rende il software difficile da mantenere. Con l’aumento del debito tecnologico, gli sviluppatori dedicano la maggior parte del loro tempo a correggere bug e a lottare con codice fragile, invece di concentrarsi sul core business e creare nuove funzionalità.

Molte organizzazioni ora stanno scoprendo che il software legacy ha in genere una diminuzione della durata della vita utile; dopo averlo creato e rilasciato, sono costretti a decidere se buttarlo via e ricominciare da zero, o cercare di recuperarlo. Nella maggior parte dei casi, è stato fatto un notevole investimento finanziario nella base di codice, quindi c’è una tremenda pressione per riutilizzarlo. La chiave per ridurre il debito tecnologico consiste nel rifattorizzare i componenti (il processo di ristrutturazione dei componenti di un’applicazione senza modificarne il comportamento esterno) nel tempo, ma gli sviluppatori sono spesso riluttanti a farlo per paura di corrompere le funzionalità esistenti. Uno dei maggiori ostacoli al refactoring è la mancanza di test che caratterizzano il comportamento esistente di un componente.

Questo è un problema crescente in quanto vi sono molte applicazioni distribuite basate su basi di codice legacy che non hanno i testcase necessari. Questo è aggravato quando il codice legacy viene distribuito su una nuova piattaforma o prodotto, poiché la mancanza di artefatti di test significa che il debito tecnologico continua a crescere senza possibilità di “ripagarlo”. C’è un enorme gap di qualità che deve essere affrontato, ma molte aziende non sanno da dove iniziare o non hanno le risorse necessarie per affrontare il problema.

Read More