Quels sont les bugs du jeu ? Tout est cassé : des bugs légendaires dans les jeux vidéo. Visites à travers le quartier Seedy

Parfois, en surfant sur Internet, vous pouvez tomber sur le mot « bug ». Que signifie-t-il et quelle est l’étymologie de ce mot ? Vous pouvez trouver les réponses à ces questions dans cet article.

Bug - qu'est-ce que c'est ?

Le mot « bug » vient de la langue anglaise. En anglais, bug (prononcé « bug ») est un bug ou un coléoptère. Ce mot est principalement utilisé par les programmeurs, les testeurs et les joueurs. Mais qu'est-ce que ça veut dire?

Un bug est un écart entre les spécifications techniques du programme et le comportement réel du système. En raison de cette divergence, le logiciel ne peut pas remplir la fonction prévue par le développeur. En termes simples, un bug est une erreur qui se produit en raison d'une faille dans le code source du programme.

Origine du mot

Peut-être vaut-il maintenant la peine de parler de l’étymologie de ce mot. Un bug est un professionnalisme le plus souvent utilisé parmi les programmeurs. Il existe plusieurs options pour l'origine de ce mot.

Si l'on en croit la légende, ce professionnalisme est apparu en 1945. Cela s'est produit lorsque les scientifiques testaient un nouvel ordinateur appelé Mark II Aiken Relay Calculator. L'appareil a refusé de fonctionner, en raison d'un petit papillon coincé entre les contacts. L'insecte a été retiré de l'ordinateur et inséré dans un journal technique spécial. Près du papillon de nuit, il y avait une inscription « Premier cas réel de bug découvert », qui se traduit par « Le premier cas concret où un bug (bug) a été découvert ». Après cette histoire amusante, le mot « bug » a commencé à être utilisé pour signifier « erreur ».

Il existe également une version selon laquelle ce professionnalisme est apparu bien avant les tests du dispositif informatique. Certains pensent que le terme « bug » doit son origine au célèbre inventeur. Selon la légende, Edison cherchait un cafard dans son phonographe, mais celui-ci n'était pas là. Le bug provenait de l'appareil lui-même.

La version suivante dit que le mot « bug » est apparu pendant la Seconde Guerre mondiale. À cette époque, ce terme désignait des problèmes liés aux équipements radar.

Le mot « bug » a commencé à se répandre rapidement. Dans les années 80-90, seuls les programmeurs utilisaient ce professionnalisme. Avec l’avènement d’Internet, le mot a commencé à circuler activement. De nos jours, « bug » est utilisé dans leur vocabulaire par tous ceux qui ont le moindre lien avec l'informatique (joueurs, simples internautes, etc.). Par conséquent, on peut désormais l’appeler en toute sécurité une partie de l’argot Internet.

Bugs du jeu

Les bugs n’existent pas seulement dans les programmes, ils sont également assez courants dans les jeux. Un bug de jeu est un défaut des développeurs, à cause duquel le gameplay ne se déroule pas comme prévu initialement. Tout au long de l’histoire de l’industrie du jeu vidéo, des milliers de projets buggés ont été publiés. Nous parlerons des plus célèbres et des plus divertissants dans cette section.

Le projet le plus bogué de ces dernières années s’appelle peut-être Assassin’s Creed : Unity. Les projets Ubisoft n'ont jamais été réputés pour leur optimisation, mais Unity est une véritable encyclopédie de bugs. Parfois, les personnages prennent des poses très étranges et peu naturelles, se transforment en textures, traversent les murs ou se figent simplement. Il suffit de regarder le bug qui s'est propagé sur Internet en quelques heures (les visages des personnages ont tout simplement disparu, c'est pourquoi ils avaient l'air assez effrayants). Même Ubisoft lui-même a reconnu son erreur, publié un correctif qui corrigeait les bugs et indemnisait les clients pour les dommages.

Parfois, les joueurs perçoivent les bugs comme des fonctionnalités, des fonctionnalités du jeu. Cela s'est produit avec la série de jeux à succès appelée Mortal Kombat. Dans la première partie du jeu, il y avait un bug qui repeignait le Scorpion (l'un des personnages principaux du jeu) en rouge. Dans ce cas, le nom du héros a été remplacé par le message d'erreur Error Macro. Les joueurs pensaient que cette faille était l'idée des développeurs et que le ninja rouge était un personnage secret supplémentaire. Ed Boon (créateur de MK) a aimé cette idée et, dans la partie suivante, il a ajouté ce héros au jeu sous le nom d'Ermac (abréviation de Error Macro).

Comment se protéger des bugs ?

Afin de supprimer les bugs de leurs projets, les développeurs embauchent des personnes spéciales appelées testeurs. La tâche du testeur est de trouver toutes les failles d'un programme, d'un jeu ou de tout autre logiciel.

Mais les testeurs ne trouvent pas toujours des bugs, et parfois quelques défauts s'infiltrent encore dans la version finale du projet. Dans ce cas, tout espoir réside dans les utilisateurs qui peuvent envoyer une lettre spéciale décrivant l'erreur - un rapport de bug. Cela contribuera à améliorer le produit final. De plus, les grandes entreprises récompensent bien la découverte de bugs dans leurs produits. Par exemple, Google est prêt à donner 15 000 dollars pour l'inciter à détecter des bugs importants dans son navigateur.

Quand quelque chose n'allait pas.

Vers les favoris

Il y a probablement toujours eu des bugs dans les jeux. Et peu importe la qualité des testeurs, certains bugs se retrouveront toujours dans la version finale. Parfois, ces problèmes interfèrent avec la réalisation des jeux, parfois ils deviennent des mèmes et, dans des cas très exceptionnels, ils aident les concepteurs de jeux à proposer de nouvelles choses étonnantes.

Ce n'est pas le cas, bien sûr

Écran tueur dans les vieilles arcades

Il serait faux de supposer que les problèmes et les bugs n’apparaissent que dans les jeux modernes. Ils sont avec nous presque depuis le tout début de l’industrie du jeu vidéo. Les premiers exemples sont des bugs dans les machines de jeux d'arcade appelés écrans de suppression. L'essence de l'erreur est que le dernier niveau du jeu est le plus souvent impossible à terminer.

Prenez Pac-Man par exemple. Si vous atteignez le niveau 255, des choses assez terribles commencent à se produire dans le jeu : la moitié de l'écran est remplie de chiffres et de sprites de jeu, ce qui rend le jeu difficile (pour les gens ordinaires ; les professionnels sont rarement gênés par de telles difficultés). Une procédure spéciale détermine où et en quelle quantité les bonus apparaissent. Il prend les données directement du numéro de niveau, et lorsque la valeur dépasse l'octet (c'est-à-dire à l'étape 256), le jeu s'interrompt un peu.

Donkey Kong dispose également d'un écran tueur, mais sous une forme légèrement différente. Si vous atteignez le niveau 22, Mario mourra quelques secondes seulement après le début du jeu. Cela se produit en raison de la même limite d'octets.

Le temps imparti pour un niveau est calculé selon une certaine formule : 10x(*numéro de niveau*+4). Si le joueur atteint le niveau 22, alors la formule affiche le nombre 260, mais le jeu n'accepte que des valeurs jusqu'à 256, et donc 260 se transforme en 4. En quatre secondes, le héros n'aura que le temps de parcourir quelques pas , après quoi il mourra.

Dans Duck Hunt sur NES, vous pourriez rencontrer l'écran du tueur une fois que vous aurez atteint le niveau 100. Puis les canards commencèrent à sortir des buissons à grande vitesse et en grand nombre. Bien sûr, il était impossible de leur tirer dessus et le jeu s'est terminé.

Combos dans Street Fighter II

La possibilité d'infliger plusieurs coups à un adversaire est apparue avant même Street Fighter, mais c'est la deuxième partie de la série qui a popularisé le système combo et obligé les autres développeurs à y prêter attention.

Comment tout cela s'est passé : En testant le jeu et en attrapant des bugs, le producteur principal de Street Fighter II, Noritaka Funamitsu, a remarqué que dans le niveau bonus (où il fallait détruire une voiture), le personnage pouvait infliger plusieurs coups supplémentaires. Pour ce faire, il a fallu respecter un calendrier très strict, ce qui en soi était difficile.

Il a été décidé de ne pas supprimer l'erreur car il est peu probable que quiconque décide de l'utiliser. Les joueurs n’ont cependant pas reculé et ont appris les combinaisons. Dès Super Street Fighter II, sorti en 1993, le jeu a commencé à compter et à récompenser chaque coup d'un combo, cimentant ainsi officiellement le système de combo dans le genre des jeux de combat.

Un jour, je cherchais un niveau bonus (avec une voiture) et j'ai remarqué quelque chose d'inhabituel. Après avoir revu les images, mon équipe et moi avons découvert que si nous chronométrions bien, nous pourrions décrocher un coup supplémentaire. Je pensais que je ne pouvais pas utiliser cette fonctionnalité car le timing était trop petit et il était très difficile de l'attraper. Il a été décidé de tout laisser tel quel.

Le plus intéressant est que cela a servi de base à tous les futurs jeux. Ensuite, nous avons rendu les timings plus confortables et créé un système combo. Dans SFII, nous pensions que si vous jouiez bien, vous pourriez obtenir environ quatre coups sûrs. Et puis nous avons réussi à en atteindre huit. Bogue? Probablement!

Noritaka Funamitsu

Producteur Street Fighter II

Ermak dans Mortal Kombat

Ermak de Mortal Kombat doit son apparition à la rumeur. Le fait est qu'après la sortie de la première partie, de nombreux joueurs ont commencé à affirmer avoir remarqué un bug dans le jeu dans lequel la couleur des vêtements du Scorpion change du jaune au rouge et l'inscription Ermac apparaît dans la barre de vie.

Ermak dans le film Mortal Kombat : Annihilation

Immédiatement, on a supposé qu'il s'agissait d'un personnage secret qui pourrait être déverrouillé d'une manière ou d'une autre. Des images du héros sont même apparues dans les magazines de jeux de l'époque, qui se sont toutefois révélées fausses. Bien sûr, il n'y avait pas d'Ermak dans la première partie de MK. Les développeurs ont introduit un personnage secret portant ce nom uniquement dans Ultimate Mortal Kombat 3. Ainsi, à cause de rumeurs concernant un bug, un héros de jeu de combat est né.

Combat mortel ultime 3

"Pokémon perdu" de Pokémon Rouge et Bleu

Il existe de nombreux monstres emblématiques dans l'univers Pokémon. Mais il y en a un spécial : MissingNO. Contrairement à tout le monde, c'est un bug. Un Pokémon apparaît après avoir effectué trois actions consécutives. Le joueur doit d'abord terminer le didacticiel du jeu, puis utiliser un Pokémon capable de voler pour se rendre sur l'île Cinabre. Là, vous devez prendre un Pokémon aquatique et nager de haut en bas près de la côte est de l'île. Après cela, un bug se produira dans le jeu et MissingNO apparaîtra.

C'est vrai, il faut être prudent. Nintendo a averti les utilisateurs en 1999 que tout contact avec des Pokémon secrets pourrait endommager les sauvegardes du jeu. En outre, un effet secondaire de la réunion est que le nombre d’objets situés dans le sixième emplacement du sac à dos du héros passera à 128. Divers artefacts graphiques peuvent également apparaître dans le jeu. MissingNO peut même être capturé et utilisé au combat. Dans le Pokédex, il reçoit le numéro 000. Le nom du Pokémon lui-même signifie Missing Number.

MissingNO est un bug logiciel qui ne fait pas partie du jeu. Si vous le rencontrez, le jeu peut se comporter étrangement et les graphismes contiennent souvent des artefacts.

Pour résoudre les problèmes graphiques, essayez de publier MissingNO Pokemon. Si le problème persiste, la seule solution est de redémarrer le jeu. Cela signifie que vous devez effacer vos sauvegardes actuelles et recommencer.

Informations sur le site de Nintendo

Bogues d'Ultima Online

Quiconque a joué à UO sait que trouver des exploits, des bugs et toutes sortes de choses imprévues est une partie importante du gameplay. Sur les forums, vous pouvez lire d'innombrables conseils sur la façon d'améliorer vos compétences en utilisant des chevaux et des macros, comment accéder à des propriétés privées à l'aide d'un bug avec des portes, et bien plus encore. Raf Koster, l'un des développeurs du jeu, se souvient de certains bugs célèbres sur son blog. Par exemple, il s’est avéré que les objets rares que les joueurs adorent collectionner sont le résultat d’un bug.

Ultima Online était distribué sur disques et se composait en fait de deux parties. La première partie, statique, était sur support physique : c'était le sol, les arbres, les bâtiments, la décoration intérieure, tout ce que les promoteurs n'avaient pas prévu de déplacer ou de modifier d'aucune façon. La deuxième partie, dynamique, était simulée par le serveur : il s'agissait de monstres, de points de réapparition et d'objets fabriqués par les joueurs. Il arrivait que des éléments de la première catégorie tombaient dans la seconde à la suite de bugs. C'est ainsi que des objets de collection tout à fait uniques sont apparus dans le jeu, tels que toutes sortes de vases et de pièces intérieures qui ne pouvaient en aucun cas être utilisées, mais pouvaient être récupérées et emportées avec vous. Beaucoup de choses ont été vendues sur eBay pour beaucoup d'argent, les utilisateurs ont même créé des musées.

À peu près au même moment, un bug lié à l’eau portable est apparu. Les espaces aquatiques dans UO sont constitués de segments et l'emplacement de chacun est contrôlé par le serveur. Mais parfois, à cause d'erreurs, l'un des segments du réservoir du jeu pouvait disparaître, c'est pourquoi un véritable trou se formait dans l'eau. Ensuite, lorsque le serveur a redémarré, le segment manquant a été remplacé par un nouveau.

Cependant, il y avait une subtilité : dans ce cas, le segment devait avoir un paramètre qui interdisait de déplacer et de soulever l'objet. Bien sûr, ils oubliaient souvent de le faire, et donc le « morceau » d'eau nouvellement apparu pouvait être ramassé et emporté avec vous. Si nécessaire, il pouvait être posé sur le sol, pêché et relevé.

Les objets peints avec de la peinture « true black », qui sont également apparus à la suite d'un bug, sont particulièrement rares dans le monde d'UO. Le fait est le suivant : dans UO, il existe un bain pour peindre des objets. Vous versez de la peinture là-dedans, mettez le truc, il est peint - c'est simple. Cependant, en raison d'un bug, le système n'a pas pu déterminer la couleur de la peinture et la définir comme noire, et si noire qu'il n'y avait aucun autre effet visuel sur les objets peints.

Un joueur portant une telle armure ressemblait à un petit trou noir. Dois-je dire que les équipements peints dans cette couleur ont immédiatement gagné en popularité ? Plus tard, les développeurs ont supprimé tous les bains de buggy, mais ils n'ont pas touché aux objets, c'est pourquoi leur valeur est montée en flèche.

Notre mérite n’est pas d’avoir créé toutes sortes d’objets de collection sympas dans le jeu. Il s’agit de donner aux utilisateurs une liberté de comportement. Nous avons simplement créé un environnement dans lequel ces choses peuvent se produire. Oui, parfois des choses ennuyeuses se produisent, comme la possibilité de pénétrer par effraction dans les maisons d'autres personnes dans le jeu ou de tuer les personnages d'autres utilisateurs. Mais le plus souvent, des choses magiques se produisent grâce à la perspicacité des joueurs.

Raf Koster

Concepteur principal Ultima Online

Jongler avec les adversaires dans Devil May Cry

Initialement, Devil May Cry a été conçu comme le prochain volet de Resident Evil (le quatrième, pour être précis). À la tête du projet se trouvait Hideki Kamiya, qui prévoyait de faire du jeu un jeu d'action rapide dans un décor gothique, avec une caméra dynamique et un personnage principal surhumain. Du coup, le concept a tellement évolué que les créateurs s'en sont rendu compte : le jeu ne rentre plus dans la série Resident Evil. L'intrigue a été réécrite, le titre a été modifié et le héros a reçu le nom de Dante.

Le diable peut pleurer

La partie intéressante a commencé lorsque Hideki Kamiya s'est assis pour tester le jeu Onimusha : Warlords (sorti en 2001 sur PS2). Il s'est avéré qu'il y avait un bug dans le jeu, à cause duquel vous pouvez littéralement jongler avec vos adversaires tout en frappant. Bien sûr, il a été supprimé de la version finale, mais le concepteur du jeu a tellement aimé cette idée qu'il l'a transférée à DMC. Ainsi, à cause d'un bug, les jeux sur le démon Dante ont leur propre fonctionnalité.

Initialement, Devil May Cry était censé être un nouveau jeu de la série Resident Evil. Mais il ne s'est pas si bien intégré à la série qu'il est devenu DMC, et nous avons perdu une année entière de développement. Je pensais que j'avais peut-être foiré et que Capcom voulait me virer. Cela expliquerait pourquoi je n'étais pas autorisé à travailler sur DMC2.

Hideki Kamiya

Game designer de Devil May Cry, dans une interview avec le site 1UP

Onimusha : seigneurs de guerre

Peste dans World of Warcraft

En septembre 2005, World of Warcraft était jonché d'ossements de joueurs. Le coupable était la peste, qui a fauché des centaines de malheureux aventuriers. Tout a commencé avec le raid Zul'Gurub, dans lequel les joueurs devaient combattre Hakkar the Soul Flayer. Le patron avait un tour dans son sac : il suçait le sang des héros, leur redonnant ainsi des forces. Cependant, il était possible d'infecter son sang : le joueur subirait des dégâts, mais Hakkar serait également infecté et finirait par mourir.

Hakkar l'Écorcheur d'âmes

Il n'y avait qu'un seul problème : les concepteurs ont oublié de supprimer l'effet du sang infecté du gibier. Ainsi, si vous invoquiez votre partenaire lors d'un combat de boss au cours duquel il était infecté, puis que vous l'invoquiez à nouveau quelque part dans la ville, vous attraperiez vous-même la maladie et mourriez. Comme les développeurs l'ont expliqué plus tard, il n'y avait tout simplement aucun code dans le jeu qui indiquerait que le joueur n'était pas dans un raid, et il était temps de désactiver l'effet d'infection.

Les gens essayaient de rester à l’écart des villes et écrivaient aux autres : « Ne retournez pas en ville, sinon vous l’attraperez à nouveau. Restez dans le désert. » C’était une sorte de quarantaine grâce à laquelle les joueurs ont survécu.

Shane Dabiri

Il a fallu près d'un mois pour corriger la situation. En conséquence, la capacité des animaux de compagnie à être porteurs de la maladie a tout simplement été supprimée et la peste a pris fin. Les développeurs eux-mêmes disent qu'ils ne regrettent pas l'incident.

En général, grâce à la peste, nous avons créé des choses qui nous seraient utiles dans le futur. Sans elle, nous ne saurions pas comment créer les événements de jeu sympas que nous organisons actuellement. Cela s’est avéré être une page intéressante de l’histoire de notre monde du jeu vidéo. De plus, les équipes de conception ont beaucoup appris.

Shane Dabiri

L'un des dirigeants de Blizzard

Le visage de Drake dans Uncharted 2

Une image du visage de Nathan Drake floue dans Uncharted 2 : Among Thieves est apparue pour la première fois sur les tableaux d'images. « Drakeface », comme l'appelaient les utilisateurs, a rapidement gagné en popularité, est devenu un mème et une sorte de symbole du jeu sur console. Apparemment, le matériel de la PS3 est obsolète, les graphismes sont savonneux, et voici comment cela se passe.

En fait, le « drakeface » est le résultat d’un bug qui, si on le souhaite, peut être reproduit. Accédez simplement au mode de création vidéo dans la section « Jeu collectif », sélectionnez n'importe quel enregistrement de match, pointez immédiatement la caméra vers le mur et appuyez sur pause au moment du premier décès. Ensuite, nous volons simplement vers le lieu de la mort du personnage et voyons le « visage de drake ». En raison d'un bug, au moment de la mort, le visage du personnage est mal chargé, c'est pourquoi cet effet est obtenu.

Héros hurlant Forte pluie

Heavy Rain n’est pas le jeu le plus positif. Meurtre, drame familial, pluie constante, peu de raisons de s'amuser. Cependant, un bug aléatoire change tout et transforme une histoire sérieuse et triste en une véritable farce. Attention, spoilers.

À la toute fin du jeu, le personnage principal, Ethan, retrouve son fils disparu et se retrouve face à un mystérieux tueur. Et puis quelque chose se brise dans le jeu, et le mot « SEAN » apparaît à l'écran et vous invite à appuyer sur X. Le héros commence à crier le nom de son fils, encore et encore. Il y a un tueur devant lui - "SHOOON", il a été abattu avec un pistolet - "SHOOON", la bataille finale dans une usine abandonnée - eh bien, vous voyez l'idée. Malheureusement, on ne sait pas comment répéter le bug, nous ne pouvons donc qu'espérer de la chance.

Chaque joueur a rencontré des problèmes dans un jeu vidéo à un moment donné de sa vie. Et s'il a déjà beaucoup d'expérience en jeu, alors il sait que dans son environnement, de tels échecs sont appelés bugs. Cependant, tout le monde ne sait pas ce qu'est un bug, donc lorsqu'ils lisent des messages sur des forums ou des critiques de jeux, ils peuvent ne pas comprendre ce qu'ils essaient de leur dire. Mais vous devez absolument comprendre cela, car les bugs sont un très gros inconvénient des jeux informatiques, et si vous découvrez de n'importe où qu'un certain jeu en contient beaucoup, il vaut mieux s'abstenir de l'acheter. Pourquoi? Cet article vous en parlera.

Le terme « bug »

Naturellement, nous devrions commencer par considérer le terme lui-même, son étymologie et sa signification. Qu'est-ce qu'un bug ? Pourquoi s'appelle-t-on ainsi ? Cette histoire est assez intéressante, car ce terme vient du mot anglais bug, qui se traduit par « scarabée ». Mais cela signifie une erreur : comment les insectes et les problèmes du code informatique se combinent-ils ? Naturellement, il n'y a pas de lien direct - il est apparu il y a longtemps parmi les programmeurs et était fermement ancré dans des erreurs qui ont réussi à se faufiler dans le code même avec une vérification complète. Ainsi, des bugs s'insinuent dans la version finale du code et ne sont détectés qu'après le lancement du programme lui-même. Il existe encore de nombreuses informations utiles concernant ce terme, mais maintenant vous savez au moins ce qu'est un bug. Poursuivre!

Classification

Naturellement, une fois que les gens ont appris ce qu’est un bug, ils veulent comprendre ce que pourraient être de telles erreurs. Il existe une classification complète qui comprend une grande variété d'options. Les bogues peuvent varier selon le lieu et le moment de leur apparition, leur taille, la nature de l'erreur, etc. Le plus souvent, ils se distinguent par leur gravité et leur taille - les caractéristiques les plus importantes qui vous permettent de comprendre combien de temps il faudra pour corriger l'erreur et quels dommages elle peut causer ou a déjà causés. Malheureusement, des bugs peuvent survenir non seulement dans les jeux informatiques, où ils gâchent simplement l'expérience des utilisateurs. Ils peuvent également se produire dans des logiciels très sérieux : une erreur qui s'est glissée dans le code du pilote automatique d'un avion peut même conduire à son crash. Par conséquent, vous ne devriez pas réfléchir à la manière de créer un bug - il est préférable de réfléchir à la manière de le corriger.

Correction des erreurs

Le processus de développement de programmes, y compris de jeux informatiques, ne se résume pas à la simple écriture de code. La signification du mot « bug » laisse entendre que cette erreur a réussi à traverser plus d’une couche de protection. Alors, qu’est-ce qui vous permet d’attraper 99 % de tous les bugs ? La réponse est simple : c’est la phase de test. Une fois le code du programme écrit, il est envoyé à des testeurs professionnels spéciaux qui l'exécutent et vérifient les erreurs. Le rôle du testeur n'est pas moins important que celui du programmeur, et si un bug apparaît dans la version finale du produit, le blâme incombera également à la fois à la personne qui a commis cette erreur et à celle qui ne l'a pas fait. remarquez-le pendant les tests. Heureusement, 99 % des bugs sont filtrés lors de ce processus de vérification. Mais que se passe-t-il si l’un d’eux parvient à s’échapper ?

Bogues dans les versions

99 %, c'est beaucoup, mais 1 % est également significatif, surtout lorsqu'il s'agit d'erreurs. Et s’ils aboutissent dans un produit commercialisé et qui tombe entre les mains du client, l’entreprise manufacturière doit alors en assumer la responsabilité. Le plus souvent, le problème est résolu très rapidement : dès que les joueurs expriment leur mécontentement, les spécialistes s'occupent immédiatement du problème. Et après un certain temps, un patch sort (du patch anglais - "patch"), après l'installation duquel le problème est résolu automatiquement.

Rapports de bogues

Dans les jeux informatiques, les erreurs ne peuvent être remarquées que par le joueur lui-même, car aucun programme ne peut les détecter. Cependant, dans d'autres cas, il existe un logiciel spécial qui vous permet de suivre automatiquement les bogues dans les programmes, de créer un rapport détaillé que le programmeur peut comprendre et de l'envoyer au développeur. C'est incroyablement pratique et utile car vous pouvez immédiatement savoir où se trouvent exactement les erreurs dans votre logiciel et permettre également aux développeurs de les corriger le plus rapidement possible. En faisant cela, vous les aiderez, vous-même, ainsi que de nombreux autres utilisateurs qui ont acheté ce programme. Il va sans dire que cette approche ne fonctionne qu'avec des logiciels sous licence - les logiciels piratés n'ont tout simplement aucun lien avec le développeur, car ils n'ont pas été achetés et, par conséquent, ne sont pas soumis aux obligations de garantie du vendeur envers l'acheteur.

Malheureusement, ces programmes ne peuvent pas éliminer des erreurs spécifiques telles que, par exemple, le bug de VKontakte - comme dans les jeux, vous devrez les détecter manuellement, puis les signaler personnellement au support technique de ce site ou de toute autre page sur laquelle vous trouvé un bug.

Comment trouver un bug dans le code

Combien de fois passez-vous des heures à essayer de comprendre pourquoi cette navigation nuisible a glissé, et cette image s'affiche et déforme tout le texte d'une manière incroyable ? Cette méthode permet de trouver la cause presque sans réfléchir en 5 minutes. Presque tout le monde a probablement utilisé cette méthode pour trouver des bugs dans la mise en page.

Pour quoi

Beaucoup de temps dans la mise en page est consacré à la résolution des bugs et à la recherche de leurs causes. Si vous pensez que vous pouvez passer plus de 20 minutes à rechercher la cause, il est préférable d'utiliser cette méthode en toute sécurité ; cela prend rarement plus de 5 à 10 minutes. Cependant, cela prend rarement moins de 5 minutes. Et c'est son seul inconvénient.

Quand

Quand « la colonne a glissé », ou « ce vilain menu ne s’affiche à nouveau pas comme il le devrait ». Ou des milliers d’autres problèmes que vous observez et que vous ne pouvez pas comprendre ce qui fait que le site s’affiche comme il le fait. Et quelle ligne du code fait cela.

Idée

La méthode est parfois appelée méthode de dichotomie, le problème classique de la capture d'un lion dans le désert est également connu, et parfois elle est également appelée méthode de Newton.

Le principe est très simple pour retrouver par exemple un point sur un segment :

1. Divisez le segment en deux, déterminez quelle moitié contient notre point
2. Nous répétons la procédure pour la moitié résultante du segment avec un point

Et ainsi de suite jusqu'à obtenir la précision requise.

Et voici à quoi cela ressemble dans un problème concernant la capture d'un lion dans le désert :

Nous divisons le désert en deux avec une clôture. Ensuite, la partie dans laquelle le lion est resté est à nouveau divisée au milieu, et ainsi de suite - jusqu'à ce que le lion soit dans un enclos étroit.

L'algorithme appliqué à la mise en page diffère peu des classiques. Le lion sera un morceau de code qui fera un bug. Désert - tout le code.

>Superdupermégaalgorithme

1. Supprimer la moitié ou juste une grande partie du code HTML (CSS)
   • Si le problème reste visible, continuez la procédure pour le code restant
   • Si le problème a disparu, renvoyez le code supprimé et répétez la procédure correspondante (en supprimant l'autre moitié)

En conséquence, seul le HTML « glitch » restera, généralement quelques blocs associés au glitch.
Le même répétez pour le code CSS. Si en HTML il était encore nécessaire de respecter la hiérarchie, alors en CSS, vous pouvez supprimer en toute sécurité la moitié du code.

De cette façon, à la fin, il vous restera quelques lignes de CSS et uniquement les blocs HTML qui constituent le problème. Avec autant de code, il sera difficile de ne pas trouver un bug ou une faute de frappe.

Parfois, il est plus facile de commencer avec CSS, mais l'essence reste la même. Nous supprimons le code jusqu'à ce que nous trouvions l'endroit qui provoque le bug.

En même temps, il vaut mieux demander de l'aide sur les forums avec juste cette page « nettoyée », sans un tas de code supplémentaire que tout le monde a la flemme de comprendre.

En conséquence, nous déterminons avec précision la ligne de code ou le morceau de HTML qui est à l’origine du bug, et cela représente déjà la moitié de la bataille.

À la fin

C’est même étrange pourquoi si peu a été écrit sur cette méthode (peut-être parce qu’elle est trop simple ?). J'espère que cela aidera quelqu'un, cela m'a aidé plus d'une ou deux fois. De plus, de telles actions aident les webmasters débutants à mieux comprendre et ressentir le fonctionnement de ce CSS. =) Et lorsque vous recherchez un problème dans le code de quelqu'un d'autre, c'est pratiquement le seul moyen.

Maîtrisez-vous déjà les techniques de base de conception de tests ? Super! Cela signifie que vous êtes un testeur qualifié.

Comment apprendre à trouver des bugs que les autres testeurs ne trouvent pas, même s’ils connaissent les mêmes techniques ?

La maîtrise des techniques n'est que la première étape sur le chemin de la maîtrise. Comme la notation musicale et les gammes pour un musicien. Comme la capacité de tenir une raquette et de frapper des revers et des coups droits pour un joueur de tennis. Comme la connaissance des ouvertures et des fins de partie pour un joueur d'échecs.

Bien sûr, il faut connaître les techniques. Mais pour les utiliser de manière significative, et encore plus créative, il faut autre chose :

Des compétences professionnelles supplémentaires sont nécessaires.

Cette formation vise à développer des compétences particulières chez le testeur :

• observation,
• capacité à poser des questions,
• "lire entre les lignes"
• Rechercher une information,
• "réflexion"
• la modélisation,
• établir des relations de cause à effet,
• comparaison et identification des différences,
• la concentration et la défocalisation,
• réflexion latérale et recadrage,
• « double pensée » professionnelle.

Lisez attentivement les articles et les manuels sur les techniques de conception de tests. Ils sont corrects et ils fonctionnent. Mais il leur manque quelque chose d'insaisissable...

D’où viennent les bugs manqués que le testeur « n’a pas remarqué » ? Pourquoi n'as-tu pas remarqué ? Ce n'est pas la faute du technicien. Ils ne disent rien sur la manière dont le résultat doit être vérifié. Je n'étais tout simplement pas assez observateur.

Pourquoi des bugs se retrouvent-ils dans le produit pour lequel le testeur « n’a pas proposé » de test approprié ? Ce n'est pas la faute du technicien. Le modèle a simplement été mal choisi ou la technique a été utilisée au mauvais endroit ou de la mauvaise manière.

Dans les descriptions des techniques, une grande attention est accordée à la manière d'analyser les données d'entrée, à la manière de créer des combinaisons et aux séquences à exécuter.

Mais l'essentiel n'y est pas écrit : comment comprendre que vous avez trouvé un bug ? Comment le reconnaître ? Comment savoir si un programme fonctionne correctement ou incorrectement ? En langage « professionnel », le thème des oracles n’a pas été abordé.

Enfin, comment savoir si vous utilisez correctement ou incorrectement une technique particulière ? Le sujet de l’évaluation de l’exhaustivité de la couverture n’est pas non plus abordé.

Dans cette formation nous apprendrons :

• analyser systématiquement la documentation, tracer le chemin depuis la spécification jusqu'aux tests puis jusqu'aux bugs,
• voir non seulement ce qui est évident, afin de remarquer des bugs non évidents,
• déplacer l'attention d'un aspect à un autre afin de détecter les bugs « d'intégration »,
• déterminer ce qui est un bug et ce qui ne l'est pas,
• prouver que le bug est vraiment un bug,
• poser les bonnes questions au client, au manager, à l'analyste et même au programmeur,
• proposer des tests sans utiliser de techniques n'est pas pire qu'avec des techniques,
• construire différents modèles - mentaux, formels, conceptuels.

De plus, nous maîtriserons le travail professionnel avec des bugs déjà découverts :

• comment décrire correctement les bugs,
• comment surveiller le sort du bug décrit,
• comment revérifier les bugs soi-disant corrigés,
• comment ne pas se fatiguer lors des tests de régression et des revérifications,

En plus des bugs détectés, vous devez également être capable de travailler avec des bugs non détectés (oui, cela arrivera quoi qu'il arrive). Nous apprendrons donc :

• calculer la couverture des tests et évaluer l'exhaustivité des tests,
• enregistrer les résultats des travaux,
• rédiger de bons rapports de tests,
• expliquez pourquoi nous avons raté ce bug...

Des jeux, des exercices, des compétitions et bien sûr de vrais tests, tout cela sera dans le programme d'entraînement.

Après cela, vous retournerez sur votre lieu de travail « magnétisé » et « chargé » pour rechercher des bugs. Et ils le ressentiront, sans aucun doute :)

Programme de formation

Le premier jour

1. Préparation des infrastructures, introduction – 30 minutes

2. Test du programme (exercice et analyse), discussion sur le thème « Qu'est-ce qui est le plus important : les techniques ou les compétences ? – 60+15 minutes

3. Tester un nouveau programme, l’art de poser des questions (exercice et analyse) – 60 minutes

4. Que faire lorsque vous trouvez un bug ? Mondialisation et localisation (démonstration et discussion) – 45 minutes

5. L’art de décrire les bugs (exercice et analyse) – 60 minutes

6. Tests de régression et revérification des bogues : comment et pourquoi exécuter les mêmes tests plusieurs fois ? - 45 minutes

7. Modélisation : capacité à regarder un programme sous différents angles (exercice et analyse) – 45 minutes

8. Test d’utilisabilité : mettez des personnages dans votre tête (exercice) – 30 minutes

Deuxième jour

1. Stratégie de test (discussion) – 45 minutes

2. Comparaison de deux programmes : lequel est le meilleur ? (exercice et discussion) – 60 minutes

3. HICCUPPSF : heuristiques pour construire des oracles (démonstration, exercice et analyse) – 15+60 minutes

4. Création de tests pour des fonctionnalités complexes (exercice et analyse) – 60 minutes

5. Cas de test, listes de contrôle, tests de recherche gratuits : dans quelle proportion doivent-ils être mélangés ? (discussion) – 30 minutes

6. Tests utilisant la méthode de recherche gratuite (exercice et analyse) – 60 minutes

7. Tests de régression et revérification des bogues : comment et pourquoi exécuter les mêmes tests plusieurs fois ? (discussion) – 30 minutes

8. Automatisation des tests (démonstration et discussion) – 45 minutes

9. Achèvement du cours, résumé – 30 minutes

Cette formation, en consultation avec Michael Bolton, utilise des techniques et des exercices de la formation de renommée mondiale Rapid Software Testing. Pour préparer l'entraînement, l'entraîneur Alexey Barantsev a mené à trois reprises des entraînements communs avec Michael en tant qu'assistant et deuxième entraîneur.