Practical Software Testing (600 700)

Machine Translated by Google
16.9 Aplicaciones Industriales del TMM | 577
2. La atención de la dirección debía centrarse en la prueba del software.

3. Dado que el TMM admite una evaluación del proceso de prueba interno,
podría usarse como una herramienta para mejorar continuamente las pruebas. Las pruebas
mejoradas apoyarían las necesidades y demandas de las empresas en crecimiento.
4. Dado que el TMM admite un procedimiento de evaluación interna, es más
rentable que contratar un equipo de evaluación independiente.
5. El TMM se basa en conceptos similares al CMM, este último de
con la que la gerencia estaba familiarizada. El TMM también tiene áreas superpuestas
con otros modelos de mejora de procesos en los que la organización estaba interesada
en establecer el cumplimiento.
6. Los hallazgos de una evaluación TMM podrían usarse para aprovechar al hombre
soporte de gestión para mejoras en el proceso de prueba.
7. La aplicación del TMM podría renovar los esfuerzos para centrarse en el software
calidad del producto.
Uno de los hallazgos útiles que resultaron de este estudio fue la importancia de
considerar los factores humanos al realizar una evaluación TMM.
[44]. Para determinar con precisión el estado de un proceso de prueba, el
los participantes en la evaluación deben proporcionar información precisa y consistente.
Deben estar motivados para trabajar con el equipo de evaluación.
hacia el objetivo de la mejora del proceso de prueba. Por eso es importante
que los participantes estén capacitados y preparados, y que la evaluación
El proceso debe adaptarse para que encaje bien con las normas culturales de la
organización. Además, también es muy importante que el equipo de evaluación de TMM
obtenga un fuerte apoyo de la gerencia para la evaluación y
los cambios de proceso que pueden seguir. Esto maximiza las posibilidades de
éxito (ver Sección 16.9.3).
Para abordar estos problemas de factores humanos, el investigador de este TMM
estudio ha agregado fases o pasos para aumentar la "fase de preparación" de
el procedimiento de evaluación descrito por Homyen [25]. La nueva inicial
se llama la “fase de propuesta”. Lo sugiere el investigador
que esta fase se aplique a organizaciones nuevas en las evaluaciones de TMM,
y/o aquellos que son conservadores en su enfoque de los cambios en los procesos.
La fase de propuesta incluye actividades como un estudio de la cultura organizacional,
obtener el apoyo de SEPG u otros grupos de mejora de procesos, reclutar voluntarios para
inscribirse en una evaluación informal
(completar el cuestionario TMM), educar al personal y a la alta dirección
El modelo de madurez de las pruebas y la evaluación del proceso de pruebas

578 |
ment en el TMM, y tener una reunión de lanzamiento para los participantes. Durante
En esta fase, la información del cuestionario se cuenta y se informa a
SEPG y/o alta dirección. Los resultados proporcionan una imagen aproximada de
el proceso de prueba, y puede usarse para motivar e iniciar acciones adicionales. Cuando se
completa este paso, se desarrolla una propuesta formal para una evaluación de TMM y se
identifican los posibles patrocinadores y proyectos. En
esta vez, el equipo de TMM debe asegurarse de que haya un número estadísticamente
significativo de participantes para la evaluación. Se desarrolla un plan de compra para up per
management, y se presentan el plan y la propuesta.
a este grupo. El equipo de TMM utiliza el plan de compra y la propuesta para
obtener el compromiso, el apoyo y la financiación de la alta dirección para
la evaluacion. Tener este compromiso por parte de la dirección es fundamental
para que la evaluación del proceso y el esfuerzo de mejora tengan éxito.
En lo que se llama la "fase de preparación orientada al ser humano", el TMM
El investigador aumenta el paso original de "preparación" del TMM con
un plan de compra desarrollador/probador. El plan de compra es importante para hacer el
participantes conscientes de que la mejora de procesos es un esfuerzo de todos, que
hay muchos beneficios que resultan de una evaluación, y esa calidad
prácticas juegan un papel fundamental en la calidad del producto. Tenga en cuenta que en el medio oeste
estudio de grupo de consultoría, la falta de soporte de desarrollador/probador se ubicó como una

de los riesgos en la aplicación de un modelo de evaluación para la mejora de procesos.
El plan de compra sugerido reduce ese riesgo.
El investigador ha sugerido varias herramientas que se pueden utilizar para apoyar la
recopilación y el procesamiento de datos de evaluación de TMM. En este estudio en particular,
se utilizaron herramientas comercialmente disponibles para producir el cuestionario en línea y
almacenar los datos. Se encontró que los participantes
prefirió la forma electrónica del cuestionario en lugar de un papel
versión. Los datos sin procesar del cuestionario se trasladaron a un comercial
Programa que produce hojas de cálculo. Fuentes y colores en la hoja de cálculo
programa se utilizaron para resaltar rangos de valores. La hoja de cálculo fue
también se utiliza para producir las clasificaciones de TMM.
Los datos de la evaluación fueron recopilados por un grupo de siete participantes;
dos eran líderes SEPG (SEPG1 y SEPG2) y cinco eran líderes de prueba
(TL1–TL5). Cada uno era responsable de un número variable de desarrolladores y
probadores; sin embargo, los miembros de la SEPG eran responsables de grupos más grandes
que los líderes de la prueba (TL). Dentro de estos grupos, algunos de los desarrolladores
tenía responsabilidades de prueba a tiempo parcial [44]. En la Tabla 16.5 se muestra un resumen
de los resultados de clasificación de TMM encontrados en este estudio.
Las clasificaciones que resultaron de este estudio son preliminares para este sitio organizacional
y se planea una evaluación más formal para obtener las clasificaciones de referencia del proceso de
prueba. Las principales lecciones aprendidas del estudio se describen a continuación.
• Los factores humanos son una consideración importante al realizar una evaluación. Una “fase de
preparación” TMM aumentada es útil para abordar los problemas de factores humanos. Se deben
proporcionar herramientas, capacitación y personalización de los pasos de trabajo para respaldar
una evaluación exitosa. Como parte del proceso de capacitación y personalización, los instructores
deben proporcionar un mapeo de los términos utilizados por el TMM con los utilizados por la
organización. Esto es útil a pesar de que el cuestionario TMM tiene un glosario de términos. Ayuda
a minimizar el número de "no sé" y respuestas inexactas.
• Realizar una evaluación, aunque sea tan informal como en este estudio, tiene muchos beneficios y es
una excelente herramienta para conocer la naturaleza de un proceso. También es una herramienta
para obtener apoyo de gestión y recursos para la mejora del proceso de prueba.
• Algunas de las áreas de proceso de prueba más débiles encontradas en este estudio fueron:
— desarrollar políticas y objetivos de prueba/depuración;
—integración de la prueba en el ciclo de vida del software;
—identificación de los riesgos de las pruebas;
—garantizar la independencia del grupo de prueba;
-capacitación;
— desarrollar un programa de revisión en toda la organización;
—desarrollar un programa de medición de pruebas.
• Satisfacer las metas de madurez del nivel 5 de TMM puede ser muy difícil para una organización o
grupo en particular. El investigador sugirió que para este sitio, grupos más pequeños de
desarrolladores/evaluadores dirigidos por líderes de prueba que estén involucrados en los detalles
de bajo nivel de las pruebas deberían trabajar para alcanzar el nivel 4 de TMM. Este puede ser un
objetivo más práctico para estos

580 | El modelo de madurez de las pruebas y la evaluación del proceso de pruebas
Resumen de los resultados de clasificación de TMM
TMM
Grupo Nivel Comentarios sobre los resultados
TL1 1 Mal uso de la plantilla del plan de prueba; mal uso de
requisitos como entrada al plan de prueba; sin riesgos de prueba
identificado para el plan de prueba; ninguna integración de la prueba en
ciclo vital.
TL2 1 Ausencia de políticas/objetivos de depuración; falta de
control y seguimiento; ninguna integración de
prueba en el ciclo de vida.

TL3 1 Sin separación de pruebas y depuración; pobre
relación desarrollador/probador; pobre institucionalización
de técnicas y métodos básicos de ensayo.

TL4 2 Necesita un programa de capacitación técnica; integración de prueba
para llegar al nivel 3.
TL5 1 Muchos "no aplicable" y "no sé"
respuestas en cuestionario.
SEPG1 1 Este grupo puede satisfacer todos los objetivos de madurez en todos
Niveles de TMM excepto para planificación de pruebas y pruebas.
programas de medición que tienen debilidades.
Este grupo lidera los esfuerzos de prueba en este sitio.

SEPG2 2 Logra todos los objetivos de madurez de TMM a través del nivel
4. Una debilidad está en la gestión de riesgos para la prueba.
TABLA 16.5
Resumen de los resultados de clasificación de TMM para
una empresa de hardware/ software.
grupos Alcanzar el nivel 5 de TMM debe abordarse a un nivel más global

nivel e involucrar a muchos participantes de SEPG que supervisan grupos grandes
de probadores, y que tienen una visión de más alto nivel de las pruebas. Ellos pueden
proporcionar el apoyo, la experiencia y la supervisión necesarios para elevar a
todo el grupo al nivel 5 de TMM.
El investigador de TMM concluyó que este estudio preliminar fue

16.9 Aplicaciones Industriales del TMM

| 581
muy informativo para el sitio de la organización. Muchos problemas de prueba fueron

planteó, y los desarrolladores, evaluadores y gerentes obtuvieron una mejor comprensión
de la naturaleza de sus procesos de prueba. Para el corto plazo el detallado
se devolvieron los resultados a cada uno de los participantes (SEPG1, SEPG2 y
TL1–5) con ideas y comentarios para ayudarlos a mejorar sus pruebas
procesos. En el futuro, se planea una evaluación formal de TMM, con financiación y apoyo
que se obtendrán de la alta dirección. Este preliminar
estudio ha allanado el camino para obtener dicho apoyo.
16.9.5 Lecciones aprendidas del

Estudios TMM
Estos estudios experimentales indican que el TMM se muestra prometedor como

herramienta útil para la comprensión, evaluación y mejora del proceso de prueba de
software. También es una rica fuente de conocimiento para ingenieros de software,
especialistas y gerentes que quieren aprender sobre buenas prácticas de prueba,
y cómo mejorar la eficacia de su proceso de prueba actual. Él
TMM es único en el sentido de que proporciona un papel distinto para todas las partes interesadas
en el proceso de prueba a través de sus tres puntos de vista críticos. Participación y
se promueve la comunicación entre todas las partes interesadas. Además, los estudios
muestran que el diseño flexible del TMM permite que sea aplicado por
diferentes tipos de organizaciones involucradas en el desarrollo y prueba de sistemas de
software de una amplia variedad de dominios de problemas.
Otro hallazgo útil que resultó de estos estudios es la importancia del papel que juegan
los factores humanos en el éxito de una evaluación.
y esfuerzo de mejora. Los factores humanos en estos estudios se centran en
dos grupos: el personal técnico (desarrolladores y evaluadores) y el personal administrativo
(gerentes de nivel superior e inferior). Las siguientes tres áreas
se encontró que eran puntos focales de factores humanos que deberían ser observados por
equipos de evaluación.
1. El personal debe estar capacitado y motivado.
Para respaldar los esfuerzos exitosos de evaluación y mejora del proceso de prueba,
una organización necesita asegurarse de que su personal técnico esté debidamente capacitado,
motivados y provistos de herramientas de apoyo para hacer el trabajo. Este requisito tiene
sus raíces en el esfuerzo de “Involucramiento total de los empleados (TIE)”, que en
en sí era parte del movimiento de "Gestión de calidad total" en Japón
[45]. El personal debe estar convencido de que la evaluación y mejora del proceso
El modelo de madurez de las pruebas y la evaluación del proceso de pruebas

582 |
es un proyecto de equipo y requiere la participación de todos. También deben estar

convencidos de que todos se benefician del esfuerzo.
2. El esfuerzo de evaluación debe adaptarse para cumplir con las normas

culturales de la organización.
Además de proporcionar capacitación y herramientas, es posible que los líderes de la

evaluación también necesiten adaptar los pasos, formularios y procedimientos de la
evaluación para que se ajusten bien a un entorno organizacional particular. Se ha
demostrado que la adaptación promueve el éxito en la evaluación de procesos y mejora
los esfuerzos a nivel de personal con el Proceso de software personal (PSP) [46]. Es
posible que los miembros del equipo de evaluación deban realizar adaptaciones tanto
a nivel de grano fino como de grano grueso. Como ejemplo detallado, en la aplicación
TMM IV, el investigador encontró que las diferencias en la interpretación de los términos
técnicos debían resolverse para que el cuestionario TMM pudiera completarse de
manera adecuada y precisa.
3. El equipo de evaluación debe obtener el compromiso y el apoyo de la gerencia.
Estos estudios ilustran la importancia de la participación y el compromiso de la gerencia

para el éxito de cualquier esfuerzo de evaluación y mejora de procesos. Las
experiencias pasadas con los esfuerzos de calidad, como la Gestión de calidad total
(TQM), y con los esfuerzos de evaluación/mejora de procesos utilizando CMM, PSP e
ISO-9000, también señalan la importancia de este compromiso. Para citar a Paulk et
al., "La mejora requiere un fuerte apoyo de gestión y un enfoque consistente a largo
plazo" [6]. Un plan de compromiso de la gerencia y una reunión de lanzamiento tal
como lo implementó el investigador de la aplicación IV de TMM promueve este apoyo
y compromiso gerencial necesarios. Los pasos del procedimiento de evaluación de
TMM se pueden ampliar fácilmente para incluir este elemento.
Finalmente, las clasificaciones del TMM ubicaron a la mayoría de los grupos

evaluados en estos estudios iniciales en niveles bajos del TMM (niveles 1, 2). En varios
casos hubo debilidades en áreas básicas como la planificación de pruebas y el
desarrollo de políticas de prueba/depuración. Estos hallazgos son paralelos a los
resultados obtenidos en estudios iniciales utilizando el CMM como modelo de referencia
para la evaluación de procesos. Luego, se evaluó a muchas organizaciones para que
estuvieran en un nivel CMM de 1 y 2. Ahora que existe un amplio reconocimiento del valor de la c
procesos, muchas organizaciones han realizado inversiones significativas en mejoras

de procesos y han aumentado sus calificaciones de madurez. Las necesidades
comerciales y la competencia promovieron la proliferación de esfuerzos de mejora.
Cuando las organizaciones sean más conscientes de la necesidad de centrarse en las
pruebas como (i) un importante proceso de mejora de la calidad y (ii) un proceso que
añade valor a sus productos, invertirán más recursos. Las mejores prácticas requeridas
para un proceso de prueba de alta calidad se aplicarán ampliamente en la industria y,
como consecuencia, los niveles de TMM deberían aumentar.
En este momento, el grupo de consultoría del medio oeste continúa trabajando
con sus clientes industriales y aplica el TMM a sus procesos de prueba. El investigador
de la empresa de hardware/software espera obtener apoyo para una evaluación TMM
completa planificada en su sitio. Varias organizaciones adicionales de consultoría,
desarrollo de software y capacitación también están en proceso de aplicar el TMM en
su trabajo. El autor planea publicar informes con colaboradores industriales a medida
que estén disponibles.
REFERENCIAS
[1] I. Burnstein, T. Suwanassart y C. Carlson, "Desarrollo de [6] M. Paulk, C. Weber, B. Curtis y M. Chrissis, El modelo de
un modelo de madurez de prueba: parte I", CrossTalk: Journal madurez de la capacidad, Addison-Wesley, Reading, MA, 1995.
of Defense Software Engineering. vol. 9, núm. 8, 1996, págs.
21 a 24,
[7] Instituto de Ingeniería de Software, www.sei.cmu. edu/cmmi/
[2] I. Burnstein, T. Suwanassart y C. Carlson, "Desarrollo de publicaciones
un modelo de madurez de prueba: parte II", CrossTalk: Journal
[8] F. Coallier, "Cómo encaja ISO 9001 en el mundo del
of Defense Software Engineering. vol. 9, núm. 9, 1996, págs.
software", IEEE Software, vol. 11, núm. 1, 1994, págs. 98–100.
19–26.
[3] I. Burnstein, A. Homyen, R. Grom, CR Carlson, "Un modelo

[9] A. Bicego, P. Kuvaja, "BOOTSTRAP: el método de
para evaluar la madurez del proceso de prueba"
evaluación de Europa", IEEE Software, vol. 10, núm. 3, 1993,
CrossTalk: Revista del Departamento de Ingeniería de
págs. 93–95.
Software de Defensa, vol. 11, núm. 11, noviembre de 1998,
págs. 26–30. [10] M. Paulk, M. Konrad, "Una descripción general del proyecto
SPICE de ISO", American Programmer, vol. 7, núm. 2, 1994,
[4] I. Burnstein, A. Homyen, T. Suwanassart, G. Saxena, R.
págs. 16–20.
Grom, "Uso del modelo de madurez de prueba para evaluar y
mejorar su proceso de prueba de software" [11] M. Paulk, B. Curtis, M. Chrissis y C. Weber.
proc. de la Semana Internacional de la Calidad Conf. (QW'99), “Modelo de madurez de capacidad, versión 1.1”, IEEE
San José, CA, mayo de 1999. Software, vol. 10, núm. 4, 1993, págs. 18–27.
[5] I. Burnstein, A. Homyen, T, Suwanassart, G. Saxena, R. [12] M. Paulk, C. Weber, S. García, M. Chrissis y M. Bush,
Grom, "Un modelo de madurez de prueba para la evaluación y “Prácticas clave del modelo de madurez de la capacidad,
mejora del proceso de prueba de software", Software Quality versión 1.1”, Informe técnico, CMU/SEI-93-TR-25, 1993,
Professional (Sociedad Estadounidense para la Calidad), vol. Instituto de Ingeniería de Software, Pittsburgh, PA.
1, núm. 4, septiembre de 1999, págs. 8–21.
584 | El modelo de madurez de las pruebas y la evaluación del proceso de pruebas
[13] D. Gelperin, B. Hetzel, “El crecimiento del software [26] J. Hearns, S. García, “Gestión automatizada del equipo de
testing”, Communications of the Association of Computing Machinery, pruebas: ¡funciona!” proc. del 10° Ing. de Software.
vol. 31, núm. 6, 1988, págs. 687–695. Conferencia del Grupo de Procesos (SEPG'98), 6–9 de marzo,
Chicago, IL, 1998.
[14] J. Durant, “Informe de encuesta sobre prácticas de prueba de
software”, Informe técnico, TR5-93, Prácticas de software [27] W. Humphrey, W. Sweet, “Un método para evaluar
Centro de Investigaciones, 1993. la capacidad de ingeniería de software de los contratistas”,
Informe técnico, CMU/SEI-87-TR-23, Instituto de ingeniería de
[15] B. Beizer, Técnicas de prueba de software, segundo
software, Pittsburgh, PA, 1987.
edición, Van Nostrand Reinhold, Nueva York, 1990.
[28] J. Puffer, A. Litter, "Planificación de acciones", Boletín informativo
[16] D. Gelperin, A. Hayashi, “Cómo apoyar mejor
del Consejo técnico de ingeniería de software de IEEE,
pruebas de software”, Application Trends, mayo de 1996,
vol. 15, núm. 2, 1997, págs. 7 a 10.
págs. 42–48.
[29] R. Grom, “Informe sobre un soporte de evaluación de TMM
[17] D. Gelperin, "¿Cuál es su madurez de comprobabilidad?"
tool,” Technical Report, Instituto de Tecnología de Illinois, Chicago,
Application Trends, mayo de 1996, págs. 50–53.
IL, 1998.
[18] T. Koomen, M. Pol, "Mejora del proceso de prueba usando TPI", [30] C. Cook, M. Visconti, “Modelo de documentación nuevo y
Informe técnico, IQUIP Informatica mejorado”, Informe técnico, Estado de Oregón
BV, Diemen, Países Bajos, 1998, http://www. Universidad, 1996.
iquip.nl.
[31] K. El Emam, D. Goldenson, L. Briand, P. Mar, “Acuerdo entre
[19] T. Koomen, M. Pol, Mejora del proceso de prueba, evaluadores en evaluaciones basadas en SPICE: algunos informes
Addison-Wesley, Reading, MA, 1999. preliminares”, Proc. Cuarta Conferencia Internacional sobre el
Proceso del Software,
[20] A. Clouse, C. Wells, “Transitioning from EIA/IS 731 to CMMI,”
Brighton, Reino Unido, 1996, págs. 149–156.
CrossTalk: Journal of Department of
Ingeniería de software de defensa, vol. 13, N° 7, julio [32] G. Saxena, "Un marco para construir y evaluar modelos de
2000, págs. 15 a 20. madurez de procesos", Ph.D. tesis, Illinois
Instituto de Tecnología, Chicago, IL, 1999.
[21] S. Shrum, "Elegir una representación de modelo CMMI",
CrossTalk: Revista del Departamento de Defensa [33] J. Weszka, P. Babel, J. Ferguson, “CMMI:
Ingeniería de software, vol. 13, núm. 7, julio de 2000, camino evolutivo hacia la mejora de los procesos empresariales”,
págs. 6–7. CrossTalk: Revista del Departamento de Ingeniería de Software de
Defensa, vol. 13, núm. 7, julio de 2000,
[22] Organización Internacional de Normalización
págs. 8–11.
(ISO), ISO/IEC Evaluación de procesos de software Trabajo
Borrador-Parte 3: Procesos de calificación, versión 1.00; Parte 5: [34] Equipo de desarrollo de productos de CMMI, “CMMI for
Construcción, selección y uso de instrumentos y herramientas de ingeniería de sistemas/ingeniería de software, versión 1.02
evaluación, versión 1.00; Parte 7: Guía para uso en (CMMI-SE/SW, V1.02) representación por etapas”, Informe Técnico,
mejora de procesos, versión 1.00, Organización Internacional de CMU/SEI-2000TR-018, ESC-TR-2000-
Normalización, Ginebra, 1995. 018, Instituto de Ingeniería de Software, noviembre de 2000.
[23] D. Zubrow, W. Hayes, J. Siegel, D. Goldenson, “Cuestionario de [35] D. Kitson, “Un estándar internacional emergente
madurez”, Informe técnico, para la evaluación de procesos de software”, Proc. IEEE tercero
CMU/SEI-94-SR-7, Instituto de Ingeniería de Software, Simposio y foro sobre estándares internacionales de ingeniería de
Pittsburgh, Pensilvania, 1994. software, Walnut Creek, CA, junio de 1999.
[24] S. Masters, C. Bothwell, “Una evaluación CMM [36] S. García, “Evolución de los paradigmas de mejora:
framework, versión 1.0”, Informe técnico, CMU/SEI 95-TR-001, Modelos de madurez de capacidad e ISO/IEC 15504
Instituto de ingeniería de software, Pittsburgh, PA, 1995. (PDTR)”, Mejora y práctica de procesos de software, vol. 3, núm. 1,
1998.
[25] A. Homyen, “Un modelo de evaluación para determinar [37] Organización Internacional de Normalización
madurez del proceso de prueba”, Ph.D. tesis, Instituto de Illinois de (ISO), “ISO/IEC 12207: Tecnología de la información—
Tecnología, Chicago, IL, 1998. Procesos del ciclo de vida del software”, 1995.
[38] J. Moore, “ISO 12207 y vida de software relacionada [44] H. Tran, "Un procedimiento sobre cómo realizar una
estándares de ciclo,” http://www.acm.org.tsc/lifecycle. evaluación de madurez de prueba en una organización de
html desarrollo de software utilizando la metodología de evaluación TMM",
Tesis de maestría, Universidad de Minnesota, Rochester, MN,
[39] R. Kehoe, A. Jarvis, ISO-9000-3, Springer-Verlag,
2001.
Nueva York, 1995.
[45] L. Zells, “Aprendiendo de las aplicaciones TQM japonesas
[40] I. Burnstein, T. Suwanassart, correspondencia privada, 2001.
a la ingeniería de software”, Gestión de calidad total para
software, G. Schulmeyer, J. McManus,
[41] J. Hook, “Evaluación del cuestionario TMM”, Informe técnico, eds., Van Nostrand Reinhold, Nueva York, 1992.
Instituto de Tecnología de Illinois, Chicago, IL, 1997.
[46] K. El Emam, B. Shostak, N. Madhavji, “Implementación de
conceptos del proceso de software personal
[42] K. Olsen, P. Stall Vinje, “Using the testing maturity model in en un entorno industrial”, Proc. Cuarta Internacional
practice test-planning and postevaluation,” Conferencia Conferencia sobre el Proceso de Software, Mejora,
EuroSTAR98, Munich, Alemania, and Practice, Brighton, Reino Unido, 1996, págs. 117–130.
1998.
[43] I. Burnstein, L. Miller (Presidente, Midwest Software Testing

Lab, Inc.), correspondencia privada,
2000–2001.
Esta página se dejó en blanco intencionalmente

APÉNDICE I
REFERENCIAS RELACIONADAS CON LA PRUEBA
I. Pruebas de software: conferencias relacionadas
A continuación se enumeran referencias a conferencias de interés relacionadas con pruebas y
procesos. Esta lista no pretende ser exhaustiva, solo representativa de las conferencias disponibles
en estas áreas. Algunas de las conferencias se llevan a cabo una vez al año; otros se llevan a cabo
varias veces al año. Las ubicaciones de las conferencias pueden variar de un año a otro.
Conferencia y exposición de automatización de pruebas de software
Ingeniería de Calidad de Software
330 Forma Corporativa
Parque anaranjado, FL 32073
www.sqe.com
www.stickyminds.com (boletín informativo)
Conferencia del Grupo de Procesos de Ingeniería de Software
Universidad de Carnegie mellon
Instituto de Ingeniería de Software
Pittsburgh, Pensilvania 15213-3890

588 | Apéndice I
Semana internacional de profesionales de pruebas de

software Técnicas prácticas de calidad de software,
PSQT Instituto internacional para pruebas de software
Dimensiones del software 8476 Bechtel Ave Inver Grove
Heights, MN 55076 www.testinginstitute.com
Conferencia de tecnología de software

Base de la Fuerza Aérea Hill STSC
5045 Colina principal vieja
Logan, UT 84322-5045
www.stc-online.org
Conferencia de la Semana Internacional de Internet y la Calidad del

Software Software Research, Inc.
Calle Minnesota 901
San Francisco, CA 94107
www.qualityweek.com
II. Sitios web para procesos de software y
Información de calidad del software
Esta lista contiene sitios web que se enfocan en material general de mejora de
procesos. Los evaluadores y administradores de pruebas pueden encontrar información
muy útil en estos sitios.
1. Centro de soporte de tecnología de software
www.stsc.hill.af.mil
Este centro está patrocinado por el Departamento de Defensa de los Estados

Unidos. Distribuyen una publicación muy útil llamada CrossTalk que es gratuita.
2. Red de mejora de procesos de software (SPIN)
www.cmu.edu/collaborating/spins/spins.html
Referencias relacionadas con la prueba

| 589
Los grupos SPIN ofrecen un foro para intercambiar información, experiencias y

conocimientos sobre la mejora de procesos de software. En muchas ciudades
grandes hay grupos SPIN locales. Asociado con la mayoría de los grupos SPIN
locales, hay una serie regular de presentaciones de profesionales involucrados en
los esfuerzos de mejora de procesos.
3. Instituto de Ingeniería de Software
www.sei.cmu.edu
Este es un centro de investigación financiado con fondos federales que ha

desarrollado la familia de modelos CMM. Los detalles sobre el proyecto CMMI se
pueden encontrar en
www.sei.cmu.edu/cmmi
4. Oficina de Procesos de Ingeniería del Software (SEPO)
http://sepo.nosc.mil
Esta es la fuente de ingeniería de software para el Centro de Sistemas de Guerra

Espacial y Naval. Ofrece servicios de consultoría para socios gubernamentales e
industriales.
5. El Laboratorio de Ingeniería de Software (SEL)
http://sel.gsfc.nasa.gov El
SEL ha recopilado y analizado métricas de desarrollo de software de proyectos

dentro del Centro de Vuelo Espacial Goddard de la NASA.
6. Consorcio de Productividad de Software
www.software.org
Asociación de la industria, el gobierno y la academia. Desarrolla métodos de

proceso, herramientas y servicios de apoyo.
7. Fundación Europea para la Mejora de Procesos de Software (ESPI)
www.espi.co.uk
Proporciona información sobre ingeniería de software y promueve prácticas de

software de calidad a través de la mejora de procesos.
8. Egrupos
www.egroups.com/group.spi
Foro electrónico para el intercambio de información relativa a la mejora de procesos

de software.
590 | Apéndice I
9. Mejora del proceso de software y determinación de la capacidad (SPICE)
www.sqi.gu.edu.au/spice/contents.html
Desarrolladores del modelo de mejora de procesos SPICE. SPICE es una iniciativa

internacional para desarrollar un estándar internacional para software pro
evaluación del proceso.
10. Sociedad Americana para la Calidad (ASQ)
www.asq.org
Editor de Software Quality Professional, una revista que contiene artículos de alta calidad
que cubren aspectos de la prueba y la calidad del software. La sociedad también participa
en la certificación de ingenieros de calidad, patrocina conferencias de calidad/pruebas,
publica libros y tiene un foro de Six Sigma.
11. Cuerpo de conocimientos de ingeniería de software (SWEBOK). Desarrollado por un grupo de
trabajo conjunto IEEE/ACM.
www.swebok.org
SWEOK contiene áreas de conocimiento y descripciones de temas que son esenciales para
todos los ingenieros de software.
12. Instituto de Garantía de Calidad (QAI)
www.qaiusa.com
Patrocina conferencias, certificaciones y actividades educativas.
tercero Sitios web orientados a pruebas
Hay muchos sitios web dedicados a las pruebas. Muchos ofrecen servicios de prueba.
La siguiente es una lista de algunos sitios web útiles relacionados con las pruebas que contienen
enlaces a documentos, conferencias y servicios de interés para los profesionales de las pruebas.
1. Bibliografía de RBSCB: Pruebas de software orientado a objetos
www.rbsc.com
Tiene una buena lista de documentos relacionados con las pruebas de orientación a objetos.
sistemas
2. Centro de recursos de pruebas y calidad del software

| 591
www.softwareqatest.com
Tiene enlaces a muchos recursos y herramientas de prueba.

3. Sociedad para la Calidad del Software
www.ssq.org
Esta es una organización cuyos miembros trabajan para promover la calidad en el

desarrollo de software.
4. Sitio web de estándares IEEE
estándares.ieee.org/catalog
Enumera los documentos de normas IEEE y cómo solicitar copias. El sitio web del IEEE
es:
ieee.org
5. Instituto de Pruebas de Software (STI)
www.ondaweb.com
Enumera publicaciones, documentos de investigación y servicios para profesionales

de pruebas. También tiene un Boletín de pruebas de software y una Guía del comprador
de STI, que es un directorio de proveedores y consultores.
6. Recursos en línea de pruebas de software
www.mtsu.edu/strom/
Esta es una buena fuente de material relacionado con las pruebas. Es mantenido por
la Universidad Estatal de Middle Tennessee. Hay una lista de investigadores en
pruebas, revisiones, monografías y fuentes educativas.
7. Revista de Pruebas de Software e Ingeniería de Calidad (STQE)
www.stqemagazine.com/
Este sitio describe una revista que contiene artículos sobre pruebas de software.
8. Investigación de software (SR Institute, Test Works)
www.soft.com
Patrocinador de conferencias de investigación sobre pruebas, el sitio tiene un boletín

con archivos.
Apéndice I
592 |
IV. Bibliografía (Artículos y Libros)
Esta sección contiene una lista de documentos y libros relacionados con las pruebas
de software que son de interés para desarrolladores, probadores y administradores.
La lista está en orden alfabético y contiene una compilación de las referencias
mencionadas en cada capítulo del libro, así como elementos adicionales que aumentan
el material del texto.
Abramovici, M., M. Brever, A. Friedman, Digital System Testing and Testable

Design, Computer Science Press, Nueva York, 1990.
Abran, A., J. Moore, P. Bourque, R. Dupuis, eds., “Guide to the Software

Engineering Body of Knowledge—Trial Version,” IEEE Computer Society Press,
Los Alamitos, CA, 2001.
Affourtit, B., "Control estadístico de procesos aplicado al software", Gestión de

calidad total para software, G. Schulmeyer, J. McManus, eds., Van Nostrand
Reinhold, Nueva York, 1992.
Arnold, T., W. Fuson, "Pruebas en un mundo perfecto", Comm. de la ACM,

vol. 37, núm. 9, 1994, págs. 78–86.
Ayer, S., F. Patrinostro, Gestión de configuración de software, McGraw Hill,

Nueva York, 1992.
Bartol, K., D. Martin, "Gestión de las consecuencias de la rotación de DP: una

perspectiva de planificación de recursos humanos", Proc. 20th ACM Computer
Personnel Research Conf., 1983, págs. 79–86.
Basili, V., D. Weiss, "Una metodología para recopilar datos de ingeniería de

software válidos", IEEE Transactions on Software Engineering, vol. SE-10, No.
6, 1984, págs. 728–738.
Beizer, B., Pruebas de caja negra, Wiley, Nueva York, 1995.
Beizer, B., Software Testing Techniques, segunda edición, Van Nostrand

Beizer, B., Software System Testing and Quality Assurance, Van Nos trand
Berard, E., Ensayos sobre ingeniería de software orientada a objetos, Volumen

1, Prentice Hall, Englewood Cliffs, NJ, 1993.

| 593
Bertolino, A., "Pruebas de software", en Guía para el cuerpo de conocimientos de

ingeniería de software, versión 0.7, A. Abran, J. Moore, P. Bourque, R.
Dupuis, eds., abril de 2000.
Bicego, A., P. Kuvaja, “BOOTSTRAP: el método de evaluación de Europa,”

Software IEEE, vol. 10, núm. 3, 1993, págs. 93–95.
Binder, R., "Diseño para la capacidad de prueba en sistemas orientados a objetos",

Comm. de la ACM, vol. 37, núm. 9, 1994, págs. 87–101.
Boehm, B., “Gestión de riesgos de software: principios y prácticas”, IEEE Software,

enero de 1991, págs. 32–41.
Boehm, B., Economía de la ingeniería de software, Prentice Hall, Englewood Cliffs,

NJ, 1981.
Boehm, B., J. Brown, M. Lipow, "Evaluación cuantitativa de la calidad del software",

IEEE 2nd International Conf. on Software Engineering, San Francisco, CA, págs. 592–
605, octubre de 1976.
Booth, P., Introducción a la interacción humano-computadora, Lawrence Erlbaum

Associates, Londres, 1989.
Brettschneider, R., "¿Está su software listo para su lanzamiento?" Software IEEE, vol.
6, núm. 4, págs. 100 a 108, 1989.
Burnstein, I., F. Saner, "Razonamiento difuso para respaldar la comprensión

automatizada de programas", Revista internacional de ingeniería de software e
ingeniería del conocimiento, vol. 10, núm. 1, febrero de 2000, págs. 115 a 137.
Burnstein, I., A. Homyen, T. Suwanassart, G. Saxena, R. Grom, "Un modelo de

madurez de prueba para la evaluación y mejora del proceso de prueba de software",
Software Quality Professional (Sociedad Estadounidense para la Calidad), vol. 1,
núm. 4, septiembre de 1999, págs. 8–21.
Burnstein, I., A. Homyen, T. Suwanassart, G. Saxena, R. Grom, "Uso del modelo de

madurez de prueba para evaluar y mejorar su proceso de prueba de software", Proc.
de la Semana Internacional de la Calidad Conf. (QW'99), San José, CA, mayo de 1999.
Burnstein, I., A. Homyen, R. Grom, CR Carlson, "Un modelo para evaluar la madurez
del proceso de prueba", CrossTalk: Journal of Department of Defense Software
Engineering, vol. 11, núm. 11, noviembre de 1998, págs. 26–30.
Apéndice I
594 |
Burnstein, I., T. Suwanassart, CR Carlson, "Desarrollo de un modelo de madurez de

prueba: parte I", CrossTalk: Journal of Defense Software Engineering, vol. 9, núm. 8,
agosto de 1996, págs. 21–24.
Burnstein, I., T. Suwanassart, CR Carlson, "Desarrollo de un modelo de madurez de

prueba: parte II", CrossTalk: Revista de ingeniería de software de defensa, vol. 9, núm. 9,
septiembre de 1996, págs. 19–26.
Card, D. "Aprendiendo de nuestros errores con el análisis causal de defectos", IEEE

Software, vol. 13, núm. 1, 1998, págs. 56 a 63.
Cangussu, J., R. DeCarlo, A. Mathur, "Un modelo formal del proceso de prueba", IEEE
Trans. Ingeniería de software, vol. 28, núm. 8, agosto de 2002,
págs. 782–796.
Chen, M., M. Kao, “Investigación de la eficacia de las pruebas en orientación a objetos

software: un estudio de caso”, Proc. Duodécima Semana Internacional de la Calidad Conf.,
mayo de 1999.
Chen, T., Y. Yu, "Sobre el número esperado de fallas detectadas por pruebas de
subdominios y pruebas aleatorias", IEEE Trans. Ingeniería de software,
vol. 22, 1996, págs. 109–119.
Chernak, Y., "Validación y mejora de la eficacia de los casos de prueba", IEEE

Software, vol. 16, núm. 1, 2001, págs. 81 a 86
Chilenski, J., P. Newcomb, "Herramientas de especificación formal para el análisis de edad

de cobertura de prueba", Proc. Conferencia IEEE on Knowledge-Based Software
Engineering, Monterey, CA, 1994, págs. 59–68.
Cho, C., “Métodos estadísticos aplicados al control de calidad del software”, en

Handbook of Software Quality Assurance, segunda edición, G. Schul meyer, J McManus,
eds., Van Nostrand Reinhold, Nueva York, 1992.
Clarke, L., A. Podgurski, A. Richardson, S. Zeil, “Una comparación de datos

criterios de selección de trayectoria de flujo”, Proc. Octava Conferencia Internacional. en SO
Engineering, agosto de 1985, págs. 244–251.
Clouse, A., C. Wells, “Transición de EIA/IS-731 a CMMI”,

CrossTalk: Revista del Departamento de Ingeniería de Software de Defensa,
vol. 13, núm. 7, julio de 2000, págs. 15–20.

| 595
Equipo de desarrollo de productos de CMMI, “CMMI para ingeniería de sistemas/ingeniería

de software, versión 1.02 (CMMI-SE/SW, V1.02) puesta en escena
representación”, Informe Técnico CMU/SEI-2000TR-018, ESC-TR 2000-018, Instituto de
Ingeniería de Software, noviembre de 2000.
Coad, P., E. Yourdon, Object-Oriented Analysis, segunda edición, Your don Press, Englewood
Cliffs, NJ, 1991.
Coallier, F., "Cómo encaja ISO 9001 en el mundo del software", IEEE Software, vol. 11, núm.
1, 1994, págs. 98–100.
Cobb, R., H. Mills, "Software de ingeniería bajo control de calidad estadístico", IEEE Software,
vol. 7, núm. 5, 1990, págs. 44 y 54,
Cook, C., M. Visconti, “Modelo de documentación nuevo y mejorado,”

Informe técnico, Universidad Estatal de Oregón, 1996.
Crosby, P., La calidad es gratis: El arte de asegurar la calidad, Mentor,

Nueva Biblioteca Americana, Nueva York, 1979.
Daich, G., G. Price, B. Ragland, M. Dawood, Tecnologías de prueba de software

Informe, agosto de 1994, Software Technology Support Center (STSC) Hill
Base de la Fuerza Aérea, UT, agosto de 1994.
Dalal, S., C. Mallows, “Algunas ayudas gráficas para decidir cuándo detenerse
software de prueba”, IEEE Journal on Selected Areas in Communications,
vol. 8, núm. 2, 1990, págs. 169–175.
Dalal, S., C. Mallows, "¿Cuándo se debe dejar de probar el software?" J. American Statistical
Association, vol. 81, núm. 403, págs. 872–879, 1988.
Delamaro, M., J. Maldonado, A. Mathur, "Mutación de la interfaz: un enfoque para las pruebas
de integración", IEEE Transactions on Software Engineering, vol. 27, núm. 3, marzo de 2001,
págs. 228–247.
DeMillo, R., R. Lipton, F. Sayward, “Sugerencias sobre la selección de datos de prueba: ayuda
para el programador en ejercicio”, Computer, vol. 11, núm. 4, 1978,
págs. 34–41.
Deming, W., Out of the Crisis, Centro de Ingeniería Avanzada del MIT
Estudio, Cambridge, MA, 1986.
Dieli, M., "Un enfoque de resolución de problemas para la planificación de pruebas de usabilidad", Proc.
596 | Apéndice I
Conferencia Internacional de Comunicación Profesional, Seattle, págs. 265–267, 1988.
Doong, R., P. Frankl, "El enfoque ASTOOT para probar programas orientados a objetos",
ACM Transactions of Software Engineering and Methodology, vol. 3, 1994, págs. 101 a 130.
D'Souza, R., R. LeBlanc, “Class testing by examing pointers”, J. Object Oriented

Programming, julio-agosto de 1994, págs. 33–39.
Duran, J., S. Ntafos, "Una evaluación de las pruebas aleatorias", IEEE Trans.
SW Ingeniería, vol. 10, 1984, págs. 438–444.
Durant, J., Informe de encuesta sobre prácticas de prueba de software, Centro de

investigación de prácticas de software, Informe técnico, TR5-93, mayo de 1993.
Dustin, E., J. Rashka, J. Paul, Pruebas de software automatizadas, Addison Wesley,

Reading, MA, 1999.
Ehrlich, W., B. Prasanna, J. Stampfel, J. Wu, "Determinación del costo de una decisión de
parada de prueba", IEEE Software, vol. 10, núm. 2, págs. 33–42, 1993.
El Emam, K., D. Goldenson, L. Briand, P. Marshall, “Acuerdo entre evaluadores en

evaluaciones basadas en SPICE: algunos informes preliminares”, Proc.
Cuarta Conferencia Internacional sobre el Proceso del Software, Brighton, Reino Unido,
1996, págs. 149–156.
Endres, A., "Un análisis de errores y causas en los programas del sistema", IEEE
Transactions on Software Engineering, vol. SE-1, N° 2, 1975.
Fagen, M., "Inspecciones de diseño y código para reducir errores en el desarrollo de

programas", IBM Systems Journal, vol. 15, núm. 3, 1976, págs. 182–211.
Fenton, N., "Medición de software: una base científica necesaria", IEEE Transactions on
Software Engineering, vol. SE-20, No. 3, págs. 199–206, 1994.
Fenton, N., Métricas de software: un enfoque riguroso, Chapman & Hall, Londres, 1991.
Fiedler, S., "Pruebas unitarias orientadas a objetos", Hewlett-Packard Journal, abril de

1989, págs. 69–74.

| 597
Firth, R., V. Mosley, R. Pethia, L. Roberts, W. Wood, Una guía para la clasificación y
evaluación de herramientas de ingeniería de software, Informe técnico, CMU/SEI-87-
TR-10. ESD-TR-87-11, Instituto de Ingeniería de Software, Carnegie Mellon, 1987.
Florac, W., A. Carleton, J. Barnard, “Control estadístico de procesos: análisis

un proceso de software a bordo del transbordador espacial”, IEEE Software, vol. 17,
n.° 4, 2000, págs. 97–106.
Frankl, P., E. Weyuker, "Mejoras demostrables en las pruebas de sucursales"

Trans. IEEE. Ingeniería de software, vol. 19, núm. 10, 1993, págs. 962–975.
Frankl, P., E. Weyuker, "Un análisis formal de la capacidad de detección de fallas

de métodos de prueba”, IEEE Trans. Ingeniería de software, vol. 19, núm. 3,
1993, págs. 202–213.
Freedman, P., G. Weinberg, Manual de recorridos, inspecciones,

and Technical Reviews, Dorest House Publishing, Nueva York, 1990.
Ganesan, K., T. Khoshgoftaar, E. Allen, “Calidad de software basada en casos

predicción”, Revista Internacional de Ingeniería de Software e Ingeniería del Conocimiento,
vol. 10, núm. 2, 2000, págs. 139 a 152.
Gale, J., J. Tirso, C. Burchfiled, "Implementación del proceso de prevención de defectos

en la organización de programación interactiva de MVS", IBM Systems
Revista, vol. 29, N° 1, 1990.
García, S., “Evolución de los paradigmas de mejora: modelos de madurez de capacidad

e ISO/IEC 15504 (PDTR)”, Mejora de procesos de software y
Práctica, vol. 3, núm. 1, 1998.
Gelperin, D., A. Hayashi, “How to support better software testing”, App plication Trends,
mayo de 1996, págs. 42–48.
Gelperin, D., "¿Cuál es su madurez de comprobabilidad?" Tendencias de aplicación,

mayo de 1996, págs. 50–53.
Gelperin, D., B. Hetzel, "El crecimiento de las pruebas de software" , CACM,

vol. 31, núm. 6, 1988, págs. 687–695.
Gilb, T., Principios de gestión de ingeniería de software, Addison Wesley, Reading, MA,
1988.
598 | Apéndice I
Gotterbarn, D., K. Miller, S. Rogerson, "La sociedad informática y ACM aprueban el código
de ética de la ingeniería de software", IEEE Computer, vol. 32, núm. 10, octubre de 1999,
págs. 84–88.
Grady, R., Métricas prácticas de software para la gestión de proyectos y la mejora de

procesos, Prentice Hall (Pearson Education), Engelwood Cliff, NJ., 1992.
Grady, R., D. Caswell, Métricas de software: establecimiento de un programa para toda la

empresa, Prentice Hall (Pearson Education), Englewood Cliff, NJ, 1987.
Graham, D., "Medición de la eficacia y la eficiencia de las pruebas", Proc.

Pruebas de software, París, junio de 1996.
Gutjahr, W., "Pruebas de partición frente a pruebas aleatorias: la influencia de la

incertidumbre", IEEE Trans. Ingeniería de software, vol. 25, núm. 5, sept./oct. 1999, págs.
661–674.
Grom, R., "Informe sobre una herramienta de apoyo a la evaluación de TMM", Informe
técnico, Instituto de Tecnología de Illinois, Chicago, IL, 1998.
Hamlet, D., "¿Estamos probando la verdadera confiabilidad?" Software IEEE, vol. 9, núm.
4, págs. 21 a 27, 1992.
Harel, D., "Statechcharts: un formalismo visual para sistemas complejos", Science of

Computer Programming, vol. 8, 1987.
Harrold, M., G. Rothermel, "Realización de pruebas de flujo de datos en clases"

proc. Segundo simposio ACM SIGSOFT sobre fundamentos de ingeniería de software,
diciembre de 1994, págs. 154–163.
Harrold, M., J. McGregor, K. Fitzpatrick, "Pruebas incrementales de estructuras de clases

orientadas a objetos", Proc. 14ª Conferencia Internacional. on Software Engineering, mayo
de 1992, págs. 68–80.
Hearns, J., S. García, "Gestión automatizada del equipo de pruebas: ¡¡funciona!!"

proc. X Jornadas de Grupos de Procesos de Ingeniería de Software (SEPG'98)
Chicago, IL, marzo de 1998.
Hetzel, B., The Complete Guide to Software Testing, segunda edición, QED Information
Sciences, Inc., Wellesley, MA. 1988.
Hollenbach, C., W. Frakes, “Reutilización de procesos de software en un entorno industrial”.


| 599
ting,” Proc. Cuarta Conf. Internacional. sobre reutilización de software, Orlando, FL,
abril de 1996, págs. 22–30.
Homyen, A. “Un modelo de evaluación para determinar la madurez del proceso de prueba,”
Doctor. Tesis, Instituto de Tecnología de Illinois, Chicago, IL, 1998.
Hook, J., "Evaluación del cuestionario TMM", Informe técnico,

Horgan, J., S. London, M. Lyu, “Lograr la calidad del software con pruebas
medidas de cobertura”, IEEE Computer, vol. 27, núm. 9, 1994, págs. 60–68.
Horgan, J., S. London, "Cobertura de flujo de datos y lenguaje C", Proc.

Simposio SIGSOFT de ACM sobre pruebas, análisis y verificación, octubre de 2010.
1991, págs. 87–97.
Howden, W., "Pruebas de mutación débiles e integridad de los conjuntos de pruebas",

Trans. IEEE. Ingeniería de software, vol. 8, núm. 4. 1982, págs. 371–379.
Howden, W., “A Survey of Dynamic Analysis Methods”, In Software Testing and Validation
Techniques, segunda edición, E. Miller y W. How den, eds., IEEE Computer Society Press,
Humphrey, W., Una disciplina para la ingeniería de software, Addison-Wesley,

Lectura, MA. 1995.
Humphrey, W., Gestión del proceso de software, Addison-Wesley, Reading, MA, 1990.
Humphrey, W., W. Sweet, "Un método para evaluar la capacidad de ingeniería de software
de los contratistas", Informe técnico, CMU/SEI-87-TR 23, Instituto de ingeniería de software,
Pittsburgh, PA, 1987.
Hurst, P., "Gestión de proyectos de software: hilos de control", en Gestión de proyectos de

ingeniería de software, segunda edición, R. Thayer, ed.,
IEEE Computer Society Press, Los Alamitos, CA, 1997, págs. 410–422.
IEEE Software, "Evaluación de herramientas", edición especial, mayo de 1992.
Instituto de Ingenieros Eléctricos y Electrónicos, Inc., Normas IEEE

Colección para Ingeniería de Software, edición de 1994, Nueva York, 1994.
Instituto de Ingenieros Eléctricos y Electrónicos, Inc., Estándar IEEE

Apéndice I
600 |
1044-1993, Clasificación estándar IEEE para anomalías de software, 1993,

reservados todos los derechos.
Instituto de Ingenieros Eléctricos y Electrónicos, Inc., Estándar IEEE/ANSI 830-1993, Prácticas

Recomendadas para Requisitos de Software
Especificación, 1993, todos los derechos reservados.
Instituto de Ingenieros Eléctricos y Electrónicos, Inc., IEEE/ANSI Std

1045-1992, Estándar para métricas de productividad de software, 1992, todos los derechos
reservado.
Instituto de Ingenieros Eléctricos y Electrónicos, Inc., Estándar IEEE/ANSI 1061-1992,

Estándar IEEE para una Metodología de Métricas de Calidad del Software, 1992, todos los
derechos reservados.
Instituto de Ingenieros Eléctricos y Electrónicos, Inc., estándares IEEE

Norma IEEE (ANSI) 1209-1992, práctica recomendada de IEEE para la
Evaluación y selección de herramientas CASE, 1992, todos los derechos reservados.
Instituto de Ingenieros Eléctricos y Electrónicos, Inc., Estándar IEEE. 828-

1990, estándar IEEE/ ANSI para la gestión de configuración de software
Planos, 1990, todos los derechos reservados.
Institute of Electrical and Electronics Engineers, Inc., IEEE/ANSI Standard 730-1989, Standard
for Software Quality Assurance Plans, 1989,

Estándar IEEE para revisiones y auditorías de software, 1988,
Institute of Electrical and Electronics Engineers, Inc., IEEE/ANSI Standard 982.2-1988, IEEE
Guide for the Use of IEEE Standard Dictionary
of Measures to Produce Reliable Software, (Reaff 1989), 1988, todos los derechos
reservado.
Instituto de Ingenieros Eléctricos y Electrónicos, Inc., Estándar IEEE.

1042-1987, Guía IEEE/ ANSI para la gestión de configuración de software,
(Reaff. 1993), 1987, todos los derechos reservados.
Instituto de Ingenieros Eléctricos y Electrónicos, Inc., IEEE/ANSI Std


| 601
1008-1987, Estándar para pruebas de unidades de software, (Reaff 1993), 1987, todas
Derechos reservados.

Prácticas Recomendadas para Descripciones de Diseño de Software, (Reaff. 1993),
1987, todos los derechos reservados.
Institute of Electrical and Electronics Engineers, Inc., IEEE/ANSI Standard 1012-1986,

(Reaff 1992), Standard for Software Verification and
Validación de Planes, 1986, todos los derechos reservados.
Institute of Electrical and Electronics Engineers, Inc., IEEE/ANSI Standard 829-1983,

(Reaff 1991), Standard for Software Test Documentation, 1983, todos los derechos
reservados.
Organización Internacional de Normalización (ISO), Software ISO/IEC

Borrador de trabajo de evaluación de procesos—Parte 3: Procesos de calificación, versión
1,00; Parte 5: Construcción, selección y uso de instrumentos de evaluación
y herramientas, versión 1.00; Parte 7: Guía para su uso en la mejora de procesos,
versión 1.00, Organización Internacional de Normalización, Ginebra,
1995.
Organización Internacional de Normalización (ISO), ISO/IEC 12207,

Tecnología de la información: procesos del ciclo de vida del software, 1995.
Organización Internacional de Normalización (ISO), Tecnología de la información:

Evaluación de productos de software: características de calidad y directrices para su uso,
ISO/IEC IS 9126, Ginebra, ISO, 1991.
Jacobson, I., M. Christerson, P. Jonsson, G. Overgaard, orientado a objetos

Ingeniería de software: un enfoque basado en casos de uso, Addison-Wesley,
Lectura, MA, 1992.
Jorgensen, P., C. Erikson, "Prueba de integración orientada a objetos", CACM,

vol. 37, núm. 9, 1994, págs. 30–38.
Juran, J., M. Gryna, M. Frank, Jr., R. Bingham, Jr. (eds.), Control de calidad
Manual, tercera edición, McGraw-Hill, Nueva York, 1979.
Juran, J., avance gerencial, McGraw-Hill, Nueva York, 1964.
Kaner, C., J. Falk, H. Nguyen, Testing Computer Software, segunda edición, Van
Nostrand Reinhold, Nueva York, 1993.
Apéndice I
602 |
Kehoe, R., A. Jarvis, ISO-9000-3, Springer-Verlag, Nueva York, 1995.
Kellner, M., L. Briand, J. Over, “Un método para diseñar, definir y

procesos de software en evolución”, Proc. Cuarta Conf. Internacional. sobre el
Software Process, Brigthon, Reino Unido, diciembre de 1996, págs. 37–48.
Kellner, M., R. Phillip, "Tecnología práctica para activos de proceso", Proc.

8º Taller Internacional de Procesos de Software: Estado de la Práctica en
Process Technology, Warden, Alemania, marzo de 1993, págs. 107–112.
Kemerer, C., “Cómo la curva de aprendizaje afecta la adaptación de la herramienta CASE,”

IEEE Software, págs. 23–28, mayo de 1993.
Khoshgoftarr, T., J. Munson, “Predicción de errores de desarrollo de software

utilizando métricas de complejidad de software”, IEEE J. Selected Areas in Comm.,
vol. 8, núm. 2, febrero de 1990, págs. 252–261.
Kit, E., Pruebas de software en el mundo real, Addison-Wesley, Lectura,

MA, 1995.
Kitson, D., "Un estándar internacional emergente para la evaluación de procesos de

software", Proc. Tercer Simposio y Foro Internacional de Normas de Ingeniería de Software
de IEEE, Walnut Creek, CA, junio de 1999.
Koomen, T., M. Pol, Test Process Improvement, Addison-Wesley, Reading, MA, 1999.
Koomen, T., M. Pol, "Improvement of the test process using TPI", Informe técnico, IQUIP
Informatica BV, Diemen, Países Bajos, 1998,
http://www.iquip.nl.
Korel, B., I. Burnstein, R. Brevelle, “Pruebas de estrés basadas en postcondiciones en

certificación de componentes COTS”, Actas de la Primera Conferencia Internacional de
Certificación de Software Assurance, Washington, DC,
marzo de 1999.
Kozaczynski, W., J. Ning, “Reconocimiento automático de programas por concepto

reconocimiento”, Ingeniería de software automatizada, vol. 1, 1994, págs. 61–78.
Kung, D., Phsia, J. Gao, Testing Object-Oriented Software, IEEE Computer Society Press,
Laitenberger, O., K. El. Eman, T. Harbich, “Una replicación interna


| 603
comparación cuasi-experimental y lista de verificación y lectura basada en perspectiva

de documentos de código”, IEEE Transactions on Software Engineering,
vol. 27, núm. 5, mayo de 2001, págs. 387–421.
Laski, J., B. Korel, "Una estrategia de prueba orientada al flujo de datos", IEEE Trans.
Ingeniería de software, vol. 9, núm. 3, 1983, págs. 347–354.
Lee, L., El día que se detuvieron los teléfonos, Primus, Nueva York, 1992.
Legg, D., "Synopsis of COCOMO", Software Engineering Project Management,

segunda edición, R. Thayer, ed., IEEE Computer Society Press,
Los Alamitos, CA, 1997, págs. 230–245.
Linnenkugel, U., M. Mullerburg, "Criterios de selección de datos de prueba para

pruebas de integración (software)", Proc. Primera Conf. Internacional. Systems
Integration, abril de 1990, págs. 709–717.
Lyu, M., A. Nikora, "Aplicación más efectiva de modelos de confiabilidad", IEEE

Software, vol. 9, núm. 4, págs. 43–52, 1992.
Mantei, M., “El efecto de las estructuras del equipo de programación en las tareas de
programación”, Comunicaciones de la ACM, vol. 24, núm. 3, 1981,
págs. 106–113.
Marick, B., El oficio de las pruebas de software, Prentice Hall, Englewood

Acantilados, Nueva Jersey, 1995.
Marks, D., Testing Very Big Systems, McGraw-Hill, Nueva York, 1992.
Martin, J., W. Tsai, "Inspección N-fold: una técnica de análisis de requisitos", Comm.
ACM, vol. 33, núm. 2, 1990, págs. 225–232.
Masters, S., C. Bothwell, “Un marco de evaluación de CMM, versión 1.0,”

Informe Técnico, CMU/SEI-95-TR-001, Instituto de Ingeniería del Software,
Pittsburgh, Pensilvania, 1995.
Mays, R., "Prevención de defectos y gestión de calidad total", en Total

Gestión de calidad para software, G. Schulmeyer, J. McManus, eds.,
Van Nostrand, Reinhold, Nueva York, 1992.
McCabe, T., G. Schulmeyer, “El principio de Pareto aplicado al software

control de calidad”, en Handbook of Software Quality Assurance, segundo
Apéndice I
604 |
edición, G. Schulmeyer, J. McManus, eds., Van Nostrand Reinhold, Nueva York,

1992.
McCabe, T., C. Butler, "Medición y prueba de la complejidad del diseño"

CACM, vol. 32, núm. 12, 1989, págs. 1415–1425.
McCabe, T., "Una medida de complejidad", IEEE Transactions on Software

Engineering, Vol SE-2, No. 4, 1976, pp. 308–320.
McCall, J., P. Richards, G. Walters, Factors in Software Quality, Informe técnico

77CIS 02, General Electric, Command and Information Systems, Sunnyvale, CA,
1977.
McGregor, J., A. Kare, "Arquitectura paralela para pruebas de componentes de

software orientado a objetos", Proc. IX Conferencia Internacional de la Semana de
la Calidad, mayo de 1996.
Mills, C., "Pruebas de usabilidad en el mundo real", SIGCHI Bulletin, vol. 19, núm.
1, págs. 43–46, 1987.
Mills, H., M. Dyer, R. Linger, "Ingeniería de software de salas limpias", IEEE

Software, vol. 4, núm. 5, págs. 19–24, 1987.
Mills, H., “Sobre la validación estadística de programas informáticos”, Informe

técnico, FSC-72-6015, División de sistemas federales de IBM, Gaithersburg, MD,
1972.
Moore, J., "ISO 12207 y estándares de ciclo de vida de software relacionados",

http://www.acm.org.tsc/lifecycle.html.
Morell, L. "Perspectivas teóricas sobre las pruebas basadas en fallas", Proc.

Segundo taller sobre pruebas, verificación y análisis de software (IEEE/ACM/
SIGSOFT), Banff, Canadá, 1988, págs. 45–62.
Moseley, V., "Cómo evaluar herramientas de manera eficiente y cuantitativa", IEEE

Software, págs. 29–32, mayo de 1993.
Murphy, G., P. Townsend, P. Wong, “Experiencias con pruebas de grupos y clases”,

CACM, vol. 37, núm. 9, 1994, págs. 39–47.
Musa, J., "Perfiles operativos en la ingeniería de confiabilidad del software", IEEE

Software, vol. 10, núm. 3, págs. 14 a 32, 1993.

| 605
Musa, J., A. Ackerman, "Cuantificación de la validación del software: cuándo dejar de

probar", IEEE Software, vol. 6, núm. 3, mayo de 1989.
Musa, J., A Iannino, K. Olomoto, Aplicación de confiabilidad, medición y predicción

del software, McGraw-Hill, Nueva York, 1987.
Myers, G., "Un experimento controlado en pruebas de programas y recorridos/

inspecciones de código", CACM, 1978, págs. 760–768.
Myers, G., El arte de las pruebas de software, John Wiley, Nueva York, 1979.
Olsen, K., P. Stall Vinje, "Uso del modelo de madurez de pruebas en la planificación
práctica de pruebas y la evaluación posterior", Conferencia EuroSTAR98, Munich,
Alemania, 1998.
Osterweil, I., "Direcciones estratégicas en la calidad del software", ACM Computing

Surveys, vol. 28, núm. 4, 1996, págs. 738–750.
Ostrand, T., E. Weyuker, "Análisis de adecuación de pruebas basado en el flujo de

datos para lenguajes con punteros", Proc. Simposio ACM SIGSOFT sobre pruebas,
análisis y verificación, octubre de 1991, págs. 74–86.
Parrish, A., S. Zweben, "Análisis y refinamiento de las propiedades de adecuación de

datos de prueba de software", IEEE Trans. Ingeniería de software, vol. 17, núm. 7,
1991, págs. 565–581.
Paulk, M., C. Weber, B. Curtis, M. Chrissis, El modelo de madurez de la capacidad,

Addison-Wesley, Reading MA., 1995.
Paulk, M., M. Konrad, "Una descripción general del proyecto SPICE de ISO", American
Programmer, vol. 7, núm. 2, febrero de 1994, págs. 16–20.
Paulk, M., M. Konrad, "Una descripción general del proyecto SPICE de ISO", American
Programmer, vol. 7, núm. 2, 1994, págs. 16–20.
Paulk, M., B. Curtis, M. Chrissis y C. Weber, “Modelo de madurez de capacidad,

versión 1.1”, IEEE Software, vol. 10, núm. 4, 1993, págs. 18–27.
Paulk, M., C. Weber, S. Garcia, M. Chrissis, M. Bush, "Prácticas clave del modelo de
madurez de la capacidad, versión 1.1", Informe técnico, CMU/SEI-93-TR-25, Instituto
de ingeniería de software , Pittsburgh, Pensilvania, 1993.
Apéndice I
606 |
Sidra de pera. D., G. Kaiser, "Pruebas adecuadas y programación orientada a objetos", J.

Programación orientada a objetos, vol. 2, núm. 5, 1990, págs. 13 a 19.
Perry, W., Métodos eficaces para la prueba de software, John Wiley, Nueva York, 1995.
Pham, H., Pruebas y fiabilidad del software, IEEE Computer Society Press, Los Alamitos, CA,
1995.
Poston, R., Automatización de pruebas de software basadas en especificaciones, IEEE

Computer Society Press, Los Alamitos, CA, 1996.
Poston, R., "Las herramientas de prueba combinan lo mejor de lo nuevo y lo antiguo", IEEE
Software, vol. 12, núm. 2, 1995, págs. 122 a 126.
Poston, R., "Pruebas automatizadas a partir de modelos de objetos", Comm. de la ACM, vol.
37, núm. 9, 1994, págs. 48–58.
Poston, R., M. Sexton, “Evaluación y selección de herramientas de prueba”, IEEE Software,

págs. 33–42, mayo de 1992.
Pressman, R., Software Engineering: A Practitioner's Approach, quinta edición, McGraw-Hill,

Boston, MA, 2001.
Prowell, S., C. Trammell, R. Linger, J. Poore, Ingeniería de software para salas limpias,
Addison-Wesley, Reading, MA, 1999.
Puffer, J., A. Litter, “Planificación de acciones”, Boletín informativo del Consejo técnico de
ingeniería de software de IEEE, vol. 15, núm. 2, 1997, págs. 7 a 10.
Putman, D., "Uso del control estadístico de procesos con programas de prueba automatizados",
CrossTalk: The Journal of Defense Software Engineering, vol. 11, núm. 8, agosto de 1998,
págs. 16–20.
Quilici, A., “Un enfoque basado en la memoria para reconocer planes de programas,”
CACM, vol. 37, núm. 5, 1994, págs. 84–93.
Rakos, J., Gestión de proyectos de software para proyectos de tamaño pequeño a mediano,
Prentice Hall, Englewood Cliffs, NJ, 1990.
Rangaraajan, K., P. Eswar, T. Ashok, "Reevaluación de las clases C", Proc.

IX Conferencia Internacional de la Semana de la Calidad, mayo de 1996.

| 607
Rapps, S., E. Weyuker, "Selección de datos de prueba de software mediante la

formación de flujo de datos", IEEE Trans. Ingeniería de software, vol. 11, núm. 4,
1985, págs. 367–375.
Richards, F., Software informático: pruebas, modelos de confiabilidad y control de

calidad, Informe técnico, NPS-55RH74071A, Escuela de posgrado naval, Monterey,
CA, 1974.
Roper, M., Pruebas de software, McGraw-Hill, Londres, 1994.
Roper, T., Software Testing Management: Life on the Critical Path, Prentice Hall,
Englewood Cliffs, NJ, 1993.
Rubin, J., Manual de pruebas de usabilidad, John Wiley, Nueva York, 1994.
Sauer, C., D. Jeffery, L. Land, P. Yetton, "La efectividad de las revisiones técnicas
de desarrollo de software: un programa de investigación motivado por el
comportamiento", IEEE Transactions on Software Engineering, vol. 26, núm. 1,
2000, págs. 1 a 14.
Saxena, G., "Un marco para construir y evaluar modelos de madurez de procesos",
Ph.D. tesis, Instituto de Tecnología de Illinois, Chicago, IL, 1999.
Schell, D., "Resumen de una prueba típica de usabilidad", Proc. Conferencia

Internacional de Comunicaciones Profesionales, Winnipeg, págs. 117–125, 1987.
Schulmeyer, G., “Métricas de aseguramiento de la calidad del software”, en Handbook

of Software Quality Assurance, G. Schulmeyer y J. McManus, eds., Van Nostrand
Schulmeyer, G., “The move to zero defect software”, en Handbook of Software

Quality Assurance, segunda edición, G. Schulmeyer, J. McManus, eds., Van
Nostrand Reinhold, Nueva York, 1992.
Schulmeyer, G., "Lecciones de calidad de software de los expertos en calidad", en

Handbook of Software Quality Assurance, segunda edición, G. Schul meyer, J.
McManus, eds., Van Nostrand Reinhold, Nueva York, 1992.
Sheldon, F., K. Kavi, R. Tausworthe, J. Yu, R. Brettschneider, W. Everett, "Medición

de la confiabilidad: de la teoría a la práctica", IEEE Software, vol. 9, núm. 4, págs.
13 a 20, julio de 1992.
Shrum, S., "Elegir una representación de modelo CMMI", CrossTalk: Journal-

Apéndice I
608 |
nal del Departamento de Ingeniería de Software de Defensa, vol. 13, No. 7, julio de 2000,
págs. 6–7.
Smith, M., D. Robson, "Un marco para probar programas orientados a objetos", J.
Programación orientada a objetos, junio de 1992, págs. 45–53.
Shooman, M., Ingeniería de software: diseño, confiabilidad y administración, McGraw-Hill,

Nueva York, 1983.
Speed, J., "¿Qué quieres decir con que no puedo llamarme ingeniero de software?"
Software IEEE, noviembre/ diciembre. 1999, págs. 45–50.
Spencer, B., "Inspecciones de software en la aplicación", CrossTalk: Journal of Defense

Software Engineering, vol. 7, núm. 10, octubre de 1994, págs. 11 a 17.
Subramaniam, B., "Seguimiento efectivo de defectos de software: reducción de costos de

proyectos y mejora de la calidad", CrossTalk: The Journal of Defense Software Engineering,
vol. 12, No. 4, abril de 1999, págs. 3–9.
Sullivan, P., "Más allá de una concepción estrecha de las pruebas de usabilidad", IEEE
Transactions on Professional Communications, vol. 32, núm. 4, págs. 256–264, 1989.
Suwannasart, T., "Hacia el desarrollo de un modelo de madurez de prueba", Ph.D. tesis,

Thayer, R., ed., Software Engineering Project Management, segunda edición, IEEE Computer
Society Press, Los Alamitos, CA, 1997.
Tian, JL Peng, "Medición y modelado de confiabilidad basados en la ejecución de pruebas

para software comercial grande", IEEE Transactions on Software Engineering, vol. 21, núm.
5, 1995, págs. 405–414.
Tichy, W., “Diseño, implementación y evaluación de un sistema de control de revisiones”,

Proc. Sexta Conferencia Internacional. Ingeniería de software, 1982, págs. 58–67.
Tsai, B., S. Stobart, N. Parrington, I. Mitchell, "Un enfoque de prueba basado en el estado que
brinda cobertura de flujo de datos en pruebas de clases orientadas a objetos".
proc. Duodécima Semana Internacional de la Calidad Conf., mayo de 1999.
Voas, J., “Certificación: reducción de los costos ocultos de la mala calidad”, IEEE Software,
julio/agosto de 1999, págs. 22–25.

| 609
Voas, J., “Certificación de componentes de software listos para usar”, IEEE Computer, junio
de 1998, págs. 53–59.
Voas, J., "Un modelo de falla dinámica para el análisis de propagación e infección en
programas de computadora", Ph.D. Tesis, College of William and Mary en Virginia, mayo de
1990.
Wakid, S., D. Kuhn, D. Wallace, “Toward credible IT testing and certi fication”, IEEE Software,
julio/agosto de 1999, págs. 39–47.
Walton, G., J. Poore, C. Trammell, "Pruebas estadísticas de software basadas en un modelo

de uso", Software: práctica y experiencia, vol. 25, núm. 1, 1995, págs. 97–108.
Weiser, M., "Los programadores usan segmentos al depurar", CACM, vol. 25, núm. 7, 1982,
págs. 446–452.
Weller, E., "Uso de métricas para administrar proyectos de software", IEEE Software, vol. 9,
núm. 5, 1994, págs. 27–32.
Weller, E., "Aplicaciones prácticas del control estadístico de procesos", IEEE Software, vol.
14, núm. 3, 2000, págs. 48–55.
Weszka, J., P. Babel, J. Ferguson, "CMMI: camino evolutivo hacia la mejora de procesos
empresariales", CrossTalk: Journal of Department of Defense Software Engineering, vol. 13,
núm. 7, julio de 2000, págs. 8–11.
Weyuker, E., T. Ostrand, J. Brophy, R. Prasad, "Despejando una carrera profesional para
probadores de software", IEEE Software, vol. 17, núm. 2, marzo/abril de 2000, págs. 76–82.
Weyuker, E., “La evaluación de los criterios de adecuación de las pruebas de software
basadas en programas”, CACM, vol. 31, núm. 6, 1988, págs. 668–675.
Weyuker, E., "Axiomatización de la adecuación de datos de prueba de software", IEEE Trans.

Ingeniería de software, vol. 12, núm. 12, 1986, págs. 1128–1138.
Whittaker, J., “¿Qué son las pruebas de software? ¿Y por qué es tan difícil? Software IEEE,
enero/ febrero. 2000, págs. 70–79.
Wilde, N., "Probar sus objetos", The C Users Journal, mayo de 1993, págs. 25–32.
Apéndice I
610 |
Wigle, G., G. Yamamura, "Prácticas de un SEPG de nivel 5 de SEI CMM"

CrossTalk: The Journal of Defense Software Engineering, vol. 10, núm. 11, noviembre
de 1997, págs. 19–22.
Wilkins, B., Principios de prueba en circuitos y sistemas VSLI en silicio, A. Brown, ed.,
McGraw-Hill, Nueva York, 1991, págs. 222–250.
Zawacki, R., "How to pick eagles", Datamation Magazine, septiembre de 1995, págs.
115–16.
Zeitler, D., “Supuestos realistas para modelos confiables de software”, Proc.

Simposio Internacional Software Reliability Eng., IEEE Press, Los Alamitos, CA, págs.
67–74, 1991.
Zells, L., "Aprendizaje de las aplicaciones TQM japonesas a la ingeniería de software",

Gestión de calidad total para software, G. Schulmeyer, J.
McManus, eds., Van Nostrand Reinhold, Nueva York, 1992.
Zhu, H., "Un análisis formal de la relación subsumida entre los criterios de adecuación
de las pruebas de software", IEEE Transactions on Software Engineering, vol. 22,
núm. 4, 1996, págs. 248–255.
Zhu, H., P. Hall, J. May, "Cobertura y adecuación de la prueba de unidad de software",

Encuestas de computación ACM, vol. 29, núm. 4, 1997, págs. 366–427.
Zubrow, D., W. Hayes, J. Siegel, D. Goldenson, “Cuestionario de madurez”, Informe

técnico, CMU/SEI-94-SR-7, Instituto de ingeniería de software, Pittsburgh, PA, 1994.
ANEXO II
PLAN DE PRUEBA DE MUESTRA
Este apéndice contiene una versión abreviada de un plan de prueba del sistema que se
desarrolló con fines educativos. Ilustrará al lector el contenido de varios de los componentes
principales de un plan de prueba típico.
Los archivos adjuntos del plan de prueba no se incluyen en este ejemplo.
Para fines pedagógicos, el software que se probará es un sistema automatizado de
programación de cursos llamado "College Course Scheduler (CCS)", que está en desarrollo
para una universidad local. El cliente propuesto es South Central College. La universidad ofrece
programas de licenciatura y maestría, y tanto los cursos de pregrado como los de posgrado se
enumeran en su catálogo y horarios de cursos. El decano de la universidad es el principal
enlace con el grupo de desarrollo llamado Windy City Developers Corporation. Los usuarios
son los asistentes administrativos y presidentes departamentales, y el registrador del colegio.
antecedentes del proyecto
Actualmente, la programación de clases se realiza manualmente según las políticas de la

universidad. Cada instructor especifica por escrito los cursos que prefiere
Apéndice II
612 |
para enseñar durante el semestre dado, y sus preferencias de hora del día para
conferencias y sesiones de laboratorio. Las preferencias como entrada por parte del
instructor deben ser cursos válidos y tiempos de clase, que se especifican para cada
departamento. Las preferencias por escrito se envían al asistente administrativo del
departamento que realiza la programación manual. Si un instructor no presenta una lista
escrita de preferencias, los cursos se programan sin preferencias. El horario final
enumera cada curso ofrecido, el instructor, el tiempo de clase y el salón. Los artículos
no programables se enumeran en un informe separado. Se envían copias impresas del
programa final a cada instructor.
Al programar manualmente, el asistente administrativo debe asegurarse de que se

cumplan las siguientes reglas:
1. el salón de clases es lo suficientemente grande para albergar a los

estudiantes matriculados; 2. se otorga un espacio para una habitación a un
solo curso; 3. Los cursos de posgrado tienen preferencia sobre los de pregrado .
cursos;
4. No se pueden programar dos cursos de posgrado al mismo tiempo.
Descripción general del proyecto
Basado en entrevistas con grupos de clientes, el programador de cursos automatizado

funcionará de la siguiente manera. Las preferencias de los instructores para los cursos,
los horarios y las necesidades especiales deben enviarse por correo electrónico a los
asistentes administrativos de sus respectivos departamentos de manera oportuna (5
semanas después del semestre actual para programar el próximo semestre). Los
asistentes administrativos clasificarán las preferencias por orden de hora de recepción y
las almacenarán en un archivo formateado. Si un instructor no responde con necesidades
específicas antes de la fecha límite designada, los cursos se asignarán en función de los
horarios anteriores y estos cursos no tendrán preferencias de tiempo.
El sistema de programación de cursos tendrá una base de datos de salones para
cada edificio del campus, número de asientos en cada salón y características especiales
en cada salón, como una pantalla desplegable, micrófonos y equipo de TV para
transmisión remota. También tendrá una base de datos de instructores (y sus direcciones
de correo electrónico) y los cursos que han impartido durante un período de 5 años, las
franjas horarias (minutos totales) normalmente asignadas para cada uno de los
Plan de prueba de muestra | 613
clases impartidas en la universidad, y las inscripciones estimadas para los cursos.

Cuando el asistente administrativo (o presidente) envía el archivo de preferencias al final
de la quinta semana del semestre (para programar para el próximo semestre), el sistema
genera un informe que enumera todas las clases asignadas para este semestre, los
instructores, el período de tiempo de la clase y un número de salón. El algoritmo de
programación debe cumplir con las cuatro reglas descritas anteriormente. A cada miembro
de la facultad se le envía por correo electrónico una copia del informe y también recibe
una copia impresa para confirmar la corrección del cronograma y corregir cualquier error.
Los horarios de todos los departamentos se publican en el horario de cursos de toda la
universidad para cada semestre que se distribuye a todos los estudiantes.
Los asistentes administrativos, los jefes de departamento y el registrador pueden

consultar el sistema para recuperar información sobre las ofertas de cursos, las aulas, los
horarios de los cursos, etc. Los presidentes y asistentes administrativos pueden realizar
cambios en las bases de datos asociadas con sus departamentos.
Los horarios de los cursos que datan de un período de 7 años también se almacenarán
en la base de datos del sistema, y los usuarios también pueden consultar esta información.
El sistema debe ser fácil de usar; todos los usuarios deben tener conocimientos de
informática. El sistema debe ejecutarse en una estación de trabajo con acceso a un
servidor e imprimir informes en todo tipo de impresoras. Tendrá que interactuar con una
función de correo electrónico para recopilar preferencias y notificar a los instructores.
Requisitos del sistema
La siguiente es una descripción abreviada de los requisitos del proyecto.
CCS-REQ-1. Informes de programación

El sistema CCS debe producir un informe de programación para cada
departamento iniciado por una solicitud de un jefe de departamento o asistente
administrativo. El programa debe incluir cada curso, el número del curso, el
instructor, los horarios de las conferencias y el número de salón. Los cursos no
programados deben enumerarse en un informe separado junto con los motivos, por
ejemplo, un conflicto con otro curso, sin espacio con la capacidad adecuada. El
algoritmo de programación requiere información de una base de datos de números
de habitaciones para cada departamento, su capacidad y características especiales.
Bases de datos de cursos de los catálogos del departamento, horas de clase válidas e instruc
Apéndice II
614 |
también forman parte del sistema. El informe del horario departamental debe enviarse por correo
electrónico a la facultad correspondiente; se puede imprimir y también se guarda en un archivo para
usar en la impresión del programa de cursos de toda la universidad que reúne el registrador de la
universidad.
CCS-REQ-2. Entradas de preferencia El sistema
debe aceptar una entrada de archivo por parte del asistente o presidente administrativo del
departamento, enumerando los números de cursos ofrecidos para el semestre, los instructores, las
inscripciones esperadas y un conjunto de preferencias de tiempo de clase.
CCS-REQ-3. Consultas Los
usuarios deben poder consultar el sistema en busca de cursos, instructores, información de

salas y preferencias anteriores. El sistema también debe guardar la información de programación
de los últimos 7 años para que la inspeccionen los usuarios.
CCS-RE4. Notificación de correo electrónico

El sistema debe tener la capacidad de enviar por correo electrónico un informe de
programación a cada miembro de la facultad en cada departamento.
CCS-REQ-5. Interfaz de usuario El sistema
debe estar basado en menús y ser fácil de aprender. Se requiere una función de ayuda y los
usuarios deben recibir comentarios sobre las actividades del sistema. El sistema debe proporcionar
información útil en caso de errores del usuario.
CCS-REQ-6. Rendimiento La emisión
de un informe de programación para 20 cursos, cada uno con hasta 5 preferencias, no

debería llevar más de 1 minuto. Las consultas no deben tomar más de 1 minuto para recuperar la
información del sistema, suponiendo que hay 200 cursos enumerados en el catálogo de la
universidad (no todos se ofrecen cada semestre), 75 instructores (tiempo completo y tiempo parcial),
12 departamentos y 200 salas en la cámara pus. Actualmente hay 12 presidentes, un registrador y
24 asistentes administrativos. Se estima el número máximo de usuarios simultáneos
emparejado en 15. Solo una persona en cada departamento puede solicitar una ejecución de
programación en un momento dado. Se permiten actualizaciones a un cronograma departamental
hasta la fecha de finalización designada. Después de esa fecha, solo el registrador puede realizar
cambios.
Plan de prueba de muestra

| 615
CCS-REQ-7. Seguridad
El sistema debe ser seguro, y solo se deben otorgar usuarios autorizados
acceso. Hay dos niveles de usuarios: (i) el registrador del colegio que es el
administrador del sistema, y (ii) los asistentes administrativos departamentales
y presidentes. El registrador tiene todos los privilegios del sistema. Todos los usuarios pueden
generar cronogramas y formular consultas. Además, los usuarios de cada departamento pueden
mantener (agregar, eliminar, modificar) los datos apropiados en el
bases de datos asociadas a su respectivo departamento. Los usuarios no pueden modificar
información de departamentos externos. El registrador de South Central College es responsable
de agregar, eliminar y modificar registros de usuarios, y
asignación de privilegios de usuario.
CCS-REQ-8. Administración de base de datos

Los usuarios deben tener la capacidad de ver, modificar, agregar y eliminar información de
las bases de datos del sistema apropiadas para sus departamentos, y
nivel de acceso.
CCS-REQ-9. Restricciones de hardware y software

El sistema CCS debe ejecutarse en una red de estaciones de trabajo basadas en UNIX. Un
servidor central contendrá las bases de datos necesarias y consultas
capacidades.
PLANIFICADOR DE CURSOS UNIVERSITARIOS
(CCS)
PLAN DE PRUEBA DEL SISTEMA
por
COLEGIO CENTRO SUR
PREPARADO POR
Jane Smith, directora del grupo de pruebas
Corporación de Desarrollo de la Ciudad de los Vientos
15 DE ENERO DE 2001
Contenido
1. Identificador del plan de
prueba 2. Introducción 3.
Elementos a probar
4. Características a probar
5. Enfoque 6.
Criterios de aprobación/rechazo
7. Criterios de suspensión y reanudación 8. Resultados

de la prueba
9. Tareas de prueba
10. El entorno de prueba 11.
Responsabilidades 12. Necesidades de
personal y capacitación 13. Programación
14. Riesgos y contingencias 15. Costos de
prueba del sistema 16. Aprobaciones

1. Identificador del plan de prueba
CCS-WCD-2001-4
2. Introducción
Las siguientes secciones describen la naturaleza del sistema bajo prueba, los objetivos
de la prueba y el alcance. También se proporciona una lista de documentos relacionados.
2.1. Naturaleza del proyecto El

College Course Scheduler (CCS) se está desarrollando para la organización
cliente, South Central College. El sistema automatizará el proceso de programación
de cursos para la universidad, una tarea tediosa que antes era realizada manualmente
por los asistentes administrativos departamentales.
La programación de cursos es una tarea importante para la universidad que se realiza
cada semestre para ubicar a los instructores y estudiantes en las aulas que satisfagan
sus necesidades. El cliente espera que el sistema CCS realice la tarea de manera más
eficiente, precisa y segura que el sistema manual actual.
Liberará a los presidentes y asistentes administrativos de una tarea que consume
mucho tiempo y les permitirá dedicar su tiempo a otros asuntos importantes que ocurren
antes de que comience cada semestre.
La entrega de un sistema de software de alta calidad es importante para el cliente,
ya que dependerá del software para implementar una operación importante que es vital
para la institución. Windy City es una empresa de desarrollo de software relativamente
nueva (establecida en 1990), y es importante para nosotros entregar un sistema CCS
completamente funcional a tiempo, dentro del presupuesto y de alta calidad en términos
de funcionalidad, rendimiento, seguridad y solidez. . Una tasa muy baja de fracaso es
nuestra meta.
El proceso de prueba de Windy City ha sido evaluado en el nivel 3 de TMM, lo que
significa que tenemos un grupo de prueba dedicado y capacitado, existen políticas de
prueba, tenemos un proceso de planificación de prueba y estamos familiarizados con las
técnicas de prueba básicas. También contamos con el personal, la capacitación y las
herramientas para garantizar que el software CCS se evalúe de manera efectiva con
respecto a los atributos funcionales y de calidad requeridos.
2.2. Objetivos y alcance de la prueba del sistema

Este plan de prueba describe el entorno, las actividades, las tareas, las
herramientas, los costos y los cronogramas para probar el sistema College Course Scheduler (C
Apéndice II
618 |
El sistema está siendo desarrollado para South Central College por Windy City Development.
Nuestro objetivo para las pruebas del sistema es asegurar que:
•
todas las funcionalidades requeridas del CCS están implementadas y funcionan
correctamente de acuerdo con los requisitos del cliente;
• el software cumple con sus requisitos de rendimiento;
• el software es confiable y robusto; puede recuperarse con gracia de

fracasos;
• el software es fácil de usar y mantener;
• el software es seguro;
•
interactúa correctamente con el software y el hardware externos requeridos.
Se realizará un conjunto completo de pruebas del sistema, que incluyen:
pruebas funcionales (ingreso de preferencias, programación con preferencias, programación

sin preferencias, incapacidad para programar, generación de informes, consultas,
actualizaciones de bases de datos, enlaces de comunicación, administración del sistema)
pruebas de rendimiento (tiempo de respuesta para consultas e informes)
pruebas de estrés (número máximo de usuarios y número máximo de transacciones

programadas)
pruebas de seguridad (login y derechos de acceso).
2.3. Documentos relacionados

Los siguientes documentos se utilizan como fuentes de información para el desarrollo
de este plan de prueba.
Documento de requisitos de CCS (CCS-REQ-1-2001)

Plan de garantía de calidad del software CCS (CCS-SQA-P-1-2001)
Plantilla de plan de prueba del sistema Windy City (STP-T-5-1995)
Plan de gestión de la configuración de CCS (CCS-CMP-1-2001)
Documento de política y procedimiento de prueba de Windy City (TPP-2-1995)
Plan de Gestión del Proyecto CCS (CCS-SPMP-2-2001)

| 619
Documento de especificación de diseño CCS (CCS-DS-3-2001)

Plan Maestro de Pruebas CCS (CCS-MTP-3-2001)
Los siguientes son documentos relacionados con la prueba que se prepararán para
el sistema CCS y se pueden utilizar como fuentes de información para el sistema
planificadores de pruebas.
Plan de Pruebas de la Unidad CCS (CCS-UTP-4-2001)
Plan de prueba de integración CCS (CCS-ITP-4-2001)

Plan de prueba de aceptación de CCS (CCS-ATP-5-2001)
Plan de prueba de usabilidad CCS (CCS-UTP-12-3-2001)
3. Elementos a probar
Todos los elementos que constituyen el sistema College Course Scheduler (CCS)
serán probados durante la prueba del sistema para asegurar que trabajan juntos para
implementar los requerimientos del cliente. Estos elementos se enumeran a continuación con
su número de identificación, número de versión y biblioteca de código fuente.
Estos elementos constituyen la configuración comprobable para el software CCS.
NOMBRE BIBLIOTECA DE IDENTIFICADORES NÚMERO DE VERSIÓN
principal CCS-1 Main_lib 2.3
get_val_input_file CCS-2 Input_lib 1.1

validar_archivo CCS-3 Input_lib 1.2
validar_salas validar- CCS-4 Input_lib 1.2
cursos validar_lec_times CCS-5 Input_lib 1.3
get_course_index get- CCS-6 Input_lib 2.1
val_preferences CCS-7 Input_lib 2.2
form_course_record CCS-8 Input_lib 2.2

CCS-9 Input_lib 1.3
horario de cursos CCS-10 Input_lib 1.4

separados CCS-11 Input_lib 1.5
get_room_index CCS-11 Input_lib 1.5
sched_ug_prefs CCS-12 Input_lib 2.3
sched_gr_prefs CCS-13 Input_lib 2.4
sched_ug_no_pref CCS-14 Input_lib 2.3
sched_gr_no_prefs CCS-15 Input_lib 1.1
producción CCS-16 Output_lib 1.1

620 | Apéndice II
print_schedule e- CCS-17 Salida_lib 2.3

mail_schedule CCS-18 Salida_lib 1.5
print_no_schedule CCS-19 Output_lib 1.5
consulta CCS-20 Query_lib 2.1
form_query CCS-21 Query_lib 2.1
base de datos_admin CCS-22 Database_lib 1.1
sys_admin login CCS-23 Admin_lib 1.1
select_options ayuda CCS-24 Admin_lib 2.1

CCS-25 Admin_lib 2.1
CCS-26 Help_lib 2.2
4. Características a probar
La siguiente es una lista de las características que se probarán junto con su diseño.
identificador de especificación.
DISEÑO
IDENTIFICADOR DE ESPECIFICACIONES
RASGO
Programación con preferencias CCS-DS-3-2001-1
Programación sin preferencias CCS-DS-3-2001-2
Informe: impresión CCS-DS-3-2001-3
Informe: envío de correo electrónico CCS-DS-3-2001-4
Envío de preferencias CCS-DS-3-2001-5

preferencias CCS-DS-3-2001-6
Seguridad CCS-DS-3-2001-7
consultando CCS-DS-3-2001-8
Múltiples usuarios CCS-DS-3-2001-9
Informes de tiempo de respuesta CCS-DS-3-2001-10

Administración de base de datos CCS-DS-3-2001-11
Interfaz CCS-DS-3-2001-12
Ayudar CCS-DS-3-2001-13
Administracion del sistema CCS-DS-3-2001-14
Las pruebas de configuración y recuperación no se realizarán para esta versión

debido a limitaciones de tiempo. Las versiones futuras se someterán a dichas pruebas. usabilidad
las pruebas están cubiertas en el CCS-Usability Test Plan (CCS-UTP-12-3-2001).
5. Enfoque
Windy City Software es una organización de nivel 3 de TMM. Contamos con un grupo
de pruebas dedicado y capacitado, y contamos con los recursos y el entorno necesarios
para probar todo el software que desarrollamos para asegurar la alta calidad y el
cumplimiento de los requisitos de nuestros clientes. El sistema de calendario de cursos
universitarios se probará minuciosamente en varios niveles (consulte los documentos
relacionados en la Sección 2.3). Las pruebas a nivel del sistema serán exhaustivas y extensas.
Todos los artículos serán probados para asegurar que funcionen juntos correctamente; se
probarán todas las funciones y requisitos para garantizar que satisfagan las necesidades del
usuario. Se utilizará un rastreador de requisitos para probar para asegurar que todos los
requisitos estén cubiertos por al menos un caso de prueba. Las plantillas para el diseño de
pruebas y las especificaciones de los casos de prueba se encuentran en el documento de
Procedimiento y Política de Pruebas de Windy City TTP-2-1995. Los casos de prueba y las
especificaciones de diseño, así como cualquier script de prueba que se prepare, se guardarán
en un repositorio de prueba para su uso en versiones futuras.
5.1. Fuentes de datos de dominio de muestra y oráculos de prueba El decano

de South Central College ayudará a proporcionar entradas y salidas de programación
típicas, salas, cursos, inscripciones y otra información necesaria relacionada con la
universidad para la base de datos de prueba. También se describirán los patrones de edad
esperados. Se utilizarán los datos de entrada de los últimos seis semestres y los horarios
generados se compararán con los horarios existentes para ayudar a evaluar el sistema.
5.2. Personal
Dos ingenieros de pruebas, Prerek Patel y Sally Jordan, serán responsables del
diseño de casos de prueba, la ejecución de las pruebas y el registro de los resultados.
Serán supervisados por Jane Smith, directora de pruebas, y Jonathan Boyd, ingeniero de
pruebas principal. Todos tienen al menos 5 años de experiencia en pruebas de sistemas
similares y han recibido capacitación interna en la aplicación de técnicas de diseño de
pruebas y uso de herramientas de prueba.
5.3. Mantenimiento de
registros Todos los eventos observados durante la ejecución se registrarán en un
registro de prueba que se asociará con cada prueba. A todos los fallos se les asignará una gravedad.
Apéndice II
622 |
y registrarse en un informe de incidente/problema de prueba. Se hará un recuento del número de estos últimos
informes. Los formatos para los registros de prueba y los informes de incidentes/problemas de prueba se describen
en el documento de política y procedimiento de prueba de Windy City, TTP-2-1995. Todos los defectos revelados
durante la prueba del sistema se registrarán en el repositorio de defectos. El número de defectos encontrados (por
tipo y nivel de gravedad) por KLOC en cada tipo de prueba del sistema también se registrará para la evaluación
de la calidad. La productividad de los probadores se monitoreará utilizando una medida de la cantidad de casos
de prueba desarrollados por semana y la cantidad de casos de prueba ejecutados por semana.
5.4. Estado de la prueba
Las pruebas del sistema se controlarán mediante reuniones semanales sobre el estado de las pruebas.
Las tramas y los informes resumidos serán preparados por Jane Smith y Jonathan Boyd. La cantidad de requisitos
cubiertos por semana frente a la cantidad total de requisitos será uno de los elementos trazados para realizar un
seguimiento del progreso de las pruebas. Otros elementos que se trazarán incluyen el número de defectos de un
nivel de gravedad específico encontrado por semana. Las mediciones, gráficos y plantillas asociadas con los
informes de estado de las pruebas se describen en el documento estándar de procedimientos y políticas de
pruebas de Windy City, TTP-2-1995. Los costos de las pruebas serán monitoreados utilizando los valores ganados
como se describe en el documento de Procedimientos y Políticas de Pruebas de Windy City, TTP-2-1995.
5.5. Herramientas de prueba
Las siguientes herramientas se utilizarán para apoyar el esfuerzo de prueba del sistema.
Todo el personal de pruebas involucrado en este proyecto ha sido capacitado y tiene experiencia en el uso de
estas herramientas. La función de estas herramientas se describe en el documento de Políticas y Procedimientos
de Pruebas de Windy City, TTP-2-1995.
Herramientas de soporte para pruebas de sistemas CCS
Herramienta de gestión de la configuración
Herramienta de creación de configuración
Requisitos para probar el rastreador
Herramienta/comparador de captura-reproducción
Rastreador de defectos
Herramienta de prueba de rendimiento
Generador de carga

| 623
5.6. Criterios para detener la

prueba La decisión de detener la prueba del sistema se basará en el
seguimiento de (i) la cobertura de todos los requisitos y (ii) la cantidad de informes
abiertos de incidentes/problemas. Consideraremos que la prueba del sistema está
completa cuando todos los requisitos hayan sido cubiertos por al menos un caso
de prueba y no haya informes de incidentes/problemas con niveles de gravedad de
defectos asociados de 1 a 3 (impacto catastrófico-moderado). Aceptamos el riesgo
de que el software aún contenga defectos de bajo nivel de gravedad que tengan
un efecto mínimo en los usuarios.
5.7. Tipos de pruebas del sistema
PRUEBAS FUNCIONALES. Se evaluarán todos los requisitos

funcionales descritos en el Documento de requisitos de CCS (CCS-REQ-1-2001).
Se utilizarán las siguientes técnicas de diseño de pruebas de caja negra:
1. partición de clases de equivalencia y análisis de valores límite (ECP/

BVA);
2. prueba de transición de estado.
En general, las pruebas funcionales se diseñarán utilizando ECP/BVA para garantizar

que todas las clases de entradas legales (por ejemplo, cursos correctos, preferencias de
tiempo e instructores) sean aceptadas por el software y que las entradas ilegales sean
rechazadas. En el caso de este último, el sistema debe permanecer funcional. Se
ejercitarán y examinarán todas las clases posibles de salidas del sistema; por ejemplo,
se generarán e imprimirán todo tipo de informes de programación de varios tamaños y
para departamentos representativos. También se diseñarán casos de prueba que
indiquen ausencia de preferencias y aquellos que den lugar a conflictos o imposibilidad
de programar. También se evaluará la capacidad de enviar horarios por correo electrónico
a los miembros de la facultad de los departamentos representativos. El servicio de ayuda
se evaluará con solicitudes de ayuda para ingresar preferencias, generar consultas,
actualizar las bases de datos departamentales y generar un cronograma. La función de
administración del sistema se evaluará con respecto a agregar, eliminar y modificar la
información del usuario, y la asignación adecuada de los derechos de acceso del usuario.
Apéndice II
624 |
Se ejercerán y examinarán todos los estados efectivos del sistema y las transiciones
de estado; por ejemplo, el estado de preferencias de ingreso, el estado de generación de
informes, el estado de ingreso de un nuevo usuario. El diagrama de transición de estado del
sistema que se encuentra en el Documento de requisitos de CCS (CCS-REQ-1-2001) se
utilizará como fuente de información para el diseño de la prueba. Los datos de entrada de
las operaciones de programación manual también servirán como fuente para diseñar datos
de prueba, y los programas obtenidos de estas operaciones manuales se utilizarán como
oráculos para evaluar las salidas del sistema. Las especificaciones de diseño de prueba y
los casos de prueba se encuentran en los archivos adjuntos a este plan de prueba.
PRUEBAS DE RENDIMIENTO. Los requisitos críticos de rendimiento se expresan en

términos de tiempo necesario para la generación de informes y el tiempo de respuesta a las
consultas. El sistema se probará con preferencias y datos de cursos del departamento más
pequeño (filosofía) y el departamento más grande (informática) para determinar el tiempo
de generación del informe. Las consultas se formularán en función de las entradas típicas
proporcionadas por el decano de la universidad.
Se registrarán los tiempos de respuesta. El número promedio de transacciones y consultas
de programación simuladas también se utilizará para evaluar el desempeño con múltiples
usuarios.
PRUEBAS DE SEGURIDAD. Se realizarán pruebas utilizando nombres de usuario y

contraseñas legales e ilegales para garantizar que los usuarios no autorizados no tengan
acceso al sistema y que cada tipo de usuario tenga acceso a las funciones permitidas del
sistema apropiadas para su nivel de seguridad. También se diseñarán pruebas que
representen la adición, modificación y eliminación de usuarios. Los probadores intentarán
identificar cualquier trampilla que permita a usuarios no autorizados acceder al sistema.
Esto se implementará al permitir que Tom White y John Li, probadores no asignados
formalmente al grupo de prueba para este proyecto, sirvan como un "equipo tigre". En esta
capacidad, intentarán "irrumpir" en el software utilizando cualquier medio que ideen. Todos
los intentos serán documentados y los resultados registrados.
PRUEBAS DE ESTRÉS. Las pruebas de estrés son importantes para que el

sistema CCS descubra condiciones de carrera, interbloqueos, agotamiento de recursos
en patrones inusuales o no planificados y alteraciones en el funcionamiento normal del
sistema de software. Se ejercerán los límites del sistema y los valores umbral. Varios
usuarios departamentales pueden acceder al CCS al mismo tiempo, colocando un pesado
carga de programación de transacciones y consultas sobre los recursos del sistema. Es más
probable que esto ocurra durante la quinta semana de cada semestre, cuando se debe hacer
la programación para el próximo semestre. Se estima que el número promedio de usuarios es
de 15. Durante las pruebas de estrés, se simularán las entradas de 25 usuarios y se observará
el comportamiento del sistema. Las herramientas monitorearán el uso de la CPU, la cantidad
de llamadas al sistema, las interrupciones y otras características del sistema para determinar
si se han producido eventos anormales. Los parámetros del sistema se ajustarán para
maximizar la eficiencia.
PRUEBAS DE REGRESIÓN. Este no es un tipo de prueba del sistema, sino que

constituye una nueva prueba del código cuando se realizan cambios. Se realizarán pruebas
de regresión para el sistema CCS cuando se realicen cambios debido a reparaciones de
defectos. La prueba de regresión se realizará ejecutando todas las pruebas en la nueva versión
del código que se ejecutaron en la versión anterior y luego
comparando resultados. Se usará una herramienta de captura y reproducción para ejecutar y

volver a ejecutar las pruebas cuando sea posible, y su comparador asociado se usará para
comparar los archivos resultantes.
6. Criterios de aprobación/rechazo
El documento de política y procedimiento de prueba de Windy City, TTP-2-1995, describe una

escala de niveles de gravedad para fallas y fallas. La escala varía en valores de 1 a 4 donde 1
es una falla que tiene un efecto catastrófico en el sistema/usuarios hasta un valor de 4 que
indica un efecto mínimo en el sistema/usuario. Para el sistema de software CCS, una prueba
se considerará aprobada si la falla observada se califica en un nivel de 3 o 4. Eso significa que
la prueba puede continuar; sin embargo, todas las fallas y defectos asociados deben registrarse
y abordarse. Los informes de incidentes de prueba y los informes de problemas/defectos
deben completarse para todas las fallas observadas. Todas las fallas deben enviarse a
desarrollo y priorizarse para su reparación posterior, seguidas de pruebas de regresión por
parte del grupo de prueba.
7. Criterios de Suspensión/Reanudación
Normalmente, las pruebas se suspenderán al final de la jornada laboral. Todos los documentos
relacionados con la prueba deben enviarse a Jane Smith. La prueba es re-
Apéndice II
626 |
sumado el siguiente día de trabajo por la mañana. Además, las pruebas se suspenderán si:
(i) se observa una falla de nivel de severidad 1 o 2; (ii) el sistema no
puede aceptar un archivo de entrada válido; (iii) el sistema no puede producir
un cronograma; (iv) ocurre una falla de hardware.
Cuando se repara el defecto que causa la falla del software, la nueva versión del software se someterá
a una prueba de regresión. Si la nueva versión pasa la prueba de regresión, se pueden reanudar las pruebas
normales.
Si durante la prueba del sistema hay una falla de hardware, el probador notificará a los miembros del
personal apropiados y reanudará la prueba cuando se realicen las reparaciones, reiniciando desde el comienzo
de la prueba.
8. Entregables de prueba
Los siguientes elementos serán generados por el grupo de prueba del sistema para este proyecto. Una
descripción detallada de cada artículo está contenida en el documento de Procedimiento y Política de Pruebas
de Windy City, TTP-2-1995.
Plan de prueba del sistema (copia al cliente)
Especificaciones de diseño de prueba del sistema
Especificaciones del caso de prueba del sistema
Especificaciones del procedimiento de prueba del sistema
Registros de prueba del sistema
Informes de incidentes de prueba del sistema
Informe de resumen de prueba del sistema
Guiones de prueba (a partir del uso de la herramienta de captura y reproducción)
Datos de prueba
• archivos de entrada y salida, pantallas e informes resultantes de func
pruebas nacionales;
• datos de entrada y salida de pruebas de rendimiento y estrés;
• entradas y resultados de pruebas de seguridad;
•
Pantallas de entrada de consultas y resultados.
Las entradas para todas las pruebas se encuentran en los archivos adjuntos al plan de prueba del
sistema. El plan de prueba y los anexos del plan de prueba estarán bajo el control del Sistema de
gestión de la configuración de Windy City (consulte el Plan de gestión de la configuración de CCS,
CCS-CMP-1-2001).
9. Tareas de prueba
Se encuentra una lista de tareas de prueba en un archivo adjunto a este plan de prueba del sistema.
Se preparó mediante el desarrollo de una estructura de desglose del trabajo para las tareas
relacionadas con las pruebas requeridas por el proyecto CCS. El archivo adjunto enumera cada tarea
de prueba como se muestra a continuación, sus tareas predecesoras, las habilidades especiales
necesarias para llevar a cabo la tarea, la persona responsable, el esfuerzo requerido y la fecha de finalización.
Lista de tareas de prueba:
• preparar el plan de prueba y los anexos;
• preparar las especificaciones del diseño de la prueba;
• preparar las especificaciones del caso de prueba;
• entrevistas con el decano de South Central College para obtener ejemplos de horarios anteriores,
preferencias y otros datos relacionados con la universidad necesarios para preparar las entradas
de las pruebas y configurar la base de datos necesaria para las pruebas;
• seguimiento de informes de transmisión de pruebas;
• preparar guiones de prueba y configurar las herramientas;
• ejecutar las pruebas funcionales y registrar los resultados;
• ejecutar las pruebas de rendimiento y estrés; registro de resultados;
• ejecutar las pruebas de seguridad y regresión; registro de resultados;
• pruebas de regresión; registro de resultados;
• transmitir documentos relacionados con las pruebas a la gestión de configuración
grupo;
• supervisar al personal de pruebas y organizar las mediciones relacionadas con las pruebas;
Apéndice II
628 |
• prepararse para las reuniones sobre el estado de las pruebas y asistir a ellas;
• preparar el estado de la prueba y los informes resumidos de la prueba.
10. El entorno de prueba
REQUISITOS DE HARDWARE. Cinco estaciones de trabajo UNIX conectadas en red;

un servidor central con una capacidad de base de datos Oracle. La base de datos de la
prueba debe prepararse utilizando los datos de South Central College relacionados con los
departamentos, los cursos ofrecidos, los instructores, las salas, las inscripciones y las
necesidades especiales.
REQUISITOS DE LA HERRAMIENTA DE SOFTWARE. Para probar este sistema,

utilizaremos la herramienta de captura y reproducción actualmente en uso por el grupo de
prueba con una capacidad de comparación. Se utilizarán sondas de software desarrolladas
internamente para monitorear los atributos del sistema de hardware/software durante las
pruebas de rendimiento y estrés. Se utilizará un generador de carga para simular
interacciones de múltiples usuarios.
11. Responsabilidades
Dado que nuestra organización está en el nivel 3 de TMM, tenemos un grupo de prueba
dedicado. Los miembros del grupo de prueba responsables de probar el sistema College
Course Scheduler son:
• Jane Smith, directora de pruebas
• Jonathan Boyd, ingeniero principal de pruebas.
• Prerek Patel, ingeniero de pruebas
• Sally Jordan, ingeniera de pruebas
• Tom White y John Li no están formalmente asociados con el grupo de pruebas de este
proyecto, pero ayudarán en las pruebas de seguridad.
Los dos ingenieros de pruebas, Prerek Patel y Sally Jordan, serán responsables de la
especificación del diseño de la prueba, el diseño del caso de prueba y del procedimiento de
prueba, la ejecución de la prueba y el registro de los resultados. Serán supervisados por Jane Smith,
gerente de pruebas y Jonathan Boyd, ingeniero de pruebas líder, quienes también son
responsables de desarrollar el plan de pruebas, respaldar el diseño de casos de prueba,
administrar documentos y mediciones relacionados con las pruebas, administrar el estado de la prueba
reunión y desarrollo de informes de estado de la prueba y el resumen final de la prueba
reporte. También se reunirán con el decano de la universidad para recopilar los datos necesarios.
datos del curso e identificar escenarios de uso típicos. Un adjunto describe en detalle las
responsabilidades de prueba para estos miembros del personal.
El grupo de desarrollo de CCS es el encargado de dar respuesta a la prueba
informes de incidentes/problemas. Este grupo localizará, reparará defectos y registrará
defectos Devolverán el código reparado a los probadores para la regresión.
y otras pruebas requeridas. El grupo también apoya a los probadores con la tarea de
mantenimiento del repositorio de defectos,
12. Necesidades de personal y capacitación
Los miembros del personal necesarios para el esfuerzo de prueba del sistema se enumeran en la Sección
11 de este plan de prueba y en un anexo a este plan de prueba. Somos un TMM

organización de nivel 3. Todo nuestro personal de pruebas ha recibido capacitación en el
desarrollo del diseño de pruebas, casos de prueba y especificaciones de procedimientos de prueba. Ellos
tener la capacitación necesaria en el uso de herramientas de prueba y también haber tenido
experiencia en la planificación de pruebas, por lo que no se requiere capacitación adicional para este proyecto.
13. Programación
La duración de las tareas y los horarios se describen en detalle en un archivo adjunto a

este plan de prueba. El proyecto debe estar listo para la prueba de aceptación por
XX/AA/0Z. Esto permitirá instalar el sistema para que esté listo
para programar para el semestre de primavera de 200Z.
14. Riesgos y Contingencias
1. Se requiere que el decano de la universidad viaje mucho y es posible que no esté

disponible para el grupo de prueba. Si el decano de la universidad no está disponible para
interactuar con el equipo de prueba para proporcionar datos para la base de datos de prueba, el uso
información y horarios pasados, entonces el vicedecano estará disponible
al grupo y proporcionará la información necesaria.
Apéndice II
630 |
2. Conflicto de responsabilidades de dotación de personal. Es posible que Jonathan Boyd, el

ingeniero de pruebas principal, deba trabajar en un proyecto más urgente (ABC-51-17-03)
actualmente en producción. Sally Jordan tiene la experiencia y la capacitación para actuar como
ingeniera líder de pruebas si se presenta esta circunstancia. Sue Chan, miembro del grupo de
prueba organizacional, reemplazará a Sally como ingeniera de prueba.
3. Retrasos en el esfuerzo de prueba. Si el cronograma de prueba se ve afectado

significativamente por defectos de alto nivel de gravedad, se asignará un desarrollador adicional al
proyecto para realizar la localización de fallas. Además, Mike Smith, un probador experimentado,
tiene una tarea liviana durante este período de tiempo y estará disponible si se necesita potencia
adicional para el probador.
15. Costos de prueba del sistema
Nuestra organización ha sido evaluada en el nivel 3 de TMM con respecto a su proceso de prueba.
Esto implica que tenemos un proceso de prueba estable y predecible, un personal capacitado y
herramientas de prueba disponibles. Además, también tenemos una extensa base de datos de
costos de prueba de proyectos anteriores. El proyecto CCS es típico de las muchas aplicaciones
que hemos desarrollado en el pasado y para las cuales hemos recopilado datos relevantes
relacionados con las pruebas. Estimamos que los elementos de impacto de los costos de prueba
para el proyecto CCS serán similares a los de proyectos anteriores, y estamos seguros de que
podemos usar enfoques/heurísticas anteriores para ayudar a estimar los costos de prueba para el
sistema CCS. Nuestra confianza se basa
sobre:
• la naturaleza de este proyecto que no es complejo (no tiene misión- o

características críticas para la seguridad);
• la similitud con proyectos que hemos desarrollado con éxito en el pasado;
• nuestro proceso de prueba relativamente estable y nuestro grupo de prueba altamente calificado;
• Costos mínimos de herramientas y capacitación debido a nuestro nivel de madurez de pruebas.
En el pasado, hemos tenido éxito al usar el modelo COCOMO para estimar los costos totales
de este tipo de proyecto utilizando un conjunto de constantes generadas a partir de datos internos.
Luego aplicamos la heurística desarrollada por nuestra organización de que los costos de prueba
del sistema para este tipo de proyecto serán del 34,5 %.

| 631
del costo total del proyecto. En este caso, se ha obtenido una estimación
del coste global de todo el proyecto utilizando el modelo COCOMO y el
método Delphi. Los dos coinciden en un margen del 5,3 %. El costo total
del proyecto se estima en $ABC. Por lo tanto, el costo total de las
pruebas del sistema es ABC * .345 dólares.
16. Aprobaciones
Jane Smith
Gerente de prueba
FIRMA FECHA
cris padilla
Gerente de proyecto
FIRMA FECHA
tim rubin
Gerente de aseguramiento de la calidad del software
FIRMA FECHA
Esta página se dejó en blanco intencionalmente

ANEXO III
PRUEBA DEL MODELO DE MADUREZ
Parte 1:
EL CUESTIONARIO TMM
Parte 2:
ACTIVIDADES, TAREAS Y RESPONSABILIDADES DE TMM
Este apéndice tiene dos partes. La Parte 1 contiene el Cuestionario TMM

completo. La Parte 2 contiene el conjunto completo de Actividades, Tareas y
Responsabilidades (ATR) recomendadas para cada nivel del TMM.
PARTE 1 • EL CUESTIONARIO TMM
Esta parte del Anexo III contiene el contenido completo del documento
Cuestionario TMM, versión 2.0. El Cuestionario TMM tiene ocho secciones. El
contenido de cada sección se describe a continuación.
SECCIÓN 1. Instrucciones para el demandado.

SECCIÓN 2. Identificación y antecedentes del declarante.
SECCIÓN 3. Antecedentes organizativos.
634 | Apéndice III
No es No
Preguntas Sí No aplicar conocido
Comentarios
CUADRO AIII.1
Plantilla de cuestionario.
BLOQUE 4. Las preguntas del TMM. Para cada nivel de TMM hay:
(i) el conjunto de metas de madurez;

(ii) el conjunto de subobjetivos de madurez asociados con cada madurez
objetivo de la ciudad;
(iii) el conjunto de preguntas asociadas a cada objetivo de madurez.
Cada pregunta tiene cuatro respuestas posibles, como se muestra en el

formulario de plantilla de cuestionario que se muestra arriba (Tabla AIII.1).
El encuestado debe responder SÍ, NO, NO APLICA O
NO CONOCIDA. El encuestado también puede ingresar comentarios
relacionados con cada pregunta en el espacio proporcionado.
BLOQUE 5. Preguntas sobre la herramienta de prueba.
BLOQUE 6. Preguntas de tendencias de prueba.

SECCIÓN 7. Comentarios de los encuestados.
SECCIÓN 8. Glosario de términos.
Sección 1. Instrucciones para el Demandado
Lea y responda las siguientes preguntas detenidamente utilizando el conocimiento y la

experiencia obtenidos al trabajar en proyectos actuales en su
organización. Muchos de los términos técnicos se definen en el glosario
sección de este documento. Si desea comentar alguna de las preguntas
o califique sus respuestas, por favor use el espacio para comentarios proporcionado. Su
las respuestas se mantendrán confidenciales.
Prueba del modelo de madurez | 635
Para las preguntas de la meta de madurez que se encuentran en la Sección 4, cuatro posibles
Las opciones se ofrecen de la siguiente manera:
1. SÍ. Comprobar cuándo una práctica está bien establecida y consistente

realizado.
2. NO. Marque cuando la práctica no esté bien establecida o se realice de manera
inconsistente.
3. NO APLICA. Marque cuando tenga el conocimiento requerido del proyecto u organización,
pero crea que la pregunta no se aplica al proyecto u organización.
4. NO SE SABE. Marque cuando no esté seguro de cómo responder a esta pregunta, o no

tenga la información o la experiencia adecuadas.
Solo se debe seleccionar una de las opciones para cada pregunta y se deben considerar todas
las preguntas. Continúe con el resto del cuestionario y gracias por su ayuda.
Sección 2. Identificación y antecedentes del demandado
Al evaluar los datos de TMM, ayudará a los asesores a tener información sobre la experiencia
en ingeniería de software, las habilidades técnicas y las funciones actuales de cada encuestado.
1. Identificación del encuestado
Nombre
Posición
Nombre del proyecto
Teléfono
Correo electrónico
Fecha
2. Antecedentes del encuestado

¿Cuál describe mejor su puesto actual?
Gerente
Alta dirección o alta dirección
Gerente de proyecto
636 | Apéndice III
Gerente de prueba
Líder del grupo de aseguramiento de la calidad del software
Líder de grupo de procesos de ingeniería de software
Líder de subgrupo relacionado con la prueba (especifique el nombre del subgrupo)
Otro (por favor especifique)
Personal técnico
Ingeniero de software
Ingeniero de pruebas
Programador (desarrollador)
Analista
Miembro del grupo de aseguramiento de la calidad del software
Miembro del grupo de procesos de ingeniería de software
Miembro del subgrupo relacionado con la prueba (especifique)
Otro (por favor especifique)
3. Deberes y responsabilidades actuales
¿En qué actividades relacionadas con los exámenes participa activamente (puede marcar más de una)?
Política de pruebas y desarrollo de objetivos.
Planificación de pruebas
Diseño de casos de prueba y procedimientos de prueba

Ejecución de pruebas
Recopilación y análisis de mediciones relacionadas con las pruebas

Recopilación de datos de defectos
Mantenimiento de la base de datos de defectos.
Desarrollo de estándares
Revisiones y auditorías
Seguimiento del estado
Capacitación
Definición de métricas
Contratación y reclutamiento
Comunicaciones usuario/cliente
Control de procesos
Prevención de defectos
Transferencia tecnológica
Evaluación de procesos
Prueba del modelo de madurez

| 637
La mejora de procesos
Modelado e ingeniería de confiabilidad
Pruebas de usabilidad
Evaluación de herramientas
Proceso de reutilización
4. ¿Ha recibido alguna capacitación en TMM?
Sí (por favor describa)

No
5. ¿Cuál es el alcance de su experiencia en la industria del software?
Su organización actual Número de años

Experiencia general en la industria Número de años
Experiencia general de prueba Número de años
6. ¿Ha participado en otros tipos de evaluaciones de pruebas de software?
Sí (por favor describa)

No
Sección 3. Antecedentes organizacionales
1. Describa lo mejor que pueda el tipo de su organización.
Desarrolla software militar

Desarrolla software de aplicación
Desarrolla software de telecomunicaciones.
Garantía de calidad de software/pruebas de software/certificación
Otro (por favor describa)
2. ¿La mayoría (más del 50 %) del software desarrollado para

uso interno o externo?
Interno Externo no aplica
3. ¿Cuántas personas están empleadas en la organización evaluada?
Número total de empleados

Número dedicado al desarrollo y/o mantenimiento de software
Número involucrado en pruebas de software
638 | Apéndice III
4. Describa el porcentaje de personal involucrado en las pruebas de la siguiente manera:
Tiempo completo
Tiempo parcial
Consultores
5. ¿Las personas involucradas en la mejora de procesos en su organización son bien

respetadas con respecto a sus habilidades técnicas y de gestión?
(Por favor circule uno: 1 significa sin respeto y 5 significa muy respetado).
12345
6. ¿Están claramente definidas y respaldadas las responsabilidades para la mejora del

proceso de prueba? (Encierre en un círculo uno: 1 significa no definido ni
compatible, y 5 significa bien definido y compatible).
12345
7. ¿La organización evaluada tiene un grupo de procesos de ingeniería de software o

una unidad similar?
Sí No
8. ¿Cómo está organizado el grupo de prueba? (Por favor, seleccione uno)
Los desarrolladores hacen las pruebas
Grupo de prueba dentro del desarrollo, informe al gerente del proyecto

Grupo de prueba separado, informe al gerente de prueba
Parte del grupo de aseguramiento de la calidad del software
9. ¿Cómo caracterizaría generalmente la naturaleza de sus pruebas?

¿proceso?
Ad hoc
Informal
Algo estructurado
Altamente estructurado
10. ¿Con qué frecuencia los gerentes de proyectos deben enfrentar los desafíos de los
requisitos cambiantes de los clientes?
Nunca Poco frecuentemente Frecuentemente muy frecuentemente


| 639
Sección 4. Preguntas sobre el objetivo de madurez
Responda a cada una de las siguientes preguntas con una respuesta SÍ, NO, NO
APLICA o NO SE SABE. Se pueden ingresar comentarios después de cada pregunta.
• TMM Nivel 2: Definición de fase
META DE MADUREZ 2.1: DESARROLLAR META Y POLÍTICAS

DE PRUEBA Y DEPURACIÓN
El propósito de este objetivo es diferenciar claramente los procesos de prueba y

depuración. Se deben identificar los objetivos, tareas, actividades y herramientas para
cada uno. Deben asignarse responsabilidades para cada uno. La gerencia debe
establecer políticas para acomodar e institucionalizar tanto
procesos.
LAS SUBOBJETIVOS DE MADUREZ que respaldan este objetivo son:
2.1.1. Se forma un comité o grupo de toda la organización sobre pruebas y

depuración y se les proporciona financiación y apoyo. Los comités desarrollan,
documentan, distribuyen y respaldan procedimientos, metas y políticas para pruebas y
depuración. Los objetivos, políticas y procedimientos, una vez aprobados, se
implementan y se revisan periódicamente.
2.1.2. Las políticas/objetivos de prueba y depuración se reflejan en los planes
de proyecto/prueba.
2.1.3. Se establece un esquema básico de clasificación de defectos y se
establece un depósito de defectos básico.
2.1.4. Se identifican medidas simples de prueba y depuración.
y recogido.
PREGUNTAS
1. ¿Se han establecido comités de prueba y depuración?

2. ¿Se han implementado políticas, metas, actividades y herramientas para el proceso de prueba?
identificado, documentado y aprobado?
3. ¿Se han identificado, documentado y aprobado políticas, objetivos, actividades y
herramientas para el proceso de depuración?
640 | Apéndice III
4. ¿Está definido el proceso de prueba?
5. ¿Está definido el proceso de depuración?
6. ¿Se han distribuido al proyecto los documentos de política sobre pruebas?
gerentes y desarrolladores (probadores)?
7. ¿Se han distribuido al proyecto los documentos de políticas sobre depuración?
gerentes y desarrolladores (probadores)?
8. ¿Siguen los desarrolladores de software (probadores) una organización escrita?
política para las pruebas cuando la planificación de pruebas?
9. ¿Siguen los desarrolladores una política organizacional escrita para
depuración?
10. ¿Se utilizan medidas básicas para determinar el logro de las pruebas?
¿metas?
11. ¿Se utilizan medidas básicas para determinar el logro de la depuración?
¿metas?
12. ¿Se han desarrollado las políticas y objetivos de pruebas con aportes de
grupos de usuarios/clientes con respecto a sus necesidades?
13. ¿Se han desarrollado las políticas y objetivos de depuración con aportes y comentarios de los
grupos de usuarios/clientes con respecto a sus necesidades?
14. ¿Se ha desarrollado un esquema básico de clasificación de defectos?
15. ¿Se ha establecido un depósito de defectos?
16. ¿Los desarrolladores/evaluadores registran los defectos en el repositorio de manera consistente?

¿base?
17. ¿Se revisan periódicamente las políticas y objetivos de prueba/depuración?
META DE MADUREZ 2.2: INICIAR UN PROCESO DE

PLANIFICACIÓN DE PRUEBAS
El propósito de este objetivo es establecer un proceso de planificación de pruebas en toda la
organización. La planificación de pruebas implica establecer objetivos de prueba, analizar riesgos,
delinear estrategias y desarrollar especificaciones de diseño de prueba y casos de prueba. Un plan de
prueba también debe abordar la asignación de recursos, los costos y las responsabilidades de las
pruebas en los niveles de unidad, integración, sistema y aceptación.
2.2.1. Se forma un comité o grupo de toda la organización sobre planificación de pruebas
y se le proporciona financiación y apoyo. El Comité


| 641
desarrolla, documenta, distribuye y respalda procedimientos, objetivos y políticas para la planificación de
pruebas. Los objetivos, políticas y procedimientos, una vez aprobados, se establecen y se revisan
periódicamente.
2.2.2. Las plantillas del plan de prueba para todos los niveles de prueba se desarrollan,
registran y distribuyen a los gerentes de proyecto y desarrolladores/evaluadores para su uso en proyectos
organizacionales. Otros documentos requeridos relacionados con la prueba se identifican y prescriben de
acuerdo con la política de la organización.
2.2.3. Hay capacitación técnica disponible para cubrir el uso de plantillas de planes de prueba
y el desarrollo de planes de prueba.
2.2.4. Se implementa un procedimiento para incluir los requisitos generados por el usuario
como entradas al plan de prueba.
2.2.5. Se evalúan y aplican las herramientas básicas de planificación y las mediciones de
prueba.
PREGUNTAS
1. ¿Se ha creado un comité o grupo de planificación de pruebas en toda la organización?

¿establecido?
2. ¿Existe una política organizacional y procedimientos para la prueba?
¿planificación?
3. ¿Se han distribuido y aprobado la política y los procedimientos?
4. ¿Existe el apoyo y la financiación adecuados para la planificación de pruebas para todos
proyectos?
5. ¿Se utilizan las metas/los objetivos de la prueba como base para la planificación de la prueba?
6. ¿Se han desarrollado y distribuido plantillas de planes de prueba al proyecto?
gerentes?
7. ¿Existen herramientas de planificación adecuadas disponibles para la planificación de pruebas?
8. ¿Se ha capacitado a los gerentes de proyectos en el uso de plantillas y planes?
herramientas de ning?
9. ¿Se ha capacitado a los desarrolladores (probadores) en el uso de plantillas y herramientas de
planificación?
10. ¿Los desarrolladores (probadores) están debidamente capacitados para desarrollar especificaciones
de prueba, diseños de prueba y casos de prueba para el plan de prueba?
11. ¿Se tienen en cuenta los riesgos relacionados con las pruebas al desarrollar planes de prueba?
12. ¿Están disponibles las estimaciones (tiempo, presupuesto, herramientas) de proyectos anteriores para su
uso en la planificación de pruebas?
13. ¿Se realiza la planificación de pruebas a nivel de unidad?

Apéndice III
642 |
14. ¿La planificación de las pruebas se realiza a nivel de integración?
15. ¿Se realiza la planificación de las pruebas a nivel del sistema?
16. ¿Se realiza la planificación de pruebas en el nivel de aceptación?
17. ¿Existe un procedimiento para solicitar la opinión del usuario/cliente para la planificación de pruebas
cuando corresponda (p. ej., en la planificación de pruebas de aceptación)?
18. ¿Los desarrolladores (probadores) tienen la oportunidad de aportar información al plan de prueba en todos
los niveles?
19. ¿Se revisa el proceso de planificación de pruebas de forma periódica y/o basada en eventos?
20. ¿Están definidos en los documentos organizativos otros elementos relacionados con las pruebas, como los
informes de transmisión de pruebas, los registros de pruebas, los informes de incidentes de pruebas y los
informes resumidos de pruebas?
21. ¿Se completan para cada proyecto otros elementos relacionados con las pruebas, como informes de
transmisión de pruebas, registros de pruebas, informes de incidentes de pruebas e informes resumidos
de pruebas?
22. ¿Apoya la administración las interacciones entre los gerentes de proyectos (pruebas), los desarrolladores
(probadores), los diseñadores y los analistas para respaldar la planificación de las pruebas?
23. ¿Se especifican las medidas de prueba básicas en el plan de prueba en todos los niveles?
24. ¿Los desarrolladores (probadores) recopilan y almacenan información básica relacionada con las pruebas?
¿mediciones?
25. ¿Se utilizan las medidas de prueba básicas para garantizar que se cumplan los objetivos básicos de prueba?
se han cumplido?
META DE MADUREZ 2.3: I NSTITUCIONALIZAR

TÉCNICAS Y MÉTODOS BÁSICOS DE PRUEBA
El propósito de este objetivo de madurez es mejorar la capacidad del proceso de prueba mediante la aplicación
de técnicas y métodos de prueba básicos. En las políticas y planes de prueba se debe especificar claramente
cómo y cuándo se aplicarán estas técnicas y métodos, y cualquier herramienta básica que los apoye. Varias
técnicas y métodos básicos que se utilizan a menudo en el proceso de prueba son estrategias de diseño de
prueba de caja negra y caja blanca, el uso de una matriz de validación de requisitos y la división de la prueba
basada en la ejecución en subfases, como prueba unitaria, de integración, de sistema y de aceptación. .
Algunas herramientas de prueba que respaldan el uso de estas técnicas y métodos son analizadores estáticos
y dinámicos, analizadores de cobertura, generadores de datos de prueba y herramientas de verificación de
errores.
2.3.1. Se forma un comité o grupo de toda la organización sobre tecnología de prueba

y se le proporciona financiación y apoyo. El comité estudia, evalúa y recomienda un conjunto de
técnicas y métodos de prueba básicos, y un conjunto de formularios simples y herramientas para
respaldarlos. Desarrolla políticas, procedimientos y documentos relevantes, y estos se distribuyen.
Una vez aprobados, se ponen en marcha y se revisan periódicamente.

2.3.2. La capacitación técnica y las herramientas básicas están disponibles para
respaldar el uso de técnicas y métodos de prueba.
2.3.3. Las pruebas de software se planifican e implementan en la unidad,
niveles de integración, sistema y aceptación según política.
2.3.4. Las estrategias de prueba básicas (caja blanca/negra), las técnicas y los métodos
se utilizan en toda la organización para diseñar casos de prueba. Se promueve la interacción entre
los desarrolladores (evaluadores) y otro personal técnico (p. ej., diseñadores y analistas de
requisitos) para identificar problemas de capacidad de prueba, fomentar el desarrollo de
representaciones de software útiles para los métodos de prueba de caja blanca/negra y para admitir
múltiples niveles de prueba.
PREGUNTAS
1. ¿Se ha formado un comité o grupo para evaluar y recomendar un conjunto de técnicas, métodos
y herramientas de prueba básicos?
2. ¿Se han documentado, distribuido y distribuido las recomendaciones del grupo?
uted, y aprobado?
3. ¿Se han incluido herramientas y técnicas básicas en las políticas de prueba?
4. ¿Se han diseñado formularios y plantillas apropiados para apoyar las técnicas de prueba básicas?
5. ¿Proporciona la alta dirección los recursos adecuados para respaldar el uso de técnicas y
métodos de prueba básicos, así como herramientas de prueba básicas?
6. ¿Se ha capacitado a los desarrolladores (probadores) para aplicar las herramientas, formularios
y métodos básicos?
7. ¿Se aplican técnicas y métodos de prueba básicos en una organización?

base nacional?
8. ¿Se aplican las herramientas básicas de prueba en toda la organización?
9. ¿Se revisan periódicamente las técnicas y métodos de prueba básicos?

644 | Apéndice III
10. ¿Incluyen las declaraciones de política de pruebas el requisito de multinivel?
¿pruebas?
11. ¿Se planifican e implementan las pruebas en varios niveles (unidad, integración, sistema, etc.)?
12. ¿Están las técnicas y herramientas de prueba básicas descritas en el estado de la política?
mentos aplicados en todos los niveles de prueba?
13. ¿Las técnicas y herramientas de prueba que se aplicarán se describen en múltiples
planes de prueba de nivel?
14. ¿Apoya la alta dirección la interacción entre analistas, diseñadores y desarrolladores (probadores)
para garantizar que se aborden los problemas de las pruebas?
por estos grupos?
• TMM Nivel 3: Integración

META DE MADUREZ 3.1: ESTABLECER UNA
ORGANIZACIÓN DE LA PRUEBA
El propósito de esta meta de madurez es identificar y organizar un grupo de
personas altamente calificadas que se encargan de las pruebas. El grupo de prueba debe
ser responsable de la planificación de pruebas, ejecución y registro de pruebas,
estándares, métricas de prueba, base de datos de prueba, reutilización de prueba, seguimiento de prueba y
evaluación. El grupo también debe ser responsable de mantener el depósito de defectos.
3.1.1. Se forma un comité de toda la organización para trazar el
marco estructural para la organización o el grupo de pruebas. Se proporciona liderazgo, apoyo y
financiación para el grupo de prueba. Roles y responsabilidades,
y se definen trayectorias profesionales para el grupo de prueba.
3.1.2. Se establece un grupo de prueba para toda la organización a través de
se definen los esfuerzos del grupo de trabajo y su funcionalidad y posición en la jerarquía de informes.
Se asignan miembros bien capacitados y motivados a
el grupo de prueba. Se establecen vínculos de comunicación de usuario/cliente, desarrollador y SQA
bien definidos con el grupo de prueba. El grupo de prueba es revisado
periódicamente por la dirección.
3.1.3. Hay capacitación disponible para asegurar que el grupo de prueba tenga la
experiencia técnica y aplicar herramientas y técnicas de prueba apropiadas,
evaluar nuevas herramientas y técnicas, y planificar el esfuerzo de prueba.

PREGUNTAS
1. ¿La organización reconoce las pruebas como una actividad profesional?
2. ¿Se ha formado un comité o grupo de trabajo para trazar un marco
para una organización de prueba o grupo de prueba?
3. ¿Existe una organización de prueba de software en toda la organización responsable de probar cada
proyecto?
4. ¿Hay una trayectoria profesional que puedan seguir los miembros del grupo de prueba?
5. ¿Se proporcionan recursos adecuados para la organización de pruebas de software?
6. ¿Los miembros de la organización de prueba de software están capacitados en pruebas?
métodos, planificación de pruebas, teoría, herramientas y técnicas?
7. ¿Se compensa adecuadamente a los probadores con respecto a otro software?
ingenieros?
8. ¿Están definidos los roles y responsabilidades del grupo?
9. ¿Las actividades del grupo están documentadas y reportadas a la alta dirección?
10. ¿El grupo de pruebas de software de la organización se coordina con el grupo de SQA para mejorar
la eficacia de las pruebas y mejorar la calidad del software con respecto a los requisitos del usuario?
11. ¿El grupo de prueba tiene una ruta de comunicación con los desarrolladores para la planificación de
pruebas, el diseño de pruebas y la reparación del código cuando surgen problemas?
12. ¿Se solicitan las inquietudes de los clientes como información para evaluar las políticas de la organización?
13. ¿Existe un mecanismo formal para la interacción probador-usuario/cliente?
14. ¿La gerencia revisa periódicamente el grupo de prueba?
META DE MADUREZ 3.2: ESTABLECER UN

PROGRAMA DE CAPACITACIÓN TÉCNICA
El propósito de esta meta de madurez desde el punto de vista del grupo de prueba es asegurar que haya
personal calificado disponible para realizar las tareas de prueba. El programa de formación formal se
basa en una política de formación. Requiere especificar objetivos de capacitación y desarrollar planes y
materiales de capacitación específicos.
Las clases de capacitación están disponibles para todos los miembros del personal. El impacto del
programa de capacitación en los probadores es capacitarlos en técnicas, métodos y herramientas de
prueba de última generación. También prepara a los evaluadores para la planificación de pruebas, para
tareas que implican la integración de las pruebas en el ciclo de vida del software, para el proceso de
revisión y para identificar y priorizar los riesgos relacionados con las pruebas. En los niveles más altos
de TMM, prepara a los probadores para el control del proceso de prueba, una medida de prueba.
Apéndice III
646 |
programa de aseguramiento, pruebas estadísticas, planificación de acciones de procesos de

prueba, modelado de confiabilidad y otras actividades de prueba de nivel superior.
3.2.1. Un comité o grupo de toda la organización sobre

la formación se establece con financiación y recursos. la formación técnica
El comité desarrolla, obtiene la aprobación y distribuye el documento de política de capacitación
organizacional. La política y el programa de capacitación se revisan periódicamente.
3.2.2. Se establece y habilita un grupo de capacitación interno

con liderazgo, herramientas e instalaciones establecidas de acuerdo con la política. Él
grupo desarrolla un programa de entrenamiento. Los objetivos y planes de capacitación son
desarrollados por el grupo con aportes de los gerentes de proyectos/pruebas. Los materiales de
capacitación son desarrollados por el grupo y los miembros del grupo sirven como capacitación.
instructores
PREGUNTAS
1. ¿Se ha establecido un comité o grupo de capacitación técnica con

financiación y apoyo?
2. ¿Están documentadas, desglosadas, las políticas y metas relacionadas con la capacitación técnica?
tributado y aprobado?
3. ¿La organización sigue una política organizacional escrita para cumplir
sus necesidades de formación?
4. ¿Se ha establecido un programa de capacitación técnica para mejorar las habilidades?

para el cuerpo tecnico?
5. ¿Se desarrollan planes de capacitación con aportes de los gerentes de proyectos/pruebas?
6. ¿Se proporcionan los recursos adecuados para implementar la capacitación técnica?
¿programa?
7. ¿La gerencia recomienda cursos de capacitación para el personal técnico sobre
¿una base regular?
8. ¿Los miembros del grupo de capacitación desarrollan materiales de capacitación y sirven como
instructores para los cursos de formación?
9. ¿Los participantes en el grupo de prueba reciben la capacitación necesaria para
desarrollando las habilidades y adquiriendo los conocimientos necesarios para realizar sus
tareas de prueba?
10. ¿Se utilizan medidas para determinar la calidad y eficacia de
el programa de entrenamiento?
11. ¿Se revisan periódicamente las actividades del programa de capacitación?
META DE MADUREZ 3.3: I NTEGRAR PRUEBAS

EN EL CICLO DE VIDA DEL SOFTWARE
El propósito de este objetivo de madurez es promover el desempeño de las pruebas
actividades en paralelo con otras actividades de la fase del ciclo de vida que comienzan temprano en
el ciclo de vida del software. Una organización madura no retrasa las actividades de prueba hasta que
se completa la codificación. Ejemplos de buenas prácticas promovidas por
este objetivo son: la planificación de pruebas maestras y del sistema se inicia temprano en la vida
ciclo en el momento de los requisitos, y la integración y la planificación de pruebas unitarias son
iniciado en tiempo de diseño detallado. Una variación del modelo V es utilizada por
gerentes, probadores y desarrolladores para guiar las actividades de integración. Los recursos que
respaldan la integración del esfuerzo de prueba son, por ejemplo,
personal calificado, modelos de ciclo de vida de apoyo, estándares y documentos de política,
planificación y programación adecuadas.
3.3.1. Se establece un comité o grupo de toda la organización sobre la integración de las
actividades de prueba y se le proporciona financiación y
apoyo. El comité desarrolla, documenta, distribuye y apoya
procedimientos, metas y políticas para la integración de pruebas. Los objetivos, políticas y
los procedimientos, una vez aprobados, se implementan y se revisan periódicamente.
3.3.2. Las actividades de prueba están integradas en el ciclo de vida del software.
usando el modelo de ciclo de vida adoptado siguiendo el organigrama escrito
política. Las políticas de planificación de proyectos y pruebas se ajustan para promover la integración
de las pruebas. Los estándares y las pautas de calidad se desarrollan para los productos de trabajo
relacionados con las pruebas producidos en cada fase del ciclo de vida.
3.3.3. Se proporcionan recursos y capacitación para respaldar la integración de las
actividades de prueba en el ciclo de vida del software.
PREGUNTAS
1. ¿Se ha establecido un grupo o comité para apoyar la integración de
actividades de prueba?
Apéndice III
648 |
2. Tiene un modelo de ciclo de vida de software que admite la integración de pruebas

actividades han sido adoptadas?
3. ¿Se han identificado las actividades de prueba y los requisitos de prueba asociados con
cada fase del ciclo de vida?
4. ¿Se ha desarrollado, aprobado y distribuido una política de integración y un conjunto de
procedimientos documentados basados en el modelo adoptado?
5. ¿Se proporciona capacitación adecuada para la integración del esfuerzo de prueba?
6. ¿Se proporcionan los recursos adecuados para la integración del esfuerzo de prueba?
7. ¿Se revisan periódicamente las actividades para integrar las pruebas en el ciclo de vida
del software?
8. ¿Se han modificado los procedimientos de planificación de proyectos y pruebas para
cumplir y adaptarse a las actividades de integración?
9. ¿Cada proyecto sigue una política organizacional escrita para la integración de los
esfuerzos de prueba?
10. ¿Han desarrollado la organización de pruebas y el grupo SQA un conjunto de estándares
documentados para todos los productos de trabajo de prueba producidos en cada fase
del ciclo de vida?
11. ¿Existe una política para manejar el incumplimiento de las normas?
META DE MADUREZ 3.4: C ONTROL Y

SEGUIMIENTO DEL PROCESO DE PRUEBA
El propósito de este objetivo de madurez es promover el desarrollo de un sistema de

seguimiento y control para el proceso de prueba para que las desviaciones de los planes de
prueba puedan detectarse lo antes posible y la gerencia pueda tomar medidas efectivas para
corregir las desviaciones. Tener esta capacidad respalda un proceso de prueba que es más
probable que se realice a tiempo y dentro del presupuesto. El control y la supervisión de las
pruebas también dan visibilidad al proceso de pruebas, respaldan las pruebas como una
actividad profesional y pueden conducir a productos de software de mayor calidad.
3.4.1. Se forma un comité o grupo de toda la organización sobre el control y

seguimiento de las pruebas y se le proporciona financiación y apoyo. El comité desarrolla,
documenta, distribuye y apoya
procedimientos, metas, políticas y medidas para controlar y monitorear las pruebas. Las metas,
políticas, procedimientos y medidas, una vez
aprobados, se ponen en marcha y se revisan periódicamente.
3.4.2. Mediciones relacionadas con la prueba para controlar y monitorear
se recogen para cada proyecto. El informe del estado de la prueba se realiza en un
de forma regular para cada proyecto de acuerdo con la política. Los planes de contingencia son
desarrollado, registrado y documentado junto con planes de prueba para cada proyecto para su uso
cuando el seguimiento del estado muestra que las pruebas se desvían significativamente
de lo planeado.
3.4.3. Capacitación, herramientas y otros recursos están disponibles para
apoyar el control y seguimiento de la prueba.
PREGUNTAS
1. ¿Se ha establecido un comité o grupo para apoyar el monitoreo?
y el control de la prueba?
2. ¿Existe una política organizacional para el seguimiento y control de
¿pruebas?
3. ¿Hay herramientas y capacitación disponibles para apoyar el control y monitoreo?
ing de una prueba?
4. ¿Se ha desarrollado un conjunto de medidas básicas para seguir el progreso de la prueba?

multado y distribuido?
5. ¿Los gerentes de proyectos y los gerentes de pruebas trabajan juntos para controlar
y planes de seguimiento?
6. ¿Cada proyecto sigue una política organizacional escrita para el control
ling y el seguimiento del proceso de prueba?
7. ¿Se desarrollan planes de contingencia relacionados con las pruebas para cada proyecto para apoyar
control de puertos de una prueba?
8. ¿La organización recopila y almacena datos de seguimiento y control de pruebas?
métricas para cada proyecto?
9. ¿La información sobre el estado de las pruebas se basa en los hallazgos de las reuniones regulares
sobre el estado y se informa a los gerentes de pruebas, proyectos y niveles superiores de forma periódica?
¿base?
10. ¿La organización de pruebas, con el apoyo de la gestión del proyecto,
desarrollar planes de contingencia para riesgos de prueba?
11. ¿Están los elementos de prueba bajo el control de un sistema de gestión de configuración?
12. ¿Son las actividades para controlar y monitorear el proceso de prueba
revisada periódicamente?
650 | Apéndice III
• TMM Nivel 4: Gestión y Medición
META DE MADUREZ 4.1: ESTABLECER UN

PROGRAMA DE REVISIÓN EN TODA LA ORGANIZACIÓN
Las revisiones son un tipo de técnica de prueba que se puede utilizar para eliminar defectos
de los artefactos de software. Lograr este objetivo de madurez da como resultado un
programa de revisión que ayuda a una organización a identificar, catalogar y eliminar
defectos de los artefactos de software de manera efectiva y temprana en el ciclo de vida del
software. Las revisiones también respaldan las evaluaciones de calidad de los elementos
relacionados con el software. Ejemplos de elementos que pueden revisarse son documentos
de requisitos, documentos de diseño, planes de prueba y especificaciones de casos de prueba.
4.1.1. Se forma un comité o grupo de toda la organización que se enfoca en

desarrollar un programa de revisión y se le proporciona financiación y apoyo. El comité
desarrolla, documenta, distribuye y apoya los procedimientos, objetivos, políticas y medidas
para las revisiones de los productos de trabajo de software resultantes de todas las fases
del ciclo de vida del software. Los objetivos, políticas, procedimientos y medidas, una vez
aprobados, se implantan y revisan periódicamente 4.1.2. El personal está capacitado para
que comprenda y siga las políticas, prácticas y procedimientos de revisión adecuados.
También están capacitados para recopilar, almacenar y aplicar mediciones de
revisión.
4.1.3. Los artefactos de software se revisan para cada proyecto como se describe
en la política de revisión y se refleja en el plan del proyecto. Las mediciones de revisión se
recopilan y aplican para mejorar la calidad del producto y del proceso.
PREGUNTAS
1. Tiene un comité o grupo de toda la organización sobre el proceso de revisión
establecido, con financiación y recursos?
2. ¿Se ha desarrollado, distribuido y aprobado una política de revisión en toda la organización?
3. ¿Se reflejan las preocupaciones de los clientes en la política de revisión?
4. ¿Se han implementado procedimientos de revisión, mediciones y sistemas de informes?

definido, documentado y aprobado?
5. ¿Se proporcionan los recursos adecuados (p. ej., financiación, materiales de revisión, herramientas)
para implementar el programa de revisión?

6. ¿Están capacitados los revisores y los líderes de revisión?
7. ¿Cada proyecto sigue la política organizacional escrita para per
formar reseñas?
8. ¿Los cronogramas del plan del proyecto reflejan las necesidades de revisión?
9. ¿Se planifican las revisiones y se informan y documentan los resultados?
10. ¿Se revisan los productos de trabajo de software/prueba desarrollados en diferentes fases del ciclo
de vida del software?
11. ¿Los defectos encontrados durante las revisiones se almacenan en un repositorio de defectos?
12. ¿Se rastrean las acciones relacionadas con los defectos identificados en las revisiones hasta que
se resuelven?
13. ¿Se recopilan y analizan las medidas relacionadas con la revisión?
14. ¿Se recopilan mediciones relacionadas con productos de trabajo de software durante
ing las críticas?
15. ¿Se evalúa periódicamente el programa de revisión?
META DE MADUREZ 4.2: ESTABLECER UN PROGRAMA

DE MEDICIÓN DE PRUEBAS
El propósito de un programa de medición de pruebas es identificar, recopilar, analizar y aplicar medidas
para ayudar a una organización a determinar el progreso de las pruebas, evaluar la calidad y la eficacia
de su proceso de pruebas, evaluar la productividad de su personal de pruebas, evaluar los resultados de
las pruebas. esfuerzos de mejora y evaluando la calidad de sus productos de software.
Ejemplos de medidas relacionadas con las pruebas son los costos de las pruebas, la productividad de los
evaluadores, la cantidad de casos de prueba ejecutados y la cantidad de defectos detectados.
LAS SUBOBJETIVOS DE MADUREZ que respaldan estos objetivos son:
4.2.1. Se forma un comité o grupo de toda la organización que se enfoca en desarrollar un
programa de medición de pruebas y se le proporciona financiamiento y apoyo. El comité desarrolla,
documenta, distribuye y apoya los procedimientos, objetivos, políticas y medidas que se aplican a los
artefactos de software y el proceso de prueba. Las metas, políticas, procedimientos y medidas, una vez
aprobadas, se implementan y revisan periódicamente.
4.2.2. Se desarrolla un programa de medición de prueba de acuerdo con la política con un
sistema de informes de medición. Se recogen las medidas,

Apéndice III
652 |
almacenada y analizada. Se aplican en toda la organización para establecer objetivos de

prueba/proyecto y para mejorar la calidad del producto y del proceso de prueba. Las medidas
de prueba se aplican en toda la organización para respaldar la toma de decisiones, la planificación
de proyectos/pruebas, y el seguimiento y monitoreo de proyectos/pruebas y la planificación de
acciones.
4.2.3. Se proporciona capacitación, herramientas y otros recursos para respaldar el
programa de medición de pruebas.
PREGUNTAS
1. ¿Se ha establecido con fondos y recursos un comité de toda la organización responsable de

la medición de pruebas?
2. ¿Se ha desarrollado, distribuido y aprobado una política de medición de pruebas en toda la
organización?
3. ¿Se reflejan las preocupaciones de los clientes en la política/plan de medición?
4. ¿Se han desarrollado procedimientos de medición de pruebas y sistemas de informes?
multado, documentado y aprobado?
5. ¿Se han especificado y documentado las medidas apropiadas para cada fase del ciclo de
vida de la prueba?
6. ¿Se proporcionan recursos adecuados (p. ej., financiamiento, materiales, herramientas) para
implementar el programa de medición de pruebas?
7. ¿Está disponible la capacitación en identificación, recolección y análisis de mediciones para
los gerentes y el personal técnico?
8. ¿Cada proyecto sigue la política organizacional escrita para per
formando medidas?
9. ¿Hay un depósito de datos de prueba disponible para que lo usen los gerentes y técnicos?
personal técnico?
10. ¿Se establecen metas de pruebas cuantitativas para cada proyecto?

11. ¿Se utilizan mediciones para rastrear y monitorear las pruebas?
12. ¿Se ha establecido un conjunto básico de atributos y métricas de calidad del software?
definido?
13. ¿Se utilizan medidas de los atributos de calidad del software para rastrear el software?
calidad durante la prueba?
14. ¿Se utilizan elementos de datos de prueba para respaldar la planificación de acciones para la mejora
del proceso de prueba?
15. ¿El programa de medición se evalúa periódicamente?


| 653
M ETA DE MADUREZ 4.3: E VALUACIÓN

DE LA CALIDAD DEL SOFTWARE
El propósito del objetivo de madurez de la evaluación de la calidad del software es relacionar

los problemas de calidad del software con la adecuación del proceso de prueba, definir y
promover el uso de atributos de calidad del software medibles y definir objetivos de calidad
para evaluar los productos de trabajo del software. Los atributos de calidad de la muestra son
corrección, eficiencia, integridad, facilidad de uso, mantenibilidad, flexibilidad, capacidad de
prueba, portabilidad, reutilización e interoperabilidad.
4.3.1. Se forma un comité o grupo de toda la organización centrado en la evaluación

de la calidad del software y se le proporciona financiación y apoyo. El comité desarrolla,
documenta, distribuye y respalda procedimientos, objetivos, políticas, estándares y medidas
para la evaluación de la calidad del software. Los objetivos, políticas, procedimientos,
estándares y mediciones, una vez aprobados, se implementan y revisan periódicamente.
4.3.2. Se proporciona capacitación, herramientas y otros recursos para respaldar

la evaluación de la calidad del software.
4.3.3. Los objetivos de calidad se desarrollan para cada proyecto de acuerdo con
la política. El proceso de prueba está estructurado, medido y evaluado para garantizar que se
alcancen los objetivos de calidad. Se solicita la opinión del usuario/cliente para el desarrollo
de objetivos de calidad.
PREGUNTAS
1. ¿Se ha establecido, financiado y apoyado un comité para toda la organización sobre
evaluación de la calidad del software?
2. ¿El comité ha desarrollado, distribuido y aprobado una política para toda la organización
relacionada con la evaluación de la calidad del software basada en mediciones?
3. ¿Se reflejan las preocupaciones de los clientes en la política de calidad?
4. Tiene un conjunto de estándares y procedimientos de evaluación de la calidad del software.

sido desarrollado, documentado y aprobado?
5. ¿Se proporcionan recursos adecuados (p. ej., financiamiento, materiales, herramientas)
para programas y evaluaciones de calidad?
6. ¿Están capacitados los gerentes y el personal técnico para que puedan establecer objetivos
de calidad medibles, desarrollar y comprender estándares de calidad,
Apéndice III
654 |
recopilar medidas de calidad y evaluar atributos de calidad para artefactos de software?
7. ¿Cada proyecto sigue la política organizativa escrita para la evaluación?

uando la calidad del software?
8. ¿Se establecen metas de calidad para evaluar productos de trabajo de software para cada
¿proyecto?
9. ¿Se ha establecido un conjunto de atributos de calidad medibles para los productos de software?
especificado, verificado, distribuido y aprobado?

10. ¿Se establecen objetivos de calidad medibles para cada producto de software?
11. ¿Existe un procedimiento formado para la entrada del cliente al software?
proceso de evaluación de la calidad de cada proyecto?
12. ¿Se evalúa periódicamente el proceso de prueba para evaluar su impacto en
calidad del software?
13. ¿Se realizan mejoras en las pruebas y otros procesos de evaluación de la calidad?
cesos para aumentar el nivel de calidad del software?
14. ¿Las actividades para la evaluación de la calidad del software se revisan en un pe?
base riodica?
• TMM Nivel 5: Optimización/Defecto

Prevención y Control de Calidad
META DE MADUREZ 5.1: PREVENCIÓN DE DEFECTOS
El propósito de esta meta de madurez es animar a una organización a clasificar, registrar y

analizar formalmente sus defectos. También se alienta a la organización a utilizar una
combinación de análisis causal de defectos y planificación de acciones para guiar el cambio
del proceso de modo que estos defectos se eliminen de su negocio.
productos futuros. Las actividades de prevención de defectos recomendadas incluyen
registro y seguimiento, análisis causal de defectos, planificación de acciones,
implementación y seguimiento, y capacitación en métodos de prevención de defectos.
5.1.1. Se forma un comité o grupo de toda la organización centrado en

la prevención de defectos y se le proporciona financiación y apoyo. Él
El comité desarrolla, documenta, distribuye y apoya los procedimientos,
metas, políticas, estándares y medidas para la prevención de defectos. Él
objetivos, políticas, procedimientos, estándares y mediciones, una vez aprobados,
se implementan y se revisan periódicamente.
5.1.2. Se proporciona capacitación, herramientas y otros recursos para respaldar las
actividades de prevención de defectos.
5.1.3. Los equipos de prevención de defectos se establecen de acuerdo con la política, con
apoyo de gestión. Las responsabilidades se asignan al defecto.
equipos de prevención. Los equipos se aseguran de que los defectos inyectados/eliminados sean
identificado y registrado para cada fase del ciclo de vida, se establece un procedimiento de análisis causal
para identificar las causas fundamentales de los defectos, y esa acción
Los planes se desarrollan a través de la interacción de gerentes, desarrolladores y
probadores para evitar que los defectos identificados vuelvan a ocurrir. Estos planes son
seguimiento, y los cambios en los procesos se producen como resultado del éxito en los proyectos piloto.
PREGUNTAS
1. Tiene un comité o grupo de toda la organización sobre prevención de defectos
se ha establecido con financiación y apoyo?
2. ¿El comité ha desarrollado y distribuido políticas, programas y procedimientos para toda la organización
para apoyar la prevención de defectos y los ha aprobado?
3. ¿Se reflejan las preocupaciones de los clientes en la política de prevención de defectos?
4. ¿Se proporcionan los recursos adecuados (p. ej., financiación, materiales, herramientas) para
actividades de prevención de defectos?
5. ¿Están capacitados los gerentes y el personal técnico en la prevención de defectos?

¿actividades?
6. ¿Se han establecido equipos de prevención de defectos (los miembros pueden ser parte
de desarrollo, pruebas, SQA, grupos SEPG)?
7. ¿Cada proyecto sigue la política organizacional escrita para defectos?
¿prevención?
8. ¿Están planificadas las actividades de prevención de defectos?
9. Para cada fase del ciclo de vida, ¿se clasifican todos los defectos inyectados/eliminados?
y registrado formalmente en un depósito de defectos?
10. Una vez identificadas, se analizan y eliminan las causas comunes de los defectos.
nated sistemáticamente?
11. ¿Se desarrollan planes de acción específicos para evitar que se repitan los defectos?
12. ¿Se miden y rastrean las acciones de prevención de defectos para asegurar el progreso?
res y para evaluar la eficacia?
13. ¿Se implementan acciones efectivas de prevención de defectos en toda la organización en forma de
cambios de procesos documentados?
14. ¿Se revisan periódicamente las actividades/programas de prevención de defectos?

Apéndice III
656 |
META DE MADUREZ 5.2: C ONTROL DE CALIDAD

El propósito de este objetivo de madurez es desarrollar un conjunto completo de
procedimientos y prácticas de control de calidad que respaldan el lanzamiento de software de alta
calidad que cumple plenamente con los requisitos del cliente. El logro de este objetivo permite que
una organización incorpore mediciones, técnicas y herramientas avanzadas para mejorar la eficacia
de sus pruebas.
proceso, reducir los defectos del software, mejorar la confiabilidad del software y aumentar la
facilidad de uso. Las actividades de control de calidad requieren herramientas automatizadas para
respaldar la ejecución y repetición de casos de prueba y la recopilación de defectos y
análisis. Las técnicas estadísticas y los perfiles de uso se utilizan para respaldar los esfuerzos de
prueba y el logro de los objetivos de calidad. Los niveles de confianza pueden ser
establecidos que indican la probabilidad de que el software esté libre de fallas. Él
el software se prueba para la usabilidad. Se utilizan criterios cuantitativos para determinar

cuando dejar de probar. Estos criterios cuantitativos pueden basarse, por
ejemplo, alcanzar un cierto nivel de fiabilidad o confianza, o cuando
el número de defectos/unidad de tiempo en una clasificación de gravedad seleccionada llega a un
cierto nivel.
5.2.1. Un comité o grupo de toda la organización que se centra en

se forma el control de calidad y se le proporciona financiación y apoyo. Él
comité desarrolla y actualiza documentos, y distribuye y apoya
procedimientos, metas, políticas, estándares y medidas para el control de calidad. Las metas,
políticas, procedimientos, estándares y medidas, una vez
aprobados, implementados y revisados periódicamente
5.2.2. La prueba de software y los grupos SQA identifican
atributos del software y establecer objetivos de calidad cualitativos y cuantitativos
para productos de software con entrada de usuario/cliente de acuerdo con la política. Estos
los objetivos están incluidos en los planes de prueba. Las herramientas y técnicas de prueba se utilizan para
determinar si se han cumplido los objetivos de calidad. Se utilizan criterios cuantificables

para tomar decisiones de parada de prueba.
5.2.3. El grupo de prueba y los grupos relacionados están capacitados y asignados

responsabilidades por el uso de métodos estadísticos y otros aspectos relacionados con la calidad.
actividades de evaluación de software tales como pruebas de usabilidad. La prueba o relacionada
El grupo interactúa con los usuarios/clientes para recopilar entradas para el modelado de uso y
pruebas de usabilidad.
PREGUNTAS
1. ¿Se ha creado un comité de toda la organización centrado en el control de calidad?
establecido con financiación y apoyo?
2. ¿Se han desarrollado, distribuido y aprobado políticas, programas y procedimientos en
toda la organización para respaldar el control de calidad del software?
3. ¿Se reflejan las preocupaciones de los clientes en las políticas de control de calidad del software?
4. ¿Son los recursos adecuados (p. ej., financiación, materiales, laboratorios, herramientas)
previsto para las actividades de control de calidad?
5. ¿Están capacitados los gerentes y el personal técnico en actividades de control de calidad?
6. ¿Se utilizan métodos estadísticos durante las pruebas para evaluar el software?
¿calidad?
7. ¿Los objetivos de calidad cuantitativos y cualitativos para los productos de software son
identificados por el grupo de prueba de software y el grupo SQA con aportes de los
usuarios/clientes?
8. ¿Se incorporan los objetivos de calidad en los planes de prueba?

9. ¿Se identifican y
documentado?
10. ¿Se recopilan los aportes de los usuarios/clientes para el modelado de uso?
11. ¿Se ha asignado la responsabilidad de las pruebas de usabilidad?

12. ¿Se evalúa cuidadosamente la usabilidad del software con respecto al usuario?
¿necesidades?
13. ¿Existe un mecanismo para la participación de los usuarios en las pruebas de usabilidad?
14. ¿Se aplican los comentarios de los usuarios para realizar mejoras en el software en
desarrollo?
15. ¿Se especifican los criterios cuantitativos para las decisiones de parada de prueba en los planes de prueba?
16. ¿Se revisan periódicamente las actividades de control de calidad?
META DE MADUREZ 5.3 :

OPTIMIZACIÓN DEL PROCESO DE PRUEBA
El propósito de este objetivo de madurez es promover la mejora continua del proceso de prueba
y la reutilización del proceso de prueba. Se alienta a una organización a identificar las prácticas
de prueba que deben mejorarse, implementar las mejoras y realizar un seguimiento del progreso
de la mejora. También se alienta a aplicar actividades de control de procesos a las pruebas,
evaluar continuamente nuevas herramientas y tecnologías relacionadas con las pruebas para la
adaptación y apoyar la transferencia de tecnología. Finalmente, se alienta a una organización a
que identifique
Apéndice III
658 |
probar subprocesos, almacenarlos en una biblioteca de activos de proceso y adaptarlos
para su reutilización en futuros proyectos.
5.3.1. Se constituye un grupo de toda la organización centrado en la mejora del proceso
de prueba y se le proporciona financiación y apoyo. Tiene
responsabilidades de supervisión continua para los problemas del proceso de prueba que incluyen
reutilización del proceso de prueba, control del proceso de prueba, evaluación y mejora del proceso
de prueba y transferencia de tecnología. Proporciona liderazgo para el proceso de prueba.
esfuerzos de mejora. El grupo desarrolla y actualiza documentos, y
distribuye y respalda los procedimientos, objetivos, políticas, estándares y mediciones para las
actividades de mejora del proceso de prueba. Los objetivos, políticas, procedimientos, estándares
y medidas, una vez aprobados, se establecen,
y revisada periódicamente.
5.3.2. La formación está disponible para la gestión y el personal técnico
en las áreas de planificación de acciones, evaluación de procesos de prueba, control de procesos de
prueba, reutilización de procesos de prueba y transferencia de tecnología.
5.3.3. El proceso de prueba se somete a una evaluación periódica de acuerdo con
a la política y se implementan planes de acción para realizar mejoras. Nuevo
las herramientas y técnicas se evalúan e integran continuamente.
5.3.4. Los componentes del proceso de prueba de alta calidad son reconocidos como
activos y se almacenan y reutilizan en toda la organización.
PREGUNTAS
1. ¿Se ha creado un grupo o grupo de trabajo centrado en la mejora del proceso de prueba?
establecido, con financiación y apoyo?
2. ¿Se han desarrollado políticas, programas y procedimientos en toda la organización para
respaldar la evaluación, mejora y reutilización del proceso de prueba?
distribuido y aprobado?
3. ¿Se han desarrollado, distribuido y aprobado políticas, programas y procedimientos en toda la
organización para respaldar el control del proceso de prueba?
4. ¿Se han desarrollado, distribuido y aprobado políticas, programas y procedimientos en toda la
organización para apoyar la transferencia de tecnología?
5. ¿Se proporcionan los recursos adecuados (p. ej., financiación, materiales, herramientas) para
¿Transferencia tecnológica?

| 659
6. ¿Se proporcionan los recursos adecuados (p. ej., financiación, materiales, herramientas) para el
control del proceso de prueba?
7. ¿Se proporcionan los recursos adecuados (p. ej., financiación, materiales, herramientas) para la
evaluación, mejora y reutilización del proceso de prueba?
8. ¿Los gerentes y el personal técnico están capacitados en control de procesos?
9. ¿Los gerentes y el personal técnico están capacitados en la evaluación del proceso de prueba,
mejora y reutilización?
10. ¿Los gerentes y el personal técnico están capacitados en transferencia de tecnología?
11. ¿Se ha establecido una biblioteca de activos de procesos (PAL)?
12. ¿Se adaptan los procesos de prueba en PAL y se reutilizan en posteriores
proyectos?
13. ¿Se evalúan continuamente las herramientas de prueba para que las usen los
¿grupo?
14. ¿Existe un procedimiento para la adaptación/integración de nuevas herramientas y tecnologías
en el proceso de prueba (transferencia de tecnología)?
15. ¿Se evalúa periódicamente el proceso de prueba?
16. ¿Los resultados de una evaluación generan acciones de mejora?
17. ¿Las acciones de mejora exitosas conducen a cambios en el proceso de prueba organizacional,
los documentos asociados y las normas?
18. ¿Están definidas las mediciones para el control del proceso de prueba?
19. ¿Se realizan periódicamente actividades de control del proceso de prueba que dan como resultado
ajustes al proceso de prueba?
20. ¿Se revisa periódicamente el programa de transferencia de tecnología?
21. ¿Se revisa periódicamente el programa de evaluación y mejora del proceso de pruebas?
22. ¿Se revisa periódicamente el programa de control del proceso de prueba?
23. ¿Se revisa periódicamente el programa de reutilización del proceso de prueba?
Sección 5. Preguntas sobre herramientas de prueba
Los evaluadores deben tener en cuenta que las preguntas de la herramienta de prueba no tienen un
impacto formal en la clasificación que resulta del proceso de clasificación de TMM. Esta sección del
Cuestionario TMM es útil para que los evaluadores obtengan una mayor comprensión del estado actual
del proceso de prueba de una organización. Las respuestas a estas preguntas también son útiles al
ensamblar herramientas para los Testers.

660 | Apéndice III
banco de trabajo Para cada uno de los tipos de herramientas enumerados a continuación, el encuestado
debe decidir si se aplican "nunca", "rara vez", "a menudo" o "siempre".
I. HERRAMIENTAS DE GESTIÓN DE RECURSOS DE PRUEBA
1. Administradores de configuración (supervisan y controlan los efectos de los cambios durante el
desarrollo y el mantenimiento y preservan la integridad de las versiones desarrolladas y lanzadas).
2. Herramientas de gestión de proyectos (ayudan a los gerentes/proyectos a planificar, programar y
realizar un seguimiento del desarrollo, las pruebas y el mantenimiento de los sistemas).
3. Planificadores de pruebas (ayudan a los desarrolladores/evaluadores/gerentes en la planificación y
definición de pruebas de aceptación, sistema, integración y nivel de unidad).
II. REQUISITOS Y HERRAMIENTAS DE SOPORTE DE PRUEBAS DE DISEÑO
1. Analizadores de requisitos y especificaciones (evalúan las especificaciones en cuanto a consistencia,
integridad y conformidad con los estándares de especificación establecidos).
2. Simuladores de sistemas/prototipos (fusionar actividades de análisis y diseño con pruebas).
3. Rastreadores de requisitos (reduzca el esfuerzo de trabajo de rastrear los requisitos a la información
de diseño asociada, el código fuente y los casos de prueba para proyectos grandes).
tercero HERRAMIENTAS DE SOPORTE DE PRUEBAS DE IMPLEMENTACIÓN Y

MANTENIMIENTO
1. Compiladores.
2. Analizadores estáticos de código fuente (examinar el código fuente sin ejecutar
eso).
• Auditores (analizan el código para garantizar el cumplimiento de las reglas establecidas)
y normas).
• Medidores de complejidad (computar métricas del código fuente para determinar varios atributos
de complejidad asociados con el código fuente o diseños escritos en un lenguaje de diseño
de programas).
• Herramientas de referencias cruzadas (proporcionan referencias entre varios
entidades).
• Medidores de tamaño (recuento de líneas de código fuente, SLOC).

• Verificadores de estructura (identificar anomalías estructurales y desarrollar representaciones
gráficas o textuales del código).
• Analizadores de sintaxis y semántica (identifican conflictos de tipo en argumentos de llamada de
subrutinas compiladas por separado).
3. Herramientas de preparación de pruebas (preparación de apoyo de datos de prueba o información de
casos de prueba)
• Extractores de datos (crear datos de prueba a partir de bases de datos existentes o
conjuntos).
• Generadores de casos de prueba basados en requisitos (ayudan a los desarrolladores a evaluar
los requisitos creando casos de prueba a partir de requisitos escritos siguiendo las reglas
del lenguaje de especificación formal de la herramienta).
• Generadores de datos de prueba (soportan el desarrollo de entradas de prueba que están
formateadas o pueden formatearse fácilmente en los archivos requeridos).
4. Herramientas de ejecución de pruebas (analizar dinámicamente el software que se está probando).
• Analizadores de aserciones (instrumentan el código con expresiones lógicas que especifican
condiciones o relaciones entre las variables del programa).
• Herramientas de reproducción de captura (registre automáticamente las entradas/salidas de las
pruebas usando scripts de captura, reproduzca las pruebas usando scripts de reproducción.
Útil para volver a probar cuando se realizan cambios).
• Analizadores de cobertura/frecuencia (evalúa el grado de cobertura de los casos de prueba con
respecto a sentencias ejecutadas, ramas, caminos o módulos).
• Depuradores (no es estrictamente una herramienta de prueba; estos admiten la ubicación
de defectos revelados durante la prueba).
• Emuladores (pueden usarse en lugar de componentes del sistema faltantes o no disponibles y,
por lo general, funcionan a la velocidad en tiempo real de los componentes que se emulan).
• Analizadores de red (analizan el tráfico en la red para identificar áreas y condiciones
problemáticas, además de permitir la simulación de las actividades de múltiples terminales).
• Analizadores de rendimiento/temporización (supervisar las características de temporización de
los componentes de software o de sistemas completos).

662 | Apéndice III
• Comprobadores de errores en tiempo de ejecución (supervise los programas en busca de
referencias a la memoria, fugas de memoria o errores de asignación de memoria).
• Simuladores (se utilizan en lugar de sistemas faltantes o no disponibles).

componentes).
• Visualizadores de estado/documentos de sesión (proporcionan información sobre el estado

de la prueba y registran información seleccionada sobre una ejecución de prueba).
• Gestores de ejecución de pruebas (automatizar diversas funciones de configuración

realizar ejecuciones de prueba, realizar una variedad de pruebas y limpiar después
una prueba para restablecer el sistema).
5. Evaluadores de pruebas (realizan funciones que consumen mucho tiempo y son propensas a errores).
• Comparadores (comparar entidades entre sí después de un software

prueba y nota las diferencias).
• Reductores y analizadores de datos (convierte los datos a una forma que se puede
interpretarse más fácilmente y, en ocasiones, puede realizar varios análisis estadísticos
de los datos).
• Rastreadores de defectos/cambios (realice un seguimiento de la información de defectos y la generación).
borrar informes de defectos).
Sección 6. Preguntas de tendencias de prueba
Como en el caso de las preguntas de uso de la herramienta de prueba, las preguntas de tendencia de prueba
están diseñados para proporcionar una visión más amplia del proceso de prueba a los evaluadores.
No juegan ningún papel formal en una clasificación de TMM. Los evaluadores pueden utilizar las
respuestas como mejor les parezca para ayudar en el proceso de evaluación.
1. Desde su perspectiva, ¿cuáles son las principales fortalezas de las pruebas?

proceso en su organización hoy?
2. Desde su perspectiva, ¿cuáles son las principales debilidades de las pruebas?
proceso en su organización hoy?
3. ¿Qué cambios ha realizado la organización para mejorar el proceso de evaluación en los últimos
2 a 5 años?
4. ¿Cómo calificaría la efectividad general del proceso de prueba?
hoy en comparación con hace 2 años? Seleccione uno de los siguientes
opciones: igual, mejorado, muy mejorado, poco mejorado, peor,
no sé
5. Compare la fracción de tiempo y los recursos asignados para la prueba ahora

y hace 2 años. Seleccione una de las siguientes opciones: igual,
aumentado en gran medida, disminuido en gran medida, más o menos igual, no sé.
6. Compare el número actual de evaluadores de tiempo completo en la organización
al número disponible hace 2 años. Seleccione uno de los siguientes
opciones: igual, aumentado, disminuido, no sé.
7. Compare el número actual de evaluadores a tiempo parcial en la organización
al número disponible hace 2 años. Seleccione uno de los siguientes
opciones: igual, aumentado, disminuido, no sé.
8. Desde su perspectiva, durante los últimos 2 años la comunicación entre evaluadores,
desarrolladores y gerentes: mejoró, permaneció igual,
empeoró, no sé?
9. Desde su perspectiva, ¿ha abordado la gerencia las necesidades de los probadores/
desarrolladores? Sí, no, hasta cierto punto, no lo sé.
Sección 7. Comentarios de los encuestados
Esta sección está reservada para que un encuestado comente sobre la naturaleza de la
Cuestionario TMM en sí mismo. Los encuestados pueden comentar sobre cualquier aspecto de
el cuestionario, por ejemplo, sobre la claridad de las preguntas, la organización de las
preguntas, la integridad y la facilidad de uso del documento. Los comentarios proporcionan
información útil para los mantenedores del cuestionario.
quién puede entonces considerar los cambios apropiados. Los encuestados pueden utilizar el
sección en blanco provista a continuación y/o agregar páginas suplementarias con sus
comentarios
Sección 8. Glosario de Términos
A continuación se incluye una descripción de muchos de los términos utilizados en el

Cuestionario de TMM para ayudar a comprender y responder las preguntas de TMM. Las
referencias en las descripciones se relacionan con el Glosario estándar de terminología de
ingeniería de software de IEEE, IEEE Std. 610.12–1990.
test de aceptación. Pruebas formales realizadas para determinar si un sistema cumple con
los criterios de aceptación especificados y para permitir que el cliente
determinar si acepta el sistema. [IEEE-STD-610.12–1990]
Apéndice III
664 |
actividad. Cualquier paso dado o función realizada, tanto mental como física,
hacia el logro de algún objetivo. Las actividades incluyen todo el trabajo que realizan los gerentes
y el personal técnico para realizar las tareas del proyecto y de la organización.
evaluación. Término genérico utilizado en el campo de la ingeniería de software para referirse

a evaluaciones de procesos de software o evaluaciones de capacidades de software.
Cualquier proceso o subproceso de ingeniería de software puede someterse a una evaluación
o evaluación.
artefacto. Un objeto o artículo producido o moldeado por mano de obra humana.

Como se menciona en las evaluaciones de procesos basadas en modelos, los artefactos son los
productos resultantes de la promulgación de un proceso. Algunos ejemplos de artefactos del
proceso de desarrollo de software son los diseños de software, el código y los casos de prueba.
evaluación. Ver evaluación del proceso de prueba.
base. (1) Una especificación o producto que ha sido revisado formalmente

y acordado, que a partir de ese momento sirve como base para un mayor desarrollo y solo puede
modificarse mediante procedimientos formales de control de cambios. (2) Líneas de base más
cambios aprobados de esas líneas de base
constituyen la identificación de configuración correcta para el artículo. [IEEE STD-610.12–1990]
Pruebas de caja negra. Una estrategia de prueba básica que considera una especificación de
diseño funcional para diseñar casos de prueba sin tener en cuenta la estructura interna del
programa. Esta estrategia admite la prueba del producto frente a las especificaciones externas
del usuario final.
herramienta de captura/reproducción. Una herramienta de prueba que registra las entradas y los resultados de la prueba (p. ej.,
pantallas) y proporciona facilidades para la posterior re-ejecución o reproducción de

la prueba.
compromiso. Un pacto que se asume libremente, se hace visible y se espera que sea
mantenida por todas las partes.
gestión de la configuración. Un proceso que requiere experiencia técnica y administrativa para

identificar y documentar el funcionamiento y el físico
características de un elemento de configuración, controlar los cambios en esas características,
registrar e informar el procesamiento de cambios y el estado de implementación,
y verificar el cumplimiento de los requisitos especificados. Elementos de configuración

| 665
pueden ser, por ejemplo, unidades de código, conjuntos de prueba, especificaciones y planes de prueba.
[IEEE-STD-610.12–1990]
consenso. Un método de toma de decisiones que permite a los miembros del

equipo desarrollar una base común de comprensión y llegar a un acuerdo general
sobre una decisión. cliente cliente). El individuo u organización responsable de
aceptar el producto y autorizar el pago a la organización desarrolladora.
depuración La depuración, o localización de fallas, es el proceso de (1) ubicar la

falla o defecto, (2) reparar el código y 3. volver a probar el código.
defecto. Una falla en un sistema o componente del sistema que hace que el
sistema o componente no cumpla con su función requerida. Un defecto, si se
encuentra durante la ejecución, puede causar una falla del sistema.
prevención de defectos. Las actividades involucradas en la identificación de

defectos o defectos potenciales y la prevención de su introducción en productos
futuros.
desarrollador. Un profesional de software con habilidades técnicas que está

involucrado en la definición, diseño, implementación, evaluación y mantenimiento
de un sistema de software.
emulador Hardware, software o firmware que realiza las tareas de un componente

de hardware específico.
usuario final. El individuo o grupo que usará el sistema para su propósito operativo
previsto cuando se implemente en su entorno. revisión/actividad impulsada por
eventos. Una revisión o actividad cuya implementación se basa en la ocurrencia

de un evento dentro del proyecto.
revisión formal. Una reunión formal en la que se presenta un producto al usuario

final, cliente u otras partes interesadas para comentarios, evaluación y aprobación.
También puede ser una reunión para presentar/discutir actividades técnicas y de
gestión, o una reunión para discutir el estado de un proyecto.
meta. (1) Una declaración de intenciones, o (2) una declaración de un logro que un
individuo o una organización quiere lograr.
infraestructura. El marco subyacente de una organización que incluye estructuras

organizacionales, políticas, estándares, capacitación, instalaciones y herramientas,
que respaldan sus procesos continuos.
Apéndice III
666 |
institucionalización. La construcción de infraestructura y cultura autosuficientes que apoyen

métodos, prácticas y procedimientos que permitan un modo
de hacer negocios, incluso después de que aquellos que originalmente construyeron la infraestructura
se fueron.
pruebas de integración. Una progresión ordenada de las pruebas en la que el individuo

elementos de software, elementos de hardware o ambos se combinan y prueban
hasta que se haya integrado todo el sistema.
gerente. Una función que abarca la prestación de servicios técnicos y administrativos.

dirección y control a las personas que realizan tareas o actividades dentro
el área de responsabilidad del gerente. Las funciones tradicionales de un gerente incluyen la
planificación, la programación, la organización, la dotación de personal, la dirección y el control
del trabajo dentro de un área de responsabilidad. Puede haber varios niveles
de gerentes en una organización dependiendo del tipo de jerarquía
estructura en su lugar.
nivel de madurez. Una meseta o etapa evolutiva bien definida para un proceso.
respaldado por un conjunto de objetivos y prácticas que, cuando se implementan, describen el
estado del proceso.
medida. Una asignación objetiva empírica de un número (o símbolo) a

una entidad para caracterizar un atributo particular.
método. Un conjunto razonablemente completo de reglas y criterios que establecen un

forma precisa y repetible de realizar una tarea y llegar al resultado deseado.
resultado.
organización. Una unidad dentro de una empresa, o toda la empresa misma. Un

La organización tiene responsabilidades específicas, personal y una estructura de informes.
Todos los proyectos dentro de una organización suelen compartir una gestión de alto nivel
común y políticas comunes.
revisión/actividad periódica. Una revisión o actividad que ocurre en intervalos de tiempo

regulares y específicos.
política. Una declaración de principio o curso de acción de alto nivel que se utiliza
para gobernar un conjunto de actividades en una organización.
procedimiento. Un medio o técnica mediante el cual la realización de una tarea o

El proceso está asegurado. El procedimiento puede implicar varios elementos organizativos.
mentos, y su documentación puede incluir alguna combinación de función

declaraciones, pasos y/o planes operativos. La documentación define
qué debe realizarse, cómo debe realizarse y quién es responsable de los resultados.
proyecto. Una empresa que requiere un esfuerzo concertado que se centra en

desarrollar y/o mantener un producto específico. El producto puede incluir
hardware, software y otros componentes. Por lo general, un proyecto tiene su
propia gestión, financiación, contabilidad de costes y calendario de entrega.
gerente de proyecto. La persona con la responsabilidad comercial total de un proyecto.

La persona que dirige, controla, administra, planifica y regula
el desarrollo de un sistema de software o un sistema de hardware/software. Él
El gerente del proyecto es el individuo responsable en última instancia ante el cliente.
calidad. (1) El grado en que un sistema, componente o proceso cumple

requisitos especificados. (2) El grado en que un sistema, componente,
o proceso satisface las necesidades o expectativas del cliente o usuario. [IEEE-STD
610.12–1990]
pruebas de regresión. El proceso de volver a probar el software que ha sido modificado

para asegurar que la modificación no haya introducido defectos.
y que el software aún puede cumplir con su especificación.
recurso. Los medios físicos, humanos y económicos necesarios para apoyar

un proceso, política, procedimiento, meta o programa; por ejemplo, materiales de
capacitación, herramientas de hardware y software, documentos estándar, miembros del
personal y fondos para viajes.
revisión. Una reunión de grupo cuyo propósito es evaluar un artefacto de software.

o un conjunto de artefactos de software.
riesgo. Posibilidad de sufrir pérdida.
gestión de riesgos. Un enfoque para el análisis de problemas que sopesa los riesgos en
una situación mediante la identificación de los riesgos, sus probabilidades de ocurrencia y
su impacto, para dar una comprensión más precisa de las pérdidas potenciales
y cómo evitarlos. La gestión de riesgos incluye la identificación de riesgos,
análisis, priorización y control.
Apéndice III
668 |
role. Una unidad de responsabilidades definidas que puede ser asumida por uno o
más individuos.
Gerente senior. Una función de gestión a un alto nivel en una organización.

cuyo enfoque principal es la vitalidad a largo plazo de la organización, en lugar de
que proyectos a corto plazo y preocupaciones y presiones contractuales.
simulador. Un dispositivo, sistema de procesamiento de datos o programa de computadora que

representa ciertas características del comportamiento de un sistema físico o abstracto.
ciclo de vida del software. El período de tiempo que comienza cuando se concibe un
producto de software y finaliza cuando el software ya no está disponible para su uso.
usar. El ciclo de vida del software generalmente incluye una fase de concepto, una fase de
requisitos, una fase de diseño, una fase de implementación, una fase de prueba, una fase de
instalación y verificación, una fase de operación y mantenimiento y, algunas veces, una fase
de retiro. [IEEE-STD-610.12–1990]
proceso de software. El conjunto de métodos, prácticas, normas, documentos,

actividades, políticas y procedimientos que los ingenieros de software utilizan para desarrollar
y mantener un sistema de software y sus artefactos asociados, como proyectos y planes de
prueba, documentos de diseño, código y manuales.
aseguramiento de la calidad del software. (1) Un patrón planificado y sistemático de todos

acciones necesarias para proporcionar la confianza adecuada de que un software funciona
producto se ajusta a los requisitos técnicos establecidos. (2) Un conjunto de actividades
diseñadas para evaluar el proceso por el cual los productos de trabajo de software
son desarrollados y/o mantenidos. [IEEE-STD-610.12–1990]
probador de software. Ver probador.
producto de trabajo de software. Cualquier artefacto creado como parte de la definición,

mantenimiento o uso de un producto de software. Esto incluye documentos de diseño, pruebas
planos, manuales de usuario, código de computadora y documentación asociada. Los
productos de trabajo de software pueden o no estar destinados a entregarse a un cliente o
usuario final.
estándar. Requisitos obligatorios empleados y aplicados para prescribir

un enfoque disciplinado y uniforme para el desarrollo de software. [IEEE-STD 610.12–1990]
prueba del sistema El proceso de probar un sistema integrado de hardware y software para
verificar que el sistema cumple con los requisitos especificados.
requerimientos técnicos. Aquellos requisitos que describen lo que debe hacer el software
y sus limitaciones operativas. Ejemplos de técnica
Los requisitos incluyen funcionalidad, rendimiento, interfaz y calidad.
requisitos
caso de prueba. Un elemento relacionado con la prueba que contiene la siguiente

información: (1) Un conjunto de entradas de prueba. Estos son elementos de datos recibidos de un
fuente externa por el código bajo prueba. La fuente externa puede ser hardware, software
o humano. (2) Condiciones de ejecución. Estas son condiciones
requerido para ejecutar la prueba, por ejemplo, un cierto estado de una base de datos,
o una configuración de un dispositivo de hardware. (3) Productos esperados. Estos son
los resultados que producirá el código bajo prueba.
ensayador. Un profesional técnicamente capacitado que participa en las pruebas.

y evaluación de un sistema de software, y en la evaluación y mejora del proceso de prueba.
pruebas. (1) Un grupo de procedimientos llevados a cabo para evaluar algún aspecto de
una pieza de software. (2) Un proceso utilizado para revelar defectos en el software.
y para establecer que el software ha alcanzado un grado específico de
calidad con respecto a los atributos seleccionados.
prueba de cuestionario de madurez. Un conjunto de preguntas que ayuda a un equipo de

evaluación a determinar el nivel de madurez de pruebas de una organización. Eso
se ocupa de la implementación de importantes prácticas de prueba de software en una
organización de software.
administrador de pruebas La persona con la responsabilidad comercial total de las pruebas y

evaluación de un producto de software. El individuo que dirige, controla, administra, planifica
y regula la evaluación de un sistema de software o
sistema hardware/software. El gerente de pruebas trabaja con el gerente de proyectos para
garantizar que el sistema sea de la más alta calidad y satisfaga a los clientes.
requisitos
evaluación del proceso de prueba. Una evaluación por parte de un equipo capacitado de software/prueba/
profesionales de SQA para determinar el estado actual de una organización

proceso de prueba, para determinar los problemas relacionados con el proceso de prueba
de alta prioridad que enfrenta una organización, y para obtener el apoyo organizacional para
mejora del proceso de prueba.
Apéndice III
670 |
herramientas de prueba Los sistemas de software y/o hardware, u otros instrumentos, que
se utilizan para medir y evaluar un artefacto de software.
producto de trabajo de prueba. Cualquier artefacto creado como parte del proceso de prueba. Los
ejemplos son planes de prueba, especificaciones de casos de prueba, procedimientos de prueba y

documentos de prueba.
examen de la unidad. Conjunto de actividades técnicas involucradas en demostrar que una

unidad de software individual ha sido implementada correctamente, que el código y el diseño
de una unidad son consistentes y que el diseño de la unidad es
correcto.
modelo V. Un marco para describir las actividades del ciclo de vida del desarrollo de
software desde la especificación de requisitos hasta el mantenimiento. (El Modelo V
Modificado incluye actividades de desarrollo y ejecución de pruebas).
validación. El proceso de evaluar un sistema o componente de software durante o al final

del ciclo de desarrollo para evaluar si cumple con los requisitos del cliente. [IEEE-STD-610.12–
1990]
verificación. El proceso de evaluar un sistema o componente de software para determinar

si los productos de una fase de desarrollo determinada satisfacen las condiciones impuestas
al comienzo de esa fase. [IEEE-STD 610.12–1990]
Pruebas de caja blanca. Una estrategia de prueba básica que requiere el conocimiento de
la estructura interna de un programa para diseñar casos de prueba.
PARTE 2 • ACTIVIDADES, TAREAS Y TAREAS DE TMM
RESPONSABILIDADES (ATR)
Esta parte del Apéndice III contiene el conjunto completo de actividades, tareas y
responsabilidades (ATR) para las tres vistas críticas descritas en el TMM. La sección está
organizada por nivel de TMM, luego por los objetivos de madurez dentro de cada nivel y
finalmente por las tres vistas críticas. Para cada nivel de TMM hay:
(i) Una declaración de cada objetivo de madurez;

(ii) ATR para gerentes;
Parte 2: Actividades, tareas y responsabilidades de TMM (ATR) | 671
(iii) ATR para desarrolladores/probadores;

(iv) ATRs para usuarios/clientes.
• TMM Nivel 2: Definición de fase
META DE MADUREZ 2.1: DESARROLLAR META Y POLÍTICAS

DE PRUEBA Y DEPURACIÓN
Recuerde que en el nivel 2 de TMM no se requiere un grupo de prueba dedicado, por lo que los
ATR se asignan formalmente solo a los desarrolladores. Si una organización tiene un grupo de
especialistas en pruebas, los ATR del desarrollador se pueden transferir a este grupo.
ATR PARA GERENTES (SUPERIOR Y

GESTIÓN DE PROYECTOS)
• Proporcionar liderazgo, recursos adecuados y financiación para formar el comité (equipo o

grupo de trabajo) sobre pruebas y depuración. La composición del comité es gerencial,
con personal técnico como miembros.
• Poner a disposición cualquier política de prueba/depuración preexistente o de muestra

y metas
• Asumir un papel de liderazgo en el desarrollo de políticas de prueba/depuración.
• Apoyar las recomendaciones y políticas del comité al:
—distribuir documentos de políticas/objetivos de prueba/depuración a los gerentes de

proyecto, desarrolladores/evaluadores y otro personal interesado, y solicitar
retroalimentación de estos grupos;
— designar un equipo permanente para supervisar el cumplimiento y la realización de
cambios en las políticas;
• Asegúrese de que estén disponibles la capacitación, la educación y las herramientas

necesarias para llevar a cabo las metas y políticas definidas de prueba/depuración.
• Promover los cambios culturales necesarios para implementar las políticas de prueba/
depuración.
672 | Apéndice III
• Asignar responsabilidades de prueba y depuración.
• Alentar las aportaciones/retroalimentación de usuarios clave/grupos de clientes para las políticas

de prueba/depuración.
• Asegurar que haya soporte para el desarrollo de un esquema simple de clasificación de

defectos y un depósito de defectos. El esquema de clasificación y el repositorio deben estar
disponibles para que todo el personal del proyecto los estudie y acceda.
• Asegúrese de que los desarrolladores (probadores) estén familiarizados con el esquema de

clasificación de defectos y registren los defectos que ocurren para cada proyecto en el
repositorio.
• Revisar periódicamente los objetivos y las políticas de prueba y depuración.
ATR PARA DESARROLLADORES
• Trabajar con la gerencia para desarrollar políticas de prueba y depuración

y metas
• Participar en el equipo que supervisa el cumplimiento de la política de prueba/depuración y la

gestión de cambios.
• Familiarizarse con el conjunto aprobado de objetivos y políticas de prueba/depuración,

manteniéndose al día con las revisiones y haciendo sugerencias de cambios cuando
corresponda.
• Establecer metas de prueba para cada proyecto en cada nivel de prueba que reflejen o
metas y políticas de pruebas organizacionales.
• Desarrollar planes de prueba que cumplan con la política de prueba.
• Llevar a cabo actividades de prueba que cumplan con los requisitos organizacionales.
políticas
• Trabajar con los gerentes de proyecto para desarrollar un esquema de clasificación de defectos
y depósito de defectos.
• Registrar los defectos que ocurren en cada proyecto en el repositorio de defectos.
• Participar en revisiones periódicas de políticas de prueba/depuración y

metas.
ATR PARA USUARIOS/CLIENTES
• Los usuarios/clientes brindan información/retroalimentación sobre las metas y políticas de prueba y
depuración cuando la gerencia lo solicita. (Estos grupos desempeñan un papel indirecto en la formación
de los objetivos y políticas de prueba/depuración de una organización, ya que estos objetivos y políticas
reflejan los esfuerzos de la organización para garantizar la satisfacción del cliente/usuario. Comentarios
de
estos grupos deben ser alentados por la gerencia y SQA. En general, las necesidades de sus clientes
y del mercado en general tendrán un impacto en la naturaleza de las metas y políticas de prueba/
depuración de una organización).
META DE MADUREZ 2.2: I NICIAR UN PROCESO

DE PLANIFICACIÓN DE PRUEBAS
ATR PARA GERENTES
• Proporcionar liderazgo, financiación y recursos a toda la organización
comité de planificación de pruebas.
• Garantizar que las declaraciones de política de planificación de pruebas se distribuyan y
aprobado.
• Promover cambios culturales para apoyar la planificación de pruebas.
• Asegúrese de que la declaración de la política de pruebas, los estándares de calidad y las plantillas del plan
de pruebas respalden la planificación de pruebas con compromisos de recursos, herramientas y
capacitación.
• Asegúrese de que la declaración de la política de pruebas contenga un mecanismo formal para la entrada
del usuario/cliente en el proceso de planificación de pruebas, especialmente para las pruebas de
aceptación. (En niveles más altos de TMM, esto también incluirá la planificación de pruebas de
usabilidad).
• Asegurarse de que todos los proyectos cumplan con la planificación de la prueba
política.
• Asegúrese de que las plantillas del plan de prueba se apliquen de manera uniforme para todos los proyectos.
• Asegúrese de que todos los desarrolladores (probadores) completen todos los documentos necesarios
posteriores a la prueba, como registros de prueba e informes de incidentes de prueba.

674 | Apéndice III
• Asegúrese de que los planes de prueba estén preparados para todos los niveles de prueba: unidad, en
integración, sistema y aceptación.
• Participar en clases de capacitación para la planificación de pruebas, uso de plantillas de planes de prueba,
identificación/estimación de riesgos de prueba, herramientas de planificación (esto se aplica a los gerentes de
proyecto y gerentes de prueba cuando hay un grupo de prueba).
• Seleccione las herramientas de planificación de pruebas adecuadas.
• Preparar planes de prueba multinivel para cada proyecto con aportes y apoyo de los desarrolladores. (Esto se aplica a
los jefes de proyecto y de prueba cuando hay un grupo de prueba). Los jefes de proyecto/prueba utilizan las
plantillas de plan de prueba de la organización como guía para preparar planes de prueba. Se identifican los
riesgos de prueba y se seleccionan e incluyen medidas simples en el plan de prueba para garantizar que se hayan
cumplido los objetivos de prueba. Los datos de defectos de proyectos anteriores se utilizan cuando corresponde
para ayudar en la planificación de pruebas).
• Asegurarse de que los desarrolladores (probadores) preparen adjuntos del plan de prueba, como casos de prueba y
procedimientos de prueba.
• Asegurarse de que se preparen documentos de prueba auxiliares, como informes de transmisión de prueba y registros
de prueba.
• Revisar los planes de prueba con los desarrolladores (testers).
• Asegúrese de que todos los desarrolladores (probadores) completen todos los documentos necesarios posteriores a
la prueba, como registros de prueba e informes de incidentes de prueba.
• Preparar un informe de resumen de prueba (jefes de proyecto/prueba).
• Promover interacciones con desarrolladores (probadores) y clientes para desarrollar planes de prueba de aceptación y
casos de uso y/o cualquier otra descripción de interacciones típicas de usuario/computadora.
• Revisar periódicamente las políticas de planificación de pruebas con el personal técnico.
• Participar como miembros del comité de planificación de pruebas.
• Asistir a clases de capacitación para la planificación de pruebas, para el uso de herramientas de planificación y
plantillas y para identificar los riesgos de las pruebas.
• Ayudar al gerente del proyecto (prueba) a determinar los objetivos de la prueba, los riesgos de la prueba y los costos
de la prueba para la planificación en todos los niveles de la prueba.

Parte 2: Actividades, tareas y responsabilidades de TMM (ATR)

| 675
• Ayudar al director del proyecto (prueba) en la selección de métodos de prueba, procedimientos,

y herramientas
• Desarrollar especificaciones de casos de prueba, especificaciones de procedimientos de prueba y otros

documentos relacionados con las pruebas.
• Trabajar con analistas y diseñadores para garantizar que los problemas de capacidad de prueba se
aborden durante las fases de diseño y requisitos para respaldar la planificación y el diseño de la
prueba.
• Recopile medidas simples relacionadas con las pruebas para garantizar que se hayan cumplido los objetivos de las pruebas.
logrado.
• Complete todos los documentos necesarios previos y posteriores a la prueba, como informes de
transmisión de pruebas, informes de incidentes de pruebas y registros de pruebas.
• Trabajar con los clientes para desarrollar casos de uso y/o cualquier otra descripción de la interacción
típica entre el usuario y la computadora y los planes de prueba de aceptación.
• Participar en las revisiones de las políticas de planificación de pruebas.
ATR PARA USUARIOS/CLIENTES
• Articular los requisitos claramente.
• Suministrar información y consenso para el plan de pruebas de aceptación. Los atributos funcionales
y relacionados con el rendimiento requeridos que esperan los clientes/usuarios deben especificarse
clara y cuantitativamente si es posible.
• Proporcionar insumos para el desarrollo de casos de uso y/o cualquier otro
descripciones de la interacción típica entre el usuario y la computadora.
META DE MADUREZ 2.3: I NSTITUCIONALIZAR

TÉCNICAS Y MÉTODOS BÁSICOS DE PRUEBA
ATR PARA GERENTES
• Proporcionar liderazgo, apoyo y financiamiento a un comité o grupo responsable de identificar, evaluar
y recomendar técnicas, métodos y herramientas de prueba básicos.

676 | Apéndice III
• Asegúrese de que las recomendaciones del grupo estén documentadas, distribuidas y aprobadas.
• Garantizar que las políticas y estándares de una organización estén diseñados para
promover la institucionalización de métodos de diseño de pruebas de caja negra/blanca.
• Asegurarse de que las políticas y estándares de pruebas requieran pruebas multinivel.
• Garantizar que los desarrolladores (testers) adquieran la educación y la formación necesarias
comprender y aplicar métodos de prueba de caja blanca y negra, y
para desarrollar casos de prueba, procedimientos de prueba, registros de prueba e incidentes de prueba
informes.
• Asegúrese de que los desarrolladores (probadores) tengan la educación y capacitación necesarias
ing para realizar pruebas en múltiples niveles.
• Proporcionar recursos para respaldar el uso de los métodos de prueba de caja negra/blanca, como
herramientas y plantillas.
• Fomentar la cooperación entre desarrolladores (probadores), requisitos y
analistas y diseñadores en temas de pruebas.
• Asegúrese de que los planes de prueba incluyan el uso de métodos de diseño de prueba de caja negra/blanca
ods
• Asegúrese de que los planes de prueba cubran los niveles múltiples de prueba.
• Promover los cambios culturales necesarios para respaldar la aplicación en toda la organización de
técnicas y herramientas de prueba básicas.
• Promover los cambios culturales necesarios para apoyar las pruebas multinivel.
• Asignar el tiempo y los recursos adecuados para diseñar y ejecutar el sistema negro/
Pruebas de caja blanca, pruebas multinivel y análisis de los resultados de las pruebas.
• Ajustar los cronogramas del proyecto para que se puedan realizar pruebas multinivel
adecuadamente.
• Proporcionar visibilidad para la aplicación exitosa de técnicas de prueba y

métodos.
• Revisar periódicamente técnicas y métodos y herramientas de prueba básicos.

• Participar como miembros de un comité responsable de evaluar y recomendar técnicas, métodos y
herramientas de prueba.
• Asista a clases y sesiones de capacitación, lea materiales, adquiera herramientas, trabaje con colegas
expertos y adquiera experiencia práctica en la aplicación de métodos de diseño de pruebas de caja
blanca y caja negra.
• Asista a clases y sesiones de capacitación, lea materiales, adquiera herramientas, trabaje con colegas
expertos y adquiera experiencia práctica en pruebas a nivel de unidad, integración, sistema y
aceptación.
• Garantizar que se utilice un equilibrio de enfoques de prueba para el diseño de casos de prueba
en todos los niveles de prueba.
• Diseñar casos de prueba, especificaciones de prueba y procedimientos de prueba basados en el
conocimiento de estrategias, técnicas y métodos de prueba.
• Configurar el entorno de software/hardware necesario para ejecutar las pruebas.
Apague las instalaciones cuando se completen las pruebas.
• Ejecutar casos de prueba en todos los niveles de prueba.
• Registrar datos relacionados con la prueba.
• Registrar datos relacionados con defectos.
• Interactuar con especificadores y diseñadores para revisar sus representaciones del software. Las
representaciones incluyen especificaciones de entrada/salida, pseudocódigo, diagramas de estado y
gráficos de flujo de control que son fuentes ricas para el desarrollo de casos de prueba. Estas
representaciones son vitales para diseñar casos de prueba de caja blanca/negra.
• Consulte el repositorio de defectos para obtener información sobre defectos anteriores de proyectos
similares para ayudar a diseñar pruebas adecuadas.
• Apoyar la gestión (proyecto/prueba) para garantizar que las pruebas multinivel y el uso de técnicas de
prueba de caja negra/blanca formen parte de las políticas de la organización, se incorporen a los
planes de prueba y se apliquen en toda la organización.
• Trabaje con los gerentes de proyectos (pruebas) para garantizar que haya tiempo y recursos para realizar
pruebas en todos los niveles.

Practical Software Testing (600 700)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Practical Software Testing (600 700)

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

16.9 Aplicaciones Industriales del TMM | 577

2. La atención de la dirección debía centrarse en la prueba del software.

El modelo de madurez de las pruebas y la evaluación del proceso de pruebas

estudio de grupo de consultoría, la falta de soporte de desarrollador/probador se ubicó como una

16.9 Aplicaciones Industriales del TMM | 579

prueba. Las principales lecciones aprendidas del estudio se describen a continuación.

proporcionar herramientas, capacitación y personalización de los pasos de trabajo para respaldar

a minimizar el número de "no sé" y respuestas inexactas.

— desarrollar políticas y objetivos de prueba/depuración;

—integración de la prueba en el ciclo de vida del software;

—identificación de los riesgos de las pruebas;

—garantizar la independencia del grupo de prueba;

— desarrollar un programa de revisión en toda la organización;

—desarrollar un programa de medición de pruebas.

objetivo más práctico para estos

580 | El modelo de madurez de las pruebas y la evaluación del proceso de pruebas

Resumen de los resultados de clasificación de TMM

TL1 1 Mal uso de la plantilla del plan de prueba; mal uso de

requisitos como entrada al plan de prueba; sin riesgos de prueba

identificado para el plan de prueba; ninguna integración de la prueba en

control y seguimiento; ninguna integración de

prueba en el ciclo de vida.

relación desarrollador/probador; pobre institucionalización

de técnicas y métodos básicos de ensayo.

para llegar al nivel 3.

TL5 1 Muchos "no aplicable" y "no sé"

Niveles de TMM excepto para planificación de pruebas y pruebas.

programas de medición que tienen debilidades.

Este grupo lidera los esfuerzos de prueba en este sitio.

4. Una debilidad está en la gestión de riesgos para la prueba.

Resumen de los resultados de clasificación de TMM para

una empresa de hardware/ software.

grupos Alcanzar el nivel 5 de TMM debe abordarse a un nivel más global

El investigador de TMM concluyó que este estudio preliminar fue

16.9 Aplicaciones Industriales del TMM

muy informativo para el sitio de la organización. Muchos problemas de prueba fueron

16.9.5 Lecciones aprendidas del

Estos estudios experimentales indican que el TMM se muestra prometedor como

1. El personal debe estar capacitado y motivado.

El modelo de madurez de las pruebas y la evaluación del proceso de pruebas

es un proyecto de equipo y requiere la participación de todos. También deben estar

2. El esfuerzo de evaluación debe adaptarse para cumplir con las normas

Además de proporcionar capacitación y herramientas, es posible que los líderes de la

3. El equipo de evaluación debe obtener el compromiso y el apoyo de la gerencia.

Estos estudios ilustran la importancia de la participación y el compromiso de la gerencia

Finalmente, las clasificaciones del TMM ubicaron a la mayoría de los grupos

16.9 Aplicaciones Industriales del TMM | 583

procesos, muchas organizaciones han realizado inversiones significativas en mejoras

[3] I. Burnstein, A. Homyen, R. Grom, CR Carlson, "Un modelo

584 | El modelo de madurez de las pruebas y la evaluación del proceso de pruebas

16.9 Aplicaciones Industriales del TMM | 585

[43] I. Burnstein, L. Miller (Presidente, Midwest Software Testing

Esta página se dejó en blanco intencionalmente

REFERENCIAS RELACIONADAS CON LA PRUEBA

I. Pruebas de software: conferencias relacionadas

A continuación se enumeran referencias a conferencias de interés relacionadas con pruebas y

Conferencia y exposición de automatización de pruebas de software

Ingeniería de Calidad de Software

330 Forma Corporativa

Parque anaranjado, FL 32073

www.stickyminds.com (boletín informativo)

Conferencia del Grupo de Procesos de Ingeniería de Software