che cosa investe i tester nelle versioni testate? [chiuso]

Vuoi dire che, a parte l'intero "insetto di produzione gigante, la gente della QA viene licenziata" investita?

Almeno in alcune aziende in cui ho lavorato, il QA è servito come supporto tecnico di secondo livello. Sarebbero stati chiamati a fianco (o prima) degli sviluppatori se un problema apparisse sul campo, dal momento che spesso avevano una comprensione migliore delle peculiarità del prodotto spedito rispetto agli sviluppatori. Questo accade un po 'quando hai un sacco di vecchie versioni del prodotto sul campo - gli sviluppatori tendono ad essere molto concentrati sullo stato attuale del prodotto.

Tuttavia, il QA sa che (giusto o sbagliato) sono quelli a cui la gente guarda se un bug arriva alla produzione - nessun altro.

But how are testers, aside from attitude towards their work, vested in the releases they test?

Quindi ai tuoi sviluppatori interessa solo perché potrebbero essere invitati per notte / fine settimana?

Se è così, ti trovi in una situazione molto difficile. Perché quella squadra è molto meno impegnata nel proprio lavoro di quanto tu non creda. Se la sola cosa che li ritengono responsabili è la paura di lavorare fuori dal lavoro, questa non è una buona situazione. Fornisce molta meno motivazione di quanto tu non creda.

Non è una buona situazione perché vuoi che i tuoi dipendenti si preoccupino, non per paura delle conseguenze, ma per la maestria del loro mestiere. Questo è vero sia che tu scriva codice, software di prova o pizzi - i dipendenti migliori sono orgogliosi del loro lavoro, qualunque esso sia.

Trovare bug può essere motivo di orgoglio per i team di test, tra l'altro .. vengono riconosciuti per il loro ruolo nelle versioni di software di qualità? Nell'identificare bug / problemi?

La maggior parte dei luoghi di lavoro con dipendenti non investiti, disillusi o disimpegnati ha cattiva gestione, mancanza di riconoscimento o è oberata di lavoro.

Vuoi eliminare "professionalità e attitudine" dall'equazione che è l'unica cosa che resisterà alla prova del tempo. Non importa quale lavoro svolgete, se trattate il vostro lavoro come una professione che cercherete sempre di migliorare, il che naturalmente lo rende un investito. Coloro che trattano il loro lavoro come un lavoro, tendono a fare solo ciò che è necessario e possono o non possono effettivamente essere attribuiti al risultato. Quindi hai eliminato il mezzo chiave per far acquisire i tuoi tester. Assumi l'atteggiamento oltre all'abilità.

Puoi ottenere uptick a breve termine offrendo bonus o minacciando di punire, ma l'efficacia di questi approcci cala nel tempo.

Un'altra cosa su cui lavorare è assicurarsi che le RESPONSABILITÀ siano chiaramente assegnate e conosciute. La maggior parte dei manager si limita a ritenere le proprie persone responsabili per non aver rispettato le proprie responsabilità. Ma questo non è abbastanza per infondere la giusta motivazione. Per citare Office Space - "Bob, questo renderà solo qualcuno abbastanza duro da non essere licenziato". La parte che di solito manca e che è la parte più importante dell'assegnazione delle responsabilità è ASSICURARSI CHE LE PERSONE HANNO L'AUTORITÀ A GARANTIRE LE LORO RESPONSABILITÀ SUL PROGRAMMA. Se incolpate le persone di non aver eseguito le loro responsabilità ma credono di non aver rispettato le responsabilità perché le loro idee sono state respinte, quindi non assumersi la responsabilità era qualcosa fuori dal loro controllo, porta decisamente alla mancanza di proprietà / interessi personali. Considerando che, se la persona ha spinto per ottenere le loro idee incorporate, avranno certamente un interesse acquisito per assicurarsi che abbiano successo.

ALTRE INFO / ODDS e amp; ENDS

Scusa se non attribuisco alcuni di questi risultati, ma a volte copio e incollo cose come queste per i miei scopi senza pensare a catturare la fonte.

Il sondaggio di 10 anni condotto su 200.000 dirigenti e dipendenti da parte dell'organizzazione Jackson ha dimostrato che le aziende che riconoscono costantemente l'eccellenza generano un rendimento sul capitale più di 3 volte superiore rispetto a quelli che non lo fanno.

In qualche modo mi interrogo su questo studio perché sono stato in aziende dove hanno cercato di farlo e potrebbe aver contribuito a motivare coloro che hanno ricevuto il riconoscimento, ha avuto l'effetto opposto su coloro che non hanno ricevuto il riconoscimento che sentivano si sono meritati.

Sebbene, solo un sentimento generale sul fatto che i propri sforzi siano apprezzati, e non semplicemente previsti, può richiedere molto tempo.

I premi orientati verso la famiglia del dipendente hanno il potenziale di essere significativamente più utili di quelli diretti al dipendente. Ad esempio, per un'azienda in Florida, mandare dipendenti e familiari in un weekend pagato interamente a un hotel Disney Resort e l'ingresso al parco costa probabilmente meno di $ 1.000 ma probabilmente il coniuge ei bambini dimenticheranno in qualche modo che il dipendente non ha Sono stato in giro molto negli ultimi due mesi. La famiglia felice, equivale a meno stress a casa, il che significa un impiegato più felice, il che significa un dipendente più produttivo.

Considerando che un bonus di $ 1.000 probabilmente non verrà nemmeno visto dalla famiglia, quindi tutto ciò a cui pensano è che mamma / papà lavora troppo. Famiglia infelice, uguale a dipendente stressato.

Gli studi hanno dimostrato che quando i premi sono in linea, le persone tendono ad essere meno utili.

Coinvolgili in ogni fase del processo.

• Invitali a partecipare a future riunioni di progettazione.
• Falli presentare durante il pre-grooming e il grooming se fai agile
• Sottolinea l'importanza di porre sempre una domanda "Allora, come testeremo questo?" durante la toelettatura.
• Falli presentare durante la scrum giornaliera se ne hai uno
• Invitali a lavorare sui piani di test con gli sviluppatori - prima il codice è scritto!
• Invitali a lavorare con gli sviluppatori per le distribuzioni
• Dì loro real di rispondere quando qualcosa soddisfa la definizione di fatto
• Assicurati che la definizione di fatto includa input dal QA per i test
• Non utilizzare le stime di tempo degli sviluppatori senza includere gli stessi dal QA
• trova i modi per mostrare in che modo aiuta lo sviluppatore, ma è un ostacolo per le funzioni
• definisce il loro ruolo di ingegnere della qualità, non di "tester"
• potenzia le persone fornendo supporto e formazione in modo che possano apprendere l'attività tecnica e di sviluppo
• offri loro una fonte di idee per testare utilizzando l'euristica di prova - link
• inviarli a conferenze sulla professione di controllo qualità e test, ad es. devops, velocity
• Invitalo a lavorare a stretto contatto con i clienti e l'assistenza clienti in modo che possano capire e quindi essere in grado di presentare le cose dal punto di vista del cliente
• insegnare loro come fornire report di bug di alta qualità con elementi come screenshot, passaggi da riprodurre, variabili iniziali da sapere. Ciò renderà più facile e più piacevole per gli sviluppatori lavorare con loro. Ridurrà il "ma cosa stavi facendo quando hai ottenuto quegli scenari".
• fornire loro un ragionevole tester per dev ratio (ad esempio da 0,5 a 3 sviluppatori) in modo che possano entrare nei dettagli. Se il rapporto è più simile a 1 tester a 10-20 sviluppatori, sarà più probabile che eseguano attività automatiche che non testano realmente il prodotto in modi utili che continuano ad aggiungere valore nel tempo.
• tieni un registro delle cose che hanno trovato e presentalo a gruppi più grandi e itera su di esso
• assicurati che i tester abbiano il pieno potere di aggiungere un bug al sistema di tracciamento dei bug e che sia facile per loro farlo. Ovviamente dovrebbe essere revisionato (curato) prima di essere elaborato dagli sviluppatori.
• assicurati che abbiano buoni strumenti e processi per fare il loro lavoro. Se non lo fanno, ad esempio non esiste un framework di automazione dell'interfaccia utente, impostalo come attività che gli sviluppatori si accoppiano con loro.
• sottolineare loro che stanno salvando il cliente e l'azienda da cose brutte e quindi sono una parte fondamentale dell'azienda.

Modifica "lancio del codice sul muro per qa", per l'associazione con QE durante tutto il processo

Se viene rilevato un difetto, è colpa dello sviluppatore, se un difetto non è rilevato è colpa del tester, e quando succede qualcosa è colpa della direzione.

Gli sviluppatori sono motivati a creare codice privo di bug, i tester sono motivati a trovare il codice pieno di bug, i manager sono motivati a trovare dipendenti pieni di bug.