Come vengono eseguiti i test software alle startup tecnologiche?

10

Ho visto molti articoli di ricerca e blog tecnici che vantano i vantaggi dei test del software. Ne ho convinto. Ma poiché tutte le ricerche sui test del software sono condotte da grandi società di software, non credo che si applichino davvero alle startup. Poiché le startup hanno esigenze e vincoli diversi rispetto alle grandi società di software.

Quindi questo ha sollevato le domande. Le startup tecnologiche dovrebbero scrivere test automatici? In tal caso, vengono eseguiti allo stesso modo delle grandi società di software? (test del fumo, test di regressione, ecc.) È meglio se puoi fare riferimento ad alcuni articoli di ricerca su questo argomento ... dal momento che non sono riuscito a trovarne nessuno da solo.

(Devo ammettere che anche se sono ancora agli inizi della mia carriera, ma devo ancora vedere una startup che è seriamente impegnata a scrivere test automatizzati)

testing startup

— ming_codes
fonte

5

Mi sono unito a una piccola start-up da 10 anni e sono stato il primo ad aggiungere effettivamente test eseguiti di notte. Non perché fossi un genio, ma questa era la prima volta che il manager (anche programmatore) ha riconosciuto che era giunto il momento di aggiungerli e che finalmente avevano la forza lavoro. Gli stratagemmi spesso devono sopravvivere prima e perfezionare in seguito. Certo, questa start-up è stata avviata da non esperti, quindi questa funzione doveva essere "inserita".

— Giobbe

5

Avvio di 10 anni ...?

— pap

Dilbert ha dichiarato : "Se le migliori pratiche sono adottate da tutti nel settore, allora le migliori pratiche diventano mediocrità". Immagino sia un po 'vero, eh.

— ming_codes

Avvio di 10 anni ... devono usare Java: 3 anni di progettazione + 7 di sviluppo :) scherzando (I am a Java dev btw)

— nuvio

11

C'è sempre un conflitto tra ciò che dovrebbe essere fatto e ciò per cui realisticamente abbiamo tempo. Sì, molte startup rinunciano allo sviluppo guidato dai test e ai test automatizzati per radersi un po 'di tempo libero per avviare un progetto.

I siti di social network e le aziende di app mobili sono le grandi bolle ora e sono fortemente competitivi. A volte la differenza tra andare a vivere in 4 mesi contro 5 mesi significa perdere.

Il time-to-market è la chiave, e quindi se si verifica il successo, allora è il momento di ridimensionare, quindi ci sarà un sacco di tempo per trasformare il tuo software non testato di merda in qualcosa di utile.

— albero_acero
fonte

Tuttavia, il time to market è un po 'un mito. I concorrenti in ritardo in un mercato possono spazzare via i giocatori esistenti: amici> myspace> facebook.

— Joeri Sebrechts,

@JoeriSebrechts Ho letto un articolo interessante sulla progressione del software e su come si collega al successo dei concorrenti in ritardo. Ci sono variabili in gioco, il periodo di sicurezza per un concorrente in ritardo con una soluzione simile è uguale alla quantità di tempo che la base di utenti di un software può trasformare dai primi utenti ad utenti generici. Una soluzione simile ovviamente significa caratteristiche simili e non innovative rispetto al primo arrivato nel mercato (ad esempio Facebook è stato rivoluzionario rispetto a MySpace). Una volta raggiunta una massa critica di Early Adopters, gli utenti generici iniziano a migrare.

— maple_shaft

12

Il test del software non è una religione. È solo un'ottima idea.

Dici di non avere la forza lavoro per scrivere test adesso? Ok bene. Tra 6 settimane, avrai la forza lavoro per trovare il bug che sta bloccando la tua applicazione, che sarebbe stato trovato immediatamente se avessi messo a punto dei test adeguati?

Troppi test possono rallentare lo sviluppo. Troppi test possono anche rallentarlo. Devi trovare il giusto equilibrio, e di solito è difficile dire dove sia. E nulla di tutto ciò è specifico per le grandi o piccole aziende.

— Mike Baranczak
fonte

4

Per molti anni, mentre lavoravo in piccole aziende e start-up, avevo il malinteso che "non avevo abbastanza tempo per scrivere test unitari per il mio codice" .

Quando scrivevo i test, erano cose gonfie e pesanti che mi incoraggiavano solo a pensare che avrei dovuto scrivere test unitari solo quando sapevo che erano necessari.

Di recente sono stato incoraggiato a utilizzare Test Driven Development e l'ho trovato una rivelazione completa .

Ora sono fermamente convinto che "non ho il tempo di non scrivere unit test" .

Nella mia esperienza, sviluppando pensando ai test, si ottengono interfacce più pulite, classi e moduli più mirati e in genere più codice SOLID , testabile.

Ogni volta che lavoro con un codice legacy che non ha test unitari e devo testare manualmente qualcosa, continuo a pensare "questo sarebbe molto più veloce se questo codice avesse già dei test unitari" . Ogni volta che devo provare ad aggiungere funzionalità di unit test al codice con elevato accoppiamento, continuo a pensare "sarebbe molto più facile se fosse stato scritto in modo disaccoppiato" .

Se c'è una cosa che ho scoperto nel corso degli anni, se stai lavorando in una start-up devi essere agile e non solo nel senso della metodologia di sviluppo del software . Per me TDD è uno strumento importante che consente di iniziare e rimanere agili .

— Mark Booth
fonte

1

Non si tratta di chi dovrebbe fare test del software, Test del software è una specie di filosofia di sviluppo del software. Il test del software pone le basi di una buona qualità del software e, in una startup, la qualità del software è un vantaggio quando l'acquisizione da parte di una grande azienda è dietro l'angolo;)

— Francisco Valdez
fonte

1

Le migliori pratiche riguardano l'intero settore, sia che tu stia trasformando la nonna in un sito Web o creando il sistema di guida per un satellite. Dovrebbero essere sempre seguiti da coloro che vogliono considerarsi professionali, ecco perché sono chiamati le MIGLIORI pratiche.

— Ryathal
fonte

Potresti essere sorpreso di apprendere che le migliori pratiche non sono così diffuse nel settore. thedailywtf.com

— Gary Willoughby,

@Gary è più un settore in teoria, o parte di quel mondo utopico in cui i progetti hanno scadenze realistiche e html ha un significato semantico e i manager ammettono di non avere conoscenze tecniche che li aiuterebbero a prendere decisioni migliori ...

— Ryathal

"Best practice" di solito significa fare cose come fanno tutti gli altri, producendo un risultato medio. La compagnia mediamente affermata si comporta abbastanza bene, ma l'avvio tecnologico medio non arriva abbastanza lontano da un arresto spettacolare.

— David Thornley,

1

@DavidThornley - No, penso che "Best Practice" sia ciò che la maggior parte delle persone crede che dovrebbero fare, indipendentemente dal fatto che abbiano il tempo, l'energia o l'approvazione della direzione per farlo. * 8 ')

— Mark Booth,

@Mark Booth: in genere, quando ho sentito la frase, significa quello che ho detto. YMMV, ovviamente. Tuttavia, Ryathal si riferisce a un mondo in cui i progetti hanno scadenze realistiche e ciò non è necessariamente possibile nel mondo degli affari. Avere un prodotto in uscita con due mesi di ritardo può essere insignificante o fatale (in particolare per una startup che potrebbe essere a rischio di rimanere senza soldi), e spesso fastidiosamente c'è un valido caso commerciale per ottenere qualcosa che per lo più esce dalla porta il prima possibile. Trovo difficile credere nelle "migliori pratiche" che possono condannare un'azienda.

— David Thornley,

1

Sì, le startup a volte tagliano gli angoli e non impiantano test adeguati. A volte questo è appropriato (per progetti abbastanza piccoli o quando il tempo / denaro sono fondamentali)

Questo non è esclusivo per le startup però. Uno dei nostri fornitori di appaltatori IT addirittura ha un ambiente di test. Tutto è fatto per vivere e questa è una grande società di software multinazionale (spaventosa!)

— Tom Squires
fonte

1

Dovrebbero? Sì. Lo fanno in pratica, non tutte le volte che dovrebbero.

Il motivo più tipico indicato è la mancanza di risorse che include il tempo degli sviluppatori, i costi per l'assunzione di un tester dedicato o part-time, il costo di creazione di un ambiente di test e così via. Puoi persino trovare queste scuse in grandi ambienti aziendali e in piccole start-up.

Guardando in un altro modo, i test sono una delle cose più facili da tagliare da un programma di sviluppo, in particolare uno con una pressione del tempo molto stretta e / o pressione dei costi per produrre risultati visibili. Insieme a un lavoro di progettazione dettagliato, è considerato "fluff" da molti manager e il primo posto che diranno "taglialo in modo che possiamo far funzionare il nostro programma e il budget" seguito da "Perché non stai programmando?".

In alcune aziende, ci sarà qualcuno che esegue i test push. Di solito questo sarà lo sviluppatore assunto e di solito saranno qualcuno con esperienza e probabilmente qualcuno che ha una partecipazione finanziaria di qualche tipo nell'azienda. Una società che inizia con questo "DNA" probabilmente eseguirà dei test dall'inizio.

— jfrankcarr
fonte