Todo responsable del rea de QA debe en algn momento, mejorar su suite de

Indicadores y ampliar su horizonte de alcance general, y as ir tomando ms

posicin en la organizacin.
A mi modo de ver, algunas de las directrices que debe seguir son las siguientes:
analizar y medir la calidad del software
gestionar el proceso de certificacin de entregables
gestionar los procedimientos para la deteccin temprana de defectos
automatizar el proceso de certificacin de proveedores internos y externos
controlar la productividad y calidad del desarrollo antes de su despliegue en produccin
mejorar el cumplimiento de los requisitos funcionales
elaborar un modelo de calidad para los entregables, estableciendo de esa manera los
patrones necesarios que permitan medir ciertas propiedades:
eficiencia
rendimiento
usabilidad
fiabilidad
mantenibilidad
portabilidad
otros
definir con qu tipo de herramientas se llevar a cabo la gestin de los modelos de calidad
definidos.
seleccionar e implementar las herramientas ms apropiadas para la organizacin.
definir quienes harn uso de las mismas, como ser:
desarrolladores
testers
jefe de proyectos
analistas funcionales
responsables de departamentos
CIOs
adecuar las herramientas corporativas con las de terceros a travs de interfaces que
permitan extraer los datos necesarios para generar las mtricas correspondientes de calidad.
definir el proceso de obtencin de informacin en tiempo real y diferido
analizar la informacin obtenida contra los modelos de calidad para determinar / identificar
tendencias, comparaciones entre proyectos, e incidencias
trabajar bajo modelos de cuadro de comandos (dashboards) en forma colaborativa y a
partir de una matriz de perfiles de usuario
establecer un sistema de informes, notificaciones y alertas, va web y/o dispositivos mviles
gestionar el proceso de anlisis de cumplimiento de cdigo
gestionar el proceso de generacin, ejecucin y anlisis de cobertura de pruebas unitarias
gestionar el proceso de generacin, ejecucin y anlisis de cobertura de pruebas manuales
gestionar el proceso de generacin, ejecucin y anlisis de cobertura de pruebas
automatizadas
Complementando todo lo hasta aqu escrito, tambin se podran considerar los
siguientes indicadores:
1. Definir un plan estratgico de TI
2. Definir la arquitectura de la informacin
3. Determinar la direccin tecnolgica
4. Definir los procesos, organizacin y relaciones de TI
5. Administrar la inversin de TI
6. Comunicar las aspiraciones y direccin de la gerencia
7. Administrar recursos humanos de TI
8. Administrar la calidad
9. Evaluar y administrar los riesgos de TI
10. Administrar proyectos
11. Identificar soluciones automatizadas
12. Adquirir y mantener software
13. Adquirir y mantener infraestructura tecnolgica
14. Administrar cambios
15. Definir y administrar los niveles de servicio
16. Administrar los servicios de terceros
17. Administrar el desempeo y la capacidad
18. Garantizar la continuidad del servicio
19. Garantizar la seguridad de los sistemas
20. Administrar la configuracin
21. Administrar los problemas
22. Administrar los datos
23. Administrar el ambiente fsico
24. Administrar las operaciones
25. Monitorear y evaluar el desempeo de TI
26. Monitorear y evaluar el control interno
27. Garantizar el cumplimiento regulatorio
28. Proporcionar el gobierno de TI
Fuentes: COBIT y CheckQA
Para la siguiente publicacin (Parte 2) explotar los Indicadores Bsicos de TI,
tengamos hasta aqu una primera idea de cmo deberamos conformar nuestro
horizonte de trabajo y as definir hacia donde dirigirnos.


Plantilla del Plan de Pruebas de Software
Imagen de: pmoinformatica.com
En el desarrollo de software, la fase de pruebas es crtica para asegurar que el producto sea
enviado a ambiente de produccin con la calidad esperada por el cliente.

Es por esto que hoy en da es indispensable contar con un Plan de Pruebas de Software para
especificar minuciosamente las funciones a probar, como sern ejecutadas esas pruebas, quienes
sern los responsables y el cronograma para su ejecucin.

El Plan de Pruebas de Software puede aplicarse a todo el Proyecto de Desarrollo de Software, o
puede acotarse a una iteracin o conjunto de casos. Adems, puede definir jerarquas de casos de
prueba a considerar.

Aqu les dejamos una plantilla de Plan de Pruebas de Software, entre sus secciones estn el
Resumen Ejecutivo, Alcance de las Pruebas, Funcionalidades a Probar, Pruebas de Regresin,
Criterios de Aceptacin y Rechazo, Criterios de Suspensin y Reanudacin, Especificaciones de
ambientes de Pruebas, Recursos de Personal y Entrenamiento, Matriz de Responsabilidades,
Cronograma, Riesgos, entre otros aspectos.

PMOInformatica.com, La Oficina de Proyectos de Informtica, presenta la Plantilla para el
Plan de Pruebas de Software:

Secciones de la Plantilla de Plan de Pruebas de Software
Historial de Versiones: El histrico de las versiones del Plan de Pruebas de Software,
indicando quien elabor la versin y la fecha.
Ficha del Proyecto: Informacin sobre el nombre del proyecto, departamento o rea
organizacional, Lder o Gerente del Proyecto, el Patrocinador (Sponsor) y el Gerente o Lder de
Pruebas.
Aprobaciones: Lista de las personas que deben aprobar el Plan de Pruebas de Software,
indicando su nombre, cargo, departamento y espacio para su firma.
Resumen Ejecutivo: Resumen de todo el contenido del plan de Pruebas de Software,
describe cul es su propsito, establece si es un plan maestro o un plan detallado, identifica el
alcance del plan de pruebas en relacin con el plan de Proyecto de Software, restricciones (por
ejemplo de recursos o presupuesto), alcance del esfuerzo de pruebas entre otros aspectos.
Alcance de las Pruebas:
o Elementos de Pruebas: Listado de todos los mdulos, componentes o elementos
que se van a probar. Si es de alto nivel, se listan las reas funcionales (mdulos o procesos que
cubre el Testing), por otro lado, si es de un nivel detallado se listan los programas, unidades o
mdulos.
o Nuevas Funcionalidades a Probar: Es un listado de lo que se va a probar Desde
el Punto de vista del Usuario. No es una descripcin tcnica del software sino sus caractersticas y
funcionalidades. Se incluyen tanto las que son nuevas como las que se estn modificando.
o Pruebas de Regresin: Listado de las funcionalidades no directamente
involucradas en el desarrollo, pero cuyos componentes estn siendo afectados y por ende deben
probarse para asegurar que continan funcionando adecuadamente. Al igual que en el punto
anterior, se describen desde el punto de vista del usuario.
o Funcionalidades a No Probar: Listado de las funcionalidades que NO se van a
probar. Debe incluir informacin de las razones por las cuales no se van a probar y los riesgos que
se estn asumiendo.
o Enfoque de Pruebas (Estrategia): La Estrategia de Pruebas puede definirse
como un documento aparte, o puede ser incluido dentro del Plan de Pruebas segn su extensin.
Aqu pueden definirse los tipos de pruebas a realizar (funcionales, de desempeo, de interfaces,
no funcionales, etc.), requerimientos especiales de las pruebas, configuraciones a probar,
subconjuntos de datos a considerar, nivel de pruebas de regresin, entre otros aspectos.
Criterios de Aceptacin o Rechazo:
o Criterios de Aceptacin o Rechazo: Son los criterios de aceptacin que sern
considerados para dar por completado el Plan de Pruebas de Software, por ejemplo: Completar
100% de pruebas unitarias, cierto porcentaje de casos exitosos, cobertura de todos los
componentes y lneas de cdigo, porcentaje de defectos corregidos, entre otros.
o Criterios de Suspensin: Establece claramente bajo qu condiciones se detienen
un conjunto de casos de pruebas, por ejemplo en caso de existir defectos que impidan la ejecucin
de ms casos de pruebas, cierto porcentaje de casos fallidos, o cualquier otro que se especifique.
o Criterios de Reanudacin: Luego de haber suspendido las pruebas, aqu se
establece bajo qu criterios se reanudaran.
Entregables: Establece que se entregar como parte de la ejecucin del plan, por
ejemplo: Documento de Plan de Pruebas, Casos de Pruebas, Especificacin de Diseo de Casos,
Logs de errores, Reportes de errores (bugs), evidencias de pruebas, reportes emitidos por
herramientas de pruebas y cualquier otro que se establezca.
Recursos:
o Requerimientos de Entornos Hardware: Lista de los requerimientos de
equipos, hardware y red necesarios para completar las actividades del Plan de Pruebas de
Software. Incluye Servidores de Aplicacin, Bases de Datos, Equipos de PC que necesitan los
Testers, Conectividad a la red (incluyendo accesos), entre otros.
o Requerimientos de Entornos Software: Lista de los requerimientos de
software necesarios para completar las actividades de prueba, puede incluir accesos a Sistemas
(en entorno de pruebas) y Bases de Datos, as como instalacin de software en los
Computadores asignados a los Testers.
o Herramientas de Pruebas Requeridas: Especifica las herramientas de software,
metodologas o tcnicas especiales empleadas en las pruebas, por ejemplo Herramientas de
Automatizacin de Pruebas, Software de Gestin de Pruebas, entre otros.
o Personal: Lista del personal necesario para completar las actividades de pruebas,
especificando sus roles, por ejemplo: Un (1) Lder de Pruebas, Cinco (5) Analista de Pruebas
(Testers), Dos (2) especialistas en automatizacin de pruebas, entre otros.
o Entrenamiento: Necesidades de entrenamiento en el Sistema o Aplicacin que se
est desarrollando, as como en las herramientas de prueba a utilizar.
Planificacin y Organizacin:
o Procedimientos para las Pruebas: Especifica los procedimientos o metodologa
de pruebas de software a emplear durante la ejecucin del plan de pruebas de software.
o Matriz de Responsabilidades: Lista cada una de las personas integrantes del
equipo de QA y sus responsabilidades. Se puede hacer uso de una Matriz RACI (Responsable,
Aprobador, Consultado, Informado).
o Cronograma: Debe estar basado en estimaciones de actividades realizadas por
el equipo de prueba. En l se Identifican los hitos relevantes en las pruebas de software, se
establecen las dependencias (actividades predecesoras) y dems aspectos componentes de un
cronograma.
o Premisas: Las premisas relacionadas con las tareas de pruebas de software,
incluyendo limitaciones de tiempo, disponibilidad de recursos que se asumen, uso de una
metodologa de pruebas, uso de una herramienta, entre otros.
o Dependencias y Riesgos: Aqu se listan los riesgos identificados en el proceso
de pruebas de software, por ejemplo, algunas fuentes de riesgos suelen ser:
Dependencias con Desarrollos.
Dependencias con otros proyectos.
Disponibilidad de recursos.
Restricciones de tiempo.
Premisas que resulten no ser ciertas.
o Los riesgos se pueden clasificar en funcin de su probabilidad e impacto,
cada uno debe contemplar un plan de mitigacin para evitar que ocurra o plan de contingencia
cuando el riesgo no puede mitigarse y tiene que aceptarse.
Referencias: Lista de todos los documentos que pueden citarse como apoyo o para
ampliar el contenido del plan de pruebas. Algunos ejemplos de lo que se puede hacer referencia
aqu son:
o Plan de Proyecto.
o Especificaciones de Requerimientos.
o Diseo General.
o Diseo Detallado.
o Procedimientos y estndares de Desarrollo.
o Procedimientos y estndares de Pruebas.
o Metodologas, Procedimientos y estndares corporativos.
Glosario: Definiciones de trminos usados en la documentacin, y general sobre el rea
de pruebas.