Cambios de la versin 2008 frente a la 2005.

Incluir la seccin 1.2. Qu son las pruebas?

La Seccin 4.1 ha cambiado a "Proceso de Desarrollo de Pruebas"
antes era "Identificacin de condiciones de prueba y el diseo de casos
de prueba.

La Seccin 2.1 ahora analiza 2 modelos de desarrollo: secuencial vs

Iterativo Incremental.

Nuevos trminos:

Ataque de fallos (4.5), Anticipar Errores (1.5):

Generalmente los
probadores pueden anticipar defectos basados en la
experiencia. Un enfoque estructurado para adivinar el error, es la tcnica de
enumerar una lista de posibles errores y disear pruebas para el ataque de estos
errores. Este enfoque sistemtico se denomina ataque de fallos.

Retesting (volver a probar) (1.4):

Despus de que un defecto es detectado y corregido, el software debe ser
analizado de nuevo para confirmar que el defecto original ha sido eliminado con
xito. Esta actividad de volver a probar se hace a modo de confirmacin.
La depuracin (defecto de fijacin) es una actividad de desarrollo, no es una
actividad de prueba.

Independencia de Pruebas (1.5):

Un cierto grado de independencia (evitando la subjetividad del desarrollador) es a
menudo ms eficaz en la bsqueda defectos y fallos. La independencia no es, sin
embargo, un sustituto de familiaridad, porque los desarrolladores pueden encontrar
de manera eficiente muchos defectos en su propio cdigo.

Modelo de Desarrollo Iterativo-Incremental (2.1):

2.1.2 Modelo de Desarrollo Iterativo - Incremental (K2)
El modelo de desarrollo iterativo-incremental, es un proceso que comprender las
siguientes etapas: establecimiento de requisitos, diseo, construccin y pruebas,
realiza una serie de ciclos de desarrollo ms cortos. Algunos ejemplos son:

Creacin de Prototipos,
Desarrollo rpido de aplicaciones (RAD),
Rational Unified Process (RUP)
Desarrollo gil.

El sistema resultante producido por una iteracin puede ser probado en varios
niveles como parte de su l desarrollo.

Un incremento, sumado por otros desarrollados anteriormente, forma un sistema

parcial que crece, que tambin debe ser probado.
Las pruebas de regresin son cada vez ms importante en todas las iteraciones
despus de la primera.
La verificacin y validacin pueden llevarse a cabo en cada incremento.

Definicin de Pruebas (1.2):

1.2 Qu es la prueba?
Una percepcin comn de las prueba es que slo consiste en las pruebas de
funcionamiento, es decir, ejecutar el software.
Esto es parte de la prueba, pero no son todas las actividades de prueba.
Existen actividades de prueba antes y despus de la ejecucin de la prueba:
actividades tales como la planificacin y el control, la eleccin de
condiciones de prueba, el diseo de casos de prueba y la comprobacin de sus
resultados, la evaluacin de los criterios de salida, el seguimiento y control de las
pruebas y la finalizacin o cierre (despus de una fase de prueba ha sido
completado).
Las pruebas tambin incluyen la revisin de documentos (incluyendo el cdigo
fuente) y el anlisis esttico.
Tanto las pruebas dinmicas y las pruebas estticas se pueden utilizar como un
medio para lograr objetivos similares, y proporcionar informacin a fin de mejorar
tanto el sistema sea probado, el desarrollo y los procesos de prueba.
Se pueden tener diferentes objetivos de prueba:

Comprobar defectos.
Ganando la confianza sobre el nivel de calidad y la informacin
La prevencin de defectos.

La designacin "D" se ha quitado de la seccin 6.1.5 Herramientas de

preparacin de datos de la prueba.

Cambios de la versin 2010 frente a la 2008.

Captulo 1.4 ahora contiene el concepto de trazabilidad entre la base de

pruebas y los casos de prueba.
Captulo 2.x ahora contiene objetos de prueba y la base de pruebas.
Retest ahora es el trmino principal como en las pruebas de
confirmacin.
El aspecto de calidad de datos y calidad de pruebas se ha aadido en
varios lugares:
o Datos de calidad y el riesgo en el captulo 2.2, 5.5, 6.1.8
Captulo 5.2.3 Criterios de Entrada se agregan como un subcaptulo
nuevo. Razn: coherencia con los criterios de salida.

Captulo 6.1 se ha reducido por las descripciones de herramientas eran

demasiado grandes para una leccin de 45 minutos.

IEEE Std. 829:2008 ha sido actualizado. En esta versin del programa

de estudios no estn reconocidas las actualizaciones. La seccin 5.2 se
refiere al documento del Plan Maestro de prueba. Que se actualiza con
esta norma.
El Cdigo de tica se ha movido de la CTAL a CTFL.

Criterios de entrada
5.2.3 Los criterios de Entrada (K2)
Los criterios de entrada, nos permiten definir cundo comenzar las pruebas, tanto
como en el comienzo de un nivel de prueba o cuando un conjunto de pruebas est
listo para su ejecucin. Por lo general los criterios de entrada podrn abarcar lo
siguiente:

Disponibilidad de ambiente de pruebas.

Disposicin de herramientas en el entorno de Prueba
Disponibilidad del cdigo a probar.
Data de prueba disponible

Cdigo de tica
1.6 Cdigo de tica (K2)
La participacin en las pruebas de software permite a las personas conocer la
informacin confidencial y privilegiada. Un cdigo de tica es necesario, entre otras
razones para asegurar que la informacin no se expone a un uso inadecuado.
Reconociendo el cdigo de ACM y el IEEE de la tica para los ingenieros, el
ISTQB se adhiere al siguiente cdigo de tica:
INTERES PBLICO - probadores de software certificados, debern actuar de
manera coherente con el inters pblico.
DEL CLIENTE Y LA EMPRESA - probadores de software certificados, debern
actuar de una manera que busque el mejor inters de su cliente y su empleador,
de conformidad con el inters pblico.
PRODUCTO - probadores de software certificados, se asegurarn de que las
prestaciones que ofrecen (en los productos y los sistemas que ponen a prueba)
cumplen con los estndares profesionales ms altos posibles.
JUSTICIA - probadores certificados de software, debern mantener la integridad e
independencia en su vida profesional actuando con justicia.
GESTIN - probadores certificados de software, gerentes y lderes deber firmar y
promover un enfoque tico a la gestin de pruebas de software.
PROFESIN - probadores de software certificados debern promover la integridad
y reputacin de la profesin coherente con el inters pblico.
COLEGAS - probadores de software certificados, sern justos y de apoyo de sus
colegas, y buscarn promover la cooperacin con los desarrolladores de software.
AUTONOMIA - probadores de software certificados, debern participar en el
aprendizaje permanente sobre la prctica de su profesin y promovern un
enfoque tico de la prctica de la misma.