Pruebas Funcionales: Se enfocan en los requisitos funcionales como casos de uso y reglas de
negocio, su finalidad es verificar la apropiada aceptación de datos, Verificar el procesamiento,
recuperación y la implementación de las reglas del negocio
Se ejecutan con cada caso de uso o flujo de caso de uso usando datos validos e inválidos.
Unitarias – Humo - regresión – integración.
Pruebas no Funcionales: es la verificación de un requisito que especifica criterios que pueden
usarse para juzgar la operación de un sistema (requisitos no funcionales).
Compatibilidad – seguridad – stress- usabilidad
Pruebas Unitarias: asegura que cada unidad funcione correcta y eficientemente por separado.
Verifica que el código hace lo que tiene que hacer.
Pruebas de Integración: se enfocan en las interacciones entre los componentes y los sistemas,
verifica que los cambios no interfirieron en el funcionamiento de las interfaces, componentes o
sistemas existentes
Pruebas de regresión: volver a probar un programa previamente probado, después de algunas
modificaciones para asegurarse que no haya errores debido a los cambios realizados.
Pruebas de Humo: Permite detectar problemas que por lo regular no son detectados en las
pruebas normales, las pruebas de humo no son exhaustivas, pero van de extremo a extremo.
Error: El hecho de equivocarse
Defecto: Error visualizado en el código (sin ejecutarlo)
Falla: Cuando el sistema falla debido al defecto (en tiempo de ejecución o producción)
Caso de prueba o test case: Un conjunto de valores de entrada, precondiciones de ejecución,
resultados esperados y postcondiciones de ejecución, desarrollados para un objetivo particular de
condición de prueba, tal como para ejercer una ruta de un programa en particular para verificar
el cumplimiento de un requisito específico
Test plan: documento de recopilación de todos los casos de prueba que se deben ejecutar y el
orden que deben seguir.
Principios de prueba (7):
efectuar una prueba donde no existen defectos no significan que estos no existen, sino
que la prueba no pudo detectarlos.
NO existe una prueba que cubra todas las necesidades y variables del cliente
Se realizan al inicio de vida de los productos
Agruparlas por grupo ayudara a detectar el mismo tipo de defecto más rápido
Deben actualizarse periódicamente para detectar nuevos tipos de errores
Se efectúan dependiendo del funcionamiento del software
El producto final debe de cumplir con las expectativas del usuario.
Proceso de Pruebas: Contempla 5 elementos principales que describen el ciclo de vida de un
producto:
Planificación y Control: define objetivos y cumplir metas establecidas como: mejorar la
calidad del producto, identificar defectos, facilitar información para la toma de decisiones
evitar la aparición de defectos.
Análisis y diseño de Pruebas: Transforma los objetivos en tareas que debemos hacer, por
ejemplo: revisar la base de pruebas, requisitos e informes de análisis de riesgo también se
diseñan y ordenan los casos de prueba se diseña la configuración del entorno de pruebas
Ejecución: Se especifican los procedimientos, se verifica que el entorno de pruebas haya
sido correctamente configurado, implementar los casos de prueba finalmente se registran
los resultados de ejecución
Evaluación de Criterios de Salida: Compara la ejecución de las pruebas con los objetivos
que definimos previamente. Elaborar un resumen de las pruebas para los clientes y equipo
de trabajo.
Actividades de Cierre: se recopilan los resultados de las pruebas terminadas, comprobar
los documentos que han sido entregados, cuantos usuarios aceptaron las pruebas
El proceso de pruebas es mas grande que el de la ejecución analiza y verifica todo el sistema.
Modelos de Pruebas: Un modelo contiene las diferentes formas en que se puede aplicar los
diferentes tipos de prueba, para escoger el mejor modelo debemos verificar los objetivos de
trabajo y elegir el que mejor nos convenga
Desarrollo secuencial (modelo V): se basa en 4 modelos de prueba que son
Pruebas de componente
Pruebas de integración
Pruebas de sistema
Pruebas de aceptación
Desarrollo Iterativo- Incremental: forma un grupo de tareas y forma una parte del sistema y sirve
para la probarlo.
Iteraciones: numero de veces que realizas una prueba modificando las condiciones.
Existen mas modelos de prueba qui pueden combinarse y van a depender del tipo de arquitectura
del sistema.
Niveles de Prueba: es el orden en el que deben ejecutarse las pruebas
Pruebas de caja blanca (pruebas de estructura): Están basadas en el funcionamiento del código
del software se verifican puntos tales fallas en la seguridad interna, trayectorias mal estructuradas,
el flujo a través del código su finalidad es mejorar el diseño del sistema su seguridad y usabilidad
del sistema.
Pruebas de caja negra: verifica la funcionalidad del software sin examinar el código, (pruebas de
humo).
Tipos de Herramientas:
Herramientas de Gestión: se pueden emplear durante todo el ciclo de vida del software
Gestión de pruebas (interfaces para ejecutar pruebas, localizar defectos y elaboración de
reportes)
Gestión de Requisitos (Almacena los requisitos y atributos para proporcionar indicadores)
Gestión de incidencias (guardan y administran información sobre las fallas y peticiones)
Gestión de Configuraciones (Contiene y administra las versiones de soporte del software,
útiles para más de un entorno)
Herramientas de Ejecución: Permiten encontrar las fallas de software en una etapa temprana del
desarrollo de pruebas
Revisión (almacenan y comunican los informes de las fallas)
Análisis Estáticos (ayudan a localizar defectos sin la necesidad de realizar pruebas
dinámicas y analizan la estructura y dependencia).
Modelado (validar modelos de software además localizan y enumeran los defectos).
Análisis de Riesgo: Elemento fundamental para el desarrollo de un proyecto
Identificación de los riesgos
Riesgos del proyecto: cualquier evento incierto que puede impactar al proyecto, tiene 3 categorías
principales:
Riesgos organizacionales: son los que están relacionados con los recursos humanos involucrados
del proyecto
Riesgos Técnicos: Son los que causan mas perdidas por las malas ejecución de las pruebas.
Riesgos de Negocios: factores externos al proyecto, como clientes o socios.
Riesgos del producto: se refiere a la posibilidad de que el software o sistema no cumpla con las
expectativas del cliente (problemas de funcionalidad).
Análisis de impacto: Probabilidad de que un riesgo ocurra
Alta o nivel 3 (alta Probabilidad de que ocurra un problema 75%)
Media o nivel 2 (Media posibilidad de que ocurra un problema 50%)
Baja o nivel 1 (Baja probabilidad de que ocurra un problema menos del 25 %)
Impacto:
Alto o nivel 3 (el problema impacta a todo el proyecto, el proyecto no puede continuar sino se
resuelve).
Medio o nivel 2 (El problema impacta a partes importantes del proyecto y debe atenderse lo antes
posible)
Bajo o nivel 1 (El proyecto afecta a partes no vitales del proyecto es necesario que se resuelva sin
embargo se pueden tomar otras alternativas en lo que se soluciona)
Prioridad:
Nivel 6 a 9 Alta: se deben atender inmediatamente y se deben monitorear todos los días hasta
que se resuelvan.
Nivel 3 a 5 Media: requiere que sean tratados y monitoreados en juntas internas.
Nivel 1 a 2 Baja: es necesario monitorear el problema ocasionalmente.
Toma de contramedidas:
Riesgo
Monitoreo
Control de riesgo.
Estimación de Pruebas: Nos permite tener una idea estimada de cuanto tiempo y dinero nos
tomara realizar las pruebas
¿Cómo hacer una estimación?
Dividir el proyecto en tareas y subtareas de tal manera que cada una de ellas sea lo más
explícita.
Asignar cada una de las tareas a algún miembro el equipo tomar en cuenta las habilidades
experiencia y conocimiento del equipo
Estimación de esfuerzo por tarea.
Estimación de los tres puntos
Punto “A” los mejores probadores y todos los recursos disponibles
Punto “M” (El más probable) Probadores adecuados y recursos suficientes
Punto “B” Equipo sin la mejor experiencia y escasos recursos.
Una vez se tiene la estimación se envía a los administradores del proyecto para la aprobación de
esta. Es buena practica dejar un tiempo de “reserva” por cualquier cambio un tiempo estimado de
una semana es lo recomendable.
Plan de pruebas:
Elaborar un plan de pruebas ahorra esfuerzo y tiempo durante el proceso de análisis.
Análisis: estudiar la documentación del software
Estrategia de pruebas:
Determinación del alcance de pruebas.
Elementos que se les va a realizar la prueba se les conoce como bajo cobertura se tienen que
conocer los requerimientos del cliente, las especificaciones del producto, presupuesto asignado,
habilidades y numero de equipo de trabajo,
Elementos que no están bajo prueba pero que están definidos fuera de cobertura.
Identificación de tipo de Prueba
Dependiendo de las metas del proyecto determinaremos que prueba hacer (Humo, Integración,
Unitarias etc.)
Análisis de Riesgo
Evento futuro incierto que tiene cierta posibilidad que ocurra genere perdidas. (falla)
Estrategia de Prueba
Define quien ejecutará la prueba y cuando lo hará (se consideran las habilidades de cada tester y
requerimientos del cliente)
El tester debe tener una buena cooperación y atención al detalle
Capital humano
El Objetivo de toda prueba es encontrar la mayor cantidad de errores y que el software este libre
de fallas cuando sea adquirido por el usuario final
Para definir los objetivos de prueba se necesita determinar todas las aplicaciones del software que
necesitan probarse (mediante una lista) planificar las pruebas dependiendo de la importancia de
las funciones del software.
Criterios de Prueba: es un estándar que se establece durante el proceso de pruebas con el que se
ahorra tiempo
Criterio de suspensión: determina el punto critico del ciclo de prueba (si se suspende se
reanudará hasta que el criterio sea solucionado).
Criterio de salida: determina la finalización exitosa de una fase de pruebas se considera el
objetivo esperado que es necesario para pasar a la siguiente fase (se consideran porcentajes como
Tasa de ejecución tiene que ser igual al 100% casos ejecutados entre casos de pruebas totales,
Tasa de éxito es el porcentaje de casos de prueba exitosos entre casos de pruebas ejecutados
debemos conseguir un alto porcentaje esto dependerá del alcance del proyecto).
Planeación de recursos.
Resumen detallado de todos los recursos disponibles para la realización del proyecto (humanos,
económicos, equipo)
Planeación del ambiente de pruebas.
Trata de recrear el escenario real al que se enfrentara la aplicación dentro del software o
hardware.
Calendarización
Técnica utilizada para monitorear el avance del proyecto (cantidad de gente disponible para las
pruebas, días laborales y fecha de entrega y riegos del proyecto).
Entregables
Todos los documentos, herramientas o componentes que se aplican en el proceso de pruebas, por
ejemplo, documentación del plan de prueba y de los casos de prueba, simuladores reporte de
defectos y resultados
Resultado
Creación de casos de prueba
En el ambiente de procesos de prueba se necesita ser especifico ya que los escenarios son
confusos y cubren un amplio rango de posibilidades.
Casos de prueba es el conjunto de acciones que sirve para verificar una característica o función
específica de un software.
Constan de valores de entrada (datos de prueba)
Datos de prueba son los datos que existen (por ejemplo, en una base de datos) antes de que una
prueba sea ejecutada y que afectan o son afectados por el componente o sistema en pruebas.
Precondiciones y postcondiciones son elementos opcionales en casos de prueba.
Al realizar casos de prueba debemos tener en cuenta:
Utilizar el Lenguaje más simple. Para que cualquier persona pueda utilizarlo
si distintas pruebas usan el mismo caso de prueba usarlo como condición,
seguir las especificaciones documentadas (no asumir características o funcionalidad).
Diseño de Pruebas: Técnicas para diseñar los casos de prueba.
Tabla de decisión: usada cuando el software admite mas de un dato de entrada y genera una
respuesta a cada combinación
Diagrama de transición de estados: prueba las diferentes transacciones presentes en un sistema y
esta compuesta por los siguientes elementos 4 elementos:
Estados que el software puede ocupar
Transición de un estado a otro
Eventos
Acciones
Valores Limite: Técnicas que facilita el proceso de prueba para cubrir las más importante.
Equivalencia de particiones: Técnica de caja negra que se puede aplicar en cualquier nivel
de prueba, consiste en dividir los casos que pueden considerarse lo mismo; valores limites son los
que se prueban entre los límites de las particiones.
Pruebas de calidad: Son las pruebas que garantizan la calidad de software
Pruebas de exactitud y de adecuación: las de exactitud comprueban que el software
cumple con los requerimientos específicos por otro lado las de adecuación verifican y
evalúan la capacidad de un conjunto de funciones para la realización de tareas especificas
Pruebas de Interoperabilidad: se examina que una aplicación funcione correctamente en
todos los entornos es decir la forma en que estos se relacionan entre sí.
Pruebas de usabilidad: grado de adecuación del software (proporcionar funciones que
satisfacen las necesidades declaradas e implícitas) la flexibilidad en el control y el logro de
objetivos se realizan en la fase de diseño del software y cuyo objetivo es analizar los
siguientes factores:
o Eficacia: capacidad del software para cumplir con los objetivos específicos incluye
facilidad y exactitud.
o Eficiencia: el sistema permite la navegación de los usuarios entre pantallas y que
haya uniformidad en la aplicación.
o Precisión: No deben existir datos incorrectos u obsoletos, ni enlaces rotos
o Satisfacción: El usuario esta conforme con el uso del software
o Accesibilidad: se ejecutan para asegurar que el sistema puede ser usado por
personas con discapacidades o necesidades particulares (reconocimientos de voz,
lectura de pantalla, etc.)
Pruebas técnicas: tipos de prueba que tienen como meta verificar la función del producto para
asegurar su calidad. Su meta es encontrar todas las vulnerabilidades del sistema. Que
comúnmente son errores de diseño o configuración o bugs de software, se encargan de validad la
capacidad que tiene el software para impedir los ataques de seguridad más comunes (accesos no
autorizados, copias no autorizadas de información, ruptura de cogido de encriptación).
Pruebas de fiabilidad: su objetivo es determinar una medida estadística que comparare la
estabilidad real con la esperada.
Pruebas de robustez: evalúa la tolerancia del software ante fallos que ocurren de manera externa
y se comunica mediante el sistema operativo.
Pruebas de recuperabilidad: valora la capacidad el sistema de restablecerse de una falla ya sea de
hardware o software y maneja los siguientes aspectos:
Failover: simular o controlar fallos controlados. Comprueban los sistemas failover
y comprobar que no hubo afectación en el servicio o perdida de datos.
Back-up y restablecimiento: son los que establecen medidas para minimizar las
consecuencias tras una falla.
Pruebas de mantenibilidad: facilidad con la que un software puede ser analizado, modificado o
probado de las cuales podemos mencionar:
Pruebas dinámicas de mantenimiento: Se enfocan en los requerimientos
para verificar que se alcancen los niveles de servicio requeridos.
Pruebas de mantenimiento correctivo: Miden el tiempo en que una falla
en el sistema es corregida.
Pruebas de mantenimiento adaptativo: valoran 3 condiciones
o El esfuerzo requerido para modificar el sistema
o probar los cambios
o La respuesta del sistema a esas variaciones
Es necesario probar el software para verificar como funciona como fue diseñado
Pruebas de eficiencia: el software responde sobre circunstancias específicas entre estas pruebas
Pruebas de carga: Miden la capacidad del sistema cuando soporta niveles
crecientes de carga los cuales simulan condiciones normales de operación con
estas pruebas logramos clasificar las siguientes características:
o Máxima capacidad de operación del sistema.
o Determina si la infraestructura actual es suficiente para soportar la
aplicación
o Sustentabilidad de la aplicación correspondiente a los picos de uso
Pruebas de Estrés: el objetivo de esta prueba es determinar su estabilidad,
confiabilidad y determinar los limites en los que falla
Pruebas de escalabilidad: Miden la capacidad de un sistema para satisfacer las
necesidades futuras como por ejemplo más información almacenada o un
incremento en las operaciones realizadas
Pruebas de Utilización de recursos: Evalúan la forma en que los sistemas utilizan
los recursos disponibles entre los que se encuentran, ancho de banda, espacio de
memoria y capacidad del disco.
Pruebas de portabilidad: Su finalidad es medir que tan fácil puede ser transferido
un sistema
o Pruebas de instabilidad: son para verificar que el software pude ser
instalado siguiendo un manual o un asistente de instalación
o Pruebas de compatibilidad: su función verifica si el software es capaz de
funcionar correctamente en diferentes sistemas operativos, entornos de
red o hardware.
Prueba exploratoria: está basada en la experiencia del tester y su objetivo esta basado en
la investigación y aprendizaje, sus características son:
Creación simultanea de los casos de pruebas y su ejecución.
Se enfoca en la investigación del sistema o su aplicación
Mejora el diseño de pruebas
El tester tiene el control de las pruebas sin seguir ningún guion
determinado.
Los elementos de las pruebas exploratorias constan de 5 elementos que
son:
Clasificación de defectos: cataloga los errores mas comunes del pasado y
analiza la causa que origino esos defectos.
Carta de prueba es un documento que debe contener que y como debería
probarse
Cuadro de tiempo: dos testers deben trabajar 90 minutos sin interrupción
con el fin de ver la reacción del sistema y preparar la respuesta correcta
Revisión de resultados: se evalúan los defectos encontrados en las áreas
cubiertas por las pruebas
Cierre: se juntan los resultados de las pruebas para verificar si se necesita
alguna prueba adicional.
Proceso de mejoramiento de Pruebas: La calidad de un sistema está relacionada con la calidad del
proceso utilizado para desarrollar un producto.
Modelos que utilizan marcos de referencia para juzgar la capacidad de un proceso
TMM (Test Maturity Model): Modelo de madurez
o Inicial: representa un estado donde no hay un proceso de pruebas formalmente
documentado y estructurado
o Definición: Se establecen objetivos, políticas y técnicas de pruebas
o Integración: es cuando el proceso de pruebas se integra en el ciclo de vida del
producto y se documenta con normas, procedimientos y métodos formales
o Gestión y medición: es cuando el proceso de pruebas puede ser medido,
gestionado y adaptado a proyectos específicos de forma eficaz
o Optimización: representa el estado en el que la información obtenida puede ser
utilizada para evitar defectos en el proceso de prueba
TPI (Test Process Improvement): el proceso de pruebas se revisa a través de varios
puntos.
o Ciclo de vida
o Organización
o Infraestructura
o Herramientas
Dentro de estos cuatro existen elementos que llamamos Áreas Claves y cubren todo el
proceso de prueba las cuales se clasifican en diferentes niveles para asegurarse que cada
área es asignada en el nivel adecuado se deben establecer una serie de requerimientos
llamados puntos de control.
CTP (Critical Testing Process): La premisa de este modelo es que hay determinados
procesos de prueba críticos.
Para emplear este modelo se evalúan los procesos de prueba existentes que varían en
función del contexto especifico, determina cuales procesos son más fuertes y débiles.
Puntos críticos: El proceso de prueba, establecimiento del contexto, análisis de riesgo para
la calidad, prueba de estimación y planeación, prueba del equipo y sistema de desarrollo,
administración de la versión de prueba, prueba de ejecución, reporte de bugs, cambio de
administración
5 pasos por seguir una vez identificados las áreas de mejora:
o Dar prioridad a la solución de problema
o Planear el proceso de mejora
o Implementar el cambio y medir la mejora en el tiempo
o Consolidar el cambio para convertirlo en modo en el que se hacen las cosas
o Volver a comenzar
STEP (Systematic Test and Evaluation Process)
No se necesitan que las pruebas se hagan en un orden especifico, consideran las pruebas
como una actividad dentro de la vida de un software especifico que comienzan dentro de
la definición de requerimientos
Entre sus características están: Las pruebas se realizan al principio del ciclo de vida, se emplean
como requisito y modelo de uso, el diseño de soporte de prueba conduce al diseño del producto,
los probadores y diseñadores trabajan conjuntamente.
Las métricas utilizadas: Estados de pruebas en el tiempo, requisitos de prueba y cobertura de
tiempo, tendencia y densidad de los defectos, porcentaje de defectos encontrados y efectividad al
eliminarlos, costes de las pruebas en términos de tiempo, utilización del proceso de pruebas
definido, satisfacción del cliente.
Administración de defectos: proceso colección de defectos.
Descubrimiento: comunicación entre el tester y los comunicadores de los defectos que se
han encontrado; verifican que realmente existan errores para poder pasar a la siguiente
etapa
Categorización: clasificación de los defectos encontrados: Critica – Alta – Media – Baja
Resolución de Defectos:
Asignación: Desarrolladores se encargan de reparar los
defectos
Programación de la reparación: los desarrolladores crean un
programa para reparar los defectos reportados
Reparación de defectos: Los tester verifican que las fechas se
cumplan en la reparación de defectos
Reporte de Solución: Entrega de documento de parte de los
desarrolladores con la información de los defectos reparados.
Verificación: el equipo de tester verifica los cambios funcionen
y no haya provocado nuevos defectos
Clausura: conclusión de un defecto
Reporte: Los miembros que pertenecen a las pruebas tienen que estar enterados de los defectos.
Ciclo de vida de un defecto: Nuevo, asignación, apertura, solucionado, espera de prueba. Prueba,
verificado, cerrado.