Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>

BLOG

GDPR - Une leçon de modernisation

GDPR - Une leçon de modernisation Temps de lecture : 3 minutes

Dans mon métier, je rencontre beaucoup de clients qui entament ou en plein milieu de leur transformation digitale, et dont beaucoup tentent de résoudre l'énigme de la Livraison / Déploiement Continu. Depuis 5 ans, la discussion autour du développement logiciel s'est concentrée sur la rapidité et la qualité. La plupart des gens disent que l'automatisation est la clé, tout comme moi - l'automatisation rend les tâches plus rapides, plus fiables et plus répétables.

L'une des nombreuses automatisations avec lesquelles les entreprises sont aux prises est l'automatisation des tests, et cela s'explique par les données de test. Les environnements de test partagés impliquent le partage et l'écrasement des données de test. Une fois l'exécution d'un test exécutée, les données sont «sales» et ne peuvent pas être réutilisées pour les tests suivants sans «actualisation».

Dans moins d'un an, nous devons également nous pencher sur les nouvelles exigences réglementaires sur les données d'essais. Il existe des millions d'articles sur les implications du RGPD, mais je m'en tiendrai à ce qui est requis du point de vue des tests.

Sensible vs insensible

Les noms, adresses, numéros de carte de crédit, numéros de compte, numéros de téléphone, noms de compte, etc. sont tous évidemment sensibles, mais le vrai défi est de trouver les limites des données insensibles qui peuvent rendre toutes les données sensibles. Par exemple, ci-dessous, j'ai anonymisé l'auteur, le compte et l'image, mais la plupart d'entre vous seront en mesure de réidentifier cet enregistrement, en raison d'un «comportement connu».

En d'autres termes, une combinaison de comportement connu et de texte libre avec différents éléments de données individuellement insensibles peut devenir si rare qu'elle n'est plus insensible. C'est-à-dire que les données insensibles peuvent devenir sensibles si la profondeur d'un ensemble de données typique est trop faible.

Vous devez vous poser ces questions:

  • Quelles données sont sensibles?
  • Y a-t-il un comportement, un contenu spécifique ou des éléments de données insensibles qui deviennent sensibles lorsqu'ils sont combinés?

Parfois, même le contenu en texte libre peut être sensible.

Il existe deux manières distinctes de rendre les données sensibles non identifiables; anonymisation et pseudonymisation. Les deux masquent les données basées sur un algorithme de cryptage (clé), mais avec l'anonymisation, vous jetez la clé, donc ce n'est pas réversible.

Une fois que toute cette plomberie de données est terminée, nous devons la synchroniser sur toutes les bases de données, fichiers et autres magasins de données gérés par les applications avec lesquelles nous interagissons, internes ou externes. Le défi de le faire dans toutes les applications internes est déjà assez difficile, mais qu'en est-il des tiers? Dans l'exemple Twitter, supposons que je teste une nouvelle fonctionnalité où les commentaires sur un tweet s'afficheraient également en tant que commentaire sur un compte Facebook connecté. D'une manière ou d'une autre, nous devons synchroniser nos données de test anonymisées pour effectuer les tests de cette fonctionnalité également.

SSS - Synthétiser, simuler et stimuler

Avec des données anonymisées (ou pseudonymisées), il est plus difficile pour nous les humains d'identifier les cas de test par les données, donc les tests manuels seront plus difficiles. Pour les initiatives de livraison continue, en revanche, l'anonymisation des données fonctionne dans votre meilleur intérêt.

Pour que l'automatisation des tests fonctionne, nous avons besoin de données de test appropriées, synchronisées et intactes dans tous les systèmes auxquels on accède pendant l'exécution d'un scénario de test.

Nous avons besoin de données de test pour 3 objectifs principaux:

  1. Pour alimenter nos scripts de test - manuels ou automatisés
  2. Pour alimenter notre SUT - pour que la validation des cas de test soit synchronisée avec (1)
  3. Pour alimenter des simulations / actifs virtuels (stubs / mocks) avec des données de test synchronisées dans des magasins de données où nous n'avons pas le contrôle

Lorsque nous voulons aller plus loin et passer des tests automatisés et que nous voulons pouvoir le faire en continu, nous devons également le faire à plusieurs reprises, de préférence à partir d'un script d'automatisation.

Proactif vs. Réactif

Si nous regardons au-delà du RGPD, je pense que les organisations doivent se pencher davantage sur l'interface et les modèles de données. Ils nous renseignent sur les structures et données valides et invalides par le biais du «contrat» ou de la spécification. Nous devons tester de manière proactive en utilisant ces contrats et spécifications au lieu de tester de manière réactive par rapport aux données. Nous devons penser en termes de prévention des bogues où l'AQ n'est pas un événement ou une phase spécifique, mais plutôt un processus en cours.

Écrit par

Björn Gullberg

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.