Qué pruebas debemos hacerle a nuestro software y

para qué?

0 COMENTARIOS

SUSCRÍBETE A GENBETA

Recibe un email al día con nuestros artículos:

SUSCRIBIR
Síguenos

 Twitter

 Facebook

 Youtube

 Telegram

 RSS
  Flipboard
 LinkedIn

TE RECOMENDAMOS

La Unión Europea aprueba la nueva Ley de Copyright: cómo te afecta y por qué es
importante

Un error de código causa que Subaru tenga que destruir casi 300 vehículos por no tener
arreglo
 

Tras una larga polémica los términos 'Maestro' y 'Esclavo' ya no se usarán más en Python

Compartir

 FACEBOOK

 TWITTER

 EMAIL

15 Marzo 2018 - Actualizado 10 Junio 2018, 12:08

JUAN QUIJANO

“Los test no son opcionales”. Esto que parece a muchos una

verdad de perogrullo, sigue siendo uno de los temas pendientes
en el mundo del desarrollo de aplicaciones de software actual.
Sí, increíblemente aún hay muchos compañeros “del metal” que
no son conscientes que programar sin pruebas no solo es como
hacer acrobacias en el trapecio sin red de seguridad, sino además
una fuente de errores, malas prácticas y ansiedad.

Y por ello quiero repasar los fundamentos básicos de las

pruebas que debiéramos aplicar, cada uno en su necesidad, a
nuestros desarrollos.

¿Por qué hacer pruebas?

Para que lo entienda hasta el más novel de los lectores, hacer
pruebas es la forma de asegurarse que lo que queremos que
haga nuestro programa, lo haga, y lo haga sin errores.

La construcción de software implica conocimiento, experiencia,

talento, capacidad intelectual y un punto de arte. Es decir, es una
labor muy difícil, y falta aún mucho para que eso cambie a mejor.
De hecho, la complejidad está tendiendo al crecimiento de una
forma, como en todo lo relacionado con el Front-End en
Javascript, al absurdo.

Habiendo superado, hace ya décadas, la capacidad humana de

aprensión y memorización; lo que implica necesariamente que los
fallos y errores son inevitables si los intentamos evitar con solo
nuestras capacidades humanas.

Las pruebas no son opcionales. Un

software sin pruebas es una bomba a
punto de estallar
¿A quien no le ha pasado que ha dejado su código medio año en
un cajón, y a la vuelta de ponerse a toquetearlo tener la sensación
de que lo ha escrito otra persona? No reconocemos a nuestra
propia criatura.Y no hablemos cuando estamos integrados en un
equipo, o recibimos el “regalito” de soportar o evolucionar un
código heredado.

Por ello las pruebas son imprescindibles, ya que nos permiten

garantizar que las aplicaciones cumplen las funcionalidades que
se esperan de ellas y las expectativas de calidad (no solo de
código); ayudando a encontrar esos errores o defectos que aún
no se han descubierto; reduciendo el costo del desarrollo, el de
propiedad para los usuarios; y desarrollar confianza en los clientes
al evitar los molestos errores de regresión.

Eso sin hablar de la sensación de seguridad incremental que se

obtiene cuanto más cerca estamos de un despliegue, ya que a
más código que tenemos, más pruebas nos aseguran (en forma
de una tupida malla) que todo funciona correctamente.

DevOps y la herencia de la
automatización
La llegada de las metodologías Agiles, desde los años 90 del siglo
pasado, fue un revulsivo en la organización y ejecución de
pruebas dentro de procesos Waterfall.

En estos últimos, se podría generalizar, las pruebas principalmente

eran manuales; definidas meticulosamente en voluminosos
documentos de planes de pruebas; y que se realizaban
solamente una vez acabada la codificación del software.

Xtreme Programming, en cambio, hizo mucho hincapié en la

automatización y en el concepto de pruebas orientadas a la
prevención de los finales de los años 80; marcando de esta forma,
la futura filosofía Agile. Por ello, actualmente utilizamos
frameworks de pruebas que permiten realizar automáticamente la
mayoría de los test en todos los ámbitos de la aplicación.

Las pruebas manuales y

automatizadas son complementarias
Y más cuando se pretende adoptar el concepto de Integración
Continua, como parte imprescindible de DevOps, donde la
propia construcción y validación de la Build por medio de todo
tipo de pruebas automáticas es parte inherente del proceso.

Siendo esto aún más crítico en niveles altos de madurez en donde

llegaríamos a aplicar despliegue automatizado o, incluso,
continuo.

La importancia que han ido ganando las pruebas ha sido tal que la
propia forma de codificar el software también ha sufrido cambios
profundos. El nacimiento de TDD (desarrollo orientado a las
pruebas) y su forma de supeditar el código a los test, implica que
hacer software testeable es un requisito imprescindible en el
código de calidad.

Y, aunque no lleguemos a utilizar esta avanzada técnica de

desarrollo (que no es nada fácil), el objetivo de poder probar de
forma automática nuestro código, ha reforzado prácticas tan
importantes en la programación orientada a objetos como es
SOLID.

Pruebas automatizadas vs manuales

Tenemos una primera gran división en el mundo de las pruebas
entre las automatizadas y las manuales.

Como indica su nombre, las primeras dependen de una

herramienta de pruebas que implica, en casi todos los casos, un
lenguaje o subconjunto del lenguaje propio. Es decir, si las hago
en nUnit va a ser muy complicado pasarlas a MS Test.

Las pruebas manuales requieren de interacción humana. El

probador se pone en la piel del rol de usuario que se tenga que
validar, y realiza todas aquellas operaciones que tenga definidas
en un plan de pruebas, o le busca “las cosquillas” al sistema para
llegar allí donde ningún “luser” ha llegado anteriormente...

Como ves, ambos tipos de ejecución de pruebas son

complementarios e importantes para garantizar un software de
calidad.

La automatización es rápida y puede probar muchas variaciones

sutiles en los datos; también puede repetir fácilmente las pruebas
a medida que el software evoluciona; y debido a que es ejecutado
por el sistema, se evita la fatiga y los errores que a veces
acompañan a las tareas repetitivas.
En cambio, aunque las pruebas manuales generalmente tardan
más en ejecutarse (ya que las realiza una persona), a menudo
requieren mucho menos tiempo de configuración. Es una buena
opción para las pruebas que solo deben ejecutarse
ocasionalmente, o en los casos en que el costo/tiempo de la
configuración de automatización supere los beneficios.

Un universo de tipos de pruebas

Siguiendo los pasos de la complejidad inherente de nuestra
industria, las pruebas también sufren de una miríada inacabable
de tipos, versiones, evoluciones y clases. Pero centrémonos en las
más importantes e imprescindibles, según cada caso y contexto.

Prueba unitaria: las pruebas unitarias son pruebas automatizadas

que verifican la funcionalidad en el componente, clase, método o
nivel de propiedad.
El objetivo principal de las pruebas unitarias es tomar la pieza más
pequeña de software comprobable en la aplicación, aislarla del
resto del código y determinar si se comporta exactamente como
esperamos. Cada unidad se prueba por separado antes de
integrarlas en los componentes para probar las interfaces entre las
unidades.

Las pruebas unitarias deben escribirse antes (o muy poco

después) de escribir un método; siendo los desarrolladores que
crean la clase o el método, quienes diseñan la prueba.

Así, conseguimos mantener el foco en lo que debe hacer el

código, y se convierte en una poderosa herramienta para aplicar
KISS, JIT, y mantener el foco en lo que tiene que hacer en vez de
en el cómo, evitando introducir complejidad sin valor.

Pruebas de integración: desde una perspectiva de prueba, las

unidades individuales se integran juntas para formar
componentes más grandes. En su forma más simple, dos unidades
que ya han sido probadas se combinan en un componente
integrado y se prueba la interfaz entre ellas.

Las pruebas de integración – o de componentes - identifican

problemas que ocurren cuando las unidades se combinan. Los
nuevos errores que surgen probablemente estén relacionados con
la interfaz entre las unidades en lugar de dentro de las propias
unidades; simplificando la tarea de encontrar y corregir los
defectos.

Pruebas de regresión: cada vez que se realizan cambios en un

proyecto, es posible que el código existente ya no funcione
correctamente o que se presenten errores no descubiertos
previamente. Este tipo de error se llama regresión.
Para detectar estos defectos, todo el proyecto debe someterse a
una regresión: una nueva prueba completa de un programa
modificado, en lugar de una prueba de solo las unidades
modificadas, para garantizar que no se hayan introducido errores
con las modificaciones.

Como se puede deducir, este tipo de pruebas debe ser

automatizado porque puede estar compuesto por decenas o
miles de pruebas unitarias, de integración o más.

Una versión menos costosa, podría ser construir pruebas que

repliquen las acciones que provocaron la regresión, y comprueben
que han sido corregidos al no volver a sucederse los errores;
además de añadir los test unitarios que aseguren que el código
que ha corregido la regresión funciona correctamente.

Pruebas de funcionalidad: pruebas automatizadas o manuales

que prueban las funcionalidades de la aplicación o módulo
construidos desde el punto de vista del usuario final, con sus
diferentes roles, para validar que el software hace lo que debe y,
sobre todo, lo que se ha especificado.

En su versión automática son pruebas que se automatizan para

"ahorrar tiempo de pruebas". A partir de los casos de prueba de
las pruebas manuales, se automatizan los casos de prueba para
que se repitan en las ejecuciones. Esos casos suelen ser los más
importantes (happy flow) de los módulos o procesos de negocio
"vitales" de la aplicación. Es decir, los procesos que siempre tienen
que funcionar y que bajo ningún concepto pueden fallar. El
objetivo de las pruebas funcionales automáticas es comprobar
que no haya regresiones.
 Las pruebas obligan a hacer un
código desacoplado y promueven la
calidad

En el caso de las manuales, las ejecuta un tester como si fuese un

usuario, pero siguiendo una serie de pasos establecidos en el plan
de pruebas, diseñado en el análisis de los requisitos para
garantizar que hace lo que debe (casos positivos), que no falla
(casos negativos) y que es lo que se ha solicitado.

El tester realizará las acciones indicadas en cada paso del caso de

prueba comprobando que se cumple el resultado esperado. Si el
resultado es distinto, se reportará un defecto con todo detalle:
descripción, datos utilizados, capturas de pantalla, etc., para
facilitar la solución.

El mayor problema con el que se enfrentan las pruebas

funcionales para ser automatizadas es su fragilidad. Cada prueba
testea miles de líneas de código, centenares de integraciones en
todos los tiers, y una interfaz de usuario cambiante. Llegando a no
ser sostenible el conjunto de pruebas en relación con su
definición, coste y mantenimiento.

Llevando las aplicaciones a su límite

Ya tenemos probada y desplegada nuestra aplicación. Ahora viene
la parte de operaciones y también se debe probar de forma
automática las capacidades y debilidades del software y de la
plataforma sobre la que corre (infraestructura y dependencias),
llevándola al límite, para comprobar su disponibilidad, estabilidad
y resiliencia.

Pruebas de estrés: las pruebas a pequeña escala, como un

usuario único que ejecuta una aplicación web o una base de datos
con solo un puñado de registros, pueden no revelar problemas
que suceden cuando la aplicación se usa en condiciones "reales".

La prueba de estrés empuja los límites funcionales de un sistema.

Se realiza sometiendo el sistema a condiciones extremas, como
volúmenes de datos máximos o una gran cantidad de usuarios
simultáneos.

También se utilizan para, llevado el sistema al colapso o

degradación, comprobar su funcionamiento continuado por
encima de su límite y, una vez liberado de la carga, evaluar su
capacidad de resiliencia volviendo a su estado óptimo de
funcionamiento.
Lleva la aplicación al límite, busca que
rompa, y luego observa como se
reconstruye
Y en la actualidad cada vez más se utilizan las capacidades de la
Cloud tanto para crear un gran número de usuarios, distribuir las
peticiones en todo el mundo, como para obtener los recursos de
procesamiento, memoria y almacenamiento necesarios en
operaciones de este calibre.

Prueba de rendimiento: determinan la capacidad de respuesta,

el rendimiento, la confiabilidad y/o la escalabilidad de un sistema
bajo una carga de trabajo determinada.

En aplicaciones web, las pruebas de rendimiento a menudo están

estrechamente relacionadas con las pruebas de estrés, la medición
del retraso y la capacidad de respuesta bajo una carga pesada.

En otras aplicaciones (escritorio y aplicaciones móviles, por

ejemplo), las pruebas de rendimiento miden la velocidad y la
utilización de recursos, como el espacio en disco y la memoria.

Si almacenamos todos los resultados de las pruebas de

rendimiento durante un plazo de tiempo, podemos conocer el
estado de salud de la aplicación, pudiendo obtener tendencias y
previsiones de funcionamiento; y optimizando cada despliegue
según el rendimiento necesario en cada caso.

Pruebas de seguridad: validan los servicios de seguridad de una

aplicación e identifican posibles fallos y debilidades.
Muchos proyectos utilizan un enfoque de caja negra para las
pruebas de seguridad, lo que permite a los expertos, sin
conocimiento del software, probar la aplicación en busca de
agujeros, fallos, exploit y debilidades.

Y esto es solo el principio

Funcionales, Usabilidad, Exploratorios, Aceptación, Infraestructura,
etc. El universo de las pruebas es inmenso, siendo una de las
ramas de la mal llamada informática, que requiere de una
especialización especifica.

Y más cuando la llegada de la Infraestructura como Código,

automatiza y mejora procesos conocidos como el Estado de
Configuración Deseada, añadiendo capacidades de lógica de
negocio en la construcción, mantenimiento y pruebas a nivel de
plataforma.

No lo olvides nunca: las pruebas no son opcionales.

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
catastroficas.

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.

Tipos de pruebas de software

 Imagen de: Software Testing Network
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
o Plantilla de casos de uso.
o 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 quien es reponsable de que y a que 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 especificas para asegurar la calidad con pruebas funcionales, de carga y seguirdad.
 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:

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

software
o 5 Herramientas para automatización de pruebas de software.
o Ejemplo de Selenium WebDriver.
o Software Testing con Selenium y Ruby.
o Como instalar Selenium WebDriver y Ruby.
o Testing de Aceptación automatizado con Selenium.
o 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.

Cursos de Software Testing

 ¿Estás trabajando en el área de pruebas de
software y te gustaría ampliar tu formación?
Te recomendamos los Cursos de Software Testing de
Udemy.

Introducción al Testing de Software, pruebas de

webservices con SoapUI, automatización de pruebas
con Selenium y muchos más.

Más artículos sobre Software Testing

 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.
Hoy en dia los proyectos de software son más complejos que nunca
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 mas
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 codigo 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.

Aun 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 mas
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.

4 técnicas de testeo 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.
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, A
va 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 mas 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 importanta 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 actuan 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 funcionalidad 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 construye unos estándares de actuación en

la implementación, diseño y arquitectura de un sistema.

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

Hay otras herramientas de pruebas de software, estaré feliz de discutirlos

en la sección de comentarios de abajo! Y si estais interesados en estos
temas sobre como construir software que funciona, os recomiendo que
os suscribais a nuestro newsletter mensual para recibir los últimos
artículos y las mejores prácticas.

Tened un buen dia!

La Importancia que tienen las pruebas del software de calidad del mismoson de gran utilidad
para ver las fallas que presenta el sistema y poderanalizar las futuras fallas además de esto
también sirven para quecuando entreguemos nuestro software ya nalizado este software
esteculminado tenga altos estándares de calidad y esté listo para entregar!"ara la prueba del
software e#isten unos modelos que son de sumaimportancia para realizar las pruebas de dic$o
software estos modelostienen varios esquemas que son los que se le realizan al software
comolo son%&' (odelo )ascada% el cual permite *ealizar pruebas cuando estáterminado la
construcci+n del sistema!,' (odelo Incremental% con este modelo se realizan pruebas a
cadaetapa o incremento que $aiga en el sistema!-' (odelo .volutivo% este se enfoca en el uso y
retroalimentaci+n de losusuarios!/' (odelo .spiral% este modelo se enfoca en las pruebas
c0clicas deveri caci+n y validaci+n en el desarrollo del sistema!1' (odelo 2"% .ste modelo se
realiza la prueba durante las me3oras quese le $acen al sistema!"or esta raz+n es
recomendable dividir el software por etapas y alrealizar alguna etapa de una vez $acer las
pruebas para de una vezme3orar si $ay algo malo y no acumular las pruebas para el nal
cuandoes más dif0cil identi car en que parte del software se está presentandoel
inconveniente para poder entregar el software con una alta calidad"or esto y por muc$as
razones es de suma importancia realizar laspruebas de un software desde que iniciamos
durante y nalizado elsoftware para que cuando vallamos a entregar el producto sea de
grancalidad! .stas pruebas son importantes en el desarrollo de las - etapasdel software inicio
durante y al nalizar el software ya que si realizamosdic$as pruebas solo al nalizar el software
corremos el riesgo quedurante el desarrollo o peor a4n al iniciar el software tengamos un
errory nos toque comenzar desde el inicio! 5usti que la importancia de elaborar y aplicar el
plan de pruebas en unproyecto de desarrollo de software"lan de "ruebas de 6oftware
Qué importancia tienen las pruebas del software en la
calidad del mismo?
La Importancia que tienen las pruebas del software de calidad del mismo son
de gran utilidad para ver las fallas que presenta el sistema y poder analizar las
futuras fallas además de esto también sirven para que cuando entreguemos
nuestro software ya finalizado este software este culminado, tenga altos
estándares de calidad y esté listo para entregar.
Para la prueba de los software existen unos modelos que son de suma
importancia para realizar las pruebas de dicho software estos modelos tienen
varios esquemas que son los que se le realizan al software como lo son:
-Modelo Cascada: el cual permite Realizar pruebas cuando está terminado la
construcción del sistema.
-Modelo Incremental: con este modelo se realizan pruebas a cada etapa o
incremento que haiga en el sistema.
-Modelo Evolutivo: este se enfoca en el uso y retroalimentación de los
usuarios.
-Modelo Espiral: este modelo se enfoca en las pruebas cíclicas de verificación y
validación en el desarrollo del sistema.
-Modelo XP: Este modelo se realiza la prueba durante las mejoras que se le
hacen al sistema.
Por esto y por muchas razones es de suma importancia realizar las pruebas de
un software desde que iniciamos durante y finalizado el software, para que
cuando vallamos a entregar el producto sea de gran calidad. Estas pruebas son
importantes en el desarrollo de las 3 etapas del software inicio durante y al
finalizar el software ya que si realizamos dichas pruebas solo al finalizar el
software corremos el riesgo que durante el desarrollo o peor aún al iniciar el
software tengamos un error y nos toque comenzar desde el inicio.
Por esta razón es recomendable dividir el software por etapas y al realizar
alguna etapa de una vez hacer las pruebas para de una vez mejorar si hay algo
malo y no acumular las pruebas para el final cuando es más difícil identificar en
que parte del software se está presentando el inconveniente para
poder entregar el software con una alta calidad.