Menu

Mon parcours inattendu pour devenir un testeur de logiciels (du niveau débutant à un gestionnaire)

my unexpected journey becoming software tester

Essayez Notre Instrument Pour Éliminer Les Problèmes

«Vous construisez une vie réussie… un jour à la fois…»

Mon parcours en tant que testeur de logiciels a commencé de manière un peu inattendue.

J'ai comparu pour les premiers entretiens en supposant que c'était une opportunité de développement. Pour être honnête, comme tous les autres diplômés en informatique, j'étais un peu sceptique quant à l'idée d'aller de l'avant avec Testing.

Mais finalement, j'ai décidé d'essayer. Seulement avec l'espoir que ma nature curieuse m'aidera dans ce domaine.

Je ne pourrais pas accepter l'offre sans poser cette question - Aurai-je la possibilité de passer au développement au cas où les tests ne m'intéressent pas? :).

Croyez-moi, je n'ai même jamais pensé à quitter Testing après ça.

dfs en utilisant stack c ++

mon-voyage-comme-testeur-logiciel

Quand je suis apparu pour la manche technique, je n’étais pas préparé à autre chose que le concept de base des tests logiciels . Je suppose que la seule chose qui m’a guidé a été l’idée que je suis évalué de manière logique et non théorique ».

C'était mon tout premier apprentissage dans le domaine des tests - j'ai compris comment nous ( rafraîchisseurs ) ont été évalués.

Même aujourd'hui, j'utilise des techniques similaires lors de l'embauche de recrues pour mon équipe. Je vérifie leur logique, leur ténacité et leur approche d'un problème avant toute autre chose.

Lecture recommandée => 4 choses importantes que j'ai apprises au cours de mon parcours en tant que responsable des tests d'assurance qualité

J'ai rejoint Zycus en tant que stagiaire QA et j'ai reçu un produit le troisième ou le quatrième jour. Il s'agissait de l'un des produits les plus importants (à l'époque dans le concept) et les plus ambitieux de l'entreprise. Après m'être installé pendant les premières semaines, il n'y a pas eu de retour en arrière pour moi.

Nous avons commencé en tant qu'équipe QA de deux personnes et, peu après quelques mois, j'étais le seul à diriger les efforts de test. Au cours des 2 à 2,5 premières années, j'avais enregistré près de 3000 défauts dans différentes catégories telles que Fonctionnel, Performance, Sécurité, UI, Convivialité, Multilingue , Multi-Tenancy, etc.

Pendant un temps considérable avant de nouveaux ajouts à l'équipe de test, j'ai été confronté à une solide équipe de développement de 15 à 16 membres. Même après les ajouts, le ratio QC: Dev n'était pas très sain et je peux encore dire avec fierté que ce fut un voyage réussi compte tenu de tout ce que nous avons testé, livré et géré.

Le point important que je veux souligner ici est: Tout cela provenait d'une compréhension des tests dans la pratique et pas seulement de la théorie.

Je suis dans le domaine des tests de logiciels depuis près de six ans maintenant. Ce fut un voyage incroyable avec tant d'expériences différentes et beaucoup d'apprentissage fructueux.

Actuellement, je travaille en tant que Senior QA Manager en m'occupant de 5 à 6 produits et modules. Mais ce qui me donne de la joie et du bonheur, c'est de diriger une équipe de plus de 30 testeurs heureux et passionnés.

Bien sûr, de nombreuses personnes ont contribué à mon apprentissage, mais je peux toujours dire que la plupart de mon expérience et de mes connaissances ont été difficiles (et probablement la meilleure), c'est-à-dire en apprenant / en résolvant le problème par moi-même.

'L'expérience est le meilleur professeur.'

Bien que je dise cela, je ne veux pas du tout dire que vous ne bénéficierez pas de l’apprentissage ou de l’application de théories documentées sur les tests de logiciels. Ce que je crois, c'est que tout cela aidera sûrement mais rien de mieux que de comprendre le concept fondamental et d'affronter les problèmes avec audace.

Je crois que les choses documentées ne vous apprendront pas vrais tests , bien que cela puisse vous donner une direction et alors vous êtes seul. Au moins dans mon cas, il y a eu des problèmes qui n'ont peut-être pas été documentés pour résoudre mes problèmes exacts ou je ne pouvais pas les trouver à temps. Mon seul choix était de comprendre le problème / la situation au cœur et d'y réagir avec l'approche que je trouvais juste.

Exemples - Comment j'ai abordé différentes situations

Permettez-moi de vous expliquer cela à l'aide des problèmes / situations auxquels j'ai été confronté et comment je les ai abordés.

# 1) La compréhension des affaires est un cran supérieure aux tests de compréhension

Eh bien, vous le savez tous. Le test ne consiste pas seulement à tester quelques validations et à effectuer des vérifications.

En tant que testeur, nous sommes censés visualiser tous les scénarios possibles, même le plus rare des rares scénarios sans faute. Nous sommes censés prendre en compte toutes les données de test possibles que l'utilisateur réel pourrait utiliser.

Pour tout ça, nous sommes censés comprendre le métier au maximum.

Ce ne sera pas faux si je dis que nous devons comprendre l'entreprise et la base d'utilisateurs autant, voire plus, qu'un analyste commercial.

J'étais confronté à des chances similaires.

J'étais supposé comprendre des scénarios commerciaux complexes dans le domaine des achats, réfléchissez aux nouvelles exigences et évaluez-les du point de vue de l'utilisateur. Je n'étais pas seulement censé travailler sur mes cas, mais aussi contribuer aux phases d'exigence et de conception de chaque itération. Même ici, aucune référence toute prête n'est venue à mon secours en dehors de ma capacité de réflexion et de raisonnement.

Pour mieux comprendre le métier et mieux concevoir vos scénarios / cas, rien ne fonctionne comme un stylo et du papier.

Lire aussi => 5 Doit avoir des outils sans test pour les testeurs pour rendre la vie plus facile

Avant d'aller à Discussion sur les exigences réunion, j'avais l'habitude de noter à l'avance d'éventuels doutes / corrections / points peu clairs. J'écrivais les scénarios sur lesquels je voulais essayer ou construire des cas de test; parfois, même dessiner vos scénarios fonctionne comme un charme.

Lorsque vous écrivez / dessinez, cela entre dans votre esprit avec une meilleure clarté, puis votre esprit travaille sur ces informations et produit plus de scénarios et donne une meilleure clarté. Cela continue jusqu'à ce que vous ayez ce sentiment de FAIT !!!

# 2) Jouer contre toute attente et sous pression

Je travaillais sur un produit qui était / est assez énorme et complexe pour former une équipe de 30 ingénieurs travaillant en continu pendant trois longues années pour l'amener à un niveau vendable.

Pendant la majeure partie de la phase initiale, soit j'étais face à une équipe de 15 à 20 développeurs allant du niveau junior, mid-senior et senior, soit j'étais accompagné d'un ou de deux autres testeurs. Ils ajoutaient tous sans relâche de nouvelles fonctionnalités au produit, ce qui exigeait une attention égale et parallèle de la part des tests.

Participer aux réunions de besoins, rédiger des cas, les exécuter, les rondes exploratoires, maintenir les serveurs, les déploiements, rien n'était facultatif.

À ce moment-là, je n’étais au courant d’aucune méthodologie, meilleur entrainement , un cours ou un livre qui peut me montrer des solutions à de tels problèmes. Même aujourd'hui, je ne suis pas sûr qu'il y ait quoi que ce soit qui puisse précisément vous aider à combattre les réalités du terrain lorsque vous y faites face.

Ce que je faisais plutôt, c'est agressif et cycles rapides de tests exploratoires (Je n'étais pas au courant du nom à ce moment-là) sur chaque fonctionnalité une par une, puis répétez. Cette solution fonctionne uniquement sur la vitesse à laquelle vous pouvez changer vos pensées et encadrer des situations / scénarios.

Bien sûr, cela exigeait un travail vraiment rapide et agressif, mais cela a fonctionné pour moi.

Ce que je veux dire par rond agressif est, vous ciblez une chose à la fois (Dites un élément d'un formulaire à la fois) et testez-le indépendamment et en association avec d'autres éléments / choses liés.

Lecture recommandée => Comment être un accro de la productivité (surtout en tant que testeur)

Par exemple. Comment tester une zone de texte.

Ce que vous pouvez tester ici, c'est:

  1. S'il accepte et stocke les données telles quelles
  2. Validation du type de données
  3. Validation de la longueur maximale
  4. Manipulation des caractères spéciaux
  5. Manipulation XSS
  6. Traitement des données multilingues
  7. Gestion des espaces vides / pas de données
  8. Comportement de l'onglet et de la saisie des clés
  9. Gestion des erreurs (cross-browser)
  10. Alignement de l'interface utilisateur (cross-browser)
  11. Copier coller les données / faire glisser les liens vers la zone de texte
  12. Le plus important - le comportement de ce champ w.r.t. d'autres éléments liés (toute attente commerciale liée à ce champ, comme le remplissage de quelque chose dans un autre champ en fonction des données de ce champ)

Est-ce que penser aux tests ci-dessus vous donne la certitude que rien ne peut vraiment mal tourner dans ce domaine?

comment faire un plan de test

Eh bien, cibler une chose à la fois a toujours fonctionné pour moi et j'avais aussi l'habitude de terminer mon travail.

# 3) Lorsque vous êtes confronté à «l'inattendu»

Selon vous, quel livre vous aidera soudainement à «Comment faire» alors que vous êtes censé faire quelque chose que vous n’avez jamais fait auparavant?

Si nous parlons spécifiquement alors - Aucun.

Je me souviens de l'époque où, en l'absence de notre chef de produit, je devais, avec quelques autres membres juniors et mid-senior, déployer pour la première fois notre application sur une instance de démonstration (qui était en production à l'époque). C'était très critique pour la toute première démo de notre produit.

Eh bien, nous l'avons fait, mais avec beaucoup d'essais et d'erreurs. La raison étant, aucun de nous n’avait d’expertise sur Scripting Linux et shell . Je me souviens que notre service informatique (tout de bonne foi) a soulevé des inquiétudes à mon directeur de l'époque au sujet de l'exécution de mauvaises commandes sur les serveurs de production. Peut-être que c'était juste un catalyseur et que le script shell / Linux était mon intérêt naturel, mais peu de temps après, j'ai fini par prendre la responsabilité de maintenir et de mettre à niveau cinq à six environnements simultanément.

Shell et Linux ont si bien attiré mon intérêt que je suis bientôt celui qui a commencé à animer des sessions de formation internes sur ce sujet.

# 4) Lorsque votre performance est mesurée, votre expérience n'est pas

Très tôt dans ma carrière, je me suis comparé et mesuré aux testeurs très évolués et expérimentés. Je pense que beaucoup d’entre vous doivent avoir vécu une situation similaire et savoir ce que ces attentes supplémentaires vous font.

Le remède ici était de Me pousser et évoluer .

La seule façon d’avancer était de ne pas penser à quel point je suis moins expérimenté, de ne pas me limiter aux normes mondiales de mesure à quelle vitesse je devrais grandir / apprendre. Je ne me limite pas aux critères de World sur la rapidité avec laquelle on devrait commencer à diriger et le titre dont on a besoin avant de le faire.

Eh bien, sur ce point, je dois dire, quel que soit le domaine auquel vous appartenez, je vous recommande de lire The Leader Who Had No Title de Robin Sharma. Cela vous aidera à libérer ce qui se trouve en vous. Cela vous dira que personne, sauf vous, ne peut vous retenir.

Si je dois lier mon expérience en quelques phrases, ça va comme ceci:

«Votre curiosité, votre attention aux détails, votre discipline, votre pensée logique, votre passion pour le travail et votre capacité à disséquer les choses sont tout ce qui compte pour être un testeur destructeur et performant. Cela a fonctionné pour moi et je crois fermement que cela fonctionnera pour vous. Si vous avez ces qualités, cela doit fonctionner pour vous.

Eh bien, en lisant jusqu'ici si vous pensez que je fais la promotion des qualités humaines de base plutôt que des connaissances théoriques plus approfondies, ce n'est pas tout à fait vrai. Je crois que commencer par quelque chose et y goûter le succès, cela dépend un peu plus de vos qualités intrinsèques que des informations que vous avez apprises. Cependant, pour aller loin dans n'importe quel domaine, il faut tirer des leçons, des principes et des expériences.

Dans mon cas aussi, j'ai dû apprendre les terminologies, les concepts, les théories dans une certaine mesure au fur et à mesure que j'allais plus loin dans ma carrière. La raison étant, en tant que testeur, vous devez interagir avec plusieurs personnes qui parleront en ces termes et vous devez le comprendre.

En tant que responsable ou co-testeur, vous aurez un nouveau testeur venant d'une partie du monde avec sa propre connaissance des faits, des définitions et des terminologies. Ici aussi, vous ne pouvez pas rester passif envers ces choses; vous devez avoir une connaissance préalable du maximum de choses possibles utilisées / dites là-bas.

L'apprentissage est inévitable.

J'ai dû en apprendre davantage sur les différents types de tests, comment les exécuter et comment les expliquer aux membres de mon équipe au bon stade. J'ai dû évaluer de nouvelles idées, de nouveaux outils et les mettre en œuvre. L'apprentissage de nouveaux concepts et méthodologies devient tout aussi important à mesure que vous gravissez les échelons.

En savoir plus => Le guide de A à Z sur la sélection de la meilleure automatisation

Conclusion

Bien qu'il soit presque impossible d'écrire chaque chose importante et infime que j'ai apprise au fil des ans, c'est ma tentative de la résumer dans une liste à puces.

  • Les tests sont très difficiles à définir. Quelqu'un peut faire de superbes tests et ne pourra peut-être pas le définir avec des mots. C'est comme vous le voyez.
  • Chacun peut avoir sa propre définition des tests. Le mien était simple- 'On vous donne une chose - Trouvez les défauts et améliorez-les.'
  • Vous n’avez pas nécessairement besoin de grandes théories, de matrices complexes ou d’ISTQB pour être un testeur destructeur. Tu dois être curieuse , concentré et passionné, pense logiquement et a une capacité de dissection. Cependant, en savoir plus ne fait pas de mal, mais pas au prix de perdre le nœud.
  • Les approches / concepts traditionnels ont eux aussi leur propre importance et j'ai le même respect à leur égard compte tenu du fait qu'il y a une bonne partie du monde où ils sont une juste nécessité. Les tests seuls ne peuvent pas évoluer; l'environnement doit également évoluer pour cela.
  • En tant que testeur, il devient tout aussi important de apprendre nouveau outils, techniques et méthodologies à mesure que vous avancez . La planification des tests, de meilleures approches pour effectuer différents types de tests, les tests situationnels sont quelques-uns à citer.
  • Étant donné que les tests sont fluides, la définition d'un ajustement approprié diffère également considérablement d'une organisation à l'autre. Être un testeur destructeur ou excellent peut suffire à obtenir un chèque de paie si vous êtes chanceux ou exiger des connaissances supplémentaires sur le fonctionnement des tests dans les entreprises traditionnelles. Les deux sont à leur place.par exemple.J'embauche des personnes selon ma définition du test (qui varie un peu selon l'expérience et le profil du candidat bien sûr).
  • Comme il y a un style de codage, de conduite, de cuisine; il existe également un style de test. Vous pourriez ne pas l'apprécier à moins que vous ne le fassiez à votre façon. Ce que je veux dire, c'est que le test peut avoir des lignes directrices, mais il ne devrait pas être lié par les micro-processus.
  • Le plomb efficace devrait inciter son équipe à choisir le travail plutôt qu'à l'assigner. Il peut occasionnellement le modifier pour l'amélioration du Produit.
  • Essayez de former vos collaborateurs dans leur domaine d'intérêt et dans les domaines où vous souhaitez qu'ils soient formés. Alignez les pensées et les efforts de votre équipe sur l'objectif final, qui est «la meilleure qualité».
  • N'essayez pas de gérer vos employés, dirigez-les. Soyez amical et accessible, cela rend le travail beaucoup plus facile.
  • Chaque membre de votre équipe doit aimer le travail qu'il fait, avoir un attachement au produit et être affectueux envers les gens autour. Alors seuls les meilleurs d'entre eux sortiront.
  • Le monde des tests doit évoluer. Une part considérable du monde passe à des approches plus pratiques comme les tests exploratoires, les tests contextuels (que beaucoup de gens font sans le savoir) que même d'autres devraient essayer et développer plus de techniques comme le
  • Davantage de communautés de test devraient être formées et les personnes partageant les mêmes idées devraient se rassembler à une plus grande échelle. Il y a tellement de choses à partager, apprendre, s'adapter et innover.

J'espère que mon expérience et mes découvertes vous aideront à devenir un meilleur testeur ou à mieux comprendre les tests.

Lectures complémentaires => Du débutant au professionnel: un guide complet du parcours réussi d'un professionnel du test

A propos de l'auteur: Cet article est écrit par Mahesh C., membre de l'équipe STH. Il travaille actuellement en tant que Senior Quality Assurance Manager ayant une expérience de la direction des tests pour plusieurs produits et composants complexes.

J'adorerai entendre en retour. Commentez ici ou contactez-nous. Merci beaucoup d'avoir lu.

lecture recommandée

^