Presentazione di un (nuovo) metodo di prova per una squadra [chiuso]

Evolvere la cultura della squadra

Questa potrebbe essere la parte più difficile dell'implementazione dei processi di test nella tua organizzazione. Ogni squadra reagisce per cambiare in modo diverso. Alcune persone abbracciano l'opportunità di provare qualcosa di nuovo, e alcuni sono perfettamente felici nei loro modi e non vedono alcun motivo per cambiare. Posso dirti questo: a nessuno piace un fascista . Costringere le persone a fare le cose in un certo modo probabilmente genererà più resistenza.

Ecco alcuni suggerimenti per presentare i cambiamenti nella tua organizzazione:

• Fornire prove empiriche, come "Abbiamo catturato il bug X prima di consegnarlo al cliente, e ci sono volute 8 ore per ripararlo. Il cliente ha riscontrato un errore Y un mese dopo la consegna e ci sono voluti una settimana per il patch esso ". Modifica: Vedo che hai detto che il tuo cliente potrebbe essere interessato ai costi di un sito di test. Vedi se riesci a dimostrare che catturare i bug in anticipo salverà i soldi del cliente.
• Mostra agli sviluppatori come funzionano i nuovi strumenti. Molti di noi sono sviluppatori perché pensiamo che la tecnologia sia divertente. Prova a condividere nuovi strumenti / processi di test come nuovi giocattoli con cui giocare.
• Non impostare il tuo cuore su una singola soluzione. Lascia che il team sperimenta varie tecnologie. Per i test dell'interfaccia utente automatizzati, è possibile utilizzare TFS, Selenium, passando manualmente gli script di test o altre opzioni. Mantenere la porta aperta a diverse tecnologie consente al team di individuare gli strumenti adatti, incoraggiando inoltre un processo democratico che promuova una partecipazione condivisa al processo decisionale. Incoraggia le discussioni aperte con il team di sviluppo.
• NON aspettati che tutto cambi in una volta. Cerca di concentrarti su una cosa alla volta. Ecco un esempio di rottura del cambiamento in fasi più piccole:
  1. Scrivi alcuni test unitari per il codice server che verificano che la funzionalità di sistema funzioni come previsto
  2. Crea una VM di test che duplica l'ambiente operativo del tuo prodotto
  3. Casi di utilizzo dei documenti che possono essere utilizzati per testare la GUI
  4. Combina il codice server e il codice client in un unico repository su TFS in modo che la versione più recente sia facilmente identificabile, testabile e in grado di essere implementata
  5. Inizia a utilizzare i test dei casi d'uso ogni volta che vengono impegnati nuovi componenti (automatici o manuali)

Questi sono solo alcuni esempi di attività. Potrebbero essere necessarie settimane per arrivare dove vuoi essere; potrebbe volerci mesi. Quanto esattamente il tuo team adotta i processi di test dipenderà dalla tua cultura. Ultimo ma non meno importante,

• NON rinunciare, ma sii educato e amabile a riguardo. Se continui a suggerire modi per migliorare i processi di test, il team di sviluppo potrebbe provare alcuni dei tuoi suggerimenti in una giornata lenta solo per curiosità.

Soluzione tecnica

Vorrei poterti dare delle informazioni migliori sulle soluzioni tecniche per la tua situazione. Lavoro a tempo parziale in un negozio .NET e posso dirti che utilizziamo TFS esclusivamente per l'integrazione continua, ovvero il controllo della versione per il codice client (EXTJS con ASP.NET MVC 3) e il codice server (C # w / Entity Framework ), UI automatizzati e test unitari sul ramo di rilascio e distribuzione automatizzata a un sito di test e un sito demo (che sarà il nostro sito di produzione alla fine). Come ho detto sopra, le tue soluzioni tecniche specifiche dipenderanno in gran parte dalla cultura della tua organizzazione.

Buona fortuna!

Hai un numero di opzioni, ma qui è dove inizierei. Intendiamoci, vengo dal mondo java, ma un sito web dovrebbe essere un sito web, davvero.

1. Test del sito web: Selenium è uno strumento fantastico per test di script contro siti Web.
2. Virtualizza: puoi duplicare gli ambienti in VMware o VirtualBox e salvarli. Quando si desidera eseguire i test di sistema / integrazione, caricare l'ambiente appropriato ed eseguire i test.
3. Metodologia: Test Agile: una guida pratica per tester e team agili ha molti buoni consigli su questo davanti. Suggerirei di iniziare con qualcosa di abbastanza semplice, vedere come va e revisionare in modo appropriato.

Penso che la prima domanda qui sia quella che ti aspetti di uscire dai test. Uso i test come uno strumento di progettazione, codice che è facile da testare, di solito è un buon codice e una rete di sicurezza. Sembra che quello che vuoi sia una rete di sicurezza.

Se vuoi una rete di sicurezza, devi avere un ambiente di prova. Non si desidera eseguire test nel proprio ambiente di produzione. Per prima cosa, significa che stai distribuendo il codice che pensi possa essere interrotto in produzione. Per un altro, non è possibile controllare i dati o controllare l'accesso. Per l'ennesimo, significa che stai distribuendo il codice che pensi possa essere interrotto nella produzione . Questa è follia, pura e semplice, e ci sono modi migliori.

La prossima domanda è cosa testare. Il team deve avere una strategia di test e quando qualcosa viene implementato, deve esserci una comprensione di quali test devono essere scritti. Una delle ragioni per cui sono un fan di Test Driven Development è che i test vengono scritti in concomitanza con il codice, quindi i test non sono visti come una sorta di sovraccarico che tutti devono sopportare e si ha la certezza che ciò che deve essere testato è testato perché tutto è testato. Potresti considerare se sia plausibile implementare TDD nel tuo negozio ... è possibile che i tuoi colleghi sviluppatori lo considerino se scrivere e eseguire i test fosse facile?

Anecdotally, sono stato in grado di convincere una squadra ad andare con TDD e IC semplicemente sottolineando un paio di cose: in primo luogo, tutti noi facciamo sempre il TDD. Prima di scrivere il codice, hai intenzione, e dopo aver scritto il codice, in genere controlli per vedere se corrisponde a tale intento. TDD è il processo per mettere le tue intenzioni in un test in modo che tu sappia che il codice che scrivi domani non viola l'intento che hai avuto ieri. Secondo: è possibile evitare di avere il tuo manager / cliente cagna per aver violato qualcosa semplicemente avendo un ambiente di test. Rimuove un sacco di seccature dalla tua vita quando queste persone non si lamentano tutto il tempo.

Se hai tempo / spazio per farlo, potresti prendere in considerazione la creazione di un ambiente CI appropriato che puoi dimostrare al gruppo. Sapere che loro possono farlo non è bello come sapere che puoi farlo per .

Per quanto riguarda i dettagli di implementazione, sembra che tu possa trarre beneficio leggendo " Integrazione continua in .NET " da Manning Publications e forse questo post sul blog di codebetter su test sul selenio con .net . Per TDD, controlla " Sviluppo basato su test in Microsoft .net "di Microsoft.

Penso che il più grande ostacolo che dovrai affrontare (e affrontare costantemente per un po ') sia la resistenza. Anni fa ho introdotto internamente build notturne e rilasci automatizzati e impedito agli sviluppatori di archiviare i binari compilati e ho cercato di scoraggiarli dallo spostamento del codice direttamente ai siti dei clienti. Sono rimasto sorpreso di quanto si lamentassero per aver aspettato che il codice venisse testato da QC, riluttanza a scrivere qualsiasi tipo di test unitario di base e come continuano a ignorare i processi e spostare manualmente il codice. Può essere scoraggiante vedere come le persone riluttanti possono essere migrate verso un processo che è effettivamente migliore per la stabilità del prodotto. Ma devi rispettare il tuo piano. Spostare manualmente il codice e non effettuare il check-in è una follia.

Se la direzione ha le spalle devi solo procedere con una cosa alla volta. Per prima cosa fai in modo che controllino tutte le modifiche a un singolo repository e che tutto sia stato creato da quel repository. Seriamente tutto dovrebbe essere sotto controllo della versione. Tutto dovrebbe essere compilato da un server. Una volta che le build si sono rotolate, introdurre test automatici.

La domanda è incorniciata da un test di aiuto di cui sto ancora imparando, ma sembra che tu non abbia nemmeno un processo di compilazione e rilascio appropriato. Solo una piccola parte del nostro prodotto utilizza qualsiasi tipo di test automatizzato e questo è il nostro materiale Java. Vengono eseguite attività CI e invia un messaggio di posta elettronica all'ultimo sviluppatore da impegnare in caso di errore di un elemento della configurazione. Oltre a questo non esiste un altro tipo di test automatizzato.

Quindi costruire e rilasciare è qualcosa con cui ho esperienza. Ho dovuto scrivere da zero un processo di compilazione e rilascio per un negozio che avrebbe controllato i file binari compilati e gli script sql su VSS e quindi avrebbe inviato manualmente quei binari o script ai client. Ho usato NAnt w / NAntContrib per compilare vb6 e .Net e poi Ant per la nostra roba Java. VSS è stato scaricato per SVN. Inizialmente ho avuto CruiseControl.NET per la gestione di CI ma recentemente sono passato a Jenkins. CC.Net non ha gestito molto bene l'IC e sono passato dalla frustrazione. Ho usato NAnt per distribuire il codice alle nostre aree di sviluppo e controllo interno con build notturne. WiX (Windows Installer XML) per installare / aggiornare i client.

Mi sono imbattuto in un libro che leggerò solo per avere qualche idea, si chiama How Google Test Software di James Whittaker. Voglio davvero fare test automatici anche nella mia azienda e con tutti gli altri lavori che devo fare è un processo continuo. Buona fortuna a te amico!

(oh e usiamo JIRA per il tracciamento dei problemi e in precedenza usavamo Serena TeamTrack. Nemmeno mi fa schifo, ma penso che il nostro materiale JIRA non sia implementato correttamente)