X
BLOG

GDPR: una lección de modernización

GDPR: una lección de modernización Tiempo de leer: 3 minutos

En mi profesión, conozco a muchos clientes que están comenzando o en medio de su transformación digital, y muchos de los cuales están tratando de resolver el rompecabezas en torno a la entrega / implementación continua. Durante los últimos 5 años, la discusión sobre el desarrollo de software se ha centrado en la velocidad y la calidad. La mayoría de la gente dice que la automatización es clave, y yo también: la automatización hace que las tareas se ejecuten más rápido, de manera más confiable y más repetible.

Sin embargo, una de las muchas automatizaciones con las que las organizaciones están luchando es la automatización de pruebas, y la razón de esto son los datos de prueba. Los entornos de prueba compartidos significan compartir y sobrescribir datos de prueba. Una vez que se ha ejecutado una prueba, los datos están "sucios" y no se pueden reutilizar para pruebas posteriores sin una "actualización".

En menos de un año, también debemos analizar los nuevos requisitos reglamentarios sobre los datos de prueba. Hay millones de artículos sobre las implicaciones de GDPR, pero me ceñiré a lo que se requiere desde el punto de vista de las pruebas.

Sensible vs insensible

Los nombres, direcciones, números de tarjetas de crédito, números de cuentas, números de teléfono, nombres de cuentas, etc. son obviamente confidenciales, pero el verdadero desafío es encontrar las limitaciones de los datos insensibles que pueden hacer que cualquier dato se vuelva sensible. Por ejemplo, a continuación he anonimizado el autor, la cuenta y la imagen, pero la mayoría de ustedes podrán volver a identificar este registro debido a un "comportamiento conocido".

En otras palabras, una combinación de comportamiento conocido y texto libre con diferentes datos individualmente insensibles puede volverse tan rara que ya no es insensible. Es decir, los datos insensibles pueden volverse sensibles si la profundidad de un conjunto de datos típico es demasiado superficial.

Debes hacerte estas preguntas:

  • ¿Qué datos son sensibles?
  • ¿Hay comportamiento, contenido específico o hay datos insensibles que se vuelven sensibles cuando se combinan?

A veces, incluso el contenido en texto libre puede ser sensible.

Hay dos formas distintas de hacer que los datos confidenciales no sean identificables; anonimización y  seudonimización. Ambos enmascaran los datos basándose en un algoritmo de encriptación (clave), pero con la anonimización, usted desecha la clave, por lo que no es reversible.

Una vez que se realiza toda esta instalación de datos, necesitamos sincronizarlos en todas las bases de datos, archivos y otros almacenes de datos que son administrados por las aplicaciones con las que interactuamos, internas o externas. El desafío de hacer eso en todas las aplicaciones internas es bastante difícil, pero ¿qué pasa con los terceros? En el ejemplo de Twitter, supongamos que estoy probando una nueva función en la que los comentarios de un tweet también aparecerían como un comentario en una cuenta de Facebook conectada. De alguna manera, también necesitamos sincronizar nuestros datos de prueba anónimos para cumplir con las pruebas de esa función.

SSS: sintetizar, simular y estimular

Con datos anonimizados (o seudonimizados), es más difícil para los humanos identificar los casos de prueba por los datos, por lo tanto, las pruebas manuales serán más difíciles. Para las iniciativas de entrega continua, por otro lado, la anonimización de datos funciona en su mejor interés.

Para que la automatización de pruebas funcione, necesitamos datos de prueba adecuados, sincronizados y sin tocar en todos los sistemas a los que se accede durante la ejecución de un caso de prueba.

Necesitamos datos de prueba para 3 propósitos principales:

  1. Para alimentar nuestros scripts de prueba: manual o automatizado
  2. Para alimentar nuestro SUT, de modo que la validación de los casos de prueba se sincronice con (1)
  3. Para alimentar simulaciones / activos virtuales (stubs / simulacros) con datos de prueba sincronizados en almacenes de datos donde no tenemos el control

Cuando queremos dar un paso más y pasar de las pruebas automatizadas y queremos poder hacerlo de forma continua, también tenemos que hacerlo repetidamente, preferiblemente desde un script de automatización.

Proactivo frente a reactivo

Si miramos más allá de GDPR, creo que las organizaciones deben mirar más en la interfaz y los modelos de datos. Nos informan sobre estructuras y datos válidos e inválidos a través del "contrato" o especificación. Necesitamos probar de manera proactiva usando esos contratos y especificaciones en lugar de probar de manera reactiva con los datos. Necesitamos pensar en términos de prevención de errores donde QA no es un evento o una fase específica, sino un proceso continuo.

Escrito por

Bjorn Gullberg

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft