Concevoir un meilleur système

Concevoir des stratégies de système

L'état d'esprit du testeur est souvent associé à la tentative de casser un système. Malheureusement, cela conduit à une compétition entre eux et les constructeurs [Laing 2016] alors qu'une collaboration est attendue entre les membres de l'équipe [Schwaber 2020]. Du point de vue de l'équipe, la stratégie des personnes impliquées peut être résumée par les parties suivantes :

Fête

Stratégies

Développeur*

• Concevoir et construire

Tester*

• Aider les développeurs ?
• Casser le travail des développeurs ?

Product Owner (PO)

• Obtenir le meilleur retour sur investissement

Scrum Master(SM)

• Proposer des changements de stratégie
  

(*) Du point de vue de Scrum, les développeurs et les testeurs sont censés être sur le même bateau et donc collaborer et s'entraider [Schwaber 2020].

D'un point de vue agile plus large, il est également admis qu'indépendamment des rôles Scrum, une équipe agile ressemble beaucoup à un jeu infini coopératif [Cockburn 2006].

En considérant la théorie des jeux, il est généralement admis, à partir du "Dilemme du Prisonnier" [Mero 1998], que la coopération conduit à une situation gagnant-gagnant. La théorie des jeux appliquée aux organisations agiles révèle effectivement que la coopération l'emporte sur la compétition [Hazrati 2010], ce qui devrait être une bonne raison pour amener l'équipe à viser une collaboration pour la conception d'un meilleur système.

Malheureusement, le tableau ci-dessus peut sembler assez naïf parce qu'il omet de prendre en compte des éléments supplémentaires tels que les personnes ignorantes, sous pression ou pragmatiques et les "traîtres", par exemple.

• les gens qui ne connaissent pas les normes qui devraient être appliquées
• des personnes qui doivent réduire leurs attentes en matière de qualité pour se conformer à la pression du contexte.
• des personnes paresseuses et pragmatiques qui veulent fournir quelque chose qui soit suffisamment bon pour passer des tests connus, quel que soit le point de vue des clients.
• des personnes corrompues qui sapent le produit, par exemple en installant des portes dérobées pour permettre des violations de la sécurité.

Alors que le premier élément est favorisé par des critères d'acceptation trop simples, le second doit être évité pour éviter les impacts négatifs sur la sécurité du produit. 

Dans le cadre de ces hypothèses, certains développeurs ont des stratégies différentes, par exemple :

• Ne pas respecter les normes de l'organisation (même involontairement)
• Ne pas répondre aux besoins réels des clients
• miner la solution par des failles qui peuvent notamment avoir un impact sur les normes du produit, comme la sécurité
  

Si l'on considère l'équilibre de Nash, la connaissance de la stratégie de chacun doit être claire afin de permettre un gain maximal pour chaque joueur [Nash 1950] ; cela implique que les gens doivent être conscients des dernières stratégies supplémentaires qui impliquent une concurrence avec eux pour atteindre un niveau acceptable.

Sachant cela, " Concevoir un meilleur système " ne se limite pas au produit livré mais aussi au système qui construit le produit. Par conséquent, il semble qu'il pourrait y avoir une 5e valeur dans le manifeste du test agile de Laing [Laing 2016] :

“La collaboration plutôt que la concurrence”

Cette dernière approche conduit à prendre en compte la concurrence, mais en favorisant d'abord la collaboration, car on remarque que cette dernière forme de test vient aussi en premier, car les tests de gauche tirent parti de la qualité dès que possible, ce qui implique une qualité intégrée pour prévenir bugs.

Impact sur la maturité des tests

En ce qui concerne le manque de connaissances, Kaizen et Yokoten devraient être impliqués pour réduire l'impact négatif de l'ignorance.

En ce qui concerne les questions de pression, le PO est celui qui décide des éléments les plus précieux à publier à l'aide des techniques de Story Splitting [Lawrence 2012] et de Story Mapping [Patton 2014] et qui applique éventuellement une certaine budgétisation des erreurs pour gérer les publications de faible qualité.

S'appuyer uniquement sur des tests d'acceptation définis à chaque User Story (US) notamment grâce à un atelier "3 Amigos" n'est évidemment pas suffisant. C'est pourquoi les équipes agiles devraient également effectuer des tests exploratoires pour repérer les développements "paresseux". Les Gemba walks, les X-Teams et le Double Loop Learning [Argyris 1977] ou le PanTesting sont également utiles pour obliger les développeurs à étendre les tests d'acceptation avec un esprit d'expérience utilisateur (UX) et à créer éventuellement des US supplémentaires qui compléteraient la fonctionnalité avec des éléments supplémentaires.

Comme nous l'avons vu plus haut, la mise en péril influe sur la concurrence avec ceux que l'on appelle les " traîtres ". Pour ce faire, les tests de sécurité proposent différentes stratégies de test [OSSTMM 2010] [Moustier 2019-1] :

• Aveugle: les développeurs sont au courant des attaques - cela se produit lorsque les cas de test sont connus par l'équipe ainsi que lorsque les tests ont lieu.
• Double aveugle: le testeur/attaquant ne sait rien du système et les développeurs ne savent rien des attaques (ni de la façon dont le testeur/attaquant procède, ni du moment où cela se produit).
• Boîte grise: Les développeurs connaissent une partie du contenu de l'attaque ou le testeur/l'attaquant connaît une partie du contenu à attaquer.
• Double boîte grise: les développeurs et le testeur/attaquant disposent de certaines informations de l'autre équipe.
• Tandem: les développeurs et les testeurs/attaquants collaborent de manière transparente.
• Inversion: les développeurs ne savent pas quoi ni quand de l'attaque, mais le testeur/l'attaquant connaît certaines informations sur le système visé.

‍

Ces nombreuses stratégies montrent les nombreux points de vue des développeurs et des testeurs/attaquants et donnent des indications sur les avantages de l'approche de test indépendante de l'ISTQB [ISTQB 2018] et sur la valeur ajoutée de la coopération entre les développeurs et les testeurs.

Le point de vue d'Agilitest sur la conception d'un meilleur système

Puisque la plupart des utilisateurs d'Agilitest sont plutôt tournés vers la fonctionnalité que le codage pour des raisons culturelles, Agilitest est souvent utilisé par les Business Owners situés en dehors des équipes de développement qui tirent parti des tests indépendants ; cependant, Agilitest peut être utilisé dans n'importe quelle stratégie de test, d'une stratégie de test inversée ou en double aveugle à une manière collaborative avec un atelier 3 Amigos dans une approche en tandem.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍