¿Dónde encaja el testing en proyectos de TI con Scrum?

Testing OK

Recordemos que los incrementos solo están finalizados si los desarrollos están acabados, probados y documentados tal y como se ha recogido en la definición de hecho (DoD), y eso implica que sea el propio equipo el que realice el testing y el control de calidad. En el equipo puede haber perfectamente un rol de tester, y de no haberlo, recordemos que se trata de equipos multidisciplinares y que en su conjunto, y si han sido formados, pueden tener perfectamente las habilidades y la independencia de un tester.

Scrum no es un modelo que ha surgido de arriba a abajo: de la teoría a la práctica, sino al revés: ha tomado forma y cuajado desde las prácticas empleadas por algunos equipos como antítesis a los modelos de procesos. Esto tiene sus ventajas y sus inconvenientes: no es un modelo diseñado para cubrir todas las áreas al estilo de una ISO 12207 o un modelo de procesos tipo CMMI o ISO 15504. Por esta razón, no hay un procedimiento (ni debería haberlo) para prescribir cómo hacer testing (dentro del área de SQA). Si existen una serie de patrones de testing que son más o menos cercanos a la Agilidad, mi más ferviente recomendación es la integración continua y las pruebas automatizadas.

Si a pesar de ello se requiriese de un procedimiento de calidad institucionalizado, el que resultaría válido para proyectos con niveles de integridad bajo correspondería al control de calidad considerado de independencia mínima (estándar IEEE 1012). Para proyectos con niveles de integridad elevado puede (debería) resultar aconsejable emplear modelos de mayor independencia. A quien interese puede encontrar un desarrollo en ese sentido en el artículo Scrum y aseguramiento de calidad.