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.
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.
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.
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.
La CCX Company, en colaboración con VTEX Commerce Cloud, expresa su gratitud por haber tenido la oportunidad de enriquecer su comprensión sobre las ventajas, tendencias y otros elementos abordados en el presente tema. Este artículo fue elaborado en conjunto y le es presentado por el equipo de VTEX Commerce Cloud.
