1.

Con base a la lectura, realizar un cuadro comparativo donde se defina la etapas de la

estructura de la prueba y sus las caractersticas.

Fase Caractersticas
Ausencia de probadores Prueban su propio cdigo-
independientes.
a menudo puede ver ms defectos que un probador que trabaja en
un equipo de programacin y o programador de profesin.
Tiene otro punto de vista de suposiciones- relacin pruebas,
revisiones.
Actitud escptica de pesimismo.

Probadores independientes Las pruebas independientes pertenecen equipo independiente.

dentro de los equipos de
desarrollo. Ventajas.
El probador es totalmente imparcial.
No hace suposiciones respecto a la calidad.
Desventajas.
Pruebas independientes obstculo en la comunicacin.
Ejecucin de la prueba independiente es la ultima etapa que se hace
afectados por los retrasos anteriores.
Probadores independientes Los productos necesitan personas y como estas lo utilizan dependen de
procedentes de la la tarea que se lleve a cabo es por ello que pueden cambiar debido al
organizacin de negocio o negocio que sea, tambin a los cambios tecnolgicos.
de la comunidad
Ejemplo: IBM Cognos power play- explorar datos-gestor empresarial.
de usuarios.

Especialistas en pruebas Probadores de usabilidad, probadores de seguridad o probadores de

independientes para tipos certificacin que certifican un producto de software en base a los
de pruebas especficas. estndares y la normativa

Probadores de usabilidad:
Es una prueba de facilidad con la que los usuarios pueden aprender a
utilizar un producto. Chequea la facilidad de uso, flujo aplicaciones de
 prueba, se comprueba la navegacin sistema.

Probadores de seguridad:
permite comprobar si el sistema es permeable de ser penetrado por
alguna forma de hacking(es la bsqueda permanente de los
conocimientos en todo lo relacionado con los sistemas informticos).
Acceso interno o externo no autorizado.
Tareas de prueba: Lder de pruebas: tiene conocimiento y experiencia en el diseo
ejecucin y reporte de pruebas sobre un producto de software, pero
Aparece en ella las del lder
tambin es capaz de estimar, planificar y dar seguimiento a un proyecto
de prueba y el probador.
de pruebas.
Coordina y planifica, Adapta la planificacin en base a los resultados y
progreso de las pruebas, Establece una gestin de la configuracin
adecuada de los productos de prueba a efectos de su trazabilidad.
Decidir sobre la implementacin del entorno de pruebas

El probador: Detectar la mayor cantidad de fallas severas antes de que

el software salga a produccin el tester o probador participa en todas
las etapas del proceso del desarrollo del software, colaborando para la
calidad del mismo.

Revisar y contribuir a los planes de pruebas. Analizar, revisar y evaluar

los requisitos de usuario, las especificaciones y los modelos para su
capacidad de ser probado. Preparar y obtener datos de prueba.
Implementar pruebas en todos los niveles de prueba, ejecutar y registrar
las pruebas. Evaluar los resultados y documentar las desviaciones de
los resultados esperados. Utilizar herramientas de administracin o
gestin y herramientas de seguimiento de prueba segn proceda.
Planificacin de pruebas: 1.Analizar Requerimientos de desarrollo de software.
mbito del desarrollo y la Se debe entender los requerimientos de usuario, se debe analizar las
implementacin de especificaciones, el diseo funcional, requisitos no funcionales, matriz
proyectos, as como en las de trazabilidad, casos de uso historia de usuario. Preguntas especficas
actividades de de cada requisito.
mantenimiento.

2. Identificar las funcionalidades nueva a probar.

Debemos identificar e incluir el plan de pruebas lista de
funcionalidades
3. identificar las funcionalidades de sistemas existentes que deben
probarse.
Se deben identificar las funciones que estn siendo impactadas
Por el desarrollo en alguna forma.
Funcionalidades de cara al usuario: si se modifica se agrega ms
pantallas y flujo de proceso.
Componentes internos: son funcionalidades no modificadas a cara
del usuario, se mantiene la misma interfaz grfica y flujo de procesos.
4. definir la estrategia de pruebas.
Consiste en seleccionar bsicamente cuales son los tipos de pruebas de
software que se deben realizar.
Pruebas funcionales. Ejemplo prueba de sistema que se realizan
luego de que el equipo de desarrollo integra los componentes de
distintas capas.
Pruebas de caja negra. El cual es una tcnica de pruebas de software
en la cual la funcionalidad se verifica sin tomar en cuenta la estructura
interna del cdigo, detalles de implementacin o escenarios de
ejecucin internos del software.
Pruebas no funcionales. Se define pruebas no funcionales para cada
requisito sobre el desempeo, tiempo de respuesta, mantenibilidad,
pruebas de seguridad de software.
Prueba de caja blanca. Segn la estructura y arquitectura del software
que se este desarrollando.
Pruebas de regresin. Se definen sobre funcionalidades modificadas
componentes interenos.
5. Definir los criterios de inicio, aceptacin y suspensin de
pruebas.para definir los criterios de aceptacin o rechazo es necesario
definir el nivel de tolerancia a fallos de calidad.
Criterios de inicio o reanudacin. Definen condiciones que deben
cumplirse para reanudar las pruebas.
Criterios de suspensin. Dependen de los acuerdos del nivel de
servicio ejemplo personal dedicado el nivel puede ser menos exigente.

6. identificar el entorno, ambiente requerido.

Se documentan caractersticas de los entornos hardware y software
necesarios para realizar la ejecucin de pruebas de software.

7. Determinar necesidades de personal y entretenimiento.

debe completarse previamente la estimacin del esfuerzo de pruebas a
partir del diseo de el caso de pruebas.

Requisitos de entrenamiento
ejemplo
Transferencia de conocimientos en el sistema y su operacin con el
rea de negocio.
Formacin de metodologas de pruebas de software.
Entretenimiento de tipos de pruebas especializadas desempeo,
estrs, arquitectura, caja blanca
Formacin en automatizacin de pruebas de software.
8. establecer la metodologa y procedimientos de prueba.
la metodologa de pruebas de software depender de la que se est
utilizando para la gestin de proyecto.

9. elaborar la planificacin de las pruebas.

la cual se compone por:
matriz de responsabilidades, cronograma, premisas.

10. identificar los riesgos y definir planes de respuesta.

El probador de software los riegos por lo general estn vinculados con
factores como:
Dificultades entornos
Pruebas dependen de factores externos
Conocimientos especializados por parte del personal
Posibilidad que no se cumpla alguna premisa.

Mostrar mensaje anterior

Punto 2.
2. Defina con sus propias palabras a que se refiere la gestin de la configuracin en las
pruebas de software y gestin de incidencias.
Gestin de la configuracin en las pruebas de software.
Un elemento de Configuracin puede ser prcticamente cualquier producto o subproducto del
desarrollo de software. Las especificaciones de requisitos, los documentos de anlisis y de
diseo, el Cdigo fuente y ejecutable, y los procedimientos y datos de prueba pueden ser
sometidos a control de Configuracin. Es un proceso donde se identifica, se define elementos
en el sistema, adems de ello controla cambios en los elementos que surgen a lo largo del
ciclo de vida reportando, registrando solicitudes de cambio; elementos que estn completos y
correctos.
Establece mantiene la integridad de los productos lo cuales se encuentran los componentes,
datos y documentacin. Para generalizar mejor el concepto y conceptualizarlo quise hacer un
ejemplo de las pruebas de software.
En esta seccin se describen algunos de los artefactos utilizados comnmente documentado
relacionados con el software de prueba, tales como:
Ejemplo imagen

artefacto

Plan de prueba
escenario de prueba
Caso de prueba
 Matriz de trazabilidad

Plan de prueba. Un plan de ensayo describe la estrategia que se utilizar para probar una
aplicacin, los recursos que se van a utilizar, el entorno de prueba en el que se va a realizar la
prueba, y las limitaciones de las pruebas y el calendario de actividades de prueba.
Normalmente, el Lder del equipo de Control de Calidad ser el encargado de escribir un plan
de pruebas.
Un plan de prueba incluye lo siguiente:

Introduccin al documento de plan de pruebas

Supuestos mientras se prueba la aplicacin
Lista de casos de prueba incluido en la prueba de la aplicacin
Lista de caractersticas a ensayar
Qu tipo de enfoque para utilizar mientras se prueba el software
Lista de entregables que necesitan ser probado
Los recursos asignados para probar la aplicacin
Todos los riesgos involucrados durante el proceso de prueba
Un calendario de tareas e hitos que deben alcanzarse

Escenario de prueba.
Es una declaracin de una lnea que se notifica a qu rea de la aplicacin se pondr a
prueba. Los escenarios de prueba se utilizan para garantizar que todos los flujos de proceso
se prueban de extremo a extremo. Un rea particular de una aplicacin puede tener tan poco
como un escenario de prueba a unos pocos cientos de escenarios dependiendo de la
magnitud y la complejidad de la aplicacin.
Los trminos "escenario de prueba" y "casos de prueba" se utilizan indistintamente, sin
embargo, un escenario de prueba tiene varios pasos, mientras que un caso de prueba tiene un
solo paso. Visto desde esta perspectiva, escenarios de prueba son los casos de prueba, pero
incluyen varios casos de prueba y la secuencia que deben ser ejecutados. Aparte de esto,
cada ensayo depende de la salida de la prueba anterior.

Caso de prueba.
Los casos de prueba implican un conjunto de pasos, las condiciones y los insumos que se
puede utilizar en el desempeo de tareas de prueba. La intencin principal de esta actividad
es asegurar si un software de pasa o no en trminos de su funcionalidad y otros aspectos. Hay
muchos tipos de casos de prueba, tales como funcional, negativo, de error, casos de prueba,
casos de prueba lgicas fsicas, casos de prueba de interfaz de usuario, etc.
Por otra parte, los casos de prueba se escriben para realizar un seguimiento de la cobertura
de las pruebas de software. Generalmente, no hay plantillas formales que pueden ser
utilizados durante el caso de la prueba de escritura. Sin embargo, los siguientes componentes
estn siempre disponibles y se incluyen en cada caso de prueba:

Prueba de identificacin de caso

mdulo de producto
Versin del producto
Revisin histrica
Propsito
supuestos
Las condiciones previas
Pasos
Gastos esperados
resultado real
Postcondiciones

CODIFICACION Y BANCOS DE PRUEBAS

Codificacin de la aplicacinDiseo e implementacin de un sistema de informacin para la
asignacin de citas de consulta externa en las reas de medicina general, odontologa y
psicologa
Esta etapa consiste en implementar o escribir cada uno del requerimiento como un programa
de computadora en un lenguaje de programacin, convirtiendo cada tarea en instrucciones en
el lenguaje de programacin.
La verificacin es el proceso por el cual se comprueba que un diseo o producto funciona tal
como se espera. Al programa que est siendo verificado se le llama producto y al conjunto de
pruebas que se aplican en la verificacin se le llama banco de pruebas.
PRUEBAS TCNICAS
A lo largo de este captulo se pretende mostrar la funcionalidad de la aplicacin para poder
verificar y validar cada una de las tareas que realiza, de tal manera que se pueda establecer si
la aplicacin cumple o no, con los requerimientos establecidos.
En la siguiente pantalla se permite que los usuarios de la aplicacin se autentiquen y puedan
acceder a la aplicacin de acuerdo a su perfil ya sea administrador, doctor o usuario. De
acuerdo al perfil de cada persona se pueden llevar a cabo diferentes tareas, que se describen
a continuacin.
Matriz de trazabilidad.
Muchos casos de prueba se pueden derivar de un nico escenario de prueba. Adems, a
veces mltiples casos de prueba estn escritas para un solo software que se conocen
colectivamente como bancos de pruebas.
Matriz de trazabilidad (tambin conocido como Matriz requisito de trazabilidad - RTM) es una
tabla que se utiliza para rastrear los requisitos durante el ciclo de vida del software de
desarrollo. Puede ser utilizado para el rastreo hacia adelante (es decir, desde Requisitos para
disear o Coding) o hacia atrs (es decir, de codificacin de Requisitos). Hay muchas
plantillas definidas por el usuario para RTM.
Cada requisito en el documento RTM est vinculada con su caso de prueba asociados para
que las pruebas se pueden hacer segn los requisitos mencionados. Por otra parte, ID de
error tambin se incluye y se vincula con sus correspondientes requisitos y casos de prueba.
Los principales objetivos de esta matriz son:

Asegrese de que el software se desarrolla de acuerdo con los requisitos mencionados.

Ayuda en la bsqueda de la causa raz de cualquier insecto.
Ayuda en la localizacin de los documentos desarrollados durante las diferentes fases del
SDLC

Dentro de la documentacin voy a dar este pequeo ejemplo de Diseo e implementacin de

un sistema de informacin para la asignacin de citas de consulta externa en las reas de
medicina general, odontologa y psicologa
El propsito de la Gestin de Configuracin del Software es establecer y mantener la
integridad de los productos de software a travs del ciclo de vida del proceso de software.
La Gestin de Configuracin del Software implica la identificacin de la Configuracin del
software en puntos dados en el tiempo, el control sistemtico de los cambios en la
Configuracin y el mantenimiento de la integridad y trazabilidad de la Configuracin a travs
del ciclo de vida del software. Los productos incluidos son:

Software distribuido al cliente.

Documentos de requerimientos del software.
Cdigo.
Elementos requeridos para crearlos (ejemplo: el compilador)
Uno de los aspectos funcionales que debe tener la gestin de configuracin del software es la
identificacin, el control, el estado, la auditoria y revisin.
Un elemento de Configuracin puede ser prcticamente cualquier producto o subproducto del
desarrollo de software. Las especificaciones de requisitos, los documentos de anlisis y de
diseo, el Cdigo fuente y ejecutable, y los procedimientos y datos de prueba pueden ser
sometidos a control de Configuracin.
Gestin de incidencias.
es una interrupcin a lo que no se planifica como el servicio, unas de esas interrupciones
pueden ser los fallos, consultas reportados por el usuario, equipo de servicio; es por ello que
la gestin de incidencias eficientemente restaura la operatividad normal del servicio.
Las incidencias pueden surgir durante el desarrollo, las revisiones, las pruebas o el uso de un
producto de software. As mismo, pueden surgir por problemas en el cdigo o en el sistema en
funcionamiento, o en cualquier tipo de documentacin que incluya requisitos, documentos de
desarrollo, documentos de prueba e informacin de usuario, como guas de ayuda o
instalacin.
Un ejemplo de ello es por ejemplo una urgencia la cual se necesita que la incidencia se
resuelva rpidamente; al igual que el impacto en donde se puede determinar el nmero
de usuarios afectados, aspectos adversos que la incidencia tiene.
Punto 3.

3.Defina con sus propias palabras la diferencia entre riesgo del proyecto y riesgo del
producto.

Riesgo del proyecto.

Bueno como su palabra lo indica el riesgo es un factor negativo donde interviene factores de
organizacin como los conflictos entre departamentos, entre usuarios, incapacidad del equipo
de hacer un seguimiento de la informacin encontrada durante las pruebas y revisiones, el
riesgo tambin genera incertidumbre, perdida si en dado caso llegue a ser realidad las
consecuencias sern desastrosas; por otro lado el riesgo del proyecto amenaza al plan del
proyecto ya que si se hacen realidad la planificacin se retrasa debido a ello aumentan los
costos entre los que se encuentran a continuacin

Presupuesto: se necesita una mayor inversin.

Planificacin: se necesita ms tiempo.
Personal: se necesitan ms o mejores cualificados.
Recursos: se necesitan ms o mejores instrumentos.
Requisitos: se necesitan ms condiciones.
Cliente y requisitos
Impacto de software

Tambin influye en la parte de organizacin la actitud indebida o falsas expectativas, los

aspectos tcnicos tales como baja calidad del diseo, cdigo, datos de configuracin, datos de
prueba y pruebas; aspectos de proveedores como fallos de proveedores, amenazan el plan
del proyecto, la planificacin temporal y los costos ejemplo. perdida de un diseador
experimentado.
Riesgos del producto.
Son riesgos asociados a un producto en particular de forma nica y especfica, se identifican
por aquellos que tienen visin clara de la tecnologa personal un entorno especifico de un
proyecto. Uno de los riegos del producto es debido a su funcionalidad, a su rendimiento;
amenaza la calidad y la planificacin temporal del software, la implementacin puede llegar a
ser difcil o imposible ejemplo, rendimiento componente menor a lo esperado.