La plupart des programmeurs ne peuvent pas tester efficacement leurs programmes car ils ne peuvent pas se mettre dans l'état mental nécessaire. En plus de ce problème psychologique, il y a un autre problème important: le programme peut contenir des erreurs causées par l'incompréhension du programmeur sur le récit ou l'explication du problème. Si tel est le cas, lorsque les programmeurs testent leurs propres programmes, ils portent souvent les mêmes malentendus qui rendent le problème difficile à trouver. Trouver des défauts dans son propre travail est souvent intolérable dans l'état mental des gens.
La vue ci-dessus ne signifie pas qu'il est impossible pour les programmeurs de tester leurs propres programmes. Cependant, en revanche, si d'autres personnes effectuent des tests de programme, ce sera plus efficace et plus fructueux. Remarque: cet argument ne s'applique pas à la correction d'erreurs (correction d'erreurs connues). La correction par l'auteur du programme d'origine est nettement plus efficace.
À bien des égards, une organisation d'ingénierie ou de programmation est un organisme vivant et présente également des problèmes psychologiques.
Cet article se concentre sur la discussion de certaines des manifestations de la psychologie dans le processus de test et comment appliquer la psychologie au test.
En fait, la psychologie est principalement utilisée pour deviner le comportement opérationnel de l'utilisateur dans le test. Deviner le comportement des utilisateurs n'est pas une question simple, après tout, ce n'est pas ce que le poisson pense. Pour un nouveau testeur, il est en effet très difficile de deviner avec précision le comportement de l'utilisateur. Cela nécessite une richesse d'expérience et d'accumulation, ainsi qu'une intuition inexplicable. Sur la base de ces années d'expérience professionnelle, j'ai résumé les comportements opérationnels de certains utilisateurs, et ce code de conduite est toujours applicable à la plupart des utilisateurs.
1. En termes de mentalité, clarifiez votre rôle
De manière générale, dans des circonstances idéales, les testeurs de logiciels testeront toutes les situations d'exécution possibles du programme, mais dans la plupart des cas, cela est presque impossible. Même si un programme semble très simple, ses combinaisons d'entrée et de sortie possibles peuvent atteindre des centaines, voire des milliers. Il n'est pas réaliste de concevoir des cas de test pour toutes les situations possibles. Un test complet d'une application complexe consommera beaucoup de temps et de ressources humaines, ce qui n'est pas économiquement réalisable.
La recherche psychologique nous dit que lorsque les gens font quelque chose qui est déjà connu pour être inapproprié ou impossible, ils ont souvent de très mauvais résultats. Mais si le test du programme est défini comme le processus de recherche d'erreurs dans le programme, le test devient une tâche qui peut être effectuée, surmontant ainsi les problèmes psychologiques. Bien que cela ressemble à un jeu de mots subtil, cela a un impact important sur le succès des tests logiciels.
Par conséquent, ne testez pas le programme uniquement pour prouver que le programme peut s'exécuter correctement. Au contraire, vous devez supposer qu'il y a des erreurs cachées dans le programme au début (cette hypothèse est vraie pour presque tous les programmes), puis tester le programme pour en trouver autant que possible erreur.
En bref, les tests de logiciels sont plus convenablement considérés comme un processus destructeur consistant à essayer de trouver des erreurs dans le programme (en supposant leur existence). Un test réussi peut favoriser l'amélioration de la qualité du logiciel dans cette direction en induisant des erreurs de programme. Bien sûr, en fin de compte, les gens doivent encore construire un certain degré de confiance grâce aux tests de logiciels: le logiciel fait ce qu'il doit faire, mais pas ce qu'il ne devrait pas faire.
2. Ne suivez pas trop les règles
Pour un nouveau produit, de nombreuses personnes ne liront pas le manuel d'utilisation. Cela est dû au fait que le produit est déjà familier à l'utilisateur ou que l'utilisateur a utilisé le même produit et que certains utilisateurs n'aiment tout simplement pas suivre les règles. . Cela rend le test plus difficile.Les testeurs doivent simuler les étapes et les scénarios d'utilisation que les utilisateurs peuvent utiliser pour s'assurer que le produit est bon.
L'analyse de ce comportement de l'utilisateur est en fait très facile à comprendre. La personne qui utilise cette fonction n'est peut-être pas un artiste professionnel. Sa compréhension du fichier n'est qu'en surface. Il peut être pour la commodité de l'œuvre de simplement changer le fichier en ce qu'il pense être correct. Up. Bien sûr, cela est considéré comme un bogue, et finalement le bogue est corrigé.
En résumé, ne suivez pas strictement les règles, car les utilisateurs ne le font pas. Ils utiliseront également certaines méthodes pour contourner les règles et essaieront de les prendre en considération lors des tests.
Troisièmement, réfléchissez davantage aux règles et aux comportements que les utilisateurs respectent inconsciemment
Certains utilisateurs ont des habitudes inconscientes d'utilisation du produit. Comme mentionné dans l'article précédent, de nombreux utilisateurs ne lisent pas le manuel, et certains excellents chefs de produit travaillent également à la conception de produits permettant aux utilisateurs d'échapper au manuel. Bien sûr, c'est un produit qui ne peut être réalisé qu'après que le produit ait de nombreux utilisateurs fidèles, tout comme le téléphone mobile Apple. Pour un produit nouvellement lancé, de nombreux utilisateurs ne comprennent toujours pas les règles, mais en fait les utilisateurs ne veulent pas comprendre. Ils n'utilisent le produit qu'en fonction de leur propre expérience et ne lisent le manuel que lorsqu'ils se heurtent à un mur. Par conséquent, le testeur doit s'assurer que la couverture de test de la scène anormale est complète et dispose d'un guide convivial pour guider l'utilisateur pour l'utiliser correctement.
Lors du test, vous pouvez oublier de manière appropriée les règles familières et opérer en fonction de votre esprit subconscient. En tant que testeur, vous connaissez ce produit, mais pas les utilisateurs. Parfois, ils agissent volontairement selon leurs propres idées.
Dans le test, le testeur doit deviner la psychologie et le comportement de l'utilisateur à partir des aspects consistant à guider l'utilisateur dans son fonctionnement, à utiliser la fonction et à prédire l'expérience de l'utilisateur. Cependant, deviner la psychologie et le comportement des utilisateurs n'est pas une question simple, après tout, ce n'est pas ce que le poisson pense. Pour un testeur qui vient d'entrer dans l'industrie, il est en effet très difficile de deviner avec précision le comportement des utilisateurs, ce qui nécessite une riche expérience et une accumulation.
Quatre, comprendre la pensée inverse
La pensée inverse consiste à penser la cause à partir du résultat. Ce n'est pas la façon dont les utilisateurs pensent, mais de nombreux utilisateurs sont déclenchés de cette manière. En d'autres termes, pour les utilisateurs, le processus n'est pas important, ils peuvent utiliser n'importe quelle méthode et méthode d'exploitation pour atteindre leur objectif. Certaines opérations ne sont pas intéressantes pour l'utilisateur.
Il est nécessaire de déduire de l'objectif et de deviner les étapes et les scénarios d'opération possibles pour compléter les cas de test. Bien que la probabilité de rencontrer une telle scène soit très faible, il existe plusieurs aspects de l'utilisation de la psychologie dans le test pour guider les utilisateurs dans l'utilisation et l'utilisation des fonctions, et pour prédire l'expérience des utilisateurs. Toutefois, si le chef de produit considère ces deux aspects de manière exhaustive lors de la conception du produit, ils seront résolus au stade de la conception du produit. Cependant, ces deux aspects ne peuvent pas dépendre complètement de la conception du chef de produit. Pensez-y davantage lors des tests. , Cultivez votre propre réflexion utilisateur.
Tester la psychologie consiste à étudier la manière dont les utilisateurs pensent et fonctionnent, et à tester les produits du point de vue des utilisateurs. Assurez-vous ensuite que le produit répond autant que possible aux besoins des utilisateurs. Les produits qui peuvent fidéliser les utilisateurs sont de bons produits.
Cinq, savoir gérer les relations interpersonnelles avec les développeurs
Quel est le but du développement et des tests? Le développement est de répondre aux besoins des clients et les tests sont de garantir la qualité du logiciel. Les deux devraient être une relation de coopération gagnant-gagnant, pas un jeu à somme nulle, pas un flux et reflux, ce n'est pas vous gagnez et je perds. Il y a opposition et unité entre le développement et les tests. C'est une communauté de lance et de bouclier.
Les développeurs de logiciels sont plus conscients de l'architecture logicielle, peuvent déterminer à l'avance où les bogues sont susceptibles de se produire et localiser rapidement les problèmes qui se produisent; tandis que les testeurs, en tant qu'utilisateurs de logiciels, peuvent rapidement faire part de leurs impressions sur l'utilisation du logiciel. Laissez les développeurs comprendre le test, aidez les développeurs à en savoir plus sur les exigences de l'utilisateur et à comprendre en profondeur comment le logiciel est utilisé. Les bons testeurs devraient se lier davantage aux développeurs et travailler dur avec eux pour faire un meilleur travail.
Cependant, il convient de noter que les ingénieurs de test logiciel soumettent principalement des rapports d'erreurs, mais ne peuvent pas prendre l'initiative de proposer des mesures d'amélioration spécifiques pour améliorer le processus logiciel, et encore moins interférer directement avec les méthodes de travail du programmeur, afin de ne pas être ingrat et affecter la future coopération agréable. N'oubliez pas que la méthode d'amélioration des processus logiciels est l'affaire du service de contrôle de la qualité des logiciels, qui est leur travail.
6. Les tests de logiciels doivent être évités par les programmeurs qui conçoivent des logiciels
Le développement et les tests sont des activités intrinsèquement différentes: le développement consiste à créer ou à construire un module ou l'ensemble du système; et le but des tests est de prouver qu'un module ou un système ne fonctionne pas correctement. Il y a une contradiction essentielle entre ces deux activités: si une personne joue à la fois le rôle de constructeur et de destructeur, il est impossible de jouer les deux rôles diamétralement opposés.
Tout d'abord, lorsqu'un programmeur a fini de concevoir, il est très difficile de lui demander de changer soudainement de vue du jour au lendemain et d'essayer d'avoir une attitude négative envers son propre programme.
Deuxièmement, le programme peut contenir des erreurs causées par l'incompréhension du programmeur sur le récit ou l'explication du problème. Si tel est le cas, lorsque les programmeurs testent leurs propres programmes, ils portent souvent les mêmes malentendus qui rendent le problème difficile à trouver. Sur la base des facteurs psychologiques ci-dessus, les développeurs ne devraient pas être autorisés à participer au test.
Résumé du nouveau rêve: le test de logiciels est un travail technique, et il implique également une certaine psychologie humaine.Parfois, les tests ne sont pas seulement des tests. Les tests sont un travail très créatif et intellectuellement stimulant, et suivre les règles en silence peut ne pas vous permettre de maximiser votre valeur. Le but ultime du test est pour l'utilisateur. Seul du point de vue de l'utilisateur peut tester de manière flexible, obtenir des résultats efficaces et améliorer le produit. Ce n'est qu'alors qu'un testeur professionnel qualifié.