Quando è il momento di avere un reparto di QA? [chiuso]

Question

L'(QA) reparto Quality Assurance è più o meno un gruppo di tester debunking vostra applicazione (s) per tutto il giorno, dando il via libera per la stampa, la gestione dei programmi / Beta Alpha. E molto altro ancora.

Ma senza un reparto di QA in una società di software, le questioni si pone troppo spesso in campo, e problemi di costa più da risolvere. Tuttavia, la maggior parte delle aziende inizia in un garage, con 1 dipendente essere te stesso, e poi cresce in una società di software.

Quando si fa a dire che è per creare tale dipartimento? Niente a che fare con la dimensione della società, i problemi che incontra?

Answer 1

Non appena si può permettere. Lei non potrà mai avere un prodotto che sarà il più affidabile senza un reparto di QA che con uno. I programmatori non fanno bene QA persone, ed è sempre meglio avere una seconda persona (o più) la revisione come funziona l'applicazione.

Tutte le aziende di software buono, e le organizzazioni con un buon dipartimenti IT che creano i programmi hanno un team di QA. E 'di vitale importanza per lo sviluppo del software.

Answer 2

  

L'(QA) reparto Quality Assurance è più o meno un gruppo di tester debunking vostra applicazione (s) tutto il giorno

Sono turbato che si visualizza QA come "un gruppo di tester debunking tua app" come QA è un blocco stradale per il prodotto finale. Mi fa pensare che hai avuto una brutta esperienza con QA in passato. Invece di cercare di guardare il valore di QA porta alla vostra azienda. Si desidera l'utente finale sia in grado di contare sul vostro prodotto fin dall'inizio. Se l'utente finale è trovare problemi o difetti, e diventando frustrato con la tua applicazione o sito web, si fidano di vostra applicazione sempre meno. QA dovrebbe ridurre il rischio di utenti che perdono fiducia nella vostra app. Se il QA non sta facendo che allora non sono portare il valore che è un must-have per qualsiasi applicazione. A quel punto, è necessario nuovo QA. Non solo button-pusher. QA che conosce l'applicazione altrettanto bene come lo sviluppatore. QA che collabora con il proprietario e sviluppatore di prodotti per assicurarsi che tutti sono sulla stessa pagina per quanto riguarda i requisiti e le aspettative nel prodotto finale.

Una nota finale è sviluppatori non sono QA. Gli sviluppatori dovrebbero solo mettere il cappello sulla QA quando è assolutamente necessario. Questo è difficile in una piccola azienda di 1 o 2 sviluppatori. Quindi sono d'accordo con gli altri quando dicono ottenere QA non appena possibile. Alla mia posizione in loco per una grande azienda di sviluppo software, gli sviluppatori solo mettere sul cappello QA quando abbiamo scadenze difficili che devono essere soddisfatte e il tempo QA è ad un premio. Anche quando lo fanno mettere il cappello sulla QA, il processo di test viene esaminata da uno dei QA piombo su quel team di sviluppo per assicurare che il dev sta testando pienamente ed efficacemente l'applicazione. Solo fino a quando il cavo di QA è soddisfatto del livello di test che è andato nella porzione che il dev ha testato sarà la guida QA firmare su quella parte.

Answer 3

In qualità di ex direttore di QA di una società di software di successo, direi che crescere non appena si rilascia il primo programma. (Prima, se possibile). In realtà, non appena si può permettere. Ma, come sviluppatore, si dovrebbe fare un sacco di test da soli durante l'intero ciclo dev, non solo alla fine. Il lavoro di QA (a seconda di quale libro che hai letto) è quello di gestire un sacco di test legacy, test FUMO, test di regressione, test del mondo reale, e la scrittura di test automatizzati procedure, processi e piani, ecc.

test ad hoc è solo una piccola parte di ciò che QA dovrebbe fare. Ci sono due principali aree di interesse per il QA. 1) Se il software di fare ciò che deve fare, e soddisfare i requisiti in un modo che è utilizzabile dal cliente, e 2) Se il software non fare quello che non dovrebbe fare.

piallato, procedurale e test ad hoc sono alla base della QA. Ho scoperto che se si fa un solo tipo di test o l'altro, non si avrà un ciclo di QA di successo.

Ho rilasciato software senza QA quando si lavora per conto mio, ma posso dirvi, è sempre più inclini errore, non importa quanto ho provarlo. Una seconda serie di occhi + è la cosa migliore per il software.

Basta fare in modo di costruire la tua squadra di A.D.D. anale-ritentiva, computer geek. Otterrete i vostri risultati migliori in questo modo. :) Le persone che sono orgogliosi quando possono fare qualcuno software vanno asta ... eh .. (Sto scherzando .. Io conosco un sacco di QA Tester che non hanno A.D.D) ...

Answer 4

Siamo una piccola startup nuova con un singolo sviluppatore. Ogni volta che si parla di aggiungere ulteriori risorse mia prima risposta è assumermi una persona QA!

Answer 5

Credo che si cresce un reparto di QA biologico: anche quando sei un programmatore solista, si dovrebbe fare alcuni del lavoro che una persona QA fa.

Se, per esempio, una persona spende il 10% delle loro attività QA tempo che fa, poi, non appena si arriva a dieci persone, si può avere una persona dedicata a QA.

Answer 6

Dipende. Se siete una piccola azienda con un po 'di team efficiente e il vostro tasso di errore è basso, probabilmente non è il problema più grande è necessario risolvere.

Se il mercato pressioni di produrre più velocemente, il numero di sviluppatori è in crescita, e il tasso di errore sta cominciando a danneggiare le vostre relazioni con i clienti, allora si può considerare che fissa il processo rendendolo più formale.

Il trucco per sopravvivere in una piccola azienda è quello di implementare solo processo, quando il suo valore paga per sé. Se si sta assumendo persone per ottenere un miglioramento della qualità, deve essere abbastanza grande da pagare per se stessa, il che significa che, prima, la qualità deve essere piuttosto male (e di business dannosi).

Spesso una migliore processo di supporto è molto più importante, perché anche il miglior gruppo QA sarà ancora lasciare che di tanto in tanto gli insetti uscire da lì. I clienti saranno in modo più impressionato con voi se si gestisce bene le correzioni / patch (non noterà una significativa riduzione insetti, a meno che le versioni precedenti erano tutti veramente male).

Paul.

Answer 7

Per fare l'avvocato del diavolo: "reparto di QA" è una falsa pista, e in molti casi un poliziotto-out

.

Diamo trattare con falsa pista prima. "Dipartimento" è una dichiarazione di struttura organizzativa, che riferisce a chi; che è secondario. "QA" è un termine generico, senza alcun significato particolare. (? Non mi credete Ecco un test -?.. Vorresti non "assicurare la qualità" Naturalmente non tutti vogliono che)

Così che cosa è che si vuole veramente qui? Si vuole conoscere modi di guasto del software prima che gli utenti fanno.

Se il software ha "problemi" nel campo, beh, questo significa che il lavoro di capire modi di guasto non è sempre fatto, e si possono voler assumere qualcuno con le doti per fare che.

mi capita di credere che la descrizione del lavoro di uno sviluppatore dovrebbe comprendere almeno alcuni di che. Se assumo tester, preferisco loro di dover lavorare sodo per trovare modalità di guasto. Se l'applicazione si blocca in pochi secondi di un tester di mettere le mani su di esso, gli sviluppatori stanno andando a sentire su di esso in termini diretti. La frase "difetto madornale" viene in mente.

On per il poliziotto-out. La verità è che non si può mettere la qualità nel prodotto dopo il fatto. Ma "dobbiamo assumere alcuni tester" è il grido di molti sviluppatori catturato svolta con le mani nel codice ben al di sotto di livelli accettabili di qualità. (Lo so - sono stato uno di loro.)

Quindi, se si fa assumere qualcuno con esperienza di test, la cosa giusta da fare secondo me è quello di mettere a lavorare fianco a fianco gli sviluppatori. Segnalazione allo stesso gestore. Con la stessa missione:. Renderlo corretto in primo luogo

Answer 8

Bene - si vuole una persona diversa dal programmatore che ha scritto il test del codice. Ciò non significa che avete bisogno di un reparto di QA. In un sacco di negozi analisti aziendali potranno anche fare dei test, che è molto più economico, perché si può essere in prova solo durante l'ultima parte del costruire, non durante l'analisi dei requisiti e la progettazione. In un piccolo negozio che probabilmente non hanno nemmeno usare il business analyst parola, ma sai cosa voglio dire - di prodotti o di progettazione persone che non il codice. Anche in una società molto grande questo modello ha i suoi vantaggi; gruppi di test possono assumere una vita propria.

Answer 9

Non appena il codice di base cresce così grande che una sola persona non può conoscere tutti i dettagli.

Il ragionamento alla base di questo è che il 90% delle regressioni sono fatti perché i programmatori non sono consapevoli del intero quadro e possibile effetto collaterale del loro codice sul resto del sistema. In questi casi non si sa nemmeno che si non deve mai fornire -1 come parametro di età o qualcosa di simile. Nella maggior parte dei casi, le interfacce dovrebbero essere chiare e avere il controllo degli errori, ma in grandi basi di codice Si scivola, anche quando si punta a rispettare la scadenza, o lavorare per lunghe ore sono gocce di concentramento.

Quindi, anche se si dovrebbe fare dei test di base, anche quando sei un one man show , roba come unit test e simili strutture di collaudo automatizzati dovrebbero essere utilizzati non appena il codice cresce abbastanza grande che si ( o chiunque altro possa lavorare con voi) non può afferrare l'intero sistema in mente.

Answer 10

dovrebbe funzionare senza QA, ma con

• CI Software
• programmazione aziendale (e analizzare e progettare e di ..) le linee guida e alcuni strumenti per "forzare" il programmatore di andare con loro
• alcune recensioni ora e poi
• fasi di test ad esempio squadra-test-ambiente, l'integrazione (tutte le applicazioni insieme) e consolidamento (stesso di integrazione, ma con le copie dei dati di produzione)
• se neeeded un gruppo di pianificazione di rilascio
• e .. beh .. programmatori buoni artigiani

Answer 11

Sono attualmente in esecuzione una società di software garage-startup, in questo momento ho sostituire un Q & A con la famiglia e gli amici, li ho richiamare o farli venire per un paio di birre e test drive il mio prodotto per me.

Questo test "corridoio" ha funzionato abbastanza bene finora, poi di nuovo il mio prodotto non è rivolto agli utenti tecnicamente esperti, se era Potrei avere un tempo più difficile trovare i tester.

Se non si dispone di prontamente disponibile famiglia e gli amici vi consiglio che getta un'annuncio nella vostra annunci locali o Craigslist, dovrebbe essere difficile trovare un paio di studenti o qualcuno che metterà alla prova per il salario minimo.

Per quanto riguarda quando di assumere pieno del personale volta QA direi dipende esclusivamente dallo stato finanziario della società.

Answer 12

Quando si ha una - due società a noleggiare un tester può essere eccessivo. Provate a trascorrere del tempo sui test da soli. O chiedere ad un amico sviluppatore (che non è sulla squadra) per giocare con app per qualche tempo. O chiedere ad un amico (non sviluppatori) - quasi come User Acceptance Testing
. Noleggio quando si inizierà a vendere il software, quando si avrà 3 o più sviluppatori, quando si avranno due molto in mente di fare il test (e dico davvero non testare 'inizia sulla mia macchina', ma 'ho cercato di schiacciarlo per diverse ore, ma funziona ancora. Forse dovrei ottenere davvero la creatività? ').