Mucha gente cree que las pruebas de software consisten en encontrar errores. A veces les digo a los probadores: “no trates de encontrar el mayor número de fallos, trata de pasar por alto el menor número posible “, y no me entienden: ¿qué diferencia hay?
Y hay una gran diferencia. En este artículo quiero contarte qué es y qué herramientas hay que utilizar para realizar pruebas realmente útiles. Además, por qué es importante contratar servicios de empresa de quality assurance.
Error 1: Confusión con la Búsqueda de Errores
Estoy probando el producto. Mi trabajo consiste en conseguir el mayor número posible de errores. ¡Esto tiene sentido! Para un probador siempre es un placer recibir bugs, es un resultado visible y medible de su trabajo, y cuantos más sean, más me aprecian como probador.
¿Qué áreas voy a probar en este caso? En primer lugar, los más inestables. Suelen ser inestables porque son menos prioritarios, pero eso no importa, el número de errores es mucho más importante.
¿Qué pasa si me encuentro con un error difícil de sobrellevar? El tiempo de investigación es muy importante. ¿Por qué debería molestarme en ello, si puedo realizar 3 correcciones menos convencionales en el mismo tiempo?
¿Qué pruebas debo realizar primero? Por supuesto, los menos convencionales.
Te contaré un secreto: a veces, en las entrevistas de trabajo, los probadores, en respuesta a la petición de «probar una calculadora«, hacen una lista de pruebas interesantes y útiles, pero entre las treinta primeras no hay ninguna prueba para «comprobar la suma» y otras operaciones básicas.
Eso es exactamente lo que parece la búsqueda de errores, que no tiene nada que ver con las pruebas.
Error 2: No Definir una Prueba o Testing
Estoy probando el producto. Mi tarea consiste en omitir el menor número posible de errores, que son prioritarios para el usuario. Cuantos menos fallos se pasen por alto, menor será la insatisfacción del cliente, y mayor será la valoración de la eficacia de mi trabajo.
¿Qué áreas voy a probar en este caso? Naturalmente, empezaré por las áreas más prioritarias para el usuario. Aunque sean estables y tengan éxito, seguiré probando los principales escenarios de usuario para que no se me escape ningún problema grave en ningún caso.
¿Qué pasa si tengo dificultades? Por ejemplo, un defecto difícil de reproducir, o un malentendido del proceso de negocio del usuario, o una falta de requisitos… Si se trata de una característica importante, averiguaré «qué es lo que falla«, «cómo hacerlo bien«. Al final puede que me lleve mucho tiempo averiguar el defecto y en términos de error/tiempo el resultado de las pruebas efectivas no será muy alto, pero obtendré un conocimiento más profundo sobre el producto, la arquitectura, los usuarios.
¿Qué pruebas realizaré primero? Por supuesto, los más estándar. Ejecutar el escenario más básico en las condiciones más básicas para asegurarse de que la funcionalidad más importante funciona. Y sólo después de eso pasaré a escenarios menos estándar.
Error 3: Realizar un Testing Ineficaz
Para que las pruebas sean eficaces y útiles a largo plazo, hay que seguir unas reglas sencillas y utilizar herramientas de prueba clave:
- Analizar el producto y documentar las pruebas
Al hacer clic en los botones se pueden producir muchos errores, pero no se puede saber qué se ha probado. La única solución es documentar las pruebas. Los casos de prueba detallados que deprimen a los probadores y requieren mucho tiempo rara vez son necesarios. Pero las listas de comprobación con una lista de «lo que hay que comprobar» son necesarias.
- Evaluación de las pruebas
Para no ser gatitos ciegos, hay que evaluar la eficacia de las pruebas. Analizar los fallos no detectados y los motivos por los que se han omitido. Cobertura de la funcionalidad y el código mediante pruebas. Nivel de satisfacción de los usuarios, a través de cuestionarios y recogida de opiniones. La calidad de la corrección de errores por parte de los desarrolladores que preguntan.
SIEMPRE hay algo que mejorar, y la ausencia de un proceso de mejora continua es un atolladero inevitable.
- Discutir los objetivos de las pruebas con el equipo
Mucha gente cree que las pruebas tienen unos objetivos míticos. Y que siempre son los mismos.
¿Cómo no van a estarlo?
Cada proyecto, empresa y equipo tiene sus propios objetivos. ¿Todos los entienden de la misma manera? ¿Los has expresado en voz alta?
Para que sea de máxima utilidad, es necesario conocer bien cuál es ese uso. Y no te sorprendas si la opinión de los PM y los desarrolladores no coincide con la tuya. No hay que hacerles cambiar de opinión, sino ajustarse a los objetivos actuales del proyecto.
- Comprender a los usuarios y sus procesos empresariales
Es un misterio para mí cómo es posible, pero es un hecho: los probadores suelen probar un producto sin saber nada del usuario.
- ¿Cómo se utiliza el producto?
- ¿Por qué es necesario, qué problemas resuelve?
- ¿Cuál es la cualificación media de los usuarios?
- ¿En qué tipo de entorno trabajan los usuarios? ¿En qué entornos y con qué equipos?
No especules sobre la «media del sector». Los probadores deben conocer realmente a sus usuarios. A menudo no reciben esta información de los analistas. ¡Recapacita! No se puede probar un producto de forma adecuada sin conocer a su usuario.
¿Y si todo este proceso pudiéramos automatizarlo?
Error 4: No Contratar un Servicio de Testing de Software
El control de calidad es algo en lo que muchas empresas no piensan, pero comprobar la calidad de tu sitio web o aplicación es una excelente manera de garantizar que todos tus recursos en línea están actualizados y funcionan correctamente.
Los servicios de pruebas de software pueden ser caros, pero ¿pueden merecer la pena? Hemos buscado en nuestros archivos para encontrar la respuesta, y esto es lo que hemos encontrado: QAwerk es el servicio utilizado por algunas de las mayores empresas del mundo, que están dispuestas a pagar por un servicio de pruebas de este tipo.
Los servicios garantizan que los fallos, los errores y las vulnerabilidades no lleguen a sus usuarios finales y que tu software se pruebe constantemente y se actualice a la última versión. Así que, para simplificar las cosas, he aquí algunas de las ventajas de utilizar un servicio de Testing:
- Control de calidad
- Ahorro de coste
- Evita grandes pérdidas
- Ahorra tiempo
- Flexibilidad en diferentes tipos de testing
- Pruebas manuales y automáticas
- Es rápido
Conclusiones
Aprende a descubrir lo que está mal, lo que no les gusta a otros miembros del equipo de desarrollo. Asegúrate de investigar los fallos que se te escapan y haz todo lo posible para que no se te vuelvan a escapar. No persigas los bugs – tu mantra debe ser «felicidad del usuario«, «producto de calidad» y «proyecto exitoso«, no «conseguir el mayor número de bugs posible» – MUY a menudo estos 2 objetivos están demasiado alejados.
Por otro lado, es mejor prevenir que curar. Es mejor que tu software sea probado por un servicio de pruebas independiente que confiar en tus desarrolladores, que podrían no estar a la altura. La contratación de un servicio de pruebas externo tiene muchas ventajas, como la posibilidad de contratar a los mejores para el trabajo. Si quieres evitar un mal rendimiento o defectos en tu software, lo mejor es contratar un servicio de pruebas para que lo haga por ti.
