Concepteurs Web au travail

  • Auteur de la discussion Diakotte
  • Date de début

magellan

Modérâleur
Staff
Comme j'ai un peu de temps à tuer avant de reprendre la route... voilà quelques idées et rappels sur ce qu'on appelle trop vulgairement les tests

C'est quoi les "tests"
Déjà, le préalable est de savoir ce que va faire ton développement. On ne peut pas tester en aveugle avec ce que j'appelle "la méthode du singe" (comprendre mettre un babouin qui ne connait pas le clavier et qui va marteler le clavier jusqu'à déclencher un blocage).
Il y a grossièrement deux types d'orientations de tests:
- Soit on a de la donnée à injecter pour reproduire "tous" les cas (ce qui est mathématiquement un cauchemar... car avoir toutes les combinaisons est évidemment possible mais techniquement impossible à valider... sauf à avoir dix ans devant soit)
- Soit on intègre manuellement de la donnée d'une manière ou d'une autre, et là les données entrées doivent faire sens.

Dans le premier cas on peut envisager: une base de données, une application où l'on saisit des choses enregistrées... bref un "outil de productivité"
Dans le second cas ça peut être un jeu où là les tests sont "explore toutes les facettes pour voir si visuellement, techniquement ou ergonomiquement tu déclenches des incidents".

Quels sont les types de tests
- Les tests unitaires
Ce sont ceux faits par le développeur. il code, et à chaque modification il s'assure que, sur un jeu de données restreint, il obtient le résultat attendu
- Les tests en volumétrie
Là on teste sur une volumétrie de données plus large pour voir si les règles sont respectées sur toute l'étendue des données possibles
- La non-régression
Encore des tests trop souvent passés à la trappe! Pour résumer ces tests, c'est "Vérifier que toute fonctionnalité validée dans un version précédente soit toujours fonctionnelle dans la version révisée". En gros? "Tout ce qui fonctionnait doit encore fonctionner". On n'a pas idée du nombre de régressions liées à des effets de bord soit de développement (modification d'une librairie provoquant un changement de comportement ailleurs dans l'application), soit à des changements techniques (comme une montée de version de JVM provoquant des pannes parce que la patch note indique que la fonction X se comportait... à l'envers et qu'au lieu de répondre false elle répond désormais true... Vécu lors des montées de version de JRE dans les version 1.4.xxx que je t'ai haï Sun avec tes patch note qu'on se cognait à chaque révision!!!)
- Les tests de montée en charge
Ce point est.. VITAL. que j'ai pu pousser des gueulantes avec mes devs à cause de ça! Prenons un cas concret (vécu). Il y avait une requête qui remontait des données à une page Web. Le gars me disait "sur le serveur en lui-même ça marche nickel ça passe, mais à distance c'est l'enfer". Oui CRETIN: ta requête prenait tous les champs de la base (SELECT * ) pour afficher quatre colonnes! BORDEL. Donc, quand il y avait 10.000 lignes en base, ça trimballait des dizaines de colonnes inutiles et donc des Mo de données.. je te laisse augurer de la suite des résultats en terme de performance. De la même manière, une recette avec 300 lignes ça ne vaut rien. Une base qui contient 1.5 millions de lignes (comme c'est assez souvent mon cas ces derniers temps, je gère de la comptabilité...) c'est autrement plus signifiant. Une même requête exécutée sur deux volumétries distinctes passera pépère à peu de lignes, et sera insupportable à grosse volumétrie. Et là, la question sera dès lors "mauvaise conception, ou résultat inévitable?".
Complétons: quand on teste des données, on doit se mettre dans le cas le plus défavorable. ça n'a aucun sens de dire "ça va marcher". Ce qu'il faut au contraire dire, c'est "ça va foirer parce que le débit réseau est pourri, parce que le serveur est lent/saturé, que le volume à stocker est insuffisant etc.

Les tests? Cela doit mettre en exergue plusieurs choses, contrairement à ce que peuvent penser les moins habitués
- Oui, on va détecter les bugs évidents et les corriger
MAIS
- Cela peut mettre en lumière des soucis de conception
- Indiquer que des demandes du client n'ont que peu de sens OU qu'on a vendu un truc inepte au client (cas vécu de statistiques inexploitables au final car s'adossant à des données obsolètes par exemple)
- Préciser qu'un fonctionnement n'est pas forcément le plus adapté. Cas d'école: une ergonomie mal fichue, un fichier de sortie finalement inexploitable car trop gros/incomplet/inutilement riche
- Faire émerger des soucis techniques vicieux comme de la compatibilité matérielle, des soucis de performance selon le processeur (encore du vécu: un développement réalisé par mes soins fonctionnait parfaitement bien sur du Intel, et posait de gros soucis sur des AMD, parce qu'une optimisation de VB.net ralentissait notablement le comportement... et donc vive les asynchronismes!)
- Révéler des erreurs sévères de conception (formatage de champs, liaisons entre tables dans la BDD, mauvais choix de librairies amenant des fuites mémoire... la liste des choses que j'ai pu subir est longue)

Pour finir: les tests sont le parent pauvre et oublié dans bien des projets. Pourquoi? Parce que cela coûte cher sans rendement immédiat. Le raisonnement débile qui est tenu est "chaque jour de test c'est du jour non facturé et sans réalisation. Pire: chaque bug induit du temps dépensé en plus des développements". Que répondre? Personnellement je réponds ainsi
- J'ai ajouté un pourcentage de temps sur le chiffrage POUR CA. Le client n'en veut pas? alors il assume que la qualité n'y sera pas... point final. Mieux: qu'il se tape les tests alors, et qu'il ne se plaigne pas s'il y a des retours.
- Je considère les tests comme une épreuve de validation. Si les tests sont OK, alors le client aura un produit fini. Moins il découvrira de bug, plus il sera confiant pour notre relation commerciale. De là, il pourra dès lors nous confier la maintenance (TMA), voire des évolutions, et même si le projet dure vraiment, aller jusqu'à nous proposer de refondre le produit dans une nouvelle technologie... ce qui est une chouette opportunité d'apprendre de nouvelles choses!

Ne JAMAIS réduire le rôle des tests. Ne JAMAIS dénigrer les équipes qui se tapent les tests. Il faut confier les tests à d'autres que les développeurs, car tous nous avons la même tendance, à savoir valider le fonctionnement selon notre point de vue alors qu'il faut précisément faire tout le contraire. Quand je fais tester mon code, je sais que je vais avoir des retours. Je m'en fous: Il n'y a pas de honte à avoir des anomalies tout simplement parce qu'on peut rater des cas pourtant évidents. Avec un bon testeur (et merci à ceux que j'ai chez moi, ce sont des bêtes de guerre pour ça) on peut obtenir un produit réussi, complet, fiable et mieux que tout viable.
 

SergioVE

Tout à faire car rien n'est fait.
Comme chaque fois que tu nous fais un topo, bravo. On ne peut en particulier que souligner tes deux derniers paragraphes.
Notre demandeur étant plus précisément orienté vers le développement Web j’ose un minuscule complément : contrôler l’application avec les principaux navigateurs du marché, et se poser la question douloureuse des appareils mobiles…
 

magellan

Modérâleur
Staff
Pour la partie navigateurs et tests, cela s'est sévèrement amélioré, et la plupart des thèmes et fonctionnalités Js sont quand même assez standard ("merci" chromium comme moteur de rendu).
 
Vous devez vous inscrire ou vous connecter pour répondre ici.
Derniers messages publiés
Statistiques globales
Discussions
730 098
Messages
6 717 060
Membres
1 586 286
Dernier membre
petitangebleu1977
Partager cette page
Haut