GLOSARIO TESTING:

Automatizar: Implementar procedimientos automáticos en un proceso,

mecanismo, sistema o aparato.

Automático: Que funciona por sí solo o que realiza total o parcialmente un

proceso sin ayuda humana.

Qué es DevOps (y sobre todo qué no es DevOps)

DevOps es uno de los términos más mencionados en el actual entorno de IT.

Normalmente se asocia a estrategias de transformación digital, y a

metodologías como Continuous Delivery o desarrollo ágil.

En un post anterior (El legendario origen del movimiento DevOps),

presentábamos la génesis del término, pero como ocurre con la mayoría de las

buzzwords tecnológicas, es complicado encontrar una definición canónica, y es

frecuente de hecho encontrar usos del término contradictorios, o

flagrantemente incorrectos.

Gran parte de la confusión viene de mezclar lo que es DevOps con los

requisitos necesarios o los beneficios obtenidos al implementar DevOps. Sin

querer ser excesivamente dogmáticos acerca de un término cuyas líneas de

contorno aún no han acabado de asentarse del todo, vamos a intentar al

menos arrojar algo de luz sobre el concepto.

1
DevOps según WikiPedia

Comenzamos con lo más próximo que hoy en día podemos tener a una

definición canónica. ¿Qué dice Wikipedia de DevOps?:

*"DevOps es un acrónimo inglés de development (desarrollo) y operations

(operaciones), que se refiere a una metodología de desarrollo de software que

se centra en la comunicación, colaboración e integración entre desarrolladores

de software y los profesionales de sistemas en las tecnologías de la

información (IT)".*DevOps es una respuesta a la interdependencia del

desarrollo de software y las operaciones IT. Su objetivo es ayudar a una

organización a producir productos y servicios software más rápidamente, de

mejor calidad y a un coste menor.

Las empresas con entregas (releases) muy frecuentes podrían requerir

conocimientos de DevOps. Flickr desarrolló un sistema DevOps para cumplir

2
 un requisito de negocio de diez despliegues diarios. A este tipo de sistemas se

les conoce como despliegue continuo (continuous deployment) o entrega

continua (continuous delivery), y suelen estar asociados a metodologías lean

startup. Grupos de trabajo, asociaciones profesionales y blogs usan el término

desde 2009".

Todo claro, ¿verdad? ¿O pensáis como yo que hay overflow de conceptos?

Rescatemos de momento tres ideas clave:

 DevOps es una metodología para creación de software.

 DevOps se basa en la integración entre desarrolladores software y

administradores de sistemas.

 DevOps permite fabricar software más rápidamente, con mayor calidad,

menor coste y una altísima frecuencia de releases.

3
Con estos conceptos en mente, repasemos algunas corrientes de opinión en

torno a DevOps.

¿Es DevOps una cultura?

No, DevOps no es en sí una cultura, pero sí requiere de un fuerte cambio

cultural y organizativo para su implementación. Un cambio cultural hacia la

colaboración, la comunicación, y en último término la completa integración

entre las antiguas áreas (en lo habitual rabiosamente estancas) de desarrollo y

sistemas.

Este cambio cultural es tan complicado de conseguir en algunas

organizaciones, que son muchos los que lo identifican directamente con

DevOps, pero recordemos: DevOps es una metodología de desarrollo software,

y un cambio de cultura no es en sí mismo una forma de desarrollar software.

¿Es DevOps una nueva raza de hombres orquesta?

Otro error común es confundir DevOps con modelos que algunas startups se

ven abocadas a adoptar en sus inicios, en los que todos los miembros del

equipo técnico saben de desarrollo, de sistemas, de tuning de rendimiento, de

4
bases de datos... y hasta de cablear la oficina, comprar portátiles y hasta

configurar el móvil de la gente de negocio. ¿Os suena ;-)?

Ese modelo puede funcionar durante un tiempo, pero no escala. DevOps no

consiste en aumentar la responsabilidad de los desarrolladores haciendo que

lleven varias gorras (en particular dos, la de desarrollo y la de sistemas), sino

en sustituir esas dos gorras por una sola: una nueva gorra DevOps.

¿Es DevOps una profesión?

Según Rob Steward, vicepresidente de desarrollo de producto de Progress

Software, “una buena práctica de DevOps liberará a los desarrolladores para

que se centren en hacer lo que mejor saben hacer: escribir software. DevOps

elimina el trabajo y las preocupaciones de la puesta en producción del software

una vez que está escrito”.

5
Si esto es así, ¿qué es un ingeniero DevOps? ¿No hemos quedado en que

DevOps permite que un desarrollador sólo desarrolle? ¿Entonces por qué se

buscan en el mercado –y cada vez con mayor demanda- perfiles con

habilidades específicas para montar equipos DevOps?

La respuesta es sencilla: para un desarrollador pasar a un modelo DevOps

resulta inmediato, mientras que un ingeniero de sistemas necesita nuevas

habilidades. Estas habilidades, según una investigación de Puppet Labs, son,

por este orden: scripting, don de gentes, reingeniería de procesos, y en último

lugar experiencia con herramientas específicas. Un perfil que no es fácil de

encontrar.

Así que no, DevOps no es una profesión, y estrictamente no existen ni perfiles

DevOps ni ingenieros DevOps, sino “ingenieros de sistemas con capacidades

específicas para integrarse en equipos DevOps”.

DevOps: un modelo de desarrollo de productos digitales

Como conclusión, quedémonos con una definición simple de DevOps con la

que todos podamos estar de acuerdo: DevOps es una metodología de

desarrollo software basada en la integración entre desarrolladores y

administradores de sistemas, que permite que los desarrolladores puedan

enfocarse sólo en desarrollar y puedan desplegar su código en segundos.

6
 DevOps es especialmente útil en el nuevo entorno de la transformación digital y

el desarrollo de productos digitales, para los que el usuario final y/o el cliente

interno de negocio demanda TTM (time-to-market), más flexibilidad, más

calidad, menos coste y una altísima frecuencia de releases.

DevOps
DevOps (acrónimo inglés de development -desarrollo- y operations -
operaciones-) es una práctica de ingeniería de software que tiene como
objetivo unificar el desarrollo de software (Dev) y la operación del software
(Ops). La principal característica del movimiento DevOps es defender
enérgicamente la automatización y el monitoreo en todos los pasos de la
construcción del software, desde la integración, las pruebas, la liberación hasta
la implementación y la administración de la infraestructura. DevOps apunta a
ciclos de desarrollo más cortos, mayor frecuencia de implementación,
lanzamientos más confiables, en estrecha alineación con los objetivos
comerciales.1234

Índice

 1Definiciones e Historia
 2Herramientas DevOps
 3Relación y otros enfoques
o 3.1Agile
o 3.2Entrega Continua
o 3.3ArchOps
o 3.4DataOps
o 3.5Objetivos
o 3.6Microservicios
 4Véase también
 5Referencias
 6Enlaces externos

Definiciones e Historia[editar]

7
Ilustración que muestra DevOps como la intersección de desarrollo,
operaciones de tecnología y calidad (QA)
En la conferencia Agile 2008 Toronto, Yhens Wasna y Patrick Debois
introdujeron el término en su charla sobre "Infraestructura Ágil". 5 A partir de
2009, el término DevOps se ha promocionado constantemente y se ha
incorporado a un uso más general a través de una serie de "devopsdays", 6 que
comenzaron en Bélgica y ahora también se han extendido a otros países.7
El término DevOps ha sido utilizado en múltiples contextos diferentes. 8
Una definición propuesta por Bass, Weber y Zhu es:
DevOps es un conjunto de prácticas destinadas a reducir el tiempo entre el
compromiso de un cambio en un sistema y el cambio que se coloca en la
producción normal, al tiempo que garantiza una alta calidad. 9
En los últimos años, también han evolucionado iniciativas de DevOps más
tangenciales, como OpsDev,10 WinOps,11 y BizDevOps.12

Herramientas DevOps[editar]
Como DevOps pretende ser un modo de trabajo interfuncional, en lugar de una
sola herramienta de DevOps existen conjuntos (o "toolchains") de múltiples
herramientas.13 Se espera que tales herramientas de DevOps encajen en una o
más de estas categorías, que reflejen los aspectos clave del proceso de
desarrollo y entrega:1415

1. Código: desarrollo y revisión de código, herramientas de administración

de código fuente, fusión de código
2. Construcción: herramientas de integración continua, estado de
compilación
3. Prueba: herramientas de prueba continuas que brindan
retroalimentación sobre los riesgos comerciales
4. Paquete: repositorio de artefactos, distribución previa a la
implementación de la aplicación
5. Lanzamiento - gestión de cambios, aprobaciones de versiones,
automatización de versiones
6. Configurar - configuración y gestión de la infraestructura, Infraestructura
como código

8
 7. Monitor: monitoreo del rendimiento de las aplicaciones, experiencia del
usuario final
Algunas categorías son más esenciales en una cadena de herramientas
DevOps que otras; especialmente la integración continua (por
ejemplo, Jenkins) y la infraestructura como código (por ejemplo, Puppet).1617

Relación y otros enfoques[editar]

Agile[editar]
La necesidad de DevOps surgió del creciente éxito del desarrollo de software
ágil, ya que eso llevó a que las organizaciones quieran lanzar su software más
rápido y con mayor frecuencia. A medida que trataban de superar la tensión
que esto suponía para sus procesos de gestión de versiones, debían adoptar
patrones como la automatización del lanzamiento de aplicaciones, las
herramientas de integración continua y la entrega continua.18
Entrega Continua[editar]
La entrega continua y DevOps tienen objetivos comunes y a menudo se usan
en conjunto, pero hay diferencias sutiles. 1920
Si bien la entrega continua se centra en la automatización de los procesos de
entrega de software, DevOps también se centra en el cambio de la
organización para admitir una gran colaboración entre las muchas funciones
involucradas.19
DevOps y la entrega continua comparten una base común en métodos ágiles y
pensamiento delgado: cambios pequeños y frecuentes con valor focalizado
para el cliente final.21
ArchOps[editar]
ArchOps es una extensión de DevOps que incrementa el nivel de abstracción al
priorizar los artefactos de arquitectura de software por encima del código fuente
para el despliegue y operación de soluciones de software 22. ArchOps establece
que los modelos de arquitectura son entidades de primera clase dentro del
desarrollo, despliegue y operación de soluciones de software.

DataOps[editar]
La aplicación de entrega continua y DevOps para el análisis de datos se ha
denominado DataOps. DataOps busca integrar ingeniería de datos, integración
de datos, calidad de datos, seguridad de datos y privacidad de datos con
operaciones.23 Aplica principios de DevOps, desarrollo ágil y el control
estadístico del proceso, utilizado en la fabricación ajustada, para mejorar el
tiempo de ciclo de extracción de valor del análisis de datos. 24
Objetivos[editar]
Los objetivos de DevOps abarcan todo el proceso de entrega. Incluyen:

 Frecuencia de despliegue mejorada;

 Llegada al mercado más rápida;

9
 Baja tasa de errores en nuevas versiones;
 Tiempo de entrega más corto entre parches;
 Tiempo de recuperación más rápido (en caso de que una nueva versión
falle).
Los procesos simples se vuelven cada vez más programables y dinámicos,
utilizando un enfoque DevOps.25 DevOps tiene como objetivo maximizar la
previsibilidad, eficiencia, seguridad y mantenimiento de los procesos
operativos. Muy a menudo, la automatización apoya este objetivo.
La integración de DevOps se enfoca en la entrega de productos, pruebas
continuas, pruebas de calidad, desarrollo de características y versiones de
mantenimiento para mejorar la confiabilidad y la seguridad y proporcionar ciclos
de desarrollo e implementación más rápidos. Muchas de las ideas (y personas)
involucradas en DevOps provienen de la administración de sistemas
empresariales y los movimientos ágiles de desarrollo de software. 26
Microservicios[editar]
Este tipo de enfoque permite a las empresas digitales brindar alta disponibilidad
y estabilidad a sus aplicaciones; esto se debe a que todas las partes de las
aplicaciones (base de datos, back-end, frontend, etc.) son independientes y, si
una de ellas falla, no implica que toda la aplicación se caiga, en lugar de eso,
las otras partes continuarán trabajando mientras se restaura el componente
afectado.27 Los creadores de DevOps requieren de microservicios para
optimizar sus desarrollos, y dejar atrás arquitecturas monolíticas.

CUCUMBER Y LAS PRUEBAS DE ACEPTACIÓN DE USUARIO

Cucumber es una herramienta para hacer pruebas de aceptación de usuario
(mediante enfoque BDD -Behaviour Driven Development-) escrita en Ruby y
que ayuda a que el usuario final, es decir, la persona que se encuentra
trabajando en el ambiente del negocio propiamente dicho, y el equipo de
proyecto (analista, desarrollador y probador) se puedan entender fácilmente.
Hay algunas siglas que deberemos conocer como ser: BDD, TDD y ATDD.
Cucumber es una herramienta que es el resultado de una serie de transiciones
que durante la historia del software testing han venido transformando los
enfoques:

 para fines de 1957, se aplicaba el enfoque orientado al Debugging

 para fines de 1978, se aplicaba el enfoque orientado a la Demostración
 para fines de 1982, se aplicaba el enfoque orientado a la Destrucción
 para fines de 1988, se aplicaba el enfoque orientado a la Evaluación
 actualmente y desde hace algunos años, el enfoque esta orientado
(según mi opinión), al comportamiento, entorno y riesgos
Vayamos entonces a la definición de las Siglas,
BDD
Se centra en el comportamiento mientras que TDD se centra en la
implementación.

10
TDD
Se centra en capturar requisitos en test de aceptación y los usa para conducir
el desarrollo.
ATDD
Esta centrado en los requisitos desde el punto de vista del desarrollador, BDD
esta enfocado en la captura de requisitos desde el cliente
Profundicemos en el BDD
 Es un método de diseño y codificación que integra pruebas de (a)
Aceptación y (b) Unitarias
 Esta orientado a un desarrollo “Outside -> In”
 Define el uso de un DSL(pre-condiciones, proceso, post-condiciones)
para las pruebas (es un subconjunto del lenguaje natural Gerkin)
 En el Gerkin, se describe el comportamiento del software sin importar el
desarrollo
 La Sintaxis en el Gerkin esta compuesta por Feature y Scenario
Respecto a Cucumber
 Se trabaja bajo Framework tipo BDD
 Esta escrito en Ruby pero disponible para otros lenguajes
 Los primeros pasos para trabajar con él deben ser: (a) Instalar Ruby y
(b) Instalar Cucumber
 Es una herramienta que trabaja con las líneas de comandos
 Lee los ficheros “.features” (a partir del directorio indicado)
 Por cada “scenario”, ejecuta sus “steps”
 El roadmap sería algo por el estilo:
o Fase inicial: Nuestro proyecto (con la intención de automatizar)
o Fase de Negocio: Features -> Scenario -> Steps
o Fase tecnológica: Step Definitions -> Support Code -> Automation
Library
o Fase final: Nuestro proyecto (automatizado)
 El framework podría armarse con:
o una herramienta para la creación y configuración de entornos de
desarrollo virtualizados
o un sistema de control de código fuente distribuído
 Las acciones a seguir podrían ser:
o Crear un directorio: ejemplo-cucumber
o Crear un sub directorio: feature
o Crear un archivo: features/primeros_pasos.features
o Ir a la consola, situarse en el directorio y escribir: cucumber
o Crear un test: abrir un editor de texto y escribirlo
o Ejecutar el test case
o Crear un directorio dentro del directorio features
o Copiar la salida obtenida de la ejecución del test case y copiarla a
un nuevo archivo
o Ejecutar el test case de nuevo
o En definitiva…
o BDD y Cucumber son demandados por la industria ya que
permiten introducir testing desde el principio del desarrollo
 

11
Aclaración de algunos conceptos
Feature:
Es la funcionalidad que vamos a testear.
Scenario:
El escenario vendría a ser una historia de usario de la funcionalidad, esto
quiere decir que cada scenario sería probar una funcionalidad en un contexto
distinto.
Given:
El estado inicial del escenario, se pueden concatenar varios con And’s.
When:
El proceso que queremos probar, también se pueden concatenar varios usando
And’s… pero de inicio no tiene sentido, deberíamos probar sólo una cosa en
cada escenario.
Then:
Las comprobaciones para saber si el escenario se está ejecutando
correctamente o no.
Una vez escritos los pasos de la “feature”, nos queda escribir los “steps” para
que se ejecute el test del escenario.
A continuación, les muestro un ejemplo:

Feature: Search courses

Courses should be searchable by topic
Search results should provide the course code
Scenario: Search by topic
Given there are 240 courses which do not have the topic “biology”
And there are 2 courses, A001 and B205, that each have “biology” as one of
the topics
When I search for “biology”
Then I should see the following courses:
| Course code |
| A001 |
| B205 |
Primeras Conclusiones
 Las “pruebas” (descripciones de funciones de texto plano con
escenarios) son típicamente escritas antes que nada.
 Estas pruebas deben ser verificadas por los analistas de negocios,
expertos en el dominio, y nó los miembros técnicos.
 El código de producción se escribe de afuera hacia adentro, y así
obtener el estado PASS en las historias de usuarios.
 Algunos enfoques definen que tanto los desarrolladores y stakeholders
son los que escriben las pruebas.
 Las pruebas unitarias nos indican que nuestro desarrollo está correcto.
 Las pruebas de aceptación nos indican que nuestro desarrollo es lo
correcto.
 Con las pruebas de aceptación logramos aumentar el feedback,
minimizando las malas interpretaciones.
 Con las pruebas de aceptación debemos lograr construir un lenguaje
común.
 Utilizando ejemplos estimulamos la creatividad e imaginación de los que
estén participando en el proyecto.
12
 Cucumber
o hace fácil leer y escribir test cases de aceptación por cualquier
miembro del equipo
o se convierte en una herramienta que propone la colaboración y la
comunicación
o permite escribir especificaciones ejecutables
o facilita la comprensión de los test cases para los stakeholders,
como un documento de requisitos
o permite que la documentación se mantenga actualizada
reflejando el estado del proyecto
o permite indicar que varios escenarios compartan un mismo
background
o permite indicar los datos que se usan en un escenario en forma
de tabla
o permite ejecutar un mismo escenario con varios valores de
entrada y de salida
o permite anotar los escenarios para ejecutar solo aquellos que nos
interesen

Primeros Pasos con Serenity y Cucumber

Índice de contenidos

 1. Introducción
 2. Entorno
 3. Preparar el proyecto
 4. El primer Test
 5. Generar el reporte
 6. Conclusiones
 7. Referencias

1. Introducción

Serenity es una herramienta que nos facilita hacer BDD centralizando los test
de nuestra aplicación.

13
El reporte generado nos indica el estado funcional de nuestra aplicación con
gran detalle y sirve también como documentación viva.

Nos ofrece muchas posibilidades, pero en este tutorial nos vamos a centrar en
un reporte con Cucumber para la definición de escenarios y su implementación.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

 Hardware: Portátil MacBook Pro Retina 15′ (2.5 Ghz Intel Core I7,
16GB DDR3).
 Sistema Operativo: Mac OS Sierra
 Entorno de desarrollo: Intellij Idea CE
 Java 1.8
 Apache Maven 3.5.0

3. Preparar el proyecto

Vamos a usar Serenity con Cucumber. Para ello, incluimos la dependencia de

Serenity-cucumber. Si veis las dependencias, incluye el core de serenity.

pom.xml

XHTML

1 <dependencies>

2         <dependency>

3             <groupId>net.serenity-bdd</groupId>

14
4             <artifactId>serenity-cucumber</artifactId>

5             <version>1.6.4</version>

6         </dependency>

7     </dependencies>

También incluimos el failsafe plugin para que ejecute los test en la fase de
verificación y el plugin de serenity para generar el reporte en la fase justo
después de ejecutar los tests (post-integration-tests).

XHTML

1 <plugins>

2         <plugin>

3             <artifactId>maven-failsafe-plugin</artifactId>

4             <version>2.19.1</version>

5             <configuration>

6                     <includes>

7                         <include>RunTest.java</include>

8                     </includes>

15
9                 </configuration>

10                 <executions>

11                     <execution>

12                         <goals>

13                             <goal>integration-test</goal>

14                             <goal>verify</goal>

15                         </goals>

16                     </execution>

17                 </executions>

18         </plugin>

19         <plugin>

20                 <groupId>net.serenity-bdd.maven.plugins</groupId>

21                 <artifactId>serenity-maven-plugin</artifactId>

22                 <version>1.7.2</version>

23                 <executions>

24                     <execution>

25                         <id>serenity-reports</id>

26                         <phase>post-integration-test</phase>

27                         <goals>

28                             <goal>aggregate</goal>

29                         </goals>

30                     </execution>

31                 </executions>

32             </plugin>

33     </plugins>

Serenity incluye un fichero de propiedades llamado serenity.properties y que

incluimos en el raíz de nuestro proyecto.

16
En él podemos definir muchas variables que utiliza serenity y agregar nuestras
propiedades.
Podéis consultar todas las que existen
aquí.

Como ejemplo, vamos a incluir el título del reporte:

4. Declaración de un escenario con Cucumber

Creamos un fichero con extensión .feature en los resources de la parte de test

del proyecto maven y describimos un escenario:

Creamos la clase que implemente los pasos del escenario.

Java

17
             public class MyFirstScenario {

1                 

2                     @Given("^some context$")

3                     public void user() throws Throwable {

4                         // Write code here that turns the phrase above into concrete
actions
5
                        throw new PendingException();
6
                    }
7
                
8
                
9
                    @When("^some action is carried out$")
10
                    public void navigatesTo(String url) throws Throwable {
11
                        // Write code here that turns the phrase above into concrete
12 actions

13                         throw new PendingException();

14                     }

15                 

16                     @Then("^a particular set of observable consequences should

obtain$")
17
                    public void mainPageIsDisplayed() throws Throwable {
18
                        // Write code here that turns the phrase above into concrete
19 actions

20                         throw new PendingException();

                    }

18
 Creamos el runner que va a ejectuar los tests:

 @RunWith : el runner de cucumber con serenity

 @CucumberOptions: es propio de cucumber. Tiene varias opciones de
configuración, pero sólo necesitamos asociarle la ruta de las features. Pueden
ser más de una feature o carpetas:

Java

1     import cucumber.api.CucumberOptions;

2     import net.serenitybdd.cucumber.CucumberWithSerenity;

3     import org.junit.runner.RunWith;

4     

5     @RunWith(CucumberWithSerenity.class)

6     @CucumberOptions("src/test/resources/MyFirstFeature.feature")

7     public class RunTest {

8     }

Java

    @RunWith(CucumberWithSerenity.class)
1
    @CucumberOptions(features = {"src/test/resources/myWorkingFeatures",
2
"src/test/resources/myPendingFeatures"})
3
    public class RunTest {
4
    }

19
Java

    @RunWith(CucumberWithSerenity.class)
1
    @CucumberOptions(features =
2 {"src/test/resources/myWorkingFeatures/frist.feature",
"src/test/resources/myPendingFeatures/second.feature"})
3
    public class RunTest {
4
    }

Los test definidos en este runner se pueden ejecutar desde la misma clase:

5. Generar el reporte

Nota:Todo el código de ejemplo generado para mostrar estos test, lo podéis

consultar en github.

20
Anteriormente, en el tercer paso, incluimos un RunTest.java, que es el runner
que acabamos de definir, para ser ejecutado como test de integración.
Al invocar «mvn verify», ejecutará el runner y generará el reporte de serenity.
Por defecto lo crea en target/site/serenity.

Ahí genera el fichero index.html que contiene el reporte.

21
En este ejemplo hemos definido varios escenarios de como cenan los niños

22
pequeños según sus gustos o sus capacidades. Pulsando en cada test, se ve
en detalle la ejecución de cada test.

Por ejemplo, vemos que Sofía cuando cena pescado con patatas, parece que
no le gusta demasiado.

O Jorge, que la leche con cereales no deja nada, le encanta.

23
Aunque parece que todavía no es su momento para tomar tortilla, y hay un
compromiso de hacerlo próximamente:

24
6. Conclusiones

Serenity nos ayuda a implementar los escenarios y tener un reporte del estado
de nuestra aplicación. Tiene una buena integración con cucumber y es
bastante sencilla tanto la configuración inicial como la implementación.
Esto es sólo el principio, iremos conociendo qué otras posibilidades nos ofrece
Serenity.

7. Referencias

 Serenity
 Github
 Código de ejemplo

25
Conceptos básicos para una ejecución en Screenplay

El patrón de screenplay tiene un enfoque de desarrollo encaminado por

comportamiento Behaviour Driven Development (BDD). Esta no es una
herramienta para testing sino una estrategia de desarrollo que se enfoca
en prevenir defectos en lugar de encontrarlos en un ambiente controlado,
tal y como se explica en el artículo BDD para la automatización de pruebas

Para automatizar procesos, también se utiliza la herramienta Cucumber para

implementar metodologías como BDD, las cuales permiten ejecutar
descripciones funcionales escritas en texto plano como pruebas de
software automatizadas.

Para la implementación en los temas de la automatización, debemos tener en

cuenta que se deben manejar ciertos conceptos que abarquen los siguientes
elementos: Runners, User Interface, Features, StepDefinitions, task,
Interactions, Questions y Reports. 

A continuación, explicaremos cada paquete que se maneja en Screenplay para

aclarar dudas sobre las definiciones, entender la mejora desde la forma con
POM hasta Screenplay. Además encontrarás el paso a paso para llevar a cabo
una ejecución simple de un proceso de pruebas. 

Runners: es el ejecutor de los features, tags, glue (donde se encuentra el step

definition), URL del driver y la conexión con excel del drive.

En la imagen podrás ver las configuraciones previas o a tener en cuenta de los

features.

26
 

User Interface: las UI son el mapeo de la interfaz, donde capturaremos todos

los elementos con los cuales podríamos llegar a interactuar durante la
automatización. Además, se le puede añadir la URL donde se iniciará la
prueba.

27
Features: los features son las historias de usuario que se llevarán a cabo en
las pruebas y proveerá los métodos que utilizaremos más adelante para los
StepDefinitions.

StepDefinitions: los Step Definitions son la traducción de los features a

código. Los métodos que se utilizaran son los features (historias de usuario),
por lo tanto, iremos a la clase “RunnerTags”, le daremos clic derecho sobre
ésta, y en la opción “Run as” escogemos “JUnit Test”.

28
Y los pegamos en los StepDefinitions correspondientes.

29
Se deben tener en cuenta las importaciones para las anotaciones @Given,
@When y @Then

Actor

30
Task: son las interacciones que se llevarán a cabo para cumplir con las
historias de usuarios planteadas. Las tasks se pueden caracterizar porque
no se habla en términos de clic, set data o select. Son verbos más amplios
como loguearse formulario, cerrar sesión y buscar.

Tal y como explica Víctor Soto, experto en automatización de pruebas de

Pragma, hay que pensar en términos de tareas. Por ejemplo, para ejecutar la
tarea “Login”, se requiere de algunas Interacciones y saber interpretar cuáles
son esas acciones a llevar a cabo y verificar que sí cumplan con el objetivo
principal.

Interactions: indicar  acciones como dar clic, select,  enviar datos, scroll, entre
otras cosas. 

31
 Qu
estions: son lo assert a llevar a cabo para asegurar el cumplimiento de ciertos
parámetros.

Reports: los reportes generados por medio de los test ejecutados se

visualizarán de la siguiente forma:

32
BDD para la automatización de pruebas
En la actualidad en muchas de las empresas del mundo digital en las que se
desarrolla software, se habla de la  Automatización de pruebas, esto con la
finalidad de sacar productos más rápidos, reducir errores, procesos
automáticos y muchos otros motivos. Probablemente cuando se abarca este
tema lo primero que nos preguntamos es ¿Porque deberíamos hacerlo,  quién
debería hacerlo y cómo hacerlo?, por ello hablaremos de BDD y algunas de las
cosas que se pueden realizar.

¿Qué es BDD (Behavior Driven Development)?

Este se refiere a desarrollo dirigido por comportamientos, BDD no se trata de

una técnica ni tampoco una herramienta de testing, sino que se trata de una
estrategia de desarrollo, que se enfoca en prevenir defectos en lugar de
encontrarlos en un ambiente controlado.

¿Qué es Automatización de pruebas?

Por definición, las pruebas automatizadas son aquellas que se ejecutan sin
requerir la intervención de una persona. En el articulo sobre Selenium
WebDriver podremos encontrar información sobre la herramienta de
automatización Selenium y algunas particularidades para tener en cuenta a la
hora de la automatización de pruebas.

33
 Hoy en día, BDD es una estrategia que encaja muy bien en las
metodologías ágiles, ya que en estas generalmente los requerimientos son
entregados como HU’s (Historias de usuario). Lo que se plantea a través del
desarrollo dirigido por comportamientos es la definición de un lenguaje común
para el negocio y equipo solucionador.

Con BDD las pruebas de aceptación podrían ser escritas directamente en

lenguaje Gherkin sin ningún problema, ya que este es un lenguaje común el
cual lo puede escribir alguien sin conocimientos en programación, lo normal es
que este se encuentre escrito en inglés, aunque algunas personas que no
tienen dominio del inglés lo hacen en el idioma que mejor dominan. A
continuación, un ejemplo de lenguaje Gherkin tomado de Cucumber.

El lenguaje Gherkin no es más que texto con una estructura de 5 palabras

claves con las que construimos sentencias y con estas describimos las
funcionalidades. Este texto se guarda en un archivo con la extensión “.feature”,
las palabras claves que normalmente se utilizan son:

 Feature: Nombre de la funcionalidad que vamos a probar, el título de la

prueba (HU).
 Scenario: por cada prueba que se ejecutara se especifica la
funcionalidad a probar.
 Given: Este sería el contexto del escenario de prueba o las
precondiciones de los datos.
 When: Se especifican el conjunto de las acciones que se van a ejecutar
en el test.
 Then: Aquí se especifica el resultado esperado del test y/o las
validaciones que deseamos realizar.

¿Qué herramientas permiten lenguaje Gherkin?

Las herramientas Cucumber o JBehave, permiten implementación de una

capa de conexión entre lenguaje Gherkin y la interfaz de usuario que se desea
probar, pudiendo así utilizar eso como los pasos de una prueba automatizada.

34
 Una de las principales características cuando hacemos BDD con Cucumber es
que los escenarios de prueba a la funcionalidad se escriben mucho antes de la
elaboración del código de una prueba automatizada. Cuando se escribe en
lenguaje Gherkin sobre Cucumber se utilizan ejemplos concretos de lo que
queremos que haga el software y a medida que se escriben los escenarios,
estos asumen un papel importante como documentación del proyecto y
documentación sobre las pruebas automatizadas.

Pasos para escribir lenguaje Gherkin con cucumber:

1. Crear un archivo con extensión “.feature”  ejemplo

“is_it_Friday_yet.feature”
2. Redactamos la HU con las palabras claves:

Feature: Search for an ítem

To check an item price and add them to shopping cart
as an online customer
user should be able to search for an ítem

3. Redactamos el/los escenarios asociados a esta HU con las palabras

claves:

Scenario: Search products from navigation-menu

Given that Fray wants to buy Sweater
When He searches for Sweater using the navigation menú
Then He should see the list of Sweaters with prices available for sale

Si se ejecuta este fragmento de código en un ide como eclipse podemos ver

que este nos genera la definición de los pasos presionando la tecla F11 en la
consola de la siguiente manera:

You can implement missing steps with the snippets below: 

@Given("^that Fray wants to buy Sweater$")

public void that_Fray_wants_to_buy_Sweater() throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}
@When("^He searches for Sweater using the navigation menú$") public void
He_searches_for_Sweater_using_the_navigation_menú() throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}
@Then("^He should see the list of Sweaters with prices available for
sale$")public void
He_should_see_the_list_of_Sweaters_with_prices_available_for_sale() throws
Throwable {

35
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}

Para finalizar, con el uso del lenguaje gherkin se puede generar

documentación de evidencia, hacer uso de este fragmento de código el cual
puede ser implementado para realización de una prueba E2E o en una prueba
unitaria, ya que podemos realizar el paso a paso de la prueba sobre esa
historia de usuario con la ejecución de cada método o si solo se deseamos
comprobar el resultado final de la prueba.

Cucumber
Software
Descripción
Traducción del inglés-Cucumber es una herramienta de software utilizada por
programadores informáticos que admite el desarrollo basado en el
comportamiento. El enfoque central del Cucumber BDD es su analizador en
lenguaje simple llamado Gherkin.

Pruebas de software

Diagrama que en forma gráfica, evoca la situación en la cual las opiniones y/o
evaluaciones se concretan a través de una multitud de evaluadores y
aportantes (crowdsourced testing), trabajando en forma abierta y participativa
(crowdsourcing).
Las pruebas de software (en inglés software testing) son las investigaciones
empíricas y técnicas cuyo objetivo es proporcionar información objetiva e
independiente sobre la calidad del producto a la parte interesada o  stakeholder.
Es una actividad más en el proceso de control de calidad.

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

Índice

 1Definición
 2Historia
 3Proceso de Desarrollo de Software
o 3.1Pruebas estáticas
o 3.2Pruebas dinámicas
 4Pruebas contra Especificación (ESRE)
 5Tipos de pruebas por su ejecución
 6Enfoques de pruebas
 7Clasificación de las pruebas según lo que verifican
o 7.1Pruebas funcionales
 7.1.1Niveles de prueba
o 7.2Pruebas no funcionales
 8Herramientas para realizar pruebas de software
o 8.1Herramientas en código abierto
o 8.2Herramientas comerciales
 8.2.1Herramientas de gestión de pruebas
 8.2.2Herramientas para pruebas funcionales
 8.2.3Herramientas para pruebas de carga y rendimiento
 9Véase también
 10Referencias
 11Enlaces externos

Definición[editar]
Un caso de pruebas es una breve declaración de algo que debería ser
probado. Es el mecanismo, manual o automático, de verificar si el
comportamiento del sistema es el deseado o no. 1

Historia[editar]
El objetivo de las pruebas es presentar información sobre la calidad del
producto a las personas responsables de este. Las pruebas de calidad
presentan los siguientes objetivos: encontrar defectos o bugs, aumentar la
confianza en el nivel de calidad, facilitar información para la toma de
decisiones, evitar la aparición de defectos.

37
Teniendo esta afirmación en mente, la información que puede ser requerida es
de lo más variada. Esto hace que el proceso de testing sea completamente
dependiente del contexto en el que se desarrolla. 2
El ambiente ideal de las pruebas es aquel que es independiente del desarrollo
del software, de esta manera se logra objetividad en las pruebas.
A pesar de lo que muchos promueven, no existen las "mejores prácticas" como
tales. Toda práctica puede ser ideal para una situación, pero completamente
inútil o incluso perjudicial en otra.
Por esto, las actividades técnicas, documentación, enfoques y demás
elementos que condicionarán las pruebas a realizar deben ser seleccionadas y
utilizadas de la manera más eficiente según contexto del proyecto.

Proceso de Desarrollo de Software[editar]

Tenemos el proceso de desarrollo en cascada, se denomina de este modo, ya
que a cada salida de una etapa cae en la siguiente, es decir, las etapas se
llevan a cabo una a continuación de la otra. Una de las peculiaridades de este
proceso, es que no está previsto volver a una etapa anterior, es decir si se
olvidó relevar algún requerimiento al comienzo, no tiene una alternativa para
considerar este caso. Este proceso supone cada etapa independiente de las
etapas anteriores.
También tenemos el desarrollo iterativo y creciente, se tiene las mismas etapas
que en el Proceso de Desarrollo en Cascada, sin embargo, en este proceso, la
etapa de relevamiento se divide en distintos sub conjuntos,y cada uno de estos
sub conjuntos se construye de la misma forma que con el ciclo de vida en
cascada. Se van desarrollando por partes que luego se integran, una vez
finalizadas las mismas.
Otro Proceso de Desarrollo que tenemos es el Iterativo, en este tenemos las
mismas etapas de desarrollo que los procesos anteriores, pero trabajamos
sobre el todo, no necesariamente conocemos al comienzo todos los detalles
del producto que queremos construir.
Y por último tenemos el desarrollo ágil de software, este es un proceso iterativo
e incremental, se caracteriza por contar con iteraciones cortas y por no tener
fases lineales, tipo cascada en cada iteración. Existen distintas metodologías
Ágiles, que entre las más conocidas y utilizadas encontramos "Scrum" y "XP:
Extreme Programming".
Pruebas estáticas[editar]
Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.
Puede referirse a la revisión de documentos, ya que no se hace una ejecución
de código. Esto se debe a que se pueden realizar "pruebas de escritorio" con el
objetivo de seguir los flujos de la aplicación.
Pruebas dinámicas[editar]
Todas aquellas pruebas que para su ejecución requieren la ejecución de la
aplicación.

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

Pruebas contra Especificación (ESRE)[editar]

Antes de entender para que les sirve a los probadores beta trabajar con el
documento de especificación de requerimientos, debemos saber qué son las
especificaciones de requerimientos (ESRE).
Las Especificaciones de Requerimientos son un documento clave en el
desarrollo de Software. Cuando consideramos los ciclos de vida clásicos, tiene
la descripción completa de lo que va a hacer el sistema sin describir cómo lo va
a hacer. Estos documentos tienen una estructura en forma de reporte bastante
definida, poseen carátula, historial de cambios, introducción, definiciones,
acrónimos y abreviaturas, especificación de requerimientos funcionales,
especificación de requerimientos no funcionales y casos de uso.
Los probadores beta se guían en este documento para validar si el sistema se
comporta de la manera que indican las ESRE. Contiene información detallada
sobre los requisitos funcionales y no funcionales que el Cliente desea en el
sistema. También se pueden ejecutar casos de pruebas a partir de las
especificaciones de requerimientos ya que estos resultan muy útiles porque
son sencillos de seguir y se conocen de antemano los posibles resultados.

Tipos de pruebas por su ejecución[editar]

 Pruebas manuales
 Pruebas automáticas

Enfoques de pruebas[editar]

 Pruebas de Caja blanca

 Pruebas de Caja negra

 Testing aleatorio3

Clasificación de las pruebas según lo que verifican[editar]

Pruebas funcionales[editar]
Artículo principal: Pruebas funcionales

Una prueba funcional es una prueba basada en la ejecución, revisión y

retroalimentación de las funcionalidades previamente diseñadas para el
software (requisitos funcionales). Hay distintos tipos como por ejemplo:

 Pruebas unitarias
 Pruebas de componentes
 Pruebas de integración
 Pruebas de sistema

39
 Pruebas de humo
 Pruebas alpha
 Pruebas beta
 Pruebas de aceptación
 Pruebas de regresión
Niveles de prueba[editar]
Podemos considerar el proceso de pruebas funcionales como un proceso
donde se va probando inicialmente lo de más bajo nivel y se van integrando y
probando paulatinamente componentes hasta lograr un sistema completo
totalmente probado. Por eso se dice que hay distintos niveles de prueba. Se
empieza por las pruebas unitarias, luego las pruebas de Integración, luego las
de pruebas de sistema, las de humo, las alpha, las beta y finalmente las
de pruebas de aceptación.
Las pruebas de regresión se puede considerar como la ejecución (normalmente
automática) de las pruebas ya realizadas hasta el momento.
Pruebas no funcionales[editar]
Una prueba no funcional es una prueba cuyo objetivo es la verificación de un
requisito que especifica criterios que pueden usarse para juzgar la operación
de un sistema (requisitos no funcionales) como por ejemplo la disponibilidad,
accesibilidad, usabilidad, mantenibilidad, seguridad, rendimiento. Podemos
clasificar las pruebas no funcionales según el tipo de requisito no funcional que
abarcan:

 Pruebas de compatibilidad
 Pruebas de seguridad
 Pruebas de Estrés
 Pruebas de usabilidad
 Pruebas de rendimiento
 Pruebas de internacionalización y localización
 Pruebas de escalabilidad
 Pruebas de mantenibilidad
 Pruebas de instalabilidad
 Pruebas de portabilidad

Herramientas para realizar pruebas de software[editar]

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

1. Herramientas de gestión de pruebas

2. Herramientas para pruebas funcionales

40
 3. Herramientas para pruebas de carga y rendimiento
Herramientas en código abierto[editar]

1. Herramientas de gestión de pruebas

 Bugzilla Testopia
 FitNesse
 qaManager
 qaBook
 RTH.5
 Salome-tmf
 Squash TM
 Test Environment Toolkit
 TestLink
 Testitool
 XQual Studio
 Radi-testdir
 Data Generator

1. Herramientas para pruebas funcionales

 Selenium
 Soapui
 Watir
 WatiN (Pruebas de aplicaciones web en .Net)
 Capedit
 Canoo WebTest
 Solex
 Imprimatur
 SAMIE
 ITP
 WET
 WebInject

1. Herramientas para pruebas de carga y rendimiento

 JMeter
 Gatling
 FunkLoad
 FWPTT load testing
 loadUI
Herramientas comerciales[editar]
Herramientas de gestión de pruebas[editar]

 ApTest Manager
41
 HP Quality Center/ALM
 PractiTest
 QA Complete
 QAS.Test Case Studio
 qaBook
 SMARTS
 Silk Central
 SpiraTest
 T-Plan Professional
 TestLog
 Zephyr
Herramientas para pruebas funcionales[editar]

 BASSP testConfig/testExecutor
 Internet Macros
 QA Wizard
 QuickTest Pro
 Ranorex
 Rational Robot
 Sahi
 Silk Test
 SoapTest
 Squish
 Test Complete
 vTest
Herramientas para pruebas de carga y rendimiento[editar]

 ANTS – Advanced .NET Testing System

 Forecast
 HP LoadRunner
 IBM Rational Performance Test (RPT)
 Load Impact
 LoadStorm
 NeoLoad
 Silk Performer
 WebLOAD Professional
 Webserver Stress Too

Caja negra (sistemas)

Ir a la navegación Ir a la búsqueda

Para otros usos de este término, véase Caja negra.

42
Esquema de una caja negra

En teoría de sistemas y física, una caja negra es un elemento que se estudia

desde el punto de vista de las entradas que recibe y las salidas o respuestas
que produce, sin tener en cuenta su funcionamiento interno. En otras palabras,
de una caja negra nos interesará su forma de interactuar con el medio que le
rodea (en ocasiones, otros elementos que también podrían ser cajas negras)
entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace.
Por tanto, de una caja negra deben estar muy bien definidas sus entradas y
salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los
detalles internos de su funcionamiento.

Índice

 1 Justificación
 2 Caja negra y programación modular
 3 Pruebas de software
 4 Caja negra vs 'Cajanegrizar'
 5 Véase también

Justificación

Un sistema formado por módulos que cumplan las características de caja

negra será más fácil de entender ya que permitirá dar una visión más clara del
conjunto. El sistema también será más robusto y fácil de mantener, en caso de
ocurrir un fallo, éste podrá ser aislado y abordado más ágilmente.

Caja negra y programación modular

En programación modular, donde un programa (o un algoritmo) es dividido en

módulos, en la fase de diseño se buscará que cada módulo sea una caja negra
dentro del sistema global que es el programa que se pretende desarrollar, de
esta manera se consigue una independencia entre los módulos que facilita su
implementación separada por un equipo de trabajo donde cada miembro va a
encargarse de implementar una parte (un módulo) del programa global; el
implementador de un módulo concreto deberá conocer como es la
comunicación con los otros módulos (la interfaz), pero no necesitará conocer
como trabajan esos otros módulos internamente; en otras palabras, para el
desarrollador de un módulo, idealmente, el resto de módulos serán cajas
negras. Es muy importante.

Pruebas de software
43
En pruebas de software, conociendo una función específica para la que fue
diseñado el producto, se pueden diseñar pruebas que demuestren que dicha
función está bien realizada. Dichas pruebas son llevadas a cabo sobre la
interfaz del software, es decir, de la función, actuando sobre ella como una caja
negra, proporcionando unas entradas y estudiando las salidas para ver si
concuerdan con las esperadas.

Caja negra vs 'Cajanegrizar'

Este concepto de caja negra utilizado en física, informática y disciplinas

técnicas o tecnológicas en general, aunque está relacionado, no debe
confundirse con el 'Cajanegrismo'; éste es un concepto más vinculado a la
sociología que hace referencia al hecho de que las personas solemos
olvidarnos del funcionamiento interno de las cosas (generalmente nuevos
dispositivos tecnológicos) a medida que nos familiarizamos con ellos y
terminamos por asimilarlos como de uso cotidiano. A este proceso de olvidar el
funcionamiento interno de las cosas se le conoce con el nombre de
'cajanegrizar'.

Se podría decir que la principal diferencia entre ambos conceptos es que

mientras el primero, el estudio de un sistema como una caja negra, es un
proceso de abstracción, el segundo, el 'cajanegrismo', es más bien un proceso
de olvido.

Pruebas de caja blanca

Las pruebas de caja blanca (también conocidas como pruebas de caja de
cristal o pruebas estructurales) se centran en los detalles procedimentales del
software, por lo que su diseño está fuertemente ligado al código fuente. El
ingeniero de pruebas escoge distintos valores de entrada para examinar cada
uno de los posibles flujos de ejecución del programa y cerciorarse de que se
devuelven los valores de salida adecuados.
Al estar basadas en una implementación concreta, si esta se modifica, por
regla general las pruebas también deberán rediseñarse.
Aunque las pruebas de caja blanca son aplicables a varios niveles —
unidad, integración y sistema—, habitualmente se aplican a las unidades de
software. Su cometido es comprobar los flujos de ejecución dentro de cada
unidad (función, clase, módulo, etc.) pero también pueden probar los flujos
entre unidades durante la integración, e incluso entre subsistemas, durante las
pruebas de sistema.
A pesar de que este enfoque permite diseñar pruebas que cubran una amplia
variedad de casos de prueba, podría pasar por alto partes incompletas de
la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva
de todos los flujos de ejecución del código analizado.
Las principales técnicas de diseño de pruebas de caja blanca son:

 Pruebas de flujo de control

 Pruebas de flujo de datos

44
 Pruebas de bifurcación (branch testing)
 Pruebas de caminos básicos

Hacking[editar]
En los análisis de vulnerabilidades y pruebas de penetración de sistemas
informáticos (Pentest), las pruebas de caja blanca hacen referencia a una
metodología donde el ciberdelincuente posee conocimiento total y absoluto del
sistema que pretende atacar. El objetivo de estos tests, que perciben el sistema
de forma transparente, es simular el comportamiento de un intruso malicioso
que contase con permisos de acceso e información precisa acerca del sistema.

Testing aleatorio
Ir a la navegaciónIr a la búsqueda

En el desarrollo de software, el testing es una de las tareas más importantes,

pero también es compleja y no siempre adoptada correctamente. Las Prueba
unitaria, de carga, integración y funcionales son distintos tipos de testing, cada
uno con objetivos diferentes y aplicados en diferentes etapas del desarrollo del
software. En el testing de unidad se desarrollan pruebas individuales sobre
componentes de un sistema. En la codificación de dichas pruebas, se busca
simular el entorno de dicho componente y descubrir la presencia de errores o
“bugs”. Más allá del esfuerzo, las pruebas de unidad pueden probar la
presencia de ciertos errores, pero no pueden asegurar la ausencia de ellos.
Buscando ampliar el ámbito de las pruebas de unidad, se han aplicado diversas
técnicas que van desde la automatización de pasos o caminos de ejecución,
con valores fijos o componentes predefinidos (hard-coded) o estáticos, y
condiciones específicas, hasta los enfoques basados en la generación de
objetos de manera aleatoria,1 aplicados a la Programación Orientada a Objetos.
El fundamento básico de este enfoque propuesto es el testing aleatorio.
Tanto la generación de valores aleatorios para testing, como el testing aleatorio
(RT o random testing) en sí no son técnicas nuevas. Por ej., en el paradigma
funcional existe una herramienta para probar especificaciones sobre funciones
llamada QuickCheck. Esta herramienta (escrita en Haskell) y sus ideas
subyacentes son usadas como fundamento para algunas herramientas
desarrolladas para RT en POO.

AUTOMATIZACIÓN DE PRUEBAS
En las pruebas de software, la automatización de pruebas consiste en el uso
de software especial (casi siempre separado del software que se prueba) para
controlar la ejecución de pruebas y la comparación entre los resultados
obtenidos y los resultados esperados. La automatización de pruebas permite
incluir pruebas repetitivas y necesarias dentro de un proceso formal de pruebas
ya existente o bien adicionar pruebas cuya ejecución manual resultaría difícil.

45
Generalidades[editar]
Algunas pruebas de software tales como las pruebas de regresión intensivas
de bajo nivel pueden ser laboriosas y consumir mucho tiempo para su
ejecución si se realizan manualmente. Adicionalmente, una aproximación
manual puede no ser efectiva para encontrar ciertos tipos de defectos, mientras
que las pruebas automatizadas ofrecen una alternativa que lo permite. Una vez
que una prueba ha sido automatizada, esta puede ejecutarse repetitiva y
rápidamente en particular con productos de software que tienen ciclos de
mantenimiento largo, ya que incluso cambios relativamente menores en la vida
de una aplicación pueden inducir fallos en funcionalidades que anteriormente
operaban de manera correcta. Existen dos aproximaciones a las pruebas
automatizadas:

 Pruebas manejadas por el código: Se prueban las interfaces

públicas de las clases, módulos o bibliotecas con una variedad amplia de
argumentos de entrada y se valida que los resultados obtenidos sean los
esperados.
 Pruebas de Interfaz de Usuario: Un marco de pruebas genera un
conjunto de eventos de la interfaz de usuario, tales como teclear, hacer
click con el ratón e interactuar de otras formas con el software y se
observan los cambios resultantes en la interfaz de usuario, validando que el
comportamiento observable del programa sea el correcto.
La elección misma entre automatización y ejecución manual de pruebas, los
componentes cuya prueba será automatizada, las herramientas de
automatización y otros elementos son críticos en el éxito de las pruebas, y por
lo regular deben provenir de una elección conjunta de los equipos de
desarrollo, control de calidad y administración. Un ejemplo de mala elección
para automatizar, sería escoger componentes cuyas características son
inestables o su proceso de desarrollo implica cambios continuos.

Pruebas manejadas por el código[editar]

En el desarrollo contemporáneo de software existe una tendencia creciente a
usar Frameworks como los denominados XUnit (por ejemplo JUnit y NUnit) que
permiten la ejecución de pruebas unitarias para determinar cuándo varias
secciones del código se comportan como es esperado en circunstancias
específicas. Los casos de prueba describen las pruebas que han de ejecutarse
sobre el programa para verificar que este se ejecuta tal y como se espera. La
automatización de pruebas es una característica clave del desarrollo ágil de
software en donde se le conoce como "desarrollo guiado por pruebas". En
ellas, las pruebas unitarias se escriben antes que el código que genera la
funcionalidad. Solo cuando el código pasa exitosamente las pruebas se
considera completo. Cuando hay cambios, el programador descubre
inmediatamente cualquier defecto que rompa los casos de prueba lo cual baja
el costo de la reparación. Dos inconvenientes de este estilo de trabajo son:

1. Algunas veces se "desperdicia" la capacidad del programador

escribiendo las pruebas unitarias. El entrecomillado se debe
precisamente que asegurar la calidad del producto no es desperdicio
alguno.

46
 2. Normalmente se prueban los requerimientos básicos o el flujo normal
del caso de uso en vez de todos los flujos alternativos, dado que
extender las pruebas más allá de la prueba base eleva el costo del
producto. En algunas ocasiones los flujos alternativos son probados por
un equipo de pruebas más o menos independiente del equipo de
desarrollo.

Pruebas de Interfaz de Usuario[editar]

Muchas herramientas de automatización de pruebas proveen características
para grabar y reproducir acciones del usuario para posteriormente ejecutarlas
un número indefinido de veces, comparando resultados obtenidos con
resultados esperados. La ventaja de esta aproximación a la automatización es
que requiere de menos desarrollo de software, sin embargo el confiar en estas
características del software lo hace menos confiable en la medida que muchas
veces dependen de la etiqueta o posición del elemento de interfaz, y, al
cambiar, el caso de prueba debe ser adaptado al cambio o probablemente
fallar. Una variante de estas pruebas es la prueba de sistemas basados en la
web en las que la herramienta de prueba ejecuta acciones sobre el navegador
e interpreta el HTML resultante. Una variación más es la automatización sin
scripts, que no usa grabación y reproducción de acciones sino que construye
un modelo de la Aplicación Bajo Prueba ABP (AUT en sus siglas en inglés) que
permite a la persona que prueba ("tester") que cree pruebas simplemente
editando parámetros y condiciones.

Proceso Unificado de Rational

El Proceso Unificado de Rational o RUP (por sus siglas en inglés de Rational
Unified Process) es un proceso de desarrollo de software desarrollado por la
empresa Rational Software, actualmente propiedad de IBM.1 Junto con
el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar
más utilizada para el análisis, diseño, implementación y documentación de
sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto
de metodologías adaptables al contexto y necesidades de cada organización.
También se conoce por este nombre al software, también desarrollado por
Rational, que incluye información entrelazada de diversos artefactos y
descripciones de las diversas actividades. Está incluido en el Rational Method
Composer (RMC), que permite la personalización de acuerdo con las
necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso
Unificado, y una especificación más detallada, el Rational Unified Process,
que se vendiera como producto independiente.

Índice

47
 1Principios de desarrollo
o 1.1Adaptar el proceso
o 1.2Equilibrar prioridades
o 1.3Demostrar valor iterativamente
o 1.4Colaboración entre equipos
o 1.5Enfocarse en la calidad
o 1.6Elevar el nivel de abstracción
 2Ciclo de vida
 3Principales características
 4Fases
o 4.1Fase de Inicio
o 4.2Fase de Elaboración
o 4.3Fase de Desarrollo
o 4.4Fase de Transición
 5Artefactos
o 5.1Inicio
o 5.2Elaboración
o 5.3Construcción
o 5.4Transición
 6Historia
 7Comentarios sobre Método
 8Referencias

Principios de desarrollo[editar]
La Filosofía del RUP está basado en 6 principios clave que son los siguientes:
Adaptar el proceso[editar]
El proceso deberá adaptarse a las necesidades del cliente ya que es muy
importante interactuar con él. Las características propias del proyecto, el
tamaño del mismo, así como su tipo o las regulaciones que lo condicionen,
influirán en su diseño específico. También se deberá tener en cuenta el alcance
del proyecto.
Equilibrar prioridades[editar]
Los requisitos de los diversos participantes pueden ser diferentes,
contradictorios o disputarse recursos limitados. Debe poder encontrarse un
equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán
corregir desacuerdos que surjan en el futuro. Al igual esta metodología está
acorde con UML, Unificado Modelo Lenguajes'
Demostrar valor iterativamente[editar]
Los proyectos se entregan, aunque sea de un modo interno, en etapas
iteradas. En cada iteración se analiza la opinión de los inversores, la
estabilidad y calidad del producto, y se refina la dirección del proyecto así como
también los riesgos involucrados.

48
Colaboración entre equipos[editar]
El desarrollo de software no lo hace una única persona sino múltiples equipos.
Debe haber una comunicación fluida para coordinar requisitos, desarrollo,
evaluaciones, planes, resultados, etc.
Enfocarse en la calidad[editar]
El control de calidad no debe realizarse al final de cada iteración, sino
en todos los aspectos de la producción. El aseguramiento de la calidad forma
parte del proceso de desarrollo y no de un grupo independiente, también es
una estrategia de desarrollo de software.
Elevar el nivel de abstracción[editar]
Artículo principal: Abstracción (informática)

Este principio dominante motiva el uso de conceptos reutilizables tales

como patrones de diseño del software, lenguajes 4GL o esquemas
(frameworks) por nombrar algunos. Estos se pueden acompañar por las
representaciones visuales de la arquitectura, por ejemplo con UML.

Ciclo de vida[editar]

Esfuerzo en actividades según fase del proyecto.

El ciclo de vida RUP es una implementación del desarrollo en espiral. Fue
creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de
vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan pocas
pero grandes y formales iteraciones en número variable según el proyecto. En
la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la
fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia
la comprensión del problema y la tecnología, la delimitación del ámbito del
proyecto, la eliminación de los riesgos críticos, y al establecimiento de
una baseline (línea base)2 de la arquitectura.
Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de
modelado del negocio y de requisitos.

49
En la fase de elaboración, las iteraciones se orientan al desarrollo de la
baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos,
modelo de negocios (refinamiento), análisis, diseño y una parte de
implementación orientado a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por
medio de una serie de iteraciones.
Para cada iteración se seleccionan algunos Casos de Uso, se refinan su
análisis y diseño y se procede a su implementación y pruebas. Se realiza una
pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine
la implementación de la nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto
preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero
dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

Principales características[editar]

 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software
 Pretende implementar las mejores prácticas en Ingeniería de Software,
de forma que se adapte a cualquier proyecto
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e
incremental, estar centrado en la arquitectura y guiado por los casos de uso.
Incluye artefactos (que son los productos tangibles del proceso como por
ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que
desempeña una persona en un determinado momento, una persona puede
desempeñar distintos roles a lo largo del proceso).

Fases[editar]

 Establece oportunidad y alcance

 Identifica las entidades externas o actores con las que se trata
 Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se establecen las
disciplinas:
Proceso
Las etapas de esta sección son: (revisar nuevamente la gráfica)

 Modelado de negocio
 Requisitos
 Análisis y Diseño

50
 Implementación
 Pruebas
 Despliegue
Soporte
En esta parte nos encontramos con las siguientes etapas:

 Gestión del cambio y configuraciones

 Gestión del proyecto
 Entorno
La estructura dinámica de RUP es la que permite que éste sea un
proceso de desarrollo fundamentalmente iterativo, y en esta parte se
ven inmersas las cuatro fases descritas anteriormente:

1. Inicio (también llamado Incepción o Concepción).

2. Elaboración.
3. Desarrollo (también llamado Implementación, Construcción).
4. Cierre (también llamado Transición).
Fase de Inicio[editar]
Esta fase tiene como propósito definir y acordar el alcance del proyecto
con los patrocinadores o alumnos de un proyecto en el cual tenemos
que, identificar los riesgos asociados al proyecto, proponer una visión
muy general de la arquitectura de software y producir el plan de las
fases y el de iteraciones posteriores.
Fase de Elaboración [editar]
En la fase de elaboración se seleccionan los casos de uso que permiten
definir la arquitectura base del sistema y se desarrollaran en esta fase,
se realiza la especificación de los casos de uso seleccionados y el
primer análisis del dominio del problema, se diseña la solución
preliminar.
Fase de Desarrollo [editar]
El propósito de esta fase es completar la funcionalidad del sistema, para
ello se deben clarificar los requisitos pendientes, administrar los
cambios de acuerdo a las evaluaciones realizados por los usuarios y se
realizan las mejoras para el proyecto.
Fase de Transición [editar]
El propósito de esta fase es asegurar que el software esté disponible
para los usuarios finales, ajustar los errores y defectos encontrados en
las pruebas de aceptación, capacitar a los usuarios y proveer el soporte
técnico necesario. Se debe verificar que el producto cumpla con las
especificaciones entregadas por las personas involucradas en el
proyecto.

Artefactos[editar]

51
RUP en cada una de sus fases (pertenecientes a la estructura dinámica)
realiza una serie de artefactos que sirven para comprender mejor tanto
el análisis como el diseño del sistema (entre otros). Estos artefactos
(entre otros) son los siguientes:
Inicio[editar]

 Documento Visión.
 Diagramas de caso de uso.
 Especificación de Requisitos.
 Diagrama de Requisitos.
Elaboración[editar]
 Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lógica

o Diagrama de clases
o Modelo E-R (Si el sistema así lo requiere)
Vista de Implementación

o Diagrama de Secuencia
o Diagrama de estados
o Diagrama de Colaboración
Vista Conceptual

o Modelo de dominio
Vista física

o Mapa de comportamiento a nivel de hardware.

 Diseño y desarrollo de casos de uso, o flujos de casos de uso
arquitectónicos
 Pruebas de los casos de uso desarrollados, que demuestran que la
arquitectura documentada responde adecuadamente a
requerimientos funcionales y no funcionales.
Construcción[editar]

 Especificación de requisitos faltantes

 Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la
planeación iterativa
 Pruebas de los casos de uso desarrollados, y pruebas de regresión
según sea el caso
Transición[editar]

 Pruebas finales de aceptación

 Puesta en producción
 Estabilización

52
 Historia[editar]
Los orígenes de RUP se remontan al modelo espiral original de Barry
Boehm. Ken Hartman, uno de los contribuidores claves de RUP
colaboró con Boehm en la investigación. En 1995, Rational Software
compró una compañía sueca llamada Objectory AB, fundada por Ivar
Jacobson, famoso por haber incorporado los casos de uso a los
métodos de desarrollo orientados a objetos. El Rational Unified
Process fue el resultado de una convergencia de Rational Approach y
Objectory (el proceso de la empresa Objectory AB). El primer resultado
de esta fusión fue el Rational Objectory Process, la primera versión de
RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe
Philippe Kruchten.
El primer libro para describir el proceso fue titulado The Unified
Software Development Process3
En 2006, IBM creó un subconjunto de RUP ajustado para proyectos
de desarrollo ágil - publicado como un método libre, llamado OpenUP a
través del sitio de Eclipse.4

Comentarios sobre Método[editar]

Por otro lado, en lo que se refiere a la metodología esta comprende tres
principios claves: Dirigido por los casos de uso, centrado en la
arquitectura, iterativo e incremental.
En lo referente a "dirigido por los casos de uso", significa que los
requerimientos están enfocados a dar valor al cliente y que el proceso
debe garantizar que todo el desarrollo, pruebas, planificación,
documentación, etc., está orientado a cubrir estas expectativas del
cliente y asegurar que los requerimientos de valor se ponen en
producción.
En lo referente a "centrado en arquitectura", significa que hay un énfasis
a diseñar una arquitectura de calidad, y es la arquitectura también la
que guía la forma cómo se debe planear y hacer el desarrollo.
En lo referente a "iterativo e incremental", significa que el proyecto se
divide en varios ciclos de vida (llamadas iteraciones) que deben dar
como resultado un ejecutable. Por cada una de las iteraciones se va
agregando requerimientos y sobre todo valor al cliente; por este motivo
es incremental..

ISTQB. ¿Qué es? ¿Cuales son los niveles de certificación?

53
 El ISTQB (International Software Testing
Qualifications Board)  es una organización de certificación de la calidad del
software que opera internacionalmente. El ISTQB fue fundado en noviembre de
2002 en Edimburgo y está legalmente registrado en Bélgica. Esta organización
se encarga de soportar y definir un esquema de certificación internacional.
Suministra el plan de estudios y el glosario sobre los que se definen los que se
establecen las guías para la acreditación y evaluación de los profesionales del
testing a cargo de los comités de cada país Según ellos mismos, el ISTQB ha
creado esquema más exitoso del mundo para la certificación de los probadores
de software. Hasta junio de 2013, ha certificado a más de 307.000 testers en
70 países en todo el mundo, con una tasa de crecimiento de aproximadamente
12.000 certificaciones por trimestre.

Es decir, la certificación ISTQB, junto con TMAP, es la única certificación a

nivel personal de cierta importancia a nivel de Calidad del Software. Cuando
digo a nivel personal, me refiero a que las organizaciones pueden obtener otras
certificaciones, pero como tester o ingeniero de calidad, stas 2 son las únicas
con cierta importancia a nivel europeo.

Actualmente hay 4 niveles de certificación según ISTQB:

 ISTQB Foundation Level (CTFL)

 ISTQB Advanced Level (CTAL)
 Test Manager
 Test Analyst
 Technical Test Analyst
 Advanced Level (CTAL) – Full Advanced Level (after passing the above
exams of Advanced Level)
 Expert Level
 Improving the Test Process
 Test Management
 Test Automation (Previsto para implementarse en 2014)
 Security Testing (Previsto para implementarse en 2015)

54
Certificaciones ISTQB
Si decides ir adelante con la certificación, aquí te dejamos algunos enlaces de
interés. Para más información podéis visitar el artículo ISTQB – Material de
Estudio de la web Testing en Español.

Metodología de Desarrollo Tradicional RUP

 Ing. Pedro Elías Pabón
 

 31 Julio 2018

La metodología de desarrollo RUP por sus siglas en inglés ó Proceso de
Desarrollo Unificado es un proceso de desarrollo de software y junto con el
Lenguaje Unificado de Modelado UML, constituye la metodología estándar más
utilizada para el análisis, implementación y documentación de sistemas
orientados a objetos. El RUP no es un sistema con pasos firmemente
establecidos, sino un conjunto de metodologías adaptables al contexto y
necesidades de cada organización.
 
Principales Características:

 Desarrollo iterativo.
 Forma disciplinada de asignar tareas y responsabilidades (quién hace
qué, cuándo y cómo).
 Pretende implementar las mejores prácticas en Ingeniería de Software.
 Administración de requisito.
 Uso de arquitectura basada en componentes.
 Control de cambios.
 Modelado visual del software.
 Verificación de la calidad del software.

55
 
Ciclo de Vida:

 
El ciclo de vida RUP es una implementación del desarrollo en espiral. Fue
creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de
vida organiza las tareas en fases e iteraciones. RUP divide el proceso en
cuatro fases, dentro de las cuales se realizan pocas pero grandes y formales
iteraciones en número variable según el proyecto. En la Figura muestra cómo
varía el esfuerzo asociado a las disciplinas según la fase en la que se
encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia
la comprensión del problema y la tecnología, la delimitación del ámbito del
proyecto, la eliminación de los riesgos críticos, y al establecimiento de una
baseline (línea base)2 de la arquitectura.
Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de
modelado del negocio y de requisitos.

 En la fase de elaboración, las iteraciones se orientan al desarrollo de la

baseline de la arquitectura, abarcan más los flujos de trabajo de
requisitos, modelo de negocios (refinamiento), análisis, diseño y una
parte de implementación orientado a la baseline de la arquitectura.
 En la fase de construcción, se lleva a cabo la construcción del producto
por medio de una serie de iteraciones.

Para cada iteración se seleccionan algunos Casos de Uso, se refinan su

análisis y diseño y se procede a su implementación y pruebas. Se realiza una
pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine
la implementación de la nueva versión del producto.

 En la fase de transición se pretende garantizar que se tiene un producto

preparado para su entrega a la comunidad de usuarios.

56
Como se puede observar en cada fase participan todas las disciplinas, pero
dependiendo de la fase el esfuerzo dedicado a una disciplina varía.
 
Fases:

1. Fase de Inicio: Esta fase tiene como propósito definir y acordar el

alcance del proyecto con los patrocinadores, identificar los riesgos
asociados al proyecto, proponer una visión muy general de la
arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.
2. Fase de elaboración: En la fase de elaboración se seleccionan los casos
de uso que permiten definir la arquitectura base del sistema y se
desarrollaran en esta fase, se realiza la especificación de los casos de
uso seleccionados y el primer análisis del dominio del problema, se
diseña la solución preliminar.
3. Fase de Desarrollo: El propósito de esta fase es completar la
funcionalidad del sistema, para ello se deben clarificar los
requerimientos pendientes, administrar los cambios de acuerdo a las
evaluaciones realizados por los usuarios y se realizan las mejoras para
el proyecto.
4. Fase de Cierre: El propósito de esta fase es asegurar que el software
esté disponible para los usuarios finales, ajustar los errores y defectos
encontrados en las pruebas de aceptación, capacitar a los usuarios y
proveer el soporte técnico necesario. Se debe verificar que el producto
cumpla con las especificaciones entregadas por las personas
involucradas en el proyecto.

Metodología de desarrollo de software.

El Modelo en V o de Cuatro Niveles.
El Método-V define un procedimiento uniforme para el desarrollo de productos
para las TIC. Es el estándar utilizado para los proyectos de la Administración
Federal Alemán y de defensa. Como está disponible públicamente muchas
compañías lo usan. Es un método de gestión de proyectos comparable
a PRINCE2 y describe tanto métodos para la gestión como para el desarrollo
de sistemas.
La versión actual del Método-V es el Método-V XT que se terminó en Febrero
del 2005. No es comparable con CMMI. Mientras que CMMI solo describe
"qué" se ha hecho, el Método-V describe el "cómo" y el "cuándo" y "quién" es el
responsable de haberlo hecho.
El Método-V fue desarrollado para regular el proceso de desarrollo de software
por la Administración Federal Alemana. Describe las actividades y los
resultados que se producen durante el desarrollo del software.
El Método-V es una representación gráfica del ciclo de vida del desarrollo del
sistema. Resume los pasos principales que hay que tomar en conjunción con
las correspondientes entregas de los sistemas de validación.

57
 La parte izquierda de la V representa la corriente donde se definen las
especificaciones del sistema. La parte derecha de la V representa la corriente
donde se comprueba el sistema (contra las especificaciones definidas en la
parte izquierda). La parte de abajo, donde se encuentran ambas partes,
representa la corriente de desarrollo.
La corriente de especificación consiste principalmente de:
 Especificaciones de requerimiento de usuario
 Especificaciones funcionales
 Especificaciones de diseño
La corriente de pruebas, por su parte, suele consistir de:
 Calificación de instalación
 Calificación operacional
 Calificación de rendimiento
los proyectos lleguen finalmente a ser exitosos desde los puntos de vista de
objetivos de negocio, costos, funcionalidad, sencillez y capacidad de soporte.
La corriente de desarrollo puede consistir (depende del tipo de sistema y del
alcance del desarrollo) en personalización, configuración o codificación.
Pero la contra al chiste clásico de la implementación de soluciones de cómputo
puede lograrse utilizando metodologías de ingeniería y arquitectura de
software, logrando que
En general las metodologías llevan a cabo una serie de procesos comunes que
son buenas prácticas para lograr los objetivos antes mencionados
independientemente de cómo hayan sido diseñadas. Las fases que agrupan
estos procesos son las siguientes:
 Análisis 
 Especificación 
 Diseño 
 Programación 
 Prueba 
 Documentación 
 Mantenimiento 
 Reingeniería 
Así mismo las diferentes metodologías tienen diversos ciclos de vida del
desarrollo de software, los modelos más comúnmente utilizados son los
siguientes:
 Modelo en cascada 
 Modelo en espiral 
 Modelo de prototipos 
 Método en V 
 Desarrollo por etapas 
Escribiré más adelante acerca de cada una de las metodologías mencionadas
a continuación de forma más extensa posteriormente, por lo pronto dejaré
abierta la investigación a los lectores acerca de los diferentes marcos de
trabajo y metodologías formales de desarrollo de software. Las metodologías a
tratar desde el punto de vista de la arquitectura de software y la administración
de proyectos serán las siguientes:
Metodologías tradicionales 
 Capability Maturity Model (SW-CMM) 
 Capability Maturity Model Integration for Development (CMMI-DEV) 

58
 Big Design Up Front (BDUF) 
 Cleanroom Software Engineering 
 Rational Unified Process (RUP) 
 Essential Unified Process for Software Development (EssUP) 
 Fusebox Lifecycle Process (FLiP) 
 Software Process Improvement and Capability dEtermination (SPICE) 
 Métrica 
 Jackson System Development (JSD) 
 Joint Application Development (JAD) 
 Open Unified Process (OpenUP) 
Metodologías ágiles 
 Extreme Programming (XP) 
 Scrum 
 Agile Modeling Adaptive Software Development (ASD) 
 Crystal Clear 
 Dynamic Systems Development Method (DSDM) 
 Feature Driven Development (FDD) 
 Lean Software Development (LSD) 
 Agile Unified Process (AUP) 
 Software Development Rhythms 
 Agile Documentation 
 ICONIX Process 
 Microsoft Solutions Framework (MSF) 
 Agile Data Method 
 Database Refactoring 
 LeanCMMI 
Debido a la coyuntura económica internacional, que diría mi primo) que quiero
construirme una casa.
¿Qué pensaríais de mí si empezara a poner ladrillos sin antes haber hecho un
estudio...
...del suelo, materiales, recursos, y sin haber hecho un diseño previo?
Pensaríais de mí, lo mismo que yo pienso de la gente que se pone a programar
sin seguir una metodología de programación.
La metodología que os presento es el Modelo en V, o Modelo de Cuatro
Niveles. 
¿En qué casos la utilizo?
Se trata de un proceso ideal, por su robustez, para proyectos pequeños, con
equipos de una a cinco personas. 
También es ideal, por su claridad, para toda esa gente que nunca ha
programado siguiendo una metodología. Para el proyecto final de carrera o
para ese cliente que te ha conseguido un amigo de un amigo que te lo pide a ti
y no se dirige a una empresa por esto de la desaceleración.
¿En que consiste exactamente?
La figura que aparece a continuación presenta el Modelo en V, o Modelo de
Cuatro Niveles, del ciclo de vida de un proyecto de desarrollo de software. El
modelo representa, en forma de V, las relaciones temporales entre las distintas
fases del ciclo de desarrollo de un proyecto.  

59
 En los niveles lógicos del 1 al 4, para cada fase del desarrollo, existe una fase
correspondiente o paralela de verificación o validación. Esta estructura
obedece al principio de que para cada fase del desarrollo debe existir un
resultado verificable.
En la misma estructura se advierte también que la proximidad entre una fase
del desarrollo y su fase de verificación correspondiente va decreciendo a
medida que aumenta el nivel dentro de la V. La longitud de esta separación
intenta ser proporcional a la distancia en el tiempo entre una fase y su
homóloga de verificación.
 El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del
proyecto constituyen los dos extremos del ciclo. Se compone del análisis de
requisitos y especificaciones, se traduce en un documento de requisitos y
especificaciones.
 El nivel 2 se dedica a las características funcionales del sistema
propuesto. Puede considerarse el sistema como una caja negra, y
caracterizarla únicamente con aquellas funciones que son directa o
indirectamente visibles por el usuario final, se traduce en un documento
de análisis funcional.
 El nivel 3 define los componentes hardware y software del sistema final,
a cuyo conjunto se denomina arquitectura del sistema.
 El nivel 4 es la fase de implementación, en la que se desarrollan los
elementos unitarios o módulos del programa.

60
¿Tengo que hacer documentación de todo?
Por supuesto. Cada fase tiene que estar respaldada por su documento
correspondiente y test.
¿Por qué utilizar una metodología?
Porque es lo más rápido y barato. Volviendo al ejemplo de la casa, imaginad la
cantidad de veces que debería volver atrás y tirar paredes ya hechas porque de
pronto descubro que el suelo es inestable, la bañera no cabe, la instalación
eléctrica no la había tenido en cuenta… 
Pues, con el código pasa exactamente lo mismo.

Pruebas de carga

En Inglés: “load testing”.

Pruebas de carga es el tipo de prueba relacionado con medida del

comportamiento de un componente o sistema con una carga creciente, por
ejemplo el número de usuarios concurrentes y/o número de transacciones para
determinar qué carga puede ser soportada por el componente o sistema.

¿Conoces la diferencia entre Pruebas de Carga, Capacidad y Estrés?

octubre 2, 2018/en Contenidos Técnicos /por GreenSQA

En GreenSQA implementamos diferentes tipos de pruebas que permiten

simular el entorno de operación real de un sistema de información diseñado
para atender una gran demanda de usuarios y su comportamiento en
situaciones adversas. En nuestra compañía contemplamos tres tipos de
pruebas que permiten evaluar la llegada de usuarios sobre el sistema y así
determinar su comportamiento frente a la demanda de los usuarios.

Conoce algunas de los tipos de evaluación que usamos en nuestro servicio de

Pruebas no Funcionales:

1. Carga – Load test

Con esta prueba, la

empresa puede conocer la cantidad de usuarios que soporta su producto, en

61
un lapso de tiempo determinado, según los usuarios que espera tender el
cliente en su sistema, sin forzarlo a una capacidad mayor a la esperada.

Por ejemplo: Se necesita probar un puente para saber su comportamiento con

100 personas sobre él (el dato de la cantidad es determinado por el cliente), los
arquitectos de pruebas lo que hacen es dividir este grupo total en grupos más
pequeños que vayan ingresando al puente de manera paulatina en un lapso de
tiempo (5 personas inician, al minutos ingresan otras 5 y así sucesivamente
hasta completar las 100 personas) y con una actividad específica como
“saltar” , lo que al final permite evaluar el comportamiento del puente y si su
estructura y estado final tuvieron el comportamiento saludable para soportar
esta actividad.

2. Capacidad – Capacity Test

El objetivo de las pruebas de capacidad es evaluar el punto de quiebre de la

aplicación, es determinar la carga máxima de usuarios que puede soportar la
aplicación (escalabilidad).  Tomando nuevamente el ejemplo de la analogía del
puente se agregaría más personas por intervalo de tiempo superando las 100
personas que inicialmente esperábamos que soportara el puente, ejemplo 150
personas en total, siempre haciendo pausas entre cada grupo que se suman a
las que ya están saltando en el puente, llegando hasta el punto puente colapse
o se vea seriamente afectado, de esta manera nos daríamos cuenta de que
capacidad tiene el sistema para atender usuarios de manera concurrente.

3. Estrés – Stress Test

62
Acá colocamos a prueba la robustez y la confiabilidad del software probado,
sometiéndolo a condiciones de uso extremas. Entre estas condiciones se
incluyen el envío excesivo de peticiones y la ejecución en condiciones de
hardware limitadas. El objetivo es saturar el programa hasta un punto de
quiebre donde aparezcan bugs (defectos) potencialmente peligrosos y verificar
si los mismos pueden recuperar sus recursos físicos de forma autónoma sin
requerir la intervención humana.

Por ejemplo: Continuando con el ejemplo de personas saltando sobre el

puente, en esta prueba colocamos a las mismas 150 personas de participaron
en la prueba de capacidad, pero sin pausa entre salto y salto, con el objetivo de
evidenciar si el puente puede recuperar su forma después de alterar su
estructura durante la prueba.

GreenSQA
Somos una empresa especializada en la implementación de estándares,
metodologías y modelos usados en la Industria del software a nivel mundial
para las pruebas y el aseguramiento de calidad tanto de los productos de
software como del proceso productivo para su desarrollo.
greensqa.com/

¿QUÉ SON LAS PRUEBAS DE RENDIMIENTO?

Home/.Net/¿Qué son las pruebas de rendimiento?

63
Las pruebas de rendimiento son un conjunto de pruebas que nos permiten
medir la velocidad de ejecución de una serie de tareas en un sistema, bajo
unas condiciones determinadas.

De esta forma, podremos:

o Demostrar si el sistema cumple con los criterios establecidos

o Comparar sistemas para evaluar cuál de ellos se ejecuta más rápido
o Detectar cuellos de botella (qué partes del sistema se ejecutan de una
manera menos óptima afectando de esta manera a la ejecución global).

  Tipos de pruebas

Existen diferentes tipos de pruebas de rendimiento, siendo las más destacadas:

 Pruebas de carga: 

Una prueba de carga se ejecuta para comprender el comportamiento de un

sistema ante una carga determinada. Esta carga puede ser el número de
usuarios esperado en producción o un número de transacciones durante un
tiempo determinado.

El objetivo de este tipo de pruebas es determinar cuáles son las transacciones

más críticas para una posible optimización de las mismas, detectando posibles
cuellos de botella y corrigiendo los mismos para mejorar el rendimiento.

 Pruebas de stress: 

Estas pruebas son utilizadas normalmente para someter a la aplicación al

límite de su funcionamiento mediante la ejecución de un número de usuarios
muy superior al esperado, o bien, mediante la substracción de recursos
(también conocidas como pruebas negativas donde se simula por ejemplo el
fallo de un servidor en clúster).

La finalidad de este tipo de prueba es la de determinar la robustez de una

aplicación cuando la carga es extrema facilitando la configuración de las
alarmas del sistema cuando se alcancen ciertos límites.

 Pruebas de resistencia: 

64
Se realizan con el fin de determinar si la aplicación puede mantener la carga
esperada de manera continuada y durante un largo periodo de tiempo. El
objetivo principal de este tipo de pruebas es verificar que no existen fugas de
memoria o procesos que pierdan rendimiento transcurrido un cierto periodo de
tiempo.

  ¿Cuándo debemos ejecutar este tipo de pruebas?

Para alcanzar en un sistema un nivel de rendimiento acorde con los criterios

establecidos, es fundamental que los esfuerzos en estas pruebas comiencen
desde el inicio del desarrollo y se amplíen durante su construcción. 

Cuanto más se tarde en detectar un defecto de rendimiento, mayor es el coste

de la solución. Esto es cierto en el caso de las pruebas funcionales, pero
mucho más en las pruebas de rendimiento.

  ¿Cómo debemos ejecutarlas?

En las pruebas de rendimiento es imprescindible que las condiciones de

prueba sean similares a las esperadas en el uso real. De no ser así, las
conclusiones a las que lleguemos serán difícilmente extrapolables al entorno
productivo.

Tenemos contras con un plan de pruebas detallado en que debemos tener

identificados los casos de uso más representativos que serán el objeto de
nuestro estudio.

La ejecución de estas pruebas lleva un trabajo de preparación, recolección y

análisis, por lo que es importante planificarlas dentro de nuestro roadmap de
proyecto.

  ¿Qué etapas debemos seguir?

En la siguiente imagen se muestra un ejemplo del conjunto

de pasos/etapas que debemos tener en cuenta a la hora de realizar nuestras
pruebas de rendimiento:

65
 

 En la etapa de planificación definiremos nuestra estrategia de pruebas,

fijando unos objetivos que sean medibles, concretos y evaluables, y así,
obtendremos la información necesaria relativa a los entornos que vamos
a necesitar, herramientas, personas implicadas, etc. Y analizaremos los
casos de prueba que van a ser incluidos en nuestras pruebas de
rendimiento.

 Durante la fase de preparación realizaremos el aprovisionamiento

necesario, configuraremos monitores que nos permitan obtener los datos
de la ejecución de pruebas, y realizaremos unas pequeñas pruebas de
humo que nos permitan determinar que todo está correctamente
configurado y listo para la siguiente fase.

 Estableceremos una línea fase gracias a la preparación realizada y

comenzaremos con la ejecución de los diferentes tipos de prueba que
queramos realizar.

 Finalmente, en la fase de resultados, tendremos que recopilar los datos

de los monitores, evaluar la información y realizar un informe con las
conclusiones que hayamos sacado tras el estudio realizado. En dicho
informe debemos reflejar aquellos aspectos que influyen de forma
negativa en el sistema, de forma que puedan ser adaptados y/o
mitigados.

 Tras los cambios introducidos debemos volver a realizar todo el

ciclo definido con el objetivo de poder comparar el sistema antes de los
cambios y tras los mismos, determinando si las mejoras aplicadas han
sido efectivas o es necesario seguir adaptando elementos del sistema.

Pruebas de rendimiento

El servicio de Pruebas de Rendimiento del Software de MTP se orienta hacia la

optimización del software desde el punto de vista de la eficacia de las
aplicaciones, es decir, la ejecución de este tipo de pruebas de calidad del
software evita los diferentes problemas derivados del rendimiento de las
aplicaciones, aumentando su disponibilidad y la optimización de costes.

Dentro del concepto de pruebas de rendimiento se incluyen:

66
 Pruebas de Carga. Se comprueba si el sistema es capaz de asumir la
carga esperada, con tiempos de respuesta aceptables y consumos de recursos que
no pongan en peligro la producción.
 Pruebas de Capacidad. Se obtienen los límites de funcionamiento del
sistema y los elementos que limitan el rendimiento dentro de la plataforma.
 Pruebas de Estabilidad. Permiten garantizar el correcto uso de los
recursos por parte de la aplicación durante un periodo prolongado de tiempo.
 Pruebas de Estrés o sobrecarga. Se somete al sistema a un nivel de
carga por encima de lo esperado, pero que puede llegar a producirse bajo
determinadas circunstancias.
 Pruebas de Aislamiento. Se comprueba el correcto funcionamiento de
cada uno de los elementos que forman arquitecturas complejas.
 Pruebas de Regresión. Se compara el rendimiento actual de una
aplicación con el que tenía antes de una implantación.

Entre los beneficios asociados al servicio de Pruebas de Rendimiento

de Calidad del Software de MTP sobresalen:

 Disponer de equipos especializados con experiencia en el uso de las

principales herramientas de prestaciones del mercado.
 Garantizar que los sistemas evolucionan correctamente en cuanto a su
rendimiento gracias al uso de una metodología propia de pruebas de regresión,
mediante el uso de termómetros y líneas base.
 Mayor visibilidad de estas pruebas para todos los implicados en los
proyectos.

PRUEBAS DE RENDIMIENTO

El servicio de pruebas de rendimiento de software se centra en determinar la

velocidad con la que el sistema bajo pruebas realiza una tarea en las
condiciones particulares del escenario de pruebas. Este servicio ayuda a su
organización a detectar los cuellos de botella de su aplicación, antes de que
sus usuarios sufran un mal rendimiento, con la consecuente pérdida económica
y frustración de sus clientes o empleados.
Globe Testing se centra en buscar objetivos claros para cada una de las
pruebas de rendimiento que realiza, en lugar de generar carga en un sistema
sin un fin concreto.

METODOLOGIAS ÁGILES

En la situación actual en el que los cambios se producen de manera

increíblemente rápida y se producen cambios dentro de los cambios, muchos
autores comentan que las guías tradicionales de gestión de proyectos intentan
ver el futuro. Ahora es necesario modelos que nos ayuden a adaptarnos a los
cambios. Esta afirmación es mucha más acertada en el sector de las

67
 tecnologías de la información y las comunicaciones (TIC) en el que la velocidad
y agilidad al cambio es fundamental. Por esta razón, surgen las metodologías
ágiles.
Contenidos [hide]
 1 ¿QUÉ ES METODOLOGÍA AGILE?
o 1.1 Metodología Ágile
o 1.2 Metodologías Tradicionales
 2 MANIFIESTO ÁGIL
 3 ALGUNOS TIPOS DE METODOLOGÍAS ÁGILES
o 3.1 1. metodologia agile Scrum
o 3.2 2. Programación Extrema – XP
o 3.3 3. metodologia agile Kanban
o 3.4 1.-metodologia agile Scrum
o 3.5 2.- Programación Extrema (XP)
o 3.6 3.- metodologia agile Kanban
 4 LA METODOLOGÍA ÁGIL MÁS USADA: SCRUM
¿QUÉ ES METODOLOGÍA AGILE?
A menudo me hacen la pregunta: ¿Qué es la metodología agile? En pocas
palabras, agile en informática, se usa para describir un método alternativo de
gestión de proyectos.
Agile es un proceso que ayuda a los equipos a proporcionar respuestas rápidas
a los cambios que se reciben sobre su proyecto. ¿Esto qué significa? Pues que
crea oportunidades para evaluar la dirección de un proyecto durante el ciclo de
desarrollo del mismo. Los equipos evalúan el proyecto en reuniones regulares
llamadas sprints o iteraciones.
Este 2019 he querido poner en un cuadro las diferencias más significativas que
existen entre la metodología agile y las metodologías tradicionales.
METODOLOGÍA ÁGILE METODOLOGÍAS
TRADICIONALES

– Flexibilidad ante los cambios del – Rigidez ante los cambios, de

proyecto de forma moderada a manera lentos o moderada
rápida – Los clientes interactúan con el
– Los clientes hacen parte del equipo de desarrollo mediante
equipo de desarrollo reuniones
– Grupos pequeños (promedio 10 – Grupos de gran tamaño y varias
participantes in situ) en el mismo veces distribuidos en diferentes
lugar. sitios
– Menor dependencia de la – Dependencia de la arquitectura de

68
 arquitectura de software software mediante modelos
– Continuo Feedback acortando el – Poco Feedback lo que extiende el
tiempo de entrega tiempo de entrega
– Diversidad de roles – Mínimos roles
– Basadas en heurísticas a partir de – Basadas en normas de estándares
prácticas de producción de código de desarrollo
– Procesos menos controlados, – Procesos muy controlados por
pocas políticas y normas políticas y normas
– Capacidad de respuesta ante los – Seguimiento estricto del plan inicial
cambios de desarrollo

Tanto los métodos de desarrollo de software tradicionales como los ágiles

tienen sus propias ventajas y desventajas.

TE PUEDE INTERESAR: Metodología SCRUM

El método de desarrollo de software ágil utiliza un enfoque iterativo y basado

en equipo.

Sin embargo, siempre que sea posible, se debe considerar el enfoque ágil
(metodología agile), ya que proporciona más beneficios, especialmente para
las nuevas empresas. Permite lanzar una aplicación de software funcional
completa mucho más rápido. También es más rentable, ya que hacer cambios
es menos costoso que con el enfoque tradicional.
En base a este cuadro podemos entender mejor ahora el manifiesto ágil.

MANIFIESTO ÁGIL
Los 11 principios del manifiesto ágil son:

1. Nuestra principal prioridad es satisfacer al cliente a través de

la entrega temprana y continua del software de valor.
2. Son bienvenidos los requisitos cambiantes, aun llegando tarde al
desarrollo. Los procesos ágiles se doblegan al cambio como ventaja
competitiva para el cliente.
3. Entregar con frecuencia software que funcione, en periodos de un par de
semanas hasta un par de meses.
4. Las personas del negocio y los desarrolladores deben trabajar juntos de
forma cotidiana a través del proyecto.
5. Construcción de proyectos en torno a individuos motivados.

69
6. La forma más eficiente y efectiva de comunicar información de ida y
vuelta dentro de un equipo de desarrollo es mediante la conversación cara a
cara.
7. El software/producto/servicio que funcione es la principal medida de
progreso.
8. Los procesos ágiles promueven el desarrollo sostenido. Los
desarrolladores, patrocinadores, y usuarios han de mantener un ritmo
constante de forma indefinida.
9. La atención continua a la excelencia técnica ensalza la agilidad.
10. La simplicidad como arte de maximizar la cantidad de trabajo que se
hace, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que
se auto organizan.
 

ALGUNOS TIPOS DE METODOLOGÍAS ÁGILES

1. METODOLOGIA AGILE SCRUM
2. PROGRAMACIÓN EXTREMA – XP
3. METODOLOGIA AGILE KANBAN
 

1.-METODOLOGIA AGILE SCRUM

 

70
 Es un modelo de desarrollo ágil caracterizado por:

1.- Aportar una estrategia de desarrollo incremental, en lugar de la planificación

y ejecución completa del producto.

2.- La calidad del resultado se basa principalmente en el conocimiento

innato de las personas en equipos auto organizados, antes que en la calidad de
los procesos empleados.
3.- Solapamiento de las diferentes fases de desarrollo.

4.- Seguir los pasos del desarrollo ágil: Desde el concepto o visión general de
la necesidad del cliente, construcción del producto de forma incremental a
través de iteraciones. Estas iteraciones (En scrum se llaman Sprint) se repiten
de forma continua hasta que el cliente da por cerrada la evolución del producto.
Características específicas de SCRUM.
TE PUEDE INTERESAR: Qué es Cloud Computing

1. Una de las bases de las metodologías ágiles es el ciclo de vida iterativo

e incremental. El ciclo de vida iterativo o incremental es aquel en que se va
liberando el producto por pares, periódicamente, iterativamente, poco a poco y
además, cada entrega es el incremento de funcionalidad respecto a la anterior.
Cada periodo de entrega -> Sprint
2. El segundo pilar más importante de scrum son las revisiones. Su
importancia reside en que las reuniones son la  base para lograr transparencia
y comunicación, y posibilitan algo característico en un equipo ágil:
1. Reunión de planificación del sprint. Al principio de cada sprint,
para decidir que se va a realizar en ese sprint.
2. Reunión diaria. Máximo 15 minutos. Se trata que se hizo ayer,
que vas a hacer hoy y que problemas se han encontrado.
3. Reunión de revisiones del Sprint. Al final de cada sprint, se trata
que ha completado y que no.
4. Retrospectiva del Sprint. También al final del sprint, y sirve para
que los implicados den sus impresiones sobre el sprint y se utiliza para la
mejora del proceso.
2.- PROGRAMACIÓN EXTREMA (XP)
 

71
 Metodología ágil centrada en potenciar las relaciones interpersonales como
clave para el éxito en desarrollo del software, promoviendo el trabajo en
equipo, preocupándose por el aprendizaje de los desarrolladores y propiciando
un buen clima de trabajo.

XP se basa en retroalimentación continua entre cliente y el equipo de

desarrollo. XP es especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes.

Características específicas de XP

1. Se valora al individuo y las interacciones del equipo de desarrollo sobre

el proceso y las herramientas. La gente es el principal factor de éxito de un
proyecto software.
2. Desarrollar software que funciona más que conseguir una buena
documentación.
3. La colaboración con el cliente. Se propone que exista una interacción
constante entre el cliente y el equipo de desarrollo.
4. Responder a los cambios. La habilidad de responder a los cambios que
puedan surgir a lo largo del proyecto determina también el éxito o fracaso del
mismo. La planificación no debe ser estricta sino flexible y abierta.
 

72
3.- METODOLOGIA AGILE KANBAN
 

Kanban es una palabra japonesa que significa “tarjetas visuales” (kan significa
visual, y ban tarjeta). Esta técnica se creó en Toyota, y se utiliza para controlar
el avance del trabajo, en el contexto de una línea de producción. Actualmente
está siendo aplicado en la gestión de proyectos software.
Fuente: Javier Garzás
[device]
[countdown id=»1517594246″ relative=»70″ format=»dHMS»
serverSync=»true» alwaysExpire=»false» compact=»false» tickInterval=»1″
counter=»until» template=»minimal» expiryText=»C%C3%B3digo%3A
%23W23%7BQ~%2412DACWE1″ until=»12,2,2018,16,53″]
[/device]

Es la técnica mas empleada actualmente para regular un flujo de avance

continuo en proyectos TIC.

Presentación de información visual relativa a la producción (identificación de

componentes, estado del proceso, etc).

Se basa en una idea muy simple. Ésta es que el trabajo en curso (Work In
Progress, WIP)

73
 LA METODOLOGÍA ÁGIL MÁS USADA: SCRUM
 Lo óptimo recomendado por la DSDM  Consortium (organización ágil), es la
utilización de modelos de gestión mixtos. Recomendado como modelo de
gestión integral y estratégica del proyecto a PRINCE2 y en las fases iterativas
que se repitan durante la creación del producto/servicio se debería usar al
modelo SCRUM.
LA METODOLOGÍA SCRUM O SCRUM METHODOLOGY

La metodología Scrum o Scrum Methodology es el más conocido de los

frameworks Ágiles que hay en la actualidad. Es la fuente de gran parte del
pensamiento que se encuentra detrás de los principios y valores del Manifiesto
Ágil, que a su vez forma una base común a todos estos enfoques. Ver
el Manifiesto Ágil para más información.
Contenidos [hide]
 1 Metodología scrum
o 1.1 Valores de Scrum
 2 El framework Scrum
 3 Roles de Scrum
 4 El rol Product Owner
 5 El rol Miembro del Equipo de Desarrollo
 6 El rol Scrum Master
 7 Product Backlog – Artefacto
 8 Refinamiento del Product Backlog – Actividad
 9 Planificación del Sprint – Actividad
o 9.1 1.- Determinar qué trabajo será realizado en el Sprint
o 9.2 2.- Determinar cómo realizará el trabajo
o 9.3 Resultado de la Planificación del Sprint
 10 Sprint Backlog – Artefacto
 11 Desarrollo
 12 Incremento de Producto – Artefacto
 13 Indicadores adicionales de avance visible
 14 Definición de Hecho (Definition of Done) – Acuerdo
 15 Scrum Diario – Actividad
 16 Revisión del Sprint – Actividad
 17 Retrospectiva del Sprint – Actividad
 18 Ciclo de vida scrum – Enjuagar y repetir
METODOLOGÍA SCRUM

74
 VALORES DE SCRUM
Para trabajar con una metodología scrum se necesita una base firme de
valores que sirvan como fundamento para el proceso y los principios del
equipo. A través del uso del trabajo en equipo y la mejora
continua, Scrum tanto crea como depende de estos valores. Éstos son Foco,
Coraje, Apertura, Compromiso y Respeto.
 Foco. Porque nos enfocamos en sólo unas pocas cosas a la vez,
trabajamos bien juntos y producimos un resultado excelente. De este modo
logramos entregar ítems valiosos antes.

 Coraje. Porque no estamos solos, nos sentimos apoyados y tenemos

más recursos a nuestra disposición. Esto nos da el coraje para enfrentar
desafíos más grandes.

 Apertura. Durante el trabajo en conjunto expresamos cotidianamente

cómo nos va y qué problemas encontramos. Aprendemos que es bueno
manifestar las preocupaciones, para que éstas puedan ser tomadas en cuenta.

 Compromiso. Porque tenemos gran control sobre nuestro destino, nos

comprometemos más al éxito.

 Respeto. A medida que trabajamos juntos, compartiendo éxitos y

fracasos, llegamos a respetarnos los unos a los otros, y a ayudarnos
mutuamente a convertirnos en merecedores de respeto.
Si una organización permite a Scrum hacer su trabajo, descubrirá sus
beneficios y comenzará a comprender por qué estos valores son tanto
requeridos como generados por Scrum.
EL FRAMEWORK SCRUM

75
Scrum es un framework pensado para construir productos: todo comienza
cuando tenemos stakeholders que necesitan uno.
TE PUEDE INTERESAR: Metodología SCRUM

Scrum es un proceso de equipo. El Equipo Scrum incluye tres roles: el Product

Owner, el Scrum Master y los miembros del Equipo de Desarrollo. El Product
Owner tiene la responsabilidad de decidir qué trabajo deberá ser realizado. El
ScrumMaster actúa como líder servicial, ayudando al equipo y a la organización
a hacer el mejor uso de Scrum. El Equipo de Desarrollo construye el producto
en forma incremental, en una serie de períodos cortos de tiempo llamados
Sprints. Un Sprint es un período fijo de tiempo, de una a cuatro semanas, con
una preferencia hacia los intervalos más cortos. En cada Sprint el
Equipo Scrum construirá y entregará un Incremento de Producto. Cada
incremento es un subconjunto reconocible, operativo y visiblemente mejorado
del producto, que alcanza criterios de aceptación claros y está construído con
un nivel de calidad llamado Definición de Hecho (Definition of Done).
Scrum incluye tres artefactos esenciales: el Product Backlog,
el Sprint Backlog y el Incremento de Producto. El Product Backlog es la lista
ordenada de ideas para el producto, mantenida en el orden en que esperamos
construirlas. El Sprint Backlog es el plan detallado para ser desarrollado en el
próximo Sprint. El Incremento de Producto es un resultado requerido de

76
cada Sprint. Es una versión integrada del producto, mantenida en un nivel de
calidad lo suficientemente alto como para poder ser lanzado si así lo decidiera
el Product Owner. Adicionalmente a estos artefactos, Scrum requiere
transparencia dentro del equipo y para con las partes interesadas. Por lo tanto,
el Equipo Scrum produce muestras visibles de planes y avances.
Scrum incluye cinco Actividades o reuniones. Estas son: el Refinamiento del
Product Backlog, la Planificación del Sprint, el Scrum Diario, la Revisión
del Sprint y la Retrospectiva del Sprint.
Describiremos los roles, artefactos, actividades y el flujo del ciclo de Scrum a
continuación.
ROLES DE SCRUM
Los roles que existen en scrum son tres. Product Owner, Equipo de
desarrollo y Scrum Master. La manera en que confluyen dichos roles dentro de
la consecución del producto se muestra en esta gráfica.

EL ROL PRODUCT OWNER

El Product Owner es la única persona responsable de delinear el producto más
valioso posible para la fecha deseada. Esto se logra gestionando el flujo de
trabajo hacia el equipo, que a su vez se lleva a cabo seleccionando y refinando
ítems del Product Backlog.
El Product Owner mantiene el Product Backlog y asegura que todos sepan qué
hay en él y cuáles son las prioridades. El Product Owner puede ser ayudado
por otros individuos pero el rol debe ser ocupado por una única persona.
Ciertamente, el Product Owner no es responsable de todo. El Equipo Scrum
completo es responsable de ser lo más productivo posible, de mejorar sus
prácticas, de hacer las preguntas correctas, de ayudar al Product Owner, etc.

77
El Equipo de Desarrollo es responsable de determinar cuánto trabajo puede ser
tomado en un Sprint, y de producir un Incremento de Producto al finalizar el
mismo.
De todas formas, el Product Owner, en Scrum, se encuentra en una posición
única. Suele ser la persona más cercana al “costado del negocio» de todo el
proyecto. Es típicamente el encargado de «sacar el producto» y quien se
espera hará el mejor trabajo posible en cuanto a satisfacer a todas las partes
interesadas. El Product Owner lleva adelante esta tarea mediante la gestión
del Product Backlog y asegurándose que el Product Backlog y el avance contra
éste se mantengan visibles.
El Product Owner, al decidir sobre qué debe hacer y qué posponer el Equipo de
Desarrollo, toma las decisiones de alcance versus fechas que llevan al mejor
producto posible.

EL ROL MIEMBRO DEL EQUIPO DE DESARROLLO

El Equipo de Desarrollo está compuesto por los profesionales que hacen el
trabajo necesario para poder entregar el Incremento de Producto. Se auto-
¬organizan para realizar su trabajo. Se espera que los miembros del Equipo de
Desarrollo estén disponibles tiempo completo para el proyecto.

Scrum requiere que el Equipo de Desarrollo esté conformado por un grupo

interdisciplinario de personas que, entre todos, reúnan las habilidades
necesarias para entregar cada incremento del producto.

78
Los miembros del Equipo de Desarrollo tienen la responsabilidad de auto-
¬organizarse para lograr el objetivo del Sprint, produciendo cada nuevo
Incremento de Producto siguiendo el Plan del Sprint.
El Product Owner crea una lista ordenada de lo que hay que hacer. Los
miembros del Equipo de Desarrollo hacen un pronóstico de cuánto pueden
realizar en un Sprint y deciden cómo lo van a llevar a cabo.
EL ROL SCRUM MASTER
El Scrum Master es un «líder servicial», que ayuda al resto del equipo Scrum a
seguir su proceso. Debe tener una buena comprensión de Scrum y la habilidad
de capacitar a otros en sus sutilezas.
El Scrum Master trabaja junto al Product Owner para que éste logre crear y
mantener el Product Backlog. Trabaja junto al Equipo de Desarrollo para
encontrar e implementar las prácticas técnicas que les permitirán tener un
Incremento de Producto ‘Hecho’ al final de cada Sprint. Trabaja con el
Equipo Scrum completo para evolucionar la Definición de Hecho.
El Scrum Master también es responsable de velar por la remoción de los
impedimentos al avance del equipo. Estos impedimentos pueden ser externos
al equipo, como por ejemplo la falta de apoyo de otro equipo, o internos, como
ser que el Product Owner no sepa preparar el Product Backlog de forma
adecuada. El Scrum Master fomenta la auto-¬organización. Los problemas
deben ser resueltos por el equipo siempre que sea posible.
El Scrum Master actúa como coach para el Equipo Scrum, ayudando a sus
miembros a ejecutar el proceso Scrum. Los ayuda a trabajar juntos y a
aprender el framework Scrum, al tiempo que los protege de distracciones tanto
internas como externas. Puede facilitar reuniones y ayuda a mantener al
Equipo Scrum en el buen camino, productivo y creciendo en sus capacidades.
El Scrum Master es responsable de asegurar que Scrum sea comprendido e
implementado, tanto dentro como fuera del equipo. Ayuda a personas fuera del
equipo a entender el proceso y a comprender qué interacciones con el equipo
son valiosas y cuáles no. El Scrum Master ayuda a todos a mejorar para que el
Equipo Scrum sea más productivo y valioso.

79
PRODUCT BACKLOG – ARTEFACTO
El Product Backlog es un artefacto esencial en Scrum. Es una lista ordenada
de ideas para el producto, mantenida en el orden en que esperamos llevarlas a
cabo. Es la única fuente posible de requerimientos. Esto significa que todo el
trabajo que realiza el Equipo de Desarrollo proviene del Product Backlog. Toda
idea de funcionalidad, mejora, bug fix, requerimiento de documentación -¬todas
y cada una de las tareas que llevan a cabo-¬se deriva de un ítem
de Product Backlog. Cada ítem en el Product Backlog incluye una descripción y
una estimación.
El Product Backlog puede comenzar como una lista extensa o breve. Puede
estar descrito de forma detallada o muy vaga. Típicamente empieza siendo
breve e impreciso y se va convirtiendo en más extenso y concreto con el correr
del tiempo. Aquellos ítems del Product Backlog que estén programados para
ser implementados en breve serán «refinados»: es decir clarificados, definidos
en mayor detalle, divididos en fracciones más pequeñas, como parte de la
actividad de Refinamiento del Product Backlog.
El Product Owner es responsable de mantener el Product Backlog, aunque
puede -¬y debería-¬recibir ayuda para construirlo y mantenerlo actualizado.
Los ítems del Product Backlog pueden surgir del Product Owner, los miembros
del Equipo de Desarrollo o incluso de otras partes interesadas.
RECORDATORIO :: ROLES

Product Owner
Scrum Master
Equipo de desarrollo

80
 REFINAMIENTO DEL PRODUCT BACKLOG – ACTIVIDAD
Como los Ítems del Product Backlog a menudo son grandes y generales al
momento de nacer, y dado que las ideas vienen y van y las prioridades
cambian, el Refinamiento de Product Backlog es una actividad constante a lo
largo de un proyecto Scrum. Esta actividad incluye pero no se limita a:

 mantener el Product Backlog ordenado;;

 eliminar o degradar ítems que ya no sean importantes;;

 agregar o promover ítems que surgen o se vuelven importantes;;

 dividir ítems en ítems más pequeños;;

 unir ítems en ítems más grandes;;

 estimar ítems.
Un beneficio clave del Refinamiento de Product Backlog es la preparación de
los Sprints subsiguientes. Es por ello que esta actividad presta especial
atención a la preparación de ítems que deben ser implementados en breve.
Hay muchos elementos a considerar al llevarla a cabo, incluyendo pero no
limitado a:
 Cada ítem que ingresa al Sprint debería idealmente representar un
incremento de «valor de negocio».
 El Equipo de Desarrollo debe poder construir cada ítem dentro de un
único Sprint.
 Debe ser claro para todos qué se pretende.
Dependiendo de la naturaleza del producto, pueden ser necesarias otras
habilidades y aportes. Sea cual sea el caso, siempre es preferible considerar al
Refinamiento de Product Backlog una actividad para todos los miembros del
equipo, no solo para el Product Owner.
PLANIFICACIÓN DEL SPRINT – ACTIVIDAD
Cada Sprint comienza con una actividad acotada en el tiempo (time-¬boxed)
llamada Planificación del Sprint. En esta reunión el Equipo Scrum colabora
para seleccionar y comprender el trabajo que será realizado en el Sprint que
está por comenzar.
El equipo completo participa de la reunión de Planificación del Sprint.
Trabajando a partir del Product Backlog ordenado, el Product Owner y los
Miembros del Equipo de Desarrollo discuten cada ítem y llegan a un acuerdo
compartido respecto al mismo y al trabajo necesario para completarlo en forma
consistente con la Definición de Hecho actual.
Todas las reuniones de Scrum son acotadas en el tiempo. La duración
recomendada para la Planificación del Sprint es de dos horas o menos por

81
 cada semana de duración del Sprint. Debido a que la reunión está acotada en
el tiempo, el éxito de la Planificación del Sprint es altamente dependiente de la
calidad del Product Backlog utilizado. Es por esto que el Refinamiento
del Product Backlog es una actividad importante en Scrum.
En Scrum, la Planificación del Sprint se describe como compuesta de dos
partes:
TE PUEDE INTERESAR: Qué es Cloud Computing

1. Determinar qué trabajo será realizado en el Sprint.

2. Determinar cómo realizará el trabajo.
1.- DETERMINAR QUÉ TRABAJO SERÁ REALIZADO EN EL SPRINT
En la primera parte de la reunión, el Product Owner presenta en orden ítems
del Product Backlog al Equipo de Desarrollo, y el Equipo Scrum completo
colabora para comprender el trabajo a realizar.
El número de ítems del Product Backlog que será tomado en
un Sprint depende exclusivamente del Equipo de Desarrollo. Para decidir
cuántos ítems tomar, el Equipo de Desarrollo considera el estado actual del
Incremento de Producto, la performance del equipo en el pasado, la capacidad
actual del equipo y el Product Backlog ordenado. El Equipo de Desarrollo por sí
solo decide cuánto trabajo tomar. Ni el Product Owner, ni ninguna otra parte
interesada, pueden solicitarle más trabajo al Equipo de Desarrollo.
A menudo, aunque no siempre, se le da un objetivo al Sprint, llamado Objetivo
del Sprint. Ésta es una práctica muy poderosa que ayuda a todos a enfocarse
en la esencia de lo que debe ser realizado, minimizando la importancia de
detalles que pueden no ser importantes para lo que realmente queremos lograr.
2.- DETERMINAR CÓMO REALIZARÁ EL TRABAJO
En la segunda parte de la reunión, el Equipo de Desarrollo colabora para
decidir cómo producir el próximo Incremento de Producto de acuerdo con la
Definición de Hecho actual. Sus miembros realizan el diseño y planificación
mínimo suficiente como para poder confiar en que se podrá completar el
trabajo durante el Sprint. El trabajo a realizarse los primeros días se divide en
pequeñas unidades de un día o menos. El trabajo a realizarse más adelante
puede dejarse en unidades más grandes, a ser descompuesto luego.
Decidir cómo hacer el trabajo es responsabilidad del Equipo de Desarrollo, así
como decidir qué hay que hacer es responsabilidad del Product Owner.
El Product Owner puede quedarse en esta parte de la reunión para responder
preguntas y resolver malentendidos. Sea cual fuere el modo, estas respuestas
deberán estar fácilmente disponibles.
RESULTADO DE LA PLANIFICACIÓN DEL SPRINT
La Planificación del Sprint concluye cuando el Equipo Scrum llega a un acuerdo
común respecto a la cantidad y complejidad de lo que se planea realizar

82
 durante el Sprint y -¬dentro de un rango de circunstancias razonables-¬espera
poder completarlo. El Equipo de Desarrollo pronostica la cantidad de trabajo
que completará y se compromete a realizarlo.
Resumiendo: en la Planificación del Sprint, el Equipo de Desarrollo
 considera y discute ítems del Product Backlog con el Product Owner;;
 se asegura de haberlos comprendido;;

 selecciona un número de ítems que pronostica podrá realizar;;

 y crea un plan suficientemente detallado como para asegurarse que

podrá realizarlo.
La lista resultante de cosas por hacer es lo que se  llama Sprint Backlog.
RECORDATORIO :: ACTIVIDADES

Revisión del Sprint

Retrospectiva del Sprint
Refinamiento del Product Backlog
Planificación del Sprint
Scrum Diario

SPRINT BACKLOG – ARTEFACTO

El Sprint Backlog es la lista de ítems del Product Backlog refinados que han
sido elegidos para ser desarrollados en el Sprint actual, junto al plan del equipo
para poder realizar el trabajo. Refleja el pronóstico de qué trabajo puede ser
completado.
Generado el Sprint Backlog, comienza el Sprint y el Equipo de Desarrollo
desarrolla el nuevo Incremento de Producto definido por el Sprint Backlog.
DESARROLLO
Durante el Sprint, el Equipo de Desarrollo se auto-¬organiza para producir un
Incremento de Producto en concordancia con el Sprint Backlog, según fue
determinado durante la Planificación del Sprint.
Auto-¬organización significa que el Equipo de Desarrollo produce el Incremento
de Producto de forma responsable, siguiendo los estándares de la
organización, de acuerdo con la Definición de Hecho y decide cómo proceder al
respecto.

INCREMENTO DE PRODUCTO – ARTEFACTO

El artefacto más importante en Scrum es el Incremento de Producto.
Cada Sprint produce un Incremento de Producto. Éste debe ser de calidad lo
suficientemente alta como para ser entregado a usuarios finales. El Incremento
de Producto debe cumplir con la Definición de Hecho actual del

83
 Equipo Scrum y cada parte del mismo debe ser aceptable para el Product
Owner.
INDICADORES ADICIONALES DE AVANCE VISIBLE
Scrum requiere transparencia dentro y fuera del equipo. Así como el
Incremento de Producto es la forma más poderosa de crear transparencia, el
Equipo Scrum creará cualquier otro artefacto que necesite para asegurarse que
el estado del proyecto sea transmitido de forma eficaz. Los burn charts y task
boards son algunos de los más populares.
DEFINICIÓN DE HECHO (DEFINITION OF DONE) – ACUERDO
Cuando se entrega el Incremento de Producto, éste tiene que estar «hecho» de
acuerdo a una visión compartida de qué significa «hecho». Esta definición es
diferente para cada Equipo Scrum y, a medida que el equipo madura, la
Definición de Hecho se irá expandiendo y se volverá más exigente.
Ésta siempre debe incluir la noción de que el Incremento de Producto es de
calidad suficiente como para ser lanzado: el Product Owner podría elegir
lanzarlo en forma inmediata.
El Incremento de Producto contiene toda la funcionalidad de Incrementos de
Producto anteriores y está plenamente verificado de manera que todos los
Ítems del Product Backlog completados continúan funcionando en forma
conjunta.
SCRUM DIARIO – ACTIVIDAD
El Equipo de Desarrollo se auto-¬organiza. El mismo emplea el Scrum
Diario para asegurarse que todo marcha “viento en popa” para lograr el
Objetivo del Sprint. La reunión tiene lugar a la misma hora y en el mismo lugar
todos los días. Cada Miembro del Equipo de Desarrollo cuenta tres cosas:
 Qué he logrado desde el último Scrum Diario;
 Lo qué pienso lograr entre este momento y el próximo Scrum Diario;
 Qué está impidiendo mi avance.
Puede haber breves preguntas y respuestas aclaratorias, pero no hay una
discusión de ninguno de estos asuntos durante el Scrum Diario. Sin embargo,
muchos equipos se reúnen inmediatamente luego del Scrum Diario para
trabajar sobre cualquier asunto que haya surgido de esta reunión.

El Scrum Diario no es un reporte a la gerencia, ni al Product Owner, ni al Scrum

Master. Es una reunión de comunicación dentro del Equipo de Desarrollo, para
asegurarse de estar todos en la misma sintonía. Solo los miembros del Equipo
Scrum, incluyendo Scrum Master y Product Owner, hablan durante esta
reunión. Otras partes interesadas pueden asistir y escuchar. A partir de lo
surgido durante esta reunión, el Equipo de Desarrollo se reorganizará, si es
necesario, a fin de lograr el Objetivo del Sprint.

84
El Scrum Diario es un elemento clave de Scrum, que lleva a obtener
transparencia, confianza y una mejor performance. Permite el reconocimiento
rápido de problemas y promueve la auto-¬organización y que el equipo
aprenda a depender sólo de sí mismo. Las reuniones de Scrum siempre las
acotamos en el tiempo. La duración máxima recomendada para el Scrum
Diario es de quince minutos.
RECORDATORIO :: ARTEFACTOS

Sprint Backlog
Incremento de Producto
Product Backlog

REVISIÓN DEL SPRINT – ACTIVIDAD

Al final de cada Sprint, el Equipo Scrum y las partes interesadas revisan el
resultado del Sprint. Todas las reuniones de Scrum las debemos acotar en el
tiempo. La duración máxima recomendada para la Revisión del Sprint es una
hora por cada semana de duración del Sprint.

El punto central de discusión es el Incremento de Producto completado durante

el Sprint. Dado que las partes interesadas son quienes tienen un interés en los
resultados, lo sensato y conveniente es que ellos acudan a esta reunión. Ésta
es una reunión informal para echarle una mirada a dónde estamos y para
colaborar en cómo podemos seguir avanzando. Todos pueden contribuir en la
Revisión del Sprint. Naturalmente, el Product Owner realiza las decisiones
finales respecto al futuro, actualizando el Product Backlog según sea
apropiado.
Los equipos encuentran sus propias formas de realizar la Revisión del Sprint.
Es usual una demostración del Incremento de Producto. El grupo a menudo
discute lo que observó durante el Sprint y qué ideas de producto le vinieron a la
mente. Debemos discutir el estado del Product Backlog y hablar acerca de
posibles fechas de finalización y ver si es viable llegar a dicha fecha.

La Revisión del Sprint brinda a todos los presentes una vista panorámica del
Incremento de Producto. Bajo esta perspectiva, es común actualizar el Product
Backlog como parte de la Revisión del Sprint.

RETROSPECTIVA DEL SPRINT – ACTIVIDAD

Al final de cada Sprint, el Equipo Scrum se reúne para la Retrospectiva del
Sprint. El propósito es revisar cómo fueron las cosas respecto al proceso, la
relación entre las personas y las herramientas utilizadas. El equipo identifica

85
 qué salió bien y qué no tan bien, e identifica potenciales mejoras. Luego diseña
un plan para mejorar las cosas a futuro. Todas las reuniones en Scrum están
acotadas por tiempo. La duración recomendada de la Retrospectiva del Sprint
es una hora por cada semana de duración del Sprint.

El Equipo Scrum mejora su proceso propio, siempre permaneciendo dentro del

framework Scrum.

CICLO DE VIDA SCRUM – ENJUAGAR Y REPETIR

El ciclo de Scrum se repite desde aquí, para cada Sprint.

Para resumir:

 los miembros del Equipo Scrum (el Product Owner, el Equipo de Desarrollo y

el Scrum Master) colaboran para crear una serie de Incrementos de Producto
durante intervalos cortos acotados en el tiempo llamados Sprints.
Cada incremento satisface el criterio de aceptación del Product Owner y la
«Definición de Hecho» compartida por el equipo. Todos trabajan a partir de un
Backlog de Producto. En cada Sprint, comienzan por una Planificación del
Sprint para producir un Backlog del Sprint, es decir un plan para el Sprint. Se
auto-¬organizan para realizar el Desarrollo, mediante reuniones Diarias de
Scrum para coordinar y asegurarse de estar produciendo el mejor Incremento
de Producto posible. Realizan
un Refinamiento del Backlog para prepararse para la reunión de planificación
del próximo Sprint. Terminan el Sprint con una Revisión del Sprint y una
Retrospectiva del Sprint, revisando el producto y su proceso.

QUÉ ES CLOUD COMPUTING

Contenidos [hide]
 1 Qué es Cloud Computing
 2 Características del Cloud Computing
o 2.1 Ubicuidad
o 2.2 Tecnología de la virtualización
o 2.3 Virtualización
o 2.4 Facilidad de uso
o 2.5 Escalabilidad
 3 Tipos del Cloud Computing
o 3.1 Software como servicio –  SaaS.
o 3.2 Infraestructura como servicio – IaaS.

86
 o 3.3 Plataforma como servicio – PaaS
 4 Modos del Cloud Computing
o 4.1 Nubes públicas
o 4.2 Nubes privadas
o 4.3 Nubes híbridas
o 4.4 Nubes comunitarias
 5 Beneficios usando Cloud Computing
o 5.1 Reducción de costes
o 5.2 Seguridad y fiabilidad
o 5.3 Flexibilidad
o 5.4 Movilidad
o 5.5 Focalización
QUÉ ES CLOUD COMPUTING
Definamos Qué es Cloud Computing. Nace de los términos Cloud o Nube, es el
símbolo que se usa generalmente para representar internet. Es una metáfora
empleada para hacer referencia al servicio Web que permite el
almacenamiento de archivos y el uso de aplicaciones online. Y del termino
Computing o Computación, que reúne los conceptos de informática, lógica de
coordinación y almacenamiento.
Concepto conocido también bajo los términos de servicios en la
nube, informática en la nube, o nube de conceptos, es un paradigma que
permite ofrecer servicios de informática y almacenamiento a través de Internet,
los sistemas de información están alojados en servidores accesibles desde
internet. Son servidores encargados de atender peticiones en cualquier
momento y en modo servicio, de recursos computacionales, hardware, software
y datos, mediante una conexión a Internet.
El término Cloud Computing no hace referencia a una tecnología concreta sino
a un modelo de implementación de servicios de las TIC a través de Internet.
Los servicios más habituales en la nube son el almacenamiento de datos,
aplicaciones de software, procesamiento remoto de datos, repositorio de
contenidos, entornos colaborativos, etc.

Ahora que tenemos claro Qué es Cloud Computing, vayamos a ver sus

características principales.
TE PUEDE INTERESAR: Metodología SCRUM

CARACTERÍSTICAS DEL CLOUD COMPUTING

El servicio Cloud Computing abre un nuevo modelo de TIC flexibles que se
adaptan a cada empresa, entre sus características cabe mencionar:

87
UBICUIDAD
Posibilidad ofrecida a los usuarios de acceder a los servicios contratados
de Cloud Computing desde cualquier dispositivo ,en cualquier lugar y en
cualquier momento, siempre cuando se disponga de conexión a redes de
internet.
TECNOLOGÍA DE LA VIRTUALIZACIÓN
Ofrece a los usuarios el nivel de flexibilidad necesario con los dispositivos para
la realización de las actividades diarias.

VIRTUALIZACIÓN
Consiste en la creación, a través de software, de una versión virtual de algún
recurso tecnológico. Es la tecnología que sustenta el Cloud Computing.
FACILIDAD DE USO
La complejidad tecnológica del Cloud es transparente para el usuario final, no
hay necesidad de conocer la infraestructura que hay detrás de la nube para
hacer uso de sus servicios.

ESCALABILIDAD
Provisión escalable y elástica en función de la demanda. Capacidad
consistente en aumentar o disminuir las funcionalidades ofrecidas al cliente, en
función de sus necesidades puntuales sin necesidad de nuevos contratos,
eliminando así el sobrecoste derivado de mantener los sistemas infrautilizados
fuera de las puntas de demanda.

TIPOS DEL CLOUD COMPUTING

Existen diferentes tipos de servicios según el consumo:

SOFTWARE COMO SERVICIO –  SAAS.

El proveedor no solo ofrece la infraestructura hardware y los entornos de
ejecución necesarios, sino también los productos software. Las aplicaciones
informáticas están alojadas en el servidor y se accede a ellas a través de
un navegador web, sin necesidad de instalar las mismas en el disco duro. De
esta manera se libera al cliente de operaciones de mantenimiento, técnicas y
de soporte, garantizan una disponibilidad permanente. Es un modelo sin costes
de alta, escalable y con actualizaciones disponibles normalmente a demanda y
accesible desde cualquier lugar.

88
Posiblemente en la vanguardia de las Empresas que ofrecen este servicio
está Salesforce, que comenzó a prestar sus servicios en 1999 siendo pioneros
en el sector, es el paradigma de software como servicio. Grandes
organizaciones de todo tipo de sectores han contratado sus servicios con éxito
como por ejemplo en las Finanza (American Express, Barclays Bank),
Tecnológico (Vodafone, BCM software, Bq, Spotify, EA sport), trasportes
(KLM).
INFRAESTRUCTURA COMO SERVICIO – IAAS.
Con este modelo se externaliza el uso de servidores fuera del entorno de la
empresa, transfiriendo el espacio en disco o las bases de datos a servidores
externos. El consumidor alquila los recursos de hardware (ciclos de CPU,
memoria, disco o equipamientos de red) en vez de comprarlos e instalarlos en
su propio CPD, lo que le permite ir variando el consumo de los recursos en
función de sus necesidades, es lo que se conoce como elasticidad de la
infraestructura.

TE PUEDE INTERESAR: Qué es Cloud Computing

PLATAFORMA COMO SERVICIO – PAAS

Se ofrece directamente un sistema operativo y un entorno donde desarrollar un
servicio por parte de un tercero. PaaS suele estar restringido para empresa de

89
desarrollo de aplicaciones que necesitan herramientas para alojar y desarrollar
sus propias aplicaciones. Entre estas herramientas están bases de datos,
servidores de aplicaciones, gestores de fuentes, software de trabajo
colaborativo, etc.

MODOS DEL CLOUD COMPUTING

Dependiendo de las necesidades de las organizaciones se decide por un tipo
de nube u otro, según dónde estén instaladas las aplicaciones y qué clientes
pueden acceder a ellas:

NUBES PÚBLICAS
Los servicios se encuentran instalados en servidores externos a la empresa. Su
principal ventaja es que no requieren de fuertes inversiones en hardware y en
mantenimiento, sólo se paga por el uso. Los trabajos de gestión,
mantenimiento y seguridad recaen en la empresa proveedora del servicio. La
desventaja es que toda la información de la empresa estará en manos de
terceros, por lo que se debe comprobar a quién se contrata el servicio y su
fiabilidad: la empresa proveedora debe informar sobre el grado de protección,
los usuarios que tienen acceso y las copias de seguridad de los datos.

NUBES PRIVADAS
El desarrollo es el mismo que en las públicas con la salvedad de que los
servidores se encuentran dentro de la propia empresa que genera y mantiene
la nube. De esta manera la empresa controla los datos lo que supone mayor
seguridad para la misma. Como contrapartida, se debe realizar una inversión
más fuerte en la compra de los equipos, la contratación de ancho de banda y
sistemas y software de seguridad, además de los gastos de mantenimiento.

NUBES HÍBRIDAS
Permiten aprovechar las aplicaciones locales en una nube pública, es decir, la
empresa es propietaria de una parte de la red y comparte otra parte. Permite,
90
entre otras cosas, sincronizar y/o replicar datos entre clouds públicas y
privadas y migrar servicios de forma continua entre ambos tipos de nubes.

NUBES COMUNITARIAS
Compartidas por varias organizaciones y dan soporte a una comunidad
específica con preocupaciones similares. Tienen características de los modelos
indicados anteriormente: pueden ser gestionadas por la empresa o por terceros
y su ubicación puede ser interna o externa a la empresa. Algunos de estos
servicios son gratuitos, otros son de pago (aunque normalmente más
económicos que la compra de la licencias tradicionales).

BENEFICIOS USANDO CLOUD COMPUTING

Los diferentes usos y servicios ofertados bajo este nuevo modelo afectan, tanto
a las organizaciones como a los particulares que observan cómo la prestación
de servicios en la nube les reporta ventajas en términos de eficiencia,
flexibilidad y disminución del esfuerzo inversor y, por otro, a las empresas
tecnológicas y operadoras tradicionales que ven una oportunidad de ampliar su
negocio.

REDUCCIÓN DE COSTES
La tecnología cloud convierte los coste fijos (de infraestructura) en coste
variables (de operación), lo que permite mejorar el control del gasto y evita la
adquisición de activos así como su mantenimiento.  Al no gestionar el centro de
procesos de datos (CPD) y el desarrollo/mantenimiento del software de gestión 
se consigue reducir costes de adquisición de equipos y del personal técnico,
los problemas de actualizaciones de hardware y software, despliegues de SI,
etc

SEGURIDAD Y FIABILIDAD
Habitualmente la seguridad es mayor ya que los proveedores de servicios de
Cloud suelen disponer de políticas de seguridad mucho más rigurosas. Del
mismo modo, al tratase de un servicio en la nube, es altamente improbable la
caída de servicio o cualquier pérdida de información y estará disponible 24X7.
El acceso puede realizarse desde cualquier lugar del mundo, a cualquier hora y
desde cualquier dispositivo al realizarse el acceso por Internet. Las soluciones
tradicionales son mucho más limitadas.

FLEXIBILIDAD
El servicio se paga de acuerdo a la demanda. La forma de pago suele ser por
mes y se suele pagar una cuota dependiendo del número de usuarios,
módulos, servicios, potencia… etc.

91
MOVILIDAD
Los datos alojados en la nube pueden ser consultados desde cualquier lugar.

FOCALIZACIÓN
Permite a las compañías y organismos públicos concentrar su energía en su
actividad principal (core business).
Un vídeo explicativo de lo que es cloud computing que a mi me gusta mucho.
Como no, es de google.

Ingeniería de software

Ingeniería de software

Áreas del
Software
saber

Desarrollo y
Campo de
mantenimiento
aplicación
de software

Ciencias de la
Subárea de
computación

[editar datos en Wikidata]

Un ingeniero de software (Trevor Parscal) programando en la sede de San

Francisco de la Fundación Wikimedia.
La Ingeniería de Software Es una de las ramas de las ciencias de la
computación que estudia la creación de software confiable y de calidad,
basándose en métodos y técnicas de ingeniería. Brindando soporte operacional
y de mantenimiento, el estudio de las aplicaciones de la ingeniería

92
de software.1Integra ciencias de la computación y las ciencias básicas cuyos
orígenes se encuentran en la ingeniería.2
Se citan las definiciones más reconocidas, formuladas por prestigiosos autores:

 Ingeniería de software es el estudio de los principios y metodologías

para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978).
 Ingeniería de software es la aplicación práctica del conocimiento
científico al diseño y construcción de programas de computadora y a la
documentación asociada requerida para desarrollar, operar y mantenerlos.
Se conoce también como desarrollo de software o producción
de software (Bohem, 1976).
 La ingeniería de software trata del establecimiento de los principios y
métodos de la ingeniería a fin de obtener software de modo rentable, que
sea fiable y trabaje en máquinas reales (Bauer, 1972).
 La ingeniería de software es la aplicación de un enfoque sistemático,
disciplinado y cuantificable al desarrollo, operación, y mantenimiento
del software.3
En 2004, la U. S. Bureau of Labor Statistics (Oficina de Estadísticas del Trabajo
de Estados Unidos) contó 760 840 ingenieros de software de computadora.4
[actualizar]

El término "ingeniero de software", sin embargo, se utiliza de manera genérica

en el ambiente empresarial, y no todos los que se desempeñan en el puesto de
ingeniero de software poseen realmente títulos de ingeniería de universidades
reconocidas.5
Algunos autores consideran que "desarrollo de software" es un término más
apropiado que "ingeniería de software" para el proceso de crear software.
Personas como Pete McBreen (autor de Software Craftmanship) cree que el
término IS implica niveles de rigor y prueba de procesos que no son apropiados
para todo tipo de desarrollo de software.
Indistintamente se utilizan los términos "ingeniería de software" o
"ingeniería del software"; aunque menos común también se suele referenciar
como "ingeniería en software".678En Hispanoamérica los términos más
comúnmente usados son los dos primeros.
La creación del software es un proceso intrínsecamente creativo y la ingeniería
del software trata de sistematizar este proceso con el fin de acotar el riesgo de
fracaso en la consecución del objetivo, por medio de diversas técnicas que se
han demostrado adecuadas sobre la base de la experiencia previa.
La ingeniería de software se puede considerar como la ingeniería aplicada
al software, esto es, por medios sistematizados y con herramientas
preestablecidas, la aplicación de ellos de la manera más eficiente para la
obtención de resultados óptimos; objetivos que siempre busca la ingeniería. No
es solo de la resolución de problemas, sino más bien teniendo en cuenta las
diferentes soluciones, elegir la más apropiada.
La producción de software utiliza criterios y normas de la ingeniería
de software, lo que permite transformarlo en un producto industrial usando
bases de la ingeniería como métodos, técnicas y herramientas para desarrollar

93
 un producto innovador regido por metodologías y las buenas prácticas. Dicho
producto es un medio que interviene en las funciones de sus usuarios para
obtener un proceso productivo más eficaz y eficiente; hoy en día las empresas
no podrían funcionar sin software porque este es un producto de uso masivo;
por lo cual, el nivel de una empresa está determinado por la calidad de su
infraestructura tecnológica y los productos desarrollados o adquiridos de
acuerdo a sus necesidades.

Índice

 1Historia
 2Objetivos
 3Recursos
o 3.1Recursos humanos
o 3.2Recursos de entorno
 4Implicaciones socioeconómicas
o 4.1Económicamente
o 4.2Socialmente
 5Notaciones
o 5.1LUM (lenguaje unificado de modelado) o UML
o 5.2BPMN (notación para el modelado de procesos de negocios)
o 5.3Diagrama de flujo de datos (DFD)
 6Herramienta CASE
 7Metodología
o 7.1Etapas del proceso
 7.1.1Obtención de los requisitos
 7.1.2Análisis de requisitos
 7.1.3Limitaciones[20]
 7.1.4Especificación
 7.1.5Arquitectura
 7.1.6Programación
 7.1.7Desarrollo de la aplicación
 7.1.8Pruebas de software
 7.1.9Implementación
 7.1.10Documentación
 7.1.11Mantenimiento
o 7.2Ventajas[24]
 7.2.1Desde el punto de vista de gestión
 7.2.2Desde el punto de vista de los ingenieros de software
 7.2.3Desde el punto de vista de cliente o usuario final
 8Modelos y ciclos de vida del desarrollo de software
o 8.1Modelo en cascada o clásico
o 8.2Modelo de prototipos
o 8.3Modelo en espiral

94
 o 8.4Modelo de desarrollo por etapas
o 8.5Modelo incremental o iterativo
 8.5.1Modelo estructurado
 8.5.2Modelo orientado a objetos
o 8.6Modelo RAD (rapid application development)
o 8.7Modelo de desarrollo concurrente
o 8.8Proceso unificado del desarrollo de software
 9Producto
 10Naturaleza de la ingeniería de software
o 10.1Matemáticas
o 10.2Creación
o 10.3Gestión de Proyecto
 11Participantes y papeles
o 11.1Cliente
o 11.2Desarrolladores
o 11.3Gestores
o 11.4Usuarios finales
o 11.5Código ético de un ingeniero de software
 12Educación ética
o 12.1Organizaciones
 13Véase también
 14Referencias
 15Bibliografía
 16Enlaces externos

Historia[editar]
Artículo principal: Historia de la ingeniería del software

Cuando aparecieron las primeras computadoras digitales en la década de

1940,9 el desarrollo de software era algo tan nuevo que era casi imposible
hacer predicciones de las fechas estimadas de finalización del proyecto y
muchos de ellos sobrepasaban los presupuestos y tiempo estimados.. Los
desarrolladores tenían que volver a escribir todos sus programas para correr en
máquinas nuevas que salían cada uno o dos años, haciendo obsoletas las ya
existentes.
El término ingeniería del software apareció por primera vez a finales de la
década de 1950. La ingeniería de software fue estimulada por la crisis
del  software de las décadas de entre 1960 y 1980. La ingeniería
del software viene a ayudar a identificar y corregir mediante principios y
metodologías los procesos de desarrollo y mantenimiento de sistemas
de software.
Aparte de la crisis del software de las décadas de entre 1960 y 1980, la
ingeniería de software se ve afectada por accidentes que conllevaron a la
muerte de tres personas; esto sucedió cuando la máquina de
radioterapia Therac-25 emite una sobredosis masiva de radiación y afecto

95
contra la vida de estas personas.10Esto remarca los riesgos de control
por software,11 afectando directamente al nombre de la ingeniería de software.
A principios de los 1980,12 la ingeniería del software ya había surgido como una
genuina profesión, para estar al lado de las ciencias de la computación y la
ingeniería tradicional. Antes de esto, las tareas eran corridas poniendo tarjetas
perforadas como entrada en el lector de tarjetas de la máquina y se esperaban
los resultados devueltos por la impresora.
Debido a la necesidad de traducir frecuentemente el software viejo para
atender las necesidades de las nuevas máquinas, se desarrollaron lenguajes
de orden superior. A medida que apareció el software libre, las organizaciones
de usuarios comúnmente lo liberaban.
Durante mucho tiempo, solucionar la crisis del software fue de suma
importancia para investigadores y empresas que se dedicaban a producir
herramientas de software.
Para la década de 1980, el costo de propiedad y mantenimiento
del software fue dos veces más caro que el propio desarrollo del software, y
durante la década de 1990, el costo de propiedad y mantenimiento aumentó
30 % con respecto a la década anterior. En 1995, muchos de los proyectos de
desarrollo estaban operacionales, pero no eran considerados exitosos. El
proyecto de software medio sobrepasaba en un 50 % la estimación de tiempo
previamente realizada, además, el 75 % de todos los grandes productos
de software que eran entregados al cliente tenían fallas tan graves, que no eran
usados en lo absoluto o simplemente no cumplían con los requerimientos del
cliente.11
Algunos expertos argumentaron que la crisis del software era debido a la falta
de disciplina de los programadores.
Cada nueva tecnología y práctica de la década de 1970 a la de 1990 fue
pregonada como la única solución a todos los problemas y el caos que llevó a
la crisis del software. Lo cierto es que la búsqueda de una única clave para el
éxito nunca funcionó. El campo de la ingeniería de software parece un campo
demasiado complejo y amplio para una única solución que sirva para mejorar la
mayoría de los problemas, y cada problema representa solo una pequeña
porción de todos los problemas de software.
El auge del uso del Internet llevó a un vertiginoso crecimiento en la demanda
de sistemas internacionales de despliegue de información en la World Wide
Web. Los desarrolladores se vieron en la tarea de manejar ilustraciones,
mapas, fotografías y animaciones, a un ritmo nunca antes visto, con casi
ningún método para optimizar la visualización y almacenamiento de imágenes.
También fueron necesarios sistemas para traducir el flujo de información en
múltiples idiomas extranjeros a lenguaje natural humano, con muchos sistemas
de software diseñados para uso multilenguaje, basado en traductores
humanos.
La ingeniería de software contribuyó alrededor de 90 000 millones de dólares
por año, ya que entró en juego el Internet. Esto hace que los desarrolladores
tuviesen que manejar imágenes mapas y animaciones para optimizar la
visualización/almacenamiento de imágenes (como el uso de imágenes en

96
miniatura). El uso de los navegadores y utilización de lenguaje HTML cambia
drásticamente la visión y recepción de la información.
Las amplias conexiones de red causaron la proliferación de virus informáticos y
basura o spam en los correos electrónicos (E-mail). Esta situación puso en una
carrera contra el tiempo a los desarrolladores con el fin de crear nuevos
sistemas de bloqueo o seguridad de dichas anomalías en la informática, ya que
se volvían sumamente tediosas y difíciles de arreglar 11
Después de una fuerte y creciente demanda surge la necesidad de crear
soluciones de software a bajo costo, lo que conlleva al uso de metodologías
más simples y rápidas que desarrollan software funcional. Cabe señalar que los
sistemas más pequeños tenían un enfoque más simple y rápido para poder
administrar el desarrollo de cálculos y algoritmos de software.

Objetivos[editar]
La ingeniería de software aplica diferentes normas y métodos que permiten
obtener mejores resultados, en cuanto al desarrollo y uso del software,
mediante la aplicación correcta de estos procedimientos se puede llegar a
cumplir de manera satisfactoria con los objetivos fundamentales de la
ingeniería de software.
Entre los objetivos de la ingeniería de software están:

 Mejorar el diseño de aplicaciones o software de tal modo que se adapten

de mejor manera a las necesidades de las organizaciones o finalidades
para las cuales fueron creadas.
 Promover mayor calidad al desarrollar aplicaciones complejas.
 Brindar mayor exactitud en los costos de proyectos y tiempo de
desarrollo de los mismos.
 Aumentar la eficiencia de los sistemas al introducir procesos que
permitan medir mediante normas específicas, la calidad
del software desarrollado, buscando siempre la mejor calidad posible según
las necesidades y resultados que se quieren generar.
 Una mejor organización de equipos de trabajo, en el área de desarrollo y
mantenimiento de software.
 Detectar a través de pruebas, posibles mejoras para un mejor
funcionamiento del software desarrollado.13

Recursos[editar]
Recursos humanos[editar]
Artículo principal: Recursos humanos

Son todas aquellas personas que intervienen en la planificación de cualquier

instancias de software (por ejemplo: gestor, ingeniero
de software experimentado, etc.), El número de personas requerido para un
proyecto de software solo puede ser determinado después de hacer una
estimación del esfuerzo de desarrollo...

97
Recursos de entorno[editar]
Es el entorno de las aplicaciones (software y hardware)
el hardware proporciona el medio físico para desarrollar las aplicaciones
(software), este recurso es indispensable.14

Implicaciones socioeconómicas[editar]
Económicamente[editar]
En los Estados Unidos, el software contribuyó a una octava parte de todo el
incremento del PIB durante la década de 1990 (alrededor de 90 000 millones
de dólares por año), y un noveno de todo el crecimiento de productividad
durante los últimos años de la década (alrededor de 33.000 millones de dólares
estadounidenses por año). La ingeniería de software contribuyó a US$ 1 billón
de crecimiento económico y productividad en esa década. Alrededor del globo,
el software contribuye al crecimiento económico de maneras similares, aunque
es difícil de encontrar estadísticas fiables. [cita  requerida]
Además, con la industria del lenguaje está hallando cada vez más campos de
aplicación a escala global.
Socialmente[editar]
La ingeniería de software cambia la cultura del mundo debido al extendido uso
de la computadora. El correo electrónico (e-mail), la WWW y la mensajería
instantánea permiten a la gente interactuar de nuevas maneras. El software
baja el costo y mejora la calidad de los servicios de salud, los departamentos
de bomberos, las dependencias gubernamentales y otros servicios sociales.
Los proyectos exitosos donde se han usado métodos de ingeniería
de software incluyen a GNU/Linux, el software del transbordador espacial,
los cajeros automáticos y muchos otros.

Notaciones[editar]
LUM (lenguaje unificado de modelado) o UML[editar]
Artículo principal: Lenguaje unificado de modelado

Es un lenguaje de modelado muy reconocido y utilizado actualmente que se

utiliza para describir o especificar métodos. También es aplicable en
el desarrollo de  software.
Las siglas UML significan lenguaje unificado de modelado esto quiere decir que
no pretende definir un modelo estándar de desarrollo, sino únicamente un
lenguaje de modelado.15
Un lenguaje de modelado consta de vistas, elementos de modelo y un conjunto
de reglas sintácticas, semánticas y pragmáticas que indican cómo utilizar los
elementos.
En esta materia nos encontramos con varios diagramas que se pueden usar
tales como: casos de uso, de clases, componentes, despliegue, etc.
BPMN (notación para el modelado de procesos de negocios)[editar]
Artículo principal: Business Process Model and Notation

98
El objetivo de la notación para el modelado de procesos de negocios es
proporcionar de una manera fácil de definir y analizar los procesos de negocios
públicos y privados simulando un diagrama de flujo. La notación ha sido
diseñada específicamente para coordinar la secuencia de los procesos y los
mensajes que fluyen entre los participantes del mismo, con un conjunto de
actividades relacionadas. Características básicas de los elementos de BPMN

 Objetos de flujo: eventos, actividades, rombos de control de flujo

(gateways).
 Objetos de conexión: flujo de secuencia, flujo de mensaje, asociación.
 Swimlanes (carriles de piscina): pool, lane.
 Artefactos: objetos de datos, grupo, anotación. 15
Diagrama de flujo de datos (DFD)[editar]
Un diagrama de flujo de datos permite representar el movimiento de datos a
través de un sistema por medio de modelos que describen los flujos de datos,
los procesos que tranforman o cambian los datos, los destinos de datos y los
almacenamientos de datos a la cual tiene acceso el sistema.
Su inventor fue Larry Constantine, basado en el modelo de computación de
Martin y Estrin: flujo gráfico de datos. Con los diagramas de flujo de datos
determina la manera en que cualquier sistema puede desarrollarse, ayuda en la
identificación de los datos de la transacción en el modelo de datos y
proporciona al usuario una idea física de cómo resultarán los datos a última
instancia.16

Herramienta CASE[editar]
Las Herramienta CASE son herramientas computacionales (software) que
están destinadas a asistir en los procesos de ciclo de vida de un software,
facilitan la producción del software, varias se basan principalmente en la idea
de un modelo gráfico.17

Metodología[editar]
Un objetivo de décadas ha sido el encontrar procesos y metodologías, que
sean sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en
el desarrollo y la calidad del producto software, en pocas palabras, determina
los pasos a seguir y como realizarlos para finalizar una tarea.
Etapas del proceso[editar]
La ingeniería de software requiere llevar a cabo numerosas tareas agrupadas
en etapas, al conjunto de estas etapas se le denomina ciclo de vida. Las etapas
comunes a casi todos los modelos de ciclo de vida son las siguientes:
Obtención de los requisitos[editar]
Se debe identificar sobre qué se está trabajando, es decir, el tema principal que
motiva el inicio del estudio y creación del nuevo software o modificación de uno
ya existente. A su vez identificar los recursos que se tienen, en esto entra el
conocer los recursos humanos y materiales que participan en el desarrollo de
las actividades. Es importante entender el contexto del negocio para identificar
adecuadamente los requisitos.

99
Se tiene que tener dominio de la información de un problema, lo cual incluye
los datos fuera del software (usuarios finales, otros sistemas o dispositivos
externos), los datos que salen del sistema (por la interfaz de usuario, interfaces
de red, reportes, gráficas y otros medios) y los almacenamientos de datos que
recaban y organizan objetos persistentes de datos (por ejemplo, aquellos que
se conservan de manera permanente).
También hay que ver los puntos críticos, lo que significa tener de una manera
clara los aspectos que entorpecen y limitan el buen funcionamiento de los
procedimientos actuales, los problemas más comunes y relevantes que se
presentan, los motivos que crean insatisfacción y aquellos que deben ser
cubiertos a plenitud. Por ejemplo: ¿El contenido de los reportes generados,
satisface realmente las necesidades del usuario? ¿Los tiempos de respuesta
ofrecidos, son oportunos?, etc.
Hay que definir las funciones que realizará el software ya que estas ayudan al
usuario final y al funcionamiento del mismo programa.
Se tiene que tener en cuenta cómo será el comportamiento del software ante
situaciones inesperadas como lo son por ejemplo una gran cantidad de
usuarios usando el software o una gran cantidad de datos entre otros.
Análisis de requisitos[editar]

Extraer los requisitos de un producto software es la primera etapa para crearlo.

Durante la fase de análisis, el cliente plantea las necesidades que se presenta
e intenta explicar lo que debería hacer el software o producto final para
satisfacer dicha necesidad mientras que el desarrollador actúa como
interrogador, como la persona que resuelve problemas. Con este análisis, el
ingeniero de sistemas puede elegir la función que debe realizar el software y
establecer o indicar cuál es la interfaz más adecuada para el mismo. 18

El análisis de requisitos puede parecer una tarea sencilla, pero no lo es debido

a que muchas veces los clientes piensan que saben todo lo que
el software necesita para su buen funcionamiento, sin embargo se requiere la
habilidad y experiencia de algún especialista para reconocer requisitos
incompletos, ambiguos o contradictorios. Estos requisitos se determinan
tomando en cuenta las necesidades del usuario final, introduciendo técnicas
que nos permitan mejorar la calidad de los sistemas sobre los que se trabaja. 19
El resultado del análisis de requisitos con el cliente se plasma en el documento
ERS (especificación de requisitos del sistema), cuya estructura puede venir
definida por varios estándares, tales como CMMI. Asimismo, se define
un diagrama de entidad/relación, en el que se plasman las principales
entidades que participarán en el desarrollo del software.
La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es
una parte crucial; de esta etapa depende en gran medida el logro de los
objetivos finales. Se han ideado modelos y diversos procesos metódicos de
trabajo para estos fines. Aunque aún no está formalizada, ya se habla de
la ingeniería de requisitos.
La IEEE Std. 830-1998 normaliza la creación de las especificaciones de
requisitos de software (Software Requirements Specification).
100
Finalidades del análisis de requisitos:

 Brindar al usuario todo lo necesario para que pueda trabajar en conjunto

con el software desarrollado obteniendo los mejores resultados posibles.
 Tener un control más completo en la etapa creación del software, en
cuanto a tiempo de desarrollo y costos.
 Utilización de métodos más eficientes que permitan el mejor
aprovechamiento del software según sea la finalidad de uso del mismo.
 Aumentar la calidad del software desarrollado al disminuir los riesgos de
mal funcionamiento.19
No siempre en la etapa de "análisis de requisitos" las distintas metodologías de
desarrollo llevan asociado un estudio de viabilidad y/o estimación de costes. El
más conocido de los modelos de estimación de coste del software es el
modelo COCOMO
Limitaciones20[editar]
Los software tienen la capacidad de emular inteligencia creando un modelo de
ciertas características de la inteligencia humana pero solo posee funciones
predefinidas que abarcan un conjunto de soluciones que en algunos campos
llega a ser limitado. Aun cuando tiene la capacidad de imitar ciertos
comportamientos humanos no es capaz de emular el pensamiento humano
porque actúa bajo condiciones.
Otro aspecto limitante de los software proviene del proceso totalmente
mecánico que requiere de un mayor esfuerzo y tiempos elevados de ejecución
lo que lleva a tener que implementar el software en una máquina de mayor
capacidad.
Especificación[editar]
La especificación de requisitos describe el comportamiento esperado en
el software una vez desarrollado. Gran parte del éxito de un proyecto
de software radicará en la identificación de las necesidades del negocio
(definidas por la alta dirección), así como la interacción con los usuarios
funcionales para la recolección, clasificación, identificación, priorización y
especificación de los requisitos del software.
Entre las técnicas utilizadas para la especificación de requisitos se encuentran:

 Caso de uso
 Historias de usuario
Siendo los primeros más rigurosas y formales, los segundas más ágiles e
informales.
Arquitectura[editar]
Artículo principal: Arquitectura de software

La integración de infraestructura, desarrollo de aplicaciones, bases de datos y

herramientas gerenciales, requieren de capacidad y liderazgo para poder ser
conceptualizados y proyectados a futuro, solucionando los problemas de hoy.
El rol en el cual se delegan todas estas actividades es el del Arquitecto.

101
El arquitecto de software es la persona que añade valor a los procesos de
negocios gracias a su valioso aporte de soluciones tecnológicas.
La arquitectura de sistemas en general, es una actividad de planeación, ya sea
a nivel de infraestructura de red y hardware, o de software.
Lo principal en este punto es poner en claro los aspectos lógicos y físicos de
las salidas, modelos de organización y representación de datos, entradas y
procesos que componen el sistema, considerando las bondades y limitaciones
de los recursos disponibles en la satisfacción de las pacificaciones brindadas
para el análisis.
Hay que tener en consideración la arquitectura del sistema en la cual se va a
trabajar, elaborar un plan de trabajo viendo la prioridad de tiempo y recursos
disponibles. En los diseños de salidas entra los que es la interpretación de
requerimientos lo cual es el dominio de información del problema, las funciones
visibles para el usuario, el comportamiento del sistema y un conjunto de clases
de requerimientos que agrupa los objetos del negocio con los métodos que les
dan servicio.
La arquitectura de software consiste en el diseño de componentes de una
aplicación (entidades del negocio), generalmente utilizando patrones de
arquitectura. El diseño arquitectónico debe permitir visualizar la interacción
entre las entidades del negocio y además poder ser validado, por ejemplo por
medio de diagramas de secuencia. Un diseño arquitectónico describe en
general el cómo se construirá una aplicación de software. Para ello se
documenta utilizando diagramas, por ejemplo:

 Diagrama de clases
 Diagrama de base de datos
 Diagrama de despliegue
 Diagrama de secuencia
Los diagramas de clases y de base de datos son los mínimos necesarios para
describir la arquitectura de un proyecto que iniciará a ser codificado.
Dependiendo del alcance del proyecto, complejidad y necesidades, el
arquitecto elegirá cuales de los diagramas se requiere elaborar.
Las herramientas para el diseño y modelado de software se
denominan CASE (Computer Aided Software Engineering) entre las cuales se
encuentran:

 Enterprise Architect
 Microsoft Visio for Enterprise Architects
Programación[editar]
Artículo principal: Programación

Implementar un diseño en código puede ser la parte más obvia del trabajo de
ingeniería de software, pero no necesariamente es la que demanda mayor
trabajo y ni la más complicada. La complejidad y la duración de esta etapa está
íntimamente relacionada al o a los lenguajes de programación utilizados, así
como al diseño previamente realizado.

102
Desarrollo de la aplicación[editar]
Para el desarrollo de la aplicación es necesario considerar cinco fases para
tener una aplicación o programa eficiente, estas son:

 Desarrollo de la infraestructura: Esta fase permite el desarrollo y la

organización de los elementos que formaran la infraestructura de la
aplicación, con el propósito de finalizar la aplicación eficientemente.
 Adaptación del paquete: El objetivo principal de esta fase es entender
de una manera detallada el funcionamiento del paquete, esto tiene como
finalidad garantizar que el paquete pueda ser utilizado en su máximo
rendimiento, tanto para negocios o recursos. Todos los elementos que
componen el paquete son inspeccionados de manera detallada para evitar
errores y entender mejor todas las características del paquete.
 Desarrollo de unidades de diseño de interactivas: En esta fase se
realizan los procedimientos que se ejecutan por un diálogo usuario-sistema.
Los procedimientos de esta fase tienen como objetivo principal:

1. Establecer específicamente las acciones que debe efectuar la unidad de

diseño.
2. La creación de componentes para sus procedimientos.
3. Ejecutar pruebas unitarias y de integración en la unidad de diseño.

 Desarrollo de unidades de diseño batch: En esta fase se utilizan una

serie de combinación de técnicas, como diagrama de flujo, diagramas de
estructuras, tablas de decisiones, etc. Cualquiera a utilizar será beneficioso
para plasmar de manera clara y objetiva las especificaciones y que así el
programador tenga mayor comprensión a la hora de programar y probar los
programas que le corresponden.
 Desarrollo de unidades de diseño manuales: En esta fase el objetivo
central es proyectar todos los procedimientos administrativos que
desarrollarán en torno a la utilización de los componentes
computarizados.21
Pruebas de software[editar]
Artículo principal: Pruebas de software

Consiste en comprobar que el software realice correctamente las tareas

indicadas en la especificación del problema. Una técnica es probar por
separado cada módulo del software (prueba unitaria), y luego probarlo de
manera integral (pruebas de integración), para así llegar al objetivo. Se
considera una buena práctica el que las pruebas sean efectuadas por alguien
distinto al desarrollador que la programó, idealmente un área de pruebas; sin
perjuicio de lo anterior el programador debe hacer sus propias pruebas. En
general hay dos grandes maneras de organizar un área de pruebas, la primera
es que esté compuesta por personal inexperto y que desconozca el tema de
pruebas, de esta manera se evalúa que la documentación entregada sea de
calidad, que los procesos descritos son tan claros que cualquiera puede
entenderlos y el software hace las cosas tal y como están descritas. El segundo
enfoque es tener un área de pruebas conformada por programadores con

103
experiencia, personas que saben sin mayores indicaciones en qué condiciones
puede fallar una aplicación y que pueden poner atención en detalles que
personal inexperto no consideraría.
De acuerdo con Roger S. Pressman, el proceso de pruebas se centra en los
procesos lógicos internos del software, asegurando que todas las sentencias se
han comprobado, y en los procesos externos funcionales, es decir, la
realización de pruebas para la detección de errores. Se requiere poder probar
el software con sujetos reales que puedan evaluar el comportamiento
del software con el fin de proporcionar realimentación a los desarrolladores. Es
importante que durante el proceso de desarrollo del software no se pierda
contacto con los interesados o solicitantes del desarrollo de software, de esta
manera los objetivos del proyecto se mantendrán vigentes y se tendrá una idea
clara de los aspectos que tienen que probarse durante el período de pruebas. 22
Implementación[editar]
Artículo principal: Implementación

Una implementación es la realización de una especificación técnica o

algoritmos con un programa, componente software, u otro sistema de cómputo.
Muchas especificaciones son dadas según a su especificación o un estándar.
Las especificaciones recomendadas según el World Wide Web Consortium, y
las herramientas de desarrollo del software contienen implementaciones de
lenguajes de programación. El modelo de implementación es una colección de
componentes y los subsistemas que contienen. Componentes tales como:
ficheros ejecutables, ficheros de código fuente y todo otro tipo de ficheros que
sean necesarios para la implementación y despliegue del sistema.
La etapa de implementación del diseño de software es el proceso de convertir
una especificación del sistema en un sistema ejecutable. Siempre implica los
procesos de diseño y programación de software, pero, si se utiliza un enfoque
evolutivo de desarrollo, también puede implicar un refinamiento de la
especificación del software. Esta etapa es una descripción de la estructura
del software que se va a implementar, los datos que son parte del sistema, las
interfaces entre los componentes del sistema, y algunas veces los algoritmos
utilizados.23
Documentación[editar]
Es todo lo concerniente a la documentación del propio desarrollo del software y
de la gestión del proyecto, pasando por modelaciones (UML), diagramas de
casos de uso, pruebas, manuales de usuario, manuales técnicos, etc; todo con
el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y
ampliaciones al sistema.
Mantenimiento[editar]
Artículo principal: Mantenimiento de software

Fase dedicada a mantener y mejorar el software para corregir errores

descubiertos e incorporar nuevos requisitos. Esto puede llevar más tiempo
incluso que el desarrollo del software inicial. Alrededor de 2/3 del tiempo de
ciclo de vida de un proyecto14 está dedicado a su mantenimiento. Una pequeña
parte de este trabajo consiste eliminar errores (bugs); siendo que la mayor

104
parte reside en extender el sistema para incorporarle nuevas funcionalidades y
hacer frente a su evolución.
Ventajas24[editar]
Desde el punto de vista de gestión[editar]

 Facilitar la tarea de seguimiento del proyecto

 Optimizar el uso de recursos
 Facilitar la comunicación entre usuarios y desarrolladores
 Facilitar la evaluación de resultados y cumplimiento de objetivos
Desde el punto de vista de los ingenieros de software[editar]

 Ayudar a comprender el problema

 Permitir la reutilización
 Facilitar el mantenimiento del producto final
 Optimizar el conjunto y cada una de las fases del proceso de desarrollo
Desde el punto de vista de cliente o usuario final[editar]

 Garantizar el nivel de calidad del producto final

 Obtener el ciclo de vida adecuado para el proyecto
 Confianza en los plazos del tiempo mostrados en la definición del
proyecto

Modelos y ciclos de vida del desarrollo de software[editar]

La ingeniería de software, con el fin de ordenar el caos que era anteriormente
el desarrollo de software, dispone de varios modelos, paradigmas y filosofías
de desarrollo, estos los conocemos principalmente como modelos o ciclos de
vida del desarrollo de  software, esto incluye el proceso que se sigue para
construir, entregar y hacer evolucionar el software, desde la concepción de una
idea hasta la entrega y el retiro del sistema y representa todas las actividades y
artefactos (productos intermedios) necesarios para desarrollar una aplicación. 25
El ciclo de vida de un software contiene los siguientes procedimientos:

 Definición de objetivos: definir el resultado del proyecto y su papel en

la estrategia global.26
 Análisis de los requisitos y su viabilidad: recopilar, examinar y
formular los requisitos del cliente y examinar cualquier restricción que se
pueda aplicar.26
 Diseño general: requisitos generales de la arquitectura de la
aplicación.26
 Diseño en detalle: definición precisa de cada subconjunto de la
aplicación.26
 Programación (programación e implementación): es la implementación
de un lenguaje de programación para crear las funciones definidas durante
la etapa de diseño.26

105
 Prueba de unidad: prueba individual de cada subconjunto de la
aplicación para garantizar que se implementaron de acuerdo con las
especificaciones.26
 Integración: para garantizar que los diferentes módulos se integren con
la aplicación. Este es el propósito de la prueba de integración que está
cuidadosamente documentada.26
 Prueba beta (o validación), para garantizar que el software cumple con
las especificaciones originales.26
 Documentación: sirve para documentar información necesaria para los
usuarios del software y para desarrollos futuros.26
 Implementación
 Mantenimiento: para todos los procedimientos correctivos
(mantenimiento correctivo) y las actualizaciones secundarias
del software (mantenimiento continuo).26
Modelo en cascada o clásico[editar]
Artículo principal: Desarrollo en cascada

En ingeniería de software el modelo en cascada ―también llamado desarrollo

en cascada o ciclo de vida clásico― se basa en un enfoque metodológico que
ordena rigurosamente las etapas del ciclo de vida del software, esto sugiere
una aproximación sistemática secuencial hacia el proceso de desarrollo
del software, que se inicia con la especificación de requisitos del cliente y
continúa con la planificación, el modelado, la construcción y el despliegue para
culminar en el soporte del software terminado.27
Modelo de prototipos[editar]
Artículo principal: Modelo de prototipos

En ingeniería de software, el modelo de prototipos pertenece a los modelos de

desarrollo evolutivo. Este permite que todo el sistema, o algunos de sus partes,
se construyan rápidamente para comprender con facilidad y aclarar ciertos
aspectos en los que se aseguren que el desarrollador, el usuario, el cliente
estén de acuerdo en lo que se necesita así como también la solución que se
propone para dicha necesidad y de esta manera minimizar el riesgo y la
incertidumbre en el desarrollo, este modelo se encarga del desarrollo de
diseños para que estos sean analizados y prescindir de ellos a medida que se
adhieran nuevas especificaciones, es ideal para medir el alcance del producto,
pero no se asegura su uso real.
Este modelo principalmente se aplica cuando un cliente define un conjunto de
objetivos generales para el software a desarrollarse sin delimitar
detalladamente los requisitos de entrada procesamiento y salida, es decir
cuando el responsable no está seguro de la eficacia de un algoritmo, de la
adaptabilidad del sistema o de la manera en que interactúa el hombre y la
máquina.
Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al
cliente a entender de mejor manera cuál será el resultado de la construcción
cuando los requisitos estén satisfechos.28

106
Modelo en espiral[editar]
Artículo principal: Desarrollo en espiral

El modelo en espiral, que Barry Boehm propuso originalmente en 1986, es un

modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de
la construcción de prototipos con los aspectos controlados y sistemáticos del
modelo en cascada, es decir, cuando se aplica este modelo, el software se
desarrolla en una serie de entregas evolutivas (ciclos o iteraciones), cada una
de estas entregando prototipos más completas que el anterior, todo esto en
función del análisis de riesgo y las necesidades del cliente. Aunque el modelo
espiral representa ventajas por sobre el desarrollo lineal, el cálculo de los
riesgos puede ser muy complicado y por lo cual su uso en el ámbito real es
muy escaso.29
Modelo de desarrollo por etapas[editar]
Artículo principal: Desarrollo por etapas

Es un modelo en el que el software se muestra al cliente en etapas refinadas

sucesivamente. Con esta metodología se desarrollan las capacidades más
importantes reduciendo el tiempo necesario para la construcción de un
producto; el modelo de entrega por etapas es útil para el desarrollo de la
herramienta debido a que su uso se recomienda para problemas que pueden
ser tratados descomponiéndolos en problemas más pequeños y se caracteriza
principalmente en que las especificaciones no son conocidas en detalle al inicio
del proyecto y por tanto se van desarrollando simultáneamente con las
diferentes versiones del código.
En este modelo pueden distinguirse las siguientes fases:

 Especificación conceptual.
 Análisis de requisitos.
 Diseño inicial.
 Diseño detallado (codificación, depuración, prueba y liberación).
Cuando es por etapas, en el diseño global estas fases pueden repetirse según
la cantidad de etapas que sean requeridas.
Entre sus ventajas tenemos:

 Detección de problemas antes y no hasta la única entrega final del

proyecto.
 Eliminación del tiempo en informes debido a que cada versión es un
avance.
 Estimación de tiempo por versión, evitando errores en la estimación del
proyecto general.
 Cumplimiento a la fecha por los desarrolladores.
Modelo incremental o iterativo[editar]
Artículo principal: Desarrollo iterativo y creciente

107
Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo
de software, creado en respuesta a las debilidades del modelo tradicional de
cascada, es decir, este modelo aplica secuencias lineales como el modelo en
cascada, pero de una manera iterativa o escalada según como avance el
proceso de desarrollo y con cada una de estas secuencias lineales se
producen incrementos (mejoras) del software.30
Se debe tener en cuenta que el flujo del proceso de cualquier incremento
puede incorporar el paradigma de construcción de prototipos, ya que como se
mencionó anteriormente, este tipo de modelo es iterativo por naturaleza, sin
embargo se diferencia en que este busca la entrega de un producto
operacional con cada incremento que se le realice al software.
Este desarrollo incremental es útil principalmente cuando el personal necesario
para una implementación completa no está disponible.
Modelo estructurado[editar]
Este modelo ―como su nombre lo indica― utiliza las técnicas del diseño
estructurado o de la programación estructurada para su desarrollo, también se
utiliza en la creación de los algoritmos del programa. Este formato facilita la
comprensión de la estructura de datos y su control. 31Entre las principales
características de este modelo se encuentran las siguientes:

 Generalmente se puede diferenciar de una manera más clara los

procesos y las estructuras de datos.
 Existen métodos que se enfocan principalmente en ciertos datos.
 La abstracción del programa es de un nivel mucho mayor.
 Los procesos y estructuras de datos son representados
jerárquicamente.31
Este modelo también presenta sus desventajas entre las cuales podemos
mencionar algunas:

 Se podía encontrar datos repetidos en diferentes partes del programa. 31

 Cuando el código se hace muy extenso o grande su manejo se complica
demasiado.32
En el modelo estructurado las técnicas que comúnmente se utilizan son:

 El modelo entidad-relación, esta técnica se relaciona principalmente con

los datos.
 El diagrama de flujo de datos, esta es utilizada principalmente para los
procesos.33
Modelo orientado a objetos[editar]
Estos modelos tienen sus raíces en la programación orientada a objetos y
como consecuencia de ella gira entorno al concepto de clase, también lo hacen
el análisis de requisitos y el diseño. Esto además de introducir nuevas técnicas,
también aprovecha las técnicas y conceptos del desarrollo estructurado, como
diagramas de estado y transiciones. El modelo orientado a objetos tiene dos
características principales, las cuales ha favorecido su expansión:

108
 Permite la reutilización de software en un grado significativo.
 Su simplicidad facilita el desarrollo de herramientas informáticas de
ayuda al desarrollo, el cual es fácilmente implementada en una notación
orientada a objetos llamado UML.34
Modelo RAD (rapid application development)[editar]
Artículo principal: Desarrollo rápido de aplicaciones

El RAD (rapid application development: ‘desarrollo rápido de aplicaciones’), es

un modelo de proceso de software incremental, desarrollado inicialmente por
James Maslow en 1980, que resalta principalmente un ciclo corto de desarrollo.
Esta es una metodología que posibilita la construcción de sistemas
computacionales que combinen técnicas y utilidades CASE (Computer Aided
Software Engineering), la construcción de prototipos centrados en el usuario y
el seguimiento lineal y sistemático de objetivos, incrementando la rapidez con
la que se producen los sistemas mediante la utilización de un enfoque de
desarrollo basado en componentes.35
Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso
RAD permite que un equipo de desarrollo cree un producto completamente
funcional dentro de un periodo muy limitado de tiempo sin reducir en lo más
mínimo la calidad del mismo.36
Modelo de desarrollo concurrente[editar]
El modelo de desarrollo concurrente es un modelo de tipo de red donde todas
las personas actúan simultáneamente o al mismo tiempo. Este tipo de modelo
se puede representar a manera de esquema como una serie de actividades
técnicas importantes, tareas y estados asociados a ellas.
El modelo de proceso concurrente define una serie de acontecimientos que
dispararan transiciones de estado a estado para cada una de las actividades de
la ingeniería del software. Por ejemplo, durante las primeras etapas del diseño,
no se contempla una inconsistencia del modelo de análisis. Esto genera la
corrección del modelo de análisis de sucesos, que disparara la actividad de
análisis del estado hecho al estado cambios en espera. Este modelo de
desarrollo se utiliza a menudo como el paradigma de desarrollo de aplicaciones
cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de
componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de
proceso concurrente define actividades en dos dimensiones: una división de
sistemas y una división de componentes. Los aspectos del nivel de sistemas se
afrontan mediante dos actividades: diseño y realización.
La concurrencia se logra de dos maneras:

 Las actividades del sistema y de componente ocurren simultáneamente

y pueden modelarse con el enfoque orientado a objetos descrito
anteriormente;
 Una aplicación cliente/servidor típica se implementa con muchos
componentes, cada uno de los cuales se pueden diseñar y realizar
concurrentemente.

109
En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de
desarrollo de software y proporciona una imagen exacta del estado actual de
un proyecto. En vez de confinar actividades de ingeniería de software a una
secuencia de sucesos, define una red de actividades, todas las actividades de
la red existen simultáneamente con otras. Los sucesos generados dentro de
una actividad dada o algún otro lado de la red de actividad inicia las
transiciones entre los estados de una actividad.
Proceso unificado del desarrollo de software[editar]
Artículos principales: Proceso Unificado y Rational Unified Process.

El proceso unificado es un proceso de software genérico que puede ser

utilizado para una gran cantidad de tipos de sistemas de software, para
diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes
niveles de competencia y diferentes tamaños de proyectos.
Provee un enfoque disciplinado en la asignación de tareas y responsabilidades
dentro de una organización de desarrollo. Su meta es asegurar la producción
de software de muy alta calidad que satisfaga las necesidades de los usuarios
finales, dentro de un calendario y presupuesto predecible. 37
El proceso unificado tiene dos dimensiones:

 Un eje horizontal que representa el tiempo y muestra los aspectos del

ciclo de vida del proceso a lo largo de su desenvolvimiento
 Un eje vertical que representa las disciplinas, las cuales agrupan
actividades de una manera lógica de acuerdo a su naturaleza.
La primera dimensión representa el aspecto dinámico del proceso conforme se
va desarrollando, se expresa en términos de fases, iteraciones e hitos
(milestones).
La segunda dimensión representa el aspecto estático del proceso: cómo es
descrito en términos de componentes del proceso, disciplinas, actividades,
flujos de trabajo, artefactos y roles.
El refinamiento más conocido y documentado del proceso unificado es el RUP
(proceso unificado racional).
El proceso unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos específicos.
De la misma manera, el proceso unificado de rational, también es un marco de
trabajo extensible, por lo que muchas veces resulta imposible decir si un
refinamiento particular del proceso ha sido derivado del proceso unificado o del
RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un
mismo concepto.38

Producto[editar]
El software se ha convertido en algo muy necesario en nuestra sociedad actual,
es la máquina que conduce a la toma de decisiones comerciales, sirve para la
investigación científica moderna, es un factor clave que diferencia productos y
servicios modernos. Esto se da porque el software está inmerso en sistemas de
todo tipo alrededor de nosotros.

110
El software de computadora es el producto que diseñan y construyen los
ingenieros de software. Esto abarca programas que se ejecutan dentro de una
computadora de cualquier tamaño y arquitectura, después de estar construido
casi cualquier persona en el mundo industrializado, ya sea directa o
indirectamente.
Los productos se pueden clasificar en:

 Productos genéricos: Son los producidos por una organización para ser
vendidos al mercado.
 Productos hechos a medida: Sistemas que son desarrollados bajo
pedido a un desarrollador específico.
Estos productos deben cumplir varias características al ser entregados, estas
son:

 Mantenibles: El software debe poder evolucionar mientras cumple con

sus funciones.
 Confiabilidad: No debe producir daños en caso de errores.
 Eficiencia: El software no debe desperdiciar los recursos.
 Utilización adecuada: Debe contar con una interfaz de usuario adecuada
y su documentación.
Lo que constituye el producto final es diferente para el ingeniero y los usuarios,
para el ingeniero son los programas, datos y documentos que configuran
el software pero para el usuario el producto final es la información que de cierto
modo soluciona el problema planteado por el usuario.

Naturaleza de la ingeniería de software[editar]

La ingeniería de software es una disciplina que está orientada a aplicar
conceptos y métodos de ingeniería al desarrollo de software de calidad.
Matemáticas[editar]
Los programas tienen muchas propiedades matemáticas. Por ejemplo la
corrección y la complejidad de muchos algoritmos son conceptos matemáticos
que pueden ser rigurosamente probados. El uso de matemáticas en la IS es
llamado métodos formales.
Creación[editar]
Los programas son construidos en una secuencia de pasos. El hecho de definir
propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es
necesario para mejorar la productividad de los desarrolladores y la calidad final
de los programas. Este punto de vista inspira los diferentes procesos y
metodologías que se encuentran en la IS.
Gestión de Proyecto[editar]
El desarrollo de software de gran porte requiere una adecuada gestión del
proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo
de profesionales que liderar. Recursos (espacio de oficina, insumos,
equipamiento) por adquirir. Para su administración se debe tener una clara
visión y capacitación en gestión de proyectos.

111
Participantes y papeles[editar]
Para el desarrollo de un sistema de software es necesaria la colaboración de
muchas personas con diversas competencias, capacidades e intereses. Al
conjunto de personas involucradas en el proyecto se les conoce como
participantes.
Al conjunto de funciones y responsabilidades que hay dentro del proyecto o
sistema se le conoce como roles o papeles. Los roles están asociados a las
tareas que son asignadas a los participantes, en consecuencia, una persona
puede desempeñar uno o múltiples roles, así también un mismo rol puede ser
representado por un equipo.39
Cliente[editar]
Es frecuente el uso de los términos "usuarios", "usuarios finales" y "clientes"
como sinónimos, lo cual puede provocar confusión; estrictamente, el cliente
(persona, empresa u organización) es quién especifica los requisitos del
sistema,40 en tanto que el usuario es quien utiliza u opera finalmente el
producto software, pudiendo ser o no el cliente.
Desarrolladores[editar]
Esta clase de participantes están relacionados con todas las facetas
del proceso de desarrollo del  software. Su trabajo incluye la investigación,
diseño, implementación, pruebas y depuración del software.41
Gestores[editar]
En el contexto de ingeniería de software, el gestor de desarrollo de software es
un participante, que reporta al director ejecutivo de la empresa que presta el
servicio de desarrollo. Es responsable del manejo y coordinación de los
recursos y procesos para la correcta entrega de productos de software,
mientras participa en la definición de la estrategia para el equipo de
desarrolladores, dando iniciativas que promuevan la visión de la empresa. 42
Usuarios finales[editar]
El usuario final es quien interactúa con el producto de software una vez es
entregado.40 Generalmente son los usuarios los que conocen el problema, ya
que día a día operan los sistemas.
Código ético de un ingeniero de software[editar]
Un ingeniero de software debe tener un código donde asegura, en la medida
posible, que los esfuerzos realizados se utilizarán para realizar el bien y deben
comprometerse para que la ingeniería de software sea una profesión benéfica y
respetada. Para el cumplimiento de esta norma, se toman en cuenta ocho
principios relacionados con la conducta y las decisiones tomadas por el
ingeniero; donde estos principios identifican las relaciones éticamente
responsables de los individuos, grupos y organizaciones donde participen. Los
principios a los que deben sujetarse son sobre la sociedad, cliente y
empresario, producto, juicio, administración, profesión, colegas y por último el
personal.

112
 Sociedad: Los ingenieros de software deben actuar de manera
congruente con el interés social, aceptando la responsabilidad total de su
trabajo, moderando los intereses con el bienestar social, aprobando
el software solamente si se tiene una creencia bien fundamentada,
cooperando en los esfuerzos para solucionar asuntos importantes de
interés social, ser justo y veraz en todas las afirmaciones relativas
al software o documentos asociados.
 Cliente y empresario: Se debe actuar de manera tal que se llegue a
conciliar los mejores intereses de los clientes y empresarios,
congruentemente con el interés social. Estos deberán prestar servicios en
sus áreas de competencia, siendo honestos y francos sobre las
limitaciones, no utilizar un software que se obtenga ilegalmente o sin ética,
usar la propiedad de los clientes o empresarios de manera autorizada,
mantener secreto cualquier documento de información confidencial.
 Producto: Hay que asegurarse que los productos y sus modificaciones
cumplan con los estándares profesionales más altos posibles, procurando
la alta calidad, costos aceptables y una agenda razonable asegurando que
los costos y beneficios sean claros y aceptados por el empresario y el
cliente. Asegurar que las metas y objetivos de cualquier proyecto sean
adecuados y alcanzables.
 Juicio: Se debe mantener una integridad e independencia en el juicio
profesional, moderando todo juicio técnico por la necesidad de apoyar y
mantener los valores humanos, mantener la objetividad profesional con
respecto a cualquier software o documento relacionado, no involucrarse en
prácticas financieras fraudulentas.
 Administración: Se deberá asegurar una buena administración para
cualquier proyecto en el cual se trabaje, utilizando procedimientos efectivos
para promover la calidad y reducir riesgos, asegurándose también que se
conozcan las políticas y procedimientos del empresario para proteger
contraseñas, archivos e información confidencial.
 Profesión: Se debe incrementar la integridad y reputación de la profesión
en conjunto con el interés social, ayudando al desarrollo de un ambiente
organizacional favorable para actuar, promoviendo el conocimiento público
de la ingeniería de software, extendiendo el conocimiento de la ingeniería
de software por medio de participaciones en organizaciones, reuniones y
publicaciones profesionales.
 Colegas: Cada ingeniero deberá apoyar y ser justos con los colegas,
motivando a sus colegas sujetándose al código, ayudando también a su
desarrollo profesional, reconocer los trabajos de otros y abstenerse a
atribuirse de méritos indebidos, revisar los trabajos de manera objetiva,
sincera y propiamente documentada.
 Personal: Los ingenieros de software participaran toda su vida en el
aprendizaje con la práctica y promoverán un enfoque ético de la profesión,
mejorando su conocimiento de los avances en el análisis, especificación,
diseño, desarrollo, mantenimiento, pruebas del software y documentos
relacionados en conjunto con administración del proceso de desarrollo. 43
METODOLOGÍAS, MODELOS, NORMAS Y ESTÁNDARES
INTERNACIONALES DE CALIDAD

113
Metodologías, modelos, normas y estándares internacionales de calidad.

Lo guíamos en la selección e implantación de metodologías, modelos, normas

y estándares internacionales de calidad como ISO 29110, ITIL, CMMI y
Scrum. Brindamos asesoría, consultoría o gestión directa en la mejora de sus
procesos institucionales, de producción y de servicio.

No somos una entidad certificadora, nuestro servicio se centra en guiar e

implementar un proceso de mejora en su organización basado en la
implementación de estos modelos, metodologías y normas u otros de su
elección. Asesoramos y capacitamos al personal que ejecutará los servicios,
definimos sus nuevos procesos mejorados y lo acompañamos en su camino a
la certificación. Incluye asesoramiento y guía en la selección de una entidad
certificadora si usted lo desea. No dude en Contactarnos para más información.

114
¿Por qué mejorar nuestros procesos de producción y servicios en la industria del
software y las TI?

Existen muchas razones para hacerlo pero más que nada se hace para cumplir
algunos de los siguientes objetivos:

 Disminuir los costos del proyecto

 Mejorar la productividad
 Mejorar los tiempos de desarrollo y entrega
 Agilizar procedimientos de gestión de los procesos
 Mejorar la calidad de los productos y servicios asociados al desarrollo de
software
 Aumentar la satisfacción de los clientes

Conociendo esto entonces podemos definir un conjunto de pasos básicos para

la mejora de un proceso productivo o de servicio asociados al desarrollo de
software. Lo invitamos a conocer estos pasos en el el artículo Ideas básicas
para mejorar un proceso de producción o servicio en la industria del software.
También puede ser de su interés nuestra propuesta de Paso a paso
implantando un nuevo proceso de desarrollo de software en la organización.

ISO 29110

ISO/IEC 29110 Estandar Certificado de Ingeniería de Software

La  ISO / IEC 29110 es una nueva serie de Normas e Informes Técnicos que

llevan como título Ingeniería de Software – Perfiles de Ciclo de Vida en
Pequeñas Entidades. Una PE´s (VSE por sus siglas en inglés – Very Small
Entities) se define como una entidad (empresa, organizacion, departamento o
proyecto) que tiene menos de 25 personas. La mayoría de las PYMES de
software pertenecen a la categoría VSE.

115
La ISO/IEC 29110 ha sido desarrollada para mejorar la calidad del producto y/o
servicio de software, y para mejorar el desempeño de la organización, sin
pretender excluir el uso de diferentes modelos de ciclo de vida tales
como: Cascada, Iterativo, Incremental, Evolutivo o Prototipos. La ISO/IEC
29110 se divide en 5 partes de acuerdo al tipo de audiencia a la que está
dirigida, es decir, al campo de aplicación de cada una conformando un marco
de trabajo.

ITIL

ITIL Foundation

ITIL® Foundation estructura la gestión de los servicios TI sobre el concepto de

Ciclo de Vida de los Servicios. Este enfoque tiene como objetivo ofrecer una
visión global de la vida de un servicio desde su diseño hasta su eventual
abandono sin por ello ignorar los detalles de todos los procesos y funciones
involucrados en la eficiente prestación del mismo.

En ITIL v3 reestructura el manejo de los temas para consolidar el modelo de

“Ciclo de Vida del Servicio” separando y ampliando algunos subprocesos hasta
convertirlos en procesos especializados. Esta modificación responde a un
enfoque empresarial para grandes corporaciones que utilizan ampliamente ITIL
en sus operaciones y aspira a consolidar el modelo para conseguir aún mejores
resultados. Es por ello que los especialistas recomiendan que empresas
emergentes o medianas no utilicen ITIL v3 si no cuentan con un modelo ITIL
consolidado y aspiran a una expansión a muy largo plazo. El Ciclo de Vida del
Servicio consta de cinco fases también llamadas disciplinas, correspondientes
a los nuevos libros de ITIL®:

 Estrategia del Servicio

116
  Diseño del Servicio
 Transición del Servicio
 Operación del Servicio
 Mejora Continua del Servicio

CMMI

Capability Maturity Model Integration

Modelo de Madurez de la Capacidad Integrado (Capability Maturity Model for

Integration) es un modelo de procesos que contiene las mejores prácticas de la
industria para el desarrollo, mantenimiento, adquisición y operación de
productos y servicios.

CMMI es el acrónimo de Capability Maturity Model Integration y se refiere a

los modelos que contienen las mejores prácticas que ayudan a las
organizaciones a mejorar sus procesos. Han sido desarrollados por equipos de
trabajo formados por especialistas de la industria, el gobierno y el Software
Engineering Institute(SEI) que transfirió los derechos al CMMI Institute para su
operación y comercialización.

Según el modelo que se utilice se puede obtener el documento con un conjunto

de guías que ayudan en:

 Desarrollo y mantenimiento de productos y servicios (CMMI DEV),

 Adquisición de productos y servicios (CMMI ACQ) y
 Establecimiento, entrega y gestión de los  servicios (CMMI SVC).

Aunque puede parecer complejo y costoso de implementar no lo es tanto y en

su última versión 1.3 incorpora Tips para su implantación en Pymes y en

117
entornos ágiles. CMMI no te define cómo debes hacer las cosas sino un
conjunto de metas que debes cumplir y una propuesta de prácticas y
evidencias que te ayudan a alcanzar y certificar esas metas. Hemos definido e
implementado con éxito procesos de desarrollo ágiles con CMMI aplicando
nuestro modelo de desarrollo DAC.

Modelo del proceso DAC aplicando CMMI+Agile

Scrum

Scrum

118
Scrum es un proceso en el que se aplican de manera regular un conjunto
de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras
y su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.

En esta metodología se realizan entregas parciales y regulares del producto

final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello,
Scrum está especialmente indicado para proyectos en entornos complejos;
donde se necesita obtener resultados pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovación, la competitividad,
la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está

entregando al cliente lo que necesita, cuando las entregas se alargan
demasiado, los costes se disparan o la calidad no es aceptable, cuando se
necesita capacidad de reacción ante la competencia, cuando la moral de los
equipos es baja y la rotación alta, cuando es necesario identificar y solucionar
ineficiencias sistemáticamente o cuando se quiere trabajar utilizando
un proceso especializado en el desarrollo de producto (Tomado de Proyectos
Ágiles).

JUNIT: es un conjunto de bibliotecas creadas por Erich Gamma y Kent

Beck que son utilizadas en programación para hacer pruebas unitarias de
aplicaciones Java.
JUnit es un conjunto de clases (framework) que permite realizar la ejecución de
clases Java de manera controlada, para poder evaluar si el funcionamiento de
cada uno de los métodos de la clase se comporta como se espera. Es decir, en
función de algún valor de entrada se evalúa el valor de retorno esperado; si la
clase cumple con la especificación, entonces JUnit devolverá que el método de
la clase pasó exitosamente la prueba; en caso de que el valor esperado sea
diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo
en el método correspondiente.
JUnit es también un medio de controlar las pruebas de regresión, necesarias
cuando una parte del código ha sido modificado y se desea ver que el nuevo
código cumple con los requerimientos anteriores y que no se ha alterado su
funcionalidad después de la nueva modificación.
El propio framework incluye formas de ver los resultados (runners) que pueden
ser en modo texto, gráfico (AWT o Swing) o como tarea en Ant.
119
En la actualidad las herramientas de desarrollo
como NetBeans y Eclipse cuentan con plug-ins que permiten que la generación
de las plantillas necesarias para la creación de las pruebas de una clase Java
se realice de manera automática, facilitando al programador enfocarse en la
prueba y el resultado esperado, y dejando a la herramienta la creación de las
clases que permiten
TestNG
Ir a la navegaciónIr a la búsqueda

TestNG es un framework para pruebas y testing que trabaja con Java y está

basado en JUnit (para Java) y NUnit (para .NET), pero introduciendo nuevas
funcionalidades que los hacen más poderosos y fáciles de usar, tales como:

 Anotaciones JDK 5 (Annotations) (JDK 1.4 también es soportado con

JavaDoc annotations).
 Configuración flexible de pruebas.
 Soporte para pruebas para data-driven testing (with @DataProvider).
 Soporte de pasaje de parámetros.
 Permite distribución de las pruebas en maquinas esclavas.
 Modelo de ejecución poderoso (TestSuite nunca más).
 Soportado por herramientas y plugins importantes y variados como:
(Eclipse, IDEA, Maven, etc.).
 Permite embeber BeanShell para una flexibilidad más amplia.
 Funciones JDK por defecto de runtime y logging. (sin dependencias)
 Métodos dependientes para pruebas sobre servidores de aplicación.
TestNG está diseñado para cubrir todas las categorías de las pruebas:
unitarias, funcionales, end-to-end, integración, etc.

PRUEBA DE SOFTWARE: Es la validación y verificación de un sistema, en la

parte funcional, en la parte de calidad y además con la intención de encontrar
errores, mediante el uso de: procesos, procedimientos, técnicas, herramientas
y profesionales.

CASO DE PRUEBA DE SOFTWARE:

Un caso de prueba o test case es, en ingeniería del software, un conjunto de

condiciones o variables bajo las cuales un analista determinará si
una aplicación, un sistema software (software system), o una característica de
éstos es parcial o completamente satisfactoria.
Se pueden realizar muchos casos de prueba para determinar que un requisito
es completamente satisfactorio. Con el propósito de comprobar que todos los
requisitos de una aplicación son revisados, debe haber al menos un caso de
prueba para cada requisito a menos que un requisito tenga requisitos
secundarios. En ese caso, cada requisito secundario deberá tener por lo menos
un caso de prueba. Algunas metodologías como RUP recomiendan el crear por

120
lo menos dos casos de prueba para cada requisito. Uno de ellos debe realizar
la prueba positiva de los requisitos y el otro debe realizar la prueba negativa.
Si la aplicación es creada sin requisitos formales, entonces los casos de prueba
se escriben basados en la operación normal de programas de una clase
similar.
Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada
conocida y una salida esperada, los cuales son formulados antes de que se
ejecute la prueba. La entrada conocida debe probar una precondición y
la salida esperada debe probar una postcondición.
Bajo circunstancias especiales, podría haber la necesidad de ejecutar la
prueba, producir resultados, y luego un equipo de expertos evaluaría si los
resultados se pueden considerar como "correctos". Esto sucede a menudo en
la determinación del número del rendimiento de productos nuevos. La primera
prueba se toma como línea base para los subsecuentes ciclos de
pruebas/lanzamiento del producto.
Los casos de prueba escritos, incluyen una descripción de la funcionalidad que
se probará, la cual es tomada ya sea de los requisitos o de los casos de uso, y
la preparación requerida para asegurarse de que la prueba pueda ser dirigida.
Los casos de prueba escritos se recogen generalmente en una suite de
pruebas.
Las variaciones de los casos de prueba son comúnmente utilizados en pruebas
de aceptación. La prueba de aceptación es realizada por un grupo de usuarios
finales o los clientes del sistema, para asegurarse que el sistema desarrollado
cumple sus requisitos. La prueba de aceptación de usuario se distingue
generalmente por la incorporación de un trayecto feliz o casos de prueba
positivos.

Estructura de los casos de prueba....[editar]

Formalmente, los casos de prueba escritos consisten principalmente en seis
partes con subdivisiones:

 Introducción/visión general: Contiene información general acerca de

los Casos de Prueba.
o Identificador: Es un identificador único para futuras referencias,
por ejemplo, mientras se describe un defecto encontrado.
o Caso de prueba dueño/creador: Es el nombre del analista o
diseñador de pruebas, quien ha desarrollado pruebas o es responsable
de su desarrollo.
o Versión: La actual definición del caso de prueba.
o Nombre: El caso de prueba debe ser un título entendible por
personas, para la fácil comprensión del propósito del caso de prueba y
su campo de aplicación.
o Identificador de requerimientos: el cual está incluido por el
caso de prueba. También aquí puede ser un identificador de casos de
uso o de especificación funcional.

121
 o Propósito: Contiene una breve descripción del propósito de la
prueba, y la funcionalidad que chequea.
o Dependencias: Indica qué otros subsistemas están involucrados
y en qué grado.
 Actividades de los casos de prueba
o Ambiente de prueba/configuración: Contiene información
acerca de la configuración del hardware o software en el cual se
ejecutará el caso de prueba.
o Inicialización: Describe acciones, que deben ser ejecutadas
antes de que los casos de prueba se hayan inicializado. Por ejemplo,
debemos abrir algún archivo.
o Finalización: Describe acciones, que deben ser ejecutadas
después de realizado el caso de prueba. Por ejemplo si el caso de
prueba estropea la base de datos, el analista debe restaurarla antes de
que otro caso de prueba sea ejecutado.
o Acciones: Pasos a realizar para completar la prueba.
o Descripción de los datos de entrada
 Resultados
o Salida esperada: Contiene una descripción de lo que el analista
debería ver tras haber completado todos los pasos de la prueba.
o Salida obtenida: Contiene una breve descripción de lo que el
analista encuentra después de que los pasos de prueba se hayan
completado.
o Resultado: Indica el resultado cualitativo de la ejecución del caso
de prueba, a menudo con un Correcto/Fallido.
o Severidad: Indica el impacto del defecto en el sistema: Grave,
Mayor, Normal, Menor.
o Evidencia: En los casos que aplica, contiene información, bien un
link al print de pantalla (screenshot), bien una consulta a una base de
datos, bien el contenido de un fichero de trazas, donde se evidencia la
salida obtenida.
o Seguimiento: Si un caso de prueba falla, frecuentemente la
referencia al defecto implicado se debe enumerar en esta columna.
Contiene el código correlativo del defecto, a menudo corresponde al
código del sistema de tracking de bugs que se esté usando.
o Estado: Indica si el caso de prueba está: No iniciado, En curso, o
terminado.

Diferencia entre pruebas manuales y automatizacion de pruebas

El proceso de ALM o ciclo de vida de un software se forma a partir de la

combinación de algunos procedimientos, actividades y tareas de desarrollo,
operación y mantenimiento con pruebas constantes. Se puede afirmar que
las pruebas de software son una de las disciplinas más importantes dentro de
ese ciclo. Con algunas opciones de pruebas disponibles en el mercado, el

122
manual fue el más utilizado durante mucho tiempo. El funcionamiento depende
exclusivamente de un analista – un humano -, que tiene la función de ejecutar
la prueba. Hoy, con el aumento de la complejidad de las aplicaciones y la
constante necesidad de reducción del lead time, se hizo inviable el uso de la
prueba manual en todos los casos. A partir de este gap en el mercado, se creó
la prueba automatizada. Su cartilla de ventajas es grande. Desde la adhesión,
pasando por la velocidad hasta la precisión que los humanos no logran
alcanzar.

En este post, vamos a compartir las principales diferencias y aspectos

localizados entre las pruebas manuales y automatizadas, evidenciando cómo y
por qué usar cada uno de ellos con el objetivo de generar más valor para el
negocio.

La prueba automatizada se realiza a través de un software programado por un

especialista. Unitario o punta a punta, tiene alta escala y velocidad de
ejecución. Es adecuado para pruebas en back-end, de integración, de
regresión y unitario además de poseer esfuerzo adicional reducido.

Sin embargo, no abordamos sólo sus ventajas aquí. Con la prueba

automatizada, el mantenimiento puede ser frágil y su principal desventaja es la
no representación de la visión de usuarios reales en el proceso. ¿Y cómo llenar
esa laguna?

En este punto se encuentra la principal asignación del sistema manual: trae la

visión de usuarios reales, que es muy diferente de la visión de una máquina de
automatización! Pero es bueno recordar que su ejecución es lenta y necesita
un esfuerzo exponencial al cubrir múltiples navegadores, dispositivos y
sistemas operativos.

Pero, ¿cuál es la mejor estrategia de prueba para mi empresa? Depende.

Es necesario evaluar las características de cada proyecto, el presupuesto

disponible y la metodología más adecuada para los plazos establecidos. La
definición de qué estrategia debe ser adoptada en un proyecto dependerá
también de las metas y el tipo de cada negocio. Es responsabilidad del PO del
proyecto observar si el sistema afectará la distribución de tiempo entre los
miembros del equipo. Y si se alcanza la cobertura de las pruebas de las
funcionalidades.

Generalmente, el sistema manual es una solución viable para equipos

pequeños trabajando en aplicaciones con poca madurez y estabilidad. Para los
equipos que trabajan dentro de la metodología ágil, en la mayoría de los casos,
se utiliza una estrategia de metodología mixta, parte de las pruebas manuales y
parte automatizadas. En todo caso, para el éxito de la implementación de

123
pruebas de software, tres pilares fundamentales necesitan ser observados:
Datos para Pruebas, Ambiente, y Virtualización de Servicios.

En cuanto a la experiencia del usuario, existe algún sistema complementario a

los dos sistemas?

Hoy, las estrategias de QA implican una mezcla de pruebas automatizadas y

manuales y también el nuevo multitud. Según Gartner, para 2020, el nuevo
sistema estará presente en el 60% de las iniciativas de pruebas móviles, pues
permite a los usuarios probar la aplicación en condiciones reales de
funcionamiento con una retroalimentación inmediata.

¿Qué es, cómo y por qué usar el CrowdTesting será un artículo publicado
próximamente aquí en el Blog.  ¡Quedate atento!

La prueba manual es más indicada para:

 Pruebas exploratorias
 Pruebas de usabilidad
 Pruebas Ad-hoc

La automatización de pruebas es más indicada para:

 Pruebas de regresión
 Pruebas de carga
 Pruebas de rendimiento

Las pruebas que se pueden realizar mediante el enfoque automático o manual

 Pruebas de integración
 Pruebas del sistema
 Pruebas de unidad
 Pruebas de aceptación

Que es Selenium:

Selenium es un entorno de pruebas de software para aplicaciones basadas en

la web. Selenium provee una herramienta de grabar/reproducir para crear
pruebas sin usar un lenguaje de scripting para pruebas (Selenium IDE).
Incluye también un lenguaje específico de dominio para pruebas (Selanese)
para escribir pruebas en un amplio número de lenguajes de programación
populares incluyendo Java, C#, Ruby, Groovy, Perl, Php y Python. Las pruebas
pueden ejecutarse entonces usando la mayoría de los navegadores
web modernos en diferentes sistemas operativos como Windows, Linux y OSX.

124
Selenium WebDriver[editar]
Selenium WebDriver es el sucesor de Selenium RC. Selenium WebDriver
acepta comandos (enviados en Selenese o vía el API de cliente) y los envía a
un navegador. Esto se implementa a través de un controlador del navegador
específico para cada navegador que envía los comandos y trae los resultados
de regreso. La mayoría de los controladores del navegador lanzan y acceden a
la aplicación de navegador (como Mozilla Firefox o Internet Explorer), pero
también hay un controlador para HtmlUnit que simula un navegador. A
diferencia de Selenium 1, donde el servidor Selenium RC era indispensable, en
Selenium WebDriver no se requiere de un servidor especial para ejecutar las
pruebas, en vez de ello WebDriver inicia una instancia del navegador y lo
controla; sin embargo puede usarse Selenium Grid (ver abajo) para ejecutar
pruebas en sistemas remotos (ver más abajo). Desde inicios de 2012, Simon
Stewart de Google (inventor del WebDriver) y David Burns de la Fundación
Mozilla se encuentran negociando con el W3C que WebDriver se convierta en
un estándar de Internet, como tal Selenium-Webdriver (Selenium 2.0) apunta a
ser la implementación de referencia del estándar WebDriver en varios
lenguajes de programación. Selenium-WebDriver está completamente
implementado y soportado en Java, Ruby, Python y C#. En la práctica, esto
significa que la API de Selenium 2.0 tiene significativamente menos llamadas
que el API de Selenium 1.0. Donde Selenium 1.0 intentaba proveer una interfaz
rica en muchas operaciones, Selenium 2.0 intenta proveer de los bloques de
construcción básicos con los cuales los desarrolladores puedan programar su
propio lenguaje específico de dominio. Uno de ellos ya existe y es el
proyecto Watir en Ruby que tiene una historia rica en buen diseño. Watir-
WebDriver implementa el API de Watir como un envolvente del Selenium-
Webdriver en Ruby. Watir-WebDriver se crea de forma completamente
automática, basado en las especificaciones del WebDriver y HTML.

Que es Scrum

Scrum es un proceso en el que se aplican de manera regular un conjunto

de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras
y su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final,

priorizadas por el beneficio que aportan al receptor del proyecto. Por ello,
Scrum está especialmente indicado para proyectos en entornos complejos,
donde se necesita obtener resultados pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovación, la competitividad,
la flexibilidad y la productividad son fundamentales.

125
Scrum también se utiliza para resolver situaciones en que no se está
entregando al cliente lo que necesita, cuando las entregas se alargan
demasiado, los costes se disparan o la calidad no es aceptable, cuando se
necesita capacidad de reacción ante la competencia, cuando la moral de
los equipos es baja y la rotación alta, cuando es necesario identificar y
solucionar ineficiencias sistemáticamente o cuando se quiere trabajar
utilizando un proceso especializado en el desarrollo de producto.

Ver en detalle cuales son los beneficios de Scrum, sus fundamentos y

sus requisitos.

El proceso
En Scrum un proyecto se ejecuta en ciclos temporales cortos y de duración
fija (iteraciones que normalmente son de 2 semanas, aunque en algunos
equipos son de 3 y hasta 4 semanas, límite máximo de feedback de producto
real y reflexión). Cada iteración tiene que proporcionar un resultado completo,
un incremento de producto final que sea susceptible de ser entregado con el
mínimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que

actúa como plan del proyecto. En esta lista el cliente (Product
Owner) prioriza los objetivos balanceando el valor que le aportan
respecto a su coste (que el equipo estima considerando la Definición de
Hecho) y quedan repartidos en iteraciones y entregas.  
Las actividades que se llevan a cabo en Scrum son las siguientes (los tiempos
indicados son para iteraciones de 2 semanas):
Planificación de la iteración

126
 El primer día de la iteración se realiza la reunión de planificación de la iteración.
Tiene dos partes:

1. Selección de requisitos (2 horas). El cliente presenta al equipo la lista

de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente
las dudas que surgen y selecciona los requisitos más prioritarios que prevé que
podrá completar en la iteración, de manera que puedan ser entregados si el
cliente lo solicita.
2. Planificación de la iteración (2 horas). El equipo elabora la lista de
tareas de la iteración necesarias para desarrollar los requisitos seleccionados.
La estimación de esfuerzo se hace de manera conjunta y los miembros del
equipo se autoasignan las tareas, se autoorganizan para trabajar incluso en
parejas (o grupos mayores) con el fin de compartir conocimiento (creando un
equipo más resiliente) o para resolver juntos objetivos especialmente
complejos.

Ejecución de la iteración
Cada día el equipo realiza una reunión de sincronización (15 minutos),
normalmente delante de un tablero físico o pizarra (Scrum Taskboard). El
equipo inspecciona el trabajo que el resto está realizando (dependencias entre
tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden
impedir este objetivo) para poder hacer las adaptaciones necesarias que
permitan cumplir con la previsión de objetivos a mostrar al final de la iteración.
En la reunión cada miembro del equipo responde a tres preguntas:

 ¿Qué he hecho desde la última reunión de sincronización para ayudar al

equipo a cumplir su objetivo?
 ¿Qué voy a hacer a partir de este momento para ayudar al equipo a
cumplir su objetivo?
 ¿Qué impedimentos tengo o voy a tener que nos impidan conseguir
nuestro objetivo?

Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo

pueda mantener el foco para cumplir con sus objetivos.

 Elimina los obstáculos que el equipo no puede resolver por sí mismo.

 Protege al equipo de interrupciones externas que puedan afectar el
objetivo de la iteración o su productividad.

Durante la iteración, el cliente junto con el equipo refinan la lista de requisitos

(para prepararlos para las siguientes iteraciones) y, si es necesario, cambian o
replanifican los objetivos del proyecto (10%-15% del tiempo de la iteración) con
el objetivo de maximizar la utilidad de lo que se desarrolla y el retorno de
inversión.

Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración.
Tiene dos partes:

127
1. Revisión (demostración) (1,5 horas). El equipo presenta al cliente los
requisitos completados en la iteración, en forma de incremento de producto
preparado para ser entregado con el mínimo esfuerzo. En función de los
resultados mostrados y de los cambios que haya habido en el contexto del
proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya
desde la primera iteración, replanificando el proyecto.
2. Retrospectiva (1,5 horas). El equipo analiza cómo ha sido su manera
de trabajar y cuáles son los problemas que podrían impedirle progresar
adecuadamente, mejorando de manera continua su productividad. El
Facilitador se encargará de eliminar o escalar los obstáculos identificados que
estén más allá del ámbito de acción del equipo.

Pruebas de desempeño

Pruebas de rendimiento del software

En la ingeniería del software, las pruebas de rendimiento son las pruebas que
se realizan, desde una perspectiva, para determinar lo rápido que realiza una
tarea un sistema en condiciones particulares de trabajo. También puede servir
para validar y verificar otros atributos de la calidad del sistema, tales como
la escalabilidad, fiabilidad y uso de los recursos. Las pruebas de rendimiento
son un subconjunto de la ingeniería de pruebas, una práctica informática que
se esfuerza por mejorar el rendimiento, englobándose en el diseño y la
arquitectura de un sistema, antes incluso del esfuerzo inicial de la codificación.

Índice

 1Introducción
o 1.1Pruebas de carga
o 1.2Prueba de estrés
o 1.3Prueba de estabilidad (soak testing)
o 1.4Pruebas de picos (spike testing)
o 1.5Prerrequisitos para las pruebas de carga
 2Mitos de las pruebas de rendimiento
 3Tecnología
 4Especificaciones del rendimiento
 5Tareas a realizar
 6Metodología
o 6.1Metodología de pruebas de rendimiento de aplicaciones Web
 7Véase también
 8Enlaces externos

Introducción[editar]
Las pruebas de rendimiento pueden servir para diferentes propósitos. Pueden
demostrar que el sistema cumple los criterios de rendimiento. Pueden
128
comparar dos sistemas para encontrar cual de ellos funciona mejor. O pueden
medir que partes del sistema o de carga de trabajo provocan que el conjunto
rinda mal. Para su diagnóstico, los ingenieros de software utilizan herramientas
como pueden ser monitorizaciones que midan qué partes de un dispositivo o
software contribuyen más al mal rendimiento o para establecer niveles (y
umbrales) del mismo que mantenga un tiempo de respuesta aceptable.
Es fundamental para alcanzar un buen nivel de rendimiento de un nuevo
sistema, que los esfuerzos en estas pruebas comiencen en el inicio
del proyecto de desarrollo y se amplie durante su construcción. Cuanto más se
tarde en detectar un defecto de rendimiento, mayor es el coste de la solución.
Esto es cierto en el caso de las pruebas funcionales, pero mucho más en
las pruebas de rendimiento, debido a que su ámbito de aplicación es de
principio a fin.
En las pruebas de rendimiento, a menudo es crucial (y con frecuencia difícil de
conseguir) que las condiciones de prueba sean similares a las esperadas en el
uso real. Esto es, sin embargo, casi imposible en la práctica. La razón es que
los sistemas en producción tienen un carácter aleatorio de la carga de trabajo y
aunque en las pruebas se intente dar lo mejor de sí para imitar el volumen de
trabajo que pueda tener el entorno de producción, es imposible reproducir
exactamente la variabilidad de ese trabajo, salvo en el sistema más simple.
Los nuevos conceptos en la implementación de la arquitectura (por
ejemplo: SOA) han añadido complejidad adicional a las pruebas de
rendimiento. Los servicios o recursos de la empresa (que comparten
infraestructura o plataforma) requieren pruebas de rendimiento coordinadas
(con la creación del volumen y carga de todos los sistemas que comparten la
infraestructura o plataformas) para reproducir realmente el estado del entorno
de producción. Debido a la complejidad, coste y tiempo necesario en torno a
esta actividad, algunas organizaciones emplean herramientas que pueden
mostrar y crear condiciones (también conocido como "ruido") en los entornos
de pruebas de rendimiento para comprender la capacidad y las necesidades de
recursos y verificar/validar los niveles de calidad.
Pruebas de carga[editar]
Este es el tipo más sencillo de pruebas de rendimiento. Una prueba de carga
se realiza generalmente para observar el comportamiento de
una aplicación bajo una cantidad de peticiones esperada. Esta carga puede ser
el número esperado de usuarios concurrentes utilizando la aplicación y que
realizan un número específico de transacciones durante el tiempo que dura la
carga. Esta prueba puede mostrar los tiempos de respuesta de todas las
transacciones importantes de la aplicación. Si la base de datos, el servidor de
aplicaciones, etc.. también se monitorizan, entonces esta prueba puede
mostrar el cuello de botella en la aplicación.
Prueba de estrés[editar]
Esta prueba se utiliza normalmente para romper la aplicación. Se va doblando
el número de usuarios que se agregan a la aplicación y se ejecuta una prueba
de carga hasta que se rompe. Este tipo de prueba se realiza para determinar la
solidez de la aplicación en los momentos de carga extrema y ayuda a los

129
administradores para determinar si la aplicación rendirá lo suficiente en caso de
que la carga real supere a la carga esperada.
Prueba de estabilidad (soak testing)[editar]
Esta prueba normalmente se hace para determinar si la aplicación puede
aguantar una carga esperada continuada. Generalmente esta prueba se realiza
para determinar si hay alguna fuga de memoria en la aplicación.
Pruebas de picos (spike testing)[editar]
La prueba de picos, como el nombre sugiere, trata de observar el
comportamiento del sistema variando el número de usuarios, tanto cuando
bajan, como cuando tiene cambios drásticos en su carga. Esta prueba se
recomienda que sea realizada con un software automatizado que permita
realizar cambios en el número de usuarios mientras que los administradores
llevan un registro de los valores a ser monitorizados.
Prerrequisitos para las pruebas de carga[editar]
Un desarrollo estable de la aplicación instalado en un entorno lo más parecido
al de producción.
El entorno de pruebas de rendimiento no debe cruzarse con pruebas de
aceptación de usuarios ni con el entorno de desarrollo. Esto es tan peligroso
que si las pruebas de aceptación de usuarios, o las pruebas de integración o
cualquier otra prueba se ejecutan en el mismo entorno, entonces los resultados
no son fiables. Como buena práctica, siempre es aconsejable disponer de un
entorno de pruebas de rendimiento lo más parecido como se pueda al entorno
de producción.

Mitos de las pruebas de rendimiento[editar]

Algunos de los mitos más comunes son los siguientes.

1. Las pruebas de rendimiento se hacen para romper el sistema: Las

pruebas de estrés se hacen para observar el punto de ruptura del
sistema. Por el contrario, las pruebas normales de carga se hacen
generalmente para ver el comportamiento de la aplicación bajo una
carga de usuarios esperada, y dependen de otros requisitos, tales como
el aumento de carga esperado, la carga continuada por un periodo
prolongado de tiempo mientras la demanda aumenta, la resistencia a
las caídas o las pruebas de estrés.
2. Las pruebas de rendimiento sólo deben hacerse después de las
pruebas de integración del sistema: Aunque esta es la norma común
en la industria, las pruebas de rendimiento también pueden realizarse
mientras se realiza el desarrollo inicial de la aplicación. Este tipo de
enfoque se conoce como pruebas de rendimiento tempranas. Este
enfoque garantizaría un desarrollo holístico de la aplicación
manteniendo los parámetros de rendimiento en mente. Por lo tanto, la
búsqueda de un problema en el rendimiento justo antes de la
terminación de la aplicación y el coste de corregir el error, se reduce en
gran medida.

130
 3. El probar el rendimiento sólo implica la creación de scripts y
cualquier cambio en la aplicación solo puede causar una simple
refactorización de dichos scripts: Las pruebas de rendimiento son en
sí mismas una ciencia evolucionada de la industria del software. En sí
mismos, los scripts, aunque importantes, son sólo uno de los
componentes de las pruebas de rendimiento. El principal desafío para
cualquier persona que pruebe el rendimiento es determinar el tipo de
pruebas necesarias y analizar los distintos medidores de rendimiento
para determinar el cuello de botella de rendimiento.
Por otro lado, en relación con este mito, también es falso que cualquier cambio
en la interfaz de usuario, especialmente en el ámbito Web, supone un completo
desarrollo de los scripts desde cero. Este problema se vuelve mayor si
los protocolos involucrados incluyen Web Services, Siebel, scripts de
acciones, Citrix o SAP.

Tecnología[editar]
La tecnología de las pruebas de rendimiento utiliza uno o
más PCs o servidores para actuar como peticionarios. Cada uno emula la
presencia de un número de usuarios y cada uno ejecuta una secuencia
automática de las interacciones (registrada como una secuencia de comandos,
o como una serie de scripts para simular los distintos tipos de uso por parte de
los usuarios) con la aplicación cuyo rendimiento se pone a prueba. Por lo
general, un PC actúa como gestor de prueba, coordinando, recopilando
las métricas de cada uno de los ejecutores y acumulando los datos de
rendimiento para la realización de los informes.
La secuencia habitual es incrementar la carga, comenzando con un pequeño
número de usuarios virtuales y aumentando el número durante un periodo
hasta alcanzar el máximo. El resultado de la prueba muestra la forma en que el
rendimiento varía con la carga, mostrando como el número de usuarios
modifica el tiempo de respuesta. Existen diversas herramientas disponibles
para la realización de tales pruebas. Estas herramientas suelen ejecutar un
conjunto de pruebas que simulan usuarios reales utilizando el sistema. A veces
los resultados pueden revelar curiosidades, por ejemplo, si el promedio de
tiempo de respuesta puede ser aceptable, si existen valores anómalos en las
peticiones que necesitan tiempos considerablemente más largo para ejecutarse
- algo que puede ser causado por peticiones poco eficientes a la base de
datos, fotos, etc.
Las pruebas de rendimiento se pueden combinar con pruebas de estrés, con el
fin de ver qué pasa cuando una carga aceptable se supera ¿Se cae el sistema?
¿Cuánto tiempo tarda en recuperarse si se reduce una gran carga? ¿Un fallo
produce daños colaterales?
El modelo de análisis de rendimiento es un método para modelar el
comportamiento de una aplicación en una hoja de cálculo. El modelo se
alimenta con las mediciones de los recursos solicitados por las peticiones
(CPU, IO, LAN, WAN), ponderado por el nivel de transacción (las peticiones
realizadas por unidad de tiempo, habitualmente una hora).
La demanda de recursos de las peticiones son acumuladas para obtener la
demanda de recursos por unidad de tiempo y divididas por la capacidad total

131
de recursos por la misma unidad, obteniendo así la carga de recursos. Usando
la fórmula de tiempo de respuesta (R=S/(1-U), R=tiempo de respuesta,
S=tiempo del servicio, U=carga), los tiempos de respuesta pueden ser
calculados y calibrados con los resultados de las pruebas de rendimiento. El
modelo de análisis del rendimiento permite la evaluación de diferentes
opciones de diseño y dimensionamiento del sistema sobre la base actual o la
prevista del uso de la aplicación. Por lo tanto, es mucho más rápido y más
barato que las pruebas de rendimiento, aunque requiere una alta comprensión
de las plataformas de hardware.

Especificaciones del rendimiento[editar]

Es fundamental detallar las especificaciones de rendimiento (requisitos) y
documentarlas en algún plan de pruebas de rendimiento. Idealmente, esto se
hace durante la fase de requisitos del desarrollo de cualquier proyecto de
desarrollo de sistemas, antes de cualquier esfuerzo de diseño.
Sin embargo, con frecuencia las pruebas de rendimiento no se realizan
teniendo en cuenta alguna especificación, es decir, nadie ha expresado cuál es
el tiempo máximo de respuesta aceptable para un número determinado de
usuarios. Las pruebas de rendimiento se utiliza con frecuencia como parte del
proceso de ajuste de la ejecución. La idea es identificar el "eslabón más débil" -
hay, inevitablemente, una parte del sistema que, si responde con mayor
rapidez, eso se traducirá en un funcionamiento del sistema global más rápido.
A veces es una difícil tarea determinar qué parte del sistema representa esta
ruta crítica, y algunas herramientas de prueba incluyen (o puede tener
añadidos que lo proporcionan) instrumentos que se ejecuta en
el servidor (agentes) y que informan de tiempos de transacción, número de
accesos a bases de datos, sobrecarga de la red, y otros monitores del servidor,
que pueden ser analizados junto con los datos principales de las estadísticas
de rendimiento. Sin estos instrumentos se podría tener a alguien encargado de
observar el administrador de tareas de Microsoft Windows del servidor para ver
como se carga la CPU en las pruebas de rendimiento (suponiendo que se
prueba un sistema de Windows).
Hay una supuesta historia de una empresa que gastó una gran cantidad de
tiempo y dinero para optimizar su software sin haber realizado un análisis
adecuado del problema. La empresa terminó reescribiendo el proceso de
sistema ‘idle loop’, que es donde habían encontrado que el pasaba la mayor
parte de su tiempo, pero incluso con el más eficiente proceso de espera en el
mundo, obviamente, no mejoraron el rendimiento general ni un ápice.
Las pruebas de rendimiento se pueden realizar a través de la web, e incluso
hacerse en diferentes partes del país, ya que es sabido que los tiempos de
respuesta de Internet varían regionalmente. También se puede hacer en local,
aunque el hardware de enrutamiento debe estar configurado para introducir el
desfase de lo que suele ocurrir en las redes públicas. Las cargas deben ser
realizadas en puntos realistas del sistema. Por ejemplo, si el 50%
de usuarios de un sistema accede a través de una conexión de módem de 56K
y la otra mitad a través de una T1, entonces la carga simulada (ordenadores
que simulan los usuarios reales) se debe realizar, ya sea con las mismas

132
conexiones (caso ideal) o simular la latencia de la red de conexiones de este
tipo, siguiendo el mismo perfil de usuario.
Siempre es útil disponer de una estimación del pico de número de usuarios que
se espera que utilicen el sistema en las horas punta. Si puede ser también una
estimación del máximo tiempo de respuesta permitido en el percentil 95, para
que la configuración de la ejecución de las pruebas se ajuste a estas
especificaciones.
La especificación de rendimiento, como mínimo, debería responder a las
siguientes preguntas:

 ¿Cuál es el alcance, en detalle, de la prueba de rendimiento? ¿Qué

subsistemas, interfaces, componentes, etc están dentro y fuera del ámbito
de ejecución de esta prueba?
 Para las interfaces de usuario involucradas, ¿Cual es el número de
usuarios concurrentes que se esperan para cada uno (especificando picos y
medias?
 ¿Cuál es la estructura objetivo del sistema (hardware, especificandor
todos los servidores de red y configuraciones de dispositivo)?
 ¿Cuál es la distribución del volumen de trabajo de la aplicación para
cada componente? (por ejemplo: 20% login, 40% buscando, 30%
seleccionando elemento, 10% comprando).
 ¿Cual es la distribución del trabajo del sistema? [Las cargas de trabajo
múltiples pueden ser simuladas en una sola prueba de eficacia] (por
ejemplo: 30% del volumen de trabajo para A, 20% del volumen de trabajo
para B, 50% del volumen de trabajo para C)
 ¿Cuáles son los requisitos de tiempo para cada uno y para todos los
procesos por lotes (especificando picos y medias)?

Tareas a realizar[editar]
Las tareas para realizar una prueba de este tipo serían las siguientes:

 Decidir usar recursos internos o externos para ejecutar las pruebas, en

función de la experiencia de la casa (o falta de ella).
 Reunir u obtener requisitos de rendimiento (especificaciones) de los
usuarios y/o analistas.
 Desarrollar un plan de alto nivel, incluyendo los requisitos, recursos,
plazos e hitos.
 Elaborar un plan de pruebas de rendimiento detallado (incluyendo
los escenarios detallados y casos de prueba, cargas de trabajo, información
del entorno, etc).
 Elegir la/s herramienta/s de prueba.
 Especificar los datos de prueba necesarios y la distribución de ellos (a
menudo pasado por alto, y a menudo el fracaso de una prueba de
rendimiento válida).
 Desarrollar scripts de prueba de concepto para cada
aplicación/componente sometido a la prueba, utilizando la herramienta de
prueba elegida y estrategias.

133
 Desarrollar un plan de prueba de rendimiento detallado, incluyendo
todas las dependencias y los plazos.
 Instalar y configurar los simuladores de peticiones y controladores.
 Configurar el entorno de prueba (lo ideal es que sea idéntico hardware a
la plataforma de producción), configurar los router, aislar la red (no
queremos alterar los resultados por parte de otros usuarios), desplegar la
aplicación en el servidor, desarrollar la base de datos de prueba, etc.
 Ejecutar las pruebas, probablemente en repetidas ocasiones
(iterativamente), a fin de ver si el desconocimiento de cualquier factor
podría afectar a los resultados.
 Analizar los resultados - ya sea de aceptando/rechazando, o
investigando el camino crítico y recomendando medidas correctivas .

Metodología[editar]
Metodología de pruebas de rendimiento de aplicaciones Web[editar]
Según Microsoft Developer Network, la Metodología de las Pruebas de
Rendimiento consiste en las siguientes actividades:

 Actividad 1. Identificar el entorno de pruebas. Identificar el entorno físico

de pruebas y el entorno de producción, así como las herramientas y
recursos de que dispone el equipo de prueba. El entorno físico
incluye hardware, software y configuraciones de red. Tener un profundo
conocimiento de todo el entorno de prueba desde el principio permite
diseños más eficientes de pruebas y la planificación y ayuda a identificar
problemas en las pruebas en fases tempranas del proyecto. En algunas
situaciones, este proceso debe ser revisado periódicamente durante todo el
ciclo de vida del proyecto.
 Actividad 2. Identificar los criterios de aceptación de rendimiento.
Determinar el tiempo de respuesta, el rendimiento, la utilización de los
recursos y los objetivos y limitaciones. En general, el tiempo de respuesta
concierne al usuario, el rendimiento al negocio, y la utilización de los
recursos al sistema. Además, identificar criterios de éxito del proyecto que
no hayan sido recogidos por los objetivos y limitaciones, por ejemplo,
mediante pruebas de rendimiento para evaluar qué combinación de la
configuración da lugar a un funcionamiento óptimo.
 Actividad 3. Planificar y diseñar las pruebas. Identificar los principales
escenarios, determinar la variabilidad de los usuarios y la forma de simular
esa variabilidad, definir los datos de las pruebas, y establecer las métricas a
recoger. Consolidar esta información en uno o más modelos de uso del
sistema a implantar, ejecutarlo y analizarlo.
 Actividad 4. Configurar el entorno de prueba. Preparar el entorno de
prueba, herramientas y recursos necesarios para ejecutar cada una de las
estrategias, así como las características y componentes disponibles para la
prueba. Asegúrarse de que el entorno de prueba se ha preparado para la
monitorización de los recursos según sea necesario.
 Actividad 5. Aplicar el diseño de la prueba. Desarrollar las pruebas de
rendimiento de acuerdo con el diseño del plan.

134
  Actividad 6. Ejecutar la prueba. Ejecutar y monitorizar las pruebas.
Validar las pruebas, los datos de las pruebas, y recoger los resultados.
Ejecutar pruebas válidas para analizar, mientras se monitoriza la prueba y
su entorno.
 Actividad 7. Analizar los resultados, realizar un informe y repetirlo.
Consolidar y compartir los resultados de la prueba. Analizar los datos, tanto
individualmente, como con un equipo multidisciplinario. Volver a priorizar el
resto de las pruebas y volver a ejecutarlas de ser necesario. Cuando todas
las métricas estén dentro de los límites aceptados, ninguno de
los umbrales establecidos han sido rebasados, y toda la información
deseada se ha reunido, las pruebas han acabado para el escenario definido
por la configuración.

Prueba unitaria

En programación, una prueba unitaria es una forma de comprobar el correcto

funcionamiento de una unidad de código. Por ejemplo en diseño estructurado o
en diseño funcional una función o un procedimiento, en diseño orientado a
objetos una clase. Esto sirve para asegurar que cada unidad funcione
correctamente y eficientemente por separado. Además de verificar que el
código hace lo que tiene que hacer, verificamos que sea correcto el nombre,
los nombres y tipos de los parámetros, el tipo de lo que se devuelve, que si el
estado inicial es válido, entonces el estado final es válido también.
La idea es escribir casos de prueba para cada función no trivial o método en el
módulo, de forma que cada caso sea independiente del resto. Luego, con
las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del
sistema o subsistema en cuestión.

Índice

 1Características
 2Ventajas
 3Limitaciones
 4Herramientas
 5Referencias

Características[editar]
Para que una prueba unitaria tenga la calidad suficiente se deben cumplir los
siguientes requisitos:

 Automatizable: No debería requerirse una intervención manual. Esto es

especialmente útil para integración continua.
 Completas: Deben cubrir la mayor cantidad de código.

135
 Repetibles o Reutilizables: No se deben crear pruebas que sólo puedan
ser ejecutadas una sola vez. También es útil para integración continua.
 Independientes: La ejecución de una prueba no debe afectar a la
ejecución de otra.
 Profesionales: Las pruebas deben ser consideradas igual que el código,
con la misma profesionalidad, documentación, etc.
Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se
recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.

Ventajas[editar]
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar
que las partes individuales son correctas. Proporcionan un contrato escrito que
el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco
ventajas básicas:

 Fomentan el cambio: Las pruebas unitarias facilitan que el programador

cambie el código para mejorar su estructura (lo que se ha dado en
llamar refactorización), puesto que permiten hacer pruebas sobre los
cambios y así asegurarse de que los nuevos cambios no han introducido
defectos.
 Simplifica la integración: Puesto que permiten llegar a la fase de
integración con un grado alto de seguridad de que el código está
funcionando correctamente. De esta manera se facilitan las pruebas de
integración.
 Documenta el código: Las propias pruebas son documentación del
código, puesto que ahí se puede ver cómo utilizarlo.
 Separación de la interfaz y la implementación: Dado que la única
interacción entre los casos de prueba y las unidades bajo prueba son las
interfaces de estas últimas, se puede cambiar cualquiera de los dos sin
afectar al otro, a veces usando objetos maquetados (mock object -
maqueta) que habilitan de forma aislada (unitaria) el comportamiento de
objetos complejos.
 Los errores están más acotados y son más fáciles de localizar: Dado
que tenemos pruebas unitarias que pueden desenmascararlos.

Limitaciones[editar]
Es importante darse cuenta de que las pruebas unitarias no descubrirán todos
los errores del código. Algunos enfoques se basan en la generación aleatoria
de objetos para amplificar el alcance de las pruebas de unidad. 1 Esta técnica se
conoce como testing aleatorio (RT, por random testing). Por definición, sólo
prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de
integración, problemas de rendimiento y otros problemas que afectan a todo el
sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos
especiales de entradas que puede recibir en realidad la unidad de programa
bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto
con otras pruebas de software.

Herramientas[editar]

136
 Typemock[1]: Entorno de pruebas para C++, C# y .NET - incluso puedes
probar el código legado con él.
 JUnit: Entorno de pruebas para Java creado por Erich Gamma y Kent
Beck. Se encuentra basado en SUnit creado originalmente para realizar
pruebas unitarias para el lenguaje Smalltalk.
 TestNG: Creado para suplir algunas deficiencias en JUnit.
 JTiger: Basado en anotaciones, como TestNG.
 SimpleTest: Entorno de pruebas para aplicaciones realizadas en PHP.
 PHPUnit: Sistema para la realización pruebas unitarias en PHP.
 CPPUnit: Versión del framework para lenguajes C/C++.
 NUnit: Versión del framework para la plataforma.NET.
 FoxUnit: Entorno OpenSource de pruebas unitarias para Microsoft Visual
FoxPro.
 MOQ: Entorno para la creación dinámica de objetos simuladores
(mocks). «MOQ».
 QUnit: Biblioteca para pruebas unitarias en Javascript. Creada por la
fundación jQuery, ha sido reescrita para ser independiente de la biblioteca
jQuery.
 libunittest: Biblioteca portable para pruebas unitarias en C++ que usa el
nuevo estándar C++11.
 CUnit: Entorno para escribir, administar y correr test unitarios en
lenguaje C.
 PyUnit: Framework para la elaboración de pruebas unitarias en python.
 QtTest: Clases para pruebas unitarias en la biblioteca Qt (C++).
 utPLSQL: Framework para la elaboración de pruebas unitarias en
PLSQL.

Pruebas de regresión
Ir a la navegaciónIr a la búsqueda

Se denominan pruebas de regresión a cualquier tipo de pruebas

de software que intentan descubrir errores (bugs), carencias de funcionalidad, o
divergencias funcionales con respecto al comportamiento esperado del
software, causados por la realización de un cambio en el programa. Se evalúa
el correcto funcionamiento del software desarrollado frente a evoluciones o
cambios funcionales. El propósito de éstas es asegurar que los casos de
prueba que ya habían sido probados y fueron exitosos permanezcan así. Se
recomienda que este tipo de pruebas sean automatizadas para reducir el
tiempo y esfuerzo en su ejecución.
Las pruebas de regresión se pueden considerar como el subconjuntos de
pruebas planificadas que se seleccionan para ser ejecutadas , generalmente de
forma automática y periódicamente en cada nueva liberación del
producto/software , teniendo como objetivo la verificación de que el producto no
haya sufrido regresiones.

137
 Este tipo de cambio puede ser debido a prácticas no adecuadas de control de
versiones, falta de consideración acerca del ámbito o contexto de producción
final y extensibilidad del error que fue corregido (fragilidad de la corrección), o
simplemente una consecuencia del rediseño de la aplicación.
Por lo tanto, en la mayoría de las situaciones del desarrollo de software se
considera una buena práctica que cuando se localiza y corrige un bug, se
grabe una prueba que exponga el bug y se vuelvan a probar regularmente
después de los cambios subsiguientes que experimente el programa.
Existen herramientas de software que permiten detectar este tipo de errores de
manera parcial o totalmente automatizada, la práctica habitual en programación
extrema es que este tipo de pruebas se ejecuten en cada uno de los pasos
del ciclo de vida del desarrollo del software.

Índice

 1Tipos de regresión
 2Como mitigar los riesgos
 3Usos
 4Automatización
 5Citas
 6Véase también
 7Referencias

Tipos de regresión[editar]
Clasificación de ámbito

 Local - los cambios introducen nuevos errores.

 Desenmascarada - los cambios revelan errores previos.
 Remota - Los cambios vinculan algunas partes del programa (módulo) e
introducen errores en ella.
Clasificación temporal

 Nueva característica - los cambios realizados con respecto a nuevas

funcionalidades en la versión introducen errores en otras novedades en la
misma versión del software.
 Característica preexistente - los cambios realizados con respecto a
nuevas funcionalidades introducen errores en funcionalidad existente de
previas versiones.

Como mitigar los riesgos[editar]

 Repetición completa y habitual de la batería de pruebas, manual o

mediante automatización.
 Repetición parcial basada en trazabilidad y análisis de riesgos.
 Pruebas de cliente o usuario:

138
 o Beta - distribución a clientes potenciales y actuales de versiones
beta.
o Pilot - distribución a un subconjunto bien definido y localizado.
o Paralela - simultaneando uso de ambos sistemas.* Usar releases
mayores. Probar nuevas funciones a menudo cubre las funciones
existentes. Cuantas más nuevas características haya en un release,
habrá mayor nivel de pruebas de regresión "accidental".
 Parches de emergencia - estos parches se publican inmediatamente, y
serán incluidos en releases de mantenimiento futuras.

Usos[editar]
Las Pruebas de Regresión pueden usarse no solo para probar
la corrección de un programa, sino a menudo usarse para rastrear la calidad
de su salida. Por ejemplo en el diseño de un compilador, las pruebas de
regresión deben rastrear el tamaño del código, tiempo de simulación, y el
tiempo de compilación de las suites de prueba. Cuando quiera que aparece un
nuevo build, el proceso de regresión aparece.

Automatización[editar]
Las pruebas de regresión se pueden llevar a cabo manualmente o mediante
automatización. A medida que pasa el tiempo, las pruebas de regresión se van
acumulando hasta tal punto que son difíciles de mantener. A través de
la automatización de pruebas, se puede ejecutar una suite de pruebas de
regresión cada vez que hay un cambio en el software. 1

Citas[editar]

 "También como consecuencia de la introducción de nuevos bugs,

el mantenimiento del programa necesita más pruebas del sistema por
sentencia escrita que cualquier otra programación. En teoría, después de
cada corrección uno debe ejecutar el batch completo de casos de prueba
antes de ejecutar contra el sistema, para asegurarse de que no ha sido
dañado de forma oscura. En la práctica, tales pruebas de regresión deben
aproximarse a esta idea teórica, y es muy costoso." -- Fred Brooks, The
Mythical Man Month (p 122)

Tipos de prueba mas comunes

Cada vez más los usuarios móviles se han vuelto más exigentes
e impacientes. En tan sólo unos segundos, ya pueden determinar si una App
les gusta o no.

139
 Si la app es demasiado complicada o lenta, seguramente no sólo pasarán al
competidor sino que también publicarán una crítica negativa de tu sitio en las
redes sociales que podría perjudicar tu reputación.

Debido a que cualquier aplicación sólo dispone de una oportunidad rápida de

hacerlo bien y que cada vez más hay más competencia altamente
cualificada, realizar un gran test es la clave del éxito.

Desde pruebas funcionales más básicas o concretas, pruebas basadas en

riesgo hasta pruebas de seguridad y privacidad,… Se pueden hacer cantidad
de pruebas que aseguren el buen funcionamiento de la app. Desde pruebas a
nivel externo hasta incluso en el propio código, lo cual es primordial para un
buen test.

A continuación vamos a detallar cuatro tipos de pruebas de software que

desempeñaría un QA o tester:
 Funcionales
 No funcionales
 Estructurales
 De regresión o re-pruebas

Pruebas de software funcionales

Son las que revisan el comportamiento del sistema, subsistema o componente

software. Suelen ser pruebas ya documentadas en especificaciones de
requisitos o en casos de uso.

También se las llaman Pruebas de Caja Negra (“black-box testing”) dado que

se valora el comportamiento externo del sistema. Entre algunas de sus pruebas
podemos encontrar las ‘Pruebas de seguridad’ y las ‘Pruebas de
interoperabilidad’.

140
Fuente foto: http://toka-solutions.com

Pruebas de software no funcionales

Dentro de este grupo de pruebas se incluyen las de Rendimiento, Carga,

Estrés, Usabilidad, Mantenibilidad, Fiabilidad y de Portabilidad.

Puesto que estas pruebas normalmente consideran el comportamiento externo

del sistema, en la mayoría de los casos se utilizan técnicas de Pruebas de Caja
Negra.

Pruebas de software estructurales

En este tipo de pruebas se indaga más el comportamiento interno, en el que se

revisa los componentes y la integración de éstos. Por eso se las suele
llamar Pruebas de Caja Blanca (“white-box testing”).

Fuente foto: blog.elevenpaths.com

Pruebas de software de regresión o re-pruebas

Las pruebas de regresión se realizan una vez que un error detectado ha sido
corregido para confirmar que éste ha sido eliminado.

Además de probar el componente que ha tenido que ser modificado es

importante volver a revisar todo para descubrir cualquier defecto introducido, o
no cubierto previamente, como consecuencia de los cambios.

141
Fuente foto: http://christianfontalvo.com

Y aquí termina los tipos de pruebas existentes que permitirán validar

correctamente cualquier app. Por otro lado, si os interesa conocer más cosas
sobre testing, podéis acceder aquí. 

Que es un defecto de prueba de software

En nuestra vida cotidiana utilizamos multitud de aparatos -electrodomésticos,

vehículos, equipos informáticos…- que, con mayor o menor frecuencia, fallan o
presentan defectos. Los fabricantes, a medida que los van evolucionando, se
ocupan también analizar estos defectos con el fin de evitar que se repitan en
futuras versiones. En la mayoría de los casos, las marcas llevan un registro de
incidencias recogidas a través de los talleres adheridos y servicios postventa,
que les permite conocer los fallos más habituales, su gravedad, frecuencia, etc.

En el mundo del software esta tarea no es tan habitual o, al menos, no lo era

hasta hace poco. Tradicionalmente, cuando se detecta un defecto en una
aplicación que está en fase de pruebas o una incidencia cuando ya está en
producción, la anomalía se reporta al equipo de desarrollo para que la subsane,
pero raramente se analiza el motivo que la produjo con el objetivo de evitar que
se repita en futuras versiones.

Los modelos de pruebas de alta madurez, como los niveles 4 y 5 de TMMi,

incluyen dentro de sus prácticas el análisis de la causa raíz de los defectos de

142
forma sistemática, con el objetivo final de prevenirlos. Un proceso de pruebas
maduro pasa de focalizarse en la detección de defectos para orientarse en la
prevención de los mismos. Esta prevención consiste, básicamente, en analizar
defectos detectados durante el proceso de pruebas y en producción, identificar
sus causas y tomar acciones correctivas para prevenir que vuelvan a ocurrir.
Se trata de una prevención proactiva, en la que se analizan los defectos para
mejorar el proceso 'aguas arriba' y evitar que ese tipo de defecto, así como
otros similares, aparezcan de nuevo.

Esta práctica permite optimizar el proceso de pruebas, reduciendo sus costes,

mejorando el time to Market e incrementando la calidad de los productos
puestos en producción. También permite mejorar el proceso de desarrollo
desde requisitos hasta construcción, ya que las acciones correctivas
identificadas para evitar que los defectos analizados vuelvan a producirse
ponen el foco en las fases iniciales del ciclo de vida del software.

Está demostrado que aplicando este tipo de técnicas, la cobertura de requisitos

probados aumenta en un 15% y que el número de incidencias en producción se
reduce en un 18%. Además, aumenta el rendimiento del proceso de desarrollo
en su conjunto, reduciendo el tiempo de entrega en un 12 %.

El proceso de pruebas basado en la prevención de defectos para asegurar

la calidad del software
Para implantar un proceso de pruebas basado en la prevención de defectos es
necesario definir qué parámetros van a servir para decidir si un defecto debe
ser analizado o no. Partiendo de la base de que los recursos son limitados, no
es viable analizar la causa raíz de todos los defectos, sino sólo de aquellos que
por su tipología merecen ese esfuerzo. Los parámetros que habitualmente se
utilizan son: el daño potencial del defecto (económico o de imagen), frecuencia
de ocurrencia, el coste que supone solucionarlo y el impacto del defecto en el
conjunto de la aplicación.

Por otra parte, es necesario disponer de técnicas, mecanismos, herramientas y

formación para que el análisis de la causa raíz de los defectos pueda llevarse a
cabo de forma sistemática y formalizada. Diagramas de Ishikawa, diagramas
de causa-efecto, esquemas de clasificación de defectos o la técnica de los 5
porqués, son algunos ejemplos de técnicas que permiten analizar cuál es la
causa raíz de un defecto.

Con los parámetros y mecanismos de prevención implantados se estará en

disposición de incorporar esta práctica al proceso de pruebas. Lo habitual es
que al final de cada uno de los niveles de pruebas definidos en la organización
se seleccionen, en base a los parámetros establecidos, los defectos a analizar.
Para su análisis se aplicarán las técnicas definidas hasta llegar a identificar la
causa raíz que ha provocado el defecto. Una vez conocida dicha causa, el
siguiente paso será definir una o varias acciones correctivas que puedan evitar
que un defecto similar ocurra. Como es lógico, las acciones correctivas se
focalizan en las etapas anteriores al punto del ciclo de vida en la que se detectó
el defecto, ya sea fase de requisitos, análisis, diseño o construcción.

143
La prevención de defectos es muy útil en cualquier servicio de pruebas, sobre
todo en aquellos sectores donde la evolución del negocio o del software sea
muy dinámica. Por ejemplo, en el sector Telco, caracterizado por el gran
volumen de aplicaciones que intervienen en los flujos de provisión -CRM,
integración, facturación, backend, plataforma de red, etc.- y por la continua
aparición de nuevas campañas que implican cambios en el software, disponer
de un proceso de pruebas de alta madurez basado en la prevención de
defectos garantiza un aumento evidente de la calidad del software, a la vez que
una reducción del time to market muy significativa.

Algunos ejemplos reales de defectos analizados y de acciones correctivas

identificadas en una compañía del sector Telco serían los siguientes:

-Defectos por problemas de entorno: se trata de defectos que impiden

completar altas de clientes o cuando no llegan las órdenes a los instaladores
finales. Tras el análisis se determina que en un 80% de los casos la causa es
que no todos los sistemas que participan en el flujo están disponibles. Como
acción correctiva se incluye una checklist de comprobación para asegurar la
disponibilidad de todos los sistemas.

-Defectos por parametrización incorrecta: consiste en acciones que el sistema

no debería permitir, pero que se permiten. La causa raíz es que la
parametrización original del sistema no es correcta.

-Defectos por configuración de perfiles incorrecta: en los que existen botones o

funciones no disponibles debido a que los perfiles no están correctamente
configurados. Tras analizar el defecto, se determina que los requisitos de dicha
configuración no son correctos y se realizan acciones para mejorar el proceso
de especificación de requisitos.

-Defectos por flujos complejos: en los que se visualizan errores genéricos al

tramitar pedidos y que, en un alto porcentaje de casos, se deben a un error en
un sistema concreto del flujo de provisión derivado de un defecto en el diseño
técnico del sistema. En este caso, se actúa sobre el diseño técnico para
corregir el defecto.

-Probar el software antes de su paso a producción es una práctica

indispensable, pero no suficiente. La importancia que tienen los sistemas sobre
el negocio de las organizaciones obliga a disponer de un ciclo de vida de
software de alta madurez basado en la prevención, y es que, al igual que en el
resto de aspectos de la vida, más vale prevenir que curar.

Que es Cucumber

Cucumber no es una herramienta de Testing, es un modelo de colaboración

2 comentarios / General / Por jgarzas / 11 mayo, 2016

Principalmente este año y el anterior, hemos estado bastante ocupados

ayudando a gente a reforzar sus procesos ágiles con el uso de BDD, Gherkin,
Cucumber. Estos temas llevan dando vueltas bastantes años, pero parece que

144
ahora se les está dando su importancia de manera más ámplia. Y, cómo suele
suceder, esto suele llevar a algunas interpretaciones no del todo correctas y de
ahí viene este post.
Las primeras ideas sobre BDD vienen de hace ya sus años, de allá por 2003, y
aunque hoy han sido etiquetadas por muchos como sólo de Testing,
deberíamos tener presente que todo esto no sólo es, ni exclusivamente nació,
para el Testing: realmente nació para evitar los históricos problemas que
conllevan las necesidades de negocio (requisitos, historias, etc.) que se
malentienden.
La idea que dio origen a Cucumber era la de combinar las “pruebas de
aceptación automatizadas”, los “requisitos funcionales” (historias de usuario,
etc.) y la “documentación”, todo ello en un formato entendible (Gherkin) por
personas sin conocimientos técnicos (Product Owners, negocio, etc.).
Cuando en 2008 se creó Cucumber, lo hizo para proporcionar ese (a) lenguaje
común entendible por personas sin conocimientos técnicos (Gherkin), (b) dar
soporte a un proceso (BDD) y (c) ser una herramienta que proporcionaría una
fuente única con el comportamiento esperado para el software a desarrollar.
Por ello, el hacer uso de Cucumber es para mucho más que contar con una
ayuda para automatizar pruebas. Y esto lo puedes ver claramente en las dos
actividades que siempre deben acompañar a Cucumber: los talleres de
especificación (tres amigos) y el proceso de “fuera a dentro”.
Los talleres de especificación (tres amigos)
En inglés le llaman así «los tres amigos», en español queda un poco raro, en
cualquier caso todo esto viene a que en la definición de una necesidad
(requisito, historia, etc.) siempre deben participar “tres amigos”: la persona de
negocio, el programador y el Tester. Los tres especifican con ejemplos cómo el
software deberá comportarse y lo escriben en escenarios Gherkin.

El proceso: Desarrollo de fuera a dentro, BDD y especificaciones con

ejemplos
Al proceso que rodea u engloba a Cucumber Dan North le llamó BDD y Gojko
Adzic le dio un otro nombre: Especificación con ejemplos. A todo ello, al
proceso, también se le conoce como “desarrollo de fuera a dentro”.
Se llama “de fuera a dentro” porque el desarrollo comienza desde la
funcionalidad hacia dentro, hacia el sistema, la funcionalidad guía al desarrollo.
Los programadores ejecutan los escenarios que describen cómo se espera que
se comporte funcionalmente el sistema con Cucumber, y ello les dice lo qué
hay que implementar.
Similar a la idea de TDD, pero Cucumber se sitúa en un nivel de abstracción
más alto, más cerca del dominio, del negocio, de las necesidades funcionales y
más lejos de clases y métodos.

Cucumber es una herramienta para la colaboración

Cuando Cucumber se usa únicamente como una herramienta para automatizar
pruebas y sin la participación de negocio… pierde su valor.
Cuando se escriben los escenarios Gherkin de Cucumber después, una vez
que el software está implementado, en vez de al revés, pierdes todas las
ventajas.
Las características Cucumber en Gherkin deben escribirse antes que el código

145
de la aplicación. Las características de Cucumber nacen con los requisitos de
software. Cucumber es una herramienta de colaboración que busca un
entendimiento común de las necesidades, basado en la colaboración de tres
roles: negocio, desarrollo y Testing.

Pruebas de humo
Ir a la navegaciónIr a la búsqueda

En ingeniería de software y pruebas de software, las pruebas de

humo (smoke testing) son aquellas pruebas que pretenden evaluar
la calidad de un producto de software previo a una recepción formal, ya sea al
equipo de pruebas o al usuario final, es decir, es una revisión rápida del
producto de software para comprobar que funciona y no tiene defectos que
interrumpan la operación básica del mismo.
Se hace la analogía al humo, puesto que en bienes raíces se inyecta humo en
las tuberías de agua para validar que no tengan fugas, evitando provocar
inundaciones.

Técnicas de Pruebas de Software

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.

146
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,
Ava y TestNG, Powermock, XCTest

2. Pruebas de integración

La prueba de integración es una extensión lógica de las pruebas unitarias. Dos

unidades que ya han sido testeadas y combinadas en un componente y su
interface son testeadas entre ellas. Un componente, en este ejemplo, se refiere
a un agregado que está integrado en más de una unidad, estas son
combinadas en componentes, que son agregadas por orden en partes 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

147
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

148
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!

Que es Testware

Testware es un subconjunto del software de aplicación de propósito especial.

El termino Testware proviene de la combinación de palabras “test” y “software”.
Las aplicaciones testware están diseñadas específicamente para pruebas de
software y son generalmente utilizados por las personas encargadas del control
de calidad de una aplicación o Software Quality Assurance.
Testware permite minimizar costo por desarrollo de sistemas al minimizar o
eliminar errores antes de entregar una aplicación para uso del usuario. En

149
 general testware es conocido también como herramientas de pruebas e incluye
casos de prueba, plan de pruebas e informes de pruebas.

Métricas de un proyecto de prueba de software

La generación de conocimiento necesita un poso de calidad que se extiende

desde el dato mismo hasta el programa desarrollado para interactuar con
la información. Las métricas de calidad de software permiten monitorizar un
producto para determinar su nivel de calidad aunque, el seguimiento que este
tipo de medidas permiten llevar a cabo brinda la oportunidad de conocer
muchas más cosas de una solución.

 Créditos fotográficos: istock Agsandrew

Beneficios y ejemplos del uso de métricas de calidad de software

La mala calidad de la información y de software impacta negativamente en el

negocio a diferentes niveles:

 Disminuye ingresos y aumenta el gasto.

 Incrementa el riesgo.

 Provoca una reducción de la confianza, tanto dentro como fuera de

la organización.

Un enfoque proactivo tanto del gobierno de la información como del data

quality permite la identificación temprana de errores o defectos que
pueden ser corregidos a tiempo, eliminando de raíz problemas mayores. Los
efectos positivos empiezan a notarse y sus beneficios aumentan en un ciclo
de mejora continua propiciado por el control de las métricas de calidad de
software.

Esta monitorización facilita el evaluar:

 La calidad del producto.

 El rendimiento del equipo de desarrollo.

 La justificación del uso de nuevas herramientas o soluciones.

 Los resultados obtenidos a partir de la incorporación del software a los

procesos y operaciones.

150
Para conseguir llegar al nivel de evaluación, es preciso contar con datos
relevantes, precisos y actualizados sobre diferentes áreas, que faciliten una
perspectiva global de la solución. Así, las métricas de calidad de
software pueden aplicarse a diferentes contextos, como:

1. El proyecto: son las que facilitan la gestión del riesgo permitiendo tomar
el pulso a la iniciativa de desarrollo desde su inicio.
2. El producto: están enfocadas a medir las características del software y
todos los entregables que lo acompañan, fruto del proyecto de desarrollo,
como modelos, componentes adicionales y documentación.
3. El proceso: tienen por objeto identificar mejores prácticas para su
exportación a futuros proyectos y, para conseguirlo, recopilan datos de
distintas iniciativas a lo largo de un periodo de tiempo determinado.

Sin embargo, a la hora de centrarse en la solución en sí, existen

algunas métricas de calidad de software imprescindibles, como las que
tienen que ver con los cinco siguientes criterios:

A/ Métricas de exactitud: intentan aportar información sobre la validez y

precisión del software y su estructura, incluyendo la etapa de despliegue, pero
también la de pruebas y la función de mantenimiento.

B/ Métricas de rendimiento: a través de ellas se consigue medir el

desempeño del software, tanto de cada uno de sus módulos, como del sistema
al completo.

C/ Métricas de usabilidad: hay que descartar la complejidad y buscar una

solución intuitiva y user-friendly. este tipo de métricas de calidad de
software ayudan a determinar si la solución cumple con dichos requisitos.

D/ Métricas de configuración: las limitaciones, el estilo de código y todos los

datos relativos al desarrollo y cualidades del producto se verán evaluados en
base a estas métricas.

E/ Métricas de eficiencia: minimización de latencias, velocidad de respuesta,

capacidad, es un enfoque similar al de la productividad pero con un matiz un
poco distinto, que añadido a aquél, aporta una visión mucho más completa de
la solución.

De esta forma, evaluando el software a través de diferentes ópticas y en

base a continuas mediciones, se puede ganar en alineación con el
objetivo de calidad que, poco a poco, se irá sofisticando y para lograr
alcanzar cotas superiores.

Que es un plan de pruebas

151
 En esta actividad se inicia la definición del plan de pruebas, el cual sirve como
guía para la realización de las pruebas, y permite verificar que el sistema de
información cumple las necesidades establecidas por el usuario, con las
debidas garantías de calidad.

El plan de pruebas es un producto formal que define los objetivos de la prueba

de un sistema, establece y coordina una estrategia de trabajo, y provee del
marco adecuado para elaborar una planificación paso a paso de las actividades
de prueba. El plan se inicia en el proceso Análisis del Sistema de
Información (ASI), definiendo el marco general, y estableciendo los requisitos
de prueba de aceptación, relacionados directamente con la especificación de
requisitos.
Dicho plan se va completando y detallando a medida que se avanza en los
restantes procesos del ciclo de vida del software, Diseño del Sistema de
Información (DSI), Construcción del Sistema de Información (CSI)
e Implantación y Aceptación del Sistema (IAS).

Se plantean los siguientes niveles de prueba:

 Pruebas unitarias.
 Pruebas de integración.
 Pruebas del sistema.
 Pruebas de implantación.
 Pruebas de aceptación.

En esta actividad también se avanza en la definición de las pruebas de

aceptación del sistema. Con la información disponible, es posible establecer los
criterios de aceptación de las pruebas incluidas en dicho nivel, al poseer la
información sobre los requisitos que debe cumplir el sistema, recogidos en el
catálogo de requisitos.

TÉCNICAS Y
TAREA PRODUCTOS PRÁCTICAS PARTICIPANTES

ASI 10.1: Definición  Plan de  Sesiones de  Jefe de

del Alcance de las Pruebas Trabajo Proyecto
Pruebas  Analistas
 Equipo de
Soporte Técnico
 Usuarios
Expertos

ASI 10.2: Definición de  Plan de  Sesiones de  Jefe de

Requisitos del Entorno Pruebas Trabajo Proyecto
de Pruebas  Analistas
 Equipo de
Soporte Técnico
 Usuarios
Expertos

152
ASI 10.3: Definición de  Plan de  Sesiones de  Jefe de
las Pruebas de Pruebas Trabajo Proyecto
Aceptación del  Analistas
Sistema  Equipo de
Soporte Técnico
 Usuarios
Expertos

¿Qué es un mainframe?

De seguro, alguna vez habrás escuchado hablar de un mainframe o habrás

leído sobre ellos en algún artículo o reseña. Si no estás claro con este
concepto, estás de suerte, ya que en este artículo te explicaremos de la
manera más sencilla posible lo que es un mainframe. Si eres experto o tienes
algún conocimiento, este artículo te ayudará a refrescar la memoria y afianzar
conceptos.

¿Qué es un mainframe? 

Para explicar lo que es un mainframe de una manera simple, debes imaginar

que estás en una enorme sala, la cual se encuentra ocupada por una gran
cantidad de equipos entrelazados y conectados entre sí. Servidores, unidades
procesadoras, unidades de almacenaje, entre otros. Todo este aparataje
representa una especie de súper computadora que ofrece servicios de red a
varios clientes o terminales, o simplemente, se encuentra orientada a realizar
enormes cantidades de cálculos complejos.

153
Los mainframe son super computadoras al servicio de una red. Imagen
de: Argonne National Laboratory. Bajo licencia: CC BY 2.0.

Con esta imagen en mente, podemos entonces definir rápidamente lo que es

un mainframe. Se trata de una enorme o gran computadora central, la cual es
capaz de realizar millones de instrucciones por segundo. Además tienen la
capacidad de trabajar de manera ininterrumpida, incluso si se tiene que
cambiar algún componente del mainframe, ya que su diseño modular, le
permite trabajar sin parar y sin necesidad de re-iniciarse.

Por lo general estas, enormes computadoras son utilizadas como las centrales

de cálculo y almacenamiento de grandes organizaciones o empresas como
bancos, universidades, corporaciones, etc. Por demás está decir, que los
mainframe son capaces de trabajar a altas velocidades y realizar múltiples
tareas a la vez. Además cuentan con una arquitectura diseñada para permitir
un equilibrio de beneficios y un mayor nivel de seguridad para los datos que se
procesan o se transmiten desde y hacia el mainframe, siendo ideales para
trabajos en equipo y en redes que requieran altas velocidades de trabajo y
sensación de seguridad informática.

Arquitectura de un mainframe. Imagen de: Agiorgio. Bajo licencia: CC BY-SA

4.0.

Al tener estructura centralizada, los mainframe reducen costos

de mantenimiento y facilitan la gestión de tareas de una central, en lugar de
ejecutarse en varios servidores más pequeños.

154
Mainframe antiguo en acción. Imagen de: Erik Pitti. Bajo licencia: CC BY 2.0.

Podemos decir entonces que los mainframe son el corazón de una empresa, ya
que centralizan el trabajo de red y facilitan la ejecución de tareas a velocidades
realmente grandes, equilibrando seguridad y eficiencia a un costo mucho más
bajo que utilizar varios servidores. A pesar de no ser un concepto nuevo, estos
equipos han evolucionado, permitiendo incluso un bajo consumo de energía y
alta resistencia a cambios bruscos de temperatura.

Pruebas exploratorias
El testing exploratorio o pruebas exploratorias es un estilo o enfoque para
la realización de pruebas de software. Su principal característica es que el
aprendizaje, el diseño y la ejecución de las pruebas se realizan de forma
simultánea. Cem Kaner, quien acuñó el término en 1983, define el testing
exploratorio como "un estilo de testing que enfatiza la libertad personal y la
responsabilidad del tester para optimizar continuamente la calidad de su trabajo
tratando el aprendizaje a través de las pruebas, el diseño de las pruebas, la
ejecución de las pruebas y la interpretación del resultado de las pruebas como
actividades que se apoyan mutuamente y que se ejecutan en paralelo a lo largo
del proyecto."
Mientras se está probando el software, el tester va aprendiendo a manejar el
sistema y junto con su experiencia y creatividad, genera nuevas pruebas a
ejecutar. A menudo se piensa que el testing exploratorio es como una técnica
de prueba de caja negra. Sin embargo, aquellos que lo han estudiado, lo
consideran un enfoque que se puede aplicar a cualquier técnica de pruebas, en
cualquier etapa del proceso de desarrollo. La clave no es la técnica ni el
elemento que estamos probando o revisando; la clave es el compromiso
cognitivo del tester y la responsabilidad del tester para gestionar su tiempo.

Descripción[editar]
El testing exploratorio persigue saber cómo funciona realmente el software y
responder a preguntas sobre cómo éste maneja los casos fáciles y difíciles. La
calidad del testing exploratorio depende de las habilidades del tester de realizar

155
los casos de prueba oportunos y encontrar los defectos presentes. Mientras
más conocimientos tiene el tester sobre el producto y los diferentes métodos de
prueba, mejor será el testing realizado.
Se puede comparar el testing exploratorio libre con su antítesis, el scripted
testing o testing basado en procedimientos de prueba. En este enfoque, los
casos de prueba son diseñados con antelación, incluyendo tanto los pasos a
realizar como el resultado esperado. Estas pruebas son más tarde ejecutadas
por un tester que compara el resultado actual con el resultado esperado.
Cuando realizamos testing exploratorio, los resultados esperados están
abiertos. Algunos resultados pueden ser precedidos y esperados, otros puede
que no. El tester configura, opera, observa y evalúa el producto y su
comportamiento, investigando de forma crítica el resultado y reportando la
información de lo que parecen ser defectos (que amenazan el valor del
producto) o problemas (que amenazan la continuidad y calidad de las pruebas).
En realidad, el testing casi siempre es una combinación de testing exploratorio
y guiado, pero con una tendencia hacia uno de ellos, dependiendo del contexto.
Según Cem Kaner y James Marcus Bach, el testing exploratorio es más una
mentalidad o "...una forma de pensar sobre el testing" que una metodología.
Ellos también dicen que hay todo un abanico de opciones desde lo ligeramente
exploratorio (testing ligeramente ambiguo o vagamente guiado) hasta lo
altamente exploratorio (testing exploratorio totalmente libre).
La documentación del testing exploratorio se mueve en un rango que va desde
documentar todas las pruebas realizadas a documentar únicamente los
defectos. En las pruebas por parejas, dos personas crean los casos de pruebas
juntas; una los ejecuta y la otra documenta. El testing basado en sesiones es
un método específicamente diseñado para el testing exploratorio auditable y
medible a gran escala.
Para el testing exploratorio se usan a menudo herramientas, incluyendo
herramientas de captura de pantalla o video que se usan a modo de registro de
la sesión. O herramientas para ayudar a la generación rápida de situaciones de
interés, por ejemplo, la herramienta de James Bach: Perlclip.
Caso de uso. En Ingeniería del software, es una técnica para la captura de
requisitos potenciales de un nuevo Sistema o una actualización de Software.
Cada caso de uso proporciona uno o más escenarios que indican cómo
debería interactuar el sistema con el usuario o con otro sistema para conseguir
un objetivo específico. Normalmente, en los casos de usos se evita el empleo
de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario
final.

Habilidades de un tester

Descripción

156
Los probadores de software (también conocidos como testers, su
denominación en inglés) planifican y llevan a cabo pruebas de software de los
ordenadores para comprobar si funcionan correctamente. Identifican el riesgo
de sufrir errores de un software, detectan errores y los comunican. Evalúan el
funcionamiento general del software y sugieren formas de mejorarlo.
Ver todos los cursos de Probadores de software (testers)
Actividades laborales
Los probadores de software pueden probar todo tipo de software, programas
individuales para aplicaciones o productos (una serie de programas que
almacenan y procesan información para realizar una tarea específica). Las
aplicaciones incluyen pantallas para que los usuarios introduzcan información y
puedan imprimir los resultados. Los probadores también pueden analizar sitios
web o juegos de ordenador.

Pueden estar involucrados con el desarrollo de un nuevo programa, ya que a

menudo deben probar nuevas versiones de un software, o simplemente llevar a
cabo un control rutinario de un producto existente.

En primer lugar, identifican todos los riesgos tales como: errores que podrían
ocurrir en el software cuando alguien lo está usando, confusiones a la hora de
utilizar un software por parte de un usuario debido a la falta de información, la
instalación del software en diferentes tipos de sistemas, etc. Prueban estos
riesgos para conseguir que un software ofrezca la máxima confianza. Deben
diseñar pruebas que se puedan repetir y evaluar.

Pueden evaluar el correcto funcionamiento:

 Si el software coincide con la especificación original (o qué hay que

hacer para que coincida).
 Si cuando un usuario hace clic en un botón o enlace para que suceda
algo, por ejemplo, para ir a una nueva pantalla, se abre la pantalla
correcta.
 Si el usuario tiene que introducir algunos datos, el software actúa de
forma correcta y los datos se almacenan de forma segura.
 Si está diseñado para que varios usuarios puedan abrirlo al mismo
tiempo sin que el programa reduzca su velocidad de procesamiento.

157
Si se puede utilizar herramientas de automatización de pruebas para iniciar una
sesión en muchos usuarios al mismo tiempo.
Si cuando el software tiene que compartir información con otro programa,
continúa funcionando correctamente.

Los probadores de software, por ejemplo, pueden introducir deliberadamente

información en una ruta equivocada para asegurarse de que reciben el
mensaje de error esperado. Por ejemplo, si se les pide que introduzcan un año
de nacimiento, podrían poner 1892 en lugar de 1992 y comprobar que el
programa reacciona de la forma adecuada y detecta el error.

Los probadores de software no suelen tener tiempo para probar todas las
combinaciones posibles de las acciones que pueden aplicarse con un software,
por lo que tienen que ponerse de acuerdo de antemano con el cliente sobre el
tiempo disponible que tendrán. Mantienen un registro detallado las pruebas que
realizan. Una vez completadas las pruebas, enumeran los errores y redactan
un informe para que los programadores y administradores de proyectos puedan
implementar posteriormente.

Algunos probadores trabajan como consultores, y deben viajar a los

hogares/locales de los clientes para asesorarles sobre los procedimientos de
prueba, así como la realización de las pruebas.
Perfil profesional
Un probador de software necesita:

 Importantes habilidades de TIC.

 La capacidad de trabajar con calma bajo presión.
 Capacidad de organización.
 Pensamiento lógico.
 Capacidad de planificar el trabajo futuro.
 Prestar atención a los detalles.
 Ser capaz de redactar informes claros.
 Habilidades de comunicación oral.
 Habilidades de trabajo en equipo.

Descubre qué estudiar para ser Probadores de software (testers)

Competencias

158
  Acuerda de antemano cuánto hay que testar en el tiempo disponible.
 Aptitudes para la comunicación verbal y escrita.
 Aptitudes para la planificación.
 Aptitudes para redactar informes.
 Bien organizado.
 Capacidad de análisis.
 Capacidad para priorizar tareas.
 Capacidad para trabajar en equipo.
 Capaz de prestar atención al detalle.
 Capaz de trabajar bajo presión.
 Conocimientos especializados en informática.
 Destrezas en informática.
 Elabora y realiza tests sobre programas informáticos, páginas web y
juegos.
 Habilidad para evaluar.
 Habilidad para resolver problemas.
 Idea tests que puedan repetirse y valorarse.
 Identifica riesgos.
 Lista errores y redacta informes para programadores y directores de
proyectos para que actúen según los mismos.
 Lleva registros precisos de lo que se ha testado.
 Metódico.
 Observador.
 Recomienda formas de mejorar la realización de tests.
 Resuelve cómo probar riesgos a fin de que el software resulte lo más
seguro posible.
 Sensato.
 Sentido común.
 Trabaja en equipo.
 Tranquilo.

Estudios oficiales
A continuación se relacionan algunos de los estudios oficiales (ciclos formativos
o carreras universitarias) que permiten ejercer esta profesión. Hay que tener en
cuenta que dependiendo del ámbito de especialización, es posible que se

159
tenga que complementar la formación con otros cursos más específicos del
sector. La formación continua es un aspecto clave para la mejora profesional.

Testing y calidad de software, desafíos prioritarios para la competitividad

empresarial
  

La satisfacción de José Luis Antón, responsable de la Unidad de Negocio de

SOGETI era evidente durante la presentación en España de la décima edición
del informe World Quality Report 2018/19.  Este informe, además de ser
reconocido como el más amplio estudio de Testing y Calidad de Software a
nivel mundial, constituye también la fuente más completa de análisis de este
mercado, además de confirmar algunas de las previsiones que la compañía ha
venido efectuando en estos últimos años.

Basado en 1.770 entrevistas a CIOs, Directores IT y QA Managers de 10

sectores de actividad de 32 países, el estudio (dividido en 10 secciones, 4
tecnológicas y 6 de mercados diferentes, con informes sectorizados por países)
confirma un cambio fundamental en las expectativas de negocio en cuanto a la
calidad y a su impacto en la experiencia del consumidor. Advierte de la
existencia de una demanda de calidad evidenciada en la rapidez que ha hecho
que la responsabilidad de garantizar la satisfacción del usuario final recaiga en
los equipos de Quality Assurance (creado por SOGETI, Capgemini y Micro
Focus).

En cuanto a los objetivos principales de las empresas (que deberán

incrementar sus presupuestos de aquí a tres años), el informe señala que “Por
primera vez en estos 10 años, la satisfacción de los clientes se ha erigido como
la razón fundamental para las inversiones en testing”, subrayando que “el
principal motivo por el que las empresas invierten en testing es el factor
seguridad, que se estima como factor prioritario en el 47% de los encuestados
a nivel mundial y un 45% en las empresas españolas”.

160
Para José Luis Antón, “el informe de este año refleja claramente que
garantizar la calidad ya no es una tarea de “back office”, sino una actividad
crítica para los negocios, ya que de ellos depende la satisfacción de los
clientes y, consecuentemente, la competitividad de las empresas”.

Los datos además, demuestran que el testing se ha convertido en un elemento

intrínseco del negocio dado el uso intensivo de lo digital por parte de clientes y
usuarios, así como por la irrupción de tecnologías de vanguardia como el IoT o
el blockchain.

Así entonces, se estima que el 71% de las organización es de nuestro país

aplicará Inteligencia Artificial a la presentación de las pruebas de testing en sus
cuadros de mando, lo que significa estar 11 puntos por encima de la media
mundial que se sitúa en un 60%.  Resulta sintomático  que el 54% de estas
afirme que están ya experimentando (o que lo harán en los próximos 12
meses) con una aproximación a las pruebas basadas en técnicas de IA, lo que
significa un porcentaje similar a la media mundial (57%).

José Luis Antón, responsable de la Unidad de Negocio de SOGETI

Igualmente el 59% de las empresas manifiesta que es probable que el año

próximo se centre en el análisis predictivo, el 54% declara estar interesada en
la automatización robótica y el 36% en el machine learning.

Pero hay que destacar – manifestó Antón  -, que es la primera vez que

la ”satisfacción del usuario final” se sitúa como objetivo principal dentro de la
estrategia de garantía de calidad y pruebas de software, lo que ha permitido
seguir muy de cerca la existencia y el desarrollo de las aplicaciones. Una
iniciativa necesaria ante los bajos niveles de automatización y desafíos con
datos de prueba y entornos que retrasan la garantía de calidad y la eficacia de
las pruebas de software. Por lo tanto, las habilidades requeridas para
garantizar la calidad y las pruebas de software han cambiado

161
“Con las ambiciones sobre la experiencia del consumidor establecidas para los
equipos de QA, la adopción de la inteligencia artificial y automatización para
optimizar el software de pruebas es inevitable. Creemos –
subrayó Antón -, que esta transformación cambiará de manera radical el
panorama de habilidades para QA y Testing. Nuevos roles como el IA QA
strategist, Data scientists, o expertos en pruebas para Inteligencia Artificial
entrarán a formar parte de los equipos de Quality Assurance”.

Pero uno de los aspectos más

importantes según el estudio, es que la IA ha cambiado las capacidades
demandadas en los perfiles de QA, de hecho actividades como IoT, Blockchain,
Cloud, etc., subrayan esta debilidad, tema que por lo demás, en mayor o menor
medida, afecta a todo el mundo de la TI. Sogeti reconoce que “las empresas
declaran que carecen de profesionales con conocimientos suficientes en una
media del 32%”, situación preocupante. Pero hay que tener en cuenta que
durante los próximos años emergerán tres nuevos roles en los departamentos
de testing, muy centrados en aspectos como conocimientos algorítmicos,
optimización matemática o habilidades de inteligencia empresarial. En lo que a
Sogeti respecta, se señalan AI QA Strategists;  Data Scientists; y Testers
expertos en IA; como fondo, la mejora de la toma de decisiones.

“No debemos perder de vista que al mismo tiempo, los departamentos de

calidad necesitan mejorar rápidamente sus habilidades y adoptar nuevas
tecnologías para mantenerse al día con la IA y el entorno de transformación
basado en la automatización. Esta necesidad de nuevos profesionales es todo
un reto para las empresas, por lo que quedarse atrás en él, puede significar
también quedarse atrás del mercado”, concluye Antón.

162
FUNCIONES Y RESPONSABILIDADES DE UN LIDER DE
TESTING
Creado porGustavo Terrera
/
Comentarios0

Muchas ofertas de trabajo llegan para postularse como Lider de Testing

aunque ninguna de las búsquedas me convence en cuanto a su contenido y lo
que se pide. Se me hace que las áreas de recursos humanos aún hoy no se
encuentran lo suficientemente asesoradas por parte del área técnica para
entender y saber qué piden (o mejor dicho, qué se necesita). Solo aquellos que
se encuentran trabajando en el área pueden saber muy bien cada una de las
tareas que tiene a su cargo un Lider de Testing (en algunas empresas hasta
tiene la categoría o función de Coordinador de Testing), por ese motivo me
pareció interesante enumerar las tareas que tiene a su cargo esta función a
partir de un artículo que leí hace un tiempo y le agregué algunas más que tenía
por ahí. Ojalá que esta info la levanten algún responsable de reclutamiento y
que le permita mejorar sus búsquedas.

1. Estar actualizado sobre las últimas técnicas de prueba, estrategias,

herramientas de prueba y frameworks.
2. Estar consciente de los proyectos actuales y futuros de la organización.

163
3. Revisar y analizar los requisitos del proyecto.
4. Planificar y organizar la transferencia de conocimientos, como así también el
autoaprendizaje.
5. Levantar las consultas relacionadas con los requisitos y conseguir el usuario
clave del negocio (por ejemplo, el cliente, el analista de negocio, gerente de
producto o proyecto manager) asignado al proyecto, para que resuelva
nuestros problemas.
6. Planificar, organizar y dirigir la reunión de lanzamiento de pruebas.
7. Alcance de las pruebas requeridas.
8. Diseñar la estrategia de prueba requerida conformes con el alcance y los
estándares de organización.
9. Crear el plan de pruebas de software, para que sea revisado, aprobado y
firmado por las partes interesadas.
10. Evaluar e identificar las herramientas para la gestión y automatización de
pruebas requeridas
11. Estimación del esfuerzo de la prueba y al equipo requerido (en cuanto a su
tamaño, habilidades, actitudes y calendario)
12. Crear un cronograma de pruebas (tareas, dependencias y asignación de
recursos)
13. Identificar las necesidades de formación
14. Identificar las métricas de prueba a recoger
15. Comunicarse con el cliente o los miembros del equipo on site, según los
requerimientos
16. Revisar los casos de prueba y datos de prueba obtenidos durante las
pruebas, para conducir los comentarios de revisión posteriores
17. Seguir los nuevos requerimientos actualizados y modificar en consecuencia
los artefactos de prueba.
18. Determinar, adquirir, controlar, mantener y optimizar el entorno de prueba
(hardware, software y red)
19. Obtener información sobre los últimos releases / construcciones desde el
equipo de desarrollo / cliente.
20. Crear y mantener el framework de automatización de pruebas requerido
21. Administrar el proyecto de gestión de pruebas
22. Administrar las aplicaciones bajo prueba
23. Asignar tareas de acuerdo con el plan de pruebas
24. Comprobar el estado de cada tarea diaria asignada y resolver los
problemas que afecten a los miembros del equipo con dichas tareas
25. Asegurar que cada miembro del equipo está ocupado con el trabajo de
manera óptima, teniendo en cuenta y balanceando la sobrecarga y demasiada
inactividad
26. Reasignar las tareas de prueba de acuerdo a lo que requerido
27. Seguir las tareas asignadas en relación con el plan de pruebas y la
programación del proyecto
28. Revisar la automatización de las pruebas creadas y obtener los
comentarios de revisión
29. Tomar el control y mantener la suite de automatización de pruebas del
proyecto
30. Planificar y ejecutar la automatización de pruebas
31. Revisar los informes de incidencias y asignar los defectos válidos al área de
desarrollo correspondiente

164
32. Asignar los defectos que vuelven por reporte y ayudar al Tester que tome el
tema en todo lo que requiera

Curso online Intensivo Manual Testing

El curso online “Intensivo de Testing Manual” esta diseñado para entender
desde la primera clase a usar una herramienta que permite la gestión del
testing. Bajo este enfoque práctico se desarrollará el curso y se lo
complementará con la correspondiente teoría que acompañará cada
ejercitación que se vaya realizando. De esta forma se podrá comprender el
alcance de las tareas que se realizan en todo proyecto de Software Testing
(esquema tradicional). En este sentido, rápidamente se podrá entonces
identificar cada una de las etapas que componen un proyecto y los
documentos que se utilizan para cada tarea asignada.
CLIC AQUI

33. Garantizar que han sido re probados los defectos resueltos

34. Consolidar y reportar resultados de las pruebas a las partes interesadas
35. Estar disponible a todo requerimiento por parte de los Testers
36. Actualizar el plan de pruebas de software según lo que se requiera
37. Asegurar que los casos de prueba se actualizan a partir de las pruebas de
los Testers
38. Asegurar que la automatización de pruebas se actualiza sobre la base de la
actualización de los casos de prueba
39. Preparar las métricas de prueba
40. Escalar y conseguir resolver los problemas relacionados con el entorno de
prueba y con el equipo
41. Planificar, organizar y dirigir las reuniones del equipo y asegurar que se
tomen acciones a partir de las discusiones generadas en el equipo
42. Planificar y organizar la formación de los miembros del equipo
43. Revisión los informes de estado de la prueba de los Testers del equipo
44. Revisar el tiempo registrado por los Testers de acuerdo con sus diversas
actividades
45. Reportar el estado de situación a los grupos de interés (por ejemplo, el
cliente, el director del proyecto / director de pruebas y gerencias involucradas)
46. Mantener a los Testers motivados
47. Mejorar el proceso de prueba sobre la base de las sugerencias que se
recolecten y del propio juicio
48. Administrar el propio nivel de energía y el tiempo
49. Dominar la metodología de ciclo de vida de Desarrollo
50. Tener conocimientos de Conceptos del Testing y sus diferentes tipos
51. Distribuir y hacer seguimiento de la demanda de trabajo entre los miembros
del equipo.
52. Establecer un orden de prioridad a cada tarea.
53. Monitorear el cumplimiento de los planes de acción definidos; detectar
desvíos, proponer sus correcciones e implementarlas.
54. Colaborar en la estimación de plazos de realización de etapas y tareas.

165
55. Promover/auditar la creación de pruebas unitarias por parte de Desarrollo.
56. Controlar los casos y datos de prueba cuando sea necesario.
57. Velar por que se aplique la metodología de trabajo, dentro de los
lineamientos definidos.
58. Proponer ajustes o mejoras a la metodología vigente.
59. Funcionar como nexo para la correcta implementación de las tareas de
Testing de los equipos externos contratados, incluyendo el control
correspondiente.
60. Desarrollar y analizar los indicadores de la gestión del área de testing.
61. Gestionar Riesgos: identificar y gestionar los riegos del testeo.
62. Gestionar el alcance: aceptar o demorar solicitudes de testeo según la
demanda y características del proyecto.
63. Participar en la revisión de la estrategia de testing para cada proyecto.
64. Monitorear el cumplimiento de los objetivos del área.
65. Proponer ajustes a la planificación estratégica definida.
66. Evaluar el desempeño de colaboradores a cargo.
67. Identificar necesidades de capacitación, para propiciar el conocimiento del
equipo.
68. Participar en la gestión del presupuesto del sector.
69. Estar orientado al logro de objetivos.
70. Poseer habilidades de planificación y organización.
71. Poseer buenas habilidades de comunicación, dinamismo y proactividad.
72. Estar certificado en algún área de conocimiento de testing
(ISTQB, CAT, Scrum Master, TMMi)

166
Cómo probar un sitio web

¿Quieres saber cómo probar tu sitio web? Aquí puede encontrar información
sobre las principales técnicas de prueba de sitios web. Consideraremos los
elementos de la lista de verificación de prueba del sitio web que se deben
revisar para garantizar la preparación de su sitio para el lanzamiento.

ARTICLE CONTENT

 Pruebas de documentación
 Pruebas de funcionalidad del sitio web
 Pruebas de usabilidad
 Pruebas de interfaz de usuario
 Pruebas de compatibilidad (configuración)
 Pruebas de rendimiento
 Pruebas de seguridad
 Pruebas relacionadas con el cambio
 Pruebas amigables para móviles
 Prueba beta
 Cómo probar su sitio web con EasyQA Chrome Extension

167
Las pruebas, como la etapa final del desarrollo del sitio web, desempeñan un
papel vital en el proceso de creación de software de alta calidad.

Después de la prueba del sitio web, el cliente recibe un proyecto listo sin
errores, con buena legibilidad, facilidad percibida, comodidad y confiabilidad.

Las reglas básicas para probar un sitio web son los pasos que muestran al
usuario lo fácil y lógico que es el proyecto, lo fácil y posible de encontrar la
información requerida.

Cuanto más complejo sea el sitio, más tiempo llevará probarlo y depurarlo.
Según los detalles del proyecto, hasta el 50% del presupuesto total y los
recursos de tiempo pueden asignarse para probar un sitio web.

Para organizar las pruebas del sitio web, se proporciona una metodología
especialmente desarrollada. La verificación de su sitio web se realiza de
acuerdo a esta metodología.

Las pruebas pueden realizarse de varias maneras, pero no se olvide del

proceso en sí y de la estrategia de prueba. La secuencia de tus acciones
depende de ello.

Entonces, consideremos las etapas principales que debe pasar para probar su
sitio. Mira la foto de abajo. Aquí puedes verlos.

Esto podría ser como un tutorial de prueba de sitios web para su sitio.

Pruebas de documentación

Deberíamos comenzar con la fase preparatoria, probando la documentación.

El evaluador estudia la documentación recibida (analiza la funcionalidad del
sitio definida, examina los diseños finales del sitio y realiza un plan de prueba
en el sitio web para realizar más pruebas).

Los principales artefactos relacionados con las pruebas del sitio web se
analizan en esta etapa:

168
  Requerimientos
 Plan de prueba
 Casos de prueba
 Matriz de trazabilidad.

Pruebas de funcionalidad del sitio web

Las pruebas funcionales tienen como objetivo garantizar que cada función del
sitio web funcione de acuerdo con la especificación del requisito. Prueba de
sitio web de la funcionalidad muestra “Lo que hace el sistema”.
Intentemos crear la lista de verificación para las pruebas de funcionalidad de tu
sitio web.

Pruebas de enlaces

 Usted debe verificar:

 Enlaces salientes
 Corrección de enlaces internos
 No hay enlaces que conducen a la misma página.
 Los enlaces que se utilizan para enviar correos electrónicos a los
administradores del sitio
 Si hay páginas que no están referenciadas
 No hay enlaces rotos

Pruebas de formularios para todas las páginas.

Utiliza formularios para la comunicación interactiva con sus clientes. Por lo
tanto, los siguientes puntos deben ser revisados:

 La validez de los datos de entrada.

 Valores permitidos para el campo de datos
 Valores de entrada no válidos para el campo de datos
 Opciones para formularios en los que es posible la eliminación o
cualquier otra modificación de los datos.

Prueba de cookies
Las cookies son pequeños archivos que se almacenan en la computadora del
usuario después de visitar su página web.

 Prueba un sitio con cookies deshabilitadas

 Probar un sitio con cookies habilitadas
 Verifique que la cookie esté encriptada antes de escribirla en la máquina
del usuario
 Compruebe los aspectos de seguridad al eliminar las cookies.
 Si las cookies tienen una duración de acción, se comprueba si están
activas en el período de tiempo especificado.

Validación HTML / CSS

 Errores de sintaxis HTML

169
  Verifique que el sitio esté disponible para las máquinas de búsqueda.
 Verifique que su página web tenga un mapa del sitio preciso en formato
XML y HTML

Herramientas útiles para la prueba funcional del sitio web: Selenio, Proyecto

de prueba de Linux, JUYIT Sprinter de Hewlett Packard Entreprise (prueba
manual), Navegador de navegación (Pruebas tanto automatizadas como
manuales), Usuariosnap (prueba manual).

Siga este enlace, si desea saber más acerca de las pruebas

funcionales: https://geteasyqa.com/qa/software-testing-types/

Pruebas de usabilidad

Las pruebas de usabilidad están destinadas a evaluar su página web

probándola con usuarios representativos. Ayuda a definir la capacidad del
usuario para aprender a operar, preparar entradas para e interpretar salidas de
su sitio.

Pruebas de navegación Contiene las siguientes verificaciones:

 Todas las páginas de su sitio son comprensibles y fáciles de usar

 Botones, formas y campos son convenientes para el uso
 Hay un acceso al menú principal desde todas las páginas.

Pruebas de contenido lista de verificación

 No hay errores gramaticales y ortográficos.

 Las imágenes se colocan correctamente con los tamaños adecuados.
 Verifique la optimización de la paleta de colores del sitio y los tamaños
de fuente
 El contenido debe ser informativo, comprensible, estructurado y
lógicamente vinculado
 Las instrucciones son claras y contienen información correcta.

Finalmente, Evaluar la usabilidad de su portal web., solo responde a estas

preguntas:

 ¿Es su sitio web comprensible y conveniente?

 ¿Es conveniente la navegación?
 ¿Qué impresión le da al usuario?
 ¿Hay cosas superfluas o innecesarias?

Algunas herramientas para las pruebas de usabilidad: Zoom de

usuario, Reflector, Lazo11.
Aquí también puedes leer sobre las pruebas de usabilidad 
– https://geteasyqa.com/qa/software-testing-types/

Pruebas de interfaz de usuario

170
Pruebas de interfaz de usuario (UI) Se proporciona para verificar que la
interfaz gráfica de usuario de su sitio web cumpla con las especificaciones.

Aquí hay algunas verificaciones para las pruebas de interfaz de usuario de un

sitio web:

 Cumplimiento de las normas de interfaces gráficas.

 Evaluación de elementos de diseño: diseño, colores, fuentes, tamaños
de fuente, etiquetas, cuadros de texto, formato de texto, títulos, botones,
listas, iconos, enlaces
 Pruebas con diferentes resoluciones de pantalla.
 Pruebas de versiones localizadas: precisión de traducción
(multilenguaje, multidivisa), verificación de la longitud de los nombres de
los elementos de la interfaz, etc.
 Prueba de la interfaz gráfica de usuario en dispositivos de destino:
teléfonos inteligentes y tabletas.

Herramientas útiles para pruebas de interfaz de usuario: FitNesse, iMacros, IU

codificada, Jubula LoadUI.
Más información sobre las pruebas de UI está
aquí. https://geteasyqa.com/qa/software-testing-types/

Pruebas de compatibilidad (configuración)

Se realizan pruebas de compatibilidad (configuración) para probar su sitio web

con cada una de las configuraciones de software y hardware compatibles:

 Configuración del sistema operativo

 Configuración del navegador
 Configuración de la base de datos

Pruebas multiplataforma permite evaluar el trabajo de su sitio en diferentes

sistemas operativos (tanto de escritorio como móviles): Windows, iOS / Mac
OS, Linux, Android y BlackBerry, etc.

Métodos de prueba de sitios de navegador cruzados ayuda para verificar el

trabajo correcto del sitio en diferentes configuraciones de navegador: Mozilla
Firefox, Google Chrome, Internet Explorer y Opera, etc.

Pruebas de base de datos se realiza para garantizar el trabajo correcto de su

sitio en diferentes configuraciones de base de datos: Oracle, DB2, MySql,
MSSQL Server, Sybase.

Compatibilidad de impresión También debe mencionarse en su plan de

prueba de sitio web:

 Verifique que las fuentes, los gráficos de página, la alineación de página

se puedan imprimir correctamente

171
  Asegúrese de que todas las páginas de su sitio se ajusten al tamaño del
papel y al tamaño definido en la opción de impresión.

Puedes usar herramientas como BrowserStack, CrossBrowserTesting por

Smart Bear, Tornasol, Navegador, Rational Clearcase de IBM,
Ghostlab Para las pruebas de compatibilidad de su sitio.

Busque más información sobre las pruebas de configuración

aquí. https://geteasyqa.com/qa/software-testing-types/

Pruebas de rendimiento

Pruebas de rendimiento tiene como objetivo determinar cómo funciona un

sistema en términos de capacidad de respuesta y estabilidad bajo una carga
determinada. Los sitios deben soportar altas cargas. Los métodos de prueba
del sitio web de rendimiento contienen:

 Comprobar el comportamiento del sitio en o más allá de los límites de su

carga de trabajo anticipada (Pruebas de estrés)
 Probando el comportamiento del sitio al aumentar la carga de trabajo
(Prueba de carga)
 Probar la capacidad de trabajar dentro o justo por encima del período
aceptable (Pruebas de estabilidad)
 Prueba del rendimiento del sitio web al aumentar el volumen de datos en
la base de datos (Prueba de volumen)
 Prueba del rendimiento del sitio web cuando múltiples usuarios inician
sesión en él. (Prueba de concurrencia)
 Probar el comportamiento de su sitio cuando la carga de trabajo
adicional se da continuamente (Pruebas de resistencia)
 Prueba de velocidad de carga de página

Herramientas útiles para los diferentes tipos de pruebas de

rendimiento: Apache JMeter, HP LoadRunner, Ejecutante de seda de Micro
Focus, WebLOAD, y Gatling.
¿Desea saber más acerca de las mejores herramientas de prueba web para
evaluar el rendimiento de su sitio? Ir a este enlace

Pruebas de seguridad

Pruebas de seguridad se realiza para verificar que el sistema de información

protege los datos y mantiene la funcionalidad según lo previsto.

Puede simular el ataque de origen malicioso para evaluar el nivel de seguridad

de su sitio (Penetración pruebas).

Otro tipo de pruebas de seguridad, Pruebas de vulnerabilidad, permite

evaluar el monto total de los riesgos involucrados.

Algunas verificaciones para las pruebas de seguridad:

172
  Asegúrese de que el acceso no autorizado a páginas seguras no sea
posible
 Verifique que las sesiones se eliminen automáticamente después de una
inactividad prolongada del usuario
 Probar las funciones de seguridad SSL
 Todos los intentos de romper, informar errores, etc. deben registrarse y
almacenarse en un archivo separado para su posterior análisis.
 Verifica el trabajo de captcha usando scripts automáticos.
 Asegúrese de que los archivos restringidos no se puedan descargar sin
el acceso adecuado
 Asegúrese de que no haya capacidad de inicio de sesión al ingresar la
contraseña o el nombre de usuario incorrectos

Puedes usar herramientas como Retina CS Community, OWASP Zed Attack

Proxy, Veracode, Google Nogotofail, y Mapa SQLpara las pruebas de
seguridad de su sitio.

Siga este enlace para saber más sobre las pruebas de seguridad
– https://geteasyqa.com/qa/software-testing-types/

Pruebas relacionadas con el cambio

Pruebas relacionadas con el cambio tiene dos propósitos principales:

 Asegurarse de que todos los errores detectados se han solucionado con

éxito (Re-prueba o prueba de confirmación). En pocas palabras, debe
ejecutar los casos de prueba que originalmente detectaron los errores
nuevamente y esta vez pasan sin ningún problema.
 Asegurando que no han aparecido nuevos defectos después de los
cambios. (Pruebas de regresión).Además de los casos de prueba de
errores detectados, también contiene casos de prueba que verifican
todas las funcionalidades de su sitio.

Selenio, HP Quick Test Professional,TestComplete, Prueba de

conducción, SoapUI t Los ools se utilizan a menudo para pruebas
relacionadas con el cambio.

Aquí puede obtener más información sobre las pruebas relacionadas con el
cambio – https://geteasyqa.com/qa/software-testing-types/

Pruebas amigables para móviles

Como ha leído antes, algunas de las verificaciones del sitio web se referían a la
versión móvil de su sitio. Hoy en día, la cantidad de personas que usan solo
dispositivos móviles para el acceso a Internet tiende a aumentar de manera
estable. Por eso es muy importante asegurarse de que el sitio web sea
compatible con dispositivos móviles.

Aquí hay algunos consejos para probar su sitio web en el móvil:

173
  Verificar la compatibilidad con teléfonos inteligentes y tabletas.
 Asegúrate de que la navegación del sitio sea lo más sencilla posible.
 Optimiza el tiempo de carga de tu sitio.
 Asegúrese de que los botones sean lo suficientemente grandes para las
personas con dedos grandes
 Optimizar el tamaño de todas las imágenes
 No uses Flash y ventanas emergentes
 Usa viñetas y oraciones cortas.
 Asegúrese de que su número de teléfono esté a un clic de distancia de
ser marcado
 Verifique que el sitio web pueda acceder a su ubicación a través de GPS

Herramientas útiles para pruebas amigables para

móviles: BrowserStack, Perfecto Mobile Laboratorio de Calidad
Continua, Emulador de Windows Phone, Emulador de Android
Studio, Page Speed de Google en línea etc.

Aquí puedes leer cómo probar tu sitio en el móvil

– https://geteasyqa.com/qa/test-website-mobile/

Prueba beta

Prueba beta – La etapa final de la prueba preliminar. Como regla general, es

realizado por usuarios finales y por personas.

Las pruebas beta reemplazan su sitio en manos de usuarios reales fuera de su

equipo para descubrir puntos débiles desde la perspectiva del usuario que no
querría tener en su versión final de la aplicación.

Herramientas como HockeyApp, Ubertesters, y Vuelo de prueba son las

plataformas utilizadas en todo el mundo para pruebas beta.

Ahora, cuando hemos considerado las fases principales del proceso de prueba
del sitio web, tratemos de encontrar el error y reportarlo con una de las
herramientas de prueba web real, EasyQA Chrome Extension.

Cómo probar su sitio web con EasyQA Chrome Extension

EasyQA Chrome Extension le permite crear un informe de error desde su sitio

web o la aplicación web, sin perder tiempo en enviar la información puede
ayudarlo a comenzar a procesar y corregir el error pronto.

Es realmente sencillo usar EasyQA Chrome Extension para trabajar con

errores.

Las únicas cosas que necesitas hacer son:

 Generar el token para tu proyecto

 Instale EasyQA Chrome Extension en su navegador

174
  Inicia sesión (solo si lo deseas).

¿Qué ES UN PLAN DE QA?

En el ámbito del desarrollo de software, la sigla QA significa Quality Assurance, o

aseguramiento de la calidad. Se trata de un conjunto de actividades de evaluación
de las distintas etapas del proceso de desarrollo para garantizar que el producto
final sea de calidad. El concepto de calidad se presta a múltiples interpretaciones,
pero siempre implica que el software satisfaga las necesidades del cliente.
Más allá de las diferencias, un buen plan de QA no puede desconocer la
importancia de los estándares. Con esto nos referimos a reglas escritas y no
ambiguas sobre los objetivos del producto, las metodologías de diseño y a seguir y
convenciones necesarias para guiar la tarea de los programadores (estilos de
codificación, estructuras de datos, etc.).
El plan de QA atraviesa el proceso de desarrollo desde el nacimiento de la idea
hasta la implementación del software.  En las primeras etapas, verifica que los
objetivos estén bien planteados y los requerimientos sean precisos. En las fases de
diseño y codificación, vigila el cumplimiento de los estándares fijados. Finalmente,
revisa que el software en funcionamiento respete los requerimientos pedidos y que
la entrega al cliente se haga en las condiciones adecuadas.
El QA se basa en conjunto de pruebas de calidad entre las que se incluyen:

 Testeo unitario: se prueba que cada módulo funcione bien por separado.
 Prueba de stress: se prueba la resistencia de la aplicación enviándole una
cantidad de peticiones excesiva, buscando que colapse.
 Test de integración: los módulos probados independientemente durante el
testeo unitario se acoplan y se prueban en conjunto.
 Test funcional: se prueba que el software ofrezca las funciones solicitadas.
 Test de aceptación: el usuario verifica que el producto satisfaga sus
expectativas.
Las pruebas de QA no sólo son beneficiosas para el usuario final, que recibirá un
producto de calidad, sino también para el equipo de desarrollo, que al establecer un
control permanente sobre el proceso evitará en buena medida los costos de tener
que corregir errores en etapas avanzadas del proyecto.

QA al Crear una app: testeo y validación del proyecto

175
QA es la etapa donde se deben revisar mediante diversos testings el
resultado de la app que se ha creado. Se llevan a cabo un conjunto de
actividades sirven como control de calidad de lo obtenido.
Para los Clientes: Qué buscar en un profesional de QA y por qué deben
realizar este proceso.

En general y para cualquier proyecto de una índole más técnica, se deben

buscar profesionales calificados para el trabajo o que tengan experiencia previa
en el desarrollo de aplicaciones IT. Es por lo anterior que el sistema
de referencias de Workana permite al usuario verificar calificaciones de otros
clientes que ya han contratado al profesional y su experiencia durante el
proyecto.

Primero establecemos el conducto regular amplio de un proyecto genérico IT

Desarrollo -> Quality Assurance -> Producción

Este “control de calidad” permite:

 Verificar: Debe cumplir con los requerimientos planteados en el

levantamiento de requisitos (Alcance del proyecto), ya que es el primer
margen que debe cumplir una app , que la app haga lo que se pidió.
 Evitar problemas del usuario: Puede que debido a problemas
de usabilidad el usuario desestime su uso ya que no cumple con sus
expectativas.
 Reducir costos: A nivel de costos, detectar una problemática en la
etapa de producción suele ser mucho más costoso y con mayor impacto
negativo que si se detectara previamente.
 Rectificar: Si el levantamiento de requisitos no fue el más apropiado, en
esta etapa, las funcionalidades de la app revelarán estos problemas.

Para los freelancer: Enfoques base del QA , en qué se deben fijar

 Testear siempre en ambientes similares a los que se enfrentará la app

en producción, ya que muchas veces se desestima esta variable y
puede traer problemas en etapas posteriores. En este sentido existen
diversos parámetros que permiten evaluar el ambiente como, por
ejemplo: Pruebas funcionales, test de stress, pentesting, entre otras.
 ¡Seguridad! Otro punto importante es el nivel de seguridad de tu app, ya
que en muchas ocasiones las apps manejan información del usuario, por
lo que son blanco de ataque a considerar.
 DOCUMENTA. Muchos pasamos por ese momento tedioso en que
tenemos que resumir el control de cambios realizados y el nuevo código
que generamos, pero es un proceso fundamental que puedes entregarlo
como un plus en tu proyecto, ya que en caso de incidentes tu cliente lo
agradecerá.

Omar Leonardini, freelancer de IT y Programación en Workana.

176
Te recomendamos:

 Definir el alcance del proyecto. 

 Encontrar a un buen diseñador de UI/UX: acá tienes un listado con los
mejores freelancers.
 Ingresar a esta herramienta online para ayudarte a saber qué más
necesitas para crear tu app.

Para comenzar a trabajar de forma independiente, mira los proyectos

publicados en Workana y postúlate. O también puedes emprender: crea un
proyecto en Workana y contrata freelancers que te ayuden a desarrollarlo.

TÉCNICAS DE TESTEO DE SOFTWARE 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.

177
 

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,
Ava y TestNG, Powermock, XCTest

2. Pruebas de integración

La prueba de integración es una extensión lógica de las pruebas unitarias. Dos

unidades que ya han sido testeadas y combinadas en un componente y su
interface son testeadas entre ellas. Un componente, en este ejemplo, se refiere
a un agregado que está integrado en más de una unidad, estas son
combinadas en componentes, que son agregadas por orden en partes 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

178
 

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

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

16 HERRAMIENTAS OPEN SOURCE PARA TESTERS

Creado porGustavo Terrera
/
Comentarios0
Sin lugar a dudas, cada vez más necesitamos utilizar herramientas para
mejorar el Testing de nuestros proyectos. La mejora pasa tanto por lo operativo
como por lo económico.

Ahora bien, habiendo distintos tipos de Testing nos enfrentamos con distintos
desafíos al tener que utilizar herramientas específicas que atiendan a los
mismos.

Algunas de ellas tienen una curva de aprendizaje corta, es decir que el tester
no demora mucho en comprender su alcance, sus funciones y su aplicabilidad.

De hecho sirve y de mucho, explorar las distintas herramientas q permiten

gestionar de manera integral el Testing.

180
En la sección Tutoriales  podrás encontrar vídeos q muestran el uso de
distintas herramientas, producto de trabajos realizados por distintos equipos y
personas, que han pasado por el curso Intensivo Manual Testing
Click Aquí

No obstante, para la gestión operativa en el día a día, cierto es q necesitamos

de varias herramientas para cumplimentar cada uno de los procedimientos
definidos en un proyecto.

Otras en cambio, requieren de cierto conocimiento técnico, y eso se consigue

estudiando, explorando, practicando y equivocándose para aprender de los
errores que se cometan. Ejemplo de este tipo de situaciones lo tenemos con
las herramientas para automatizar pruebas donde el tester debe tener
necesariamente cierto conocimiento en programación.

Considerando lo escrito hasta ahora, el framework deberá soportar la

instalación, configuración, integración y evolución de las herramientas que se
necesiten con la debida administración de las mismas, ya que serán ambientes
que deberán mantenerse.

Sin lugar a dudas, el armado del framework es un proyecto en si mismo q

deberá seguirse y controlarse, adecuando la necesidad de Testing q tengamos
con la herramienta o herramientas apropiadas.

Por otro lado, como no estamos aislados, deberemos organizar y coordinar

acciones con el área de desarrollo a los efectos de estar alineados.

Podemos pensar incluso, en que nuestra propuesta por una nueva herramienta
o nuevo framework permitirá q también el área de desarrollo acepte su
incorporación para traccionar con la misma.

En muchas organizaciones, el área de Testing depende del área de Desarrollo,

mientras q en otras, trabajan en conjunto y de manera colaborativa.

Demás está decir, que deberemos contar con un equipo multidisciplinario de

testers con distintos perfiles técnicos q sepan no solo manejar las herramientas
sino además, interpretar resultados para elaborar los correspondientes reportes
de avance.

A continuación, te dejo el listado de las herramientas q desde el sitio web

testing-whiz.com recomiendan y q vale la pena analizar y hasta incluso
probarlas.

Podrán ver q hay más de un bugtracker y ésto tiene q ver con las
particularidades q presente cada instalación.

181
En lo personal, durante el año estaré explorándolas para publicar el resultado
de la evaluación q haga en nuestra sección Tutoriales, donde podrás encontrar
las grabaciones q han hecho los distintos grupos o personas q han pasado por
el curso Intensivo Manual Testing.

CURSO ONLINE INTENSIVO MANUAL TESTING

CRONOGRAMA MARZO 2017
Clase 1: Lunes 6
Clase 2: Miércoles 8
Clase 3: Viernes 10
Clase 4: Lunes 13
Clase 5: Miércoles 15
Clase 6: Viernes 17
Clase 7: Lunes 20
HORARIO
7:00 pm a 9:00 pm
(GMT-03:00)
(19:00hs a 21:00hs)
 

En el curso online, además de tratar los aspectos teóricos más importantes, se

ejercita con herramientas open source y aranceladas para comprender su
manejo y la forma en la que se pasa de la teoría a la práctica.
 

Para más info, click aquí

https://testingbaires.com/16-herramientas-open-source-testers/
 

Listado de herramientas

1. Selenium (Web Application Testing)

2. Appium (Mobile Testing)
3. JMeter (Load Testing)
4. Jenkins (Continuous Testing)
5. TestLink (Test Management)
6. Mantis (Bug-Tracking & Project Management)
7. Postman (API Testing)
8. Firebug / Firepath (Online Debugging)
9. GitHub (Project & Source Code Hosting)
10. Bugzilla (Defect Tracking & Collaboration)
11. RazorSQL (Database Query Tool)
12. PhantomJS (Headless Browser)
13. UIAutomator (Android Testing Framework)
14. Notepad++ (Source code Editor)
15. FileZilla (FTP Solution)
182
 16. AutoIT (Language Automation)
 

Selenium

Selenium es uno de los frameworks más utilizados para probar aplicaciones

web, principalmente para la interfaz web y las pruebas funcionales. Viene con
una serie de herramientas como Selenium IDE, Selenium RC, Selenium
WebDriver y Selenium Grid que ofrece diferentes soluciones para atender
diferentes requisitos de automatización de pruebas.

Referencias
http://www.seleniumhq.org/projects/webdriver/
 

Appium

Appium es un framework de automatización de pruebas para probar

aplicaciones web nativas, híbridas y móviles para plataformas iOS, Android y
Windows en dispositivos reales y simuladores. Dado que soporta aplicaciones
multiplataforma, permite probar aplicaciones en diferentes plataformas
utilizando la misma API. Appium permite a los usuarios elegir el idioma que
tiene las bibliotecas de clientes de Selenium como Java, Objective-C,
JavaScript con Node.js, PHP, Ruby, Python, C # etc. para crear pruebas.

Referencias
http://appium.io
 

JMeter

JMeter es una herramienta basada en Java diseñada para cargar el

comportamiento de la aplicación y medir el rendimiento del sitio web. Puede
probar recursos estáticos y dinámicos que incluyen servicios web SOAP /
REST, sitios web HTTP y HTTPS, bases de datos, FTP y servidores de correo,
así como PHP, ASP.NET y Java. Funciona simulando la carga en el servidor
para analizar el rendimiento general de la aplicación / sitio web bajo prueba.
 

Referencias
http://jmeter.apache.org
 

183
Jenkins

Jenkins es una herramienta para iniciar pruebas continuas y construir la

integración a través de la automatización. Proporciona una forma poderosa de
administrar los cambios de código, las pruebas y el ciclo de vida del
despliegue, junto con la administración de releases, acelerando el ciclo de vida
general del desarrollo del software. Hoy en día, Jenkins ofrece soporte para
más de 1.200 plugins que le permiten integrarse con cualquier tecnología.

Referencias
https://jenkins.io
 

Testlink

TestLink es una herramienta de gestión de pruebas basada en la web

ampliamente utilizada. Proporciona soporte para administrar y mantener casos
de prueba, conjuntos de pruebas, documentos de prueba y proyectos en un
solo lugar. Puede alojarse en un servidor e integrado con herramientas de
seguimiento de errores como Mantis, JIRA, Bugzilla, FogBugz, etc. para facilitar
el proceso de ejecución de pruebas. TestLink se puede utilizar tanto para
pruebas manuales como automatizadas.

Referencias
http://testlink.org

Acceso a la sección Tutoriales donde podrás encontrar vídeos q muestran el

uso no sólo de Testlink sino además de otras herramientas.
Click Aquí

Mantis

Mantis es una herramienta líder de seguimiento de errores utilizada por los

probadores para el seguimiento de errores encontrados en el software durante
el proceso de prueba. También proporciona funciones de gestión de proyectos
y administración de problemas que ayudan a lograr una colaboración más
rápida y efectiva entre equipos y clientes.
 

Referencias
184
https://www.mantisbt.org
 

Postman

Postman es una gran herramienta para probar APIs. Los probadores y

desarrolladores pueden utilizar esta herramienta gratuita como una extensión
de Chrome o un producto de colaboración en la nube para desarrollar, probar y
documentar las API más rápidamente. Permite a los usuarios comprobar el
historial de las solicitudes HTTP enviadas, personalizar secuencias de
comandos, autocompletar URL, previsualizar imágenes, realizar pruebas de
producción, organizar o configuraciones locales con una amplia gama de
características y funciones.
 

Referencias
www.getpostman.com
 

Firebug

Firebug es una extensión de navegador web que ayuda a los probadores en la

depuración, edición y supervisión en línea de CSS, HTML y JavaScript de la
aplicación web. Firebug junto con Firepath se utiliza para identificar XPath de
cualquier elemento. Tanto Firebug como Firepath pueden instalarse como una
extensión para Mozilla Firefox, mientras que Firebug Lite se puede agregar
como una extensión de Chrome que proporciona una rica presentación de
elementos HTML y DOM para la edición en directo.
 

Referencias
http://getfirebug.com
 

GitHub

GitHub es un servicio de repositorio basado en la web para alojar y administrar

proyectos de software, versiones y código fuente. Proporciona características
como edición en línea, ticketing, seguimiento de errores, administración de
tareas, así como funciones de redes sociales como feed, wikis, que ayudan a
millones de desarrolladores y probadores a trabajar de manera colaborativa.
Promueve el desarrollo rápido y flexible de proyectos con más de 14 millones
de usuarios y más de 35 millones de repositorios.
 

Referencias
https://github.com
 

185
Bugzilla

Bugzilla es otra herramienta de rastreo y prueba de defectos que es

ampliamente utilizada por los probadores para realizar un seguimiento de los
errores pendientes. Viene con una variedad de características tales como un
sistema integrado del email, gerencia avanzada de la pregunta, sistema de los
permisos, el sistema incorporado del informe así como los perfiles editable del
usuario para asegurar proceso de prueba liso y eficaz.
 

Referencias
https://www.bugzilla.org
 

Razor SQL

Razor SQL es una herramienta de SQL Query y Database Editor para

Windows, Mac OS y Linux. Permite a los probadores importar, exportar y
convertir bases de datos en varios formatos como MySQL, Oracle, DB2,
PostgreSQL, SQLite, MS SQL Server y MS Access. Con Razor SQL, los
usuarios también pueden explorar objetos de base de datos y realizar
comparaciones de bases de datos.
 

Referencias
https://razorsql.com
 

PhantomJS

PhantomJS es un navegador que se utiliza para automatizar las interacciones

de la página con fines de prueba. Ayuda a los usuarios a habilitar la navegación
y el comportamiento del usuario en una página sin cargar la interfaz gráfica.
PhantomJS imita y manipula una página web para llevar a cabo la
automatización de pruebas que en última instancia, ahorra una tremenda
cantidad de tiempo para los probadores.
 

Referencias
http://phantomjs.org
 

UIAutomator

UIAutomator es un marco para pruebas de interfaz de usuario funcional para

aplicaciones de Android. Permite a los probadores probar las aplicaciones de
Android creando múltiples casos de prueba que pueden ejecutarse en varios
dispositivos con diferentes resoluciones. UIAutomator también puede utilizarse

186
para probar aplicaciones preinstaladas, como Ajustes del teléfono, así como
aplicaciones de terceros.
 

Referencias
https://google.github.io/android-testing-support-library/docs/uiautomator/
 

Notepad++

Notepad ++ es un editor de texto que permite a los usuarios editar el código

fuente de 27 lenguajes de programación en entorno Windows. También soporta
resaltado de sintaxis y plegado, ediciones sincronizadas, zoom in y zoom out,
vistas múltiples, marcadores, grabación de macros y reproducción junto con
GUI personalizable.
 

Referencias
https://notepad-plus-plus.org
 

FileZilla

FileZilla es una aplicación FTP multiplataforma para clientes y servidores.

Permite a los usuarios cargar y descargar archivos desde y hacia su sitio FTP,
así como realizar múltiples transferencias de archivos y navegación
simultáneamente. FileZilla ayuda a transferir en FTP, SFTP, FTP cifrado como
FTPS y SFTP. También incluye un administrador de sitio que puede almacenar
todos los detalles de la conexión en una interfaz tipo Explorer.
 

Referencias
https://filezilla-project.org
 

AutoIT

AutoIT es una herramienta para automatizar la GUI de Windows y las

secuencias de comandos generales usando una combinación de pulsaciones
de teclas, movimiento del ratón y manipulación de ventana / control. Se utiliza
para automatizar tareas que son difíciles de realizar con ciertos idiomas. Es
muy utilizado por los probadores para crear scripts de automatización para el
entorno de Windows.

187
Kubernetes vs Docker: ¿En que se diferencian?

Hace poco surgió el Tutorial Kubernetes en Español, el cual lanzamos la

semana pasada, y hoy siguiendo esos pasos vamos a comenzar a aclarar una
de las dudas más comunes al momento de trabajar con contenedores.
Tanto Kubernetes y Docker puede parecer lo mismo a primera vista, ambos
permiten hacer cosas similares como el permitir ejecutar contenedores, sin
embargo ambos trabajan en capas diferentes de la infraestructura Cloud y mas
que competidores en realidad son dos socios que pueden trabajar muy bien
juntos.
Muchas veces escuchamos hablar de Kubernetes vs Docker, o incluso hay
muchos tutoriales que hablan de uno y otro como si fueran algo diferente y que
compiten entre si en cuanto a funcionalidades, cuando en realidad son
complementos que trabajan juntos.
Repasemos ahora las funciones de cada uno, y aprendamos más abajo para
qué sirve Kubernetes cuando usamos Docker.

¿QUÉ ES UN CONTENEDOR?
Un contenedor es un paquete cerrado que contiene todo lo necesario para que
una aplicación o un servicio que se ejecute encapsulado dentro de una sola
imagen completamente independiente el servidor anfitrión que lo aloje, incluye
tanto binarios como archivos de configuración y demás ficheros que necesite.
La idea detrás de esto es que sea ligeros y portables, que se pueda transferir
entre diferentes entornos sin contratiempos ya que el funcionamiento interno es
completamente independiente del sistema operativo que lo aloja.

¿UN CONTENEDOR ES ENTONCES UNA MAQUINA VIRTUAL?

Es bastante similar a una maquina virtual y podemos verlo de esa manera sin
embargo la filosofía es un poco diferente (lo vimos antes en el artículo Docker
vs Máquinas Virtuales), en una maquina virtual se virtualiza todo el servidor,
incluido el sistema operativo completo, mientras que en un contenedor solo
contiene los ficheros necesarios.
Ejemplo de esto puede ser un contenedor que empaqueta solamente la
aplicación desarrollada en Node.JS y las dependencias que necesite, nada
mas, esto hace que el contenedor sea mas liviano y que que el inicio sea de
apenas segundos, en contraposición a una maquina virtual que puede llevar
varios minutos en iniciar.

En una maquina virtual tenemos que instalar el sistema operativo, configurar

todo lo necesario, instalar nuestra aplicación junto a una larga lista de tareas
para poner a punto el sistema, algo que puede llevar horas realmente
dependiendo de nuestros propósitos, mientras que la construcción de un
contenedor en Docker por ejemplo lleva considerablemente menos tiempo.
El hecho de que un contenedor no virtualize un sistema operativo completo
hace que el uso de contenedores sea mucho mas eficiente en cuestión
consumo de recursos de hardware que las maquinas virtuales tradicionales.

¿QUÉ ES DOCKER?

188
Básicamente Docker es un sistema que nos permite construir, transferir,
desplegar y ejecutar los contenedores con nuestras aplicaciones dentro de una
manera muy sencilla y confiable, garantizando un despliegue escalable de
forma eficiente sin importar el sistema operativo anfitrión.
Con Docker podemos tener este grado de certeza y confianza en cuanto a
compatibilidad entre equipos porque todo lo que necesita nuestra aplicación
junto las librerias y demás dependencias se encuentran encapsuladas dentro
del mismo contenedor, lo que nos garantiza que el contenedor se ejecutara de
la misma forma en cualquier equipo o servidor.

¿QUÉ ES KUBERNETES?
Si bien Docker mismo permite ejecutar los contenedores creados y las
herramientas de gestión que nos provee  pueden ser suficientes para gestionar
un solo servidor, resultan muy poco practicas de utilizar a gran escala  para
montar una infraestructura distribuida de múltiples contenedores corriendo en
tal vez  docenas o cientos de servidores al mismo tiempo.

Para esto se necesita un sistema que se encargue de gestionar todo el cluster

de servidores, eso significa un sistema que se encargue de distribuir los
contenedores a través del sistema según los recursos disponibles en el cluster,
ademas de crear, ejecutar, vigilar, medir, destruir y relanzar los contenedores,
debe mantener y controlar en todo momento cada aspecto relevante de los
contenedores y su estado, de todo eso y mas se encarga Kubernetes.
El desarrollo de Kubernetes esta basando en la experiencia previa de sus
programadores en un proyecto interno de Google llamado Borg, que por su
estructura y filosofía de división del trabajo se asemeja al colectivo Borg de Star
Trek, por esa razón no es casualidad que su nombre clave para Kubernetes en
su comienzo era Project Seven

Este nombre de Project Seven es un guiño al proyecto original de Google por

ser una referencia a un personaje llamado Seven of Nine, nombre que es una
denominación Borg dentro del universo Star Trek que luego con el tiempo y el
correr de los capítulos simplificaron como Seven en la serie Star Trek Voyager
para ser mas precisos.
Con este nombre pretendieron indicar que al igual que en la serie, el nuevo
proyecto Seven era una versión mas amigable que el proyecto Borg original,
posteriormente adopto como nombre final Kunernetes que tiene su origen el
idioma griego y cuya traducción significa timonel o piloto, por lo que su logo es
una rueda de timón de barco y que ademas tiene siete puntas en alusión a
Seven, su nombre en código original.

KUBERNETES Y DOCKER: ¿POR QUE UTILIZARLOS?

La ventaja de los servicios en la la nube son varios, desde el punto de vista
técnico la nube tiene la gran ventaja de ser elástica, permite crecer e decrecer
en recursos según las necesidades de computo casi al instante, eso nos
asegura poder acompañar el crecimiento de la carga de trabajo aumentando
los recursos y volver a decrecer cuando ya no lo necesitemos.

189
De esta forma permite no tener recursos ociosos que cuestan dinero, por lo que
solo pagamos por lo que usamos, en ese sentido el Cloud Hosting es mas
rentable que las soluciones tradicionales.
Si bien Kubernetes soporta varios tipos de contenedores diferentes el mas
común y popular es Docker, en esta sociedad perfecta que forman ambos,
Docker es el que se encarga de crear las imágenes y los contenedores que se
van a utilizar y Kubernetes se encarga de gestionar todo.

Ambos tienen la ventaja de ser de código abierto, esto es una ventaja no solo
por un tema económico, sino que lo fundamental de este punto es que al ser
open-source nos da la opción de adaptarlo a nuestras necesidades con libertad
sin estar atado a las limitaciones de una licencia y a las limitaciones técnicas
que muchas veces enfrentamos con un producto cerrado.

Tampoco olvidar que detrás de estos dos productos hay una amplia comunidad
que nos asegura respaldo técnico, ademas las empresas desaparecen y con
ellas sus productos pero los proyectos de codigo abierto normalmente no
mueren, solo se transforman, esto es otra ventaja ya que nos ofrece proyección
de futuro a mediano y largo plazo.

Esperamos que tras estas explicaciones ya hayan quedado claras las

diferencias entre Kubernetes vs Docker.

Si has oído hablar de Gherkin pero no sabes en qué consiste, te explicamos qué
es y las ventajas que hacen que sea un lenguaje para todos, por lo que es el
lenguaje empleado en BDD.

Por qué es necesario Gherkin

Habitualmente los proyectos tienen dos tipos de perfiles:

  

Perfiles de negocio , que entienden poco de tecnología, pero saben

mucho de retorno de inversión, de funcionalidades, de requisitos, etc.

  

Perfiles tecnológicos , que saben mucho de tecnología, pero conocen

poco del negocio habitualmente.

Hay entornos donde es muy importante que haya mucha cohesión entre esos
perfiles, por lo que es vital tener un lenguaje común que entiendan estos dos
perfiles, incluso que entiendan las máquinas.

Este lenguaje se llama Gherkin, y que sirve para acercar estos dos mundos.

Qué es Gherkin
190
Gherkin es un DSL o Lenguaje Específico de Dominio (Domain-Specific
Languaje), es decir, un lenguaje que está creado para resolver un problema.

Tiene una estructura generada por varios elementos, como vemos en la siguiente
imagen.

Estos elementos nos ayudan a que todos esos comportamientos vayan poco a
poco bajando de nivel, hasta llegar a un lenguaje que entiendan fácilmente los
desarrolladores.

Los elementos más utilizados habitualmente

son Feature , Scenario , Example , Scenario
Outline , Given , When , Then y And . El resto son un poco más desconocidos en
general o bien que se han publicado recientemente.

Ejemplo básico de Gherkin

Veamos un ejemplo muy sencillo de Gherkin.

En el mismo tenemos una Feature, dónde después poco a poco va aterrizando

a Scenarios .

Después eso aterriza en algo mucho más palpable, qué es lo que todos
entendemos como acciones, como puede ser seleccionar un curso nuevo o
arrancar el curso dado un usuario, que están mucho más relacionado con
pruebas de aceptación.

Automatiza las tareas de desarrollo e integración continua con Jenkins

Dentro de las herramientas para desarrolladores, hoy nos centramos en
el software de automatización Jenkins, que sirve de motor para automatizar
las tareas en gran parte del flujo de trabajo de un proyecto, por lo que resulta
especialmente útil en los equipos técnicos que quieren agilizar las tareas de
desarrollo de cara a los procesos de integración continua.
Como servidor de automatización, Jenkins permite que una máquina realice
numerosas tareas a las que los humanos destinamos demasiado tiempo en
demasiadas ocasiones. Para esto, encontramos en Jenkins centenas de
plugins hechos por la comunidad, que se pueden integrar en varias etapas del
proceso de desarrollo. Aunque podríamos hacer con él todo tipo de tareas
automáticas, Jenkins se suele usar perfectamente como servidor de integración
continua. Escrito en Java y accesible mediante interfaz web, Jenkins es

191
multiplataforma y se ha consolidado últimamente como una de las herramientas
más usadas en la actualidad para realizar las tareas de integración continua.

¿En qué consiste la integración continua?

La integración continua es una práctica habitual en el mundo del desarrollo

actual, usada principalmente por equipos de desarrollo que han adoptado
metodologías ágiles de trabajo. Básicamente, consiste en un proceso por el
cual cualquier pequeña mejora en el software se integra rápidamente con el
software que se llevará producción. Cualquier mejora, debidamente probada,
es integrada en los repositorios de control de versiones, junto con las mejoras
producidas por otros desarrolladores del equipo de trabajo. En la práctica,
mediante la integración continua es posible llegar a crear diferentes versiones
de un sofware diariamente o intradía. La integración continua es un proceso
habitual en empresas de desarrollo avanzadas y startups tecnológicas,
preocupadas por llevar cuanto antes valor a los clientes finales.

Jenkins e integración continua

Los desarrolladores y gestores de proyecto saben que llevar a producción un

software o una nueva versión es una tarea delicada. Para que sea posible, es
fundamental contar con algún sistema de automatización, que sea capaz de
construir el software, o desplegarlo en servidores, pero que sólo permita esa
puesta en producción cuando el software ha sido probado convenientemente.
En este punto es donde entra Jenkins, como sistema de automatización, capaz
de realizar cientos de tareas necesarias para asegurar la calidad del software y
facilitar su despliegue o construcción. Algunas de las tareas más habituales
que Jenkins es capaz de hacer son las siguientes:
o Testar el software.
o Revisar las métricas de calidad del software establecidas por el equipo
de trabajo.
o Enviar las modificaciones del software, una vez pasadas todas las
validaciones, al repositorio principal.
o Automatizar la compilación del software o su despliegue, una vez se
hayan integrado nuevos cambios en el proyecto.
o Notificar debidamente a los desarrolladores o al equipo de
aseguramiento de la calidad cuando se encuentra cualquier tipo de error, ya

192
 sea en base a las pruebas del software o a las métricas de calidad
definidas.
o Generar o visualizar la documentación de un proyecto
Como servidor de automatización, además, Jenkins es capaz de extender sus
funcionalidades con centenares de plugins para realizar un sin fin de tareas
útiles.

El mundo de la programación se encuentra en constante avance, y a parte de

nosotros actualizarnos dia a día para ser mejores programadores o
administradores, los builds también necesitan actualizarse constantemente.

Es aquí donde Gradle toma protagonismo, si aún no conoces qué es, cuáles son
sus ventajas y algunos complementos que serán de gran ayuda te invitamos a
que continúes leyendo este artículo y sigas aprendiendo sobre esta herramienta.

¿QUÉ ES GRADLE?

Gradle, es una herramienta que permite la automatización de compilación de

código abierto, la cual se encuentra centrada en la flexibilidad y el rendimiento.
Los scripts de compilación de Gradle se escriben utilizando Groovy o Kotlin DSL
(Domain Specific Language) .

Gradle tiene una gran flexibilidad y nos deja hacer usos otros lenguajes y
no solo de Java , también cuenta con un sistema de gestión de dependencias
muy estable. Gradle es altamente personalizable y rápido ya que completa las
tareas de forma rápida y precisa reutilizando las salidas de las ejecuciones
anteriores, sólo procesar las entradas que presentan cambios en paralelo.

Además es el sistema de compilación oficial para Android y cuenta con

soporte para diversas tecnologías y lenguajes.

193
CARACTERÍSTICAS

Algunas características de Gradle que podemos destacar son las siguientes:

  Depuración colaborativa: Permite compartir los resultados de la

compilación para resolver en equipo de forma eficiente posibles problemas
que aparezcan.
  Construcción incremental: Valida en el proceso de compilación si la
entrada, salida o implementación de una tarea ha cambiado, en caso de
no existir algún cambio la considera actualizada y no se ejecuta.
  Diseño de repositorio personalizado: Podremos tratar prácticamente
cualquier estructura de directorios del sistema de archivos como un
repositorio de Artifacts.
  Dependencias transitivas: Es uno de los principales beneficios que
ofrece al utilizar la gestión de dependencias ya que se encarga de
descargar y administrar las dependencias transitivas.
  Soporte a Groovy y Scala incorporado: Compatibilidad con los
proyectos de Groovy, permitiendo trabajar con código Groovy o código
Scala e inclusive desarrollar código mixto Java y Groovy o Java y Scala.
  Compilación incremental para Java: En caso de que el código fuente o
la ruta de clase cambien, Gradle cuenta con la capacidad para detectar
todas las clases que se vean afectadas por dicho cambio y procederá a
recompilarlas.
  Embalaje y distribución de JAR, WAR y EAR: Cuenta con
herramientas para empaquetar el código basado en JVM (Java Virtual
Machine) en archivos de archivo comunes.
  Integración con Android Studio: Android Studio no cuenta con un
generador interno, sino que delega todas las tareas de compilación en
Gradle, garantizando la corrección en todas las construcciones, ya sea
que se ejecuten desde Android Studio, la línea de comandos o un servidor
de construcción de integración continua.
  Soporte de MS Visual C ++ y GoogleTest: Gradle acepta la
construcción con el compilador de Visual C de Microsoft en Windows. (VS
2010, VS 2013 y VS 2015 compatibles), así como también realizar
pruebas de aplicaciones C con GoogleTest.
  Publicar en repositorios Ivy y Maven: Permite publicar Artifacts en
repositorios Ivy con diseños de directorios completamente personalizables.
De igual modo, sucede con Maven en Bintray o Maven Central.
  TestKit para pruebas funcionales: Permite la ejecución prágramática de
builds inspeccionando los resultados de compilación, ésta es una prueba
de compatibilidad entre versiones.
  Distribuciones personalizadas: En Gradle cada distribución cuenta con
un directorio init.d en el que se pueden colocar scripts personalizados que
pre configuran su entorno de compilación.
  Lee el formato POM: Es compatible con el formato de metadatos POM,
por lo que es posible recuperar dependencias de cualquier repositorio
compatible con Maven.

194
   Compara builds: Resalta de forma rápida las diferencias entre
compilaciones, lo que hace que el análisis de la causa raíz sea mucho
más rápido y eficaz.
  Compilador daemon: Gradle crea un proceso de daemon que se
reutiliza dentro de una compilación de múltiples proyectos, cuando
necesita bifurcar el proceso de compilación, mejorando la velocidad de
compilación.
  Personalizar y extender escaneos: Ofrece la opción de agregar sus
propios datos para construir escaneos como etiquetas, valores y enlaces,
integrando escaneos de compilación en la cadena de herramientas.
  Caché de dependencia de terceros: Las dependencias de repositorios
remotos se descargan y almacenan en caché localmente, las
compilaciones posteriores utilizan los artifacts almacenados en caché para
evitar el tráfico de red innecesario.

COMPLEMENTOS GRADLE

Gradle permite construir desde microservicios hasta aplicaciones móviles,

puede ser utilizado por pequeñas startups como por grandes empresas, ya
que ayuda a los equipos a desarrollar, automatizar y entregar software de
calidad en un menor tiempo (dependiendo de su complejidad y planificación
previa del proceso de desarrollo).

195
Esta herramienta cuenta con una gran variedad de complementos o
plugins que ayudan agilizar la construcción, entre los cuales destacamos los
siguientes:

  javamuc.gradle-semantic-build-versioning: Proporciona soporte para

vel ersionado semántico de las compilaciones, es fácil de usar y
configurar.
  io.freefair.maven-publish-war: Permite crear una publicación de
mavenWeb.
  io.freefair.maven-publish-java: Crea una publicación mavenJava.
  org.mozilla.rust-android-gradle.rust-android: Un complemento que
ayuda a construir bibliotecas Rust JNI con Cargo para su uso en proyectos
de Android.
  net.wooga.build-unity: Este complemento proporciona tareas para
exportar proyectos de plataforma desde los proyectos de Unity3D.
  de.db.vz.msintplugin: Este complemento nos permitirá ejecutar pruebas
de integración de microservicio con docker.
  com.bmuschko.docker-remote-api: Nos facilita la gestión de imágenes
y contenedores Docker.
  com.google.cloud.tools.jib: Crea un contenedor para tu aplicación Java.

Gradle cuenta con paquetes para ser implementado en cualquier plataforma su

gran versatilidad permite trabajar con monorepos o multirepositorios, modelando,
sistematizando y construyendo soluciones exitosas, de forma rápida y precisa.

¿Qué experiencias has tenido con Gradle? ¿Prefieres Maven?

Blog sobre Java EE

Estás aquí: Inicio / Java / Maven / ¿Qué es Gradle?

¿Qué es Gradle?

1 abril, 2015 Por Cecilio Álvarez Caules 16 comentarios

Poco a poco todo avanza en el mundo de la programación y uno de los campos

que siempre necesita de mejoras continuas es el mundo de la
automatización de builds (construcciones). Todos hemos manejado estos
años ant y maven para automatizar la construcción de proyectos lo máximo
posible. Poco a poco Gradle se esta haciendo hueco como nueva herramienta
para gestionar la automatización de los builds.

¿Qué es Gradle?

Gradle es una herramienta de automatización de la construcción de nuestro

código que bebe de las aportaciones que han realizado herramientas como ant

196
y maven pero intenta llevarlo todo un paso mas  allá. Para empezar se apoya
en Groovy y en un DSL (Domain Specific Language) para trabajar con un
lenguaje sencillo y claro a la hora de construir el build comparado con
Maven. Por otro lado dispone de una gran flexibilidad que permite trabajar con
ella utilizando otros lenguajes y no solo Java. Dispone por otro lado  de un
sistema de gestión de dependencias sólido.

Vamos a construir un ejemplo sencillo de Gradle. Para ello el primer paso será
instalarnos las herramientas de Gradle para eclipse a través del marketplace.

197
 

Realizada este primera operación podemos usar el entorno de eclipse para

generarnos un proyecto de Gradle.

198
 

Seleccionamos el proyecto de QuickStart y se construye el típico proyecto de

eclipse que contiene una estructura de carpetas tipo Maven.

199
Como podemos ver disponemos de un fichero build.gradle que es el
encargado de gestionar el build y que mostramos su código a continuación.

Como podemos ver se trata de un DSL (Domain Specified Language) que es

bastante compacto. En las primeras lineas registramos tres plugins que nos
permitirán abordar diversas tareas.

Java Plugin: Se encarga de poner a nuestra disposición tareas del mundo java
como por ejemplo la tarea “jar” de empaquetado que usamos en la linea 13.

Eclipse Plugin :Se encarga de integrar gradle dentro de eclipse y configurar

un classpath basado en las dependencias que asignamos en la linea 24

Application Plugin: Se encarga de añadir las tareas de ejecución de tal forma

que desde el propio gradle podamos ejecutar nuestro proyecto definiendo en la
linea 11 la clase main.

Una vez tenemos definido el fichero podemos ver el contenido de la clase

Principal que deseamos ejecutar.

200
 1. package com.arquitecturajava;
2.
3. import org.apache.logging.log4j.LogManager;
4. import org.apache.logging.log4j.Logger;
5.
6. public class Principal {
7. private static final Logger logger = LogManager.getLogger();
8.
9. public static void main(String[] args) {
10. logger.error("hola, mundo");
11. }
12. }
En este caso se trata de una clase que usa el API de log4j (versión2) para
imprimir un mensaje de error. Para ello deberemos definir en la carpeta de
resources el fichero log4j2.xml que nos configura el appender de consola.

1. <?xml version="1.0" encoding="UTF-8"?>

2. <Configuration status="WARN">
3. <Appenders>
4. <Console name="Console" target="SYSTEM_OUT">
5. <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level
%logger{36} - %msg%n" />
6. </Console>
7. </Appenders>
8. <Loggers>
9. <Root level="error">
10. <AppenderRef ref="Console" />
11. </Root>
12. </Loggers>
13. </Configuration>
Realizados estos pasos ya tenemos un mini proyecto y podemos usar gradle  y
su tarea build para construir nuestro código y generar un jar.

201
Realizada esta operación gradle nos generará un jar con el proyecto
preparado.

De igual forma podríamos haber ejecutado la tarea :run y que gradle nos

ejecutara el proyecto.

202