17 ans dans l'industrie, parler de tests

Auteur : Équipe technique de la ligne financière numérique Xiaoxia Ant

Résumé de l'étape de carrière du testeur senior de 17 ans d'Ant Group, de la forme du produit, du modèle de R&D, de la perspective organisationnelle pour examiner le travail de test et la technologie de test, à la perspective individuelle pour examiner la structure des capacités de test et discuter de la croissance personnelle. Le texte long de 10 000 caractères est bourré de bric-à-brac. L'éditeur espère sincèrement que chacun pourra trouver un moment fixe pour le lire attentivement sans être dérangé. Je crois que ces véritables expériences de croissance technique peuvent vous donner une inspiration utile.

écrit devant

Quand j'étais encore à l'école, j'aimais un dessin animé : "About Going to Work" - Zhu Deyong, donc, la première année après avoir obtenu mon diplôme et rejoint l'entreprise, mon patron m'a demandé de faire le premier ppt, et j'étais très heureux d'avoir écrit un gros titre : "About Testing", qui a ensuite été ordonné par le patron d'être changé en "Sharing xx Project Test Experience".

Le temps passe vite, la semaine dernière vient de passer le 6e anniversaire de rejoindre Ant, et 10 jours plus tard, c'est le 17e anniversaire de ma pratique des tests. Je peux enfin utiliser ce sujet pour relier mon expérience de travail, mon expérience et ma réflexion au fil des ans et le partager avec tout le monde.

Si vous travaillez dans l'industrie des tests et de la qualité depuis plusieurs années et que vous avez de telles questions ou confusions :

1. Que dois-je faire si j'ai travaillé sur des projets et que j'ai l'impression qu'il n'y a pas d'accumulation ?

2. Je veux faire quelque chose de nouveau, mais je ne sais pas quoi faire ?

3. À quoi ressemble une planification de développement de carrière de qualité ? Comment passer au niveau supérieur ?

4. Pourquoi l'équipe qualité est-elle divisée et combinée ?

5. Que dois-je faire si ma croissance n'est pas évidente cette année ? Vous souhaitez changer d'équipe, ou changer de poste ?

J'espère que ces partages pourront vous donner des perspectives ou des idées, et voir le problème plus clairement à travers la surface.

    

Cet article est divisé en six parties. Les trois premières parties examinent le travail de test et la technologie de test à partir de la forme du produit et du modèle de R&D. Les quatre et cinq parties suivantes examinent le travail de test et l'organisation des tests du point de vue de l'organisation. La sixième partie examine la structure des capacités de test du point de vue individuel.Discutez brièvement de la croissance personnelle.

        

1. La forme du produit détermine le travail de test

Ne regardez pas la version trop longtemps : différentes formes de produits conduisent à différentes priorités de test, et les méthodes et outils de test ont également évolué et se sont développés en conséquence. La méthodologie traditionnelle de test des produits d'ingénierie a été relativement parfaite, et pour les nouvelles entreprises, un système de test de base complet et efficace peut être rapidement établi en se référant aux méthodes et outils existants.Le travail de test se concentre généralement sur la technologie de test spéciale pour les caractéristiques de l'entreprise . En plus des produits d'ingénierie, les tests de services intelligents tels que les modèles d'algorithmes de données sont devenus un point chaud dans l'industrie des tests ces dernières années et ont une énorme marge de développement.

"Le soi-disant test consiste à vérifier si le produit répond aux exigences de l'objectif et à trouver les bogues du produit en exécutant le produit."

Au fil des ans, l'objet du test, le produit, a évolué. Analysons d'abord les similitudes et les différences du contenu du travail de test en fonction de certaines formes de produits qui ont émergé au cours du processus d'évolution du produit.

1. Logiciel autonome

Les premiers livres de test de logiciels ont commencé à partir du test de logiciels autonomes, et les plus typiques sont les produits de la série Office de Microsoft. En raison des caractéristiques de l'installation de logiciels autonomes et de la très faible fréquence des mises à jour logicielles à ce moment-là, en plus des tests de fonctionnement et de performances conventionnels, le travail de test doit également se concentrer sur les tests de package d'installation, les tests de compatibilité du système et des tests très importants. les commentaires des utilisateurs La reproduction du bogue. Concevez des cas de test selon prd, simulez les opérations de l'utilisateur et vérifiez les fonctions grâce à l'interaction de l'interface. C'est aussi la raison pour laquelle le test s'appelle un peu.

2. Webservices

Le produit que j'ai commencé à tester en 2005 était la recherche, un service Web typique.

Les tests de service Web peuvent être divisés en tests front-end et back-end. Les tests de page front-end peuvent toujours simuler les opérations de l'utilisateur pour l'exécution de cas d'utilisation. Les tests back-end n'ont pas d'interface utilisateur, il est donc nécessaire de développer des outils de test. pour aider à l'initiation des cas d'utilisation et à la requête des résultats. À cette époque, le concept de test d'interface a commencé à émerger, mettant l'accent sur la testabilité des applications back-end.

Dans le même temps, par rapport aux fonctions claires d'un logiciel autonome, la réalisation de la stratégie de recherche du produit de recherche est plus importante.La conception de cas d'utilisation ne peut pas se limiter à prd, mais la réalisation de la logique interne du système doit être considérée de manière globale, telle que la sélection de la requête de recherche (données de test) et la capture et le tri. La vérification de la stratégie et la conception du cas de test doivent être basées sur l'apport complet du prd et du département.

D'autres services Web plus fonctionnels, tels que les forums, les sites de téléchargement et la navigation sur le portail, peuvent être relativement facilement testés pour la plupart des cas d'utilisation via la page d'accueil, ainsi que des tests de compatibilité pour les navigateurs grand public. L'enregistrement et la lecture de la page d'accueil ont commencé à se développer.

Le test de performances commence à différencier les frontends et les backends. Le backend met l'accent sur la vitesse de traitement des applications et les indicateurs d'occupation du matériel, et le frontend met l'accent sur la vitesse de réponse des pages.

3. Logiciel client

Produits typiques : version PC du logiciel social, version PC du logiciel de téléchargement de musique, version PC de la méthode de saisie. Le client est installé et déployé sur l'ordinateur de l'utilisateur, ce qui est quelque peu similaire à un logiciel autonome. Cette partie du test doit prendre en compte les différences d'environnement utilisateur et améliorer autant que possible la couverture de la simulation. Comme ci-dessus, en raison à la connectivité entre le client et le serveur, les journaux du client peuvent être redistribués automatiquement pour faciliter la surveillance et le positionnement sont beaucoup plus pratiques que la reproduction des bogues à l'ère autonome.

Le serveur utilise toujours les tests d'interface comme méthode principale et l'automatisation de l'interface s'est progressivement développée.

Les tests de performance continuent d'être affinés et des évaluations d'indices multidimensionnels sont nécessaires pour chaque fonction utilisateur.

4. Applications mobiles

L'essor des applications mobiles a eu lieu vers le début de 2010 et son essence est similaire à celle des logiciels clients.Cependant, comme l'environnement de test est passé du PC au téléphone mobile, des outils de test automatisés basés sur l'enregistrement et la lecture des opérations d'interface ont inauguré une vague de rafraîchissements à ce moment-là. Les fonctionnalités de publication et de mise à jour des canaux des applications mobiles ont entraîné le développement technique de la version en niveaux de gris et de la mise à jour en niveaux de gris. D'une part, le journal de comportement des utilisateurs aide à la découverte et au positionnement des problèmes, et d'autre part, il sert également de référence pour l'itération du produit. Le retour du journal doit tenir compte de l'utilisation du trafic du téléphone mobile de l'utilisateur. La méthode standard consiste à attendre que l'utilisateur se connecte au Wi-Fi avant de revenir.

La compatibilité doit prendre en compte les 20 à 100 meilleurs modèles.

A l'ère de l'Internet mobile, les tests de performance sont devenus très importants, évidemment les utilisateurs ne sont pas aussi patients sur mobile que sur PC. Et faites attention aux indicateurs spécifiques des scénarios de téléphonie mobile tels que la puissance, le trafic, la génération de chaleur et la faiblesse du réseau.

5. Matériel

Vers 2014, le matériel intelligent a fait son apparition, et par hasard, je me suis également lancé dans un petit test de matériel : les boîtiers TV. L'essence est similaire à l'application, avec la différence entre le micrologiciel et le logiciel. Dans le même temps, il est nécessaire de prendre en compte la qualité de la livraison du matériel et de coopérer avec les fabricants pour garantir la qualité des lots.

6. Webservices mobiles

La compatibilité est passée de la couverture de la version du navigateur du PC à la couverture combinée du navigateur mobile et du modèle de téléphone mobile.Avec la montée en puissance de H5, la page n'est plus limitée à l'affichage dans le navigateur.

Le test de performance autour de la page est plus affiné, par exemple, les indicateurs d'ouverture de page incluent : affichage du premier caractère, affichage du cadre de la page, affichage du premier écran, affichage de tout, etc., le tout pour une expérience rapide de l'utilisateur.

7. Commerce international

Remarque : Cette classification n'est pas orthogonale à la classification ci-dessus. Toutes les formes de produits ci-dessus peuvent être des activités internationales. Si vous ne vendez des produits que pour un pays spécifique, créez un environnement localisé, une simulation de réseau localisée, une vérification logique de fuseau horaire, une localisation. La vérification de la rédaction, la conformité réglementaire de la localisation et d'autres aspects doivent être ciblés.

Si l'entreprise internationalisée est orientée vers plusieurs pays et plusieurs langues, c'est-à-dire qu'un produit doit prendre en charge au moins deux ensembles de langues en même temps, et peut s'étendre pour prendre en charge plus de langues à tout moment. Dans la conception et le développement de produits, il est nécessaire de se concentrer sur la conception d'architecture fonctionnelle indépendante de la langue et liée à la langue, et dans le processus de test, il est nécessaire de prendre en charge l'internationalisation, la localisation, les tests simultanés rapides multi-versions et multilingues. Développer et modifier une ligne de code, tester et vérifier 10 versions linguistiques deviendra un cauchemar pour l'efficacité des tests. Le contraire d'un cauchemar est une opportunité. Il y a beaucoup de place pour améliorer l'efficacité du point de vue de la conception de l'architecture, de l'automatisation des cas et de la séparation logique des cas.

8. Architecture distribuée de microservices

L'essentiel est que les tests côté serveur, les tests d'interface, le débogage conjoint intégré et les tests système soient toujours applicables, mais en raison des caractéristiques de l'architecture distribuée et de l'augmentation du nombre d'applications/interfaces de microservices impliquées dans des fonctions mono-utilisateur, certains des problèmes et des solutions ont été apportés : General Mock améliore l'efficacité du développement de simulations, la stabilité de l'environnement de test doit être gérée en permanence, les cas d'utilisation exceptionnels des appels d'interface/asynchrones sont couverts, le test de performance du lien complet est effectué en ligne, et la flambée des coûts d'automatisation des interfaces a entraîné le développement de l'enregistrement et de la lecture des tests d'interface.

9. Produits/services infonuagiques

Accès complet au cloud ! ! ! La migration vers le cloud de l'objet testé entraîne la migration vers le cloud du processus de test, ainsi que la migration vers le cloud des outils de test et des plateformes de test.

Si un produit cloud est déployé sur un seul cloud, la différence avec les tests traditionnels réside principalement dans les travaux liés à l'environnement (environnement de test, environnement de débogage commun, environnement de test de performance, plateforme d'outils de test sur le cloud, etc.), si un produit cloud est déployé sur un cloud multi-version Ensuite, les tests d'intégration cloud, l'adaptation multi-cloud, la gestion des versions client, la vérification de la solution de déploiement, la reprise après sinistre et multi-actif, la gestion des versions, le positionnement de la récurrence des problèmes, etc. doivent être pris en compte.

La forme du produit de l'activité cloud n'a pas beaucoup changé, et le modèle commercial sous-jacent, tel que le saas et le toB, aura un impact plus important sur le test.

10. Big data/modèle algorithmique/entreprise intelligente

Fin 2012, il y avait un livre classique "L'ère du Big Data", qui soulignait clairement que le plus grand changement à l'ère du Big Data est d'affaiblir la causalité et d'accorder plus d'attention à la corrélation. Les changements apportés par le produit sont les suivants : premièrement, il doit y avoir beaucoup de données, et deuxièmement, basées sur le big data, des méthodes intelligentes telles que l'apprentissage automatique sont utilisées pour trouver la corrélation entre les données et les résultats (logique) pour fournir des services en externe. . Les produits auxquels j'ai été exposé incluent : la recherche intelligente, la recommandation personnalisée, la reconnaissance vocale et d'image, le dialogue intelligent, etc.

Ce type de forme de produit a eu un impact très important sur le test : parce que la logique interne de l'objet testé n'est plus clairement visible, le cas de test a complètement échoué à suivre l'idée de réaliser une couverture logique. De même, même s'il est changé en couverture de données, il est difficile de diviser les données en classes d'équivalence, et le taux de couverture de code perd son rôle dans la mesure de la combinaison de nœuds du réseau de neurones. La seule façon de le combattre est de le tester avec le big data. Par exemple, divisez les données en deux parties, l'une comme ensemble de formation/validation et l'autre comme ensemble de test, mais dans le processus de développement réel, le processus de test est très similaire au processus de formation et de vérification, et il n'est pas nécessaire pour remettre le processus de test à l'équipe de test pour exécution, en outre, en raison de la grande tolérance de la qualité du client, de nombreuses entreprises intelligentes peuvent directement effectuer une vérification/évaluation/itération de seau en ligne, et l'ensemble du processus de R&D peut facilement ignorer l'équipe de test . (Donc certaines entreprises intelligentes n'ont vraiment pas d'équipe de test...)

Bien sûr, les tests peuvent encore faire beaucoup de choses.

1) Séparez la partie données pour l'assurance qualité des données.

Il y a du big data derrière l'entreprise intelligente, et il y a aussi des services de données pures : comme les données massives comme les cartes, comme les documents livrés aux organisations sous forme de données, les données de sortie de ces services de données pures, les données d'entrée de services intelligents, et les données de sortie peuvent être utilisées comme objets de test de type données sont utilisés pour une assurance qualité complète. Par rapport aux tests de processus en cours d'exécution centrés sur les cas d'utilisation et orientés objet côté serveur, client et application, le champ de données est plus enclin à tester les résultats (données). Je conclus que les raisons sont les suivantes : premièrement, certaines données sont des données collectées/achetées, et le processus de traitement n'entre pas dans le cadre du test. Deuxièmement, même si le processus de traitement des données entre dans le cadre du test, il est trop coûteux d'utiliser la conception de cas pour la logique de traitement des données et la couverture précise de la structure des données, il est donc préférable de tester directement les données de résultat. 3. Les résultats de sortie des services de données sont naturellement différents à chaque fois. Par rapport aux services d'application qui peuvent s'exécuter pendant une longue période après un test avant la publication, les services de données doivent tester la couverture/l'assurance qualité pour chaque lot de résultats de données en cours d'exécution. (un test ne suffit pas).

La méthodologie et les services d'outils de qualité des données ont prospéré dans le système Ali ces dernières années, y compris, mais sans s'y limiter : la vérification des règles de données, l'inspection des données, la surveillance des données, l'attaque et la défense des données, la garantie de stabilité des liaisons de données, etc. Sur la base des caractéristiques du big data, une vague de solutions de test intelligentes est également née, telles que la dérivation automatique de la vérification, l'attaque et la défense automatiques, etc.

2) L'évaluation des effets commerciaux des entreprises intelligentes est un vaste domaine. Différents formulaires commerciaux intelligents ont des angles d'évaluation et d'analyse différents. Il s'agit d'un test de la capacité des testeurs à comprendre l'entreprise, les données et la mise en œuvre d'algorithmes. Définissez d'abord les dimensions, les indicateurs et le calibre de l'évaluation, puis délimitez la plage de données d'évaluation pour l'évaluation et l'analyse, et effectuez une analyse d'attribution plus poussée pour les indicateurs qui ne répondent pas aux attentes.Enfin, l'ensemble du processus est précipité dans une plate-forme d'outils, qui peut également être directement intégré dans le processus de R&D.

3) Combiner des fonctionnalités intelligentes de recherche et de développement d'entreprise pour améliorer l'efficacité, telles que la plate-forme d'étiquetage/gestion/évaluation des ensembles de données, l'outil d'analyse d'attribution de mauvais cas, la capacité de point bloqué du processus de publication, etc. Cette partie du travail jouera un rôle important dans les premières étapes du développement d'une entreprise intelligente.

4) La chose la plus difficile est le test du modèle d'algorithme lui-même. Sous les contraintes de performance des coûts, aucune méthodologie mature et complète n'a été vue. Une approche plus réaliste consiste à résoudre les problèmes locaux en fonction des caractéristiques de l'entreprise et à équilibrer les entrées et les sorties. Mon équipe essaie des tests de métamorphose, une analyse d'attribution de cas erronés, etc.

L'entreprise intelligente s'est développée depuis plus de dix ans et se développe actuellement à grande vitesse, couvrant de plus en plus d'industries, d'entreprises et de produits. Dans l'avenir le plus optimiste, presque toutes les entreprises évolueront vers des entreprises intelligentes (tout comme presque toutes les industries peuvent l'appeler Internet+). Par conséquent, il y aura une vague de mises à niveau technologiques et d'innovations dans l'assurance qualité des services intelligents, qui stimuleront le développement de l'industrie des tests. Mon équipe travaille également dur pour explorer cette direction. Les personnes intéressées sont invitées à envoyer un e-mail et à appeler pour discuter sur DingTalk.

Ce qui précède répertorie certains formulaires de produit et travaux de test avec lesquels j'ai été en contact. On peut voir que le formulaire de produit détermine le contenu du travail de test, puis détermine la technologie de test. La maturité de l'industrie du formulaire de produit détermine également la maturité de la technologie/des outils de test de l'industrie. Lors du lancement d'un nouveau test d'entreprise, il est nécessaire d'utiliser les outils de test matures de l'industrie/de l'entreprise pour réduire les coûts d'organisation et utiliser une main-d'œuvre de test précieuse pour les tests spécifiques aux caractéristiques de l'entreprise. Les entreprises avec des formes de produits plus matures doivent établir rapidement un système de test initial efficace, tandis que celles qui ont de nouvelles formes de produits doivent renforcer la pré-recherche sur la technologie de test pour tirer pleinement parti de l'espace de développement potentiel.

2. Exigences du mode R&D pour les travaux de test

C'est trop long pour lire la version : le modèle de R&D met en avant des exigences plus spécifiques pour le travail de test. Plus le modèle de R&D est agile, plus les exigences pour l'accumulation technique du travail de test sont élevées. Au final, le travail de test doit être connectés en série grâce à l'automatisation et à l'intégration continue.

En plus de la forme du produit, une autre influence décisive sur le travail de test est le mode R&D.

En 2009-2011, il y a eu une nette vague de développement agile dans le modèle R&D : de la grande version du développement en cascade à l'intégration continue/développement agile, mais à mesure que la manie agile s'estompait progressivement, de nombreuses équipes sont revenues à la rationalité et n'ont pas poursuivi l'extrême l'agilité (n releases quotidiennes) comme objectif, mais un équilibre itératif guidé par les demandes de l'entreprise (release hebdomadaire/bihebdomadaire + release mensuelle de projets à grande échelle).

Ici, nous ne commentons pas la bonne ou la mauvaise applicabilité du modèle de R&D, mais analysons uniquement l'impact du modèle de R&D sur les tests.

Permettez-moi d'abord de définir la différence entre ce que j'entends par cascade et développement agile :

En mode Great Waterfall, le processus de R&D et le processus de test sont indépendants, et le test global est effectué une fois toutes les exigences satisfaites. Le processus de test comprend l'examen complet des exigences, l'examen du système, l'examen des résultats des tests, le test d'interface, le test d'intégration, le test du système, la vérification préalable à la publication et d'autres liens, et la version globale sera publiée une fois tous les processus de test terminés.

Dans le développement agile (en prenant la version hebdomadaire comme exemple), toutes les exigences sont divisées en n histoires (histoires d'utilisateurs), et le développement est mis en œuvre en fonction des histoires. Une fois chaque histoire terminée, elle sera testée. Une fois le test de l'histoire terminé, l'histoire peut être publiée directement. Lors du test de l'histoire actuelle, le développement développe déjà l'histoire suivante, formant ainsi un pipeline échelonné, et le cycle de la proposition d'exigence à la publication et au lancement de chaque histoire peut être raccourci au niveau hebdomadaire. Étant donné que le processus de développement et le processus de test sont échelonnés et parallèles, le cycle de publication et de lancement de toutes les exigences = le temps de développer toutes les histoires + le temps de tester une histoire.

En utilisant l'analogie de la fabrication d'un gâteau à trois couches, la grande cascade consiste à fabriquer le gâteau entier (grande version) couche par couche et à le soumettre au test pour le tester. Par conséquent, il existe un test évident comme limite dans le développement et processus de test. Le développement agile est divisé en plusieurs petits gâteaux (story), l'un est testé une fois l'autre terminé et l'autre est publié après le test. Lorsque le test teste le petit gâteau actuel, le développement développe déjà le petit gâteau suivant, formant un mécanisme de pipeline échelonné. Lorsque tous les petits gâteaux sont finalement développés, le test n'a besoin que de tester le dernier petit gâteau pour terminer la libération de tous les gâteaux.

Cela semble être une excellente idée pour être agile, non ?

En fait, en termes d'histoire et d'architecture, la mise en œuvre agile est très difficile. Les exigences peuvent-elles être divisées en histoires indépendantes, et chaque histoire a à peu près la même taille (afin d'assurer le développement et les tests échelonnés) ? En termes d'architecture, les gâteaux à trois couches peuvent-ils être réalisés un par un, et le découplage de chaque gâteau à trois couches peut-il être réalisé ? Comment éviter l'effet de la modification du bottom cake sur tous les top cakes ?

En supposant que les problèmes ci-dessus peuvent être résolus, le plus grand impact sur les tests réside dans la façon d'assurer la contrôlabilité de chaque cycle de test de story. Le processus de test comprend de nouvelles fonctionnalités, des régressions, des performances, etc. Pour les produits matures, l'ensemble des cas d'utilisation de régression peut être très large. Les bugs trouvés lors des tests ont également un impact indéterminé. Alors la réponse est prête à sortir : l'automatisation de l'ensemble du processus de test est la meilleure garantie pour le cycle. Grâce à l'automatisation, le cycle passe du temps incertain des humains au temps de fonctionnement prévisible et accéléré de la machine. Plus le cycle est complet. plus l'automatisation couvre le processus, plus la certitude du cycle est élevée. Le coût du développement/maintenance automatisé lui-même doit être caché dans le temps d'exécution de ces automatisations, de préférence dans le temps de préparation avant que chaque histoire ne soit testée.

Cela dit, la conclusion est en fait très simple : plus la version est agile, plus le test est rapide, plus le degré d'automatisation est élevé et plus la capacité d'automatisation de l'équipe est élevée.

C'est peut-être la raison pour laquelle les testeurs Internet sont plus techniques que les testeurs de logiciels traditionnels. Les essais et erreurs rapides d'Internet, les petites étapes et les idées d'itération utilisateur nécessitent l'efficacité des versions Internet et favorisent le développement de la technologie de test. Pour les éditeurs de logiciels traditionnels, y compris certaines institutions financières traditionnelles, les testeurs peuvent également utiliser une petite quantité d'automatisation + petit à petit pour effectuer la livraison des tests dans un cycle de version de plusieurs mois.

J'ai été en contact avec des équipes extrêmement agiles (plusieurs releases par jour), et la technologie des tests automatisés s'est développée à l'extrême : la couverture des cas d'utilisation automatisés est extrêmement élevée (> 90 %), et l'automatisation est ultra-rapide ( Cela favorise les pratiques techniques telles que les cas d'utilisation automatisés, la gestion du code et de la configuration à partir de la même source, la construction en un clic de l'environnement, les points de carte de mesure de couverture et le pipeline CI (intégration continue).

Pour revenir à la réalité, le développement d'une entreprise ne nécessite pas nécessairement une agilité aussi extrême, l'agilité ultime étant d'utiliser des investissements hors cycle en échange d'une vitesse en cycle, ce qui entraînera une augmentation de divers coûts techniques (ressources machines, capacités d'architecture , et les capacités du personnel), et le rythme itératif Il tombe généralement au niveau hebdomadaire pour atteindre un état plus équilibré. En conséquence, les testeurs utiliseront le rapport coût-bénéfice de l'automatisation comme principe de sélection pour l'étendue de l'automatisation. Le bénéfice dépend du temps économisé après l'automatisation et est favorisé par le nombre de fois que l'automatisation est répétée. Le coût provient du coût de écriture d'automatisation et lorsque le programme sous test change. mise à jour maintenance. Par exemple, les tests de performance, les tests d'interface et les tests unitaires ont été sélectionnés en raison du nombre d'exécutions répétées ; l'enregistrement et la lecture ont été sélectionnés en raison du faible coût de l'écriture automatisée ; l'analyse de code peut diluer les coûts en raison d'un large éventail de domaines d'activité applicables ; les interfaces qui changent fréquemment ne conviennent pas à l'automatisation de l'interface utilisateur, etc.

3. Évolution de la technologie de test

Ne regardez pas la version trop longtemps : la technologie des tests continue d'évoluer dans deux directions : la qualité et l'efficacité, offrant au personnel de qualité un large espace de développement technologique.

Les exigences posées par l'entreprise (forme du produit et modèle de R&D) pour le travail de test doivent être répondues par la technologie de test.

Il existe deux types d'exigences commerciales pour le travail de test, l'une est la qualité et l'autre la performance (y compris l'efficacité et le coût).Par conséquent, la technologie de test est également divisée en deux directions :

1. Comment garantir la qualité du test : test complet, test correct

Nous ne répéterons pas la division de classe d'équivalence méthodologique la plus élémentaire, l'analyse des valeurs limites, etc.. Dans la pratique commerciale, la couverture de classe d'équivalence d'opération utilisateur et la couverture de code sont deux mesures importantes. Les différentes méthodes de mesure qui en découlent visent toutes à assurer une couverture à 100 % dans ces deux directions.

Les deux sources importantes de conception de cas d'utilisation sont prd et les points de service. prd représente le comportement d'utilisation de l'utilisateur et les points de service représentent la logique de mise en œuvre du système. Après plus de 20 ans de développement de services Internet, les fonctions utilisateur sont devenues de plus en plus puissantes et la logique de mise en œuvre derrière les fonctions est devenu plus complexe, il peut y avoir des milliers de classes équivalentes derrière une même opération (pensez à la stratégie préférentielle pour passer des commandes sur Double Eleven).

Afin de couvrir cet objectif ultime à 100 %, les testeurs doivent avoir une compréhension approfondie de l'objet testé, désassembler les classes d'équivalence à partir de plusieurs dimensions telles que la fonction, le code, la logique normale, la gestion des exceptions, etc., et enfin concevoir des cas d'utilisation exécutables. pour couvrir chacun une classe d'équivalence.

Le développement de la technologie de test repose également sur ceci :

Compréhension de l'objet mesuré : analyse prd, analyse des liens système, analyse de l'impact du changement, etc.

Désassemblage et couverture des classes d'équivalence : mesure de la couverture du code, test fuzz, clustering des scénarios de trafic, analyse des règles de code, génération de cas d'utilisation, etc.

Identification et jugement des relations de vérification des cas d'utilisation : lignage des données de code, dérivation automatique de la vérification, jugement des résultats de test, etc.

2. Comment mesurer rapidement et à moindre coût

Sur la base de tests complets, l'amélioration de l'efficacité et la réduction des coûts sont les exigences éternelles.

Voici un chemin d'évolution technologique très clair :

Tests manuels -> instrumentation de test -> tests automatisés -> plateforme / service de test -> tests intelligents

1) Outils d'essai

Le travail de test est naturellement répétitif : le travail répété entre les versions est une régression, la répétition entre différents cas fonctionnels est l'initialisation de l'environnement et des données ; le travail répété entre différents cas d'équivalence de la même fonction est l'exécution du cas d'utilisation et la vérification des résultats. Le même cas sera également exécuté à plusieurs reprises dans plusieurs versions de test au sein de la version, ainsi qu'entre l'auto-test de développement et le travail de test. La répétition la plus extrême est le test de compatibilité, et tous les liens sont répétés.

Si les tests manuels sont désassemblés en : construction de l'environnement, préparation des données, exécution des cas d'utilisation, lecture des résultats, vérification des résultats et rédaction du rapport, chaque lien peut être résolu par des outils pour améliorer l'efficacité de l'exécution manuelle.

2) Automatisation

Si chaque lien est instrumentalisé, tous les liens sont ensuite connectés en série via des outils et des scripts, et l'exécution en un clic d'un seul cas d'utilisation est réalisée, et l'automatisation d'un seul cas d'utilisation est réalisée. Après avoir résolu l'interférence/dépendance d'exécution entre les cas d'utilisation et réalisé l'exécution par lots de tous les cas d'utilisation, il peut être lié à la soumission de code pour réaliser une intégration continue.

3) Plateforme/service de test

Plus le degré d'automatisation des cas d'utilisation est élevé, plus le coût de l'automatisation des cas d'utilisation est élevé, plus la couverture des cas d'utilisation est élevée et plus la répétition entre les cas d'utilisation est élevée. Lorsque l'entreprise et l'équipe se développent ensemble dans une certaine mesure, les capacités générales de test peuvent être davantage abstraites, et les capacités de test qui peuvent être réutilisées entre les équipes et les entreprises peuvent être fournies à une gamme plus large dans un service basé sur une plate-forme plus flexible. mode, supportant des équipes techniques avec des centaines à des milliers de personnes (dev + test). Tels que le cadre de test automatisé, la maquette générale, les règles générales d'analyse, la vérification générale, l'analyse de code, la plate-forme de test de performance, etc.

4) Essai intelligent

Différent du test commercial intelligent mentionné ci-dessus, le test intelligent fait référence à l'utilisation d'une technologie intelligente pour les tests. En 2019, j'ai eu l'honneur de diriger le groupe de tests intelligents du groupe de qualité des entités économiques, de mener des recherches sur les tests intelligents et d'essayer de régler la définition des niveaux de normes de tests intelligents. Notre équipe a divisé les activités de test en trois grands domaines et 8 sous-domaines, et a désassemblé l'espace intelligent de chaque sous-domaine et correspondu avec quelques cas pratiques.

La formulation de la norme est de guider l'orientation du développement de la technologie. La norme incarne potentiellement les difficultés dans le domaine des tests intelligents : à travers le modèle d'algorithme/apprentissage automatique pour résoudre les liens qui dépendent fortement des personnes dans le processus de test, tels que que la couverture de la planification des scénarios et le jugement des résultats, de sorte que personne ne soit impliqué dans l'intervention.

L'intervention sans pilote dans le test équivaut à : efficacité du test = efficacité d'exécution de la machine, et l'occupation du cycle des personnes dans le test -> 0. Certaines explorations qui peuvent être vues jusqu'à présent incluent : la génération automatique de cas d'utilisation, la vérification automatique des cas d'utilisation (vérification automatique de l'interface utilisateur via la reconnaissance d'image, via la dérivation de la relation de données pour la vérification automatique des données, etc.), localisation automatique des échecs de cas d'utilisation, réparation automatique des cas d'utilisation, etc.

Les tests intelligents sont expérimentés dans l'industrie depuis plusieurs années, mais je n'ai pas vu de cas pratiques qui remplacent complètement les êtres humains. Je reste optimiste quant à cette direction : avec la standardisation continue du processus de test, l'accumulation d'actifs de données de test, et le développement de la technologie du modèle d'algorithme, l'amélioration de la capacité du modèle d'algorithme des testeurs et les tests intelligents apporteront certainement de plus en plus de contributions.

4. Évolution des responsabilités qualité

Ne lisez pas la version trop longtemps : avec les exigences de l'industrie et le développement de la technologie, l'extension du concept de test s'étend progressivement, et l'étendue des responsabilités assumées par le personnel de qualité s'étend également progressivement. L'équipe qualité d'Ali Ant a progressivement assumé la plus grande responsabilité du risque technique, ce qui a ouvert un nouvel espace pour le développement de carrière du personnel de qualité.

Après avoir parlé du travail de test, nous devons également parler du processus d'évolution du rôle du test.

Comme pour la technologie de test, il existe également une voie d'évolution évidente pour les responsabilités de test dans l'industrie, et le même processus de développement peut être observé dans le processus de développement de chaque entreprise lors de la comparaison avec les meilleures entreprises de l'industrie Internet.

Test -> Qualité -> Qualité + Efficacité -> Efficacité Qualité + Risque Technique

1. Tests vs Qualité

Dans l'article précédent, les deux responsabilités de test et de qualité sont fondamentalement synonymes, mais au stade précoce du développement de l'industrie, du test à la qualité représente une différence majeure entre les deux responsabilités de fournir le processus de test et de fournir des résultats de qualité. Tant qu'elle s'appelle une équipe qualité, elle peut dépasser les limites du travail de test et faire de l'assurance qualité sous différents angles, tels que la gestion des processus de R&D, la sqa (assurance qualité logicielle), ces contenus de travail peuvent appartenir à l'équipe qualité. En combinaison avec les besoins de l'entreprise, l'équipe qualité peut également entreprendre des travaux tels que l'évaluation de la qualité de l'entreprise et la comparaison de la concurrence commerciale.

2. Efficacité

Lorsque la qualité de service atteindra un état stable, les exigences de performance seront certainement relevées. La performance peut être divisée en deux périmètres : la performance qualité et la performance R&D.

En raison de la nature répétitive, la performance de masse est généralement proposée en premier. La méthode courante consiste à s'appuyer sur le processus devops pour améliorer l'efficacité de la plate-forme d'outils et à accumuler la capacité pour chaque lien avec un coût élevé et une répétition élevée. Cette partie du travail a été effectuée dans le lien plus rapide de la façon de tester la technologie de test, et aucune analyse répétée ne sera effectuée.

La portée de l'efficacité de la R&D est plus large. Grâce à l'identification répétitive de l'ensemble du travail de R&D, nous pouvons trouver une marge d'amélioration de l'efficacité et accumuler des capacités. Par exemple, si des activités marketing similaires nécessitent plusieurs développements, nous pouvons accumuler des capacités de configuration marketing low-code + capacités d'acceptation pré-exécution en libre-service pour les opérations.Des institutions et des commerçants similaires ont des accès multiples, qui peuvent accumuler un accès en libre-service institutionnel + des capacités de débogage conjointes en libre-service, etc. Le travail relevant du côté R&D est généralement entrepris par le rôle R&D, et le travail relevant du côté qualité peut être entrepris par le rôle qualité.

3. Risque technique

C'est le domaine que j'ai le plus appris depuis que j'ai rejoint Ant, et c'est aussi une nouvelle tendance dans l'industrie ces dernières années.

Laissez-moi vous raconter une expérience personnelle il y a environ 9 ans :

À cette époque, j'étais le chef de l'équipe qualité, et mon champ d'activité comprenait un site Web avec un pv de dizaines de millions. Un jour, mon patron (le chef de l'équipe qualité) a appelé et a dit : "Le site Web est Ils ont dit qu'il ne pouvait pas être ouvert en ligne, alors j'ai essayé. Il y a aussi un écran blanc sur la page d'accueil. été publié ces derniers jours. On dit que le serveur est en panne." Mon patron a dit : "Et alors ?" J'ai dit : "Non, ce n'est pas un test manqué, cela n'a rien à voir avec notre équipe, et l'exploitation et la maintenance s'en occupent." Ensuite, mon patron a mis du temps à me faire comprendre, comment le site Web raccroché n'avait rien à voir avec la qualité, l'équipe qualité ne devrait pas ignorer que le site Web est en panne, Le l'équipe qualité devrait faire quelque chose pour améliorer la qualité du produit.Après tout, nous nous appelons l'équipe qualité, etc... Plus tard, nous avons fait une surveillance commerciale fine, des alarmes hiérarchiques, le positionnement automatique des règles d'alarme à haute fréquence et d'autres règles en ligne projets spéciaux de qualité. En comparant les mots Ant actuels, c'est presque le risque technique, la haute disponibilité, la stabilité, la gouvernance de haute sécurité, la réponse rapide d'urgence et d'autres travaux.

Pourquoi ai-je parlé de cette expérience ? Cet incident m'a beaucoup touché : nous sommes une équipe de qualité, et nous testons chaque ligne de code publiée en ligne, mais il y aura des problèmes de qualité qui affecteront sérieusement les utilisateurs en ligne, alors que doit faire l'équipe de qualité ? ? (Définir les responsabilités, assumer les responsabilités), être responsable de cette partie de la qualité ? A cette époque, nous l'avons définie comme qualité en ligne, c'est-à-dire qu'elle soit causée par des bogues de programme ou de conception, les problèmes qui affecteront la qualité en ligne sont de la responsabilité.Pour cette raison, nous devons trouver des problèmes, les localiser rapidement Récupérez ces perspectives pour former une méthodologie et collaborez avec d'autres rôles pour établir un processus commun. Pour moi, cette responsabilité s'appelait qualité en ligne dans l'ancienne société, et risque technique chez Ant.

(Note 1 : Il y a ici un conflit de logique conceptuelle : qualité en ligne = risque technique, donc la qualité (hors ligne + en ligne) inclut le risque technique. Mais en même temps, fortement influencé par l'expérience personnelle ci-dessus, dans mon esprit, le risque technique = va make Pour tous les problèmes qui tournent mal en ligne, le risque technique recouvre le concept traditionnel de qualité à l'envers, car la qualité des programmes est aussi une source de problèmes en ligne.)

(Remarque 2 : étant donné que les responsabilités des risques techniques sont destinées à être partagées par plusieurs équipes et rôles, et qu'il existe des différences dans la définition des rôles et des responsabilités des équipes dans les principales organisations techniques, dans différents contextes, les risques techniques font référence à des choses et des problèmes , il existe également de légères différences lorsque vous travaillez avec des équipes.)

Le travail technique du risque peut être divisé en identification du risque, prévention, découverte, hémostase, positionnement, récupération, exercice de planification, attaque et défense rouges et bleues, etc. selon le stade. Par rapport aux tests unitaires, aux tests d'interface, aux tests d'intégration, aux tests système et aux tests utilisateur dans la phase de test, ces divisions de phase ne représentent que des dépendances d'avant en arrière, et non une sérialisation absolue. Je pense que les étudiants qui ont lu cet article ont une bonne compréhension des risques techniques. Je ne m'étendrai pas trop sur la méthodologie spécifique ici, mais je me contenterai d'énumérer quelques points clés sur lesquels je souhaite insister :

1) L'identification des risques doit être analysée sous deux angles : la manifestation finale du problème et la source du problème.

Puisque risque technique = problèmes en ligne, la performance des problèmes en ligne est naturellement la perspective la plus importante. Ant a défini six domaines de risque technique en 16 ans : haute disponibilité, sécurité du capital, qualité des données, capacité de performance, coût et sécurité. Les quatre premiers types de risques impliquant plus de rôles de qualité sont définis à partir de la performance du problème. Bien que ces concepts ne soient pas complètement orthogonaux (par exemple, les problèmes de performances et de capacité se manifesteront par des problèmes de haute disponibilité, et la qualité des données entraînera également des performances de sécurité financière), il est relativement facile à utiliser pour distinguer les principaux types de risques techniques dans le travail. .

b. Il existe diverses sources d'introduction de problèmes. Il existe un dicton classique : "Pas de changement, pas de mal." L'ensemble du lien qui fournit des services comprend des passerelles, des applications, des configurations, des intergiciels, des nuages, du matériel de salle informatique, des réseaux, etc. Modifications peuvent être introduits et causer des problèmes en ligne. (Il peut y avoir des changements dans le câble optique s'il n'y a pas de changement à la maison -_-).

c. Dans le processus d'identification des risques, il doit y avoir deux manières de penser, positive et négative, pour assurer l'intégrité de l'identification des risques : déduire les raisons des problèmes éventuels (la panne du service peut être due à des bogues, des machines, des salles informatiques, des réseaux ), et d'éventuels problèmes. Les modifications entraîneront des problèmes (une mauvaise configuration peut entraîner un blocage du service, un montant erroné, des réclamations de clients de rédaction).

2) Créer des capacités de prévention pour la source des problèmes et créer des capacités de découverte pour les manifestations des problèmes.

3) Les deux lignes d'hémostase et de restauration de positionnement doivent être découplées et parallélisées.

Dans le concept de test, corriger le bug après positionnement = résoudre le problème, mais dans le risque technique, l'hémostase et la récupération du positionnement sont deux concepts. L'hémostase signifie seulement que le problème ne sera plus déclenché en permanence, et l'impact ne s'étendra plus, mais les conséquences du problème qui s'est produit Pourtant, (telles que les factures de carte, les erreurs de données, les erreurs de réception de fonds et de paiement), la récupération consiste à revenir complètement à l'état normal avant le problème. Ainsi, les caractéristiques temporelles positives des risques techniques nous obligent à privilégier l'hémostase lorsque l'hémostase et la récupération ne peuvent être réalisées en même temps, et la récupération de l'hémostase doit être découplée.

4) Le plan doit être évalué et foré régulièrement pour maintenir son efficacité, et les erreurs dans le plan entraîneront des défaillances secondaires.

5) L'attaque et la défense rouges et bleues doivent vérifier les capacités d'une série de systèmes techniques de risque tels que la découverte, l'hémostase, la récupération et la pré-planification. La capacité de régression similaire au test garantit les capacités techniques de prévention et de contrôle des risques du système en ligne et de la personne responsable.

6) La sensibilisation culturelle est importante. Par rapport aux tests hors ligne, le risque technique implique davantage de contenu de travail impliquant des personnes : analyse des risques, rapidité d'intervention d'urgence, prise de décision et jugement d'urgence, collaboration multiservices (telle que l'exploitation complète du client, le produit, les relations publiques, la gestion, les affaires, la finance, etc. .) ), etc., et la nocivité en ligne du risque détermine que l'expérience ne peut pas être accumulée par le combat réel. Par conséquent, dans le travail quotidien, l'équipe doit mettre l'accent sur la crainte des risques, appliquer strictement le processus, prendre au sérieux chaque exercice offensif et défensif et maintenir l'héritage de la culture du risque grâce à un fonctionnement continu de la culture du risque.

Le développement technique du risque technique s'articule également autour de ces étapes, similaires au processus de test, chaque étape subit également un processus de manuel à automatisé à intelligent. La performance du risque étant basée sur l'environnement de production en ligne, les données de base du risque sont plus facilement standardisables que les données de base du test (ordres de modification, ordres d'opération, éléments de suivi, règles de vérification, liens d'appel, lignage des données, etc. ), ces dernières années L'accumulation de données sur les risques a également ouvert la voie à l'intelligentisation des métiers du risque, et de nombreuses bonnes pratiques techniques ont également émergé.

Comme mentionné ci-dessus, la qualité et le risque technique sont déjà deux notions qui vont de pair. En tant que personne de qualité, vous ne devez pas manquer l'exploration et le développement dans le domaine du risque technique. De la prise de responsabilité à l'accumulation d'expérience en passant par le renforcement des capacités, vous devez faites-le d'une manière terre-à-terre.

5. Conception d'une organisation de qualité

Ne lisez pas la version trop longtemps : ce n'est qu'en comprenant votre propre équipe qualité que vous pourrez mieux évaluer votre présent et planifier votre avenir.

L'attribution des responsabilités découle de la conception organisationnelle, et la conception organisationnelle découle de la stratégie commerciale. Afin de faire du bon travail dans un travail de qualité, il est également nécessaire de comprendre la conception de l'organisation de la qualité d'un point de vue supérieur et de voir où vous en êtes. Ce qui suit ne représente que la réflexion et l'analyse personnelles, bienvenue pour faire des briques.

Remarque : Compte tenu de la situation générale dans l'industrie, l'équipe de qualité sera utilisée comme équipe représentative pour assumer les responsabilités mentionnées ci-dessus.

En recrutement, outre le souci du business et de la technologie, les candidats sont souvent plus soucieux de l'équipe : Quelle est la taille de cette équipe de qualité ? Cette simple question se pose en fait : à quel niveau de structure organisationnelle cette équipe de qualité est-elle conçue ?

Puisqu'il existe une correspondance naturelle entre le travail de test et le travail de développement, généralement la structure organisationnelle de l'équipe qualité et la structure organisationnelle de l'équipe de développement maintiendront également une correspondance. Du point de vue de la collaboration commerciale en amont et en aval, s'assurer qu'une équipe de développement l'unité se connecte uniquement à une équipe de test unique l'unité peut économiser le développement Coûts de synergie des tests. Ainsi, lorsque vous demandez quelle est la taille d'une équipe de qualité, le sous-texte demande : quelle est la taille de cette équipe de qualité qui se connecte à une équipe de développement ? À combien de cadres supérieurs le responsable de cette équipe qualité relève-t-il ? La réponse est évidente : plus l'équipe qualité est grande, plus le niveau organisationnel auquel elle appartient est élevé et plus l'étendue des responsabilités que l'équipe qualité peut assumer est grande.

L'équipe qualité d'une grande entreprise a connu plus de 5 ans de développement et a essentiellement expérimenté le processus de combinaison et de séparation :

Les start-up démarrent généralement avec plusieurs développements sans tests à plein temps. Une fois qu'un seul produit est formé, les tests à plein temps commencent. Pendant la période de développement du produit, l'équipe de test et l'équipe de développement grandissent ensemble. De petites équipes de test sont regroupées en une grande équipe de test de matrice de produits, et même continuer à se regrouper vers le haut en tant qu'équipe de test multi-entreprises. Après que le développement multiservice ait atteint un certain stade, en raison des divers impacts du développement multiservice et multiligne, l'équipe de test multiservice sera scindée, revenant à la forme d'une équipe de test monoservice pour soutenir chacun entreprise, ou même divisée en équipes d'unités plus petites. Lorsque les multiservices continueront à se développer jusqu'à un certain stade et que davantage de collaboration et de liens entre les entreprises seront nécessaires, l'équipe de test sera à nouveau agrégée pour une planification unifiée plus holistique.

D'une manière générale, une forme organisationnelle combinée est propice à assumer un plus large éventail de responsabilités horizontales, en mettant l'accent sur la cohérence globale des stratégies de qualité, d'efficacité et de risque technique dans une grande organisation technique, favorisant ainsi la pleine réutilisation des capacités de qualité, d'efficacité et de risque. , et éviter les doubles emplois Dans le même temps, il est avantageux pour les testeurs potentiels d'effectuer des migrations interentreprises vers le cloud au bon moment et de promouvoir la capacité des testeurs. Si une grande organisation technologique prend en charge plusieurs entreprises et qu'il existe des différences évidentes dans les objectifs stratégiques, les étapes et les méthodes de développement entre les entreprises, la stratégie globale en matière de qualité, d'efficacité et de risque technique aura tendance à considérer le type d'entreprise avec la proportion la plus élevée, ce qui est susceptible de donner des affaires spéciales apporte un malaise. Plus la différence commerciale est grande, plus l'inconfort est grand et plus le préjudice potentiel pour l'entreprise est important. Si l'équipe qualité abandonne la stratégie globale et met l'accent sur les stratégies d'individualisation de l'entreprise et le renforcement des capacités différenciées, alors premièrement, les avantages de la réutilisation des grandes équipes ne peuvent pas être pleinement reflétés (échelle, capacité du personnel) finiront par refléter les conflits au sein de l'équipe qualité, ce qui apportera une pression importante voire insupportable sur la gestion interne de l'équipe qualité.

La forme organisationnelle divisée permet à l'équipe de qualité de suivre l'activité, d'ajuster les stratégies de manière flexible et de développer rapidement des capacités ciblées. Elle convient le mieux aux entreprises en développement et en évolution rapides. L'inconvénient est que, limité par la taille de l'équipe et le personnel réserves de capacité, technologie de test La vitesse de développement et la précipitation des capacités seront affectées.Les testeurs correspondent à une entreprise depuis longtemps et leur vision est limitée, ce qui affectera également l'accumulation et le développement des capacités des testeurs. De plus, en raison d'informations médiocres et de prises de décision incohérentes au sein d'équipes multi-qualités, un renforcement répété des capacités est susceptible de se produire, entraînant des investissements répétés au niveau organisationnel.

En général, la conception de la structure organisationnelle de l'équipe qualité affecte deux aspects de la gestion organisationnelle : le téléchargement et la distribution, c'est-à-dire le flux d'informations et le flux d'exécution de la prise de décision. Une conception organisationnelle raisonnable peut équilibrer la tempête d'informations et la perte d'informations, et peut également améliorer l'efficacité de la gestion de la mise en œuvre de la prise de décision et de l'ajustement du retour d'information. Quel que soit le statut, l'équipe qualité est mieux placée pour recevoir les téléchargements de la ligne métier et de la ligne fonctionnelle en même temps, et en fonction des exigences sous-jacentes à la forme organisationnelle, prendre des décisions stratégiques spécifiques, en tenant compte des exigences de la deux lignes et en équilibrant les conflits potentiels. Il n'y a ni avantages ni inconvénients en soi, et celui qui convient à l'entreprise et à l'organisation est le meilleur. Mais en même temps, il faut aussi insister sur le fait que, quelle que soit la forme d'organisation de l'équipe, il faut faire jouer pleinement les avantages actuels, éviter les inconvénients et faire de la qualité un accélérateur de business plutôt qu'un ralentisseur.

La stratégie commerciale détermine la conception de l'organisation technique, et la portée du rapport test-exploitation est déterminée au sein de l'organisation technique, et la taille de l'équipe qualité est essentiellement déterminée. Voici un bref exposé sur le rapport mesure-ouverture très important dans la conception d'une organisation de qualité.

Il y a plus de dix ans, j'ai demandé à un certain patron, quel est le ratio de test approprié ? Mon patron a dit : le ratio de test est un nombre magique, je peux définir n'importe quel nombre, et ensuite vous pouvez le faire.

J'y réfléchis depuis de nombreuses années et j'ai eu les idées suivantes :

1) Il est possible de régler le rapport d'ouverture de mesure sur n'importe quelle valeur.

2) Comme le nombre du diable, il semble insignifiant à première vue, je ne sais pas pourquoi, mais il y a beaucoup d'informations cachées derrière.

3) Quel que soit le rapport de mesure, des résultats de qualité doivent être obtenus.

4) Le taux d'ouverture du test peut continuer à changer et les résultats de qualité doivent être garantis s'il change.

5) Un bon patron doit expliquer clairement la pensée derrière cela à ses camarades de classe, et il ne doit pas être paresseux dans une communication importante, et doit tenir compte des sentiments des membres, sinon le ressentiment peut durer longtemps.

Toujours la même phrase : la stratégie commerciale détermine la conception organisationnelle, et la conception du ratio test/ouverture peut être considérée de manière globale à partir des perspectives suivantes.

1) Attributs de qualité de l'entreprise elle-même

a. Quel dommage un problème de qualité causera-t-il à l'entreprise ?

b. Une bonne qualité peut-elle apporter de la croissance à l'entreprise ?

c. Quelles sont les exigences de qualité de l'environnement de l'industrie ?

2) Exigences de qualité actuelles de l'entreprise

a. La qualité, l'efficacité et le coût sont un triangle impossible. Quelle est la stratégie de compromis actuelle pour l'entreprise ?

b. Comment la qualité de l'entreprise se compare-t-elle à celle d'autres produits concurrents ?

3) Qualité actuelle de l'eau

a.Des résultats de qualité

capacité de b.Quality

c. Capacités d'organisation de la qualité

4) Dans l'attente des changements

a) Modifications des exigences de qualité pour le développement de l'industrie

b. Changements dans le stade de développement de l'entreprise

c. Le défi du développement de nouvelles technologies pour une technologie de qualité

5) Autres considérations organisationnelles telles que le recrutement du personnel, le développement de l'équipe et la compétitivité de l'industrie.

Quelqu'un a demandé, cela signifie-t-il que l'entreprise ne fait pas attention à la qualité parce que la proportion de testeurs est inférieure à celle des testeurs ? Tout d'abord, un malentendu doit être dissipé : le rôle de qualité entreprend le travail de qualité, mais cela ne signifie pas que tout le travail de qualité est entrepris par le rôle de qualité. Le ratio test/ouverture est le ratio personnel de qualité à temps plein : personnel de qualité non professionnel, et non le ratio qualité : charge de travail non qualitative. Un autre facteur d'influence est la division du travail de qualité entrepris par du personnel de qualité non professionnel, tel que l'auto-test de développement, la vérification du produit et l'acceptation des opérations.

Quel que soit le ratio test/ouverture, l'équipe qualité doit coordonner le travail qualité de tous les rôles, formuler des stratégies qualité, fournir des plates-formes d'outils, concevoir des processus qualité et superviser l'exécution de chaque rôle pour atteindre un équilibre entre qualité globale et efficacité. et le coût. La réponse est donc naturellement non. Les ratios test/capital des différentes entreprises ne sont pas comparables, et les ratios test/capital ne sont pas nécessairement liés au degré d'accent mis sur l'activité.

(Certains se demandent également, sous un même métier, le ratio historique de test et de développement peut-il expliquer l'importance du métier ? La réponse est également négative. Sous un même métier, cela dépend aussi du stade de développement, de la maturité des tests, des capacités de développement correspondantes , et l'équipe de test réelle. Responsabilités et autres facteurs complets.)

Petite astuce, pour voir si l'entreprise attache de l'importance à la qualité, vous pouvez regarder la voix du rôle qualité dans le travail qualité des autres rôles.

Après avoir déterminé l'emplacement et la taille de la structure organisationnelle de l'équipe qualité, l'équipe qualité doit se voir confier des responsabilités claires. Se référant aux risques qualité, efficacité et technique évoqués ci-dessus, il convient de déterminer les responsabilités spécifiques de ces trois directions, et de décomposer les objectifs stratégiques correspondants à l'équipe qualité.

Les responsabilités assumées par une équipe qualité spécifique peuvent être reflétées à partir du nom de l'équipe : par exemple, la chaîne de changements de nom de Département Qualité -> Département Qualité Technologie -> Département Qualité et Risques Technologiques représente le processus de mise à niveau des responsabilités de l'équipe.

Résumé : La conception d'une organisation de qualité est décomposée couche par couche, de la stratégie commerciale à la stratégie technologique en passant par la stratégie de risque qualité. De la structure organisationnelle au rapport d'échelle en passant par l'attribution des responsabilités, différentes conceptions organisationnelles ne sont pas intrinsèquement bonnes ou mauvaises, seule la meilleure est la meilleure. Dans le contexte d'Internet, la prémisse des changements rapides est également ajoutée. Ce n'est qu'en comprenant la conception de l'organisation de la qualité dans laquelle vous vous trouvez que vous pourrez mieux tirer parti de la tendance, tirer pleinement parti de vos avantages et offrir une valeur de qualité.

6. Plan de développement de carrière pour le personnel de qualité

Ne lisez pas la version si elle est trop longue : comprenez les exigences de la structure de capacité, démontez et analysez vous-même.

Parlons enfin du plan de développement de carrière du personnel de qualité.

En fait, la principale motivation qui m'a poussé à écrire cet article vient de la question que mes élèves de qualité m'ont le plus posée ces dernières années. Pour répondre à cette question, comme mentionné ci-dessus, vous devez d'abord voir clairement l'environnement dans lequel vous vous trouvez (industrie, entreprise, entreprise, équipe), puis vous voir clairement et enfin vous pouvez répondre par vous-même à vos propres questions d'évolution de carrière.

Nous avons parlé du développement de la technologie de test à partir de la forme du produit et du modèle de R&D, et de la conception organisationnelle à partir des rôles et des responsabilités. En fait, les parties 1 à 3 parlent de ce que les gens de qualité peuvent faire, et les parties 4 à 5 parlent de ce que l'organisation Ce n'est que dans ce chapitre que je peux revenir à l'individu, qu'est-ce que je fais déjà, que puis-je faire d'autre et que ferai-je à l'avenir ?

Après ces années de développement, les grandes entreprises ont mis en place un système de promotion professionnelle de qualité stable. Derrière la norme de promotion se trouve la structure des capacités. Nous devons nous voir clairement. Le moyen le plus pratique est de nous désassembler en fonction de la structure des capacités et de leur correspondre. Les critères spécifiques pour les niveaux de promotion s'analysent eux-mêmes.

La capacité professionnelle de qualité peut être décomposée en trois dimensions :

1) Compréhension des affaires et de l'architecture, qui est la capacité de base des rôles de qualité, reflétée dans : la compréhension du modèle commercial, de la conception du produit, de la logique du processus et de la conception de l'architecture, de la pile technologique et des détails de mise en œuvre du côté technique. La compréhension n'est pas seulement pour le travail de qualité, d'efficacité et de liens de risque, mais doit également participer à la conception du produit et de l'architecture le plus tôt possible du point de vue de la qualité, et fournir une valeur de qualité au stade le plus précoce.

2) La capacité de la technologie de la qualité, qui est la capacité de base du rôle de la qualité. De l'analyse des tests à la stratégie de test, du manuel à l'automatisation, du renforcement des capacités de test de base pour tester la mise en œuvre de technologies innovantes, il est nécessaire d'être passionné par le développement de l'industrie technologie, élargir constamment l'horizon et promouvoir La technologie de pointe est mise en œuvre et des solutions techniques de qualité sont fournies en fonction des caractéristiques de l'entreprise.

3) Capacités techniques générales telles que les algorithmes de données d'ingénierie, ce sont les capacités de catalyseur du rôle de qualité, les capacités d'ingénierie vont de l'écriture automatisée de code de cas d'utilisation, aux outils de qualité, à la construction de plate-forme, à la conception et à la livraison d'architecture de qualité, les capacités d'algorithme de données se reflètent dans comment tester une entreprise intelligente et comment tester avec intelligence.

Avec le développement de l'industrie, chacune de ces trois dimensions a une profondeur technique suffisante, et il n'est pas facile d'équilibrer le développement à court terme. Il existe un principe très important dans la planification des capacités : utilisez vos points forts. Personnellement, je suggère qu'au début, vous devriez vous attaquer correctement à plusieurs directions techniques (utiliser pleinement les opportunités offertes par l'équipe) et avoir une compréhension de votre niveau de capacité, de votre potentiel et de votre intérêt dans chaque direction ; , c'est mieux vaut être bon et aimer la direction, cultiver profondément pendant 2-3 ans, puis répéter ce processus d'évaluation-sélection.

Comment évaluer le degré auquel sa propre capacité a atteint? Rappelez-vous un principe : vous méritez ce que vous méritez. Ce n'est qu'en obtenant des résultats que nous pouvons prouver notre capacité.

L'exigence seuil est d'être responsable de grands projets et d'entreprises complexes (nombreuses et souvent compliquées selon le niveau de compétence). L'exigence avancée est d'avoir des méthodes techniques, des systèmes et des innovations dans le processus. L'exigence ultime est de prouver que les résultats du processus ci-dessus vous sont dus.

Je partage avec vous une astuce pratique :

Résumez la chose la plus difficile que vous faites chaque année et comparez-la avec la chose la plus difficile de l'année précédente. Est-ce plus difficile ?

Chaque année, je repense aux meilleures compétences que j'utilise, par rapport aux meilleures compétences de l'année précédente, est-ce que c'est mieux ?

Pensez à votre travail chaque année, changez-vous il y a deux ans et sentez que vous pouvez le faire à ce moment-là, veuillez lever la main. Étudiants qui lèvent la main, veuillez prêter attention à votre auto-évaluation de croissance.

La croissance personnelle et le développement organisationnel sont positivement corrélés la plupart du temps, s'il y a une incohérence entre les deux, alors l'un d'entre eux doit faire des changements. Chacun est le premier responsable de son propre développement de carrière.Il doit prendre une mesure plus proactive, parler à ses superviseurs, aligner ses cognitions, obtenir des commentaires et demander de l'aide.

Enfin, le plan de développement de carrière d'un personnel de qualité peut sortir de la ligne de la qualité. En raison des caractéristiques d'un travail de qualité, de contacts commerciaux diversifiés et de capacités professionnelles étendues, tant que vous décidez d'ajuster la structure des capacités, de transférer à entreprise, recherche et développement, efficacité, gestion de projet et succès dans les risques techniques Les cas sont nombreux chaque année.

temps d'oeuf

Pour en revenir aux questions au début de l'article, la plupart des questions que je reçois quotidiennement sont en fait basées sur les propres demandes de l'interrogateur, même s'ils sont préoccupés par l'industrie, ils sont également préoccupés par eux-mêmes. Par conséquent, la personne qui répond à la question doit savoir quelque chose sur la personne qui pose la question afin de répondre avec plus de précision.

Les trois méthodes suivantes sont fournies et la difficulté de fonctionnement est divisée en trois niveaux, de facile à difficile.

La manière la plus simple, je l'appelle la méthode d'analyse instantanée : Parlez au superviseur, tant que le superviseur qui est avec vous depuis plus de six mois doit être la personne qui connaît (et se soucie le plus) de votre état actuel, le les retours d'analyse donnés sont naturellement plus précis. Prenez le professeur comme ami et faites bien chaque tâche.

Une méthode un peu gênante, je l'appelle la méthode de l'examen historique : analysez votre propre processus de croissance depuis votre carrière, concentrez-vous sur l'analyse des événements clés, quelles compétences ont été considérablement améliorées et quel type de scène vous a donné cette opportunité, vous pouvez tout développer jusqu'à aujourd'hui (en travaillant chez Ali Ant), vous devez avoir fait quelque chose de bien, extraire les points clés de votre croissance, utiliser l'histoire comme un miroir et chercher des opportunités pour vous déclencher à nouveau.

C'est une méthode assez difficile, que j'appelle la méthode de prévision future : trouvez des pairs relativement expérimentés (y compris votre superviseur) en qui vous avez confiance et que vous reconnaissez, discutez ensemble du développement futur de l'entreprise et de l'industrie et analysez les exigences de votre travail et de vos compétences. Commencez par la fin en tête, développez-vous avec un but.