INTRODUCCION QA

1
La calidad es una medida de excelencia. Se refiere a un estado libre de defectos,
deficiencias o variaciones significativas de un producto o resultado que se entrega para
satisfacer los requerimientos específicos de un proyecto o cliente.

Introducción al testing y a la industria del software

Para comprender esta definición en contexto, es importante revisar cómo se
produce software.

Ciclo de vida de producción de software (o SDLC, software development lifecycle,

por sus siglas en inglés).

La producción de software se puede iniciar por una de dos vías:

 Proyecto
 Producto

Proyecto: existe un cliente particular con una necesidad específica para su

negocio. Ej: Una peluquería que trabaja con turnos que desea además cobrar en
el momento en el que se gestiona el turno.

El cliente entonces contacta a un proveedor de software y le detalla sus

necesidades. El desarrollador (puede ser un individuo o una compañía, muchas
veces llamadas software factories) toma nota de los requerimientos, hace las
preguntas necesarias para entender mejor aquellas cuestiones que el cliente no
sabe especificar - si desea que sea posible tomar turnos en feriados, por ejemplo -
y luego realiza un cotización en base al esfuerzo - horas y cantidad de
desarrolladores necesarios. Si el cliente lo acepta, se inicia el proyecto.

Entonces: un proyecto es una solución particular para un cliente con necesidades

específicas. Típicamente nos encontramos a entidades financieras, bancos,
gobiernos y grandes empresas entre los clientes que solicitan soluciones a
medida, con alto grado de confidencialidad y exigencia.

Producto:

La propuesta de software para un producto se inicia con la detección de una

necesidad en el mercado. Por ejemplo, podemos decir que la compra remota es
una necesidad que puede ser satisfecha a gran escala. Soluciones como Amazon,
Ebay, Mercado Libre pretenden dar solución a esta necesidad. El camino es un
poco distinto ya que el que produce el software responde casi siempre a un
esfuerzo de un equipo (muchas veces una start up) que trabaja para entender
cómo resolver ese problema de forma que muchos usuarios en el mundo deseen
utilizar ese software. Entonces un producto pretende resolver un problema a gran
escala y sus usuarios habitualmente van directo a consumirlo.
Para el ciclo de vida de desarrollo de software, ser un proyecto o ser un producto
no cambia el orden en el que ocurren los pasos.

El ciclo de vida del desarrollo de software luce así:

1. Estrategia: Recopilación de requisitos y planificación /Strategy:

requirements specification and planning
2. Diseño de software /Software design
3. Desarrollo de software /Software development
4. Prueba e Integración /Testing and integration
5. Despliegue /Deployment
6. Operacionalización y Mantenimiento / Operation and maintenance

Secreto de la industria:
Existen varias versiones del gráfico o los pasos del ciclo de vida de la producción
de software. La idea es que comiences a familiarizarte con la idea de que el
momento del testing es un paso previo a la entrega del producto al cliente. Lo
más probable es que en un proyecto real, estos pasos estén superpuestos. Por
ejemplo: mientras se termina de desarrollar la fase 2, puede que el equipo de
testing ya esté trabajando en las pruebas de la fase 1 y que también el cliente
vaya viendo entregas parciales. Vamos a profundizar sobre este tema cuando
veamos "Producción ágil de software" en encuentros futuros

El acto de testear un software es un acto de QC (o sea, de quality control -

controlamos que la calidad sea la que prometimos). Y QA se refiere al
responsable de garantizar que todo el proceso desde los requerimientos hasta
el final cumpla con los estándares de calidad prometidos. Que incluye, por
supuesto, hacer testeos de código, pero también incluye procesos de
desarrollo de código, testeos unitarios, testeos estáticos y otros procesos que
tal vez un tester no realice nunca, ya que caen bajo la responsabilidad de los
desarrolladores de software.

Ciclo de producción de software: testing

Cuando el código es pequeño y no es complejo es relativamente sencillo hacer un
pequeño test para comprobar que esté funcionando. Cuando somos
desarrolladores a eso lo llamamos unit testing.

Si durante la resolución de los desafíos en Scratch, realizaron pruebas intermedias

para comprobar que el código estuviera actuando como ustedes lo habían
imaginado, estuvieron realizando acciones de unit testing.
 En programación, una prueba unitaria o test unitario es una forma efectiva de
comprobar el correcto funcionamiento de las unidades individuales más
pequeñas de los programas informáticos. Por ejemplo, una función o un
procedimiento.

En el ciclo de vida de producción de software, ese tipo de testing se realiza

durante la etapa de development o desarrollo y la realizan los equipos de
desarrolladores.

Etapa de testing:

Una vez que el código ha sido chequeado por parte del equipo de desarrollo, se
envía al equipo de Quality control (QC) para que revisen si funciona. Aquí nos
adentramos en el corazón del trabajo de un equipo de testing.

¿Cómo se prueba el software?

Se realiza un empaquetado para poder implementar el software en un ambiente

especial de pruebas para garantizar la calidad. Las pruebas o el control de calidad
garantizan que las soluciones implementadas superen el estándar de calidad y
rendimiento. Esto puede implicar repetir pruebas unitarias, la realización de
pruebas de integración y de extremo a extremo, verificación/validación e informes
o identificación de errores o defectos en la solución de software.

Aquí el tester es protagonista, debe encontrar los fallos cometidos en la etapa o

iteración y reportarlos, para resolverlos antes de la siguiente etapa o iteración. Su
éxito se medirá en su capacidad de encontrar estos errores antes que el usuario.

¿Cuándo comienzan las pruebas de software en SDLC?

La mayoría de la gente piensa en las pruebas de software como algo que sucede
al final del proceso de desarrollo de software. Después de todo, ¿qué podría ser
más lógico que probar el producto que se acaba de crear?

En realidad, las pruebas de software deben comenzar mucho antes de que el

producto terminado esté listo para enviarse. De hecho, a menudo es mejor
comenzar a probar temprano en el SDLC, cuando todavía hay muchos cambios
por hacer.

La primera fase del SDLC (strategy) incluye la recopilación o análisis de

requisitos.

Aquí es cuando determina qué debe hacer el sistema y cómo funcionará. También
es cuando se identifican los posibles riesgos y problemas que deben abordarse.
Como todavía no hay nada del producto desarrollado, es como ver los planos de
una casa a punto de ser construida. Podemos anticipar algunos problemas antes
de gastar dinero en construir, pero otros solamente los podremos ver una vez que
se inicia el desarrollo del código.

El diseño de las pruebas debe comenzar durante la recopilación de requisitos para

garantizar que el sistema funcione según lo previsto y que no haya fallas
importantes. Si se encuentran problemas en esta etapa inicial, a menudo se
pueden solucionar antes de que se invierta demasiado tiempo y dinero en el
desarrollo.

Una vez que se finaliza la documentación de los requisitos, se procede al diseño

(design) y desarrollo (development). Aquí es donde tiene lugar la escritura de
código real y el producto comienza a tomar forma. El código debe probarse a
medida que se escribe, para asegurarse de que funciona correctamente y cumpla
con todos los requisitos.

En este punto, las pruebas no solo se preocupan por la funcionalidad; también

comienzan a abordar el rendimiento y la escalabilidad.

El producto debe poder manejar la carga esperada y ofrecer tiempos de respuesta

aceptables. (¿Te suena familiar que la página web de un concierto se "caiga" en
las primeras horas de venta de entradas? Eso responde a la carga que puede
sostener un proyecto de software)

A medida que avanza el desarrollo, se realizan pruebas más detalladas sobre

características y funciones específicas. Las pruebas de integración se realizan
para asegurarse de que todas las piezas encajan correctamente, y las pruebas del
sistema verifican que todo el producto funciona según lo previsto.

Todo el conocimiento que se gane en la etapa de análisis de requerimientos,

permite que los QA, o los testers si es un equipo pequeño, puedan ya ir
trabajando sobre el diseño de las pruebas. No es necesario esperar a que los
desarrolladores entreguen porciones de software para comenzar a trabajar.
Y muchas veces las preguntas de los testers ayudan a construir un código
más eficiente y funcional ya que ponen foco en problemas que pueden
ocurrir más adelante y permiten que se solucionen desde el momento del
diseño.

Introducción al lenguaje unificado de modelado (UML)

Contexto

Uno de los mayores desafíos en el diseño y producción de software es poder

entenderse entre equipos de distintas disciplinas. El cliente pide requerimientos en
lenguaje cotidiano, los ingenieros lo pasan a lenguaje técnico y los testers deben
poder entender ambos lenguajes para poder controlar que lo que se pidió esté
realmente presente en el producto o proyecto que se va a entregar.
Una de las estrategias que se utilizan para diagramar los requerimientos es el uso
de esquemas realizados en UML o unified modelling language - lenguaje unificado
de modelado. Cuenta la leyenda que en el año 1997 un grupo de ingenieros
entusiastas, cansados de intentar leer dibujos en servilletas, decidieron poner fin al
castigo y armaron este sistema de símbolos y códigos que es independiente de los
lenguajes de programación. ¿Qué significa eso? Que no importa el nivel de
requerimientos o la dificultad del lenguaje a utilizar, las funcionalidades y casos de
uso se pueden representar utilizando UML.

Como UML es un lenguaje y no una metodología, se puede utilizar sin necesidad

de tener guías o ceremonias.

En el caso de las metodologías ágiles se llaman así porque son metodologías y requieren que
aprendamos ceremonias, pasos y procesos para llevarlas a cabo correctamente y que nos brinden
los mayores beneficios al ser implementadas.

Ciclo de vida de producción de Software

(SDLC o software development life cycle, en inglés, ¿recuerdan?)

Sabemos que puede sonar repetitivo, pero estamos haciendo algo que se llama
consolidación que es cuando recordamos algo que aprendimos y hacemos el
intento de ponerlo en práctica y no solamente repetirlo como cuando
estudiábamos de memoria... ¡si es que alguien sigue estudiando así!

Strategy: En el primer paso, ese en el que se toman los requerimientos del cliente
y se comienza a pensar la estrategia con la que se va a resolver el proyecto o el
producto, aparecen una serie de relaciones entre personas (usuarios, roles) y
datos (que ingresan, se almacenan o se entregan al usuario).

Manejo y transacción de datos:

Datos
Los datos son representaciones simbólicas de determinados atributos,
variables cuanti o cualitativas. Podemos considerar que son una descripción
codificada de un suceso o una entidad. En tecnología digital, estos valores son
recibidos por la computadora a través de distintos medios, y son manipulados a
través de distintos procesamientos.

¿Cómo puede ser que hablemos de datos todos los días y nunca hayamos dicho
que son una descripción codificada de un suceso?
¡A por un ejemplo se ha dicho! Cuando vemos la siguiente imagen:

¿Puedes decir qué estás viendo?

Eso que ha salido de tu cabeza es un dato. Frente a un evento (te

mostramos una imagen), regresa un dato (en este caso, el dato es un gato).

Metadatos
Apenas entendemos lo que es un dato, y tenemos que hablar de metadatos. Es
necesario para que no exista confusión entre uno y el otro.

Dato: foto

Metadata
filename: gatolindo
 type: .jpg
author: Nico’s phone
date: Oct 12 2017
time: 4:35 PM
location: <a href="https://www.findlatitudeandlongitude.com/?lat=50.2209618&lon=-
96.8747148">N 50° 13' 15.4626", W 96° 52' 28.9734"</a>

Los metadatos son la descripción de los datos. Podemos considerarlo como “datos
sobre datos”. Describen qué sabemos sobre el dato.

Se definen como los datos que proporcionan información sobre uno o más
aspectos de los datos; se utilizan para resumir información básica sobre datos
que pueden facilitar el seguimiento y el trabajo con datos específicos.

Una situación cotidiana puede ser: buscar en nuestro disco rígido todos los
archivos que sean .pdf (metadato: tipo de archivo) para luego ordenarlos por
tamaño (metadato: bytes que ocupan) y así eliminar aquellos que consuman
mucho espacio de almacenamiento.

Impacto comercial de los metadatos

Los metadatos dentro de las páginas web también pueden contener descripciones
del contenido de la página, así como palabras clave vinculadas al contenido que
hacen que al buscar algo online, los buscadores como Google o Ecosia puedan
entender mejor dónde encontrar lo que estás buscando.

Información
Los sistemas de información son la integración de componentes para la
recopilación, el almacenamiento y el procesamiento de datos para proporcionar
información, contribuir al conocimiento y productos digitales que facilitan la toma
de decisiones. Poseer información certera y a tiempo permite disminuir riesgos y
mejorar la toma de decisiones.

Características de la buena información

Lee estas características pensando en los ejemplos anteriores y el ejercicio que

has realizado. ¿Pudiste detectar evaluaciones subjetivas en la información
presentada?

 Subjetividad: El valor y la utilidad de la información son muy subjetivos,

porque al momento de relacionar los datos y sus metadatos, puede que
haya intereses detrás de cómo se presentan los mismos. Asimismo, lo que
es información para una persona puede no serlo para otra.
 Relevancia: La información es buena solo si es relevante, es decir,
pertinente y significativa para quien toma las decisiones.
  Oportunidad: La información debe ser entregada en el momento correcto y
en el lugar correcto a la persona correcta.
 Exactitud: La información debe estar libre de errores, porque la
información errónea puede resultar en malas decisiones y erosionar la
confianza de las personas o usuarios.

 Formato de información correcto: La información debe estar en el

formato correcto para que sea útil para el tomador de decisiones.
 Completa: Se dice que la información está completa si el tomador de
decisiones puede resolver satisfactoriamente el problema en cuestión
utilizando esa información.
 Accesibilidad: La información es inútil si no es de fácil acceso para los
tomadores de decisiones, en el formato deseado, cuando se necesita.

En el mundo de la tecnología, muchas veces como usuarios accedemos a

información que está destinada a cambiar conductas (aplicaciones para entrenar,
para registrar hábitos) o para consumir (comercio electrónico, compras y ventas),
entre otras opciones. Es fundamental que cualquier información presentada a los
usuarios cumpla con las características de la buena información ya que ayudará a
generar confianza en el producto tecnológico y a lograr cumplir con el objetivo
deseado en el usuario.

¿Por qué es importante este tema para un tester?

Un tester es una pieza fundamental en el proceso de construcción de software de

buena calidad. Para ello debe traer información sobre algo que no funciona como
se espera y debe poder sostener su información en base a qué datos tomó para
hacer esa afirmación.

Muchas veces una sola persona haciendo pruebas debe detener el trabajo de
otros equipos para poder volver a analizar una porción de código que no está
dando los resultados esperados.

Los sistemas de información recolectan datos para convertirlos en información a través

de transacciones

Transacciones

En la programación informática, una transacción generalmente significa una

secuencia de intercambio de información y trabajo o procesamiento relacionado
(como la actualización de la base de datos) que se trata como una unidad y tiene
el fin de satisfacer una solicitud y garantizar la integridad de la base de datos.
Para que una transacción se complete y los cambios en la base de datos sean
permanentes, la transacción debe completarse en su totalidad.

Una transacción típica es un pedido de mercadería por catálogo. Un cliente llama

por teléfono al centro de ventas y un representante del cliente recibe su llamado,
detecta su necesidad y la ingresa en una computadora. La transacción del pedido
implica verificar una base de datos de inventario, confirmar que el artículo está
disponible, realizar el pedido y confirmar que se ha realizado el pedido y la hora
prevista de envío. Si vemos esto como una sola transacción, entonces todos los
pasos deben completarse antes de que la transacción sea exitosa y la base de
datos realmente cambie para reflejar el nuevo estado de inventario y estar lista
para un nuevo pedido. Si algo sucede antes de que la transacción se complete
con éxito, se debe realizar un seguimiento de cualquier cambio en la base de
datos para que se pueda deshacer.

¿Qué es el Testing?
El testing o prueba de software es un método para verificar si el producto de
software real cumple con los requisitos esperados y busca garantizar que el
producto de software esté libre de defectos.

Implica la ejecución de componentes de software o sistemas utilizando

herramientas manuales o automatizadas y se evalúan una o más propiedades de
interés. El propósito de las pruebas de software es identificar errores, brechas o
requisitos faltantes en contraste con los requisitos reales.

La prueba de software es el proceso de evaluar y verificar que un producto o

aplicación de software hace lo que se supone que debe hacer. Los beneficios de
las pruebas incluyen la prevención de errores, la reducción de los costos de
desarrollo y la mejora del rendimiento.

¿Cuáles son los objetivos del testing?

1. Para evitar defectos en el producto de software:

Uno de los objetivos de las pruebas de software es evitar los errores en las
primeras etapas del desarrollo. La detección temprana de errores reduce
significativamente el costo y el esfuerzo. La prevención de defectos implica hacer
un análisis de causa raíz de los defectos encontrados previamente y luego tomar
medidas específicas para prevenir la ocurrencia de ese tipo de errores en el futuro.
Las pruebas eficientes ayudan a proporcionar una aplicación sin errores. Si
previene los defectos, se reducirá el recuento general de defectos en el producto,
lo que garantiza aún más un producto de alta calidad para el cliente.

2. Evaluar productos de trabajo:

Los requisitos iniciales, el diseño, las historias de usuario y el código deben
verificarse antes de que el desarrollador los recoja para el desarrollo. Identificar
cualquier ambigüedad o requisitos contradictorios en esta etapa ahorra un tiempo
considerable de desarrollo y prueba. El análisis estático del código (revisiones,
recorridos, inspección, etc.) ocurre antes de que el código se integre o esté listo
para la prueba. Esta prueba se conoce como Verificación y puede ser realizada
por el mismo equipo de desarrollo o por el equipo de QA (quality assurance).

3. Verificar requerimientos:

El principal objetivo de las pruebas debe ser satisfacer las necesidades del cliente.
Los testers prueban el producto y aseguran la implementación de todos los
requisitos especificados. El desarrollo de todos los casos de prueba,
independientemente de la técnica de prueba, garantiza la verificación de la
funcionalidad de cada caso de prueba ejecutado. El tester también debe crear una
matriz de trazabilidad de requisitos (RTM), que garantizará el mapeo de todos los
casos de prueba a los requisitos. RTM es una forma efectiva de garantizar que los
casos de prueba tengan la cobertura de requisitos adecuada.

4. Validar el objeto de prueba:

Para validar si el objeto de prueba está completo y funciona según las

expectativas de los usuarios y las partes interesadas (stakeholders). Las pruebas
aseguran la correcta implementación de los requisitos junto con la seguridad de
que funcionan según las expectativas de los usuarios. Esta idea de prueba se
llama Validación.

5. Construir confianza:

Uno de los objetivos críticos de las pruebas de software es mejorar la calidad del
software que se entregará para construir confianza con quien lo solicitó. El
software de alta calidad significa un menor número de defectos. En otras palabras,
cuanto más eficiente sea el proceso de prueba, menos errores tendrá en el
producto final. Lo que, a su vez, aumentará la calidad general del objeto de
prueba. La excelente calidad contribuye a un aumento significativo en la
satisfacción del cliente, así como a menores costos de mantenimiento.

6. Reducir riesgos:

La posibilidad de pérdida también se conoce como riesgo. El objetivo de las

pruebas de software es reducir el riesgo. Cada proyecto de software es único y
contiene un número significativo de incertidumbres desde diferentes perspectivas,
como ser el tiempo de lanzamiento al mercado, el presupuesto, la tecnología
elegida, la implementación o el mantenimiento del producto. Si no controlamos
estas incertidumbres, podremos tener riesgos potenciales no solo durante las
fases de desarrollo sino también durante todo el ciclo de vida del producto. Por lo
tanto, el objetivo principal de las pruebas de software es integrar el proceso de
gestión de riesgos para identificar cualquier riesgo lo antes posible en el proceso
de desarrollo.

7. Mantener informadas a las partes interesadas (stakeholders):

El propósito de las pruebas es proporcionar información completa a las partes

interesadas sobre restricciones técnicas o de otro tipo, factores de riesgo,
requisitos ambiguos, etc. Puede ser en forma de cobertura de pruebas, informes
de pruebas que cubran detalles como lo que falta, lo que salió mal. El objetivo es
ser transparente y hacer que las partes interesadas entiendan completamente los
problemas que afectan la calidad. Un ejemplo concreto puede ser avisar al cliente
que uno de los requerimientos tiene mucho riesgo y eso aumenta la probabilidad
de errores y costos asociados. Al mantener informado al cliente, éste puede tomar
decisiones con menor costo que si se le avisa al final, cuando no hay nada para
hacer.

8. Para encontrar defectos en el producto de software:

Otro objetivo esencial de las pruebas de software es identificar todos los defectos
en un producto. El lema principal de las pruebas es encontrar el máximo de
defectos en un producto de software mientras se valida si el programa funciona
según los requisitos del usuario o no. Los defectos deben identificarse lo antes
posible en el ciclo de prueba.

Mientras que un defecto se pueda encontrar en la fase de pruebas, se lo conoce

como error y tiende a ser solucionable antes de llevar el producto al cliente.

Otros objetivos posibles:

A veces debemos cumplir con los requisitos o estándares contractuales, legales o

reglamentarios, y se debe verificar el cumplimiento del objeto de prueba con
dichos requisitos o estándares. Por ejemplo, en relaciones contractuales con
gobiernos o sistemas de seguridad o defensa, hay estándares de seguridad
distintos que para una aplicación de compra y venta de ropa usada.

Otros casos incluyen que el software sea desarrollado para una región específica
y deba seguir las reglas y regulaciones legales de esa región. Además, el producto
de software puede tener que ser compatible con los estándares de prueba
nacionales e internacionales.

Beneficios del testing

Estos son los beneficios de usar pruebas de software:

1. Rentabilidad: es una de las ventajas más importantes de las pruebas de

software. Probar cualquier proyecto de TI a tiempo lo ayuda a ahorrar
dinero a largo plazo. En caso de que los errores se detecten en la etapa
anterior de las pruebas de software, cuesta menos repararlos.
 2. Seguridad: Es el beneficio más vulnerable y sensible de las pruebas de
software. La gente está buscando productos de confianza. Ayuda a eliminar
riesgos y problemas antes.
3. Calidad del producto: Es un requisito esencial de cualquier producto de
software. Las pruebas aseguran que se entregue un producto de calidad a
los clientes.

4. Satisfacción del Cliente: El objetivo principal de cualquier producto es dar

satisfacción a sus clientes. Las pruebas de UI/UX garantizan la mejor
experiencia de usuario.

Errores de software y bugs

Un error es una desviación de lo que se esperaba como exacto o correcto. En
software, un bug es un error, defecto o falla en un programa o sistema que causa
“un resultado inesperado o incorrecto o un comportamiento no deseado.“
Podemos inferir lo siguiente:

 Un error es una variante inesperada del resultado esperado

 Los errores son una categoría de bugs de software
 Los errores pueden surgir de:
o requerimientos incompletos o incorrectos
o falla humana en el momento de la codificación (programación)

Categorías comunes de errores de software:

1. Errores funcionales

La funcionalidad es la forma en la que se debe comportar el software. Los errores

funcionales son, por ejemplo, si algo que se espera que realice es difícil, resulta
confuso y extraño o es directamente imposible.

Mira esta pantalla de ejemplo:

Imagen 4.3: Pantalla “Eliminar publicación”. Fuente: producción propia.

La funcionalidad esperada del botón Cancelar es que el modal de Eliminar
publicación se cierre y que se regrese a la página original de la publicación, sin
eliminarla. Si el botón de cancelar no es clicable, estamos frente a un error de
funcionalidad.

1. Errores de comunicación o interpretación

El software presenta al usuario opciones o CTA (call to action) que son poco
claros o que no realizan la acción que dicen realizar. Por ejemplo, no hay Menú de
ayuda o Instrucciones para usuarios nuevos. O acciones que son centrales al
software pero no figuran en la sección de Preguntas Frecuentes. Hasta puede ser
que un botón lea “Guardar” y esté ejecutando “Eliminar.”

Imagen 4.4: Pantalla con copy erróneo en botón Guardar. Fuente: producción propia.
En este ejemplo - Imagen 4.4-, el equipo responsable de la creación visual de este
aviso (Front End) transcribió incorrectamente el texto en el botón “Eliminar” y el
usuario lee “Guardar” y el software ejecuta eliminar.

2. Errores de comandos faltantes

Este tipo de errores ocurre cuando un comando esperado está ausente. Observa

el siguiente ejemplo:

Imagen 4.5: Pantalla “Completa tu perfil”. Fuente: producción propia.

Esta pantalla permite que el usuario complete su perfil. Pero, no hay opción para
que el usuario se vaya de esta pantalla sin completar su perfil. Ya que el botón
“Cancelar” no se le provee al usuario, este es un error de comando faltante.

3. Errores de sintaxis e idioma

Los errores de sintaxis corresponden a palabras mal escritas (ortografía o error de

tipeado simple) u oraciones que son incorrectas desde lo gramatical. En el caso de
software en español, también encontramos en esta categoría errores de herencia
de inglés. Verás muchas veces que algunos textos todavía conservan el idioma en
el que fueron escritos originalmente. Observa las siguientes imágenes a ver si
puedes identificar todos los errores que puedas. Recuerda, ¡atención al detalle es
una habilidad que debes desarrollar como si fueras investigador profesional!
Dato: estos errores generalmente se ven al testear un software que ya tiene su

GUI o UI lista.

Imagen 4.6: Pantalla “Comprar tickets”. Fuente: producción propia.

Imagen 4.7: Pantalla “Agrega el nombre

de una empresa”. Fuente: producción
propia.
 1. Errores en el manejo de errores

Cualquier error que ocurra mientras el usuario está interactuando con el software
necesita ser manejado en forma clara y con sentido. En otras palabras, el usuario
debe comprender qué pasó (en un lenguaje ameno) y debe tener claro qué hacer
como siguiente paso. Si esto no ocurre, a estos errores se los denomina “Error en
el manejo de errores.”
Imagen 4.8: Pantalla “Error 707”. Fuente: producción propia.

Siempre que sea posible, el usuario debe tener claro qué pasos debe seguir.
Si en un formulario, por ejemplo, hay campos obligatorios que necesitan ser
llenados, los mensajes de validación deben ser claros e indicar qué acciones debe
realizar el usuario. Aquí tienes un ejemplo bien manejado:

Imagen 4.9: Pantalla “Completa tus datos”. Fuente: producción propia.

Otros ejemplos de mal manejo de errores pueden lucir como las pantallas a

continuación:

Imagen 4.10: Pantalla “Unexpected error”. Fuente: producción propia.

Imagen 4.11: Pantalla “Aviso. No ocurrió un error”. Fuente: producción propia.

2. Errores de cálculo

Este tipo de errores ocurre cuando una porción del código del software tiene algún
error. Algunos ejemplos son:

 Errores de lógica
 Fórmulas incorrectas
 Tipos de datos no alineados (texto vs números, por ejemplo)
  Errores de código
 Errores en las funciones internas del código
 Bases de datos inexistentes o mal asignadas

En 1999, la NASA perdió su orbitador climático en Marte debido a que uno de los
proveedores de la NASA involucrado en su construcción utilizó medidas imperiales
(usadas en Inglaterra) en lugar de utilizar el sistema métrico universal (utilizado en
todo proyecto científico). Este pequeño error causó que los propulsores del
orbitador no funcionen correctamente. Debido a este error, el orbitador se estrelló
casi inmediatamente al llegar a Marte.

3. Errores de control de flujo

El control de flujo en un software describe qué hará este en su próximo paso y

bajo qué condiciones.
Por ejemplo, consideremos un sistema en el que el usuario debe completar un
formulario y las opciones disponibles son: Guardar, Guardar y cerrar y
Cancelar.
Si el usuario hace clic en el botón de Guardar y cerrar, la información del usuario
en ese formulario debiera ser guardada y el formulario cerrarse. Si al hacer clic en
ese botón, no se cierra el formulario, es un error de control de

flujo.
 Imagen 4.12: Pantalla “Formulario de inscripción”. Fuente: producción propia.

Error, defecto y falla

Error Acción humana que produce un resultado incorrecto

Defecto Desperfecto en un componente que puede causar que el mismo falle en

sus funciones

Fallo Manifestación visible de un defecto

En el terreno profesional de un tester, normalmente siempre se topará con errores

ya que son exactamente lo que está buscando al analizar un producto o un
proyecto de software. Los defectos y las fallas se descubren una vez que el
producto ya está funcionando del lado del cliente y es éste quien las informa.

La identificación de defectos - poder categorizarlos, reportarlos y que

eventualmente se solucionen - es parte de las actividades del equipo de Control y
Garantía de calidad. El mayor desafío que tiene este equipo es poder realizar las
pruebas necesarias en cada momento de las etapas del Ciclo de vida del
Desarrollo de Software (SDLC). El objetivo es poder detectar los errores lo antes
posible. ¿Por qué? Porque a medida que se avanza en el proceso, los costos para
encontrar y corregir errores crecen en forma exponencial.

El momento más económico para arreglar un error es durante el periodo de

análisis de requerimientos, y luego el costo se va incrementando sin excepción
en cada etapa subsiguiente, llegando al escenario más costoso de todos que
es en el periodo de mantenimiento luego de la implementación.

Aquí te dejamos un esquema para que recuerdes la secuencia de producción de

un error:
Un tester detecta defectos y explica cómo fallan, acompañando el reporte con un
análisis de los efectos negativos. El tester no siempre puede saber cuál es el
error que dio lugar a ese defecto.

Evaluación de criticidad y prioridad

Si el ciclo de producción de software está funcionando correctamente el equipo de
testing (QA) podrá identificar o alertar de errores a tiempo antes de que salgan a la
luz, frente a los clientes o usuarios finales. Como bien sabemos esto sería una
descripción del escenario ideal. Lo habitual es que haya muchas líneas de código
y muchas personas colaborando al mismo tiempo (grandes empresas con
procesos de trabajo muy establecidos) o pocas personas haciendo muchas tareas
superpuestas (contexto de empresas pequeñas o en estadío de startup). Es en
esa superposición de muchas personas o muchas tareas que a veces vemos
cómo los errores salen a la luz (bugs o defectos). O los descubrimos con muy
poco tiempo antes de que sea necesario entregar el producto y ya no hay margen
para cambios.

Verificación y validación
El proceso de verificar y validar es el proceso por el cual se investiga si un sistema
de software satisface las especificaciones, requerimientos y estándares indicados
y si cumple el propósito deseado.

 Verificación: ¿Estamos construyendo el producto correctamente?

 Validación: ¿Estamos construyendo el producto correcto?

Estos dos términos son utilizados indistintamente por muchas personas. Dado que
los especialistas en testing se encargan fundamentalmente de la verificación,
debemos hacer foco en comprender el término y distinguirlo de la validación.

Verificación

Es el proceso por el que se determina si el software que está siendo analizado se

está diseñando y desarrollando de acuerdo a requerimientos especificados. Los
requerimientos o especificaciones actúan como guía en todo el proceso de
desarrollo de software. El código que se escribe para un software está basado en
esa documentación inicial.

Seth Godin define a la calidad como “estar a la altura de los requerimientos.”

La potente definición de Godin simplifica al máximo nuestra tarea al iniciar un

proyecto:
  Asegúrate de haber comprendido lo que se debe hacer
 Haz las preguntas en este momento o luego ya deberás cumplir con lo
establecido en ese documento inicial

La verificación se realiza para corroborar que el software que está siendo

desarrollado adhiera a estas especificaciones en todos los momentos de su ciclo
de desarrollo. La verificación asegura que la lógica del código esté alineada con
estas especificaciones y que no contenga errores.
Dado que el proceso de verificación suele ser complejo debido al tamaño del
proyecto o la complejidad del mismo, se utilizan varios métodos de verificación.
Algunos de ellos son: inspección del código, revisiones de código, revisiones
técnicas, entre otros. Los equipos de testing (QA) también pueden usar modelos
matemáticos y cálculos para predecir el comportamiento del código y verificar su
lógica (etapa de análisis de requerimientos).

la verificación se realiza en forma interna, dentro de los equipos que van a estar trabajando
con el desarrollo de la aplicación. Es importante hacer este proceso antes de iniciar el
trabajo ya que asegura que no se trabaje en direcciones equivocadas, gastando recursos
escasos. Una vez más, el equipo de testing está para asegurarse de que se trabaje en forma
eficiente, anticipando los problemas y ahorrando tiempo y dinero.
La realidad: muchas organizaciones y startups tardan mucho en implementar procesos de
verificación. Y suelen hacerlo cuando ya han constatado más de una vez que se gasta
mucho más en “lo hacemos rápido, sin un plan” que “lo hacemos bien, verificando paso por
paso y luego lo construimos.”
Conclusiones:
La verificación es un proceso continuo, interno que se debe realizar en todas las etapas del
desarrollo de software. La verificación es el testing estático.
Sus principales ventajas son:

1. Actúa como control de calidad en cada etapa del proceso de desarrollo de software.
2. Permite que el equipo de desarrollo produzca productos que se ajustan a los
requerimientos y a las necesidades del cliente.
3. Ahorra tiempo ya que se detectan los defectos en las etapas tempranas del desarrollo
de software.
4. Reduce o elimina los defectos que pueden surgir en las etapas más tardías del
desarrollo de software.

Validación

La validación es el proceso de chequear que se esté desarrollando el producto

correcto. A diferencia de la verificación que va desde los requerimientos hacia el
código, la validación se hace en dirección opuesta. Va escalando por las distintas
capas de desarrollo y va chequeando que el software desarrollado sea el producto
correcto. Es por ello que este proceso lo lleva adelante, en su mayor parte, el
equipo de desarrollo, y se realiza cuando el producto ya está listo para ser
entregado. La validación es el testing dinámico.
Para que ya vayas teniendo un idea, en el proceso de validación, estas son las
actividades más relevantes:

1. Testeo de caja negra (Black box testing - BBT) - Testeo de sistema

completo. Responsables: equipo de QA/testing
2. Testeo de caja blanca (White box testing - WBT). Responsables:
desarrolladores
3. Testeo unitario (Unit testing - UT). Responsables: desarrolladores
4. Testeo de integración o integraciones (Integration testing). Responsables:
desarrolladores

El extraño caso del UAT (User Acceptance Test). El UAT es el último test
del proceso de verificación (y está a cargo de usuarios reales, beta testers o
usuarios designados por el cliente), o puede ser considerado como parte de la
Validación ya que es parte del proceso de validación del producto. Hoy en día
la línea que divide Verificación de Validación es muy difusa ya que los
procesos se han vuelto más dinámicos, respondiendo a cambios mucho más
ágiles propios del desarrollo de software ágil.

Si en el campo profesional estos dos procesos se superponen, ¿por qué es

importante que aprendamos estos conceptos?
Volviendo al punto de partida inicial: la verificación sirve para saber si estamos
construyendo el producto correctamente (de acuerdo a lo pedido) y la
validación nos sirve para saber si hemos construido el producto correcto (el que
necesita el mercado o el cliente y que va a generar valor).

Verificación Validación

Incluye chequear documentos,

Incluye el testeo y validación del producto real.
diseños, código y programas.

En su mayoría, son pruebas En su mayoría, son pruebas dinámicas (dynamic

estáticas (static testing). testing).

No incluye la ejecución del

Incluye la ejecución del código.
código.

Los métodos utilizados son BBT (black box

Los métodos utilizados son
testing), WBT (White box testing) y testeos no
reviews, repasos, inspecciones
funcionales. También incluye: performance
de código, demostración y
testing, regression testing, security testing y
análisis.
testing de sistema.
 Revisa que el software cumpla
Chequea que el software cumpla con los
con los requerimientos.
requerimientos y las expectativas del cliente.
Documenta lo que no cumple o
Documenta el feedback del cliente.
lo que falta cumplir.

Permite encontrar defectos en Permite encontrar defectos que no se pudieron

etapas tempranas del desarrollo. encontrar durante la verificación.

El objetivo de la verificación es la
aplicación y la arquitectura y El objetivo de la validación es el producto en sí.
requerimientos de software.

El equipo de QA realiza la El equipo de desarrollo ejecuta la validación con

verificación. ayuda del equipo de Testing.

Ocurre antes de la validación. Ocurre luego de la verificación.

En su mayoría, consiste en el
En general, consiste en la ejecución de un
análisis de documentación y la
programa y la realiza una computadora.
realizan personas.

Introducción a la documentación de defectos (bugs)

Ya estamos afilando nuestras herramientas de detección de defectos. Ya sabemos
cómo clasificarlos y hasta nos aventuramos a entender un poco del mundo de la
UX. ¿Cómo podemos iniciarnos en la documentación clara y efectiva de un
defecto?

Si bien vamos a estar explorando varias técnicas y matrices de documentación, es

importante saber que hay una estructura básica que incluye todos los datos
necesarios para que un equipo de desarrolladores sepa a qué error nos referimos,
en qué contexto del software está y qué esperamos de la solución. Reportar
defectos en forma clara también ayuda a que puedan resolverse rápidamente.

Reporte #125

Defecto: La palabra “Settings” está mal escrita en el menú de Configuración en la

versión en inglés.

Descripción del defecto (¿Cuál es el bug?): Falta la letra “g” en la palabra “Settings”
 Comportamiento esperado (¿Cómo debería verse?): Cambiar la palabra “Settins” por
“Settings”

Enlaces relacionados: Ver imágenes a continuación

Más información: Si es necesario aclarar el contexto para replicar el error

Cuándo se encontró el defecto: 19.11.2022

Prioridad:
 Muy alta
 Alta
 Media
 Baja

Dónde se reportó el defecto: incluir link al ticket

Cómo se encontró el defecto: Durante una prueba de QA

Responsable de encontrar el defecto: Mariela García

Reporte #125: Imágenes de apoyo. A la izquierda vemos la imagen como se ve hoy y a la

derecha cómo debería verse una vez solucionado el error.

5. Colección cooperativa de defectos in the wild

Estuvimos viendo muchos ejemplos. Casi todos recuperados de la vida real, de
anécdotas de testers y de nuestras experiencias personales. Es hora de que te
sumes y comiences tu propia colección de errores que han atravesado barreras de
supervisión y testeo para llegar directamente al usuario final.

Las pruebas son necesarias para reducir el riesgo de detectar errores pero
muchas veces no logran anticipar todos los casos posibles de uso.

Cuanto mejores y más adecuadas sean las pruebas de software, menor será el
riesgo de encontrar errores durante la fase de operación o producción, y ya
sabemos que no todos los errores son iguales. No es lo mismo un error crítico y
urgente que un error trivial que puede esperar. El problema con los errores en
producción es que están a la vista de todos.

La ejecución anticipada de las pruebas reduce el riesgo de que los errores

provoquen fallas críticas en el sistema.

¿Qué puede causar un error y/o un defecto en un programa de

software?

Ya hemos visto errores y defectos. Veamos cuáles son las causas posibles de
los errores y defectos en software

1. Error Humano
Las personas a cargo de un proyecto pueden equivocar alguno de los
puntos a resolver. Desde una fecha de entrega incorrecta (“Era para hoy?”),
hasta enviar a producción una porción de código que no estaba testeada
todavía. Los memes abundan, dando cuenta de cuántas veces se pierden
los detalles en la comunicación incompleta de requerimientos o en la
falta de procesos de verificación.

2. Condiciones Ambientales
Existen causas ambientales que tienen impacto directo sobre la tecnología.
Algunos ejemplos son la radiación, el magnetismo, campos electromagnéticos,
polución, tormentas solares, rayos cósmicos. Y luego algunas fallas en el
hardware (los componentes duros de la tecnología) causadas por elementos
externos. Algunos ejemplos son: fallos de discos duros debido a fluctuaciones
en el suministro de energía eléctrica, temblores, terremotos, inundaciones, y
otros elementos de la naturaleza que puedan afectar directamente a la
estructura más visible de una computadora.

3 Defectos de fabricación (Defects)

Estos son desperfectos en un componente que pueden causar que el sistema falle
en desempeñar las funciones requeridas, por ejemplo, una sentencia o una
definición de datos incorrectos. Failure (Fallo) es una desviación funcional de un
componente o sistema respecto de la prestación, servicio o resultado esperados.

4 Errores en el código
Errores al escribir código por parte de un programador que no hayan sido
detectados en la fase de pruebas. No son errores de malos entendidos (como en
el caso de los errores humanos) sino que son errores de la lógica interna que
hacen que el código no pueda ser ejecutado. Por ejemplo, ingresar una edad
“negativa” (-18) puede generar que una aplicación no funcione o que un usuario
pueda pedir 1 millón de hamburguesas mediante una app de pedidos a domicilio.

Así como has visto el ciclo de vida de producción de software, estaremos

viendo las etapas del Ciclo de Vida del Testing (STLC).

Procesos de prueba
Como has estado aprendiendo, no existe un único proceso para realizar pruebas.
Sin embargo, podemos tener en cuenta una serie de actividades que son comunes
a todos estos procesos. Estas actividades ayudan a que el Testing alcance los
objetivos establecidos.

Debemos tener en cuenta que un proceso de pruebas se ve afectado por una gran
cantidad de factores internos y externos que deberemos tener en cuenta a la hora
de planificar. Nombraremos algunos a continuación, pero deberás tener presente
que ninguna lista es exhaustiva y que dependerá de cada proceso o entorno en
que se aplique.

Factores que pueden afectar el ciclo de pruebas:

 Modelo de Ciclo de vida del desarrollo del Software y metodologías del

proyecto en uso.
 Niveles y tipos de pruebas considerados.
 Riesgos del producto y del proyecto.
 Restricciones operativas del entorno (económicos, financieros,
contractuales, temporales, etc).
 Políticas o estándares requeridos.

Teniendo esto en cuenta, sabremos que cada proceso de prueba será único y
diferente del resto, pero dentro de estas actividades comunes, podemos identificar
una serie de etapas a transitar en orden.

Pasos comunes a los procesos de prueba

1. Análisis de requerimientos
2. Planificación
3. Diseño y análisis
4. Implementación – Configuración del entorno
 5. Ejecución
6. Actividades de cierre
7. Control y monitoreo

Iremos desarrollando estos pasos a lo largo de las siguientes guías.

1. Análisis de requerimientos
Hasta el encuentro de hoy, estuvimos viendo los requerimientos como una
categoría amplia en la que incluimos “todo lo que puede pedirse al momento de
iniciar un proyecto de software.”

Ahora estamos en condiciones de ser más precisos y definir al requisito de

software como una descripción detallada del sistema en implementación. Los
requerimientos describen el uso práctico del producto o servicio, la condición
o la capacidad a la que debe ajustarse un sistema. Los requisitos pueden variar
desde declaraciones abstractas de alto nivel de servicios o restricciones del
sistema hasta especificaciones funcionales matemáticas detalladas.

¿Qué es el análisis de requisitos? Es el proceso por el que se determinan las

expectativas del usuario para un sistema en consideración. El resultado de este
análisis debe ser cuantificable y detallado.

 Sirve como base para los planes de prueba y el plan del proyecto.
 Sirve como un acuerdo entre el desarrollador y el cliente.
 Es un proceso que permite aclarar los requisitos declarados y no
declarados
 Sirve para validar el requisito de integridad, falta de ambigüedad y
viabilidad.
Imagen 7.1: El impacto de un error en el análisis de requerimientos. Fuente:
Foundations of software testing de Dorothy Graham, Rex Black, Erik Van
Veenendaal e Isabel Evans.

En la imagen 7.2 se muestra la consecuencia de un análisis deficiente de

los requisitos y su impacto en el ciclo de vida del desarrollo del software.
Imagen 7.2: Consecuencias en el costo de un análisis deficiente. Fuente: elaboración
propia.

El cuadro muestra la relación entre la fase del desarrollo y el costo de la

corrección de errores. Si el análisis de requisitos no se realiza en la fase inicial del
SDLC, entonces su impacto es enorme para solucionarlo en fases posteriores.
Cuando el análisis de requisitos no se produce de forma satisfactoria, pueden
aparecer algunas consecuencias como ser: la entrega incorrecta de funciones,
mala calidad del producto, una gran cantidad de cambios para corregir fallas del
sistema, extensión de los plazos iniciales del proyecto, entre otros. Cuanto más se
extiende el tiempo en analizar el requisito, más cuesta hacerlo luego y eso afecta
la entrega y la calidad del proyecto.

Desafíos en la fase de análisis de requisitos en el control de calidad

A continuación presentamos algunos de los desafíos más habituales en el

momento de poder analizar los requerimientos. En la teoría parece simple lograr
este nivel de comunicación entre los equipos, pero esta etapa del proceso suele
ser la que más desafíos trae.

 En la etapa inicial de SDLC, el alcance no está claramente definido.

 Muchas veces hay una comprensión ambigua de los procesos.
 La comunicación entre el equipo del proyecto y las partes interesadas juega
un papel importante.

Las entradas insuficientes del cliente conducen a suposiciones y no se

aceptan en UAT.

 Inconsistencia dentro de un solo proceso en múltiples usuarios

  Puntos de vista conflictivos de los clientes.
 Nuevos requisitos frecuentes.

En los casos vistos hasta el encuentro de hoy, los requerimientos siempre se

presentaron como una lista muy ordenada de elementos a desarrollar. La vida
profesional está más cerca de esta lista de desafíos y pasa el tiempo entre que el
cliente presenta su lista de requerimientos y se llega a una lista más definida con
la que se puede trabajar sin cambios.

Herramientas y técnicas utilizadas para el análisis de los requisitos

Para mitigar el efecto de un mal análisis de requerimientos, existen herramientas y

técnicas que podemos aplicar en este momento. Te presentamos dos:

1. Casos de Uso: Es una metodología utilizada en el análisis de requisitos

para identificar, aclarar y organizar los requisitos. Es un conjunto de
posibles secuencias de interacciones entre sistemas y usuarios en un
entorno particular y relacionado con un objetivo particular.
2. Documento de comprensión de los requisitos (RUD): el documento
cubre los detalles de la comprensión de los requisitos relacionados con los
puntos siguientes:
 Suposiciones
 Detalles del sistema
 Requisitos del sistema lógico
 Entidad del sistema
 Hardware
 Criterios de aceptación
 Priorizar cada requisito
 Discutir con el equipo e identificar el alcance de la prueba
 Desglose los requisitos en tareas e historias de usuario.

¿Cómo analizar los requisitos?

 Averigua qué software tienes que hacer.

 Identifica los requisitos preguntando por qué, qué, quién, cómo, etc.
 Descubre cuán compleja sería la aplicación y su impacto en las pruebas.
 Ten en cuenta que todas las cosas tendrían que ser probadas.

Validación de requisitos

Valida los requisitos en función de los puntos a continuación para que al final de la
fase de análisis de requisitos esté disponible toda la información requerida.

 Corrección: averiguar declaración/requisito incorrecto.

 Completitud: tienes el desafío de encontrar el requisito faltante.
 Factibilidad: encuentra todas las características que son posibles de probar
y cuáles están más allá del alcance.
 Testeabilidad: verifica la posibilidad de crear diferentes pruebas aplicables.
  No Ambigüedad: encuentra una interpretación única de los requisitos.
 Consistencia: descubre la consistencia del requisito y apunte a un solo
requisito.

Función de control de calidad

Un miembro de un equipo QA debe estar involucrado en la actividad de análisis de

requisitos para garantizar que los requisitos identificados por el cliente o el BA y
aceptados por el cliente sean medibles. Además, esta actividad proporciona
claridad en varias etapas de SDLC ya que permite identificar la disponibilidad de
recursos, permite anticipar los tiempos y preparación de pruebas.

A continuación, las actividades que debe realizar el control de calidad:

1. Analiza todos y cada uno de los requisitos del documento de especificación.

Cuando puedas y tengas suficiente información, redacta los casos de uso.
2. Enumera escenarios de alto nivel.
3. Aclara tus consultas y la funcionalidad con las partes interesadas.
4. Promueve sugerencias para implementar las funciones o cualquier
problema lógico.
5. Identifica defectos o necesidades de aclaración contra el pliego de
condiciones presentado por el cliente.
6. Realiza el seguimiento del defecto (si los hubiera detectado) con respecto al
documento de especificaciones.
7. Crea escenarios de prueba de alto nivel.
8. Crea una Matriz de Trazabilidad.

Para que un equipo de QA pueda iniciar este proceso de análisis de

requerimientos debe contar con un documento, habitualmente llamado SRS
(Software Requirement Specification).

En esta fase, el equipo de control de calidad (QA) analiza a un nivel superior qué
probar y cómo probar. Dicho de otro modo, diseñan qué pruebas se deben
realizar, en qué momento y con qué herramientas.

El equipo de control de calidad luego realiza un seguimiento con varias partes

interesadas, como Business Analyst, System Architecture, Client, Test
Manager/Lead, en caso de que se requiera alguna consulta o aclaración para
comprender el requisito. Los requisitos pueden ser funcionales o no funcionales,
como rendimiento, seguridad, facilidad de uso, etc., o pueden ser ambas cosas al
mismo tiempo.

¿Para qué se realiza este seguimiento? El equipo de QA está buscando completar

una RTM o Matriz de trazabilidad. Además buscará realizar el informe de
factibilidad de automatización y una lista de preguntas, si corresponde, para ser
más específicos sobre los requisitos.
Actividades realizadas para el análisis de requisitos

Hay tres actividades principales que realiza el equipo de control de calidad en esta
fase. Las actividades se describen a continuación.

DEFINICIÓN DEL ALCANCE

El equipo de control de calidad identifica el alcance de las pruebas en niveles altos

y se divide en varios módulos funcionales. El equipo también identifica los tipos de
pruebas necesarias para realizar: pruebas de humo, pruebas de cordura, pruebas
funcionales, pruebas de regresión, etc.

El equipo de control de calidad analiza los requisitos previos y los detalles del
entorno donde se supone que se realizarán las pruebas. El equipo recopila
detalles sobre las prioridades de las pruebas y se enfoca en la secuencia de
módulos que se validarán.

RTM (MATRIZ DE TRAZABILIDAD)

El seguimiento de requisitos es un proceso de documentación de los vínculos

entre los requisitos y los productos de trabajo desarrollados para implementar y
verificar esos requisitos. El RTM captura todos los requisitos en el Análisis de
Requisitos junto con su trazabilidad en un solo documento. Todo esto se entrega
al final del ciclo de vida.

La Matriz se crea al comienzo de un proyecto, ya que forma la base del alcance

del proyecto y los entregables que se producirán. Es bidireccional, ya que realiza
un seguimiento del requisito hacia adelante al examinar la salida de los
entregables y hacia atrás al observar el requisito comercial que se especificó para
una característica particular del producto.

¿QUÉ ES LA MATRIZ DE TRAZABILIDAD DE REQUERIMIENTOS (RTM)?

La Matriz de trazabilidad de requerimientos es un documento que mapea y rastrea

los requerimientos del usuario con casos de prueba. Captura todos los
requerimientos propuestos por el cliente y la trazabilidad de los requerimientos en
un solo documento, entregado al finalizar el ciclo de vida del desarrollo del
Software, ya que es un entregable.

El objetivo principal de la Matriz de trazabilidad de requerimientos es validar que

todos los requerimientos se verifiquen a través de casos de prueba, de modo que
no se desmarque ninguna funcionalidad durante las pruebas de software.

Surge aquí una pregunta, teniendo en cuenta todos los escenarios / casos
posibles. ¿Cómo asegurarse de que ningún requisito se quede fuera del ciclo de
prueba? Usaremos las siguientes herramientas.
Un escenario de prueba es la representación de uno o más flujos de negocio o
flujos críticos que se ejecutarán de forma concurrente sobre la infraestructura
objetivo por uno o más usuarios virtuales.

Un caso de prueba es un documento/plantilla cargada en un sistema de

gestión de pruebas, que consiste en un conjunto de variables y condiciones
en las cuales la viabilidad de una aplicación de software debe
predeterminarse para verificar su funcionalidad. Ayuda a los testers a
determinar si un sistema está funcionando como debía funcionar según los
requisitos del cliente. Si el caso de prueba es el "cómo", entonces el
escenario de prueba es el "qué". Es una secuencia de muchos casos de
prueba que deben ejecutarse uno tras otro para verificar la funcionalidad de
la aplicación. Los casos de prueba son un subconjunto de escenarios de
prueba, mientras que el último se basa en la funcionalidad y se trata del
flujo de trabajo.

Un caso de prueba es el diseño de cómo y bajo qué condiciones se probará algo.

Por ejemplo, si deseas probar un automóvil, un escenario de prueba es “probar el
vehículo en condiciones de tormenta de granizo” y un caso de prueba puede ser
“Probar el sistema de frenos bajo condiciones meteorológicas de tormenta.”

¿Por qué es importante la RTM?

Es una forma sencilla de rastrear el requisito con sus escenarios de prueba y

casos de prueba correspondientes. RTM suele ser una hoja de trabajo que
contiene los requerimientos con todos los escenarios y casos de prueba posibles y
su estado actual, es decir, si se aprobaron o fallaron. Esto ayudaría al equipo de
prueba a comprender el nivel de actividades de prueba realizadas para el producto
específico.

¿Qué parámetros debemos incluir en la RTM?

ID de requerimiento (ID: es la identificación o número/letras que lo identifica al

requisito, el cuál es único, no se repite)

Tipo de requisito y descripción

Casos de prueba con estado

Ejemplo: un ejemplo simple de Matriz de trazabilidad de requerimientos, donde

podemos indicar el resultado de la prueba en el Status, si Pasó o Pass: es que no
hay errores, si falló o Fail: es que hay errores, y No run: no pudo ser corrida, el
sistema no lo permitió o no existe la opción para hacerlo.
Imagen 7.3: Ejemplo RTM. Fuente: elaboración propia.

¿Qué vemos en la matriz de trazabilidad?

Una matriz de trazabilidad de requerimientos permite mostrar:

 Cobertura de requerimientos con el número de casos de prueba,

normalmente se expresa en %
 Estado de diseño y estado de ejecución para un caso de prueba específico
 Los defectos relacionados y el estado actual también se pueden mencionar
en la misma matriz.
 Este tipo de matriz proporcionaría una pantalla para todas las actividades
de prueba.
 Un equipo de testers también puede optar por el seguimiento de
requerimientos en las herramientas de gestión de pruebas disponibles.
 Confirma la cobertura de prueba del 100%, es decir que se han corrido un
100% de las pruebas diseñadas.
 Indica los requerimientos que faltan probar o las incoherencias del
documento.
 Muestra los defectos generales o el estado de ejecución con un enfoque en
los requerimientos del negocio.
 Ayuda a analizar o estimar el impacto en el trabajo del equipo de control de
calidad con respecto a la revisión o reelaboración de los casos de prueba
(volver a escribirlos revisando bien los requerimientos y hablando con el
desarrollador para acordar los objetivos).

¿Cómo crear una matriz de trazabilidad de requerimientos?

Ya hemos realizado en el ejercicio 7.1 el primer paso: documentar todos los
requerimientos identificados en el caso y asignarles un número de seguimiento.

Los equipos de Testing no documentan el BRD ni el TRD, lo realizan los Analistas

de negocios o de sistemas. Además, algunas empresas utilizan Documentos de
requerimientos de función (FRD - functional requirements document) que son
similares al Documento de requerimientos técnicos, pero el proceso de creación
de la Matriz de trazabilidad sigue siendo el mismo.

Ahora tenemos toda la información necesaria para poder crear una RTM en
pruebas:

 Paso 1: Nuestro caso de prueba de muestra es "Verificar el inicio de sesión,

cuando se ingrese el ID y la contraseña correctos, debe iniciar sesión
correctamente"

Imagen 7.6: RTM - Paso 1. Fuente: elaboración propia.

 Paso 2: Identifique el requisito técnico que este caso de prueba está

verificando. Para nuestro caso de prueba, se está verificando el requisito
técnico es T94. T94 Si el User id y el password son válidos, login exitoso
 Paso 3: tengamos en cuenta este requisito técnico (T94) en el caso de
prueba.
 Imagen 7.7: RTM - Paso 3. Fuente: elaboración propia.

 Paso 4: Identificar el requisito del negocio para el que se define este TR

(requisito técnico-T94)

Imagen 7.8: RTM - Paso 4. Fuente: elaboración propia.

 Paso 5: tenga en cuenta el BR (requisito del negocio) en el caso de prueba

 Imagen 7.9: RTM - Paso 5. Fuente: elaboración propia.

Identificar el requerimiento para el cual el requisito técnico T94 fue definido

 Paso 6: haga lo anterior para todos los casos de prueba. Más tarde,
extraiga las primeras 3 columnas de su conjunto de pruebas. ¡RTM en
prueba está listo!

Imagen 7.10: RTM en prueba - Paso 6. Fuente: elaboración propia.

ANÁLISIS DE AUTOMATIZACIÓN

La automatización es una optimización que se realiza para poder replicar las

pruebas una y otra vez cada vez que una nueva versión de software está
disponible para ser testeada. Para automatizar se requieren conocimientos de
programación ya que los QA especializados en automatización escriben sus
propias pruebas para cada caso que deseen testear.
En la fase de requisitos, el equipo de control de calidad analiza el alcance de la
automatización para las pruebas de regresión. Si se agrega la automatización al
alcance, el equipo decide qué herramienta se puede usar, qué funcionalidades se
cubrirán como automatización, el marco de tiempo y la asignación de recursos
involucrados para el desarrollo de la automatización. Una vez que se completa
este análisis, el equipo de control de calidad proporciona el Informe de viabilidad
de automatización a diferentes partes interesadas para que lo aprueben.

Cómo analizar los requisitos

Un requisito bien desarrollado debe mantener estas características. Debe ser:

 Atómico
 Identificado de forma única
 Completo
 Coherente y sin ambigüedades
 Trazable
 Priorizado
 Comprobable

Ahora podemos inferir el significado de cada uno de estos atributos de un

buen requisito:

Atómico

Todos y cada uno de los requisitos deben ser atómicos. Es decir, deben tener un
nivel de detalles muy bajo y no debería ser posible separarlos en componentes.

Continuando con el ejemplo anterior, el mal requisito es “Los estudiantes podrán

matricularse en cursos de grado y posgrado”. Este es un mal requisito porque no
es atómico ya que habla de dos entidades (diferentes, cursos de pre grado y
posgrado. La forma en la que este requisito se vuelve atómico es al separarlo en
dos: un requisito para cada entidad. Uno hablará de la inscripción a los cursos de
pre grado, mientras que el otro hablará de la inscripción a los cursos de posgrado.

Identificado de forma única

De manera similar, el siguiente atributo de calidad es verificar la identificación

única. En el ejemplo que venimos usando, tenemos dos requisitos separados,
pero ambos tienen el mismo ID # 1. Por lo tanto, al hacer referencia al ID#1, no
sabremos con exactitud a qué porción del requerimiento estamos haciendo
referencia. Entonces, separarlos con identificaciones únicas nos dará como
resultado lo siguiente:

Sección 1: inscripciones en cursos.

Requisito: 1.1 es inscripción en cursos de pre grado.

 Requisito: 1.2 es inscripción en cursos de posgrado.

Completo

Además, todos y cada uno de los requisitos deben estar completos. En la imagen
7.12, vemos cómo el ejemplo de un requisito incompleto dice que un "usuario
profesor iniciará sesión en el sistema proporcionando su nombre de usuario,
contraseña y otra información relevante". Aquí, la “otra información relevante” no
está clara, por lo que la otra información relevante debe detallarse para completar
el requisito.

Consistente y sin ambigüedades

Los requisitos deben ser consistentes e inequívocos. En el cuadro vemos que

coexisten dos requisitos que presentan contradicciones.

 "Un estudiante tendrá cursos de pre grado o cursos de posgrado, pero no

ambos".
 "Algunos cursos tendrán que estar abierto tanto a estudiantes de pre grado
como de posgrado”.

El problema en este requisito es que desde el primer requisito parece que los
cursos se dividen en dos categorías: cursos de pregrado y cursos de posgrado y el
estudiante puede optar por cualquiera de los dos, pero no por ambos. Pero
cuando lee otro requisito, entra en conflicto con el primer requisito y dice que
algunos cursos se abrirán tanto para graduados como para estudiantes pre-grado.

Por lo tanto, es necesario convertir este requisito en un buen requisito, que es "Un
estudiante tendrá cursos de pre grado o cursos de posgrado, pero no ambos". Lo
que significa que cada curso se marcará como curso de pre grado o curso de
posgrado.

Trazable

Todos y cada uno de los requisitos deben ser rastreables porque existen
diferentes niveles de requisitos. Más adelante veremos que estos niveles son:
requisitos comerciales, requisitos arquitectónicos y de diseño; seguidos de
requisitos de integración del sistema.

Ahora, cuando convertimos los requisitos comerciales en requisitos

arquitectónicos y de diseño o convertimos los requisitos arquitectónicos y de
diseño en requisitos de integración de sistemas, tiene que haber trazabilidad. Lo
que significa que deberíamos ser capaces de tomar todos y cada uno de los
requisitos comerciales y asignarlos a uno o más requisitos de arquitectura y diseño
de software correspondientes. Entonces, aquí hay un ejemplo de un requisito
incompleto que dice: "¿Mantener la información del estudiante, asignada a la ID de
solicitud de BRD?" Asignando la identificación del requisito 4.1.ya tenemos un
requisito trazable.
Por lo tanto, este mapeo debe estar ahí para todos y cada uno de los requisitos.
De la misma manera que tenemos un requisito de mapeo de alto y bajo nivel, el
mapeo también existe entre el sistema y el requisito de integración con el código
que implementa ese requisito y también hay un mapeo entre el sistema y el
requisito de integración con el caso de prueba que prueba ese requisito en
particular. Esto permite la trazabilidad a lo largo de todo el proyecto

Priorizado

Luego, se deben priorizar todos y cada uno de los requisitos, de modo que el
equipo tenga una guía sobre qué requisito se puede implementar primero y cuál se
puede hacer más adelante. En el ejemplo vemos el caso común de que todos los
requisitos son importantes y han sido priorizados con la misma prioridad 1.

Todo no puede tener la misma prioridad, ya que los equipos deben poder saber
por dónde empezar o cuál es el requisito del cual dependen otros.

Entonces, el ejemplo de un buen requisito aquí es el registro de estudiantes y la

inscripción de cursos tiene la prioridad más alta 1, mientras que mantener la
información del usuario está debajo en la prioridad 2 y luego tenemos ver la boleta
de calificaciones en la prioridad 3.

Comprobable

Todos y cada uno de los requisitos deben ser comprobables.

En nuestro ejemplo, el requisito mal redactado es "cada página del sistema se

cargará en un marco de tiempo aceptable". Ahora, hay dos problemas con este
requisito: primero, cada página significa que puede haber muchas páginas, lo que
hará que los esfuerzos de prueba sean difíciles de medir. El otro problema es que
dice que la página se va a cargar en un período de tiempo aceptable. Ahora, ¿cuál
es el período de tiempo aceptable? ¿Aceptable para quién? Entonces, tenemos
que convertir un argumento no comprobable en un argumento comprobable, que
indique específicamente de qué página estamos hablando ("páginas de registro de
estudiantes e inscripción de cursos") y también se proporciona el marco de tiempo
aceptable (5 segundos).

Conclusión
Esta es una mera introducción a la buena práctica en la redacción de requisitos. El
hábito de ir redactando requisitos atómicos, completos e identificables acelera la
comunicación entre los equipos y ahorra tiempo y desgaste.

Resultado de la fase de análisis de requerimientos

Luego de completar la fase de “Análisis de requerimientos”, tendremos esta

documentación a disposición de los equipos:
  Documento de comprensión de requisitos.
 Escenarios de alto nivel.
 Estrategia de prueba de alto nivel y aplicabilidad de prueba.

Análisis de requisitos de software aplicado

En el encuentro de hoy dedicamos mucho tiempo a los requerimientos. ¿La

razón? Un buen análisis de requerimientos ahorra tiempo, elimina errores, baja la
cantidad de suposiciones entre los equipos y entrega felicidad a los
desarrolladores.

El requisito de software detalla las necesidades funcionales o no funcionales que

deben implementarse en un sistema.

Funcional significa proporcionar un servicio particular al usuario.

Por ejemplo, en el contexto de la aplicación bancaria, el requisito funcional será

que cuando el cliente seleccione "Ver saldo", debe poder ver el último saldo de su
cuenta.

El requisito de software también puede ser no funcional. Puede ser un requisito

de rendimiento. Por ejemplo, un requisito no funcional es que cada pantalla de
aviso del sistema sea visible para los usuarios por 5 segundos.

Para claridad y especificidad, los requisitos de software generalmente se

expresan como declaraciones.

Tipos de requisitos

Requisitos comerciales: son requisitos de alto nivel que se toman del caso
comercial de los proyectos. Por ejemplo, un sistema de servicios bancarios
móviles brinda servicios bancarios en el sudeste asiático. El requisito comercial
que se decide para India es el resumen de cuenta y la transferencia de fondos,
mientras que para China es el resumen de cuenta y el pago de facturas.
 Imagen 7.13: Ejemplos de tipos de requisitos. Fuente: elaboración propia.

Requisitos arquitectónicos y de diseño: estos requisitos son más detallados que

los requisitos comerciales. Determina el diseño general requerido para
implementar el requisito comercial. Para nuestra organización educativa, los casos
de uso de arquitectura y diseño serían inicio de sesión, detalles del curso, etc. El
requisito sería como se muestra a continuación.

Imagen 7.14: Caso de uso bancario y requisito. Fuente: elaboración propia.

Requisitos del sistema y de integración: En el nivel más bajo, tenemos requisitos

del sistema y de integración. Es una descripción detallada de todos y cada uno de
los requisitos. Puede ser en forma de historias de usuarios que realmente
describen el lenguaje comercial cotidiano. Los requisitos se encuentran en
abundantes detalles para que los desarrolladores puedan comenzar a codificar.
Aquí, en el ejemplo del módulo de pago de facturas, donde se mencionarán los
requisitos para agregar un emisor de facturas.
 Imagen 7.15: Pago de facturas y requerimientos. Fuente: elaboración propia.

A veces, para algún proyecto, es posible que no recibas ningún requisito o

documento para trabajar. Pero todavía hay otras fuentes de requisitos que puedes
considerar para el requisito o la información, de modo que se pueda basar el
software o diseño de prueba en estos requisitos.

Entonces, las otras fuentes de requisitos en las que puede confiar son

 Transferencia de conocimientos de colegas o empleados que ya trabajan

en ese proyecto
 Habla sobre el proyecto con el analista comercial, el gerente de producto, el
líder del proyecto y los desarrolladores.
 Analiza la versión anterior del sistema que ya está implementada en el
sistema
 Analiza el documento de requisitos anterior del proyecto.
 Mira los informes de errores anteriores, algunos de los informes de errores
se convierten en solicitudes de mejora que pueden implementarse en la
versión actual.
 Mira la guía de instalación si está disponible para ver cuáles son los
requisitos de instalación.
 Analiza el dominio o el conocimiento de la industria que el equipo está
tratando de implementar

Independientemente de la fuente de requisitos que obtengas, asegúrate de

documentarlos de alguna forma. Haz que otros miembros del equipo con
experiencia y conocimientos los revisen.

Planificación de pruebas de software

Imagen 8.1: Ciclo de vida del testing. Fuente: GeeksForGeeks

La mayoría de las iniciativas de desarrollo comienzan con identificar los requisitos

de software que especifican lo que la empresa espera del proyecto.

Los requisitos de software a menudo incluyen necesidades comerciales de alto

nivel, requisitos arquitectónicos que detallan cómo se diseñará y admitirá la
función, y requisitos detallados del sistema a partir de los cuales los
desarrolladores crearán el producto. Los requisitos del sistema incluyen
especificaciones funcionales y no funcionales. Es trabajo del tester identificar
oportunidades para probar y validar.

En esta fase de STLC (Software Testing Life Cycle o Ciclo de vida del testeo del
software), los tester trabajan tanto dentro de sus propios equipos como de forma
interdisciplinaria para contextualizar cómo probarán el software. El análisis de
requisitos a menudo incluye sesiones de intercambio de ideas, identificación de
puntos ciegos o áreas poco claras en los requisitos y priorización de ciertas
evaluaciones.

En caso de duda o falta de documentación de requisitos, el equipo de control de

calidad hará preguntas a los equipos de ingeniería o comercial para aclarar y
diseñar una estrategia de prueba.

La segunda fase de STLC es importante, ya que guía gran parte del trabajo a
seguir. La planificación de pruebas toma los conocimientos encontrados durante
los requisitos o el análisis del producto y los convierte en una estrategia de control
de calidad documentada.

El liderazgo del equipo de prueba determina qué recursos y esfuerzos se

destinarán a las pruebas. La documentación del plan de prueba resultante informa
tanto a los testers como a otros departamentos cómo comenzará el trabajo de
prueba, manteniendo a todos en la misma página. Este plan es especialmente útil
cuando otros miembros de la organización son parte activa en las pruebas y en la
corrección de errores, como por ejemplo los desarrolladores que ejecutan pruebas
unitarias y escriben revisiones.

El plan de pruebas especifica varios detalles del trabajo de control de calidad que
se realizará, incluidos el alcance, los objetivos, los tipos de pruebas funcionales y
no funcionales (tanto automáticas como manuales) y los detalles de los entornos
de prueba. Una vez que se determinan estos detalles, la gestión de pruebas
establece roles y plazos para el trabajo. Finalmente, el equipo de pruebas puede
determinar qué entregables proporcionará al completar las fases de STLC.

La creación de un plan de pruebas implica los siguientes pasos:

Imagen 8.1: Pasos en la creación del plan de pruebas. Fuente: elaboración propia.
FASES DE UNA PLANIFICACIÓN

1. Análisis de producto
El foco de un tester es aprender lo más posible sobre el producto que se está
probando, el cliente y los usuarios finales de productos similares. Idealmente, esta
fase debería centrarse en responder a las siguientes preguntas:
 ¿Quién usará el producto?
 ¿Cuál es el objetivo principal de este producto?
 ¿Cómo funciona el producto?
 ¿Cuáles son las especificaciones de software y hardware?
Para lograr estas respuestas, recomendamos hacer lo siguiente:
 Entrevistar a clientes, diseñadores y desarrolladores.
 Revisar la documentación del producto y del proyecto.
 Realizar un recorrido del producto.

Imagen 8.2: Etapas del análisis de producto. Fuente: elaboración propia.

2. Diseño de la estrategia de prueba

El documento de estrategia de prueba es desarrollado por el administrador de
pruebas y define lo siguiente:
 Objetivos del proyecto y cómo alcanzarlos.
 La cantidad de esfuerzo y costo requerido para la prueba.
Más específicamente, el documento debe detallar:
  Alcance de la prueba: contiene los componentes de software (hardware,
software, middleware) que se probarán y también aquellos que no se
probarán.
 Tipo de prueba: Describe los tipos de pruebas que se utilizarán en el
proyecto. Esto es necesario ya que cada prueba identifica tipos específicos
de errores.
 Riesgos y problemas: describe todos los posibles riesgos que pueden
ocurrir durante las pruebas (plazos ajustados, gestión insuficiente,
estimación presupuestaria inadecuada o errónea), así como el efecto de
estos riesgos en el producto o negocio.
 Logística de prueba: menciona los nombres de los testers (o sus
habilidades), así como las pruebas que realizarán. Esta sección también
incluye las herramientas y el cronograma establecido para las pruebas.

Imagen 8.3: Estrategia de la prueba. Fuente: elaboración propia.

2.1. Definir el alcance de las pruebas

Antes del inicio de cualquier actividad de prueba, se debe conocer el alcance de la
prueba. Debes pensarlo mucho. Los componentes del sistema que se probarán
(hardware, software, middleware, etc.) se definen como "el alcance". Los
componentes del sistema que no se probarán también deben definirse claramente
como "fuera del alcance".
Definir el alcance de su proyecto de prueba es muy importante para todas las
partes interesadas. Un alcance preciso ayuda ya que:
 Brinda a todos una información confiable y precisa de las pruebas que está
realizando
 Todos los miembros del proyecto tendrán una comprensión clara de lo que
se prueba y lo que no.

¿Cómo determinar el alcance de tu proyecto?

Para determinar el alcance, debes tener en claro:
 Requisito preciso del cliente
 Presupuesto del proyecto
 Especificaciones del producto
 Habilidades y talento de su equipo de prueba
 2.2. Identificar el tipo de prueba
Un tipo de prueba es un procedimiento de prueba estándar que proporciona un
resultado de prueba esperado. Cada tipo de prueba está formulado para identificar
un tipo específico de errores del producto. Sin embargo, todos los tipos de
pruebas tienen como objetivo lograr un objetivo común: "Detección temprana de
todos los defectos antes de entregar el producto al cliente".
Los tipos de prueba comúnmente utilizados son pruebas de caja negra (black-box
testing), pruebas basadas en la experiencia de usuario, pruebas basadas en
requerimientos y especificaciones y pruebas de caja blanca (white-box testing).

Cómo elegir el tipo de prueba más apropiado

Existe una amplia variedad de pruebas para probar productos de software. Puede
que un equipo no tenga suficientes esfuerzos y/o recursos para manejar todos los
tipos de pruebas disponibles. Como administrador de pruebas, debes establecer la
prioridad de los tipos de pruebas. Usa estas preguntas como guía:
 ¿Qué tipos de pruebas son más pertinentes para las pruebas de
aplicaciones web?
 ¿Qué tipos de pruebas pueden ignorarse para ahorrar costos?
 ¿Con qué tipos de pruebas ya trabajaste y te sientes a gusto?
 ¿Con qué recursos cuentas para probar pruebas nuevas?
2.3. Documentar riesgos y problemas
El riesgo es un evento incierto del futuro con una probabilidad de ocurrencia y un
potencial de pérdida. Cuando el riesgo realmente ocurre, se convierte en el
"problema".
En el plan de prueba de control de calidad, documentarás aquellos riesgos que
puedas identificar:

RIESGOS MITIGACIÓN

Los miembros del equipo Planifique un curso de capacitación para

carecen de las habilidades mejorar las habilidades de sus miembros
requeridas para las pruebas de
sitios web.

El cronograma del proyecto es Establezca la Prioridad de prueba para cada

demasiado apretado; es difícil una de las actividades de prueba.
completar este proyecto a
tiempo
 Test Manager tiene poca Planificar la capacitación en liderazgo para el
habilidad de gestión gerente

El cliente exige una salida a Preparar al cliente en pruebas anteriores para

producción sin errores la posibilidad de errores mínimos.
Asegurarse hacia adentro del equipo que no
haya errores críticos en producción.

Estimación presupuestaria Establezca el alcance antes de comenzar a

incorrecta y sobrecostos trabajar, preste mucha atención a la
planificación del proyecto y realice un
seguimiento y mida constantemente el
progreso

2.4. Crear logística de prueba

El Test Manager debe responder a las siguientes preguntas:
 ¿Quién hará la prueba?
 ¿Cuándo ocurrirá la prueba?
Aún cuando no estén definidas las personas del equipo que llevarán a cabo las
pruebas, el manager decidirá qué perfil de especialidad debe llevarlas a cabo.
Para seleccionar el miembro correcto para una tarea específica, debe considerar
si su habilidad está calificada para la tarea o no, y también estimar el presupuesto
del proyecto.
¿Recuerdas atención al detalle? Es tu habilidad crítica a desarrollar. Sin embargo,
te recomendamos tener una actitud de curiosidad y apertura en estas situaciones:
 Habilidad para entender el punto de vista de los clientes.
 Fuerte deseo de calidad.
 Comunicación efectiva
En el desarrollo de las pruebas, todos los perfiles de personas tendrán una fuerte
formación técnica, pero son aquellas personas que se dedican a completar su
perfil quienes tienen mejor desempeño laboral y mayor crecimiento.
En este caso, el miembro que se hará cargo de la ejecución de la prueba es el
probador. Según el presupuesto del proyecto, puede elegir un miembro interno o
externo como probador.

¿Cuándo ocurrirá la prueba?

Las actividades de prueba deben coincidir con el calendario de entregas de las
actividades de desarrollo asociadas.
Comenzará a probar cuando tenga todos los elementos requeridos que se
muestran en la siguiente figura.

Imagen 8.4: Requerimientos para el testeo. Fuente: elaboración propia.

3. Definición de objetivos
Esta fase define los objetivos y los resultados esperados de la ejecución de la
prueba. Dado que todas las pruebas pretenden identificar tantos defectos como
sea posible, los objetivos deben incluir:
 Una lista de todas las características del software (funcionalidad, GUI,
estándares de rendimiento) que deben probarse.
 El resultado ideal o punto de referencia para cada aspecto del software que
necesita pruebas. Este es el punto de referencia con el que se compararán
todos los resultados reales.

4. Establecer criterios de prueba

Los criterios de prueba se refieren a los estándares o reglas que rigen todas las
actividades en un proyecto de prueba. Los dos principales criterios de prueba son:
 Criterios de Suspensión: define los puntos de referencia para suspender
todas las pruebas. Por ejemplo, si los miembros del equipo de control de
calidad encuentran que el 50 % de todos los casos de prueba han fallado,
todas las pruebas se suspenden hasta que los desarrolladores resuelvan
todos los errores identificados hasta el momento.
 Criterios de salida: define los puntos de referencia que significan la
finalización exitosa de una fase de prueba o proyecto. Los criterios de
salida son los resultados esperados de las pruebas y deben cumplirse
antes de pasar a la siguiente etapa de desarrollo. Por ejemplo, el 80 % de
todos los casos de prueba deben marcarse como exitosos antes de que
una función o parte del software en particular pueda considerarse adecuada
para uso público.
5. Asignación de recursos de planificación
Esta fase crea un desglose detallado de todos los recursos necesarios para la
finalización del proyecto. Los recursos incluyen el esfuerzo humano, el equipo y
toda la infraestructura necesaria para realizar pruebas precisas y completas.
Esta parte del plan de prueba decide la medida de los recursos (número de testers
y equipos) que requiere el proyecto. Esto también ayuda a los gerentes de
pruebas a formular un cronograma y una estimación correctamente calculados
para el proyecto.
Veamos una tabla de ejemplo para determinar los recursos humanos:

Nro. Miembro Tarea

1 Gerente de prueba Gestionar todo el proyecto

Definir las direcciones del proyecto y adquirir los
recursos apropiados

2 Tester Identificar y describir técnicas de

prueba/herramientas/arquitectura de
automatización apropiadas.
Verificar y evaluar el enfoque de prueba
Ejecutar las pruebas, Registrar resultados,
Reportar los defectos.
El probador puede ser miembro interno o
externo, según el presupuesto.
Para la tarea que requiere poca habilidad,
subcontratar para ahorrar costos del proyecto.

3 Desarrollador/Programador Implementar los casos de prueba, el programa

que testea de prueba, el conjunto de pruebas, etc.

4 Administrador de pruebas Crea y garantiza que el entorno de prueba y los

activos se gestionen y mantengan
Brinda soporte para usar el entorno de prueba
para la ejecución de la prueba
 5 QA Encargarse del aseguramiento de la calidad
Comprobar para confirmar si el proceso de
prueba cumple con los requisitos especificados

Veamos una tabla de ejemplo para determinar los recursos de sistemas:

Nro. Recurso Descripción

1 Servidor Instalar la aplicación web bajo prueba.

Esto incluye un servidor web, un servidor de base de datos y un
servidor de aplicaciones separados, si corresponde

2 Herramienta La herramienta de prueba es para automatizar la prueba,

de prueba simular la operación del usuario, generar los resultados de la
prueba. Existen muchas herramientas de prueba que se pueden
utilizar para este proyecto, como Selenium, QTP, etc.

3 Red Se necesita una red que incluya LAN e Internet para simular el
entorno empresarial y de usuario real

4 Ordenador La PC que los usuarios usan a menudo para conectarse al

servidor web

6. Planificación de la configuración del entorno de prueba

El entorno de prueba se refiere a la configuración de software y hardware en la
que los QA ejecutan sus pruebas. Idealmente, los entornos de prueba deberían
ser dispositivos reales para que los testers puedan monitorear el comportamiento
del software en condiciones reales de usuario. Ya sea que se trate de pruebas
manuales o pruebas de automatización, nada supera a los dispositivos reales,
instalados con navegadores reales y los sistemas operativos no son negociables
como entornos de prueba. No comprometa los resultados de sus pruebas con
emuladores o simuladores.
¿Cómo configurar el entorno de prueba?
Para finalizar esta tarea, se necesita una fuerte cooperación entre el equipo de
prueba y el equipo de desarrollo.
Debe hacerle algunas preguntas al desarrollador para comprender claramente la
aplicación web que se está probando. Aquí hay algunas preguntas recomendadas.
Por supuesto, puede hacer las otras preguntas si lo necesita.
 ¿Cuál es la conexión máxima de usuarios que este sitio web puede manejar
al mismo tiempo?
 ¿Cuáles son los requisitos de hardware/software para instalar este sitio
web?
 ¿El ordenador del usuario necesita alguna configuración en particular para
navegar por el sitio web?

7. Determinar el programa de prueba y la estimación.

Para la estimación de pruebas, el proyecto se dividirá en tareas más pequeñas y
se asignará el tiempo y el esfuerzo necesarios para cada una.
Luego, se creará un cronograma para completar estas tareas en el tiempo
designado con la cantidad específica de esfuerzo.
Sin embargo, la creación del cronograma requiere aportes desde múltiples
perspectivas:
 Disponibilidad de empleados, número de días laborables, plazos de los
proyectos, disponibilidad diaria de recursos.
 Riesgos asociados al proyecto que ha sido evaluado en una etapa anterior.

¿NECESITAS UN EJEMPLO?

Tarea Miembros Esfuerzo

estimativo

Crear las especificaciones de Diseñador de pruebas 170 horas

las pruebas

Ejecutar las pruebas Tester / Administrador de 80 horas

pruebas

Reportar las pruebas Tester 10 horas

 Enviar los reportes 20 horas

Total 280 horas

Luego se crea el cronograma para completar estas tareas. Hacer un cronograma

es un término común en la gestión de proyectos. Al crear un cronograma sólido en
la Planificación de pruebas, el Gerente de pruebas puede usarlo como
herramienta para monitorear el progreso del proyecto y controlar los sobrecostos.
Para crear el cronograma del proyecto, el administrador de pruebas necesita
varios tipos de entrada, como se muestra a continuación:
 Fecha límite del empleado y del proyecto: los días hábiles, la fecha límite
del proyecto, la disponibilidad de recursos son los factores que afectaron el
cronograma
 Estimación del proyecto: en base a la estimación, el administrador de
pruebas sabe cuánto tiempo lleva completar el proyecto. Para que pueda
hacer el cronograma del proyecto apropiado
 Riesgo del proyecto: Comprender el riesgo ayuda a Test Manager a
agregar suficiente tiempo adicional al cronograma del proyecto para lidiar con
los riesgos.

8. Establecer entregables de prueba

Los entregables de prueba se refieren a una lista de documentos, herramientas y
otros equipos que deben crearse, proporcionarse y mantenerse para respaldar las
actividades de prueba en un proyecto.
Se requiere un conjunto diferente de entregables antes, durante y después de la
prueba.
 Entregables requeridos antes de la prueba. Documentación sobre:
o Plan de prueba
o Diseño de prueba
 Entregables requeridos durante la prueba. Documentación sobre:
o Guiones de prueba
o Simuladores o emuladores (en etapas iniciales)
o Datos de prueba
o Registros de errores y ejecuciones
 Entregables requeridos después de la prueba. Documentación sobre:
o Resultados de la prueba
 o Informes de defectos
o Notas de lanzamiento
Un plan de pruebas en software es la columna vertebral sobre la que se construye
todo el proyecto. Sin un plan lo suficientemente amplio y bien elaborado, los
controles de calidad se confundirán con objetivos y plazos vagos e indefinidos.
Esto dificulta innecesariamente las pruebas rápidas y precisas, y retrasa los ciclos
de lanzamiento.

Análisis y diseño
Factores que determinan los niveles de detalles de las condiciones de prueba:
1. Nivel de prueba, el nivel de detalle y la calidad de la base de prueba.
2. Complejidad del sistema/software y ciclo de vida de desarrollo utilizado.
3. Riesgos asociados a proyectos y productos.
4. La relación entre los conceptos básicos de las pruebas, lo que debe
probarse y cómo debe probarse.
5. Una herramienta de gestión de pruebas.
6. Madurez del proceso de evaluación, así como de las habilidades y
conocimientos de los analistas.
7. El nivel de especificidad del Diseño de Prueba y otras implicaciones de la
tarea de prueba.
8. Disposición de los clientes a participar en la consulta.

Las siguientes son las diversas fuentes para recopilar información de prueba:
1. Requisitos de software: la especificación de requisitos de software
(documento SRS) establece cómo debe construirse el sistema de software. En
pocas palabras, SRS proporciona una ruta de proyecto para todos los
involucrados. Proporciona descripciones avanzadas de especificaciones de
software activas e inactivas, así como condiciones de funcionamiento que indican
cómo el usuario puede interactuar con el sistema una vez completado. Las
siguientes son características comunes de SRS:
¿Cuál es el propósito del software que se está construyendo?
o Todas las revisiones de software.
o Rendimiento del software, o para qué está diseñado.
o Rendimiento del software en el entorno de producción.
o Detalles válidos y no válidos.
o Conectores visuales externos, o cómo el software interactuará con el
hardware u otro software.
o Restricciones en el diseño del software o las establecidas en el entorno
operativo.
2. Requisitos comerciales: muestra los detalles del software de alto rendimiento.
Este es un documento oficial que describe las necesidades del cliente (escrito,
oral). Por lo general, lo produce un analista comercial que trabaja con los clientes
y se basa en la interacción y las necesidades de los clientes. Business Process es
una descripción detallada de cómo nuestros socios comerciales pretenden cumplir
con sus roles, construir relaciones comerciales y compartir tareas para participar
de manera efectiva con la ayuda de sus sistemas de información.
3. Documento de diseño funcional: la especificación de diseño funcional, o FDS,
es un documento que describe cómo funcionará un proceso o sistema de control.
Explica cómo funcionará el sistema planificado, cómo interactuará la gente con él
y qué se puede esperar de una variedad de condiciones operativas. La
especificación de diseño específico ayuda por una variedad de razones. Una de
las principales razones es que lleva mucho tiempo producir dibujos o escribir un
código de PLC sin algún tipo de acuerdo escrito sobre lo que debe lograr el
sistema. Las especificaciones de diseño funcional se pueden compartir con los
miembros del equipo, los compradores y las partes interesadas relevantes para
obtener comentarios y revisiones hasta que se acuerde y firme el documento final.
Este proceso de revisión y los cambios son importantes para garantizar que el
diseño final sea objetivo y satisfaga las necesidades de los participantes.
Posteriormente, el documento se entrega a los equipos de ingenieros para el
diseño técnico y los programas, con detalles operativos que sirven de guía. Los
ingenieros sabrán qué dibujar, los desarrolladores sabrán qué debe hacer el
código y los clientes sabrán qué traer cuando se complete la especificación de
diseño funcional. La especificación de diseño específico identifica lo que debe
usarse en el ciclo de vida de la ingeniería de software industrial.
4. Requisitos operativos: los requisitos de rendimiento son importantes para su
producto porque, como dicen, proporcionan algunos tipos de funcionalidad.
Hágase la pregunta "¿esto afecta el rendimiento de mi herramienta?" O "¿Cuál es
el significado de esto?" puede ayudar con este programa. Esas necesidades
específicas pueden tener un conjunto menor de riesgos y requisitos. También
puede tener requisitos que expliquen cómo su sistema de software interactuará
con diferentes herramientas, lo que nos lleva a las necesidades de las
interacciones externas.

5. Requisitos de relación externa: los requisitos de interacción externa

son la variedad más precisa de necesidades con propósito. Estos son
especialmente importantes cuando se trabaja con sistemas integrados.
Describen cómo su producto interactuará con diferentes componentes.

¿Cuándo crear un diseño de prueba?

Una vez que se definen las condiciones de prueba y se dispone de suficiente
información para crear los casos de prueba de alto o bajo nivel, se puede crear el
diseño de prueba para un nivel específico.
Hay algunas actividades que se llevan a cabo de forma rutinaria cuando se
implementa la prueba. Estas actividades también pueden incorporarse al proceso
de diseño cuando las pruebas se crean de forma iterativa.

Un ejemplo de tal caso es la creación de datos de prueba.

Los datos de prueba definitivamente se crearán durante la implementación de la

prueba. Por lo tanto, es mejor incorporarlo en el propio diseño de la prueba.

Este enfoque permite la optimización del alcance de las condiciones de prueba

mediante la creación automática de casos de prueba de bajo o alto nivel.

Tipos de prueba
Los tipos de prueba vistos a continuación son una clasificación sencilla, adaptada
al nivel del curso.

PRUEBAS DE CAJA BLANCA:

Las técnicas de prueba de caja blanca analizan las estructuras internas, las
estructuras de datos utilizadas, el diseño interno, la estructura del código y el
funcionamiento del software en lugar de solo la funcionalidad como en las pruebas
de caja negra. También se denomina prueba de caja de vidrio o prueba de caja
transparente o prueba estructural.

Proceso de trabajo de las pruebas de caja blanca:

1. Entrada: requisitos, especificaciones funcionales, documentos de diseño,

código fuente.

2. Tramitación: Realización de análisis de riesgos para orientar a lo largo de todo

el proceso.

3. Planificación adecuada de las pruebas: diseñar casos de prueba para cubrir

todo el código. Ejecute enjuague-repetir hasta que se alcance el software sin
errores. Comunique los resultados.

4. Salida: Elaboración de informe final de todo el proceso de ensayo.

Ventajas:

o Las pruebas de caja blanca son muy exhaustivas ya que se prueban todo el
código y las estructuras.

o Da como resultado la optimización del error de eliminación de código y

ayuda a eliminar líneas adicionales de código.
 o Puede comenzar en una etapa anterior, ya que no requiere ninguna interfaz
como en el caso de las pruebas de caja negra.

o Fácil de automatizar.

Desventajas:

o La principal desventaja es que es muy costoso.

o El rediseño del código y la reescritura del código necesitan que los casos de
prueba se escriban nuevamente.

o Se requiere que los evaluadores tengan un conocimiento profundo del

código y el lenguaje de programación en lugar de las pruebas de caja
negra.

o Las funcionalidades que faltan no se pueden detectar ya que se prueba el

código existente.

o Resulta muy complejo y a veces poco realista en el contexto de los tiempos

de entrega de un proyecto.

PRUEBAS DE CAJA NEGRA:

La técnica de prueba en la que el tester no tiene acceso al código fuente del

software y se lleva a cabo en la interfaz del software sin preocuparse por la
estructura lógica interna del software se conoce como prueba de caja negra.

o PRUEBA FUNCIONAL:

Son aquellas que se llevan a cabo para comprobar las especificaciones críticas
para el negocio, la funcionalidad y la usabilidad. Este tipo de pruebas garantizan
que las características y funcionalidades del software se comporten según lo
esperado sin ningún problema. Valida principalmente toda la aplicación con
respecto a las especificaciones mencionadas en el documento Software
Requirement Specification (SRS). Los tipos de pruebas funcionales incluyen
pruebas unitarias, pruebas de interfaz, pruebas de regresión, entre otras.

o PRUEBAS NO FUNCIONALES:

Son pruebas similares a las funcionales, sin embargo, evalúan características

como fiabilidad, usabilidad, escalabilidad, etc. Las pruebas no funcionales, como
las pruebas de carga y esfuerzo, normalmente se llevan a cabo mediante
herramientas y soluciones de automatización. Además de las pruebas de
rendimiento, los tipos de pruebas no funcionales incluyen pruebas de instalación,
pruebas de confiabilidad y pruebas de seguridad. Se cree que, al ser No
 funcionales, no deben realizarse, pero deben ejecutarse tan pronto como sea
posible. Los errores no funcionales pueden desencadenar en el fracaso del
proyecto.

o PRUEBA DE REGRESIÓN:

Se define como un tipo de prueba de software para confirmar que un programa

reciente o un cambio de código no ha afectado negativamente a las funciones
existentes. La prueba de regresión no es más que una selección total o parcial de
casos de prueba ya ejecutados que se vuelven a ejecutar para garantizar que las
funcionalidades existentes funcionen bien.

Esta prueba se realiza para asegurarse de que los nuevos cambios de código no
tengan efectos secundarios en las funcionalidades existentes. Garantiza que el
código antiguo siga funcionando una vez que se hayan realizado los últimos
cambios en el código.

Tipos de pruebas de regresión

o Pruebas de regresión finales: se realiza para validar la compilación que no ha

sufrido cambios durante un período de tiempo. Esta compilación se implementa o
envía a los clientes.

o Pruebas de regresión normal: se realiza para verificar si la compilación NO ha

roto ninguna otra parte de la aplicación debido a los cambios recientes en el
código para corregir defectos o mejorar.

Imagen 8.6: Pruebas de caja blanca y caja negra. Fuente: elaboración propia.
 Pruebas de caja blanca Pruebas de caja negra

Imprescindible conocimiento del No se requiere el funcionamiento

funcionamiento interno. interno de una aplicación.

También conocido como caja También conocido como caja

transparente/prueba estructural. cerrada/prueba basada en datos.

Normalmente realizado por probadores y Usuarios finales, evaluadores y

desarrolladores. desarrolladores.

Los dominios de datos y los límites Esto solo se puede hacer mediante
internos se pueden probar mejor. un método de prueba y error.

Niveles de prueba
Las pruebas de nivel de software se pueden clasificar principalmente en 4 niveles:
 Imagen 8.7: Niveles de prueba. Fuente: elaboración propia.

1. Pruebas unitarias: un nivel del proceso de prueba de software donde se

prueban unidades/componentes individuales de un software/sistema. El propósito
es validar que cada unidad del software funcione según lo diseñado. Las realizan
los desarrolladores sobre el mismo código.

2. Pruebas de integración: un nivel del proceso de prueba de software donde las

unidades individuales se combinan y prueban como un grupo. El propósito de este
nivel de prueba es exponer fallas en la interacción entre unidades integradas. Las
realizan los desarrolladores, cuando deben integrar más de un sistema de datos,
por ejemplo.

3. Prueba del sistema: un nivel del proceso de prueba de software en el que se

prueba un sistema/software completo e integrado. El propósito de esta prueba es
evaluar el cumplimiento del sistema con los requisitos especificados. Las realizan
los testers.

4. Pruebas de aceptación (UAT): un nivel del proceso de prueba de

software en el que se prueba la aceptabilidad de un sistema. El propósito
de esta prueba es evaluar el cumplimiento del sistema con los requisitos
comerciales y evaluar si es aceptable para la entrega. Suele ser realizada
por testers, usuarios beta y a veces por usuarios especiales del cliente (sus
project managers, por ejemplo).

Historias de usuario
Dentro de un contexto de metodologías ágiles, uno de los pasos en el proceso es
crear historias de usuario. Y si bien puede parecer que es un paso extra del
proceso, realmente nos dan un contexto importante y asocian las tareas con el
valor que estas aportan al usuario final.

Una historia de usuario es una explicación general e informal de una función de

software escrita desde la perspectiva del usuario final. Su propósito es articular
cómo proporcionará una función de software el valor al cliente.

Historias de usuario (User story)

Las historias de usuario no son lo mismo que los requerimientos del sistema de
software que son mucho más detallados y técnicos. En el desarrollo de software
ágil las personas están en primer lugar, y por lo tanto las historias de usuarios
ponen a los usuarios finales reales en el centro de la conversación. Las historias
utilizan un lenguaje no técnico para ofrecer contexto al equipo de desarrollo y sus
esfuerzos. Después de leer una historia de usuario, el equipo sabe por qué está
compilando lo que está compilando y qué valor crea.

Las historias de usuario son uno de los componentes centrales de un programa

ágil. Ayudan a proporcionar un marco centrado en el usuario para el trabajo diario,
lo que impulsa la colaboración y la creatividad y mejora el producto en general.

Sin embargo, si bien surgen en el marco de las metodologías ágiles, no son

exclusivas de las mismas. Son una gran herramienta que puede replicarse en
otras formas de trabajo.

¿Qué son las historias de usuario en un contexto de metodologías ágiles?

Una historia de usuario es la unidad de trabajo más pequeña en un marco ágil. Es

un objetivo final, no una función, expresado desde la perspectiva del usuario del
software.

Son unas pocas oraciones en un lenguaje simple que describen el resultado

deseado. Al escribirlas no se entra en detalles. Los requisitos se agregan más
tarde, una vez acordados por el equipo.

Las historias encajan perfectamente en marcos ágiles como Scrum y Kanban.

 En scrum, las historias de usuario se agregan a los sprints y se "queman"

durante la duración del sprint. Es este trabajo en historias de usuarios lo
que ayuda a los equipos de scrum a mejorar en la estimación y la
planificación de sprints, lo que lleva a pronósticos más precisos y una
mayor agilidad.
 Los equipos de Kanban extraen las historias de los usuarios en su cartera
de pedidos y las ejecutan a través de su flujo de trabajo. Gracias a las
historias, los equipos Kanban aprenden a gestionar el trabajo en curso
(WIP) y pueden perfeccionar aún más sus flujos de trabajo.

¿Cómo se relaciona un historia de usuario con un requerimiento?

Los requerimientos de un sistema definen qué es lo que el sistema debe hacer,

para lo cual se identifican las funcionalidades requeridas y las restricciones o
límites que se imponen. Las historias de usuario se desprenden de los
requerimientos ya que representan la expresión funcional de la acción que se
describe en los mismos requerimientos.
 ¡Recordatorio! Requerimientos del usuario:

Un requerimiento define las funciones y capacidades de un sistema de software.

En otras palabras: describe cómo un sistema debe comportarse. Podemos
pensar los requerimientos del sistema de manera técnica pero también
podemos analizar los requerimientos desde la perspectiva de quien usará el
sistema: el usuario.

Los requerimientos de usuario son un documento donde se describe “qué” debe

hacer el sistema en términos no técnicos y debe ser lo más detallado posible
para evitar ambigüedades. En la mayoría de las empresas también llaman a los
requerimientos de usuario RU o especificación de requerimientos de usuario.

Una historia de usuario es una herramienta en el desarrollo Agile de software que se utiliza
para capturar una descripción de una función de software desde la perspectiva de un
usuario. La historia de usuario describe el tipo de usuario, lo que quiere y por qué, y ayuda
a crear una descripción simplificada de un requisito.

El propósito de una historia de usuario es escribir cómo un proyecto entregará valor al

usuario final. Entonces, el trabajo del equipo de desarrollo es ocuparse de cómo desarrollar
el código que satisfará los requisitos de la historia de usuario. En el mejor de los casos, los
desarrolladores colaboran estrechamente con los propietarios de la empresa y las partes
interesadas para aclarar los detalles a medida que se desarrolla el código.

Las historias de usuario no reemplazan los casos de uso ni la documentación de requisitos

técnicos. En cambio, los desarrolladores de productos pueden escribir historias de usuarios
para ayudar a priorizar cómo se agregará la funcionalidad a un proyecto durante el período
de tiempo del proyecto. Una historia de usuario puede considerarse un punto de partida
para una conversación que establece el requisito real del producto.

¿Quiénes son los usuarios?

Usuario: se refiere a la persona que utiliza un producto o servicio de forma habitual.

Dependiendo del área donde se utiliza la palabra, podemos diferenciar algunos aspectos de
la persona y del producto o servicio.

Por ejemplo, un usuario en la salud es aquel que utiliza un servicio médico y un usuario en
informática puede referirse a un perfil de una cuenta en determinado sistema de una
plataforma social, un sistema de ventas, un sistema de gestión de reportes gerenciales, etc.

Cada cuenta tiene un perfil de usuario que indicará los privilegios, accesos, políticas de
seguridad, restricciones y hábitos de la persona que usa la cuenta. Por lo cual, existen
perfiles de cuentas, por motivos de seguridad y así poder proteger las transacciones a
realizar y el impacto en los datos. Según el perfil la persona podrá acceder a ciertos menús
del sistema y realizar determinadas transacciones, generalmente consulta, alta, baja y
modificaciones.

Tipos de usuarios

Los tipos de usuarios varían según el sistema y las necesidades de su uso. Por ejemplo,
pueden dividirse, según el nivel de permisos o privilegios que tienen en un sistema en:

 Usuarios operacionales: son aquellos que alimentan información y datos para que
las funciones del sistema se ejecuten adecuadamente.
 Usuarios supervisores o administradores: gestionan y administran los accesos y/o
privilegios de los demás usuarios haciendo que la operación sea eficiente.
 Usuarios ejecutivos: trabajan con los sistemas creando estrategias especiales
configurando el sistema. Ejemplo: generando campañas de publicidad en marketing,
creando una nueva línea de préstamos de un banco o armando el nuevo listado de
ofertas de un supermercado, todos publicándose en la página web de la empresa y
pudiendo usar dichos datos para vender los productos/servicios por medio de los
sistemas.
 Usuarios de sistemas: se dedican a acceder al sistema para realizar cambios,
actualizaciones, probar y encontrar errores en el sistema para así arreglarlos, pero no
en el mismo ambiente y bases de datos donde acceden los clientes finales.

Es importante tener en cuenta que Usuarios diferentes tienen requerimientos y prioridades

diferentes. Por otra parte, los usuarios finales del sistema y la organización que paga por el
sistema pueden tener requerimientos diferentes. Muchas veces se arman prototipos del
sistema para aclarar requerimientos.

Un prototipo es un primer modelo que sirve como representación o simulación del producto
final y que nos permite verificar el diseño y confirmar que cuenta con las características
específicas planteadas. De este modo, se prueba el diseño para que el cliente lo vea, defina
y decida lo que quiere, y así tenga mejor aceptación, descartando programaciones
innecesarias.

Características de una historia de usuario

Las historias de usuario suelen expresarse con una frase simple con la siguiente estructura:

“Como [perfil], [quiero] [para].”

¡Desglosemos esta estructura!

“Como [perfil]”: Quién: suele ser un puesto de trabajo, un cliente o un tipo de usuario,
también conocido como persona del usuario. ¿para quién desarrollamos esto? Buscamos el
perfil de la persona: Juan. Nuestro equipo debería comprender quién es Juan. Con suerte
hemos entrevistado a muchos Juan. Comprendemos cómo trabaja esa persona, cómo piensa
y cómo se siente. Sentimos empatía por Juan.
“Quiero”: aquí describimos su intención, no las funciones que usan. ¿Qué es lo que están
intentando lograr realmente?

“Para”: Para qué: esta es la razón por la cual el usuario necesita la característica o
funcionalidad. ¿Cómo encaja su deseo inmediato de hacer algo en la perspectiva general?
¿Cuál es el beneficio general que intentan lograr? ¿Cuál es el gran problema que debe
resolverse?

Por lo tanto, cada parte de la estructura corresponde a:

El resultado final es un sentimiento: "Como <quién>, quiero <qué> para que <por qué>".
Se pueden agregar más detalles a una historia de usuario dividiéndola en historias de
usuario más pequeñas y agrupándolas en temas.

COMO <ROL/PERFIL>

QUIERO <FUNCIONALIDAD/OBJETIVO>

PARA QUE <BENEFICIO/VALOR DE NEGOCIO>

Una historia de usuario Agile debe ser breve, por lo general cabe en una nota adhesiva o
una tarjeta de notas. Las historias de usuario deben ser escritas por la empresa en el idioma
del cliente para que quede claro tanto para la empresa como para el equipo de desarrollo lo
que quiere el cliente y por qué lo quiere.

En algunos casos, a las historias de usuario también se les asigna un identificador único y
un nivel de esfuerzo/prioridad. El identificador único suele ser un número y permite a los
desarrolladores realizar un seguimiento de cuántas historias de usuario hay y cuándo se
completan. El nivel de esfuerzo o prioridad está más personalizado para el equipo, pero
normalmente es un rango que indica cuánto tiempo llevará la función, cuántos
desarrolladores se necesitarán o cuántos requisitos tiene la función.

Por último, las historias de usuario deben asociarse con criterios de aceptación
predefinidos. Los criterios de aceptación se utilizan para identificar los límites de una
historia de usuario y lo que se debe hacer para que la historia se considere completa. Esto
también podría incluir cualquier prueba que deba realizarse para verificar una historia de
usuario.

¿Para qué se utilizan?

El propósito de una historia de usuario es articular cómo un elemento de trabajo entregará
un valor particular al cliente. Ten en cuenta que los "clientes" no tienen porqué ser usuarios
finales externos en el sentido tradicional, también pueden ser clientes internos o colegas
dentro de tu organización que dependen de tu equipo.
Principios básicos

Los principios básicos de requerimientos ágiles son:

 Son peticiones concretas y pequeñas

 Contienen la información imprescindible, ¡menos es más!
 Apoyan la cooperación, colaboración y conversación entre los miembros del
equipo
 Potencian la participación del equipo en la toma de decisiones
 Se crean y evolucionan a medida que el proyecto se desarrolla

Modelo INVEST

El siguiente modelo nos guía para escribir buenas historias de usuario. La palabra INVEST
es un acrónimo que marca las características para tener en cuenta al definir las historias de
usuario:

Independientes Es ventajoso que cada historia de usuario pueda ser planificada e

I entre sí implementada en cualquier orden según las prioridades que
establezca el Product Owner.

Negociables con Una historia de usuario es una descripción corta de una

N el Product Owner necesidad que no incluye detalles. Deben ser negociables ya que
sus detalles serán acordados con el cliente o el usuario durante la
fase de conversación. Se debe evitar historias con demasiados
detalles porque limitaría la conversación acerca de las mismas.

Valor para el La historia debe tener un valor intrínseco para el usuario,

V usuario centrado en lo que el usuario necesita, no en la tecnología que se
usará.

Estimable El equipo de desarrollo que la vaya a desarrollar debe ser capaz

E de estimar el esfuerzo que supone realizarla. Esto se relaciona
directamente con el tamaño de la historia y el conocimiento que
tenga el equipo sobre la necesidad explicitada.

Small (de un De forma que el equipo pueda llevar a cabo el desarrollo en un

S tamaño pequeño) sprint e incluso desarrollar varias historias en un mismo sprint.
 Testeable Se debe poder escribir pruebas que verifiquen que el software de
T la historia funcione adecuadamente. Si el cliente o usuario no
sabe como probar la historia de usuario significa que no es del
todo clara o que no es valiosa. Si el equipo no puede probar una
historia de usuario nunca sabrá si la ha terminado o no.

Errores comunes al escribir historias de usuario

Describir historias de usuario muy generales, del estilo “Como usuario quiero manejar
distintas cotizaciones para poder seleccionar la más conveniente”. Si bien a primera vista
cumple el patrón esperado de una Historia de Usuario, el rol de esta no está bien
especificado. ¿Quién es el usuario observando las cotizaciones? Es distinta la funcionalidad
detrás si es el administrador del sitio, o un usuario visualizando datos.

Especificar lo más detalladamente posible el usuario detrás de cada user story. De

manera similar para una user story que comienza con “Como Product Owner…” o “Como
desarrollador”. Una buena Historia de Usuario refleja la visión desde el punto de vista del
usuario del producto final, y no desde el líder o integrante del equipo de desarrollo.

Ignorar la parte de para qué quiero la funcionalidad de la Historia de Usuario. Parece

trivial, pero poder justificar la funcionalidad pedida es un ejercicio útil para mejorar el
proceso de identificar requerimientos.

La necesidad de especificar criterios de aceptación. Una manera de verlos es como casos

de prueba para el código que implementa la user story, y por su papel, debe prestarse
atención en su formulación. Por ejemplo, para una user story que describe la funcionalidad
de buscar un determinado producto en un catálogo, un criterio de aceptación podría
describir el escenario donde no se encuentre el producto al realizar la búsqueda y
especificar en este caso que se espera que aparezca en pantalla un texto del estilo
“Actualmente no se posee el producto en stock ¡Vuelva a consultar pronto!”

Un error muy frecuente es cuando no hay acumulación en absoluto. Se ve con demasiada

frecuencia cuando es prácticamente desconocido lo que sucederá después del sprint actual.
El propietario del producto puede ser muy consciente de ello en su cabeza, pero todos los
demás no tienen idea de estos planes.

No hay suficientes detalles. Demasiadas cosas parecen ser obvias cuando no lo son. Lo
que puede ser evidente para una persona, puede ser una sorpresa total para otra. Debes
asegurarte de detallar explícitamente los aspectos esenciales sin importar cuán triviales
creas que son. Sin embargo, debemos tener cuidado con no sobrepasarse con detalles: un
backlog desordenado tiene poco valor.
Escribir tareas técnicas en lugar de las historias. Tener demasiadas funciones técnicas
puede resultar en tener un software que no funcione como usted espera o, peor aún, que no
funcione en absoluto. Deje que el equipo tome la decisión final sobre los aspectos técnicos.

Beneficios de las historias de usuario

Las historias de usuario brindan a los equipos de desarrollo un contexto importante incluso
antes de que comience un proyecto. Ponen énfasis en el usuario y se enfocan en resolver
situaciones reales a las que se puede enfrentar un cliente. Esto puede ayudar a los equipos
de desarrollo a pensar de forma más crítica y creativa.

Las historias de usuario brindan una serie de beneficios clave:

 Mantienen el foco en el usuario. Una lista de tareas mantiene al equipo enfocado

en tareas que necesitan ser marcadas, pero una colección de historias mantiene al
equipo enfocado en resolver problemas para usuarios reales.
 Permiten la colaboración. Con el objetivo final definido, el equipo puede trabajar
en conjunto para decidir cómo atender mejor al usuario y cumplir ese objetivo.
 Impulsan soluciones creativas. Las historias alientan al equipo a pensar de manera
crítica y creativa sobre cómo resolver mejor un objetivo final.

Crean impulso. Con cada historia que pasa, el equipo de desarrollo disfruta de un pequeño
desafío y una pequeña victoria, impulsando el impulso.

Los beneficios adicionales de usar historias de usuario incluyen:

 Mayor visibilidad y colaboración en todo el equipo de desarrollo.

 Mejor uso de los comentarios de los usuarios finales o de los clientes.
 Posible ahorro de tiempo al priorizar el desarrollo de requisitos y funcionalidad.
 Ayuda a evitar las restricciones que se producen cuando los detalles de las
especificaciones se definen demasiado pronto.
 Mayor claridad en torno al valor comercial y la entrega de productos que los
usuarios finales realmente necesitan.

Un componente clave del desarrollo ágil de software es poner a las personas primero, y una
historia de usuario coloca a los usuarios finales en el centro de la conversación. Estas
historias utilizan un lenguaje no técnico para brindar contexto al equipo de desarrollo y sus
esfuerzos. Después de leer una historia de usuario, el equipo sabe por qué está
construyendo, qué está construyendo y qué valor crea.

Las historias de usuario son uno de los componentes centrales de un programa ágil. Ayudan
a proporcionar un marco centrado en el usuario para el trabajo diario, lo que impulsa la
colaboración, la creatividad y un mejor producto en general.
Trabajando con historias de usuario

Una vez que se ha escrito una historia, es hora de integrarla en su flujo de trabajo. Por lo
general, una historia la escribe el propietario del producto, el gerente del producto o el
gerente del programa y la envía para su revisión.

Durante una reunión de planificación de sprint o iteración, el equipo decide qué historias
abordarán en ese sprint. En ese momento, los equipos discuten los requisitos y la
funcionalidad que requiere cada historia de usuario. Esta es una oportunidad para ser
técnico y creativo en la implementación de la historia por parte del equipo. Una vez
acordados, estos requisitos se agregan a la historia.

Otro paso común en esta reunión es calificar las historias en función de su complejidad o el
tiempo de finalización. Los equipos usan tallas de camisetas, la secuencia de Fibonacci o el
póquer de planificación para hacer las estimaciones adecuadas. Se debe dimensionar una
historia para que se complete en un sprint, de modo que, a medida que el equipo especifica
cada historia, se asegura de dividir las historias que superarán ese horizonte de finalización.

¿Cómo escribir historias de usuario?

Tenga en cuenta lo siguiente al escribir historias de usuario:

 Definición de "hecho": la historia generalmente está "hecha" cuando el usuario

puede completar la tarea descripta, pero asegurate de definir qué es eso.
 Resumí subtareas o tareas: decide qué pasos específicos deben completarse y
quién es responsable de cada uno de ellos.
 Personas de usuario: ¿para quién? Si hay varios usuarios finales, considera
crear varias historias.
 Pasos ordenados: escribe una historia para cada paso en un proceso más grande.
 Escucha los comentarios: habla con los usuarios y captura el problema o la
necesidad en sus palabras. No es necesario adivinar las historias cuando puedes
obtenerlas de sus clientes.

Tiempo: el tiempo es un tema delicado. Muchos equipos de desarrollo evitan por completo
las discusiones sobre el tiempo y confían en cambio en sus marcos de estimación. Dado que
las historias deben poder completarse en un sprint, las historias que pueden tardar semanas
o meses en completarse deben dividirse en historias más pequeñas o deben considerarse su
propia épica.

¿Cómo pruebo las historias de usuario?

En la mayoría de las actividades de software, las historias de los usuarios son un breve
recordatorio de las conversaciones entre el propietario del producto, el desarrollador y el
tester. Si bien las historias de los usuarios son muy breves, el formulario suele usarse
incorrectamente y esto genera ambigüedad, discusiones innecesarias, reelaboración y
pérdida de tiempo. Ahora veremos cómo probar las historias de usuario para que puedas
asegurarte de que sean de alta calidad y reduzcan el trabajo repetido y acorten los plazos.
Diez pruebas para escribir satisfactorias historias de usuario

1. Claridad

Tus historias de usuario deben ser claras e inequívocas. El propietario del producto, el
desarrollador y el evaluador deben tener un entendimiento común de lo que se entregará a
partir del texto de la historia. A medida que escribas tus historias, asume que, si es posible
que se malinterpreten, se malinterpretarán. Además, asegúrate de que tus historias incluyan
toda la funcionalidad necesaria (excluyendo la navegación).

2. Conciso

Las historias no necesitan ser largas para transmitir el significado funcional esencial. Una o
más oraciones cortas pueden ser suficientes. Recuerda que los criterios de aceptación son
complementarios a la historia.

Sugerencia: evite la descripción sobre la navegación, los detalles de implementación, los

criterios de aceptación y los atributos de los objetos.

3. Orientado al usuario

Una historia debe escribirse desde la perspectiva del usuario. La típica recomendación ágil
es el formato:

Como User_type, quiero realizar_algo, por tal motivo.

En algunos casos, el tipo_usuario puede ser otra pieza de software, o quizás incluso un
dispositivo que interactúa con el software, como un sensor.

Sugerencia: Nunca escribas tus historias desde la perspectiva del desarrollador y evita el
término general usuario.

4. Comprobable

Una historia puede ser comprobable si contiene declaraciones claras de funcionalidad.

Utiliza frases que infieran el movimiento, el almacenamiento y la recuperación de datos.
Los ejemplos de historias comprobables incluyen frases como "actualizar perfil", "mostrar
informe de ventas", "enviar correo electrónico". Escribir sus historias de esta manera
asegurará que la intención funcional central sea clara. Esto proporciona la base a partir de la
cual se pueden generar escenarios de prueba. El conjunto de pruebas completo
generalmente dependerá de criterios de aceptación detallados complementarios.

Sugerencia: Los criterios de aceptación detallados son complementarios a la historia de

usuario principal, no incrustes criterios de aceptación en el texto de la historia de usuario.

5. Medible
Nos referimos aquí a la capacidad de medición del tamaño, utilizando específicamente el
punto de función COSMIC (CFP) como base para el dimensionamiento. Es un estándar
ISO maduro de segunda generación, adecuado para todo tipo de trabajo de software. Las
historias de usuarios solo se pueden medir si contienen expresiones claras de todos los
movimientos de datos que se necesitarán y medirán. La mensurabilidad ayuda
significativamente tanto con la planificación como con el aseguramiento de la calidad. El
tamaño funcional no es el único atributo medible de una historia de usuario, sin embargo,
es uno de los más importantes dado que se relaciona con el esfuerzo de construirlo.

Sugerencia: No medir el tamaño agrega incertidumbre a tu trabajo de software.

6. Consistente

Usa palabras coherentes tanto para tipos_de_usuarios como para tipos_de_objetos en un

conjunto de historias de usuarios. La nomenclatura coherente reducirá la confusión, los
defectos, la repetición del trabajo y el desperdicio. Los sistemas complejos y los entornos
con mucha jerga tienden a ser propensos a que los miembros del equipo le den diferentes
términos al mismo usuario u objeto.

7. Completa

La falta de requisitos es una de las mayores causas de fallas en los proyectos de software.
La mayoría de los proyectos crecen en tamaño a medida que se hacen evidentes las
necesidades adicionales. Este aumento en el alcance conduce a más trabajo, más
reelaboración, cronogramas extendidos, sobrecostos presupuestarios y, en algunos casos,
fallas en el proyecto. Aunque el enfoque Agile desalienta el trabajo inicial excesivo, es
esencial un trabajo de alcance inicial. Busca cuidadosamente los requisitos que faltan
cuando escribas historias de usuario.

8. Único

Todos los requisitos deben ser únicos. Los requisitos duplicados son un problema que
tiende a ser más frecuente en proyectos más grandes.

9. Valioso

Todas las historias de usuario deben ser valiosas para el "negocio". Es apropiado desafiar el
valor y la importancia de cada historia de usuario, de modo que solo se entregue la
funcionalidad más importante. Si no se puede rastrear una historia de usuario hasta la
entrega de un resultado comercial medible, es posible que no sea valiosa y tal vez deba
excluirse del alcance. El valor financiero real de la historia puede ser difícil de medir,
utilizando el tamaño funcional (CFP) como base para el valor (especialmente para la
medición del valor ganado EVM).

10. Sin diseño

Las historias de usuario no deben hacer referencia a la tecnología utilizada para entregarlas.
Este nivel de detalle se puede incluir como complemento a la historia del usuario para
ayudar a proporcionar contexto sobre "cómo" se debe entregar. Esto es particularmente
adecuado para aspectos no funcionales de cómo se logrará la funcionalidad.

El lugar de una historia de usuario dentro de una épica

Historias, épicas e iniciativas

Estas estructuras simples ayudan a los equipos ágiles a gestionar con elegancia el alcance y
la estructura del trabajo.

Digamos que con su equipo quieren hacer algo ambicioso, como lanzar un cohete al
espacio. Para hacerlo, deberán estructurar el trabajo: desde los objetivos más grandes hasta
los detalles minuciosos. Querrán poder responder a los cambios, informar su progreso y
ceñirse a un plan. Épicas, historias e iniciativas son precisamente las herramientas que
necesitarás para hacerlo.

Al comprender cómo estas populares metodologías ágiles y DevOps ayudan a organizar el

trabajo, su equipo puede lograr un equilibrio saludable entre la estructura, la flexibilidad y
el lanzamiento de cohetes al espacio.

¿Qué son?

 Las historias, también llamadas "historias de usuarios", son requisitos breves o

solicitudes escritas desde la perspectiva de un usuario final.
 Las épicas son grandes cuerpos de trabajo que se pueden dividir en varias tareas
más pequeñas (llamadas historias).
 Las iniciativas son colecciones de épicas que conducen hacia un objetivo común.

Épica ágil vs. historia

En cierto sentido, las historias y épicas en ágil son similares a las historias y épicas en el
cine o la literatura. Una historia es una narración simple; una serie de historias relacionadas
e interdependientes constituye una épica. Lo mismo ocurre con la gestión de su trabajo,
donde la finalización de historias relacionadas conduce a la finalización de una épica. Las
historias cuentan el arco del trabajo completado, mientras que la épica comparte una visión
de alto nivel del objetivo unificador.

En un equipo ágil, las historias son algo que el equipo puede comprometerse a terminar en
un sprint de una o dos semanas. A menudo, los desarrolladores trabajaban en docenas de
historias al mes. Las épicas, por el contrario, son pocas y tardan más en completarse. Los
equipos a menudo tienen dos o tres épicas en las que trabajan para completar cada
trimestre.

Si su empresa estaba lanzando cohetes al espacio y deseaba mejorar el servicio de

transmisión para sus lanzamientos, podría estructurar sus historias como las siguientes.

Organizar el trabajo en historias y épicas también les ayuda a usted y a su equipo a

comunicarse de manera efectiva dentro de la organización. Si estuviera informando el
progreso de su equipo al jefe de Ingeniería, estaría hablando en épicas. Si estuviera
hablando con un colega en su equipo de desarrollo, hablaría a nivel de historia.

Ágil Épica vs Iniciativa

Así como las épicas se componen de historias, las iniciativas se componen de épicas. Las
iniciativas ofrecen otro nivel de organización por encima de las épicas. En muchos casos,
una iniciativa compila épicas de varios equipos para lograr un objetivo mucho más amplio
y más grande que cualquiera de las épicas en sí. Si bien una épica es algo que puede
completar en un mes o un trimestre, las iniciativas a menudo se completan en varios
trimestres o un año.
 10
¿Qué es un caso de prueba?
Los casos de prueba definen cómo probar un sistema, software o una aplicación. Un caso
de prueba es un conjunto singular de acciones o instrucciones que debe realizar un tester
que valida un aspecto específico de la funcionalidad de un producto o aplicación. Si la
prueba falla, el resultado podría ser un defecto de software que la organización puede
clasificar para arreglar.

Un tester o profesional de control de calidad generalmente escribe casos de prueba que se

ejecutan después de completar una característica o el grupo de características que
componen la versión. Los casos de prueba también confirman si el producto cumple con los
requisitos de software.

Un grupo de casos de prueba se organiza en un conjunto de pruebas, que prueba un

segmento lógico de la aplicación, como una característica específica.

Caso de prueba vs términos similares

Un caso de prueba es un concepto básico en las pruebas de software, pero existen términos
similares que pueden causar confusión a los principiantes o a las personas menos
familiarizadas con el control de calidad. Explicaremos qué es un caso de prueba, en
relación con otros términos técnicos o con nombres similares.

Caso de prueba vs escenario de prueba

Como su nombre lo indica, un escenario de prueba describe una situación o funcionalidad

que requiere pruebas. Por ejemplo, un escenario de prueba podría ser: "Verificar la
funcionalidad de inicio de sesión". Los escenarios de prueba suelen tener sus propios
números de identificación para el seguimiento. Los equipos de control de calidad a menudo
derivan casos de prueba (acciones de bajo nivel) a partir de escenarios de prueba (acciones
de alto nivel); y los escenarios de prueba generalmente provienen de la documentación de
requisitos comerciales y de software.

Caso de prueba vs script de prueba

Estos términos son esencialmente intercambiables. Tanto un caso de prueba como un script
de prueba describen una serie de acciones que prueban un elemento de la funcionalidad del
software.

¡Advertencia! Un script de prueba se usa a menudo en el contexto de la automatización de

pruebas, en el que una máquina realiza las pruebas. Por lo tanto, en un contexto de
automatización, un desarrollador debe escribir un script de prueba para que sea legible por
una máquina, mientras que un caso de prueba sería interpretado por un ser humano para la
prueba manual.
Caso de prueba vs plan de prueba

Un caso de prueba cubre una situación de prueba particular o una parte específica de la
funcionalidad del producto. Un plan de prueba es un documento mucho más completo que
cubre todos los aspectos de las pruebas de software inminentes. El propósito del plan de
prueba es alinear las expectativas de toda la organización sobre lo que ocurrirá durante la
prueba, incluido el alcance del proyecto, los objetivos, las fechas de inicio y finalización,
las funciones y responsabilidades, los entregables y la mitigación de defectos.

Caso de prueba vs caso de uso

Un caso de uso describe cómo un sistema realizará una tarea bajo ciertas condiciones. La
documentación de requisitos comerciales o de software describe los casos de uso, que
detallan cómo el usuario final interactuará con el sistema y el resultado que debe recibir.
Los casos de uso describen cómo debería funcionar el producto, mientras que los casos de
prueba describen cómo se debe probar el producto. Los casos de prueba se derivan de los
casos de uso para garantizar que el producto se pruebe a fondo.

¿Por qué son importantes los casos de prueba?

Los casos de prueba definen lo que se debe hacer para probar un sistema, incluidos los
pasos ejecutados en el sistema, los valores de datos de entrada que se ingresan en el sistema
y los resultados que se esperan durante la ejecución del caso de prueba. El uso de casos de
prueba permite a los desarrolladores y testers descubrir errores que pueden haber ocurrido
durante el desarrollo o defectos que se pasaron por alto durante las pruebas ad hoc.

Los beneficios de un caso de prueba efectivo incluyen:

 Buena cobertura de prueba garantizada.

 Costos reducidos de mantenimiento y soporte de software.
 Casos de prueba reutilizables.
 Confirmación de que el software satisfaga los requisitos del usuario final.
 Mejora de la calidad del software y la experiencia del usuario.
 Los productos de mayor calidad conducen a clientes más satisfechos.
 Más clientes satisfechos aumentarán las ganancias de la empresa.

En general, escribir y usar casos de prueba conducirá a la optimización del negocio. Los
clientes están más satisfechos, aumenta la retención de clientes, disminuyen los costos de
servicio al cliente y reparación de productos, y se producen productos más confiables, lo
que mejora la reputación y la imagen de marca de la empresa.

Tipos de casos de prueba

Para validar y verificar la funcionalidad del sistema, la organización debe adoptar un
enfoque multifacético que evalúe la parte delantera y trasera del producto. Hay diferentes
formas de categorizar los distintos tipos de casos de prueba.
Casos de prueba formales

Con estos tipos de casos de prueba, el tester escribe una prueba en la que todas las entradas
son conocidas y detalladas, como las condiciones previas y los datos de prueba. Las
pruebas formales tienen una entrada predefinida, lo que significa que proporcionan una
salida esperada, que la prueba intenta validar.

Casos de prueba informales

Estos no tienen entradas o salidas conocidas. Los testers ejecutan este tipo de casos de
prueba para descubrir y registrar los resultados, lo que puede revelar hallazgos interesantes
sobre la calidad digital.

La mayoría de los tipos de casos de prueba son formales, planificados con anticipación de
acuerdo con los requisitos del software. Exploremos algunos tipos y ejemplos de casos de
prueba más:

Imagen 10.1: 8 tipos de casos de prueba. Fuente: elaboración propia.

Casos de prueba de funcionalidad:

Estas pruebas determinan si la funcionalidad de destino tiene éxito o no al realizar su

función dentro del sistema. El equipo de control de calidad escribe estos tipos de casos de
prueba en función de los requisitos y los ejecuta cuando el equipo de desarrollo termina con
la función. Muchos tipos diferentes de pruebas funcionales pueden validar la funcionalidad
de la aplicación, incluidas las pruebas unitarias que verifican los segmentos de
funcionalidad aislados más pequeños posibles. Los casos de prueba funcionales deben
incluir:
  una descripción y/o nombre de la función bajo prueba
 condiciones previas
 pasos para la prueba
 un resultado esperado

Casos de prueba de IU:

Estas pruebas confirman que la interfaz de usuario (con lo que interactúa el usuario final)
funciona como se esperaba. Por lo general, las pruebas de IU se enfocan en los elementos
visuales de una aplicación o página web para confirmar que funcionan y se desempeñan de
acuerdo con los requisitos. Las pruebas de IU a menudo examinan elementos de
visualización como menús, submenús, botones, tablas y columnas para asegurarse de que
sean legibles y consistentes.

Las interfaces de usuario siguen evolucionando. Por esta razón, las pruebas de IU también
pueden significar validar una interfaz de voz o video. Las pruebas de IU también deben
incluir problemas de accesibilidad, como si un lector de pantalla puede identificar un botón
en una página.

Casos de prueba de rendimiento:

Las pruebas funcionales comprueban si la aplicación funciona. Las pruebas no funcionales,

como las pruebas de rendimiento, comprueban el rendimiento de la aplicación en diferentes
tipos de cargas de trabajo. Una prueba de rendimiento debe ser específica con cada paso y
resultado esperado documentados, así como datos de entrada claramente definidos, para
que el tester pueda evaluar con precisión cómo funciona el sistema en las condiciones
dadas.

Hay una variedad de tipos de pruebas de rendimiento, incluidas pruebas de carga, tensión,
picos y escalabilidad. Cada tipo de prueba de rendimiento, y cada prueba individual, revela
información diferente sobre cómo responde el sistema a las distintas cargas de usuarios.

Casos de prueba de integración:

Estos tipos de casos de prueba evalúan cómo funciona la funcionalidad combinada cuando
se fusiona con la aplicación. Si bien es importante probar unidades individuales de
software, es igualmente importante asegurarse de que los sistemas dispares puedan
comunicarse entre sí de manera efectiva. El tester debe comprender bien los flujos de la
aplicación para escribir pruebas de integración efectivas.

Las pruebas de API son un aspecto de las pruebas de integración. Las aplicaciones se
comunican entre sí a través de las API, especialmente a medida que los productos se
interconectan más en el mundo centrado en dispositivos móviles de hoy. Las pruebas de
API son un ejercicio vital para cubrir con casos de prueba de integración.
Casos de prueba de usabilidad:

En lugar de probar la funcionalidad o el rendimiento de la aplicación, las pruebas de

usabilidad examinan lo que los posibles usuarios finales, no los testers, piensan de un
producto. Los investigadores de UX preparan pruebas para participantes fuera de la
organización para medir qué tan fácil o difícil es usar el producto.

Las organizaciones pueden realizar pruebas de usabilidad de varias maneras, incluidas

moderadas o no moderadas, remotas o en persona. El objetivo es aprovechar la perspectiva
de un usuario final para identificar puntos en la aplicación que harían que dejara de usarla.
Las pruebas de usabilidad pueden ser formales o informales, según el objetivo y el método
UX de investigación.

Casos de prueba de bases de datos:

El hecho de que la funcionalidad de una aplicación, la interfaz de usuario y las API

funcionen no significa que los datos se almacenen correctamente. Las pruebas de la base de
datos validan si los datos de la aplicación se almacenan de acuerdo con los requisitos y las
reglamentaciones. Al igual que las pruebas de funcionalidad, las pruebas de bases de datos
pueden variar en alcance, desde la validación de un pequeño objeto de base de datos hasta
una acción compleja que involucra múltiples partes de la aplicación.

Algunos criterios que las pruebas de la base de datos pueden evaluar incluyen si los datos
se almacenan de manera consistente, si personas no autorizadas pueden acceder a ellos y
cómo se almacenan localmente en un dispositivo. Los datos consistentes y seguros deben
ser una prioridad para todas las empresas, independientemente de los estándares de
cumplimiento de la industria; las pruebas de bases de datos ayudan a lograrlo.

Casos de prueba de seguridad:

Estas pruebas identifican vulnerabilidades dentro de un sistema o producto. Otro tipo de

prueba no funcional, las pruebas de seguridad tienen como objetivo encontrar formas de
proteger mejor los activos de software, así como identificar cómo el sistema resiste los
tipos comunes de ataques y definir el riesgo asociado con el producto.

Algunas pruebas de seguridad pueden incluir análisis de vulnerabilidades, análisis de

configuración y pruebas de penetración, también llamadas pruebas intrusivas. En última
instancia, el objetivo de las pruebas de seguridad es generar comentarios procesables que la
organización pueda usar para remediar las vulnerabilidades.

Casos de prueba de aceptación del usuario:

Estos tipos de casos de prueba validan el producto desde la perspectiva del usuario final.
Un usuario final o cliente realiza pruebas de aceptación del usuario en un entorno de prueba
para validar el flujo de extremo a extremo del producto.

Las pruebas de aceptación del usuario pueden ser útiles cuando los requisitos comerciales
cambian durante el curso del desarrollo. Las partes interesadas no siempre comunican de
manera efectiva estos cambios al equipo de desarrollo. A través de los casos de prueba
UAT, la organización puede documentar los criterios de entrada y salida que cubren las
lagunas en las pruebas anteriores.

Casos de prueba exploratorios:

Estos casos de prueba informales ocurren cuando el tester evalúa el sistema de forma ad-
hoc para intentar descubrir defectos que no se detectaron en las pruebas estructuradas. Si
bien las pruebas exploratorias no están definidas por un conjunto prescrito de acciones, el
enfoque aún requiere cierta estructura, particularmente en lo que respecta a la
documentación de resultados y el calendario, para garantizar una retroalimentación
efectiva.

Las pruebas exploratorias pueden ayudar a validar los requisitos al verificar el sistema de
maneras no cubiertas en las pruebas con guión. Las pruebas exploratorias permiten que la
organización de control de calidad sea adaptable y aprenda de las lagunas en la cobertura de
las pruebas.

Resultados del caso de prueba

Si bien los objetivos de los casos de prueba varían, la mayoría de los casos formales tienen
resultados predecibles. De hecho, el formato de caso de prueba típico debe detallar el
resultado esperado y el resultado real, que la prueba misma valida. La mayoría de los
resultados de los casos de prueba entran en estas categorías:

 aprobado
 fallo
 sin ejecutar
 obstruido

Las pruebas de aprobación y falla indican que el sistema logra lo que se supone que debe
hacer o falla en ese intento. Estos resultados no deben confundirse con las pruebas
diseñadas para ser positivas o negativas, que pueden pasar o fallar. Las pruebas positivas
aseguran que los usuarios puedan seguir todos los pasos y pasar el resultado esperado
cuando la entrada es correcta, como una transferencia de dinero exitosa entre cuentas
cuando hay un saldo superior a $0. Las pruebas negativas aseguran que el sistema maneja
correctamente las entradas no válidas, como no permitir el inicio de sesión si la contraseña
es incorrecta. Ambos tipos de pruebas pasan o fallan dependiendo del resultado esperado.

Los resultados de las pruebas que se marcan como no ejecutados son, como sugiere el
nombre, pruebas que aún no se han ejecutado o que no se ejecutarán como parte de esta
ronda de pruebas. Las pruebas bloqueadas resultan de una circunstancia externa o
condición previa que inhibe la ejecución de la prueba. Por ejemplo, una falla del sistema
que impide que la funcionalidad esté disponible provocará una prueba bloqueada, al igual
que un entorno de prueba configurado incorrectamente.
¿Cuándo tenemos que empezar a construir casos de prueba?

Lo antes posible, empezando la planificación de un “testing básico” generando casos de

prueba junto con la especificación de requerimientos. Esto se debe a que los casos de
prueba NO deben estar influenciados por las estrategias de solución que hemos de elegir
sino por la especificación del problema.

¿Qué casos debo testear?

Idealmente uno querría probar absolutamente todas las posibles combinaciones de datos y
situaciones. Esto se hace normalmente imposible debido a la cantidad de casos que
deberíamos generar. Lo que se hace comúnmente es reconocer las situaciones que creemos
son más extremas y algunas de las más comunes. Este proceso debe ser planificado y
documentado.

Cada caso de prueba cuesta dinero: esfuerzo para generarlo, tiempo para prepararlo y
ejecutarlo, esfuerzo para evaluar los resultados y hacer seguimiento en el caso de hallar
errores, teniendo que volver a probarlo y reportar. Por lo tanto, el número de casos de
prueba necesarios para detectar los errores debe ser minimizado para reducir costos.

Perseguimos dos premisas al crear casos de prueba:

 Los casos de prueba deben ser finitos, cuantos menos y mejor diseñados, es mejor.
 Los casos de prueba buscan errores, queremos el menor número de casos de prueba
que encuentre la cantidad máxima de errores

Formato de caso de prueba

La documentación del caso de prueba generalmente incluye toda la información pertinente

para ejecutar y recopilar datos de la prueba. Si bien el formato de caso de prueba específico
puede diferir entre organizaciones, la mayoría incluye los siguientes detalles:

 Nombre del módulo. Este es el módulo o característica bajo prueba.

 Identificación y/o nombre de la prueba. Este es un identificador único que debe
seguir una convención de nomenclatura estándar.
 Nombre del tester. La persona que realiza la prueba.
 Datos de prueba. Esto describe los conjuntos de datos que se utilizarán para la
prueba.
 Supuestos o condiciones previas. Describa los diversos pasos que se deben realizar
antes de la prueba, o lo que podemos suponer situacionalmente sobre la prueba,
como "después de un inicio de sesión exitoso".
 Prioridad de prueba. Defina si la prueba es de prioridad baja, media o alta.
 Escenarios de prueba. Como se describió anteriormente, esta es la acción de alto
nivel de la que se deriva el caso de prueba.
 Entorno de prueba. Identificar el nombre y/o las características del entorno de
prueba.
 Pasos de prueba. Detalle los pasos que debe seguir el tester en el orden deseado.
 Resultados previstos. Esta es la salida que espera recibir del sistema.
  Resultados actuales. Esta es la salida que realmente recibe del sistema.
 Determinación de pasa/falla. Si los resultados reales coinciden con los resultados
esperados, la prueba pasa. Si no, la prueba falla.

Al seguir el formato de caso de prueba anterior, la organización puede adherirse a una

forma estándar de escribir pruebas, lo que resulta útil durante el mantenimiento. La
organización debe revisar, mantener y aprobar regularmente los casos de prueba para
garantizar que cubran adecuadamente la funcionalidad nueva y antigua. Los casos de
prueba completamente detallados reducen la necesidad de pruebas exploratorias que
requieren mucho tiempo para llenar los vacíos de cobertura.

Modelo

ID El ID se le da al caso de prueba.

Descripción La descripción del caso de prueba.

Requisito El ID se proporciona al requisito al que se asigna este caso de

relacionado prueba.

Requisitos previos Cualquier condición previa o requisito que debe cumplirse antes de
ejecutar la prueba.

Pasos de la prueba Se dieron instrucciones paso a paso para ejecutar la prueba.

Datos de prueba Datos que se utilizan mientras se realiza la prueba.

Resultado esperado El resultado que se espera de la prueba, registrado antes de ejecutar

la prueba.

Resultado real El resultado real obtenido después de ejecutar la prueba

Estado El estado obtenido después de ejecutar la prueba. Puede ser Pasa,

Falla, No Ejecutado, Bloqueado.
 Comentarios Cualquier comentario que se haga para la prueba.

Información del Incluye información de red/hardware/software en la que se ejecuta

entorno la prueba.

Formato de elaboración de casos de prueba

Veremos 3 (tres) formatos para elaborar casos de prueba:

1. Paso a paso. Este formato se utiliza en:

 La mayoría de las reglas de procesamiento
 Casos de prueba únicos y diferentes
 Interfaces GUI
 Escenarios de movimiento en interfaces diferentes
 Entradas y salidas complicadas para representar en matrices.

Escribir casos de prueba de manera eficiente

Los casos de prueba bien escritos tienen beneficios obvios: productos de mejor calidad,
clientes más felices, mayores ganancias y un mantenimiento de prueba más fácil. Pero se
requiere de esfuerzo y organización para redactar casos de prueba que cooperen para lograr
estos objetivos.

En general, el tester debe escribir casos de prueba al principio del SDLC, como durante la
fase de recopilación de requisitos. Los testers deben consultar los requisitos y la
documentación de casos de uso, así como el plan de prueba general cuando escriben casos
de prueba. Un prototipo también puede informar al tester sobre cómo se verá la
característica o funcionalidad cuando se complete.

Una vez que el tester tiene toda esta información, puede comenzar a escribir los diversos
tipos de casos de prueba mencionados anteriormente. Al escribir casos de prueba, el tester
debe considerar los flujos de la aplicación: la forma en que el usuario llega a la
funcionalidad de la aplicación es un elemento importante de su viaje y debe validarse
adecuadamente. Por ejemplo, los cambios en la configuración de la cuenta deben funcionar
correctamente en una aplicación móvil, que puede ser el flujo principal, pero también deben
funcionar en un navegador web, así como en cualquier otro lugar donde los usuarios
puedan interactuar o cambiar la configuración.

Un diseño de caso de prueba efectivo será:

 Exacto o específico sobre el propósito.

 Económico: no se utilizan pasos ni palabras innecesarias.
  Rastreable: los requisitos se pueden rastrear.
 Repetible: el documento se puede utilizar para realizar la prueba varias veces.
 Reutilizable: el documento se puede reutilizar para volver a realizar la prueba con
éxito en el futuro.

Para lograr estos objetivos, los ingenieros de pruebas y control de calidad pueden utilizar
las siguientes prácticas recomendadas:

a. Priorizar qué casos de prueba escribir en función de los plazos del proyecto y los
factores de riesgo del sistema o la aplicación.
b. Crear casos de prueba únicos y evitar casos de prueba irrelevantes o duplicados.
c. Confirmar que el conjunto de pruebas verifica todos los requisitos especificados
mencionados en el documento de especificación.
d. Escribir casos de prueba que sean transparentes y directos. El título de cada caso de
prueba debe ser corto.
e. Los pasos del caso de prueba deben dividirse en los segmentos más pequeños
posibles para evitar confusiones durante la ejecución.
f. Los casos de prueba deben escribirse de manera que permitan que otros los
entiendan fácilmente y modifiquen el documento cuando sea necesario.
g. Ten en cuenta al usuario final siempre que se cree un caso de prueba.
h. No asumir las características y la funcionalidad del sistema.
i. Cada caso de prueba debe ser fácilmente identificable.
j. Las descripciones deben ser claras y concisas.

k. Buenas prácticas para elaborar casos de prueba

La mejor práctica es desarrollar por lo menos dos casos de prueba para cada requerimiento
a probar. A medida que se va conociendo el negocio y teniendo más experiencia en el
testing, se va estimando mejor la cantidad de casos de prueba necesarios. Por ejemplo, para
testear correcta y completamente un Login, requiere de 7 casos de prueba.

Los casos de prueba deben ser simples: se deben crear casos de prueba que sean lo más
simple posible ya que otra persona que no sea el autor puede ejecutarlos. Usa un lenguaje
asertivo como “ir a la página de inicio”, “ingresar datos”, “hacer clic en esto”, etc. Esto
facilita la comprensión de los pasos de prueba y hace que la ejecución sea más rápida.

El título debe ser fuerte: la manera correcta de comenzar con el título de un caso de prueba
es con un verbo en infinitivo. Los verbos en infinitivo denotan un mandato.

Tomar al usuario final en cuenta: el objetivo final es crear casos de prueba que cumplan
con los requisitos del cliente y que sean fáciles de usar. Un tester debe crear casos de
prueba tomando en cuenta la perspectiva del usuario final.

Evitar la repetición de casos de prueba: si se necesita un caso de prueba para ejecutar

algún otro, llama al caso de prueba por su id. Inclúyelo en la columna de pre-condiciones o
donde corresponda dependiendo la herramienta.
 No asumir: No asumir la funcionalidad y las características de la aplicación mientras
preparas el caso de prueba. Apégate a los documentos de especificación y si tienes alguna
duda, pregunta.

Asegurar la mayor cobertura posible: Asegúrate de escribir casos de prueba para todos los
requisitos especificados. Algo que se puede utilizar es una matriz de trazabilidad para
garantizar que se prueben todos los casos de pruebas asociados. La mayoría de las
herramientas permiten vincular los casos de prueba entre sí.

Autonomía: el caso de prueba debe generar los mismos resultados cada vez, sin importar
quién lo pruebe.

Implementar técnicas de prueba: no es posible verificar todas las condiciones posibles de

una aplicación, pero las técnicas de prueba ayudan a seleccionar los casos de prueba con la
máxima posibilidad de encontrar un defecto.

Mantener un repositorio estándar de casos de prueba reutilizables para su aplicación

garantizará que la mayoría de los errores comunes se detecten más rápidamente. La
reutilización de los casos de prueba ayuda a ahorrar dinero en recursos para escribir
pruebas repetitivas. Siempre se cubrirán casos de prueba importantes, por lo que será casi
imposible olvidarlos.

Una lista de verificación ayuda a completar la redacción de casos de prueba rápidamente

para nuevas versiones de la aplicación. Los casos de prueba se pueden consultar en la lista
de verificación de pruebas para asegurarse de que los problemas más comunes se
solucionen en la fase de desarrollo.

Definir la prioridad de una prueba. Generalmente es mejor utilizar cualquiera de los 3

niveles, alto, medio y bajo, o 1, 50 y 100. Por lo tanto, cuando tengas un cronograma,
primero debes completar todas las pruebas de alta prioridad y luego pasar a las pruebas de
prioridad media y baja. Para identificar estos niveles se debe conocer bien el negocio y la
importancia de los niveles de error para el usuario.

La forma de escribir pruebas y casos de prueba eficaces se puede optimizar con el tiempo.
Algunas de las mejores prácticas incluyen el uso de títulos sólidos, descripciones sólidas y
mantener el lenguaje conciso y claro. Pero también querrá incluir condiciones previas,
suposiciones y los resultados esperados.

Toda esta información es relevante para el tester de software, especialmente cuando se

determina si el caso de prueba es un "pasó" o un "error" en su lugar.

Como sabes, si se trata de una aplicación web, los resultados de la prueba pueden diferir
según el navegador en el que se ejecute la prueba. Para la facilidad de otros evaluadores,
desarrolladores o quien esté revisando el documento de prueba, debe agregar el nombre y la
versión del navegador al caso para que el defecto se pueda replicar fácilmente.
Mantén las cosas simples y transparentes, pero no demasiado simples, hazlo complejo, pero
no demasiado complejo: mantén todos los pasos de los casos de prueba atómicos y
precisos. El caso de prueba debe ser auto explicativo y fácil de entender.

La revisión por pares es importante, revisando los más seniors las pruebas de otros testers
más juniors para mejorarlos. Este no solo es un momento de verificación y validación, sino
también de aprendizaje continuo. Es importante que quien revise tenga conocimientos de
testing y del negocio. Es una práctica muy importante y que se aplica muy seguido.

Especifica los resultados esperados y los supuestos antes de ejecutar los casos de pruebas.
Recuerda que muchas veces se supone que hay, por ejemplo, datos cargados para poder
correr un caso de prueba, y muchas veces no están cargados o fueron pisados por otra
versión de la base de datos o porque alguien los utilizó para probar.

Factores de calidad de los casos de prueba

Un caso de prueba debe cumplir con los siguientes factores de calidad:

1. Correcto. Ser apropiado para los probadores y el entorno. Si teóricamente es

razonable, pero exige algo que ninguno de los probadores tiene, se caerá por su
propio peso.
2. Exacto. Demostrar que su descripción se puede probar.
3. Económico. Tener sólo los pasos o los campos necesarios para su propósito.
4. Confiable y repetible. Ser un experimento controlado con el que se obtiene el
mismo resultado cada vez que se ejecuta, sin importar qué se pruebe.
5. Rastreable. Saber qué requisitos del caso de uso se prueban.
6. Medible. Este es un ejercicio muy útil para quienes escriben pruebas, para verificar
constantemente dónde están, si pierden alguno de los elementos, o si no se cumple
un estándar.

Gestión de casos de prueba

Una forma de asegurarse de que los casos de prueba sean fáciles de localizar y comprender
es revisarlos minuciosamente. Los casos de prueba requieren coherencia en las
convenciones de nomenclatura y las descripciones. Una verificación de cordura también
puede revelar si la descripción "simple" del escritor de los pasos de la prueba realmente
tiene sentido para otro lector y si refleja las condiciones del mundo real.

A medida que aumenta el alcance de un producto, también lo hace la huella de sus casos de
prueba. En pocas palabras, cuanto más desarrolle, más necesitará probar, lo que puede
generar desafíos cuando se trata de escalar conjuntos de pruebas. Los casos de prueba no
solo tienen que mantenerse al día con la nueva funcionalidad, sino que la necesidad de
realizar pruebas de regresión significa que los casos de prueba más antiguos también
necesitan actualizaciones.

Las herramientas o productos de administración de pruebas pueden ayudar a las

organizaciones a rastrear y actualizar las pruebas según sea necesario. Hay muchas
opciones para las herramientas de gestión de pruebas. En última instancia, la mejor opción
es la que se adapta de la mejor manera posible a sus flujos de trabajo, lo que permite al
equipo ver, comentar y acceder a los registros de auditoría.

La generación de informes es otro elemento importante de la gestión de casos de prueba.

Los informes de casos de prueba deben brindarle al equipo información procesable sobre
cómo se están realizando las pruebas, qué cobertura tiene y dónde puede mejorar el equipo
en el futuro.

Si bien puede ser desalentador administrar conjuntos de pruebas, en última instancia, es una
tarea necesaria para mantener la calidad digital de sus productos. Si la tarea es difícil de
mantener internamente, busque herramientas o servicios que le ayuden a mantenerse al día.

¿Cómo convertir historias de usuarios en casos de prueba?

La siguiente es una plantilla de muestra que incluye una historia de usuario, una prueba de
aceptación y un caso de prueba:

Historia del usuario:

Como [función de usuario],
Necesito [la capacidad de hacer algo],
para que pueda [obtener algún beneficio o evitar alguna consecuencia]
Criterios de aceptación/Prueba:
Dado [entrada | condiciones previas],
cuando [acciones | disparadores],
entonces [salida | Consecuencias].
Caso de prueba:
ID de TC [id/número único]
Resumen [objetivo]
Requisitos previos [condiciones previas que deben cumplirse para llevar a cabo más pasos]
Procedimiento de prueba [procedimiento paso a paso para la ejecución]

Resultados esperados y reales

Una historia de usuario promueve más discusiones y colaboración dentro del equipo. Los
criterios de aceptación definen límites y requisitos. Los siguientes son los pasos clave
involucrados en la creación de criterios de prueba en un modelo Agile:

1. La empresa proporciona requisitos y criterios de aceptación para una historia de

usuario.
 2. El control de calidad revisa las consultas y extrae los casos de prueba existentes. Se
crean nuevos casos de prueba basados en las áreas funcionales.
3. Los ingenieros controlan los escenarios que afectan el flujo de trabajo comercial en
caso de que no se capturen en la historia del usuario.
4. QA proporciona una sesión a los analistas de negocios para implementar cambios en
las primeras etapas.
5. Mientras redactan los casos de prueba, los equipos de control de calidad visualizan
el flujo de trabajo para que toda la cobertura del camino feliz o escenario positivo,
el análisis de límites y los escenarios negativos puedan cubrirse de una manera bien
estipulada.

 Escenario positivo: el escenario positivo (Happy Path) prueba los requisitos básicos
de una aplicación. Si el resultado de Happy Path es un fracaso, entonces el resto de
las pruebas pueden bloquearse debido a defectos críticos.
 Escenarios negativos: prueba los escenarios negativos para ver cómo se comporta el
sistema en caso de entradas inapropiadas.
 Escenario de regresión: verifica algunos elementos estándar, como encabezados,
pies de página, opciones de menú estándar, hipervínculo y escenarios
interrelacionados. Estos escenarios de prueba lo ayudarán a realizar pruebas de
regresión.
 Análisis de límites: prueba las condiciones de límites para verificar que el sistema
se comporte correctamente en los límites mínimo y máximo sin ningún
comportamiento abrupto.
 Escenario de integración: realizar pruebas de integración es necesario cuando un
proyecto tiene varios módulos pero los cambios se realizan en un solo módulo,
verifica si la funcionalidad está funcionando entre todos los módulos
colectivamente.

Analogía entre una historia de usuario y su caso de prueba:

 11

Paso a paso
Ahora veremos paso a paso cómo debemos realizar un plan de pruebas. Los datos
necesarios para identificar y armar cada caso de prueba incluye diversa información, que
vimos anteriormente pero volveremos a repasar aquellas más relevantes:

Identificador: Identificador único para el caso de prueba. Es el código con el objetivo de

vincular, por ejemplo, un informe de errores al caso de prueba en el cual ha sido detectado.

Conjunto de prueba: Identificador de los conjuntos de prueba donde el caso de prueba es

usado.

Nombre de la Funcionalidad: Funcionalidad del IP (Inventario de Prueba) que se testea

con este caso de prueba.

Prioridad: Prioridad asignada al caso de prueba, por ejemplo: 1- alta, 2- media, 3-baja.

Requisitos: características del objeto de pruebas que el caso de prueba debe evaluar.

Necesidades de ambientes: si bien no es un requisito obligatorio, debe saberse e indicarse

en qué ambiente se van a correr las pruebas. Lo ideal es que haya un ambiente separado de
Testing y exclusivo para correr las pruebas, para no ser afectado por que se esté
actualizando el código, como ser en el ambiente de desarrollo o por que estén realizando
otras pruebas como puede ser en los ambientes de pre-producción donde el cliente prueba
 para dar su aceptación o en un ambiente de pruebas de automatización donde se pueden
afectar los resultados por el uso de dicho ambiente.

Situación: puede haber un caso en el que esté probando una aplicación, un desarrollador
esté realizando modificaciones en paralelo a la misma aplicación o alguien pueda actualizar
la aplicación después de que termine la prueba. Esto conduce a una situación en la que los
resultados de su prueba pueden variar con el tiempo.

Por lo tanto, siempre es mejor agregar una marca de tiempo con el nombre del evaluador en
los comentarios de la prueba para que el resultado de una prueba (aprobado o reprobado) se
pueda atribuir al estado de una aplicación en ese momento en particular. Alternativamente,
puede tener una columna 'Fecha de ejecución' agregada por separado al caso de prueba
que identificará explícitamente la marca de tiempo de la prueba.

HW: Lista de Hardware requerido para ejecutar el caso de prueba.

SW: Lista de Software requerido para ejecutar el caso de prueba.

Configuración (setup): Lista de pasos necesarios para comenzar las pruebas.

Retroceder acciones (cleanup): Lista de pasos necesarios para retroceder al estado previo a
la prueba.

Precondiciones: situación inicial o previa a la ejecución de pruebas o características de

Explicación de la acción que se hará con los datos de la situación inicial. Por ejemplo: dar
de alta un elemento, agregar un elemento a una lista.

Resultado esperado: Especificación del resultado esperado de ejecutar las pruebas.

Dependencias (si hay): orden de ejecución de casos de prueba, razón de las dependencias.

Valores de entrada: descripción de los datos de entrada de un objeto de pruebas. Puede ser
un dibujo o un texto explicando los datos con los que se probará el caso. Debe ser claro y
no dejar dudas.

Los siguientes datos se completan una vez que el caso de prueba se ejecutó:

 Resultado real: Especificación de lo que realmente ocurrió: Pasó/Falló/No se pudo

ejecutar
 Post-caso de prueba condiciones: características de un objeto de prueba tras la
ejecución de pruebas, descripción de su situación tras la ejecución de las
pruebas. Puede ser un dibujo o texto explicando cómo se espera que los datos
iniciales queden luego de ejecutar la acción. Debe ser claro y no dejar dudas.

Ejemplo
 · Identificador: 1
· Nombre: Alta de elemento al final de una lista ordenada
· Situación inicial: Lista:(3 → 5 → 7 → 15)
· Acción: Agregar a la lista el elemento 18
· Resultado esperado: Lista: (3 → 5 → 7 → 15 → 18)

 Duración: Tiempo reloj en ejecutar el caso de prueba.

 Esfuerzo: Horas-Persona requeridas para configurar y ejecutar el caso de prueba.
 Fecha: Fecha en la que se realizó la prueba.
 Identificación del Defecto: En caso de que la prueba falle se debe identificar el
incidente reportado para su seguimiento.
 Versión: Identificador de la versión probada.
 Tester: Nombre del tester que ejecutó el caso de prueba.
 Evidencias: son los resultados que se adjuntan con foto/s de la/s pantallas con los
resultados (screenshot) y pueden ser también con los pasos realizados. También se
pueden realizar videos para mostrar el paso a paso y el resultado final.

Cada vez que se ejecuta un caso debe registrarse la información resultante para que quien
sea responsable del código probado, sepa si está correcto o se produjo algún error o
resultado no deseado.

Aquí se obtiene un resultado real de la ejecución del código que denominamos Resultado
Final de la Ejecución del Caso de Prueba.

Las ejecuciones de casos se agrupan en “Corridas” que se deben identificar para saber
cuándo (y a veces quién) realizó una ejecución.

Consideraciones respecto de las pruebas

El fundamento respecto a la Prueba de Software es que no se puede probar completamente
un sistema compuesto por varios programas, por lo que en el momento de realizar las
pruebas se deben tomar decisiones respecto a cómo se van a diseñar los casos de prueba.
Otro punto importante a tener en cuenta es la actitud que debe tener la persona que realiza
las pruebas.

La prueba exhaustiva requiere probar el comportamiento de un programa para todas las

combinaciones válidas e inválidas de entradas. Además, se debe probar esto en cada punto
donde se ingresan datos, bajo cada estado posible del programa en ese punto. Esto no es
posible, ya que el tiempo requerido y el costo es prohibitivo.

En un mundo ideal, desearíamos probar cada permutación posible de un programa. Incluso

un programa aparentemente simple puede tener centenares o millares de combinaciones
posibles de la entrada y de la salida. Crear los casos de prueba para todas estas
posibilidades no es económicamente factible. Este problema fundamental, tendrá
implicancias para la economía de las pruebas, suposiciones que el tester tendrá que hacer
sobre el programa y la manera en el cual los casos de prueba se diseñan.
El objetivo debe ser maximizar la producción de las pruebas, esto es, maximizar el número
de los errores encontrados por un número finito de los casos de prueba.

La forma en cómo se seleccionan los casos de prueba es una de las principales decisiones a
tomar, teniendo en cuenta las siguientes consideraciones:

Los casos de prueba deben ser revisados regularmente, escribiendo nuevas pruebas que
ejerciten diferentes partes del software, con el objetivo de encontrar más defectos

Otro aspecto que se debe considerar al realizar pruebas es decidir cuándo el programa falla
para un conjunto de datos de entrada, o sea, conocer cuál es la salida esperada del
programa. Este problema es conocido como el problema del oráculo.

Un oráculo es cualquier agente (humano o mecánico) que decide si un programa se

comportó correctamente en una prueba dada, y produce por consiguiente un veredicto de
"pasó" (pass) o de "falló" (fail).

Un oráculo es lo que nos dice qué resultado debemos esperar ante determinadas entradas y
condiciones de ejecución.

Básicamente es el mecanismo, ya sea manual o automático, de verificar si el

comportamiento del sistema es el deseado o no. Para esto, el oráculo deberá comparar el
valor esperado contra valor obtenido, el estado final esperado con el estado final alcanzado,
el tiempo de respuesta aceptable con el tiempo de respuesta obtenido, etc. Pueden ser:

 personas
 modelos
 Documentos
 productos similares
 normas o estándares

Existen diversas clases de oráculos, y la automatización del oráculo puede llegar a ser muy
compleja y costosa. El oráculo más común es el oráculo entrada/salida, que especifica la
salida esperada para una entrada específica. Si el programa hace exactamente lo que su
especificación dice que debe hacer y no hace nada más, entonces cumple con su
especificación.

No es razonable decir que un programa es correcto si cumple con su especificación, ya que

las especificaciones pueden tener errores.

En este punto es interesante reflexionar sobre algo a lo que se llama la Paradoja del
Pesticida: los insectos (bugs, refiriéndose a fallos) que sobreviven a un pesticida se hacen
más fuertes, y resistentes a ese pesticida. O sea, si diseñamos un conjunto de pruebas
probablemente ciertos bugs sobrevivan. Si luego diseñamos una técnica más completa y
llamémosle “exhaustiva”, entonces encontraremos más bugs, pero otros seguirán
sobreviviendo. Al fin de cuentas los que van quedando son los más duros de matar, y se
van haciendo resistentes a los distintos pesticidas.
Obtención de casos de prueba a partir de requisitos
El diseño de casos de prueba debe ser un proceso controlado.

Los casos de prueba pueden ser creados formal o informalmente, dependiendo de las
características del proyecto y la madurez del proceso en uso.

Cobertura de pruebas

Es una medida de calidad de las pruebas. Se definen cierto tipo de entidades sobre el
sistema, y luego se intenta cubrirlas con las pruebas. Es una forma de indicar cuándo
probamos suficiente, o para tomar ideas de qué otra cosa probar (pensando en aumentar la
cobertura elegida).

Trazabilidad
Las pruebas deben ser trazables: ¿qué casos de prueba han sido incluido en el catálogo o
listado de pruebas, basados en qué requisitos?

Las consecuencias de los cambios en los requisitos sobre las pruebas a realizar pueden ser
identificadas directamente.

La trazabilidad también ayuda a determinar la cobertura de requisitos.

Especificación de casos de prueba

Se han desarrollado muchas maneras de escribir y especificar estos Casos. Aquí

presentaremos una adaptación que busca simplificar las pruebas:

Ejemplo: si quiero probar si mi solución de agregar un elemento a una lista simplemente

vinculada que está ordenada podría plantear las siguientes situaciones o CASOS (estos son
sólo algunos ejemplos):

- Agregar un elemento a una lista vacía.

- Agregar un elemento a la lista que tiene un solo elemento.

- Agregar un elemento al principio de la lista.

- Agregar un elemento al medio de la lista.

- Agregar un elemento al final de la lista.

- Agregar un elemento que ya existe en la lista.

Construcción de Casos de Prueba: Este paso debe realizarse muy temprano en el proceso
de desarrollo, tal como se mencionó anteriormente. El resultado de este paso es una
especificación de Casos de Prueba, que pueden tener una estructura como la que
proponemos en el punto siguiente (“Estructura de los Casos de Prueba”).

Ejecución de los Casos de Prueba: (comúnmente llamada “corrida”) La ejecución de los

casos se realiza una vez terminada la codificación. Esta ejecución consiste en tomar cada
especificación de caso de prueba, ejecutar el software que estamos probamos (puede ser
una porción de código) y registrar el resultado de la ejecución. Normalmente una corrida
implica la ejecución de TODOS los casos de prueba. Un mismo Caso de Prueba se puede
ejecutar muchas veces, tantas como corridas se realicen, idealmente al menos cada vez que
se modifica algo del código.

Los 3 problemas más comunes en casos de prueba

Pasos compuestos

En primer lugar, ¿qué es un paso compuesto? Es aquel que se puede dividir en varios pasos
individuales.

Ejemplo: estás dando instrucciones desde el punto A al punto B: si dices que 'Ve al lugar
XYZ y luego al ABC', esto no tendrá mucho sentido, porque aquí nos encontramos
pensando: '¿Cómo puedo llegar a XYZ en primer lugar”- en lugar de comenzar con “Gire a
la izquierda desde aquí y avance 1 kilómetro, luego gire a la derecha en R número 11 para
llegar a XYZ ” podría lograr mejores resultados.

Las mismas reglas exactas se aplican a las pruebas y sus pasos también.

Por ejemplo: escribiendo una prueba para Amazon.com: haga un pedido de cualquier
producto. Recuerde, las pruebas siempre tratan sobre 'Cómo' realizar la prueba, por lo que
es importante escribir los pasos exactos de 'Cómo pagar y pagar' en su prueba.

1. Dirigirse a: Amazon.com
2. Busque un producto ingresando la palabra clave / nombre del producto en el campo
'Buscar' en la parte superior de la pantalla.
3. De los resultados de búsqueda que se muestran, elija el primero.
4. Haga clic en Agregar al carrito en la página de detalles del producto.
5. Checkout y pago.
6. Consulta la página de confirmación del pedido.

El paso “5” es un paso compuesto, por lo tanto, el caso anterior es más efectivo cuando se
escribe de la siguiente manera:

1. Dirigirse a: Amazon.com Busque un producto ingresando la palabra clave / nombre

del producto en el campo 'Buscar' en la parte superior de la pantalla.
2. De los resultados de búsqueda que se muestran, elija el primero.
3. Haga clic en Agregar al carrito en la página de detalles del producto.
4. Haga clic en Pagar en la página del carrito de compras.
 5. Ingrese la información de CC, envío y facturación.
6. Haga clic en Pagar.
7. Consulta la página de confirmación del pedido.

El comportamiento de la aplicación se toma como comportamiento esperado

Cada vez más proyectos tienen que afrontar esta situación en estos días. La falta de
documentación, la programación extrema, los ciclos de desarrollo rápidos son algunas de
las razones que nos obligan a confiar en la aplicación (una versión anterior más o menos)
para escribir las pruebas o para basar las pruebas en sí.

Ejemplo: si la siguiente es la página para la que está escribiendo / diseñando los pasos de
prueba:

Si los pasos de mi caso de prueba son los siguientes:

Caso 1:

1. Inicie el sitio de compras.

2. Haga clic en Envío y devolución. Resultado esperado: la página de envío y
devolución se muestra con 'Ponga su información aquí' y un botón 'Continuar'.

Entonces, esto es incorrecto.

Caso 2:
 1. Inicie el sitio de compras.
2. Haga clic en Envío y devolución.
3. En el cuadro de texto 'Ingrese el número de pedido' presente en esta pantalla,
ingrese el número de pedido.
4. Haga clic en Continuar - Resultado esperado: se muestran los detalles del pedido
relacionados con el envío y las devoluciones.

El caso 2 es un mejor caso de prueba porque a pesar de que la aplicación de referencia se

comporta de manera incorrecta, solo la tomamos como una guía, investigamos más y
escribimos el comportamiento esperado según la funcionalidad correcta anticipada.

Varias condiciones en un caso

Los siguientes son los pasos dentro de una prueba para una función de inicio de sesión.

Ejemplo:

1. Ingrese detalles válidos y haga clic en Enviar.

2. Deje el campo Nombre de usuario vacío. Haga clic en Enviar.
3. Deje el campo de la contraseña vacío y haga clic en Enviar.
4. Elija un nombre de usuario / contraseña que ya haya iniciado sesión y haga clic en
Enviar.

Lo que tenían que ser 4 casos diferentes se combinan en uno. Podrías estar pensando: ¿Qué
hay de malo en eso? Está ahorrando mucha documentación y lo que puedo hacer en 4, lo
estoy haciendo en 1. Bueno, no del todo, ¿por qué?

¿Qué pasa si una de las condiciones falla? Tenemos que marcar toda la prueba como
'fallida'. Si marcamos el caso completo como 'fallido', significa que las 4 condiciones no
están funcionando, lo cual no es realmente cierto.

Las pruebas deben tener un flujo. Desde la condición previa hasta el paso 1 y todos los
pasos. Si sigo este caso, en el paso A, si tiene éxito, iniciaré sesión en la página, donde la
opción 'iniciar sesión' ya no está disponible. Entonces, cuando llegue al paso B, ¿dónde
ingresará el tester el nombre de usuario? Verás, el flujo está roto.

Por eso, escribir pruebas modulares, parece mucho trabajo, pero todo lo que necesitas es
separar las cosas y usar a nuestros mejores amigos Ctrl + C y Ctrl + V para trabajar para
nosotros.

Ejemplo:

Veamos cómo escribir casos de prueba de manera eficiente para una pantalla de 'Inicio de
sesión' familiar y simple como se muestra en la siguiente figura. Los enfoques de prueba
será casi el mismo incluso para pantallas complejas con más información y características
críticas.
El primer enfoque para cualquier proceso de caso de prueba será obtener un prototipo de
pantalla, si está disponible. Es posible que esto no esté disponible para algunas de las
funcionalidades y depende de la importancia de diseñar un prototipo en las primeras etapas
de desarrollo.

Pero, si un SRS (Especificación de requisitos de software) documento está disponible para

el proyecto, la mayoría de los prototipos de pantalla son desarrollados por el equipo del
proyecto. Este tipo de pantalla simplifica el trabajo del evaluador y aumenta la eficiencia de
las pruebas.

A continuación, las especificaciones de requisitos funcionales. Depende del proceso de

organización, estará disponible en un conjunto de múltiples documentos.

Por lo tanto, decida cuál es el mejor documento para redactar casos, ya sea un documento
de requisitos del usuario o una especificación de requisitos funcionales (o incluso un
documento SRS si el equipo de pruebas lo puede entender cómodamente) que
proporcionará un flujo funcional completo de lo seleccionado. característica para ser
probado.

Una vez que el prototipo de pantalla y las especificaciones funcionales están en su lugar, el
tester debe comenzar a escribir los casos con el siguiente enfoque y criterio.

Pruebas de IU, Interfaz Usuaria: los controles / campos que son visibles para el
usuario. Hay controles estáticos y dinámicos disponibles para probar la función. Por
ejemplo, En la pantalla de inicio de sesión anterior, los textos de 'Nombre de
usuario y contraseña' son campos estáticos que no requieren la interacción del
usuario, solo para mostrar el texto.
Casos funcionales: Por otro lado, el botón Iniciar sesión y los Hipervínculos
(¿Olvidó su contraseña? Y Registro) son campos dinámicos que requieren la
interacción del usuario haciendo clic en los controles, que realizarán alguna acción
después.
 Casos de bases de datos: Una vez que el usuario ingresa el nombre de usuario y la
contraseña, las pruebas se pueden escribir para verificar la base de datos
relacionada, si el nombre de usuario y la contraseña están verificados en la base de
datos y la tabla correctas y también el usuario tiene permiso para iniciar sesión en la
aplicación bajo prueba.
Pruebas de proceso: esto está relacionado con el proceso (no las acciones
asociadas con los controles visibles disponibles en la pantalla) asociado con la
característica y la funcionalidad.

Por ejemplo, Si hace clic en el enlace “Olvidé mi contraseña” en la pantalla de muestra

anterior, puede enviar un correo electrónico al usuario. Entonces, tal vez un correo
electrónico deba probarse para el proceso y la confirmación adecuados.

Finalmente, mantenga el Enfoque de BAOE (Básico, Alternativo, Opciones y Excepciones)

para la cobertura completa del flujo funcional y la característica a probar. Todos los
conceptos deben aplicarse a pruebas positivas y negativas.

i) Flujo básico

ii) Flujo alternativo

iii) Opciones

iv) Excepciones

Por ejemplo, Veamos el enfoque BAOE simple para la pantalla de inicio de sesión

Flujo básico: Ingrese la ruta URL del inicio de sesión en cualquier navegador e ingrese la
información requerida e inicie sesión en la aplicación.

Flujo alternativo: Instale la aplicación en un dispositivo móvil e ingrese la información

requerida e inicie sesión en la aplicación.

Opciones: ¿Cuáles son las opciones disponibles para llegar a la misma pantalla de inicio de
sesión?

Ejemplo, después de iniciar sesión en la aplicación, al hacer clic en 'Cerrar sesión' puede
aparecer la misma pantalla o, si el tiempo de espera de la sesión o la sesión expiró, el
usuario puede acceder a la pantalla de inicio de sesión.

Excepciones
¿Cuáles son las excepciones si mis pruebas son negativas?

Ejemplo si se ingresan credenciales incorrectas en la pantalla de inicio de sesión, si el

usuario recibirá un mensaje de error o ninguna acción asociada.
Con toda esta información en la mano, comencemos a escribir los casos de prueba para la
pantalla de inicio de sesión, en un formato con la cobertura y trazabilidad completa y con
información detallada. La secuencia lógica y la numeración de identificar el ' ID de caso de
prueba ' será muy útil para un historial de ejecución de identificación rápida de casos de
prueba.

Nro Pasos para reproducir Comportamiento esperado

1. Abra un navegador e ingrese la URL Debería mostrarse la pantalla de inicio de

para la pantalla de inicio de sesión. sesión.

2. Instale la aplicación en el teléfono Debería mostrarse la pantalla de inicio de

Android y ábrala. sesión.

3. Abra la pantalla de inicio de sesión y El texto 'Nombre de usuario' y 'Contraseña'

compruebe que los textos disponibles
estén escritos correctamente.
debe aparecer antes del cuadro de texto
relacionado. El botón de inicio de sesión
debe tener el título 'Iniciar sesión'. '¿Olvidó
su contraseña?' Y 'Registro' deberían estar
disponibles como enlaces.

4. Introduzca el texto en el cuadro El texto se puede ingresar haciendo clic con

Nombre de usuario. el mouse o enfocarse usando la pestaña.

5. Ingrese el texto en el cuadro El texto se puede ingresar haciendo clic con

Contraseña. el mouse o enfocarse usando la pestaña.

6. Haga clic en ¿Olvidó su contraseña? Hacer clic en el enlace debería llevar al

Enlace. usuario a la pantalla relacionada.

7. Haga clic en el enlace de registro Hacer clic en el enlace debería llevar al

usuario a la pantalla relacionada.

8. Introduzca el nombre de usuario y la Hacer clic en el botón Iniciar sesión debería

contraseña y haga clic en el botón llevar a la pantalla o aplicación relacionada.
Iniciar sesión.
9. Vaya a la base de datos y verifique que El nombre de la tabla debe validarse y debe
el nombre correcto de la tabla esté actualizarse un indicador de estado para un
validado con las credenciales de inicio de sesión exitoso o incorrecto.
entrada.

10. Haga clic en Iniciar sesión sin ingresar Haga clic en el botón Iniciar sesión para
ningún texto en los cuadros Nombre de alertar a un cuadro de mensaje 'El nombre
usuario y Contraseña. de usuario y la contraseña son obligatorios'.

11. Haga clic en Iniciar sesión sin ingresar Haga clic en el botón Iniciar sesión para
texto en el cuadro Nombre de usuario, alertar a un cuadro de mensaje 'La
pero ingrese texto en el cuadro contraseña es obligatoria'.
Contraseña.

12. Haga clic en Iniciar sesión sin ingresar Haga clic en el botón Iniciar sesión para
texto en el cuadro Contraseña, pero alertar a un cuadro de mensaje 'El nombre
ingresando texto en el cuadro Nombre de usuario es obligatorio'.
de usuario.

13. Ingrese el texto máximo permitido en Debe aceptar el máximo permitido de 30

los cuadros Nombre de usuario y caracteres.
Contraseña.

14. Ingrese el nombre de usuario y la No debe aceptar el texto que comience con
contraseña comenzando con los caracteres especiales, lo cual no está
caracteres especiales. permitido en el Registro.

15. Ingrese el nombre de usuario y la No debe aceptar el texto indicando con

contraseña comenzando con espacios espacios en blanco, lo cual no está permitido
en blanco. en Registro.

16. Ingrese el texto en el campo de No debe mostrar el texto real en su lugar

contraseña. debe mostrar el símbolo de asterisco *.

17. Actualiza la página de inicio de sesión. La página debe actualizarse con los campos
Nombre de usuario y Contraseña en blanco.
18. Ingrese el nombre de usuario.
19. Introduce la contraseña.
20. Mueva el foco al enlace Olvidé mi
contraseña usando Tab.
21. Mueva el foco al enlace Registro
usando Tab.
22. Actualice la página de inicio de sesión El botón Iniciar sesión debe estar enfocado
y presione la tecla Intro.
23. Actualice la página de inicio de sesión El primer foco en la pantalla de inicio de
y presione la tecla Tab.
24. Ingrese el usuario y la contraseña y
deje la página de inicio de sesión
inactiva durante 10 minutos.
25. Introduzca la URL de inicio de sesión
en los navegadores Chrome, Firefox e
Internet Explorer.
26. Ingrese las credenciales de inicio de
sesión y verifique la actividad de inicio la misma en todos los navegadores.
de sesión en los navegadores Chrome,
Firefox e Internet Explorer.
Depende de la configuración de llenado
automático del navegador, los nombres de
usuario ingresados previamente deben
mostrarse como un menú desplegable.
Depende de la configuración de
autocompletar del navegador, las
contraseñas ingresadas anteriormente NO
deben mostrarse como un menú desplegable.
Deben poder utilizarse tanto el clic del ratón
como la tecla Intro.
Deben poder utilizarse tanto el clic del ratón
como la tecla Intro.
y la acción relacionada debe activarse.
sesión debe ser el cuadro Nombre de
usuario.
La alerta del cuadro de mensaje 'Sesión
caducada, ingrese nuevamente el nombre de
usuario y contraseña' debe aparecer con los
campos de nombre de usuario y contraseña
limpios.
La misma pantalla de inicio de sesión debe
mostrarse sin mucha desviación en el
aspecto y la alineación del texto y los
controles de formulario.
La acción del botón Iniciar sesión debe ser
27. Verifique que el enlace Olvidé la Ambos enlaces deben llevar a las pantallas
contraseña y el registro no esté roto en relativas en todos los navegadores.
los navegadores Chrome, Firefox e
Internet Explorer.

28. Verifique que la funcionalidad de La función de inicio de sesión debería

inicio de sesión funcione
correctamente en teléfonos móviles
con Android.
29. Verifique que la funcionalidad de
inicio de sesión funcione
correctamente en Tab y iPhones.
funcionar de la misma manera que está
disponible en la versión web.
La función de inicio de sesión debería
funcionar de la misma manera que está
disponible en la versión web.

30. Verificar la pantalla de inicio de sesión
permite que los usuarios concurrentes
del sistema y todos los usuarios
obtengan la pantalla de inicio de sesión
sin demoras y dentro del tiempo
definido de 5-10 segundos.
Esto debe lograrse usando muchas
combinaciones de sistema operativo y
navegadores, ya sea física o virtualmente, o
puede lograrse usando alguna herramienta
de prueba de rendimiento / carga.

Recopilación de datos de prueba

Cuando se escribe el caso de prueba, la tarea más importante para cualquier tester es
recopilar los datos de prueba. Muchos evaluadores omiten esta actividad y la pasan por alto
con la suposición de que los casos de prueba se pueden ejecutar con algunos datos de
muestra o datos ficticios y se pueden alimentar cuando los datos realmente se requieren.
Este es un concepto erróneo crítico de alimentar datos de muestra o datos de entrada desde
la memoria mental en el momento de ejecutar casos de prueba.

Si los datos no se recopilan y actualizan en el documento de prueba en el momento de

escribir las pruebas, el evaluador pasaría anormalmente más tiempo para recopilar los datos
en el momento de la ejecución de la prueba. Los datos de la prueba deben recopilarse tanto
para casos positivos como negativos desde la perspectiva del flujo funcional de la
característica.

Encuentre un documento de datos de prueba de muestra para las pruebas escritas

anteriormente, que a su vez será útil sobre la eficacia con la que podemos recopilar los
datos que facilitarán nuestro trabajo en el momento de la ejecución de la prueba.
Nro Propósito de los datos de Datos de prueba reales
prueba

1. Pruebe el nombre de Administrador (admin2015)

usuario y la contraseña
adecuados
2. Pruebe la longitud máxima Administrador del sistema principal
del nombre de usuario y la (admin2015admin2015admin2015admin)
contraseña

3. Pruebe los espacios en Ingrese espacios en blanco usando la tecla de espacio

blanco para el nombre de para el nombre de usuario y la contraseña
usuario y la contraseña

4. Pruebe el nombre de Admin (activado) (digx ## $ taxk209)

usuario y la contraseña
incorrectos
5. Pruebe el nombre de Admin istrador (admin 2015)
usuario y la contraseña con
espacios no controlados
entre ellos.
6. Pruebe el nombre de $% # @ # $ Administrador (% # * # ** # admin)
usuario y la contraseña
comenzando con caracteres
especiales
7. Pruebe el nombre de administrador (admin2015)
usuario y la contraseña con
todos los caracteres
pequeños
8. Pruebe el nombre de ADMINISTRADOR (ADMIN2015)
usuario y la contraseña con
todos los caracteres en
mayúscula
9. Pruebe el inicio de sesión Administrador (admin2015): para Chrome en la misma
con el mismo nombre de máquina y en una máquina diferente con el sistema
usuario y contraseña con operativo Windows XP, Windows 7, Windows 8 y
varios sistemas Windows Server.
simultáneamente al mismo
tiempo.
Administrador (admin2015): para Firefox en la misma
máquina y en una máquina diferente con el sistema
operativo Windows XP, Windows 7, Windows 8 y
Windows Server.

Administrador (admin2015): para Internet Explorer en

10. Pruebe el inicio de sesión
con el nombre de usuario y
la contraseña en la
aplicación móvil.
la misma máquina y en una máquina diferente con el
sistema operativo Windows XP, Windows 7, Windows
8 y Windows Server.
Administrador (admin2015): para Safari y Opera en
móviles, iPhones y tabletas con Android.

¿Qué es una prueba estándar en pruebas web?

Repasemos algunos conceptos que debemos tener presentes:

 Cree casos de prueba que estén completos: pasos, datos, variables, etc. Esto
garantizará que los datos / variables (aunque no similares) se puedan reemplazar
simplemente cuando se requiera un caso de prueba similar.
 Los criterios de entrada y salida deben definirse adecuadamente.
 Los pasos modificables o la declaración en los pasos deben resaltarse en un color
diferente para encontrarlos y reemplazarlos rápidamente.
 El lenguaje utilizado para la creación de casos de prueba estándar debe ser genérico.
 Todas las características de cada sitio web deben cubrirse en los casos de prueba.
 El nombre de los casos de prueba debe ser el nombre de la funcionalidad o la
característica que cubre el caso de prueba Esto facilitará mucho la búsqueda del
caso de prueba del conjunto.
 Si hay una muestra básica o estándar, un archivo GUI o una captura de pantalla de
la función, debe adjuntarse con los pasos correspondientes.

Al usar los consejos anteriores, uno puede crear un conjunto de scripts estándar y usarlos
con modificaciones pequeñas o necesarias para diferentes sitios web.

El uso de un conjunto estándar de casos de prueba manuales para diferentes sitios web con
modificaciones menores es la mejor manera de realizar una prueba de sitio web. Todo lo
que necesitamos es crear y mantener los casos de prueba con los estándares y el uso
adecuados.

Mejoramiento y mantenimiento de los casos de prueba

Comprobación de los casos de prueba

Una prueba realizada con precisión es fácil de ejecutar lo que significa que, si el tester
sigue las instrucciones, el resultado de aprobado o fallido será correcto. Se puede medir
fácilmente por medio del tiempo que se tarda en ejecutar la prueba, y si el tester tiene que
buscar o no aclaraciones en el proceso de prueba.

Lenguaje para mejorar la comprobación

Los pasos de los casos de prueba deben ser escritos en forma activa. El tester debe saber
qué hacer, y cómo hacerlo.

Por ejemplo, navegar en la página de la tienda online y preparar la lista de lo que va a

comprar, para comparar los precios y la variedad con los datos disponibles.

Controlar longitud para mejorar la comprobación

Es necesario tener en cuenta la longitud de los casos de prueba para saber cuán compleja y
precisa es la prueba.

Un buen caso de prueba debe tener entre 8 y 16 pasos ―en el método paso a paso.

Existen varias ventajas en mantener los casos de prueba cortos: se requiere menos tiempo y
hay menos posibilidades de cometer errores, de necesitar ayuda o de alguna pérdida de
datos.

Con base en la longitud de los casos de prueba es posible estimar con precisión el tiempo y
el esfuerzo que se debe invertir en la prueba, lo mismo que sus resultados.

En los casos de prueba de matriz, una buena longitud oscila entre 18 y 20 minutos para la
prueba.

Tipos de Mantenimiento
Si un problema es detectado por el usuario, inmediatamente puede notificarlo al
administrador del sistema. Dicha petición debe ser atendida por el administrador y este
procederá a diagnosticar de qué tipo de mantenimiento se trata, luego de finalizar las etapas
de desarrollo de un sistema.

Atendiendo a estos fines, podemos establecer los siguientes tipos de mantenimiento:

A. Correctivo. Cambios precisos para corregir errores del producto de software.
B. Evolutivo. Incorporaciones, modificaciones y eliminaciones necesarias en un
producto de software para cubrir la expansión o cambio en los requerimientos del usuario.
C. Adaptativo. Modificaciones que afectan los entornos en los que el sistema opera,
por ejemplo, cambio en las configuraciones del hardware, software de base, gestores de
base de datos, comunicaciones, etc.
D. Perfectivo. Acciones llevadas a cabo para mejorar la calidad interna de los sistemas
en cualquiera de sus aspectos: restructuración de código, definición más clara del sistema y
optimización del rendimiento y eficiencia.

Una vez identificado el tipo de mantenimiento y su origen se determina un tiempo

razonable para su modificación y prueba, haciéndolo del conocimiento del usuario.

Si se trata de un mantenimiento correctivo, los cuales son más comunes, se verifica y

reproduce el problema, o se estudia la viabilidad del cambio propuesto por el usuario. En
ambos casos se identifican, según el tipo de mantenimiento de que se trate, cuál es la más
adecuada. El plazo y urgencia de la solución a la petición se establece de acuerdo con el
estudio anterior.

Las tareas de los procesos de desarrollo que va a ser necesario realizar son determinadas en
función de los componentes del sistema actual afectados por la modificación. Estas tareas
pertenecen a actividades de los procesos análisis, diseño, desarrollo y pruebas.

Por último, y antes de la aceptación del usuario, es preciso establecer un plan de pruebas de
regresión que asegure la integración del sistema de información afectado.

Revisiones periódicas
El monitoreo permanente del sistema asegura que las necesidades de mantenimiento sean
identificadas y satisfechas cuando resulte necesario. Cuando el sistema es de uso
prolongado, se puede establecer un mecanismo para recibir retroalimentación de los
usuarios como una forma efectiva para determinar las necesidades de mantenimiento y
modificación.

A los sistemas se les debe dar mantenimiento para asegurar que continúen operando en el
nivel mostrado durante la etapa de prueba. Si los sistemas se deterioran, existe el riesgo de
que no se desempeñen conforme a los estándares requeridos.

Problemas comunes a la hora de hacer casos de prueba

Demasiado específico: ejecute solo una condición de prueba específica

Los casos de prueba deben considerar una variedad de condiciones que se espera que
maneje el software. El caso de prueba debe poder probar exhaustivamente el módulo de
software con casi todas las combinaciones posibles de condiciones principales.
Para poder probar exhaustivamente todas las combinaciones de condiciones, el probador de
software debe encontrar una manera de presentar estas condiciones de manera que sea fácil
de seguir, revisar y modificar para otros si el proceso del mundo real exige tales acciones.

Cubrir una pequeña parte de la funcionalidad: necesitan probar una parte más grande del
sistema

Los casos de prueba a menudo se centran en una función específica. A menudo, esta
función está determinada por el diseño técnico interno del software. Tales prácticas a
menudo se encuentran en grandes aplicaciones monolíticas como SAP u Oracle ERP,
donde un probador de software no siempre puede tener conocimiento de todo el proceso
comercial, por lo que el caso de prueba nunca termina reflejando lo que el diseñador de
prueba no sabe, pero debería tener. hizo el esfuerzo de comprender.

En cambio, los casos de prueba deben reflejar los patrones y flujos de uso. Cada caso de
prueba debe tratar de cubrir la mayor parte del flujo que sea razonablemente posible,
cruzando los límites técnicos y modulares de la aplicación.

Prueba de software creada solo para un rol de usuario específico

A menudo hemos visto casos de prueba escritos para un rol de usuario muy específico, sin
tener en cuenta a todos los demás usuarios de la aplicación. Esto limita el alcance de los
casos de prueba y, por lo tanto, compromete significativamente su efectividad. Dichos
casos de prueba prueban efectivamente solo pequeños elementos de la aplicación, mientras
que engañosamente pretenden ser casos de prueba completos y sólidos.

Los casos de prueba que son más efectivos reflejan los patrones de uso, o lo que el mundo
Agile denomina viajes de usuario. Una aplicación comercial, por ejemplo, debe probarse
con casos de prueba diseñados para probar todo el proceso comercial, cubriendo todos los
roles de usuario y todos los sistemas que podrían estar involucrados en el proceso
comercial.

Escrito para demostrar que los casos de uso más comunes están bien cubiertos en la
aplicación

Esto es uno de los problemas más comunes y es el resultado de lo que yo llamo un enfoque
'perezoso' para el diseño de pruebas. El diseñador de pruebas simplemente convierte el
documento de requisitos en casos de prueba.

En cambio, el diseñador de la prueba debe buscar los "casos de esquina" o las "condiciones
de contorno". La mayoría de los desarrolladores pueden escribir fácilmente código para los
casos de uso más comunes. Los problemas surgen en el momento en que hay una condición
que es incluso ligeramente diferente al caso de uso más común o previsto. Un caso de
prueba bien diseñado los detectará de manera fácil y consistente.
Catalogación de casos de prueba y control de versiones

Cualquier caso de prueba puede volverse completamente inútil si no se cataloga

sistemáticamente y se mantiene disponible para su uso. Imagine una biblioteca con libros
no catalogados y colocados sistemáticamente en estantes, especialmente después de que
varios prestatarios se hayan saciado. Sería imposible usar los libros si no puede
encontrarlos con facilidad cuando los necesita.

A menudo, cientos de casos de prueba se escriben con mucho esfuerzo y luego se vuelcan
en una estructura de carpetas compartidas. Si bien esto puede funcionar si tiene muy pocos
casos de prueba, un sistema mal organizado colapsa en el momento en que la cantidad de
casos de prueba aumenta más allá de un puñado.

Por lo tanto, necesita una herramienta de prueba de software que pueda etiquetar y
catalogar sistemáticamente los casos de prueba. Luego, su herramienta de prueba de
software debería poder "sacar" casos de prueba cuando sea necesario ejecutarlos. Para que
todo este proceso sea fluido en todo el equipo de pruebas de software, necesita una
poderosa herramienta de pruebas que pueda crear y mantener sin esfuerzo múltiples
versiones de casos de prueba.

12

¿Qué es un formulario web?

Ya todos sabemos lo que es un formulario web, son esa serie de campos de texto, fechas,
números, cajitas para tiquear y con un botón al final que tenemos que rellenar para
registrarnos en un página, para reservar un fin de semana en cancun o para aprobar un
examen.

Un formulario sin mucho diseño, normalmente lo vamos a ver así:

¿Por qué vamos a analizar los formularios HTML?
El testing de formularios es un proceso que se realiza para probar la calidad de un
formulario en un página web, verificando elementos como campos de texto, longitud y
diseño en general. Uno de los propósitos de testear formularios es para mejorar las tasas de
conversión, lo que sería el porcentaje de gente que pasa de ser visitantes de la página a
consumidores/clientes de dicha página.

Los formularios son herramientas importantes para muchos sitios web ya que sirven como
dispositivos de comunicación con los clientes, creando una conexión entre los visitantes y
las empresas.

Que los clientes puedan enviar la información que quieren de manera correcta a través del
formulario es importante como, por ejemplo en el caso de un pedido o una consulta de
soporte. Ahí tenemos información que se debe representar de la manera que quiere el
cliente y por eso es importante que probemos el correcto funcionamiento del formulario.

Por ejemplo, una tienda de ropa en línea podría usar un formulario de encuesta para que sus
clientes califiquen diferentes aspectos del sitio web que les gustan y no les gustan. La
tienda puede realizar pruebas al formulario para evaluar si el diseño está en línea con la
estética general del sitio web. También, pueden asegurarse de que la fuente sea legible, que
sea de fácil acceso, que cada opción sea funcional y no tenga errores técnicos o de
usabilidad. Ya que, en caso que enviemos un formulario que no esté probado podemos
perder toda esa información que para la empresa puede ser de mucha utilidad.

¿Por qué es importante la prueba de formularios?

Ya vimos que es la prueba de formulario y algunas de las razones por las cuales deberíamos
siempre hacer pruebas de formulario, ahora vamos a enumerar todas las ventajas que nos
va a dar la prueba de formularios.

 Impulsa el tráfico de usuarios

Puede ayudar a impulsar el tráfico a su sitio web, mejorando tanto las variantes
orgánicas (visitantes) como las pagas (clientes). Cuando sus formularios funcionan
correctamente, es más probable que los clientes regresen a su sitio web y dejen
comentarios.

 Mejora las comunicaciones empresa-cliente

Un formulario que funciona según lo previsto permite a los clientes comunicarse
con la empresa para proporcionar la información necesaria para las operaciones
comerciales.

 Percepción del cliente

 Tener un formulario que funciona como corresponde puede darle mucha
información a la empresa sobre cómo el cliente percibe el sitio web, que cosas le
gustan, cuáles no, qué cosas están fallando, siempre desde la perspectiva de alguien
que utiliza el sitio web.

 Mejora la resolución de problemas

El testeo de formularios es útil porque nos va a ayudar a descubrir todos los
problemas que tenga nuestro formulario y cómo resolverlos.

 Mejora las conversiones de clientes

Testear nuestro formulario es importante porque puede ayudar a convertir a los
visitantes en clientes. Además, los formularios que funcionan correctamente pueden
mejorar la percepción que tiene el cliente sobre nuestro sitio web.

 Mejora la usabilidad del formulario

La usabilidad es esencial para un formulario porque describe qué tan bien los
clientes pueden usar y navegar a través de los distintos aspectos y detalles del
formulario. Probar los formularios nos va a dejar un formulario sencillo de utilizar
para el cliente.

Conclusión: ya entendemos que es un formulario, que son las pruebas de formulario y por
qué son importantes, pero, ahora hay una pregunta que nos aparece, ¿qué elementos
componen un formulario y que cosas deberíamos validar de dichos elementos ?

Pero… ¿Qué elementos componen a un formulario?

Los formularios están compuestos principalmente por campos de texto o en html (lenguaje
de programación con el que se crean los formularios) conocidos como inputs, estos campos
son los que deberemos completar con nuestra información.

Hay muchas convenciones que damos por sentado en los formularios, por ejemplo si me
piden ingresar numeros, que solo pueda ingresar numeros o que si voy a ingresar mi
contraseña no se pueda ver el texto y aparezcan circulos negros.

Pero esto hay que validarlo y para eso tenemos que entender cómo funcionan estos campos
y qué tipos de campos existen. En esta guía veremos los distintos tipos de campos que
existen y cuáles son algunas de las validaciones importantes que tenemos que hacer.

Inputs
HTML, que es el lenguaje de programación usado para crear formularios, nos propone una
gran diversidad de alternativas a la hora de crear nuestros formularios, es decir, una gran
variedad de elementos para diferentes propósitos. Estas van desde la clásica caja de texto,
hasta la lista de opciones en un menú desplegable, pasando por las cajas de validación, etc.
Por ahora nos concentramos en los inputs y más adelante veremos las cajas o menús
desplegables

Los campos de texto son generados en el código por medio de la etiqueta <input> por eso
les decimos inputs. Con solo la etiqueta input decimos que el formulario va a tener un
campo de texto, pero, no tiene definido ningún tipo de dato concreto.

Tipo de inputs
Para poder especificar el tipo de dato que se va a ingresar en nuestro input se le agrega un
atributo llamado type y a ese atributo se le especifica el tipo de dato, por ejemplo: <input
type="number">. Esto haría un input de tipo numérico. Veamos entonces todos los tipos de
datos que nos permite el input.

1. TEXT (Texto)
Este tipo permite al usuario ingresar texto.

Se vería así:

Para textos muy grandes usamos otro tipo de input llamado textarea, que lo veremos más
adelante.

Validaciones a realizar en los campos de texto

Al encontrarnos con un campo de texto, nosotros como testers tenemos la tarea de validar
los siguientes puntos, para que el formulario funcione de la manera esperada.

 Mayúsculas, minúsculas y números

Que el campo le permita al usuario escribir en mayúsculas, minúsculas y números.
Imagínate que tienes que ingresar la dirección de tu calle, deberías poder ingresar
mayúsculas, minúsculas y números.

 Caracteres especiales
Los caracteres especiales son caracteres que no están presentes en el diseño del
teclado. Se pueden usar si se presiona una combinación de teclas en el teclado (ej:
coma, ©,®, #)

 Caracteres de control
 Un carácter de control es, en el ámbito de la informática, un carácter no imprimible
que sirve para uso interno de la computadora (ej: null, ETX)

 Máximo posible
Usualmente nosotros validamos una longitud de caracteres que elija el programador,
supongamos que el programador elige que se pueden ingresar 100 caracteres,
deberemos probar qué más de 100 no se pueda.
El máximo posible de caracteres que se puede ingresar por defecto en un campo de
texto es 524,288 caracteres.

 No trunca la cadena ingresada

Cuando decimos que no trunque la cadena ingresada es que no acorte el largo de la
cadena, por ejemplo: "Mi nombre es M…"

2. NUMBER (Numérico)
Este tipo permite al usuario ingresar números. Los navegadores vienen con validaciones
para evitar que el usuario ingrese algo que no sea números. Además, en los navegadores
modernos, los campos numéricos suelen venir con controles que permiten a los usuarios
cambiar su valor de forma gráfica.

Se vería así:

Validaciones a realizar en los campos numéricos

Al encontrarnos con un campo numérico, nosotros como testers tenemos la tarea de validar
los siguientes puntos, para que el formulario funcione de la manera esperada.

 Sólo números (o carácteres como +, -, ., o el número e, entre otros)

Supongamos que tenemos que ingresar una suma o que tenemos que ingresar un dni
con puntos entre cada número.

 Máximo posible
 Usualmente nosotros validamos una longitud numérica que elija el programador,
supongamos que el dato a ingresar es un año, el programador pondrá que no se
puedan ingresar más de 4 caracteres y nosotros deberemos validar que el
funcionamiento sea correcto.
Dato de color: el máximo posible de caracteres numéricos que se puede ingresar por
defecto es de 524,288 caracteres numéricos.

 Números negativos, cero, decimales

Que el campo le permita al usuario escribir números negativos, el número cero o
escribir con decimales. Lo decimales en campos numéricos suelen escribirse con
punto en vez de coma, ej: 10.5

 No nulos
Significa que no permite enviar el formulario con ese campo vacío, seguramente lo
has visto en algún formulario de google que has completado en el pasado. Depende
de como armemos el formulario y que consideremos importante, este tipo de
restricciones pueden existir o no. Por ejemplo, muchas veces los datos personales
son campos marcados como no nulos, ya que son fundamentales para poder
procesar y gestionar los datos ingresados.

3. DATE (Fechas)
Este le permite al usuario ingresar una fecha, ya sea mediante una caja de texto o una
interfaz gráfica con selector de fecha.

Se vería así:
Validaciones a realizar en los campos de fechas
Al encontrarnos con un campo de fecha, nosotros como testers tenemos la tarea de validar
los siguientes puntos, para que el formulario funcione de la manera esperada.

 Sólo números, tipo de caracteres aceptados, combinado, formato predefinido

Que el campo le permita al usuario solo escribir números o usar caracteres
combinados como por ejemplo el guión para escribir una fecha (31-05-1997)

 Formato: d/m/a . a/m/d . m/d/a . d-m-a . a-m-d . m-d-a

El formato en el que se representa la fecha depende del país en donde se utilice la
web que aloja al formulario o la cultura a la que pertenecen los usuarios que lo van
a completar. Supongamos que en el argentina usamos dia/mes/año, revisar que esté
ese formato y no a/m/d

 Caracteres especiales
Los caracteres especiales son caracteres que no están presentes en el diseño del
teclado. Se pueden usar si se presiona una combinación de teclas en el teclado (ej:
coma, ©,®, #). Es necesario corroborar si el formulario acepta o no acepta este tipo
de caracteres según los requerimientos planteados en el proyecto.

 No nulos
Significa que no permite enviar el formulario con ese campo vacío, seguramente lo
has visto en algún formulario de google que has completado en el pasado.

4. Email
Este tipo permite al usuario ingresar un mail. Los navegadores vienen con validaciones para
validar que se esté ingresando con el formato correcto de un mail. Este input se va a ver
como un input de texto común y corriente.

Validaciones a realizar en los campos de email

Al encontrarnos con un campo de email, nosotros como testers tenemos la tarea de validar
los siguientes puntos, para que el formulario funcione de la manera esperada.

 Mayúsculas, minúsculas y números

Que el campo le permita al usuario escribir en mayúsculas, minúsculas y números.
Supongamos que tenemos un mail con todas esas combinaciones. Ej:
T3St3r@egg.com

 Caracteres especiales
Qué podamos poner un mail con caracteres especiales, por ejemplo
**testers!!@egg.com

 Formato correcto de un mail

Que el campo solo le permita al usuario escribir con el formato que corresponde de
un mail, texto@dominio.com. Que no permita escribir algo así: testers.com

5. Texto oculto
Hay determinados casos en los que podemos desear esconder el texto escrito en el campo
input, por medio de círculos negros, de manera que aporte una cierta confidencialidad. Para
esto vamos a usar el type password.

Se vería así:
Validación campo oculto
Con el campo oculto lo único que tenemos que validar es su correcto funcionamiento, si yo
ingreso texto en dicho campo debería mostrarlo oculto.

6. TEXTAREA para texto largo

Si deseamos poner a disposición del usuario un campo de texto donde pueda escribir
cómodamente sobre un espacio compuesto de varias líneas, hemos de invocar una nueva
etiqueta: <textarea> y su cierre correspondiente.

Este tipo de campos son prácticos cuando el contenido a enviar no es un nombre, teléfono,
edad o cualquier otro dato breve, sino más bien, un comentario, opinión, etc. En los que
existe la posibilidad de que el usuario desee rellenar varias líneas.

El resultado es el siguiente:

Asimismo, es posible predefinir el contenido del campo.

Validaciones a realizar en los campos de texto largo

Al encontrarnos con un campo de texto, vamos a realizar las mismas validaciones que
realizamos para los campos de texto normales.

 Mayúsculas, minúsculas y números

 Que el campo le permita al usuario escribir en mayúsculas, minúsculas y números.
Imagínate que tienes que ingresar la dirección de tu calle, deberías poder ingresar
mayúsculas, minúsculas y números.

 Caracteres especiales
Los caracteres especiales son caracteres que no están presentes en el diseño del
teclado. Se pueden usar si se presiona una combinación de teclas en el teclado (ej:
coma, ©,®, #)

 Caracteres de control
Un carácter de control es, en el ámbito de la informática, un carácter no imprimible
que sirve para uso interno de la computadora (ej: null, ETX)

 Máximo posible
Como ya vimos en el campo de texto, usualmente nosotros validamos una longitud
numérica que elija el programador, supongamos que el dato a ingresar es un parrafo
de 100 caracteres, el programador pondrá que no se puedan ingresar más de 100
caracteres y nosotros deberemos validar que el funcionamiento sea correcto.

 No trunca la cadena ingresada

Cuando decimos que no trunque la cadena ingresa es que no acorte el largo de la
cadena de caracteres, por ejemplo: "Mi canción favorita es p…"

Configuraciones extras
Vamos a explicar algunas configuraciones que le podemos poner a nuestros campos de
texto para que funcionen de manera distinta, esta información es por si llegan a encontrarse
con campos con alguna de estas características, entiendan cuál es la configuración que se
les ha asignado.

size: define el tamaño de la caja de texto, en número de caracteres visibles. Si al escribir el

usuario llega al final de la caja, el texto que escriba a continuación también cabrá dentro del
campo, pero irá corriéndose a medida que se escribe, haciendo desaparecer la parte de texto
que queda a la izquierda.

maxlength: indica el tamaño máximo del texto, en número de caracteres, que puede ser
escrito en el campo. En caso de que el campo de texto tenga el atributo maxlength, el
navegador no permitirá escribir más caracteres que los que hayamos indicado.

placeholder: este atributo especifica una pequeña pista que describe el valor esperado para
el campo (input).
La pequeña sugerencia se muestra en el campo de entrada antes de que el usuario ingrese
un valor. Una vez que escriba, ese valor va a desaparecer.

¿NECESITAS UN EJEMPLO DE placeholder?

Genera un campo de este estilo:

value: en algunos casos puede resultarnos interesante asignar un valor predefinido al

campo en cuestión. Esto puede ayudar al usuario a rellenar más rápidamente el formulario o
darle alguna idea sobre la naturaleza de datos que se requieren.

Es importante destacar que esto no significa que el usuario no pueda escribir en dicho
campo, si quiere puede cambiar lo que está por defecto, por lo que él quiera

¿Qué validaciones podemos hacer?

Antes que nada, el equipo de desarrollo nos debe confirmar si es necesario validar estas
configuraciones. Algunas de las formas de validar son:

 Qué el texto desaparezca al llegar al final de la caja pero podamos seguir

escribiendo

 Qué los campos al cargar el formulario ya tengan valores

 Qué el texto en gris en un campo desaparezca al escribir en él

Título del campo (etiqueta label)

El campo de texto puesto solo en un formulario va a ser confuso para un usuario, ya que es
un recuadro vacío esperando ser completado.

En este ejemplo vemos un campo con título, otro sin título que el usuario no entendería por
qué debe llenarlo y con qué información debería llenarlo.
Es por eso que para indicarle al usuario qué información debería ingresar en el campo o
input se incorpora un título a dicho campo, este título suele ponerse con una etiqueta de
html llamada <label>, por lo que si en algún momento de la guía ven la palabra label, sepan
que es el texto que aparece previo a un campo de texto.

Esto en una página se vería así:

La validación para esto es que el título se corresponda con el tipo de campo a rellenar, si
el título del campo dice nombre y solo me deja ingresar números, ¡tenemos un problema!

Otros elementos de formularios

Seguramente hayan notado que los inputs son una manera muy práctica de hacernos llegar
la información del navegante. No obstante, en muchos casos, permitir al usuario que escriba
cualquier texto permite demasiada libertad y puede que la información que éste escriba no
sea la que nosotros estamos necesitando.

Por ejemplo, pensemos que queremos que el usuario indique su país de residencia. En ese
caso podríamos ofrecer una lista de países para que seleccione el que sea. Este mismo caso
se puede aplicar a gran variedad de informaciones, como el tipo de tarjeta de crédito para
un pago, la puntuación que da a un recurso, si quiere recibir o no un boletín de novedades,
etc...

Este tipo de opciones predefinidas por nosotros pueden ser expresadas por medio de
diferentes campos de formulario. Veamos a continuación cuales son:

Listas de opciones
Las listas de opciones son ese tipo de menús desplegables que nos permiten elegir una (o
varias) de las múltiples opciones que nos proponen. Esto en una página se vería así:

Validaciones a realizar en las listas de opciones

Al encontrarnos con listas de opciones, nosotros como testers tenemos la tarea de validar
los siguientes puntos, para que el formulario funcione de la manera esperada.

 Datos requeridos
Que la lista de opciones tenga todas las opciones necesarias, por ejemplo si la lista
de opciones es sobre los meses del año, que tenga los 12 meses como opción.

 Datos seleccionables
Que la lista de opciones le permita al usuario seleccionar cualquiera de las opciones
que se encuentran disponibles.

 Modificar selección
Que el usuario pueda cambiar la opción que eligió, por ejemplo, elegí el mes enero
y después lo quiero cambiar, que la lista me dejé realizar ese pequeño cambio.

 Tiempo de respuesta
Validar que la lista de opciones no tarde demasiado tiempo en mostrar las opciones
o en elegir opciones, sino el usuario puede interpretar que durante ese tiempo
muerto el proceso se ha trabado

 Mostrar todos los datos del listado

Validar que la lista de opciones al abrirla/cliquear, muestre todas las opciones,
supongamos que si tiene los 12 meses del año pero al cliquear no me sale dicha
opción para usar.

 Orden
Validar que la lista de opciones muestre el orden correcto de las opciones por
ejemplo, no puede mostrar los meses así:
A. Noviembre
 B. Mayo
C. Enero

 Selección múltiple
En algunos casos en las listas de opciones se puede seleccionar más de una opción,
validar si esto sería correcto o no según el campo que tiene que completar el
usuario.
Por ejemplo, si estamos dando una lista de opciones con los meses del año para que
ingrese en qué mes nació, no puede poner dos opciones pero, si le estamos
preguntando en qué meses es invierno, debería poder elegir más de una opción.

Botones de opción
Existe otra alternativa para plantear una elección, en este caso, obligamos al usuario a elegir
únicamente una de las opciones que se le proponen. Para esto usamos los botones de
opción.

Los botones de opción pueden ser, por ejemplo, una lista de agujeros circulares que pueden
contener un espacio blanco (para la opción de “no seleccionado”) o un punto (para la
opción de “seleccionado”). Adyacente a cada botón de opción normalmente se muestra un
texto que describe la opción que representa el botón de opción.

Un botón de opción se ve normalmente de la siguiente manera:

Validaciones a realizar en los botones de opción

Al encontrarnos con botones de opción, nosotros como testers tenemos la tarea de validar
los siguientes puntos, para que el formulario funcione de la manera esperada.

 Marcar y desmarcar
 Que el usuario pueda cambiar la opción que eligió, por ejemplo, elegí invierno y
después lo quiero cambiar, que el botón de opción me dejé desmarcar la opción y
elegir otra.

 Funcionamiento de los botones de opción

Que el usuario al elegir la opción se marque con algún color o algún cambio en el
botón y que cuando desmarque la opción vuelva a su estado original o en blanco.

 Opciones únicas o opciones múltiples

En las listas de opciones vimos que dependiendo de lo que le fuéramos a pedir al
usuario que rellene, podíamos tener la opción de que eligiera una o múltiples
opciones, bueno, esto también es válido para los botones de opción. Por lo que,
dependiendo del dato que se le pida al usuario validar si debería poder elegir una o
múltiples opciones.

 Datos requeridos
Que los botones de opción tengan todas las opciones necesarias, por ejemplo si los
botones de opciones son sobre los meses del año, que tenga los 12 meses como
opción.

 Alineación de los botones

Revisar que la opción se alinee correctamente con la caja a seleccionar por
ejemplo:

Botones
Como podremos imaginarnos, en formularios no solamente habrá elementos o campos
donde solicitar información del usuario, sino también habrá que implementar otra serie de
funciones. Concretamente, han de permitirnos su envío mediante un botón. También puede
resultar práctico poder proponer un botón de borrado o bien un botón de volver.
Botón de envío de formulario (botón submit)
Para dar por finalizado el proceso de relleno del formulario y hacerlo llegar a su gestor, el
usuario ha de enviarlo por medio de un botón previsto a tal efecto. Usualmente el botón de
encuentra al final del formulario y tiene un texto acorde.

Supongamos que tenemos un formulario de registro, tendríamos un boton que diga

“Registrarse”. Esto en la página se verá así:

Validaciones a realizar en el botón de envío

Al encontrarnos con el botón de envío, nosotros como testers tenemos la tarea de validar los
siguientes puntos, para que el formulario funcione de la manera esperada.

 Verificar que el botón sea clickeable

Que el usuario pueda hacer click en el botón a la hora de enviar el formulario. Y que
al hacer click se ejecute la acción esperada, en este caso enviar el formulario.

 Posición del botón

Que el botón esté situado en un lugar lógico en el flujo del uso del formulario, por
ejemplo, que se encuentre al final del formulario. Esto no es completamente
necesario pero ayuda a que el usuario tenga una mejor experiencia.

 No nulos
 En caso que tengamos datos obligatorios, el botón no nos debería dejar enviar el
formulario sin antes llenar dichos campos o no debería mostrar un mensaje de error.

 Redirección o mensaje de confirmación

Validar que la página nos redirecciona a alguna página deseada o nos da una
mensaje de confirmación (“registro con éxito!!”) al hacer click en el botón.

 Texto del botón

Validar que el nombre del botón sea el correcto o que sea algo coherente,
supongamos que queremos que el usuario se registre el boton deberia decir,
registrate o submit.

Botón de borrado (botón de reset)

Este botón nos permitirá borrar el formulario por completo, en el caso de que el usuario
desee rehacerlo desde el principio.

A diferencia del botón de envío, indispensable en cualquier formulario, el botón de borrado

resulta meramente optativo y no es utilizado frecuentemente. Hay que tener cuidado de no
ponerlo muy cerca del botón de envío y de distinguir claramente el uno del otro, para que
ningún usuario borre el contenido del formulario que acaba de rellenar por error.

Esto en una página se vería así:

Validaciones a realizar en el botón de borrado
Al encontrarnos con el botón de borrado, nosotros como testers tenemos la tarea de validar
los siguientes puntos, para que el formulario funcione de la manera esperada.

 Verificar que el botón sea clickeable

Que el usuario pueda hacer click en el botón.

 Funcionamiento del botón

Que al clickear el botón se borren los campos rellenados.

 Posición del botón y visibilidad del botón

Algunos detalles de posición y visibilidad que podemos validar son:
- que el botón no se encuentra muy cerca del botón de envío para poder distinguir
claramente el uno del otro, y así minimizar la posibilidad de que por error el usuario
borre el contenido del formulario que acaba de rellenar.
- que el botón no haya quedado oculto entre otros elementos del formulario.

 Texto del botón

Validar que el nombre del botón sea el correcto o que sea algo coherente,
supongamos que queremos que el usuario pueda borrar el formulario el botón
debería decir, borrar o resetear.

URL
Hay una cosa extra que podemos validar cuando hacemos click en el botón de envío y es
cerciorarnos de que los datos sensibles no se envíen a través de la url.

¿Qué significa esto?

Cuando nosotros enviamos nuestro formulario, toda la información que estaba en los
campos se envía al servidor de la página que se encarga de enviarlo a la base de datos y de
esa manera estar registrados. Si el formulario no está bien programado, la información va a
viajar a la base de datos pero, el usuario va a ver toda la información en la url de la página.

¿Qué peligro conlleva eso?

Además de que hace que el usuario probablemente no esté muy contento con esto, el riesgo
real es que los usuarios pueden ver exactamente qué parámetros se envían a su servidor y
no solo pueden guardar esa URL con un marcador (para volver a enviar) sino que también
pueden modificar la URL para enviar otros parámetros, potencialmente sin sentido, a
nuestra base de datos / servidor.
¿Por qué sucede esto?
Esto sucede porque a la hora de enviar nuestro formulario se envía a través de una petición
HTTP, las peticiones HTTP son básicamente la manera en la que la página se comunica con
el servidor.

Vamos a poner un ejemplo muy sencillo, el usuario teclea en su url www.ejemplo.com, el

navegador en ese momento envía una petición HTTP al servidor para que traiga la página
web. El servidor envía la petición con la página para que el navegador la cargue y por
último la muestre.

Estas peticiones también se usan para enviar la información, cuando nosotros le damos al
botón de submit en nuestro formulario, enviamos una petición HTTP con toda nuestra
información para que el servidor la guarde.

Get y Post
Como podemos ver hay dos tipos de peticiones, una que es de traer (get) información del
servidor y otra que es enviar (post) información al servidor. Estos dos métodos, llamados
get y post, nos ayudan a definir cada acción que se realiza en nuestro servidor, los
programadores definen según necesidad si hacen que “x” acción sea get o post.

El problema con nuestro formulario aparece cuando en vez de poner el formulario con un
método post, lo ponemos con un método get y ahí vamos a ver toda nuestra información en
la url.

¿Cómo se vería esto?

Como podemos ver en la url se puede ver que ingresó el usuario en cada campo, ahora
podría guardar esa url y enviar otros parámetros sin sentido.
 14

Las herramientas de gestión de pruebas ayudan a tener todo organizado, almacenan los
casos y resultados de las pruebas, gestionan el flujo de trabajo de los defectos y
proporcionan informes útiles para analizar las tendencias y el progreso. Para los proyectos
más pequeños, una hoja de cálculo puede ser suficiente. Los generadores de datos ahorran
tiempo. Ya que generan datos a partir de información ya existente y tus normas. Son muy
útiles para obtener información de varias fuentes. Después se debe verificar la precisión de
los resultados.

¿Qué es TestLink?
TestLink es un software basado en la Web que funciona como herramienta de gestión de
proyectos y pruebas tanto manuales como automatizadas.

Admite la especificación de requerimientos, la gestión de diferentes tipos de pruebas y el

seguimiento de errores generando informes en tiempo real en diversos formatos, como MS
Word, Excel y HTML. Permite la integración de otros sistemas populares de seguimiento
de errores como Jenkins, JIRA, Mantis, Bugzilla, TRAC.

Al ser un software basado en la Web, brinda la posibilidad de establecer roles para distintos
usuarios dentro de una cuenta.

¿Por qué usar herramientas de prueba?

Las herramientas de prueba ofrecen muchos beneficios que respaldan las iniciativas de
prueba. Algunas de ellas son las siguientes:

 Reducción de tareas repetitivas

 Evaluación objetiva
 Facilidad de acceso a la información sobre exámenes o pruebas.
 Mayor consistencia y repetibilidad.

 Las herramientas de prueba ayudan a establecer estructuras de ejecución de pruebas

que hacen que el trabajo, que de otro modo sería extenso, sea fácilmente ejecutable.

 Especificaciones de TestLink
 La siguiente tabla enumera algunas de las especificaciones importantes de TestLink.

Nro Especificación y descripción

1 Derechos de autor de la aplicación

Es desarrollado y mantenido por Teamtest. Es una herramienta de código abierto.
2 Alcance de la herramienta
Se puede utilizar como marco de automatización de pruebas. Se utiliza como una
utilidad de prueba.

3 Métodos de prueba
Pruebas ágiles
Pruebas de caja negra
Prueba exploratoria
Pruebas funcionales/manuales
Pruebas tradicionales

4 Objetivos de la herramienta
Pruebas de escritorio
Pruebas web

5 Funciones de gestión
Gestión de requisitos
Gestión de pruebas
Reporte

6 Requisitos de Software
Apache: 2.2.2.1
MySQL: 5.5.16
PHP: 5.3.8
PhpMyAdmin: 3.4.5
Servidor FTP de Filezilla: 0.9.39
Tomcat: 7.0.21

7 Manejo de errores
Capturar capturas de pantalla

8 Interfaz de usuario disponible

API COM
Interfaz de usuario directa
GUI usability
Características de TestLink
 Cada producto se prueba en planes de prueba de acuerdo con los procedimientos de
prueba naturales.
 Los casos de prueba están organizados en una estructura jerárquica (menú de árbol)
 Se admiten palabras clave para aportar más profundidad a las pruebas de la
organización.
 Las pruebas se pueden priorizar, asignar a los Tester, definir como hitos
 Los informes se pueden enviar por correo directamente desde la herramienta
 Gestión de roles de usuario
 Pruebas de compilación de software múltiple
 Supervisión del rendimiento, informes de prueba y generación de gráficos
 Integración con otro software a través de API
 Integración del sistema de seguimiento de defectos/errores
 Útil para realizar un seguimiento de todas las actividades de control de calidad
desde la primera fase del ciclo de vida de las pruebas de software.
 Útil en gestión de proyectos, seguimiento de tareas, gestión de requisitos y gestión
de pruebas.
 Admite todas las actividades de nivel macro realizadas por control de calidad.

Ventajas de TestLink

 Herramienta de gestión de pruebas de código abierto.

 Buena gestión de usuarios y control de permisos.
 Es posible importar resultados de prueba desde CSV/Excel, lo que ahorra mucho
tiempo en el registro de resultados
 La exportación de casos de prueba es posible en formato Word
 Resumen de ejecución de pruebas en el panel
 Seguimiento de ejecución de casos de prueba por ciclo de prueba por proyecto
 Visualización de resultados tabulares para múltiples ciclos de prueba
 Generación de informes de resultados de pruebas

Desventajas de TestLink

 Expectativas poco realistas de la herramienta

 TestLink no permite la provisión para probar aplicaciones móviles.
 Con el avance de las tecnologías web y el aumento de la complejidad, a veces al
evaluador le resulta difícil utilizar esta herramienta para la gestión de pruebas.
 15

Implementación
Es la etapa donde los diseños de prueba realizados en las etapas previas del STLC como
casos, procedimientos y datos de prueba, se configuran para estar listos para la etapa
siguiente -Ejecución-. Es un proceso que respeta un orden lógico y prioritario establecido
por el Gerente de pruebas, quien también prepara los entornos para la ejecución de las
pruebas.

En este momento, si realizaramos alguna prueba automatizada aquí también se

desarrollarían esos scripts. También es el momento en donde se adquieren, de ser necesario,
herramientas para la gestión de estas pruebas.

En esta etapa, el Gerente de Pruebas debe asegurar:

 entrega del entorno de prueba

 entrega de datos de prueba
 se comprueban las limitaciones, los riesgos y las prioridades
 se comprueban los criterios de entrada (explícito/implícito)
 el equipo de prueba está listo para la ejecución:
o Asegurarse de que el entorno de prueba está en su lugar.
o Garantizar que cada caso de prueba esté bien documentado y revisado.
o Poner el entorno de prueba en un estado de preparación.
o Verificación contra criterios de entrada explícitos e implícitos para el nivel
de prueba especificado.
o Describir el entorno de prueba, así como los datos de prueba con gran
detalle.
o Realización de una verificación de aceptación de código ejecutándolo en un
entorno de prueba.

Desventajas de la implementación temprana de pruebas

La implementación temprana de las pruebas también puede tener algunas desventajas.

· Por ejemplo, si se ha adoptado el ciclo de vida ágil para el desarrollo de productos,

el código en sí puede sufrir cambios drásticos entre iteraciones consecutivas. Esto
hará que toda la implementación de la prueba sea inútil.
· De hecho, cualquier ciclo de vida de desarrollo iterativo afectará el código entre
iteraciones, incluso si no es tan drástico como en el ciclo de vida Agile.
· Esto hará que las pruebas predefinidas queden obsoletas o requieran un
mantenimiento continuo y con muchos recursos.
 · De manera similar, incluso en el caso de ciclos de vida secuenciales, si el proyecto
está mal administrado y los requisitos siguen cambiando incluso cuando el proyecto
se encuentra en un estado avanzado, la implementación de la prueba inicial puede
volverse obsoleta.

Por lo tanto, antes de iniciar el proceso de implementación de pruebas, el gerente de

pruebas (Test Manager) debe considerar estos puntos importantes:

· Ciclo de vida de desarrollo de software que se utiliza

· Características que deben probarse
· Probabilidad de cambio en el requisito tarde en el ciclo de vida del proyecto
· Posibilidad de cambios en el código entre dos iteraciones

Ventajas de la implementación temprana de pruebas

La implementación temprana de la prueba también ofrece algunas ventajas.

· Las pruebas concretas, por ejemplo, brindan ejemplos listos del comportamiento
apropiado del software si se documentan de acuerdo con las condiciones de la
prueba.
· A los expertos en dominios les resulta más fácil verificar las pruebas concretas que
las reglas comerciales no concretas, lo que les permite detectar fallas en las
especificaciones del software.

Entorno de pruebas
El primer paso es configurar el entorno de pruebas

¡Lenguaje técnico! Entorno de pruebas es una configuración de software y hardware

para que los equipos de prueba ejecuten casos de prueba. En otras palabras, admite la
ejecución de pruebas con hardware, software y red configurados.
En otras palabras, un entorno de prueba le permite crear entornos idénticos cada vez que
necesite probar su producto. Es la herramienta más importante para que un ingeniero de
pruebas tenga confianza en los resultados de las pruebas.
Configuración del entorno de pruebas

Esta es una fase crucial del ciclo de vida de las pruebas de software y requiere la ayuda de
otros miembros de la organización. Los tester deben tener acceso a las capacidades de
informe de errores, así como a la arquitectura de la aplicación para respaldar el producto.
Sin estos elementos, es posible que los tester no puedan hacer su trabajo.

Una vez listos, los testers establecen los parámetros para el entorno de prueba, que incluyen
el hardware, el software, los datos de prueba, los marcos, las configuraciones y la red. En
esta fase STLC, los testers ajustan estos parámetros ambientales según lo que requiera el
caso de prueba.

La configuración de un entorno de prueba adecuado garantiza el éxito de las pruebas de

software. Cualquier falla en este proceso puede generar costos y tiempo adicionales para el
cliente.

Importancia del entorno de prueba

Un entorno de prueba proporciona información precisa sobre la calidad y el

comportamiento de la aplicación que se está probando. En otras palabras, un entorno de
prueba le proporciona la configuración necesaria para ejecutar sus casos de prueba.

Un entorno de prueba lo ayuda aún más al proporcionar un entorno dedicado para que
pueda aislar el código y verificar el comportamiento de la aplicación. Esto garantiza que no
se esté ejecutando en el servidor ninguna otra actividad que pueda influir en el resultado de
las pruebas.

Desafíos en la configuración de la gestión del entorno de prueba

Planificación adecuada del uso de recursos. La planificación ineficaz del uso de recursos
puede afectar el resultado real. Además, puede dar lugar a conflictos entre equipos.

Entorno remoto. Es posible que un entorno de prueba esté ubicado geográficamente

aparte. En tal caso, el equipo de prueba debe confiar en el equipo de soporte para varios
activos de prueba. (Software, hardware y otros temas).

Tiempo de configuración elaborado. A veces, la configuración de la prueba se vuelve

demasiado elaborada en casos de pruebas de integración.

Uso compartido por equipos. Si el entorno de prueba es utilizado por el equipo de

desarrollo y prueba simultáneamente, los resultados de la prueba se dañarán.

Configuración de prueba compleja. Ciertas pruebas requieren una configuración de

entorno de prueba compleja. Puede representar un desafío para el equipo de prueba.

¡Pro tip alert! Prácticas recomendadas para configurar una gestión del entorno de
prueba

 Comprende los requisitos de la prueba a fondo y educa a los miembros del equipo
de prueba.
 La conectividad debe verificarse antes del inicio de la prueba.
 Comprueba el hardware y el software necesarios, las licencias, navegadores y
versiones
 Planificación del uso programado del entorno de prueba.
 Herramientas de automatización y sus configuraciones.
Ejecución
Si es hora de ejecutar tus pruebas, comprueba este checklist de procedimientos que
deben cumplirse previamente:

 El diseño o definición de las pruebas debe ser completo.

 Las herramientas de prueba, especialmente las herramientas de gestión de
pruebas deben estar listas
 Los procesos para el seguimiento de los resultados de las pruebas, incluidas las
métricas, deben estar funcionando.
 Cada miembro del equipo debe comprender los datos a rastrear
 Los criterios para registrar pruebas y reportar defectos deben publicarse y estar
disponibles para todos los miembros del equipo.
 Si la estrategia de prueba que se utiliza es reactiva, aunque sea parcialmente, se
debe asignar tiempo adicional para aplicar metodologías basadas en defectos y
experiencia.

La ejecución de prueba es la etapa del STLC donde se ejecuta una prueba en el componente
o sistema bajo prueba, produciendo un resultado real.

Durante la ejecución, una función de los administradores de pruebas es:

 Supervisar el progreso de acuerdo con el plan.

 Iniciar y llevar a cabo acciones de control para guiar las pruebas.

Durante la ejecución, es importante mantener una capacidad de seguimiento entre las

condiciones, la base y el objetivo de las pruebas y tener el nivel adecuado de registro de la
prueba que incluya detalles relevantes..

Se debe reservar tiempo suficiente para las sesiones de ejecución de pruebas. Esta
estimación de tiempo estará basada en la experiencia y en los defectos impulsados por los
hallazgos del tester.

Los testers seguirán los planes de prueba desarrollados en la primera fase y utilizarán los
scripts de prueba escritos en la segunda fase. Las pruebas deben ejecutarse siguiendo
estrictamente el plan, con todas las discrepancias, defectos, fallas, problemas y errores
registrados tan pronto como se identifiquen. Los defectos y discrepancias deben asignarse a
los casos de prueba y luego volver a probarse para garantizar la validez de los resultados de
la prueba.

Las discrepancias se miden como la diferencia entre los resultados de la prueba reales y
esperados.

Idealmente, las pruebas deben realizarse según los casos de prueba definidos. Sin embargo,
el administrador de pruebas puede permitir que los testers realicen pruebas adicionales para
detectar comportamientos nuevos e interesantes observados durante las pruebas.
Obviamente, si se detecta alguna falla durante tales pruebas no planificadas, se deben
documentar las variaciones de los casos de prueba predefinidos, para que puedan
reproducirse en el futuro.

Desafíos para la ejecución en STLC

Muchos de los desafíos relacionados con la fase de ejecución del ciclo de vida de las
pruebas de software se relacionan con la documentación, la consistencia y la tecnología.

A menudo, en el rápido ritmo de desarrollo y lanzamiento, las pruebas se vuelven de baja

prioridad. El equipo sacrificará las pruebas críticas para sacar el lanzamiento más rápido, lo
que puede generar problemas que solo se descubren más tarde.

Según una encuesta reciente, quienes diseñan pruebas de TI en los Estados Unidos y el
Reino Unido identificaron la dificultad para usar software y herramientas de prueba como
el mayor desafío para la ejecución exitosa de las pruebas. Las herramientas que no son
fáciles de usar y requieren una capacitación extensa y que requiere mucho tiempo para los
testers no técnicos pueden aumentar el costo y limitar la eficiencia de las pruebas.

¡Pro tip alert! ¿Quieres ser un experto en ejecución? Te dejamos aquí las mejores
prácticas:

 Registra las pruebas realizadas para respaldar cada requisito.

 Verifica que se hayan cumplido los requisitos en el producto, utilizando una
Matriz de Trazabilidad de Requisitos (RTM).
 Utiliza el RTM para analizar el trabajo realizado en un proyecto. Con este
análisis, el equipo de control de calidad puede estimar mejor los ciclos de trabajo
posteriores, se pueden eliminar las reelaboraciones innecesarias y redundantes
para reducir los costos y los proyectos tendrán menos defectos y problemas.

Al final de la fase de ejecución, se debe completar todo el plan de prueba, con todos los
defectos identificados y documentados. Este documento, un informe de defectos, es una
herramienta importante para administrar el proyecto y garantizar una versión de alta
calidad.

Informe de defectos
El informe de defectos es un proceso de detección de defectos en la aplicación que se está
probando o en el producto mediante la prueba o el registro de los comentarios de los
clientes y la creación de nuevas versiones del producto que solucionen los defectos en
función de los comentarios del cliente. Es el documento por excelencia que culmina la
etapa de ejecución.
Mapeo de defectos

Una vez que se informa y se registra el defecto, debe mapearse con los casos de prueba
fallidos/bloqueados y los requisitos correspondientes en la Matriz de trazabilidad de
requisitos. Este mapeo lo realiza el Defect Reporter. Ayuda a hacer un informe de defectos
adecuado y analizar el producto. Una vez que los casos de prueba y los requisitos se
mapean con el defecto, las partes interesadas pueden analizar y tomar una decisión sobre si
reparar o diferir el defecto en función de la prioridad y la gravedad.

Volver a probar

Volver a probar es ejecutar una prueba fallida anteriormente contra AUT para verificar si el
problema se resolvió. Una vez que se ha solucionado un defecto, se realiza una nueva
prueba para verificar el escenario en las mismas condiciones ambientales.

Durante la nueva prueba, los tester buscan detalles granulares en el área modificada de la
funcionalidad, mientras que la prueba de regresión cubre todas las funciones principales
para garantizar que no se rompa ninguna funcionalidad debido a este cambio.

Pruebas de regresión

Una vez que todos los defectos están en estado cerrado, aplazado o rechazado y ninguno de
los casos de prueba está en estado de progreso/fallido/no ejecutado, se puede decir que la
prueba de integración del sistema se basa completamente en los casos de prueba y los
requisitos. Sin embargo, se requiere una ronda de pruebas rápidas para garantizar que
ninguna de las funciones se interrumpa debido a cambios en el código/arreglos de defectos.

Tipos de pruebas de regresión

Pruebas de regresión finales: se realiza una "prueba de regresión final" para validar la
compilación que no ha sufrido cambios durante un período de tiempo. Esta compilación se
implementa o envía a los clientes.

Pruebas de regresión: se realiza una prueba de regresión normal para verificar si la

compilación NO ha roto ninguna otra parte de la aplicación debido a los cambios recientes
en el código para corregir defectos o mejorar.

La ejecución de la prueba también ocurre en al menos 2 ciclos (3 en algunos proyectos).

Por lo general, en cada ciclo, se ejecutarán todos los casos de prueba (el conjunto de
pruebas completo). El objetivo del primer ciclo es identificar cualquier bloqueo, defectos
críticos y la mayoría de los defectos altos. El objetivo del segundo ciclo es identificar
defectos altos y medios remanentes, corregir lagunas en los guiones y obtener resultados.

Informe de estado de ejecución de prueba

Informe de ejecución de prueba diario/semanal:
 ¡Alerta de lenguaje técnico! Informe de estado de ejecución de prueba.
Por lo general, se trata de una comunicación enviada para establecer la transparencia de
las actividades del día del equipo de control de calidad durante el ciclo de prueba;
incluye información sobre defectos e información sobre la ejecución del caso de prueba.

¿A quién debería ir? – Normalmente, el equipo de desarrollo, el equipo de soporte del

entorno, el analista comercial y el equipo del proyecto son los destinatarios/participantes de
la reunión. El Plan de prueba es el mejor lugar para encontrar esta información.

¿Qué contiene un informe de estado de ejecución de prueba?

1. Número de casos de prueba planificados para ese día

2. Número de casos de prueba ejecutados ese día
3. Número de casos de prueba ejecutados en general
4. Número de Defectos encontrados ese día/y sus respectivos estados
5. Número de Defectos encontrados hasta el momento/y sus respectivos estados
6. Número de defectos críticos: aún abiertos
7. Tiempos de inactividad del entorno, si los hay
8. Showstoppers - si los hay
9. Adjunto de la hoja de ejecución de pruebas / Enlace a la herramienta de Gestión de
Pruebas donde se ubican los casos de prueba
10. Archivo adjunto al informe de error/enlace a la herramienta Defecto/Prueba/Gestión
utilizada para la gestión de incidentes

Los 10 puntos anteriores, si los miras de cerca, son los datos sin procesar. Reportar los
hechos es una cosa y reportar algunos hechos “inteligentes” es otra. ¿Cómo refinamos esta
información?

Muestra el estado general con un indicador de color. Por ejemplo: Verde: a tiempo;
Naranja: Ligeramente atrasado, pero puede absorber el retraso; Rojo: Retrasado.

Incluye algunas métricas simples como el % de casos de prueba aprobados hasta el

momento, la densidad de defectos, el % de defectos graves; Al hacer esto, no solo estás
dando números, en realidad estás dando una idea de la calidad del producto que está
probando.

 Si una fase significativa está completa, resaltala.

 Si hay un defecto crítico que va a bloquear toda/una parte de la ejecución futura,
resaltalo.
 Si usas una presentación, asegúrate de incluir algunos gráficos para tener un mejor
impacto.

Por ejemplo, el siguiente gráfico es una representación del número de defectos abiertos, por
módulo:
 Cuadro 15.1: número de defectos abiertos. Fuente: elaboración propia

Aparte de estos, también puedes incluir opcionalmente:

 ¿Cuáles son las próximas actividades previstas?

 ¿Necesitas algún aporte de alguno de los otros equipos y, de ser así, qué?

Por último, algunos consejos para ayudar en el proceso:

 Ser conciso a la vez que completo.

 Asegurate de que los resultados que informe sean precisos
 Usa puntos con viñetas para que el informe sea muy legible
 Vuelve a verificar para incluir la fecha, el asunto, la lista y los archivos adjuntos
correctos.
 Si el Informe es demasiado grande y tiene demasiados factores para informar:
colócalo en una ubicación común como un archivo y envía un enlace en el correo
electrónico en lugar del archivo en sí. (Asegúrese de que los destinatarios tengan
permisos de acceso a esta ubicación y al archivo)

Informe de estado de muestra

Informe de estado de las pruebas de control de calidad:

Siguiendo estas pautas, llegamos al siguiente informe de estado.

Actividades de cierre
Las actividades de cierre de prueba son aquellas actividades que se realizan al final del
proceso de prueba. Por lo general, se realizan después de que se entrega el producto, como
por ejemplo generar un informe de prueba. De acuerdo con el proceso de prueba, es
esencial garantizar que los procesos para entregar información de origen esencial para
evaluar los criterios de salida y los informes estén disponibles y sean efectivos.

Una vez que se declara finalizada la fase de ejecución de la prueba, se deben capturar los
resultados importantes para archivarlos o transmitirlos a la persona interesada.

Desde la fase de análisis de la prueba hasta la ejecución, pasando por el diseño y la

implementación, el Gerente de prueba debe asegurarse de que los miembros del equipo
proporcionen la información de manera correcta y oportuna. Esto es necesario para una
evaluación y un informe eficientes.

La tasa de informes y su profundidad dependen del proyecto y de la organización. Ambos

factores deben discutirse durante la planificación de la prueba después de las
conversaciones con las partes interesadas del proyecto.

Juntas, estas tareas forman las actividades de cierre de prueba, que se dividen en estos
cuatro grupos clave:

Comprobación de la finalización de las pruebas

Aquí, el administrador de pruebas se asegura de que todos los trabajos de prueba se hayan
completado realmente. Por ejemplo, cada prueba planificada debe haberse ejecutado o
evitado deliberadamente.

Todos los errores conocidos deben corregirse, aplazarse o reconocerse como limitaciones
permanentes. En caso de corrección de errores, las correcciones también deben probarse.
Entrega de objetos de prueba

Los productos de trabajo relevantes deben pasarse a las personas relevantes. Por ejemplo,
los errores conocidos deben comunicarse al equipo de mantenimiento del sistema.

Las pruebas y su información de configuración deben transmitirse al equipo de pruebas de

mantenimiento. Los conjuntos de pruebas de regresión manuales y automáticas deben
registrarse y transmitirse al equipo de mantenimiento del sistema.

Experiencia de aprendizaje

Un componente importante de las actividades de cierre de pruebas son las reuniones que
analizan y documentan las lecciones aprendidas de las pruebas, así como el ciclo de vida
completo del desarrollo de software.

Estas discusiones se enfocan en asegurar que los buenos procesos se repitan y los malos se
eliminen en el futuro. Si quedan algunos problemas sin resolver, se vuelven parte de los
planes del proyecto.

Algunas de las áreas consideradas en futuros planes de prueba incluyen:

1. ¿Se involucró un amplio espectro de usuarios en el análisis de los riesgos de

calidad? Por ejemplo, muchas veces se descubren defectos inesperados al final del
proyecto.
a. Podría haberse evitado si hubiera una representación más amplia de usuarios en las
sesiones de análisis de riesgos de calidad.
b. Por lo que, en futuros proyectos, se incluirían más usuarios en estas sesiones.
2. ¿Fueron correctas las estimaciones de la prueba? Si, por ejemplo, las estimaciones
han estado significativamente fuera de lugar, las futuras tareas de estimación deben
abordar las razones, como las pruebas ineficientes, detrás de esta estimación
incorrecta.
3. ¿Cuáles fueron los resultados del estudio de causa y efecto de los defectos y las
tendencias mostradas por ellos?
. Por ejemplo, si las solicitudes de cambio se propusieron tarde en el proyecto,
afectando la calidad del análisis y el desarrollo, Test Manager debe investigar las
tendencias que implican métodos incorrectos.
a. Estas tendencias podrían ser como perder un nivel de prueba que tenía el potencial
de identificar defectos antes, uso de nuevas tecnologías, cambio en los miembros del
equipo, falta de experiencia, etc.
4. ¿Hay margen para mejorar los procesos de prueba?
5. ¿Hubo alguna desviación inesperada del plan de prueba, que debería incorporarse en
la planificación de pruebas futuras?

Archivar

Los documentos de prueba como los informes y registros de prueba y los productos de
trabajo deben archivarse en el sistema de gestión de configuración. Es decir, tanto los
planes de prueba como los de proyecto, con una relación clara con la versión y el sistema
utilizado para la prueba, deben estar disponibles en el archivo de planificación.

Las tareas mencionadas anteriormente son muy importantes, pero los equipos de prueba
generalmente las pasan por alto. Por lo tanto, deben estar claramente integrados en el plan
de prueba.

Una o más de estas tareas pueden quedar fuera debido a cualquiera de estas razones:

 Reasignación inoportuna
 Eliminación de miembros del equipo.
 Demanda de recursos para otros proyectos
 Fatiga del equipo

Para garantizar la inclusión de estas tareas en el plan de pruebas, el contrato debe

mencionarlas explícitamente.

Control y monitoreo
El Monitoreo de Pruebas y el Control de Pruebas es básicamente una actividad de gestión.
El Monitoreo de Pruebas es un proceso de evaluación y retroalimentación sobre la fase de
prueba “actualmente en progreso”. Test Control es una actividad de guiar y tomar acciones
correctivas basadas en algunas métricas o información para mejorar la eficiencia y la
calidad.

La actividad de supervisión de pruebas incluye:

1. Proporcionar feedback al equipo y a los otros usuarios interesados en el

progreso de los esfuerzos de prueba.
2. Informar los resultados de las pruebas realizadas, a los miembros asociados.
3. Encontrar y rastrear las métricas de prueba.
4. Planificación y Estimación, para decidir el camino de acción futuro, en base
a las métricas calculadas.

Los puntos 1 y 2 hablan sobre los Informes de prueba, que es una parte importante del
Monitoreo de prueba. Los informes deben ser precisos y concisos. Aquí es importante
comprender que el contenido del informe difiere para cada parte interesada.

Los puntos 3 y 4 hablan de las métricas. Las siguientes métricas se pueden utilizar para la
supervisión de pruebas:

 Métrica de cobertura de prueba.

 Métricas de ejecución de pruebas (Número de casos de prueba aprobados,
fallidos, bloqueados, en espera).
 Métricas de defectos.
  Métricas de trazabilidad de requisitos.
 Métricas varias como el nivel de confianza de los tester, hitos de fecha,
costo, cronograma y tiempo de respuesta.

Métricas
Una métrica es una medida cuantitativa del grado en que un sistema, componente del
sistema o proceso posee un atributo dado. Las métricas se pueden definir como
"ESTÁNDARES DE MEDICIÓN".

Las métricas de software se utilizan para medir la calidad del proyecto. Simplemente, una
métrica es una unidad utilizada para describir un atributo. La métrica es una escala para
medir.

Supongamos que, en general, “Kilometro” es una métrica para medir el atributo

“Distancia”. De manera similar, en el software, "¿Cuántos problemas se encuentran en mil
líneas de código?", Aquí el número de problemas es una medida y el número de líneas de
código es otra medida. La métrica se define a partir de estas dos medidas.

¿Por qué probar métricas?

La generación de métricas de prueba de software es la responsabilidad más importante del

líder/gerente de prueba de software. Las métricas de prueba se utilizan para:

o Tomar las decisiones necesarias para la siguiente fase de actividades.

o Comprender qué tipo de mejora se requiere para el éxito del proyecto.
o Tomar una decisión sobre las modificaciones a realizar.

Importancia de las métricas de prueba de software:

Por ejemplo, un analista de pruebas tiene que:

1. Diseñar los casos de prueba para 3 requisitos.

2. Ejecutar estos 3 casos de prueba diseñados.
3. Registrar los errores, buggs o fallos encontrados en los casos de prueba
relacionados
4. Una vez resuelto volver a ejecutar el caso de prueba fallido correspondiente.

En el escenario anterior, si no se siguen las métricas, el trabajo realizado por el analista de

pruebas será subjetivo, es decir, el informe de pruebas no tendrá la información adecuada
para conocer el estado de su trabajo/proyecto.
Si las métricas están involucradas en el proyecto, entonces se puede publicar el estado
exacto de su trabajo con los números/datos adecuados. Es la manera en la que los tester
cuantifican las pruebas.

Control de pruebas
El Control de Pruebas implica orientar y tomar medidas correctivas de la actividad, con
base en los resultados del Monitoreo de Pruebas. Los ejemplos de control de prueba
incluyen:

1. Priorización de los esfuerzos de prueba

2. Revisión de los horarios y las fechas de las pruebas
3. Reorganización del entorno de prueba
4. Repriorización de los casos/condiciones de prueba

La supervisión y el control de las pruebas van de la mano. Al ser principalmente una

actividad de gerente, un Analista de Pruebas contribuye a esta actividad recopilando y
calculando las métricas que eventualmente se utilizarán para el seguimiento y el control.
 16

Una vez que hemos aprendido cómo funcionan los procedimientos y ciclos de prueba, al
ejecutar las pruebas deberemos reportar los errores encontrados. A continuación,
analizaremos cómo encontrar errores y cómo reportarlos efectivamente para lograr su
resolución, y así, aportar como tester, calidad al producto.

Proceso de gestión de defectos

La gestión de defectos es un proceso sistemático para identificar y corregir errores. Un
ciclo de gestión de defectos contiene las siguientes etapas:

Imagen 16.1: Ciclo de gestión de defectos. Fuente: elaboración propia

1. Descubrimiento
En la fase de descubrimiento, los equipos de proyecto tienen que descubrir tantos defectos
como sea posible, antes de que el cliente final pueda descubrirlos. Se dice que se descubre
un defecto y se acepta el cambio de estado cuando los desarrolladores lo reconocen y lo
aceptan.
 Imagen 16.2: Ciclo de gestión de defectos - Descubrimiento. Fuente: elaboración propia

2. Categorización
La categorización de defectos ayuda a los desarrolladores de software a priorizar sus tareas.
Eso significa que este tipo de prioridad ayuda a los desarrolladores a corregir primero
aquellos defectos que son muy cruciales.

3 Resolución de defectos
La resolución de defectos en las pruebas de software es un proceso paso a paso para
corregir los defectos. El proceso de resolución de defectos comienza con la asignación de
defectos a los desarrolladores, luego los desarrolladores programan el defecto para que se
solucione según la prioridad, luego se solucionan los defectos y finalmente los
desarrolladores envían un informe de resolución al administrador de pruebas. Este proceso
ayuda a corregir y rastrear defectos fácilmente.

Puedes seguir los siguientes pasos para corregir el defecto:

 Imagen 16.3: Pasos para la resolución de defectos. Fuente: elaboración propia

 Asignación: asignada a un desarrollador u otro técnico para que la corrija y cambie el

estado a Respondiendo.
 Calendarizar el arreglo: el lado del desarrollador se hace cargo de esta fase. Crearán un
cronograma para corregir estos defectos, dependiendo de la prioridad del defecto.
 Arreglar el defecto: mientras el equipo de desarrollo está reparando los defectos, el
administrador de pruebas realiza un seguimiento del proceso de reparación del defecto en
comparación con el cronograma anterior.
 Reportar la solución: obtenga un informe de la resolución de los desarrolladores cuando se
solucionen los defectos.

4.Verificación
Después de que el equipo de desarrollo soluciona e informa el defecto, el equipo de prueba
verifica que los defectos se hayan resuelto realmente.

5.Cierre
Una vez que se ha resuelto y verificado un defecto, el estado del defecto cambia a cerrado.
De lo contrario, debe enviar un aviso al desarrollo para verificar el defecto nuevamente.

6.Reporte de errores
 ¿Es lo mismo un reporte de errores o de incidencias?
Un informe de incidencias es un documento en el que se registran y detallan las
ocurrencias encontradas en una prueba. El informe de incidencias describe un fallo, no su
causa. La estructura de un informe de incidencias puede ser encontrada en el estándar
ISO/IEC/IEEE 29119-3:2013 que incluye plantillas y ejemplos de documentación de
prueba.

Elementos del reporte

Los reportes de testing deben ser comprensibles, ordenados, fiables, transparentes, ágiles,
consistentes, precisos, completos y trazables, por lo cual, deben gozar de información
pertinente y congruente para ayudar a todos en el equipo a entenderlos fácil y rápidamente.

En general incluyen los siguientes elementos:

 Caso de prueba (aporta todos los detalles respecto de las precondiciones)

 Resultado del defecto modo de fallo (usando una descripción del resultado obtenido
y el resultado esperado)
 Descripción de la desviación para facilitar su resolución (incluyendo informes,
capturas de pantalla, mensajes de error de la aplicación, etc.)
 Referencias cruzadas a informes relacionados.
 Origen del problema: se puede mostrar la trazabilidad hasta indicar donde es el
origen del problema
 Comentarios
 Acciones correctivas tomadas
 Hora y usuarios que ha realizado cambios
 Muchos sistemas hacen un seguimiento automático de cambios en el ciclo de vida
de incidente / error
 Registro histórico (history log)

Métricas de errores importantes

¿Cómo medir y evaluar la calidad de la ejecución de las pruebas?

Esta es una pregunta que todo Gerente de Pruebas quiere saber. Hay 2 parámetros que
puede considerar de la siguiente manera
 Imagen 16.4: Parámetros de reporte de errores. Fuente: elaboración propia

¿NECESITAS UN EJEMPLO?

Imagen 16.5: Ejemplo reporte de errores. Fuente: elaboración propia

En el escenario anterior, puede calcular que la tasa de rechazo de deserción (DRR) es 20/84
= 0,238 (23,8 %).
Otro ejemplo, supongamos que un sitio web tiene un total de 64 defectos, pero su equipo de
pruebas solo detectó 44 defectos, es decir, no detectaron 20 defectos. Por lo tanto, puede
calcular que la relación de fugas por defecto (DLR) es 20/64 = 0,312 (31,2 %).

Conclusión: la calidad de la ejecución de la prueba se evalúa a través de los siguientes dos

parámetros

Cuanto menor sea el valor de DRR y DLR, mejor será la calidad de la ejecución de la
prueba. ¿Cuál es el rango de relación que es aceptable? Este rango podría definirse y
aceptarse en base al objetivo del proyecto o puede consultar las métricas de proyectos
similares.

En este proyecto, el valor recomendado de relación aceptable es 5 ~ 10%. Significa que la

calidad de la ejecución de la prueba es baja. Debe encontrar una contramedida para reducir
estas proporciones, como

 Mejorar las habilidades de prueba de los miembros.

 Dedique más tiempo a probar la ejecución, especialmente a revisar los resultados de
la ejecución de la prueba.

Reportar un defecto paso a paso

1. Definir el error

El primer paso es definir el error escribiendo un resumen en el título y proporcionando una

descripción general del problema. Al escribir un resumen en el título del defecto, incluya el
área y la función donde ocurre el problema. ¿Por qué? Porque la mayoría de las
aplicaciones están altamente integradas y, por lo tanto, son complejas. Además, no puede
asumir que los desarrolladores u otros revisores de defectos saben cómo funciona la
aplicación en todos los casos.

La descripción irá seguida de detalles adicionales, así que sé breve y ve al grano. Puede ser
lo único que leen muchos revisores, por lo que es esencial describir el problema de manera
efectiva.

2. Investiga la causa raíz

La investigación significa asegurarse de que el error sea realmente un error. Querrá

verificar los ajustes de configuración, los ajustes del usuario, cualquier cosa en la
aplicación que afecte su funcionamiento. Haga todo lo posible para asegurarse de haber
establecido una base precisa. Busque declaraciones de registro de errores, si es posible.

Asegúrese de agregar cualquier investigación realizada al final de su informe de defectos en

un formato de nota.
Las "notas" son buenas maneras de comunicar a los desarrolladores la investigación que ha
realizado para que puedan determinar dónde deben comenzar.

3. Agregar documentación de respaldo

Agrega o adjunta un archivo de grabación de pasos o un video del defecto siempre que sea
posible. Si usa productos de Microsoft, hay una aplicación gratuita de grabadora de pasos
que puede usar para solucionar el problema. Creará una vista de captura de pantalla por
captura de pantalla de dónde hizo clic y la ubicación del código. Esto ayuda a los
desarrolladores a resolver el problema de manera más eficiente. Además, enumere los
resultados de las consultas de la base de datos o los archivos de registro de errores. Similar
a agregar una nota, esto brinda soporte de respaldo de que el defecto existe y no es solo un
problema de UI. Los cinco tipos de documentación de respaldo que se debe considerar usar
son:

 Archivos de la grabadora de pasos de Microsoft

 Video grabado de los pasos que toma y la reacción de la aplicación (elija entre
varios programas de video gratuitos disponibles en línea o simplemente use su
teléfono inteligente)
 Consulta de base de datos y captura de pantalla de los resultados.
 Capturas de pantalla o texto completo de los mensajes de error en la descripción o
como archivo adjunto
 Registros de errores, que existen para la mayoría de las aplicaciones,
independientemente de si son móviles, web o heredadas; adjunte una copia del
registro o copie y pegue el texto en su descripción; asegúrese de identificar qué
archivo de registro, si hay más de uno

4. Formatee su informe para una alta legibilidad

Proporcionar un formato comprensible hace que su defecto sea más fácil de revisar y más
probable que sea aceptado. Dé formato al texto del defecto separándolo en las siguientes
secciones:

Resumen (título)

Descripción

Compilación/plataforma

Pasos para reproducir

Resultados previstos

Resultados actuales

Investigar
 Documentación de soporte

La sección "compilación/plataforma" es opcional, según la aplicación que se esté

probando. Incluya esta sección cada vez que la aplicación se ejecute en más de una
plataforma o navegador, y anote la versión específica.

La sección "pasos para reproducir" debe ser precisa. Si no puede reproducir el defecto cada
vez, incluilo en el informe. Repetí los pasos para reproducir varias veces y verifique que
tiene los pasos y acciones correctos en el orden correcto que son necesarios para reproducir
el defecto. Al escribir los pasos para reproducir, tene en cuenta que es posible que los
desarrolladores no sepan cómo funciona la aplicación en general. Dales pasos detallados
pero concisos para que puedan reproducir el defecto.

Elementos importantes en el informe de errores

A continuación, se presentan las características importantes en el informe de error:

1. Número/id de error

Un número de error o un número de identificación (como swb001) hace que el informe de

errores y el proceso de referencia a errores sean mucho más fáciles. El desarrollador puede
verificar fácilmente si un error en particular se ha corregido o no. Hace que todo el proceso
de prueba y repetición sea más fluido y fácil.

2. Título del error

Los títulos de errores se leen con más frecuencia que cualquier otra parte del informe de
errores. Esto debería explicar todo sobre lo queincluye el error. El título del error debe ser
lo suficientemente sugerente para que el lector pueda entenderlo. Un título de error claro
hace que sea fácil de entender y el lector puede saber si el error se informó anteriormente o
se solucionó.

3. Prioridad

Según la gravedad del error, se puede establecer una prioridad para él. Un error puede ser
un Bloqueador, Crítico, Mayor, Menor, Trivial o una sugerencia. Las prioridades de errores
se pueden dar de P1 a P5 para que los importantes se vean primero.

4. Plataforma/Entorno

La configuración del sistema operativo y del navegador es necesaria para un informe de

error claro. Es la mejor manera de comunicar cómo se puede reproducir el error.
 Sin la plataforma o el entorno exactos, la aplicación puede comportarse de manera diferente
y es posible que el error del lado del tester no se replique del lado del desarrollador. Por lo
tanto, es mejor mencionar claramente el entorno en el que se detectó el error.

5. Descripción

La descripción del error ayuda al desarrollador a comprender el error. Describe el problema

encontrado. Una descripción deficiente creará confusión y hará perder el tiempo a los
desarrolladores y testers.

Es necesario comunicar claramente sobre el efecto de la descripción. Siempre es útil usar

oraciones completas. Es una buena práctica describir cada problema por separado en lugar
de desmenuzarlos por completo. No utilice términos como “Creo” o “Creo”.

6. Pasos para reproducir

Un buen informe de error debe mencionar claramente los pasos para reproducir. Estos
pasos deben incluir acciones que puedan causar el error. No haga declaraciones genéricas.
Sea específico en los pasos a seguir.

7. Resultado esperado y real

La descripción de un error está incompleta sin los resultados esperados y reales. Es

necesario delinear cuál es el resultado de la prueba y qué debe esperar el usuario. El lector
debe saber cuál es el resultado correcto de la prueba. Claramente, mencione lo que sucedió
durante la prueba y cuál fue el resultado.

8. Captura de pantalla

Una imagen vale más que mil palabras. Tome una captura de pantalla de la instancia de
falla con los subtítulos adecuados para resaltar el defecto. Resalte los mensajes de error
inesperados con color rojo claro. Esto llama la atención sobre el área requerida.

¿Cuáles son los estados de un defecto?

El número de estados soportados por herramientas es variable, veamos a continuación una
categorización de defectos en un ciclo:

Nuevo– el tester ha introducido un defecto en el sistema

Abierto– informe de problema confirmado (por el jefe de pruebas o desarrollador)

Rechazado– rechazado el informe del problema (por el tester, jefe de pruebas o

desarrollador)

Inspección– el desarrollador intenta identificar el defecto

En observación– el defecto no puede ser reproducido, se encuentra bajo vigilancia

Trabajo en progresión– el defecto es localizado y preparado/desbloqueado para su

corrección

Repetición de pruebas (retest)– el desarrollador ha corregido la causa del error y ha hecho

su prueba de escritorio (revisa que se cumpla el requerimiento y el error ya no esté)

Finalizado- tester ha verificado la corrección a través de la repetición de las pruebas

No resuelto– el tester no ha podido verificar la corrección, el defecto aún se encuentra ah

Análisis y modificación de estados

Normalmente el jefe de pruebas o responsable decide si un defecto debe ser corregido o

rechazado - de forma alternativa el consejo de control de cambio puede decidir sobre la
corrección de un defecto teniendo en cuenta el coste de reparación. En el caso en que no
haya un responsable de testing, muchas veces dicho rol es tomado por el líder de proyecto.

Todos los cambios (incluidos los comentarios) deben ser registrados en el sistema de
gestión de incidencias. Esto asegura el control continuo sobre el estado de corrección de un
defecto. Permite Pueden planificar las actividades de pruebas futuras

¡Sólo un tester puede poner un defecto en estado Finalizado!

Los informes de defectos son analizados de forma sistemática con el objeto de evaluar el
estado de desarrollo de las actividades de corrección de defectos conformidad con el plan
de proyecto y la calidad de software.

Preguntas para tener en cuenta:

 ¿Es perceptible una reducción en el número de detecciones de nuevos defectos? ¿o

se está incrementando el número a lo largo del ciclo de vida del proyecto?
 ¿Hay objetos de prueba particulares que presenten un alto número de defectos?
¿Hay algún objeto de prueba que presente un número de defectos más bajo que el
número medio de defectos?
 ¿Cuántos defectos de severidad alta / prioridad alta aún siguen abiertos?

 ¿Cuánto tiempo requiere la corrección de un defecto? ¿Cuál es el tiempo medio para

la corrección de defectos?