Imaginemos que tenemos un cultivo de girasoles donde según un análisis encontramos una cantidad diversa de insectos (pulgones, mariquitas, larvas etc.). Dicha cantidad de insectos nos indica que es importante determinar que se debe hacer con ellos, ya que está afectando la producción de aceite de girasol; constantes plantas en estado deplorable evidencian que todos estos “bichos” deben eliminarse de nuestro cultivo para mejorar este ritmo de producción.
En el transcurso se decide que se debe utilizar un insecticida que elimina todo tipo de insectos. Se demuestra la efectividad probando en cada especie, para luego empezar con la desinfección total. Al cabo de un mes el cultivo está peor, completamente “enfermo” y no hay posibilidad de salvar al menos la mitad de la cosecha. A pesar de aplicar todo el insecticida a todos los bichos que afectaban la cosecha, esta no ha mejorado.

En un análisis, sobre cada tipo de depredador de nuestro cultivo encontramos que los insectos conocidos como “mariquitas” impedían la proliferación de larvas, pulgones, cochinillas, ácaros, piojos, polillas, araña roja, mosca blanca, ya que siempre han sido depredadores naturales de estos últimos y que al identificarlos como algo dañino para nuestro cultivo eliminándolos era un error, porque hay especies de insectos benéficos a la salud de nuestro cultivo.
Este ejemplo muestra como se puede pasar por alto un falso positivo, un bug “bicho” en el sistema que en realidad puede ser incluso vital para el completo funcionamiento un sistema de información que si prescindimos de él podría traernos cantidad de inconvenientes que pueden tener un costo muy alto y más cuando tienden a ser frecuentes.
¿Cómo evito un falso positivo?

Lo primero que debemos hacer es aprender a identificarlos, hay que asegurarnos que los test que apliquemos prueben correctamente lo que tengan que probar.
Por ejemplo si en nuestras pruebas, no dejamos definido que un comportamiento esperado (Digamos que un campo “temperatura bajo cero” acepte números negativos únicamente), pero nuestros datos de prueba no se tuvieron en cuenta para analizar únicamente ese rango inferior a cero entonces, al probar, no funciona el campo con números positivos. Habría un desgaste de trabajo posiblemente para hallar el error que al final pudo haberse solucionado tomando en cuenta que el test debía aplicarse al contexto del requerimiento y el desarrollo en general sin sesgarse (ver La “Paradoja del pesticida”).
Un falso negativo es un suceso contrario, aquí el bug si existe, pero la prueba falla y deja “pasar en limpio” un error en el sistema que llegaría a causar estragos en el momento menos esperado; ya sería que el insecticida no le hizo cosquillas ninguna de las especies de “bichos” en el cultivo de girasoles.
Muy seguramente te toparás con falsos positivos y negativos mi querido tester, pero ¡No te alarmes más de la cuenta! les sucede incluso a los analistas más experimentados. Aunque no debemos subestimar que esto puede afectar la calidad del producto y ser uno de los problemas más grandes a los que nos hemos enfrentado, lo más esencial es diseñar la pruebas lo más fiel posible al contexto. Un dato muy importante que debemos tener en cuenta es que si el entorno en el que probamos es inestable o la base de datos tiene datos corruptos muy seguramente encontraremos inconvenientes de este estilo.
Un caso de prueba, un sin fín de combinaciones

Los casos de pruebas en issues muy complejos, nos traerán casos de pruebas derivados en muchas combinaciones posibles, donde seguramente en un punto puede encontrarse algo, pero desde mi humilde opinión es necesario comprender los casos de pruebas más importantes; tenerlos muy bien analizados, detallados y en combinación de un buen orden en nuestro marco de trabajo, permitirá que podamos tener una cobertura de pruebas óptima.
¿Te has topado con falsos positivos y negativos en tus pruebas, cómo manejarías una situación similar?
Déjanos en los comentarios tus opiniones acerca de este tema.