Qu'est-ce qu'une armée pourrait apprendre à un testeur? Quels sont les deux extrêmes dans les approches de test? Comment expliquer que la dette technique soit rouge par paiement? Qu'est-ce que les questions précédentes ont en commun?
La chose générale est que malgré toute leur différence, ils sont tous proches d'une seule personne.
Jim Holmes a derrière lui plusieurs décennies d'expérience informatique, qui ont commencé dans les années 80 dans l'US Air Force - il n'est pas surprenant qu'il soit prêt à en dire beaucoup. Le concept de «culture de test» est important pour lui, et nous lui avons posé des questions qui peuvent varier considérablement, mais qui sont en fin de compte liées à la culture de test.
- Question introductive: parlez-nous de vous.- Je m'appelle Jim Holmes, je suis consultant indépendant et propriétaire de ma propre entreprise, Guidepost Systems. Je me spécialise dans la qualité de la livraison de logiciels et je programme depuis environ 20 ans, avant de servir dans l'armée pendant longtemps. Je me suis intéressé sérieusement à la qualité il y a une quinzaine d'années, tout en travaillant sur plusieurs projets peu réussis. En général, j'ai fait beaucoup d'automatisation de tests, de tests unitaires, de tests d'intégration, et surtout de tests fonctionnels, de tests d'interface utilisateur. En particulier, j'ai travaillé pour une entreprise qui a écrit le merveilleux outil Telerik Test Studio. Et au cours des 5 à 8 dernières années, j'ai commencé à m'occuper non seulement d'aspects purement techniques, mais aussi de la qualité de l'approvisionnement dans son ensemble - c'est-à-dire de la qualité des relations entre l'équipe d'approvisionnement et l'entreprise. Mais en même temps, je continue de déboguer les scripts WebDriver pendant longtemps et de résoudre des problèmes tels que les échecs périodiques dus à des actions asynchrones incorrectes. Je vis dans la ville d'Ashland en Oregon - faites attention à vous, pas à Portland (quand aux États-Unis vous dites «Oregon», généralement tout le monde pense «Portland»).
- Probablement, pour le testeur, la partie la plus inhabituelle de votre biographie est le service militaire. Que faisiez-vous exactement là-bas?- J'ai servi dans l'US Air Force parce que j'ai toujours été inspiré par les avions et que mon père était pilote. Il m'a emmené sur mon premier vol alors que j'avais seulement 4 ans. Dans l'Air Force, j'ai eu beaucoup de chance, j'ai fait partie de l'équipe E-3 - c'est un si gros avion avec un énorme disque sur le dessus, où j'étais responsable du fonctionnement du radar et de certains systèmes de communication. Depuis onze ans, j'administre et débogue ce grand système électronique. Et pendant le temps libre des vols, j'ai administré les ordinateurs de notre escadron. À cette époque, il est devenu possible de créer des réseaux sur le lieu de travail. De plus, comme j'étais soldat, j'étais payé pour l'éducation, alors je suis allé dans une école du soir pour développer des logiciels.
Quant à votre question, l'expérience du service militaire est inhabituelle non seulement pour les testeurs, mais aussi pour de nombreux autres domaines. Je peux dire qu'au moins on m'a enseigné la discipline là-bas.
- Oui, dans le cas de l'armée, la première chose qui me vient à l'esprit est la discipline. Et avec cela, de nombreux testeurs et développeurs ont des problèmes. Pensez-vous qu'ils ont quelque chose à apprendre des militaires?- C'est une question très intéressante. Le fait est que la discipline qui m'a été enseignée était quelque peu différente, disons, des parachutistes, c'est-à-dire qu'il n'y avait pas de cris et de punitions constants. On m'a enseigné une approche disciplinée des tests et, en général, de la résolution de problèmes. La discipline en milieu de travail était également importante - comprendre ce qu'était une hiérarchie; pour apprendre à y travailler, il faut pouvoir communiquer avec les supérieurs. Ce genre de discipline m'a beaucoup aidé.
J'ai quitté l'armée il y a 25 ans - oui, je suis un vieil homme - et le travail dans le secteur civil contrastait de façon très intéressante avec mon expérience précédente en raison des priorités qui y étaient. Dans l'armée, j'ai servi dans un avion, qui était censé surveiller l'ennemi sur un vaste territoire et assurer ma propre sécurité. Toute erreur représentait un risque pour la vie de nos soldats. Je ne veux pas exagérer, mais c'était vraiment le cas. Donc, quand quelqu'un en informatique commence à paniquer et à exiger qu'une tâche soit résolue tout de suite, grâce à ma discipline et mon expérience, je peux toujours rassurer les gens - nous ne sommes pas menacés que quelqu'un meure, et nous ne perdons pas des centaines de milliers de dollars par minute (et j'ai été dans de telles situations). Nous paniquons très souvent et laissons l'entreprise ou les actionnaires nous intimider inutilement et créer une tension déraisonnable qui ne fait de bien à personne. Peut-être que la meilleure chose que l'armée m'a enseignée est la capacité d'appeler au calme, d'évaluer la situation de manière saine et de planifier nos actions à l'avance, et de ne pas se précipiter dans une tâche sans réfléchir à cause d'une panique créée artificiellement.
- Autrement dit, vous devez prendre le temps de réfléchir à une stratégie.- Oui, et dans l'informatique, ce problème a été long: des exigences constantes pour livrer le projet dès cette seconde. L'essentiel est de faire vite, et ce qui se fait exactement est d'une importance secondaire. Le plus souvent, cette pression peut être contrôlée si le dialogue se déroule correctement. Mais pour cela, il est important de pouvoir dire que nous créerons plus de valeur si nous passons un peu plus de temps et abordons le problème de manière rationnelle.
- Passons à vos activités actuelles. Au travail, vous savez comment ils abordent les tests dans différentes entreprises de différentes manières. Il est clair que l'approche peut dépendre, par exemple, de la taille de l'entreprise. Mais il y a probablement beaucoup de différences moins évidentes - pouvez-vous en parler?- C'est une merveilleuse question. En plus de mon travail indépendant, je travaille également avec Pillar Technology de Columbus, Ohio. Je connais des gens de cette entreprise depuis longtemps. Maintenant, environ 250 personnes y travaillent, et presque toutes travaillent sur le principe de la programmation extrême (XP): elles ont beaucoup de tests unitaires, et le développement est très bien pensé. Quand j'ai été embauché là-bas il y a trois ans, j'étais le seul testeur et ils ont créé un produit de très haute qualité. Ils ont abordé les tests exclusivement à partir de la position de XP, à partir de la position de développement piloté par les tests. Il s'agit d'une excellente approche, et ils l'ont appliquée avec succès, et moi, avec d'autres employés, j'ai réussi à changer certains aspects de la livraison de logiciels.
Et vous pouvez comparer cette expérience avec une autre entreprise dans laquelle je suis consultant depuis trois ans. Il s'agit d'une entreprise industrielle, elle figure dans le top dix de Fortune et emploie environ 200 000 personnes dans le monde. Ils ont un très grand département informatique pour les besoins internes de l'entreprise. Il y a beaucoup de bonnes personnes là-bas, mais leurs tests sont restés bloqués sur les pratiques des années 1980 ou 1990. La société produit d'énormes lots d'exactement les mêmes produits, et beaucoup sont habitués au fait que, dans la production, par exemple, de roulements à billes, il est tout à fait possible d'estimer le nombre de défauts attendus. Mais le problème est qu'ils transfèrent ce type de pensée à l'informatique.
J'ai eu une conversation avec quatre, en général, des employés très intelligents qui ont participé à la collecte des rapports de défauts de plusieurs projets et à essayer de prédire le nombre de défauts possibles à l'avenir. Je leur ai dit que cela était tout à fait raisonnable dans l'industrie, mais comment distingueront-ils les indicateurs calculés pour une application mobile des indicateurs, par exemple, des services Web? Ils ont répondu qu'il n'y avait aucune différence. J'ai donc eu la chance de voir des points complètement opposés sur le spectre des différentes approches et cultures de test.
De plus, j'ai travaillé avec des entreprises qui n'ont pas réussi à sortir de la phase de démarrage, quand elles travaillent tout le temps sans regarder en arrière, sans essayer de couvrir toute la situation. Et puis, après plusieurs années, dans des projets complexes, les problèmes qui se sont posés à ce stade commencent à se faire sentir fortement, et je dois convaincre les gens que cette approche est mauvaise et que maintenant je dois m'arrêter et réfléchir correctement à mes actions. En général, ma réponse a été quelque peu détaillée, j'espère que je n'ai pas complètement perdu le contact avec votre question.
- Et dans votre pratique de conseil, il y a des moments où, après avoir terminé le travail avec l'entreprise, ils vous ont dit «rien ne s'est amélioré»?- Je vais vous dire un secret que c'est dur avec les gens, nous sommes des créatures très difficiles. C'est l'une des raisons pour lesquelles j'ai tellement de cheveux gris (la seconde est ma fille). Changer une personne est difficile; changer des personnes dans une organisation est encore plus difficile. Alors oui, j'ai cette situation assez souvent.
Concernant certains consultants, on dit même qu'il a "grillé". Cela est dû au fait que nous faisons beaucoup d'efforts pour changer la culture qui s'est formée dans l'organisation, et nous devons beaucoup travailler avec des problèmes sur le plan personnel - les gens ont peur des changements, ils doivent constamment se convaincre que cela est nécessaire et recherchez le chemin qui leur convient. Peu importe à quel point je suis fort et fort, je ne peux pas simplement dire: faites ceci et cela. Besoin de parvenir à un consensus. Ce travail doit être effectué pendant des années afin de réaliser quelque chose, et quand il semble que vous avez résolu le problème et que vous partez consulter une autre organisation, vous y rencontrerez exactement les mêmes problèmes que précédemment. Encore une fois, vous passez énormément de temps et d'efforts, et il s'avère que dans cette première entreprise, tout est déjà revenu à son état antérieur.
Les gens sont tellement arrangés, c’est dur avec nous, on revient souvent à nos vieilles habitudes. Mais malgré cela, il existe des exemples de travail vraiment réussi. Il existe des organisations qui parviennent à consolider le résultat obtenu avec vous. En général, je dirais que l'un équilibre l'autre. Je continue de faire ce travail parce que ces succès sont extrêmement satisfaisants.
- Dans votre blog, vous avez écrit sur vos principes professionnels, et là vous avez parlé de la nécessité d'être ouvert, d'apprendre toujours de nouvelles choses, d'écouter plus que de parler, de vous adapter et d'être gentil avec les gens. Je me demande si l'informatique aide vraiment une bonne attitude envers les gens?- Oui, ça aide. J'ai dit que j'avais servi dans l'armée, où nous avions une discipline stricte - mais nous devons comprendre que la discipline et la structure n'interfèrent en rien avec les bonnes relations et l'empathie avec les autres. Connaissez-vous le chef écossais Gordon Ramsay? Il dirige le spectacle Hell's Kitchen. Je le mentionne parce que les chefs dans les restaurants chers se comportent très souvent de façon dégoûtante avec les employés - ils crient et insultent. Je déteste cette attitude envers les gens. Pour moi, une bonne attitude les uns envers les autres est importante. Si vous voulez apporter des changements, vous devez comprendre pourquoi les gens leur résistent, c'est-à-dire que vous avez besoin d'empathie. Et cela vous permettra de donner envie à la personne de changer. Une telle approche est beaucoup plus efficace que de crier sur les gens et d'exiger qu'ils obéissent et ne posent pas de questions. Chaque personne a son propre esprit, sa propre âme, sa propre expérience. Je ne voudrais pas approfondir la philosophie, mais je crois qu'à long terme, une bonne attitude et de l'empathie vous permettront d'obtenir d'excellents résultats. Alors oui, ils aident.
- Vous dirigez des séminaires et enseignez à l'un d'eux la programmation à des personnes qui ne savent pas programmer. J'ai deux questions. Premièrement, quels problèmes empêchent le plus souvent les gens de s'auto-programmer? Deuxièmement - pensez-vous qu'au cours de la prochaine année, les tests automatisés l'emporteront sur les tests manuels?- D'après mon expérience, les gens sont souvent dérangés non pas par des difficultés techniques, mais par la peur. Je peux donner un exemple de mon expérience dans une entreprise de Fortune 10, dont j'ai déjà parlé. J'ai travaillé avec une équipe de testeurs qui effectuaient des tests manuels et nous devions faire de l'automatisation à l'aide de WebDriver. Parmi ceux-ci, la plupart n'ont même pas pu ouvrir Eclipse pour commencer à écrire du code. Ils avaient peur d'écrire un script pour l'automatisation, car selon eux, cela n'était pas très différent de l'écriture d'un service Web évolutif ou d'une base de données avec multithreading, c'est-à-dire des choses que les développeurs apprennent depuis des années. Cette peur les empêchait de faire des choses généralement simples.
Je développe actuellement un cours pour le ministère des tests basé sur un atelier dans lequel j'explique que vous n'avez pas besoin d'années de pratique pour simplement ouvrir un script Java, C # ou Ruby, le lire et comprendre la structure générale ou écrire test simple sur WebDriver. De plus, même si vous ne comprenez pas tout ce qui se passe dans le code, vous pouvez lui donner une évaluation générale, car vous savez, par exemple, qu'une méthode ne doit pas occuper trois écrans, il ne doit pas y avoir quatre instructions imbriquées si - elles seront difficiles pour tester, vous ne pouvez pas donner aux variables des noms à une lettre et ainsi de suite. À mon avis, au stade initial, la principale difficulté est de surmonter la peur que vous ayez à résoudre des tâches incroyablement complexes. Et j'ai toujours été intéressé de voir à quelle vitesse mes clients se débarrassent de cette peur - il suffit de donner à la personne un test unitaire simple et de lui demander d'écrire organiser, agir et affirmer. Je pense que cette composante humaine est très importante.
La plupart des technologies avec lesquelles nous travaillons ne sont pas si compliquées, peu sont impliquées dans des choses comme les véhicules sans pilote. Une fois, j'ai organisé un séminaire pour un client en Inde, et il y avait un gestionnaire sans aucune expérience en programmation. Ce manager était très en colère au début, et c'était précisément cette peur dont je viens de parler, et cette peur était superposée à la réticence à paraître stupide. Mais à la fin de la première leçon, il a tellement plongé dans l'écriture des tests que j'ai dû le mettre hors du public une heure après la fin de la leçon - il s'est assis, s'enfouissant dans le moniteur, jumelé avec un autre participant au séminaire et a écrit des tests simples pour l'algorithme de salaire planches. Et le point ici n'est pas du tout dans mes compétences pédagogiques - cela montre simplement l'importance de cette peur ou de son absence. Ici, nous parlons de choses inhérentes à la nature humaine.
Votre deuxième question concernait la transition des tests manuels aux tests automatisés. J'ai une certaine expérience ici, j'ai travaillé pendant trois ans dans une entreprise qui se consacre à l'automatisation des tests. Je pense que la question devrait être posée différemment et viser non pas les tests d'automatisation, mais le développement de testeurs et leur acquisition de nombreuses compétences techniques, dont l'une devrait être les tests automatisés. J'aimerais voir de tels testeurs qui, ayant une histoire d'utilisateur, des spécifications et des exigences, pourraient librement dialoguer avec des développeurs sur des choses assez spécialisées et rechercher conjointement des solutions qui seront ensuite incorporées dans du code. Ceci est quelque peu différent de l'approche dans laquelle le testeur enseigne la programmation, juste pour pouvoir écrire des scripts WebDriver. Cette compétence, bien sûr, est également importante, mais, à mon avis, elle n'est pas la plus importante. La super-tâche, à mon avis, est la capacité de dialoguer avec le développeur et de s'assurer qu'il a en tête le processus de test lorsqu'il écrit le code. Même TDD sera déjà un résultat significatif - je pense que toutes les organisations devraient pouvoir écrire comme ça.
L'essentiel est que les tests correctement fournis sont loin d'être réduits à des tests unitaires ou des tests d'intégration. Très souvent, les gens sont satisfaits de tester un chemin d'exécution de code typique - tous les tests sont réussis, les cases à cocher sont partout, la couverture de code à 100% est atteinte. Mais rien de tout cela ne garantit la qualité du code, n'est-ce pas? Bien que ce soient aussi des procédures nécessaires, bien sûr. Donc, à ma connaissance, le testeur ne devrait pas simplement écrire quelques tests fonctionnels ou tests dans WebDriver, mais réfléchir à la façon dont il peut établir une coopération plus étroite avec les développeurs et les analystes commerciaux. Vous pouvez, par exemple, essayer
la programmation mob . En général, je pense que l'automatisation est un outil, pas un objectif.
- Les mots «coopération étroite avec les développeurs» nous sont très proches en tant qu'organisateurs de Heisenbug - même le slogan de la conférence est «sur les tests, mais pas seulement pour les testeurs». Et dans le cadre de cette coopération, je voudrais poser la question suivante: qu'en tant que personne ayant une grande expérience des tests, aimeriez-vous dire à nos lecteurs et programmeurs?"Que nous ne sommes pas tous mauvais!" Les testeurs ont gagné leur notoriété avec leurs propres actions. Ils trouvent à redire aux moindres détails lors des réunions, communiquent souvent des rapports de bogues, pas des mots. Le développeur vient travailler le matin et voit 50 rapports de bogues qui parlent d'erreurs grammaticales et de pages non alignées. J'ai été dans les deux rôles et je sais comment les programmeurs réagissent à cela. Cela fait partie de la vieille école de tests, et je me suis moi-même comporté une fois de cette façon aussi. Mais les testeurs, qui sont plus habitués à l'approche moderne, comprennent qu'il est plus facile et préférable de simplement lui parler que de bombarder un programmeur avec des rapports de bogues.
À mon avis, il est important pour les développeurs de comprendre qu'un bon testeur peut être très précieux, et si vous lui parlez à l'avance, vous pouvez vous épargner beaucoup de temps et de nerfs. C'est ce que dit la théorie des contraintes. Supposons que je suis développeur et que je constate que le testeur a détecté un problème. Si, au lieu d'écrire à ce sujet dans TFS ou ailleurs, je m'adresse à lui et parle en personne, alors cette conversation m'aidera à réduire le nombre de défauts dans le code que j'écris. De plus, dans la communication personnelle, la plupart des testeurs, en règle générale, sont loin d'être effrayants. , , , , — , , , .
, . , , , , — , . , .
, , : Heisenbug , Fortune 10. , ? 6-7 Heisenbug , .
— . «The leadership journey» . , : , , — . ?— , , IT: , , , , . , , , , . , , , . , , .
, . , , , . , : , , . , , , . , , , . . , , . , , - , . , , . , — .
— , . : , , , . — ?— 18 , , 13 14. . , — , , . , , . , .
, . , , . DevOps. , , . , . , Skype - , Skype for Business Google Hangouts, . . , . , , , Xbox — , .
, — . , . hangout Slack — . , , .
20 , , — . . , , , . , , , . . , — , . , , .
— «Technical debt: payment plan». « » , « » , . , , , , ?— . , , IT - , . (Trish Khoo), Twitter hogfish. — , . , , «Technical debt: payment plan». , , , , -, .
, , , , - . -, , , . , , . - X , Y , . , - . , , 30 - , . , -, . , , : - .
, 10 3 . 3 . , . . , , , , . , , , - , . , . , , IT, , . , . , . . , , - , , , .
, , . , , . , , , . , .
— , , , . , , , .— . , . , , , . , , — , . , , - . .
, . , , , , . , , , , , , . , , , .
— , — . , .— Fortune 10, , . , . , , , . , , , , , Acceptance Testing.
, , . , (, Sonar Cube), , . , , . , « », , , , . , , . , , - .
— . .— , . , : , .