Menu

Qu'est-ce que le test logiciel? Plus de 100 didacticiels de test manuels gratuits

what is software testing

Essayez Notre Instrument Pour Éliminer Les Problèmes

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

Qu'est-ce que le test logiciel?

Le test de logiciel est un processus de vérification et de validation de la fonctionnalité d'une application pour déterminer si elle satisfait aux exigences spécifiées. Il s’agit de détecter les défauts d’une application et de vérifier où l’application fonctionne selon les besoins 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.) avec le comportement attendu (exigences).

Ce que vous apprendrez:

Liste des didacticiels de test de logiciel manuel

Il s'agit de la série la plus approfondie de didacticiels sur les tests de 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, à son tour, améliorera vos compétences de test.

Entraînez-vous gratuitement à des tests manuels de bout en bout sur un projet en direct:

Tutoriel n ° 1: Principes de base des tests logiciels manuels
Tutoriel n ° 2: Présentation du projet en direct
Tutoriel n ° 3: Écriture de scénario de test
Tutoriel n ° 4: Rédiger un document de plan de test à partir de zéro
Tutoriel n ° 5: Écriture de cas de test à partir d'un document SRS
Tutoriel n ° 6: Exécution des tests
Tutoriel n ° 7: Suivi des bogues et validation des tests
Tutoriel n ° 8: Cours de test de logiciels

Cycle de vie des tests logiciels:

Tutoriel n ° 1: STLC

Test Web:

Tutoriel n ° 1: Test d'applications Web
Tutoriel n ° 2: Test multi-navigateurs

Gestion des cas de test:

Questions et réponses d'entretien de sélénium pour 4 ans d'expérience

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 de test
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 du test
Tutoriel n ° 4: Outils de gestion des tests
Tutoriel n ° 5: Tutoriel HP ALM
Tutoriel n ° 6: Jira
Tutoriel n ° 7: Tutoriel TestLink

Test Techniques:

Tutoriel n ° 1: Test de cas d'utilisation
Tutoriel n ° 2: Test de transition d'état
Tutoriel n ° 3: Analyse de la valeur limite
Tutoriel n ° 4: Partitionnement d'équivalence
Tutoriel n ° 5: Méthodologies de test de logiciels
Tutoriel n ° 6: Méthodologie Agile

Gestion des défauts:

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

Test fonctionel

Tutoriel n ° 1: Test unitaire
Tutoriel n ° 2: Test de santé mentale et de fumée
Tutoriel n ° 3: Les tests de régression
Tutoriel n ° 4: Test du système
Tutoriel n ° 5: Test d'acceptation
Tutoriel n ° 6: Test d'intégration
Tutoriel n ° 7: Test d'acceptation des utilisateurs UAT

Test non fonctionnel:

Tutoriel n ° 1: Tests non fonctionnels
Tutoriel n ° 2: Test de performance
Tutoriel n ° 3: Test de sécurité
Tutoriel n ° 4: Test de sécurité des applications Web
Tutoriel n ° 5: Tests d'utilisation
Tutoriel n ° 6: Test de compatibilité
Tutoriel n ° 7: Test d'installation
Tutoriel n ° 8: Test de documentation

Types de tests logiciels:

Tutoriel n ° 1: Types de tests
Tutoriel # 2 : Test de la boîte noire
Tutoriel n ° 3: Test de base de données
Tutoriel n ° 4: Test de bout en bout
Tutoriel n ° 5: Essais exploratoires
Tutoriel n ° 6: Test incrémental
Tutoriel n ° 7: Test d'accessibilité
Tutoriel n ° 8: Test négatif
Tutoriel n ° 9: Test du backend
Tutoriel n ° 10: Test alpha
Tutoriel n ° 11: Tests bêta
Tutoriel n ° 12: Test alpha vs bêta
Tutoriel n ° 13: Test gamma
Tutoriel n ° 14: Test ERP
Tutoriel n ° 15: Tests statiques et dynamiques
Tutoriel n ° 16: Tests ad hoc
Tutoriel n ° 17: Tests de localisation et d'internationalisation
Tutoriel n ° 18: Test d'automatisation
Tutoriel n ° 19: Test de la boîte blanche

Carrière de test de logiciels:

Tutoriel n ° 1: Choisir une carrière en test de logiciels
Tutoriel n ° 2: Comment obtenir un travail de test QA - Guide complet
Tutoriel n ° 3: Options de carrière pour les testeurs
Tutoriel n ° 4: Commutateur de test non informatique vers logiciel
Tutoriel n ° 5: Lancez votre carrière de test manuel
Tutoriel n ° 6: Leçons tirées de 10 ans de tests
Tutoriel n ° 7: Survivre et progresser dans le domaine des tests

Préparation à l'entrevue:

Tutoriel n ° 1: Préparation de CV QA
Tutoriel n ° 2: Questions d'entrevue de test manuel
Tutoriel n ° 3: Questions d'entretiens de test d'automatisation
Tutoriel n ° 4: Questions d'entretien QA
Tutoriel n ° 5: Gérez n'importe quel entretien d'embauche
Tutoriel n ° 6: Obtenez un travail de test comme un frais

Test de différentes applications de domaine:

Tutoriel n ° 1 : Test des applications bancaires
Tutoriel n ° 2: Test des applications de soins de santé
Tutoriel n ° 3: Test de la passerelle de paiement
Tutoriel n ° 4: Test du système de point de vente (POS)
Tutoriel n ° 5: Test de site Web de commerce électronique

Test de la 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 n ° 2: Test de migration
Tutoriel n ° 3: Test sur le cloud
Tutoriel n ° 4: Test ETL
Tutoriel n ° 5: Mesures de test de logiciels
Tutoriel n ° 6: Services Web

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

Introduction aux tests logiciels manuels

Le test manuel est un processus dans lequel vous comparez le comportement d'un morceau de code développé (logiciel, module, API, fonctionnalité, etc.) avec le 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. N'oubliez pas qu'il est très important de bien comprendre les exigences.

questions d'entrevue sur maven et jenkins

Pensez-vous comme un utilisateur final de ce que vous allez tester. Après cela, vous n'êtes plus lié au document d'exigence logicielle 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 à votre propre compréhension et à des choses qui ne sont pas écrites ou dites.

Parfois, il peut s'agir d'une exigence manquée (exigence incomplète) ou implicite (quelque chose qui ne nécessite pas de mention distincte mais qui doit être satisfaite), et vous devez également le tester.

De plus, une exigence ne doit pas nécessairement être une exigence documentée. Vous pouvez très bien avoir une connaissance des fonctionnalités du logiciel ou vous pouvez même deviner et tester une étape à la fois. Nous appelons généralement cela des tests ad hoc ou des tests exploratoires.

Examinons en détail:

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

En deuxième - Le test est comme une attitude ou un état d'esprit qui doit venir de l'intérieur. Les compétences peuvent être acquises, mais vous ne deviendrez un testeur réussi que lorsque vous aurez par défaut quelques qualités en vous. Quand je dis que les compétences de test peuvent être acquises, je veux dire une éducation ciblée et formelle autour du processus de test de logiciels.

Mais quelles sont les qualités d'un testeur performant? Vous pouvez en savoir plus 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. Cela vous aidera à comparer vos caractéristiques avec celles attendues dans le rôle du testeur de logiciels.

Pour ceux qui n'ont pas le temps de parcourir l'article, voici un résumé:

«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 efficace. Cela a fonctionné pour moi et je crois fermement que cela fonctionnera aussi pour vous. Si vous possédez déjà ces qualités, cela doit fonctionner pour vous aussi.

Nous avons parlé des prérequis fondamentaux de devenir un testeur de logiciels. Voyons maintenant pourquoi le test manuel a et aurait toujours son existence indépendante avec ou sans croissance des tests d'automatisation.

Pourquoi un test manuel est-il requis?

Savez-vous quelle est la meilleure chose à propos d'être un testeur, cela aussi 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 réflexion. C'est quelque chose que vous ne pouvez pas vraiment acheter pour quelques dollars. Vous devez y travailler vous-même.

Tu vas devoir développer l'habitude de poser des questions et vous devrez leur demander à chaque minute lorsque vous testerez. La plupart du temps, vous devriez vous 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 de testeurs très efficaces). Si oui, vous sauriez que les tests sont considérés comme un processus de réflexion et que votre succès en tant que testeur dépend entièrement des qualités que vous possédez en tant que personne.

Voyons ce flux simple:

  • Tu fais quelque chose ( effectuer des actions ) pendant que vous l'observez avec une certaine intention (en comparant avec l'attendu). Maintenant votre observation Compétences et la discipline faire des choses entre en jeu ici.
  • Voila! Ca c'était quoi? Vous avez remarqué quelque chose. Tu l'as remarqué parce que tu donnais parfait attention aux détails devant toi. Tu ne lâcheras pas parce que tu es curieuse . Ce n'était pas dans votre plan que quelque chose d'inattendu / étrange se produise, vous le remarquerez et vous enquêterez davantage. Mais maintenant vous le faites. Vous pouvez laisser tomber. Mais vous ne devriez pas laisser tomber.
  • Vous êtes heureux, vous avez découvert la cause, les étapes et le scénario. Vous allez maintenant le communiquer 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 êtes le communiquer de manière constructive .
  • Oops! Et si je le fais de cette façon? Que faire si j'entre un entier correct en entrée mais avec des espaces blancs au début? Et qu'est-ce qui se passerait si? … Et qu'est-ce qui se passerait si? … Et qu'est-ce qui se passerait si? Cela ne se termine pas facilement, cela ne devrait pas se terminer facilement. Vous serez imaginer beaucoup de situations et de scénarios et en effet vous serez tenté de les exécuter également.

Le diagramme ci-dessous représente la vie d'un testeur:

La vie d

Lisez à nouveau ces quatre points mentionnés ci-dessus. Avez-vous remarqué que je l'ai gardé très court tout en soulignant la partie la plus riche d'être un testeur manuel? Et avez-vous remarqué la mise en évidence audacieuse 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 actuelle d'aujourd'hui - peut-elle être remplacée par l'automatisation?

Dans SDLC quelle que soit la méthodologie de développement, peu de choses restent toujours constantes. En tant que testeur, vous consommerez les exigences, les convertirez en scénarios de test / cas de test. Vous exécuterez ensuite ces cas de test ou les automatiserez directement (je sais que quelques entreprises le font).

Lorsque vous l'automatisez, votre concentration est constante, ce qui automatise les étapes écrites.

Revenons à la partie formelle, c'est-à-dire en exécutant les cas de test écrits manuellement.

Ici, vous vous concentrez non seulement sur l'exécution des cas de test écrits, mais vous effectuez également de nombreux tests exploratoires. Rappelez-vous, vous êtes curieux? Et vous imaginerez. Et vous ne pourrez pas résister, vous ferez effectivement ce que vous avez imaginé.

L'image ci-dessous montre comment l'écriture du scénario de test est simplifiée:

Rédaction de cas de test simplifiée

Je remplis un formulaire et j'en ai terminé avec le premier champ. Je suis trop paresseux pour que la souris déplace le focus vers le champ suivant. J'ai appuyé sur la touche «tabulation». J'ai fini de remplir le champ suivant et dernier aussi, maintenant je dois cliquer sur le bouton Soumettre, le focus est toujours sur le dernier champ.

Oups, j'ai accidentellement appuyé sur la touche 'Entrée'. Laissez-moi vérifier ce qui s'est passé. OU il y a un bouton d'envoi, je vais double-cliquer dessus. Pas satisfait. Je clique dessus plusieurs fois, trop vite.

As-tu remarqué? Il y a tellement d'actions utilisateur possibles, à la fois intentionnelles et non intentionnelles.

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

Vous continuerez d'ajouter vos nouveaux cas de test au fur et à mesure que vous testerez l'application. Ce seront des cas de test pour les bogues que vous avez rencontrés pour lesquels il n'y avait auparavant aucun cas de test écrit. Ou, pendant que vous testez, quelque chose a déclenché votre processus de réflexion 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 bogues cachés . Un logiciel sans bogue est un mythe. Vous ne pouvez viser que pour le rapprocher de zéro, mais cela ne peut tout simplement pas se produire sans qu'un esprit humain ne cible en permanence le même, similaire mais non limité à l'exemple de processus que nous avons vu ci-dessus.

Au moins à ce jour, il n’existe aucun logiciel capable de penser comme un esprit humain, d’observer comme un œil humain, de poser des questions et de répondre comme un humain, puis d’effectuer des actions intentionnelles et non intentionnelles. Même si une telle chose se produit, à qui l'esprit, les pensées et les yeux imiteront-ils? Le vôtre ou le mien? Nous, les humains, n'avons pas non plus le même droit. Nous sommes tous différents. Puis?

Besoin de tests manuels lorsque l'automatisation est proche:

Les tests d'automatisation ont leur part de gloire ces jours-ci et en auront encore plus dans les années à venir, mais ils ne peuvent tout simplement pas remplacer les tests manuels d'assurance qualité (lire les tests humains / exploratoires).

Vous devez avoir entendu avant- ' Vous n'automatisez pas les tests, vous automatisez la vérification ». Cette phrase parle beaucoup de la place des tests manuels d'assurance qualité avec les tests d'automatisation. De nombreux grands noms du monde entier ont écrit et parlé de ce sujet, donc je n’insisterai pas beaucoup là-dessus.

L'automatisation ne peut pas remplacer les tests humains car:

  • Cela exige des jugements d'exécution sur tout ce qui se passe sous vos yeux (pendant que vous testez) et dans quelques cas également dans les coulisses.
  • Cela exige une observation claire et constante.
  • Il exige interrogatoire.
  • Cela demande une enquête.
  • Cela demande du raisonnement.
  • Il exige des actions non planifiées selon les besoins lors des tests.

Les tests peuvent être remplacés par un outil / machine qui sera capable d'absorber les détails, de les traiter, de commander des actions et de les réaliser comme un esprit humain et humain, et tout cela à l'exécution et dans tous les contextes possibles. Cet outil doit à nouveau être comme tous les humains possibles.

Bref, les tests humains ne peuvent pas être remplacés. Peut-être qu'un film de science-fiction hollywoodien dans quelques années s'en rappellera, mais dans la vraie vie, je ne peux pas le voir venir pendant quelques centaines d'années, ce que je peux imaginer. Je ne l’effacerai pas pour toujours car je crois aux possibilités infinies.

Sur une note séparée, même si cela se produit 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 transformateurs. :)

= >> Lecture recommandée - Meilleures entreprises de services de test manuel

Comment l'automatisation complète les tests manuels?

Je l'ai déjà dit et je le répète, l'automatisation ne peut plus être ignorée. Dans un monde où l'intégration continue, la livraison continue et le déploiement continu deviennent des choses obligatoires, les tests continus ne peuvent pas rester inactifs. Nous devons trouver des moyens de le faire.

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

Il devient extrêmement important de faire rédiger des tests / contrôles très précis afin qu’ils puissent être automatisés sans aucune déviation par rapport aux attentes initiales et puissent être utilisés lors de la régression du produit dans le cadre de «tests continus».

Noter: Le mot continu du terme «test continu» 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. Bien que dans le sens, cela peut très bien signifier chaque seconde ou nano-seconde.

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

J'ai utilisé à dessein 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 échouent rapidement. Et pour les faire échouer rapidement, les critères de sortie doivent également être automatisés.

Exemple:

Disons qu'il y a un défaut de blocage dans lequel je ne parviens pas à 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 prochaine vérification où la connexion est une condition préalable, comme la publication d'un statut. Vous savez très bien qu'il est voué à l'échec. Alors, 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 encore quelque chose que vous devez avoir entendu auparavant - Vous ne pouvez pas et ne devez pas essayer de tout automatiser.

Sélectionnez des cas de test qui, s'ils sont automatisés, bénéficieront considérablement aux testeurs humains et a un bon retour sur investissement. Pour cette question, il existe une règle générale qui dit que vous devez essayer d'automatiser tous vos cas de test de priorité 1 et, si possible, 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'à ce que vous en ayez terminé avec les plus élevés. La sélection des éléments à automatiser et la concentration sur ceux-ci améliorent la qualité de l'application lorsqu'elle est utilisée et maintenue en permanence.

Conclusion

J'espère que vous devez maintenant comprendre pourquoi et à quel point des tests manuels / humains sont nécessaires pour fournir des produits de qualité et comment l'automatisation le complète.

Accepter l'importance du test manuel d'assurance qualité et savoir pourquoi il est spécial est la toute première étape pour devenir un excellent testeur manuel.

Dans nos prochains tutoriels sur les tests manuels, nous aborderons une approche générique pour faire des tests manuels, comment ils coexisteront avec l'automatisation et de nombreux autres aspects importants.

Je suis sûr que vous acquerrez une immense connaissance des tests logiciels une fois que vous aurez parcouru la liste complète des didacticiels de cette série.

python if instruction sur une ligne

Nous serions ravis de vous entendre. N'hésitez pas à exprimer vos pensées / suggestions dans la section commentaires ci-dessous.

lecture recommandée

^