Certaines personnes disent : les tests logiciels constituent le niveau de travail le plus bas. Certains disent : lorsque le salaire des emplois de test atteint un certain niveau, il ne peut que rester là où il est et ne peut pas être amélioré. D'autres disent : par rapport au développement, l'industrie des tests est très low-tech et peut être facilement remplacée.
C’est en fait le plus gros malentendu à propos de l’industrie des tests. Les tests peuvent être approfondis ou superficiels, étroits ou larges. Il existe très peu de tests exceptionnels. De nombreuses personnes qui parlent de tests ne peuvent en réalité mentionner quelques bugs.
Chen Fuxuan, répondant à Zhihu, travaille comme testeur chez Microsoft depuis six ans. Il a résumé les différentes étapes des testeurs. Vous pouvez voir à quelle étape vous vous trouvez.
Même si je suis maintenant passé au développement, je suis dans ce secteur depuis six ans après tout, il semble donc que j'ai encore l'occasion de parler ici.
Au début, je suis entré en contact avec les tests par pur hasard : lorsque Microsoft est venu dans notre école pour des entretiens, seuls ceux qui effectuaient les tests étaient prêts à m'accepter. Mais après avoir exercé pendant un certain temps, je suis progressivement tombé amoureux de ce poste. Permettez-moi de parler de certaines de mes expériences passées.
Tout comme pour le développement, les testeurs expérimentés et inexpérimentés jouent des rôles très différents au sein de l’équipe. À en juger par les actions entreprises lorsqu'ils rencontrent des problèmes lors des tests, j'ai observé que les testeurs peuvent atteindre à peu près les niveaux suivants :
1. Ouvrez un bug ;
2. Recherchez des informations supplémentaires telles que les documents de conception et l'historique pour déterminer s'il s'agit d'un problème, puis fournissez les étapes détaillées pour reproduire le bogue ;
3. Affiner les étapes de reproduction et déterminer les étapes minimales pouvant reproduire le bug, si possible automatiser les étapes de reproduction ;
4. Essayez d'identifier le problème en étudiant le code ;
5. Essayez de fournir un correctif ;
6. Analyser les causes des erreurs et proposer des méthodes standardisées pour détecter des problèmes similaires, tels que le stress, le fuzzing, etc. ;
7. Être capable de définir des méthodes d'analyse de données correspondantes pour des processus de test standardisés peut garantir que les développeurs et les chefs de projet peuvent obtenir les informations dont ils ont besoin pour contrôler l'état de la qualité.
Alors, quel est notre objectif en tant que testeur ?
Mon objectif pour moi est de passer du niveau 1 au niveau 4 pour tous les bugs que je contrôle, et dans au moins deux cas j'ai même pu atteindre le niveau 6.
Je suis chez Microsoft depuis plus de six ans et dans de nombreux départements j'ai vu des tests qui atteignent toujours le niveau 7. Personne n'ose dire que ses compétences sont incompétentes s'il peut tester dans cet état.
Pour les développeurs, si vous avez quelqu'un autour de vous qui peut effectuer des tests de niveau 4 sur la plupart des bugs, je pense que le travail de développement sera beaucoup plus facile.
Même la capture de bugs est divisée en plusieurs types.
Attraper un groupe de singes et cliquer deux fois au hasard sur le clavier est un test, et avancer soigneusement étape par étape à travers divers moyens techniques (couverture de code, tests de résistance, analyse de sécurité, etc.) est également un test.
En tant que technicien, à qui faites-vous confiance ?
Je pense que la plupart des gens choisiraient la seconde option, mais je dirais qu'en pratique, de nombreuses équipes de test finissent sans le savoir par choisir la première.
Pourquoi? Parce que les testeurs ne comprennent pas la conception du produit, ils choisiront instinctivement la chose la plus simple à faire, mais demandez-leur : combien en avez-vous testé ? Quel est votre niveau de confiance ? Ils étaient tous abasourdis.
Je ne dis pas que les tests sur des singes n’ont aucun sens : au contraire, ils peuvent révéler de nombreux angles morts dans notre réflexion. Mais si toute votre équipe vit entièrement de tests sur des singes, il n’y a absolument aucun moyen que cela vous donne un résultat auquel vous puissiez avoir confiance.
Alors les lecteurs se demanderont inévitablement : combien y a-t-il de tests et d’équipes de renom ?
Malheureusement, parlant d'expérience personnelle, le fait est que parmi les testeurs que je rencontre, il n'est pas rare de voir des testeurs qui ne peuvent faire au mieux que le niveau 1.
Les testeurs qui peuvent atteindre 3 sont considérés comme assez bons par beaucoup de gens. Quant aux équipes composées de plusieurs testeurs experts, c'est vraiment rare (la proportion au siège de Microsoft est beaucoup plus élevée).
Oui, ne soyez pas surpris, c'est ce qui m'arrive au travail. Mais veuillez noter que cela ne signifie pas que l'entreprise dépense de l'argent pour lutter contre le gaspillage, mais que sans formation professionnelle en matière de tests, cela conduira inévitablement à la situation actuelle au début de l'entrée dans l'industrie. Nous partons tous de cet état et nous avons tous besoin de temps pour progresser.
Certaines personnes peuvent également se demander : n’est-ce pas pour rivaliser avec les développeurs pour le travail ? Oui c'est vrai. Mais pourquoi ne pouvons-nous pas l'attraper ?
Quel est notre objectif ? Est-ce pour ouvrir des bugs ou pour créer de meilleurs produits ? Si votre objectif est d'ouvrir plus de bogues, c'est très simple.
À titre d'exemple concret, j'ai vu un jour un collègue ouvrir un bug dans le code d'automatisation des tests en tant que bug de produit. Sa théorie est que quel que soit le bug, ouvrez-le d'abord, puis décidez s'il s'agit d'un problème de produit, d'un code de test. problème ou même un problème environnemental. Tout dysfonctionnement peut être atténué, et il n'est de toute façon pas responsable d'en indiquer la cause.
En fait, il est impoli de demander à un collègue de faire ceci ou cela, mais cette façon de ne rien faire et d'ouvrir les bugs en premier retarde le travail de tous les collègues.
En tant que membre de l'équipe, le temps supplémentaire consacré au test sur le produit peut parfois faire gagner plusieurs jours de travail de développement, car le testeur est la personne la plus familiarisée avec le bug, tandis que le développement doit l'analyser à partir de zéro.
——Bien sûr, le développement devrait également essayer d'introduire les tests dans le processus de développement afin que chacun connaisse les détails de l'avancement des différentes fonctions. Cette collaboration peut également réduire considérablement le temps nécessaire aux testeurs pour reconcevoir les cas d'utilisation lorsque la conception du produit change.
Enfin : le didacticiel vidéo complet sur les tests de logiciels ci-dessous a été compilé et mis en ligne. Les amis qui en ont besoin peuvent l'obtenir eux-mêmes [garanti 100 % gratuit]
Document d'entretien sur les tests logiciels
"Nous devons étudier pour trouver un emploi bien rémunéré. Les questions d'entretien suivantes proviennent des derniers documents d'entretien de sociétés Internet de premier plan telles que Alibaba, Tencent, Byte, etc., et certains patrons de Byte ont donné des réponses faisant autorité. Après avoir terminé cela Je crois que tout le monde peut trouver un emploi satisfaisant sur la base des informations recueillies lors de l'entretien.
