Guía
de conceptos
para comenzar
en el mundo
del testing
Las pruebas de software
o software QA es una
disciplina de la ingeniería
que tiene como objetivo
garantizar que el producto
final tenga valor y cumpla
con las expectativas del
u s u a r i o
Maria
Este eBook fue escrito por Paula
Rodriguez
Índice Introducción
1. ¿Qué son las pruebas o testing?
- Beneficios 5
- Tipos de pruebas 5
2. Tipos de pruebas funcionales
- Pruebas manuales 7
- Pruebas automatizadas 7
-Tipos de pruebas automatizadas 8
-Pruebas Unitarias 8
-Pruebas de Integración 8
-Pruebas e2e 8
3. Pirámide de Cohn o
pirámide del testing 9
4. Prácticas en el testing
- TDD: Test driven development 10
-Principios 11
-Beneficios 11
-Limitantes 11
- BDD: Behavior-Driven Development 11
-Principios 11
-Lenguaje común 12
-Given-When-Then 12
-Role-Feature-Reason 12
-Gherkin 12
- ¿Por qué hacer pruebas automáticas? 14
- ¿Qué deberíamos probar y qué NO? 15
5. Plus: Conceptos interesantes
- Las 3A de una prueba unitaria 16
-Ejemplo (en typescript) 16
- Pruebas de mutación 17
- ¿Hace Google pruebas en el baño? 17
6. Conoce más 18
Introducción
¿Esta es tu primera experiencia en el
mundo del testing y no sabes por
dónde iniciar? ¿Eres un desarrollador
frontend o backend, un desarrollador
experimentado o incluso un analista
de certificación? No importa cuál
sea tu caso, es fundamental conocer
los conceptos básicos claves que te
ayuden a entender un poco más
sobre este grandioso mundo que
son las pruebas.
En este eBook tiene como objetivo
explicar brevemente los conceptos
más comunes en el mundo del testing,
abrir un espacio de debate y compartir
conocimientos y experiencias.
¿Qué Las pruebas de software también
conocidas como testing, se realizan
son las
con el fin de validar la calidad del
aplicativo, software, desarrollo, o
como desees llamar al producto
final; son una forma objetiva de
pruebas
evaluarlo antes de ser puesto en
un ambiente productivo.
o testing?
Beneficios
Mejorar el software para prevenir defectos.
Encontrar errores antes de que éstos lleguen al usuario final.
Asegurar la mantenibilidad del código implementado.
Reducir tiempos de verificación del sistema en casos de cambios.
En general, existen dos tipos de pruebas de software:
Cuando se prueban funcionalidades Por lo tanto, cuando se prueba la
específicas del software se dice que respuesta del software ante situaciones
se realiza una prueba funcional, estas extremas que no se encuentran rela-
pruebas también se conocen como cionadas directamente a funcionali-
pruebas automatizadas puesto que dades específicas decimos que se
son a su vez un tipo de prueba realizó una prueba no funcional. De
funcional clasificada por ejecución y una forma más técnica las pruebas
son muy utilizadas en el ámbito del no funcionales pueden definir de la
desarrollo de software. siguiente manera:
“Las pruebas no funcionales
son las que se hacen
desde una perspectiva ¿Quieres
totalmente diferente a las aprender
pruebas automatizadas. más sobre
Este tipo de pruebas son pruebas no
un medio de control de funcionales?
calidad, que se realiza en
aplicaciones de software Desde Pragma te
para asegurarse de que recomendamos
los siguientes artículos:
todo funciona bien y
poder saber en qué
circunstancias podrían
fallar.”
Víctor Manuel Soto Morales
en conoce qué son las pruebas Conoce qué son las
no funcionales de software. pruebas no funcionales
de software.
Un buen ejemplo de este tipo de
pruebas es cuando queremos medir la
respuesta del software a una cantidad
determinada de peticiones, a esto
lo conocemos como prueba de
rendimiento.
Para no alargarnos y porque además Pruebas Perfomance:
otros pragmáticos ya han cubierto tipos y etapas.
estos conceptos, nos centraremos
en lo relacionado a las pruebas de
software funcionales.
Tipos de
pruebas
funcionales
Pruebas manuales
Estas pruebas son ejecutadas por un tester o una persona que simula ser un
usuario del software, normalmente para este tipo de pruebas se utiliza un plan o
un diagrama que especifica los posibles casos y resultados de cada situación en
el software y cómo debe responder ante diferentes entradas.
La tarea del tester es principalmente verificar que se cumplen con los resultados
especificados anteriormente y de haber una irregularidad debe reportar con todo
detalle el error encontrado.
Pruebas automatizadas
Estas pruebas se implementan mediante un software especializado, generalmente
son realizadas por los desarrolladores del producto y tiene múltiples beneficios
para el negocio, como aquellos que nos enuncia Software Testing Bureau en
su artículo:
{
Capacidad de ejecución de pruebas.
Integración continua y Devops.
Ahorra tiempo y recursos.
Pruebas repetibles.
Mayor precisión.
Tipos de
pruebas
automatizadas
Así mismo, existen varios tipos
de pruebas que varían según el
ámbito en el que son aplicadas.
Claramente existen muchas
más pero te mencionaré tres:
Pruebas Unitarias
Estas pruebas se realizan sobre
un componente específico
con el fin de verificar el
comportamiento del mismo.
Pruebas de Integración
Estas pruebas se realizan sobre varios
componentes con el fin de verificar la
interacción entre los mismos. Éstas
pruebas llevan generalmente más
esfuerzo que las pruebas unitarias.
Pruebas e2e
Estas pruebas se realizan sobre todo el sistema o flujo del
programa con el fin de simular las acciones y eventos del
usuario final. Éstas pruebas llevan generalmente más esfuerzo
que las pruebas de integración.
Pirámide
de Cohn o
pirámide
del testing
Se habla también de la pirámide
del testing también conocida como
Pirámide de Cohn; básicamente nos
expone un modelo dónde se debe
priorizar la implementación de las
pruebas desde la parte inferior a la
superior de la pirámide. De forma que
controlemos la mayor cantidad de
errores posible, así como explica wc
testing en su artículo:
“Las pruebas no funcionales De esta manera Cohn propone
que en todo desarrollo se debe
son las que se hacen desde disponer más esfuerzo y tiempo
una perspectiva totalmente en la realización de pruebas
unitarias, seguido de las pruebas
diferente a las pruebas de integración y por último de
automatizadas. Este tipo las pruebas e2e. Además, entre
más cerca de la punta superior
de pruebas son un medio se encuentre una prueba dentro
de control de calidad, que de la pirámide, su complejidad y
uso de recursos aumenta
se realiza en aplicaciones puesto que se debe simular una
de software para asegurarse mayor cantidad de procesos, así
mismo, tiende a ser más común
de que todo funciona bien que encontremos más pruebas
implementadas de las definidas
y poder saber en qué hacia la base de la pirámide
circunstancias podrían debido a que son, en teoría, más
sencillas de implementar.
fallar.”
Metodologías
en el testing
A lo largo del tiempo, se han propuestos
diferentes metodologías, prácticas, procesos
o técnicas para hacer de la implementación
de pruebas un camino definido e incluir el
proceso de pruebas en el desarrollo de una
forma más fluida.
TDD: Test driven development
Test driven development o desarrollo guiado por pruebas, es una práctica que
consiste en implementar las pruebas antes del código principal. Tiene un ciclo
muy bien definido que se muestra en la siguiente imágen:
RED:
Escribe una
prueba que falle.
GREEN:
Implementaremos el
código para que pase
la prueba anterior.
REFACTOR:
Mejora el código que
acabas de escribir
verificando siempre que
el código escrito pase
la prueba implementada.
Principios Beneficios
Las pruebas deben ser sencillas de Produces código ‘limpio’ o
implementar, si no es así, quiere decir sólo el requerido.
que la prueba no está bien diseñada Al terminar la implementación
o planteada. cuentas con tus pruebas
Debes escribir el código estrictamente implementadas.
necesario, puesto que debemos Se reducen los errores o bugs
limitarnos a cumplir con las condiciones que puedan surgir en un futuro.
de las pruebas implementadas.
Limitantes
Está diseñada para ser aplicada en pruebas unitarias.
BDD: Behavior-Driven Development
Behavior Driven Development o desarrollo dirigido por comportamiento es una
técnica de testing que se centra en las funcionalidades o comportamientos
definidos en los requerimientos del producto y en la perspectiva del usuario.
Tiene como objetivo principal que las pruebas especificadas sean entendidas
por la mayor cantidad de personas en un equipo, de esta manera, se usa como
estrategia la definición de historias de usuario en un lenguaje común para
todos los participantes.
Principios
Enfocado en funcionalidades.
Los requerimientos del aplicativo deben traducirse como historias de usuario.
Cada historia de usuario de prueba debe contener ejemplos específicos.
Lenguaje común
Un lenguaje común es un estándar con el cuál se va a estructurar la definición
de las pruebas a implementar, existen varios pero aquí nombraremos tres:
Given-When-Then
Given ‘dado’: When ‘cuando’: Then ‘entonces’:
Especificación de Especificación Especificación
precondiciones. de acciones. de validaciones.
Role-Feature-Reason
As a ‘como’: I want ‘deseo’: So that ‘para que’:
Especificación Especificación Especificación
tipo de usuario. de necesidades. de objetivos.
Gherkin
Es un lenguaje evolucionado del Given-When-Then con una mayor profundidad
y especificidad, su uso es muy extendido en el campo de la automatización
y cuenta con varias herramientas que lo implementan, como por
ejemplo Cucumber.
Para su descripción se usa la siguiente terminología, siendo comúnmente
usadas Feature, Scenario, Given, When, Then:
Obtenido del artículo
Qué es Gherkin
Ejemplo de uso
¿Por qué
hacer
pruebas
automáticas?
Finalmente nos encontramos con ésta Es una invitación abierta de que
pregunta, y si lo descrito anteriormente dejemos pensar sólo en nuestro
no es suficiente, podemos adicionar bienestar y pensemos en el otro,
que además de ventajas corporativas tener pruebas en un código nos
podemos obtener: puede ayudar a comprender su
funcionamiento y además, ser
una forma de documentación para
las próximas almas que lleguen
Tranquilidad con el código a trabajar sobre el mismo. Sólo
implementado y los resultados imagínate un mundo en el que
obtenidos. toda empresa hiciera pruebas al
software que produce con al
Como decimos coloquialmente menos un 80% de cobertura y
“te curas en salud” puesto que pregúntate ¿Qué es lo mejor que
las pruebas son una forma de podría pasar?
asegurar la calidad de tu trabajo
y el de tu equipo. Piénsalo, tu yo del futuro te lo
agradecerá.
Adicional a lo anterior, te puede
facilitar la vida al momento de
adicionar cambios en un proyecto
del cual no recuerdas siquiera si
participaste en el mismo.
¿Qué deberíamos
probar y qué NO?
Lo ideal en un proyecto sería Lo primero que debes hacer es
que lográramos una cobertura conocer cuál es la ruta crítica de tu
completa del mismo en términos aplicativo; para darte una idea
de pruebas, sin embargo este podrías preguntarte lo siguiente:
escenario es una completa utopía.
Y es que muchas veces para lograr ¿Cuál es el flujo principal de
éste objetivo puedes tardar la mi aplicación?
misma cantidad de tiempo haciendo
¿Cuáles son los componentes
pruebas que lo que se tarda en el
transversales en mi aplicativo?
desarrollo entero del proyecto, o
sea, si se tarda un mes el desarrollo, ¿Cuáles son los componentes que
puede que se tarde otro mes la sufren más cambios a lo largo de
implementación de las pruebas la ejecución del flujo principal?
respectivas, por lo que es muy ¿Qué componentes se integran
probable que no contemos con con entes externos?
disponibilidad de tiempo para hacerlo.
¿Manejas componentes que deben
Entonces, ¿Qué podríamos hacer? cumplir con expectativas de
Bueno, una solución posible en la seguridad? ¿Cuáles?
que reduces tiempo implementando
pruebas es aplicando la técnica de
TDD, que además tiene muchos Después de responder las preguntas
más beneficios como por ejemplo anteriores, deberías tener una
reducir bugs a futuro. Otra buena lista de componentes que se
solución es escoger las partes o encuentran involucrados en la ruta
componentes de tu código que principal de funcionamiento de tu
consideres que sean relevantes aplicativo, así que, ya sabes por
para el funcionamiento de tu dónde empezar o qué componentes
aplicativo pero ¿qué deberíamos estás obligado a cubrir, sólo
probar y qué no? recuerda, lo importante es
enfocarse en las funcionalidades
de peso, aquellas que sean
cruciales para el funcionamiento
del aplicativo y también,
componentes que hacen parte
del flujo de trabajo del usuario.
Plus:
Conceptos
interesantes
Las 3A de una prueba unitaria
El patrón AAA es un estándar que consiste en dividir claramente el
código de una prueba unitaria en tres secciones:
Arrange (Organizar): Es el momento en el cual se instancian los
objetos y se establecen los valores de las variables y/o constantes a
utilizar en la prueba.
Act (Actuar): Es el momento en el cual se hace uso del método que
se requiere validar.
Assert (Afirmar): Es el momento en el cual se valida que el resultado
obtenido sea igual al esperado.
Ejemplo (en typescript)
El principal objetivo de adoptar este estándar es dar a las pruebas
unitarias una estructura con el fin de lograr una fácil legibilidad.
Pruebas de mutación
Con las pruebas unitarias buscamos que se cubra la mayor porción de
código posible, sin embargo, esto no siempre es una señal de calidad.
Así que, para verificar la efectividad de las pruebas unitarias recurrimos
a las pruebas de mutación.
Al efectuar una prueba de mutación se hace un pequeño cambio al
código original y luego se ejecutan las pruebas unitarias, si las pruebas
están correctas no deberían fallar con el cambio realizado. Cada
modificación que se hace al código original se le llama mutación y la
efectividad de las pruebas unitarias se mide en relación a la cantidad de
mutaciones que logra sortear.
Para conocer las herramientas que se encargan de realizar estas
pruebas y algunas de sus configuraciones puedes revisar el artículo:
Test de mutaciones: la calidad es más importante que la cantidad.
¿Hace Google pruebas en el baño?
Aunque suene un poco raro, en 2007 Google tituló como Testing on the
Toilet (que literalmente se puede traducir como Pruebas en el baño) a
una iniciativa que tenía como objetivo fomentar la cultura de la calidad
en sus equipos.
Esta iniciativa que aún está vigente y ha publicado más de 100 artículos
sobre pruebas de software, busca inspirar a sus desarrolladores de una
forma imposible que no puedan ignorar, así que como estrategia,
decidieron colocar panfletos en los baños de la empresa y, según sus
propios testimonios ha sido el “arma secreta” con la cual han logrado
que sus empleados entiendan la importancia de hacer pruebas y las
involucren en sus desarrollos.
Si quieres saber
más de esta iniciativa
puedes entrar en
Testing on the Toilet.
Conoce más
¿Cuándo y por qué conviene automatizar pruebas de software?
¿Qué es BDD?
Conoce qué son las pruebas no funcionales de software.
La famosa Pirámide de Cohn y la dura realidad.
Pruebas Perfomance: tipos y etapas.
Pruebas unitarias: imprescindibles para programar.
Qué es Gherkin.
Sistema Calidad de Software.
Software Testing Fundamentals - Questions and Answers.
Testing on the Toilet.
Test de mutaciones: la calidad es más importante que la cantidad.
Test Unitarios, cobertura y una técnica muy chula.
Things to Consider when Frontend Unit Testing.
te invitamos a
Trabaja con nosotros
