Testing si o testing no

En muchos clientes que estuve trabajando, escuche la siguiente frase “hacemos testing si o no”. Desde mi punto de vista esta claro, “si, hacemos el testing” pero para mi sorpresa escuchaba “NO hacemos el testing”. Los motivos sobraban, entre los que se escuchaba más habitualmente:

  • es una funcionalidad muy sencilla y es imposible que el desarrollador se equivoque, o
  • no hay tiempo para probarlo en testing lo liberamos a producción porque es urgente,
  • no es necesario porque el cambio es menor.

 

Este es el punto en donde nosotros los “testers” tenemos que hacer hincapié. Incorporar tareas de testing en un proyecto, le da un valor agregado.  Detectar los errores en etapas tempranas, es mucho más beneficioso que detectarlo al final. Participación en las reuniones de relevamiento de requerimientos.

Todos estos puntos ayudan a mejoran la calidad de un producto, por eso cada vez que nos encontremos frente a una situación similar.

 

Testing con humor

Inspirado en Cartoon Tester, dejo un par de cartoons de mi propia mano en los cuales se muestra con humor situaciones que más de alguno ya debe haber experimentado :D

Federico

“Consideraciones para testing en dispositivos móviles”

Estimar y planificar un proyecto de testing requiere de información del propio proyecto de desarrollo y de experiencia en proyectos de similares características. Los proyectos que involucran desarrollo para dispositivos móviles tienen características que los diferencian. En el mapa mental que se muestra se puede observar algunas algunas consideraciones que pueden ser de utilidad al momento de llevar adelante un proyecto de estas características.

El Centro de Ensayos de Software participó en la JIAP el día 15 de Agosto de 2013 con el fin de exponer  información adquirida sobre este tipo de proyectos.

Como podemos apreciar , aspectos como la conectividad, el hardware y el software a utilizar, interrupciones, actualizaciones, experiencia de usuario, almacenamiento, comunicación con otras aplicaciones, clientes, tiempos de ejecución, etc. Son puntos relevantes a la hora de planificar un proyecto de testing para dispositivos móviles.

Agradecemos a todas aquellas personas que nos acompañaron en la charla, e invitamos a aquellas que no se hicieron presentes a ver el material aquí

María Elisa Presto

Martín Sedes

¿Cuánto vale el testing?

Hace unos días me pusieron ante una pregunta que es de las más difíciles que me han hecho en una reunión y además me agarró
totalmente desprevenido: ¿Cuál es el valor de los servicios del CES?

Lo primero que hice fue darle el listado de los precios de los diferentes roles, contándole además que en realidad se debía estimar el proyecto, la dificultad de la tarea a realizar y el tipo de testing. Sin embargo, me dijeron que no lo estaba entendiendo: me preguntaba por el valor y no por el costo. Y tenía razón, hay una clara diferencia entre ambos conceptos. Aunque, sin lugar a dudas, existe una estrecha relación entre ambos.

Poniendo las decisiones en perspectiva
Lo primero que hice fue pensar en un ejemplo. Supongamos que estamos ante el desarrollo de un sistema para un cliente importante. Una de las decisiones antes de comenzar el proyecto será el de evaluar el plan de testing de la aplicación y ver qué tipo de testing y que esfuerzo se dedicaría al mismo (estoy dejando fuera de manera deliberada a aquellos que se cuestionan la realización de t

esting en sí, pero tengamos en cuenta que esa gente también existe, por las dudas).

Si este cliente no tuviera exigencias de calidad en el sistema, posiblemente vería el esfuerzo adicional como un costo que no le aporta nada al proyecto. En ese caso el valor del testing es casi nulo; incluso el precio más bajo que pudiéramos darle para la realización de dicha tarea (incluso aquel precio en el cuál como proveedores podamos perder dinero) le parecerá caro. Pero supongamos que el cliente tenga requerimientos de calidad altos, con un negocio dependiente de lo que estamos desarrollando y en el cuál un error pueda representarle una pérdida de plata directa (ya sea por SLAs no cumplidos, lucro cesante por no disponer del sistema, lo que sea…), seguramente vea esos precios como una inversión y por lo tanto pague nuestros precios sin muchas objeciones.

También existen otros factores que puede darle valor a nuestro trabajo, como por ejemplo, cuanto repercuten los errores en la imagen o reputación del cliente.  Allí ponerle un valor es difícil, quizás la mejor pregunta para hacerse es cuál es el valor máximo que el cliente le da a su imagen, a su reputación. Algo mucho más subjetivo que el dinero, pero que en algunos casos, si bien no representa un costo directo, es importante.

Por defecto, la realidad me ha indicado que el testing no es de las actividades que se tienen en cuenta de planificar. Principalmente estoy convencido de que esto sucede porque no sabemos o no somos capaces de transmitir el valor de las actividades que realizamos. Un valor que nos permita hacer el switch y poder hacer el click en aquellas personas que toman las decisiones. Solo así se logrará que las tareas de testing sean vistas como algo que aporta valor en el sentido más estricto de la palabra.

Luego, atado a eso, vendrán los costos asociados a realizar esa tarea y allí se juega el otro tiempo del partido.

Poniendo precio a nuestro trabajo
El valor que tendrá nuestro trabajo para el cliente será el límite superior que nuestro precio podrá alcanzar. Si lo que nosotros marcamos a nuestro trabajo es mayor que el valor de realizar las actividades de testing, ¿Por qué el cliente se sentirá inclinado a cambiar la decisión de invertir en la calidad del producto?

Claro está que también existe algo que se llama mercado, por lo cual tenemos que tener en cuenta, a la hora de poner precio a nuestro trabajo, que el mismo no puede ser puesto basándose exclusivamente en el valor aportado (lamentablemente no somos Henry Ford vendiendo autos en el 1900, donde Ford vendía el auto del color que quisiera el cliente, siempre que fuera negro). Posiblemente allí le hayamos dejado claro el valor, pero encontrará un costo menor al nuestro para poder alcanzarlo.

Sin embargo, por más apropiado que sean nuestros precios a los del mercado, si no logramos aportar valor al desarrollo de software y por ende al producto, difícilmente alguien firme un cheque para realizar testing. Y es allí donde podemos aportar un diferencial: no necesariamente siendo más baratos, sino siendo los que aportemos más valor.

Nuevas formas de desarrollar => ¿nuevas formas de testear?

Desde hace un tiempo, en el mundo de la informática, las aplicaciones que desarrollamos y usamos, son técnicamente  muy distintas a las antiguas de escritorio.  Estas aplicaciones por lo general interaccionan con otras aplicaciones, por ejemplo utilizan repositorios de datos e invocan servicios externos que podrían estar distribuidos.  La pregunta que nos hacemos hoy es, para las aplicaciones de smartphones (teléfonos inteligentes), comúnmente llamadas apps, ¿se requieren nuevas formas de testear?

apps

Casi todos hemos visto videos en los que se prueban celulares sumergiéndolos en agua, soltándolos en caída libre, tirándolos contra algo para probar ciertas propiedades del hardware, tales como la resistencia de la pantalla, etc.

También existen aplicaciones web para comparar 2 modelos de celulares, incluso de diferentes marcas, se puede evaluar características, comparar funcionalidades, tamaños, etc.  Pero si lo que queremos es probar una app nativa en una versión determinada de un sistema operativo x, en principio surge la interrogante  ¿Qué tipos de prueba es conveniente ejecutar?

sistemas_operativos_smartphones

Durante el desarrollo de cualquier software, el testing unitario es fundamental para obtener información de la calidad del producto. Lo ideal es que el desarrollador ejecute pruebas funcionales en el hardware  en el cual  espera que su app se ejecute, con la versión del  software de base correspondiente. En el testing unitario se prueban las funcionalidades sin interaccionar con otros sistemas, luego  se integra con otros módulos, por ejemplo a través de una API que encapsula los elementos de comunicación  (gmaps, gps, etc.).  Estas primeras pruebas son de caja blanca, y pueden automatizarse por el equipo de desarrollo.

Cuando haya un prototipo o una primera versión de la aplicación se comienzan a ejecutar pruebas de caja negra,  para comprobar que las funcionalidades requeridas existen y se comportan según los requerimientos. En este punto se puede ser tan imaginativo y exigente como se quiera/requiera: revisar pantallas, botones,  flujos de navegación, con/sin conexión a internet, agotando la energía (batería), ciclos funcionales que incluyan llamadas telefónicas y mensajes de texto. Hoy en el mercado el horizonte se amplía muchísimo ya que los distintos modelos de celulares  tienen diferentes pantallas (tradicional/táctil), con varios diseños de botones para utilizar desde la aplicación, diferentes sistemas y versiones de los mismos.

En lo que a seguridad se refiere recomendamos a los analistas y desarrolladores aplicar alguna de las propuestas de buenas prácticas existentes (por ejemplo OWASP), logrando así, desde el comienzo del proyecto un producto “defensivo”, por ejemplo definir y aplicar métodos de protección de datos (archivos temporales,  logs, contraseñas, credenciales). Desarrollar teniendo en mente las debilidades más comunes de las aplicaciones y los fundamentos de una programación segura para prevenir posibles ataques.

Luego un equipo diferente del de desarrollo puede diseñar pruebas para intentar penetrar en la aplicación en busca de posibles vulnerabilidades.

SmartPhoneVirus

Cuando consideremos que la aplicación es estable, y que las funcionalidades hacen lo que se espera, podemos pasar a evaluar nuestra app, desde el punto de vista de su performance. Nuevamente recomendamos que el equipo de desarrollo tenga en mente la performance desde el inicio del proyecto, defina los requerimientos de performance y evalúe módulos y su integración (por ejemplo que el tiempo de respuesta no supere los 3 segundos). En este punto es importante diferenciar el tipo de arquitectura, ya que definirá los tipos de prueba a aplicar. En una arquitectura cliente servidor, será tan importante probar el cliente como el servidor (en el caso del servidor se ejecutan las pruebas usuales para aplicaciones web).  A continuación veremos las particularidades de probar el cliente.

El equipo de testing, teniendo en cuenta los requerimientos definidos  evaluará la performance de la aplicación, agregando puntos de monitorización y llevando al límite la utilización de recursos (GPS, 3G, WiFi) y combinando su ejecución con algunas de las acciones frecuentes al usar un celular, por ejemplo girar el dispositivo, llamadas y mensajes entrantes, aplicaciones que corran en background (esto podría mejorar o empeorar la performance).

En conclusión, tecnológicamente las aplicaciones que usamos están teniendo un giro casi radical y el universo de pruebas posibles se hace cada vez mayor. Sin embargo, los tipos de testing que recomendamos ejecutar son básicamente los mismos, comenzando por un testing de caja blanca (automatizadas o no). Continuando con diferentes pruebas de caja negra preferentemente  diseñadas y ejecutadas por un equipo diferente al de desarrollo.

María Elisa Presto

¿Los informáticos necesitamos cábalas para reproducir incidentes?

Ayer casi sin quererlo me encontré rodeada de fanáticos “hinchas” futboleros, al principio todo lo que decían carecía de sentido para mí. Al pasar los minutos, mi actitud hacia lo que escuchaba cambió y comencé a sorprenderme.  Algo que realmente no deja de sorprenderme son las cábalas, la creencia popular supone que existe una fuerza más allá de lo natural relacionada con una o varias acciones que provocan que suceda algo.

En el deporte y en este caso en el fútbol, ocurre que si queremos un resultado igual al anterior debemos repetir exactamente la secuencia de acciones que hicimos antes y durante el partido anterior.  Fue ahí cuando comprendí que estos hinchas no hacen más que intentar generar un contexto igual al anterior para generar un resultado igual al anterior.

Algo similar ocurre cuando probando software encontramos un incidente, para lograr reproducirlo debemos generar un contexto igual para obtener nuevamente el incidente.

Así cuando estamos probando un software debemos prestar atención a todo el ambiente y las acciones que ejecutamos para saber exactamente cómo reproducir una situación. Pero cuidado hinchas y testers de software olvidar tan sólo una de estas acciones puede significar la perdida de la copa Libertadores!

María Elisa Presto