Comment les tests logiciels sont-ils effectués dans les startups technologiques?

10

J'ai vu de nombreux articles de recherche et blogs technologiques qui présentent les avantages des tests de logiciels. J'en suis convaincu. Mais comme toutes les recherches sur les tests de logiciels sont menées par de grandes sociétés de logiciels, je ne pense pas qu'elles s'appliquent vraiment aux startups. Depuis les startups ont des besoins et des contraintes différentes par rapport aux grandes sociétés de logiciels.

Cela a donc soulevé des questions. Les startups technologiques devraient-elles écrire des tests automatisés? Si oui, sont-ils effectués de la même manière que les grandes sociétés de logiciels? (test de fumée, test de régression, etc.) Il est préférable que vous puissiez vous référer à des articles de recherche sur ce sujet .. car je n'ai pas pu en trouver par moi-même.

(Je dois admettre que même si je suis encore au début de ma carrière, mais je n'ai pas encore vu une startup sérieusement engagée à écrire des tests automatisés)

ming_codes
la source
5
J'ai rejoint une petite start-up de 10 ans et j'ai été le premier à ajouter des tests qui s'exécutent la nuit. Non pas parce que j'étais un génie, mais c'était la première fois que le manager (également codeur) reconnaissait qu'il était temps de les ajouter et qu'ils avaient enfin la main d'œuvre. Les strat-ups doivent souvent survivre en premier et se perfectionner ensuite. Certes, cette start-up a été lancée par des non-techniciens, donc cette fonctionnalité a dû être "intégrée".
Job
5
Démarrage de 10 ans ...?
pap
Dilbert a déclaré : "Si les meilleures pratiques sont adoptées par tout le monde dans l'industrie, alors les meilleures pratiques deviennent de la médiocrité." Je suppose que c'est un peu vrai, heh.
ming_codes
Start-up de 10 ans ... ils doivent utiliser Java: 3 ans de conception + 7 de développement :) plaisante juste (je suis un développeur Java btw)
nuvio

Réponses:

11

Il y a toujours un conflit entre ce qui doit être fait et ce pour quoi nous avons réellement le temps. Oui, de nombreuses startups renoncent au développement piloté par les tests et aux tests automatisés pour gagner du temps afin de mettre un projet en place.

Les sites de réseautage social et les sociétés d'applications mobiles sont désormais de grandes bulles et ils sont extrêmement compétitifs. Parfois, la différence entre la mise en ligne dans 4 mois et 5 mois signifie que vous perdez.

Le temps de mise sur le marché est la clé, puis si le succès se produit, il est temps de passer à l'échelle, alors il y aura beaucoup de temps pour transformer votre logiciel non testé en quelque chose de valable.

maple_shaft
la source
Le délai de commercialisation est cependant un peu un mythe. Les entrants tardifs sur un marché peuvent faire exploser les joueurs existants: friendster> myspace> facebook.
Joeri Sebrechts
@JoeriSebrechts J'ai lu un article intéressant sur la progression du logiciel et son lien avec le succès des derniers entrants. Il existe des variables en jeu, la période de sécurité pour un entrant tardif avec une solution similaire est égale au temps nécessaire à la base d'utilisateurs d'un logiciel pour passer des premiers utilisateurs aux utilisateurs généraux. Une solution similaire signifie bien sûr des fonctionnalités similaires et non révolutionnaires par rapport au premier entrant sur le marché (par exemple, Facebook était révolutionnaire par rapport à MySpace). Une fois qu'une masse critique d'adopteurs précoces est atteinte, les utilisateurs généraux commencent à migrer.
maple_shaft
12

Les tests de logiciels ne sont pas une religion. C'est juste une très bonne idée.

Vous dites que vous n'avez pas les effectifs nécessaires pour passer des tests en ce moment? OK bien. Dans 6 semaines, allez-vous avoir la main-d'œuvre pour trouver le bogue qui plante votre application, qui aurait été trouvé immédiatement si vous aviez mis en place les tests appropriés?

Trop de tests peuvent ralentir le développement. Trop peu de tests peuvent également le ralentir. Vous devez trouver le bon équilibre, et il est généralement difficile de dire où cela se trouve. Et rien de tout cela n'est spécifique aux grandes ou petites entreprises.

Mike Baranczak
la source
4

Pendant de nombreuses années, alors que je travaillais dans de petites entreprises et des start-ups, je pensais à tort que je "n'avais pas assez de temps pour écrire des tests unitaires pour mon code" .

Quand j'ai fait des tests, ils étaient gonflés, des choses lourdes qui ne m'ont encouragé à penser que je ne devrais jamais écrire des tests unitaires que lorsque je savais qu'ils étaient nécessaires.

Récemment, j'ai été encouragé à utiliser le développement piloté par les tests et j'ai trouvé que c'était une révélation complète .

Je suis maintenant fermement convaincu que je "n'ai pas le temps de ne pas écrire de tests unitaires" .

D'après mon expérience, en développant en gardant à l'esprit les tests, vous vous retrouvez avec des interfaces plus propres, des classes et des modules plus ciblés et généralement un code plus solide et testable.

Chaque fois que je travaille avec du code hérité qui n'a pas de tests unitaires et que je dois tester manuellement quelque chose, je continue de penser "ce serait tellement plus rapide si ce code avait déjà des tests unitaires" . Chaque fois que je dois essayer d'ajouter une fonctionnalité de test unitaire au code avec un couplage élevé, je continue de penser "ce serait tellement plus facile s'il avait été écrit de manière découplée" .

S'il y a une chose que j'ai découverte au fil des ans, si vous travaillez dans une start-up, vous devez être agile , et pas seulement dans le sens de la méthodologie de développement logiciel . Pour moi, TDD est un outil important qui permet de démarrer et de rester agile .

Mark Booth
la source
1

Il ne s'agit pas de savoir qui devrait faire des tests de logiciels, les tests de logiciels sont une sorte de philosophie de développement logiciel. Les tests de logiciels posent les bases d'une bonne qualité logicielle, et dans une startup, la qualité logicielle est un bonus lorsque l'acquisition par une grande entreprise approche à grands pas;)

Francisco Valdez
la source
1

Les meilleures pratiques sont à l'échelle de l'industrie, que vous fassiez de grand-mère un site Web ou que vous créiez le système de guidage pour un satellite. Ils doivent toujours être suivis par ceux qui veulent se considérer comme professionnels, c'est pourquoi ils sont appelés meilleures pratiques.

Ryathal
la source
Vous serez peut-être surpris d'apprendre que les meilleures pratiques ne sont pas à l'échelle de l'industrie. thedailywtf.com
Gary Willoughby
@Gary est plus une industrie large en théorie, ou une partie de ce monde utopique où les projets ont des échéanciers réalistes et le html a une signification sémantique et les gestionnaires admettent qu'ils manquent de connaissances techniques qui les aideraient à prendre de meilleures décisions ...
Ryathal
«Meilleures pratiques» signifie généralement faire des choses comme tout le monde, produisant un résultat moyen. L'entreprise moyenne établie se débrouille assez bien, mais le démarrage technologique moyen ne va pas assez loin pour se planter de manière spectaculaire.
David Thornley
1
@DavidThornley - Non, je pense que la "meilleure pratique" est ce que la plupart des gens pensent qu'ils devraient faire, qu'ils aient ou non le temps, l'énergie ou l'approbation de la direction pour le faire. * 8 ')
Mark Booth
@Mark Booth: En général, quand j'ai entendu la phrase, cela signifie ce que j'ai dit. YMMV, bien sûr. Cependant, Ryathal fait référence à un monde où les projets ont des délais réalistes, et ce n'est pas nécessairement possible dans les affaires. La sortie d'un produit avec deux mois de retard peut être sans conséquence ou fatale (en particulier pour une startup qui risque de manquer d'argent), et il est souvent ennuyeux qu'il existe une solide analyse de rentabilisation pour obtenir quelque chose qui fonctionne le plus souvent dès que possible. J'ai du mal à croire aux "bonnes pratiques" qui peuvent condamner une entreprise.
David Thornley
1

Oui, les startups réduisent parfois les coins et n'implémentent pas de tests appropriés. Parfois, cela est approprié (pour des projets suffisamment petits ou lorsque le temps / l'argent est critique)

Ce n'est cependant pas exclusif aux startups. Un de nos fournisseurs de sous-traitants informatiques a même un environnement de test. Tout est fait directement pour vivre et c'est une grande société de logiciels multinationale (effrayant!)

Tom Squires
la source
1

Devraient-ils? Oui. Le font-ils dans la pratique, pas aussi souvent qu'ils le devraient.

La raison la plus typique donnée est le manque de ressources qui comprend le temps du développeur, le coût de l'embauche d'un testeur dédié ou à temps partiel, le coût de la mise en place d'un environnement de test, etc. Vous pouvez même trouver ces excuses dans les grandes entreprises ainsi que dans les petites start-ups.

Vu sous un autre angle, le test est l'une des choses les plus faciles à couper dans un calendrier de développement, en particulier avec des contraintes de temps et / ou de coûts très serrées pour produire des résultats visibles. Parallèlement à un travail de conception détaillé, il est considéré comme «fluff» par de nombreux gestionnaires et le premier endroit, ils diront «coupez-le afin que nous puissions faire fonctionner notre calendrier et notre budget» suivi de «Pourquoi ne codez-vous pas?».

Dans certaines entreprises, il y aura quelqu'un qui poussera les tests. Habituellement, ce sera le développeur embauché et généralement ce sera quelqu'un d'expérience et probablement quelqu'un qui aura un intérêt financier quelconque dans l'entreprise. Une entreprise qui commence avec cet "ADN" fera probablement des tests dès le départ.

jfrankcarr
la source