réaliser pour construire l’infrastructure de tests. Si le document est bien rédigé, il suffira
de le suivre au moment de l’exercice pour que la plate-forme de tests fonctionne.
Ce document, qui tient davantage d’une liste d’actions à accomplir que d’un document
rédigé, n’a pas à être extrêmement détaillé. Il se contente de rappeler, pour chaque étape,
qui doit faire quoi et quelles sont les relations d’ordre entre ces étapes. Idéalement, une
prévision horaire pour chaque étape est un plus, pour peu que l’on ait pris la peine lors de
l’étape précédente de mesurer sérieusement la durée unitaire de chaque action à réaliser.
Naturellement, ce document est rédigé par une personne de très bonne culture technique,
en concertation avec les différents acteurs concernés, à savoir les ingénieurs système, les
ingénieurs réseau, spécialistes du stockage, spécialistes de la virtualisation…
Constitution d’un jeu de tests applicatifs par le métier
Il ne faut pas oublier que les plans de secours ne sont pas un simple exercice de style
réalisé uniquement par des membres de la DSI. Le but est de vérifier que les utilisateurs
peuvent effectivement travailler en accédant très concrètement à leurs applications. Il est
donc important de réaliser, pour chaque application concernée par l’exercice, un scénario
de test décrivant au moins les actions suivantes :
connexion à l’application ;
consultation de données ;
mise à jour de données ;
invocation d’une fonctionnalité importante ;
déconnexion.
Des captures d’écran pour chaque étape montreront clairement les résultats à obtenir.
Ainsi, n’importe quelle personne jouant exactement ce qui est spécifié dans le jeu de tests
saura si le résultat correspond à ce qui est attendu ou pas.
La formalisation d’un jeu de tests pour chaque application impliquée dans l’exercice est
très importante car elle permet de vérifier exactement les fonctionnalités jugées
importantes par les utilisateurs (un informaticien se contentera généralement de s’assurer
qu’il arrive à se connecter sur l’application pour affirmer qu’elle est opérationnelle). Un
autre avantage de faire des jeux de tests détaillés est qu’ils peuvent être déroulés par
n’importe qui. Aussi n’est-il plus nécessaire de mobiliser les utilisateurs au moment de
l’exercice.
Cette étape étant indépendante des tests unitaires ainsi que de la réalisation de la
séquence technique, elle peut être réalisée dès que les applications concernées par
l’exercice ont été désignées, en parallèle avec les actions techniques.
Réalisation de l’exercice
À ce stade du plan, chacun possède les éléments nécessaires pour réaliser le test.
L’équipe de production dispose de la séquence technique décrivant chaque étape de la
mise en place de l’infrastructure technique de secours. De son côté, l’équipe chargée de
vérifier la disponibilité des applications dispose du dossier complet contenant tous les
de le suivre au moment de l’exercice pour que la plate-forme de tests fonctionne.
Ce document, qui tient davantage d’une liste d’actions à accomplir que d’un document
rédigé, n’a pas à être extrêmement détaillé. Il se contente de rappeler, pour chaque étape,
qui doit faire quoi et quelles sont les relations d’ordre entre ces étapes. Idéalement, une
prévision horaire pour chaque étape est un plus, pour peu que l’on ait pris la peine lors de
l’étape précédente de mesurer sérieusement la durée unitaire de chaque action à réaliser.
Naturellement, ce document est rédigé par une personne de très bonne culture technique,
en concertation avec les différents acteurs concernés, à savoir les ingénieurs système, les
ingénieurs réseau, spécialistes du stockage, spécialistes de la virtualisation…
Constitution d’un jeu de tests applicatifs par le métier
Il ne faut pas oublier que les plans de secours ne sont pas un simple exercice de style
réalisé uniquement par des membres de la DSI. Le but est de vérifier que les utilisateurs
peuvent effectivement travailler en accédant très concrètement à leurs applications. Il est
donc important de réaliser, pour chaque application concernée par l’exercice, un scénario
de test décrivant au moins les actions suivantes :
connexion à l’application ;
consultation de données ;
mise à jour de données ;
invocation d’une fonctionnalité importante ;
déconnexion.
Des captures d’écran pour chaque étape montreront clairement les résultats à obtenir.
Ainsi, n’importe quelle personne jouant exactement ce qui est spécifié dans le jeu de tests
saura si le résultat correspond à ce qui est attendu ou pas.
La formalisation d’un jeu de tests pour chaque application impliquée dans l’exercice est
très importante car elle permet de vérifier exactement les fonctionnalités jugées
importantes par les utilisateurs (un informaticien se contentera généralement de s’assurer
qu’il arrive à se connecter sur l’application pour affirmer qu’elle est opérationnelle). Un
autre avantage de faire des jeux de tests détaillés est qu’ils peuvent être déroulés par
n’importe qui. Aussi n’est-il plus nécessaire de mobiliser les utilisateurs au moment de
l’exercice.
Cette étape étant indépendante des tests unitaires ainsi que de la réalisation de la
séquence technique, elle peut être réalisée dès que les applications concernées par
l’exercice ont été désignées, en parallèle avec les actions techniques.
Réalisation de l’exercice
À ce stade du plan, chacun possède les éléments nécessaires pour réaliser le test.
L’équipe de production dispose de la séquence technique décrivant chaque étape de la
mise en place de l’infrastructure technique de secours. De son côté, l’équipe chargée de
vérifier la disponibilité des applications dispose du dossier complet contenant tous les