1- Testing

2- Pruebas Exploratorias

¿Qué es Testing Exploratorio?

El testing exploratorio es un enfoque o técnica de prueba muy poderoso, ya que

otorga plena libertad de probar y se le considera un aliado perfecto para el ritmo de
trabajo de un equipo ágil.

¿Cuándo es recomendable realizar Pruebas Exploratorias?

● Cuando se quiere aprender rápidamente del producto.

● Al proveer feedback de un producto nuevo o de alguna funcionalidad de un
producto; en este caso en concreto, probar una historia de usuario.
● Cuando se desea ampliar la cobertura de las pruebas, por ejemplo, si se
cubre una parte del testing con casos de pruebas o pruebas automatizadas,
es factible buscar bugs o nuevos flujos con este enfoque.
● Para mejorar las pruebas existentes, es posible crear nuevos flujos o
alternativos no considerados en el set de pruebas y mejorar las pruebas
obsoletas.
● Es de utilidad en las pruebas de regresión cuando se requieren resultados
rápidos y es necesario comprobar que la aplicación y/o el sistema no fue
afectado con la última versión subida; el testing exploratorio es apropiado
para definir flujos críticos o buscar bugs.
Beneficios del Exploratory Testing

Al trabajar dentro de un equipo ágil, las principales ventajas son las siguientes:

1. Entregar feedback anticipadamente

No es necesario finalizar el proceso de pruebas para entregar feedback, día a día se

pueden ir proponiendo mejoras.

2. Tomar decisiones en tiempo real

Cuando se trabaja en un equipo ágil, es fácil estar al tanto de los cambios o mejoras
que se implementarán en el equipo y así poder adaptar internamente las pruebas.

3. Llegar donde la automatización no puede llegar

Los testers pueden pensar como un usuario.

4. Entregar resultados en un menor tiempo

Es posible informar al equipo cómo van las pruebas diariamente, o bien, en el

momento que se estime necesario.
Notas de Pruebas

Las notas son de suma importancia para el tester, pues ahí registra todo lo que se
considera importante durante la exploración.

Riesgos

Apuntar todos los riesgos identificados durante la sesión de pruebas.

Defectos

Registrar los identificadores (IDs) o la descripción de los incidentes encontrados.

Inconvenientes

Anotar todo inconveniente o impedimento que haya surgido durante la sesión.

Después de exponer los puntos claves para documentar una sesión, a continuación se
muestra el registro de una sesión empleando el enfoque de testing exploratorio ágil.

Notas de Pruebas

Las notas son de suma importancia para el tester, pues ahí registra todo lo que se

considera importante durante la exploración.

Riesgos

Apuntar todos los riesgos identificados durante la sesión de pruebas.

Defectos

Registrar los identificadores (IDs) o la descripción de los incidentes encontrados.

Inconvenientes

Anotar todo inconveniente o impedimento que haya surgido durante la sesión.

Después de exponer los puntos claves para documentar una sesión, a continuación se

muestra el registro de una sesión empleando el enfoque de testing exploratorio ágil.

Ejemploo

3- Pruebas de Interfaz Gráfica

¿Qué son las pruebas de GUI?

La prueba de GUI es un proceso de prueba de la interfaz gráfica de usuario de la

aplicación para garantizar la funcionalidad adecuada según las especificaciones.
Implica verificar los componentes de la aplicación como botones, íconos, casillas de
verificación, color, menú, ventanas, etc.

Prueba de funcionalidad

Prueba de diferentes funciones a lo largo de la aplicación. Implica validar todas las

navegaciones, así como todos los valores de campo que están presentes en las
páginas frontales, utilizando todos los escenarios positivos y negativos.

Pruebas de UI

Probar el factor de apariencia de la página web. El factor de apariencia incluye el

tipo de pantalla, fuente, alineación, botón de radio, casilla de verificación, etc.

● Las áreas cubiertas en las pruebas de IU son usabilidad, apariencia,

controles de navegación / barras de navegación, instrucciones y estilo de
información técnica, imágenes, tablas, accesibilidad, etc.
● Para probar la accesibilidad, tenemos que verificar las pautas de
accesibilidad al contenido de W3C-Web.
Defectos habituales en la interfaz de usuario
● Problemas de alineación de botones
● Espacio inconsistente entre etiquetas o cuadros de texto
● Etiquetas rotas, es decir, etiqueta de una sola línea que se muestra en dos
líneas
● Desalineación entre cuadros de texto, iconos de información, etiquetas o
menús desplegables
● Superposición de campos
● Campos incompletos
● Los datos de la página están desalineados; algunos desplazados en el
tiempo hacia arriba o hacia abajo
● En cualquier navegador, al seleccionar alguna acción, la acción
correspondiente no está sucediendo
● Cambiar el tamaño no funciona como se esperaba
● El tiempo de caducidad de la sesión es muy corto o muy largo para algunos
navegadores
● Problemas específicos del navegador: pocos campos no se pueden editar
después de ingresar datos en un navegador, pero se pueden editar en otro
navegador.
Requisitos clave de la prueba de usabilidad y la interfaz de usuario
Los requisitos clave de pruebde la aplicación web son:

1. Disponibilidad de varios componentes en una interfaz de usuario

2. Varios estados del componente UI

Componente:

Un componente es un bloque de construcción, que se puede usar con la

combinación de varios otros componentes para formar una aplicación. Los
componentes se pueden reutilizar en toda la aplicación.

Los ejemplos de un componente incluyen Botón, Campo de texto, Sugerencia

automática, Casilla de verificación, Menú desplegable, etc.Algunos componentes
basicos

Caja: Se pueden seleccionar una o más opciones del componente de casilla de

verificación

Botones de radio: Cuando solo es necesario seleccionar una opción, los botones de
opción son útiles

ad
Algunos componentes avanzados
1. Acordeón: Se pueden apilar varios elementos verticalmente con este
componente. Cada elemento se puede expandir para ver su contenido. También se
puede ampliar más de un elemento.

2. Pan rallado: Este es un componente muy útil que ayuda en la navegación del sitio
web. El usuario puede identificar su ubicación actual dentro del sitio web desde este
componente.

ad

3. Carrusel: Se pueden incorporar varios conjuntos de elementos de información en

un componente de carrusel. Los buscadores de caminos en la parte inferior indican
que hay más elementos presentes. Las flechas ayudan en la navegación dentro del
carrusel. Por lo general, la navegación del carrusel se configura como un bucle
continuo.
ad
Hacer clic aquí para obtener más información útil sobre los componentes de la
interfaz de usuario

Estados de los componentes de la interfaz de usuario

La disponibilidad de componentes se basa exclusivamente en las pautas de
requisitos del proyecto. Variará de un proyecto a otro.

Los distintos estados de la interfaz de usuario para un componente básico son:

1. Estado sin llenar

2. Estado lleno y enfocado
3. Estado normal y estado predeterminado
4. Estado de desplazamiento
5. Estado discapacitado
6. Estado enmascarado

ad
Estado sin llenar:

Antes de introducir cualquier valor en un componente, se dice que es un estado sin

completar. El estado Sin relleno muestra el texto del marcador de posición, si lo hay.
El siguiente es un componente de campo de texto.
Estado lleno:

Un componente con un valor introducido por el usuario se llena en estado.

ad
En el estado de enfoque:

El usuario vuelve a visitar un componente que ya está lleno. El componente debe

mostrar el cursor, lo que indica que el componente específico que se está enfocando

Estado normal:

La visualización de un componente con el valor ya ingresado por el usuario en la

pantalla se describe el estado normal.

ad
Estado predeterminado:

Un componente que muestra el valor autocompletado del servidor / backend. El

usuario también puede editar este valor en algunos escenarios.

Estado de desplazamiento:

El desplazamiento del mouse sobre el componente resalta el componente que

indica la acción de desplazamiento.
Antes de Hover:

En vuelo estacionario:

ad

Cuál Es El Mejor Software De Eliminación De Virus

Estado discapacitado:

El componente está deshabilitado y el usuario no puede editar los campos.

Estado habilitado

Estado discapacitado

ad

Estado enmascarado:

Los datos sensibles como la contraseña se pueden ocultar con este componente.

Los requisitos clave de prueba de USABILIDAD de la aplicación web son:

1. Familia tipográfica
2. Tamaño de fuente
3. Color
4. Espaciado de letras
 5. Altura de la línea
6. Validación de antecedentes
7. Relleno / Opacidad
8. Medidas de los componentes como largo, ancho y ancho.
9. Ubicación / espacio entre los componentes en una pantalla

ad
Las características de usabilidad anteriores se pueden probar en el código o
utilizando el elemento inspeccionar en la aplicación. Otra forma más sencilla es
utilizar complementos. Los complementos pueden variar según el navegador en el
que se deba probar la aplicación.

Detalles de varios complementos del navegador

Nombre Detalles de uso Compatibilidad

Regla de Este complemento ayuda a probar la anchura y Chrome y

página la altura de los componentes. Las posiciones Firefox
superior, izquierda, derecha e inferior de los
componentes también se pueden calcular

Web El inspector web muestra la fuente, el color del Chrome y Safari

Inspector texto y el color de fondo del simplemente
haciendo clic en el icono del inspector web y
colocándolo sobre la sección que se va a
probar.

Insecto de Firebug es un complemento de código abierto Firefox

fuego para monitorear CSS, HTML, DOM, XHR y
JavaScript de la página web. Esta es una
alternativa del elemento inspeccionar,
compatible con Firefox.

ColorZilla Es un complemento de selector de color que se Chrome y

utiliza para analizar el color de la página web. Firefox
 Mídelo Se utiliza para probar el ancho, alto y alineación Chrome, Safari y
de elementos en píxeles. Firefox

ad
Ventajas de los complementos:

● Ahorra tiempo
● Fácil de usar
● Es rentable
Limitación de complementos:

● Error de paralaje al usar la medición

● Compatible con todas las aplicaciones
● Compatible con varios navegadores
Referencias para complementos:

● Web Inspector: Herramientas de desarrollo de Apple

● Firebug: Wiki Firebug
● Mídelo
● Colorzilla
ad
Herramientas de prueba de GUI
Hay varias herramientas disponibles en el mundo de la tecnología que ayudarían a
los evaluadores en las pruebas de IU.

● Selenio
● Pruebas funcionales unificadas de HP
● Pepino
● IU codificada
● Realmente
¡Una lista detallada de herramientas GUI está disponible en
softwaretestinghelp.com! Por favor haz click aquí .

Ejemplos de casos de prueba de GUI

1) Verificar el funcionamiento de las flechas del carrusel y los buscadores de
caminos

2) Verifique que el campo de contraseña acepte valores solo en un estado

enmascarado

3) Verifique que el botón 'guardar' permanezca inactivo hasta que se ingresen todos
los campos obligatorios

4) Verifique que el usuario pueda navegar a la parte superior de la página usando la

barra 'Superior'
5) Verifique que se muestre el mensaje correcto cuando los filtros aplicados no
recuperen ningún resultado

6) Verificar la navegación desde los enlaces disponibles en Encabezados y pies de

página

7) Verifique que la alineación de los botones de radio sea precisa

8) Verifique que se puedan seleccionar múltiples opciones en las casillas de

verificación a la vez

9) Verifique que el título de cada sección esté en negrita

10) Verifique el cambio de color de los hipervínculos al hacer clic

Botones más comunes

1. Buttons (Botones)

2. Drag & Drop (arrastra y suelta)

3. Navigation Bar (Barra de Navegación)

4. Accordion (Acordión)

5. Input Box o Input Fields o Text Box o Text Fields (campos con entrada texto editables)

6. Slider (Control deslizador)

7. Bento Menu (Menú de grillas)

8. Hamburger Menu (Menú hamburguesa)

9. Meetball Menu (Menú de bolas de carne)

10. Kebab Menu (Menú de brocheta)

11. Doner Menu (Menú de Doner)

12. Breadcrumb (Migaja de Pan)

13. Card (tarjeta - informativa)

14. Carousel (Carrusel)

15. Checkbox (cajita de chequeo)

16. Comment box (caja de comentario)

17. Dropdown - Menu, List, Button (Desplegable)

18. Feed (es una sección)

19. Form (Formulario - conjunto de inputs)

20. Icon (ícono)

21. Loader (cargador de una página)

22. Pop-Up (ventana emergente)

23. Notification (Notificaciones)

24. Picker (Selector de fechas)

25. Progress Bar (Barra de progresos)

26. Radio Buttons (Botones de Radio)

27. Search Bar o Search Field (Barra o Campo de Búsqueda)

28. Sidebar Navigation (barra lateral - barra vertical de navegación)

29. Stepper (lo mismo que Progress Bar pero con pasos predefinidos)

30. Tag (Etiqueta)

31. Tab o Tab Bar (Pestaña para seleccionar y abrir)

32. Tootltip (mini mensaje de info)

33. Toggle (como "Switches" - botón de On-Off)

34. Banners (rectángulo con contenido o mensaje normalmente con interacción)

35. Hero Banner (Imagen Principal de portada o fondo)

36. Footer (Pie de Página)

37. Header (cabecera)

38. Body (cuerpo de página)

4- API testing postman

¿Qué son las APIs y para qué sirven?

Las interfaces de programación de aplicaciones conocidas comúnmente como

APIs (Application Programming Interfaces) son un conjunto de comandos,
funciones y protocolos que permiten la comunicación entre softwares.
Por ejemplo, cuando un desarrollador está trabajando en una aplicación o en la web
de una tienda online, no necesita crear desde cero el sistema de pago y control de
stock, ya que esto le llevaría demasiado tiempo. En cambio, es posible que pueda
conectar el sistema a una API de terceros que cumple dicha función de sistema de
pago y control de stock.

Ahora bien, ¿qué ventajas tiene esto? Básicamente, el proceso de desarrollo va a

ser mucho más rápido y menos costoso, al aprovechar la infraestructura ya
existente.

¿Qué son los Web Services?

De esta forma, adentrados en qué es una API, hablaremos de una parte de ellas: los
Web Services o Servicios Web.

Los Web Services son un conjunto de estándares y protocolos para

intercambiar datos entre aplicaciones. Esto suena muy similar a la definición de
API, ¿verdad? Y es que efectivamente un Servicio Web es una API que se conecta
a la aplicación pero a través de internet.

Entonces, ¿cuál es la diferencia entre una API y un Web Services? Como

mencionamos en líneas anteriores, un Web Service es una API pero que se ofrece
solamente a través de internet, o sea de HTTP; en cambio las API pueden utilizar
cualquier otro protocolo de comunicación.
Aplicación web conectada a un sistema externo a través de HTTP.

¿Cómo integrarse con un Web Service?

Basándonos en la gráfica anterior, en donde por un lado se encuentra la aplicación

web y por otro el sistema externo al que se conectará, se presenta el siguiente
escenario: ¿qué sucede si la aplicación está desarrollada con un lenguaje de
programación en específico, y el otro sistema está desarrollado con un lenguaje
diferente?, ¿cómo va a ser posible la comunicación entre sí?

Pongamos un ejemplo simple, una persona que habla solamente español que trata
de comunicarse con otra persona que solo habla inglés, la comunicación va a ser
imposible, en este caso lo mejor es tener un lenguaje intermedio, un lenguaje que
ambas partes puedan entender.

En los Web Services, el lenguaje intermedio sería a través de XML con el protocolo
SOAP. Otra forma de comunicación posible es a través de la arquitectura REST,
aplicando el lenguaje XML o JSON. En este contexto, ¿de qué va a depender si la
comunicación se hará a través de SOAP o REST? La respuesta es que dependerá
de cómo esté desarrollado el Web Service.

SOAP y REST

SOAP es un protocolo diseñado para poder facilitar la comunicación entre

plataformas, basado en XML y en otro lenguaje denominado WSDL. Del mismo
modo, REST es una arquitectura más moderna y liviana, y es la más común en la
que se prueba actualmente.

El hecho de que la arquitectura REST utilicé lenguaje JSON la hace más reducida y
fácil de utilizar. Una gran ventaja de REST es que tiene operaciones bien definidas
como son GET, POST, PUT, PATH y DELETE, siendo estas las más comunes y que
detallamos a continuación.

Métodos HTTP

Métodos HTTP más utilizados en las pruebas de API REST.

Debemos utilizar GET para leer la información de la API, POST en el caso que
debamos crear información nueva, utilizar PUT y PATCH para modificar y actualizar
información y DELETE en el caso que debamos eliminar información.

¿Qué es el API Testing?

Ya vimos bastante teoría sobre las API y los Web Services, ahora entra en juego el
rol del tester para explicar en detalle en qué consiste el tema central de este post:
API test.
De acuerdo a la Pirámide de Automatización, API Testing es un tipo de prueba de
software que está dentro de los tipos de pruebas de integración.

Lo que hace API Testing es validar y verificar que las funcionalidades responden
correctamente, por lo que se considera un tipo de prueba a bajo nivel, es decir, que
no interactúa directamente con la interfaz de usuario.

En el caso de que estemos probando una API REST, cuando interactuamos con un
Web Services por HTTP, ¿cómo sabemos que los resultados son correctos?
Básicamente, por las respuestas de los códigos de estado cuando consultan
información a la API.

El flujo consiste en enviar los datos de entrada, la API REST la procesa y se obtiene
como resultado la salida con los siguientes códigos de respuesta:

● Códigos 200: cuando son respuestas exitosas

● Códigos 300: cuando son mensajes de redirección
● Códigos 400: cuando son errores del cliente
● Códigos 500: cuando existen problemas con el servidor
Para resumir, ¿por qué hacer API testing? ¿Cuáles son los beneficios de probar
esto? Veamos sus principales ventajas a continuación.

Beneficios de API Testing

Promueve el Shift Left Testing

No es necesario contar con el producto totalmente terminado para comenzar a

probar, basta con tener conexión a las API para ir probando sus funcionalidades.

Mantenimiento sencillo

Al ser más sencillo que las pruebas de interfaz de usuario, lo ideal es tener pruebas
de API robustas para que las pruebas de interfaz de usuario sean solamente
preventivas.

Sabemos que las pruebas de interfaz de usuario son cambiantes y hay que
re-escribirlas y mantenerlas constantemente. En cambio, con las pruebas de API es
poco frecuente que se produzcan cambios y en caos que haya algún cambio es más
fácil poder controlarlo.

Mayor velocidad de ejecución

¿Sabía que es posible probar 300 pruebas de APIs en tres minutos

aproximadamente? Eso significa que existe más tiempo para corregir y más tiempo
para probar.

Reducción de errores

Al estar probando y corrigiendo en una capa intermedia, van a mejorar los

resultados de las pruebas en general.

Integración del trabajo

Foto de Fauxels en Pexels

Como testers, al probar una API se necesitará mucho apoyo de parte del equipo de
desarrollo, y por consiguiente, podrá conocer la parte más técnica del proyecto.

Tipos de Pruebas API

En las API no solamente podemos ejecutar pruebas funcionales, también es posible

ejecutar otro tipo de pruebas que nos van a ser útiles para potenciar la calidad de
las pruebas. A continuación, voy a comentar alguna de ellas. Es importante tener
presente que siempre el tipo de prueba que vamos a utilizar va a depender del tipo
de API que estemos probando.
Pruebas Funcionales

En este tipo de pruebas vamos a validar las funcionalidades de la API, por ejemplo
al contar con una API REST, primero se validan los códigos de estado para saber
que la API se encuentra disponible. También es posible validar las operaciones
dependiendo de los casos de prueba, aunque no siempre es recomendable confiar
en las pruebas de interfaz de usuario, por lo que realizar uno que otro flujo a nivel de
API permite validar el correcto funcionamiento.

Pruebas de Seguridad

Para estas pruebas es posible probar la autenticación, si utiliza algún tipo de key o
token, verificar que no cualquiera pueda utilizar la API, verificar si hay datos
sensibles encriptados, entre otras aspectos. Lo anterior es lo más básico que se
debe verificar en cuanto a seguridad.

Si queremos ser un poco más exhaustivos y tener un tipo de checklist de seguridad,

podemos aplicar el Top 10 API Security de OWASP. Es recomendable que la
aplicación de estos criterios deba realizarse en conjunto con el área de desarrollo o
seguridad, al ser pruebas mucho más técnicas.

Pruebas de Rendimiento

En este punto aparecen distintos tipos de pruebas de rendimiento, tales como:

pruebas de carga, pruebas de estrés, pruebas de escalabilidad, pruebas de
volumen, etc. Estas pruebas sirven para validar la carga de usuarios y que la API
pueda responder correctamente a dicha carga.

Pruebas de Integración

Para validar la integración, podemos hacerlo verificando la integración con otras API
integradas en un mismo proyecto.

Documentación

La documentación es muy importante al momento de probar; no podemos comenzar

a probar APIs si no tenemos documentación asociada a ella. Contar con
documentación representa un significativo ahorro de tiempo y esfuerzo, tanto para el
tester como para el desarrollador.
Herramientas para API Testing

Cuando hablamos de herramientas para probar, siempre vienen a la cabeza las más
populares: SoapUI y Postman.

SoapUI

Primero hablemos de SoapUI, una herramienta desarrollada en Java que

inicialmente se utilizaba para probar servicios SOAP pero que luego se
extendió para los servicios REST. Si bien SoapUI cuenta con una versión pagada,
la versión gratuita contiene todo lo necesario para probar, se puede integrar con
scripts de pruebas con lenguaje Groovy, y en definitiva es una de las herramientas
más poderosas en el mercado.

Sin embargo, no es una herramienta muy intuitiva, en especial para aquellos que
están iniciándose en el mundo del API testing, por lo que va a ser necesario requerir
algún curso o tutorial guiado sobre cómo utilizarla.

Postman

Por otro lado tenemos Postman, una herramienta que principalmente se utiliza
para probar API de tipo REST. Postman es una herramienta muy completa que
además de probar, documentar y ayudar incluso en el proceso de desarrollo de
APIs, sirve para automatizar: se pueden agregar scripts de prueba en lenguaje
JavaScript.

Una de las ventajas de Postman frente a SoapUI, es que su interfaz de usuario es

mucho más amigable e intuitiva, dispone de colecciones y agrupaciones de
peticiones, lo que la hacen más simple de entender, incluso para aquellos que están
recién comenzando.
5- Pruebas datos SQL
¿Qué necesito para usar SQL?

SQL por si mismo nos va a permitir acceder a la base de datos y manipular datos,
pero para aprovechar la base de datos, necesitamos otras herramientas que
conectarán con nuestra base de datos, consultarán, mostrarán, modificarán o
borrarán datos.

Sintaxis básica SQL; Cláusulas comunes, declaraciones y Operadores

Tablas de base de datos

Los datos se almacenan en objetos llamados Tablas. Una tabla es una colección de
entradas de datos relacionados y consiste en Columnas. Las bases de datos
suelen contener una o varias Tablas y cada Tabla se identifica por un nombre (por
ejemplo,

‘Clientes’). Las tablas contienen registros (o filas) de datos.

A continuación se muestra un ejemplo de una tabla de base de datos denominado

Clientes. La tabla contiene tres registros (uno para cada persona) y cinco columnas:

Tabla Clientes

Instrucciones SQL básicas

La mayor parte de las acciones que debe llevar a cabo en una base de datos se
hacen con sentencias SQL.

Algunos puntos clave a tener en cuenta antes de continuar:

● SQL no distingue entre mayúsculas y minúsculas.

● Algunos sistemas de bases de datos requieren un punto y coma al final
de cada sentencia SQL. Punto y coma es la forma estándar para
separar cada instrucción SQL en sistemas de bases de datos que
permiten a múltiples sentencias que se ejecutan en la misma llamada al
servidor.
● El asterisco (*) es una forma rápida de seleccionar todo.
● SQL utiliza comillas simples alrededor de valores de texto (la mayoría
de los sistemas de bases de datos también aceptar doble citas). Sin
embargo los valores numéricos no deben ir entre comillas.
 ● El signo de porcentaje (%) se utiliza para definir los patrones (letras en
el patrón de falta) y puede ser usado tanto antes como después de las
letras (cadenas).

SQL SELECT

La sentencia SQL SELECT se usa para seleccionar datos de una base de datos. El
resultado es almacenado en una tabla llamada Result-Set. La sintaxis es la
siguiente:

SELECT nombre_columna

FROM nombre_tabla

Como alternativa, podemos cambiar nombre_columna por un asterisco (*) para que
la consulta nos devuelva todas las columnas.

Por ejemplo, sobre la base de datos anterior:

Tabla Clientes

Si queremos obtener el contenido de las columnas ‘Lastname’ y ‘Firstname’,

deberíamos usar la sentencia Select de la siguiente manera;

SELECT LastName, FirstName FROM Clientes

Y obtendríamos:

SELECT LastName, FirstName FROM Clientes

Si lo que queremos es obtener el contenido de todas las columnas de la tabla

Clientes, usaríamos la siguiente sentencia:

SELECT * FROM Clientes

Dónde el resultado sería:

 Tabla Clientes

SQL SELECT DISTINCT

La sentencia SQL SELECT DISTINCT se usa para seleccionar sólo los valores
individuales de una base de datos que puede contener valores duplicados. La
sintaxis es la siguiente:

SELECT DISTINCT nombre_columna

FROM nombre_tabla

Por ejemplo, siguiendo con nuestro ejemplo, partiendo de la misma tabla:

Tabla Clientes

Si lo que queremos saber es que valores DISTINTOS tiene la columna ‘City’, lo

haríamos ejecutando la siguiente sentencia:

SELECT DISTINCT City

FROM Clientes

Y el resultado sería el siguiente:

SELECT DISTINCT City FROM

Clientes

SQL WHERE

La sentencia SQL WHERE se usa para seleccionar sólo las filas de una base de
datos que tienen un criterio determinado. La sintaxis es la siguiente:
SELECT nombre_columna

FROM nombre_tabla

WHERE nombre_columna operador valor

Cuando usamos la cláusula WHERE, podemos usarla con los siguientes

operadores:

● = Igual
● <> No Igual (En algunas versiones de SQL se puede encontrar como
!=)
● < Menor que
● > Mayor que
● <= Menor que o igual
● >= Mayor que o igual
● BETWEEN Entre 2 valores
● LIKE Busca un determinado patrón
● IN Especifica múltiples posibles valores para una columna

Por ejemplo, siguiendo con nuestro ejemplo, partiendo de la misma tabla:

Si lo que queremos es seleccionar sólo la gente que vive en London, usaríamos la

siguiente cláusula WHERE como parte de la sentencia SELECT. Lo haríamos
ejecutando la siguiente sentencia:

SELECT *

FROM Clientes

WHERE City ='London'

Y el resultado sería el siguiente:

SELECT *
FROM Customers WHERE City = ‘London’
Si quisiéramos seleccionar sólo la gente cuyos nombres comienzan con la letra H,
usaríamos la siguiente cláusula y operador WHERE como parte de la sentencia
Select

SELECT *

FROM Clientes

WHERE FirstName Like'H%'

Y el resultado sería el siguiente:

SELECT * FROM Clientes WHERE FirstName LIKE ‘H%’

6- Prueba E2E
¿Qué son las pruebas de extremo a extremo?

Las pruebas de extremo a extremo son una metodología de prueba de software

para probar el flujo de una aplicación de principio a fin. El propósito de esta prueba
es simular el escenario del usuario real y validar el sistema bajo prueba y sus
componentes para la integración y la integridad de los datos.

ad
Se realiza de principio a fin en escenarios del mundo real, como la comunicación de
la aplicación con hardware, red, base de datos y otras aplicaciones.
La razón principal para llevar a cabo esta prueba es determinar varias dependencias
de una aplicación, así como garantizar que se comunique información precisa entre
varios componentes del sistema. Por lo general, se realiza después de completar las
pruebas funcionales y del sistema de cualquier aplicación.

Tomemos un ejemplo de Gmail:

ad
La verificación de extremo a extremo de una cuenta de Gmail incluirá los
siguientes pasos:

1. Lanzamiento de una página de inicio de sesión de Gmail a través de URL.

2. Iniciar sesión en la cuenta de Gmail con credenciales válidas.
3. Accediendo a la Bandeja de entrada. Abrir correos electrónicos leídos y no
leídos.
4. Redactar un nuevo correo electrónico, responder o reenviar un correo
electrónico.
5. Abrir elementos enviados y consultar correos electrónicos.
6. Comprobación de correos electrónicos en la carpeta Spam
7. Cerrar sesión en la aplicación Gmail haciendo clic en 'cerrar sesión'

Herramientas de prueba de extremo a extremo

Herramienta recomendada:

# 1) TestCraft
Recomendamos utilizar una herramienta de automatización de pruebas de un
extremo a otro como TestCraft.

ad
TestCraft es una plataforma de automatización de pruebas de selenio sin código. Su
revolucionaria tecnología de inteligencia artificial y el modelado visual único
permiten una creación y ejecución de pruebas más rápidas al tiempo que eliminan la
sobrecarga de mantenimiento de las pruebas.

Los probadores crean escenarios de prueba totalmente automatizados sin

codificación. Los clientes encuentran errores más rápido, lanzan con más
frecuencia, se integran con el enfoque CI / CD y mejoran la calidad general de sus
productos digitales. Todo esto está creando una experiencia de prueba completa de
principio a fin.

=> Visite el sitio web de TestCraft

¿Cómo funciona la prueba de extremo a extremo?

Para entender un poco más, averigüemos ¿Cómo funciona?

Ads by optAd360
Toma unejemplode la industria bancaria. Pocos de nosotros debimos haberlo
probado Cepo. Cuando el titular de una cuenta Demat compra cualquier acción, se
le debe entregar al corredor un porcentaje particular de una cantidad. Cuando el
accionista vende esa acción, ya sea que obtenga ganancias o pérdidas, un
porcentaje particular de la cantidad se le da nuevamente al corredor. Todas estas
transacciones se reflejan y gestionan en cuentas. Todo el proceso involucra la
Gestión de Riesgos.

Cuando miramos el ejemplo anterior, teniendo en cuenta la prueba de extremo a

extremo, veremos que todo el proceso incluye varios números, así como diferentes
niveles de transacciones. Todo el proceso involucra muchos sistemas que pueden
ser difíciles de probar.

Métodos de prueba E2E

# 1) Prueba horizontal:

Este método se utiliza con mucha frecuencia. Ocurre horizontalmente en el contexto

de múltiples aplicaciones. Este método puede ocurrir fácilmente en una sola
aplicación ERP (Enterprise Resource Planning). Tomemos un ejemplo de una
aplicación basada en la web de un sistema de pedidos en línea. Todo el proceso
incluirá cuentas, estado de inventario de los productos y detalles de envío.

ad
# 2) Prueba vertical:

En este método, todas las transacciones de cualquier aplicación se verifican y

evalúan desde el principio hasta el final. Cada capa individual de la aplicación se
prueba de arriba a abajo. Tome un ejemplo de una aplicación basada en web que
utiliza códigos HTML para llegar a los servidores web. En tales casos, se requiere
API para generar códigos SQL contra la base de datos. Todos estos escenarios
informáticos complejos requerirán una validación adecuada y pruebas dedicadas.
Por tanto, este método es mucho más difícil.

‘ Prueba de caja blanca ’ así como también ‘ Prueba de caja negra ’ ambos están
asociados con esta prueba. O, en otras palabras, podemos decir que esta es la
combinación de beneficios tanto de las pruebas de caja blanca como de las pruebas
de caja negra. Dependiendo del tipo de software que se esté desarrollando, en
diferentes niveles, tanto las técnicas de prueba, es decir, las pruebas de caja blanca
como las de caja negra, se utilizan cuando sea necesario. Básicamente, la prueba
de extremo a extremo funciona tan bien como el enfoque arquitectónico de cualquier
software o programa para validar las funciones del sistema.

ad
Los probadores como la verificación de extremo a extremo porque la escritura de
casos de prueba del usuario ’ s perspectiva y en un escenario del mundo real,
puede evitar los dos errores comunes. ‘ falta un error ’ y ‘ escribir casos de prueba
que no verifican escenarios del mundo real ’ . Esto proporciona a los probadores
una inmensa sensación de logro.

A continuación se enumeran algunas pautas que deben tenerse en cuenta al

diseñar los casos de prueba para realizar este tipo de pruebas:

● Los casos de prueba deben diseñarse desde la perspectiva del usuario final.
● Debería centrarse en probar algunas características existentes del sistema.
● Se deben considerar múltiples escenarios para crear múltiples casos de
prueba.
● Deben crearse diferentes conjuntos de casos de prueba para centrarse en
múltiples escenarios del sistema.
A medida que ejecutamos cualquier caso de prueba, es similar el caso con esta
prueba. Si los casos de prueba son 'Pasados', es decir, obtenemos el resultado
esperado, se dice que el sistema ha superado con éxito la prueba de extremo a
extremo. Del mismo modo, si el sistema no produce el resultado deseado, entonces
se requiere una nueva prueba de un caso de prueba teniendo en cuenta las áreas
de falla.

ad
¿Por qué realizamos las pruebas E2E?
En el escenario actual, como también se muestra en el diagrama anterior, un
sistema de software moderno comprende su interconexión con múltiples
subsistemas. Esto ha hecho que los sistemas de software modernos sean muy
complicados.
Estos subsistemas de los que estamos hablando pueden estar dentro de la misma
organización o en muchos casos también pueden ser de diferentes organizaciones.
Además, estos subsistemas pueden ser algo similares o diferentes al sistema
actual. Como resultado, si hay alguna falla o falla en cualquier subsistema, puede
afectar negativamente a todo el sistema de software y provocar su colapso.

Estos importantes riesgos pueden evitarse y controlarse mediante este tipo de

pruebas:

● Mantenga un control y realice la verificación del flujo del sistema.

● Aumente las áreas de cobertura de prueba de todos los subsistemas
involucrados con el sistema de software.
● Detecta problemas, si los hay, con los subsistemas y, por lo tanto, aumenta la
productividad de todo el sistema de software.
ad
A continuación se mencionan los Algunas actividades que se incluyen en el
proceso de un extremo a otro:

● Un estudio exhaustivo de los requisitos para realizar esta prueba.

● Adecuado configuración de entornos de prueba.
● Un estudio exhaustivo de los requisitos de hardware y software.
● Descripciones de todos los subsistemas, así como del principal sistema de
software involucrado.
● Enumere los roles y responsabilidades de todos los sistemas y subsistemas
involucrados.
● Los métodos de prueba utilizados en esta prueba, así como los estándares
que se siguen, su descripción.
● Diseño de casos de prueba y seguimiento de la matriz de requisitos.
● Registre o guarde los datos de entrada y salida de cada sistema.
Marco de diseño de pruebas E2E
7- Re-Testing bug
¿Qué son las pruebas de regresión o regression testing?

Es un tipo de prueba que se realiza para confirmar que un cambio reciente no ha

afectado las características existentes de un sistema. En estas pruebas se
seleccionan todos o algunos de los casos de prueba que ya han sido ejecutados y
se vuelven a ejecutar para garantizar que las funcionalidades existentes, es decir,
las que no han sido cambiadas, funcionen correctamente.

¿Qué son las pruebas de confirmación o re-testing?

Es un tipo de prueba que se realiza para confirmar que los defectos que se habían
encontrado y reportado anteriormente ya no estén presentes, en un caso más
amplio se podría decir, que los casos de pruebas que habían fallado antes, puedan
pasar sin problemas luego de que una solución haya sido aplicada.
Pero veamos con mayor detalle una comparación entre estos dos tipos de prueba.

8- Regresión Testing
Las pruebas de regresión (en raras ocasiones, las pruebas de no regresión [1] ) consisten
en volver a ejecutar pruebas funcionales y no funcionales para garantizar que el software
desarrollado y probado previamente siga funcionando después de un cambio. [2] Si no, eso
se llamaría una regresión .

Técnicas [ editar ]
Las diversas técnicas de prueba de regresión son:

Vuelva a probar todo [ editar ]

Esta técnica verifica todos los casos de prueba en el programa actual para verificar su
integridad. Aunque es costoso ya que necesita volver a ejecutar todos los casos, asegura que
[9]
no haya errores debido al código modificado.

Selección de prueba de regresión [ editar ]

A diferencia de Retest all, esta técnica ejecuta una parte del conjunto de pruebas (debido al
costo de volver a probar todo) si el costo de seleccionar la parte del conjunto de pruebas es
[9]
menor que la técnica Retest all.

Priorización de casos de prueba [ editar ]

Priorice los casos de prueba para aumentar la tasa de detección de fallas de un conjunto de
pruebas. Las técnicas de priorización de casos de prueba programan los casos de prueba para
que los casos de prueba que tienen una prioridad más alta se ejecuten antes que los casos de
[9]
prueba que tienen una prioridad más baja.

Tipos de priorización de casos de prueba [ editar ]

● Priorización general: priorice los casos de prueba que serán beneficiosos en

versiones posteriores
● Priorización específica de la versión: priorice los casos de prueba con respecto a una
versión particular del software.

Híbrido [ editar ]
Esta técnica es un híbrido de selección de pruebas de regresión y priorización de casos de
[9]
prueba.

Beneficios y desventajas [ editar ]

Las pruebas de regresión se realizan cuando se realizan cambios en la funcionalidad existente
del software o si hay una corrección de errores en el software. Las pruebas de regresión se
pueden lograr a través de múltiples enfoques; si se sigue un enfoque de prueba total , se brinda
certeza de que los cambios realizados en el software no han afectado las funcionalidades
[10]
existentes, que permanecen inalteradas.
En el desarrollo de software ágil, donde los ciclos de vida del desarrollo de software son muy
cortos, los recursos son escasos y los cambios en el software son muy frecuentes, las pruebas
[10]
de regresión pueden generar muchos gastos generales innecesarios.
En un entorno de desarrollo de software que tiende a usar componentes de caja negra de un
tercero, realizar pruebas de regresión puede ser complicado, ya que cualquier cambio en el
componente de terceros puede interferir con el resto del sistema (y realizar pruebas de regresión
[10]
en un tercero). componente del partido es difícil, porque es una entidad desconocida).
9- Smoke Testing

PAPEL DE LAS PRUEBAS DE HUMO

La prueba de humo El ciclo que realizan los equipos de control de calidad en el

entorno de prueba asegura que si la compilación implementada está logrando el
objetivo principal y si debe probarse más a fondo o no. En otras palabras, si la
compilación falla en el escenario de prueba de la funcionalidad principal, el equipo
de control de calidad la rechazará de inmediato y dejarán de probarla. Está
diseñado para garantizar la funcionalidad principal de la nueva construcción.
Este tipo de proceso y método de verificación también verifica la estabilidad y el
aspecto funcional completo de la construcción y si falla la prueba de humo, entonces
no tiene sentido seguir adelante con la prueba.
Por lo tanto, en pocas palabras, las pruebas de humo son muy prometedoras para
confirmar si una compilación es lo suficientemente estable como para seguir
probando.
También, lea: Las grandes novedades de CodeIgniter 4

RESUMEN DE LAS PRUEBAS DE HUMO

Con prueba de humo, la mayoría de los problemas de compilación se pueden

identificar en las primeras etapas del desarrollo del programa y pueden ser útiles
para la corrección de los mismos, por lo que se puede decir que las pruebas de
humo son una prueba de regresión frecuente de las funcionalidades principales y se
manifiesta si la compilación es listo para llevar a cabo más pruebas.
Los desarrolladores pueden adoptar este método y la compilación pasa la prueba,
entonces solo se puede implementar para más pruebas; de lo contrario, se debe
rechazar.
Aquí hay una representación pictórica de lo anterior:
Copiar infografía

Copy to Clipboard
¿CUÁNDO HACER LA PRUEBA DE HUMO?

Prueba de humo debe realizarse en la fase inicial del ciclo de vida de prueba, ya
que verifica muy pronto la productividad de la construcción y asegura si los
requisitos elementales se pueden cumplir o no. Siempre qupe se implemente una
compilación nueva o se realice algún cambio en la compilación, se deben realizar
pruebas de humo.
El desarrollo de software siempre se divide en diferentes sprints para que se cubran
todos los rincones por lo que es importante que cada sprint tenga un código estable
por lo que la prueba de humo toma muy poco tiempo para cumplir con esta
necesidad antes de la prueba de regresión y, de esta manera, también ahorramos
nuestro precioso tiempo también.
El objetivo de las pruebas de humo es probar las funcionalidades importantes
nooode un sistema y no ejecutar los escenarios de prueba exhaustivos.
También, lea: 7 señales de que su empresa necesita actualizarse a un nuevo CRM

¿Y SI NO HAY PRUEBA DE HUMO?

Es necesario que cada compilación nueva que se implemente se pruebe

agresivamente con pruebas de humo porque es posible que sin ella, ciertos errores
críticos no se detectarían y pueden ser un obstáculo más adelante en otros ciclos de
prueba. También es posible que sin la prueba de humo, se pueda generar un error
de integración.

BENEFICIOS DE LAS PRUEBAS DE HUMO

A. Identificación de problemas importantes en la fase de prueba inicial que ahorra

tiempo.
B. Garantía de estabilidad para realizar más pruebas.
C. Implementación de productos de calidad a un ritmo más rápido, ya que ofrece
comentarios rápidos.
D. Suaviza la integración y facilita el seguimiento del progreso del desarrollo.

PASOS A SEGUIR PARA LAS PRUEBAS DE HUMO

A. Realice pruebas de humo en la fase inicial del proyecto.

B. Mantenga constantemente todas las pruebas de humo.
C. No debería llevar mucho tiempo.
D. Deben realizarse escenarios de prueba para cada despliegue y sprint.
E. Si es posible, automatice los escenarios de prueba de humo para reducir aún
más el tiempo y el costo.
F. Realice esta prueba para todas las funciones clave de la compilación
implementada.
TIPOS

Taquí hay tres tipos de pruebas de humo, a saber: - Método manual, método de
automatización y método híbrido.
El método manual es el método de prueba de humo más comúnmente utilizado bajo
el cual los casos de prueba de humo se prueban manualmente para la construcción
nueva y las características recién agregadas. Aquí, los scripts deben modificarse en
función de cada requisito.
Las pruebas de humo de automatización también se aplican cuando necesitamos
usar el lote de casos de prueba automatizados y la compilación se puede probar de
inmediato cada vez que se encuentra un problema nuevo.
Las pruebas de humo híbridas, como su nombre indica, son la fusión de ambas
metodologías mencionadas y su objetivo es mejorar el rendimiento general de las
pruebas de humo.
10- aplicaciones para móviles

Tipos de Aplicaciones Móviles

Las aplicaciones móviles no son tan sencillas de probar como las aplicaciones web
de escritorio; se dividen en tres tipos: Nativas, Híbridas y Web.

Aplicaciones Nativas

Una aplicación nativa es la que se ejecuta en el dispositivo de manera más rápida y

avanzada en cuanto a las funciones, por lo que se debe descargar antes de usar.
Dado que son aplicaciones específicas para una plataforma, se deben desarrollar
utilizando IDEs y lenguajes específicos.

Android utiliza lenguajes como Java o Kotlin y Android Studio, o Eclipse como IDE;
por su parte, Apple utiliza lenguajes como Objective-C o Swift y XCode como IDE.

Algunos ejemplos de aplicaciones Nativas son Google Maps, LinkedIn, Twitter,

Telegram, PokemonGo, etc.

Aplicaciones Web

Una aplicación web es a la que se puede acceder a través de cualquier navegador

móvil; esto significa que no se requiere descargarla al dispositivo para comenzar a
usarla. Al igual que las aplicaciones web, las aplicaciones web móviles
generalmente se crean utilizando JavaScript, CSS y HTML5.
Algunos ejemplos de aplicaciones Web son wordpress.com, Medium.com y
emol.com.

Aplicaciones Híbridas

Una aplicación híbrida combina las características de las aplicaciones web y nativas.
Usualmente es desarrollada como una aplicación móvil web utilizando JavaScript,
CSS y HTML5. Al ser empaquetadas en un entorno nativo, se puede utilizar el
mismo código para diferentes plataformas. Este tipo de aplicaciones se deben
descargar al igual que las aplicaciones nativas.
Algunos ejemplos de aplicaciones híbridas son Facebook, Instagram, Uber y Slack.

¿Qué considerar al realizar App Testing?

Como testers, debemos tener en cuenta las siguientes consideraciones antes de

comenzar a probar una aplicación móvil:

¿Cuál es el tipo de App que se probará?

Como se mencionó anteriormente existen 3 tipos de aplicaciones móviles: Nativas,

Híbridas y Web; conocer esta información, ayudará a definir qué tipos de pruebas se
pueden realizar.

¿En qué versiones del Sistema Operativo funcionará la App Móvil bajo
prueba?

Se debe tener claro que versiones de iOS y Android se deben cubrir. Esta
información deberá ser entregada por el Cliente o por el Equipo de Desarrollo.

¿En qué dispositivos se probará la Aplicación Móvil?

Independiente del tipo de aplicación móvil que se probará, se debe definir un set de
dispositivos móviles físicos o reales de pruebas. Se recomienda siempre contar con
set dispositivos de pruebas físicos o reales de cada una de las plataformas
existentes, debido a que la mayoría de las pruebas se realizarán en los dispositivos
definidos. Los dispositivos móviles físicos o reales permitirán probar principalmente
la experiencia de usuario.
Debido a que tener un set de dispositivos solo físicos o reales puede ser muy
costoso, se recomienda ampliar la cobertura de dispositivos con Simuladores y
Emuladores.

Los Simuladores y Emuladores son aplicaciones limitadas, en cuanto a lo que

se puede probar, por tanto, no se puede probar la experiencia del usuario.

Un Simulador como el que nos proporciona Xcode, simula o imita dispositivos como
iPhone o iPad. En cambio un Emulador – haciendo referencia a lo que nos
proporciona Android Studio – actúa como el dispositivo configurado emulando su
Sistema Operativo y su Hardware.

Se habla de Simuladores por la herramienta XCode, ya que solo permite simular

dispositivos con sistema operativo iOS. En cambio Android Studio, permite emular
distintos dispositivos con sistema operativo Android.

Otra alternativa son herramientas de Cloud Testing, aunque son de pago. Algunas
de las más conocidas son Sauce Labs y Browser Stack. Al ser herramientas que se
encuentran en la nube, nos permiten testear Apps a través del servicio Real Device
Cloud, emuladores/simuladores móviles y pruebas de aplicaciones en vivo.

Ambas herramientas cuentan con una gran variedad de dispositivos de pruebas, a

continuación se puede revisar su cobertura:

​
​ https://www.browserstack.com/list-of-browsers-and-platforms/live
 ​
​ https://saucelabs.com/platform/supported-browsers-devices

¿Qué equipos elegir para armar el set de Dispositivos de Prueba?

En este artículo de BrowserStack (actualizado a enero del 2020), se recopila

información estadística sobre el uso de más de 2 millones de desarrolladores en
BrowserStack y de las últimas tendencias del mercado global.

Una de las propuestas básicas es STARTING UP y consta de los siguientes

dispositivos:

● Apple iPhone 8 (Celular) iOS 13.0

● Apple iPhone XR (Celular) iOS 12.0
● Google Pixel 3 (Celular) Android 9.0
● Samsung Galaxy S9 Plus (Celular) Android 8.0
● Samsung Galaxy S8 (Celular) Android 7.0
● Apple iPad 6th (Tablet) iOS 11.0
Con este Set de dispositivos se puede tener la siguiente Cobertura de Mercado.
¿Dónde descargo la aplicación móvil a probar?

En los siguientes sitios web se pueden obtener las versiones para probar apps
nativas e híbridas:

Testflight

Testflight está disponible solo para la plataforma Apple. Esta aplicación se descarga
de App Store y se instala en el dispositivo de prueba. A través de una invitación se
puede descargar la versión a probar.

Visual Studio App center

Visual Studio App Center es una plataforma donde se pueden cargar y descargar
aplicaciones. Sus herramientas están diseñadas para aplicaciones Android e iOS
construidas en Swift, Objective-C, Java, React Native, UWP y Xamarin.

Almacenamiento en la Nube (Disponible para aplicaciones Android)

La APK de Android no tiene limitación en donde puede ser publicada, por lo que se
puede utilizar algún servicio de almacenamiento en la nube como Google drive, One
drive o Dropbox.

Diseños de Interfaces o Mockups

Los diseñadores pueden utilizar alguna herramienta para publicar el diseño de cada
pantalla de la aplicación móvil, tales como Zeplin, Figma, Adobe XD o InVision.
Cada una de estas herramientas ofrece un sin fin de funcionalidades.

¿Cómo capturar evidencias en un dispositivo móvil?

Probablemente sea una pregunta que se realice uno mismo si no es un usuario de
algunas de las plataformas existentes. En Android, la funcionalidad de capturar
pantalla es nativa y Google indica que se realiza de la siguiente manera:

⚠ Esta combinación varía dependiendo del fabricante. Revise cómo hacer

screenshots de manera alternativa en algunas marcas aquí.

La funcionalidad de Grabar Pantalla no es nativa de Android. Algunas marcas como

Samsung, Xiaomi, Huawei, Honor, OPPO o Realme incluyen esta funcionalidad en
sus teléfonos. Revise cómo grabar pantalla en las marcas mencionadas aquí.

⚠ Si el dispositivo Android de pruebas no tiene esta funcionalidad, revisar las

siguientes aplicaciones: Screen Recorder, Vysor y HiSuite (HUAWEI).

En iOS la funcionalidad de capturar pantalla es nativa y depende del modelo de

iPhone; se realiza de la siguiente manera:
La funcionalidad de grabar pantalla también es nativa de iOS desde iOS 11 y se
realiza de la siguiente manera:

Tipos de Pruebas de Software en una Aplicación Móvil

Algunas de las pruebas que debería tener en consideración todo tester en al

momento de testear una aplicación móvil son:

Funcionalidad
En este tipo de pruebas nos enfocamos principalmente, ya que aseguran que la
aplicación móvil funcione según lo indicado en los requerimientos y/o historias de
usuario. Algunas de las funcionalidades a probar son:

Registro/Login

● Verificar que el usuario pueda registrarse e iniciar sesión.

● Verificar la integración con las aplicaciones como Facebook, Twitter,
Snapchat o Google.
Modo vertical (Portrait) y horizontal (Landscape)

● Verificar si la App tiene activado la opción landscape.

Acciones Básicas, opciones del Menú, Títulos, Textos y Botones

● Asegurar que todos los botones, enlaces y otros elementos de la Interfaz de

Usuario (IU) funcionen como se espera.
● Revisar las integraciones con otras aplicaciones, como por ejemplo
aplicaciones de pago (Transbank, PayPal, etc.)
● Probar los formularios, verificar que la entrada está validada (campos
obligatorios vs. campos opcionales).
Notificaciones, Mensajes Error/Éxito

● Comprobar que las notificaciones push se procesen correctamente.

Gestos Básicos

● Verificar cómo se comporta la aplicación al realizar algunos gestos básicos en

la pantalla.
● Como apoyo a los Gestos Básicos, Luke Wroblewski, Director de producto en
Google, creó la Guía ilustrada referencial con los diferentes gestos que se
pueden realizar en pantallas táctiles.
Incidentes comunes que se reportan en las pruebas funcionales

● Integración con redes sociales en las funcionalidades de Registro y Log in.

Al probar esta integración, a veces ocurre que después de “registrarse” o “loguear
un usuario” no se retorna a la App, sino que se queda en las mismas RR.SS. Se
recomienda probar estos escenarios con las Apps de RR.SS instaladas y
desinstaladas.

● Habilitar la opción de rotar pantalla

Al probar esta funcionalidad puede suceder que el contenido no se adapta a modo
Landscape, ya que no está configurada.

● Realizar un Gesto Básico en Pantalla

Ocurre que al intentar realizar algún gesto la App se rompe. Esto puede pasar
cuando el gesto no está configurado correctamente.

Usabilidad

Este tipo de pruebas se centra en garantizar que el usuario final tenga una buena
experiencia al usar la aplicación. Las pruebas de usabilidad aseguran que se
construya una aplicación móvil intuitiva y fácil de usar.

Es recomendable incorporar a los usuarios desde que se liberan los Mockup o

Diseño de interfaz, y obtener su feedback al respecto.

También incorporar en nuestro proceso de pruebas las Pruebas UAT. Es vital

obtener el feedback de los usuarios que no conocen la aplicación, antes de salir a
producción. Nuestro rol como testers es ayudar a coordinar, preparar guiones
de pruebas y orientar a los usuarios en las Pruebas UAT.
Su feedback ayudará a definir al cliente qué acciones tomar con respecto a la
aplicación móvil, y si es factible lanzarla al mercado o ejecutar algunos cambios
antes de su lanzamiento.

Conectividad

Las aplicaciones web no funcionan sin conexión y la misma regla se aplica a las
aplicaciones web móviles. En este caso, se debe probar si funcionan bien frente
diferentes velocidades de conexión a Internet.

Cuando se trata de aplicaciones móviles nativas y algunas aplicaciones móviles

híbridas, es fundamental verificar si una aplicación funciona correctamente en el
modo fuera de línea o modo avión, y cómo funciona con 3/4/5G o Wi-Fi.

Los escenarios que se pueden probar son los siguientes:

● Cómo se comporta conectada a una red de Datos de un Operador.

● Cómo se comporta conectada a una red Wi-Fi.
● Cómo se comporta conectada a una red de datos de un operador y a una red
Wi-Fi.
● Cómo se comporta cuando se pierde la conexión.
● Cómo se comporta cuando la señal es débil.
Incidentes comunes que se reportan en las pruebas de conectividad

● Cuando se pierde la conexiona Internet la App no muestra una alerta.

La App no informa al usuario que se perdió la conexión.

● Cuando una App está conectada a la red de datos de un operador y esta se

queda sin Internet (se terminó el saldo del teléfono).
La App no alerta esta situación y queda en un estado de loop, esperando respuesta
del servidor.

Rendimiento

Las pruebas de rendimiento ayudan a garantizar que la aplicación móvil

funcione como se espera bajo cargas de trabajo diferentes y específicas. El
rendimiento de una aplicación móvil es crítico, y se considera un factor importante
para su éxito.

Nadie quiere esperar, y muchos usuarios desinstalan una aplicación si se inicia

lentamente, o bien, si tarda demasiado en cargar el contenido, por lo que se
recomienda:

● Contabilizar el tiempo desde que se abre la App hasta que se muestra la

primera pantalla, pues no debe exceder los 2 segundos.
● Verificar el consumo de batería.
● Chequear si se sobrecalienta el dispositivo móvil.
● Revisar el uso de memoria.
Los escenarios indicados anteriormente se pueden probar con el solo hecho de
utilizar un dispositivo móvil físico de pruebas. A medida que se utilice la App se
deben tener en cuenta factores como el tiempo de respuesta, la batería y la
memoria. No debemos ser especialistas en pruebas de rendimiento para alertar
alguna de estas situaciones.

Incidentes comunes que se reportan en las pruebas de rendimiento

● La App se demora mucho en cargar. La primera vez que se usa se tarda

mucho en que cargue la primera pantalla.

Apptim

Apptim es un Spin-off de Abstracta que permite probar y analizar fácilmente el

rendimiento de las aplicaciones móviles, evitando que los problemas se transmitan a
sus usuarios. Actualmente solamente está disponible para aplicaciones nativas.

Interrupciones

Este tipo de pruebas asegura que la aplicación móvil funcione como se espera
cuando se encuentre ante eventos abruptos e inesperados. Existen muchas
posibilidades de que un usuario reciba una llamada o una notificación push mientras
usa la aplicación móvil.

Algunos de los escenarios que podemos probar son:

● ¿Qué ocurre al recibir una llamada o un SMS? ¿Qué ocurre al realizar una
llamada o enviar un SMS? ¿La aplicación móvil continúa funcionando o se
rompe?
● Qué sucede después que el usuario apaga el dispositivo o que el dispositivo
se apaga inesperadamente, ¿la aplicación móvil abre correctamente o se
rompe?
● ¿Cómo se comporta la app al recibir una alerta o notificación?
● ¿Qué pasa con la aplicación al interactuar con otras del dispositivo?
Compatibilidad

Para este tipo de pruebas es recomendable crear una estrategia de pruebas de

dispositivos combinada, entre dispositivos físicos o reales. Se debe definir qué
versiones del sistema operativo soporta la aplicación móvil y probar lo siguiente:

Independiente del tipo de aplicación, todo diseño de una aplicación móvil

debe ser responsivo. Al igual que las aplicaciones web de escritorio, las
aplicaciones web móviles se deben probar en varios navegadores. Algunos de los
navegadores móviles más conocidos son Google Chrome, Safari, Firefox, Edge,
Opera y Samsung.

● Cómo se comporta en diferentes versiones del sistema operativo, tales como

iOS y Android.
 ● Cómo funciona en diferentes dispositivos móviles de especificaciones de
hardware.
● La aplicación móvil se ve bien y funciona sin problemas en diferentes
resoluciones y tamaños de pantalla.
Incidentes comunes que se reportan en las pruebas de compatibilidad

● La App no es responsiva: El diseño de la App no se adapta correctamente al

tamaño de pantallas más pequeñas.
● El contenido de la App web no se visualiza correctamente: Los campos de la
página se desconfiguran en cierto navegador y sistema operativo.
Descarga, Instalación y Actualización

La aplicación móvil más fabulosa no es útil si los usuarios no pueden descargarla,

instalarla o actualizarla sin tener problemas. Por tanto, se debe verificar lo siguiente:

● ¿Se puede descargar la aplicación?

● ¿Cómo se comporta la aplicación móvil durante la instalación, desinstalación
y reinstalación? ¿Se presentó alguna interrupción?
● ¿Se puede actualizar la aplicación móvil? ¿Los datos almacenados son
consistentes después de la actualización?
● ¿Se puede actualizar la App cuando existen múltiples actualizaciones
disponibles? ¿Cómo se comporta cuando otras aplicaciones móviles se están
actualizando?
● ¿La aplicación móvil funciona correctamente después de actualizar el sistema
operativo del dispositivo? Es vital verificar que una actualización del sistema
operativo no rompa la aplicación y se pueda volver a utilizar.
Incidentes comunes que se reportan en este tipo de pruebas

● La App no funciona luego de actualizar el Sistema Operativo del dispositivo

móvil.
Localización

Las pruebas de localización aseguran que la aplicación móvil funcione como se

espera en diferentes mercados, países y regiones. Algunos de los escenarios que
podemos probar son:

● Verificar que las traducciones sean correctas y que no sean traducciones

generadas automáticamente, ya que los usuarios reconocerán esto de
inmediato y probablemente no disfrutarán usando la App.
● Comprobar que la aplicación muestre la hora correctamente en diferentes
zonas horarias.
● Confirmar que los textos y los elementos de la interfaz se vean y funcionen
en diferentes idiomas sin problemas.
Incidentes comunes que se reportan en las pruebas de localización

● En una App las traducciones son generadas automáticamente. El texto en

otro idioma auto-generado no entrega el mensaje correcto.
Lecciones aprendidas sobre Pruebas de Software en una Aplicación Móvil

1. El tipo de aplicación móvil y su versión de Sistema Operativo definirá las

pruebas que se deben incluir en el plan.
2. Siempre se debe tener al menos un dispositivo móvil físico o real para probar,
complementar con simuladores o emuladores y herramientas en la nube. Se
debe buscar una estrategia combinada de dispositivos reales y virtuales que
abarquen las necesidades de las pruebas.
3. Considerar las pruebas de usabilidad en el proceso de testing. Debe existir
un grupo de usuarios que evalúen la aplicación móvil antes de salir al
mercado, no solo bastará con la visión de los testers.
4. Siempre considerar distintos escenarios de conectividad en las pruebas, tales
como modo avión, Wi-Fi o diferentes redes de cobertura.
5. No tenemos que ser especialistas en performance para alertar de algún
comportamiento irregular en el dispositivo móvil.
6. Revisar siempre cómo se comportará la App después de una actualización.
Es vital asegurarse si se instaló la versión que corresponde.
7. No es lo mismo probar una aplicación para escritorio que para un dispositivo
móvil. Tenemos que considerar otros escenarios para realizar las pruebas de
software en una aplicación móvil