Per molti anni il nostro gruppo di sviluppo IT ha sottoscritto la metodologia di sviluppo del software di cascata con pod separati di programmatori specializzati nello sviluppo di database, nel livello logico e nello sviluppo del livello di presentazione. Naturalmente avevamo anche un piccolo gruppo di garanzia della qualità che si occupava di tutte le responsabilità dei test. I requisiti, i compiti e gli errori sono stati trasmessi elettronicamente, si è svolta pochissima conversazione e il processo si è svolto dolorosamente.
Nel 2010 abbiamo compiuto il monumentale passaggio ad Agile con Scrum e dopo alcuni gravi dolori in crescita abbiamo davvero iniziato a eccellere come una squadra intera. La comunicazione è costante, le persone crescono e imparano gli uni dagli altri ogni giorno e le nostre pubblicazioni sono più stabili e molto più allineate con le vere priorità di business.
Un settore in cui stiamo ancora cercando di crescere è la condivisione delle responsabilità del controllo qualità del software tra tutti i membri del team di sviluppo per allontanarsi dall'atteggiamento di sballottamento che sembra ancora persistere quando arriva il momento di testare una funzionalità.
Qualcuno ha qualche consiglio su come far crescere un team di sviluppo verso la proprietà della qualità delle applicazioni collettive? Attualmente pratichiamo XP quindi abbiamo iniziato a fare più programmazione di coppia tra sviluppatori e tester durante la creazione di un'unità e test di integrazione. Ma è comunque difficile convincere l'intero team a pensare in modo proattivo alle strategie di test per ogni sprint. Inevitabilmente uno o due compiti " Scrivi casi di test " vengono gettati nello sprint backlog senza alcuna previsione riguardo a ciò che verrà testato e come sarà meglio conseguito e organizzato in modo che l'intero team sia a conoscenza di cosa testare è stato completato, cosa viene attualmente testato e cosa resta da testare.
Ci scusiamo per la domanda prolissa, ma qualsiasi consiglio sarebbe molto apprezzato.