Tests de qualité de l'assurance de la qualité de zéro à la fin

1. Introduction: Petite introduction à mon sujet, je m'appelle Emeka et j'ai été ingénieur en assurance qualité pendant de nombreuses années J'ai également travaillé pour de nombreuses entreprises privées et gouvernementales. Je me suis principalement spécialisé dans l'assurance qualité mineure, mais j'ai également effectué des tests d'automatisation. Mais dans ce cours, je vais vous former sur l'assurance qualité mineure. Si vous avez besoin d'une assurance qualité ou si vous vous contentez de jouer et de trier ce cours. Bienvenue Je vais en fait suivre une formation pour vous familiariser l' assurance qualité manuelle , rôles et les responsabilités d'un ingénieur QA, ses activités quotidiennes, préparation des entretiens et des conseils sur la façon de rédiger un bon CV. Profitez donc du processus et bon apprentissage. 2. Qu'est-ce que SDLC: Alors, qu'est-ce que SDLC, où SDLC signifie cycle de vie du développement logiciel C'est donc un peu comme si toute la magie opère. Donc, en termes de cycle de vie du développement logiciel, je vais en quelque sorte le décomposer en fonction du moment où une application ou un logiciel essaie d' être développé, n'est-ce pas ? Quel est le processus ou la méthode de développement d' une application ou d'un logiciel de A à Z ? ensemble de ce processus est donc ce que nous appelons un cycle de vie de développement logiciel. Aujourd'hui, le cycle de vie du développement logiciel passe par de nombreuses phases, et de nombreuses personnes, experts en la matière ou fonctions professionnelles jouent un experts en la matière ou fonctions professionnelles rôle dans le cycle de vie du développement logiciel. Je vais donc expliquer le tout en termes de quels sont les joueurs d'équipe, vous savez, comment ces processus se déroulent, vous savez, quand ils ont lieu. Et pour vous, QA, comment participez-vous au cycle de vie du développement logiciel ? Quel est ton rôle ? Tu sais, que fais-tu dans ce processus ? Quand viens-tu ? Tout cela vous sera donc expliqué plus tard dans le cours. 3. Comment fonctionne SDLC: Alors, comment fonctionne le SDLC ? Eh bien, comme je l'ai mentionné, c'est un peu comme le parapluie de la façon dont une application est développée du début à la fin ou un logiciel est développé du début à la fin. Alors maintenant, dans le SDLC, tout est divisé en phases. L'une des premières phases est donc la phase d'analyse des exigences. Maintenant, si vous débutez dans le domaine du SDLC ou de l'informatique, qu' est-ce que la phase d' analyse des exigences phase d'analyse des exigences est donc celle où l'analyste commercial ou le propriétaire du produit, vous savez, s'assoit avec les parties prenantes. Nous sommes donc analystes commerciaux. Un analyste commercial est une personne engagée pour rédiger des récits d'utilisateurs ou pour écrire les fonctions de développement de l'application ou du logiciel. Ainsi, l'artefact ou le document créé par l'utilisateur, l'analyste commercial, est un témoignage d'utilisateur ou un document d' exigences commerciales Permettez-moi donc de le détailler davantage. Cette personne, un analyste commercial, s'adresse donc à la partie prenante. Maintenant, qui est partie prenante ? partie prenante peut être l'entreprise, quelqu'un qui est en fait pour, par exemple, parler de Walmart Qui est partie prenante de Walmart. Il se peut donc que ce soient les responsables, vous savez, personnes qui aiment travailler chez des personnes qui aiment travailler chez Walmart qui aient besoin de développer une application permettant à leurs clients de se connecter en ligne pour acheter des produits, n'est-ce pas ? Les responsables ou les employés de Walmart peuvent donc trouver un analyste commercial et SG sait quoi, nous avons ce problème. Nous avons ce problème. Nous essayons de développer un logiciel ou une application permettant aux clients d' acheter des produits en ligne. C'est un exemple typique. Donc, ce que fait l'analyste commercial , c'est qu'il discute avec les parties prenantes de Walmart et qu'ils rédigent en quelque sorte des scénarios de haut niveau sur ce que devrait être cette application L'application pourrait donc être un exemple typique, il pourrait s'agir d'une application ordinaire où les gens peuvent acheter des choses. Il doit donc avoir un identifiant de connexion , un mot de passe. Il doit avoir un écran de paiement. Il doit y avoir un endroit où vous pouvez saisir les informations de votre carte, toutes ces choses. Le manager a donc en quelque sorte une idée de ce qu'il veut. C'est à l'analyste commercial ou au responsable du produit de le présenter d'une manière plus structurée, plus réfléchie et mieux organisée, là où les développeurs ou n' importe quel autre acteur peuvent y travailler. Les parties prenantes sont donc un peu comme donnaient des idées de haut niveau au lieu de s'organiser. L'analyste commercial est donc désormais chargé recueillir toutes ces idées et mettre dans un format plus structuré. Qu'est-ce qu'un format plus structuré ? Il se peut, par exemple, que l'application doive avoir un ID utilisateur. L'application doit avoir un mot de passe. Maintenant, quel type de mot de passe ? L'application et le mot de passe doivent tous faire la distinction majuscules et minuscules. Vous savez, il doit comporter de huit à dix caractères. Donc, tout cela est un peu comme des détails, droit au but. C'est donc ce que l'analyste commercial est chargé de faire. Assurez-vous que la personne chargée du développement comprend clairement ce qu'elle essaie de faire ou ce que l'application est censée faire. C'est donc le rôle d' un analyste commercial. L'analyste commercial prend toutes ces idées et les classe dans un format organisé plus structuré lequel la personne chargée de développer sur lequel la personne chargée de développer l'application devrait travailler. Et le produit final du document ou de ce que l'analyste commercial développe, le produit final, est ce que nous appelons un BRD Il s'agit d'un document d'exigences commerciales dans Waterfall. J'aborderai ce qu'est Waterfall plus tard. Dans Agile, c'est ce que nous appelons une user story. Ainsi, une histoire d'utilisateur parle d'un scénario, des critères d'acceptation ou de ce que pourrait être une histoire utilisateur typique . L'application devrait pouvoir avoir une page de connexion. Il s'agit d'un stockage utilisateur typique. Donc, tout cela est en quelque sorte décomposé en morceaux. Ce ne sera donc pas comme un document où tout est simplement mis au courant. Tout est décomposé en tailles, où vous travaillez sur ceci et sur cela. Je vais leur dire d'en savoir plus leur fonctionnement, sur le processus, sur la façon dont les personnes ou l'équipe travaille sur cette application pour la faire passer à la phase de finalisation. Mais pour résumer, nous avons parlé de la phase d'analyse des exigences et identité des responsables de cette phase, que nous appelons le propriétaire du produit ou l'analyste commercial Nous sommes les principaux responsables de l' interaction avec les parties prenantes, en quelque sorte , en mettant leurs idées par écrit ou dans un format où elles peuvent, vous savez, les transmettre davantage aux développeurs pour qu' ils les développent. 4. Phase de design: La deuxième phase est donc ce que nous appelons la phase de conception. Maintenant, c'est là que se déroule la majeure partie du travail. Qui est donc responsable de la phase de conception ? Donc, comme je l'ai mentionné plus tôt, l'exigence est rédigée. C'est pourquoi les analystes commerciaux ont discuté avec les parties prenantes de ce que nous appelons le document des exigences commerciales ou le témoignage de l'utilisateur . Ils ont tout mis par écrit, et tout a été documenté. Ils ont fait l' approbation par la direction. La direction a donc accepté que cette exigence soit complète et prête à être utilisée. Donc, dans la phase de conception, le développeur s'en charge, n'est-ce pas ? Ainsi, lorsque le développeur choisit cette option, il commence à entrer dans la phase de développement au cours laquelle le développeur commence à développer cette application. Maintenant, cela peut être par étapes ou tout cela peut être effectué en une seule fois. Je vais tout de même détailler les différents types de méthodologie, et je vais vous expliquer quelle est la méthodologie utilisée pour expliquer comment cette répartition se produit. Mais en général, le développeur qui est réellement responsable de l'écriture du code celui qui est responsable de la conception de cette application. Ils écrivent donc les codes en fonction du stockage utilisateur. Ainsi, la mention utilisateur ou le document des exigences commerciales que l'analyste commercial remet au développeur est très spécifique au point, vous savez, que tout doit être étiqueté directement. Alors devinez quoi, ce ne sont pas les développeurs qui font preuve de créativité c'est l'entreprise qui est à l'origine de la créativité , ni l'analyste commercial ou le donateur de produits qui ont tout compris. Donc, ce que fait le développeur, c'est développer. Même si le développeur doit encore faire preuve de créativité en ce qui concerne la façon de développer l' application ou le type de codes et d'éléments à écrire, il n'est pas de sa responsabilité de sortir du cadre. La responsabilité est de développer l'application conformément aux exigences énoncées. Donc, si l'exigence l'indique, le nom d'utilisateur doit être de ce caractère, il doit comporter de huit à dix caractères. C'est ça. Ça ne devrait pas être dix ou douze. Ils pourraient revenir en arrière et suggérer à l'analyste commercial : «   OK, je pense que c'est peut-être ça, ce qui n'arrive souvent pas ». Mais même s'ils suggèrent, c'est vrai, l'activité, c'est à l'analyste commercial ou au responsable du produit d'aller voir la direction et de lui dire : «   OK, qu'en pensez-vous ? Vous savez, mais souvent, lorsque l'analyste commercial ou le propriétaire du produit rédige ces exigences, le développeur les développe en fonction des spécificités des exigences ou de l'histoire de l'utilisateur. 5. Phase de test: Appliquer minutieusement. Maintenant, rien de tel qu'une application 100 % sans défaut ou 100 % sans erreur. La plupart des applications vont présenter des défauts, même lors de leur mise en production. Par exemple, quand je parle de production, je veux dire, quand ils vont être publiés, alors que les clients l'utilisent réellement, il alors que les clients l'utilisent réellement, il y a toujours des erreurs, mais votre rôle en tant qu' ingénieur en assurance qualité est de vous assurer que les erreurs majeures sont éliminées rapidement. Ainsi, ceux qui peuvent entrer en production ou ceux que les clients utilisent peuvent être allumés, peut-être des erreurs mineures qui n'empêchent pas le client de faire ce qu'il doit faire. Ainsi, par exemple, si un client ne peut pas ajouter son panier, ajouter des articles à son panier ou payer ce qu' il a acheté en ligne, c'est une grosse erreur, vous savez, et nous allons parler davantage en termes de points ajouter des articles à son panier ou payer ce qu' il a acheté en ligne, c'est une grosse erreur, vous savez élevés, comment prioriser un défaut ou une erreur, vous savez, afin que tout cela s' vous savez, afin que tout explique comme l'ensemble du la responsabilité quotidienne d'une assurance qualité, vous savez, à quoi faites-vous attention ? Comment faites-vous votre travail ? Vous savez, lorsque vous vous connectez au système, connectez-vous pour la journée, quels sont vos rôles et responsabilités ? Nous en parlerons plus en détail dans le prochain cours. Mais en général, pour une assurance qualité, vous savez, votre rôle est de tester l'application pour détecter les défauts. Et cela demande beaucoup de créativité. Cela demande beaucoup de réflexion hors des sentiers battus. Par exemple, un exemple typique est l'utilisation du mot de passe L summit. Et si j'utilise tous les dix caractères, non ? Exemple typique. Et si je les distinguais tous plus majuscules et minuscules ? Est-ce de la rapidité et de l'erreur ? Et si vous y réfléchissez, cela devrait également correspondre à ce qui figure dans le document d'exigences commerciales ou dans le témoignage d'utilisateur. Votre témoignage d'utilisateur ou votre document sur les exigences de votre entreprise est donc votre document sur les exigences de votre entreprise est votre guide en termes de test. Il va donc indiquer exactement ce que l' application est censée faire. À présent, votre rôle est de vous y mesurer. Votre rôle est de faire le contraire de ce qu'il est censé faire pour créer une erreur. Donc, s'il est dit d'utiliser un nom et passe ou d'aller à la caisse, vous savez, vous faites le contraire Pour voir comment vous allez réagir si vous faites le contraire ? Si vous faites le contraire, que devez-vous faire ? Cela devrait certainement vous donner une erreur. Parce que si vous faites le contraire, vous devriez vous donner une erreur. Si cela ne vous donne pas une erreur et vous amène pas là où il est censé vous mener, c'est un défaut. C'est une erreur. Vous faites également le positif. Le mot de passe utilisateur typique est le bon chemin, et cela devrait vous mener au bon endroit C' est ce que nous appelons des tests positifs. Donc, lorsque vous faites le contraire, cela s'appelle un test négatif. Un test négatif consiste à tester l'application, tester ce que l'application n' est pas censée faire. Pour voir quelle sera la réaction. Et quelle que soit la réaction, vous devez la comparer au document relatif aux exigences de l'entreprise ou au témoignage de l'utilisateur. Donc, s'il est écrit nom d'utilisateur, mot de passe, envoyer, vous entrez le nom d'utilisateur, le mauvais mot de passe, soumettez. Je devrais te donner une erreur. Et que dit cette exigence lorsque vous entrez un mauvais mot de passe dans le nom d'utilisateur et que vous le soumettez ? Quelle erreur s'affiche-t-il ? Cela vous montre-t-il la bonne erreur ou non ? Donc, tout cela est peu complexe, vous savez, et c'est intéressant, un peu complexe, vous savez, et c'est intéressant, très intéressant car cela demande beaucoup de créativité, un peu comme sortir des sentiers battus, deviner, comment puis-je casser cette application ? Qu'est-ce que je peux faire ? Et bien souvent votre processus devrait provenir, vous savez, dans un scénario réel, lorsqu'un client utilise une application. Plusieurs clients utilisent l'application. Ils vont dessiner des choses différentes , faire des choses différentes. Certains d'entre eux peuvent se connecter, une personne peut les mettre dans les cartes. Certaines personnes peuvent ajouter des articles lors de leur commande. Vous savez, certaines personnes peuvent juste avoir des choses différentes à des moments différents. Votre rôle est de réfléchir aux différentes manières dont ces clients utiliseront cette application dans la vie réelle, vous savez, et de réfléchir à la manière dont je peux détecter les erreurs. Votre rôle n'est donc pas de vous assurer que l' application fonctionne. Non. Votre rôle est de casser l'application. Votre rôle est de trouver les défauts. Trouvez comment l'application vous donnera une erreur. Parce que si vous regardez, si vous y réfléchissez bien, nous voulons nous assurer que l' application fonctionne. D'accord, utilisez le nom, le mot de passe, soumettez allez à l'enregistrement, connectez-vous à l'application, ajoutez des éléments à votre carte, partez, , cela va probablement passer, n'est-ce pas ? Mais maintenant, lorsque vous commencez à faire des tests négatifs, comme je l'ai mentionné, que vous entrez et utilisez un mauvais mot de passe, que se passe-t-il ? Cela vous donne-t-il une erreur ? Utilisez le nom correct et le mot de passe Summit. Vous allez maintenant à l' enregistrement, vous savez, cueillir des objets dans votre voiture, vous savez, les sortir, est-ce que c'est elle qui les sort ? Est-ce que cela met à jour, vous savez, des choses comme ça ? J' essaie juste de casser le système, vous savez, faire des choses qui vous demanderont d'aimer parce que ces choses d'encodage sont plus que des choses complexes. L'aspect positif sera donc probablement plus facile à développer pour le développeur et cela va probablement passer. Mais quand vous commencez à faire des choses comme, vous savez, dans la vraie vie, parce que dans clients vont faire beaucoup de choses, différentes choses, comme ajouter une carte. Ils peuvent ajouter des articles à la carte, ensuite, ils peuvent la retirer, ou ils peuvent l' acheter, revenir en arrière, ils veulent l'annuler, vous savez, des choses comme ça. Tous les scénarios sont des choses auxquelles vous allez réfléchir, par exemple comment puis-je casser l'application ou comment puis-je trouver des erreurs en pensant ainsi. C'est ainsi que vous pensez en tant qu' ingénieur en assurance qualité ou en assurance qualité. Et nous allons parler davantage des rôles et des responsabilités, des artefacts ou des documents dont vous avez besoin en tant qu'ingénieur en assurance qualité pour vous préparer aux tests. Nous allons parler des types de tests. Il existe donc différents types de tests. Donc, comme je l'ai mentionné, celui que je vous ai expliqué en ce moment est positif et négatif. Lorsque ces doses sont négatives, il existe toujours différents types de tests Nous allons donc vous expliquer plus en détail et plus loin. 6. Phase de déploiement: La phase suivante est ce que nous appelons la phase de déploiement. La phase de déploiement se déroule donc, disons que tout se passe comme si vous aviez fait votre part en tant qu'ingénieur en assurance qualité, testé l'application, vous aviez testé l'application, que vous aviez découvert des défauts ou des erreurs , que les développeurs l'avaient corrigée et vous avaient répondu . Je vais étendre l'ensemble du processus, à savoir que faites-vous lorsque vous trouvez une erreur ? Comment vous y prenez-vous ? Mais disons que tout est fait et qu'ils sont prêts à, exemple, mettre l'application à la disposition des clients, n'est-ce pas ? C'est ce que nous appelons la phase de déploiement. La phase de déploiement parle donc, vous savez, de la manière dont l'application sera déployée en production. Donc, lorsque nous parlons de production, nous voulons dire en cours d'utilisation, exemple le fait que les clients puissent se connecter à Internet et l'utiliser. Bien souvent, ce processus ou phase de déploiement est ce que nous appelons publication. Ainsi, lorsqu'ils disent qu'une version on parle également de déploiement. Alors, comment se coordonne l'équipe, n'est-ce pas ? Ainsi, lorsqu'une version est publiée, c'est lorsqu' ils ont créé les user stories, développé l' application, l'ont testée, et vous avez donné votre approbation, comme si tout fonctionnait comme prévu, tout fonctionnait comme prévu, alors le PO L'équipe chargée de la mort collabore également pour mettre cette application en production Une chose à laquelle vous devez faire attention est la terminologie. Quand je dis que la terminologie désigne les termes ou les jargons informatiques ou, vous savez , méthodologie, Agile, Waterfall, QA, PA, PO , document d'exigences commerciales, tous ces termes, vous devez les connaître et être capable de parler avec ces termes , car c'est un peu comme le langage informatique C'est ainsi que vous savez que les gens comprennent. Ainsi, lorsque vous parlez de production, ils ne diront pas quand ils en feront la promotion auprès des clients. Ils vont dire qu'ils vont le mettre en production, vous savez, et aussi comment le faire passer en production, de lancement ou en phase de déploiement. donc vous familiariser avec tous ces termes Vous devez donc vous familiariser avec tous ces termes, vous savez, vous devez parler cette langue en informatique, vous savez, façon parce que lorsque vous travaillez en équipe, sont le genre de choses que vous allez entendre, tous ces termes. Vous allez rencontrer la plupart des termes, donc, vous savez, vous voulez être en mesure de vous familiariser avec tous ces termes en termes de, vous savez, ce que cela signifie. Donc, comme je l' ai dit, la phase de déploiement parle de sortie, n'est-ce pas ? Et le PO, ainsi que les analystes commerciaux et les développeurs, vous savez, collaborent pour obtenir cet effort. Le QA participe peu à ce processus. Les Q ways ne participent donc pas vraiment beaucoup à la phase de sortie, principalement parce que le développement est plus actif dans cette phase. Ce sont eux qui assurent la stabilité de l'environnement. Ils s'assurent que l' environnement est prêt. Et euh, une chose que je vais également expliquer, c'est l'environnement, n'est-ce pas ? Ainsi, lorsque le travail de développement est en cours ou que le Q est en cours de test, ils ne le font pas dans un environnement différent de celui utilisé pour le déploiement d'une application en production. Ainsi, lorsqu'une application est déployée en production, il s'agit d'un environnement différent, car je vais vous expliquer pourquoi, par exemple, je vais utiliser un exemple typique de Walmart Donc, le site Web de Walmart, non ? Cette application, ils voudront peut-être mettre à jour certaines choses. Il ne serait pas judicieux d'utiliser même serveur ou le même environnement pour effectuer des travaux de développement, car cela pourrait perturber ou interférer avec leur production réelle, comme lorsqu'une application est en production, n'est-ce pas ? Supposons donc qu'un développeur écrit un code et le place dans l'environnement de test ou dans l'environnement de développement. S'ils partagent le même environnement que l'environnement de production, cela pourrait interférer avec l'application ou le site Web en production. Disons donc un walmart.com typique, non ? Les clients l'utilisent en permanence, ils achètent, ils vendent. Je veux dire, ils achètent des trucs, tu sais, des choses comme ça. Maintenant, s'ils veulent ajouter une nouvelle idée ou une nouvelle initiative de développement d'une application ou développement d'une application ou d'un futur à Walmart.com, Ils veulent y ajouter une fonctionnalité. C'est vrai. Ce n'est donc pas le cas lorsque le développeur travaille sur cette fonctionnalité Il travaille désormais sur le même environnement que celui dans lequel le walmart.com est hébergé, si cela a du sens Ils sont donc dans ce qu'ils appellent l'environnement de développement. Vous allez leur parler d'un environnement de développement, d'un environnement d' assurance qualité, d'un environnement de pré-production , d'un environnement UAT Ils disposent donc d'un environnement distinct, d'un espace distinct dans lequel ils effectuent des travaux de développement. Quand je parle de travail de développement, je parle , de test, d'UAT, de préproduction . Parfois, le développeur et l' assurance qualité partagent le même L'UAT peut avoir un environnement différent ou ce que nous appelons la préparation avant production est donc en fait l' endroit où l'application est hébergée, où les clients peuvent utiliser l'application comme vos sites Web habituels qui ont disparu et d'autres choses de ce genre constituent un environnement de production. L'application est en cours d'utilisation. Mais il ne s'agit pas de la même application où se déroule le SDLC Le cycle de vie du super développement. Toutes les phases sont discutées d' exigence, de développement à la manière Q. Ce n'est pas la même phase que celle où ils font le travail. Ainsi, lorsque le développement écrit le code, le développeur écrit le code, le Q lorsque vous testez l'application, vous ne testez pas le même environnement que lequel le site Web est hébergé pour que les clients puissent l'utiliser. Donc, une fois que vous avez effectué vos tests, le développement a écrit le code, que le développement a écrit le code, que vous avez fait vos tests, que vous l'avez approuvé, puis ils l'ont poussé, ils proposent ce changement Peu importe ce que le développeur a écrit, les modifications, la nouvelle fonctionnalité qu'il a créée, les nouveaux modules complémentaires ou quoi que ce soit d'autre, et que vous l'avez testé, ils le mettent maintenant production là où en production là où les clients étaient censés l'utiliser. Ainsi, lorsque le travail est en cours, ce n'est pas le même endroit où les clients utilisent le même site Web. Donc, quand ils font tout. Donc, même les données, tout est une maquette, tout est faux, non ? Ce n'est pas réel. Une fois que tout est terminé , ils le mettent en production, où les clients peuvent désormais constater le changement. Supposons donc que le futur soit d'ajouter disons, un autre type de bloc-notes à la caisse. Ainsi, lorsque vous essayez d'effectuer un paiement, vous souhaitez ajouter MX now à l'une des options de paiement d'un client. Peut-être qu'Amex n'est pas l'une des options en production. Le développeur écrit donc le code pour permettre à AMEX travailler sur le site Web Lorsqu'il écrit le code, MX n'est toujours pas disponible en production. Mais il a écrit un code pour permettre aux clients de MX d' acheter avec la carte MX, et cet environnement est appelé environnement de développement. Il vous envoie, un test, un test pour que les clients de MX puissent utiliser leur carte pour acheter des produits sur le site Web. Tu testes ça. Cela fait toujours partie de l'environnement de développement et de test. Une fois que vous aurez confirmé que je l'ai testée, les clients de MX peuvent utiliser leur carte pour faire des achats Et n'oubliez pas que vous avez fait vos tests négatifs, que vous avez fait toutes ces sortes de tests, que vous avez confirmé que tout allait bien Ensuite, ils procèdent au déploiement ou à la publication. Le déploiement de cette version signifie donc qu' ils ont maintenant intégré cette fonctionnalité, ce passage à la production où les clients peuvent désormais utiliser une carte AMEX pour acheter Ainsi, lorsque vous appuyez, cela s'appelle une libération. Lorsque vous le mettez en production, c'est vrai, les clients peuvent maintenant et ils font annonce que, d' accord, les clients, je veux dire, malgré le fait qu'ils figurent sur leur site Web, vous voyez le logo Mex et d'autres choses de ce genre selon lesquelles clients peuvent désormais utiliser Amex Donc, une fois que c'est sur leur site Web, je veux dire que les clients peuvent désormais utiliser la carte AMEX pour acheter C'est donc ce qui s' est passé à l'époque : le changement s'est produit et ce changement est maintenant en cours de production pour que les clients puissent l'utiliser. C'est donc un peu la façon dont se déroule la phase de déploiement, vous savez, et aussi en termes d'environnement. Cet environnement est donc également très important. Vous allez beaucoup le affaiblir. L'environnement Death, Q est donc différent de l'environnement de production. Et nous allons également parler de l'UAT, ce qu'est l'UAT en termes de, vous savez, comment se déroule ce processus avant sa mise en production Donc, c'est juste que c'est en fait une phase de déploiement avant de publier. 7. Phase de maintenance: Et la dernière phase concerne maintenance et le cycle de vie du développement logiciel. Donc, en matière de maintenance, c'est assez facile, comme, vous savez, la production de conception d'applications, celle-ci a été mise en production. Les clients l'utilisent. Vous savez, maintenant ils donnent leur avis, non ? Ainsi, par exemple, la maintenance est là qu'ils puissent voir comment les clients utilisent l'application. Supposons donc, vous savez, que les clients trouvent cela facile, n'y a aucun défaut, aucune erreur, vous savez, puis ils envoient des commentaires. Vous savez, nous acceptons non, mais l'entreprise prend en compte les commentaires, l'équipe, l' équipe de développement ou précise l'analyse commerciale, pour être plus précis. Ce sont eux qui prennent les commentaires et les envoient aux parties prenantes pour leur dire que l'application fonctionne bien, qu'il l'application fonctionne bien, n'y a pas d'erreur, rien. Maintenant, si, par exemple, un futur a été développé, mais qu' il ne fonctionne pas, n'est-ce pas ? Donc vous l'avez raté. Donc le développeur l'a raté, le QA l' a oublié, vous savez, c'est en production, les clients se plaignent de pouvoir, par exemple, vérifier, vous savez, qu' il y a une erreur de production C'est un problème, non ? Et c'est à cela que sert la phase de maintenance. La maintenance consiste donc à vérifier correctement les commentaires des clients. Comment fonctionne l' application en production ? Y a-t-il des problèmes ? Y a-t-il des erreurs ? Maintenant, lorsqu'il y a une erreur, vous savez, en production , vous savez, il existe également un processus différent pour corriger ces erreurs Vous savez, qui, vous n'allez pas aimer Cut, ils n'abandonneront pas l'ensemble de l' application en production. Non. Supposons que vous ayez développé le logiciel, n'est-ce pas ? Et vous l'avez mis en production. Même s'il y a eu une erreur, vous n'allez pas arrêter l'application dans son intégralité. Quelle que soit l'erreur, vous contactez le BA, nous obtenons des informations, puis ils travaillent dessus, puis ils les envoient au développeur, ils l'informent que c'est ce qui ne va vous contactez le BA, nous obtenons des informations, puis ils travaillent dessus, puis ils les envoient au développeur, ils l'informent que c' pas, c'est ce qui se passe. C'est l'erreur de mise en production. Donc, ce qui se passe, c'est ce que nous appelons le hot fix. Un hot fix correspond à un problème de production. La plupart de ces frais exceptionnels sont pour la plupart des priorités élevées, n'est-ce pas ? C'est comme si, par exemple, dans l'application, ils pouvaient dire que les clients ne peuvent peut-être pas ajouter d'articles à leur voiture. C'est vrai. Et pour pouvoir payer, ils doivent ajouter des articles à leur voiture, puis passer à la phase de paiement. Ainsi, lorsqu'ils ajoutent quelque chose à leur voiture, cela ne s'affiche pas. C'est un gros problème, non ? Empêcher les clients d'acheter des produits. Donc, ce que font les développeurs, c'est qu'il écrit un code. N'étant pas en production, il écrit un code dans l'environnement de développement. Moi, lorsque nous avons parlé de l'environnement Dave, il écrit le code pour permettre aux clients d'ajouter des articles. Il écrit donc que c'est essentiel pour U now, à la manière Q. Vous le testez, vous achetez tout un tas de choses en ligne et vous voyez s' il est capable d'ajouter tout un tas de choses en ligne pour voir si elles peuvent être ajoutées au c. Rappelez-vous que ce n'est pas un environnement de production. C'est toujours l'environnement de développement. Donc, vous faites tout cela, vous vous assurez que cela fonctionne. Une fois que vous voyez cela, d'accord, vous y allez en tant que client, vous ajoutez des articles à votre voiture et ça ne fait que s'ajouter, n'est-ce pas ? Vous retirez des éléments, ont-ils retirés, vous en ajoutez à nouveau, ont-ils ajouté toutes sortes de scénarios ? Vous vous assurez que les clients peuvent réellement demander à aller à la voiture. Une fois que vous aurez récupéré fonctionne et que vous ne pouvez pas ajouter c. Ensuite, le développeur va maintenant envoyer ce code en production pour mettre à jour l'erreur en cours. Quelle que soit cette erreur, il mettra à jour cette erreur une fois que j'aurai testé redéfini le code et que vous l'aurez Donc, cette erreur écrite par le code remplacera celle qui est actuellement en cours de production, juste pour la corriger. Et encore une fois, la maintenance se fait toujours. Les clients vont donc à nouveau utiliser cette application. Continuez à utiliser l'application pour voir s'ils peuvent désormais ajouter des éléments à leur voiture ? Peuvent-ils maintenant ajouter des objets à la voiture avant de partir ? S'ils le peuvent, c'est un succès car cette erreur a été corrigée. Ensuite, ils continuent à utiliser l'application. Les clients continueront à utiliser l' application en permanence. Pour voir si tout fonctionne. Je veux dire, ils continuent à utiliser l'application, pas pour voir, mais ils continueront à utiliser l'application. Alors c'est le BA qui surveille, non ? Pour voir si des problèmes sont détectés ou si les clients en disent, est-ce qu'ils l'apprécient ou, vous savez, s' ils rencontrent encore d'autres problèmes ? Et dans les scénarios réels, maintenance est énorme car les clients rencontrent des problèmes dans l'application. Ils détectent les erreurs, vous savez, et c'est pourquoi nous avons besoin de maintenance, car nous n'allons pas retarder l'application et la production et nous dépoussiérer les mains et les mains baissées. Non. Une fois que nous l' avons mise en production, nous devons toujours la surveiller pour nous assurer qu'aucune erreur n' détectée, car si une erreur est détectée, c'est ce que font les clients. Ils disent « stop », non ? C'est donc comme si cela pouvait arrêter les affaires et arrêter le progrès. Donc, ce qu'ils font, c'est que nous devons le surveiller. Donc, c'est l'équipe de la mort, l'équipe de la mort, l'équipe du SDLC qui surveille de la mort, l'équipe du SDLC Donc, les développeurs d' analystes commerciaux , vous savez, nous sommes tous là, vous faites toujours partie de l'équipe pour vous assurer que même si cette application est en production, les BA surveillent toujours, n'est-ce pas ? Juste pour s'assurer que l'application fonctionne toujours pendant que les clients l'utilisent. Et s'il y a une erreur, comme je l'ai mentionné, il y a tout un processus, comme je l'ai expliqué, pour résoudre ce problème et le remettre en production. 8. Qu'est-ce qu'une méthodologie: Passons maintenant à la méthodologie, quelle est la méthodologie ? Méthodologie. Vous vous souvenez quand j'ai parlé du cycle de vie du développement logiciel et de la façon dont une application est développée de A à Z, n'est-ce pas ? C'est ce que nous appelons le cycle de vie du développement logiciel. Maintenant, pensez aux méthodologies situées un cran en dessous du SDLC. Alors maintenant, je me souviens quand j'ai parlé de toutes les différentes phases, la phase d'exigence, la phase de développement, la phase de test, vous savez, la phase de déploiement, la phase de maintenance , ces phases sont ce que nous appelons le SDLC, n'est-ce pas Mais une étape ci-dessous est la méthodologie. Maintenant, comment se situent les exigences, leur profondeur , la méthode Q, le déploiement, la maintenance, , la méthode Q, le déploiement, la maintenance, comment ont-elles été réduites ou comment pouvons-nous exécuter une application en utilisant toutes ces phases, n'est-ce pas ? Le développement logiciel est donc la façon dont l'application va de zéro à la fin. Maintenant, dans ces phases du début à la fin, nous avons des phases, n'est-ce pas ? Maintenant, les méthodologistes qui utilisent ces phases. Ainsi, pendant le test en cours de développement, ces phases peuvent différer en fonction du type de méthodologie. Sur la base d'un type de méthodologie, maintenance des ondes Q à la profondeur de ces exigences peut être différente de celle d'un autre processus. Ils se différencient donc, ils sont différents quant à la façon dont vous utilisez ces différentes phases. Mais en général, ces cinq phases concernent toutes les méthodologies. Mais maintenant, certaines méthodologies peuvent être différentes. De la part d'autres, vous savez, en utilisant ces cinq phases, n'est-ce pas ? Donc, les deux plus courants dont je vais parler sont la cascade et l'agilité, n'est-ce pas ? Donc Waterfall, c'est un peu comme au début quand l' informatique était nouvelle, non ? La cascade a commencé par une cascade. Waterfall est donc un peu comme une ancienne approche. L'agilité est la nouvelle approche. Je vais donc expliquer davantage est Waterfall, ce qu'est agilité, quels sont les avantages et les inconvénients, vous savez, en quoi ils diffèrent. Et je veux que vous connaissiez les deux parce que j'ai l'impression que lorsque vous connaissez Waterfall, vous savez agilité, vous êtes mieux équipé. Vous êtes plus polyvalent en tant qu' ingénieur en assurance qualité plus expérimenté. Je pense donc qu'aujourd'hui, tout est agile, comme de nombreuses entreprises sont en train de passer du mode cascade à l'agilité Mais c'est très important, c'est très bien pour vous de continuer à connaître Waterfall et à savoir Agile. Ainsi, vous pourrez être mieux formé pour connaître les différences, tout en mieux équipé pour être un testeur d'assurance qualité plus qualifié lorsque vous connaissez les deux. Ainsi, vous savez mieux comprendre cycle SDLC et savez comment fonctionne une assurance qualité à la fois en cascade et en mode agile 9. Qu'est-ce que la chute d'eau: Alors, qu'est-ce qu'une cascade, n'est-ce pas ? La chute d'eau est donc une méthodologie, et nous utilisons ce terme méthodologie. Waterfall est donc une méthodologie relevant du cycle de vie du SDLC ou Super Development Alors, de quoi est composée la cascade ? La cascade comprend toutes ces phases. Il y a donc une phase d'exigence. Il y a une phase de développement, une phase de test, une phase de déploiement et une phase de maintenance, n' est-ce pas ? Comme je l'ai expliqué, toutes ces phases en cascade. Mais en quoi est-ce différent ou qu'est-ce qu'une cascade ? Waterfall est donc une méthodologie dans laquelle une application est entièrement développée de A à Z avant de passer aux tests d'assurance qualité et de diplôme. Donc, comme je l'ai mentionné, comme pour les analystes commerciaux, juste au moment où ils rencontrent les parties prenantes et les parties prenantes expliquent ce qu'elles veulent, quoi devrait ressembler l'application, ce dont elles ont besoin. L'analyste commercial intègre cette idée dans un processus plus détaillé, dans un document plus détaillé lequel les développeurs peuvent développer l'application , afin d'éviter toute confusion lorsque les développeurs écrivent les codes. Ils veulent être aussi précis que possible, spécifiques que possible au point. Dans ce cas, la personne qui écrit et qui discute avec la partie prenante est ce que nous appelons un analyste commercial. Hein ? Et je vais expliquer qui s'assoit avec les parties prenantes d' Aj, comment on les appelle. Mais chez Waterfall, quelqu'un qui discute avec les parties prenantes est ce que nous appelons l' analyse commerciale, n'est-ce pas ? Et les documents que les créent après avoir discuté avec les parties prenantes et qu'ils les envoient à l'équipe chargée de la mort, les développeurs expliquant comment effectuer leur travail, constituent ce que nous appelons un document d' exigences commerciales. Maintenant, dans certains cas, il existe des situations où ils disposent de documents relatifs au système d'entreprise. Un document de système d'entreprise se trouve donc un niveau inférieur aux documents relatifs aux exigences de l'entreprise. Les documents relatifs aux exigences commerciales sont donc endroit où toutes ces exigences sont rédigées. C'est ce que nous appelons une exigence. L'exigence pourrait être des scénarios à puces, n'est-ce pas ? Il peut donc s'agir d'une application, une page de connexion doit avoir un identifiant utilisateur. C'est une exigence. Si c' est une cascade, nous appelons cela des exigences. Un mot de passe doit donc comporter de huit à dix caractères. C'est une exigence. La page de connexion doit comporter un bouton d'envoi. C'est une exigence. Une fois que vous avez cliqué sur le bouton d' envoi, l'utilisateur devrait être en mesure d'ajouter des articles à son compte. C'est une exigence. L'utilisateur doit être en mesure d'ajouter jusqu' à t éléments à son maximum de découpe, c'est une exigence. Donc R : ce sont des sujets dont les analystes commerciaux ont discuté avec les parties prenantes. Et les parties prenantes étaient un peu comme si elles n'avaient pas à proposer la solution complète. C'est ce que nous appelons l'analyste commercial Les parties prenantes s'assoient et ont cette conversation comme s'ils réfléchissaient à devrait être l'application. Et ce processus d' analyse commerciale avec la partie prenante est ce que nous appelons une session la partie prenante est ce que nous appelons d'identification des exigences. exigences analystes commerciaux et les parties prenantes participent donc à une séance d'identification des Les dirigeants de l'entreprise se sont donc assis et ont discuté la manière dont la demande devrait être présentée. C'est ce que vous appelez une session cool de collecte des exigences une session d'obtention de renseignements ou des sessions d'atelier Donc, une fois que cela est réellement documenté, c'est vrai, les analystes commerciaux passent à un processus plus détaillé les analystes commerciaux passent à un processus plus détaillé. Je me souviens de ce qui commence à se terminer. Ils ont donc développé l'application complète. Disons qu'il s'agit d'un gros logiciel. Il y a une page d'enregistrement, vous avez des informations que vous pouvez acheter, des informations que vous pouvez ajouter à votre carte, informations que vous pouvez utiliser quelle que soit l'application, l'analyste commercial va tout documenter. Tout est inclus dans un document d' exigences commerciales. Et je vous ai dit quelle est l'exigence, donc c'est comme dans les autres scénarios, n'est-ce pas ? L'ensemble des exigences exigera donc d'avoir jusqu'à 300 scénarios, n'est-ce pas ? Une fois qu'ils l'ont obtenu, ils retournent à l'entreprise, et c'est ce que nous trouvons, n'est-ce pas ? C'est ce qu'ils doivent examiner. Une fois les exigences l'analyse commerciale, une fois que le responsable l'a examinée, c' est vrai, et que tout va bien, ils signent. L'entreprise doit donc signer les documents relatifs aux exigences commerciales. Parce que s'ils ne s'inscrivent pas, cela signifie qu'ils n'ont pas donné leur approbation, car les analystes commerciaux ne peuvent pas simplement la radier et la donner au développeur. Je sais que tout est traité, que tout doit être approuvé , etc. La plupart de ces choses sont comme de grosses affaires, n'est-ce pas ? L'entreprise s'adresse donc à l'analyste commercial va voir les parties prenantes et leur dit qu'elles présentent le document d' exigence de chaque scénario qu'elles ont écrit et pour qu'elles l'approuvent. Ce processus est ce que nous appelons une session de jab, une session de jab JAD C'est donc lors de la session de jab que l'entreprise signe. Ils signent donc et donnent leur approbation également Ils pourraient également revenir et dire, devinez quoi ? Ce scénario présenté dans le document d' exigence, je ne veux pas, ou ils pourraient dire, peut être réalisé de cette façon. Ils font donc des allers-retours. Ainsi, une fois que tout est terminé et approuvé, l'entreprise, l'analyste commercial, est chargée signer les documents relatifs aux exigences et de les envoyer au développeur En outre, ils vous en envoient également une copie, à vous, l'ingénieur en assurance qualité. Ainsi, une fois que le développeur a développé l'ensemble du code, vous avez maintenant documents relatifs aux exigences commerciales dans votre tableau, vous en avez la copie. Alors maintenant, votre rôle est le s'il comporte peut-être 1010 exigences, n'est-ce pas ? Votre rôle est de trouver des idées pour tester ces dix histoires. Et je vais vous expliquer comment vous pouvez les tester plus tard, mais... Votre rôle est le suivant : s'il dix scénarios dans les exigences contient dix scénarios dans les exigences approuvées, votre rôle est de savoir comment capturer ces dix histoires ? Comment testez-vous ces dix histoires ? Hein ? Donc, dans Waterfall, comme je l'ai mentionné Waterfall, c'est tout, de A à Z. Ainsi, l'anal Developer the Business écrit l'ensemble des exigences relatives aux user stories. Le développeur teste tout, développe une partie du développeur développe tout, les dix user stories au complet. Vous testez qui vous rédigez les scénarios de test et vous testez les dix histoires complètes, puis le déploiement et la production sont mis en production. Ainsi, vous mettez en production l'ensemble de la fonctionnalité , du logiciel ou de l'application en une seule fois. Tout est donc fait instantanément. Alors maintenant, quel est l' inconvénient, n'est-ce pas ? L'inconvénient est donc qu' il n'est pas flexible, n'est-ce pas ? Supposons donc que le développeur développe l'application dans son intégralité. Et l'entreprise l'analyste commercial doivent approuver ce que le développeur a développé, car même le développeur le développe, il ne va pas simplement le mettre en production, il doit l'approuver. s'agit donc de l'analyste commercial ayant l'autorité des parties prenantes qui approuvent cette demande. Et disons qu'il y a une erreur. Le mot de passe comportait peut-être huit à dix caractères. Maintenant c'est le moment de les faire changer d'avis. Les entreprises ont changé d'avis et ont dit qu'elles voulaient porter le score à 11 contre 12. Vous savez, ou des choses comme ça, c'est comme si c'était très complexe, car une fois qu' une application développée du début à la fin, il est difficile de commencer à changer les choses. Ça ne donne pas de place. Vous savez, et parfois, je vais expliquer, vous savez, la différence entre les chutes d'eau et âge parce que vous savez, lorsque vous apprenez quelque chose ou que vous vous habituez à quelque chose, vous continuez à vous améliorer, plus vous le faites. Plus vous en faites, plus vous vous améliorez. Ainsi, en cas de chute d'eau, il n' y a pas de marge d'amélioration , car c'est comme si l'entreprise et les parties prenantes réfléchissaient à l' ensemble des exigences. Hein ? Et les développeurs l'ont développé, vous l'avez testé, vous appréciez la production. n'y a pas de place pour cette créativité, encore une fois, je sais quoi. J'y ai pensé de cette façon. Je veux le faire de cette façon. Tu sais ? Donc, après tout est fait instantanément. Ainsi, une fois le décès et une fois que B B et les parties prenantes participent à la séance d' élucidation, ils rédigent l' ensemble des exigences À l'approbation, le développeur développe tout, vous testez tout et vous le mettez en production. n'y a donc pas de place pour cette créativité qui fonctionne de cette façon, vous savez, donc il y a une différence entre Waterfall et Agile, mais je vais expliquer Agile plus tard, mais en termes de cascade, c'est comme si fonctionne de cette façon, vous savez, donc il y a une différence entre Waterfall et Agile, mais je vais expliquer Agile plus tard, mais en termes de cascade, tout était fait de A à Z, du début à la fin, le développement est effectué, les tests sont effectués et tout est réuni, poussé à C'est donc un peu une idée de cascade. Je vais expliquer Agile dans le chapitre suivant. 10. Qu'est-ce que l'agilité: Pour la deuxième méthodologie, je vais expliquer l'agilité. En mode Agile, cette méthode est plus populaire et plus courante, et c'est ce que de nombreuses équipes utilisent ou adoptent aujourd'hui parce qu'elles ont l' impression qu' en termes de logiciels, elles développent des applications logicielles plus efficaces et de meilleure qualité que, vous savez, la cascade traditionnelle. N'oubliez pas que je pensais que cette cascade avait commencé plus tôt, mais maintenant, c'est comme si de nombreuses entreprises adoptaient l'agilité . Rappelez-vous donc que j'ai également expliqué le SDLC et les différentes phases du SDLC, phase d'exigence, la profondeur, les tests, le déploiement, la maintenance, toutes ces phases, et aussi les chutes d'eau, et aussi les chutes d'eau, comme la façon dont ces phases sont liées aux chutes d'eau, comme si tout était fait de zéro à la fin en une seule fois comme si tout était fait de zéro à la fin Maintenant, dans Agile, il y a toujours ces phases, n'est-ce pas ? Donc, la phase d'exigence, la phase de développement, la phase Q way, la phase de déploiement, la phase de maintenance. Waterfall et Agile ont ces phases. Mais la seule différence réside dans la façon dont ces phases sont utilisées, n'est-ce pas ? Je vais maintenant expliquer Agile. Donc, dans Agile, n'oubliez pas je vous explique que quelqu'un qui s'assoit avec les parties prenantes ou les dirigeants de l' entreprise est ce que nous appelons les analystes commerciaux et que, dans Agile, on les appelle les chefs de produit. Product owners, n'est-ce pas ? Alors, que sont les analystes commerciaux, les propriétaires de produits IGL Maintenant, souvenez-vous également que j'ai mentionné que le document qu'un analyste commercial produit juste après avoir discuté avec les parties prenantes s'appelle un document d' exigences commerciales Mais dans Agile, oui, cette réunion a toujours lieu, n'est-ce pas ? Ils continuent donc à s'asseoir, le concepteur du produit discute avec parties prenantes, directement dans le cadre d'Agile Mais ce document s'appelle une user story, n'est-ce pas ? C'est donc toujours le même processus que celui que j'ai mentionné, mais c'est simplement la façon dont ils le font. Et maintenant, cette histoire d'utilisateur. L'agilité est donc divisée en phases, n'est-ce pas ? Alors souvenez-vous que j'ai dit ils avaient développé l' ensemble des exigences, peut-être les dix scénarios dans un seul document. En Ag, D se fait différemment. Supposons donc qu'ils souhaitent développer et adapter une application complète. Donc, ce qui se passe dans Ag, c'est qu'au début, ils vont décomposer l'application. Ils vont demander : quelle est la plus haute priorité ? Qui détermine la priorité la plus élevée ? Le business ? Quand je parle de l'entreprise, je veux dire les parties prenantes, les responsables et le responsable complexe de Walmart, par exemple, ils peuvent voir qu'avec le propriétaire du produit, deuxième devin, je souhaite développer cette application Je souhaite développer le logiciel. Ensuite, le PO, le Paton qui a l'entreprise. Quelle est votre priorité absolue dans le logiciel ? Tout d'abord, vous devez avoir une page de journalisation. Le client doit d'abord être en mesure de se connecter. C'est la plus grande priorité. Le bon de commande va être interrompu et utilisera d' abord la fonctionnalité de connexion. Alors ce sera le second. Ils devraient être capables d'ajouter des éléments à leur c. Ensuite, le PO entame la deuxième phase. Ensuite, la troisième phase, vous devriez être en mesure de payer au moment où vous voulez payer, de saisir les informations de paiement. L'entreprise indique donc au propriétaire du produit en fonction de sa priorité, laquelle est celle qui vient en premier. Je vends une application, mais l'application est divisée en plusieurs phases, n'est-ce pas ? Lequel est donc une priorité absolue. L'entreprise indique donc au propriétaire du produit lequel vient en premier ? Qu'est-ce qui est le plus important pour eux en premier lieu pour que l'application soit créée ? Une fois que cela est déterminé, le bon de commande commence par écrire des récits d'utilisateurs pour la fonctionnalité de connexion. Vous n'allez donc pas écrire, souvenez-vous à quoi ils servent, ils écrivent tout en même temps. Connaissant Agile, ils écrivent abord uniquement les user stories pour la fonctionnalité de connexion. L'user story pourrait donc avoir quatre scénarios. Peut-être le nom d'utilisateur et le mot de passe, vous devriez avoir le costume, les types de mots de passe qui conviennent à d'autres choses une fois le PO a écrit les scénarios dans une histoire utilisateur. Supposons par exemple que, comme je l' ai mentionné, la page de connexion puisse la page de connexion avoir quatre user stories, n'est-ce pas ? Les user story ne sont donc que des scénarios, n'est-ce pas ? Il est donc destiné à une user story qui peut comprendre un identifiant utilisateur. Descriptif. Alors, quel d'utilisateur pourrait être un nom d'utilisateur, n'est-ce pas ? Nom d'utilisateur de la fonction Ername. La description peut être qu'un utilisateur doit être en mesure de saisir son ID utilisateur pour accéder à l'application. Cela pourrait aussi être un critère d'acceptation, n'est-ce pas ? Je vous propose également des éléments qui constituent une user story. user story possède donc les deux caractéristiques qui constituent une bonne user story. Alors, qui est responsable de la rédaction de l'histoire de l'utilisateur, le propriétaire du produit. incombe donc aux responsables du produit de dire : « OK, cette histoire d'utilisateur est qualifiée pour être transmise à l'entreprise afin qu'elle l'approuve , la voie ou qu'elle l'examine ». Il doit donc y avoir quelques certitudes, une description du résumé de l'utilisateur, critères d'acceptation, vous savez, ce que l'histoire devrait impliquer, n'est-ce pas ? Donc, une fois que c'est comme si c'était déterminé qu'une fois l'histoire utilisateur, le propriétaire du produit l' a trouvée, le producteur a créé ces histoires utilisateur Ensuite, ils l'apportent à l'entreprise. Alors souvenez-vous que le produit a probablement quatre histoires d'utilisateurs, non ? Il a donc divisé toutes les fonctions de connexion en quatre scénarios. Donc, l'ID utilisateur, le mot de passe, sommet, les types de caractères du mot de passe, et tout ça. Ils l'apportent à l'entreprise. L'entreprise dit : OK, j'adore ça, non ? C'est exactement ce que je veux. Ils donnent leur approbation, non ? Vous vous souvenez que dans Water Fault, j'ai dit d'une session de jazz en mode agile, il n' y a pas de session de vent parce que ce ne sont que de petits morceaux, n'est-ce pas ? Dans Waterfall, il y a une grosse session de ga parce qu'elle comprend l' ensemble des scénarios, n'est-ce pas ? Mais dans Waterfall, Agile se déroule en plusieurs phases, y a donc pas besoin de session de coup de vent L'entreprise approuve donc. Lorsqu'ils l'approuveront, assistez la même phase que celle que j'ai mentionnée avec le SDLC Ils l'envoient au développeur. Le développeur récupère les user stories, vous savez, il y travaille. Ils te l'envoient. Maintenant, vous ne devez pas préparer l'ensemble de la demande. seule chose à laquelle vous vous préparez est de tester uniquement la fonctionnalité de journalisation. C'est tout pour le moment. Une fois que la fonctionnalité de journalisation, une fois que vous l'avez testée chez le développeur, l'a développée ici, vous testez maintenant la fonctionnalité de journalisation. Ensuite, ils l'envoient pour le déploiement, directement et pour la maintenance. Ensuite, le « non » décroche le second. La deuxième phase et la deuxième phase pourraient consister à vérifier le scanner, n'est-ce pas ? Cela signifie donc que vous pouvez permettre aux clients de se connecter à l'application ? Je veux dire, pas la connexion à l'application. Peuvent-ils ajouter des objets à leur chat et à toutes ces choses, n'est-ce pas ? C'est donc la deuxième fonctionnalité. C'est pourquoi c'est comme un aj qui fonctionne par phases, n'est-ce pas ? Je veux dire qu'à certaines de ces phases, il s'agit d'un processus complet, car maintenant nous pouvons arrêter de parler de Scrum et de toutes ces choses comme différents frameworks dans le cadre d'Agile Mais l'agilité en général se fait par étapes, n'est-ce pas ? cascade est donc une énorme application, comme toute autre application, et c'est une cascade. Dans ce cas, l'agilité, c'est comme par phases. Tout est décomposé en phases, mais ils adoptent toujours toutes les étapes du SDLC, n'est-ce pas ? Donc, toutes les étapes telles que la phase d'exigence, la phase de développement, phase Q way, la phase de déploiement et la phase de maintenance ? Waterfall et agilité vont de pair, mais comment se différencient-ils, n'est-ce pas ? Ainsi, dans les chutes d'eau, tout se développe, de la croûte à la finition. L'agilité, vous savez, se fait par phases. Ils font donc la phase un, la phase deux, la phase, jusqu'à ce que l' application complète soit développée. Et au fur et à mesure qu'ils effectuent les phases, ils développent les tests, ils les mettent en production, développent des tests, passent à la production. Certaines fonctionnalités apparaissent donc progressivement, progressivement, progressivement jusqu'à ce que l'ensemble de l'application soit développé. Maintenant, quels sont les avantages, n'est-ce pas ? Ch, pourquoi les gens utilisent-ils j parce que cela laisse place au changement. Supposons que dans la première phase, nous développons la deuxième page de connexion, les clients peuvent ajouter au c. Mais vous savez, l'entreprise et le bon de commande rédigent l'histoire de l'utilisateur. Le développeur est en train de le développer. Mais les entreprises disent : devinez quoi, j'ai changé d'avis, non ? Ils n'ont pas besoin de modifier l' intégralité de l'application. Ils n'ont pas besoin de modifier la fonctionnalité de journalisation. Ils n'ont pas besoin de changer cette phase. Donc, quelle que soit cette phase , en ajoutant des éléments à leur c, ils peuvent simplement y aller et le modifier Cela laisse donc de la place pour l'adaptation, l'application pour l'adapter à. Cela permet de s'améliorer. Supposons donc la première phase, vous écrivez le journal, vous créez la page de journalisation, vous développez la page de journalisation. Deuxième phase, ils ajoutent des objets à la casquette. Plus vous y travaillez, plus vous connaissez l'application. À la fois la mort, les deux et la méthode Q. Parce que l'entreprise peut aussi écrire de meilleures histoires maintenant, parce que maintenant, plus vous travaillez sur une application, développez par étapes, vous savez, tout le monde discute, en parle, les idées circulent. Parce que cela laisse désormais la place à des logiciels plus efficaces. Parce que maintenant, c'est comme si tout le monde travaillait dessus, vous savez, nous apportons des changements. Je veux dire, nous sommes en train de le faire. Donc, lorsque vous continuez à le faire, vous savez, vous continuez à vous améliorer, vous savez, plutôt que de le faire en cascade, la seule chose que vous faites est de développer, car toutes les exigences ont déjà été rédigées, vous ne pouvez donc rien changer. Tout part des exigences. Ainsi, une fois l'exigence rédigée, il n'y a plus de place pour les idées, car le développeur n'a pas besoin d'en avoir une idée, il fait simplement ce que les exigences stipulent. Mais dans Agile, vous savez, l'exigence n'est pas complètement écrite, elle est simplement écrite par étapes. Maintenant, l'entreprise et le PO peuvent deviner ce que dans la deuxième phase, vous savez, parce qu'ils ont travaillé sur la première phase, vous savez, phase deux, d'autres idées peuvent commencer à arriver et à changer. Vous savez, les exigences peuvent commencer à changer. Vous savez, les user stories peuvent commencer à changer, vous savez, et cela permet de créer des logiciels plus efficaces, larges et plus encore, une fois qu'ils s'assoient, les analystes commerciaux et cette entreprise s'assoient dans une pièce et rédigent le tout, ils rédigent l'intégralité de l' exigence, n'est-ce pas ? Il n'y a donc pas de place pour cette idée. C'est donc ce qu'ils ont pensé à ce moment-là. C'est ce qu'ils vont faire. Mais chez AJ, ils ont plus de temps pour continuer à réfléchir, s'améliorer et à faire des choses comme ça. C'est pourquoi de nombreuses entreprises commencent à adopter Aj. Et en termes d'Aj, cela coûte plus cher parce que l'intérim, dans ma carrière, c'est comme les moyens les plus importants Waterfall une fois l'application développée, n'est-ce pas ? Ainsi, lorsque l'application est écrite, les exigences commerciales sont rédigées, le développeur a développé l'application, puis la clé supérieure, juste pour que vous arriviez pour trois ou quatre mois Cependant, testez l'application et c'est tout, non ? Vous avez donc beaucoup à faire vous avez toutes ces exigences nécessaires pour savoir, comprendre et écrire, préparer vos documents et savoir comment les tester sous une forme ou une autre. Mais dans Agile, vous savez, dès la première phase, l' assurance qualité est déjà impliquée, vous savez, donc parce que vous allez tester toutes ces phases. Ainsi, l' équipe de est impliquée, l'équipe d'assurance qualité est impliquée, le produit neuf est impliqué. C'est donc plus cher, non ? Tout le monde est impliqué dès le départ. Donc ça le permet, tu sais, mais ça a ses avantages. Mais en termes de coût, Agile est également plus cher. Mais je veux dire, les entreprises insistent sur l'importance d'adopter l' Agile parce que, vous savez, cela permet de meilleures applications logicielles, cela permet la créativité, il permet de commettre des erreurs, vous savez, donc c'est différent entre la cascade et l'agilité. 11. Qu'est-ce que l'assurance qualité: J'en viens maintenant au grand sujet. Qu'est-ce que l'assurance qualité, n'est-ce pas ? Qu'est-ce qu'un ingénieur en assurance qualité ou en tests ? Vous pouvez donc parfois entendre le terme assurance qualité ou le terme test. Vous savez, c'est la même chose, ou vous pourriez entendre le terme ingénieur en assurance qualité. Alors, qu'est-ce qu'un ingénieur en assurance qualité, un testeur ou un QA avec certitude ? Ainsi, un ingénieur en assurance qualité ou un testeur, vous savez, est un professionnel qui intervient dans le cycle de vie du développement logiciel teste l'application. C'est donc ton rôle. Comme je l'ai mentionné dans le cours, votre rôle est de tester l'application. Donc, vous savez, je vais maintenant expliquer également les différents types de tests. Je vais vous expliquer quels sont les documents ou artefacts dont vous avez besoin pour faire vos tests, votre travail ou votre rôle, vous savez, donc je veux dire, l' assurance qualité est importante, n'est-ce pas ? C'est vraiment énorme, comme s'il s'agissait de différents types de tests, différents types de logiciels. Vous pourriez en avoir besoin, et je n' essaie pas de le dire pour vous effrayer, mais juste pour vous intéresser, c'est une aide-soignante, non ? Vous pourriez avoir une vie, un aide-soignant, vous savez, en tant qu'ingénieur en assurance qualité Ce n'est pas quelque chose de passif, tu sais, c'est exactement la même chose, non. de nombreuses entreprises qui ont des ingénieurs d'assurance qualité, selon l'entreprise, votre rôle peut être différent, mais je pense que l'essentiel est le même, ce que je vais vous expliquer. Je vais vous donner les bases de l' ingénieur en assurance qualité, n'est-ce pas ? C'est donc la base de ce qui sera similaire dans tous les domaines. Maintenant, ce qui peut être différent d' une assurance qualité, c'est la technologie, n'est-ce pas ? Certains QA peuvent donc dire qu'ils ont besoin d'un test UAT et je vais expliquer ce que c'est Ils pourraient donc dire : j'ai besoin d' un testeur d'automatisation. J'ai besoin d'un testeur pour cela, ou j'ai encore besoin d'un testeur capable de tester le XML. J'ai besoin d'un testeur capable de tester cette application. Alors maintenant, vous n'avez pas besoin de tout savoir, n'est-ce pas ? Je ne suggère pas de vous conseiller de tout savoir parce que la technologie est vraiment énorme, elle est vraiment énorme. Il vous suffit donc de vous concentrer sur vos propres activités sur lesquelles vous vouliez vous concentrer et de bâtir votre carrière à partir de celles-ci. Peut-être pourriez-vous passer à autre chose afin d' apprendre d'autres choses. Vous savez, mais je pense que ce que je vais vous expliquer, vous donner les bases d'un ingénieur en assurance qualité. À partir de là, vous pouvez commencer à ajouter des éléments comme, vous savez, ajouter des logiciels ou ajouter différents types de balances à votre assiette, mais je veux dire, en général, je pense que le rôle de l' ingénieur en assurance qualité est de tester. Vous savez, je pense que c'est le début et la genèse de toute l'histoire, comme le fait de pouvoir tester une application, casser une application pour trouver des défauts. Parce que si vous travaillez et qu'ils vous envoient trucs, que vous testez et que vous levez le pouce, rien d'erreur, ils vous regarderont et se demanderont si vous l'avez vraiment testé correctement, n'est-ce Donc, celui que vous vous assurez que les tests, nous trouvons des défauts ou, comme je l'ai dit, des erreurs, des défauts , des bogues, et comment procédez-vous corriger ces erreurs, défauts ou bogues, n'est-ce pas Ce sont donc toutes les choses qui votre responsabilité en tant qu' ingénieur en assurance qualité, testeur de barres obliques Nous allons donc examiner un peu plus en profondeur, vous savez, quels sont les artefacts ? Quels sont les documents, la façon dont vous les créez, comment faites-vous les tests ? Quels sont les différents types de tests, vous savez, toutes les règles et les responsabilités, la tâche quotidienne de l'ingénieur en assurance qualité. 12. Où se situe l'assurance qualité dans Agile: Alors, quelle est la place réelle de l'assurance qualité dans le SDLC Agile Waterfall, n'est-ce pas ? Et je pense que vous devriez probablement connaître cette réponse maintenant. Mais, vous savez, pour une assurance qualité, vous savez, comme je l'ai mentionné, votre rôle est en fait de tester l' application, n'est-ce pas ? Donc, dans le cycle de vie du développement logiciel et dans Water Fast Lash Agile, vous savez, où vous situez-vous ? Vous participez à la phase de test, n'est-ce pas ? Ainsi, en matière d'assurance qualité, de processus de cycle de vie du développement logiciel , en cascade ou en mode Agile, vous êtes en phase de test. Ainsi, lorsqu'une application est écrite, vous savez, sur la base d'un document commercial ou de données de stockage utilisateur, le développeur développe l'application Vous êtes en phase de test, la phase de test ne tourne que autour de vous, n'est-ce pas ? Avant le déploiement et la maintenance, et pendant la phase de test, beaucoup de choses peuvent se passer. Comme vous êtes les leaders, vous êtes les patrons. C'est vous qui prenez l'autorité. Il y a tellement de responsabilités. Et je ne dis pas cela pour vous effrayer, mais pour vous préparer ou pour vous faire comprendre dans quelle phase, ce logiciel vous attend. Imaginez ce logiciel complet qui sera utilisé par X clients dans le cadre d' une production réelle, à ce stade, que ce soit en cascade ou en mode agile. Donc, en cascade pendant trois ou quatre mois, toute cette application est à votre charge. Et je ne parle pas simplement de vous parce que vous avez souvent plusieurs méthodes Q, exemple quatre ou cinq méthodes Q pour travailler sur un projet, n'est-ce pas ? Vous en êtes donc tous responsables pendant ces quatre ou cinq mois. Donc, vous avez beaucoup à faire en termes de gens qui vous regardent, comme, vous savez, si un défaut est oublié, je veux dire, cela pourrait être un problème comme, vous savez, pourquoi cela se fait-il que cela ait été oublié, n'est-ce pas ? Parfois, parce qu' une fois que vous l'avez raté et que l'entreprise l'a raté, je vais expliquer ce qu'est l'UAT, c' est-à-dire le test commercial, mais une fois que vous manquez un problème , mais une fois que vous manquez un problème l'entreprise le rate, qu'il passe en production et qu' il échoue, alors ils disent : « La première fois que je vais poser cette question, c'est qu'ils ont fait le test d'assurance qualité ». C'est vrai. Je ne dis donc pas pour vous effrayer, mais je dis que c'est un gros problème. C'est pourquoi de nombreuses Q Ways obtiennent plus de six chiffres en raison de la responsabilité de ce qu'elles ont à faire. Et c'est amusant, non ? C'est juste, tu sais, je vais te montrer, tu sais, comment te préparer, comment être mieux préparé. En tant qu'ingénieur en assurance qualité, afin que la plupart de ces erreurs ne se produisent pas. Tu sais, tu te prépares, tu t' installes, tu sais, et tu fais bien ton travail. Vous savez, ce n'est pas quelque chose qui devrait vous effrayer ou quoi que ce soit d'autre, mais c'est une énorme responsabilité, vous savez, et c'est quelque chose que vous voulez être capable d'exécuter parce que vous avez beaucoup de choses à faire mais c'est une énorme responsabilité, vous savez, et c'est quelque chose que vous voulez , par exemple vous avez beaucoup d'obligations , vous savez, une fois une application et une application que tant de personnes utiliseront, n'est-ce pas ? Vous savez, croire que je l'ai testé, c'est vrai, vous le verrez en production, je l'ai testé et cela fonctionne. Tu sais, ça te fait du bien. Cela vous donne confiance en vous, du genre « OK, j'ai travaillé là-dessus, non ? Et cela peut devenir positif ou négatif. Je veux donc vous préparer à comprendre où, lorsque vous arrivez à cet endroit, vous faites du bon travail et, vous savez, votre patron est content, vous savez, entreprise est heureuse, vous savez, que vous avez un logiciel performant en production. 13. Types de tests: Donc, dans cette vidéo, nous allons parler des types de tests, n'est-ce pas ? Il existe donc différents types de tests. Donc ce que je veux dire, les différents types de tests sont comme ceux que vous testez réellement, n'est-ce pas ? Je vais donc parler d' autant de types de tests dans ce cours, vous savez, ventiler chaque type de test. Donc, en tant qu'assurance qualité, vous savez, et je ne dis pas que vous devez être responsable ou que vous devez tout savoir ou être capable d' effectuer les différents types de tests parce que, comme je l'ai dit, assurance qualité est importante, vous savez, vous devriez simplement vous concentrer sur quelques types de tests. Mais je vais vous expliquer la plupart des choses. Et je vais vous expliquer celles que vous devriez être capable de connaître, vous savez, pour faire votre travail et avoir une carrière, n'est-ce pas ? Parce qu'il existe de nombreux types de tests, mais ceux qui visent à l'égalité sont les types de tests typiques qu'une fois qu' un responsable de l'assurance qualité devrait être en mesure d'effectuer. C'est vrai. Mais parfois, d'autres types tests peuvent être plus complexes et nécessiter certaines compétences pour être exécutés, etc. et nécessiter certaines compétences pour être exécutés Mais je vais aussi les expliquer, mais je vais aussi vous dire sur lequel vous devez vous concentrer pour avoir un poste, si vous vous lancez dans l'assurance qualité, si c'est quelque chose que vous avez un peu d'expérience et que vous voulez, ne rien apprendre pour obtenir un emploi et faire votre travail avant de commencer à approfondir vos connaissances. Je vais donc vous expliquer les différents types de tests et celui sur lequel je pense que vous devriez vous concentrer. 14. Tests fonctionnels: Le premier type de test et le type de test le plus important est donc le test fonctionnel. Alors, qu'est-ce que le test fonctionnel ? Je veux dire, les tests fonctionnels sont tout ce dont j'ai parlé pour tester les fonctions de l'application ou du logiciel. Je vais donc revenir à l'exemple de Walmart. Donc, quand j'ai dit que vous voulez développer ils veulent développer une application de A à Z. Et par exemple, ils veulent vérifier l'écran de journalisation, vous pouvez ajouter des éléments à votre carte, vous pouvez payer et toutes ces choses. Ce sont toutes des fonctions de l'application, ce que l'application est censée faire ou ce qu'une application est censée exécuter, n'est-ce pas Donc, la fonction est généralement du genre, ok, puis-je entrer le nom d'utilisateur et le mot de passe et le soumettre ? C'est une fonction, non ? Puis-je ajouter des objets à ma voiture ? C'est une fonction. Puis-je accéder à une application ? C'est une fonction, non ? Ce sont donc toutes les fonctions d'une application. C'est donc en fait The I n' utiliserai aucun pourcentage spécifique, mais c'est là la majeure partie du rôle de l'ingénieur en assurance égalité. Test du fonctionnement de l'application. Et je vais vous expliquer comment testez-vous cela ? Je veux dire, pour que vous puissiez tester cela, vous devez vous préparer à tester ces fonctionnalités, n'est-ce pas ? Mais les tests fonctionnels sont majoritairement l'œuvre d'un ingénieur en assurance qualité. Tester le fonctionnement d'une application. Maintenant, l'application peut être très complexe, non ? Nous avons différents autres types de tests que je vais expliquer. Mais en résumé, les tests fonctionnels sont très importants pour qu'un ingénieur en assurance qualité puisse les effectuer. Je vais donc vous montrer comment effectuer ou comment tester 15. Test de la boîte noire: Notre deuxième type de test est donc Black Box. Alors, qu'est-ce que le test Black Box ? Les tests Black Book sont identiques aux tests fonctionnels. Je ne vais pas trop m'attarder là-dessus, mais Black Box est également un autre terme utilisé pour désigner les tests fonctionnels. Donc, c'est exactement la même chose tester les fonctions d'une application, vous savez, les fonctionnalités et autres choses de ce genre. Vous pourriez donc utiliser boîte noire ou les tests fonctionnels de Black Box, pareil. 16. Test de la boîte blanche: Le type de test suivant est donc le test en boîte blanche. Les tests sur le bus blanc sont donc principalement des tests effectués par les développeurs, sorte que les ondes Q ne sont pas responsables de ces tests. Alors, qu'est-ce que le test des bus blancs ? test en boîte blanche consiste à tester le code du code de l'application. Supposons donc que le développeur développe une application et qu'il écrit le code. Habituellement, ils pourraient demander à un autre développeur de tester ce code, non ? Vous souhaitez donc tester ce code pour certaines raisons. Vous voulez vous assurer d'utiliser le bon type de code, n'est-ce pas ? Vous utilisez le code est conforme aux normes. Donc, en gros, en guise de Q, vous testez les fonctions, n'est-ce pas ? Vous n'allez pas dépendre ou vous n' allez pas regarder les codes et tester non. Vous êtes en fait comme si vous testiez le front-end. Donc, quand je suis dans le front-end, c'est comme dans l'application, vrai, vous faites des tests manuels. Donc, ce cours est un test manuel. Donc, vous entrez le nom d'utilisateur, vous entrez le mot de passe, vous cliquez sur un mix. Test en boîte blanche : vous testez le développeur teste en fait le code lui-même, n'est-ce pas ? Donc, tous ces scripts S Sharp et Java, et toutes ces choses, comme si le développeur testait réellement ces codes. Ils le font donc avant de l'envoyer au QA. tests en boîte blanche sont donc aussi ce que vous appelez des tests unitaires. Donc vous allez utiliser ça, je veux dire, ils n'utilisent pas vraiment les tests en boîte blanche, vous les appelez tests unitaires. Les tests unitaires sont donc indispensables, est-ce pas, les développeurs font toujours des tests unitaires. Ainsi, une fois que le développeur a développé l'application, l'équipe responsable effectue son propre test unitaire. Ils testent donc l'application, le code, n'est-ce pas, qu'ils utilisent pour écrire l'application. Une fois que ce code est correct, ils l'envoient au service d'assurance qualité pour effectuer vos tests fonctionnels ou vos tests de boîte noire ou autres choses du genre, donc toutes sortes de tests. Mais au début, comme lorsque le développeur que vous connaissez écrit le code comme s'il effectuait ses propres tests unitaires ou des tests en boîte blanche pour le tester, particulier en s'assurant en particulier en s'assurant que l'application est conforme aux normes, etc. Ensuite, je l' enverrai au QA U qui n'effectuera pas vos autres types de tests. Et je vais vous expliquer plus en détail quels autres types de tests vous serez particulièrement chargé. Pourquoi avez-vous mentionné les tests unitaires, c'est parce que, vous savez, c'est un type de test, n'est-ce pas ? Et c'est quelque chose qui revient tout le temps, vous allez entendre tout le temps, comme si vous vous demandiez probablement, d' accord, qu'est-ce que les tests unitaires ? Qu'est-ce que le test en boîte blanche ? C'est donc ce que sont les tests unitaires. Vous n'en êtes pas responsable. C'est l'équipe des sourds qui en est responsable. Mais c'est un fait, une sorte de test dans le SDLC. Comme vous le savez, de nombreuses entreprises, comme de nombreux développeurs, doivent effectuer des tests unitaires pour tester l'application Je ne vais donc pas trop m'attarder là-dessus, car c'est surtout pour les équipes de la mort qui savent comment s'y prendre. Il s'agit principalement de tester les codes. Vous savez, c'est très complexe en termes de test des fonctionnalités. Donc tu n'es pas vraiment responsable. Nous voulons simplement nous assurer que cela a été fait. Je veux dire, prenez vos responsabilités de vous en assurer, mais ils vous le diront. Nous avons fait les tests unitaires et tout est ce qu' les tests unitaires et tout est ce il faut, et ils vous les enverront pour que vous commenciez à faire votre propre type de test. Les tests fonctionnels, les tests sur le bus noir, sont donc de votre seule responsabilité. 17. Tests ad hoc: Les tests pour adultes sont un peu aléatoires, non ? J'ai donc mentionné d'une certaine façon que tout doit être organisé, vous savez, mais lorsque vous faites des tests pour adultes, cela vous permet d'être juste, vous savez, juste au hasard, vous savez, nombreuses fois, ce n'est pas qui ne constitue pas l' essentiel de vos tests. Vous savez, ce n'est pas là que vous élaborez le plus de stratégies lors de vos tests Là où vous élaborez le plus de stratégies, ce sont vos tests fonctionnels, vos tests to N, Black Bus, UAT, vous savez, Adduct, c'est juste, vous savez, Vous pourriez simplement tout examiner et voir si tout fonctionne. donc ce que j'ajoute. C'est ce que sont les tests d'adduction, vous savez, et c'est également la responsabilité d'un service d'assurance qualité Le QA est donc également chargé d'effectuer les tests d' adduction Ainsi, lorsque l'adduct entre en place, c'est souvent là que des tests fonctionnels, des tests sur le bus noir ont été effectués, des tests N à N ont été effectués, tests N à N ont été effectués, tests de régression ont été effectués Ensuite, vous faites des tests d'adduction juste pour vous assurer, avant de vous assurer que tout est fait, tout fonctionne correctement. 18. Test de régression: Un autre type de test est le test de régression. Les tests de régression sont donc un autre type de test très important, non ? Alors, qu'est-ce qu'un test de régression ? Les tests de régression ont donc lieu une fois qu'une application a été testée. Donc, une fois que vous avez effectué vos tests fonctionnels, que vous avez effectué vos tests fonctionnels ou noirs, que vous avez effectué vos tests N à N, vous trouvez des défauts, n'est-ce pas ? Lorsque vous trouvez des défauts, je vais maintenant vous expliquer comment fonctionne le processus ou le cycle de vie des défauts. Donc, vous savez, lorsque vous testez une application, vous constatez immédiatement un défaut. Cela dépend alors de quel type de défaut s'agit-il ? Est une priorité élevée, une priorité faible, une priorité moyenne, une faible. haute priorité est donc déterminée par l'analyse commerciale menée avec la direction de l'entreprise. Donc, si vous ne pouvez pas vous connecter à une application, si un utilisateur ne peut pas se connecter à une application, l'entreprise a indiqué que la page de connexion était hautement prioritaire. Tu te souviens quand je dis que les Aj veulent d'abord travailler sur ce visage. Donc, s'ils veulent d'abord travailler sur ce visage, vous savez que c'est une priorité absolue. Maintenant, si vous y trouvez un défaut, vous savez que si vous entrez le nom d'utilisateur et le mot de passe et cliquez sur le sommet, vous ne pouvez pas vous connecter. Vous savez alors que c'est une priorité absolue car cela empêche le client de se connecter au système. C'est donc une priorité absolue. Tout problème que vous rencontrez, par exemple si le bouton d'envoi ne fonctionne pas, si le mot de passe est sensible aux majuscules minuscules ou si le nombre de caractères est plus long , il s'agit d'un défaut prioritaire et minuscules ou si le nombre de caractères est plus long, il s'agit d'un défaut prioritaire qui doit être corrigé. Donc, une fois que vous avez découvert qu' il y a un défaut, il y a une roue d'entrée défectueuse, n'est-ce pas ? Je vais donc vous montrer certains des artefacts ou des documents d' un rapport de défaut. En quoi consiste donc un défaut ou une erreur ? C'est donc un peu comme l'identifiant du défaut, la description. La description indique donc l'erreur à laquelle vous êtes confronté, n'est-ce pas ? La description peut être que lorsque je clique sur le bouton du sommet, rien ne se passe, n'est-ce pas ? C'est une description, puis elle sera également accompagnée des étapes inattendues. Donc, les étapes réelles sont, vous savez, ce qui se passe réellement. Ainsi, lorsque vous cliquez sur le bouton du sommet, rien ne se passe. Quel est le résultat attendu ? Les résultats attendus sont censés connecter le client lorsque je clique sur le bouton Summit , n'est-ce pas ? Vous pouvez également agir lors de l'envoi de la capture d'écran. La capture d'écran est donc comme des photos de ce que vous dites. Et aussi des étapes à reproduire car si vous l'envoyez simplement au développeur pour lui dire que ok, c'est un défaut, c'est une erreur à laquelle je suis confronté. Le pass sur lequel je clique sur le bouton du sommet ne fonctionne pas. Le développeur travaille sur tellement de choses, non ? Donc, pour gagner du temps, vous souhaitez mettre des étapes à reproduire. Donc, les étapes de reproduction ou ce que je veux dire les étapes de reproduction, c'est : qu'avez-vous fait ? Pour atteindre cette flèche, non ? J'ai donc d'abord saisi le nom d'utilisateur. première seconde, je saisis le mot de passe, je pensais avoir cliqué sur sommet, et moi et quand j'ai cliqué sur sommet, rien ne s'est passé Telles sont donc les mesures que vous avez prises. Vous devez donc inclure tout cela dans le rapport de défaut. Et je vais vous montrer, vous savez, qu'un document signalant un défaut élevé ressemble à, vous savez, mais c'est juste que les poumons viennent de voir à quel point c'est un défaut et comment vous le documentez. Donc, une fois que vous l'avez fait, vous l' envoyez au développeur, retrouvez le défaut, changez le statut en ouvert, n'est-ce pas ? Ainsi, une fois que vous l'avez envoyé au développeur, le statut est nouveau. Chaque défaut a son statut et son avantage, c'est donc un nouveau statut à parité élevée. Le développeur le choisit, change le statut pour ouvrir, travaille dessus. Lorsqu'il fonctionne dessus, il vous le renvoie. Donc, une fois que vous avez créé un défaut, vous devez l'attribuer au développeur qui va y travailler. Il existe donc différents outils pour saisir le défaut. Vous pouvez utiliser Excel, vous pouvez utiliser des outils logiciels. Vous savez, je vais vous montrer que je vais expliquer certains des outils disponibles. Je veux dire, fonction de ce que l' entreprise utilise, elle vous fournira l'outil. Donc, une fois que vous devez toujours avoir quelqu'un, vous allez l'attribuer au développeur, à la personne qui travaillera sur ce défaut, vous l'attribuez en saisissant les étapes, le défaut, je décrirai les résultats réels, les résultats attendus, le sprintsht, Lorsque vous le lui envoyez en tant que nouveau, il va l'ouvrir, changer le statut pour ouvrir, travailler dessus quand il fonctionne, vous vous le renvoyez Quand le capteur vous sera renvoyé sera réparé. Ensuite, une fois que le capteur est revenu sur vous, vous devez revenir en arrière et retester cette fonctionnalité Ainsi, une fois que le capteur vous est revenu comme corrigé, vous revenez à l'application. Ce qu'il veut dire, c'est qu'il est en fait passé à l'application elle-même dans un environnement de développement. Je ne parle pas de la vie dans la production. L'application dans l'environnement Deve, et il est parti réparer ce bouton de sommet Rappelez-vous donc que toutes ces applications sont hébergées dans l' environnement Dave, n'est-ce pas ? Alors maintenant, il entre, corrige ce bouton de soumission de telle sorte que, si vous entrez le mot de passe du nom d'utilisateur et que vous cliquez sur Soumettre, n'est-ce pas ? Je dois vous emmener, il devrait connecter la personne, le client. Vous devriez connecter le client, n'est-ce pas ? Il l'a donc réparé. est donc ce que révèle le défaut lorsqu'il vous le renvoie en tant que solution. Il dit que d'accord, allez à l'application. Entrez le nom d'utilisateur et le mot de passe, cliquez sur Soumettre et le client devrait se connecter. C'est donc ce défaut qui indique qu'il a été corrigé. Maintenant, pour vous, vous pensez que je vais aller dans l'application, saisir le mot de passe du nom d'utilisateur, cliquer sur Summit. Une fois que l'application vous aura connecté, le défaut sera dans l'application, saisir le mot de passe du nom d'utilisateur, cliquer sur Summit Une fois que l'application vous aura connecté, résolu. C'est ce qu'on appelle un pass. Vous changez donc le nombre d'étoiles fixes en étoiles passantes. Maintenant, si, par exemple, souvenez que lorsque vous testez, vous n'allez pas simplement tester le sommet du nom d'utilisateur et du mot de passe , le sommet fonctionne et c'est réussi, non. Ils vont également faire des tests maintenant, car parfois, lorsque le développeur corrige ce sommet, quelque chose d'autre peut se casser. Je veux dire autre chose, mon grand nom, une autre épée d'erreur. Vous devez donc tester cette fonctionnalité. Vous n' allez pas simplement tester le nom d' utilisateur et le mot de passe et cliquer sur le bouton Summit est corrigé Vous allez également tester, si je saisis le nom d'utilisateur, si je saisis le mauvais mot de passe et que je clique sur Soumettre. Et si je n'entre aucun nom d'utilisateur et mot de passe, cliquez sur Soumettre. Est-ce que cela va me donner la bonne erreur ? Peut-être que non, le bouton Summit fonctionne maintenant, mais quelque chose a corrigé l'erreur. Ainsi, lorsque vous cliquez sur nom d'utilisateur, mauvais mot de passe, le message d'erreur que je reçois est désormais erroné. C'est un autre problème, non ? Vous devez donc faire des tests en fonction de ce futur. Vous savez, donc une fois que tout est réparé, vous remplacez ce défaut par le passé. Ainsi, lorsque le défaut est passé, ce défaut est résolu. Vous savez, pour changer le statut de passe, de changement et de statut, vous pouvez le mettre comme passé ou le mettre comme fermé. Donc, une fois qu'il est adopté ou fermé, cela signifie que le défaut est là, comme s'il était aimé. On dit que les gens peuvent aller le voir, mais lorsque vous considérez que le statut est clos, cela signifie que le problème est clos. Voilà donc ce que c'est. Donc, ce que je dis, c'est parce que cela m'amène aux tests de régression. Donc, les tests de régression sont maintenant une fois que vous avez fait tous les tests et que vous avez trouvé des défauts, que le développeur vous a envoyé des défauts, que vous les avez corrigés et, vous savez, je dis que vous envoyez les défauts au développeur, il les a corrigés, il vous les renvoie pour retester autre ensemble dans les deux sens, d'accord Je me souviens qu'en guise de question, gardez à l'esprit que vous allez avoir des allers-retours avec le développeur. Vos tests sont des erreurs d'échec, vous enregistrez, vous enregistrez les défauts, il les corrige, il vous les renvoie, vous testez le tout dans les deux sens. Donc, une fois que vous aurez fait tout cela, et je veux dire , au début, le défaut augmentera, deviendra énorme. Mais votre équipement continue de fonctionner, les défauts diminuent. Donc parce que maintenant c'est comme s'il réparait, réparait, réparait, réparait, vous testiez à nouveau, il réparait, vous fermez, vous fermez Donc, une fois que c'est arrivé à la fin, c'était comme si vous ne pouviez plus trouver de défauts. Vous savez, l' application fonctionne, vous faites un test de régression. Les tests de régression sont donc maintenant ce que sont les tests de régression : ils testent l'ancien système par rapport aux nouvelles fonctionnalités. Ainsi, par exemple, maintenant, une application peut voir le site Web moins la quantité de com, n'est-ce pas ? Ils veulent développer une application, mais il ne s'agit plus d'une application de marque. L'application existe peut-être déjà, mais ils souhaitent modifier la fonctionnalité de journalisation Donc, la fonction de journalisation est qu'ils veulent peut-être y changer quelque chose. Peut-être veulent-ils ajouter une authentification à deux facteurs, n'est-ce pas ? Mais l'application dans son ensemble existe toujours. Donc, le but des tests de régression, c'est qu'une fois que le développeur développé la fonctionnalité de journalisation, c'est à vous de la corriger et de la mettre à votre disposition Ils vont tester le deuxième facteur d'atérification à deux facteurs Ils vont tester la fonctionnalité de journalisation. Vous allez également tester l'ensemble de l'application. C'est ce qu'ils appellent des tests de régression. Vous testez donc ce qu'il a développé, et vous testez maintenant l'application complète de ce qu'ils appellent un ancien système. Donc, vous testez s'il change x y, et il le pousse. Vous allez tester de A à Z. Non. Vous allez tester S, Y, X et Y. Je vais aussi tester de A à z. Donc vous allez tout tester Ce type de test est donc appelé test de régression, et cela se produit après tests fonctionnels ou des tests de régression, mais avant que vous n'attendiez. Donc, les tests fonctionnels, les tests sur le bus noir, vous n'envoyez que des SMS x y, n'est-ce pas ? Vous ne faites que tester ce qu'il a développé. Ces deux fonctionnalités qu'il a développées. Mais la régression, c'est que vous testez X Y, et vous testez également de A à Z. Vous testez tout, toute l'application, soit celles qu'il n'a pas touchées ou quoi que ce soit d'autre, vous allez la tester Et vous allez également tester celui qu' il a mis à jour ou modifié. Tu sais, tu vas le tester aussi. C'est ce que vous appelez des tests de régression. C'est ce qui arrive. Tests fonctionnels Dans ce scénario, vous testez X Y, black bus sing. Ensuite, vous effectuez des tests de régression, afin qu'ils testent X, Y et Z. Ensuite, vous effectuez votre test ADC pour tester au hasard Une fois que vous l'avez fait, je veux dire, pas même avant de faire des tests aléatoires, vous pouvez le faire de bout en bout. Donc vous le faites après avoir fait du fonctionnel, vous avez créé une boîte noire, puis vous le faites de bout en bout. Après avoir fait de bout en bout, vous faites une régression, après avoir fait une régression, vous faites maintenant une UAT Donc, l'UAT est celui qui, une fois que vous avez effectué votre régression, vous pouvez maintenant faire désolé d'ajouter Lorsque vous le faites au cas par cas, vous pouvez l'envoyer à l'entreprise pour qu'elle fasse le U en attente. Donc U wait est le dernier type de test. C'est à ce moment-là que vous avez effectué tous vos tests, puis que vous les envoyez à l'entreprise pour qu'elle fasse le U en attente. N'oubliez donc pas que vous testez le fonctionnement de la boîte noire de bout en bout, puis vous faites une régression par régression, puis vous le faites au cas par cas, puis vous pouvez l'envoyer à l'entreprise pour qu'elle fasse en sorte qu'elle attende. Ce sont donc les meilleurs pour les tests que vous effectuez en tant que test d'assurance qualité. Je vais parler davantage différents autres types de tests, et il s'agira de tests plus complexes, principalement destinés à des fins spécifiques. Souvent, les personnes qui font ce type de tests sont pour la plupart des personnes qu'elles font venir des personnes qu'elles font venir dans un but précis . Ce n'est pas quelque chose qu' ils vous diront, vous devez également faire ce type de tests, personnes conçues ou des personnes responsables de ce type de tests en particulier et je vais vous expliquer cela dans la prochaine 19. Tests de bout en bout: N à l'intestin. Alors, qu'est-ce que N pour l'intestin ? N à l'intestin, c'est la plupart du temps effectué à la fin des tests fonctionnels, n'est-ce pas ? Supposons donc qu'un test de fonction puisse être, vous savez, tester la page de connexion, le nom d'utilisateur, le mot de passe, envoyer. Il s'agit d'un test fonctionnel. Tu sais, tester une application. Vous pouvez mettre un produit dans le CAT, c'est un test fonctionnel. Le client test peut payer, vous pouvez payer depuis votre cT en utilisant votre mode de paiement, votre mode de paiement préféré, c'est un test fonctionnel. Donc, le test consiste à tester, depuis le début, depuis le moment où un utilisateur ou un client se connecte avec son nom d'utilisateur et passe jusqu'au moment où il de passe jusqu'au moment où il quitte l'application en utilisant ses méthodes de paiement préférées. Vous allez donc imiter, vous allez exécuter un scénario , un utilisateur entre, saisit le nom d'utilisateur, le mot de passe, le sommet accède à l'application, entre comme s' il choisit quelques éléments et le met sur la carte vont au check-out, payent et partent et ils reçoivent une confirmation par e-mail, c'est la fin des tests. souvent, c'est comme si c'était fait vers la fin, s'il s'agit d'une méthode agile, n'est-ce pas, comme si c'était fait par étapes, n'est-ce pas ? Ainsi, une fois toutes les phases terminées, vous souhaitez effectuer un test de bout en bout. Donc, du début à la fin, parce que pensez-y, comme dans Realize Scenario. C'est ce que les clients vont faire. Par exemple, ils vont se connecter. Ils vont ajouter des objets à la casquette. Ils vont partir. Ils vont vérifier leur courrier électronique pour obtenir une confirmation par e-mail. Ils vont faire tout ça. Il se peut qu'ils ne le fassent pas immédiatement. Peut-être qu'ils pourraient se connecter pour nous, vous savez, faire des courses, publier des annonces sur le CP, le motu, tout ça Ensuite, ils peuvent éventuellement le mettre leur liste d'attente ou quelque chose comme ça, avant l'heure prévue ou quelque chose comme ça, ils peuvent venir payer, mais ils ont réalisé tous ces scénarios pour qu'ils aient réellement un cycle complet, est-ce pas, pour qu'ils puissent attendre qu'une transaction ait lieu. Ils ont finalement dû se connecter à un moment donné. Ils doivent ajouter des objets à leur compte. Ils ont dû partir, et ils ont même consulté leur e-mail pour envoyer une confirmation par e-mail. Ils ont donc réellement fait tout cela. Donc, tester, c'est vérifier que vous êtes capable de vous connecter, ajouter des éléments à votre ordinateur, vous savez, vérifier et de vérifier la confirmation par e-mail. C'est ce que j'ai appelé un intestin. Donc, dans l'eau pour, c'est facile car comme je l'ai mentionné, tout est développé immédiatement testé immédiatement. Il est donc plus facile pour vous de vous attaquer à l'intestin, juste là. Donc, une fois que vous avez effectué vos tests fonctionnels et vos tests de boîte noire, vous pouvez simplement faire un test, vous savez, pour tout tester Je vais donc également vous expliquer comment vous préparer à faire une entorse. Mais je veux juste expliquer ce qu'est un intestin. Plus tard, dans le cours, je vous montrerai comment préparer ou effectuer des tests n to n, comment effectuer des tests fonctionnels, des tests bus noirs et tout cela, d'accord. Mais je suis juste en train de vous expliquer ce que c'est, tous les types de tests. Rappelez-vous que j'ai parlé des tests fonctionnels. Les tests fonctionnels consistent donc principalement à tester un scénario, n' est-ce pas ? Donc, juste un sommet sur le nom d'utilisateur et le mot de passe , vous savez, comme une page de connexion , vous savez, pour tester que les caractères partiels fonctionnent. Ce sont des tests fonctionnels. Le test d'entrée fonctionne également. Ce sont des fonctions, mais c'est un objectif différent, directement aux tests fonctionnels, vous testez le scénario. Vous testez Pouvez-vous ajouter un article à votre mollet ? Pouvez-vous vérifier, vous savez, juste des fonctions, des fonctions. Entrez-les, vous testez plusieurs fonctions à la fois. Plusieurs fonctions , comme un cycle complet. Vous testez du début à la fin. Le test fonctionnel n'est donc qu' une fonction, deux fonctions. Une, c'est plusieurs fonctions à la fois. Vous savez, assurez-vous simplement qu' une transaction complète ou un cycle complet peut avoir lieu. C'est ce qu'ils appellent Ns. 20. Test d'acceptation de l'utilisateur: Oui, des tests d'acceptation par les utilisateurs. C'est donc très important. C'est un problème important car tests d'acceptation par les utilisateurs sont également effectués. Comme je l'ai mentionné pour l'assurance qualité, les tests fonctionnels sont une priorité absolue. C'est le type de test numéro un que l'assurance qualité doit effectuer. Les tests d'acceptation par les utilisateurs se sont arrêtés là. Et bien souvent, l'assurance qualité peut effectuer des tests d'acceptation des utilisateurs ou une entreprise peut effectuer des tests d'acceptation des utilisateurs. Vous vous souvenez quand j'ai dépensé pour les entreprises, alors les entreprises aiment surtout les parties prenantes, n'est-ce pas ? Les managers disent que je donne un exemple, directeur de Walmart, non ? Ils ont l'équipe. Ce n'est pas le responsable qui va réellement le tester, mais il peut s'agir de personnes service client ou de personnes avec lesquelles vous allez réellement interagir, pas les clients eux-mêmes, mais peut-être des personnes qui aiment sont des employés de Walmart, vous savez, peut-être elles qui aimeront, vont regarder l'application Alors, quand est-ce que cela se produit ? Quand est-ce que ce test d' acceptation utilisateur ou ce que nous appelons UAT UAT, d'acceptation utilisateur ? Quand est-ce que cela se produit ? Souvenez-vous donc du moment où l'application vous est présentée, par exemple pour effectuer les tests d'assurance qualité ou le cycle de vie du SDLC Donc, une fois que vous avez fait, comme vos tests fonctionnels, votre boîte noire , vous savez, toutes ces sortes de tests jusqu'aux tests N, je veux dire, vous en donnez votre ms. Je vais tout de même expliquer d'autres types de tests, mais vous avez effectué tous les types de tests dont vous avez besoin pour les tester directement sur l'application. Vous vous adressez au BA, qui est dans l'eau dans Agile ou le PO dans l'eau, je veux dire, le BA en Waterfall ou le PO en Agile. Je dis OK, cela a été testé, non ? Maintenant, ils vont prendre l' application et la remettre , ou le BA ou le PO vont faire leurs propres tests, n'est-ce pas ? Ils vont juste le faire rapidement, par exemple vérifiant les fonctionnalités. Si tout semble bon, ils l'enverront à l'entreprise pour que celle-ci effectue ses propres tests. L'entreprise aura donc sa propre équipe qui effectuera ses propres tests internes. Ce n'est donc pas comme si le public faisait les tests. Ils ont leur propre équipe, des personnes qui travaillent comme les parties prenantes, n'est-ce pas ? Ce sont eux qui demanderaient à leur propre équipe de tester l'application. Maintenant, comment effectueraient-ils ce genre de tests ? Vos tests, vos tests en tant qu'assurance qualité, vos tests fonctionnels sont donc plus approfondis, n'est-ce pas ? Nous testons l'application, d'un point de vue technologique, comme vous testez pour casser l'application afin de détecter des défauts. Les tests UD sont principalement comme des tests logiciels, il suffit de les passer en revue comme ça, je veux dire fonctionnalités comme juste pour vérifier que plupart d'entre elles font le point positif, n'est-ce pas ? Alors, est-ce que je peux me connecter ? Puis-je demander à ma carte ? Je peux vérifier, tu sais, ça comme ça ? Vous êtes en train de tester l' application pour l'arrêter. Donc, si, par exemple, un paiement peut indiquer : « Je souhaite utiliser ce type de carte pour payer ». Ils vont utiliser des voitures non valides que l'application n'accepte même pas pour voir si cela va vous donner une erreur, et si elle vous en donne une , quel type d'erreur. C'est donc le genre de choses que vous devez vérifier. Donc, dans l'UAT, ils vont juste vérifier le côté positif Ils vont donc vérifier la page de connexion, vous savez, l'enregistrement. Puis-je ajouter du sel sur la carte ? Puis-je, vous savez, vérifier, vous savez, je vous sais, tous ces genres de choses comme ce que nous appelons les parties positives. Mais dans le domaine de l'assurance qualité, vous testez le positif et le négatif, vous testez tout. Vous savez, le vôtre est plus complet, et cela prend plus de temps. Vous savez, mais l'UA est plus rapide, et ils ont leur propre équipe et ils vérifient simplement la plupart des choses, vous savez, vous pouvez oublier un défaut, et l'entreprise peut oublier un défaut parce que le vôtre devrait être plus minutieux. Donc, si vous l'avez manqué, il est fort probable que le BS le manquera. Mais encore une fois, le BA, pas le BS, mais les entreprises ont plus de connaissances, non ? C'est quelque chose qu' ils ont fait, non ? C'est quelque chose qui, vous savez, leur permet de mieux connaître le produit. Ils ont donc peut-être des moyens de mieux le tester pour comprendre cela, car ils comprennent mieux. Ainsi, par exemple, un homme d'affaires, comme la partie prenante de Walmart, a beaucoup de connaissances sur la façon dont il utilise l'application et sur la façon dont les clients interagissent avec l'application Ils savent comment les clients se rendent, comment ils les utilisent. Vous allez donc faire ces scénarios, n'est-ce pas ? Vous allez donc tester en fonction du client le type de choses qu'il fait. Et c'est toujours un signal d'alarme lorsque l'entreprise découvre le défaut que vous avez oublié, n'est-ce pas ? Donc si vous testez l'application, vous voyez, vous avez trouvé le défaut, vous avez tout corrigé. Vous donnez les conditions et vous l'envoyez à l'entreprise, et l'entreprise trouve le défaut. Ce n'est pas beau de votre côté car cela montre que vous n'avez pas fait votre travail correctement. Tellement de fois tu veux t'en sortir, OK, tu as trouvé tous les défauts, tu les as corrigés. C'est ce que nous appelons les problèmes connus. Les problèmes connus sont comme des problèmes mineurs ou minoritaires, n'est-ce pas ? Par exemple, vous pourriez voir que vous pouvez trouver un défaut et un logiciel d'erreur, vous cliquez, vous entrez le mot de passe du nom d'utilisateur, vous cliquez sur le sommet et cela ne mène nulle part. Le bouton Summit ne fonctionne pas. C'est une grosse erreur. C'est pourquoi nous appelons un énorme défaut. Et tu donnes la priorité à ces défauts. Je vais parler de la priorisation et de toutes ces choses Mais c'est énorme, non ? Cela doit être corrigé, comme il faut le faire avant que cela n' entre dans l'entreprise. Donc, mais il y a des problèmes où l' apparence de l'application peut être le sommet, je veux dire, comme, vous savez, les graphismes et autres choses de ce genre. Il y a des problèmes mineurs, n'est-ce pas ? C'est ce que nous appelons des problèmes connus comme vous les connaissez parce que cela ne correspond pas aux exigences ou aux termes de l'histoire. Ce sont des problèmes connus, mais ça va, non ? Comme une application ne peut pas être testée à 100 %, elle ne peut pas être exempte de défauts ou d'erreurs à 100 %. Tu sais, c'est impossible, non ? Il va toujours y avoir des problèmes. Mais ces problèmes sont acceptables, les clients peuvent-ils toujours utiliser l'application avec les quelques problèmes. Si c'est oui, alors ce sont de petits problèmes, n'est-ce pas ? Et pas de problème vous devez faire savoir à l' entreprise que, d' accord, c'est ce que j'ai trouvé, n'est-ce pas ? sont les problèmes connus qui comportent de légères erreurs ici et là. Connus, ils sont donc connus. Les analystes commerciaux seront au courant de ce problème. Vous expliquez donc aux analystes commerciaux que ce sont là des problèmes connus, n'est-ce pas ? Ensuite, les analystes commerciaux ou le PO s'adresseront à l'entreprise pour qu'elle teste l'application, mais pendant que vous testez l'application pour l'UAT, voici les problèmes connus, n'est-ce pas Telles sont les questions qui ne sont pas prioritaires. Ce n'est pas grave, des choses comme ça. Ainsi, lorsque l'entreprise effectue des tests, elle garde à l'esprit que, d'accord, sont les problèmes connus que l'entreprise, le BA ou le PO m'ont signalés, mais que nous allons effectuer des tests pour détecter les principaux problèmes. Les principaux défauts sont donc les gros défauts qui devraient être ignorés. Donc, si un problème, comme je l'ai mentionné, comme je l'ai mentionné, le nom d'utilisateur pour le sommet ne fonctionne pas entreprise le découvre , c'est une malchance pour vous parce que , vous ne l'avez pas décroché, et je n'essaie pas de l' envoyer pour vous effrayer, mais j'essaie juste de le rétrograder. C' est une carrière importante. n'est pas pour cela que les gens finissent souvent par six chiffres, parce que cela beaucoup de responsabilités ici et que cela coûte des millions de dollars, ces applications coûtent des millions de dollars et vous ne voulez pas publier de candidature, ils dépensent cette somme d'argent et vous savez, elle ne fonctionne pas ou échoue, vous savez, donc vous voulez faire sûr que lorsque vous arrivez, vous prenez le temps de tester correctement et de tout faire correctement parce que vous ne pouvez pas simplement faire n'importe quel travail sur des diapositives et tout ce que vous devez mettre en production non. Tu sais, tu dois tester correctement. Vous devez être un vrai professionnel tester l'application. Je vais donc en parler plus en détail, il s'agit simplement de l'UAT. Je vais parler davantage des autres types de tests. Et cette UAT est l'entreprise qui teste réellement cette application sont donc elles qui, vous savez, sont responsables, seules responsables, mais comme je peux également le mentionner, les QA peuvent également entrer en ligne de compte Ainsi, les QA peuvent également avoir vu les QA effectuer également des tests TD. Et lorsque vous avez effectué des tests d'âge, ils les ont effectués en collaboration avec l'entreprise. Ainsi, une fois qu' ils auront terminé, ils recevront, conformément à leurs conditions et à tout ce qu'ils ont fait , la boîte noire fonctionnelle. Pour terminer les tests, tous ces types de tests, ils se coordonneront avec l'analyste commercial ou le propriétaire du produit à effectuer et avec l'entreprise pour effectuer l'UAT Vous pouvez donc parfois aider l'entreprise à effectuer l' UAT à ses côtés. Mais bien souvent, c'est toujours l'entreprise qui s'occupe de l'UAT. 21. Test d'automatisation: Donc, ce que je disais tout à l'heure, c'était comme toutes sortes de tests. Ce type de test est donc ce que nous appelons des tests d'automatisation. Les tests d'automatisation sont donc importants, car c'est vers cela que les tests se dirigent actuellement. Donc, beaucoup de testeurs, je veux dire, les tests manuels ne disparaîtront jamais. Il y aura toujours des opportunités pour un testeur manuel. Mais si vous voulez approfondir vos connaissances, augmenter votre montant en dollars, comme si vous gagniez plus d'argent, l' automatisation, c'est un peu la prochaine étape. Donc, lorsque Q a commencé, il s'agissait de tests manuels. Mais au fil du temps, ou au fur et à mesure que l' automatisation a commencé , de nombreuses entreprises ont commencé à adopter l' automatisation et embaucher des testeurs d'automatisation parce que c'est moins cher, n'est-ce pas ? Ce que cinq testeurs manuels faire, un seul testeur d'automatisation peut tout faire, ce que cinq testeurs feraient. Alors pourquoi engager cinq testeurs alors qu' un seul spécialiste de l'automatisation peut tout faire ? Et encore une fois, les tests en manoir seront toujours pertinents. Donc, ne pensez pas que c'est bien, si vous savez tests dans les manoirs signifient que je dois passer à l'automatisation pour gagner de l'argent. Non. Même en faisant des essais dans des manoirs, vous pourriez toujours avoir une carrière. Mais l'automatisation est en fait la solution du futur. Et qu'est-ce que les tests d'automatisation ? Les tests d'automatisation sont des scripts. scripts sont donc essentiellement des outils conçus pour que vous puissiez créer des scripts Donc, les tests d'automatisation, vous vous souvenez quand j'ai parlé de tests fonctionnels, de tests de régression. Tout cela peut être fait grâce à l'automatisation. L'automatisation, c'est un peu comme écrire des scripts, c'est comme écrire des codes Par exemple, lorsque vous dites que le test mano est généralement une entrée, vous accédez à l' application walmart.com, vous accédez à la page de connexion, page de connexion entrez le nom d'utilisateur et le mot de passe, vous passez à l'écran suivant Grâce à l'automatisation, vous n' avez pas à saisir manuellement l'URL de Walmart, le nom d'utilisateur, le mot de passe, le saisir le message d'envoi Vous écrivez des scripts, vous écrivez fonctions de code de fonction sur l'outil, l'outil d'automatisation avec lequel nous interagirons avec le site Web de Walmart, vous vous rendez sur le site Web de Walmart pour exécuter ces Ainsi, par exemple, vous allez écrire un script sur l'outil. Je vais vous parler de quelques outils que vous pouvez utiliser pour automatiser. Vous écrivez un script sur l'outil. Et cet outil interagira avec site Web de Walmart et nous y trouverons l'URL de Walmart, saisirons le nom d'utilisateur, saisirons le mot de passe et cliquerons dessus tout seul Tu ne vas rien faire. Il va donc le faire et vous envoyer le résultat. Si cela vous amène au journal s'il dépasse la page de journalisation, vous pouvez vous dire que cela est passé. S'il échoue, il vous donnera également une erreur. Donc tu n'as même pas besoin d'y être. Parfois, vous pouvez pourrir un script d'automatisation du jour au lendemain. Et écrivez tellement de fonctions. À vous de tester la page de connexion, de tester, de vérifier les cartes. Vous pouvez obtenir des objets et vous pouvez les ajouter à la carte, vous pouvez en retirer des objets du CP. Vous pouvez vérifier le paiement. Vous pouvez vérifier que vous recevez des e-mails, des e-mails de confirmation à votre adresse e-mail. Tu pourrais tester tout ça. Il vous suffit donc de le programmer. Il suffit d'écrire tous les scripts complets, de les laisser s'exécuter. Alors maintenant, vous voyez ce que je veux dire qui est robuste. C'est triste de votre part de faire tous ces tests de scénarios d' entraînement. Vous pouvez simplement écrire des scripts de carburant et laisser l'automatisation le faire. Et ils le font souvent parce que, par exemple, à votre place, les applications sont souvent créées à partir de zéro. Ils sont construits à partir du fait qu'ils ont peut-être ajouté des fonctionnalités de carburant pour évaluer. Maintenant, pourquoi engager quelqu'un qui testera manuellement 400 scénarios dans le cadre de tests de régression, n'est-ce pas ? Je me souviens que j'ai dit que vous aviez changé x y, donc les deux facteurs se calquent, et que vous deviez tester jusqu'à z. Mais est-ce que je vais engager quelqu'un qui va prendre six mois pour tester X Y et A à Z pour les tests de régression Quand j'ai déjà des scripts en automatisation, où j'ai déjà le code pour les tester de A à z. Donc, la seule chose qui a changé, c'est X Y. Donc oui, je peux faire des tests mineurs. Je fais Mais je peux voir écrire des scripts, je peux faire X Y, mais de A à Z, j' ai déjà un dépôt Donc, là où ils stockent tous ces codes, c'est ce qu'ils appellent un référentiel. Le référentiel est comme l'endroit où toutes ces commandes sont écrites. Allons donc dans le référentiel, choisissons toutes ces commandes et exécutons-les. Je n'ai donc pas besoin de demander à quelqu'un d'écrire tous ces scripts, de commencer à tester chaque écriture de toutes ces fonctions et de commencer à les tester manuellement. Quand je peux simplement extraire tous les scripts qui se trouvent dans le référentiel et tout exécuter sans même aimer, c'est comme courir vers un beau. Je peux demander à une seule personne de faire toute la régression. L'automatisation est très utile pour la régression. très bien parce que de nombreuses entreprises sont fondées, c'est moins cher parce que la régression, comme je l'ai mentionné, c'est que lorsque vous testez l'ancien système, vous testez l'ancienne fonctionnalité et un nouvel avenir. Donc, avec l'automatisation, l' ancienne fonctionnalité, vous avez déjà des scripts pour cela. Ils l'ont déjà fait par le passé. Il figure donc déjà dans le représentant. Il vous suffit donc de le récupérer. Et lancez-le. C'est ainsi qu' ils n'ont pas besoin d' embaucher trop de personnes, car dans les tests de manoir, si vous devez effectuer des tests de régression mineurs, vous devez engager du personnel pour tester toutes les anciennes fonctionnalités et les nouvelles fonctionnalités. Mais avec l'automatisation, l'ancienne fonctionnalité est que les scripts existent déjà. Il vous suffit donc de le sortir du référentiel et de l'exécuter et une seule personne peut le faire. C'est pourquoi l'automatisation est surtout utile pour la régression. Vous pouvez également effectuer des tests fonctionnels grâce à l'automatisation, mais, vous savez, de nombreuses entreprises continuent de se lancer dans l'automatisation. Je veux dire, si je veux dire, cela demande beaucoup de scripts, comme si ce n'était pas aussi complexe que les développeurs, mais c'est aussi comme écrire du code, non Ce ne sera pas comme écrire des codes en dur. C'est donc un peu comme un script euh. Certaines descriptions peuvent impliquer du C sharp, Java, des scripts Java, etc. Donc, si vous êtes à l'aise avec cela, vous savez, je pense que si vous pensez pouvoir prêter du Java et du C sharp et d'autres choses de ce genre, je veux dire, allez-y parce que cela augmentera le dollar, cela vous rendra, vous savez , plus demandé, vous trouverez un emploi plus rapidement, vous savez, parce que de nombreuses entreprises ont besoin ou non du X pour les testeurs d'automatisation. Mais l'homme sera toujours là, vous verrez toujours des testeurs de mano, comme si vous pouviez avoir un porte-avions Si vous voulez avoir un support à six figo, en tant que testeur manuel, vous le pouvez également Mais l'automatisation, c'est celles qui vont vite, comme les plus hautes, elles sont plus recherchées, vous savez, parce qu'elles sont plus anciennes parce que le testeur d'automatisation peut également effectuer des opérations manuelles et automatisées. Mais un testeur manuel peut faire de l'automatisation et ne peut le faire que manuellement. C'est pourquoi les entreprises privilégient les tests automatisés. 22. Test de performances: Le dernier type de test que je vais expliquer est celui des tests de performance ou des tests de faible intensité. Les tests de performance ou les tests de faible intensité doivent être effectués par automatisation. Donc, quand je parle d'automatisation. Test d'automatisation, ils effectuent des tests fonctionnels, de régression, mais aussi des tests de charge ou des tests de performance. Il faut en finir avec l' automatisation à l'aide d'outils d'automatisation, car la façon dont vous effectuez les tests de chargement ou de performance est liée à l'utilisation d'un outil d'automatisation. Je veux dire que c'est l'assurance qualité qui s'en charge, mais ce ne sera pas votre responsabilité, n'est-ce pas ? Parce qu'une fois que vous entrez , vous êtes principalement responsable des tests de méthode. Je veux dire, les tests fonctionnels, le bus noir, régression, vous savez, le soutien à l'entreprise avec l'UAT ad hoc Mais ils ont des personnes spécifiques qu'ils embauchent pour effectuer les tests de charge. Vous voyez donc des personnes que vous pouvez voir un professionnel qui disent : «  Je veux faire des tests de performance ». Vous savez, ce sont des personnes qu'ils embauchent spécifiquement pour effectuer des tests de performance. Ce n'est donc pas une responsabilité salariale de Q de le faire. Mais en même temps, lorsqu'ils disent que je veux un testeur de performance, agit toujours d'ingénieurs d'assurance qualité, d' analystes ou de testeurs d'assurance qualité. Vous savez, ils sont toujours nous sommes des testeurs, comme, vous savez, tout cela n' est que des tests, mais ce rôle, les tests de performance, sont spécifiquement conçus dans un but précis et certaines personnes sont spécialisées dans ce type de domaine spécifique. Alors, qu'est-ce qu'un test de performance ou un test de charge ? Les tests de performance ou les tests de charge testent donc le niveau de contrainte d'une application. Donc, ce que je veux dire par stress, c'est comme, par exemple, j'utiliserai à nouveau le site Walmart Quand vous allez sur walmart.com, n'est-ce pas ? Vous savez combien de personnes utilisent Walmart à un moment donné. Disons pendant peut-être une certaine heure. Vous pouvez avoir plus de 5 000 personnes qui utilisent Walmart. Et ces 5 000 utilisateurs font tous des choses différentes. Certains se connectent, d'autres ajoutent des choses à leur chat. Certains sont en train de partir. Donc, tous ces scénarios. C'est donc la responsabilité d'un testeur de performance. C'est lui ou la personne qui sera chargée de tester l'ensemble de ces scénarios pour voir si 5 000 personnes peuvent accéder à l'application en même temps. Quatre personnes, peut-être 1 000, sont sur la page de connexion. 2000 consiste à ajouter des éléments à la carte dans les deux sens, à supprimer l'arrêt d'ajout, à supprimer l'arrêt d'ajout. 2 000 personnes quittent l'établissement, saisissent les informations de leur carte , puis partent, 1 000 vérifient leurs e-mails pour obtenir une confirmation par e-mail. Il appréciera qu'il y ait deux automatisation parce qu'on ne peut pas obtenir 1 000 personnes, dans l' automatisation parce qu'on ne peut pas obtenir 1 000 personnes, 1 000 testeurs mineurs qui ajoutent la connexion ou, vous savez, c'est là que l'automatisation entre en jeu, l'outil. Ils vont donc créer des utilisateurs virtuels. Ce qu'ils appellent des utilisateurs virtuels, ce sont de faux utilisateurs C' est une façon dont c'est une startup comment le faire , créer des utilisateurs virtuels, peut-être 5 000 utilisateurs virtuels qui accèdent à cette application même temps pour voir si elle va panne parce que si elle tombe en panne, cela signifie que si l'application entre en production, si jusqu'à 5 000 personnes accèdent à l'application en même temps, . C' est une façon dont c'est une startup comment le faire, créer des utilisateurs virtuels, peut-être 5 000 utilisateurs virtuels qui accèdent à cette application en même temps pour voir si elle va tomber en panne parce que si elle tombe en panne, cela signifie que si l'application entre en production, si jusqu'à 5 000 personnes accèdent à l'application en même temps, l'application va être interrompue. Et je suis sûr que vous avez probablement entendu dire que parfois, lorsque de nombreux utilisateurs utilisent l'application, celle-ci est lente ou peut échouer. C'est donc ce qu'ils font des tests de charge ou des tests de performance pour éviter une telle situation. Ainsi, lorsque beaucoup de personnes utilisent l'application, l'application ne s'arrête pas, vous savez, ou elle ne ralentit pas. C'est ce qu'ils font des tests de performance tests d'automatisation ou tests de charge pour éviter que cela ne se produise en production, car une fois qu'ils sont entrés en production, Walmart a déjà une idée du nombre d' utilisateurs qui utilisent l'application Ils ont de la portée, non ? Ils se tournent donc vers le testeur de charge ou le testeur d'performances imitera ce scénario Il va placer le même montant, pas le même montant, mais au-dessus du même groupe de personnes sur l'application pour voir si l' application va tomber en panne ou comment l'application va fonctionner. Donc, sur cette base, vous déterminerez si l' application est bonne ou non. N'oubliez donc pas que vous avez effectué vos tests fonctionnels, vous savez, la boîte noire, tests de régression utilisateur, etc. Tous ces types de tests tests fonctionnels, n'est-ce pas ? Ce qu'il fait s'appelle des tests non fonctionnels. N'oubliez pas quand vous utilisez toujours la tige. Tests fonctionnels et non fonctionnels. Les tests fonctionnels sont donc ceux que j'ai mentionnés, même si je veux dire, ils parlaient toujours de tests habituels, de tests d'espacement, de tests de régression , de toutes ces choses Même si pour tester, je vois que la fonctionnalité est différente, mais ils sont toujours classés selon cette fonctionnalité parce que les informations que vous pouvez saisir sont réussies selon cette fonctionnalité parce que les informations que , donc pour tester, nous sommes toujours en train de saisir le mot de passe utilisateur, mais vous passez nous sommes toujours en train de saisir le mot de passe utilisateur, par des phases différentes, n'est-ce pas ? Tellement différent que vous vous retrouvez face à des scénarios différents. Est-ce que les tests de stance, les tests de régression, tout est fonctionnel dans une certaine mesure, n'est-ce pas parce que vous testez des fonctions Non fonctionnel ne l'est pas quand c'est une non-fonction, c'est ce que nous voulons dire performance parce que vous n'êtes pas simplement ce n'est pas une fonction, n'est-ce pas ? Ce n'est pas comme si vous testiez le mot de passe de l'utilisateur. fonction est le non-fonctionnel, je ne peux pas tester les performances. Donc, si X personnes l' utilisent à un moment donné, comment fonctionnerait le système ? C'est comme ça que tu t'y prends ? C'est pourquoi vous le qualifiez de non fonctionnel parce que vous testez le niveau de stress. Ils testent tout un tas de choses comme, vous savez, vous savez, combien de personnes pouvez-vous utiliser, vous savez, sur la page de connexion, quelle est la capacité pour cela et d'autres choses de ce genre. Donc d'autres CSS qu'ils appellent non fonctionnels et les outils qu'ils utilisent pour passer des vacances. Donc, à la fin du cours, je vais vous montrer comment utiliser Q pour tester les tests fonctionnels, les tests fonctionnels et les tests non fonctionnels. Quels sont les outils, même l'automatisation, si vous êtes également intéressé par l'automatisation, quels types d'outils vous pouvez utiliser, vous savez, pour effectuer l'automatisation. 23. Types d'artefacts: Dans cette vidéo, nous allons donc parler d' artefacts ou de documents issus de tests. Lorsqu'un QA U effectue des tests. Il existe différents documents basés sur les étapes des tests dont vous serez responsable, n'est-ce pas ? Donc des documents. Donc, avant de commencer les tests, vous devez avoir certains documents, des tests de câblage, certains documents doivent être produits. Après avoir effectué les tests, vous devez produire certains documents et chaque document contient sa proposition ou ce que nous avons servi au cours de ce processus. Je vais donc vous expliquer les différents types de documents. Maintenant, comme dans le scénario Realize, vous n'avez pas besoin de créer tous ces documents. Mais je veux vous préparer de manière à ce que vous puissiez parfois poser des questions de ce genre lors d' un entretien . Et aussi, lorsque vous commencez à travailler, vous savez, vous voulez savoir tout cela, n'est-ce pas ? Ainsi, si je peux mentionner deux des documents restants, vous le savez. Donc ça peut être n'importe quoi, non ? Parce qu'une fois que vous m' avez fait une question dans l'entreprise, vous devez suivre les normes de l' entreprise, comme celle-ci la façon dont ils font les choses dans le domaine de l'assurance qualité, vous savez, certains peuvent exiger, ils peuvent l'exiger. Je veux donc mieux t'équiper. Donc, quel que soit le chemin à venir, vous serez en mesure de répondre. Vous savez, vous aurez des connaissances dans ce domaine pour être en mesure d'ajouter de la valeur. Dans la vidéo suivante, je vais donc vous expliquer quels types de documents destinés à l' assurance qualité doivent être produits par un service d'assurance qualité et à quel stade ou à quel stade il doit le produire avant 24. Document de plan de test: Un QA produit est un document de plan de test. Alors, qu'est-ce que le document du plan de test ? Ce n'est donc pas très courant. Nous ne produisons pas nécessairement des documents de plan de test en permanence. Je veux dire, je peux compter le nombre de fois où je produis des documents de plan de test. Et la plupart du temps, c'est surtout le responsable de l'assurance qualité. Donc, quand je parle d'assurance qualité, un cran au-dessus des ingénieurs d'assurance qualité. Le responsable de l'assurance qualité est donc une personne qui gère plusieurs testeurs d'assurance qualité. donc le Q terminé à de nombreuses reprises qui a produit ce document. Mais je le partage simplement pour que vous sachiez également ce qu'est un document de plan de test. Il peut donc parfois vous incomber de créer un document de plan de test, vous savez, et que ferez-vous dans ce scénario. Donc, si ce scénario se produit, vous savez, je vais joindre tous les artefacts de cette vidéo afin que vous puissiez voir tous les types de documents dont le responsable de l' assurance qualité est responsable. Mais le document du plan de test décrit en quelque sorte la stratégie que vous allez utiliser pour les tests, n'est-ce pas ? Donc, souvenez-vous quand j'ai dit que l'analyse commerciale B ou le PO rédige les exigences, les donne au développeur , c'est à dire, pour développer l'application, pourquoi l'application, pourquoi le développeur développe l'application. Vous êtes en train de préparer un document de plan de test. Et n'oubliez pas qu'un document de plan de test est surtout populaire dans le cadre d'une méthodologie en cascade. Dans Agile, nous n' utilisons donc pas nécessairement des documents de plan de test car la plupart du temps, tout est interrompu étapes et les choses changent, n'est-ce pas ? Vous créez donc un document de plan de test et tout d'un coup, au cours de la deuxième phase, ils n'en veulent pas. Qu'est-ce que tu vas faire ? Vous devez revenir au plan de test pour le mettre à jour. Mais dans une cascade, comme c'était l'ancienne approche, votre plan de test était très courant car tout était développé de A à Z. Vous aviez donc mis en place une stratégie pour couvrir l'ensemble des tests, car tout avait été pensé pour développer l'application de A à Z, comme si les développeurs avaient déjà développé l' application dans développer l'application de A à Z, comme si les développeurs avaient déjà développé l' son intégralité et tout le Donc tout s'est passé comme si, vous savez, il n'y avait pas eu beaucoup de changement. Donc, dans votre plan de test, vous couvrez en quelque sorte l'ensemble des scènes. Un document de plan de test définit la stratégie selon laquelle vous allez exécuter vos tests. Et je vais vous montrer comment effectuer des tests. Mais le document du plan de test est comme un plan indiquant comment vous comptez tester l'application. Donc, en quoi consiste le plan de test, parle d' abord de l'objectif, n'est-ce pas ? Quel est l'objectif de ce document ? Eh bien, le but du document, quel est l' exemple de Walmart, est de tester la fonctionnalité ou le site Web de Walmart C'est donc le but. Tu veux tester. Et ensuite, vous parlez de la lunette, n'est-ce pas ? Quel est le champ d'application. Donc, ce qui est prévu , c'est de se rappeler quand, pour parler de la page de journalisation, vous voulez tester la page de journalisation. Vous souhaitez tester, vous pouvez l' ajouter à votre panier. Vous voulez tester, vous pouvez vérifier. Vous voulez tester, vous pouvez recevoir des e-mails à votre adresse e-mail, vous pouvez envoyer une confirmation par e-mail à votre boîte e-mail. Tu veux tester tout ça. C' est donc le champ d'application de l'appel. Qu'est-ce qui pourrait être hors de portée ? Tu sais, les tests de charge, non ? Les tests de performance, j'aime bien qu'ils ne soient pas aussi pertinents pour vous. Ces éléments peuvent être hors de portée, en fonction de ce que vous savez, directives que vous avez tirées de votre test d'assurance qualité en temps réel ou de ce qui est hors de portée. portée automatique peut donc être une activité qui ne concerne pas les tests d'assurance qualité, dont vous êtes tous responsables Ce qui entre donc dans le champ d'application c'est ce que vous êtes chargé de tester. Comme je l'ai mentionné, vous allez tester la page de connexion, vous allez tester, vous pouvez vous occuper de votre panier, vous allez tester, vous savez, vous pouvez payer depuis votre panier, vous allez tester, vous pouvez envoyer une confirmation par e-mail, tout cela, c'est ce qui est prévu, n'est-ce pas La stratégie fait également partie du plan de test, n'est-ce pas ? Permettez-moi des stratégies comme comment allez-vous tester toutes ces fonctionnalités ? La page d'enregistrement, les informations relatives à votre voiture, paiement, le courrier électronique, la confirmation. Comment allez-vous le tester ? Donc, la page de journalisation, je veux dire , la stratégie pourrait être la suivante : quel type de test allez-vous utiliser ? Quel type de test comptez-vous développer ? Vous allez donc faire tests fonctionnels, des tests de régression, des tests utilisateurs, des tests sur des bus noirs, et tout ce genre de choses, et qui va les faire. Donc, parfois, comme je l'ai mentionné, l'UAT est principalement effectuée par l'entreprise C'est donc peut-être l'entreprise qui va faire de l'UAT. Vous l'avez donc mentionné, vous savez, dans la stratégie. Il se peut qu'un test fonctionnel soit effectué par vous ou qu'il s'agisse d' un test d'assurance qualité. Tu l'as mentionné. Vous savez, tests de régression seront effectués par vous ou par les QA ou combien de Q ? Vous avez mentionné que, vous savez, toutes ces choses sont peu comme vous allez mentionner les types de tests. La section comportera également des critères d' entrée et de sortie. Donc, des carteras d'entrée et de sortie lorsque le développeur vous l' envoie pour le tester, Ce qui doit être prêt ou quelles cases à cocher doivent être créées pour que vous puissiez le récupérer auprès du développeur indique que le bonus est testé Certaines idées pourraient donc être qu'il a fait ses tests unitaires, n'est-ce pas ? N'oubliez pas que je parle de tests unitaires. est également l'une des fonctionnalités que vous souhaitez vérifier et qui a fait l'objet de tests unitaires. L'environnement aussi, non ? Disposons-nous d'un environnement stable ? N'oubliez pas quand il faut parfois dire que l'environnement que vous testez ou que l'application est développée est différent de l' application et de la production Vous devez donc vous assurer de disposer d'un environnement stable. Parfois, les sourds et les responsables de l'assurance qualité partagent le même environnement. Parfois, les sourds peuvent avoir leur propre environnement, les Q peuvent avoir leur propre environnement. Tous ces critères d'entrée seront donc les suivants : avant de commencer les tests, l'environnement doit être prêt, tests unitaires doivent être prêts Et j'ai également raté un autre type de test, ce que nous appelons les tests de fumée. Le test de fumée est souvent très populaire dans les questions d' entretien, sous le terme « test de fumée ». Les tests de fumée sont soumis au développeur lorsque celui-ci vous les envoie et que vous les récupérez pour commencer les tests. Ce qu'est un test de fumée est la même chose qu'un test aléatoire, comme un test ad hoc, mais il n'a pas dit que c'était ad hoc. Le test de fumée consiste simplement à consulter et à remplir le formulaire de demande avant de commencer le test. Donc, vous voulez vérifier, d'accord, s'il dit avoir une page de connexion. Est-ce que je vois la page de journalisation ? S'il dit qu'il a un truc à ajouter au chèque, vérifiez qu'il ajoute du suf au scanner. Je peux voir ça ? S'il dit qu'il va payer. Puis-je le voir par e-mail, confirmation que je fais un test de fumée, c'est comme de la visibilité, vous pouvez toujours exécuter certaines fonctions, mais c'est ce qui est de très haut niveau. Ce n'est pas un détail, vous n' êtes pas positif ou négatif, ce n'est pas complexe. C'est bon, ce que les sourds ont dit qu'il allait développer, l'a-t-il développé ? Donc, si vous le regardez simplement parcourir des objets, vous savez que c'est un test de fumée. Ce sont comme des critères d'entrée pour la fumée, comme des critères d'entrée. Ce sont des éléments que vous devez avoir en place avant de commencer à effectuer les tests. Tout cela va être repoussé, consigné dans les documents du plan de test Ce sont plutôt les critères de sortie, ses critères. Avant de lever le pouce, quelles sont les choses à faire ? De toute évidence, vous devez avoir effectué l'ensemble des tests. De toute évidence, les défauts que j'ai trouvés auraient dû être corrigés, non ? Donc, les critères peuvent être corrects, pas de problèmes, non ? N'oubliez pas quand nous parlons de l'absence de problèmes. J'ai donc peut-être trois questions qui ne sont pas prioritaires. Rappelez-vous que je vous ai dit qu'une application ne peut jamais être exempte de défauts ni d'erreurs. Mais l'entreprise et le responsable du produit ou les analystes commerciaux doivent être conscients de ces problèmes connus. Souvent, les critères de sortie pouvaient être corrects, quatre problèmes étaient connus et leur priorité n'était pas élevée. N'oubliez pas que vous ne pouvez pas donner de conditions lorsqu'il s' agit d'un défaut hautement prioritaire ou d'une erreur hautement prioritaire. C'est impossible. Tu ne peux pas dire que tu as tout fait. Vous avez tout testé lorsqu' ils ont détecté des défauts prioritaires. Donc, Exit prior est surtout lorsque la priorité est élevée, la priorité moyenne de résolution, et peut-être que maintenant la priorité est ce qui reste parce que vous ne pouvez pas encore dépenser X somme d'argent pour embaucher des gens, juste pour résoudre des problèmes mineurs, parce qu'ils ont d'autres choses sur lesquelles travailler. Ils ne passeront pas autant de temps à résoudre les problèmes mineurs ou à travailler sur des problèmes mineurs. Priorité élevée, priorité moyenne, oui, doit être trouvée, corrigée, proche. Mais les priorités sont faibles, ce ne sont pas des problèmes. Les critères de sortie peuvent être corrects, l'application est correctement testée, les défauts sont corrigés, les priorités faibles sont ce qui reste, les défauts de faible priorité sont ce qui reste. C'est un critère X. Et aussi des jalons. Une autre section du plan de test concerne les jalons. Les étapes importantes seront, ok, j'ai l'intention de tester cette application dans X temps parce que, comme je l'ai dit, temps c'est de l'argent. Si vous la vendez sur votre page, je ne passerai pas 88 mois à tester cette application Si l'entreprise est probablement prévue juste au moment où elle réalisait l'ensemble du projet et développait l' application dans son ensemble et, vous savez, qu'elle ne développait pas mais étudiait la planification du développement de l'application. Ils disent que le chef de projet a déjà déterminé le temps qu'il faudra aux développeurs pour développer le test de l'application. Les étapes importantes seront donc les suivantes : d'accord, il faudra quatre mois pour qu'une application soit testée Que faites-vous le premier mois ? Quel est le jalon ? Êtes-vous en train de créer un artefact ? Êtes-vous en train de créer un document ? Êtes-vous en train de créer un plan de test ? Du deuxième au troisième mois ? Tu es prête ? Êtes-vous en train de vous assurer que, vous savez, je crée, que faites-vous ? Voici donc les étapes importantes. Donc, du premier au quatrième mois, que se passe-t-il ? Lorsque vous testez numéro de demande, les tests peuvent également nécessiter plusieurs cycles. Vous pourriez donc tester, vous pourriez effectuer le premier cycle de tests, trouver les défauts, puis les réparer. Vous effectuez un autre cycle de tests, un autre cycle de tests avant de passer à la régression. La régression, c'est tester, souvenez-vous que j'ai dit X, Y et Z. Vous testez tout, le système existant, avant de donner des tonnes Tout cela sera donc développé comme prévu pour ce jalon. Donc, au cours des quatre premiers mois, qu'allez-vous faire, quel est le plan, n'est-ce pas ? Cela ne tombera donc pas uniquement sur vous. Le couvercle QA recevra également la directive en termes d'accord, c'est ce qu'est le plan. Donc je ne veux pas vous effrayer, comme si ce pas difficile du tout, comme une fois que vous serez dans le processus, vous savez, vous verrez des choses semblables, c'est beaucoup de communication, comme si rien ne vous tombait pas sur les mains, vous savez, comme si vous deviez vous débrouiller par vous-même, non, votre couvercle de QA, votre responsable de l'assurance qualité, vous savez, le travail avec vous sur ce processus, vous savez, je veux dire si vous deviez créer un document de plan de test, vous savez, donc parfois vous ne créez pas de document de plan de test, mais c'est un peu comme, vous savez, niveau élevé de ce que cela implique ou de ce que consiste un document de plan de test. Et j'ai également joint des artefacts. J'ai également joint un document, un exemple de plan de test quoi ressemble généralement un plan de test. Vous savez, parfois cela peut être plus complexe, parfois moins complexe, mais j'ai joint, vous savez, dans la vidéo, un exemple de ce à quoi devrait ressembler un plan de test. Ensuite, nous allons parler des documents de cas types. 25. Document de cas de test: Le type de document suivant est ce qu'ils appellent un document de cas type. Il s'agit en fait du document le plus important pour un QA. Par exemple, vous devez toujours créer un document de cas de test. n'y a pas de contrôle qualité aucun test n'est effectué sans un document de test. Maintenant, comment créer un dossier de test dépend ? Il existe des outils que vous pouvez utiliser pour créer des documents de cas de test ou vous pouvez créer une feuille Excel. Vous trouverez ci-joint une feuille Excel expliquant comment un document de cas de test est créé. Maintenant, si vous avez réellement un outil qui crée un endroit où vous pouvez saisir vos scénarios de test, est-ce pas, vous allez toujours suivre le même format que celui que j'ai joint dans la feuille Excel, n'est-ce pas ? C'est dans la création d'un document de cas de test, il y a une sorte de modèle ou de méthode. Donc, en fait, je vais le décomposer. Donc, quand je parle de document de cas type, n'est-ce pas ? Un document de cas de test est composé de nombreux cas de test. Alors, qu'est-ce qu'un cas de test ? Un cas de test est une situation qui montre comment vous allez tester un scénario particulier une exigence particulière ou une histoire utilisateur particulière. Rappelez-vous quand j'ai dit qu' une histoire utilisateur peut indiquer qu'une exigence du BO P peut indiquer que l'utilisateur doit avoir une page de connexion, que vous avez un identifiant utilisateur. Une page de connexion, vous avez un mot de passe. Une page de connexion doit comporter un bouton d'envoi, vous devez pouvoir saisir nom d'utilisateur, le mot de passe et le soumettre pour passer à la page suivante. Ce sont donc toutes des exigences. Maintenant, le cas de test est de savoir comment satisfaire ou comment tester ou couvrir ce cas de test ou ce stockage utilisateur. Disons donc une fonctionnalité de connexion, n'est-ce pas ? Vous entrez un nom d'utilisateur et un mot de passe, cliquez pour que je passe à la page suivante. C'est ce dont tu as besoin. votre cas de test, vous expliquez comment vous allez vérifier que vous avez saisi le nom d'utilisateur, le mot expliquez comment vous allez vérifier que vous avez saisi le nom d'utilisateur, passe, le soumettre et passer à la page suivante. Voilà ce qu'est le cas de test : un cas de test répond à une histoire utilisateur ou à une exigence. Donc, comme je l'ai dit, les exigences sont rédigées par le BAS, le développeur les développe. Maintenant, votre scénario de test, vous testez, vous ne testez pas, vous n'écrivez pas, vous ne testez pas en fonction de l'application. Vous rédigez votre scénario de test en fonction de l'histoire de l'utilisateur. Vous ne vous souciez donc même pas de ce que fait le développeur. Si le QA, le développeur, le BA ou le PO vous donnent dix exigences, dix user stories. N'oubliez pas que nous parlons de témoignages d'utilisateurs, de dix scénarios. Le scénario de test doit comporter au moins dix cas de test. Votre document de cas de test doit contenir au moins dix cas de test. Car n'oubliez pas qu'un scénario peut avoir une partie positive et une partie négative. Ainsi, par exemple, testez une fonctionnalité de journalisation en utilisant un mot de passe. mot de passe peut être composé de huit à dix caractères positifs . Il peut également comporter de 11 à 12 caractères. Il peut également être de sept à huit Ainsi, lorsqu'il est indiqué que le mot de passe requis, le mot de passe doit être composé de huit à dix caractères, sensible à l'utilisation. Votre point positif, c'est qu'ils vont tester la sensibilité sexuelle de huit à dix caractères. Maintenant que votre point négatif est possible, ils vont tester 11 à 12 caractères en faisant la distinction majuscules minuscules pour voir si vous ne devez pas vous donner une erreur. Parce que n'oubliez pas que lorsque vous testez l'exigence, elle indique huit à dix positifs et distinguez majuscules et minuscules. Ainsi, lorsque vous écrivez, lorsque vous testez une application avec le mot de passe, je saisis entre huit et dix caractères en faisant la distinction majuscules et minuscules. Vous êtes en train de faire un test positif. Membres, la question que j'ai dite, vous devez casser l'application, vous devez trouver des défauts. Vous ne trouvez aucun défaut. C'est un drapeau rouge. Vous allez donc en tester 10 à 12 pour voir ce qui va se passer. N'oubliez pas que le critère est de huit à dix, n'est-ce pas ? Vous allez en tester 10 à 12 pour voir s'il va casser et vous donner un message d'erreur. Ils vont en tester sept à huit pour voir s'il va également vous donner un message d'erreur. Vous allez également tester s'il fait la distinction majuscules et minuscules, ils utiliseront des minuscules ou majuscules pour voir s'il va vous donner une erreur. S'il vous donne une erreur, je vais vérifier que cette erreur correspond à ce qui est censé figurer dans l'exigence. Ainsi, lorsque vous rédigez votre scénario de test, c'est vrai, vous devez prendre en compte tous les scénarios de l'histoire utilisateur. Voilà donc ce qu'est un cas de test. Un cas de test consiste à savoir comment répondre à toutes les exigences. Si je dis que vous devez avoir un utilisateur et que vous devez avoir un utilisateur et l'exigence doit vous indiquer quel type de nom de visa, cela peut prendre n'importe quel nom de visa, n'est-ce pas ? Votre cas de test sera donc lorsque je me connecterai à l'application, que je passerai sur la page de connexion, que je saisirai ce nom d'utilisateur. C'est le cas type. Et votre commentaire peut indiquer que vous avez un mot de passe. Comme je l'ai mentionné, l'exigence vous indiquera quel type de mot de passe, huit à dix caractères. Donc, lors de votre test, vous dites : Lorsque je me connecte à cette application, saisissant mon nom d'utilisateur, j'ai saisi ce mot de passe de huit à dix caractères. C'est aussi un autre test que vous pouvez voir, j'ai également saisi dix à 11, dix à 12 caractères. Un autre cas de test peut voir que j'entre sept et huit caractères. Voilà donc ce qu'est un cas de test. Un cas de test répond aux exigences. Vous testez par rapport à cette exigence. Chaque exigence doit donc avoir un cas de test pour couvrir cette exigence. Une autre exigence peut être saisir le mot de passe du nom d'utilisateur, soumettre, de l'amener à la page de connexion. Votre test peut être correct, entrez votre nom d'utilisateur et votre mot de passe, puis soumettez Quand je vais sur la page de connexion, qu'est-ce que je vois ? Vous savez, allez à la page de journalisation. Et tsk, c'est un point positif. Vous pouvez écrire une partie négative et saisir un nom d'utilisateur manquant, entrer un mot de passe, soumettre un et vous devriez recevoir un message d'erreur. Entrez le nom d'utilisateur, le mot de passe oublié, entrez Soumettre, je devrais recevoir un message d'erreur. Et l'exigence vous indiquera si vous recevez un message d'erreur, disons par exemple que vous entrez, vous n' entrez pas le nom d'utilisateur, vous entrez le mot de passe, le Heat Submit. Le message d'erreur doit indiquer le nom d' utilisateur, l'ID utilisateur est manquant. C'est un message d'erreur. Ce sera l' exigence que les exigences soient aussi détaillées. Il n'y a rien de tel que de découvrir quoi que ce soit, comme si le développeur n'était pas en train de découvrir quoi que ce soit Tout ce qui a été prévu avait été documenté par l' analyste commercial ou le PO Lorsque vous dites que vous n'entrez pas de mot de passe et que votre nom d'utilisateur ne saisit pas le mot de passe pour Heat Summit, vous devez lui donner ce message d'erreur c' est ce que les exigences vont voir Dans votre cas de test, vous devez écrire le scénario de test qui dit : OK, je vais laisser le nom d'utilisateur vide, entrer le mot de passe, Heat Summit, je devrais recevoir un message d'erreur. Le message d'erreur correspond-il aux exigences ou au témoignage de l'utilisateur ? Donc, si l'histoire de l'utilisateur indique que d'utilisateur est vide, veuillez saisir le nom d'utilisateur. Lorsque vous réalisez ce scénario, lorsque vous exécutez ce scénario, lorsque vous rédigez le scénario de test, vous devez noter le test. C'est ce que tu es censé voir. Vous êtes censé voir ce cache d'erreur indiquant que le nom d'utilisateur est vide, veuillez saisir le nom d'utilisateur. N'oubliez pas lorsque vous rédigez un scénario de test, lorsque vous rédigez un scénario de test, vous ne testez pas réellement l'application. Non Vous vous apprêtez à tester l'application. Vous êtes donc en train d'écrire tous ces scénarios pour les couvrir. N'oubliez pas que vous n' avez pas l'application. L'application n'a pas été développée, n'est-ce pas ? Vous ne considérez donc que l'exigence. Donc, peu importe ce que dit l' exigence, nous rédigeons des cas de test et cela va être difficile parce que parfois certaines entreprises parce que parfois certaines entreprises doivent maintenant faire appel à Mako Mockups ressemble donc, par exemple, la page de connexion, à quoi la page de journalisation est censée ressembler Ce n'est pas comme l' application elle-même, non. Un MCO peut être comme un PDF, comme un document PDF qui vous montre une image de ce que vous utilisez dans des paragraphes Vous pouvez l'utiliser pour écrire un scénario de test. Vous savez déjà à quoi ressemblera l'application. N'oubliez pas que vous ne testez pas, donc vous ne le faites pas car cela ne sert à rien de sortir l' application. Si vous rédigez votre dossier de test contre l'application. Vous n'apercevrez jamais aucun défaut ni aucune erreur. Vous rédigez donc votre scénario de test sans vous baser sur l'application. Vous l'écrivez en fonction des exigences. R. Donc, quelles que soient les exigences énoncées, vous rédigez votre dossier de test. À l'aide d'un balisage, l'entreprise vous fournit parfois un marqueur, comme un PDF Vous regardez les photos, vous savez, et vous êtes capable d'en écrire davantage pour vous aider à rédiger vos scénarios de test. Ensuite, lorsque l' application vous a été transmise, à vos assignés N'oubliez pas que lorsque vous avez effectué votre test de détection de fumée, vous n'avez fait que vérifier l'apparence et le toucher, vous voyez que l' environnement est prêt. Vous savez, le développeur a fait les tests unitaires, il vous les envoie. Ensuite, vous pouvez maintenant utiliser ces cas de test. Pour tester l'application. N'oubliez pas que lorsque vous lisez, vous êtes prêt à répondre à des scénarios de test comme si vous deviez avoir un identifiant utilisateur Vous accédez à l'application en saisissant votre nom d'utilisateur, oui. Tu devrais avoir un mot de passe. Vous allez sur l'application, entrez le mot de passe. Les exigences, souvenez-vous de vos scénarios de test, vous devriez avoir huit à dix caractères, faire la distinction majuscules et minuscules. Vous entrez huit à dix caractères dans l'application en faisant la distinction majuscules et minuscules, ou si vous pouvez également tester des cas de test négatifs, n'est-ce pas ? Vous pouvez donc saisir de sept à huit. Vous pouvez entrer 10 à 12, vous savez, pour voir si cela va vous donner une erreur. Si cela donne une erreur, ces erreurs correspondent-elles ce qui se trouve sur le document de votre cas de test, sur le document de votre cas de test, vous avez écrit que vous avez bien écrit, envoyez le nom d'utilisateur et le mot de passe. Non, je ne saisis pas de nom d'utilisateur. Je saisis le mot de passe qu'il m'a envoyé. Cela me donne un nom d'utilisateur non valide. Entrez le nom d'utilisateur. L'ID utilisateur n'est pas valide, saisissez-le. Vous l'avez écrit sur le document de votre dossier de test. Maintenant, lorsque vous testez l'application, vous devez comparer le contenu de votre scénario de test à ce que vous voyez sur l'application. Ainsi, peu importe ce que vous voyez sur l'application, vous le comparez aux documents de votre dossier de test. N'oubliez pas que vous avez obtenu votre scénario de test conformément aux exigences. Mais lorsque vous testez l'application, vous ne comparez pas avec l'exigence, vous comparez ce que vous recherchez, le document du cas de test. Ainsi, tout test d'application, quel que soit le scénario exécuté sur l'application, est le guide utilisant votre cas de test pour vous guider. Et le cas de test peut être complexe vous pouvez l'être beaucoup selon le type de test. N'oubliez pas que je parle de tests fonctionnels. Test en boîte noire. C'est tout le nom d'utilisateur et le mot de passe qu'il a soumis. N à n pour tester deux. s'agit également d'un autre processus similaire, mais il s'agit toujours de la même capture lorsque vous rédigez un document de cas de test. Un document de cas de test peut comprendre une fonctionnalité, une régression, acceptation par l' utilisateur, de bout en bout, ajouter qu'Addo n' utilise pas vraiment de documents de cas de test Il est juste aléatoire, mais fonctionnel, boîte noire, régression, tests d'acceptation par les utilisateurs, vous savez, tout cela doit être un cas de test, un cas de test, des cas de test. Donc, vous ne commencez tout simplement pas à utiliser l'application et à essayer des choses, n'est-ce pas ? Non Vous allez écrire le dossier de test sur les cas de test. Une fois que vous avez écrit les cas de test, à l'aide des cas de test, vous allez maintenant les utiliser pour tester l'application. Et vous pouvez joindre votre scénario de test que vous comprenez à la fois avec un scénario positif et négatif. Donc, pas seulement du positif, mais du positif et du négatif. Et je joins également un écran, un document et pièce jointe à cette vidéo montrant comment se déroule habituellement un cas de test. Hein ? Le cas de test apparaît donc dans Donc, il comprend un identifiant de test, qui est tout à fait unique. Vous savez, ça pourrait être 001 ou 002. Chaque cas de test doit donc avoir un identifiant de test, qui est unique. Je devrais avoir un nom de cas de test. Ainsi, le nom du cas de test pourrait être vérifier la connexion » une fois que vous avez entré le mot de passe usam, il vous a envoyé sur la page de connexion Donc, fonctionnalité de connexion. Vous devriez également avoir des marches, non ? Donc, quand je vais sur worm.com, je vais sur la page de connexion, je saisis un mot de passe, je clique sur Soumettre . Tu devrais passer à la suivante. Il s'agit d'un test positif. Vous devriez également avoir un résultat réel et inattendu. Alors, qu' est-ce que vous voyez réellement ? Semblable à un rapport différent de, que voyez-vous ? Quels sont les résultats attendus Les résultats réels sont ce que vous voyez Les résultats attendus sont ce que devraient être les résultats attendus. N'oubliez pas que lorsque vous créez le document du cas de test, nous n'avons pas encore utilisé l'application. Il n'y a donc pas encore de résultat attendu. Une fois que vous l'avez testé sur l'application, vous entrez le résultat attendu et vous voyez simplement s'il est réussi ou non. Mais lorsque vous créez le document du cas de test avant de l' utiliser avant que l' application ne vous parvienne , vous utilisez simplement la maquette de l'exigence. Vous pouvez laisser le résultat attendu en blanc. Vous pouvez laisser passer ou échouer, vous n'avez pas besoin de saisir le résultat attendu, mais le résultat réel, vous savez déjà quel est le résultat réel car vous ne laissez pas le résultat réel vide, mais vous laissez le résultat attendu, vous remplissez le résultat attendu parce que vous savez ce que vous attendez, n'est-ce pas ? Lorsque vous entrez en utilisant pars submit, vous devez accéder à la page de connexion. C'est donc le résultat escompté. Vous n'avez pas encore le résultat réel car vous n'avez pas lancé l' application en direct. Je veux dire que vous n'avez pas encore lancé l'application. Vous pouvez donc laisser le résultat réel vide. Vous pouvez laisser le champ passel vide, vous savez, mais vous devez y inclure l'identifiant du défaut Je veux dire, l'identifiant du cas de test, la description du test, les étapes réelles, les résultats réels. Je suis désolée, résultat attendu. Les résultats réels doivent être vides. Le champ Parsle doit être vide. Et j'agis également en pièce jointe comme un document Excel indiquant quoi devrait ressembler le document du cas de test. Maintenant, il existe des outils. Beaucoup joignent, ils devront écrire un scénario de test à partir d'Excel. Par exemple, il existe des outils qui vous permettent d'aimer, c'est déjà comme l'identifiant du cas de test, qui est déjà généré lui-même pour vous. vous suffit saisir le nom du cas de test, description, les résultats réels, etc. D'autres choses sont déjà là. Mais bien souvent, comme ils disposent déjà d'outils, il existe des outils qui vous permettent de saisir des scénarios de test. Mais je veux dire, il y a aussi des scénarios où vous ne disposez pas de ces outils. Vous devez réellement le suivre sur Excel. Donc, ce que je centime Excel, ce qui est joint aux vidéos Excel. Mais vous pouvez suivre la même logique. Une fois que vous savez comment écrire ces scénarios de test sur Excel, même s'ils disposent d'un outil, vous pouvez faire la même chose. Vous pouvez le reproduire, c' est la même chose. Il s'agit donc de rédiger des cas de test documentés. 26. Données de test: Le prochain artefact dont nous allons parler concerne les données de test. Que sont les données de test ? Les données de test sont des données ou des informations que vous utilisez pour étayer votre scénario de test. Un exemple typique, comme je l'ai mentionné avec les cas de test, est la saisie du nom d'utilisateur, du mot de passe et du bouton Soumettre en tête. Les données de test signifient quelles informations saisissez-vous pour étayer votre scénario de test ? Quel identifiant, quelles données utilisez-vous pour étayer votre scénario de test. Par exemple, un cas de test typique peut être la saisie du nom d'utilisateur, du mot de passe, de l'en-tête et du bouton Soumettre. Maintenant, les données de test sont quel nom d'utilisateur saisissez-vous ? Quel mot de passe sais-tu ? Nous allons revenir à l'exemple Walmart où le mot de passe peut comporter de huit à dix caractères, et lorsque vous testez réellement le chemin positif, vous allez créer des données de test pour le parsle contenant de huit à dix C'est une voie positive. Vous allez également créer des données sept à huit ou six à sept caractères pour voir si elles vont échouer. Vous allez également créer des données de 11 à 12 caractères pour voir si elles vont échouer. En fonction des critères du mot de passe, vous pouvez créer des données de test. Cela n'a rien de complexe, cela peut être quelque chose de générique, cela peut être tout ce qui vous vient à l'esprit ou basé sur ce que l' exigence indique. Il n'est pas nécessaire que ce soit une sorte de donnée insensée ou quoi que ce soit d'autre. C'est juste quelque chose de aléatoire. La plupart de ces données sont fausses ou factices. Très souvent les développeurs vous aident avec ces données, et s'ils ne vous soutiennent pas, vous devez créer vos propres données. Il n'existe désormais aucun référentiel ni aucun outil que vous pouvez utiliser pour stocker des données. Souvent, vous stockez ces données sur des feuilles Excel, vous avez donc votre propre feuille Excel, vous créez où tous vos scénarios, où tous vos scénarios, se trouvent sur l'outil ou Excel ou toute autre application installent vos scénarios de test. Vous pourriez en fait remplir votre scénario de test, vos données de test dans le scénario de test. Ainsi, par exemple, lorsque vous rédigez votre scénario de test, vous pouvez vérifier les exigences , vous pouvez vous connecter. Lorsque vous rédigez votre scénario de test, vous pouvez saisir le nom d'utilisateur et le mot de passe qu'il soumet. Vos données de test peuvent en fait être saisies dans le scénario de test. Vous pouvez donc dire entrez le nom d'utilisateur, quel que soit le nom , John Smith, entrez le mot de passe, quel que soit le mot de passe , appuyez sur le bouton Summit. C'est en fait une autre façon de créer votre scénario de test. Vous pouvez donc créer un cas de test contenant des données de test. Parfois, cela peut être générique où il suffit de saisir le nom d'utilisateur et le mot de passe. C'est un cas de test standard typique. Mais vous pouvez également saisir les données en même temps que le scénario de test. Vous pourriez donc dire entrez votre nom d'utilisateur, Charlie, entrez le mot de passe, les informations, appuyez sur le bouton Summit. Vous pouvez donc saisir vos données de test dans votre scénario de test, vous savez, ainsi que dans des outils, comme je l'ai mentionné, où vous pouvez réellement stocker votre scénario de test. Je vais donc expliquer quel type d'outils vous pouvez utiliser pour créer un cas de test afin de créer un cas de test en dehors des documents Excel Excel. Ainsi, avec ces outils, vous pouvez réellement saisir votre scénario de test et saisir vos données de test en votre scénario de test et saisir vos données de test en même temps que votre cas de test, ce avec vos cas de test. Les données de test sont donc très obligatoires, vous savez. Lorsque vous testez le système, testez l'application, il faut utiliser des données. Comment allez-vous interroger la base de données ? Comment allez-vous interroger l'application ? Ainsi, lorsque vous vous connectez réellement à un système, lorsque vous vous connectez à une application, quels nom d'utilisateur et mot de passe saisissez-vous ? Vous devez saisir quelque chose, non ? Donc, certainement, vous avez besoin données de test pour étayer votre scénario de test. Les données de test sont désormais très importantes. Vous n'êtes pas obligé de le créer tout le temps. Le biologiste et pour les données qui vous seront fournies pour les tests en fonction du type de test que vous effectuez Il existe en fait différents types de peut-être que certains tests peuvent nécessiter ce privilège. Peut-être que cet utilisateur y a accès. Cet autre utilisateur a accès à cette fonctionnalité. Je veux dire, ce genre de tests se pose également. Ce type de test nécessitera le type de données que vous allez également obtenir de l'aide du développeur pour créer ces données de test. Parfois, si c'est complexe, s'il s'agit de données qui nécessitent un type de création spécifique ou si vous avez peut-être besoin pour créer un type de données spécifique. Vous bénéficiez toujours du soutien des développeurs pour créer ces données. Parfois, vous n'êtes pas obligé de le faire vous-même. Mais si c'est quelque chose comme très simple en termes de création d' un nom d'utilisateur et d'un mot de passe standard , je veux dire, c'est quelque chose que vous pouvez créer au hasard tout ce que vous voulez. J'explique donc que les données de test sont cruciales pour étayer votre scénario de test, et les données de test peuvent également déterminer. En termes de création de données de test, elles peuvent déterminer le type de fonctionnalité ou le type d' application que vous testez. Il se peut donc que vous deviez créer un type spécifique d'applications ou d'éléments sensibles pour créer un type spécifique de données de test. Vous ne pouvez donc pas simplement créer un test aléatoire thêta. Il doit s'agir de données de test adaptées à l'objectif, et tout cela découlera des exigences. Cela viendra des user stories. Toutes ces instructions seront fournies en fonction de la façon dont vous souhaitez créer le test aa. 27. Rapport de défauts: Et l'artefact ou document final est un rapport de défaut. Vous savez, avez-vous parlé des défauts et, vous savez, de ce qu'est un défaut. Vous savez, le simple fait de répéter un défaut est une erreur, une erreur, vous savez, un bogue. C'est ce que nous appelons un défaut. Qu'est-ce qu'un rapport de défaut, n'est-ce pas ? Un rapport de défaut est donc un document qui indique l'état ou les situations actuelles de votre défaut, de vos erreurs ou de vos bogues. Rappelez-vous quand je vous ai dit que lorsque le développeur teste l'application, je veux dire qu'il développe l' application et l'envoie à votre usine pour que vous puissiez commencer à tester. Vous allez rencontrer de multiples défauts. Vous allez rencontrer plusieurs erreurs. Vous allez rencontrer des problèmes avec l'application. C'est naturel. Rappelez-vous que je vous ai dit que si vous ne trouvez pas problèmes ou de défauts, vous ne faites pas votre travail. Votre travail consiste donc en fait à trouver les défauts et à casser l'application. Nous allons donc rencontrer plusieurs erreurs, bogues, vous savez, des problèmes qui ne correspondent pas aux exigences et qui ne correspondent pas à l'histoire de l'utilisateur. Lorsque vous rencontrez ce problème, que faites-vous ? C'est ce que nous appelons une défectiade. Il existe en fait un processus que j'ai expliqué plus tôt en termes de manière de résoudre les problèmes, les erreurs ou les bogues que vous rencontrez. Exemple typique, vous trouvez une erreur sur la page de connexion, vous appuyez sur le bouton d'envoi, ça ne marche pas, rien ne fonctionne. C'est un bug. Quel type de bogue est-ce une priorité absolue car les clients ne pourront pas se connecter à l' application pour mettre à jour leur carte et vérifier des informations de ce type ? C'est une priorité absolue. Je peux donc aussi expliquer quoi un défaut, un défaut général ressemble à quoi il consiste, n'est-ce pas ? Donc, l'identifiant du défaut, la description, les étapes à reproduire, les étapes réelles, les résultats attendus. Donc tout ça, c'est vrai. Donc, un rapport de défaut. Souvent, vous pouvez utiliser Excel, mais je ne le sais pas vraiment. Je n'aime pas vraiment Excel car il s'agit d'un rapport de défaut qui doit être un document actif car il est constamment mis à jour dans les deux sens. Mais par souci de simplicité, j'ai joint un rapport de défaut Excel pour que vous puissiez y jeter un œil. Mais les outils que vous utilisez réellement pour gérer les défauts. De nombreux outils que vous utilisez pour saisir des cas de test, gérer le document de votre cas de test, etc. Ils ont également un endroit où vous pouvez réellement saisir le défaut et le gérer. Je vais expliquer à nouveau le défaut ou le cycle de vie du défaut. Lorsqu'une erreur est détectée ou qu'un défaut est détecté, n'est-ce pas ? Vous le saisissez, l'identifiant du défaut, les étapes de description à reproduire, résultat attendu, les résultats réels. Capture d'écran. Les captures d'écran sont également très importantes. Des captures d'écran, c'est ce que vous voyez. Ainsi, lorsque vous l'envoyez au développeur parce que celui-ci est très occupé, il veut voir vos informations et être en mesure de vous indiquer où elles échouent. Tu ne veux pas commencer à te lever la tête. Une fois que vous l'avez envoyé au développeur, le statut est nouveau. Le développeur le choisit, change le statut ouvert, y travaille. Vous le renvoie aussi fixe que les étoiles. Une fois que vous l'avez récupéré, vous le testez à nouveau. Rappelez-vous que j'ai dit que lorsque vous testez à nouveau un défaut, vous testez également dans d'autres domaines. Vous ne testez tout simplement pas ce problème. Vous testez plusieurs choses. Par exemple, si cela indique que le bouton du sommet est réparé, vous testez également ce qui se passe si le nom d'utilisateur est manquant, le mot de passe est là et si vous entendez le sommet. Vous testez d'autres pièces à travers cela. Vous ne vous contentez pas de tester uniquement le bouton du sommet. Une fois que vous avez testé ou corrigé, vous modifiez le défaut pour qu'il se résorbe et c'est fait. Si le problème persiste, rouvrez-le et renvoyez-le au développeur. Souvent, il est impossible d'avoir des commentaires. Si vous utilisez réellement un outil , je vais vous expliquer les types d'outils. Si vous utilisez réellement un outil, n'est-ce pas ? Il existe des quiz où vous pouvez saisir des commentaires. Ainsi, vous et le développeur, ainsi que le BA ou le PO, pouvez échanger des communications. Par exemple, si vous rencontrez un problème, vous l'enregistrez, vous enregistrez le défaut dans le fichier que vous l' attribuez au développeur et que vous souhaitez ajouter un commentaire sur le défaut. Vous pourriez dire que vous pouvez communiquer avec le Def si vous voulez dire quoi que ce soit. Nécessairement, il existe en fait un format de défaut, et il existe un outil que vous utilisez pour saisir les défauts. Le même outil est le même que celui que vous utilisez pour saisir votre scénario de test, vos scénarios de test . Il y en a donc 12. Mais dans la section des défauts, vous créez un rapport. Il existe en fait un modèle dans lequel vous cliquez sur le défaut. Si tout va se remplir et qu'il vous suffit de saisir le défaut est déjà généré automatiquement Il vous suffit de saisir dans la définition le nom, la description, les étapes à suivre pour reproduire les arts. Tout est prêt, le modèle est prêt à être conçu pour vous. Il vous suffit donc de saisir les informations, joindre votre capture d'écran et le tour est joué. Dans cette capture d'écran, ce modèle, lorsque vous l'envoyez au développeur en tant que nouveau vous pouvez également saisir des commentaires. Je dis que c'est parce que c'est une façon pour vous de communiquer avec le développeur. Parfois, le développeur peut dire : « Oh, je ne suis pas en mesure de voir quelle est l' erreur, des choses comme ça ». C'est ainsi que vous pouvez être le développeur et le BA. Le PO peut également échanger communications à des fins de traçabilité afin de voir ce qui se passe. Une fois que vous l'avez saisi, c'est ainsi que vous continuez à faire des allers-retours. Les étoiles ne cessent de changer. Donc, la raison pour laquelle j'ai joint un document dans Excel, c'est juste pour que vous puissiez voir à quoi ressemble un rapport de défaut. Souvent, très peu de cas où vous utilisez une feuille Excel, où gérer. Mais au cas où ils n'auraient pas d'outil, j'ai joint une feuille Excel pour vous permettre voir à quoi ressemble généralement un rapport de défaut dans Excel. Mais en général, il existe des outils dans lesquels le même outil utilisant la création d'un scénario de test est également le même outil utilisant une entrée ou un défaut. Le défaut est également très important en termes de cycle de vie du défaut. Tu vas te demander. C'est donc un entretien, une question sur l'action. Expliquez-moi le cycle de vie d'un défaut. Le cycle de vie d'un défaut est essentiellement le moment où vous testez une application, vous trouvez une erreur, vous trouvez un bogue ou un défaut, et la façon dont vous travaillez sur le bogue pour vous assurer que, entre moment où vous ouvrez un défaut et celui où le développeur le sélectionne, vous le renvoyez, vous le retestez, vous le fermez, c'est un cycle de vie différent Si le cycle de vie signifie qu'il s'écoule entre le moment où le défaut est découvert et le moment où le défaut est résolu, que se passe-t-il à cet égard ? Cela vient de la membrane et celui l'entier était un ici, le statut, Sus est très important Celui qui est là quand j'ouvre le défaut, tu sais, je mets l'état comme neuf Il l'a attribué au développeur. Il l'a ouvert, l'a mis comme ouvert, a travaillé et me l'a renvoyé sous forme fixe. Je l'ai retesté une fois que tout a été fait, je l'ai fermé. Donc, celui qui est là, c'est le statut. Un cycle de vie déférent qui met l'accent sur les étoiles. Donc, comment cela passe de vous au développeur dans les deux sens, vous savez, jusqu'à ce que le défaut soit résolu. Lorsqu'un défaut est résolu, c'est la fin de ce cycle de vie, qui a été corrigé. Comme je l'ai mentionné, vous pouvez parfois vous le renvoyer, vous voyez qu'il y a des problèmes, vous le rouvrez, le lui renvoyez, vous continuez à faire des allers-retours et le statut Le statut est très important et nous l'attribuons à Parce que lorsque le développeur travaille dessus sur une application défectueuse, la seule chose qu'il regarde, c'est le statut. Si c'est nouveau, alors il va travailler dessus. Si c'est serré, il s'en fout parce que c' est terminé. Sus est très important. Lorsque vous expliquez à vos intervieweurs, Sus, en termes de défauts, ils veulent connaître le statut, comment cela a-t-il évolué ? Qu'est-ce que le sterus ? Quand tu l'as ouvert, tu trouves un insecte, de quel sterus s'agit-il ? Nouveau. Lorsque vous le leur envoyez, il est ouvert, le développeur l'ouvre, il vous le renvoie tel que corrigé, puis vous travaillez dessus, vous le fermez. C'est ce qu'ils appellent le cycle de vie des défauts. C'est également très important. C'est essentiel dans votre rôle d'ingénieur en assurance qualité, façon dont vous gérez les défauts. De plus, avec les priorités, comme chaque défaut, vous avez une priorité, élevée, moyenne, faible. J'ai mentionné qu'il fallait fixer une priorité élevée à une priorité moyenne. Ils doivent être travaillés. N'oubliez pas d'expliquer également dans le plan de test vos critères de sortie selon lesquels vous ne pouvez pas avoir de défauts moyens ou élevés, et de donner les termes selon lesquels vous avez effectué votre travail. Non. Tous les défauts élevés et moyens doivent être corrigés. Les faibles priorités sont acceptables, mais ce sont des problèmes connus. N'oubliez pas que j'ai parlé de problèmes connus. Vous pouvez faire remarquer à votre responsable Q way, au BA ou au PO qu'il s'agit de problèmes connus. Pour des raisons de temps, ils n' auront peut-être pas à réparer tous les défauts, car le temps c'est de l'argent. Mais la priorité moyenne élevée doit être fixée et doit être supprimée. Une faible priorité, c'est bien, vous pouvez la conserver, vous pouvez la laisser être, car cela n' empêche pas le client de faire ce qu'il fait. Les priorités élevées, moyennes, élevées et moyennes sont des obstacles. Ils sont des bloqueurs. Ce sont des facteurs qui empêcheront le client de faire ce qu'il veut faire. Oui, donc en général, vous savez, signaler les défauts est très important dans votre travail quotidien. Vous savez, c'est très important de la façon dont vous travaillez en tant qu'assurance qualité , de la façon dont vous gérez vos défauts qui est de la façon dont vous travaillez en tant qu'assurance qualité, de la façon dont vous gérez vos défauts. Avant donner votre feu vert, vous voulez vous assurer que tous portent réellement priorité moyenne la plus élevée et aussi sur la personne à qui vous attribuez vos défauts Donc, pour chaque défaut, souvenez-vous quand j'ai dit que vous créez, vous trouvez le bogue ou vous trouvez une erreur, et vous passez aux deux et il s'agit en fait d'une section où vous dites que vous cliquez sur les défauts, sur le modèle ou sur des informations générées automatiquement sur les personnes âgées La personne que vous désignez est également très importante. Parce que chaque fois que vous attribuez ce défaut à cela, cela déterminera qui va travailler dessus. Si vous l'attribuez au développeur, il peut parfois y avoir un type spécifique de développeur qui va travailler sur ce défaut. Lorsque vous l' attribuez, vous ne l' attribuez simplement à personne ou vous ne l'attribuez pas du tout. ce défaut à certaines personnes avec lesquelles nous Vous devez attribuer ce défaut à certaines personnes avec lesquelles nous travaillons. Tout cela est un peu comme ce qui constitue et j'ai en fait une capture d'écran. Je veux dire, j'ai un rapport, un rapport de défaut que vous pouvez consulter pour voir quelle est la norme en termes de création d'un défaut. Toutes ces informations seront en fait renseignées automatiquement pour que vous puissiez saisir vos informations et enregistrer le défaut. 28. Introduction aux outils: Nous avons maintenant terminé notre section en Q. J'ai donc parlé, vous savez, du SDLC, du processus du cycle de vie du développement logiciel , des méthodologies, de l' Agile, de la cascade, à quoi sert l'assurance qualité quels types de tests effectuent-ils ? Tu sais, quels sont les artefacts ? Ou quels sont les documents ? Vous savez, l'assurance qualité que vous êtes censé avoir ou établir et quel processus élaborent-ils tout cela ? Et aussi, vous savez, quels types de tests encore une fois, comme donner un aperçu de ce que fait Q way et de la place de Q way dans le SDLC, où nous situons-nous dans les phases, à la fois dans Agile et dans Waterfall Dans la prochaine vidéo, je vais parler des outils, vous savez, quels sont les outils utilisés par l'assurance qualité pour effectuer leurs activités quotidiennes, et aussi à quoi servent les outils, vous savez, et aussi comment vous pouvez accélérer l' apprentissage de ces outils Rien de complexe, c'est très facile de s'y retrouver. Je vais également parler de différents types d'outils, uniquement pour le manuel, mais aussi pour le manuel et l'automatisation. J'aborderai donc tout cela dans la prochaine vidéo. 29. Types d'outils: Pour les outils, pour les tests de mano, il existe un outil très populaire Et quand j'ai commencé ma carrière, j'utilisais beaucoup cet outil. Il s'appelait Quality Center ALM. Je ne suis donc pas en mesure de vous montrer l'outil, mais vous pouvez trouver que vous pourriez utiliser Google Quality Center AM. Vous allez voir le PDF dans lequel vous pouvez réellement trouver un Google qui péage L'outil est donc spécifiquement destiné à l'assurance qualité. Vous savez, cet outil est conçu uniquement pour les tests d'assurance qualité. Donc, vous savez, il explique comment saisir vos scénarios de test. Ainsi, dans Quality Center ALM, vous pouvez réellement entrer et créer un cas de test création d'un cas de test est là Vous pourriez saisir des défauts et des erreurs. Vous pouvez utiliser l'outil pour gérer le processus du cycle de vie des défauts. Vous pouvez saisir des défauts et les attribuer au développeur. Le développeur a également accès au centre de qualité ALM, où il peut réellement travailler sur ces défauts et les renvoyer pour envoyer la mémoire sur le processus de cycle de vie des défauts centre de qualité ALM est idéal pour gérer les défauts, vous savez, et aussi pour saisir des cas de test, saisir des cas de test manuels Le centre de qualité ALM est donc destiné aux tests manuels. Vous savez, je suis en train d'ajouter fonctionnalités où vous pourriez également automatiser, mais c'est uniquement basé sur des tests manuels. Un autre outil est Jira. Jira est donc un peu une nouveauté. C'est donc un peu comme la nouvelle application ou le nouvel outil pour tout un tas de choses. Jira est principalement utilisé pour Agile, où les développeurs PO, Scrum Masters et Lights sont, vous savez, un outil très robuste Mais le centre de qualité et les testeurs peuvent également utiliser Jira, mais pour y accéder , ils ont besoin d'un ajout appelé X-ray X ray est une fonctionnalité ajoutée à Jira qui vous permet de rédiger des scénarios de test et de saisir les défauts Je pense que c'est en fait le nouvel outil disponible. Le centre de qualité est B, je veux dire, il existe depuis des années. Quand j'ai commencé ma carrière, c'est tout ce que nous utilisions. Mais maintenant, Jira revient à prendre le relais, car grâce à l'agilité, Jira est très populaire et Je pense donc que de nombreuses entreprises optent pour Jira Vous savez, et pour accéder à Jira, vous avez besoin d'un plugin appelé X ray Et je veux dire qu'en termes de saisie de scénarios de test, gestion des défauts, le processus est le même. Le centre de qualité, Jira, est pareil. Vous savez, chaque cas de test, son identifiant, sa description, le nom du test, les résultats attendus réels, il va de même pour Polity Center AM et gia Le document que j'ai joint vous montrera donc comment un cas est censé être saisi, comment un défaut est censé être saisi. Ainsi, même si vous utilisez centre de qualité d'outils ALM ou Jira, vous suffit de saisir ces informations Cela va donc de soi. Lorsque vous accédez à l'outil, vous verrez toutes les informations nécessaires pour que vous puissiez simplement manger. Donc tu as juste besoin de savoir qui tu es roi, qui tu es roi. Donc, assignez, priorisez, vous savez, une perte élevée à moyenne, toutes ces choses. C'est donc à peu près standard dans tous les domaines. Maintenant, en ce qui concerne les tests d'automatisation , n'oubliez pas que lorsque j'en ai parlé, c'est nouveau. C'est vers cela que se dirigent de nombreuses entreprises , vers laquelle s'oriente le secteur, tous les secteurs optent pour l' automatisation, car dans la mesure où c'est automatisation, car dans la mesure moins cher pour elles, n'est-ce pas ? Il s'agit donc d'un rôle ou d'une tâche que dix testeurs Q effectueront. Seuls deux ou un testeur d'automatisation pouvaient tout faire. Donc, même si les tests manuels ne disparaîtront jamais. Donc, n'ayez pas peur , car les tests manuels n' auront jamais lieu, ce qui sera toujours le cas, vous savez, mais l'automatisation c'est un peu comme si vous voulez plus d'argent, si vous voulez améliorer votre courant, si vous êtes doué pour le codage parce que l'automatisation est une sorte de script, etc. il existe différents langages vous permettant de créer des scripts en Java, n' auront jamais lieu, ce qui sera toujours le cas, vous savez, mais l'automatisation, c'est un peu comme si vous voulez plus d'argent, si vous voulez améliorer votre courant, si vous êtes doué pour le codage parce que l'automatisation est une sorte de script, il existe différents langages vous permettant de créer des scripts en Java, en C sharp, Donc, si vous voulez faire avancer votre carrière, obtenir un emploi plus rapidement, gagner plus d'argent, l'automatisation est un peu comme l'avenir. Mais ce que je devais faire aujourd'hui était un manuel, il y en aura toujours un. Il existe en fait des entreprises qui ont toujours des testeurs manuels, et vous pourriez gagner votre vie en tant que testeur manuel. N'aie pas peur, Manuel, je sais que je suis en faillite ou que je n'ai pas de travail. Non, tu trouves toujours un travail et un bon travail. Pour l'automatisation, les deux sont très populaires auprès du sélénium. Selenium est un IDE qui permet de créer des scripts. Le sélénium interagit avec l'application via le front-end Par exemple, comme dans le cas typique de worm.com. Vous écrivez vos scripts sur du sélénium et vous liez le sélénium au site Web de Walmart soit le code que vous écrivez, vous l'écrivez sur du sélénium Vous écrivez votre script sur du sélénium. Un sélénium interagit avec la page Walmart pour faire ce que vous voulez Par exemple, exemple typique, je veux juste tester la fonctionnalité de journalisation, le nom d'utilisateur, le mot de passe, le bouton d' envoi. Je vais écrire que je vais programmer ça en sélénium. Selenium parlera à Walmart et dira : « OK, Walmart, allez sur la page de connexion, entrez le nom d'utilisateur, entrez ce mot de passe, saisissez-le sur le Qu'est-ce que tu vois ? Donc, quoi qu'il arrive lorsque l'on clique sur le nom d'utilisateur, le mot de passe et l'envoi sur le Walmart, Selenium lira ces informations affichera et vous les renverra Alors tu vas sur Seleu et tu vois, ce pass. Vous m'avez emmenée jusqu'au cou pour me connecter, je m'ai fait passer l'accès aux informations de connexion, j'ai accès au compte client maintenant, ou vous pourriez dire qu'il a échoué. Le mot de passe n'était pas valide. Tu vas voir. C'est donc un outil très cool, vous savez, et l'automatisation est intéressante, en fait, c'est très intéressant, vous savez, donc c'est très amusant. Vous savez, je pense que Mana est également très interactif, très analytique. Tu sais, tu dois toujours sortir des sentiers battus et trouver des moyens. Mais l'automatisation est également un avenir très intéressant à apprendre. Vous savez ainsi que vous ne chercherez jamais d'emploi, car en termes de SDLC, d'informatique, de processus de cycle de vie du développement logiciel et de création d'une application de A à Z. Le centre de qualité est aussi important et pertinent que les développeurs, car nous devons effectuer des tests. Tu sais, ils testent tout. Donc, non seulement l'application est correcte, même le matériel, vous savez, avions, les voitures, est testé Donc, lorsque nous développons le testé. Mais ce que j' enseigne aujourd'hui porte sur les logiciels, les applications, les outils logiciels. Ce sont donc les choses dont je suis en quelque sorte en train de parler, donc ce sont les tests d'assurance qualité. Mais en général, tout doit être testé. Tout ce que vous publiez doit être testé, car si vous ne le testez pas et qu'il y a un problème, ils reviendront vous poursuivre pour beaucoup d'argent et de dommages et intérêts et, vous savez, pour des risques élevés dans votre vie. Les co-tests sont donc très importants dans la vie. Ce que j'enseigne actuellement, ce sont les applications logicielles, et chaque application doit être testée. Imaginez chaque assurance qualité, il existe en fait un poste ou une règle pour les ingénieurs d'assurance qualité car l'application doit être testée. Les développeurs ne peuvent pas tester leur travail. Cela revient en fait à dire qu'il n'est pas approprié dans le monde informatique les développeurs testent leur travail. Imaginez que lorsque vous écrivez votre code et que vous le testez , vous allez bien sûr être biaisé. C'est pourquoi ils ont toujours un peuple indépendant. Ils ont toujours des personnes chargées de l'assurance qualité pour tester réellement leur travail. L'assurance qualité est donc très importante. L'assurance qualité est très pertinente. Ils auront toujours besoin de Q Ways. Je préfère le manuel, l'automatisation automatique est meilleure parce qu'une automatisation peut aussi être manuelle. Mais le manuel est également très pertinent pour qu'ils ne disparaissent pas. Pensez-y comme s'il s' agissait d' une bonne carrière, car vous n'avez pas l' impression que cela va disparaître dans les dix ou 15 prochaines années. Non Q sera toujours très demandé. Il a toujours été très demandé. Depuis le début de ma carrière il y a plus de dix ou 15 ans, Q est toujours très demandé et sera toujours très demandé. 30. Vers l'industrie: Donc, pour ce qui est de l'orientation du secteur, je sais que j'ai parlé du SDLC et de toutes les phases des exigences, du développement, des tests, du déploiement et de la maintenance C'est donc comme la norme, et c'est ainsi qu'il est passé de Waterfall à Agile. Aujourd'hui, de nombreuses entreprises optent pour le cloud, nombreux pipelines d' ingénierie Devo DeVox et CICD manière dont les données sont réellement stockées dans le cloud et sur la manière dont les personnes ou l'application interagissent avec les données En termes d' assurance qualité, je pense que vous devriez toujours adopter cette mentalité d'apprentissage continu. Donc, vous ne devez tout simplement pas suivre un cours Redis, trouver un emploi et être comme si j'en avais fini, je veux dire, un ingénieur qualité Q. Non Cela ne s'arrête pas là. Il faut toujours continuer à apprendre. Les industries continuent l'industrie est en constante évolution. De nouvelles choses ne cessent de surgir. Vous devez continuer à progresser, apprendre des choses ou moins, vous serez dépassé. C'est comme si vous essayez réellement de progresser, si vous n'apprenez rien, vous vous retrouvez coincé dans un trou. Et je suis sûr que vous allez probablement vous ennuyer. Continuez toujours à apprendre. Continuez toujours à apprendre, à progresser. Vous savez, je pense que même si vous voulez toujours rester , disons que vous avez une église, vous voulez rester dans les tests manuels, vous ne voulez pas vous lancer dans l'automatisation, mais vous pouvez toujours progresser dans les tests manuels, et ainsi de suite. Par exemple, j'ai expliqué comment tester le site Web de Walmart, qui pourrait être une page Web standard Maintenant, dans le domaine de l'informatique, il y a différents types de choses que vous allez tester. Vous n'allez pas simplement tester des sites Web. Ils ont des CRM, vous savez, ils ont un CMS, un système de gestion de contenu, vous savez, des responsables de la relation client Différentes manières de tester. Vous savez, vous pourriez tester les ML, vous savez, les différents, pas seulement les pages Web Donc, sur la question de l'entretien, vous pouvez vous demander : qu'avez-vous testé ? S'agit-il d'une page Web, du matériel informatique, vous savez, le genre de choses qui m'interviewent, exemple en termes de type d'applications que vous testez. Nous sommes différents types d'applications. Vous savez, ce sont, vous savez, standards typiques comme les sites Web. Vous savez, c'est généralement walmart.com, vous savez, testez la page d'accueil, vous savez, la page de connexion Vous pouvez modifier, ajouter des éléments à votre carte, vous pouvez consulter ce qui est typique, vous savez, d'une page Web. Mais il s'agit en fait de différents types d' applications et de choses que Q Ways teste. Donc, ne vous contentez pas de penser que vous savez, vous allez simplement tester un site Web. Non Vous savez, ils ont des ML, ils ont une interface utilisateur Soap Tu sais, ils ont tellement de choses qu'ils veulent que tu testes. Et je ne dis pas cela pour vous submerger, mais juste pour vous préparer, l'assurance qualité est dynamique, n'est-ce pas ? C'est un poste dynamique où il n'est pas nécessaire de tout apprendre, n'est-ce pas ? Vous pouvez simplement vous concentrer sur ce avec quoi vous êtes à l'aise et sur ce que vous pouvez vous lancer le défi de faire. Vous savez, je pense qu' une chose est également de sauvegarder une base de données. J'ai parlé de données, mais beaucoup de données sont stockées dans le back-end, et il existe des outils que vous utilisez pour stocker ces données Il peut donc s'agir d'Oracle SQL ou d'autres outils de ce genre. Aujourd'hui, la plupart de ces données sont en fait transférées vers le cloud. Parfois, ils peuvent vous demander de faire des tests de backend. Les tests Ben sont en fait lorsqu' il s'agit de tester le backend, les tests Ben testent la base de données Souvenez-vous que quand je dis Walmart, Walmart.com, page de connexion et tout ça, c'est ce qu'on appelle front-end est ce que vous pouvez voir, comme ce que le client verra. La fin B correspond à ce qui se passe au dos de l'application. Les données qui se déplacent. Lorsque vous entrez le nom d'utilisateur, le pass atteindra le sommet. C'est le front end. Ce qui se passe au niveau du back-end, c'est que ce nom d'utilisateur , où vous entrez les données , vous entrez dans l'onglet nom d'utilisateur va accéder au backend, où les données sont réellement stockées, et il va vérifier si ce nom d'utilisateur existe ? Si vous entrez Charlie comme nom d'utilisateur, le mot de passe sera saisi. Supposons que vous saisissiez les informations du mot de passe et que vous appuyiez sur le bouton Summit. Ce qui se passe au front end, c'est que vous entrez le nom d'utilisateur, les informations de mot de passe C char, le bouton d'envoi. Maintenant, au niveau du back-end, ce sommet sur les mots de passe Charlie va déclencher le backend et vérifier. Y a-t-il un Charlie, et s'il y a un caractère, quel est le mot de passe ? Est-ce que les informations du mot de passe sont les informations, et si le mot de passe est cette information, autorisez l'accès. Hein ? C'est donc le backend. Maintenant, les clients vont voir cela sur le back-end, le nom d'utilisateur complet, le mot de passe et toutes ces choses. Je veux dire, au niveau du backend , il y avait le support. C'est ce qu'ils appellent les tests du back-end. Et c'est très crucial car de nombreux intervieweurs qui ont demandé, vous savez, ils recherchent un testeur de backend Donc, le testeur de backend est ce qu'il vous faut pour réellement tester le backend, n'est-ce pas ? Vous ne vous contentez pas d'écrire des requêtes SQL. Des requêtes SQL comme celles auxquelles vous interrogez la base de données. C'est aussi un autre type de test. B end est également très important car c'est aussi parfois un Q, ils peuvent vous engager pour le front end et le back-end. Lorsque vous entendez « front end », « front end » ne fait que tester la face avant de l'application. Donc, utilisez le mot de passe, soumettez, accédez à la carte, ajoutez une carte, retirez la carte, consultez cette interface. backend interroge maintenant la base de données, il peut donc y avoir tellement de problèmes au niveau du back-end Donc, vous savez, et pour pouvoir interroger le backend, vous devez être à l'aise avec l' écriture de requêtes SQL. La requête SQL est également très importante en tant que rôle ou compétence pour un ingénieur d'assurance qualité, capable d'interroger la base de données. Pour interroger la base de données, vous devez écrire un langage de requête structurel. Ce n'est pas si complexe, mais c'est une façon d'interagir avec la base de données, car la base de données ne sait pas ce que c'est . Comment puis-je vérifier le nom d'utilisateur Ce n'est pas un langage que la base de données comprendra. Vous devez donc être capable d' interagir avec les données du back-end, vous devez être capable d' écrire le langage que les données du back-end comprendront. Si vous essayez de vérifier le contenu, si Charlie existe, ou si vous voulez vérifier combien d'identifiants trouvent à la Nouvelle-Orléans, peut-être chez Walmart Par exemple maintenant. Vous souhaitez vérifier combien d'utilisateurs utilisent l'application Walmart à La Nouvelle-Orléans Vous allez dans le backend et vous rédigez une requête. Vous n'allez pas entrer le nombre de noms d'utilisateur ou d'ID utilisateur qui utilisent walmart.com La base de données ne va pas comprendre cela. Il existe un moyen d'interagir avec la base de données ou une langue que vous saisissez afin que les données du backend puissent comprendre ce que vous dites et indiquer le nombre d'identifiants utilisateurs Nouvelle-Orléans qui utilisent walmart.com Donc, Data, ce que je veux dire, c'est que les tests du back-end des données sont également essentiels dans votre rôle d'ingénieur en assurance qualité. Donc, ce que j'ai expliqué jusqu'à présent, ce sont les types de tests, les tests fonctionnels, etc. tests, les tests fonctionnels Mais les tests de backend sont également très cruciaux. Je n'ai pas vraiment abordé le sujet, je n'ai pas beaucoup expliqué sur les tests de backend car c'est aussi un autre sujet à part entière. C'est aussi parce que pour pouvoir effectuer des tests de back-end, vous devez savoir comment écrire des requêtes. Vous devez être capable d'être bon en S QR. Si vous voulez en savoir plus sur les tests de back-end, je vous suggère de consulter des cours qui expliquent comment écrire des requêtes, comment interroger la base de données, etc. Une fois que vous l'avez prêté et que vous connaissez le fronting, front-end ressemble généralement à de simples tests de manoir, comme l'ensemble des fonctionnalités, toutes ces choses Lorsque vous connaîtrez le fronting et le backend, vous serez mieux équipé pour être un testeur complet de Q ten Qa Je pense donc que le back-end est également très important. 31. Comment créer un CV de l'assurance qualité: Alors, comment créer un CV d'assurance qualité, non ? J'ai donc également joint un CV Qa standard typique. C'est donc un peu comme un CV d'assurance qualité standard. Je veux dire, bien sûr, CV sont tous différents, mais il faut que vous fassiez en sorte qu' un CV se démarque. Et je peux vous le dire parce que j' ai beaucoup d'expérience dans la création de CV, n'est-ce pas ? Une chose que vous voulez toujours souligner, c'est que vous devez toujours consulter la description du poste, n'est-ce pas ? Chaque description de poste est donc différente. Même si je vais être précis en ce qui concerne l'assurance qualité, les principes fondamentaux qui vous ont expliqués ou qui vous concernent sont similaires dans tous les domaines. 80 % des rôles et des responsabilités nécessitent tout ce que j'ai expliqué. Mais maintenant, certaines positions peuvent différer en fonction du rôle. La description du poste peut donc nécessiter un certain type d'acier. Disons que c'est possible, je veux juste un testeur de back-end, comme je l'ai pensé à propos des tests, la base de données. Un autre poste peut dire : «  Je veux un front-end » ou « je veux une automatisation ». Vous savez, je veux un manuel, vous savez, fonction du fait qu' ils veulent faire des tests, qu'ils veulent de l'automatisation et que vous parlez de compétences manuelles. Il y a de fortes chances qu'ils ne vous sélectionnent pas pour un entretien. Vous devez donc consulter la description du poste pour voir ce qu'ils recherchent réellement. Une fois que vous avez examiné la description du poste, vu ce que vous recherchez réellement, vous n'avez pas à créer chaque CV pour chaque description de poste. C'est trop. Vous souhaitez inclure dans votre CV beaucoup de choses qui couvrent beaucoup de sujets. Pour commencer, vous ne voulez pas parler de créer un CV pour l'automatisation, si vous n'êtes pas un testeur d'automatisation ou si vous ne savez pas que vous ne voulez pas automatiser, cela va à l'encontre de l'objectif Tout ce que vous créez dans un CV est quelque chose que vous pouvez justifier et que vous pouvez défendre et que vous voulez faire. Vous ne mettez tout simplement pas d'automatisation dans votre CV et vous ne voulez pas l'automatiser. Tout ce qui figure dans votre CV est quelque chose que vous pouvez définir et que vous souhaitez faire. Maintenant, comment faites-vous ce CV ? Vous regardez la description du poste. Vous avez toujours un CV standard qui couvre beaucoup de choses. Mais maintenant, pour chaque poste vous souhaitez postuler ou que vous souhaitez postuler ou pour toute personne qui vous intéresse beaucoup, vous pouvez ajouter des fonctionnalités à votre CV qui indiquent ce que recherche la responsabilité du poste. Tous les points de votre CV qui couvrent les responsabilités professionnelles que vous recherchez, la description du poste que vous recherchez. Sur votre CV, vous n'avez plus à indiquer, en termes de création de ce CV, quelles sont les choses que vous avez faites dans le passé qui peuvent se traduire par ce rôle. Donc, vous savez, pour ce qui est de la rédaction de ce CV, vous pourriez parler, par exemple, que je crois avoir mentionné à propos du service d'assistance, et si vous essayez de passer à Q way. En tant que service d'assistance, vous êtes très analytique, justement parce que vous résolvez des problèmes. Tu as un ticket, tu sais, un problème. Tu sais, comment résoudre ce problème ? Comment parvenez-vous à une résolution ? Nous faisons preuve d'ingéniosité, nous résolvons des problèmes. Cela peut passer à l'assurance qualité où vous interrogez le système ou l' application pour trouver des défauts. Vous pensez poser des questions à l'application ou au système. Et si je le faisais ? Et si je le faisais ? Et si je le faisais ? Parce que lorsque vous recevez de l'aide, lorsque vous recevez un ticket, automatiquement, vous ne savez pas comment le résoudre. Vous essayez ceci, vous essayez ceci, vous essayez ceci, vous essayez ceci jusqu'à ce que vous corrigiez le ticket. Il en va de même pour l'assurance qualité. D'une certaine façon, vous ne regardez pas une application et c' est là que se trouve le bogue, non. Tu ne sais pas, tu dois essayer et essayer. Au moment où vous continuez d'essayer, continuez à essayer de trouver le bogue. Ça m'aide, tu continues à essayer de réparer des choses, et si je le faisais ? Et si je le faisais ? C'est de la même façon vous résolvez des problèmes, vous êtes débrouillard Alors maintenant, lorsque vous fermez le ticket, vous savez que vous l'avez résolu. Dans Q, vous pouvez également résoudre les défauts. Une fois que vous avez parcouru tout le cycle de vie des défauts. Souvenez-vous que je parle des étoiles, ouverture et de toutes les statistiques avec l'équipe de la mort. Et si vous le fermez, vous corrigez ce défaut. Ainsi, vous résolvez également les problèmes. Vous êtes doué pour résoudre les problèmes. le genre de choses que vous pouvez inscrire dans votre CV parce que vous ne voulez pas dire que vous avez 20 ans d'expérience dans le domaine de assurance qualité, car lorsque l'on vous posera ces questions, vous ne serez pas en mesure de vous défendre. Vous voulez donc jouer prudemment tout mettant toutes ces compétences dans votre CV qui peuvent montrer les compétences d'un ingénieur QA pour ce poste ou simplement en général. Vous voulez donc parler de points forts, réfléchir à des choses de votre passé. Pensez à des choses de votre passé qui vous ont permis de bien communiquer ? Vous êtes analyste de communication car Q way nécessite de communiquer avec le développeur, savoir gérer les relations ? Parce que le problème typique peut souvent être le cas, je trouve un défaut et je l' envoie au développeur. Le def dit que ce n' est pas un problème qui ne se produit pas sur mon système. Je ne vois pas le problème. Tu fais des allers-retours. Tu perds ton sang-froid ? Comment gérez-vous votre relation avec le développeur ? Comment gérez-vous votre relation avec l'analyste commercial ? Comment gérez-vous votre relation avec les autres membres de l'assurance qualité, vos compétences en communication, vos problèmes, vos compétences en résolution de conflits Lorsqu'un conflit survient entre vous et le développeur, comment le résolvez-vous ? Cela fait donc partie du passé. Vous pouvez également tirer des exemples de la façon dont vous gérez les conflits ou les problèmes avec vos collègues, etc., et vous pouvez l'adapter la responsabilité d'un ingénieur QA. Il suffit de tirer des leçons du passé. Vous ne voulez pas mettre des éléments non pertinents sur votre CV qui ne vous évitent aucun besoin. S'il te plaît, retire-le. Tout ce que vous mettez sur votre CV, vous n'êtes pas obligé de le faire simplement parce que vous voulez surpasser, mettre des choses non pertinentes Ils ne vont pas te choisir pour un entretien. Vous voulez mettre des choses qui ont sens pour cette description de poste. Tout ce qui indique, même si vous avez reçu un prix, faire quelque chose que même un prix est formidable, mais si vous avez quelque chose qui, selon vous, n' est pas pertinent par rapport à ce que vous proposez pour la description de poste Q, cela n'a pas besoin d'être là. Tout ce dont ils ont besoin lorsqu'ils consultent votre CV, il y en a tellement Vous recherchez quelqu'un qui possède les compétences nécessaires pour occuper ce poste. Lorsqu'ils voient des éléments que vous mettez en évidence et qui correspondent à la compétence requise pour répondre au besoin qu'ils recherchent dans la description du poste, vous avez de fortes chances. Il faut être stratégique. Vous devez être très stratégique en concerne ce que vous inscrivez sur votre CV. J'ai l'impression que de nombreuses compétences sont très transférables. Beaucoup de compétences que nous voyons avoir dans notre vie de tous les jours, même dans notre vie personnelle, sont très transférables Parce que le travail informatique nécessite beaucoup d'interactions. Nécessite beaucoup de communication. Ça peut être stressant. Je vais être honnête avec toi. Vous pourriez être très stressé parce que vous devez respecter les délais, façon dont vous pouvez inscrire votre CV. Comment pouvez-vous résoudre ou corriger x y z dans un laps de temps très précis ? Vous savez, comment êtes-vous capable d'effectuer plusieurs tâches à la fois ? Parce que parfois vous pouvez travailler sur plusieurs applications, vous savez, vous avez des compétences multitâches et tout ça ? Êtes-vous orienté vers la résolution du temps ? Quand ils vous donnent quelque chose, vous le faites rapidement. Ce sont toutes de bonnes compétences. Vous savez, vous pouvez le surligner sur votre CV. la vidéo suivante, je vais vous montrer comment répondre aux questions d' entretien. Quel genre de questions se posent-ils ? Maintenant, la prochaine étape consiste à entrer une fois que vous avez franchi la porte. Une fois que vous avez obtenu cet entretien, qu'en faites-vous ? Nous avons parlé de votre CV, pour en faire un excellent CV. Maintenant, ce dont nous allons parler c'est de savoir quand vous aurez obtenu cet entretien, comment le ferez-vous ? 32. Intro à la façon de trouver un emploi: Maintenant, dans la vidéo suivante, je vais expliquer, vous savez comment trouver un emploi, comment apprendre le travail de vos rêves, n'est-ce pas ? Il ne s'agit donc pas seulement, je sais, que vous regardez ce cours. Ce n'est pas juste normal, j'ai lu toutes ces informations, qu'est-ce que je vais en faire, non ? OK ? J'ai une idée de Q. Vous savez, je connais très bien l'assurance qualité maintenant. Que dois-je faire ? Je sais que tous ceux qui suivent ce cours veulent apprendre le métier de leurs rêves. Je souhaite faire carrière en tant qu'ingénieur en assurance qualité. Donc, dans la vidéo suivante, je vais vous montrer comment savoir, créer un CV et aussi comment répondre aux questions d'entretien. 33. Comment passer une interview: Bienvenue sur la vidéo expliquant comment réussir un entretien. Je suppose que maintenant vous avez été sélectionné pour un entretien et que vous passez à la question, maintenant que vous vous asseyez avec l' intervieweur et que vous vous demandez comment réussir cet entretien pour obtenir un emploi Je pense que la première chose à faire est de s'entraîner. Vous devez vous entraîner avant de vous présenter à l'entretien. Je peux vous le dire par expérience car chaque fois que vous vous entraînez avant votre entretien, votre entretien est toujours meilleur, toujours meilleur parce que vous avez fait vos recherches, vous vous êtes formé, vous vous êtes entraîné, vous vous êtes entraîné, votre confiance en vous est renforcée. Une chose dans les entretiens, c'est qu'il faut toujours avoir confiance en soi. Vous devez toujours être confiant, car confiance est essentielle dans tout ce que vous faites. Même si tu dis la mauvaise chose, tu dois dire la mauvaise chose et tu le dis très bien. Si vous dites ce qu'il faut et qu'il n'y a aucune confiance en vous, vous n' obtiendrez peut-être même pas cette position. La confiance, c'est comme presque tout parce que vous pourriez même dire la mauvaise chose, mais avec autant de confiance, laissez-moi lui donner une chance. De plus, vous devez avoir la mentalité d'être prêt à apprendre. ne veulent pas simplement apprendre, car dans le domaine de l'assurance qualité ou de l'informatique, ils recherchent principalement des personnes expérimentées. Mais ils veulent voir ce que vous voulez présenter de manière ingénieuse Vous n'avez pas besoin de formation, vous n'avez pas besoin de tutorat. Vous pourriez apprendre des choses, vous pourriez lancer le bal, cette mentalité. Parce que dans le domaine de l'assurance qualité, dans l'informatique, il personne que vous n'êtes autogéré. Ils ne vont pas t'engager. Même s'ils vont vous indiquer un rôle, mais ils ne l' aimeront pas, vous devez le faire pour le faire demain. Parce qu'ils vous payent beaucoup d'argent. Ils ne vous payent pas beaucoup d'argent pour vous asseoir et attendre que les gens vous disent quoi faire. Vous devez être celui qui organise les réunions, vous devez être celui qui les initie. C'est comme si vous décidiez beaucoup de choses dans votre espace, dans votre espace Q. Vous discutez avec le développeur, vous testez, vous essayez de vous assurer que l' environnement est prêt. Vous faites donc beaucoup de choses, vous êtes proactif. C'est ce qu' ils veulent voir. Vous voulez dire à quel point vous êtes proactif. En termes de : vous ne vous asseyez pas, on ne vous dit pas quoi faire, vous ne vous déplacez pas. Vous organisez des réunions, vous testez, vous le faites, vous testez les choses qui font preuve de confiance et de proactivité Quoi qu'il en soit, vous devez le souligner auprès de votre intervieweur Vous pourriez puiser de l'expérience dans le passé. plupart des questions des intervieweurs porteront sur ce que vous faites dans ce scénario familiariser avec les terminologies, les jargons informatiques, comme je l'ai mentionné, les autres, tests de back-end, les tests frontaux, les phases SDLC , toutes ces terminologies informatiques Vous devez également vous Tu veux comprendre ce qu'ils sont. Tu sais. Également en termes de questions qu'ils posent. Je sais que la question typique est toujours de me le dire par vous-même. Tell me by yourself est un moyen pour vous vous présenter. Vous n'êtes pas obligé de commencer à dire des choses non pertinentes, mais vous pouvez mentionner que vous savez comment vous êtes proactif, vous savez comment vous faites les choses en ce qui concerne ce poste. Tu ne dis juste rien. Vous voyez que tout ce que vous dites, votre proactivité, votre débrouillardise, votre communication sont liés à ce poste Personne ne se soucie de savoir si vous avez fait quelque chose dans le passé qui ne correspond pas à ce qu'il recherchait. Donc, tout ce que vous pouvez dire qui peut vous rapprocher de cette description de poste, de ce qu'ils recherchent. En fait, quand ils veulent voir votre confiance, votre proactivité, vos compétences en communication, d'autres choses, toutes ces bonnes choses liées à votre poste Un autre conseil que nous vous conseillons est d'aller sur YouTube. Vous pouvez aller sur YouTube et vous pouvez rechercher sur Google en Q les questions d'entretien et la façon dont ils y ont répondu. Je pense que c'est en gros 70 %. Je veux dire 70 %, mais c'est beaucoup en dehors de votre confiance, de votre proactivité et de votre communication Être capable de savoir comment répondre aux questions. Vous allez voir beaucoup de choses. Je vais donc être honnête avec toi. questions d' entretien d'assurance qualité sont à peu près standard dans tous les domaines. Il y a donc quelques questions que vous allez entendre tout le temps. Vous allez entendre un type de question spécifique. C'EST. Les questions sont toujours les mêmes. Donc, si vous allez simplement sur YouTube et que vous passez X minutes ou heures à écouter les questions d' entretien et la façon dont elles répondent, et que vous réfléchissez maintenant à la manière dont vous pouvez également répondre pour obtenir un emploi, ne sera pas difficile , lorsque vous aurez cette confiance en vous parce que les questions sont les mêmes, les mêmes, les mêmes Alors, Google sur YouTube, interviewez les questions et réponses, voyez comment ils répondent à ces questions et découvrez comment vous pouvez tirer parti de votre passe pour répondre à ces questions. Je peux vous garantir que si vous regardez non pas un seul YouTube, plusieurs, vous verrez les similitudes, la plupart des questions qui se posent. Si vous vous êtes préparé à ce genre de questions façon dont vous pouvez y répondre , vous aurez plus de chances d' obtenir ce poste en toute confiance , car les questions d'entretien sont toutes les mêmes. Ce n'est pas quelque chose qui va vraiment sortir du lot, quelque chose d'imaginaire, non. Les questions sont des questions très standard, et la plupart des réponses sont toujours les mêmes. Mais comme vous n' avez pas autant d'expérience ou cette expérience, vous pourriez vous inspirer de votre passé pour trouver des réponses à ces questions. Et lorsque vous parlez en toute confiance, vous savez, vous serez capable d'exécuter ou d' obtenir cette position, vous savez, parce que la plupart des questions, comme je l'ai dit, sont toutes les mêmes questions. Il suffit donc de vous préparer, préparer pour l'entretien, vous préparer pour l'entretien, d'être confiant, de connaître vos ions, connaître votre métier et d' être capable d'exécuter. Tu sais ce sourire, c'est très important, c'est sympa. Tu n'as pas besoin d'être très hostile, non. Vous n'avez pas à avoir le sourire aux lèvres pour aborder cette question, car une chose que recherchent les entretiens , à part les connaissances, c'est donc l'intervention. Elle sait ou il sait ce qu'il fait, il se peut qu'ils ne donnent pas de conférences parce qu'ils veulent des personnes adaptées à leur culture. Vous voulez donc être accessible, vous savez, vous savez, vous savez, comme si vous étiez une personne orientée vers l'équipe, vous pouvez travailler en équipe Donc, ce sourire agréable, vous savez, est également très important en informatique, car vous allez travailler avec beaucoup de monde, et je vais travailler avec beaucoup de personnes dans des conditions difficiles et stressées personnes dans des conditions difficiles et stressées Je ne dis pas que c' est si stressant. Mais ils ne vous paieront pas plus de six chiffres pour ne pas être stressé ou pour ne rien faire. Plus le salaire est élevé, plus les responsabilités sont importantes. C'est comme si vous preniez de nombreuses responsabilités. Interagir avec un grand nombre de personnes. Vous testez, vous lisez des documents. Tout cela, c'est comme si vous alliez travailler avec beaucoup de monde. Quelle est votre approche ? Veulent-ils vous engager alors qu'ils voient qu'ils peuvent travailler avec vous, ils ne sont pas à l'aise de travailler avec vous Il faut montrer qu'ils sont très sympathiques. Vous devez montrer qu'ils sont très orientés vers l'équipe, qu'ils sont confiants et proactifs, et qu' ils sont également capables de répondre à ces questions d' entretien. Parfois, même les questions d' entretien, même si vous n' avez pas cette expérience, vous répondez de manière à ce que l'entretien apprécie ce qu'il entend Vous aimez que nous tirions des éléments de votre passé qui se rapportent à cette réponse et vous avez d'autres choses qui fonctionnent pour vous. Il y a tellement de choses. Il y a tellement de points positifs qui vous permettent de vous démarquer. Outre la confiance, votre proactivité, vos compétences personnelles, vos compétences axées sur l'équipe et ce que vous dites Il y a donc tellement de choses. Et plus vous ne me découragez pas en disant que vous ne voulez pas passer un entretien, vous ne le réussissez pas, c' est comme s'il y avait plusieurs positions sur l'onde Q. Il y en a donc beaucoup. Je dois dire qu'il y en a beaucoup, mais ils continuent d'arriver, et le secteur est également compétitif. Mais n'ayez pas peur car il y a aussi des gens qui entrent comme vous. Il y a des gens qui ont très peu ou pas d'expérience comme vous. Donc, plus vous continuez à vous entraîner et à apprendre vos trucs, vous savez, et aussi ces compétences d'équipe ou de location, vos compétences interpersonnelles, ce beau sourire Vous savez, ce sourire sur votre visage ne fait pas de mal, d'être accessible parce que les gens vont travailler avec vous Vous allez travailler avec des gens. Tout cela devrait donc vous permettre de prêter l'emploi de vos rêves. Je vous verrai donc dans le prochain chapitre. Je vais parler des certifications. 34. Certifications: Dans cette vidéo, je vais parler des certifications. En tant qu'ingénieur en assurance qualité, il est toujours bon d' avoir des certifications. Maintenant, quand obtenez-vous ces certifications, les gens disent que vous les obtenez à votre arrivée, car il vous sera plus facile de réussir l'examen parce que vous êtes plus compétent et que les certifications peuvent être assez coûteuses. Ce n'est pas bon marché. Vous ne voudrez pas simplement commencer à dépenser de l'argent lorsque vous n'êtes même pas là, mais cela vous aidera également à améliorer votre CV. Parce que lorsqu'ils voient que vous êtes certifié, même si ce n'est pas le N ou le BO, c'est un avantage supplémentaire et aussi une source de crédit, car vous voulez être satisfait Vous voulez avoir l'impression que je veux dire, j'ai compris, je suis un ingénieur d' assurance qualité certifié. Ça fait du bien. est donc très important d'obtenir une certification dans votre domaine en matière d'assurance qualité et dans le domaine informatique, car même si vous savez que nous avons parfois des licences, nos masters sont des doctorats en technologies de l' Vous savez, beaucoup de gens comprennent que les certifications sont très importantes dès leur arrivée, lorsque vous commencez à travailler dans l'informatique. Comme, tu sais, ça te fait du bien, ça te fait aimer, tu sais, quelque chose que tu as atteint, tu as atteint, non ? Donc, même si lorsque vous l' inscrivez sur votre CV, oui, ils l'examinent, pour savoir pourquoi tout va bien , cette personne possède la certification, mais aussi pour vous plaire, d' accord, je suis un ingénieur en assurance qualité certifié. Il existe plusieurs organismes qui proposent des certifications pour les ingénieurs de Q Way. J'ai mis la liste en ligne pour que vous puissiez la consulter, vous pouvez rechercher celle que vous voulez faire. N'importe lequel d'entre eux est bon. sont tous bons pour vous la plupart du temps, ce à quoi vous devriez vous attendre avec impatience, car en tant que testeur manuel, c'est la certification d' assurance qualité manuelle. Vous n'avez pas besoin de passer à l'automatisation. Mais si vous êtes également très familier avec l'automatisation, il existe également des certifications pour les ingénieurs en automatisation. Les tests manuels sont certifiés pour ceux-ci. Quand prenez-vous ça ? Pour être honnête, c'est génial. Si vous pouvez vous le permettre, donc si vous lisez attentivement, si vous le comprenez, et si vous êtes en mesure de passer la certification. Il y a de fortes chances que vous puissiez décrocher l'emploi de vos rêves, car tout ce qu'ils vous demanderont sur le poste figurera dans ces certifications. Vous allez obtenir une certification couvrira toutes les questions de l' entretien. Si vous pouvez réellement réussir cet entretien et ces certifications, vous avez plus de chances de réussir un entretien. En même temps, vous pouvez toujours obtenir emploi de vos rêves sans certification, et une fois que vous êtes entré, vous pourrez éventuellement obtenir cette certification. Quoi qu'il en soit, à un moment donné, vous devez obtenir ou obtenir cette certification. 35. Merci: Merci à tous de m'avoir rejoint dans cette aventure et dans ce processus pour avoir pu vous convaincre en matière d'assurance qualité. C'était un plaisir que vous ayez regardé ma vidéo, et je suis heureuse et heureuse espérer que vous avez pu apprendre une chose ou deux et vous préparer à l'assurance qualité. Tu sais, tu dois juste croire en toi, savoir que tu l'as, regarder les vidéos, si tu as des questions, tu sais, tu peux commenter ci-dessous, et je vais certainement te répondre. Par exemple, je suis là pour vous aider à obtenir le travail de vos rêves. Vous savez, j'ai expliqué beaucoup de choses en détail. Donc, vous savez, beaucoup de vidéos, une grande partie des messages que j'ai envoyés et que j'ai expliqués sont très utiles pour décrocher l'emploi de vos rêves. Vous savez, donc je suis là, par exemple, si vous regardez les vidéos et que vous êtes confus sur quoi que ce soit, vous savez, sur n'importe quel sujet, vous savez, envoyez-moi simplement un message. Vous savez, je suis là pour, vous savez, vous guider dans le processus pour décrocher ce poste. Tu sais. Donc si vous avez des questions, vous savez, faites-moi savoir, je crois en vous, je sais que vous les avez comprises. Tu sais, tu dois faire ce travail. Donc, plus vous investissez, plus vous obtiendrez de résultats dans le cadre de cette norme. Donc, vous ne faites pas les choses passivement et, vous savez, pour regarder cette vidéo, vous aviez vraiment une intention, n'est-ce pas Vous aviez l'intention de poursuivre cette carrière. Il suffit donc de ne pas regarder la vidéo et de ne rien faire. Vous regardez la vidéo, vous allez sur YouTube, vous interviewez des questions. Tu sais, tu étudies le matériel. Donc, bon nombre des artefacts que je vous ai envoyés comprennent tous ces artefacts, vous savez, liés à ce que je dis en termes de service d'assurance qualité. Vous avez juste un lien avec votre CV, vos expériences passées, vous devez remplir le point, vous devez créer votre histoire et vous devez être bien informé. De plus, avec toutes les compétences générales que j'ai mentionnées à propos de votre confiance, de votre personnalité et de votre accessibilité. C'est un processus et je ne dis pas que c'est facile. Ce n'est pas facile. Mais c'est un processus et c'est un processus qui va être assoupli car cela pourrait changer votre vie pour toujours. Une fois que vous entrez comme si vous y étiez, le plus grand défi est d'entrer et je ne vous ai toujours pas aidée à y entrer. Une fois que vous êtes entré et que vous avez passé un ou deux ans en assurance qualité, vous êtes bon. Vous pourriez passer à autre chose. Vous pouvez faire tout ce que vous voulez car c'est le même SDL, le même processus Le plus grand défi est de faire le premier pas, de commencer, et je pense que nous pouvons commencer. Une fois que vous serez là, je suis heureuse que vous puissiez regarder cette vidéo. Tu sais, une fois que tu regardes, ça ne s'arrête pas là. Cela ne s'arrête pas là. Vous devez poursuivre ce processus. Tu dois continuer ce voyage. Vous avez des questions. Je suis là pour répondre Je suis là pour vous soutenir, et vous devez continuer. Vous savez, vous devez continuer à vous améliorer, apprendre plus de choses, vous savez, être mieux informé, plus vous vous entraînez, vous vous entraînez, vous vous améliorez, vous savez, donc vous savez, vous devez être intentionnel. Et, vous savez, je suis là pour répondre à toutes vos questions. Donc, si vous avez des questions, pas à nous contacter, et si rien d'autre, merci de votre participation. Merci d'avoir suivi mon dossier et je vous contacterai certainement. Merci d'avoir regardé Bonne chance. Je crois en toi et je sais que tu l'as.