Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Fundamentos de Pruebas de Software
Fundamentos de Pruebas de Software
Fundamentos de Pruebas
La primera demostracin en el espacio que vamos a hacer nosotros es en el ao 2014 en la Estacin
Espacial Internacional (ISS). Vamos a montar un pequeo prototipo del motor, para probarlo y dispararlo
en la ISS, y verificar el rendimiento, su fiabilidad y capacidad de operar tal como estamos prediciendo
Franklin Chang Daz, primer astronauta latinoamericano de la NASA e inventor del motor de cohete
VASIMR.
1.
2.
3.
4.
5.
6.
Los defectos no son introducidos por pequeas hadas en los sistemas que vuelan alrededor
de los centros de datos y lanzan los defectos en las computadoras y el cdigo. Para ser
completamente franco al respecto, los defectos estn en el sistema porque alguien los
coloc all. Alguien cometi una equivocacin, un error, cuyo resultado fue la insercin de
un defecto o bug en el sistema.
Un defecto o un error pueden ser insertados en cualquier momento durante el ciclo de vida.
Pueden ser insertados en los requisitos o en las especificaciones de diseo. Pueden ser
insertados en el cdigo, ya sea en la lgica de negocios o en la interfaz de usuario. Pueden
ser insertados en la documentacin, ya sea en la documentacin electrnica o impresa.
Ahora, una vez que el defecto es insertado en el sistema, ste podra o no podra de verdad
resultar en una falla. Para que una falla ocurra, la parte defectuosa del sistema tiene que ser
ejecutada. En ese momento el defecto podra provocar que el sistema funcione
incorrectamente. Asumiendo que las precondiciones correctas estn vigentes, el sistema
podra fallar al no cumplir con lo que debera hacer en esas condiciones. Si esa falla es
visible o llega a ser visible despus, ya sea a un cliente, un usuario u otro interesado del
negocio, ese comportamiento podra resultar en la insatisfaccin de la calidad del sistema.
Note que hay mucho uso del verbo condicional podra. Bajo muchas circunstancias un
defecto podra existir en el sistema y todava no ser visible en cuanto al comportamiento
visible, simplemente porque requiere una secuencia especfica de acciones antes de la
ejecucin del cdigo que contiene el defecto, o los datos especficos que son
proporcionados al cdigo que contiene el defecto o ambos.
Entonces, Qu hay detrs de todos estos defectos y fallas?
Los defectos ocurren por varias razones.
Los programadores, los analistas de negocios, los analistas de sistemas y otros
colaboradores individuales, incluyendo a los probadores, son falibles. Cometen errores y
algunos de esos errores introducen los defectos.
La gente tiende a cometer ms errores cuando est bajo condiciones de presin de tiempo.
Hoy en da las condiciones de presin de tiempo estn omnipresentes en los proyectos de
desarrollo de software y de sistemas.
Es ms fcil cometer un error cuando se est tratando de resolver un problema complejo, o
cuando se est utilizando un cdigo que ha llegado a ser complejo a travs de los aos, o
cuando se est utilizando una infraestructura que es complicada.
En muchos casos, muchas partes diferentes del sistema o de los sistemas de sistemas tienen
que trabajar todas juntas. Los sistemas de sistemas y las tecnologas que los implementan
estn cambiando continuamente y deben engranar. Por ejemplo, considere lo que se est
haciendo estos das con las arquitecturas orientadas al servicio. A menudo existen intentos
de hacer disponible los servicios implementados en cdigo de mainframes, frecuentemente
cdigo COBOL antiguo que se ejecuta en mainframes, a veces cdigo que ha estado en los
An otra es de localizar y dejar a las personas que reparen los problemas importantes.
Las pruebas pueden y algunas veces tambin deben ser realizadas debido a las
regulaciones, las cuestiones de conformidad, o los contratos. Por ejemplo, las regulaciones
Sarbanes-Oxley son aplicadas en muchas instituciones financieras en los Estados Unidos.
Para ciertos tipos de sitios web, la accesibilidad para personas con discapacidades podra
ser necesaria.
Est bien, regresemos a esta pregunta Qu es la calidad? Existen dos definiciones
formales comunes para la calidad las cuales se diferencian claramente.
Una es la aptitud para el uso. La otra es la conformidad con los requisitos.
Decimos que stas son claramente diferentes porque la definicin apta para el uso
implica que aquellos que usan, emplean, adquieren o necesitan el software son aquellos
que deberan determinar si tiene o no calidad. La definicin Conformidad con los
requisitos, por el contrario, necesita simplemente que el sistema trabaje de la manera
especificada en algn documento. Esto deja abierta la pregunta de que si la definicin de la
capacidad de ser correcto (correctness) que es proporcionada en el documento es
correcta por s misma.
Cmo se relacionan las pruebas con la calidad? En un prrafo anterior, mencionamos que
las pruebas son como un medio para gestionar los riesgos de calidad. Vayamos un poco
ms a fondo.
Suponga que ejecutamos un conjunto de pruebas las cuales encuentran muy pocos defectos.
En tal caso, deberamos tener un nivel ms alto de confianza en el sistema.
Suponga que ejecutamos un conjunto de pruebas y todas esas pruebas pasan, en este caso el
nivel restante del riesgo de la calidad es bajo, con la condicin de que las pruebas fueron
diseadas correctamente.
Suponga que ejecutamos un conjunto de pruebas y esas pruebas fallan. Esas pruebas nos
han proporcionado ahora la oportunidad de mejorar la calidad del sistema. Finalmente, si
su cobertura es adecuada entonces la totalidad del conjunto de pruebas nos dan una buena
evaluacin de la calidad del sistema.
Por supuesto, esto nos lleva a la pregunta, Estamos realmente probando las cosas
correctas? Piense que las caractersticas de calidad son importantes para su sistema y por
consecuencia resultar un sistema el cul es apto para el uso. Las caractersticas de calidad
como el rendimiento, la usabilidad, la fiabilidad y la exactitud. Ha pensado en lo que son
todas esas caractersticas? Est actualmente probndolas lo suficiente? Cmo lo sabe?
Ms adelante en este libro, veremos las formas de determinar las respuestas a esas
preguntas.
En muchos casos, las pruebas tienen uno o ms de los siguientes objetivos generales:
Las pruebas podran ser llevadas a cabo para encontrar defectos y luego proporcionar a los
programadores la informacin que ellos necesitan para corregir estos defectos. Los
programadores no resuelven todos los defectos usualmente, pero nuestra informacin
debera ayudarles a corregir al menos los defectos ms importantes.
Tambin es cierto, que las pruebas podran ser llevadas a cabo para dar a la gente
confianza en el nivel de calidad del sistema. Cuando las compaas adquieren
aplicaciones, stas ejecutan a menudo pruebas de aceptacin para ganar la confianza
previa al despliegue de la aplicacin en el centro de datos.
As mismo las pruebas podran ser llevadas a cabo para prevenir defectos. Esto le podra
parecer extrao a usted. Sin embargo, las pruebas previenen defectos cuando los
probadores estn involucrados en las revisiones y cuando los diseos de las pruebas son
completados en paralelo con la implementacin del sistema. Estas actividades de pruebas
tempranas crean ciclos de retroalimentacin beneficiosos entre las actividades de pruebas
y las actividades de desarrollo, limpiando los defectos temprano en el ciclo de vida.
Finalmente las pruebas podran ser llevadas a cabo para proporcionar informacin,
obtener una visin acerca de lo que realmente importa a la calidad del sistema sometido a
pruebas. Estamos listos para enviar? Cundo estaremos listos para enviar? Cules son
las reas de riesgo que todava tenemos que abordar? Cules son los problemas
conocidos ms temidos?
Una vez que empecemos a generar informacin como esa, la informacin que conceda una
visin del nivel de calidad, podramos ir tras el siguiente objetivo, el de ayudar a la
gerencia a comprender la calidad en el contexto de los objetivos ms grandes del proyecto.
Slo cuando la gerencia comprenda nuestros hallazgos y lo que estos significan en cuanto
al proyecto, podemos decir que como probadores estamos ayudando verdaderamente a
gestionar los riegos de calidad.
Esta lista de objetivos no es en absoluto exhaustiva, usted podra ser capaz de pensar en
otros objetivos que tuvo acerca de sus propios proyectos. Si es as, est bien.
Lo importante no es tanto los objetivos de pruebas que son escogidos, sino el alineamiento
de esos objetivos. Muchas cosas pueden salir mal aqu. Usted podra desalinear sus
propios planes y acciones como un profesional de pruebas con los objetivos de las pruebas
que son establecidos por la gerencia. Usted mismo podra verse forzado a tratar de alinear
sus planes y acciones con los objetivos de pruebas los cuales estn slo implcitos, no
declarados por la gerencia, conduciendo a problemas cuando usted se equivoque. Peor
an, es posible que no haya un slo conjunto de objetivos de pruebas consistente a travs
de toda la gerencia, sino ms bien un conjunto de objetivos de pruebas diferente y
posiblemente contradictorio a travs de los diferentes jefes y otros accionistas.
Estos problemas de alineacin son comunes y son problemas muy dainos para los grupos
de pruebas.
Los objetivos de las pruebas pueden cambiar dependiendo de la fase o del nivel de
pruebas con el que estemos involucrados. Por ejemplo, considere el objetivo de las
pruebas de encontrar defectos o bugs.
Una vez que el programador acepta el informe de defectos, asumiendo que el defecto debe
ser corregido, l identifica la causa raz. l trata de repararlo sin producir ms problemas.
Luego l realiza la prueba unitaria de la correccin.
Esto nos conduce a otra entrega, a travs del proceso de versiones de las pruebas. Sin
embargo hablaremos acerca de esto ms adelante al igual que de los informes de defectos,
esto debe ser bien definido.
1.2.1 Ejercicios
Ejercicio 1
Un programa acepta tres enteros que representan las longitudes de los lados de un
tringulo7.
ste da como resultado escaleno (lados no iguales), issceles (dos lados iguales), o
equiltero (tres lados iguales).
Escriba un conjunto de casos de prueba efectivos (que encuentren defectos comunes) y
eficientes (tan pocas pruebas como sea posible). Usualmente un caso de prueba consiste en
la accin del probador, el dato y el resultado esperado, pero aqu la accin es
generalmente el dato de entrada.
Argumente.
combinacin
del
Primero, note que los tres enteros slo pueden describir un tringulo cuando la suma de los
dos lados es mayor que el tercer lado, para todas las combinaciones posibles.
Probablemente podramos terminar con seis pruebas en total para los posibles errores
lgicos, tres para cada posible longitud de lado que podra ser mayor que la suma de los
otros dos lados, tres por cada posible longitud de lado que podra ser igual a la suma de
los otros dos lados.
Segundo, note que un programador inteligente escribira una funcin que validara que al
programa le haya sido ingresado un entero y luego reutilizara esa funcin para cada campo
de entrada. Entonces, slo tendramos que probar un carcter, un nmero real, un cero, un
entero negativo, un maxint+1, un desborde de bfer, un espacio al comienzo, un espacio al
final y un espacio en blanco, para nueve errores de entrada.
Entonces, Cmo lo hizo? Qu probamos nosotros que usted no prob? Qu prob usted
que nosotros no probamos?
Si usted no encontr algunos de estos, no se sienta mal. Al final de este libro, podr
identificar no slo todas las pruebas de arriba, sino tambin pruebas en otras reas de
riesgo.
Sin embargo, an cuando haya ledo el libro completamente, podra ser necesario que tenga
que consultar libros y notas para llegar a un conjunto completo de las pruebas. Tuvimos
que volver a leer el desarrollo del ejercicio de Myers para finalizar nuestra solucin.
Esto apunta a un tema importante de este libro. La realizacin del diseo e implementacin
de las pruebas sin material de referencia lleva a menudo a omisiones en las pruebas. La
realizacin del diseo y la implementacin de las pruebas con restricciones apretadas y
estresantes respecto al tiempo que existen durante la ejecucin de las pruebas, hacen que
tales omisiones sean an ms probables, an para probadores experimentados. Esto
subraya la necesidad de un anlisis, diseo y una implementacin cuidadosa de las pruebas
por adelantado, en vez de basarse solamente en las tcnicas exploratorias o informales.
Hay un lugar para las pruebas exploratorias en casi cada proyecto de pruebas, pero no
como una tcnica principal de pruebas.
Esta seccin, Principios Generales de las Pruebas, explicar los siguientes principios de
las pruebas:
insectos? Tal vez pudiera estar bastante seguro de que no tena gusanos picudos, sin
embargo Qu hay de otros insectos?
Algunos insectos son fciles de detectar otros no. Las pruebas son como caminar por su
huerta. Esto puede revelar la presencia de insectos, pero no puede probar la ausencia de
ellos.
Esto nos lleva al siguiente principio de las pruebas, el cual es que las pruebas exhaustivas
son imposibles.
Desafortunadamente, mucha gente piensa que la misin del equipo de pruebas es, Slo
asegurar que el software funcione antes de enviarlo. Este privilegio es completamente
imposible por razones que son bastante fciles de formular.
Por un lado si se considera el nmero de caminos diferentes de ejecucin en cualquier
parte de un software no trivial, ellos son casi infinitos. Recuerde, las aplicaciones
modernas de software consisten en decenas o cientos de millones de sentencias. El flujo de
control pasa a travs de esas sentencias por cientos, miles o millones de decisiones. Cada
una de esas decisiones puede muchas veces combinarse independientemente con todas las
otras decisiones. Por ejemplo, un cientfico de computadoras de Sun Microsystems estim
que el nmero de posibles estados en un servidor Solaris era en el orden de magnitud ms
grande que el nmero de molculas en el universo.
Por otro lado, no son slo flujos de control. Los programas existen tpicamente para
manipular datos, muchas veces datos complejos. Entonces, tenemos tambin grandes y
complejos flujos de datos en los programas. Algunos de estos flujos encaminan los datos
dentro de otras reas funcionales del sistema. Algunos de estos flujos encaminan los datos
dentro de las bases de datos, de donde son entonces extrados y utilizados ms adelante.
Se pone peor. Porque el software no es construido de materiales estandarizados como un
puente o avin, pequeos cambios en el sistema pueden causar regresiones significativas.
Estas regresiones no slo pueden ser lineales al tamao de los cambios, sino incluso
tambin pueden no estar obviamente relacionados al cambio.
Finalmente, los usuarios utilizan software de varias formas, algunas de las cuales son muy
difciles, sino imposibles de predecir. Los usuarios utilizan software en varias
configuraciones de campo, algunas de las cuales ni siquiera existen en el momento de las
pruebas.
Entonces, simplemente no hay forma de probar exhaustivamente, si por pruebas exhaustivas
queremos decir, Hasta que la probabilidad de descubrir un defecto sea igual a cero.
Incluso con la definicin de pruebas exhaustivas, que es bastante restrictiva en el glosario
del ISTQB, dice que stas prueban todas las combinaciones de las entradas y
precondiciones, lo cual todava no es posible.
Eso dicho, estas expectativas de que uno puede probar exhaustivamente, o reducir la
defectos ocurran en el 4% de los mdulos. As mismo, para su base de datos IMS, el 57%
de los defectos estaban en el 7% de los mdulos.
Como una cuestin prctica, esto puede hacer que el mantenimiento de software sea una
verdadera pesadilla. El experto en la industria del software Capers Jones informa que la
presencia excesiva de mdulos propensos a errores puede causar una reduccin del 50%
de la productividad en el mantenimiento del software.
Esto es sentido comn, pero, como dijo Mark Twain, el sentido comn es
desafortunadamente no muy comn.
Algunas personas llevan este principio a los extremos, y piensan que cada proyecto es
completamente nico. Se obsesionan con lo que es especfico, lo que los ciega a la
posibilidad de aplicar las buenas ideas de otros proyectos, organizaciones y productos. No
se equivoque. Existen las mejores prcticas de pruebas. Hablaremos de ellas en este libro.
Sin embargo, cada una de estas mejores prcticas es una prctica general que debe ser
adaptada a su proyecto. En algunos casos, por razones especficas, una buena prctica no
aplicar a un proyecto particular. Nosotros le ayudaremos a reconocer esas situaciones en
este libro.
Esta necesidad de aplicar con inteligencia y adaptar las mejores prcticas de pruebas es
crtica. El fracaso de adaptar el equipo de pruebas y sus mtodos a las necesidades
especficas que estn a la mano es una razn comn para la disolucin de los equipos de
pruebas. Una vez ms, las pruebas son una organizacin de servicios, por lo general, lo que
significa que los servicios proporcionados deben ser los servicios necesitados.
1.3.1 Ejercicios
Ejercicio 1
Haga memoria acerca de un proyecto reciente.
Haga una lista de los principios de las pruebas que recuerda que hayan sido vistos.
Haga una lista de los principios de las pruebas que recuerda que no hayan sido vistos.
Argumente.
Algunos de los otros principios de las pruebas pueden haber sido operables pero no vistos.
Por ejemplo, el agrupamiento de defectos ocurre ya sea si sabe acerca de ello o no. Puede
encontrar los agrupamientos de defectos utilizando un sistema de seguimiento de defectos y
un anlisis de causa raz para reunir datos acerca de los defectos.
T-MAP son no prescriptivos, porque proporcionan para el uso del valor del negocio la
seleccin de qu proceso debe ser implementado u omitido, y cuales procesos tienen que
ser mejorados y en qu orden. El Mejoramiento de Procesos de Pruebas y el Modelo de
Madurez de Pruebas son prescriptivos, porque proyectan puntajes de madurez acerca de
los frameworks y requieren que las mejoras sean implementadas en un orden particular a
pesar de esos niveles de madurez.
El mundo real expone aun ms variacin, mientras las personas se enfocan en las pruebas
con mayor o menor grado de formalidad y rigor.
El programa de estudios del ISTQB nivel bsico propone un framework genrico del
proceso de pruebas. ste es no prescriptivo, porque no impone un esquema de madurez y
reconoce el potencial de omisin de algunos elementos del framework en algunas
circunstancias.
Ejecutar las pruebas de confirmacin y/o regresin, cuando las nuevas versiones
de pruebas lleguen.
1.4.1 Ejercicios
Ejercicio 1
Haga memoria en un proyecto reciente.
Note cules de los pasos y tareas del proceso de pruebas del ISTQB fueron llevados a
cabo.
Note cules de los pasos y tareas del proceso de pruebas del ISTQB no fueron llevados a
cabo.
Note si algunos pasos se superpusieron o fueron completamente paralelos.
Argumente.
salida y han escuchado cuidadosamente a los informes del estado de las pruebas. Eso no
quiere decir que el equipo del proyecto sigui siempre nuestras recomendaciones;
tendemos a ser un jefe conservativo, en contra de los riesgos, mientras que muchos jefes de
proyectos se sienten cmodos aceptando niveles de riesgos ms altos. Sin embargo me
desconcierta cuando los jefes de proyectos ignoran los hallazgos de las pruebas y no tienen
criterios objetivos para la versin. Qu sentido tiene realizar las pruebas en absoluto si
no utiliza la informacin valiosa y ganada para guiar el proyecto al xito?
De todas las partes del proceso del ISQTB, las actividades del cierre de pruebas, a
menudo son las ms saltadas o truncadas. En algunos casos, esto tiene sentido. Sin
embargo, cuando un proyecto siguienteas como un proyecto de mantenimientotiene
que tratar de reutilizar los casos de prueba y otros entregables de pruebas, algn esfuerzo
es esencial para conducir las pruebas a una conclusin ordenada.
Por ltimo, en el rea de las pruebas, es importante que la gente reconozca a las pruebas
como un rea profesional especial con su conjunto nico de habilidades. stas incluyen la
escritura de guiones, el diseo de pruebas, la habilidad de explorar y atacar un sistema, la
creacin y la utilizacin de herramientas de pruebas, la construccin de modelos de
rendimiento, la redaccin de buenos informes de defectos y ms.
Como una regla general, las organizaciones involucradas en la creacin de software para
el uso interno tienden a poner demasiado nfasis en el conocimiento del dominio. Las
organizaciones que venden software tienden a poner demasiado nfasis en los
conocimientos tcnicos. La mayora de las organizaciones tienden a subestimar el
conocimiento de las pruebas.
Un buen jefe de pruebas gestionar y optimizar activamente las habilidades de su equipo.
Un probador inteligente que prev una carrera en este campo gestionar y optimizar
activamente sus propias habilidades.
La mentalidad del probador es sutilmente diferente a la de otros en un equipo de proyecto.
Probar aplicaciones y revisar especificaciones son actividades diferentes que desarrollar
cdigo o elaborar requisitos de negocio. Las mentalidades requeridas para el xito son
tambin diferentes.
Esto no quiere decir que los programadores no puedan probar su propio cdigo. Ellos
pueden y deberan realizar las pruebas unitarias, y tpicamente deberan participar en las
pruebas de integracin. Sin embargo, la mayora de los programadores tienen la mentalidad
incorrecta para realizarlo efectivamente. Ellos buscan la confirmacin de que lo que han
construido funciona, lo cual tiende a limitar psicolgicamente su efectividad en el hallazgo
y la eliminacin de los defectos.
En algunos campamentos, concretamente algunos profesionales de las diversas
metodologas giles, afirman: los programadores que practican las pruebas unitarias
automatizadas por medio de las Pruebas Dirigidas por Diseo, o algo as, no necesitan a
los probadores cerca. Veamos algunos datos.
Capers Jones en sus estudios de miles de proyectos a travs de cientos de organizaciones,
informa que las pruebas unitarias, en promedio, tienen una efectividad de eliminacin de
los defectos de alrededor del 25%. Las mejores prcticas en las pruebas unitarias resultan
en una efectividad de la eliminacin de los defectos de alrededor del 50%. Cuando
nuestras compaas, Business Innovations/RBCS, realizan evaluaciones de los equipos de
pruebas de los clientes, encontramos rutinariamente una efectividad de la deteccin de
los defectos del 80% al 85%, con un 90% hasta el 95%, que no es en absoluto inusual.
Ahora, estamos seguros de que hay mltiples razones de por qu existe esta gran diferencia
en la eficacia de la deteccin de los defectos. Una de esas razones es que la separacin de
las funciones (a travs de un equipo de pruebas independiente) ayuda a centrar las pruebas
en algo ms que confirmar que funcionan. De hecho, como se coment anteriormente, hay
En el ms alto nivel de independencia, tenemos las pruebas por medio de una persona o
personas de una organizacin o empresa diferente. Podemos tener ahora probadores con
habilidades, profesionales con la plena libertad para dar una evaluacin honesta sin temor
a reacciones adversas.
Sin embargo, los problemas de comunicacin y de los objetivos mencionados
anteriormente podran llegar a ser agudos sin una gestin cuidadosa.
Como puede ver, a lo largo de este espectro hay varios pros y contras. No es que una
solucin sea correcta y la otra equivocada, sino que las fortalezas y debilidades de cada
mtodo deben ser gestionadas y reforzadas. Una forma de hacerlo es garantizando las
pruebas por una variedad de Participantes, con diversos grados de independencia, en todo
el ciclo de vida.
Uno de los retos clave psicolgicos y sociales, el cual es especialmente urgente para el
jefe de pruebas, es la necesidad de tener objetivos de pruebas claros.
Como hemos mencionado en una seccin anterior y nuevamente ms antes en esta seccin y
habiendo expuesto con claridad, los objetivos bien alineados para las pruebas es crtico.
Esto es as porque la gente y los proyectos son usualmente dirigidos por objetivos.
No es como cuando las personas se renen un da y dicen: Oigan!, yo s, hagamos un
proyecto! Y otro responde: S, claro, Qu pasa si tambin tenemos una gran presin de
tiempo y horas extras pagadas al final? Y otro an respondiendo,Oh, s, eso sera
genial!
No, los proyectos son emprendidos por motivos. Las metas y los objetivos del proyecto
existen, aunque a veces estos no estn claramente expresados. En esos casos, estos no
podran ser compartidos a travs de los participantes del proyecto.
En la bsqueda de beneficios econmicos y sociales, las personas usualmente tratan de
alinearse usualmente con los objetivos indicados o implcitos, en la medida en que ellas
entienden aquellos objetivos establecidos por la gerencia y otros interesados del negocio.
En el rea de las pruebas, a menudo existe confusin acerca de los objetivos de las
pruebas. Muy pocas veces estn claramente definidos y bien alineados a travs de toda la
organizacin.
Al hacer evaluaciones, constantemente nos encontramos ante la confusin acerca de en qu
medida las pruebas encuentran defectos o dan confianza en la operacin correcta del
software.
Incluso cuando estos objetivos estn definidos, generalmente no hay mtricas para el xito.
Es decir, si las pruebas deberan encontrar defectos, Qu porcentaje de los defectos
deberan encontrar? Si las pruebas son para dar confianza, A qu nivel y cmo debera ser
medido eso?
Por esta razn, a menudo recomendamos una poltica de pruebas. Una poltica de pruebas
es un documento corto, un documento de dos a tres pginas que puede ayudar a definir
claramente los objetivos de las pruebas y alinear las pruebas a travs de toda la
organizacin. Hemos trabajado con una serie de clientes para ayudarles a poner en prctica
polticas de pruebas, y esas polticas les fueron de mucha ayuda.
noticia reconfortante, pero por lo menos podemos tratar de comportarnos de acuerdo a esa
situacin.
1.5.1 Ejercicios
Ejercicio 1
Reflexione acerca de las actitudes y los comportamientos de los probadores ms exitosos
que conoce.
En qu medida muestran ellos los aspectos psicolgicos abordados en esta seccin?
Qu otros elementos de sus conjuntos de personalidades y habilidades piensa usted que
conduce al xito para ellos?
Argumente.
estudios (syllabus).
_____________________________
LO es una abreviacin de la palabra en ingls Learning Objective y K es Knowledge
respectivamente. Estas dos abreviaciones hacen referencia a los objetivos del
6 aprendizaje y al nivel de conocimiento de cada objetivo como est especificado en el
Programa de Estudios Nivel Bsico 2011. (Syllabus 2011). Para mayor informacin
visitar www.istqb.org
Este ejercicio y su solucin han sido adaptados del captulo 2, del libro de Rex Black,
7
Pragmatic Software Testing.
http://es.wikipedia.org: Se usa como insecticida en cosechas agrcolas y en jardines,
8 para tratar piojos en la cabeza de seres humanos y para tratar pulgas en animales
domsticos.
es.wikipedia.org: En el desarrollo de software, un framework es una estructura
conceptual y tecnolgica de soporte definida, normalmente con artefactos o mdulos
de software concretos, con base en la cual otro proyecto de software puede ser
9
organizado y desarrollado. Tpicamente, puede incluir soporte de programas,
bibliotecas y un lenguaje interpretado entre otros programas para ayudar a desarrollar
y unir los diferentes componentes de un proyecto.
Aunque no est definido en la Real Academia Espaola es un trmino muy utilizado en
10 la informtica para indicar el la capacidad de algo que pueda ser probado o
comprobado.
Autoprueba no est definido en la Real Academia Espaola, pero es un trmino
11 utilizado en el mbito de las pruebas de software y se define como la prueba que es
realizada por el mismo autor o creador del objeto que debe ser probado.