par Colin Armitage
Les tests systématiques devraient être placés en haute priorité dans votre service
informatique.
Combien de temps votre département informatique passe-t-il à corriger des erreurs
et à effectuer des modifications que vous auriez dû réaliser avant de déployer
une application ? Si votre réponse est "beaucoup", alors vous devriez vous appesantir
à nouveau sur un aspect souvent négligé du développement d'applications : les
tests.L'année dernière, à l'occasion du lancement du produit TestBench400, mis
sur le marché par mon entreprise, nous avons eu l'occasion de discuter des techniques
de test applicatifs en environnement AS/400, avec plusieurs entreprises informatiques
basées en Amérique du Nord et en Europe.
Cette expérience nous a permis d'acquérir une perspicacité unique dans les approches
de tests en vigueur et dans la manière dont les techniciens professionnels perçoivent
généralement l'équilibre indispensable coût/bénéfice quand il s'agit de tests.
La première chose dont nous nous sommes aperçus est le sérieux problème d'image
dont souffre l'art de tester les logiciels.
En effet, ce domaine est largement perçu comme étant plus qu'obscur. Aussi, personne
ne souhaite s'y investir. De plus, ceux qui acceptent de le faire, voudraient
en finir le plus tôt possible. Considérez les scénarii de tests suivants :
La première chose dont nous nous sommes aperçus est le sérieux problème d'image
dont souffre l'art de tester les logicielsTests unitaires.
Si vous travaillez sur un site où les développeurs ne sont pas responsables
de leurs propres tests unitaires, alors félicitations. Le reste du monde doit
avoir perdu la tête.
Après tout, pourquoi se donner tant de peine à demander aux développeurs d'assurer
le bon fonctionnent de leurs propres programmes ? D'une manière générale, les
développeurs adorent développer mais ils ont horreur de tester. Seuls de rares
et précieux développeurs essaient véritablement de tester les failles potentielles
de leurs propre code de manière imaginative. Il ne faut que deux développeurs
pour mettre en place une politique de vérification croisée.
En revanche, si on ne peut pas se le permettre, il faut se résigner à accepter
les tests unitaires réalisés par le programmeur ayant conçu le code tels qu'ils
sont, c'est-à -dire, incertains.
Cependant, ces tests peuvent avoir un intérêt si vous fournissez des fiches de
test prédéfinies et qui attesteront de l'adhésion à des standards de conception
(par exemple pour la présentation de rapports, les couleurs et la disposition
des écrans), et de la fiabilité de tous les embranchements à travers le programme.
Tests des systèmes.
Les tests des systèmes sont souvent réalisés par les membres seniors d'une équipe.
Responsables de la livraison de systèmes dans leur ensemble, ces derniers sont
généralement motivés pour réaliser les tests nécessaires.
Cependant, il y a deux obstacles majeurs à la réalisation des tests de systèmes.
En effet, les responsables informatiques planifient souvent les tests comme étant
la dernière activité importante à réaliser dans un cycle de développement. D'autre
part, ces tests sont généralement programmés alors qu'une date de mise en production
du logiciel a déjà été fixée.
Aussi, lorsque les autres tâches du cycle de développement prennent du retard,
le temps disponible pour effectuer les tests s'en trouvent réduits d'autant. Voilà
comment finalement on ne teste que ce que l'on peut, au lieu tester tout ce dont
on a besoin.
Par ailleurs, la mauvaise qualité des tests unitaires oblige souvent les testeurs
à reprendre plusieurs fois une même série de tests des systèmes. Après le troisième
ou quatrième cycle de tests, même le testeur le plus consciencieux ne testera
plus que les corrections. C'est précisément à ces moments là que les bogues en
profitent pour passer à travers les mailles du filet.
Tests d'acceptation.
Dans certaines entreprises, les tests
Le test d’applications : un art méconnu
1. Définir les objectifs
des tests. Définissez l’étendue des tests requis, les méthodes utilisées
pour effectuer les tests, le personnel impliqué et les conditions dans lesquelles
vous seriez prêt à accepter le système.
2. Prévoirdes scripts de tests. Prévoyez des ensembles de données
de test comprenant des combinaisons possibles de transactions de gestion. Cette
étape doit définir les résultats attendus et les conditions qui doivent être remplies
pour que le résultat d’un test soit jugé satisfaisant.
3. Récupérer les données des tests. Bien que l’on puisse copier
une base de données active dans sa totalité, il est plus facile de vérifier 100
enregistrements que 100000. De plus, il se peut que vous soyez limité par l’espace
disque. Si vous effectuez des tests en utilisant des échantillons, vous devez
extraire un sous-ensemble représentatif par rapport aux relations existantes.
.4. Affiner les données des tests. Manipulez votre base de données
de tests afin de produire des combinaisons de données qui sollicitent correctement
le système. Cela inclut la remise à l’état initial des champs statut, l’extension
des champs dates et la protection de renseignements confidentiels.
5. Définir l’environnement de tests. L’environnement de tests des
AS/400 doit être configuré de manière homogène pour tous les cycles de tests.
Cela inclut la base de données de tests, les zones des données, les paramètres
des programmes et les listes de bibliothèques.
6. Créer des scripts interactifs. Définissez les embranchements à suivre
à travers le système de test pour vous assurer que ce dernier est testé exhaustivement.
(Ce secteur constituait la principale préoccupation de la première génération
d’outils de test).
7. Tester les programmes batch et interactifs. Après une préparation
minutieuse, les tests se posent comme une opération plus simple. Un plus grand
défi consiste à définir le niveau de test requis suite à un échec.
8. Vérifier les écrans. Une approche exhaustive doit vous permettre de
vous assurer que tous les écrans satisfont aux critères aussi bien de présentation
que de contenu.
9. Vérifier les rapports.Même avec des volumes de données
de test de taille limitée, les rapports peuvent générer plusieurs pages. Des outils
de comparaison peuvent s’avérer utiles, à condition qu’ils soient capables d’exclure
les champs qui changent constamment (par exemple les champs date et heure) du
système, et ceux dont le contenu peut légitiment varier entre deux cycles de test.
10. Vérifier la base de données. On ne peut pas compter sur les écrans
et les rapports pour refléter correctement le contenu d’une base de données. Vérifiez-le
directement en utilisant des requêtes SQL, ou des programmes qui testent la conception
du système.
11. Vérifier tous les paramètres.Le développement d’applications
sur AS/400 encourage l’utilisation de la programmation modulaire, qui renvoie
des données comme paramètres. Les tests unitaires exigent de vérifier individuellement
tous les modules avant de les lier au système.
12. Vérifier le journal du job.Même si vous réalisez un
test sans rencontrer d’échec et atteignez les résultats attendus, vos programmes
peuvent se heurter à des problèmes qui ne sont pas répertoriés du fait des moniteurs
de messages ou du paramétrage du job.
13. Vérifier les performances.Vérifiez les performances à la fois
batch et interactives. Une routine de fin de journée peut fonctionner co rrectement
avec un échantillon de test de 100 enregistrements, et prendre 25 heures avec
des volumes de données de production !
14. Effectuer des tests de contre-vérification.Comparez
les résultats des rapports à ceux des cycles de tests antérieurs et à vos attentes.
15. Préparer des rapports en prévision des audits.Les services
d’audit interne et externe montrent un intérêt grandissant pour les services informatiques.
Ils peuvent réclamer des preuves (sous la forme d’enregistrements de tests) indiquant
que vous avez testé un système avant sa mise en production.
16. Suivre l’état d’avancement du projet.Suivez à la trace l’état
d’avancement du projet de test. Des rapports réguliers sur l’état d’avancement
vous aideront à respecter les délais et à identifier rapidement une source de
retard probable.CA
Téléchargez cette ressource
Travail à distance – Guide complet pour les Directions IT et Métiers
Le travail à distance met à l'épreuve la maturité numérique des entreprises en termes de Cybersécurité, d'espace de travail, de bien-être des collaborateurs, de communication et gestion de projet à distance. Découvrez, dans ce nouveau Guide Kyocera, quels leviers activer prioritairement pour mettre en place des solutions de travail à domicile efficaces, pérennes et sécurisées.
