Cuando se desarrolla un proyecto de software nunca se debe subestimar el plan de pruebas. Este apartado es crucial, tanto para ofrecer la calidad que espera el cliente bajo los criterios que se acordaron en la definición del proyecto como para ofrecer un software robusto libre de errores. Como desarrolladores tenemos que procurar que nuestro código esté libre de bugs y cumpla los requisitos funcionales.
Cuando definamos un plan de testing o QA es importante recordar algunas de la lecciones que prácticamente todos los desarrolladores que hemos participado en un plan de pruebas hemos aprendido de forma práctica incluyendo algún quebradero de cabeza en su momento.
Un punto clave que también debe tener muy presente es el de hacer pruebas de TDD (Test driven development) para la creación de unit tests; para más información visitar el siguiente enlace http://en.wikipedia.org/wiki/Test-driven_development.
Otro punto muy importante es el manejo de subversión , el cual ayuda a tener todo el código sincronizado; la posibilidad de que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas maquinas fomenta la colaboración. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay motivo para temer por que la calidad se vea afectada, si se hizo un cambio incorrecto, simplemente deshaga el cambio, una muy buena interfaz es la de TortoiseSVN.
A continuación unos puntos claves que todo desarrollador debería tener en cuenta al momento de implementar una aplicación:
- Aunque el proyecto vaya mal en tiempo o en costes, nunca hay que recortar el tiempo de pruebas. Nos tenemos que asegurar siempre que el proyecto que entreguemos esté libre de errores, si recortamos en pruebas y además vamos apurados estaremos cometiendo muchos más errores de los habituales.
- Lo más importante que tenemos que probar son los requisitos funcionales que definen el alcance del proyecto. En definitiva, esto es lo que conforma la parte del negocio que fijamos con el cliente y los usuarios como entregable y tiene que satisface sus necesidades.
- Hay que probar el desempeño de la aplicación sea el esperado por el cliente un punto a medir son las pruebas de carga, es la única forma de que probemos al 100% que toda la parte técnica funciona correctamente.
- También es muy importante antes de lanzar el producto realizar la fase de pruebas de regresión donde se revise que cada componente funcione correctamente (después de haber corregido todos los errores encontrados previamente)
- La gestión de configuraciones y versiones es un apartado fundamental del alcance y la gestión de cambios. No debemos descuidar este apartado ya que nos podrá acarrear problemas a corto/medio plazo.
- Siempre que corrijamos un error debemos volver a testear todo. Es fundamental asegurarnos que no se haya roto nada por otro lado.
- Aunque parezca obvio, nunca hagas pruebas en el entorno de producción. Invierte lo que haga falta en un entorno de pre-producción sólido y lo más parecido posible. Es una inversión que te salvará de muchos apuros y te permitirá asegurar que no habrá diferencias entre las pruebas y cuando se suba definitivamente a producción.
- Es recomendable tener especialistas en testing o un equipo dedicado al QA en tu empresa. Testear no se debe tomar a la ligera ni ser un mero tramite burocrático para declarar la tarea como finalizada. Es fundamental que se haga un trabajo completo probando cada funcionalidad. Si no es posible tener un equipo sólo dedicado a eso, es conveniente que los encargados en ese momento de testear sólo se dediquen a probar y reportar errores.
- Es muy recomendable involucrar a los usuarios claves que han participado en la definición de los requisitos de la aplicación. Mientras se prueba pueden obtenerse un importante feedback de usabilidad. Para lo cual uno debe presentar entregables a los clientes para recibir el Ok y poder seguir avanzando en el desarrollo, es una práctica muy importante que aconseja la metodología ágil.
- Es recomendable tener herramientas que nos aporten a la comunicación de desarrolladores con gente de calidad. Para agilizar la corrección y que no se nos pase ningún bug. Ej. Xplanner, V1, etc. Ya que cuando solo usamos el envió de mails corremos el riesgo de omitir información muy importante para la corrección de errores.
http://www.genbetadev.com/trabajar-como-desarrollador/lecciones-aprendidas-del-testing-de-aplicaciones-software
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.