Imagina la siguiente situación entre amigas en la que Romina le dice a Andrea: “A ver, pruébate este jean para ver cómo te queda, porque a mí me queda largo y no lo quiero remangar”. Andrea responde: “A mí me queda bien”. “Lo que pasa es que soy más alta que vos”.
Ahora, piensa en esta otra situación entre amigos, Juan le dice a Federico: “Sabes que quise descargarme el juego que me recomendaste, pero cuando intento abrirlo se cierra de una y no puedo ingresar“. Federico responde: “Qué extraño… A mí me funciona impecable, ¡mirá!”
Con seguridad te estarás preguntando qué tendrá que ver esto con las pruebas de compatibilidad, pero…¿Cuántas veces pasaste por situaciones así durante tu vida? Situaciones en donde algo, o alguien, no era para vos, pero sí para otra persona u… otro dispositivo. ¿Cómo que otro dispositivo? Sí, muchas veces el software no funciona como se espera en ciertos tipos de dispositivos o sistemas, y esto se conoce como compatibilidad (incompatibilidad) del software.
En otras palabras, existen ciertas condiciones que no permiten operar de manera adecuada a nuestro software. Entre estas condiciones suelen encontrarse comúnmente la ausencia de drivers, la desactualización de ellos, malas parametrizaciones, problemas de estilo CSS, contenidos superpuestos, etc.
Nuestro trabajo como probadores de software es asegurarnos de que nuestro objeto de prueba sea, entre tantas cosas, compatible en la mayoría de los sistemas/dispositivos en donde será ejecutado.
Aclaración: estoy diciendo “…en la mayoría de los sistemas/dispositivos…” dado que es imposible garantizar el 100% de los escenarios libre de fallas.
Antes de iniciar las pruebas, debemos entender cuál será el contexto en donde se desplegará el software pero, sobre todo, entender muy bien cuál será el perfil del usuario que hará uso del mismo.
Para llevar adelante esta tarea debemos definir con el cliente la matriz de pruebas que queremos testear. ¡No podemos testear todo!
Definir una matriz es una forma de enmarcar nuestro trabajo y además es una manera de garantizar al cliente qué escenarios son los que fueron cubiertos con nuestras pruebas. En ella, deberemos reflejar el contexto donde se desplegará el software y aquí es donde definimos las pruebas de compatibilidad que llevaremos a cabo.
Para seleccionar nuestras pruebas es necesario conocer nuestra aplicación y preguntarnos lo siguiente:
- La aplicación, ¿puede verse afectada por distintas configuraciones de hardware? Por ejemplo: cambios en el procesador, la memoria RAM o la unidad de procesamiento gráfico.
- ¿Es de tipo mobile, web o de escritorio? En caso de que sea de escritorio, ¿operará con qué sistemas operativos? ¿Windows, Mac y/o Unix?
- ¿Tendrá interacciones con otros softwares? Es decir, ¿permitirá enviar e-mails? ¿Agendar en el calendario?, etc.
- En caso de que sea de tipo mobile. ¿Cómo se comportará con distintas conexiones de redes y sus posibles intermitencias en la señal? Por ejemplo: 4G, LTE, 5G.
- ¿Correrá sobre un navegador o sobre más de uno? Ejemplo: Chrome, Edge, Firefox, etc. ¿Y en qué versiones?
- Si es de tipo mobile. ¿Correrá en Android y/o iOS? ¿Y en qué versiones?
Como ven, una correcta planificación de nuestras pruebas implica que nos respondamos todas estas preguntas para entender bien el contexto de nuestra aplicación.
Una vez obtenida dicha información podemos empezar a crear nuestra matriz de compatibilidad de pruebas.
A continuación, les presento un ejemplo de matriz (reducida) para una aplicación mobile hipotética:
¿Cómo se lee esta matriz?
Leer esta matriz es bastante sencillo ya que bastará con armar nuestras condiciones de pruebas leyendo columna por columna y jugando con las combinaciones en caso de que existan. Por ejemplo: si hemos optado por ejecutar pruebas con el dispositivo Samsung Galaxy S21, nuestras pruebas funcionales deberán correrse en las siguientes características del dispositivo:
- Galaxy S21 – Version Android 12 – Red LTE
- Galaxy S21 – Version Android 12 – Red 5G
- Galaxy S21 – Version Android 11 – Red LTE
- Galaxy S21 – Version Android 11 – Red 5G
NOTA: El mayor problema que se enfrenta a la hora de realizar pruebas de tipo mobile es el inmenso abanico de combinaciones que se generan. Es responsabilidad del Analista de pruebas evaluar si se ejecutarán todas/algunas/ninguna de las pruebas para una versión de red y para otra.
Conclusión:
Al igual que en la vida misma, si queremos generar una buena impresión, por lo general, nos preparamos y arreglamos ¿verdad? Con nuestras aplicaciones pasa lo mismo, casi que no tenemos oportunidad de seducir dos veces a nuestros potenciales clientes. Ellos descargan una app y si no tienen la experiencia que buscan dentro de los primeros 30 segundos es casi un hecho que la desinstalarán, y con ellos se irá la oportunidad de crecer como empresa.
Las pruebas de compatibilidad son muy importantes ya que buscan confirmar el correcto desempeño de una aplicación en todas las plataformas. De esta manera, se garantizará que todos los clientes tengan una experiencia positiva, sin importar el entorno que utilicen. Porque al fin y al cabo, un usuario satisfecho es un usuario que vuelve a nosotros y nos recomienda.
0 comentarios