Podemos implantar un sistema de la calidad, partiendo de documentos de requerimientos y/o de casos de uso, podemos escribir los planes de pruebas, hacer el diseño y escribir al detalle todos los casos de prueba, podemos ejecutarlos en paralelo al desarrollo e ir manteniéndolos con los cambios.

Con todo eso puede valer para tener un producto de calidad, pero ¿qué pasa si añadimos un ingrediente más a la receta: el análisis y gestión de riesgos?

La actividad de la gestión de riesgos no es un trámite o formalismo a cumplimentar para superar una certificación: es algo útil. La gestión de riesgos cierra el círculo, vinculando requerimientos, riesgos y casos de prueba que controlan la mitigación de estos riesgos.

¿Qué aporta este ingrediente?

En primer lugar implica la revisión exhaustiva de los requerimientos (con la consecuente detección de incoherencias, lagunas o indefiniciones).

También nos obliga a pensar y definir el uso previsto de la aplicación, determinando exactamente el entorno de uso y los potenciales afectados en caso de fallo (operadores, clientes/pacientes, medio ambiente, empresa, etc.), así como el nivel de criticidad de la aplicación.

Tras el análisis tenemos identificados, evaluados y categorizados los riesgos. Esto nos proporciona una visión clara de cuáles son los módulos o áreas más críticas de la aplicación y de aquellas funcionalidades que implican mayores riesgos. Esto es de vital importancia a la hora de planificar cada una de las fases de verificación a lo largo del ciclo de vida de desarrollo del proyecto. Nos ayuda a priorizar nuestros casos de prueba, sobretodo en aquellas fases finales en las que los plazos se acortan, el tiempo apremia y hay que asumir ciertos riesgos con el máximo de cobertura.

Cuando decidimos atacar los riesgos que más impacto pueden tener, definimos mitigaciones para cada uno de ellos, teniendo en cuenta el balance entre el coste de la implementación de la mitigación, el beneficio que aporta esa funcionalidad y el daño o impacto real del error en caso de producirse.
Los riesgos se tienen que mitigar tanto como sea posible, dentro de lo razonablemente práctico (‘As Low As Reasonably Practicable-‘ALARP principle’).

Las mitigaciones previenen errores que podríamos haber pasado por alto en nuestros casos de prueba. Al definir nuevos casos de prueba que verifican que las mitigaciones se han implementado como se esperaba, estamos evitando que esos errores aparezcan una vez la aplicación esté en su uso final. Tenemos así enlazados los requerimientos, con los riesgos que pueden entrañar y con las pruebas que verifican las mitigaciones.

Cada vez que se introduce una petición de cambio en los requerimientos o aparece un error en la aplicación, podemos evaluar y categorizar el riesgo que implica, desde esta perspectiva, teniendo así más argumentos para decidir sobre su implementación o corrección. Y así durante toda la vida del proyecto.

Interesante presentación sobre métodos y buenas prácticas sobre testing. En el link que adjunto ¨slideshare.net¨, hay muchísimas presentaciones sobre el mundo de la calidad que pueden ser de vuestro interés, yo os recomiento ¨Efective Methods of Software Testing¨.

En los últimos meses he publicado algunos artículos sobre Scrum, sus beneficios y buenas prácticas, pero “no es oro todo lo que reluce”. Scrum es una metodología ágil implantada exitosamente durante años en grandes empresas…pero esto no quiere decir que la podamos implantar en cualquier entorno. Antes de su implementación deben de analizarse bien la situación en la que se encuentra nuestra empresa mediante un análisis de riesgos.

De la misma manera que hay muchas personas que creen en los beneficios de Scrum, hay otras que no acaban de ver estos beneficios con tanta claridad. Os recomiendo que leáis este interesante punto de vista obtenido de SoftwareArquitecto.

En los últimos meses he estado leyendo bastante sobre Scrum, el proceso, su implementación, como introducir calidad en el proceso…y por supuesto, he buscado herramientas que permitan gestionar un proceso ágil como Scrum de principio a fin.

Una de las herramientas que más me ha gustado ha sido VersionOne. Es una aplicación ASP.NET gratuita para equipos de hasta cinco personas. Fácil de instalar y de usar, es bastante intuitiva. La propia web de la aplicación incluye completos tutoriales sobre la administración e instalación.

En la parte superior derecha de la web de VersionOne está el enlace a “Customer Support”, allí podreis encontrar el “Getting Started”, “Planning”, “Reporting” y “Tracking”. Son muy interesantes, aprendereis a usar mejor la aplicación.

También hay un foro, donde podreis encontrar respuestas a todos vuestras preguntas. Espero que esta aplicación os sea de ayuda. Para instalar la versión de prueba necesitareis SQL Server.

Referencias

+ VersionOne

Aunque Scrum es una metodología muy simple de entender, al menos sus conceptos básicos (la implementación ya es otra cosa), no se puede aprender en cinco minutos. Eso si, “Softhouse” nos ofrece un visión global de en que consiste Scrum.

Scrum in five minutes consta de 16 páginas que nos explica el “Work Flow” de scrum, piezas claves y cada uno de los miembros del equipo scrum.

MoProSoft es un modelo de procesos para la industria de software en Mexico. Desarrollado por iniciativa de la Secretaria de Economia y con el apoyo de empresarios y academicos mexicanos. Fomenta la estandarizacion a traves de buenas practica en al gestion y desarrollo de software.

Referencia:
Podeis encontrar mas informacion sobre este modelo en:

http://www.enterate.unam.mx/Articulos/2006/marzo/moprosoft.htm

James Bach es uno de los Gurus sobre Rapid Testing, realiza multiples seminarios y conferencias alrededor del mundo (junto con Michael Bolton) sobre este tema. Os recomiendo la asistencia a alguno de estos seminarios si teneis la oportunidad, sino, hay un libro introductorio a esta materia que es de muy facil lectura que se titula “Introducction to Rapid Software Testing” escrito por Chris Brown, Gary Cobb, Robert Culbertson en el 2002.

Los test dinámicos los usaremos para realizar un gran variedad de pruebas, desde test funcionales, de rendimiento, stress…son muy importantes, ya que si la planificación, diseño, desarrollo y ejecución de los test dinámicos no se hace correctamente, el proceso de testing será ineficiente. Los test dinamicos no sólo son ejecutados por el equipo de testing, debería de ser también parte de los test unitarios y de integración del equipo de desarrollo.

Referencias
+ “Rapid Testing”, By Robert Culbertson, Chris Brown, Gary Cobb. Published by Prentice Hall. ISBN-10: 0-13-091294-8; ISBN-13

Recomiendo este Google Tech Talks presentado por Elisabeth Hendrickson sobre Agile testing. Cada vez son más los equipos de desarrollo que adoptan tecnicas “Agiles”. ¿Que es el testing ágil? en esta presentación Elisabeth Hendrickson comparte sus experiencias en como equipos de pruebas pueden ser ágiles.

Proporcionará una descripción de cómo las prácticas ágiles diferencian a las tradicionales y discute lo que significan esas diferencias para los equipos de testing.

+ Agile Testing Video