Pourquoi les programmeurs ont-ils besoin de tests ?
Les prochains niveaux seront consacrés aux tests de la manière dont les programmeurs en ont besoin . Mais d'abord, découvrons ce qu'est le test et pourquoi il est nécessaire.
En ce qui concerne les logiciels, on peut dire que la tâche des tests consiste à vérifier que le programme :
- fait ce qu'elle a à faire
- ne fait pas ce qu'elle ne devrait pas faire
Soit dit en passant, le deuxième point n'est pas moins important que le premier, mais nous y reviendrons plus tard.
Commençons par le premier point. Que signifie "le programme fait ce qu'il est censé faire" ?
Tout d'abord, quelqu'un doit faire une liste de tous les cas d'utilisation du programme. Deuxièmement, ils doivent décrire comment le programme doit fonctionner, comment l'utilisateur doit se comporter et quels résultats sont attendus. Vous ne pouvez pas continuer plus loin.
Dès que nous avons écrit "comment l'utilisateur doit se comporter", toute l'idée d'écrire une bonne documentation s'est effondrée. Les gens ne sont pas des machines, d'ailleurs, les gens se comportent très souvent avec les logiciels comme bon leur semble . Personne ne commence sa connaissance de la technologie en étudiant les instructions. C'est un fait.
Par conséquent, nous obtenons un fait nouveau : la particularité du logiciel est qu'il a beaucoup de scénarios de travail différents. Certains d'entre eux sont évidents, d'autres peuvent être documentés, d'autres peuvent être supposés, d'autres peuvent être devinés, et les 50% restants ne vous viendront même pas à l'esprit.
Du point de vue d'un programmeur, la plupart des bogues ne sont pas du tout des bogues. Une erreur se produit lorsqu'un programme ne fonctionne pas comme il le devrait ou comme prévu. Et il y a beaucoup de situations où il n'est pas clair comment le programme devrait fonctionner, ou des scénarios qui se contredisent ...
Il existe un nombre infini de scénarios, et il y aura toujours des cas dans le produit où le programme ne se comporte pas comme prévu (le programmeur a écrit le code pour seulement quelques dizaines de scénarios). Par conséquent, on peut affirmer qu'il y a toujours des bogues dans n'importe quel programme et que n'importe quel produit peut être amélioré à l'infini .
Après cela, tout se résume à l'opportunisme. D'abord, le programmeur corrige les plus gros bogues, puis les petits bogues, et ainsi de suite. Et enfin, il arrive un stade où le propriétaire du produit estime qu'il n'est pas économiquement faisable de continuer à travailler dessus.
Mais revenons aux erreurs que tout le monde reconnaît comme des erreurs : le programme fait évidemment quelque chose de mal, est tombé, a cassé quelque chose, etc. De telles erreurs peuvent être conditionnellement divisées en 3 catégories : grandes, moyennes et petites.
Et très souvent, il arrive qu'un programmeur travaille sur la correction de bogues moyens ou même petits, bien qu'il y ait encore beaucoup de problèmes plus graves dans le projet. Il ne les a tout simplement pas trouvés , alors il travaille sur les plus gros qu'il connaisse.
Par conséquent, dans tout projet, il devrait y avoir des testeurs. Ces personnes apprennent spécifiquement à regarder le produit sous différents angles. Ainsi, vous pouvez voir plus de scénarios du programme. Leur tâche est de trouver les erreurs et de les noter (pour ne pas retrouver plusieurs fois la même erreur).
Le test est un processus visant à trouver des erreurs. Ces bogues doivent être trouvés, décrits et classés par ordre de priorité. Ce n'est qu'après la hiérarchisation des erreurs que l'on peut parler d'un processus efficace d'amélioration du logiciel.
N'oubliez pas que la première étape pour résoudre un problème est de reconnaître qu'il y a un problème . Vous ne pouvez pas corriger une erreur dont vous n'êtes pas au courant.
Automatisation des tests
Je pense que nous avons tous convenu que les tests sont importants, alors regardons les tests comme les programmeurs. Comment les programmeurs voient-ils les tests ? Les programmeurs automatisent le travail d'autres personnes. Le dernier métier à disparaître sera celui de la programmation.
Nous automatisons tous les processus que nous rencontrons. Les tests doivent donc être automatisés. Et comment automatiser la recherche d'erreurs ? Réponse courte : non. Mais là encore le fait que nous soyons programmeurs vient à notre aide.
Le processus de développement logiciel consiste en des changements constants. juste en train de faire constamment des changements, les programmeurs cassent très souvent quelque chose qui fonctionnait bien jusqu'à récemment.
Et les testeurs, au lieu de chercher de nouvelles erreurs, sont obligés de vérifier constamment si nous avons cassé quelque chose qui fonctionnait bien depuis longtemps. Les soi-disant tests de régression. C'est ce type de test qui peut et doit être automatisé.
Ici, tous les logiciels peuvent être divisés en deux parties :
- le programme interagit avec la personne
- programme interagit avec un autre programme
La première option est plus difficile à automatiser, elle nécessite des automates testeurs particuliers, on les appelle aussi QA Automation ou Software Test Engineer.
Mais la deuxième option peut et doit être automatisée indépendamment. Si vous avez un logiciel qui :
- fonctionne bien
- déjà testé
- implémenté en tant que module ou bloc logique séparé
- ne prévoit pas de changer
- d'autres modules ou programmes en dépendent
- l'échec fonctionnel coûte cher
Je recommande de prendre le temps d'écrire des tests qui capturent les aspects clés de sa fonctionnalité actuelle. Il serait raisonnable d'allouer 5% de votre temps de travail à cela , soit 1 jour par mois.
Pas besoin d'écrire des tests pour des tests.
Personne ne soutiendra vos tests. Pas d'autres programmeurs, pas vous-même. Personne ne fait ça. 99% de tous les tests écrits sont abandonnés et/ou désactivés. Si vous ne pouvez pas écrire de tests, n'écrivez pas. N'écrivez que si vous ne pouvez absolument pas vous en passer.
Types de tests
Chaque programmeur, s'il n'a pas suivi de formation spéciale, pourra dire avec ses propres mots ce qu'est un test : vérifier si le programme fait ce qu'il doit faire. Cependant, les professionnels de ce domaine distinguent des domaines entiers (types) de tests.
Tous les tests tournent vraiment autour de la fiabilité et de la disponibilité des logiciels, mais pour mieux comprendre la direction des tests, regardons quelques exemples.
Disons que vous testez une boutique en ligne typique. Ensuite, les domaines de test peuvent être divisés en types suivants : tests de performance, tests fonctionnels, tests d'intégration et tests unitaires.
Si le propriétaire du site décide de lancer une campagne publicitaire sérieuse, de nombreux utilisateurs viendront sur le site en même temps. Il se peut bien que le site ne tombe pas, mais certaines de ses sections peuvent être lentes ou même cesser de fonctionner.
Afin d'éviter que cela ne se produise, vous devez identifier ces problèmes à l'avance et prendre des mesures pour les éliminer. Cela se fait à l'aide de tests de charge , ou est également appelé test de performances.
Vous pouvez également tester le fonctionnement de votre API backend et tester toutes ses fonctions : enregistrement, connexion, ajout au panier, traitement des paiements, écritures dans la base de données, etc. Tout devrait fonctionner conformément aux termes de référence. Dans ce cas, vous devez effectuer des tests fonctionnels .
Votre boutique en ligne est très probablement intégrée à des services tiers : envoi de lettres et de SMS, systèmes de paiement, chats d'assistance en ligne, collecte de commentaires des utilisateurs, systèmes de publicité, etc. Pour vous assurer que tout cela fonctionne comme prévu, vous devez effectuer des tests d'intégration . .
Enfin, les produits complexes sont souvent décomposés en modules indépendants. A partir de tels modules, vous pouvez assembler le produit final, comme à partir d'un constructeur. Si vous développez un tel module ou interagissez avec de tels modules, vous devrez alors effectuer des tests unitaires .
En résumé, nous pouvons dire que des tests fonctionnels sont nécessaires pour tester chaque fonction individuelle du site. Intégration - pour tester l'interaction de grands modules et systèmes de votre produit. Modulaire - pour tester un module séparé, eh bien, des tests de performance - pour vérifier le fonctionnement de votre site sous charge.
Il peut y avoir encore plus de types de tests : plus le produit est complexe, plus les aspects de son développement doivent être contrôlés.