DESARROLLO DE SOFTWARE

La construcción de software es un proceso colaborativo en el cual intervienen diversos actores.

Las personas conciben ideas a partir de una necesidad específica o de su creatividad.
Transmiten lo deseado, de alguna forma, a otras personas, los desarrolladores. A partir de su
interpretación de lo requerido, se construye el software. O sea, existe un dialogo entre seres
humanos, basado en el conocimiento que cada uno de ellos tiene y comparte con los demás.
También pueden participar organismos u otros productos de software que influyen en lo
deseado y lo requerido.

Los actores son personas u organizaciones afectadas por el éxito o fracaso de un proyecto, las
funcionalidades o carencias de un producto o los efectos de un servicio. En este diálogo los
actores.

1. Negocian expectativas
2. El producto les sugiere nuevas ideas.
3. Cometen errores.
4. Se reformulan las expectativas en base a riesgos identificados.

FUNCIONALIDADES

Una funcionalidad es una descripción de una acción o interacción de un usuario con el

software. Ejemplo, Imprimir un documento.

La descripción de una funcionalidad debe ser lo más simple posible. Debemos preguntarnos:
¿Qué necesita tener el software para que el usuario alcance su objetivo?

REQUERIMIENTOS

Para construir un software, los desarrolladores se basan en los requerimientos del cliente.
Esto es una necesidad o expectativa de un actor frente a un sistema de software. Estos
requerimientos pueden estar explícita o implícitamente declarados. Surgen de distintas
fuentes, como ejemplo.

1. Demandas del mercado.

2. Marco legal.

Tipos de requerimientos.

1. De diseño.
2. De arquitectura.
3. Funcionales.
4. De implementación o no funcionales.
5. De performance.
Son definidos, refinados y actualizados a medida que transcurre el desarrollo del proyecto del
software.

Los requerimientos se comunican al equipo de desarrollo. Puede ser mediante un documento

formal, llamado “Especificación de requerimientos”.

ESPECIFICACIONES

Se define como un “Documento de requerimientos”. Puede ser una especificación de

requerimientos funcionales del sistema, de diseño, de arquitectura, implementación, etc.

Por ejemplo, algunos de los requerimientos para Gmail.

1. Debemos contar con una interfaz en la cual se puedan escribir correos electrónicos y
luego enviarlos mediante un click.
2. También debemos contar con un sistema de seguridad y privacidad de la información.

La especificación de requerimientos describe detalladamente y con precisión las

funcionalidades y características del sistema.

Para el requerimiento 1, la especificación tendría que tener información detallada de la

interfaz gráfica y se podría describir la interacción del sistema y el usuario con un caso de uso,
en el cual se detallan las acciones del usuario y las respuestas del sistema, o con un diagrama
de interacción, podría hacerse en lenguaje UML.

El documento se va ajustando a medida que se analiza el requerimiento, se evalúa su relación

con otros requerimientos y se diseña el software.

Problemas a enfrentar por parte de los desarrolladores.

Se pueden presentar incongruencias entre especificación y requerimientos del producto.

También puede haber ambigüedades y carencia de precisión en el Documento de
requerimientos y/o en la Especificación de requerimientos.

1. Que la especificación no refleje los requerimientos.

2. El software no refleja los requerimientos ni las especificaciones.

Los requerimientos deben ser deseables, practicables y comprendidos.

Las tareas involucradas son.

1. Obtener
2. Negociar
3. Validar
4. Comunicar
5. Controlar
6. Explorar
Los requerimientos existen en la mente de todos los actores, por lo tanto el Documento de
requerimientos es un modelo de esa información, la cual permite gestionar el riesgo de crear
el software no deseado.

CALIDAD

Se define como la cualidad de un software de satisfacer las necesidades del usuario, éstas se
expresan mediante atributos de calidad y se clasifican en distintos factores medibles a través
de distintos indicadores.

La calidad implica un valor para algún actor, por lo tanto es inherentemente un concepto
subjetivo. Distintos actores pueden percibir distintos niveles de calidad en un mismo software.

Cada actor aporta su visión del software y por lo tanto de su calidad, veamos algunos atributos
de calidad.

Usuario final.

1. Cumplimiento de sus necesidades y/o expectativas.

2. Usabilidad.
3. Frecuencia e impacto de fallas.

Desarrollador.

1. Cantidad y tipos de defectos.

2. Facilidad de comprensión.
3. Facilidad de modificación.
4. Cumplimiento de los estándares de diseño y programación.

Responsable del negocio.

1. Retorno de la inversión.
2. Imagen de la Empresa.
3. Oportunidad en el Mercado.

Para el Tester es muy importante que el software sea testeable. Qué esté claro qué módulos
resuelven cuáles funcionalidades, así como la forma de integración de los distintos módulos o
componentes.

Pero el Tester también se ocupa de probar si se cumplen los objetivos o atributos de calidad
para los distintos actores, o sea, trabaja en combinación con todos.

El Tester investiga diferentes aspectos del software para los distintos involucrados, trata de
identificar y precisar los objetivos y atributos de calidad que están en juego, evidenciando los
conceptos implícitos, por ejemplo si se prevé o desea que una funcionalidad sea utilizada por
un número elevado de usuarios simultáneamente, es preciso indicarlo porque tiene un alto
impacto sobre su diseño y programación.
 MODELOS, ESTÁNDARES Y NORMAS DE CALIDAD.

En general se basan en la identificación de los atributos de calidad, sus factores y su manera de

medirlos. Otros autores ponen el foco en identificar los objetivos y luego ir generando el
conjunto de atributos para llegar a ese objetivo.

Las normas son guías para ayudar a lograr los estándares adoptados. En calidad de producto
de software la nueva norma es la ISO/IEC 25000, que proporciona una guía para el uso de las
nuevas series de estándares internacionales, llamados Requisitos de Calidad de Productos de
Software, (SQuaRE).

Constituyen una serie de normas basadas en la ISO/IEC 9126 y en la ISO 14598 (evaluación de
software), y su objetivo principal es guiar el desarrollo de software con la especificación y
evaluación de requisitos de calidad de software, su métrica y evaluación.

El siguiente diagrama representa el modelo de calidad interna o externa, se muestra un

conjunto de 6 características.

Calidad externa e interna

Funcionalidad Fiabilidad Usabilidad

Aplicabilidad Madurez Inteligibilidad
Precisión Tolerancia a fallos Aprendizaje fácil
Interoperabilidad Recuperación Operatividad
Seguridad Estética
Funcionalidad OK Fiabilidad OK Usabilidad OK

Eficiencia Mantenimiento Portabilidad

Comportamiento en el tiempo Analizabilidad Adaptabilidad
Utilización de recursos Cambiabilidad Instalación Fácil
Estabilidad Coexistencia
Pruebabilidad Intercambiabilidad
Eficiencia OK Mantenimiento OK Portabilidad OK

Al igual que la norma ISO/IEC 9126, este estándar define tres vistas diferenciadas en el estudio
de la calidad de un software: interna, externa y en uso. Estas vistas se relacionan entre sí,
ejemplo; la pobre calidad interna se refleja en la externa y en la de uso.

PASOS DE LA CONSTRUCCIÓN DEL SOFTWARE.

Este proceso se puede comparar a la construcción de una casa.

1. Concepción del proyecto.

2. Diseño del plano.
3. Arreglar el terreno y hacer revisión del suelo.
4. Comenzar con la cimentación.
 5. Edificar la estructura de la casa.
6. Paredes.
7. Instalaciones varias.
8. Techo.
9. Pintada del interior y de la fachada.

El software va evolucionando, desde la formulación de requerimientos, la especificación, el

diseño y la programación, hasta su transformación en un sistema más o menos complejo.

Construir software es una actividad tanto creativa como colaborativa. En el proceso vamos
explorando lo que creamos y lo vamos corrigiendo. Por ejemplo, se estudia cómo funcionan
las computadoras y se busca cómo hacerlas más eficientes, usando la imaginación y el ingenio.

Etapas:

1. Análisis y definición de requerimientos.

2. Diseño del Sistema.
3. Codificación.
4. Testing unitario.
5. De integración.
6. De Sistema.
7. Mantenimiento.

Análisis de requerimientos. Consiste en determinar qué desean los clientes y documentarlo.

Los Analistas trabajan con los clientes o analizan productos similares y formulan lo que se
considera interesante para algún actor del proyecto. En ésta etapa se basa todo el proceso de
construcción del software. Es necesario trabajar con claridad, precisión y coherencia.

Diseño del Sistema. Los diseñadores trabajan con estos requerimientos para diseñar una
solución al problema o desafío planteado. Estos trabajan en conjunto con los Analistas para
comprender mejor los requerimientos y con los Programadores para transmitirles el diseño
apropiado.

Desarrollo. Para ésta actividad se usan varios términos: Desarrollo, implementación,

programación, codificación. Los Programadores escriben en lenguaje de programación la
solución propuesta por los Diseñadores.

Testing. En diferentes momentos del proceso de construcción del software se prueban los
productos obtenidos para brindar información sobre la calidad del producto para los distintos
actores involucrados en el Proyecto.

Mantenimiento. Luego de entregado el sistema al cliente o liberado a producción, surgen en

general nuevas ideas para incorporar al software o nuevos requerimientos o también nuevas
oportunidades para el negocio. También surgen fallas que no se detectaron en etapas
anteriores. Se gestionan cambios y se abre así la etapa de Mantenimiento del software.

Este se clasifica en:

 1. Correctivo.
2. Preventivo y/o Perfectivo.
3. Adaptativo.

Estas etapas pueden tener distinto orden y distintas interrelaciones, pueden ser simultáneas o
sucesivas, pueden estar guiadas por el análisis de riesgos y pueden tender a la construcción del
todo o ser evolutivas según el modelo de desarrollo de software utilizado.

Modelo de desarrollo de software es una representación de alto nivel de las etapas que
ocurren durante el desarrollo y mantenimiento del software.

METODOLOGIAS AGILES.

Los modelos de desarrollo de software se inspiran en los de producción industrial y

evolucionan de forma similar, impulsados por la necesidad de mejorar continuamente,
superando las dificultades encontradas. Surgen varias metodologías que se corresponden con
estos modelos de desarrollo de software.

Por otra parte, el crecimiento y dinamismo de la industria del software y la tecnología de la

información plantea nuevos desafíos. Es preciso construir y poner en producción software de
calidad en plazos cada vez, más reducidos.

En el año 2001 se reunieron varios representantes de distintas metodologías para discutir

cómo mejorar la construcción de software. Publicaron luego un manifiesto, firmado por 17
autores que expresaba sus conclusiones.

Manifiesto por el Desarrollo Ágil

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia
experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre Procesos y herramientas.

Software funcionando sobre Documentación extensiva.

Colaboración con el Cliente sobre Negociación contractual.

Respuesta ante el cambio sobre Seguir un plan.

“Esto es, aunque valoramos los elementos de la derecha, preferimos más los de la izquierda.”

El término ágil no se refiere a la velocidad, sino a la flexibilidad para adaptarse a los cambios.
La rapidez no es el objetivo final sino que, en todo caso, es el efecto positivo por producir
código de alta calidad interna.

Los conceptos planteados en el manifiesto no son una invención ni surgen por generación
espontánea, sino que son el resultado de la búsqueda permanente en la construcción de
software, de la preocupación por resolver los problemas planteados de la experiencia y las
lecciones aprendidas por muchos profesionales y equipos de trabajos, en diferentes lugares y
durante mucho tiempo.
Es un intento por ponerse de acuerdo en un conjunto relativamente limitado de conceptos y
principios, por encima de las opiniones divergentes, lo cual expresa el espíritu constructivo y
de colaboración que animaba a los firmantes.

Se trató de establecer un conjunto de valores y principios, una cultura de trabajo, en el marco

de la cual se podrían implantar distintas prácticas para alcanzar el éxito y la satisfacción del
cliente en la construcción de software.

HISTORIAS DE USUARIO, DEFINICIÓN Y CARACTERÍSTICAS.

“No solo los Testers o un equipo de control de calidad se siente responsable de la calidad, no
se piensa en diferentes sectores dentro de un proyecto, solo se piensa en las habilidades de los
recursos para entregar el mejor producto posible. El enfoque de desarrollo ágil es producir alta
calidad de software en un marco de tiempo que maximice su valor. Todo el equipo se involucra
en las pruebas, y éstas impulsan la codificación, ayuda al equipo a entender cómo funciona y
como debería funcionar la aplicación.”

“Describe, de forma simple, una funcionalidad desde la perspectiva de quién desea el nuevo
comportamiento del sistema”.

Consiste en:

1. Breve descripción en el formato.

- “Como (rol)
- Quiero (funcionalidad)
- Para” (beneficio)
2. Conversaciones que incluyen detalles sobre la historia.
3. Criterios de aceptación que permiten determinar cuándo la historia ha sido
completada.

“Una historia de usuario es una explicación general e informal de una función de software
escrita desde la perspectiva del usuario final. Su propósito es articular como proporcionará una
función de software valor al cliente.”

Características:

1. Las historias de usuarios están escritas en lenguaje natural.

2. Son comprendidas por informáticos, usuarios, clientes y expertos en el negocio.
3. La discusión las enriquece.

Historias de usuario – Casos de uso.

Tanto en las historias de usuario como en los casos de uso, las conversaciones juegan un papel
importante.

En los casos de uso las conversaciones derivan en la especificación de los requerimientos y en

las historias de usuarios para refinarlas en otras historias, hasta lograr los criterios de
aceptación.
Siempre va a depender del contexto y de la organización, no quiere decir que una sea mejor
que otra, hay que lograr implementar lo que mejor se adapte al proyecto donde estamos
trabajando.

Una fórmula interesante:

Dada esta fórmula: S = F (CO, T, A, CA) en dónde S = El desarrollo de una pieza de software.

CO = Costo T = Tiempo A = Alcance CA = Calidad.

El desarrollo de software como una función entre Costo, Tiempo, Alcance y Calidad. Todas las
variables están relacionadas, si se altera una se afectan a las demás. Sin duda, las mejoras para
maniobrar son el tiempo y el alcance.

La calidad es una variable, que a veces queda librada al azar o es la primera que se descuida
cuando se reduce el tiempo o crece el alcance. Es importante resaltar que aunque principio se
pueda lograr una pequeña aceleración, luego pueden surgir efectos no deseados, como tener
que rehacer el trabajo muchas veces lo cual afecta el tiempo, el alcance y hasta el costo.

EL TESTING

En ésta lección se definen términos que utilizaremos durante el curso, se analizan varias
definiciones de testing y se muestran algunas analogías con otras disciplinas.

Validación: Es el proceso de evaluar un sistema o componente durante o al final del proceso

de desarrollo para determinar si satisface los requerimientos.

Cuando validamos respondemos a: ¿Estamos construyendo el software correcto? Durante este

proceso se contrasta el trabajo hecho con los requerimientos.

Verificación: Es el proceso de evaluar un sistema o componente para determinar si los

productos satisfacen las condiciones impuestas al principio de la fase.

Cuando verificamos respondemos a: ¿Estamos construyendo el software correctamente?

Durante este proceso se contrasta el trabajo hecho con las especificaciones.

Validación y Verificación es el proceso para determinar si los requerimientos de un sistema son

completos y correctos, si los productos de cada fase de desarrollo satisfacen los
requerimientos impuestos previos a la fase de desarrollo y si el sistema final cumple con los
requerimientos especificados.

Llamamos la atención sobre los términos completos y correctos, ya que en nuestra opinión
son indemostrables y su efecto puede ser devastador para formar Testers.

Porque lo que hacemos es preguntarnos siempre qué es lo que está faltando probar, o qué
podría fallar, tratando de ver más allá de los requerimientos y especificaciones.

En nuestra experiencia, cuando hacemos testing, validamos, verificamos o hacemos ambas

cosas, dependiendo de los objetivos de prueba establecidos.
El Testing es la verificación dinámica del comportamiento observado de un programa contra el
comportamiento esperado, usando un conjunto finito de casos de prueba, seleccionados de
manera adecuada desde el dominio infinito de ejecución.

Es el proceso de ejecutar un sistema o componente bajo determinadas condiciones,

observando o almacenando los resultados y evaluando distintos aspectos del sistema o
componente.

Proceso de analizar elementos de un software para detectar diferencias entre condiciones

existentes y requeridas y evaluar las características de cada elemento de software.

En las definiciones anteriores, se trata al testing como un proceso, o actividad independiente

de las características inherentes del software y los procesos asociados.

Como vimos en la unidad anterior, podemos considerar el desarrollo de software como una
ecuación que depende del contexto (costo, tiempo, alcance y calidad, entre otros).

El Testing es una investigación empírica técnica orientada a proporcionar información sobre la

calidad de un software para un actor o usuario. “Es una actividad cognitiva, en es una actividad
mecánica”.

Investigación porque es una búsqueda ordenada de información. Es un proceso activo de

indagación, en el que se le hacen preguntas al software y se observan cuidadosamente las
respuestas o resultados.

Empírica porque hay que hacer los experimentos, hay que ejecutar el software para ver los
resultados, se experimenta con el ambiente, otros sistemas con los que interactuamos y con el
hardware. Por lo que la investigación se basa en los experimentos y la experiencia que vamos
obteniendo.

Brindar información contribuye a disminuir la incertidumbre, no sólo son bugs lo que se busca.

La actividad cognitiva es un proceso múltiple e interactivo que involucra armónicamente todas

las funciones mentales, a saber: percepción, memoria, pensamiento, lenguaje, creatividad,
imaginación, intuición, interés, atención, motivación, conciencia e incluso creencias, valores,
emociones, etc. El sujeto matiza de significado a las partes de la realidad que más le
signifiquen e interesen.

En Testing utilizamos nuestras funciones mentales para: ENTENDER, PENSAR, EJECUTAR Y

COMPARAR.

TESTEAMOS PARA:
 1. Detectar incidentes, defectos, errores, oportunidades de mejora.
2. Evaluar la calidad de un software.
3. Ayudar a la Gerencia a tomar decisiones en base a información.
4. Verificar interoperabilidad.
5. Verificar la conformidad con estándares.
6. Minimizar los riesgos.

Diferentes objetivos de prueba requieren diferentes estrategias, tipos de prueba,

documentación y resultados.

Podemos definir como indicadores para medir la calidad, la cantidad y severidad de los
defectos detectados, en base a un cubrimiento de las pruebas, previamente establecido.

Cuando veamos técnicas y estrategias de testing, definiremos los distintos tipos de

cubrimiento, cómo definirlo y medirlo.

Ejemplo: Si ejecutamos pruebas con un cubrimiento aceptable y se detecta un error crítico (el
sistema queda sin conexión con la base de datos y se pierden los datos ingresados en los
últimos 2 minutos), podemos decir que el sistema no tiene la calidad suficiente como para ser
usado en producción. Pero si tenemos 20 errores cosméticos (tipos de letra, colores,
resolución de imágenes), podríamos decidir salir a producción a pesar de éstos ya que no
afectan la operativa habitual de los usuarios del sistema.

El testing nos proporciona un vistazo al nivel de confianza en el programa. Si ejecutamos

pruebas durante 1 mes de nuestro sistema, logrando un cubrimiento aceptable y no se detectó
ningún error crítico, aumenta la confianza que tenemos en el sistema.

Por el contrario, si detectamos errores críticos o de severidad considerable, vamos a necesitar

que se corrijan y continuaremos haciendo pruebas antes de salir a producción. O si decidimos
salir a producción con incidentes críticos, lo haremos sin confiar en el sistema y esperando que
se produzcan incendios para apagarlos.

Testeamos porque la construcción de software es un proceso colaborativo en el cual

intervienen actores diversos que negocian expectativas en un contexto determinado, piensan y
cometen errores.

La tarea del Tester es similar a las series de televisión CSI (Investigación de la escena del
crimen) o ER (Sala de emergencias) .

En CSI es necesario investigar para saber quién es el “asesino” y hay que hacer deducciones a
partir de la información disponible en la “escena del crimen”.

En ER hay que elegir qué análisis y estudios clínicos hacer para tener un correcto diagnóstico
de la situación. Además, en base a los síntomas del paciente hay que decidir cuál atacar
primero, priorizando según los riesgos.

La información de la que disponemos en el testing son las especificaciones y los

requerimientos que transmiten los usuarios, mientras que en las series hay declaraciones de
testigos, historias médicas, síntomas de los pacientes y lo que transmiten los involucrados.
En el testing, el diagnóstico se hace a partir del resultado obtenido, en función de lo cual se
decide si se detienen o continúan las pruebas. Las prioridades son los requerimientos y las
funcionalidades.

TESTING EN EL CONTEXTO ACTUAL.

El software tiene cada vez más impacto en las organizaciones, los negocios y la sociedad. Al ser
cada vez más complejos el testing también lo es.

Por ejemplo, ha aumentado la escala de las aplicaciones, la multiplicidad de las arquitecturas y

plataformas. En las aplicaciones que se construyen en la actualidad existen generalmente
varias capas, componentes, subsistemas, servicios e interfaces con otros sistemas.

Cuando se detecta una falla en el sistema, aislar el bug es fundamental y en ocasiones hay que
hacerle “seguimiento” por las distintas capas y niveles de abstracción hasta “cazarlo”. Los
entornos de desarrollo integrado (IDE) y los generadores de código facilitan la construcción de
las aplicaciones, aumentando la productividad. Se produce código con menos esfuerzo.

Las características de los sistemas han llevado a que las pruebas se multipliquen y se vuelvan
más complicadas, lo mismo ocurre con la búsqueda de soluciones. La importancia del testing
es cada vez mayor en los proyectos, debido al impacto del software en los negocios.

Siempre existió el conflicto entre el nivel de calidad del software y el plazo para la salida al
mercado. En la actualidad, hay cada vez más empresas proveedoras de software que ofrecen
sus productos y servicios y clientes cada vez más exigentes, por lo cual este conflicto se
intensifica aún más.

La disyuntiva es:

- Si no sacamos al producto al mercado en la fecha tal, puede salir al mercado un

competidor y perderemos clientes.
- Si lo hacemos con la cantidad y severidad de incidentes que se están detectando,
los clientes se molestarán y dejarán de comprarnos, afectando así de manera
negativa la imagen de la Empresa.

Lo ideal es el balance entre el nivel de calidad del software y el plazo de salida al mercado.

En testing se trata de generar cada vez más métodos y herramientas para superar las
dificultades, como ser, criterios de cobertura y avance en la automatización de las pruebas.

TESTING CONTINUO, ÁGIL

Una de las respuestas al desafío es el concepto de Testing continuo, asociado a metodologías

ágiles. Este concepto se refiere a que el testing está presente desde el inicio de la construcción
de un producto de software y continúa presente durante todo el flujo de trabajo.

No es un concepto nuevo, por eso se comienza en las etapas más tempranas , desde la
formulación y revisión de los requerimientos, pasando por todas las etapas y actividades
intermedias hasta su pasaje a producción y posterior mantenimiento.
La diferencia es que en las metodologías ágiles es imprescindible trabajar así, si efectivamente
se quiere producir software de calidad. Incluso en las metodologías XP (Extreme Programming)
se profundizan y describen actividades de testing.

El factor humano es fundamental para investigar, innovar y lograr la mejor calidad posible.

CARACTERISTICAS DEL TESTING

Para testear tenemos que:

1. ENTENDER (como se espera que se comporte el software)

2. PENSAR (entradas, condiciones de ejecución)
3. EJECUTAR (casos de prueba)
4. COMPARAR (resultados obtenidos con resultados esperados)

Prueba exhaustiva

Es aquella en la que se prueban todas las combinaciones de entradas posibles. Por definición y
cuestión de tiempo siempre son IMPOSIBLES.

Para solucionar esto tenemos que seleccionar un subconjunto de pruebas de otro conjunto
mayor. De modo tal de cubrir las funcionalidades y especificaciones principales.

Las fallas siempre están ocultas, “LA PRUEBA DE UN PROGRAMA SÓLO PUEDE MOSTRAR LA
PRESENCIA DE DEFECTOS, NO SU AUSENCIA”.

PARADOJA DEL PESTICIDA

“Cualquier método que se use para prevenir o encontrar bugs deja como residuo los más
sutiles, contra los que ese método no es efectivo.”

El pesticida mata un gran porcentaje de los insectos, pero deja un residuo, los más fuertes
sobreviven. Como consecuencia, al año siguiente es preciso un pesticida más potente.

Cuando hacemos testing pensamos pruebas, las ejecutamos, detectamos bugs, se corrigen y
volvemos a ejecutar pruebas para verificar su corrección.

Luego el conjunto de casos pensados ya no detectan bugs, pues los que detectaron en un
principio ya fueron corregidos. Pero aún puede haber bugs en el software que no hayamos
detectado. Tenemos que pensar y ejecutar nuevas pruebas para detectar esos bugs que aún
persisten.

Podemos pensar las pruebas que ejecutamos como un pesticida que va matando bugs.
Tenemos que actualizarlas y agregar nuevas pruebas al conjunto inicial para ir matando el
residuo que queda.

Al hacer buen testing, los errores van a ir cambiando, y tenemos que cambiar los casos de
prueba para mantener la calidad del software.
 TIPOS DE TESTING : CRITERIOS DE CLASIFICACIÓN

Usualmente clasificamos para agrupar elementos con características comunes, simplificando la

realidad, y analizando un conjunto de elementos desde distintos puntos de vista.

Sobre un mismo conjunto podemos definir distintos criterios de clasificación y los elementos
pueden reagruparse según cada uno de éstos.

Podemos clasificar las pruebas según:

1. El conocimiento del código.

2. La etapa del desarrollo del software.
3. El aspecto a evaluar del software.

Según el conocimiento del código, se clasifica en caja negra, dónde no se tiene acceso al
código ni su estructura interna. Para la ejecución de las pruebas de caja negra, se suministran
datos de entrada al sistema, se observa la salida obtenida y se compara con la salida esperada.
Ya que sabemos cómo se espera que se comporte el programa.

En las pruebas de caja blanca se piensan y diseñan casos de prueba conociendo el código
fuente del programa, se seleccionan los caminos de éste y el flujo de datos a ejercitar durante
las pruebas. Se denomina testing estructural.

En general es realizado por el desarrollador que escribió el código fuente. Sin embargo, puede
darse el caso en que un equipo de testing deba hacer estas pruebas. Estas pruebas de caja
blanca o transparente están orientadas a identificar defectos en el diseño del código y no a
detectar discrepancias entre los requerimientos y su implementación. En estas pruebas los
programas son vistos en términos de unidades de código que interactúan entre sí.

En cambio en las pruebas de caja gris, se tiene un conocimiento limitado del código. Se
establece un dialogo con el programador o bien se estudia la documentación técnica para
conocer la estructura interna del sistema. Un ejemplo es cuando tenemos acceso a la base de
datos y podemos leer los store procedure y ver cómo es la estructura de la misma, claves
principales, claves foráneas, tablas, índices, consultas, etc.

Según la etapa de desarrollo se clasifican en :

1. Unitarias
2. Integrales
3. Sistémicas
4. Regresivas
5. De Aceptación

Es importante destacar que el momento, la forma y la frecuencia con que se ejecutan estas
pruebas depende del proceso de desarrollo que se utilice.

Pruebas Unitarias, en éstas pruebas se prueban de forma aisladas las unidades o conjunto de
unidades del sistema. Podemos considerar una unidad como una clase, método, componente
o subsistema. Se intenta detectar discrepancias entre los requerimientos y el comportamiento
del software. Se pone énfasis en verificar la especificación de la interfaz de las unidades.
Pueden ser pruebas manuales o automatizadas, ejecutadas por quién desarrolla el software o
por un tercero, además de ser de caja negra, blanca o gris.

Pruebas Integrales, es el proceso mediante el cual son agregados los componentes para crear
un sistema más grande. Aquí el software y el hardware son combinados para evaluar su
interacción. Uno de los objetivos es identificar los problemas surgidos a partir de la
combinación de componentes. Pueden ser de caja negra, blanca o gris y pueden ser ejecutadas
por distintos actores. En general requieren de la participación de los desarrolladores porque
conocen los detalles de la integración, tablas, servicios, etc.

Pruebas de Sistema, éstas tienen como objetivo evaluar el comportamiento del sistema en su
conjunto, verificando el cumplimiento de los requerimientos explícitos e implícitos. Son
pruebas sobre las pruebas de integración. Se considera el hardware y software definido,
similar al de producción y se tienen en cuenta las interfaces externas, los dispositivos de
hardware y el entorno de ejecución.

Se evalúa:

1. Funcionalidad; se evalúa que las funcionalidades se comporten como es esperado.

2. Seguridad; protección de los datos, autenticación y autorización.
3. Usabilidad; facilidad con la que el usuario puede aprender a manejar, preparar las
entradas e interpretar las salidas de un sistema.
4. Configuración e instalación; se evalúa la dificultad o facilidad de instalar el software
por parte del usuario. Existen productos que dada su alta complejidad son difíciles de
instalar y requieren mayor conocimiento del producto por parte del usuario por
ejemplo Microsoft SQL Server.
5. Escalabilidad; se estudia el nivel de modularización y los cambios a nivel tanto de
software como de hardware.
6. Desempeño; se evalúa el rendimiento o performance del sistema.
7. Carga, se considera la máxima cantidad de usuarios concurrentes.
8. Volumen, se observa el comportamiento del sistema con gran volumen de datos.
9. Stress, se evalúa el sistema más allá de los límites para los que fue diseñado
considerando volumen y carga simultáneamente.

Pruebas de Aceptación: Son las que evalúan si el sistema puede ser utilizado por el usuario
final para realizar las funciones y tareas para las que fue construido. Ejemplo de pruebas de
aceptación son las “pruebas de humo”, ejecutadas por testers representantes del cliente.
Estas pruebas tienen más que ver con la Validación que con la verificación.

Pueden ser:

1. Formal, o extensión de la prueba de Sistema.

2. Informal; se identifican las funciones, pero hay casos de prueba a seguir. El usuario
final determina qué hacer.
3. Alfa; Pruebas realizadas por el usuario final en la organización de desarrollo.
 4. Beta; El usuario final es responsable de crear el ambiente, seleccionar sus datos y
decidir qué funciones explorar. Es responsable por identificar su propio criterio de
aceptación.

Según Michael Bolton las organizaciones consideran las pruebas de aceptación de diversas
maneras. Por ejemplo:

 Una ceremonia, en la que no hay testing real, sino más bien es un paso protocolar,
para que se haga efectivo un cobro o cierre de contrato.
 Una demostración, dónde no se requiere que aparezcan errores para convencer o
capacitar al auditorio.
 Un ejercicio suave, con pruebas simples mediante las cuales se busca salir airoso del
paso.
 La búsqueda de un chivo expiatorio, procurando detectar el error que provoque la no
aceptación, esto se da generalmente, cuando hay problemas entre las Empresas y no
se quiere aceptar el producto de antemano.
 Pruebas de sondeo, desafiando al software, buscando romperlo y al no suceder esto,
confirmar que éste funciona bien.
 Investigación, crítica, imparcial y de apoyo, buscando un software de alta calidad.

Existen riesgos en este tipo de ceremonias.

 Foco en detalles insignificantes en lugar de enfocarse en las funcionalidades y ciclos

funcionales más significativos.
 Usuarios no adecuados o no preparados para la tarea.
 Reacción negativa enfocada en el cambio y no en el software.
 Criterios de aceptación inciertos, funcionalidades y ciclos funcionales no priorizados.
 Perfiles de uso del producto no estudiados.

Si se está en un proyecto que involucra pruebas de aceptación se aconseja considerarlas lo

antes posible.

Pruebas de Regresión, su objetivo es verificar que no haya ocurrido una regresión en la calidad
del software luego de alguna corrección o modificación. La cual puede ser nueva funcionalidad
o la actualización de uno o más componentes, del software o del hardware.

En cualquier caso, no es suficiente con probar la modificación solamente, sino que es necesario
verificar que no se hayan producido desajustes en otros módulos del programa. Estas pruebas
de regresión implican la re ejecución de algunas o todas las pruebas ejecutadas anteriormente.

Tipos de regresión:

1. De incidentes recientemente corregidos.

2. De correcciones anteriores.
3. De efectos secundarios a) Volver a probar una parte del producto.
b) El objetivo es probar que a raíz de la modificación, cambio o actualización,
algo que funcionaba ya no lo hace.
Como no siempre es posible re ejecutar todas las pruebas, hay que evaluar entre las distintas
estrategias para decidir qué casos de prueba ejecutar y cuales no ya que todas tienen sus
ventajas y desventajas.

Por ejemplo, si siempre re ejecutamos las pruebas de las funcionalidades más críticas, podrían
quedar funcionalidades sin testear que nunca volveríamos a probar. Lo recomendable es que
dentro de lo posible y si los plazos de tiempo lo permiten, que se re ejecuten todas las
pruebas.

La prueba de errores severos corregidos de forma urgente, constituye una excepción, ya que
es apremiante liberar el producto inmediatamente. Pero lo que no puede suceder es que se
pierdan esos casos de prueba y no sean incorporados a las sucesivas pruebas de regresión del
producto.

Tanto en las pruebas unitarias como en las de integración, de sistema y de aceptación, se

pueden ejecutar pruebas de regresión.

Según el aspecto a evaluar, se pueden clasificar en Pruebas Funcionales y Para Funcionales.

Las pruebas funcionales se enfocan en verificar la capacidad del sistema de realizar ciertas
funcionalidades. Se basan en qué hace el sistema y se considera el punto de vista del usuario y
generalmente se utiliza un enfoque de caja negra.

Las pruebas para funcionales o no funcionales verifican otros atributos del sistema, haciendo
foco en “cómo” el sistema cumple con las funcionalidades. A pesar de llamarse pruebas no
funcionales el rendimiento y performance también se evalúan como parte del
comportamiento de las funcionalidades del sistema.

Por lo que decidimos llamarle pruebas para funcionales a aquellas que tienen como objetivo
evaluar aspectos relacionados a la rapidez (transacciones por segundo) el tamaño (kB,
kilobytes) y a la fiabilidad (tiempo promedio entre fallas, capacidad de recuperación ante
errores), entre otros aspectos.

Por ejemplo, las pruebas de usabilidad, escalabilidad, rapidez, seguridad, tamaño, portabilidad
(sistemas operativos, navegadores web) se consideran para funcionales.

OTROS TIPOS DE TESTING

Según la modalidad de las pruebas se pueden clasificar en manuales y automáticas. Hay tipos
de prueba para los cuales la automatización es especialmente recomendable.

 Las pruebas unitarias, porque existen un conjunto de herramientas que ayudan al

programador a generarlas y porque si están automatizadas se pueden agregar
fluidamente al desarrollo del software, formando parte del mismo.

Las pruebas de regresión de un software que sigue desarrollándose, pero tiene un núcleo
estable. Porque permite aumentar la productividad de las pruebas (después de varios ciclos de
regresión) y funciona como una especie de “Seguro contra incendios”.
  Las pruebas de performance, carga, estrés, son hoy inimaginables sin una etapa de
automatización de los escenarios a probar, porque también existen herramientas que
ayudan en ésta tarea, y porque sería sumamente costoso y poco eficiente organizar
con personas los simulacros adecuados.

Pero no son las únicas, es importante pensar: ¿qué actividades hacen mejor las computadoras
que las personas?

CRITERIOS DE CLASIFICACIÓN EN TESTING ÁGIL

Los 4 cuadrantes del testing ágil representan los diferentes propósitos y tipos de pruebas de
software que podemos realizar en un entorno de desarrollo ágil. En la parte superior están las
pruebas orientadas al negocio y en la inferior las pruebas orientadas a la tecnología.

A la izquierda como soporte a la programación y la derecha las que critican el producto.

Cuadrante 1.

1. Pruebas unitarias.
2. Pruebas de integrales o de componentes.
3. Pruebas automatizadas.

Cuadrante 2.

1. Pruebas funcionales.
2. Ejemplos.
3. Pruebas de Historias de usuario.
4. Prototipos.
5. Pruebas automatizadas y manuales.

Cuadrante 3.

1. Pruebas exploratorias.
2. Escenarios.
3. Pruebas de usabilidad.
4. Pruebas de aceptación.
5. Pruebas manuales.

Cuadrante 4.

1. Pruebas de carga.
2. Pruebas de rendimiento.
3. Pruebas de seguridad.

Uso de herramientas.

Como podemos apreciar coexisten varios criterios de clasificación de las pruebas, todos
aportan a la disciplina del Testing. Lo importante es pensar qué tipo de pruebas es adecuada
para cada contexto y sobre todo, qué pruebas han quedado sin hacer.
 EL MODELO V

Podemos tomar la clasificación de las pruebas según las etapas de desarrollo del software y
verlas en la dimensión del tiempo, en el modelo V.

Este modelo muestra que se puede ir trabajando en las etapas de prueba a medida que avance
el proyecto.

El entender y pensar puede darse luego de finalizadas las actividades de: Análisis de
requerimientos, Diseño del sistema y Diseño detallado. Cuando se termina el análisis de
requerimientos se puede empezar a pensar el plan de pruebas de aceptación y diseñar
pruebas. Se podría aún empezar antes de culminar la etapa.

Esta forma de trabajo ayuda a reducir ambigüedades e inconsistencias en cada etapa, que
podrían convertirse en errores. Por lo tanto, si adelantamos las actividades de entender y
pensar estaremos ahorrando re trabajo. Por eso lo llamamos modelo V con filtros.

Si tenemos un proceso de desarrollo iterativo o incremental podemos imaginar varias V

ligeramente superpuestas, una W o múltiples V. También podemos pensar en las pruebas de
regresión luego que el producto pasa a la etapa de mantenimiento o de una V a la siguiente.

ESTRATEGIAS DE TESTING

Hasta ahora hemos hablado de requerimientos, especificaciones, software, actores, calidad y

contexto de un proyecto. Todos estos elementos determinan lo que llamamos en el sentido
más amplio, Estrategia de pruebas.

Una estrategia esboza qué planear y como planearlo. Una estrategia exitosa es asimilable a
una guía para el cambio, una base firme para la mejora continua.

Por su naturaleza el testing promueve cambios ya que detecta problemas que hay que
resolver, para que estos cambios se hagan efectivos es necesario que la estrategia de pruebas
fomente la detección y corrección de errores en paralelo e impulse también cambios a nivel de
procesos y gestión del proyecto.

Si en una organización no se considera al testing como articulador y promotor del cambio, no

va a mejorar la calidad de lo que se produce y se van a presentar muchos conflictos de
intereses.

¿Qué sucede si . . . . .

1. Se detectan errores y no son evaluados ni corregidos?

2. Se detectan patrones en los incidentes encontrados y nadie evalúa esta información?
3. Al equipo que va a testear no se le provee la información actualizada de
requerimientos y especificaciones ni se dan espacios de intercambio con expertos del
negocio?
4. Si no se registran las pruebas ni los incidentes y sólo se comunican verbalmente?

Parece claro que por más que se haya asignado un equipo para testear, si no tenemos
resueltos algunos de éstos y más temas, vamos a obtener resultados bastante pobres.
La estrategia de prueba incluye:

1. Pensar.
2. Proponer.
3. Definir formas de trabajo.
4. Procesos a seguir.

Considerando al testing como parte del proyecto de desarrollo o mantenimiento del software.
Ayuda a las organizaciones a transitar a través del cambio y los objetivos de mejora, brindando
un marco para la toma de decisiones.

Más que un documento.

Es importante no confundirse, la estrategia de pruebas es mucho más que un documento.

Puede cubrir un amplio espectro de temas de testing y del negocio, alguno son:

1. Enfoque para la gestión de riesgos.

2. Técnicas de testing, manejo de datos, planificación de pruebas.
3. Criterios de completitud o finalización y análisis.
4. Gestión del testing y métricas.
5. Habilidades del equipo, estructura y entrenamiento.
6. Ambientes de prueba, control de cambios y estrategia de liberaciones.
7. Pruebas de regresión.
8. Análisis dinámico de programas y testing de performance.
9. Incidentes, seguimiento y correcciones.
10. Automatización de las pruebas y herramientas.

Nuestra estrategia de prueba puede contener más o menos de estos temas a considerar, el
listado sólo nos muestra algunos de ellos.

El objetivo del curso no es entrar en detalle en cada aspecto a considerar en la estrategia, a

continuación, explicaremos algunos de ellos y pondremos ejemplos.

GESTION DE RIESGOS

Un riesgo es la probabilidad de que algo no deseado ocurra. La magnitud de un riesgo es

proporcional a la probabilidad y al impacto del problema. Cuanto más probable es que el
problema suceda y mayor su impacto, más alto es el riesgo asociado a ese problema. Podemos
clasificar a los riesgos como:

1. Del producto.
2. Del proyecto.

Del Producto es por ejemplo el módulo de facturación no funciona correctamente.

Del Proyecto es por ejemplo si la infraestructura de pruebas no está lista en tiempo y forma o
si no se detectan incidentes en fase de testing y luego se encuentran en fase de producción.
Se podría confeccionar una lista priorizada de riesgos y luego realizar pruebas que explorasen
cada riesgo.

Por último, cuando un riesgo se mitigase y emergieran nuevos, se ajustaría el alcance de la

prueba.

Podemos usar un enfoque de adentro hacia afuera, preguntándonos, ¿Qué riesgos se asocian a
ésta funcionalidad? O al revés, ¿Qué funcionalidades se asocian a ésta clase de riesgo?

Criterios de completitud o finalización y análisis.

Ya que no es posible evaluar un software exhaustivamente, vamos a elegir de un universo de

casos bastante amplio. Por lo que se nos presenta el dilema de cuándo es suficiente, con
cuántos casos de prueba, cuándo obtengo qué resultados, luego de cuánto tiempo y de
cuántas ejecuciones.

Si bien no existe una receta para definir el criterio de finalización de pruebas. Este dependerá
del contexto del proyecto. Puntos a considerar para definir el criterio de finalización de
pruebas.

1. Tiempo de prueba o tiempo relativo al tiempo de desarrollo.

2. Cubrimiento de las pruebas.
3. Incidentes detectados, cantidad, severidad.
4. Características de la aplicación vs exigencias del mercado.

Podemos considerar que las pruebas han finalizado si:

1. Se ejecutaron pruebas en todas las etapas del desarrollo.

2. Al menos se destina un tercio del tiempo de desarrollo al testing.
3. Se cubren en amplitud todas las funcionalidades y con mayor profundidad aquellas
asociadas a los riesgos detectados.
4. Si en el último ciclo de pruebas no se detectan incidentes críticos ni severos.
5. Si se hicieron pruebas de performance, (en caso de ser una aplicación que va a ser
usada por muchos usuarios simultáneamente luego de su salida a producción)

Es importante que al definir el criterio de finalización de pruebas consideremos la realidad del

proyecto y nos propongamos criterios factibles y reales.

El criterio de finalización normalmente es una combinación de los puntos detallados, nunca es

sólo uno de ellos.

Gestión del testing y métricas.

El testing es una actividad de investigación técnica de un producto, pero tenemos que

gestionar las pruebas que pensamos y ejecutamos, las partes del software que ejercitamos
(cuáles funcionalidades) y quién lo hizo, por cuánto tiempo, con qué herramientas. Para que
luego se puedan sacar conclusiones tenemos que conocer qué hicimos y cómo lo hicimos.
Podemos definir distintos aspectos a medir, para saber dónde estamos ahora y adonde
queremos ir.
Lo que no se mide no se puede gestionar y por lo tanto no se puede mejorar. Un indicador es
una magnitud asociada a una característica que permite a través de su medición, evaluarla
periódicamente y verificar el cumplimiento de los objetivos establecidos.

Algunos indicadores:

1. Tiempo medio en resolver incidentes.

2. Desviación en el esfuerzo de testing estimado.
3. Incidentes por severidad.

HABILIDADES DEL EQUIPO, ESTRUCTURA Y ENTRENAMIENTO

Definir la estructura del equipo de pruebas, conocer sus capacidades y potencial permitirán
elaborar el plan de formación adecuado. Esta capacitación ayudará al equipo a desarrollar
habilidades que le permitan investigar de forma más eficiente los productos bajo prueba.

Tener un equipo de testing, significa mucho más que poner en un mismo lugar físico a varias
personas. La formación del equipo, su integración, organización y forma de trabajo dependerá
de cómo se perciba el testing en la institución y se verán reflejadas en los resultados que se
obtengan.

Otros aspectos.

1. Técnicas de testing, manejo de datos, planificación de pruebas

2. Ambientes de prueba, control de cambios y estrategia de liberaciones.
3. Pruebas de regresión.
4. Análisis dinámico y testing de desempeño.
5. Incidentes, seguimiento y correcciones.
6. Automatización de las pruebas y herramientas.

Lo importante es considerar en la estrategia de pruebas, además de los aspectos técnicos el

contexto del proyecto y a las personas involucradas que desempeñan los distintos roles.

TESTING DE METODOLOGÍAS ÁGILES

1. Tipos de prueba.

Los cuadrantes de testing ágil.

Se presenta una matriz de cuadrantes testing, como herramienta de ayuda a los testers, que
permite analizar si se han considerado los distintos tipos de prueba necesarios en un proyecto
dado.

Cada uno de los cuadrantes refleja las distintas razones para hacer pruebas, entre las que se
encuentran: detectar errores, disminuir el riesgo, aumentar el nivel de confianza, conocer la
aplicación. En el eje vertical, la matriz se divide en las pruebas que apoyan al equipo y las
pruebas que critican al producto. En el eje horizontal estas pruebas se dividen en pruebas
orientadas al negocio y pruebas orientadas a la tecnología.

La numeración de los cuadrantes no condiciona el orden en que se realizan los distintos tipos
de prueba. Los cuadrantes de la izquierda constituyen las pruebas que apoyan al equipo
mientras se desarrolla el producto. El objetivo de estas pruebas es ayudar a la especificación
de requisitos y en el diseño. Esta concepción de las pruebas, es una gran diferencia de los
proyectos ágiles con respecto a los proyectos tradicionales.

Los cuadrantes del lado derecho representan a las pruebas que critican el producto. Estas
pruebas consisten en revisar el software de manera constructiva, con el objetivo de aprender
cómo mejorarlo. Como resultado de este aprendizaje, se pueden incorporar nuevos requisitos,
pruebas y ejemplos, que ayuden al equipo y guíen al desarrollo. La información que se obtiene
en las pruebas que revisan el producto, debería servir de entrada para el lado izquierdo de la
matriz y así ser utilizada para crear nuevas pruebas y guiar el desarrollo futuro.

Los cuadrantes ayudan a identificar los distintos tipos de pruebas necesarios para guiar el
desarrollo. Las iteraciones cortas del desarrollo ágil brindan a los equipos la oportunidad de
aprender y experimentar con los distintos cuadrantes de testing. Por ejemplo si se detecta
tarde que el diseño no es escalable, entonces en la próxima story o proyecto se deberán
introducir las pruebas de carga de forma más temprana. El objetivo de los cuadrantes como
ayuda es para asegurarse que las pruebas se están haciendo a tiempo.

Cuadrante 1: Pruebas orientadas a la tecnología que apoyan al equipo.

El cuadrante inferior izquierdo representa el desarrollo guiado por las pruebas, actividad
central del desarrollo ágil.

Las pruebas unitarias ayudan a los desarrolladores a comprender exactamente qué necesita
hacer el código y sirven