Une
montée de version peut parfois ressembler
à une implantation initiale dans le cas
d’un retard de version (plusieurs versions
à rattraper) ou dans le cas d’une migration
de plateforme technologique avec le même
WMS. Cependant, si votre application est
à jour et que le projet consiste à implanter
la nouvelle version sans modifier la couverture
fonctionnelle en place, vous devrez réaliser
un test de non-régression. Ce test se base
sur les cahiers de tests rédigés lors du
projet initial et maintenus à jour au fil
des évolutions de l’application. Si ces
cahiers de tests n’existent pas ou sont
incomplets, vous devrez les élaborer, car
ils sont les seuls garants de la réussite
de votre projet. Les cahiers de tests sont
des documents qui listent de façon exhaustive
les cas qui composent les tâches, les processus
et les flux. Ils se composent des scénarios
de tests et de la description des jeux de
données requis pour valider chaque cas.
Globalement, vous devez avoir des cahiers
de recettes pour la plateforme technique
et pour l’application (WMS + interfaces
ERP et TMS).
Un
environnement de test est impératif. Il
se composera d’une plateforme technique
dont les spécifications techniques et fonctionnelles
sont identiques à la plateforme de l’environnement
de production (mêmes technologies, mêmes
versions des logiciels, mêmes équipements
périphériques, même paramétrage, mêmes données
de base). Les sessions de tests doivent
être cycliques et basées sur la restauration
des jeux de données définis dans les cahiers
de tests à chaque installation de correctifs.
2.
Tests unitaires
Les
tests unitaires ont pour objectif de vérifier
chaque élément individuellement sans considérer
l’ensemble. Par exemple, le test d’une interface
en particulier déclenchée manuellement ou
le test de validation des rangements en
RF ou le test d’une imprimante, etc. Ces
tests sont fragmentés et pas nécessairement
synchronisés. Lorsque tous les éléments
sont individuellement conformes aux cahiers
de tests, il est temps de passer à la phase
« d’assemblage » de ces éléments pour effectuer
les tests d’intégration.
3.
Tests d’intégration
Les
tests d’intégration ont pour objectif de
vérifier le fonctionnement d’ensembles logiques
(flux transactionnels et de marchandises).
Par exemple, le flux d’approvisionnement
de la commande achat à la localisation du
stock dans l’entrepôt. Le test commencera
donc dans l’ERP, passera par les interfaces
vers le WMS, puis dans les processus de
planification, de réception, de rangement
dans le WMS, puis de retour des transactions
vers l’ERP par l’interface, etc. Pour compléter
ces tests, les résultats obtenus devront
être conformes aux cahiers de tests sur
la totalité du flux. Au delà de la qualité
obtenue, ces tests d’intégration peuvent
avoir un aspect légal dans le cas où une
partie du flux est traitée par un prestataire.
Dans ce cas, il est essentiel de contraindre
les équipes à des validations de tests à
l’aide d’un procès verbal de tests.
4.
Tests de non-régression
Les
tests de non-régression sont identiques
aux tests d’intégration. La différence réside
dans la formulation. Il s’agit de vérifier
que le système est toujours en conformité
avec les cahiers de tests de la version
précédente à périmètre fonctionnel équivalent.
Par conséquent, vous devez dérouler l’ensemble
des cahiers de recette pour vous en assurer.
5.
Tests de stress ou de masse
Une fois que le système est conforme au
niveau des tests d’intégration, les tests
de stress permettent de valider le niveau
et la stabilité des performances dans diverses
situations (sous-utilisation, utilisation
normale ou extrême). Par exemple, votre
système est conçu pour le traitement de
5 000 commandes par jour avec une équipe
de 20 opérateurs (utilisation dite « normale
»). Cependant, votre activité est saisonnière
et vous pouvez monter à 10 000 commandes
par jour avec 50 opérateurs en pleine saison.
Vous devrez tester que votre système accepte
cette surcharge sans dégradation de sa performance
(aux niveaux technique et fonctionnel).
6.
Tests fonctionnels
Les
tests fonctionnels ont pour objectif de
vérifier l’autonomie des opérateurs (formation,
accès au système, etc.) et que les postes
de travail sont opérationnels. C’est un
peu une répétition générale. Ce test peut
sembler superflu, mais il est essentiel.
Il permet aux opérateurs d’être impliqués
dans le projet, de créer une relation de
confiance avec les super-utilisateurs de
l’équipe
de projet, de régler les derniers petits
problèmes avant le démarrage et, par conséquent,
d’avoir des acteurs souriant le jour du
démarrage et surtout, des clients satisfaits
dans les jours qui suivent.
Martin
Lalumière
Conseiller, Groupe GCL
www.gclgroup.com
|
