Producto

Evolución y desafíos de las pruebas de software

Gustavo Almeida
Gustavo Almeida September 11, 2020
Evolución y desafíos de las pruebas de software

Hace algunos años las funciones del tester o analista de pruebas se limitaba a la documentación, los informes y las pruebas manuales. Mantenía proximidad con el analista de requisitos o gerente de proyectos y, a partir de los requisitos del sistema, comenzaba la tarea de transformar los casos de uso del sistema en casos de prueba. Estos se compilaban en un documento que se utilizaba como base para acompañar la ejecución de las pruebas, como una gran lista de verificación que se debía validar en cada versión del sistema. 

Ese compilado se conoce como plan de pruebas; además de contener todo el paso a paso, tenía otra información importante para realizar pruebas tales como: alcance, configuración de ambiente, datos para pruebas, funciones y responsabilidades de las personas implicadas, fechas de ejecución, ventanas de mantenimiento, diccionario de datos, métricas y una infinidad de información que eran la base de esa etapa tan fundamental en el ciclo de vida de un software

Ejemplo de un Caso de Prueba:

Dependiendo de la complejidad del sistema, el número de casos de prueba podía llegar a cientos fácilmente. A menudo, esa documentación se mantenía en archivos del paquete Office Word (.doc) o Excel (.xls), lo que complicaba su mantenimiento. 

Un simple cambio en el nombre del botón implicaba alteraciones en docenas de páginas de ese documento. Entonces, imagine lo que sucedía cuando se modificaba una regla más compleja, algún prerrequisito.

La documentación también funcionaba como entregas definidas en las actas de reunión y auditorías internas, este enfoque de un documento más rígido fue posible gracias al modelo de desarrollo Cascada que predominaba en las empresas. El modelo seguía fases en secuencia o, como su nombre lo indica, en forma de cascada.

Representación del modelo Cascada:

En algún momento de ese periodo, comenzaron a surgir las primeras herramientas exclusivas para la automatización de pruebas y otras que permitían más flexibilidad en el registro y en el mantenimiento de los planes de pruebas y registros de bugs. Algunas de estas herramientas fueron creadas por empresas como Microsoft e IBM; por ejemplo, IBM Rational.

De forma paralela, las metodologías de desarrollo de software evolucionaron de manera más ágil, menos rígida, con muchas iteraciones y entregas, así como sujetas a cambios de requisitos constantes. En una búsqueda rápida en Internet se pueden ver miles de blogs, artículos y libros que hablan sobre Agile, Lean, SCRUM, Kanban, entre otros. También surgieron otras metodologías que permiten que las pruebas se realicen en una etapa previa al código y que se centran en el comportamiento y/o el dominio de software como: DDD, TDD, BDD

Los programadores crearon sus pruebas, los equipos dieron los primeros pasos en las metodologías ágiles y los profesionales de pruebas de software comenzaron a desarrollar, buscando nuevas formas de automatizar las pruebas que se repetían en cada iteración. Es decir, fue evidente que había una convergencia de esfuerzos de todo el equipo para entregar la más alta calidad embebida en los productos, lo que se aplica en las empresas hasta hoy, inclusive en VTEX.

Complejidad y aumento exponencial de los sistemas

Hubo un auge en desarrollo web, con sistemas SaaS escalables. Luego, entramos en la era mobile-first; por eso, el alcance de las pruebas no ha dejado de aumentar. Llegamos a un punto en que tenemos diferentes navegadores web, cada uno con sus propias particularidades, y dos sistemas operativos principales para dispositivos móviles. Además, hay una infinidad de dispositivos con diferentes tamaños y resoluciones de pantalla.

Para seguir esos cambios, surgieron los servicios de pruebas cross-browser y cross-device que ayudan a impulsar las pruebas automatizadas, proporcionando más velocidad y flexibilidad en los scripts. Estos servicios tienen en común el suministro de una infraestructura en la nube y la facilidad de paralelizar las ejecuciones de las pruebas.

No solo había una preocupación constante sobre los diferentes navegadores y tamaños de pantalla, sino también sobre la validación entre diferentes versiones del mismo navegador y/o sistema operativo. Por ejemplo, una página web puede funcionar a la perfección en una versión X del navegador, pero puede presentar errores en una versión Y. El sistema debería soportar la versión Y por cuestiones contractuales, de relación con el cliente u otras, incluso si el propio fabricante ya no brinda más asistencia técnica para esa versión.

Además de eso, aumentaron las pruebas centradas en los requisitos no funcionales. Por ejemplo, tenemos aplicaciones de transmisión de video que continúan funcionando incluso con una señal baja de la antena de telefonía, sistemas que utilizan recursos internos de los dispositivos como un acelerómetro, y una multitud de pequeños detalles que pueden aumentar aún más el alcance de las pruebas. 

En resumen, se observa que la complejidad, las dimensiones y los desafíos de las pruebas de software aumentaron a una velocidad exorbitante y continúan haciéndolo.

Pero ¿qué sucede con el profesional del área?

Toda la transformación también impactó en el perfil del profesional de pruebas de software. Ahora, este profesional está más capacitado para escribir código, utilizar herramientas de DevOps y sistemas de integración continua, por ejemplo.

Se puede observar fácilmente esa transformación a través de la nomenclatura que recibió a lo largo de los años. Hoy, tenemos numerosos términos para identificar un perfil que, a pesar de tener algunas características distintas en sus funciones, en el fondo es un perfil que comparte el sentimiento de propietario del producto y que se centra en la calidad. Podemos enumerar varios: tester de software, analista de pruebas, analista de calidad, QA analyst, gerente de pruebas, agile tester, analista automatizador de pruebas, automatizador de pruebas, ingeniero de pruebas, entre otros.

En VTEX, el perfil que mejor se adapta a nuestro equipo es SET: Software Engineer in Test. Este perfil adquirió notoriedad a través de las grandes empresas tecnológicas de Silicon Valley, y básicamente corresponde a un ingeniero de software con experiencia en pruebas y con énfasis en el desarrollo de sistemas de automatización, frameworks y sistemas destinados a probar softwares en general. 

Incluso, tenemos una oferta de trabajo para SET. Haga clic aquí para verla.

El futuro ha llegado

Estamos rodeados de datos y están surgiendo cada vez más aplicaciones orientadas a ellos. Este tipo de aplicación dificulta el uso de las técnicas de pruebas tradicionales, como la Partición de Equivalencia o el Análisis de Valor Límite, porque las respuestas no son necesariamente binarias.

Como el caso de las aplicaciones de Inteligencia Artificial, Machine Learning, aplicaciones de reconocimiento de voz, de reconocimiento facial y de imágenes en general, ¿cómo validar que un sistema reconoció correctamente a un gato en la imagen? Sabemos que en estos sistemas hay falsos positivos y una gran cantidad de antecedentes en estadística.

¿Tendremos profesionales cada vez más calificados para la tecnología embebida y hardware? Muchos asistentes virtuales surgirán y con estos muchos desafíos de prueba.

La capacitación en áreas de estadística, como la ciencia de datos, puede ser un camino que recorrer para estos profesionales. Al ritmo en que evoluciona el mundo de las pruebas de software, se espera que el profesional de esta área continúe especializándose. Después de todo, los desafíos y las responsabilidades son cada vez mayores.

¿Quiere construir una carrera que esté preparada para el futuro?
Vea nuestras ofertas de trabajo.

Continúe leyendo: historias relacionadas
Producto

Flywire se asocia con VTEX para ofrecer experiencias de pago integradas a las instituciones de educación superior de América Latina

La integración de Flywire con VTEX proporciona una experiencia de pago simplificada a lo largo de todo el…

Monserrat Contreras
Monserrat Contreras
Historias de Clientes

XIAOMI fideliza a sus clientes de la mano de VTEX

En el ecommerce como en cualquier negocio se busca permanecer. Lograr conquistar al cliente a fin de que…

Valeria Reyes
Valeria Reyes
Producto

Soluciones OOTB, de terceros y personalizadas: cómo elegir la solución adecuada para tus metas comerciales.

Sin duda no es una tarea fácil elegir el conjunto de herramientas y plataformas adecuadas para el funcionamiento…

Guilherme Portela, Paloma Castrioto, Renato Ricardi
Guilherme Portela, Paloma Castrioto, Renato Ricardi
Producto

Empresas de todo el mundo mejoran la rentabilidad con el Seller Portal del marketplace de VTEX

VTEX sabe que el modelo de marketplace es una de las estrategias más importantes para los players del…

Lalo Aguilar
Lalo Aguilar
Producto

Nuevas funcionalidades de marketplace en VTEX: ve más allá del ecommerce tradicional

Por más de 10 años, las funcionalidades de marketplace han sido un pilar de VTEX Commerce Platform.  La…

Lalo Aguilar
Lalo Aguilar
Producto

VTEX y Adyen se asocian para ofrecer un comercio unificado a los retailers online

Ya sea añadiendo nuevos contenidos, impulsando iniciativas de marketing o invirtiendo en la próxima gran tendencia, se puede…

Gabriela Porto
Gabriela Porto
Producto

Por qué VTEX IO es adecuado para las empresas de retail

Las empresas de retail suelen necesitar implementar estrategias avanzadas e interconectadas para tener éxito en el ámbito del…

Allan Centurione
Allan Centurione
Producto

Los mejores aspectos de VTEX IO

Muchos desarrolladores y especialistas en ecommerce se han visto estancados al intentar cambiar aspectos de sus sitios web…

Larícia Mota
Larícia Mota
Estrategia

Headless Commerce: la innovación del comercio electrónico

Hoy en día, los clientes exigen a las empresas tener la mejor experiencia de compras, ya sea en…

Kathy Dyer
Kathy Dyer
See More