Qu’est-ce que le test logiciel ? 100+ Tutoriels de test manuel gratuits

Un guide complet du test logiciel avec 100+ tutoriels de test manuel avec définition du test, types, méthodes et détails du processus:

Qu’est-ce que le test logiciel ?

Le test logiciel est un processus de vérification et de validation de la fonctionnalité d’une application pour trouver si elle satisfait aux exigences spécifiées. C’est le processus de trouver des défauts dans une application et de vérifier où l’application fonctionne selon les exigences de l’utilisateur final.

Qu’est-ce que le test manuel ?

Le test manuel est un processus dans lequel vous comparez le comportement d’un morceau de code développé (logiciel, module, API, fonctionnalité, etc.) par rapport au comportement attendu (exigences).

Liste de tutoriels sur les tests logiciels manuels

C’est la série de tutoriels la plus approfondie sur les tests logiciels. Parcourez attentivement les sujets mentionnés dans cette série pour apprendre les techniques de test de base et avancées.

Cette série de tutoriels enrichirait vos connaissances et améliorerait, à son tour, vos compétences en matière de test.

Pratiquez le test manuel de bout en bout Formation gratuite sur un projet en direct:

Tutoriel #1 : Les bases du test logiciel manuel
Tutoriel #2 : Introduction du projet en direct
Tutoriel #3 : Rédaction du scénario de test
Tutoriel #4 : Rédiger un document de plan de test à partir de zéro
Tutoriel #5 : Rédiger des cas de test à partir du document SRS
Tutoriel #6 : Exécution des tests
Tutoriel n°7 : Suivi des bogues et signature des tests
Tutoriel n°8 : Cours sur les tests logiciels

Cycle de vie des tests logiciels :

Tutoriel n°1 : STLC

Tests Web :

Tutoriel n°1 : Test d’application Web
Tutoriel n°2 : Test multi-navigateur

Gestion des cas de test :

Tutoriel n°1 : Cas de test
Tutoriel n°2 : Exemple de modèle de cas de test
Tutoriel n°3 : Matrice de traçabilité des exigences (RTM)
Tutoriel n°4 : Couverture des tests
Tutoriel n°5 : Gestion des données de test

Gestion des tests :

Tutoriel n°1 : Stratégie de test
Tutoriel n°2 : Modèle de plan de test
Tutoriel n°3 : Estimation des tests
Tutoriel n°4 : Outils de gestion des tests
Tutoriel n°5 : Tutoriel HP ALM
Tutoriel n°6 : Jira
Tutoriel #7 : Tutoriel TestLink

Techniques de test:

Tutoriel #1 : Test de cas d’utilisation
Tutoriel #2 : Test de transition d’état
Tutoriel #3 : Analyse de valeur limite
Tutoriel #4 : Partitionnement d’équivalence
Tutoriel #5 : Méthodologies de test logiciel
Tutoriel #6 : Méthodologie agile

Gestion des défauts :

Tutoriel n°1 : Cycle de vie des bogues
Tutoriel n°2 : Signalement des bogues
Tutoriel n°3 : Priorité des défauts
Tutoriel n°4 : Tutoriel Bugzilla

Tests fonctionnels

Tutoriel n°1 : Test unitaire
Tutoriel n°2 : Sanity et Smoke Testing
Tutoriel n°3 : Test de régression
Tutoriel n°4 : Test système
Tutoriel n°5 : Tests d’acceptation
Tutoriel #6 : Tests d’intégration
Tutoriel #7 : Tests d’acceptation de l’utilisateur UAT

Tests non fonctionnels:

Tutoriel #1 : Tests non fonctionnels
Tutoriel #2 : Tests de performance
Tutoriel #3 : Tests de sécurité
Tutoriel #4 : Tests de sécurité des applications Web
Tutoriel #5 : Tests d’utilisabilité
Tutoriel #6 : Test de compatibilité
Tutoriel #7 : Test d’installation
Tutoriel #8 : Test de documentation

Tests de logiciels:

Tutoriel #1 : Types de tests
Tutoriel #2 : Test de la boîte noire
Tutoriel #3 : Test des bases de données
Tutoriel #4 : Test de bout en bout
Tutoriel #5 : Test exploratoire
Tutoriel #6 : Test incrémental
Tutoriel #7 : Test d’accessibilité
Tutoriel #8 : Test négatif
Tutoriel #9 : Test backend
Tutoriel #10 : Test alpha
Tutoriel #11 : Test bêta
Tutoriel #12 : Test alpha vs bêta
Tutoriel #13 : Test gamma
Tutoriel #14 : Test ERP
Tutoriel #15 : Test statique et dynamique
Tutoriel #16 : Test adhoc
Tutoriel #17 : Tests de localisation et d’internationalisation
Tutoriel n°18 : Tests d’automatisation
Tutoriel n°19 : Test boîte blanche

Carrière en test logiciel:

Tutoriel n°1 : Choisir une carrière en test logiciel
Tutoriel n°2 : Comment obtenir un emploi en test d’assurance qualité – Guide complet
Tutoriel n°3 : Options de carrière pour les testeurs
Tutoriel n°4 : Passage du non-IT au test logiciel
Tutoriel #5 : Démarrer votre carrière de test manuel
Tutoriel #6 : Leçons tirées de 10 ans de test
Tutoriel #7 : Survivre et progresser dans le domaine du test

Préparation à l’entretien:

Tutoriel #1 : Préparation du CV d’AQ
Tutoriel #2 : Questions d’entretien de test manuel
Tutoriel #3 : Questions d’entretien de test d’automatisation
Tutoriel #4 : Questions d’entretien d’AQ
Tutoriel #5 : Traiter tout entretien d’emploi
Tutoriel #6 : Obtenir un emploi de test en tant que jeune diplômé

Tester une application de domaine différent :

Tutoriel n°1 : Test d’application bancaire
Tutoriel n°2 : Test d’application de soins de santé
Tutoriel n°3 : Test de passerelle de paiement
Tutoriel n°4 : Test de système de point de vente (POS)
Tutoriel n°5 : Test de site web de commerce électronique

Test de certification QA :

Tutoriel n°1 : Guide de certification des tests logiciels
Tutoriel n°2 : Guide de certification CSTE
Tutoriel n°3 : Guide de certification CSQA
Tutoriel n°4 : Guide ISTQB
Tutoriel n°5 : ISTQB avancé

Sujets de tests manuels avancés :

Tutoriel n°1 : Complexité cyclomatique
Tutoriel #2 : Test de migration
Tutoriel #3 : Test du cloud
Tutoriel #4 : Test ETL
Tutoriel #5 : Métriques de test logiciel
Tutoriel #6 : Services Web

Préparez-vous à jeter un œil au 1er tutoriel de cette série de tests manuels !!!

Introduction aux tests logiciels manuels

Les tests manuels sont un processus dans lequel vous comparez le comportement d’un morceau de code développé (logiciel, module, API, fonctionnalité, etc.) au comportement attendu (exigences).

Et comment saurez-vous quel est le comportement attendu ?

Vous le saurez en lisant ou en écoutant attentivement les exigences et en les comprenant complètement. Rappelez-vous, comprendre complètement les exigences est très très important.

Pensez que vous êtes un utilisateur final de ce que vous allez tester. Après cela, vous n’êtes plus lié, au document d’exigence du logiciel ou aux mots qu’il contient. Vous pouvez alors comprendre l’exigence de base et non seulement vérifier le comportement du système par rapport à ce qui est écrit ou dit, mais aussi par rapport à votre propre compréhension et par rapport à des choses qui ne sont pas écrites ou dites.

Parfois, il peut s’agir d’une exigence manquée (exigence incomplète) ou d’une exigence implicite (quelque chose qui n’a pas besoin d’être mentionné séparément mais qui devrait être satisfait), et vous devez tester pour cela aussi.

En outre, une exigence ne doit pas nécessairement être documentée. Vous pouvez très bien avoir une connaissance de la fonctionnalité du logiciel ou vous pouvez même deviner et ensuite tester une étape à la fois. Nous l’appelons généralement test ad hoc ou test exploratoire.

Regardons les choses en profondeur :

D’abord, comprenons le fait – Que vous compariez le test d’une application logicielle ou d’autre chose (disons un véhicule), le concept reste le même. L’approche, les outils et les priorités peuvent différer, mais l’objectif de base reste le MEME et il est SIMPLE c’est-à-dire comparer le comportement réel avec le comportement attendu.

Deuxièmement – Le test est comme une attitude ou un état d’esprit qui devrait venir de l’intérieur. Les compétences peuvent être apprises, mais vous ne deviendrez un testeur réussi que si vous avez quelques qualités en vous par défaut. Quand je dis que les compétences de test peuvent être apprises, je veux dire une éducation ciblée et formelle autour du processus de test logiciel.

Mais quelles sont les qualités d’un testeur réussi ? Vous pouvez les lire sur le lien ci-dessous :

Lisez-le ici =>Qualités des testeurs hautement efficaces

Je recommande vivement de parcourir l’article ci-dessus avant de poursuivre ce tutoriel. Il vous aidera à comparer vos caractéristiques à celles qui sont attendues dans le rôle du testeur de logiciels.

Pour ceux qui n’ont pas le temps de parcourir l’article, voici un synopsis:

« Votre curiosité, votre attention, votre discipline, votre pensée logique, votre passion pour le travail et votre capacité à disséquer les choses comptent beaucoup pour être un testeur destructeur et réussi. Cela a fonctionné pour moi et je crois fermement que cela fonctionnera pour vous aussi. Si vous avez déjà ces qualités, alors en effet cela doit fonctionner pour vous aussi. »

Nous avons parlé des prérequis de base pour devenir un testeur de logiciels. Maintenant, comprenons pourquoi le test manuel a et aurait toujours son existence indépendante avec ou sans la croissance du test d’automatisation.

Pourquoi le test manuel est nécessaire ?

Savez-vous quelle est la meilleure chose d’être un testeur, qui plus est un testeur manuel ?

C’est le fait que vous ne pouvez pas dépendre uniquement des compétences ici. Vous devez avoir/développer et améliorer votre processus de pensée. C’est quelque chose que vous ne pouvez pas vraiment acheter pour quelques dollars. Vous devez vous-même y travailler.

Vous devrez développer l’habitude de poser des questions et vous devrez les poser à chaque minute lorsque vous faites des tests. La plupart du temps, vous devriez poser ces questions à vous-même plutôt qu’aux autres.

J’espère que vous avez parcouru l’article que j’ai recommandé dans la section précédente (c’est-à-dire les qualités des testeurs très efficaces). Si oui, alors vous sauriez que le test est considéré comme un processus de pensée et la façon dont vous réussirez en tant que testeur dépend complètement des qualités que vous possédez en tant que personne.

Voyons ce flux simple :

• Vous faites quelque chose (effectuez des actions) pendant que vous l’observez avec une certaine intention (comparaison avec ce qui est attendu). Maintenant, vos compétences d’observation et votre discipline pour effectuer des choses entrent en jeu ici.
• Voila ! Qu’est-ce que c’était ? Vous avez remarqué quelque chose. Vous l’avez remarqué parce que vous accordiez une attention parfaite aux détails qui se trouvaient devant vous. Tu ne veux pas le laisser passer parce que tu es curieux. Il n’était pas prévu que quelque chose d’inattendu/étrange se produise, que vous le remarquiez et que vous l’examiniez de plus près. Mais maintenant, vous le faites. Vous pouvez laisser tomber. Mais vous ne devriez pas laisser tomber.
• Vous êtes heureux, vous avez trouvé la cause, les étapes et le scénario. Maintenant, vous allez communiquer cela correctement et de manière constructive à l’équipe de développement et aux autres parties prenantes de votre équipe. Vous pouvez le faire via un outil de suivi des défauts ou verbalement, mais vous devez vous assurer que vous le communiquez de manière constructive.
• Oops ! Et si je le fais de cette façon ? Et si j’entrais un nombre entier correct en entrée mais avec des espaces blancs en tête ? Et si ? … Et si ? … Et si ? Cela ne se termine pas facilement, cela ne devrait pas se terminer facilement. Vous allez imaginer beaucoup de situations &scénarios et en effet vous serez tenté de les réaliser aussi.

Le schéma donné ci-dessous représente la vie d’un testeur :

Lisez à nouveau ces quatre points mentionnés ci-dessus. Avez-vous remarqué que je les ai gardés très courts tout en soulignant la partie la plus riche du métier de testeur manuel ? Et avez-vous remarqué le surlignage en gras de quelques mots ? Ce sont précisément les qualités les plus importantes dont un testeur manuel a besoin.

Maintenant, pensez-vous vraiment que ces actes peuvent être complètement remplacés par autre chose ? Et la tendance chaude d’aujourd’hui – peut-elle jamais être remplacée par l’automatisation ?

Dans le SDLC avec n’importe quelle méthodologie de développement, peu de choses restent toujours constantes. En tant que testeur, vous allez consommer les exigences, les convertir en scénarios de test / cas de test. Vous allez ensuite exécuter ces cas de test ou directement les automatiser (je sais que quelques entreprises le font).

Lorsque vous l’automatisez, votre focus est stable, c’est-à-dire l’automatisation des étapes écrites.

Revenons à la partie formelle c’est-à-dire l’exécution des cas de test écrits manuellement.

Ici, vous ne vous concentrez pas seulement sur l’exécution des cas de test écrits, mais vous effectuez également beaucoup de tests exploratoires tout en le faisant. Vous vous souvenez que vous êtes curieux ? Et vous allez imaginer. Et vous ne pourrez pas résister, vous ferez effectivement ce que vous avez imaginé.

L’image donnée ci-dessous décrit comment l’écriture des cas de test est simplifiée:

Je suis en train de remplir un formulaire, et j’ai fini de remplir le premier champ. Je suis trop paresseux pour aller chercher la souris pour déplacer le focus sur le champ suivant. J’appuie sur la touche « tabulation ». J’ai fini de remplir le champ suivant et le dernier aussi, maintenant je dois cliquer sur le bouton ‘Submit’, le focus est toujours sur le dernier champ.

Oops, j’ai accidentellement appuyé sur la touche ‘entrée’. Laissez-moi vérifier ce qui s’est passé. OU il y a un bouton de soumission, je vais doublement cliquer dessus. Pas satisfait. Je clique dessus plusieurs fois, trop rapidement.

Avez-vous remarqué ? Il y a tellement d’actions possibles de l’utilisateur, qu’elles soient intentionnelles ou non.

Vous ne réussirez pas à écrire tous les cas de test qui couvrent à 100% votre application à tester. Cela doit se faire de manière exploratoire.

Vous allez continuer à ajouter vos nouveaux cas de test au fur et à mesure que vous testez l’application. Ce seront des cas de test pour les bogues que vous avez rencontrés et pour lesquels il n’y avait pas de cas de test écrit auparavant. Ou, pendant que vous testez, quelque chose a déclenché votre processus de pensée et vous avez quelques cas de test supplémentaires que vous aimerez ajouter à votre suite de cas de test et exécuter.

Même après tout cela, il n’y a aucune garantie qu’il n’y a pas de bugs cachés. Un logiciel avec zéro bogue est un mythe. Vous pouvez seulement viser à l’amener près de Zéro, mais cela ne peut tout simplement pas se produire sans un esprit humain ciblant continuellement la même chose, similaire mais non limité au processus d’exemple que nous avons vu ci-dessus.

Au moins à ce jour, il n’y a pas de logiciel qui pensera comme un esprit humain, observera comme un œil humain, posera des questions et répondra comme un humain, puis exécutera des actions intentionnelles et non intentionnelles. Même si une telle chose se produisait, quel esprit, quelles pensées et quels yeux imiteraient-ils ? Les vôtres ou les miens ? Nous, les humains, ne sommes pas non plus les mêmes. Nous sommes tous différents. Alors ?

Nécessité du test manuel quand l’automatisation est autour:

Le test d’automatisation a sa propre part de gloire ces jours-ci et aura encore plus dans les années à venir, mais, il ne peut tout simplement pas remplacer le test d’assurance qualité manuel (lire test humain/exploratoire).

Vous devez avoir entendu avant- ‘Vous n’automatisez pas le test, vous automatisez la vérification’. Cette phrase en dit long sur la position des tests d’assurance qualité manuels par rapport aux tests d’automatisation. Beaucoup de grands noms à travers le monde ont écrit et parlé de ce sujet, donc je ne vais pas insister beaucoup sur ce sujet.

L’automatisation ne peut pas remplacer le test humain parce que:

• Il exige les jugements d’exécution sur tout ce qui se passe devant vos yeux (pendant que vous testez) et dans quelques cas derrière les scènes aussi.
• Il exige une observation claire et constante.
• Il exige un questionnement.
• Il exige une investigation.
• Il exige un raisonnement.
• Il exige des actions non planifiées selon les besoins pendant le test.

Le test peut être remplacé par un outil/machine qui sera capable d’absorber les détails, de les traiter, de commander des actions et de les exécuter comme un esprit humain et un humain, et tout cela au moment de l’exécution et dans tous les contextes possibles. Cet outil doit à nouveau être comme tous les humains possibles.

Donc, en résumé, les tests humains ne peuvent pas être remplacés. Peut-être qu’un film de science-fiction hollywoodien dans quelques années s’en rapprochera, mais dans la vraie vie, je ne le vois pas venir avant quelques centaines d’années, que je puisse imaginer. Je ne l’écrirai pas pour toujours car je crois aux possibilités infinies.

Dans un autre ordre d’idées, même si cela arrive vraiment après quelques centaines d’années, l’image que je peux imaginer est celle d’un monde effrayant à coup sûr. L’âge des Transformers. 🙂

=>> Lecture recommandée – Les meilleures sociétés de services de tests manuels

Comment l’automatisation complète les tests manuels ?

J’ai dit avant et je le dis encore que l’automatisation ne peut plus être ignorée. Dans le monde où l’intégration continue, la livraison continue et le déploiement continu deviennent des choses obligatoires, le test continu ne peut pas rester inactif. Nous devons trouver des moyens sur la façon de le faire.

La plupart du temps, déployer de plus en plus de main-d’œuvre n’aide pas à long terme pour cette tâche. Par conséquent, le testeur (Test Lead/Architect/Manager) doit décider prudemment de ce qu’il faut automatiser et de ce qui doit encore être fait manuellement.

Il devient extrêmement important d’avoir des tests/contrôles très précis écrits afin qu’ils puissent être automatisés sans aucune déviation par rapport à l’attente originale et qu’ils puissent être utilisés tout en faisant régresser le produit dans le cadre du ‘Continuous Testing’.

Note : Le mot continu du terme ‘Continuous Testing’ est soumis à des appels conditionnels et logiques similaires aux autres termes que nous avons utilisés ci-dessus avec le même préfixe. Continu dans ce contexte signifie de plus en plus souvent, plus vite qu’hier. Alors que dans le sens, cela peut très bien signifier chaque seconde ou nano-seconde.

Sans avoir une correspondance parfaite entre les testeurs humains et les contrôles automatisés (tests avec des étapes précises, le résultat attendu et les critères de sortie dudit test documentés), réaliser un test continu est très difficile et cela, à son tour, rendra plus difficile l’intégration continue, la livraison continue et le déploiement continu.

J’ai volontairement utilisé le terme critères de sortie d’un test ci-dessus. Nos combinaisons d’automatisation ne peuvent plus être similaires aux combinaisons traditionnelles. Nous devons nous assurer que s’ils échouent, ils doivent échouer rapidement. Et pour qu’ils échouent rapidement, les critères de sortie doivent aussi être automatisés.

Exemple:

Disons qu’il y a un défaut de blocage dans lequel, je suis incapable de me connecter à Facebook.

La fonctionnalité de connexion doit alors être votre première vérification automatisée et votre suite d’automatisation ne doit pas exécuter la vérification suivante où la connexion est un prérequis, comme poster un statut. Vous savez très bien qu’elle est vouée à l’échec. Donc, faites-le échouer plus rapidement, publiez les résultats plus rapidement afin que le défaut puisse être résolu plus rapidement.

La prochaine chose est à nouveau quelque chose que vous devez avoir entendu auparavant – Vous ne pouvez pas et ne devriez pas essayer de tout automatiser.

Sélectionnez les cas de test qui, s’ils sont automatisés, bénéficieront considérablement aux testeurs humains et ont un bon retour sur investissement. Pour cette question, il y a une règle générale qui dit que vous devriez essayer d’automatiser tous vos cas de test de priorité 1 et si possible ensuite de priorité 2.

L’automatisation n’est pas facile à mettre en œuvre et prend du temps, il est donc conseillé d’éviter d’automatiser les cas de faible priorité au moins jusqu’au moment où vous avez terminé avec les cas de haute priorité. Sélectionner ce qu’il faut automatiser et se concentrer dessus améliore la qualité de l’application lorsqu’elle est utilisée et maintenue en permanence.

Conclusion

J’espère qu’à présent vous devez avoir compris pourquoi et à quel point les tests manuels/humains sont nécessaires pour livrer des produits de qualité et comment l’automatisation les complète.

Accepter l’importance des tests manuels d’AQ et savoir pourquoi ils sont spéciaux, est la toute première étape pour devenir un excellent testeur manuel.

Dans nos prochains tutoriels de test manuel, nous couvrirons une approche générique pour faire le test manuel, comment il coexistera avec l’automatisation et beaucoup d’autres aspects importants aussi.

Je suis sûr que vous gagnerez une immense connaissance du test logiciel une fois que vous aurez parcouru la liste complète des tutoriels de cette série.

.