Les libérer. (à en juger par les tas de buggy de .... qui sortent des grandes institutions)
Orbling
Ils ont une campagne de vente et de marketing très agressive, sous-traitent le développement à d'autres pays et s'en tirent avec tous les bugs qu'ils peuvent ... jusqu'à ce qu'ils perdent "de manière inattendue" une énorme part de marché.
Job
Pourquoi pensez-vous que c'est différent pour les grandes entreprises que pour les petites?
JohnFx
Réponses:
30
Voici quelques-unes des techniques utilisées par Google.
Embauchez de bons développeurs susceptibles de produire du code fiable.
Configurez une génération continue pour détecter les problèmes d'intégration.
Avoir des départements AQ dédiés. Cela signifie à la fois des tests de personnes et des programmes automatisés (par exemple en utilisant Selenium) qui simulent les utilisateurs finaux.
Ayez une surveillance en production pour attraper des preuves de mauvais comportement.
Je les ai classés dans ce que je soupçonne être un ordre décroissant d'efficacité dans la capture des bogues.
Bien que ce ne soit pas une mauvaise réponse, vous utilisez beaucoup de terminologie comme "QA", "test unitaire" et "build continu" qui sont probablement inconnues du genre de personne qui poserait une question comme celle-ci. Il serait préférable que vous établissiez un lien ou donniez des définitions.
Gabe
@gabe: J'ai ajouté des pointeurs à la terminologie utilisée.
btilly
3
+1 - En fait, c'est un assez bon ordre (1-> 6) quand il est MEILLEUR (c'est-à-dire le moins cher, en temps et en complexité) d'attraper des bugs également.
ozz
1
peut-être aussi des tests d'utilisabilité, avant que le ruban 90% des demandes de fonctionnalités de mot ne concernent des fonctionnalités que le mot avait déjà, les utilisateurs ne pouvaient tout simplement pas les trouver
jk.
@jk: dont la statistique est-ce? citation s'il vous plaît.
JBRWilkinson
19
Les grandes entreprises ont généralement des départements entiers de Q / A qui sont chargés de tester le code et de s'assurer qu'il fonctionne comme il est censé le faire. C'est généralement comme vous l'avez décrit - un tas de gens qui testent beaucoup de machines. Parfois, les tests sont automatisés, parfois non. Voir Assurance qualité - Wikipedia
Plusieurs fois, les développeurs eux-mêmes trouveront des bogues pendant le processus de développement. De plus, les clients sont souvent les premiers à trouver un bug.
Les petites entreprises, comme celle pour laquelle je travaille actuellement, utilisent la pratique des tests agiles
Yup, et les gens de QA composent des plans de test.
Job
+1: C'est exactement comme ça que nous le faisons, l'équipe de test (dont je fais partie) écrit les plans de test et écrit tout le code de test à l'exception des tests unitaires triviaux (les développeurs écrivent ceux-ci, certains pratiquent TDD mais ce n'est pas obligatoire). Nous nous concentrons sur l'acceptation, l'intégration et les régressions. Lorsque les développeurs découvrent des bogues, ils le consignent, le corrigent et nous le testons et écrivons l'automatisation pour cela.
Steven Evers
18
Je dirais que c'est à propos de la maturité d'une entreprise et non de sa taille :) Il y a de grandes entreprises qui ont de mauvaises pratiques de développement et de petites entreprises qui sont à la pointe du progrès.
En général, une équipe de développement mature s'engage dans les activités suivantes à 1; minimiser l'introduction de nouveaux bogues dans le système et 2; trouver des bogues dans le système existant.
Tests unitaires: il s'agit de «mini-pilotes» pour des méthodes individuelles afin de s'assurer qu'une méthode fait ce qu'elle dit. Ce sont toujours des tests automatisés.
Tests d'intégration: ces tests visent à vérifier qu'une plus grande unité de fonctionnalités fonctionne au sein du système. Cela peut impliquer de tester l'intégration de la base de données ou l'intégration avec des bibliothèques tierces. Ce sont également des tests automatisés.
Test d'acceptation: les tests d'acceptation sont écrits pour tester les besoins des utilisateurs. Ceux-ci testent généralement le «chemin heureux». Dans mon équipe, ces tests sont conçus pour montrer que si l'utilisateur utilise la fonctionnalité telle qu'elle a été conçue pour être utilisée, il n'aura aucun problème. Peut être manuel ou automatisé.
Tests fonctionnels: Ces tests sont similaires aux tests d'acceptation, mais ils testent également le «chemin malheureux». Ces tests visent à tester les scénarios pas si évidents. Peut être manuel ou automatisé.
Tests de régression: nous utilisons ce terme pour effectuer un «test complet» du système avant sa mise à disposition aux clients. Manuelle ou automatisée.
Test des gorilles: (manuel uniquement). C'est le genre de test lorsque des humains très intelligents tentent intentionnellement de casser l'application.
Test de performances Vise à s'assurer que les performances sont acceptables et ne se dégradent pas avec le temps. Habituellement automatisé.
Test de stabilité: Ces tests sont conçus pour s'assurer que le système reste stable dans le temps. Automatique.
Intégration continue: il s'agit d'un système qui extrait automatiquement votre code, le compile et exécute vos tests automatisés. Vos tests plus rapides (unité, intégration) s'exécuteront chaque fois qu'un développeur valide du code. Certains autres fonctionnent tous les soirs (acceptation, fonctionnels) ou hebdomadaires (performances, stabilité).
Rapports de couverture de code: vous indique la quantité de code testée. Le code qui n'a pas de couverture de test est plus susceptible de casser.
Différents outils qui analysent le code: ils montrent généralement où le code doit être refacturé pour le rendre moins sujet aux bogues potentiels.
Programmation en binôme: deux développeurs travaillant ensemble pour offrir des fonctionnalités. "Une paire cohérente vaut mieux que la somme de ses parties."
Le plus important à retenir est: l' automatisation et l'intégration continue .
Pas d'accord sur la maturité de l'entreprise - il est tout à fait possible que le responsable du développement logiciel se soucie également de la qualité dans une petite / jeune entreprise, et ce message est transmis de haut en bas. La maturité des ingénieurs, oui, c'est possible.
JBRWilkinson
1
@JBRWilkinson: Je suppose que nous pouvons commencer à parler de ce que signifie pour une entreprise d'être «mature». Je ne voulais pas suggérer que cela a à voir avec l'âge, plus comme la «sagesse». Une startup peut être mature / sage même si elle n'a que un an ou deux.
c_maker
4
Cela dépend de l'entreprise et des produits qu'elle développe.
Tout d'abord, de nombreuses entreprises appliquent des pratiques de codage telles que les révisions de code et les peluches obligatoires (outils de détection de bogues automatisés) pour réduire le nombre d'erreurs entrant dans le référentiel. De nombreuses entreprises ont également adopté les tests unitaires. C'est le cas où je travaille (Google). Lorsque le code est archivé, les tests sont exécutés sur tout, pour s'assurer qu'aucune nouvelle erreur n'est introduite.
Deuxièmement, de nombreuses entreprises ont des départements d'AQ chargés de valider les comportements. Cela est particulièrement courant en Finance (où les erreurs peuvent être coûteuses et les règles de validation sont complexes), mais existe également dans les entreprises qui vendent des produits aux utilisateurs où les rappels peuvent être coûteux (par exemple, Intel, Microsoft, etc.).
Troisièmement, dans la mesure du possible, les entreprises font Dogfooding (ont leurs propres utilisateurs utilisent le produit en interne), puis libèrent des bêtas limitées. De nombreuses erreurs sont détectées à ce stade. Par exemple, les gens travaillant chez Microsoft utilisent des versions internes plus récentes d'Office et Windows et DevStudio que celles que vous avez à l'extérieur. Ensuite, des groupes restreints d'utilisateurs ou des entreprises sous contrat peuvent l'échantillonner. De même, chez Google, nous utilisons des versions internes de GMail et Docs avant la sortie. Les sociétés de jeux organisent des bêtas ouvertes pour tester leurs produits et la charge sur les serveurs, etc.
Bien sûr, la réponse est "Ça dépend", mais je vais donner un échantillon de mon plus grand projet à ce jour, qui avait à l'heure de pointe environ 50 développeurs impliqués.
La configuration de base: un logiciel principal pour traiter de grandes quantités de données avec BizTalk.
La première ligne de défense sont les tests unitaires. Dans notre cas, ceux-ci ont été exécutés quotidiennement pour tout ce qui a été vérifié dans le contrôle de code source et généralement certains d'entre eux ont été exécutés manuellement par le développeur avant l'enregistrement. Les tests unitaires ont été principalement écrits par les développeurs mais parfois modifiés par des tests supplémentaires par les testeurs.
L'étape suivante a été une construction hebdomadaire de Virtual PC, où les testeurs ont exécuté une série de tests de bout en bout principalement automatisés sur le flux de données en fonction des documents de spécification de chaque composant.
Après cela, le même Virtual PC a été enrichi de certaines données commerciales assez proches de la réalité et testé à nouveau avec des cas d'utilisation spécifiques.
Ensuite, le Virtual PC a été mis en place avec d'autres composants du système (également principalement virtuels) d'autres services pour un cycle de test d'intégration basé sur des tests de bout en bout de l'utilisateur entrant les données jusqu'à la fin du flux de données.
Sur une autre piste, les paquets d'installation ont été testés par le fournisseur de systèmes pour voir s'ils étaient installés correctement dans un environnement de production et s'ils pouvaient être annulés en cas de défaillance.
Après l'installation sur l'environnement de production, nous y avons effectué des tests de charge et de stress pour tester la stabilité globale (pas quelque chose à prendre à la légère lorsque vous exécutez sur 10 serveurs BizTalk, 8 serveurs SQL et un tas d'autres matériels spécialisés comme un accélérateur XML et une archive dédiée - tous regroupés bien sûr).
Lorsque nous avons été satisfaits de tous les tests, le code a été mis en production. Vous obtenez une latence assez importante pour corriger les bogues dans le code (comme 4-6 semaines pour tout le cycle de test), et cela coûte cher de faire tous ces tests, mais la stabilité globale était assez bonne. En fait, le meilleur que j'ai vu jusqu'à présent. Encore une fois, c'est assez important pour un système qui traite chaque jour plusieurs millions de dollars. Vos besoins peuvent varier, mais c'est ainsi que nous l'avons fait et que cela a fonctionné.
La question d'origine semble plus conceptuellement générique que la plupart des réponses très détaillées qui ont été fournies.
Regardons cela d'un niveau supérieur (moins détaillé). Le logiciel est développé pour répondre aux besoins spécifiques de quelqu'un (personne, entreprise, etc.).
Ces besoins doivent être mis en correspondance avec les histoires / exigences individuelles qui seraient récemment (dans une phase de construction) mises en œuvre dans le code source.
Une bonne définition des histoires / exigences est essentielle pour que l'équipe d'assurance qualité (les vrais testeurs de logiciels) valide le code final, lorsqu'il est exécuté, répond aux exigences de ces histoires et exigences. Donc, dans ce but, l'équipe QA crée des "testcases" pour faire cette validation.
Le code, une fois publié à l'équipe QA, sera ensuite testé et des bugs seront identifiés. Bogues de types et de sévérités différents. Ces bogues sont suivis et les développeurs les assignent pour enfin les corriger.
De nos jours, l'utilisation de machines virtuelles permet à un testeur d'exécuter différents environnements dans un même matériel réel. Mais parfois, vous finissez par avoir besoin d'ordinateurs dédiés à la phase d'assurance qualité.
J'espère que cela vous aide à comprendre (approximativement) le processus global.
Eh bien, je déteste être cynique, mais avec le nombre de bogues ouverts dans un certain système d'exploitation `` appareil '', il semble que plus l'entreprise est grande et riche, plus elle est capable de créer et de livrer à l'utilisateur final des bogues. Si le logiciel fonctionne un peu et a l'air cool, ils le libèrent quand même. Si les gestionnaires pensent que c'est prêt, alors c'est prêt. C'est à ce moment-là que les insectes vraiment désagréables commencent à sortir des boiseries et que les utilisateurs finaux deviennent des cobayes. Une dizaine d'années plus tard, la plupart des bogues auront été résolus (et quelques-uns ajoutés pour faire bonne mesure) et la société sera prête à passer à la prochaine grande idée.
Réponses:
Voici quelques-unes des techniques utilisées par Google.
Je les ai classés dans ce que je soupçonne être un ordre décroissant d'efficacité dans la capture des bogues.
la source
Les grandes entreprises ont généralement des départements entiers de Q / A qui sont chargés de tester le code et de s'assurer qu'il fonctionne comme il est censé le faire. C'est généralement comme vous l'avez décrit - un tas de gens qui testent beaucoup de machines. Parfois, les tests sont automatisés, parfois non. Voir Assurance qualité - Wikipedia
Plusieurs fois, les développeurs eux-mêmes trouveront des bogues pendant le processus de développement. De plus, les clients sont souvent les premiers à trouver un bug.
Les petites entreprises, comme celle pour laquelle je travaille actuellement, utilisent la pratique des tests agiles
la source
Je dirais que c'est à propos de la maturité d'une entreprise et non de sa taille :) Il y a de grandes entreprises qui ont de mauvaises pratiques de développement et de petites entreprises qui sont à la pointe du progrès.
En général, une équipe de développement mature s'engage dans les activités suivantes à 1; minimiser l'introduction de nouveaux bogues dans le système et 2; trouver des bogues dans le système existant.
Tests unitaires: il s'agit de «mini-pilotes» pour des méthodes individuelles afin de s'assurer qu'une méthode fait ce qu'elle dit. Ce sont toujours des tests automatisés.
Tests d'intégration: ces tests visent à vérifier qu'une plus grande unité de fonctionnalités fonctionne au sein du système. Cela peut impliquer de tester l'intégration de la base de données ou l'intégration avec des bibliothèques tierces. Ce sont également des tests automatisés.
Test d'acceptation: les tests d'acceptation sont écrits pour tester les besoins des utilisateurs. Ceux-ci testent généralement le «chemin heureux». Dans mon équipe, ces tests sont conçus pour montrer que si l'utilisateur utilise la fonctionnalité telle qu'elle a été conçue pour être utilisée, il n'aura aucun problème. Peut être manuel ou automatisé.
Tests fonctionnels: Ces tests sont similaires aux tests d'acceptation, mais ils testent également le «chemin malheureux». Ces tests visent à tester les scénarios pas si évidents. Peut être manuel ou automatisé.
Tests de régression: nous utilisons ce terme pour effectuer un «test complet» du système avant sa mise à disposition aux clients. Manuelle ou automatisée.
Test des gorilles: (manuel uniquement). C'est le genre de test lorsque des humains très intelligents tentent intentionnellement de casser l'application.
Test de performances Vise à s'assurer que les performances sont acceptables et ne se dégradent pas avec le temps. Habituellement automatisé.
Test de stabilité: Ces tests sont conçus pour s'assurer que le système reste stable dans le temps. Automatique.
Intégration continue: il s'agit d'un système qui extrait automatiquement votre code, le compile et exécute vos tests automatisés. Vos tests plus rapides (unité, intégration) s'exécuteront chaque fois qu'un développeur valide du code. Certains autres fonctionnent tous les soirs (acceptation, fonctionnels) ou hebdomadaires (performances, stabilité).
Rapports de couverture de code: vous indique la quantité de code testée. Le code qui n'a pas de couverture de test est plus susceptible de casser.
Différents outils qui analysent le code: ils montrent généralement où le code doit être refacturé pour le rendre moins sujet aux bogues potentiels.
Programmation en binôme: deux développeurs travaillant ensemble pour offrir des fonctionnalités. "Une paire cohérente vaut mieux que la somme de ses parties."
Le plus important à retenir est: l' automatisation et l'intégration continue .
la source
Cela dépend de l'entreprise et des produits qu'elle développe.
Tout d'abord, de nombreuses entreprises appliquent des pratiques de codage telles que les révisions de code et les peluches obligatoires (outils de détection de bogues automatisés) pour réduire le nombre d'erreurs entrant dans le référentiel. De nombreuses entreprises ont également adopté les tests unitaires. C'est le cas où je travaille (Google). Lorsque le code est archivé, les tests sont exécutés sur tout, pour s'assurer qu'aucune nouvelle erreur n'est introduite.
Deuxièmement, de nombreuses entreprises ont des départements d'AQ chargés de valider les comportements. Cela est particulièrement courant en Finance (où les erreurs peuvent être coûteuses et les règles de validation sont complexes), mais existe également dans les entreprises qui vendent des produits aux utilisateurs où les rappels peuvent être coûteux (par exemple, Intel, Microsoft, etc.).
Troisièmement, dans la mesure du possible, les entreprises font Dogfooding (ont leurs propres utilisateurs utilisent le produit en interne), puis libèrent des bêtas limitées. De nombreuses erreurs sont détectées à ce stade. Par exemple, les gens travaillant chez Microsoft utilisent des versions internes plus récentes d'Office et Windows et DevStudio que celles que vous avez à l'extérieur. Ensuite, des groupes restreints d'utilisateurs ou des entreprises sous contrat peuvent l'échantillonner. De même, chez Google, nous utilisons des versions internes de GMail et Docs avant la sortie. Les sociétés de jeux organisent des bêtas ouvertes pour tester leurs produits et la charge sur les serveurs, etc.
la source
Bien sûr, la réponse est "Ça dépend", mais je vais donner un échantillon de mon plus grand projet à ce jour, qui avait à l'heure de pointe environ 50 développeurs impliqués.
La configuration de base: un logiciel principal pour traiter de grandes quantités de données avec BizTalk.
La première ligne de défense sont les tests unitaires. Dans notre cas, ceux-ci ont été exécutés quotidiennement pour tout ce qui a été vérifié dans le contrôle de code source et généralement certains d'entre eux ont été exécutés manuellement par le développeur avant l'enregistrement. Les tests unitaires ont été principalement écrits par les développeurs mais parfois modifiés par des tests supplémentaires par les testeurs.
L'étape suivante a été une construction hebdomadaire de Virtual PC, où les testeurs ont exécuté une série de tests de bout en bout principalement automatisés sur le flux de données en fonction des documents de spécification de chaque composant.
Après cela, le même Virtual PC a été enrichi de certaines données commerciales assez proches de la réalité et testé à nouveau avec des cas d'utilisation spécifiques.
Ensuite, le Virtual PC a été mis en place avec d'autres composants du système (également principalement virtuels) d'autres services pour un cycle de test d'intégration basé sur des tests de bout en bout de l'utilisateur entrant les données jusqu'à la fin du flux de données.
Sur une autre piste, les paquets d'installation ont été testés par le fournisseur de systèmes pour voir s'ils étaient installés correctement dans un environnement de production et s'ils pouvaient être annulés en cas de défaillance.
Après l'installation sur l'environnement de production, nous y avons effectué des tests de charge et de stress pour tester la stabilité globale (pas quelque chose à prendre à la légère lorsque vous exécutez sur 10 serveurs BizTalk, 8 serveurs SQL et un tas d'autres matériels spécialisés comme un accélérateur XML et une archive dédiée - tous regroupés bien sûr).
Lorsque nous avons été satisfaits de tous les tests, le code a été mis en production. Vous obtenez une latence assez importante pour corriger les bogues dans le code (comme 4-6 semaines pour tout le cycle de test), et cela coûte cher de faire tous ces tests, mais la stabilité globale était assez bonne. En fait, le meilleur que j'ai vu jusqu'à présent. Encore une fois, c'est assez important pour un système qui traite chaque jour plusieurs millions de dollars. Vos besoins peuvent varier, mais c'est ainsi que nous l'avons fait et que cela a fonctionné.
la source
La question d'origine semble plus conceptuellement générique que la plupart des réponses très détaillées qui ont été fournies.
Regardons cela d'un niveau supérieur (moins détaillé). Le logiciel est développé pour répondre aux besoins spécifiques de quelqu'un (personne, entreprise, etc.).
Ces besoins doivent être mis en correspondance avec les histoires / exigences individuelles qui seraient récemment (dans une phase de construction) mises en œuvre dans le code source.
Une bonne définition des histoires / exigences est essentielle pour que l'équipe d'assurance qualité (les vrais testeurs de logiciels) valide le code final, lorsqu'il est exécuté, répond aux exigences de ces histoires et exigences. Donc, dans ce but, l'équipe QA crée des "testcases" pour faire cette validation.
Le code, une fois publié à l'équipe QA, sera ensuite testé et des bugs seront identifiés. Bogues de types et de sévérités différents. Ces bogues sont suivis et les développeurs les assignent pour enfin les corriger.
De nos jours, l'utilisation de machines virtuelles permet à un testeur d'exécuter différents environnements dans un même matériel réel. Mais parfois, vous finissez par avoir besoin d'ordinateurs dédiés à la phase d'assurance qualité.
J'espère que cela vous aide à comprendre (approximativement) le processus global.
la source
Eh bien, je déteste être cynique, mais avec le nombre de bogues ouverts dans un certain système d'exploitation `` appareil '', il semble que plus l'entreprise est grande et riche, plus elle est capable de créer et de livrer à l'utilisateur final des bogues. Si le logiciel fonctionne un peu et a l'air cool, ils le libèrent quand même. Si les gestionnaires pensent que c'est prêt, alors c'est prêt. C'est à ce moment-là que les insectes vraiment désagréables commencent à sortir des boiseries et que les utilisateurs finaux deviennent des cobayes. Une dizaine d'années plus tard, la plupart des bogues auront été résolus (et quelques-uns ajoutés pour faire bonne mesure) et la société sera prête à passer à la prochaine grande idée.
la source