Resulta que en el estudio hecho por Elizabeth Hendrickson sobre trabajos de QA, salió a colación el tema. Dicho estudio, intitulado "¿Tienen que programar los testers? ("Do Testers Have to Write Code"), lleva dos años realizándose y es resultado de examinar vacantes de testing en Estados Unidos. La abrumadora conclusión es que el 80% ( y 85% este año) de los empleos requiere alguna habilidad de programación. Queda pendiente un estudio similar para México, pero me aventuro a pronosticar que ni siquiera el 50% de los trabajos de testing requiere programación.
Finalmente, el artículo hace mención de la plática del Beto. Vestido de calaca, afirma que .el reto más grande no es desarrollar la aplicación correctamente, sino la aplicación correcta. Así que lanzan una versión mínima del producto para obtener retro de usuarios finales y clientes de manera rápida. Otro googlero, James Whittaker, en su plática llamada "Todo ese testing es estorboso para un trabajo de calidad (All That Testing is Getting in the Way of Quality)". Jaime explica, al igual que Beto, que Google utiliza a sus usuarios para hacer la mayoría de sus pruebas exploratorias, ya que "(Los) Usuarios juegan mejor el rol de usuarios que los testers, por definición."
Según Joel Spolsky, entre las cinco malas razones para no tener testers, destacan la ii)Mi software está en internet ( y puedo arreglar los bugs en un segundo) y iii) Mis usuarios harán las pruebas por mi. En realidad, google si tiene Ingenieros de Prueba, quienes pasan entre el 20 y 80% del tiempo escribiendo código, según Jaime. Probablemente son las pruebas de caja negra como las conocemos están moribundas. Ergo, El testing está vivito y coleando (pero no tanto).
Por el estudio mencionado arriba, los requerimientos de empleo parecen indicar que, por lo pronto, la mayoría de los testers escriben algo de código. De nuevo, estamos hablando de Estados Unidos, pero, al final del día, ¿No hacemos mucho outsourcing de esas pruebas aquí en México? Tengo la impresión de que el testing en México está en pañales, por experiencias previas con empresas mexicanas, pero eso es tema de un estudio más extenso.
AR - Probablemente el testing como lo conocemos esté moribundo para aplicaciones masivas como facebook, gmail o twitter, donde millones de usuarios acceden a versiones crecientes de una aplicación.
ReplyDeleteSin embargo, para aplicaciones cerradas como aquellas utilizadas por bancos, instituciones gubernamentales y así, los requerimientos de confidencialidad son la clave para seguir utilizando los métodos tradicionales de testing de caja negra.
This comment has been removed by the author.
ReplyDeleteON - ON - El testing funcional se enfoca en las capacidades y beneficios de un producto al usuario final. En contextos como los que describe Alberto Savoia, un tester de caja negra no puede sustituir fácilmente a un usuario real.
ReplyDeleteHay contextos, sin embargo, donde el usuario final no puede validar el producto por falta de tiempo. Es vital entonces que el tester desarrolle conocimiento más profundo del dominio de la aplicación para probar que el producto no satisfacerá las necesidades del cliente.
El testing parafuncional, enfocado a otros aspectos del producto como seguridad, usabilidad, accesabilidad, interoperabilidad, desempeño, estrés, etc., no es algo que los usuarios finales y aún los clientes puedan entender y realizar tan trivialmente. Para probar estos atributos efectivamente, con frecuencia se requiere colaboración de testers con otro staff de índole ténico, como programadores.
Hagamos que la industria el tester en México no esté en pañales!! Yo 100% disponible =)
ReplyDelete