Revisión técnica Revisión de recorrido Revisión de inspección Revisión informal

Una revisión técnica (también conocida como Un recorrido es un conjunto de procedimientos y Una inspección es un tipo formal de revisión. Una revisión informal es una opción muy
revisión por pares) se considera un tipo de técnicas diseñados para un grupo de pares, Requiere preparación por parte de los miembros popular al principio del desarrollo.
revisión formal, aunque no se espera que dirigido por el autor para revisar el código del del equipo de revisión antes de que tenga lugar la ciclo vital de ambos

asistan gerentes. Se trata de un encuentro software. Se considera un tipo de revisión reunión de inspección. Una etapa de seguimiento software y documentación. Por lo general, la
estructurado, en el que un par / s analizan el bastante informal. El recorrido toma la forma de también es un requisito de la inspección. Esto revisión la realiza un compañero o alguien
trabajo con el fin de mejorar la calidad del una reunión, normalmente entre una y dos horas asegura que cualquier reelaboración se lleve a con experiencia relevante, y debe ser informal
trabajo original. de duración. cabo correctamente. y breve.

• Idealmente dirigido por el moderador

• Dirigido por el autor • Dirigido por un moderador • Bajo costo
• asistido por compañeros /
• Asistido por un grupo de pares Nivel • Atendido por roles especificados Se • Sin proceso formal
expertos tecnicos
• variable de formalidad Recopilación de • incluyen métricas • No se requiere documentación
• Se requiere documentación
• conocimientos • Proceso formal • Revisión ampliamente utilizada
• Sin presencia de la dirección
• Detección de defectos • Criterios de entrada y salida
• Toma de decisiones
• Búsqueda de defectos
• Resolver problemas técnicos

VyV Validación Verificación Modelo de cascada

La validación y verificación de software puede Validación involucra el real La verificación normalmente implicaría
implicar el análisis, revisión, demostración o pruebas. Esto debería tener lugar después de la reuniones y revisiones y para evaluar los El modelo Waterfall también se conoce como
prueba de todos los desarrollos de software. verificación fase tiene estado documentos, planes, requisitos y el 'modelo secuencial'. Cada etapa sigue a la
Esto incluirá el proceso de desarrollo y el terminado. especificaciones. anterior. La prueba se realiza en 'bloque'
producto de desarrollo en sí. Verificación Esto se puede lograr mediante revisiones y como última etapa.
Validación: confirmación por reuniones, etc.
y Validación es examen y provisión de evidencia
normalmente se lleva a cabo al final del ciclo de objetiva de que el Verificación: confirmación por La planificación o creación de pruebas no se

examen y provisión de evidencia considera hasta que se haya escrito el código de

vida del desarrollo (después de que se completa Se han cumplido requisitos particulares para un
software real. Esto puede dar lugar a que se
todo el desarrollo del software). Pero también se uso previsto específico. objetiva de que se han cumplido los
encuentren problemas mucho más tarde en el ciclo de
puede realizar mucho antes en el ciclo de vida del requisitos especificados.
vida del proyecto de lo deseable.
desarrollo simplemente usando revisiones. Validación: ¿Estamos construyendo el producto correcto?
Verificación: ¿Estamos construyendo el producto

correctamente?
 V - Modelo Modelo espiral RAD ¿Qué es un error?

El modelo en espiral es una prueba incremental RAD representa el desarrollo rápido de

El V-Model es un marco estándar de la industria que
Acercarse a ambos aplicaciones y es un proceso de desarrollo de Error: UNA humano acción ese
muestra claramente el ciclo de vida del desarrollo de Desarrollo y pruebas. Esto se utiliza de forma software que se desarrolló a mediados de la produce un resultado incorrecto.
software en relación con las pruebas. También más eficaz cuando los usuarios no conocen década de 1980. Fue desarrollado para
destaca el hecho de que las pruebas son todos los requisitos. A partir de lo que se superar la rigidez de procesos como 'El
Un ejemplo de error sería el error ortográfico de
igualmente importantes
conoce, se pueden definir los requisitos modelo de cascada'.
iniciales. Luego, a partir de estos, se crean el una variable dentro del código del programa.
como el software
código y los casos de prueba. A medida que
desarrollo sí mismo. los pasa el tiempo, se conocen e implementan Elementos:
relaciones entre desarrollo más detalles de los requisitos en iteraciones
y las pruebas están claramente definidas. posteriores de las fases de diseño, codificación • Creación de prototipos
y prueba. El sistema se considera completo • Desarrollo iterativo
El V-Model mejora la presencia de las cuando se han realizado suficientes • Boxeo de tiempo

actividades de prueba para mostrar un enfoque iteraciones. • Miembros del equipo

más equilibrado. • Enfoque de gestión

• Herramientas RAD

¿Qué es una falla? Prueba de componentes Integración de componentes Basado en requisitos

Pruebas Pruebas funcionales

Culpa: Una manifestación de un error en el Este tipo de pruebas de integración se refiere Basado en requisitos Pruebas es
La prueba de componentes también se conoce
software. Una falla, si se encuentra, puede causar con asegurando el simplemente probando la funcionalidad del
como prueba de unidad, módulo o programa. En las interacciones entre los componentes de software
una falla. software / sistema según los requisitos. Las
términos simples, este tipo de prueba se centra a nivel de módulo se comportan como se esperaba. pruebas mismas deben
simplemente en probar los componentes Las pruebas de integración de componentes también ser derivado de el
Un ejemplo de culpa sería una variable que se denominan a menudo "pruebas de integración en requisitos documentados y no basados en el
individuales en sí.
nunca se usa dentro del código del programa. lo pequeño". código de software en sí. Este método de
prueba funcional asegura que los usuarios
Es común que las pruebas de los
obtendrán lo que quieren, ya que el
componentes las realice el desarrollador del Por lo general, se realiza después de que se han documento de requisitos básicamente
software. Sin embargo, esto tiene un completado las pruebas de componentes, y el

bajo clasificación de pruebas comportamiento probado puede cubrir aspectos especifica lo que ha solicitado el usuario.
tanto funcionales como no funcionales del sistema
independencia.
integrado.
 Procesos de negocio Prueba de carga Pruebas de rendimiento Pruebas de estrés
Pruebas funcionales

Probar la capacidad del sistema para soportar UNA programa / sistema mayo tener Stress Testing simplemente significa poner el
Los diferentes tipos de usuarios pueden utilizar el
cargas. Un ejemplo sería probar que un sistema requisitos para cumplir con ciertos niveles de sistema bajo estrés. Normalmente, la prueba no
software desarrollado de diferentes formas. Estas
pueda procesar una cantidad específica de desempeño. Para un programa, esta podría ser la se lleva a cabo durante un período prolongado, ya
formas se analizan y comercializan
transacciones dentro de un período de tiempo velocidad a la que puede procesar una tarea que esto sería efectivamente una forma de prueba
escenarios son luego
específico. Por lo tanto, está cargando el sistema determinada. Para un dispositivo de red, podría de duración. Imagine que se diseñó un sistema
creado. Los perfiles de usuario se utilizan a
de manera efectiva a un nivel alto y luego se significar el rendimiento de la tasa de tráfico de la para procesar un máximo de 1000 transacciones
menudo en Business Process Functional
asegura de que aún pueda funcionar red. A menudo, las pruebas de rendimiento están en una hora. Una prueba de estrés sería ver si los
Testing. Recuerde que debe probarse toda la
correctamente mientras está bajo esta carga diseñadas para ser negativas, es decir, demostrar sistemas realmente podrían hacer frente a tantas
funcionalidad, no solo las áreas más
pesada. que el sistema no cumple con el nivel de transacciones en un período de tiempo
utilizadas.
rendimiento requerido. determinado. Una prueba útil en este caso sería
ver cómo se adapta el sistema cuando se le pide
que procese más de 1000.

Pruebas de seguridad Pruebas de usabilidad Prueba de almacenamiento Prueba de volumen

Un requisito importante en el software / sistemas Aquí es donde se tiene en cuenta cómo el Este tipo de prueba puede centrarse en la La prueba de volumen es una forma de prueba
actuales es seguridad, usuario utilizará el producto. Es común que se memoria real utilizada por un programa o sistema de sistemas. Su enfoque principal es
particularmente con el Internet gasten recursos considerables en definir en determinadas condiciones. Además, el concentrarse en probar los sistemas mientras
revolución. Seguridad pruebas es exactamente lo que requiere el cliente y es espacio en disco utilizado por el programa / están sujetos a grandes volúmenes de datos. Las
enfocado en encontrar lagunas en los programas simple usar el programa para lograr sus sistema también podría ser un factor. Estos pruebas deben abordarse desde un punto de
seguridad cheques. UNA objetivos. Por ejemplo; Se podrían crear factores en realidad pueden provenir de un vista negativo
El enfoque común es crear casos de prueba casos de prueba basados en la interfaz requisito y deben abordarse desde el punto de a espectáculo ese el
basados en problemas conocidos de un gráfica de usuario, para ver qué tan fácil sería vista de las pruebas negativas. programa / sistema no puedo funcionar
programa similar y probarlos con el programa de usar en relación con un escenario de correctamente cuando se utiliza el volumen de datos
bajo prueba. cliente típico. especificado en los requisitos.
 Prueba de instalabilidad Prueba de documentación Prueba de recuperación Integración de sistema
Pruebas

Documentación en hoy Las pruebas de recuperación se llevan a cabo Este tipo de pruebas de integración se refiere
Un programa complicado también puede
El entorno puede tomar varias formas, ya que la normalmente mediante el uso de casos de prueba con asegurando el
tener un proceso de instalación complicado.
documentación puede ser un documento impreso, un basados en requisitos específicos. Un sistema interacciones Entre sistemas
Se debe considerar si el programa será
archivo de ayuda integral o incluso una página web. puede estar diseñado para fallar en un escenario comportarse como se esperaba. Se realiza
instalado por un cliente o una instalación
Dependiendo del tipo de medio de documentación, determinado, por ejemplo, si es atacado por un comúnmente después alguna Sistemas
algunas áreas de ejemplo en las que centrarse usuario malintencionado; el programa / sistema Se han completado las pruebas. Normalmente, no todos
ingeniero. Cliente
podrían puede haber sido diseñado para cerrarse. Las los sistemas a los que se hace referencia en las pruebas
Las instalaciones suelen utilizar algún tipo
ser, ortografía, usabilidad pruebas de recuperación deben centrarse en cómo están controlados por la organización en desarrollo.
de automatizado instalación
precisión técnica, etc. el sistema maneja la falla y cómo maneja el proceso Algunos sistemas pueden estar controlados por otras
programa. Obviamente, esto tendría que
de recuperación. organizaciones, pero interactúan directamente con el
someterse a pruebas significativas en sí mismo,
ya que un procedimiento de instalación incorrecto sistema bajo prueba.

podría inutilizar la máquina / sistema de destino.

UAT Contrato y regulación Aceptación operativa Prueba alfa

Test de aceptación Pruebas

La prueba de aceptación del usuario o 'UAT'

es comúnmente la última prueba realizada en Este tipo de prueba de aceptación tiene como Esta forma de prueba de aceptación la realiza Las pruebas alfa deben realizarse en
el producto de software antes de su objetivo garantizar que el software desarrollado comúnmente un administrador del sistema y el desarrollador sitio, y
lanzamiento real. Es común que el cliente haya cumplido los criterios de aceptación dentro normalmente estaría preocupada realizado principalmente por probadores internos
realice este tipo de pruebas, o al menos del contrato original. Normalmente, cualquier con asegurando ese solamente. A menudo, otro personal del departamento
participe parcialmente. criterio de aceptación se define cuando se funcionalidad tal como; de la empresa puede actuar como probadores. Los
A menudo, el pruebas acuerda el contrato. La prueba de aceptación copia de seguridad / restauración, mantenimiento y departamentos de marketing o ventas a menudo se
El entorno utilizado para realizar las pruebas de de la regulación se realiza cuando la funcionalidad de seguridad está presente y se comporta eligen para este propósito.
aceptación del usuario se basa en un modelo como se esperaba.

de el clientes ahí existe específico

ambiente. Esto se hace para intentar simular regulaciones que se deben cumplir, por ejemplo,
lo más fielmente posible la forma en que el puede haber regulaciones de seguridad o
cliente utilizará realmente el producto de regulaciones legales.
software.
 Prueba Beta Vuelva a probar Pruebas de regresión Plan de prueba
Documento

Es imperativo que cuando se solucione una falla, se Al comprobar una falla solucionada, también puede
Beta Pruebas es comúnmente Un plan de prueba debe ser un documento
vuelva a probar para garantizar que la falla se haya considerar la posibilidad de comprobar que otras
realizado en el sitio del cliente, y normalmente único que básicamente contiene lo que se va
solucionado correctamente. funciones existentes no se hayan visto afectadas
realizado por los propios clientes. Potencial a probar, por qué se va a probar y cómo se va
negativamente por la solución. Esto se llama prueba de
a probar. También es importante aclarar lo
regresión.
los clientes suelen estar ansiosos por probar que no se probará en el producto de software.
un nuevo producto o una nueva versión de Con respecto al uso de un diseño de Plan de
Vuelva a probar: Test de regresión:
software. Esto permite al cliente ver las prueba estándar, podemos consultar los
“Siempre que se detecte y solucione una falla, "Las pruebas de regresión intentan verificar
mejoras de primera mano y determinar si consejos brindados por el IEEE (Instituto de
el software debe volver a probarse para que las modificaciones no hayan causado
satisface o no sus requisitos. Por otro lado, ingenieros eléctricos y electrónicos) ubicado
garantizar que la falla original efectos secundarios adversos no deseados en
brinda comentarios invaluables al en el Estándar internacional IEEE Std
tiene estado exitosamente el software sin cambios (fallas de regresión) y
desarrollador, a menudo a bajo costo o sin 929-1998.
remoto." que el sistema modificado aún cumple con sus
costo alguno.
requisitos".

Prueba genérica Política de prueba Estrategia de prueba Plan de proyecto

Proceso

Existe un proceso de prueba estándar que se Esto debería aplicarse tanto a proyectos nuevos Según la política de prueba, la estrategia de prueba está Exactamente cómo la estrategia de prueba para un
usa comúnmente dentro del Estándar BS7925-2 diseñada para ofrecer una descripción general de los
como a trabajos de mantenimiento. Normalmente, la proyecto será ser
para pruebas de componentes de software:
política de prueba debe ser bastante corta y debe requisitos de prueba para un programa o incluso una implementado se muestra en el plan del proyecto. El
ser un documento de alto nivel y debe contener los organización. plan de prueba del proyecto normalmente se hará
siguientes elementos: referencia al plan general del proyecto. En relación
• Planificación de pruebas La información relacionada con los riesgos debe con la estrategia de prueba, el plan del proyecto
• Especificación de prueba documentarse aquí, específicamente los riesgos debe detallar los elementos de la estrategia de
• Ejecución de pruebas
que serán abordados por las pruebas y las
• Definición de prueba prueba que está cumpliendo, y también los
• Comprobación de prueba y comprobación de
• El proceso de prueba pruebas específicas que se utilizarán contra cada elementos que no está cumpliendo.
• grabación para Prueba
Terminación • Evaluación de pruebas riesgo.

• Niveles de calidad

• Enfoque de mejora
 Plan de prueba de fase ¿Qué es una falla? Calidad y pruebas Planificación y control de pruebas

La planificación de pruebas básicamente

Una vez que se han subsanado las fallas,
En este documento se muestran los detalles implica determinar qué se va a probar, por
Fracaso: Desviación del software de su podemos decir que la calidad del producto de
específicos del enfoque adoptado por las entrega o servicio esperado. software ha aumentado. El término de prueba qué se va a probar y cómo se va a probar.
pruebas para una fase de prueba específica. Se "Calidad" se puede considerar como un término Para cumplir con los objetivos de las pruebas,
puede pensar que se basa en el plan del general, ya que la calidad del producto de es muy importante no solo tener buenos
proyecto, pero con una mayor cantidad de software depende de muchos factores. planes, sino también asegurarse de que se
Un ejemplo de fracaso sería el hecho de que el
detalles incluidos, como las actividades de cumplan. Test Control ayudará a lograr esto,
mensaje de advertencia nunca se muestra
prueba basadas en el plan diario o la cantidad cuando es necesario. En general, el software de calidad debe estar
ya que su propósito es garantizar que el
esperada de horas hombre para completar razonablemente libre de errores, entregarse a tiempo progreso de las pruebas en curso se compare
tareas individuales. y dentro del presupuesto original. con el Plan de pruebas.

Análisis y diseño de pruebas Equivalencia Valor límite Árbol de clasificación

Fraccionamiento Análisis Método

Los objetivos de la prueba pueden provenir de una variedad

Lo que este método le permite hacer es Por el utilizar de equivalencia El método de árbol de clasificación también se
de fuentes. Esta será
particionar efectivamente las posibles entradas particionado, un probador puede realizar conoce como método de árbol de decisión y los
generalmente toman la forma de una lista o realizar pruebas efectivas sin pruebas
del programa. Para cada uno de los campos de términos se pueden utilizar indistintamente, ya que
especificación de requisitos. Una vez que se entrada anteriores, no debería importar qué cada valor posible. Esto se puede método significan lo mismo. Se puede aprender un árbol de
entienden claramente los requisitos, debería valores se ingresen siempre que estén dentro mejorar aún más con el método otro decisiones dividiendo el conjunto de fuentes en
ser posible diseñar pruebas o condiciones del rango correcto y del tipo correcto. llamado 'Límite Valor subconjuntos según una prueba de valor de
Análisis'. Después de un tiempo, un probador experimentado atributo. Este proceso se repite en cada
basadas en estos requisitos.
a menudo se dará cuenta de que los problemas subconjunto de forma recursiva. La recursividad
Entonces el punto de equivalencia lata a
ocurrir el
dividir es para reducir la cantidad de pruebas límites de los espacios de entrada y salida. Al es terminado cuando
eligiendo una pequeña selección de los probar solo una pequeña cantidad de valores la división no es posible o se puede aplicar
posibles valores a probar, ya que el programa posibles, los valores mínimos y máximos una única clasificación a cada elemento del
los manejará de la misma manera. posibles deben estar entre los primeros subconjunto.
elementos a probar.
 Transición de estado Prueba de declaración Decisión de sucursal Condición de la rama
Pruebas Pruebas Pruebas

Este método de prueba implica el uso de un Este método de prueba utiliza un modelo del
Este tipo de prueba de caja negra se basa en el La prueba de condición de rama utiliza un
modelo del código fuente que identifica código fuente que identifica al individuo
concepto de 'estados' y 'estados finitos', y se
declaraciones. Estas decisiones, y su modelo del código fuente e identifica
basa en que el probador pueda ver los estados
Las declaraciones se clasifican como resultados. Una "decisión" se define como una decisiones establecido en
del software, la transición entre estados y lo que
"ejecutables" o "no ejecutables". Para utilizar declaración ejecutable que contiene su propia individual Operandos booleanos dentro de cada
desencadenará un cambio de estado. A
este método, lógica. condición de decisión. Una "decisión" se define
continuación, se pueden diseñar casos de
el entrada a cada
prueba para ejecutar los cambios de estado. como una declaración ejecutable que contiene su
se debe identificar el componente. Además, cada Esta lógica también puede tener el
propia lógica.
caso de prueba debe poder identificar cada transferir control a
declaración individual. Por último, el resultado otra declaración. Cada caso de prueba está
esperado de cada caso de prueba debe estar diseñado para ejercitar los resultados de la Un ejemplo de decisión sería un "bucle" en un
claramente definido decisión. Para utilizar este método, programa.
el entrada a cada
se debe identificar el componente.

Condición de la rama Basado en requisitos Pruebas de usabilidad Prueba de volumen

Prueba de combinación Pruebas funcionales

Rama Condición Combinación

Basado en requisitos Pruebas es Aquí es donde se tiene en cuenta cómo el La prueba de volumen es una forma de prueba
La prueba utiliza un modelo del código fuente e
simplemente probando la funcionalidad del usuario utilizará el producto. Es común que se de sistemas. Su enfoque principal es
identifica decisiones basadas en gasten recursos considerables en definir
software / sistema según los requisitos. Las concentrarse en probar los sistemas mientras
combinaciones de Booleano pruebas mismas deben exactamente lo que el cliente requiere y qué están sujetos a grandes volúmenes de datos. Las
operandos dentro de las condiciones de ser derivado de el tan simple es usar el programa para lograr pruebas deben abordarse desde un punto de
decisión. Esta lógica también puede tener la requisitos documentados y no basados en el sus objetivos. Por ejemplo; Se podrían crear vista negativo
código de software en sí. Este método de casos de prueba basados en la interfaz a espectáculo ese el
capacidad de transferir el control a otra
prueba funcional asegura que los usuarios gráfica de usuario, para ver qué tan fácil sería programa / sistema no puedo funcionar
declaración. La condición de decisión es una de usar en relación con un escenario de
obtendrán lo que quieren, ya que el correctamente cuando se utiliza el volumen de datos
expresión booleana que se evalúa para documento de requisitos básicamente cliente típico. especificado en los requisitos.
determinar el resultado de la decisión.
especifica lo que ha solicitado el usuario.
 Pruebas de rendimiento Pruebas de estrés Análisis dinámico Análisis estático

Estrés Pruebas simplemente medio El análisis dinámico es un método de prueba que

UNA programa / sistema mayo tener El análisis estático es un conjunto de métodos diseñados
poniendo el sistema bajo estrés. Normalmente, puede proporcionar información sobre el estado
requisitos para cumplir con ciertos niveles de para analizar el código de software en un esfuerzo por
la prueba no se lleva a cabo durante un período del software. Puede lograr esto de forma
desempeño. Para un programa, esta podría ser la establecer que es correcto, previo
prolongado, ya que esto sería efectivamente dinámica, es decir, proporciona información
velocidad a la que puede procesar una tarea a Realmente corriendo el
una forma de prueba de duración. Imagine que cuando el software se está ejecutando realmente.
determinada. Para un dispositivo de red, podría software. Como ya sabemos, cuanto antes
se diseñó un sistema para procesar un máximo Se usa comúnmente para ejercitar partes del
significar el rendimiento de la tasa de tráfico de la encontremos una avería, más barato será
de 1000 transacciones en una hora. Una prueba programa que usan recursos de memoria, por
red. A menudo, las pruebas de rendimiento están solucionarlo. Por lo tanto, al usar el análisis estático,
de estrés sería ver si los sistemas realmente ejemplo:
diseñadas para ser negativas, es decir, demostrar podemos probar el programa de manera efectiva
podrían hacer frente a tantas transacciones en
que el sistema no cumple con el nivel de incluso antes de que se haya escrito. Obviamente,
un período de tiempo determinado. Una prueba
rendimiento requerido. esto solo encontraría un número limitado de
útil en este caso sería ver cómo se adapta el • Asignación de memoria
problemas, pero al menos es algo que se puede
sistema cuando se le pide que procese más de • Uso de memoria
hacer muy temprano en el ciclo de vida del
1000. • Desasignación de memoria
desarrollo.
• Pérdidas de memoria
• Punteros no asignados

Flujo de control Complejidad ciclomática Líneas de código Análisis de flujo de datos

Graficar

La idea detrás del análisis de flujo de datos es

Los gráficos de flujo de control muestran la estructura Cyclomatic Complexity es una métrica de La forma más básica de una métrica de
resolver las dependencias entre elementos de
lógica del software. Se representa el flujo de la lógica software que se utiliza para medir la complejidad es la métrica 'Líneas de código' o
datos que utiliza un programa. Cuando se ejecuta
a través del programa. Normalmente solo lo utilizan complejidad de un programa de software. Una métrica 'LOC'. Su propósito, al igual que otras
un programa, rara vez se ejecuta en un orden
los desarrolladores, ya que es un formulario de muy vez que sepamos cuán complejo es el métricas de complejidad, es estimar la cantidad
secuencial, es decir, comenzando en la línea 1 y
bajo nivel programa, sabremos lo fácil que será probarlo. de esfuerzo que se requerirá no solo para
terminando en la línea 100. Lo que suele ocurrir es
pruebas, a menudo usado en desarrollar dicho programa, sino también ayudar
que las dependencias de los datos dentro del
Prueba de componentes. a estimar cuánto esfuerzo se requerirá para
programa determinarán el orden. El análisis de flujo
C=E-N+P probarlo.
de datos se puede utilizar para encontrar
Se puede utilizar para determinar el número de
"definiciones" que no tengan ningún "uso"
casos de prueba necesarios para probar la lógica • C = Complejidad ciclomática E =
intermedio. El análisis de flujo de datos también se
del programa. También puede brindarle la • número de aristas En su forma más simple, podríamos usar la
utiliza para detectar variables que se "utilizan"
confianza de que se ha verificado el detalle de la • N = número de nodos métrica LOC contando literalmente el número de
después de haber sido "eliminadas" de forma
lógica en el código. • P = número de componentes líneas de código en el programa.
efectiva.
 Error al adivinar Prueba exploratoria Pruebas ad-hoc Pruebas aleatorias

Este tipo de prueba normalmente se rige por el Este tipo de prueba se considera el más
¿Por qué un Tester puede encontrar más errores Un probador normalmente selecciona datos de
tiempo. Consiste en utilizar pruebas basadas en informal, y muchos lo consideran el menos
que otro Tester en la misma pieza de software? La entrada de prueba de lo que se denomina un
un capítulo de prueba que contiene los objetivos efectivo. Las pruebas ad-hoc son
mayoría de las veces, esto se debe a una técnica "dominio de entrada". La prueba aleatoria es
de la prueba. Es más eficaz cuando hay pocas o simplemente inventar las pruebas sobre la
llamada 'Adivinación de errores'. Para tener éxito simplemente cuando el probador selecciona datos
ninguna especificación disponible. En realidad, marcha. A menudo, se utiliza cuando hay muy
en Error Guessing, se requiere un cierto nivel de del dominio de entrada 'al azar'. Como puede ver,
solo debería usarse para ayudar o complementar poco tiempo para probar algo. Un error
conocimiento y experiencia. Un evaluador puede hay poca estructura involucrada en las "pruebas
un enfoque más formal. Básicamente, puede común que se comete con las pruebas
entonces hacer una suposición fundamentada aleatorias". Para evitar tener que lidiar con las
garantizar que la funcionalidad principal funcione Ad-hoc es no documentar las pruebas
sobre dónde pueden surgir problemas potenciales. preguntas anteriores, se podría implementar un
como se espera sin probarla por completo. realizadas y los resultados de las pruebas.
Esto podría basarse en la experiencia de los diseño de prueba de caja negra más estructurado
Incluso si se incluye esta información, la
probadores con una iteración previa del software,
mayoría de las veces no se registra
o simplemente en un nivel de conocimiento en lugar. Sin embargo,
información adicional, como versiones de
El uso de un enfoque aleatorio podría ahorrar
software, fechas, detalles del entorno de
tiempo y recursos valiosos si se usa en las
prueba, etc.
en ese zona de circunstancias adecuadas.
tecnología.

Seguro de calidad Específico de la industria Estándares de prueba Definición de revisión

Estándares Estándares

Revisión: Un proceso o reunión durante el cual un

Los estándares de prueba detallarán cómo realizar producto de trabajo, o un conjunto de productos
Un estándar de garantía de calidad (QA) Un estándar específico de la industria detallará
las pruebas. Idealmente, una prueba de trabajo, se presenta al personal del proyecto,
simplemente especifica que se deben realizar las exactamente qué nivel de prueba se realizará.
estándar debería ser gerentes, usuarios u otras partes interesadas para
pruebas.
referenciado de un estándar específico de QA o de comentarios o aprobación. [IEEE]

Ejemplo: ISO 9000 Ejemplos: la industria.

Se debe realizar una revisión cuando toda la

• Estándar de señalización ferroviaria
Ejemplo: BS7925-1, BS7925-2 documentación de respaldo esté disponible. Esto
• DO-178B
puede incluir documentos de diseño,
• Estándar de la industria nuclear
requisitos
• Directrices de MISRA para software de vehículos
documentos, documentos de normas,
de motor
básicamente cualquier documentación que
• Estándares farmacéuticos
haya sido influyente o sea aplicable al
documento a revisar.
 Revisar roles Proceso de revisión Administracion de incidentes IEEE Std. 1044-1993
Estructura

A continuación se muestra un ejemplo de un proceso de Denominamos incidente; cualquier evento

Las organizaciones suelen tener roles con Este estándar tiene como objetivo proporcionar un
revisión típico. Este es probablemente el significativo no planeado que ocurra durante la
nombres diferentes a los que se enumeran a enfoque estándar para la clasificación de anomalías
más documentado revisión prueba que requiera investigación y / o
continuación, pero esto le dará una idea de un encontradas en el software. Incluye
proceso que encontrará en el mundo del corrección subsecuente. El incidente debe
conjunto de roles de uso común en todo el descripciones de el
desarrollo de software y está abierto a plantearse cuando el resultado real difiera del
mundo. procesos involucrados en un ciclo de vida del
interpretación: resultado esperado. Después de la
software, incluidos detalles sobre cómo deben
investigación inevitable del incidente, puede
• Gerente registrarse y procesarse posteriormente las
• Planificación haber una razón que no sea una falla de
• Moderador anomalías. Consiste en
• Patada inicial software, por ejemplo:
• Autor cuatro secuencial pasos;
• Preparación
• Crítico Reconocimiento, Investigación, Acción,
• Reunión
• Escriba Disposición. Cada uno de esos pasos tiene tres
• Rehacer • Probar entorno incorrectamente
actividades administrativas que son;
• Seguimiento preparar
Grabación, Clasificando,
• Criterio de salida • Datos de prueba incorrectos utilizados
Identificación del impacto.
• Especificación de prueba incorrecta

Implementación de pruebas y Evaluación de criterios de salida Actividades de cierre de pruebas Atributos del desarrollador
Ejecución e informes

Esta etapa es donde se realiza la prueba real. Puede Esta etapa está diseñada para garantizar que las Esta etapa se ocupa de recopilar los resultados
Atributos de un desarrollador:
significar ejecutar los casos de prueba manualmente o actividades de prueba realizadas cumplan los Criterios de las pruebas y la documentación relacionada

mediante el uso de una herramienta de prueba de salida especificados. Los criterios de salida con las pruebas para lograr un hito antes del
Muy valorado dentro de la
automatizada. Sin embargo, antes de que esto suceda, deberían haberse especificado previamente en la lanzamiento del producto. Cualquier defecto empresa.Cualificaciones estándar de la industria.
los diseños de los casos de prueba deben convertirse etapa de planificación de pruebas. Los resultados de la encontrado durante la prueba debería haberse Visto como creativo
en casos de prueba reales. prueba almacenados se pueden comparar en esta corregido y verificado en esta etapa. Como con Comunicadores pobres
Habilidades en un área muy específica
etapa con los criterios de salida. Si no se han cumplido la mayoría de los proyectos de desarrollo,

los Criterios de salida, es posible que se requieran más siempre se encuentran problemas, aquí hay

pruebas o incluso se pueden recomendar cambios en una buena etapa para evaluarlos e intentar

los Criterios de salida. Esta es una buena etapa para aprender

crear un resumen de la prueba.

alguna lecciones para futuro
desarrollos.
 Atributos del probador Reseñas - Gerente Reseñas - Moderador Reseñas - Autor

Atributos de un probador: Gerente Moderador Autor

El Gerente será la persona que tome la decisión El moderador tiene efectivamente el control El autor es la persona que ha creado el
Rara vez valorado dentro de una empresa
de realizar la revisión. Administrar el tiempo de general y la responsabilidad de la revisión. Ellos artículo a revisar. También se le pueden
Ninguna calificación estándar de la industria las personas con respecto a la revisión también programarán la revisión, controlarán la revisión y hacer preguntas al autor en la revisión.
Considerada destructiva es una responsabilidad de los gerentes. se asegurarán de que cualquier acción de la
Muy buenos comunicadores revisión sea
Multitalentoso llevado fuera exitosamente.
Es posible que se requiera capacitación para
desempeñar con éxito la función de moderador.

Reseñas - Revisor Reseñas - Scribe Proceso de revisión formal Análisis estático

Herramientas

El proceso de revisión: Al examinar el código en lugar de ejecutar casos

Crítico Escriba
de prueba a través del código, este tipo de
Planificación herramienta puede proporcionar información sobre
Los revisores son los asistentes a la revisión El escriba (o registrador) es la persona
Patada inicial la calidad real del software. La complejidad
que intentan encontrar errores en el elemento responsable de documentar los problemas
Preparación ciclomática es una de esas características que se
bajo revisión. Deben provenir de diferentes planteados durante el proceso de la reunión
Reunión puede obtener utilizando este tipo de herramienta.
perspectivas para proporcionar una revisión de revisión.
Rehacer
bien equilibrada del tema.
Seguimiento
Criterio de salida
 Herramientas de diseño de pruebas Datos de prueba Herramientas de ejecución de pruebas Arneses de prueba
Herramienta de preparación

Este tipo de herramienta puede generar casos de prueba a Los datos se pueden seleccionar de las bases de datos Se trata de un tipo de herramienta extremadamente
Si el software que se está probando no tiene una
partir de especificaciones, que normalmente se almacenan específicas de prueba existentes utilizando este tipo de popular. Proporcionan funciones de captura y
herramienta. Los tipos avanzados de esta herramienta reproducción para aplicaciones basadas en interfaz interfaz de usuario, se pueden utilizar los mazos de
en un repositorio de herramientas CASE. Algunas
variaciones de este tipo de herramienta también pueden pueden utilizar una variedad de formatos de archivo y bases WIMP. Las herramientas cables de prueba y los controladores para ejecutar el

generar casos de prueba a partir del análisis del código en de datos. lata simular ratón software. Estos tipos de herramientas se pueden
sí. movimiento, ratón clics y comprar en el estante, pero más comúnmente se
entradas de teclado. Las herramientas pueden incluso
construyen para un propósito específico.
reconocer ventanas y botones, por lo que
haciendo ellos extremadamente
versátil. Los procedimientos de prueba normalmente
se escriben en un lenguaje de programación
específico. Esta herramienta es otra
popular elección para
pruebas de regresión.

Administracion de incidentes Prueba de rendimiento Análisis dinámico Soporte del proceso de revisión
Herramientas Herramientas Herramientas Herramientas

Este tipo de herramienta almacena y gestiona los Este tipo de herramienta consta de dos La información en tiempo de ejecución sobre el estado
Este tipo de herramienta proporciona funciones como
informes de incidentes. Esta herramienta puede del software en ejecución se obtiene mediante el uso
componentes; Generación de carga y medición almacenar comentarios de revisión, revisión
priorizar los informes de incidentes. La asignación
de transacciones de prueba., de herramientas de análisis dinámico. Estas procesos, trazabilidad
automática de acciones y los informes de estado
La generación de carga se realiza herramientas son ideales para monitorear el uso y la entre documentos y código fuente.
también es una característica común de este tipo
de herramienta. comúnmente por corriendo el asignación de memoria. Se pueden encontrar fallas

aplicación usando su interfaz o usando como pérdidas de memoria, punteros no asignados,

controladores. A continuación, se registra el número que de otra manera serían difíciles de encontrar

de transacciones realizadas de esta manera. Las manualmente.

herramientas de prueba de rendimiento comúnmente

podrán mostrar informes y gráficos de carga frente al
tiempo de respuesta.
 Comparadores de prueba Gestión de pruebas Medición de cobertura Herramientas de modelado
Herramientas Herramientas

Este tipo de herramienta se utiliza para resaltar las Las herramientas de gestión de pruebas suelen tener Este tipo de herramienta proporciona medidas Hoy en día existen varios tipos diferentes de

diferencias entre los resultados reales y los esperados. múltiple caracteristicas. Prueba objetivas de cobertura de pruebas estructurales herramientas de modelado, que pueden ir desde

Las herramientas de comparación listas para usar encontrar defectos en modelos de estado, modelos de
La gestión se ocupa principalmente de la cuando se ejecutan las pruebas reales. Antes de
normalmente pueden trabajar con una variedad de objetos y modelos de datos. Se pueden encontrar
gestión, creación y control de la documentación compilar los programas, primero se instrumentan.
formatos de archivos y bases de datos. Este tipo de defectos valiosos utilizando herramientas de modelado,
de prueba. Las herramientas más avanzadas Una vez que esto se haya completado, se pueden con el beneficio adicional de encontrarlos al principio del
herramienta a menudo tiene capacidades de filtrado
para permitir 'ignorar' filas o columnas de datos o incluso
tienen capacidades adicionales probar. El proceso de instrumentación permite ciclo de vida del desarrollo.

áreas en una pantalla. tal como prueba registrar los datos de cobertura mientras se ejecuta
funciones de gestión, por ejemplo; registro de el programa. Una vez que se completan las
resultados y programación de pruebas. pruebas, los registros pueden proporcionar
estadísticas sobre los detalles de las pruebas
cubiertas.

Herramientas de monitoreo Pruebas de seguridad Requisitos Selección de herramientas

Herramientas Herramientas administrativas Proceso

Este tipo de herramienta está diseñada para ayudar Un proceso de selección y evaluación de
Estas herramientas se utilizan normalmente para Estas herramientas se utilizan comúnmente para probar
con la verificación y validación de herramientas sugerido es:
probar aplicaciones de comercio electrónico y aplicaciones de comercio electrónico y negocios
negocios electrónicos. El objetivo principal de esta electrónicos y, a veces, sitios web. Una herramienta de requisitos, para ejemplo;
comprobación de coherencia. También están • Determinar el problema o requisito real
herramienta es verificar los sitios web para asegurarse prueba de seguridad verificará cualquier parte de un
de que estén disponibles para los clientes y también sistema basado en la web que pueda causar posibles diseñados para almacenar declaraciones de
requisitos, lo que ayuda con la trazabilidad. • Asegúrese de que no haya soluciones
generar advertencias si se detectan problemas. riesgos de seguridad si se ataca.
alternativas obvias
• Prepare un caso de negocio
• Identifique las limitaciones
• Identificar las características o características
específicas de la herramienta.Preparar una lista
• corta de posibles herramientas adecuadas.

• Realice una evaluación detallada Realice una

• prueba competitiva, si es necesario
 Proyecto de piloto Revisión - Planificación Revisión - Kick-off Revisión - Preparación

Lo último que presentamos querer es

una herramienta dentro el Debe haber conciencia de cualquier empresa Normalmente, una semana antes de la revisión Todos los participantes de la revisión examinan el
organización, solo para encontrar algunos políticas, producto planificada, el moderador se asegura de que el elemento que se va a revisar. Si se usan estándares,
semanas más adelante falla resultante requisitos y / o planes de proyecto que artículo esté listo para su revisión y distribución. El entonces se deben usar verificaciones de desviación de
en escenarios potencialmente desastrosos. Para mayo proporcionar específico moderador también informa a los asistentes sobre los estándares. También se puede utilizar la
evitar esta situación, podemos implementar un requisitos para que se lleve a cabo una revisión. La sus roles y responsabilidades. comparación con elementos similares.
proyecto piloto. Los beneficios de utilizar un definición de los criterios de Entrada y Salida, la

proyecto piloto son; selección de personal también se realiza en esta etapa.

• Adquirir experiencia usando

la herramienta
• Identifique cualquier cambio en el proceso de
prueba
• Identifique las deficiencias
idoneidad de la herramienta

Reunión de revisión Revisión - Retrabajo Revisión - Seguimiento Revisión - Criterios de salida

El moderador se asegura de que todo el trabajo Los criterios de salida pueden adoptar la forma de
La revisión normalmente dura entre 1 los Moderador y Escriba
adicional del autor sea verificado para verificar garantizar que se completen todas las acciones o que
- 2 horas. Todos los elementos de la agenda / lista de Documente los hallazgos en un Resumen de
verificación cualquier elemento no corregido esté debidamente
son trabajó revisión e informe al gerente. El Resumen de la que esté completo y sea correcto. Es posible que
se requiera una revisión adicional; depende de la documentado, posiblemente en un sistema de
mediante. El registrador anota los resultados. Los revisión contendrá los defectos encontrados y las
cantidad / complejidad seguimiento de defectos.
comentarios están dirigidos al elemento de acciones del trabajo de seguimiento a realizar.
revisión, no al autor. de rehacer
emprendido.
 El líder de la prueba El probador El cliente El Gerente de Proyecto

El líder de la prueba normalmente tendrá

experiencia en pruebas y tendrá un El Probador obviamente proporciona las El cliente es efectivamente el patrocinador del Las habilidades de gestión las proporciona el
conocimiento completo de cómo se realizan habilidades necesarias para realizar la Prueba en proyecto y proporcionará el presupuesto del proyecto. Project Manager. El Gerente de Proyecto
las pruebas. También poseerán una buena sí. Esta función puede incluir el diseño y la El Cliente también puede ser el propietario del participará activamente durante todo el
experiencia gerencial. También son ejecución de pruebas. Las habilidades de prueba negocio. proyecto y proporcionará retroalimentación al
responsables de garantizar que la cobertura automatizadas también son un posible requisito de cliente.
de la prueba sea suficiente y se les pedirá que este rol. La siguiente lista muestra algunas
produzcan informes. actividades de ejemplo que podría esperar que
realice un Tester:

• Crear especificaciones de prueba

• Preparación de datos de prueba Ejecutar
• pruebas y proporcionar resultados

El desarrollador El analista de negocios El analista de sistemas El diseñador técnico

El diseño de los sistemas estará a cargo del El detalle técnico y el soporte al diseño del
Un desarrollador proporcionará las habilidades para El Business Analyst proporcionará
analista de sistemas. El analista de sistemas sistema es responsabilidad del Diseñador
escribir el código de software real y realizar pruebas conocimiento del negocio y análisis
también será responsable de desarrollar Técnico. Este papel puede
unitarias. También se les puede llamar en una etapa habilidades. los Negocio
el Funcional incluir base de datos
posterior para proporcionar correcciones de errores y El analista también será responsable de crear los
Especificación de el Usuario administración.
asesoramiento técnico. requisitos del usuario en función de las conversaciones
con los usuarios. Requisitos.