"Calendrier des testeurs" pour décembre. Essayez une approche différente

Dans la nouvelle année, beaucoup font le point, analysent l'année écoulée, se souviennent de tous leurs résultats et font des plans pour l'avenir. Dans le 12ème numéro de notre calendrier, Anastasia Ronzhina, testeuse du service Kontur.Market , expliquera pourquoi vous devriez essayer quelque chose de nouveau, changer vos opinions, vos approches, faire des erreurs et réessayer.



Pourquoi ai-je besoin de ça?


Tout va bien avec moi, je travaille bien, ils me louent, pourquoi devrais-je changer quelque chose? C'est une question logique. En réponse, une citation du livre "Alice à travers le miroir":


Vous devez courir aussi vite pour rester en place, mais pour arriver quelque part, vous devez courir au moins deux fois plus vite!

Pendant que nous sommes assis et testons des puzzles, le monde ne reste pas immobile. James Bach et Michael Bolton mènent une autre étude et recherchent des approches sur la façon de tester avec une haute qualité en peu de temps.


La place du testeur dans le processus de développement évolue, et les processus eux-mêmes. Par exemple, Maxim et Irina de notre société ont parlé de l'évolution des autotests , de la façon dont vous pouvez accélérer le développement à l'aide de tests et changer les attitudes quant à qui devrait les écrire et à quel stade. Lena et Hilaria ont expliqué comment vous pouvez changer vos outils, vous connecter à la communication avec l'utilisateur, préparer des savoirs traditionnels et des prototypes pour améliorer la qualité du produit.


Je suis très triste quand j'entends à nouveau l'opinion qu'un testeur peut atteindre sa limite en 1,5 ans, puis soit en automatisation, soit en changeant de rôle en manager, analyste, développeur, etc. Quand votre quotidien est juste Répétition d'algorithmes: lisez les analyses, examinez les prototypes, testez, publiez les bogues, vérifiez les bogues - il est facile de comprendre pourquoi vous êtes fatigué et déçu par la profession. C'est juste ennuyeux!


Mais lorsque vous changez d'approches à l'étude du problème, d'approches à la génération de tests, de méthodes de test, alors:


  • Premièrement, vous trouvez quelque chose qui vous permet de tester plus rapidement, quelque chose qui vous permet d'effectuer une analyse approfondie des fonctionnalités et de ne rien manquer. Je pense que personne ne refusera d'améliorer son travail et l'apparition du temps libre :).
  • Deuxièmement - c'est vraiment amusant! Personnellement, il m'est très difficile d'effectuer quotidiennement des tâches typiques avec un algorithme standard.

Vous pouvez creuser un sujet spécifique et devenir un spécialiste étroit. Vous pouvez grandir en largeur. Au fil du temps, les gens seront attirés par vous, car tout à coup, vous commencerez à répondre aux questions de «votre sujet». Vous pouvez être appelé dans d'autres équipes pour mettre en place un processus ou un outil, pour enseigner quelque chose. Un autre profit - avec votre intérêt, vos connaissances, vous pouvez inspirer d'autres collègues à se développer, ce qui signifie qu'il y aura encore plus de bons testeurs dans le monde :).


Qu'est-ce qui peut changer exactement l'approche?



1. Artefacts ou documentation de test


Chacun de nous quelque part corrige un plan de test, la décomposition des tâches, le schéma de fonctionnement du produit, des instructions, des bogues, des accords. Il peut s'agir d'un morceau de papier, d'un fichier sur un ordinateur ou d'une sorte de programme. Nous créons des cas de test, des listes de contrôle, des cartes à puce, des tableaux, des graphiques, des diagrammes, des instructions ...


Ce que vous devez penser concerne les objectifs: pour quoi et pour qui faites-vous cela? La documentation de test est-elle un produit ou un outil? À quelle vitesse votre produit évolue-t-il? Et quel est le flux de nouveaux testeurs? Il y a un merveilleux ensemble de questions décrites dans la leçon 148 de Leçons apprises en test de logiciel: une approche contextuelle , Cem Kaner, James Bach et Bret Pettichord. Si vous n'avez pas de livre sous la main, il y a une traduction de cette leçon.


J'ai vu des autotests dans une équipe - comme principale documentation autoportante, pourquoi pas?



2. Techniques d'essai


C'est probablement le point le plus évident, mais sans lui. Dites-moi honnêtement, quelles techniques utilisez-vous actuellement? Non, vous ne savez pas, il suffit de postuler! Depuis combien de temps essayez-vous de trouver quelque chose de nouveau?


Je trouve souvent que les testeurs connaissent la théorie de la conception des tests, mais pour une raison quelconque, ne l'appliquent pas et ne testent pas, comme ils l'ont appris, au niveau de l'intuition, peut-être par habitude ou après des tentatives infructueuses d'utiliser les techniques. Caner a eu une idée sympa dans la leçon 26 du même livre:


L'intuition est un bon début, mais une conclusion moche (l'intuition est bonne pour commencer, mais moche à la fin).

Oui, au début, ce flair nous sauve, nous trébuchons lors des tests de bugs, nous semblons l'obtenir. Mais au fil du temps, des bogues manqués commenceront à arriver du champ de bataille. Par exemple, il s'avère soudain que lors de la combinaison de valeurs spécifiques des paramètres, quelque chose se passe mal, ou avec une action, l'objet est soudainement passé à un nouvel état, mais nous ne l'avons pas remarqué lors des tests. Les techniques vous permettront d'éviter tout cela, elles vous permettront de tester plus efficacement, vous pourrez résoudre les tâches plus rapidement et mieux.


Alexei Barantsev avait une très bonne analogie avec l'orientation. Lorsque vous avez appris à naviguer sur le terrain (en utilisant intuitivement des techniques, sans le savoir), puis après avoir étudié les cartes, les modèles, vous serez encore meilleur en navigation. De nouvelles techniques vous donneront de nouvelles opportunités pour vous déplacer dans la région. Par exemple, j'ai appris l'escalade - maintenant, vous pouvez non seulement faire le tour de la montagne, mais aussi l'escalader. Les techniques sont très difficiles à utiliser au début, pendant que vous les étudiez, mais avec le temps, vous vous entraînez puis les utilisez sur la machine.


Où puis-je trouver de nouvelles idées sur la technologie? Lisez ou, si vous l'avez déjà lu, feuilletez le livre A Practitioner's Guide to Software Test Design, Lee Copeland , ou emmenez un collègue avec vous, choisissez n'importe quelle visite de test Whittaker ( Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design, James A. Whittaker ) et 'voyagez' avec votre produit. Sortez du bon vieux temps et inscrivez-vous à un cours de conception de test. Essayez-le!



3. Techniques d'analyse et de génération d'idées


Oui, oui, c'est l'analyse de toute la formulation du problème, l'étude de la fonctionnalité, l'étude de l'objet à tester. Si nous revenons à la discussion de l'intuition, la raison des sauts d'erreurs peut encore être une tâche insuffisamment analysée, des informations incomplètement collectées. Qu'est-ce qui peut être changé ici?


Vous pouvez étudier ce que sont les oracles des tests . Vous découvrirez sûrement une nouvelle source d'information. Ou, si vous les connaissez déjà, regardez, par exemple, le produit de votre concurrent et découvrez comment vos fonctionnalités y sont implémentées.


Rechercher des techniques d'analyse, étudier la modélisation, car nous testons selon notre idée du programme, selon notre modèle. Prenez les objets de votre système et effectuez une analyse sur la télédétection (actions - paramètres - valeurs).


Tout d'abord, sélectionnez tous les objets dont vous disposez, peignez toutes les actions que vous pouvez effectuer sur ces objets, puis les paramètres qui affectent les actions, puis les valeurs spécifiques des paramètres.

Lisez des livres d' Edward De Bono sur la réflexion et l'invention de solutions personnalisées. Prenez le livre « Rice Assault » et entraînez votre cerveau. Chaque jour, nous nous précipitons sur les tâches, nous proposons et quoi d'autre pourrait affecter notre tâche. La formation vous aidera à le faire plus rapidement et de manière plus productive.



4. Environnement et processus


Je ne parle pas d'un changement d'équipe ou d'entreprise, bien que dans certaines situations, pourquoi pas? :) Je voulais parler de ce qui se passe autour des tests.


Prenez et modifiez votre navigateur préféré ou la résolution d'écran. Si vous testez une application Web, je suis sûr que vous regardez le produit différemment.


Remplacez Microsoft Visual Studio par JetBrains Rider (ou vice versa). Essayez d'utiliser un autre outil de test d'API. Explorez d'autres solutions, il est fort possible que quelque chose de nouveau et de plus pratique pour vous soit apparu.


Avez-vous constamment une branche pour tester où le projet ne va pas ou dans lequel vous trouvez des bogues dans les premières minutes? Ou trouvez-vous toujours beaucoup de bugs? Et en même temps, avez-vous également une grande file d'attente pour les tests? Étudiez l' heuristique de l'arrêt des tests (oui, vous pouvez simplement prendre la branche brute et la boucler), modifier les exigences de la branche en entrée, impliquer des collègues dans les tests. Ou peut-être que certaines branches n'ont pas vraiment besoin de tests, le développeur a déjà tout vérifié lui-même?


Et parfois, il est très utile de simplement prendre et transférer à l'autre bout de la pièce, plus près des développeurs ou d'autres testeurs. Un changement de lieu aidera à rafraîchir le regard sur le travail.



5. Rôle et responsabilités du testeur


Mon préféré Découvrez qui est le testeur dans les équipes voisines, dans d'autres projets ou même dans d'autres pays. Nous avons eu un entretien avec James Bach lors de la conférence DAMP, et certaines des réponses étaient tout simplement surprenantes. James a une idée complètement différente de qui est le testeur, s'il existe des machines automatisées et quelle est la chose la plus intéressante à propos des tests!


Optez pour quelques interviews. Allez-y. Vous apprendrez ce qui se passe dans d'autres entreprises, ce qui est apprécié par les testeurs, ce que l'on attend d'eux.


Décidez-vous toujours de libérer ou non? Ou faire ce que les managers font habituellement? Lisez le livre de Jerry Weinberg Perfect Software And Other Illusions About Testing et cela va bouleverser votre monde! Et puis assurez-vous de laisser votre gestionnaire lire.


Pensez-vous que l'assurance qualité est la responsabilité du testeur? Dans la même interview, James Bach a donné un bon exemple de garde dans une base militaire.


Bien sûr, vous pouvez simplement garder la base, et vous pouvez également étudier pourquoi les gens veulent pénétrer dans cette base, le faire comme discipline dans une école militaire. Est-ce à dire que vous ne pouvez pas garder la base? Bien sûr que non! Quelqu'un doit garder. Mais, déjà en ce qui concerne les tests, si vous étudiez et commencez à mettre en œuvre quelque chose qui réduira le nombre de bogues, alors oui, vous pouvez réduire le nombre de "gardes".

Au sujet de la garantie de la qualité et de la croissance du testeur lors de la même conférence, Maxim a présenté un bon rapport de raisonnement .


Pensez-vous toujours qu'il existe des testeurs d'automatisation et manuels? Écoutez James , écoutez un rapport sur la façon dont seuls les développeurs écrivent dans un projet d' autotests , ou comment le rôle d'un autotesteur a évolué dans une équipe et maintenant tout le monde dans une équipe écrit des autotests et ne donne à la branche que des tests verts, y compris de nouveaux tests de fonctionnalités .


Quels types de tests faites-vous? Seulement fonctionnel? Et vous pouvez répondre - pourquoi? Et qui est responsable des autres espèces? Pensez, vous verrez peut-être une sorte d'espaces.


Apprenez d'autres rôles, par exemple, comment écrire des analyses (« Méthodes modernes pour décrire les exigences fonctionnelles des systèmes » par Alistair Coburn), qui est un tel gestionnaire et que doit-il faire (« Leader idéal d' Adizes»). Cela vous permettra de mieux comprendre les autres rôles, leur position. Et aussi dessiner de nouvelles idées.


6. Autre chose


Les testeurs parlent beaucoup avec les autres et écrivent beaucoup. Nous devons expliquer des erreurs ou essayer de poser des questions lorsque nous sommes arrivés à une situation terriblement délicate. Par conséquent, développez ces compétences. Par exemple, il y a un bon livre de Maxim Ilyakhov et Lyudmila Sarycheva - « Write, Cut ». Recherchez simplement des sujets sur les sites d' éditeurs ou de magasins .


Une autre idée inattendue - vous pouvez vous tester! Ou votre développement! Comment a fait Ekaterina Bobrova .



Qu'est-ce qui nous arrête


Examinons les facteurs d'arrêt les plus populaires qui nous empêchent d'essayer une approche différente.


Pas de temps


C'est probablement le plus simple. Allez à un cours de gestion du temps, lisez des livres sur l'efficacité. Par exemple, " Jedi Techniques " de Maxim Dorofeev.


Je ne sais pas comment faire le premier pas


Mettez en surbrillance une heure spécifique, une tâche spécifique, vous pouvez commencer même avec 15 minutes. Et dans ces 15 minutes, creusez votre sujet, essayez quelque chose de différent. Il n'est pas nécessaire d'essayer tout de suite tout ce que vous avez appris. Choisissez 1 à 3 nouvelles pratiques et essayez de les appliquer. L'essentiel est de le faire tous les jours. Ces petites étapes conduiront à d'excellents résultats. Plus d'informations à ce sujet lors du webinaire avec Ekaterina Lengold .


Peur des erreurs


Je pense que chacun de nous avait peur de prendre une décision, d'essayer quelque chose pour la première fois. Et si je n'ai pas assez de compétences et que je prendrai la mauvaise décision, laissez-moi tomber le projet et mes collègues? Il faut se rappeler que les erreurs sont la norme pour le processus d'apprentissage. Nous comprenons sur eux comment ne pas le faire, ce qui signifie que nous savons maintenant où aller. Rappelons l'histoire de l'invention de l'ampoule. Edison a mené environ 2 000 expériences avant de réussir.


"Dites-moi, M. Edison, qu'est-ce que ça fait d'échouer deux mille fois de suite, en essayant de créer une ampoule?"
"Jeune homme," répondit Edison, "Je ne me suis pas trompé deux mille fois en créant cette ampoule." J'ai découvert mille neuf cent quatre-vingt-dix-neuf façons de ne pas fabriquer une ampoule.

Surcharge d'informations


Dans le livre « 100 façons de changer la vie. Partie 2 »Larisa Parfentieva parle d'une chose telle que la surcharge d'informations. Au fil du temps, nous acquérons des connaissances, ce qui nous empêche de faire face rapidement aux tâches, de prendre des décisions, d'essayer quelque chose de nouveau et de prendre des risques. Parce qu'avant d'essayer, nous commençons à analyser, à réfléchir à tout dans les moindres détails et ... au final, nous n'essayons jamais.


La solution est simple - commencez au moins avec quelque chose. Choisissez la première technique et essayez. Soit vous réaliserez plus tard que vous vous êtes trompé - et c'est un bon résultat, maintenant vous avez de l'expérience et de nouvelles informations. Dans ce cas, adoptez la technique suivante, approchez. Soit la technologie décolle, puis vous gagnez aussi. Quand l'écrivain elle-même a une telle paralysie, elle se dit: «Oui, ne t'en fais pas! et commence à écrire la première chose qui me vient à l’esprit.


Et voici une autre citation d'Albert Einstein:


Tout le monde sait depuis l'enfance que ceci et cela est impossible. Mais il y a toujours un ignorant qui ne le sait pas. Il fait une découverte.

Pas assez d'inspiration


Personnellement, mes collègues, les livres sur les tests et pas seulement , les discours et inventions de collègues d'une autre ville, d'un autre pays m'inspirent. Je voudrais tendre la main à ces personnes, créer, faire quelque chose d'utile et ne pas rester immobile.


Dans le même livre, Larisa Parfentieva partage la règle du succès pour l'acteur et réalisateur Harold Ramis.


Trouvez la personne la plus talentueuse dans la salle et, si ce n'est pas vous, restez près de lui. Suivez-le partout. Essayez de lui être utile. Et si un jour il s'avère que la personne la plus talentueuse de la pièce est vous, cherchez une autre pièce.

Trouvez ce qui vous donne de l'énergie, de la force, vous charge de changer et mangez-le!


Si vous sentez que vous avez besoin d'un mentor, écrivez sur une feuille de papier une liste de 20 personnes qui peuvent se présenter, même si ce sont les testeurs les plus célèbres, contactez ces personnes. Quelqu'un de 20 ans ne vous refusera certainement pas!


En fin de compte


Je vais citer une autre citation du livre « 100 façons de changer la vie. Partie 2 ".


Chez les personnes qui obtiennent un succès exceptionnel, il n'y a rien de spécial qui ne soit en aucune personne! Ils sont aussi indécis, douteux de soi, réfléchis, ils se trompent souvent, tombent, se sentent tristes, se comparent aux autres, ne savent pas quelle décision prendre, et parfois il leur est difficile de sortir du lit. Leur seule différence est qu'ils font constamment quelque chose, malgré tout cela.

Essayez de nouvelles techniques, de nouveaux outils, inventez les vôtres. Choisissez l'activité la plus banale et faites-la consciemment. Changez les processus, révisez vos vues. Trouvez une idée folle et intéressante et essayez de la réaliser!


Avec cet article, nous terminons le cycle annuel «Calendrier des testeurs», dans lequel 16 testeurs Contour ont parlé de leurs outils, pratiques et processus de travail. Pour beaucoup d'entre eux, ce fut une nouvelle expérience, intéressante et utile.
Le monde des tests ne se limite pas seulement à la recherche de bugs, il a de nombreux visages et dans ce monde, vous pouvez et devez expérimenter. Merci d'être avec nous :)


Liste des articles du calendrier:


Test de paire raisonnable
Commentaires: comment cela se passe
Optimiser les tests
Lire un livre
Tests analytiques
Le testeur doit attraper le bug, lire Caner et organiser le déplacement.
Service de chargement
Mesures de service d'assurance qualité
Test de sécurité
Apprenez à connaître votre client
Prendre l'arriéré

Source: https://habr.com/ru/post/fr433132/


All Articles