Lilian Sol

C.C 59.653.807 Ipiales-Nariño

Aprendiz
SENA Regional
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional

CALIDAD EN EL DESARROLLO DE SOFTWARE

PRUEBAS DE SOFTWARE

PRESENTADO POR:
LILIAN SOL NARVAEZ
59.653.807

ENTREGADO AL
INSTRUCTOR
CAMILO ANDRES GUTIERRES OVIEDO

SENA
IPIALES-NARIÑO
09-07-2021
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Pruebas de software

Hoy en día las pruebas de software son más complejas que nuca antes. La industria del software crece a una
velocidad altísima y los desarrolladores de software han de estar a la última de novedades y oportunidades en
el mundo del software para utilizar la última tecnología de la mejor manera. Por lo que esta vez, he decidido
hablar un poco más de la parte de testeo, que juega un rol crucial en las construcciones de plataformas
escalables de gran actuación.

Hay muchos tipos de negocio, pero en el desarrollo de software, la calidad es esencial para el éxito. Para
garantizar este éxito, la función de testeo es vital. Los tests de software ayudan a los equipos a evaluar el
software con los requerimientos e información recogida de los usuarios y el product owner, simplificando la
vida de los developers. Somos grandes fans de la metodología Ágil y creemos que para aplicar de manera
correcta esta metodología necesitas hacer TDD (Desarrollo guiado por pruebas) y CI (Integración continua).
Los test ágil forman uno de los roles más importantes de la metodología Ágil. Creemos que los test no
deberían separarse del proceso de desarrollo, como es hecho con modelos más tradicionales. El testeo de
software es una parte del proceso de desarrollo del mismo. Y los test deben ser escritos antes de escribir el
código para poder identificar los errores más rápidamente y corregirlos en el menor tiempo posible. El test de
software ayuda a reducir los riesgos de desarrollo, tiempo y costes.

Aún hay gente, que prefieren ahorrar dinero en el proceso de testeo. Y esto es un gran error!

Incluso aunque la inversión inicial pueda ser mayor, a largo plazo el mantenimiento de la plataforma y el
proceso de desarrollo es mucho más barato. Los test de software dan feedback rápido, por lo que todos los
amantes de la metodología Agile lo usan.

Hablamos con nuestro equipo de desarrollo de software y aunque haya docenas de diferentes tests en
internet, hemos subrayado 4 que creemos ser los más importantes y esenciales para construir software que
funciona. Tambien encontraras una lista de las mejores herramientas que utilizamos en nuestros proyectos.

Técnicas de pruebas de software esenciales para construir software que funciona.

1. Prueba unitaria

Empecemos con el primero y más pequeño de todos – prueba unitaria. La prueba unitaria se aplica en el
elemento más pequeño de un sistema, cada componente es testeado para asegurar que funciona
correctamente. Normalmente desarrolla una única función cohesiva. La función de la prueba unitaria es de
analizar cada pequeña parte y testear que funciona correctamente.
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
La prueba unitaria se usa mayormente por desarrolladores ágil, especialmente en programadores extremos,
los amantes del TDD. Sin embargo las pruebas unitarias son más populares hoy en dia y otros
desarrolladores están empezando a utilizarlo.

Herramientas de las pruebas unitarias: Junit, Phpunit, Mocha, Mockito, Chai, Sinon, Jasmine, Jest, Ava y
TestNG, Powermock, XCTest.

2. Pruebas de integración

La prueba de integración es una extensión lógica de las pruebas unitarias. Dos unidades que ya han sido
testeadas y combinadas en un componente y su interface son testeadas entre ellas. Un componente, en este
ejemplo, se refiere a un agregado que está integrado en más de una unidad, estas son combinadas en
componentes, que son agregadas por orden en partes más grandes del programa. El motivo de las pruebas
de integración es de verificar la funcionalidad y la seguridad entre los componentes que han sido integrados.
Identifica los problemas que ocurren cuando las unidades se combinan. Esto es particularmente beneficioso
porque determina cómo de eficientes son los tests trabajando juntos. Recuerda que no importante como de
eficiente cada test funcione, si no están propiamente integrados. Afecta a la funcionalidad del programa de
software. Además, es importante conocer que las pruebas de integración están basados en pruebas unitarias
con base de datos u otra biblioteca ajena de terceras partes.

Herramientas de pruebas de integración: Mocha, Jasmine, Jest y Ava.

3. Pruebas funcionales

Las pruebas funcionales se basan en asegurarse de que todas las características funcionen de cabo a rabo.
Por ejemplo, testear que las características de un usuario se actualicen cuando el usuario clicka en el botón
de guardar. Las pruebas funcionales testean una pequeña parte de la funcionalidad del sistema entera. Se
aplica para verificar que las aplicaciones y funcionalidades del software actúan correctamente acorde a un
diseño específico.

Las pruebas funcionales son elementos cruciales para asegurar la calidad del producto software y confirmar
que actúa acorde a sus funciones tal y como el usuario espera. Los test se utilizan para verificar que la
aplicación, página web ejecute sus funcionalidades a través de una respuesta adecuada a los controles de
usuario, una interfaz de usuario consistente, integración con otros sistemas y procesos de negocios, y manejo
adecuado de información y búsqueda.

Antes de empezar un proyecto, siempre nos aseguramos que empezamos a trabajar para crear las mejores
historias de usuario; corta, simple, características deseadas y descriptiva desde una perspectiva de usuario.
Las mejores historias de usuario son las más simples y normalmente tienen una forma muy entendible:

Como <type of user>, quiero <some goal> para que <some reason>

Por ejemplo,

Como estudiante, quiero notificaciones para que no olvide fechas de entrega.

Los test de funcionalidad testean este tipo de historias de usuarios. Otra forma de nombrar las pruebas
funcionales son los test de aceptación, test de consumidor, etc. Hay miles de versiones en internet, pero
creemos que “prueba funcional” es la mejor manera de nombrar a estos test.

Herramientas de pruebas funcionales: Jmeter, Gatling, Supertest, SoapUI, Cucumber, Robolectric, KIF.

4. Pruebas de rendimiento

Y la última es la prueba de rendimiento. En el desarrollo de software, la prueba de rendimiento es una práctica

de test que determina la actuación de un sistema en términos de respuesta y estabilidad en una carga de
trabajo en particular. También puede servir para investigar, medir, validar o verificar otros atributos de calidad
del sistema, como la escalabilidad, seguridad y uso de recursos.

Las pruebas de rendimiento construyen unos estándares de actuación en la implementación, diseño y

arquitectura de un sistema.
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Puede servir para verificar que una plataforma de software presenta las especificaciones del product owner.
Este test muestra como eficiente es un software. Chequea como de bien un software trabaja bajo una carga
máxima de trabajo. Hay varias variaciones o subtipos de pruebas de rendimiento como tests de carga, test de
estrés, test de volumen y muchas otras más. Estos métodos de tests de aseguran de que lo que se ha hecho,
se ha realizado correctamente, teniendo en cuenta las diferentes circunstancias que pueden aparecer en el
futuro.

Herramientas de pruebas de rendimiento: Jmeter, Gatling

 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional

Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo
objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte
interesada o stakeholder. Es una actividad más en el proceso de control de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del
tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de
desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno
corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

El objetivo de las pruebas es presentar información sobre la calidad del producto a las personas responsables
de este. Las pruebas de calidad presentan los siguientes objetivos: encontrar defectos o bugs, aumentar la
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
confianza en el nivel de calidad, facilitar información para la toma de decisiones, evitar la aparición de
defectos.

Teniendo esta afirmación en mente, la información que puede ser requerida es de lo más variada. Esto hace
que el proceso de testing sea completamente dependiente del contexto en el que se desarrolla.

El ambiente ideal de las pruebas es aquel que es independiente del desarrollo del software, de esta manera
se logra objetividad en las pruebas.

A pesar de lo que muchos promueven, no existen las "mejores prácticas" como tales. Toda práctica puede ser
ideal para una situación, pero completamente inútil o incluso perjudicial en otra.

Por esto, las actividades técnicas, documentación, enfoques y demás elementos que condicionarán las
pruebas a realizar deben ser seleccionados y utilizados de la manera más eficiente según contexto del
proyecto.

Proceso de Desarrollo de Software

Tenemos el proceso de desarrollo en cascada, se denomina de este modo, ya que a cada salida de una etapa
cae en la siguiente, es decir, las etapas se llevan a cabo una a continuación de la otra. Una de las
peculiaridades de este proceso, es que no está previsto volver a una etapa anterior, es decir si se olvidó
relevar algún requerimiento al comienzo, no tiene una alternativa para considerar este caso. Este proceso
supone cada etapa independiente de las etapas anteriores.

También tenemos el desarrollo iterativo y creciente, se tiene las mismas etapas que en el Proceso de
Desarrollo en Cascada, sin embargo, en este proceso, la etapa de relevamiento se divide en distintos sub
conjuntos, y cada uno de estos sub conjuntos se construye de la misma forma que con el ciclo de vida en
cascada. Se van desarrollando por partes que luego se integran, una vez finalizadas las mismas.

Otro Proceso de Desarrollo que tenemos es el Iterativo, en este tenemos las mismas etapas de desarrollo que
los procesos anteriores, pero trabajamos sobre el todo, no necesariamente conocemos al comienzo todos los
detalles del producto que queremos construir.

Y por último tenemos el desarrollo ágil de software, este es un proceso iterativo e incremental, se caracteriza
por contar con iteraciones cortas y por no tener fases lineales, tipo cascada en cada iteración. Existen
distintas metodologías Ágiles, que entre las más conocidas y utilizadas encontramos "Scrum" y "XP: Extreme
Programming".

Pruebas estáticas

Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.

Puede referirse a la revisión de documentos, ya que no se hace una ejecución de código. Esto se debe a que
se pueden realizar "pruebas de escritorio" con el objetivo de seguir los flujos de la aplicación.

Pruebas dinámicas

Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación.

Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con mayor amplitud. Debido a
la naturaleza dinámica de la ejecución de pruebas es posible medir con mayor precisión el comportamiento de
la aplicación desarrollada.

Pruebas contra Especificación (ESRE)

Antes de entender para que les sirve a los proveedores a trabajar con el documento de especificación de
requerimientos, debemos saber qué son las especificaciones de requerimientos (ESRE).

Las Especificaciones de Requerimientos son un documento clave en el desarrollo de Software. Cuando

consideramos los ciclos de vida clásicos, tiene la descripción completa de lo que va a hacer el sistema sin
describir cómo lo va a hacer. Estos documentos tienen una estructura en forma de reporte bastante definida,
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
poseen carátula, historial de cambios, introducción, definiciones, acrónimos y abreviaturas, especificación de
requerimientos funcionales, especificación de requerimientos no funcionales y casos de uso.

Los probadores beta se guían en este documento para validar si el sistema se comporta de la manera que
indican las ESRE. Contiene información detallada sobre los requisitos funcionales y no funcionales que el
Cliente desea en el sistema. También se pueden ejecutar casos de pruebas a partir de las especificaciones de
requerimientos ya que estos resultan muy útiles porque son sencillos de seguir y se conocen de antemano los
posibles resultados.

Tipos de pruebas por su ejecución

Pruebas manuales

Pruebas automáticas

Enfoques de pruebas

Pruebas de Caja blanca

Pruebas de Caja negra

Testing aleatorio

Clasificación de las pruebas según lo que verifican

Pruebas funcionales

Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las
funcionalidades previamente diseñadas para el software (requisitos funcionales). Hay distintos tipos como por
ejemplo:

Pruebas unitarias

Pruebas de componentes

Pruebas de integración

Pruebas de sistema

Pruebas de humo

Pruebas alpha

Pruebas beta

Pruebas de aceptación

Pruebas de regresión

Niveles de prueba

Podemos considerar el proceso de pruebas funcionales como un proceso donde se va probando inicialmente
lo de más bajo nivel y se van integrando y probando paulatinamente componentes hasta lograr un sistema
completo totalmente probado. Por eso se dice que hay distintos niveles de prueba. Se empieza por
las pruebas unitarias, luego las pruebas de Integración, luego las de pruebas de sistema, las de humo,
las alpha, las beta y finalmente las de pruebas de aceptación.

Las pruebas de regresión se puede considerar como la ejecución (normalmente automática) de las pruebas
ya realizadas hasta el momento.

Pruebas no funcionales

Una prueba no funcional es una prueba cuyo objetivo es la verificación de un requisito que especifica criterios
que pueden usarse para juzgar la operación de un sistema (requisitos no funcionales) como por ejemplo la
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
disponibilidad, accesibilidad, usabilidad, mantenibilidad, seguridad, rendimiento. Podemos clasificar las
pruebas no funcionales según el tipo de requisito no funcional que abarcan:

Pruebas de compatibilidad

Pruebas de seguridad

Pruebas de Estrés

Pruebas de usabilidad

Pruebas de rendimiento

Pruebas de internacionalización y localización

Pruebas de escalabilidad

Pruebas de mantenibilidad

Pruebas de instalabilidad

Pruebas de portabilidad

Herramientas para realizar pruebas de software

El control de la calidad de software lleva consigo aplicativos que permiten realizar pruebas autónomas y
masivas permitiendo así la verificación desde el punto de vista estático y de caja blanca, es decir pruebas
donde se analiza el software sin ejecutar el software mediante el código fuente del mismo. Podemos encontrar
herramientas escritas en software libre, código abierto o software privativo. Estas herramientas podrán ser
utilizadas para diferentes tipos de pruebas como por ejemplo:

Herramientas de gestión de pruebas

Herramientas para pruebas funcionales

Herramientas para pruebas de carga y rendimiento

Herramientas en código abierto

Herramientas de gestión de pruebas

Bugzilla Testopia

FitNesse

QaManager

QaBook

RTH.

Salome-tmf

Squash TM

Test Environment Toolkit

Test Link

Testitool

XQual Studio

Radi-testdir
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Data Generator

Herramientas para pruebas funcionales

Selenium

Soapui

Watir

WatiN (Pruebas de aplicaciones web en .Net)

Capedit

Canoo Web Test

Solex

Imprimatur

SAMIE

ITP

WET

WebInject

Herramientas para pruebas de carga y rendimiento

JMeter

Gatling

FunkLoad

FWPTT load testing

loadUI

Herramientas comerciales

Herramientas de gestión de pruebas

ApTest Manager

HP Quality Center/ALM

PractiTest

QA Complete

QAS.Test Case Studio

qaBook

SMARTS

Silk Central

SpiraTest

T-Plan Professional

TestLog
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Zephyr

Herramientas para pruebas funcionales

BASSP testConfig/testExecutor

Internet Macros

QA Wizard

QuickTest Pro

Ranorex

Rational Robot

Sahi

Silk Test

SoapTest

Squish

Test Complete

vTest

Herramientas para pruebas de carga y rendimiento

JMeter

ANTS – Advanced .NET Testing System

Forecast

HP LoadRunner

IBM Rational Performance Test (RPT)

Load Impact

LoadStorm

NeoLoad

Las pruebas de software (Software Testing) comprenden el conjunto de actividades que se realizan para
identificar posibles fallos de funcionamiento, configuración o usabilidad de un programa o aplicación, por
medio de pruebas sobre el comportamiento del mismo.

Los sistemas informáticos, programas y aplicaciones han crecido a niveles inimaginables en complejidad e
interoperabilidad, con lo cual también se han incrementado las posibilidades de defectos (bugs), a imple vista
insignificantes, pero que pudieran adquirir proporciones catastróficas.

Además factores como el uso de software de terceros desde aplicaciones móviles han añadido niveles
adicionales de complejidad y por ende incrementado los posibles puntos de fallas.

Frente a esto, el reto de los profesionales de Software Testing es modernizar sus metodologías, tecnologías y
herramientas que les permitan automatizar tareas, ejecutar ciclos de pruebas más rápidos y así reducir al
mínimo las posibilidades de errores en el Software.

A continuación pmoinformatica presenta una serie de recursos de apoyo al Software Tester para afrontar el
desafío de software desarrollado con agilidad y calidad.
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Tipos de pruebas de software

Como profesionales de Software Testing, el primer concepto que necesitamos manejar son los tipos de
pruebas que podemos realizar.

En la literatura existen diversas clasificaciones de los tipos de pruebas de software, por ejemplo pruebas
funcionales, pruebas de sistemas, pruebas no funcionales, pruebas de caja negra, pruebas de caja blanca,
entre otros.

Recientemente el ISTQB ha emergido como organización para definir estándares de software testing y en el
Syllabys del Nivel Foundation de su certificación, sección 2.3, quedan definidos los tipos de pruebas de
software según el ISTQB.

Otro aspecto a considerar es el auge que están teniendo las aplicaciones para dispositivos móviles, lo cual
abre toda una nueva gama de pruebas que debemos considerar en los planes de pruebas.

Tipos de pruebas de aplicaciones para celular

Una clasificación clásica para las pruebas de Software las divide en pruebas de caja negra y pruebas de caja
blanca. A continuación te compartimos un artículo sobre el tema:

Pruebas de caja negra según el ISTQB

También te compartimos algunos ejemplos de pruebas de caja negra:

Pruebas de caja negra: Ejemplos

Recursos para Software Testers

Aquí te compartimos recursos para presentar tu hoja de vida y también sobre las certificaciones ISTQB:

Todo profesional de Software Testing necesita presentar su hoja de vida y credenciales.

Modelo de curriculum vitae para Analista de QA

El ISTQB es una organización dedicada a la calificación y certificación de profesionales y empresas en el área

de Pruebas e Software, que ha ganado bastante prominencia en tiempos recientes.

5 preguntas y respuestas sobre ISTQB:

Aquí mostramos información sobre los niveles de certificación ISTQB.

Las certificaciones ISTQB:

Como realizar pruebas de Software

Identificar los requisitos del software

El proceso de Software Testing tiene su punto de partida en los requerimientos funcionales y no funcionales.
Aquí un modelo de matriz de trazabilidad de requisitos.

Elaborar los casos de uso o historias de usuario si estamos bajo metodología Agile
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Plantilla de casos de uso.

Plantilla de historias de usuario.

Luego se elabora el Plan de pruebas de software:

Hoy en día es indispensable contar con un Plan de Pruebas de Software para especificar minuciosamente las
funciones a probar, como serán ejecutadas esas pruebas, quienes serán los responsables y el cronograma
para su ejecución.

Aquí un método para levantar la información y elaborar el plan de pruebas de software: Pruebas de software:
10 pasos para elaborar el plan de pruebas

En toda planificación es necesario definir quién es responsable de que y a qué nivel.

Es por ello que esta plantilla de Matriz RACI puede ser de utilidad.

Seguidamente, es necesario realizar el Diseño de casos de prueba:

Especifica el área Funcional sujeta de pruebas, funcionalidad que se está probando, datos y acciones de
entrada, resultados esperados (salidas), requerimientos específicos del ambiente de pruebas o de
procedimiento, así como información para el seguimiento como el estatus actual.

Elaborar una Matriz de riesgos:

En esta se identifican y se definen planes de respuesta para los riesgos que puedan encontrarse durante el
ciclo de pruebas.

Las Herramientas para la gestión de pruebas de software

Son importantes para automatizar la gestión de casos de pruebas, defectos y su seguimiento. Hoy en día
existen numerosas herramientas en la nube que permiten gestionar diversas tareas.

Testing de Webservices usando SoapUI

Tutorial de SoapUI en español - Proyecto de ejemplo.

10 Ventajas de la automatización de pruebas de servicios web

5 Herramientas de testing de servicios web

Los servicios web se han convertido en componentes que deben incorporarse sin excepción en todo de
desarrollo de software empresarial, por lo cual se hace también importante desarrollar pruebas específicas
para asegurar la calidad con pruebas funcionales, de carga y seguridad.

La Automatización de pruebas de software.

Se ha venido convirtiendo cada vez más en una necesidad imperiosa, antes las demandas de los clientes de
ejecutar desarrollos cada vez más iterativos y rápidos. Aquí algunos recursos de utilidad:

10 Conocimientos para especializarte en automatización de pruebas de software

5 Herramientas para automatización de pruebas de software.

Ejemplo de Selenium Web Driver.

Software Testing con Selenium y Ruby.

Como instalar Selenium Web Driver y Ruby.

Testing de Aceptación automatizado con Selenium.

 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Selenium 2 para Automatización de pruebas de software.

Una vez comienza la ejecución de las pruebas del software, debe tomarse nota de los defectos y gestionar su
corrección. Esto se realiza por medio de la Gestión de defectos.

Al hacer seguimiento de los defectos, es importante tomar en cuenta todos los posibles casos emergentes
cuando se estén realizando correcciones, pues podrían surgir nuevos errores, o el mismo error podría no ser
corregido para todas las entradas posibles de datos. La no identificación de errores que todavía persisten es
la falla más frecuente que se observa en los sistemas de seguimiento de incidencias.

También durante la ejecución, deben elaborarse y presentar los Informes de avance

La fase de pruebas (Software Testing) suele ser crítica, y es un momento en el cual diversos interesados
(stakeholders) requieren información al minuto sobre el estado de la calidad del software que se está
desarrollando.

Cuando el Software ha sido extensivamente probado, lográndose un alto grado de funcionamiento, se

procede con las pruebas de aceptación, por medio de las cuales los usuarios validan y aceptan las
características funcionales y no funcionales del sistema.

Al concluir el ciclo de pruebas, se documenta las lecciones aprendidas

Son importantes para documentar que salió bien y que no tan bien, para aprender, replicar las buenas
situaciones o evitar las malas en el futuro.

7 herramientas de apoyo a pruebas de aplicaciones para celular

Pruebas de aplicaciones para celular en 6 pasos

Muchas empresas se están volcando al internet móvil desde aplicaciones para celular en busca de nuevas
oportunidades. El desarrollo de aplicaciones para celular supone nuevos retos, tanto en el área técnica como
en el aseguramiento de calidad de software.

Las pruebas de calidad de software en 10 pasos:

Frente a este reto que supone la complejidad del Software Testing hoy en día, se necesita una metodología
para las Pruebas de calidad de software estructurada y comprendida tanto por desarrolladores como
ingenieros de pruebas.

Que es el Agile Testing y cuáles son sus principios y estrategias:

Es una práctica de pruebas de software que sigue los principios del desarrollo ágil de software. El rol del tester
es el de un experto multifuncional, garante que se entregue el valor de negocio deseado por el cliente a un
ritmo sostenible y continuo.

Pruebas de software Agile: Planificar con los 4 cuadrantes del Agile Testing (1era parte):

Para aplicar el Agile Testing, se hace necesario contar con un marco de referencia para planificar las pruebas,
esto es precisamente lo que nos suministrar los 4 cuadrantes del Agile Testing.

Pruebas de software Agile: Planificar con los 4 cuadrantes del Agile Testing (2da parte):

Consejos y recomendaciones sobre cómo usar los 4 cuadrantes para definir el enfoque y plan de pruebas de
software agile.

Las diferencias de las pruebas ágiles de software respecto a enfoques predictivos tradicionales son
importantes, el Tester necesita mantenerse actualizado en las últimas técnicas y herramientas.

Vamos a aprender en qué consisten y en qué se diferencian tales tipos, como por ejemplo: unit testing,
integration testing, functional testing, acceptance testing, y muchos más.
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Existen muchos tipos de testing, o pruebas de software, que podemos usar para confirmar que nuestro
software continúa funcionando correctamente tras introducir cambios nuevos sobre nuestro código fuente.

No todas las pruebas son iguales. Es por ello que en este artículo vamos a ver cómo difieren las principales
pruebas de software.

Introducción

Muchas veces, cuando trabajamos de manera independiente en proyectos pequeños, no tenemos la

necesidad de (o el cliente no cuenta con el presupuesto para) escribir pruebas automatizadas.

Sin embargo, al empezar a trabajar en proyectos más grandes e integrarnos a equipos de trabajo más
amplios, notamos que muchas veces se habla de distintos tipos de tests.

Aunque suene increíble, muchas veces como desarrolladores tendemos a desarrollar nuevas características y
no conocemos muy bien lo que hace el equipo de QA, y no preguntamos, ya sea por falta de tiempo o porque
no queremos admitir lo poco que sabemos del tema.

Y así el tiempo avanza y no aprendemos las diferencias entre los tipos de testing que existen. Pero esto se
acaba hoy.

Aunque no vamos a escribir ni realizar pruebas en este artículo, sí que vamos revisar qué tipos existen y qué
busca lograrse con estas pruebas: para conocer mejor sus diferencias, y no sentirnos perdidos cuando estos
conceptos sean usados en una conversación.

Las personas pueden tener definiciones que difieren un poco entre sí, pero la idea general es la misma.

También hay que tener en cuenta que a veces los equipos se organizan para ejecutar conjuntos de pruebas.
A estos grupos de pruebas se les conoce como "test suites" e incluyen pruebas de los distintos tipos.

Por ejemplo, es posible ejecutar un "test suite" que englobe integration tests y regression tests.

También ten en cuenta que en algunos casos los equipos deciden "armar su propio vocabulario" y asignan
nombres a sus grupos de tests.

Pero bien. Volviendo al tema, debemos hacer testing a un nivel prudente, según:

La complejidad de nuestra aplicación, la cantidad de tráfico que nuestra aplicación recibe, y el tamaño de
nuestro equipo.

Manual vs Automated testing

De manera general, lo primero que debemos tener en cuenta es que existen pruebas de software manuales y
pruebas de software automatizadas.

Las pruebas manuales son llevadas a cabo por personas, quienes navegan e interactúan con el software
(usando herramientas adecuadas para cada caso).

Estas pruebas resultan costosas, ya que se requiere contar con un profesional encargado de esta labor; para
configurar un entorno y así mismo ejecutar las pruebas.

Como es de esperarse, estas pruebas están expuestas a errores humanos: por ejemplo, se pueden cometer
errores tipográficos u omitir pasos durante la prueba.

Las pruebas automatizadas, por el contrario, son realizadas por máquinas, que ejecutan un "test script" que
ya ha sido escrito previamente.

Estos tests (o pruebas) pueden variar mucho en cuanto a complejidad:

Desde verificar que el método de una clase específica funcione correctamente, hasta asegurar que una
secuencia de acciones complejas en la UI se lleven a cabo correctamente y devuelvan los resultados
esperados.
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Estas pruebas son más rápidas y confiables que las que se llevan a cabo manualmente – pero la calidad de
estas pruebas automatizadas depende de qué tan bien escritos se encuentren los "tests scripts" (código que
determina qué es lo que se hará en la prueba).

Automated testing es un componente clave para continuous integration y continuous delivery, y es una

excelente manera de escalar tus procesos de QA (quality assurance, aseguramiento de calidad) a medida que
agregas nuevas características a tu aplicación.

Aun así, son importantes las pruebas manuales para lo que se conoce como "exploratory testing" (lo veremos
más adelante en el artículo).

Los diferentes tipos de tests

Veamos los diferentes tipos de prueba que existen (hay más, pero éstas son las más importantes).

Unit tests

Las pruebas unitarias son a bajo nivel (cercanas al código fuente de nuestra aplicación).

Este tipo de testing consiste en probar de forma individual las funciones y/o métodos (de las clases,
componentes y/o módulos que son usados por nuestro software).

Debido a lo específicas que son, generalmente son las pruebas automatizadas de menor coste, y pueden
ejecutarse rápidamente por un servidor de continuous integration (integración continua).

Más detalles acerca de las pruebas unitarias:

Idealmente, cuando planeamos y escribimos pruebas unitarias, debemos aislar la funcionalidad hasta un
punto en que no se pueda desglosar más, y entonces escribir pruebas a partir de ello. Justamente, el nombre
de este tipo de testing hace referencia a una "unidad de código", que es independiente del resto.

Estas pruebas verifican que el nombre de la función o método sea adecuado, que los nombres y tipos de los
parámetros sean correctos, y así mismo el tipo y valor de lo que se devuelve como resultado.

Dado que las pruebas unitarias no deben tener ningún tipo de dependencia, se suele reemplazar los llamados
a APIs y servicios externos por funcionalidad que los imite (para que no exista interacción que vaya más allá
de la unidad que está siendo probanda).

En muchos casos inclusive se suele reemplazar las consultas a bases de datos, de modo que la prueba se
enfoque en operar a partir de los valores de entrada, sin depender de ninguna fuente externa.

Si no es factible aislar el uso de bases de datos de nuestras pruebas unitarias, será importante tener en
cuenta el rendimiento y buscar optimizar nuestras consultas.

Esto es importante, porque si nuestras pruebas unitarias son de larga duración, resultará incómodo
ejecutarlas y ralentizará significativamente los tiempos de desarrollo.

Cuando se habla de Test Driven Development (desarrollo guiado por pruebas), se hace referencia a unit
tests. Es decir, se usan pruebas de este tipo como especificaciones de lo que nuestro código debe hacer.

Integration tests

Las pruebas de integración verifican que los diferentes módulos y/o servicios usados por nuestra aplicación
funcionen en armonía cuando trabajan en conjunto.

Por ejemplo,

Pueden probar la interacción con una o múltiples bases de datos, o asegurar que los microservicios operen
como se espera.

Las pruebas de integración son típicamente el paso siguiente a las pruebas unitarias.
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Y son generalmente más costosas de ejecutar, ya que requieren que más partes de nuestra aplicación se
configuren y se encuentren en funcionamiento.

Functional tests

Las pruebas funcionales se centran en los requerimientos de negocio de una aplicación.

Estas pruebas verifican la salida (resultado) de una acción, sin prestar atención a los estados intermedios del
sistema mientras se lleva a cabo la ejecución.

A veces existe cierta confusión entre "integration tests" y "functional tests", ya que ambos requieren que
múltiples componentes interactúen entre sí.

La diferencia es que, una prueba de integración puede simplemente verificar que las consultas a una base de
datos se ejecuten correctamente, mientras que una prueba funcional esperaría mostrar un valor específico a
un usuario, en concordancia a lo definido por los requerimientos del producto.

End-to-end tests

Las pruebas de punta a punta replican el comportamiento de los usuarios con el software, en un entorno de

aplicación completo.

Estas pruebas verifican que los flujos que sigue un usuario trabajen como se espera, y pueden ser tan simples
como cargar una página web, iniciar sesión, o mucho más complejas, verificando notificaciones vía email,
pagos en línea, etcétera.

Las pruebas end-to-end son muy útiles, pero son costosas de realizar; y pueden ser difíciles de mantener
cuando son automatizadas.

Por tanto, es recomendable tener unas pocas pruebas end-to-end, que resulten claves para nuestra
aplicación, y confiar en mayor medida en las pruebas a bajo nivel (como pruebas unitarias y pruebas de
integración) para detectar rápidamente aquellos cambios que impactan negativamente sobre nuestra
aplicación.

Regression testing

Las pruebas de regresión verifican un conjunto de escenarios que funcionaron correctamente en el pasado,

para asegurar que continúen así.

No debemos agregar nuevas características a nuestro regression test suite hasta que las pruebas de
regresión actuales pasen.

Una falla en una prueba de regresión significa que una nueva funcionalidad ha afectado otra funcionalidad
que era correcta en el pasado, causando una "regresión".

Una falla en un test de regresión podría indicar también que hemos vuelto a producir un bug que ya había sido
resuelto en el pasado.

Smoke testing

Las pruebas de humo son pruebas que verifican la funcionalidad básica de una aplicación.

Se pretende que sean pruebas rápidas de ejecutar, y su objetivo es asegurar que las características más
importantes del sistema funcionan como se espera.

Los smoke tests pueden ser muy útiles: justo después de construir una nueva versión de nuestra aplicación,
para decidir si estamos listos para ejecutar pruebas más costosas, o justo después de un proceso de
deployment, para asegurar que la aplicación está funcionando adecuadamente en el nuevo entorno
desplegado.

Más detalles sobre los smoke tests:

 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Son un conjunto de pruebas automatizadas de alto nivel, y seleccionadas estrictamente.

Tienen lugar entre las pruebas de integración y las pruebas de regresión. Y están ahí para verificar que la
funcionalidad principal del sitio opera como es debido.

Se dice que el término "prueba de humo" tiene su origen en la plomería. Si se podía ver humo saliendo de una
tubería, significaba que tenía fugas y era necesario hacer reparaciones.

No son pruebas específicas. Son pruebas significativas que ocurren a un nivel más general. Idealmente deben
ejecutarse cada día, en cada uno de los entornos.

De modo que si un smoke test falla, significa que hay un grave problema con la funcionalidad de nuestro
software. Por tanto no deberíamos desplegar cambios nuevos hasta que los fallos sean atendidos. Y si fallan
en producción, su corrección tendrá la más alta prioridad.

Acceptance testing

Las pruebas de aceptación son pruebas formales, ejecutadas para verificar si un sistema satisface sus
requerimientos de negocio.

Estas pruebas requieren que el software se encuentre en funcionamiento, y se centran en replicar el

comportamiento de los usuarios, a fin de rechazar cambios si no se cumplen los objetivos. Estos objetivos
pueden ir más allá de obtener una respuesta específica, y medir el rendimiento del sistema.

Las pruebas de aceptación:

Son usualmente un conjunto de pruebas manuales que se realizan luego de que una fase de desarrollo ha
finalizado (de modo que se pueda volver rápidamente e iterar si algo no está correcto).

Verifican que las características de nuestro software estén alineadas con todas las especificaciones iniciales y
criterios de aceptación.

Suelen realizarse luego de las pruebas unitarias o de integración, para evitar que se avance mucho con el
proceso de prueba, y determinar a tiempo si se necesitan cambios significativos.

Para que este tipo de pruebas se lleve a cabo correctamente resulta importante que los responsables del
proyecto definan los criterios de aceptación justo antes de empezar a trabajar en el mismo. Así mismo,
cualquier requerimiento adicional que surja durante el proceso deberá verse reflejado en tales criterios de
aceptación.

Performance testing

Las pruebas de rendimiento verifican cómo responde el sistema cuando éste se encuentra bajo una alta
carga.

Estos tests son no-funcionales, y pueden tener diversas formas para entender la fiabilidad, estabilidad y
disponibilidad de la plataforma.

Por ejemplo, pueden observar los tiempos de respuesta cuando se ejecuta un alto número de requests
(consultas al servidor), o ver cómo se comporta el sistema ante una cantidad significativa de datos.

Las pruebas de rendimiento son, por su naturaleza, bastante costosas de implementar y ejecutar, pero
pueden ayudarnos a comprender si nuevos cambios van a degradar nuestro sistema (como hacerlo más lento
o aumentar su consumo de recursos).

Las pruebas de rendimiento no fallan del mismo modo en que lo hacen las demás pruebas. En vez de ello su
objetivo es recolectar métricas y definir objetivos por alcanzar.

Generalmente es buena idea realizar pruebas de este tipo ante nuevos lanzamientos y/o refactorizaciones
importantes en el código.

¿Por qué y cómo automatizar nuestras pruebas?

 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Una persona puede ejecutar todas las pruebas antes mencionadas, pero resultaría muy costoso y contra-
productivo hacer ello.

Como humanos, tenemos una capacidad limitada para realizar una gran cantidad de acciones, de manera
repetible y confiable. Pero una máquina puede fácilmente hacer ello, y probar que nuestro formulario de inicio
de sesión funciona correctamente, incluso en el intento #1000, y sin quejarse.

Para automatizar nuestros tests, primero necesitamos escribirlos mediante código de programación usando un
testing framework que se adapte a nuestra aplicación.

PHPUnit, Mocha, RSpec son ejemplos de testing frameworks, que podemos usar para escribir pruebas
automatizadas en PHP, Javascript, y Ruby respectivamente.

Existen muchas opciones por cada lenguaje.

Si nuestras pruebas pueden iniciarse ejecutando un script desde la terminal, entonces podemos ejecutarlas
también usando un servidor de continuous integration o un servicio en la nube dedicado a ello. Estas
herramientas pueden monitorear nuestros repositorios y ejecutar nuestro test suite (conjunto de pruebas) cada
vez que nuevos cambios sean subidos.

Exploratory testing

Mientras más características y mejoras agreguemos a nuestro código, mayor será la necesidad de escribir
tests para asegurar que nuestro sistema funcione apropiadamente.

Así mismo, cada vez que corregimos un bug es prudente comprobar que otros que teníamos anteriormente no
vuelvan a aparecer.

Automatizar es clave para hacer esto posible, y escribir pruebas (tarde o temprano) será parte de nuestro
development workflow.

Entonces la pregunta es: ¿vale la pena hacer pruebas manuales hoy en día?

Y la respuesta es: sí, y deben enfocarse en lo que se conoce como "exploratory testing", donde el objetivo es
descubrir errores que no son muy obvios.

Una sesión de pruebas exploratorias no debería exceder de 2 horas, y es necesario tener bien definido el
alcance, para ayudar a los evaluadores a centrarse en un área específica del software.

Una vez que todos los testers (evaluadores) han sido informados, depende de ellos probar varias acciones
para verificar cómo se comporta el sistema.

Este tipo de pruebas resulta costoso por naturaleza, pero permite descubrir errores en la UI y verificar flujos
complejos que siguen los usuarios.

Resulta útil principalmente cuando se agrega una nueva característica importante a nuestra aplicación, para
ayudar a comprender cómo se comporta en casos extremos.

Conclusión

Así como es importante verificar que nuestros usuarios pueden usar nuestra aplicación (pueden iniciar sesión,
enviar mensajes, y/o actualizar datos), es igual de importante verificar que nuestro sistema siga funcionando
adecuadamente cuando se ingresen datos incorrectos o se realicen acciones inesperadas.

Necesitamos anticipar qué ocurrirá cuando un usuario cometa un error ingresando datos incoherentes, intente
guardar un formulario sin completar todos los campos, o vaya de un paso a otro sin seguir una secuencia, con
o sin malas intenciones.

Así mismo, necesitamos verificar si es posible para un usuario comprometer datos (es decir, tener acceso a
recursos que no deben).

Entonces:
 Lilian Sol
C.C 59.653.807 Ipiales-Nariño
Aprendiz
SENA Regional
Un buen conjunto de pruebas debería "romper nuestra aplicación" y ayudarnos a entender sus límites.

Y por último, las pruebas son código también, por lo que no debemos olvidarlas durante los "code review", ya
que son un paso importante para el pase a producción.