Tester une application
A mon avis il faut penser "aviation" et procéder par étapes, à savoir qu'on commence par faire rouler l'appareil au sol avant de lui faire franchir le mur du son, d'où l'importance de distinguer les tests qualitatifs des tests quantitatifs.
Tests unitaires ou qualitatifs
il s'agit de vérifier que tout fonctionne bien, que par exemple une combo renvoie la bonne valeur, qu'une table a les bonnes lignes, que les calculs se font bien, que l'ordre de saisie des champs est correct, qu'il n'y a pas de fautes d'orthographes, etc... Bref s'assurer que toutes les manips fonctionnent correctement, que les informations stockées sont bien les bonnes et que l'interface ressemble à quelque chose.
Les cercles concentriques
A mon avis dès le début des tests il faut travailler en "cercles concentriques" : commencer par les gestions de base (familles d'articles, modes de réglement), puis continuer sur des gestions intermédiaires (clients, articles), les gestion "lourdes" (factures, commandes) et finir par les résultats et autres états.
L'idéal est de procéder par étapes : on valide le groupe 1, puis le groupe 2, etc...
La raison est simple : s'assurer qu'une malfonction ne provient pas d'un module en amont. Par exemple si je ne retrouve pas les bons articles dans une facture ce ne sera pas à cause du module de gestion des articles qui fonctionne parfaitement. De même si un état ne restitue pas les bons chiffres ce ne sera pas à cause du module de gestion des factures, etc...
Ce découpage en groupes ressemble plus ou moins au modèle des données. Je pense que c'est au développeur (ou Chef de projets) de déterminer ces groupes. Voici un exemple :
L'esprit critique
Les tests unitaires c'est aussi le moment pour les testeurs d'avoir un avis critique - et constructif bien entendu - sur l'ergonomie ou sur l'approche d'un problème.
Il est à mon avis préférable de passer du temps sur une interface "pas terrible" plutôt que de tester à fond ... pour devoir la refaire dans six mois suite aux mécontentements des clients.
Je sais de plus par expérience qu'un module finalisé et fiable a peu de chances d'être redéveloppé : "Oulala, ce truc là il marche, on n'y touche surtout pas !".
Des identifiants uniques
Pour ces tests unitaires à mon avis il faut travailler avec des identifiants uniques sur toute la base.
Dans un article j'avais proposé de décaler les identifiants de chaque table de 1000 en 1000 de manière à garantir l'unicité des identifiants, ce qui va permettre de mettre en évidence les mauvaises relations.
Certes il doit être possible de faire mieux en optant pour un GUID (identifiant unique sur toute la base) comme l'avait suggéré un contributeur du forum. Mais là ça suppose que l'application ait été développée ainsi avec les mécanismes internes qui vont bien.
Les tests quantitatifs
Une fois que les tests qualitatifs sont validés et que le module fonctionne sans problème (ou presque) on va "goinfrer" la base afin de vérifier essentiellement les temps de traitement ... mais aussi l'aspect pratique des interfaces ou des états avec beaucoup de données.
A ce stade ce n'est plus la peine de s'assurer de la cohérence des résultats, le travail a déjà dû être fait en amont.
Au niveau quantité de données je pense qu'il faut rechercher un volume maximum raisonnable !
Par exemple : sur un logiciel de facturation pour les PME/TPE on estime que pour la plupart des client ce sera moins de 100 factures par an. Alors on fera des tests quantitatifs sur 150 ou 200 pour avoir un peu de marge, voir 150 à 200 par exercice sur N exercices, de manière à bien mettre à l'épreuve les requêtes et autres algorithmes.
Là on pourra se rendre compte des lenteurs, que l'on gache beaucoup de papier à cause de ruptures mal gérées, etc...
On peut également s'appercevoir de certaines lourdeurs d'utilisation, avec le besoin par exemple d'ajouter des critères de sélection, d'inverser des tris, de remplacer des combos par des listes de recherche, etc...
A ce niveau de tests la grosse difficulté pour les testeurs c'est d'alimenter la base !
Et oui les testeurs ils ne vont pas saisir 200 factures à la "mimine" !
Il y a certes la possibilité de laisser les clients "gâver" leur base et d'attendre en croisant les doigts. Et oui ça je l'ai vu faire et j'ai aussi vu des développeurs devoir refaire des algortithmes en urgence suite à la plainte d'un client. Dans ces cas là tout le monde est "sur le pont" et c'est la panique à bord ! A éviter :-)))
Générateur aléatoire de données
La solution consiste alors à intégrer dans l'applicatif une option permettant de générer aléatoirement N enregistrements pour X fichiers. Il suffit de mettre en place des fonctions de génération aléatoire de chaines, de valeurs, de dates, etc... de mettre en place des relations aléatoires et bien entendu de gérer correctement les doublons.
Bien entendu ce module doit avoir été testé à fond par le développeur de manière à ne pas générer des effets de bord indésirables !
(pour ne pas devoir tester des trucs qui permettent de tester des trucs qui permettent de tester, etc...)