Si votre organisation traite régulièrement des données sensibles, vous devez mettre en œuvre des stratégies de conformité en matière de sécurité des données pour protéger non seulement les personnes auxquelles les données appartiennent, mais également votre organisation contre toute violation des lois fédérales (par exemple, HIPPA, GDPR, etc.). Cela affecte les organisations dans des secteurs tels que les soins de santé, la banque, le gouvernement, le juridique… vraiment toute organisation qui traite des données sensibles.
On parle de PII (Personally Identifiable Information) et PHI (Protected Health Information). Exemples de PII-
- Numéros de sécurité sociale
- comptes bancaires
- Noms complets
- Numéros de passeport, etc.
Exemples de PHI-
- Dossiers de santé
- Résultats de laboratoire
- Factures médicales et autres, qui incluent des identifiants individuels
Méthodes de protection des données sensibles
Certains clients ont décrit leurs méthodes comme des scènes que vous pourriez imaginer dans un film que vous avez regardé… visualisez un groupe de personnes armées de leurs autorisations de sécurité requises se blottissant dans une pièce verrouillée, sans fenêtres, pour vérifier manuellement les impressions des rapports afin de s'assurer que les informations sensibles n'est pas inclu. Bien que cela donne une scène de film dramatique, ce n'est pas le moyen le plus infaillible ni le plus efficace de tester les rapports pour les informations sensibles. Et avec les exigences de main-d'œuvre à distance de Covid-19, ce n'est tout simplement pas faisable pour le moment.
Nous avons aidé plusieurs de nos clients à mettre en œuvre la puissance des tests automatisés pour tester dynamiquement les sorties de leurs rapports Cognos. Cette stratégie de test détecte les rapports tôt, dès qu'ils ne sont plus conformes et avant qu'ils ne finissent en production pour se retrouver entre de mauvaises mains. C'est toujours une bonne idée de savoir où se trouve le bureau de sécurité sociale le plus proche de chez vous, comme le Bureaux de la sécurité sociale au Nevada, si le pire devait arriver, car l'équipe de votre bureau local saura comment gérer la situation.
Valeur des tests au début des cycles de développement
La détection précoce des vulnérabilités en matière de sécurité des données peut aider à éviter les futures amendes et sanctions imposées par le gouvernement. Selon le US Department of Health and Human Services, à ce jour, le Bureau des droits civils (OCR) « a réglé ou imposé une amende civile dans 75 cas, pour un montant total de 116,303,582.00 1.5 XNUMX $ ». C'est plus de XNUMX million de dollars par caisse ! Et selon le Journal HIPAA le « ne pas effectuer une analyse des risques à l'échelle de l'organisation est l'une des violations de la loi HIPAA les plus courantes pouvant entraîner une pénalité financière ».
En plus d'éviter les sanctions imposées par le gouvernement, il est généralement important de détecter les erreurs dès le début du cycle de développement, car c'est à ce stade que les problèmes sont beaucoup plus faciles et moins coûteux à résoudre. Par conséquent, l'objectif principal de cet exercice est d'utiliser MotioCIla puissance des tests de régression pour identifier facilement de telles erreurs et donc les prévenir dès le début du cycle de développement.
Voyons comment configurer les tests. Nous commencerons par configurer notre environnement Cognos, puis nous expliquerons comment configurer des tests automatisés pour les données PHI et PII pour notre exemple. Nous utiliserons également ces mêmes cas de test dans l'environnement de production pour un niveau supplémentaire de conformité et de contrôle de sécurité.
Configuration de l'environnement PHI et PII Cognos
Notre exemple d'environnement Cognos (Figure 1) se compose de plusieurs rapports, chacun contenant un mélange de données sensibles PII et PHI (par exemple, code de diagnostic, ordonnance, numéro de sécurité sociale, nom de famille du patient, etc.) et de données peu sensibles (par exemple, patient prénom, date de visite, etc.).
Figure 1 : Notre exemple d'environnement Cognos.
Il existe deux rôles Cognos, Autoriser les PII ainsi que le Autoriser PHI, qui déterminent si des données sensibles sont rendues lors de l'exécution des rapports. (Tableau 1)
| Rôles Cognos | Notes |
| Autoriser les PII | Les membres de ce rôle peuvent afficher toutes les données PII (c'est-à-dire le numéro de sécurité sociale et le nom du patient) dans les rapports Cognos. |
| Autoriser PHI | Les membres de ce rôle peuvent afficher toutes les données PHI (par exemple, les codes de diagnostic ICD10, la description détaillée du diagnostic, etc.) dans les rapports Cognos. |
Tableau 1 : rôles de Cognos contrôlant le rendu des données sensibles.
Par exemple, un utilisateur qui n'a pas nos deux rôles Cognos, son rapport « Patient Daily Intake » devrait ressembler à ceci (Figure 2) :
Figure 2 : Sortie de rapport produite par un utilisateur qui n'a pas à la fois les rôles AllowPII et AllowPHI.
Comme vous pouvez le voir, toutes les données PHI et PII sont entièrement masquées par l'utilisateur qui n'est pas membre des deux rôles « Autoriser PHI/PII ».
Exécutons maintenant le rapport avec un utilisateur membre du rôle « AllowPII », ce qui signifie que nous nous attendons à ce que cet utilisateur ne puisse afficher que les données PII (Figure 3) :
Figure 3 : Sortie de rapport produite par un utilisateur membre du rôle AllowPII et NON du rôle AllowPHI.
Et vous pouvez voir ici que les colonnes Numéro de sécurité sociale et Nom de famille s'affichent correctement sans aucune rédaction.
Jusqu'à présent, nous avons jeté un coup d'œil à l'environnement Cognos de notre clinique mythique et tout ce que nous avons vu jusqu'à présent est la sécurité des données basée sur les rôles de Cognos que beaucoup d'entre vous ont peut-être déjà implémentée dans leurs propres environnements Cognos. Cela nous amènerait alors à la question principale à laquelle les porteurs d'espoir de données sensibles n'auraient jamais à faire face :
Et si, disons après un gros effort de développement, des données sensibles se frayaient un chemin et commençaient à apparaître pour des utilisateurs qui ne sont pas censés les voir ?
Les erreurs sont certainement inévitables, donc plus tard dans le blog, nous utiliserons MotioCILa puissance des tests de régression de pour garder un œil vigilant sur nos rapports afin de s'assurer que les données privées ne sont jamais exposées à un public indésirable.
Présentation des tests de conformité pour Cognos
Comme mentionné dans la section précédente, de simples erreurs dans la création ou la modélisation de rapports peuvent induire un comportement indésirable dans la sortie des rapports dans votre environnement Cognos. Et si ces changements ne sont pas détectés, ils ont le potentiel de se faufiler dans votre environnement de production. Ce qui serait encore plus désastreux, c'est que si ces changements indésirables incluent l'exposition de données privées à un public non intentionnel.
Par exemple, un utilisateur sans être membre de l'un ou l'autre Autoriser les PII or Autoriser PHI Les rôles Cognos ne sont pas censés voir les données privées PII ou PHI dans notre exemple d'environnement Cognos. Cependant, comme vous pouvez le voir ci-dessous (Figure 4), un simple changement dans le modèle FM a provoqué l'exposition de la description du diagnostic et du numéro SSN du patient à un tel utilisateur, ce qui constitue une ÉNORME violation de la règle de sécurité fédérale HIPAA.
Figure 4 : Un utilisateur sans appartenance aux rôles AllowPII et AllowPHI est en quelque sorte exposé à des données sensibles HIPAA.
Avant de déplacer les choses vers MotioCI, nous allons d'abord créer trois utilisateurs de test dans notre environnement Cognos et les affecter à nos deux rôles de la manière suivante (tableau 2) :
| Utilisateurs | Rôle Appartenance | Notes |
| TestUtilisateurA | Autoriser les PII | Toutes les données PHI doivent être masquées pour cet utilisateur |
| TestUtilisateurB | Autoriser PHI | Toutes les données PII doivent être masquées pour cet utilisateur |
| TestUtilisateurC | Aucun | L'utilisateur ne doit PAS voir les PHI ou PII |
Tableau 2 : Test des comptes d'utilisateurs Cognos avec leurs rôles attribués.
Ces comptes d'utilisateurs de test seront ensuite utilisés dans MotioCI pour les tests de régression de nos rapports contenant des données PII et PHI sensibles. Les résultats de nos tests dépendront de la visibilité des données sensibles pour chaque utilisateur en fonction de son appartenance à un rôle.
Maintenant que nous avons configuré nos utilisateurs de test, nous sommes prêts à configurer nos tests de régression dans MotioCI.
MotioCI Configuration de l'environnement
Notre exemple d'environnement se compose d'instances Development, UAT et Production Cognos. Bien que MotioCI nous permet de nous connecter aux trois en même temps, nous allons commencer notre configuration de tests de régression dans l'environnement de développement en trois phases différentes.
Figure 5: MotioCI écran de connexion.
Figure 6: MotioCI écran d'accueil, affichant les instances de Cognos.
En ce qui concerne les tests de régression dans MotioCI, un affirmation est une vérification ou un « test » individuel qu'un scénario de test effectue sur un objet dans votre MotioCI exemple, tel qu'un rapport, un dossier ou un package. L'assertion qui effectuera le travail de test des sorties de rapport pour les données sensibles est appelée Test de conformité des données sensibles (Illustration 7). Il s'agit d'une affirmation personnalisée que nous avons rassemblée pour cet exercice. Ci-dessous, vous pouvez voir le type d'assertion qui agit essentiellement comme le modèle principal qui est copié dans les cas de test tout au long de notre MotioCI environnement. Plus à ce sujet plus tard.
Figure 7 : Type d'assertion « Test de conformité des données sensibles ». Des copies de cette assertion sont déployées dans l'environnement de test.
Certaines assertions fournissent des fonctionnalités réglables par l'utilisateur via un fenêtre d'invite. Ici, vous pouvez modifier la manière dont vous souhaitez qu'une assertion donnée teste un rapport Cognos donné. La figure 8 ci-dessous montre le fenêtre d'invite de notre affirmation que nous utiliserons pour tester nos rapports Cognos contenant des données sensibles.
Figure 8 : Fenêtre d'invite de l'assertion « Test de conformité des données sensibles », révélant toutes les options de test réglables par l'utilisateur.
La section en surbrillance supérieure de la figure 8 montre les options de test pour les données sensibles PII et PHI. Cela vous permet d'avoir le test d'assertion si le rapport doit afficher ou masquer ses données PII ou PHI. Nous apporterons des modifications à ces deux options au fur et à mesure que nous commencerons à créer des cas de test pour chacun de nos trois utilisateurs de test.
La section centrale en surbrillance de la figure 8 montre les noms des colonnes qui contiennent des données sensibles PHI dans nos rapports. Bien que notre exemple d'environnement se compose de colonnes portant les noms de code de diagnostic ICD10, de description de diagnostic, de procédure et de réception, vous pouvez certainement modifier cette liste en fonction de vos besoins.
Enfin, la section en surbrillance inférieure de la figure 8 montre les options de courrier électronique. En cas d'échec, cette assertion enverra un e-mail détaillé au destinataire configuré dans cette section.
Phase I : Rapports affichant uniquement des informations personnelles
Créons un projet sous le Développement exemple dans MotioCI et appelez-le Autoriser les informations personnelles uniquement. Nous pouvons le faire en faisant d'abord un clic droit sur le Développement nœud d'instance dans le MotioCI l'arborescence de navigation et en sélectionnant le Ajouter un projet option (figure 9).
Figure 9 : Création d'un nouveau projet. Dans MotioCI chaque projet sert de terrain d'essai pour une section prédéfinie du magasin de contenu.
La Assistant d'ajout de projet vous guidera à travers quelques étapes pour sélectionner les chemins nécessaires à votre projet. Dans notre exemple, tous les rapports contenant des données sensibles PII et PHI existent sous le Données du patient dossier. La vérification de ce dossier parent inclura automatiquement tous les rapports sous-jacents (Figures 10 et 11).
Figure 10 : Détermination de la portée du projet en MotioCI en sélectionnant les chemins dans l'environnement Cognos.
Figure 11 : Affichage de tous les objets Cognos sélectionnés pour le MotioCI .
Étant donné que tous les rapports de ce projet doivent permettre l'affichage de toutes les données PII et l'obscurcissement de tous les PHI, nous devrons configurer notre type d'assertion avec les paramètres corrects avant d'ajouter des cas de test (Figure 12). Cela signifie définir les deux options de test sur la même assertion fenêtre d'invite que nous avons vu précédemment sur la figure 8.
Figure 12 : Options de test PII et PHI de l'assertion « Test de conformité des données sensibles ».
Nous sommes maintenant prêts à ajouter nos cas de test à nos rapports. Pour ce faire, faites un clic droit sur le nœud du projet (c'est-à-dire le Autoriser les informations personnelles uniquement projet) dans MotioCI et sélectionnez le Générer des cas de test option (figure 13). Cela lancera l'assistant de génération de cas de test qui nous permettra de créer un grand nombre de cas de test pour tous les rapports du projet.
Figure 13: MotioCI peut générer automatiquement tous les cas de test nécessaires à n'importe quel niveau à partir du projet.
La Générer un scénario de test L'assistant nous permettra également de sélectionner les formats de sortie pour le scénario de test sur lequel nous souhaitons effectuer des tests. Pour notre exemple d'environnement, j'ai choisi la sortie CSV. L'assistant nous permettra également de choisir les assertions que chaque scénario de test utilisera pour le travail réel de test. Et pour nous ce serait le Test de conformité des données sensibles affirmation. Vous pouvez voir ces deux options mises en évidence ci-dessous (Figure 14).
Figure 14 : Les options révélées lors de l'assistant « Générer des cas de test ».
Après avoir cliqué sur « OK », vous serez redirigé vers le MotioCI écran d'accueil, où vous pourrez voir tous nos rapports contenant chacun un seul cas de test et chacun contenant notre seule assertion (Figure 15).
Figure 15: MotioCI arborescence de navigation affichant tous les objets Cognos contenant désormais chacun un scénario de test et l'assertion sous-jacente.
Enfin, nous devons configurer tous les scénarios de test pour exécuter leurs rapports parents en utilisant le bon utilisateur Cognos (par exemple, l'un des trois utilisateurs de test que nous avons configurés dans Cognos avant de configurer les choses dans MotioCI). Et puisque pour ce projet, nous testons pour nous assurer que le contenu PHI est ne sauraient affiché aux utilisateurs qui ne sont autorisés à afficher que les données PII, nous devrons définir tous les cas de test à exécuter avec TestUtilisateurA (voir tableau 2).
Au début, cela peut sembler une tâche fastidieuse, mais heureusement pour nous, nous pouvons définir l'utilisateur au niveau du projet qui serait ensuite hérité par TOUS les cas de test sous-jacents au sein de ce projet. Pour cela, dans l'arborescence de navigation de gauche, nous allons cliquer sur le nœud du projet ( Autoriser les informations personnelles uniquement projet) puis sélectionnez le Paramètres du projet au milieu de l'écran. Ensuite, sous le Essais section, nous verrons une option pour changer les informations d'identification (Figure 16):
Figure 16 : Si vous définissez les informations d'identification de l'utilisateur sur un projet, tous les scénarios de test exécuteront le rapport Cognos parent dans Cognos avec cet utilisateur. Cela peut être écrasé par chaque cas de test individuel.
Après avoir cliqué sur le Modifier bouton situé devant le Lettres de créance option, on nous présentera la Modifier les informations d'identification la fenêtre. Nous allons entrer les informations d'identification pour TestUtilisateurA (Figure 17).
Figure 17 : La fenêtre « Modifier les informations d'identification » vous permet de définir de nouvelles informations d'identification d'utilisateur ou d'utiliser les informations d'identification parent définies au niveau de l'instance Cognos, également appelées informations d'identification système.
Nous voyons maintenant le nouvel utilisateur reflété dans le Essais l'article de l' Paramètres du projet onglet (Figure 18).
Figure 18 : Les nouvelles informations d'identification de l'utilisateur sont désormais définies sur le projet.
Nous sommes maintenant prêts à exécuter tous nos cas de test.
Pour cela, nous allons cliquer sur le Autoriser les informations personnelles uniquement projet et au milieu on nous présentera le Cas de test onglet qui affiche tous les cas de test situés dans le projet. Comme nous n'avons toujours rien exécuté, nous verrions le Statut montrant comme Aucun résultat. Pour exécuter tous les cas de test, nous allons cliquer sur la petite flèche à côté du Courir bouton et sélectionnez le Exécuter tout option (figure 19).
Figure 19 : L'onglet « Scénarios de test » fournit un certain nombre d'actions pouvant être effectuées sur tout ou partie des scénarios de test en bloc. Ici, nous exécutons simplement tous les cas de test.
MotioCI va maintenant exécuter tous les cas de test et nous présenter les résultats lorsqu'ils sont tous terminés (Figure 20).
Figure 20 : L'onglet « Scénarios de test » affiche l'état d'exécution de chaque scénario de test, y compris les sorties, le cas échéant.
Comme vous pouvez le voir, tous nos cas de test ont réussi à l'exception du Hospitalisé rapport. Voyons donc les résultats. Pour ce faire, nous allons cliquer sur l'horodatage bleu situé sous le Résultat colonne et regardez les détails de la Figure 21.
Figure 21 : Le panneau « Résultat du scénario de test » affiche les résultats détaillés de l'exécution du scénario de test, y compris le chemin de l'objet testé, les résultats des assertions et toutes les sorties produites par le rapport.
En vertu des Normes sur l’information et les communications, les organismes doivent rendre leurs sites et applications Web accessibles. Ils y parviennent en conformant leurs sites Web au niveau AA des Web Content Accessibility Guidelines (WCAG). Résultats d'assertion section, nous pouvons maintenant voir que notre rapport est en violation des exigences de conformité PHI. Nous pouvons télécharger la sortie du rapport CSV à partir du Sorties de cas de test section en cliquant sur l'icône CSV (Figure 21).
Figure 22 : La sortie du rapport CSV montrant une colonne « Procédure » affichée qui doit avoir été masquée pour l'utilisateur du test.
Comme vous pouvez le voir dans notre rapport (Figure 22), en plus des données PII auxquelles TestUserA peut avoir accès, nous pouvons voir les données de la procédure PHI qui mettent le rapport en violation de la règle de sécurité fédérale HIPAA.
Si vous vous souvenez de la fenêtre des paramètres d'assertion, nous étions également censés recevoir une notification par e-mail pour cet échec. Voyons à quoi cela ressemble (Figure 23) :
Figure 23 : Message électronique envoyé par l'assertion du cas de test échoué, montrant une violation de la conformité des données sensibles, probablement due à une modification récente du rapport.
À ce stade, nous avons terminé les tests pour nous assurer que les données PHI sont cachées aux utilisateurs sans les Autoriser PHI Cognos rôle. Nous sommes maintenant prêts à étendre nos tests aux données PII cachées aux utilisateurs ne disposant pas des Autoriser les PII Cognos rôle.
Phase II : Rapports affichant uniquement les RPS
Avant de créer le nouveau projet, modifions d'abord les options de notre assertion principale pour nous assurer qu'elle teste maintenant toutes les PII à masquer et toutes les PHI à afficher (Figure 24).
Figure 24 : Options de test PII et PHI de l'assertion « Test de conformité des données sensibles » définies pour TestUserB.
Avec notre assertion maintenant toute configurée, nous sommes maintenant prêts à créer le nouveau projet et nos cas de test. Pour cela, nous allons simplement suivre les mêmes étapes que dans la « Phase I » et créer un projet appelé Autoriser PHI uniquement. N'oublions pas non plus d'ajouter les identifiants de TestUtilisateurB en tant qu'utilisateur du projet.
Lorsque nous aurons terminé toutes les étapes de configuration, nous exécuterons tous les cas de test comme nous l'avons fait dans la phase I. Dans notre exemple d'environnement, nous avons cette fois un rapport différent qui semble être en violation de la loi HIPAA (Figure 25).
Figure 25 : L'onglet « Scénarios de test » affichant l'état d'exécution de chaque scénario de test, y compris les sorties, le cas échéant.
Une enquête plus approfondie sur les résultats des cas de test de la Apport quotidien du patient rapport montre que notre rapport affiche les numéros de sécurité sociale des patients à un public non visé (Figure 26).
Figure 26 : résultat du scénario de test indiquant une violation de l'exigence de conformité SSN PII.
Le téléchargement et l'ouverture du fichier CSV confirmeront davantage les résultats de notre test (Figure 27) :
Figure 27 : La sortie CSV montre le SSN du patient révélé là où il aurait dû être masqué.
Comme vous pouvez le voir sur la figure 27, cependant, notre rapport masque correctement la colonne du nom de famille du patient (également une PII) en affichant uniquement l'initiale.
| Devoirs! |
| Répétez les mêmes étapes pour TestUtilisateurC qui manque à la fois Autoriser les PII ainsi que le Autoriser PHI rôles, ce qui signifie qu'ils ne sont pas censés voir les données PII ou PHI lorsqu'ils exécutent l'un de nos rapports. |
À ce stade, notre environnement devrait avoir réalisé des tests de régression complets des données sensibles PHI et PII en utilisant la sécurité des données basée sur les rôles de Cognos. Nos cas de test exécuteront chacun leur rapport parent et analyseront la sortie en fonction de la configuration de test définie dans leurs assertions sous-jacentes et nous indiqueront si l'un des rapports n'est pas conforme.
L'une des distinctions les plus importantes entre notre environnement de test et ce que vous pourriez avoir dans votre environnement est certainement la taille. Un environnement Cognos typique contient probablement des centaines voire des milliers de rapports et leur exécution simultanée, comme nous l'avons fait dans notre petit échantillon d'environnement, pourrait nuire aux performances de Cognos. Avec MotioCICependant, avec les scripts de test de , vous pouvez programmer vos scénarios de test pour qu'ils s'exécutent par lots plus petits pendant les heures creuses, garantissant ainsi des performances optimales de votre environnement Cognos pendant les heures de trafic intense.
Une bonne pratique de test pendant le développement
Cependant, entre les heures d'exécution planifiées, vous pouvez toujours exécuter manuellement autant de cas de test individuels que vous le souhaitez. Un bon exemple serait que, lors de l'élaboration d'un rapport, vous puissiez exécuter le scénario de test pour vous assurer que vos modifications n'ont créé aucune violation de la loi HIPAA.
Automatisation des cas de test de Cognos
Retour à MotioCI, sur l'arborescence de navigation, nous développons l'un des projets que nous avons créés pour révéler son contenu. Cela devrait révéler un nœud appelé Scripts de test. L'étendre affichera un ensemble de scripts de test qui ont été automatiquement créés lorsque vous avez créé votre projet pour la première fois (Figure 28).
Figure 28 : Des scripts de test peuvent être créés pour n'afficher qu'un nombre limité de cas de test correspondant à certains critères définis par l'utilisateur administrateur.
Par définition, un script de test est un composant d'un projet qui sélectionne des cas de test appartenant à un projet en fonction de critères spécifiés. Vous pouvez planifier des scripts de test ou les exécuter manuellement. Lorsque vous exécutez un script de test, MotioCI exécute tous les cas de test qui adhèrent aux critères du script.
Dans notre cas, nous aimerions définir tous les cas de test sur un calendrier. Pour cela, nous cliquons sur le Tous script de test dans l'arborescence de navigation, puis cliquez sur le Paramètres de script de test onglet situé au milieu de l'écran (Figure 29).
Figure 29 : L'onglet « Paramètres du script de test » vous permet d'ajouter un calendrier pour tous les cas de test.
Ensuite, nous sélectionnons le Ajouter un horaire option. Ici, nous pouvons maintenant définir un calendrier pour notre script de test. Je vais aller de l'avant et faire exécuter nos cas de test tous les jours du lundi au vendredi à 3h00 (Figure 30).
Figure 30 : En plus du programme quotidien et hebdomadaire, vous pouvez également définir une fréquence de minutes sur un programme.
C'est ça! Nous pouvons désormais consulter notre boîte de réception tous les matins pour savoir si l'un de nos rapports n'est plus conforme. Nous pouvons également voir tous les rapports ayant échoué en cliquant simplement sur le Modifié ou échoué script de test et tous les cas de test échoués nous seront présentés sous le Cas de test panneau (Figure 31).
Figure 31 : Le script de test « Modifié ou ayant échoué » inclus montrant le cas de test unique qui a échoué lors de la dernière exécution par lots de cas de test.
Conclusion
Le non-respect de la HIPPA, du RGPD et d'autres réglementations fédérales concernant les informations sensibles et la confidentialité peut être assez coûteux, environ 1.5 million de dollars par cas trouvé en violation, en fait.
En mettant en œuvre une stratégie de test automatisé pour gérer les tests de conformité, vous aurez cette couche de sécurité supplémentaire ainsi que la tranquillité d'esprit que vous respectez les lois. Au-delà des obligations de confidentialité des données, les tests automatisés peuvent profiter à tous les types d'industries et à toutes sortes d'exigences de test que votre organisation souhaite mettre en place.
Comment pouvons-nous vous aider?
Si vous souhaitez regarder le webinaire sur ce sujet de blog, accédez-y ici. Ou, CONTACTEZ-NOUS pour discuter plus en détail de vos questions sur les tests Cognos.
