Outsourcing Quality Assurance and Testing [chiuso]

Vorrei raccomandare contro questo per una ragione principale che non ha nulla a che fare con la competenza e le capacità della particolare società di outsourcing che ti ha avvicinato (che non posso giudicare).

Affinché il QA funzioni, una volta superato lo stadio "Gli sviluppatori fanno il proprio QA", deve essere un membro di prima classe del processo di pianificazione e gestione. Per natura, lo sviluppo e la QA saranno in una (si spera amichevole, ma) relazione di opposizione - questo naturalmente deriva dai loro obiettivi concorrenti. Dopo tutto, quali sono gli obiettivi principali degli sviluppatori?

• da fare con la versione corrente, in modo che possano iniziare a lavorare sulle fantastiche cose che hanno pianificato per il prossimo

• per ottenere tutte le funzionalità su cui hanno lavorato duramente e completato almeno una parte preliminare della versione corrente

• per passare il tempo a hackerare le nuove funzionalità invece di correggere i bug appena scoperti nel vecchio codice

nel frattempo, l'obiettivo del team QA (o del QA) è di non lasciare uscire nessuno fuori dalla porta fino a quando non vengono trovati tutti i bug, e tutti i bug trovati sono annullati.

Il problema, naturalmente, è che non possono essere entrambi giusti e, cosa altrettanto importante, nessuno dei due ha ragione tutto il tempo. A volte questa funzione grande, ma non ancora pronta, deve attendere la prossima versione. A volte la versione deve essere spedita, anche con bug noti (e chiaramente documentati!), In modo che gli sviluppatori possano passare a quello successivo. Il compromesso è che deve accadere - e non può accadere se uno di questi due gruppi è subordinato all'altro. Per questo motivo, gli sviluppatori e il team di QA devono avere un posto uguale al tavolo quando vengono prese queste decisioni, e qualcuno più in alto deve avere l'ultima parola quando prende in considerazione le loro posizioni conflittuali.

Per questo motivo, raccomando di evitare qualsiasi struttura aziendale in cui gli sviluppatori sono subordinati alle decisioni del QA, o il QA è subordinato alle decisioni degli sviluppatori - e questo sarà molto difficile da fare se gli sviluppatori sono in -house, e il team di QA è esternalizzato.

Un buon test è importante, se non più importante dello sviluppo.

Non tutti possono testare le tue cose. Devi trovare persone con molta esperienza nel tuo dominio problematico. Dovrebbero essere persone con la conoscenza del dominio, se non di più, dei tuoi sviluppatori. Se stai sviluppando un'app di assistenza sanitaria, ad esempio, assumi un'infermiera o un tecnico sanitario che usa quella roba.

In breve i migliori tester sono utenti esperti. Conoscono il dominio del problema, conoscono i problemi che stai cercando di risolvere e li conoscono meglio di te. Assumere un sacco di queste persone, troveranno un ordine di grandezza più problemi reali, quindi il tizio fuori dalla strada seguendo una procedura meccanica. Anche il casual-off-the-street può generare molto rumore, non hanno idea di quale problema tu stia cercando di risolvere. L'utente esperto dà un'occhiata alla tua app e può ottenere subito ciò che stai cercando di fare.

QA / Test ha un problema di immagine. Ho fatto il mio bel po 'di test del software freelance ed è sempre stato prezioso per i clienti. Ho lavorato principalmente con startup, piccole software house e agenzie digitali.

Il bisogno di test esterni aiuta spesso quando queste aziende hanno molto lavoro o non sono pronte a impegnarsi in una risorsa a tempo pieno. Avere la possibilità di ricorrere a un tester freelance a breve scadenza può essere estremamente prezioso.

Il problema che molte aziende devono affrontare è la mancanza di test e tester davvero validi. Ottenere un buon tester a bordo può davvero aiutare il lancio di un progetto con sicurezza. Ottenere un brutto rallenterebbe le cose. Gestisco una community di tester software, quindi ho trovato la mia giusta dose di tester grandi e cattivi.

Chiedendo a un tester alcune domande di base dovrebbero facilmente filtrare l'incompetente.

Informali sui tuoi bisogni e vedi se fanno domande o consigliano immediatamente una soluzione. I buoni tester porranno le domande giuste.

Chiedile dei progetti in cui sono stati coinvolti di recente. Qual è stata la loro più grande sfida?

Chiedi consigli / riferimenti.

Chiedi loro quale sia la loro migliore abilità o quale sia il loro focus sui test. I test stanno diventando sempre più specializzati, è difficile diventare esperti in campi specifici.

I migliori tester potranno anche analizzare in modo super rapido aree importanti (non superficiali).

Spero che ti aiuti.

Ho avuto un sacco di esperienze diverse, la maggior parte cattive. In generale ottieni ciò per cui paghi, ma non è sempre vero. Ho lavorato con i membri del QA che si sono dimostrati così preziosi per il team, che direi che erano un moltiplicatore della produttività.

Se mi fosse stata data la scelta, sceglierei sempre un QA di alto livello professionista con esperienza, oltre a diverse risorse di provenienza.

Inoltre, anche se è una buona squadra in outsourcing. Hai ancora a che fare con il sovraccarico dei problemi di comunicazione e fuso orario, che anche con le persone migliori su entrambi i lati può diventare frustrante e costoso.

Ho scoperto che il QA in outsourcing può essere efficace, se le tue aspettative sono realistiche e hai un approccio abbastanza diretto alla gestione dello sforzo.

Ero responsabile di un progetto pilota in Microsoft per sfruttare i fornitori di terze parti in Cina per i test di localizzazione. Per fare questo lavoro, ho condotto la formazione in prima persona e post mortem ogni tre mesi. Ho fatto pre-triaging dei bug che sono venuti per evitare di distrarre la nostra "squadra di guerra" con rapporti di bug scritti male o non adeguatamente regressi. Ci sono voluti alcuni sforzi, ma abbiamo ottenuto un ottimo valore da questo processo; le persone addestrate ruotavano in squadre diverse man mano che lo sforzo si espandeva. Alcune delle persone migliori del primo gruppo che ho formato stanno attualmente svolgendo attività di sviluppo aziendale e di livello dirigenziale. Questo sforzo ha avuto molto successo e lo farei di nuovo in un attimo se fossi in grado di avviare un progetto simile nella mia situazione attuale.

D'altra parte, ho anche lavorato per una società che ha esternalizzato alcuni sforzi del QA in India. Il loro approccio era quello di fornire una vaga linea guida per ciò che era necessario testare, un requisito che l'automazione del test fosse scritta in Java e nessuna risorsa interna dedicata è stata assegnata per gestire lo sforzo. Essenzialmente, hanno assunto la compagnia e "hanno buttato il compito oltre il muro". Hanno un codice terribile e non gestibile con un sacco di variabili statiche, un accoppiamento stretto, problemi temporali e un ridicolo tasso di falsi fallimenti (irriproducibili). Per la prima volta abbiamo passato circa un mese o due cercando di recuperare il codice, ma alla fine abbiamo dovuto buttare via tutto ciò che facevano e costava molti soldi.

Quindi, a prescindere da come il tuo venditore lo propone, non pensare che il QA in outsourcing ti libererà completamente dalla gestione dello sforzo. Quello che dovrebbe fare è fornire un moltiplicatore dello sforzo, se lo gestisci correttamente. Aspettatevi di dedicare almeno una persona a tempo pieno all'interno della vostra organizzazione, preferibilmente qualcuno con esperienza di QA e Project Management.

Puoi risparmiare denaro nell'assumere un team equivalente internamente, ma ciò non è garantito. Sarai isolato dallo sforzo di qualificare il talento, assumere e licenziare persone, il che vale molto se il tuo venditore trova persone di qualità. Ma avrai un sacco di lavoro pratico da fare. La cosa migliore dell'outsourcing è che puoi aumentare o ridurre lo sforzo abbastanza rapidamente in base allo stato del tuo progetto. Se non c'è molto da testare, non paghi tanto.

Data l'opportunità, in genere preferisco assumere persone impegnate per il successo della nostra azienda a fare QA. Ma se non hai le competenze interne per fare questo assunzioni, o il budget per un grande team interno a tempo pieno, è sicuramente da prendere in considerazione.

Nota a margine: il paese in cui si trovavano i nostri fornitori non era un fattore importante per il successo o il fallimento dei nostri progetti; il livello di coinvolgimento nella gestione dello sforzo da parte nostra è stato il fattore critico.