Metodologías del Testing Funcional
LTI – Plan 2024 1
Metodologías del Testing Funcional
Contenido
TERMINOLOGÍA .................................................................................................................. 3
TÉCNICAS, NIVELES Y TIPOS DE TESTEO....................................................................... 6
Niveles de Testeo – Algunas Notas para Considerar ................................................... 7
Sub Tipos o Categorías – Algunas Notas para Considerar .......................................... 8
TESTING EXPLORATORIO ............................................................................................... 10
PRODUCTOS DE PRUEBAS ............................................................................................. 13
Plan de Pruebas ............................................................................................................ 13
Informe Final de Pruebas .............................................................................................. 14
LTI – Plan 2024 2
Metodologías del Testing Funcional
El material incluido aquí es COMPLEMENTO del material proporcionado en otros recursos, no lo
sustituye, solo lo complementa.
Son objetivos de este material, aportarles algunas notas de interés dentro de algunos de los conceptos
desarrollados antes; presentarles el tema de Testing Exploratorio y profundizar en dos de los
productos de un equipo de Testing.
TERMINOLOGÍA
Bug = Defecto = Falta: Características que pueden causar que un componente o sistema
no realice las funciones requeridas.
Error = Desperfecto: Acción humana que produce un resultado incorrecto.
Falla (fallo): Desviación de un componente o sistema con relación al resultado esperado.
Calidad: Grado con el que un componente, sistema o proceso alcanza los requerimientos
especificados o las expectativas de los usuarios.
Depurar: Actividad de búsqueda de las causas de una falla en el software, normalmente
realizada por el programador.
Requisito / Requerimiento: Exigencia de tipo funcional o no funcional que debe ser
cumplida por el software para satisfacer una necesidad de los usuarios.
Revisión: Observación de alguna de las formas del software (documentación, código
fuente, ejecutable…) realizada a lo largo del proceso de desarrollo con el fin de evaluar
que se han alcanzado los objetivos fijados. Se trata de una actividad planeada y
organizada, con mayor o menor grado de formalidad.
Prueba de Confirmación Volver a probar una nueva versión del software para un caso de
prueba que ha mostrado error, con el fin de verificar si ha sido corregido.
LTI – Plan 2024 3
Metodologías del Testing Funcional
Prueba de regresión: Prueba de un software previamente probado en una versión
anterior, para verificar que en la nueva versión no se han introducido errores.
Incidencia: Un evento ocurrido que requiere investigación.
Criterio de salida: Conjunto de condiciones generales y específicas, aceptadas por el
cliente, tal que permiten que el proceso sea oficialmente terminado. Evitar ambigüedad
y malos entendidos respecto al momento de dar por terminada una prueba.
Base de pruebas: La documentación en la que se basan los casos de prueba. Es el conjunto
de documentos de donde los requisitos de un componente o sistema se pueden inferir
(caso de base de pruebas congelada).
Condición de prueba: Un ítem o evento de un componente o sistema que debería ser
verificado por uno o más casos de prueba, [Link]. una función, transacción, rasgo, atributo
de calidad o elemento estructural.
Caso de prueba: Conjunto de valores de entrada, precondiciones de ejecución, resultados
esperados y postcondiciones de ejecución, desarrollado con un objetivo particular o
condición de prueba, tales como probar un determinado camino de ejecución o para
verificar el cumplimiento de un requisito determinado. (IEEE 610)
Objetivo de la prueba: Razón o propósito para diseñar y ejecutar una prueba:
o Validación del software
o Prevención y detección de defectos
o Aumentar la información acerca de la calidad del software
o Aumentar la confianza en el software
o Identificación de riesgos potenciales
o Análisis de zonas de mejora posible
Datos de prueba: Datos que existen previos a la ejecución de la prueba (o se ingresan
durante la misma) y que afectan o son afectados por el sistema bajo prueba.
LTI – Plan 2024 4
Metodologías del Testing Funcional
Nivel de prueba: Hace referencia al nivel del ciclo de vida subyacente (por ejemplo:
prueba de sistema).
Grado de prueba: Nivel de profundidad o extensión de la prueba (parcial, completa)
Datos de prueba: Datos que existen previos a la ejecución de la prueba (o se ingresan
durante la misma) y que afectan o son afectados por el sistema bajo prueba.
Cobertura de las pruebas: Porcentaje en el cual se ha realizado pruebas a un elemento,
con relación a una serie potencial de pruebas.
Ejecución de prueba: Proceso de utilización de un componente o sistema, produciendo
resultados reales.
Política de pruebas: Documento de alto nivel describiendo principios, enfoques y los
objetivos principales de las pruebas de software en el proyecto.
Estrategia de pruebas: Descripción general que indica qué niveles de prueba deben ser
realizados y los tipos de prueba en cada nivel.
Serie de pruebas: Conjunto de casos de prueba para un componente, donde la post
condición de uno es usualmente la pre-condición del siguiente caso de prueba.
Elementos (utensilios) de pruebas / bases de prueba: Artefactos producidos durante el
proceso de pruebas, necesarios para planificar, concebir y ejecutar las pruebas, tales
como documentos, guiones, datos de entrada y de salida, procedimientos de ejecución,
archivos, entornos y otros software o herramientas utilizadas para las pruebas.
LTI – Plan 2024 5
Metodologías del Testing Funcional
TÉCNICAS, NIVELES Y TIPOS DE TESTEO
En el Módulo 3 se desarrollaron todos los aspectos relacionados al área de Testing que están dentro
del testeo funcional.
Recordemos la relación entre los conceptos de técnicas, niveles y tipos de testeo vistos en temas
anteriores:
Ahora, focalizados en Testing Funcional, tenemos que:
• De las técnicas vistas, el Testing Funcional es básicamente caja negra con algunas excepciones,
donde nos vamos a caja gris. Funcionalmente, nunca abordamos la técnica caja blanca.
• De los niveles mencionados, en el contexto del Testing Funcional, se trabaja con testeo de sistema,
testeo de integración de sistemas y testeo de aceptación. En este contexto, no abordamos los
niveles de testeo unitario (que es responsabilidad del equipo de desarrollo) ni testeo de
operabilidad (que es parte del testeo estructural).
• Y, claramente, estamos abocados al tipo de Testing Funcional.
LTI – Plan 2024 6
Metodologías del Testing Funcional
El diagrama quedaría más o menos así:
Niveles de Testeo – Algunas Notas para Considerar
Como vimos en otra parte del material, existen diferentes niveles de testeo que se “mueven” dentro
de las tres técnicas conocidas.
Los niveles de testeo que se consideran dentro del Testing Funcional, son los siguientes:
• Testeo de sistema,
• Testeo de integración de sistemas
• Testeo de aceptación.
Vamos a agregar aquí, algunas notas de interés dentro de estos niveles ya vistos.
Testeo de Sistema - Nota
Dentro del testeo de sistema, es importante considerar la siguiente nota:
Si bien el foco de MTF es el Testing Funcional, y siempre que hablemos de testeo de sistema, será en
relación a las pruebas funcionales, es oportuno aclarar, que el nivel testeo de sistema, incluye tanto
testeo de funcionalidad (Testing Funcional), como testeo de rendimiento, carga, estrés,
configuración, seguridad, instalación, entre otros (testing estructural, de arquitectura y relacionado a
los cambios).
LTI – Plan 2024 7
Metodologías del Testing Funcional
Testeo de Integración de Sistemas - Nota
Dentro del testeo de integración de sistema, es importante considerar la siguiente nota:
Si bien el foco de MTF es el Testing Funcional, y siempre que hablemos de testeo de integración de
sistemas, será en relación a las pruebas funcionales, es oportuno aclarar, que en este nivel de testeo
se verifica además la integración de todas las aplicaciones con su hardware, software y componentes
de la infraestructura necesaria (testing estructural, de arquitectura y relacionado a los cambios).
Testeo de Aceptación (UAT - User Acceptance Testing)
Además de lo que ya vimos de este nivel de testeo, es importante entender qué son las pruebas
pensadas de forma end-to-end:
Se refiere a las pruebas diseñadas para pasar por todo el aplicativo de punta a punta, desde que
ingresa un dato de entrada hasta que se registra en la base y se muestra el resultado
correspondiente.
Además, dentro del testeo de aceptación, es importante considerar la siguiente nota:
Según la naturaleza del negocio y del aplicativo en sí, este nivel de pruebas propone incluir pruebas
de seguridad. Estas pruebas pueden tener un pequeño componente funcional y gran parte de testeo
estructural. En estos casos, es necesario contar con algún usuario final con perfil técnico.
Sub Tipos o Categorías – Algunas Notas para Considerar
Dentro del Testing Funcional, existen distintos sub-tipos, que si bien persiguen el mismo objetivo, se
diferencian entre sí por el foco que cada uno de ellos da a las pruebas funcionales.
Todos los sub-tipos son complementarios a la hora de pensar en las pruebas funcionales; es
prácticamente imposible que, trabajando con uno solo de ellos, se cubran las pruebas funcionales
necesarias de un aplicativo, para asegurar su calidad. Es importante tener presente este hecho a lo
largo de la carrera, así como también, después como profesionales de TI.
En adelante, tanto en este tema como en el resto de la unidad curricular, mencionaremos estos sub-
tipos, directamente como tipos de testeo funcional.
Algunos de los sub-tipos de Testing Funcional más conocidos, son los siguientes:
• Testeo de componentes
• Testeo de interfaces
• Testeo de regresión
• Testeo de usabilidad
• Testeo de procedimientos y documentación
LTI – Plan 2024 8
Metodologías del Testing Funcional
• Testeo de flujo de transacciones
• Testeo de manejo de errores
• Testeo de control y auditorias
• Testeo de conversión
• Testeo en paralelo
En el material se desarrollaron los 4 primeros. Aquí vamos a agregar algunas notas sobre cada uno de
ellos.
Testeo de Componentes
Dentro del testeo de componentes, es importante considerar la siguiente nota:
Es oportuno aclarar que la división en componentes, debe ser identificada de forma temprana y
acordada con todos los equipos de trabajo del proyecto. Determinar cada componente no es una
tarea fácil: es complejo definir los límites para que cada componente sea útil por sí solo e
independiente de otros, y es complejo acordar las dependencias de liberación de cada componente
definido; aquí radica la importancia de que todos los involucrados en el proyecto, tengan claro cada
componente y estén de acuerdo con la división que se realice. Si bien cada componente es una
“pieza” independiente de otra, es parte de un todo que debe funcionar como tal, por esto es
importante dejar bien claras las dependencias de liberación de los componentes. Una vez
identificados los componentes del requerimiento, desarrollo podrá trabajar sobre cada componente
de forma independiente, luego cada componente será publicado en el ambiente de pruebas, y así
podrá ser verificado. Recordar que esta división en componentes, debe estar acordada en tiempo y
forma por todos en el proyecto.
Testeo de Interfaces
Dentro del testeo de interfaces, es importante considerar la siguiente nota:
Es oportuno aclarar aquí, que el relevamiento de las interfaces con las que se comunicará el
aplicativo que se va a crear, debe ser realizado durante el análisis de los requerimientos del sistema y
luego, durante el diseño del mismo, se deberá incluir información técnica sobre todas las interfaces
identificadas (incluso se puede incluir alguna nueva interfaz o cambiar y/o quitar alguna de las
identificadas durante el análisis de requerimientos). En caso de que se trate de la modificación de un
aplicativo existente, es importante precisar el alcance del cambio de forma de identificar las
interfaces que realmente se verán afectadas por dicho cambio. Esto también es una tarea para
realizar durante el análisis de los requerimientos.
LTI – Plan 2024 9
Metodologías del Testing Funcional
Testeo de Usabilidad
Dentro de lo que es el testeo de usabilidad, les compartimos la siguiente curiosidad:
De un tiempo a esta parte, este tipo de pruebas está tomando más importancia, ya que es una
condición cada vez más relevante para el éxito de cualquier aplicativo, en cualquier industria. Existen
talleres de profesionalización de testing, específicos en usabilidad y adaptabilidad de los sistemas
informáticos. Además, se pautaron estándares de usabilidad a nivel mundial.
TESTING EXPLORATORIO
Dentro del testeo funcional manual, existen diferentes enfoques, relacionados a la “forma” de trabajo
que se adopta.
La clasificación de enfoques “tradicional”, es la siguiente:
• Ad-hoc
• Planificado
• Exploratorio
En estos tiempos, en los que metodologías de trabajo deben adaptarse a la realidad de los proyectos
ágiles, esta clasificación de enfoques cambia un poquito; se habla de:
• Ad-hoc
• Guionado
• Exploratorio
¿Por qué testeo guionado y no planificado? Porque el testeo exploratorio también se planifica!! El
Testing Funcional, casi siempre es una combinación de testing exploratorio y testing guiado, pero con
una tendencia hacia uno de ellos, dependiendo del contexto del proyecto. En proyectos que trabajan
bajo con metodologías tradicionales, la tendencia es ir hacia el testing guiado; mientras que en
proyectos bajo metodologías ágiles, la tendencia es ir hacia el testing exploratorio.
Pero antes recordemos que:
LTI – Plan 2024 10
Metodologías del Testing Funcional
• Hablamos de Testing Ad-hoc cuando las pruebas se hacen sin planificar y sin documentar; cuando
se ejecutan algunas pruebas de manera rápida pero no exhaustiva, no ordenada y poco pensadas;
son pruebas improvisadas. Claramente, se trata de pruebas que serán ejecutadas una única vez.
Se podría decir que, si estas pruebas son usadas como parte del testeo unitario, antes de liberar
el aplicativo al ambiente de testeo, tienen la ventaja de que los defectos “grandes” pueden ser
encontrados de forma rápida.
A nivel de Testing, no queremos hacer esto; no hay seguimiento ni trazabilidad; como trabajo
ofrecido por un equipo de Testing, es poco profesional.
• El Testing Guionado (comúnmente conocido como Testing Planificado), es cuando primero se
diseñan las pruebas y luego son ejecutadas, incluso por alguien distinto a quien los diseñó. Estas
acciones que se realizan en distintos tiempos del proyecto. Dentro de la planificación del
proyecto, se cuenta con tiempo planificado para diseñar los casos de prueba una vez que se haya
cerrado el análisis de los requerimientos; y también se cuenta con tiempo de ejecución, que
sucederá después de diseñado y programado el aplicativo, una vez que el mismo sea liberado a
Testing.
Vale la pena aclarar que existen distintos estilos dentro del Testing Exploratorio, que van desde un
testeo exploratorio sin planificación y sin pienso (gracias a este estilo de testing exploratorio, es que
todo el enfoque exploratorio se ganó la fama de que es un testeo sin planificación), hasta un testeo
exploratorio planificado.
La definición de Testing Exploratorio, según James Bach, es que “es un proceso simultáneo de
exploración del producto (aprendizaje), diseño y ejecución de pruebas”.
Según Cem Kaner, “Es un estilo de testear software que enfatiza, la libertad personal y responsabilidad
individual del tester, para optimizar de manera continua el valor de su trabajo, tratando al aprendizaje,
diseño y ejecución de pruebas, como actividades que se apoyan mutuamente y corren en paralelo a lo
largo de un proyecto.”
En definitiva, el Testing Exploratorio es un enfoque de Testing en el que simultáneamente se aprende
sobre el aplicativo, se diseñan casos de prueba y se ejecutan dichos casos; cuando un tester hace
Testing Exploratorio, diseña y ejecuta pruebas con un objetivo (misión) en concreto. Estas tres
actividades simultáneas, se realizan para una sesión; y cada sesión se establece a partir de la misión
concreta que se haya definido.
No se trabaja al azar (es decir, no se prueba por probar), sino que se fija un objetivo (o misión), se
diseñan las pruebas para cubrir ese objetivo, se ejecutan dichas pruebas, y se sacan conclusiones con
las que se va aprendiendo sobre el aplicativo; en base a la información de estas conclusiones, se fija
un nuevo objetivo, se diseñan y ejecutan nuevas pruebas. Y así, se logra un aprendizaje continuo del
producto de software que se está probando. El diseño de las pruebas no se documenta de forma
rigurosa (propósito, paso a paso y resultado esperado), pero si se documenta lo que se quiere probar
(es decir, los propósitos de cada prueba; quizás de forma un poco más extensa que en un caso formal
LTI – Plan 2024 11
Metodologías del Testing Funcional
de prueba ya que representa toda la prueba), de forma de tener registro de lo probado, así como
también para poder reusarlos.
Cuando se opta por hacer testing exploratorio, es importante que antes de empezar se definan estos
dos puntos:
1. El objetivo que se quiere conseguir con la sesión de Testing Exploratorio (por ejemplo
establecer los flujos que podrían seguir los usuarios finales del aplicativo y probarlos, ver
cómo se integra la aplicación con software externo, entre otros). Este objetivo lo puede
fijar el propio tester, el equipo de testing, el test manager o todo el equipo de trabajo
(esto se da generalmente, en proyectos ágiles), dependiendo del contexto del proyecto.
2. Limitar de alguna manera adecuada a la realidad del proyecto, el tiempo que vamos a
dedicarle a esa actividad de testing (por ejemplo, sesiones de 1 hora, 25 min).
Se limita lo que se quiere conseguir en cuánto al tiempo, pero el objetivo es bastante general y no se
indica qué pasos debe ir verificando el tester. El tester es el responsable de definir el camino a seguir
para conseguir ese objetivo y puede ir cambiando, a medida que va aprendiendo sobre el aplicativo
durante el tiempo establecido.
La calidad del Testing Exploratorio, está ligada a las habilidades del tester para realizar los casos de
prueba oportunos y encontrar los defectos presentes. Es por esto, que es necesario que los testers
tengan una mente abierta, pensamiento crítico, sean observadores, creativos y curiosos, para detectar
los defectos más complejos y evaluar riesgos.
El Testing Exploratorio, es ideal para cuando se tiene poco tiempo, o se conoce poco el producto a
probar (ya sea un aplicativo entero o una funcionalidad), o no se cuenta con documentación detallada.
Cerrando el tema, podemos decir que el Testing Exploratorio requiere planificación, limitación de
tiempos y objetivos claros; no está “peleado” con documentar; y hacerlo bien, no es una tarea trivial.
LTI – Plan 2024 12
Metodologías del Testing Funcional
PRODUCTOS DE PRUEBAS
Existen diversos productos de testing. Aquí vamos a presentarles en detalle dos de ellos: Plan de
pruebas e Informe final de pruebas.
Plan de Pruebas
El propósito de un plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario,
responsables y manejo de riesgos, de las pruebas de un proyecto particular.
Para armar un plan de pruebas, lo primero que se debe hacer es entender los requerimientos que
componen el aplicativo a prueba, y determinar claramente cuáles serán parte de las pruebas y cuáles
no. Es decir, determinar el alcance de las pruebas.
Es necesario dejar claro en este documento, que metodología y procedimientos de prueba se usarán
durante la vida del proyecto.
Es importante definir la estrategia a seguir durante todo el proyecto, en común acuerdo con los otros
interesados del proyecto (por ejemplo, es básico conocer y acordar las liberaciones de las versiones
del producto a probar con desarrollo; definir con el cliente las pruebas de aceptación, quienes y dónde
se realizaran; definir con operaciones la liberación a producción, que pruebas se harán en este
ambiente; entre otros puntos).
Debe hacer referencia a la planificación concreta del proyecto, de forma que testing se mueva dentro
de las fechas y estimaciones de todo el proyecto. Y contener la planificación (y estimaciones)
específica para las pruebas.
Seleccionar cuáles son los tipos de pruebas que se van realizar, incluyendo detalles de los mismos y
aclarando sobre qué puntos del alcance se usará cada tipo.
Es muy importante para un plan de pruebas, definir los criterios de inicio, aceptación y suspensión de
las pruebas. El documento debe contener una sección con este punto. Por un lado, determinar las
condiciones que deben cumplirse para dar inicio o reanudar las pruebas; así como también bajo qué
condiciones se dará por aceptado el aplicativo a prueba, dando por cerradas las pruebas; y finalmente,
bajo qué condiciones se podrán suspender las pruebas del aplicativo.
Dejar claramente identificados los ambientes de trabajo, y si es posible, cómo se relacionarán los
ambientes de prueba con los otros ambientes (por ejemplo, desarrollo y producción, o con ambientes
externos que sean necesarios para pruebas de integración de sistemas por ejemplo).
Es importante también, que este documento contenga información sobre qué equipo es necesario
para cubrir las pruebas en tiempo y forma, y la capacitación que se requiera para el mismo.
LTI – Plan 2024 13
Metodologías del Testing Funcional
También incluirá una sección de riesgos, donde se detallen los riesgos identificados para las pruebas,
así como también la probabilidad de ocurrencia y la mitigación correspondiente, para cada uno de los
riesgos identificados.
Informe Final de Pruebas
El objetivo de este documento, es brindar información relevante respecto al trabajo realizado durante
un proyecto de software, con respecto a testing.
Para cubrir este objetivo, el documento contiene las siguientes secciones:
• Contexto: Esta sección debe contener información respecto al proyecto en sí mismo:
o objetivos del proyecto
o alcance del software a desarrollar
• Equipo de trabajo: Esta sección debe contener la siguiente información:
o nombre e integrantes del equipo
o roles de los integrantes del equipo dentro de las diferentes etapas del proyecto.
• Ambiente de pruebas y Herramientas utilizadas: Esta sección debe incluir los datos del ambiente
de prueba que se utilizó, las publicaciones realizadas en dicho ambiente (día, funcionalidades
publicadas, defectos corregidos) y una breve descripción de las herramientas de testing utilizadas.
• Alcance de las pruebas: Esta sección debe incluir la lista de las funcionalidades que efectivamente
se probaron. Si existieron funcionalidades que no fueron probadas, deberían incluirse aquí bajo el
título “Fuera del alcance de las pruebas”.
• Descripción de las pruebas realizadas: Esta sección debe incluir una descripción de la estrategia
utilizada para la ejecución de las pruebas (según el orden de liberación de las funcionalidades en
el ambiente de testeo, como se organizaron la ejecución de las pruebas, en qué orden, cómo
organizaron la regresión de las pruebas).
• Descripción de los defectos reportados: Esta sección debe incluir un resumen de defectos
abiertos al finalizar la entrega del proyecto, y una descripción del motivo por el que quedó abierto
cada uno (se puede tratar de una sugerencia de mejora, que quedó pendiente para una próxima
versión del aplicativo por ejemplo). Recordar que los defectos abiertos, son aquellos que no
fueron solucionados antes del pasaje a producción (en nuestro caso, antes de la entrega final del
proyecto).
LTI – Plan 2024 14
Metodologías del Testing Funcional
• Conclusión: Esta sección debe contener dos partes bien diferenciadas: por un lado, sus puntos de
vista respecto a las actividades de testeo ejecutadas durante el proyecto, así como también
sugerencias de mejora sobre las mismas. Y por el otro lado, todos los comentarios pertinentes
sobre la calidad del producto entregado.
No existe una “forma única” de este documento, y el mismo puede contener más información sobre
estos y otros puntos, que se consideren relevantes para el proyecto en el que se realizan las pruebas.
LTI – Plan 2024 15