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

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)

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.

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.

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 .

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;)

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.

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!)

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.