X
BLOG

Eliminando la negatividad de las pruebas negativas

Eliminando la negatividad de las pruebas negativas Tiempo de leer: 4 minutos
Los conceptos erróneos a menudo llevan a los probadores a tener la mala reputación de "romper" el software. Los desarrolladores y las partes interesadas pueden llamar a eso pruebas negativas, pero el resultado es un mejor producto, y todo eso es positivo.

Los probadores son los primeros usuarios de un nuevo software y son esenciales para que sea utilizable. Al final, todos tienen el mismo objetivo de ofrecer el mejor producto posible, por lo que dejar que los evaluadores exploren y descubran nuevos errores siempre es bueno: ¡cuantos más errores se encuentren, mejor! Fomentar las pruebas exploratorias en las etapas iniciales del ciclo de vida del desarrollo de software desplaza las actividades de búsqueda de errores antes, cuando son más fáciles y económicas de corregir.

Por supuesto, muchos de los errores que encuentro no están relacionados con requisitos funcionales. Los problemas de rendimiento son un ejemplo común. En la mayoría de los casos, los requisitos no dicen cuánto tiempo debe tomar algo, pero es fácil para un evaluador saber cuándo algo no está bien. Si me impacienta esperando nuestro software, nuestros clientes también lo harán. ¿Y no preferiría escuchar eso de mí cuando todavía podamos solucionarlo, en lugar de más tarde de nuestros clientes?

¿Qué estamos probando exactamente?

Son las 8:30 a. M. Y nuestro gerente de producto entra en nuestra oficina y pregunta: "¿Dónde está el líder del proyecto?"

"Él acaba de salir", dice el desarrollador principal. "¿Como podemos ayudarte?"

"¿Cuál es el estado de la historia de usuario para migrar la base de datos de MySQL a MariaDB?"

“Nos estamos quedando atrás porque algunos elementos clave de las tablas primarias de MySQL no son fáciles de migrar a MariaDB”, responde el desarrollador principal.

El tono de voz del gerente de producto se vuelve inmediatamente más agudo. “¿Cuánto tiempo atrás? ¿Días, semanas?

Nuestro desarrollador principal responde con sinceridad: "Al menos cuatro días más".

Hay silencio en la habitación. Finalmente, el gerente de producto dice: “¿Puede decirle al líder del proyecto que venga a mi oficina? Necesito hablar con él." Se da la vuelta y se va.

Está claro que el gerente de producto no está contento con el progreso de nuestra historia de usuario, y todos los desarrolladores y evaluadores ahora se sienten estresados.

Durante nuestra reunión de planificación más tarde ese día, el equipo considera todos los caminos posibles: el camino feliz, el camino infeliz y los casos extremos. Después, estoy sentado en mi cubículo probando la historia del usuario, y aunque la mayoría de las tareas aún están en progreso, decido hacer algunas pruebas negativas. Impulsado por la curiosidad, empiezo a navegar hacia áreas no relacionadas con los cambios en la base de datos y encuentro un defecto crítico.

En este punto, el líder del proyecto regresa de la oficina del gerente de producto y no parece feliz. Me acerco al líder del proyecto y le informo que encontré un error crítico en la página de inicio de sesión mientras realizaba pruebas negativas.

"¿Está probando algo más que la historia del usuario?" respondió. “Por favor, no intente cosas divertidas y negativas solo para romper la aplicación. Nos estamos quedando atrás y no creo que un usuario normal se encuentre con ese defecto ".

"Está bien", le digo, "archivaré el error y seguiré adelante".

En privado, sin embargo, me pregunto: ¿Quién o qué es un "usuario normal"?

Pruebas para el mundo real

Todavía existe la idea errónea de que un ingeniero de calidad de software rompe el producto. Los probadores mismos exclamarán: “¿Ves? Rompí el software, ¡se rompe cuando haces clic aquí! "

Por supuesto, en realidad no hicieron eso. El software no se rompe; simplemente hace lo que ha sido diseñado y codificado para hacer, para bien o para mal.

Hablando de diseño, otro mito común es que todos los errores son errores de codificación y contratiempos de programación, cuando de hecho, la mayoría se introducen durante los requisitos y el diseño. Los ingenieros de calidad del software investigan los sistemas, observan lo que hace el sistema y luego descubren e informan dónde y cómo se rompe el software, identificando cuándo fallará el sistema bajo carga o estrés o hurgando como lo haría cualquier usuario.

Entonces es un tester obligación para ir más allá del camino positivo y feliz y revelar lo que no es tan feliz.

La prueba positiva es hacer clic en el lugar correcto en el momento adecuado. Es poco probable que un usuario haga solo eso. Los usuarios hacen clic en lo que quieren, cuando quieren. No podemos automatizar a un usuario para que haga lo mismo todo el tiempo de la misma manera, por lo que no podemos confiar en nuestras pruebas automatizadas para cubrir la interacción humana.

Por eso no me gusta el término prueba negativa, ¡no es negativo!

Prefiero las "pruebas del mundo real". Cada usuario usa el producto de una manera única y no podemos comparar a los usuarios entre sí ni esperar que naveguen por la aplicación utilizando la misma ruta. Los usuarios no siguen el camino feliz. Los usuarios no siguen las instrucciones o, sinceramente, ni siquiera leen la documentación. Los usuarios desafían el producto.

Entonces, como probadores, es crucial para nosotros desafiar el producto también. Debemos variar nuestras pruebas para saber cómo responde el producto. Las pruebas excelentes no se limitan a demostrar que el producto puede producir un resultado esperado; significa aprender lo que hace el producto cuando los usuarios hacen algo que nadie predijo.

Nuestro deber como ingenieros de calidad de software es actuar y pensar como usuarios reales. Necesitamos probar fuera de nuestro plan de prueba y salir del guión. Los desarrolladores y las partes interesadas pueden llamar a eso pruebas negativas, pero el resultado es un mejor producto, y todo eso es positivo. 

Cambiar la conversación

Cualquier software tiene riesgos potenciales de no funcionar como se esperaba, por lo que es crucial validar como mínimo que el software no fallará cuando alguien inicie sesión. No estaba realizando pruebas negativas cuando encontré el error en la página de inicio de sesión; Estaba investigando el software.

Así que depende de mí comunicar esto de manera positiva. Nuestras palabras tienen un gran impacto en cómo los demás perciben y comprenden nuestro trabajo.

Cuando le dije a mi líder de proyecto que había encontrado un error mientras realizaba pruebas negativas, es comprensible que su reacción no fuera agradable. Si en cambio hubiera dicho, "Mientras estaba probando la página de inicio de sesión, descubrí un error crítico", su reacción probablemente habría sido, "Ve y presenta el error, y lo veremos más tarde".

Entonces creo que deberíamos dejar de usar positivo vs negativo terminología. En cambio, hablemos de "descubrimiento" e "investigación". Es menos confuso, más explícito y evita el problema potencial de que los desarrolladores y gerentes digan algo vergonzoso como "Oh, solo estás siendo negativo".

Cambiar mi vocabulario me ha ayudado a mejorar mi comunicación con las partes interesadas y los desarrolladores. Puedo ver un ángulo diferente de la ecuación y he podido hablar con los desarrolladores sin ningún tipo de fricción. Ahora, el equipo considera que mi trabajo mejora positivamente el producto en lugar de intentar romper el software de manera negativa.

Intente cambiar su vocabulario de "positivo" y "negativo" a verbos más descriptivos que expliquen su exploración. El equipo será más receptivo en las conversaciones e incluso podría valorar más tu trabajo.

Automatice las tareas de prueba que requieren mucho tiempo para desarrolladores y evaluadores

Escrito por

Jessica Lavoie

Jessica es ingeniera de control de calidad de software en Parasoft, donde disfruta probar funciones nuevas y preexistentes para satisfacer a los usuarios.

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

Prueba Parasoft