Control de Versiones

                     

¿Qué es el control de versiones, y por qué debería ser importarte? El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que el usuario pueda recuperar versiones específicas más adelante. A pesar de que los ejemplos de este informe muestran código fuente como archivos bajo control de versiones, en realidad cualquier tipo de archivo que se encuentre en un ordenador puede ponerse bajo control de versiones.[1]

Una herramienta de la que muchas personas, sean diseñadores gráficos o web pueden hacer uso y es de muy buena calidad es la llamada Version Control System (VCS). Con esta herramienta es posible  revertir archivos a un estado anterior, revertir el proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y mucho más. Usar un VCS también significa generalmente que si fastidias o pierdes archivos, puedes recuperarlos fácilmente. Además, obtienes todos estos beneficios a un coste muy bajo.

Sistemas de control de versiones locales

Un método de control de versiones usado por mucha gente es copiar los archivos a otro directorio (quizás indicando la fecha y hora en que lo hicieron, si son avispados). Este enfoque es muy común porque es muy simple, pero también está propenso a errores. Es fácil olvidar en qué directorio se encuentra en el momento en que se encuentra trabajando, y guardar accidentalmente en el archivo equivocado o sobrescribir archivos que no se estaba pensado hacer.

Para hacer frente al problema anterior, los programadores desarrollaron VCSs locales que contenían una simple base de datos en la que se llevaba registro de todos los cambios realizados sobre los archivos como se muestra en la siguiente imagen.

Sistemas de control de versiones centralizados

El siguiente gran problema en el que se encuentran las personas es que necesitan colaborar con desarrolladores en otros sistemas diferentes. Para resolver este problema, se desarrollaron los Centralized Version Control Systems (CVCSs). Estos sistemas, como CVS, Subversion, y Perforce, tienen un único servidor que contiene todos los archivos versionados, y varios clientes que descargan los archivos desde ese lugar central. Para que la idea quede un poco más clara se muestra la siguiente imagen.



Esta configuración ofrece muchas ventajas, especialmente frente a VCSs locales. Por ejemplo, cualquier persona puede saber (hasta cierto punto) en qué están trabajando los otros colaboradores del proyecto. Los administradores tienen control detallado de qué puede hacer cada uno; y es mucho más fácil administrar un CVCS que tener que lidiar con bases de datos locales en cada cliente.

Sin embargo, esta configuración también tiene serias desventajas. La más obvia es el punto único de fallo que representa el servidor centralizado. Si ese servidor se cae durante una hora, entonces durante esa hora nadie puede colaborar o guardar cambios versionados de aquello en que están trabajando. [1]

Sistemas de control de versiones distribuidos

Es aquí donde entran los Distributed Version Control Systems (DVCSs). En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor muere, y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una instantánea, en realidad se hace una copia de seguridad completa de todos los datos como se puede visualizar en la siguiente imagen.

Referencias:

[1] Git-scm.com. (2017). Git - Acerca del control de versiones. [online] Available at: https://git-scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones [Accessed 13 Nov. 2017].

V&V

Verificación y Validación

La importancia de este tema se viene dando desde hace ya más de 30 años por Michael S.Deutsch [DEUT79] en su estudio de "Verification and Validation" dice que:

"El desarrollo de sistemas de software implica una serie de actividades de producción en las que las posibilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar a darse desde el primer momento del proceso, en el que los objetivos pueden estar especificados de forma errónea o imperfecta, así como en posteriores pasos de diseño y de desarrollo. Debido a la imposibilidad humana de trabajar y comunicar de forma perfecta, el desarrollo de software ha de ir acompañado de una actividad que garantice la calidad."[1]

Los proyectos de desarrollo de software han padecido tradicionalmente problemas de calidad, tanto en el propio proceso de desarrollo como en los productos de entrega. Esta problemática tiene su origen en las habituales desviaciones sobre los plazos y esfuerzos previstos y en la frecuente aparición durante la implantación y operaciones de los productos resultantes.

El proceso de desarrollo adoptado por un proyecto dependerá de los objetivos y metas que tenga el mismo. Para poder alcanzar dichos objetivos se han desarrollado distintos modelos de ciclo de vida, pero en cualquiera de ellos será necesario un proceso que asegure la calidad del producto durante su desarrollo. Para ello, al final de cada fase del ciclo de vida debería comprobarse que el trabajo realizado hasta ese momento cumple con los objetivos previstos. Este es el punto clave, en el que tiene lugar la evaluación del producto, donde se decide si está o no preparado para pasar a la siguiente fase. De esta forma, si hay errores y son detectados, será más eficiente corregirlos que si se descubriesen en etapas avanzadas.[2]

El objetivo final del proceso de verificación y validación es comprobar que el sistema está hecho para un propósito, al cual intenta llegar aplicando técnicas específicas conocidas como: las pruebas y las revisiones.

El proceso de Verificación y Validación es un conjunto de procedimientos, actividades, técnicas y herramientas que se utilizan paralelamente al desarrollo de software, con el fin de asegurar que un producto resuelve el problema inicialmente planteado.

La Verificación
La verificación comprueba la consistencia del software con respecto a especificaciones y requisitos, es decir, si responde a la pregunta: ¿Se ha construido correctamente el software?

• El proceso determina si los productos resultantes de una fase del ciclo de vida del software cumple los requisitos establecidos en la fase anterior. 
• El proceso determina si el producto resultante es completo, consistente y correcto para comenzar la siguiente fase.

La Validación

La validación comprueba si lo que se ha especificado e implementado es lo que el usuario realmente desea, es decir, si responde a la pregunta: ¿Se ha construido el software correcto?

• El proceso determina si el software cumple su especificación.
• El proceso asegura que el software fabricado se comporta como se espera y de acuerdo a las expectativas del cliente.

Las tareas V&V no solo se aplican a productos de software, sino que también a los resultantes del proceso de desarrollo, como el análisis y a la especificación de requisitos, por ejemplo. De esta forma, se comprueba que el proyecto es viable y que las especificaciones documentadas son completas, correctas, precisas, legibles, evaluables, y que, en general, responden a las expectativas del cliente. La V&V del diseño debe garantizar que los requisitos no se encuentran incompletos o incorrectamente diseñados. En el caso de la implementación y la codificación, la V&V del software es comúnmente conocida como las pruebas de software. 

Técnicas de verificación y validación

Existen dos paradigmas principales que permiten la aplicación de estas en un proyecto, las cuales son el análisis estático y el análisis dinámico.

El análisis estático necesita de la ayuda de una herramienta que analice la representación estática del sistema con el propósito de descubrir errores. Trata de la verificación de "productos" obtenidos durante el desarrollo del software.

Por lo contrario, el análisis dinámico implica normalmente la ejecución del código fuente del software con los datos de prueba, con el fin de evaluar en tiempo real los diferentes escenarios soportados por el programa. [2]

Las técnicas son las siguientes:

• Técnicas estáticas: comprende de las revisiones informales que son:
• Revisión del código.
• Programación en parejas.

y revisiones formales:

• Planificación.
• Familiarización.
• Preparación.
• Examen.
• Rehacer.
• Seguimiento.
• Técnicas dinámicas.
• Caja Negra y Caja Blanca.
• Las pruebas del sistema:
• Pruebas de integración.
• Pruebas de entregas.
• Pruebas de rendimiento.
• Las pruebas de componentes:
• Métodos o funciones individuales.
• Clases de objeto.

Referencias

[1] Ton van Schijndel, Dré Robben, “TPI, CMMI and Testing”, Sogeti Nederland B.V.

[2] Hernández, J. Z. (2011). Análisis de los procesos de verificación y validación en las organizaciones software.

Automatización

En las pruebas de software, la automatización de pruebas es una de las actividades que presentan una mayor expectativa. La posibilidad de ejecutar las pruebas de software de manera desatendida, hace que las organizaciones deshagan sus esperanzas en la automatización como la solución ideal para abaratar los costes y acortar los tiempos de pruebas.

Sin embargo, poner en marcha la automatización no es una tarea sencilla. Es necesario salvar numerosas dificultades para poder llevar a cabo una automatización eficiente y que permita retornar la inversión realizada. Es importante fijar un conjunto de prácticas que agilicen las tareas de mantenimiento y construcción que aporten una cierta metodología a nuestro proceso de automatización.

Buenas Prácticas:
Los productos de la Automatización deben mantenerse organizados. Los Scripts, ficheros de datos, aplicaciones de soporte, documentación, ficheros de configuración, etc... Deben almacenarse en un sistema de directorios y carpetas que permitan su direccionamiento rápido.
La organización puede depender de los objetivos. Podemos organizar nuestra infraestructura de directorios por aplicación, por plan de pruebas, por sistema y demás.

En la sección de modularización los casos de prueba automatizados pueden modularizarse en base a librerías que realicen funcionalidades más sencillas, de esa forma se agilizará el mantenimiento de los casos.
También es posible construir librerías de propósito general que apliquen a todos nuestros casos automatizados con indepencia de la aplicación o proceso. Ejemplos de librerías de propósito general son:
* Control de errores.
* Escritura/lectura de ficheros de datos.

Ahora bien, tenemos también el aspecto de robustez que en casi de que se produzca un error no controlado durante la ejecución, la lógica del caso de prueba debe ser capaz de finalizar y dejar el estado del equipo de ejecución estable y listo para continuar con un nuevo caso de prueba.
Una posibilidad es comprobar el estado de la maqueta al comenzar una ejecución, forzando el cierre de aquellas aplicaciones que se encuentren abiertas o elevar para los servicios necesarios.

Para el sistema de trazas la información que debe aportar un caso de prueba debe ser fiable. En caso de fallo debe informar de manera concreta de lo que ha ocurrido.
Completar la construcción de los casos de prueba con un sistema de trazas que aportan toda la información o suministrar la captura de la pantalla en el momento del error, pueden ayudar a ganar confianza en los casos automatizados.

En la flexibilidad los casos de prueba automatizados se deben preparar teniendo en cuenta posibles cambios.
Una opción es parametrizar aquellos datos susceptibles de cambios: rutas de acceso, identificadores de usuarios...

En el mantenimiento de los equipos de ejecución la ejecución de casos automáticos suele ser una tarea estresante para los equipos donde corren los casos. Es recomendable programar tareas de mantenimiento como reinicios periódicos, eliminación de ficheros temporales, desfragmentación de discos, entre otros.




Referencias:
[1] González, J. (2017). Buenas Prácticas en la Automatización de Pruebas. [online] Qatecnico.blogspot.com. Available at: http://qatecnico.blogspot.com/2011/08/buenas-practicas-en-la-automatizacion.html [Accessed 25 Oct. 2017].

Plan de Pruebas en el Desarrollo del Software

Plan de Pruebas

El propósito del plan de pruebas es desarrollar el alcance, el enfoque, los recursos requeridos, calendarios, responsables y el manejo de riesgos de un proceso de pruebas. Es posible manejar un plan global que abarque los distintos tipos de pruebas como lo son la verificación e integración.

El módulo del plan de pruebas es un instrumento muy útil para dar estructura tanto al proceso de pruebas como a la documentación de las mismas es el plan de pruebas.[2]

Algunos aspectos que se deben contemplar para un plan de pruebas son los siguientes:

1) Identificar el plan: se debe permitir relacionar con el alcance. Como todo artefacto del desarrollo, está sujeto a control de configuración, por lo que debe distinguirse adicional-mente la versión y fecha del plan.

2) Alcance: Indica el tipo de prueba y las propiedades o elementos del software a ser probado.

3) Items por probar: Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan. Por un lado, es difícil y riesgoso probar una configuración que aún reporta fallas; por otro lado, si esperamos a que todos los módulos estén perfectos, puede que detectemos fallas graves demasiado tarde.

4) Estrategia: Describe la técnica, patrón o herramienta que se pueda utilizar en el diseño de los casos de prueba. Como por ejemplo en el caso de pruebas unitarias de un procedimiento, esta sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la pre-condición". En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar. La estrategia también explica el grado de automatización que se exigirá, tanto para la generación de casos de prueba como para su ejecución.

5) Caracterización de la configuración: Hace de forna explícita las condiciones bajo las cuales, el plan debe ser suspendido-repetido-culminado.
En algunas circunstancias el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado. Al corregirse los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe explicarse a partir de qué punto, ya que puede ser tan simples como aprobar el número mínimo de casos de prueba diseñados o tan complejo como tomar en cuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebas y la tasa de detección de fallas.

6) Tangibles: En este caso los documentos a entregarse al culminar el proceso previsto por el plan deben estar de la mayor forma posible bien estructurados.

7) Procedimientos especiales: Identifica el grado de las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier habilidad especial que se requiere.

8) Recursos: Se deben identificar las propiedades necesarias y deseables del ambiente de prueba, incluyendo las características del hardware, el software de sistemas. Cualquier otro software necesario para llevar a cabo las pruebas, así como la colocación específica del software a probar.

9) Calendarios: Esta parte describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar. Se puede realizar con diagramas como el diagrama de Gantt.

10) Manejo de riesgos: Identifica los riesgos en el plan, las acciones que lo solucionan y la contingencia de estos.

11) Responsables: Especifica quién es el responsable de cada una de las tareas previstas en el plan.[1]

Plan de Pruebas - IEEE 829
La estructura de un plan de pruebas en este tipo de estándar es el siguiente:

1- Introducción
2-Items de pruebas
3-Supuestos
4-Características sujetas a pruebas
5-Características No sujetas a pruebas
6-Estrategia de prueba
7-Criterios de éxito/fracaso
8-Criterios de suspensión/devolución
9-Entregables de las pruebas
10-Tareas de la etapa de prueba
11-Recursos:
        Recursos hardware
       Recursos software
       Herramientas de soporte
12) Roles y responsabilidades
13) Riesgos del proyecto de pruebas
14) Dotación de personal y formación
15)Cronograma/Calendario.
16)Aprobación




Referencias:

[1] Obtenido de: http://www.calidadysoftware.com/testing.php
[2] Obtenido de: http://www.pruebasdesoftware.com/plandeprueba.htm

Cero Defectos del Software

En esta nueva entrada les estaré comentado acerca del "Cero Defectos" del software. Todo sobre este.

El Cero Defectos es un programa de la mejora de la calidad que tiene como objetivo principal que las cosas se hagan bien desde la primera vez. Este toma en cuanta la participación del operador, así como la forma de involucrarse con el producto y el proceso, y mediante una evaluación comprender las consecuencias que puede traer algún error.

Philip Crosby nació en Wheeling, Virginia Occidental el 18 de junio de 1926. Fue un empresario estadounidense, autor que contribuyó a la Teoría Gerencial y a las prácticas de la gestión de la calidad. Hasta su muerte se dedicó a la calidad.
Un dato muy importante es que fundó Philip Crosby Associates (PCA) con sede en Winter Park, Florida, y durante los diez años seguidos la convirtió en una organización con 300 empleados alrededor del mundo y con $80 millones con ganancias. P.C.A. enseñó a la gerencia cómo establecer una cultura preventiva para lograr realizar las cosas bien y a la primera. GM, Chrysler, Motorola, Xerox, muchos hospitales, y cientos de corporaciones alrededor del mundo vinieron a P.C.A. para entender la Administración de la calidad. Todavía enseña en 16 lenguajes alrededor del mundo.[1]

Componentes Básicos para la resolución de problemas y mejoramiento de la calidad:

1. Cuatro Fundamentos:
1. Pleno involucra-miento de la dirección.
2. Administración profesional de la calidad.
3. Programas originales.
4. Reconocimiento.
2. Los 5 principios de la dirección de calidad.
1. La calidad significa cumplir los requisitos del funcionamiento del producto.
2. No existen problemas de calidad.
3. No existen ahorros al sacrificar la calidad.
4. La calidad medida de desempeño es el costo de la calidad. 
5. El único estándar de desempeño es el cero defectos.
3. Los 14 pasos de Crosby los cuales son:
1. Asegúrese de que la dirección esté comprometida con la calidad.
2. Forme equipos para el mejoramiento de la calidad con representantes de cada departamento.
3. Determine como analizar dónde se presentan los problemas de calidad actuales y potenciales.
4. Evalúe el coste de la calidad y explique su utilización como una herramienta de administración.
5. Incremente la información acerca de la calidad y el interés personal de todos los empleados.
6. Tome medidas formales para corregir los problemas identificados a lo largo de los pasos previos.
7. Instituya una comisión para el programa "Cero Defectos".
8. Instruya a todos los empleados para que cumplan con su parte en el programa de mejoramiento de la calidad.
9. Organice una "jornada de los Cero Defectos" para que todos los empleados se den cuenta de que ha habido un cambio.
10. Aliente a los individuos para que se fijen metas de mejoramiento para sí mismos y para sus grupos.
11. Aliente al personal para que comunique a la dirección los obstáculos que enfrenta en la persecución de sus metas de mejoramiento.
12. Reconozca y valore a aquellos que participan activamente en el programa.
13. Establezca consejos de calidad a fin de mantener informado al personal en forma regular.
14. Repita todo para enfatizar que el programa de mejoramiento de la calidad no finaliza jamás. 

Ventajas: 

• Se concentra el esfuerzo en ámbitos administrativos y de procedimientos competitivos.
• Consiguen mejoras en un corto plazo y resultados meramente visibles.
• Si existe reducción de productos defectuosos por consecuencia hay una reducción de los costos.
• Incrementa la productividad y dirige a la organización hacia la hacia la competitividad.
• Contribuye a la adaptación en los procesos a los avances tecnológicos y permite alinear procesos repetitivos.

Desventajas:

• Se pierde la perspectiva de la interdependencia entre los miembros de la empresa. 
• El mejoramiento continuo se hace a un proceso muy largo.
• Requiere de un cambio en toda la organización y hay que hacer inversiones importantes

Una aplicación es el sistema "jidoka", que es la automatización  con la mano humana de que el sistema permita tener su propio auto-control de oportunidad.

Referencias:

[1] Obtenido de: http://www.pablogiugni.com.ar/httpwwwpablogiugnicomarp106/ 

Cobertura de Pruebas

En este blog les estaré brindando información acerca de la cobertura de las pruebas de software, tema sumamente interesante con respecto al aseguramiento de la calidad del software. 

Para iniciar, debemos tener claro el termino de cobertura, la cual es un concepto relacionado con la medición de la relación entre factores, y se la define como el grado en el cual un elemento específico es sometido a una batería de pruebas, donde el "elemento" de la cobertura puede ser cualquier cosa que debamos cubrir durante las pruebas.[1]

Es decir, se debe determinar cómo se vincula lo que se esta probando con el pedido del cliente y expresado en el requerimiento original, convertido tal vez en especificación funcional.

Es por esto que, de la medición que se realice, resultará el grado de cobertura en la que las pruebas están dando respuesta a todo lo que se necesita cubrir.

Un primer análisis que resulta de esta medición es conocer en qué área hace falta agregar más cobertura, como por ejemplo:

• Para las pruebas basadas en requisitos, se debe planificar medir contra las especificaciones.
• Para las pruebas basadas en riesgos, debemos planificar medir contra aquellos eventos de amenazas que podamos detectar.
• Para las pruebas basadas en ínter-operabilidad, se debe planificar medir la cobertura de las configuraciones y las interfaces. 

Si se logra alcanzar una cobertura de caja negra del 100%, y una cobertura de sentencias del 100%, por lo tanto podemos pasar a la siguiente fase: la cual es prueba de condiciones.

Otra forma de que pueda suceder es de que partes del código no hayan sido ejecutadas jamás (cobertura de sentencias inferior al 100%), por lo que para estos casos habrá que realizar más pruebas buscando que se ejecuten todas y cada una de las sentencias del programa. En este sentido, puede que hayamos conseguido una cobertura elevada de sentencias. pero tal ves nos estemos contemplando las ramas condicionales.

ramas condicionales: x=0; if(y<100){x++}

Si se considera durante las pruebas un valor de "y" inferior a 100, se habrán ejecutado todas las líneas; pero nunca la variante de que x no se incremente.

Se habla de una cobertura de ramas al 100% cuando se ha ejercido todas y cada una de las posibles vías de ejecución controladas por condiciones.

La cobertura de ramas es indiscutiblemente deseable; pero habitualmente es un objetivo excesivamente costoso de alcanzar en su plenitud, salvo que se haga con herramientas de automatización.

Por lo tanto, muchas personas recomiendan: 

• Realizar pruebas de caja negra hasta alcanzar una cobertura funcional del 100% (idealmente).
• Inspeccionar código ejecutado y agregar condiciones para someter a prueba a aquellas partes del programa no ejecutadas.
• Inspeccionar condiciones con un cierto grado de complejidad "difíciles" del código para intentar forzar variedad.

La medición de la cobertura es algo muy común en las pruebas de unidad. El objetivo de los desarrolladores es agregar los casos de unidad necesarios para lograr un 100% de cobertura. sin embargo, no es algo muy habitual cuando se hacen pruebas funcionales. Algunos equipos de calidad mantienen un reporte de áreas donde cada probador marca que área probó, pero no hay seguridad de que probaron el 100% de las líneas de código que el desarrollador puso en esa área.[2]

Es por esto que el equipo de calidad requiere manejar un buid que les permita medir la cobertura, de la misma manera que lo hacen los desarrolladores en las pruebas unitarias.

BIBLIOGRAFÍA

[1] Terrera, G. (1 de 09 de 2014). Testing Baires. Obtenido de https://testingbaires.com/sobre-cobertura-en-testing-parte-1/

[2] Guillén, C. (17 de 11 de 2014). Testing Software . Obtenido de http://www.testingsoft.com/espanol/2014/11/17/como-medir-la-cobertura-de-las-pruebas-funcionales-con-jacoco/

Pruebas Exploratorias

En esta nueva entrada les estaré brindando información acerca de las Pruebas Exploratorias, datos realmente interesantes desde quien las dio a conocer hasta como es que realmente funcionan.

El término "Testing Exploratorio" fue dado a conocer por Cem Kaner. Y se tiene que ver con ejecutar las pruebas a en que se va pensando en ellas, sin tener que tener que invertir mucho tiempo en preparar o explicar las pruebas, confiando más que todo en la parte del instinto. Estas pruebas exploratorias se pueden definir como el aprendizaje, el diseño de casos de prueba y la ejecución de de las pruebas de forma simultánea. 

En otras palabras, es una técnica de de pruebas en la cual quien prueba controla activamente el diseño mientras son realizadas, y utiliza la información en la exploración para diseñar nuevas y mejores pruebas.[1]

Una estrategia básica para realizar testing exploratorio es concebir un plan de ataque general, pero que permita desviarse de él por periodos cortos de tiempo e intereses diversos. Cem Kaner lo denomina el principio del "tour bus", las personas bajan del bus y conocen los alrededores con visiones variadas. La clave es no perderse el tour entero[1].

El éxito o el fracaso del testing exploratorio está íntimamente ligado con lo que sucede en la mente del tester. Algunas habilidades deseables en los testers son la capacidad de analizar el producto y evaluar los riesgos, utilizar herramientas y tener un pensamiento crítico acerca de lo que se sabe al momento de diseñar las pruebas. También es importante que los testers tengan la capacidad de distinguir lo observado de lo inferido; ya que las inferencias podrían inducirlos a no realizar pruebas que evidencien vulnerabilidades del producto. El uso de heurísticas desempeña un rol importante en la producción de ideas variadas. Una heurísticaes un mecanismo mental para generar pruebas variadas y acordes a las características del producto que se está probando, por lo que es deseable que los testers las tengan presentes al momento de realizar testing exploratorio [2].

¿Y para qué sirve el testing exploratorio?

Las pruebas exploratorias deben ser como complemento a todas los demás tipos de pruebas existentes.

Es bastante importante para: 

* Profundizar y obtener feedback rápido sobre algo concreto.

* Aprender sobre la aplicación.

* Si ya cubres una parte del testing con automatización, testeo y verificación manual de funcionalidades etc. y quieres buscar bugs más complejos.

* Mejorar la documentación de la aplicación, de los casos de prueba o los scripts de automatización (ya que podemos usar la experiencia adquirida para mejorar la documentación de la aplicación, de los casos de prueba, etc.)[3].

El testing exploratorio requiere su planificación, limitación de tiempo y objetivo, no está reñido con documentar y hacerlo bien es más complicado[3].

Referencias:

[1] J. Bach, “Exploratory Testing Explained”, The Test Practicioner, 2002, Obtenido de: http://www.satisfice.com/articles/et-article.pdf

[2] Pérez, B., Pittier, A., Travieso, M., & Wodzislawski, M. (2007). Testing exploratorio en la práctica. CES.COM, 7.

[3] Garzas, J. (9 de Enero de 2015). javiergarzas.com. Obtenido de http://www.javiergarzas.com/2015/01/testing-exploratorio-10-min.html

Técnica: Análisis de Valores Límites (Caja Negra)

Para introducir un poco más con el tema de Caja Negra, les mostraré un video que me pareció atractivo y con la información necesaria para dar a conocer de donde proviene la idea de Caja Negra, y que no solo es esta, sino que también se cuenta con otro termino que es el de Caja Blanca, así que se los dejo para que, de una manera creativa visualicen el siguiente video animado y comprendan estos dos términos.

Ahora bien, habiendo interpretado los términos anteriores, les menciono que existen 3 tipos de técnicas que se que se pueden utilizar para diseñar las pruebas de Caja Negra, como lo son las siguientes:

1. Distribución de equivalencia: es una técnica de diseño de prueba de software que implica dividir los valores de entrada en particiones válidas e inválidas y seleccionar valores representativos de cada partición como datos de prueba.
2. Análisis de valores de límite: es una técnica de diseño de prueba de software que implica la determinación de límites para los valores de entrada y selección de valores que están en los límites y solo dentro / fuera de los límites como datos de prueba.
3. Representación gráfica de efectos de causa: es una técnica de diseño de prueba de software que implica identificar los casos (condiciones de salida), producir un gráfico de efecto de causa y generar casos de prueba en consecuencia.[1]

En esta ocasión nos enfocaremos en hablar a cerca de la técnica Análisis de Valores Límites de Caja Negra. Pero antes de iniciar, comprenderemos algunos términos: 

Valores Límites: 

•Esta técnica se encarga de probar la habilidad del programa para el manejo de datos que se encuentren en los límites aceptables.
•Esta es una técnica específicamente asociada con la técnica de equivalencia ya que el análisis se concentra solamente sobre la clase de equivalencia válida.

Análisis Valores Límites:

•El Análisis de valores límite es la técnica de diseño de pruebas de caja negra en la cual los casos de prueba son diseñados basándose en los valores límite.

Método de Análisis Valores Límites:

Este se basa en la evidencia experimental de que los errores suelen aparecer con mayor probabilidad en los extremos de los campos de entrada.
Un análisis de las condiciones límites de las clases de equivalencia aumenta la eficiencia de la prueba.

Este método utiliza un proceso para el análisis, los pasos son los siguientes:

1. Identificar la variable.
2. Identificar la(s) clase(s) válida(s). Para cada clase válida debemos identificar:
1. Valor inferior, valor menor al límite inferior, valor mayor al límite inferior.
   
2. Valor límite superior, valor menor al límite superior, valor mayor al límite superior.
   

      3. Crear un caso de prueba por cada valor identificado.

      4.Identificar el representante para cada caso.

Blibliografía:

[1] Black Box Testing. Obtenido de http://softwaretestingfundamentals.com/black-box-testing/

Revisiones Estáticas

 Beneficios de las Revisiones:

Es necesario buscar irregularidades tempranos en productos ya que estos se traducen como defectos en el producto final.

"Veamos una analogía con la arquitectura de edificios. Si en un plano el color de una línea indica su significado, una confusión en el color se traducirá en un error en el edificio. Por ejemplo, si el azul indica tuberías de agua y el amarillo cables eléctricos y el arquitecto comete un error usando el azul en una conducción eléctrica, los electricistas que usen el plano como guía para su trabajo no colocarán cables eléctricos mientras que los fontaneros colocarán tuberías de agua donde no debían ir." [1]

 El plano de un edificio es el artefacto equivalente al diseño de un producto software. Si un diseño tiene irregularidades, seguramente estas irregularidades se trasmitirán al código cuando los programadores usen ese diseño como guía para su trabajo.


Es por esto que la detección temprana de errores conlleva grandes beneficios. Si las revisiones únicamente se aplican al código mejoran la calidad y producen ahorros en los costos del proyecto. Pero más ahorros habrán si se da una revisión temprana del desarrollo.

"Estudiando los resultados publicados sobre ahorros con las revisiones, puede afirmarse que la utilización de inspecciones de código produce un ahorro del 39% sobre el coste de detectar y corregir defectos, frente a únicamente utilizar la evaluación dinámica. Sin embargo, el ahorro es del 44% si se inspecciona también el diseño."[1]

 Las revisiones también proporcionan beneficios más generales. Entre éstos se pueden citar los siguientes: evaluación del progreso del proyecto, potencia las capacidades de los participantes, mejoran la comunicación entre el equipo de desarrollo, aumentando su motivación, pues los productos paran a ser documentos públicos, proporciona aprendizaje, retroalimentación y prevención, forma y educa a los participantes.

 Objetivos de la Evaluación Estática
La evaluación estática de los productos que se vayan generar en el desarrollo de software como lo pueden ser: especificación de requisitos, modelos conceptuales, diseño, código, entre otros. Lo que pretende es comprobar su calidad. 

Los defectos que se buscan al evaluar estáticamente los productos de software son los siguientes: 

"• Para los requisitos: 
              o Corrección. Los requisitos especifican correctamente lo que el sistema debe hacer. Es                          decir, un requisito incorrecto es un requisito que no cumple bien su función. Puesto que la                    función de un requisito es indicar qué debe hacer el sistema, un requisito incorrecto será                      aquel que, o bien pide que el sistema haga algo que no es lo que debe hacer, o pide que                        haga algo que no deba hacer.               o Compleción. Especificación completamente el problema. Está especificado todo lo que                         tiene que hacer el sistema y no incluye nada que el sistema no deba hacer. En dos                                 palabras: no falta nada; no sobra nada Consistencia. No hay requisitos contradictorios.                     o Ambigüedad. Los requisitos no pueden estar sujetos a interpretación. Si fuese así, un                             mismo requisito puede ser interpretado de modo distinto por dos personas diferentes y, por                   tanto, crear dos sistemas distintos. Si esto es así, los requisitos pierden su valor pues dejan                  de cumplir su función (indicar qué debe hacer el sistema). Las ambigüedades provocan                        interpretación por parte de la persona que use o lea los requisitos. Por tanto, una                                    especificación debe carecer de ambigüedades.                                                                                      o Claridad. Se entiende claramente lo que está especificado. • Para el diseño:              o Corrección. El diseño no debe contener errores. Los errores de corrección se pueden referir                 a dos aspectos. Defectos de “escritura”, es decir, defectos en el uso de la notación de diseño                 empleada (el diseño contiene detalles prohibidos por la notación). Defectos con respecto a                   los requisitos: el diseño no realiza lo que el requisito establece. Hablando apropiadamente,                   los primeros son los puros defectos de corrección, mientras que los segundos son defectos                   de validez.              o Compleción. El diseño debe estar completo. Ya sea que diseña todo el sistema marcado por                 los requisitos; ya sea no diseñando ninguna parte no indicada en los requisitos. De nuevo,                   nada falta, nada sobra.              o Consistencia. Al igual que en los requisitos, el diseño debe ser consistente entre todas sus                     partes. No puede indicarse algo en una parte del diseño, y lo contrario en otra.              o Factibilidad. El diseño debe ser realizable. Debe poderse implementar.              o Trazabilidad. Se debe poder navegar desde un requisito hasta el fragmento de diseño donde                 éste se encuentra representado. • Código Fuente:              o Corrección. El código no debe contener errores. Los errores de corrección se pueden referir                 a dos aspectos. Defectos de “escritura”, es decir, lo que habitualmente se conoce por                             “programa que no funciona”. Por ejemplo, bucles infinitos, variable definida de un tipo                       pero utilizada de otro, contador que se sale de las dimensiones de un array, etc. Defectos                       con respecto al diseño: el diseño no realiza lo que el diseño establece." [1]

 Técnicas de Evaluación Estática

Las técnicas de Evaluación estática de artefactos del desarrollo se las conoce de modo genérico por Revisiones.  Las revisiones pretenden detectar manualmente defectos en cualquier producto del desarrollo. Por manualmente queremos decir que el producto en cuestión (sea requisito, diseño, código, etc.) está impreso en papel y los revisores están analizando ese producto mediante la lectura del mismo, sin ejecutarlo.

Algunas de esas Revisiones son: 

"• Revisiones informales, también llamadas inadecuadamente sólo Revisiones (lo cual genera confusión con el nombre genérico de todas estas técnicas). Las Revisiones Informales no dejan de ser un intercambio de opiniones entre los participantes.
 • Revisiones formales o Inspecciones. En las Revisiones Formales, los participantes son responsables de la fiabilidad de la evaluación, y generan un informe que refleja el acto de la revisión. Por tanto, sólo consideramos aquí como técnica de evaluación las revisiones formales, puesto que las informales podemos considerarlas un antepasado poco evolucionado de esta misma técnica.
• Walkthrough. Es una revisión que consiste en simular la ejecución de casos de prueba para el programa que se está evaluando. No existe traducción exacta en español y a menudo se usa el término en ingles. Quizás la mejor traducción porque ilustra muy bien la idea es Recorrido. De hecho, con los walkthrough se recorre el programa imitando lo que haría la computadora.
• Auditorias. Las auditorias contrastan los artefactos generados durante el desarrollo con estándares, generales o de la organización. Típicamente pretenden comprobar formatos de documentos, inclusión de toda la información necsaria, etc. Es decir, no se tratan de comprobaciones técnicas, sino de gestión o administración del proyecto."[1]

 Blibliografía:

[1] Obtenido de: http://webcache.googleusercontent.com/search?q=cache:nwRR7iLakiEJ:www.lsi.us.es/docencia/get.php%3Fid%3D360+&cd=4&hl=es&ct=clnk

Costos de detección y reparación de defectos de un proyecto

En la elaboración de un proyecto se pueden dar "X" cantidad de errores. Pero el problema no es que existan errores, ya que en la gran mayoría de los proyectos se va a dar, sino más bien es en que etapa se está dando este error. Se tienen algunas etapas en la que estos errores pueden aparecer, como lo son las que se muestran en el video presentado: Inicio del proyecto, organización y preparación, realización del trabajo, mantenimiento.  


Ahora bien, según en donde ese error sea ubicado en alguna de las etapas comentadas, va a variar a el costo en que este error será reparado. Como se muestra en el video, se observa que mientras ese error se muestra más al inicio será un costo menor a que se repare o modifique algo en el proyecto en las fases de fiscalización.
Es por esto que realizar una buena verificación de los requerimientos o requisitos con los que se va a implementar el proyecto para que lo principal en la historia de todo proyecto se dé (el costo) sea relativamente menor.


Se mencionado en el video un aproximado de $50 la modificación de una línea de código antes de la liberación del proyecto. Por lo contrario de la reparación o modificación del defecto encontrado después de la liberación, ya que con esto puede costar aprox. $4,000, costando 80 a 100 veces más. Con este dato nos podemos dar una idea más clara de lo perjudicial que puede resultar la reparación de un defecto encontrado en una etapa de fiscalización del proyecto.



Bibliografía
[liderdeproyecto].(2015, setiembre 30).Dirección de proyectos: ¿Cuánto cuesta repara un error?[Archivo de video]. Recuperado de https://www.youtube.com/watch?v=7i5Ugy7ys50

IEEE 1044 (2009)

El acrónimo IEEE cuyo significado es Instituto de Ingeniería Eléctrica y Electrónica es una asociación que se dedica a la estandarización de distintas áreas de tecnología, esta tiene muchos éxitos en el mercado debido a lo eficaz que resultan sus normas .

Los éxitos del IEEE incluyen:
• Resultados financieros excepcionales, con superávit neto de US $ 71,1
Millones con un superávit operativo de 21,4 millones de dólares EE.UU.
Y ganancias netas de inversión de US $ 50,2 millones.
• Un aumento del 7,6% en las ventas de productos,
Entre los suscriptores académicos de la
América del Norte y un notable crecimiento de IEEE / IET
Biblioteca electrónica en Brasil, China, India y el Sur
África, entre otras naciones.
• Un récord histórico de 397.001 miembros
En la mayoría de los grados de membresía y en IEEE
Miembros de la sociedad.
• Un récord de 1.077 conferencias técnicas
Patrocinado o copatrocinado por IEEE.(Reid & James, 2009)

El IEEE cuenta con treinta y ocho sociedades que están orientadas a trabajo distinto.  Las sociedades realizan publicaciones especializadas, redes de negocio entre otros muchos servicios más.
Además, cuenta con una serie de normas o estándares diseñadas para un tipo de trabajo específico.
Ahora hablaremos de IEEE 1044, esta norma proporciona el conjunto básico de atributos para la clasificación de fallas y defectos.(IEEE, 2009)

Esta norma puede ser utilizada por cualquier tipo de software, a esto también se le incluye la posibilidad de ser utilizado en sistemas operativos, aplicaciones, firmware y sistemas de gestión.

Esta norma busca definir un vocabulario común en el cual diferentes personas u organizaciones puedan tener una comunicación productiva acerca de algunas anomalías que se pueden dar en el software que al que se le esté atendiendo y establecer técnicas de la industria para analizar defectos del software mismo y algunos datos de fallas.

IEEE 1044 cuenta con un proceso de clasificación en la que la organización definirá su proceso de clasificación de la siguiente manera:
A) La meta o objetivos a alcanzar mediante la clasificación de los defectos y fallos.
B) La norma de referencia (por ejemplo, como se describe en una especificación, contrato o plan) utilizada para determinar qué comportamientos de sistema / software constituyen un fallo.
C) Cómo se resolverán los desacuerdos o conflictos relacionados con las decisiones de clasificación.
D) Cuando la clasificación debe comenzar y terminar dentro del ciclo de vida del proyecto o del producto.
E) Los valores específicos del proyecto, del producto o de la organización que son elegibles para la asignación a atributos de clasificación (véanse ejemplos en la Tabla A.1 y Tabla A.2).
F) Quién asignará valores a los atributos de clasificación enumerados en la Tabla 3 y Tabla 4 para cada defecto y fracaso descubierto, respectivamente.
G) Dónde y cómo se deben mantener los datos de clasificación.(Reid & James, 2009)

Además, se cuenta con una clasificación estructurada de defectos. En la tabla se registran los valores de todos los atributos de defectos. Los valores son de forma informativa. Es de forma más efectiva o común que los valores de los atributos sean registrados a medida que se encarguen del defecto. El estado de este defecto puede ser uno de los siguientes tres estados: Insertado, Detectado o Removido.

Bibliografía

IEEE. (2009). IEEE STANDART classification FOR SOFTWARE ANOMALIES. New York, NY 10016-5997, USA.

Reid, J., & James, E. (2009). CELEBRATIN 125 YEARS OF ENGINEERING THE FUTURE. IEEE Corporate Strategy, 3.

El caso del Aeropuerto de Denver

En la época de los 80 a 90 se dio la construcción del aeropuerto internacional de Denver, Colorado en Estados Unidos. Exactamente este aeropuerto se encuentra a 25 kilómetros del centro de Denver. Queriéndose dar, en este aeropuerto, la implementación de un sistema que se encargaría del equipaje automatizado más grande del mundo. El aeropuerto tendría una capacidad de 50 millones de pasajeros al año.

Como se esperaba tanta cantidad de personas anualmente, claramente debían resolver un problema, el cual sería ¿cómo lidiar con tantos equipajes?, por lo que este sistema lo resolvería realizando eficientemente la entrega del equipaje automatizado entre el check-in para recoger al momento de llegar.

El aeropuerto tenía un estimado de costo alrededor de los $5 millones. pero sucedió algo, antes del final de 1994, el Aeropuerto de Denver encontró con una deuda en bonos de más de $3.8 mil millones debido al problema que fue encontrado en la ejecución del sistema de equipajes. Dando como resultado una suma de $500 millones. En la fecha prevista, todo estaba listo menos un sistema software llamado Sistema Automático de Gestión de Equipajes (Automatic Baggage Handling System -ABHS). Un artículo en Scientific American achacaba el retraso al proceso software, y proponía como solución aumentar el nivel CMM (pero un proceso software mejorado no elimina las incertidumbres). (DeMarco & Lister, 2013)

Un análisis en profundidad habría descubierto razones de otro tipo. Imaginemos el siguiente interrogatorio ficticio al comité de dirección del proyecto:

·                     Pregunta: ¿Por qué no pudo abrir el aeropuerto sin el ABHS?

·                     Respuesta: El software estaba en el camino crítico. Sin este software, no se podía atender a los pasajeros ni un solo día.

·                     Pregunta: ¿Por qué ABHS estaba en el camino crítico?  Porque no se podía mover el equipaje sin el sistema: Tele-carritos, lectores de código de barras, dispositivos de escaneo, descargadores automáticos.

·                     Pregunta: ¿No hay más alternativas para mover el equipaje? Sí. Mozos empujando carritos y el método tradicional en los aeropuertos de cintas transportadoras y camiones pequeños.

·                     Pregunta: Si ABHS no estaba listo a tiempo ¿por qué no se usaron los métodos alternativos? Los túneles de los tele-carritos eran muy bajos.

·                     Pregunta: ¿No se podían rediseñar los túneles? Sí, pero no había tiempo. Cuando se descubrió que ABHS se retrasaba ya estaban construidos, y el tiempo de rehabilitación se estimó mayor que el necesario para perfeccionar el software.

·                     Pregunta: ¿Se sabía de alguna experiencia previa similar? 

·                     Respuesta: El aeropuerto de Munich había instalado un piloto de ABHS parecido.

·                     Pregunta: ¿El equipo visitó el proyecto de Munich? Si es así, ¿qué aprendió? 

·                     Respuesta: Sí. El equipo de Munich asignó 2 años de pruebas y convivencia con el sistema antiguo durante 6 meses para afinar el sistema nuevo. Aconsejaron hacer lo mismo.

·                     Pregunta: ¿La dirección del proyecto siguió este consejo? 

·                     Respuesta: No había tiempo.

·                     Pregunta: ¿El equipo avisó suficientemente del retraso inminente? 

·                     Respuesta: Ya los licitantes advirtieron del riesgo en sus propuestas. Se contrató a BAE Automated Systems porque ofrecían menor plazo. Durante la ejecución, el proveedor advirtió repetidas veces del potencial retraso, al introducirse cada mes nuevos cambios. Todas las partes eran conscientes de que se trataba de hacer un proyecto de 4 años en 2. Todas estas advertencias fueron ignoradas. (Barato, 2012)

En conclusión, este fracaso se dio ya que la gestión de riesgos no se planeó de la mejor forma, en la parte de prueba y pensar que todo funcionaría a la perfección si prueba anterior. Si esto se hubiera previsto a tiempo se pudo retrasar la entrega, pero no se darían tanto gasto como la suma exagerada que se terminó dando por esta falla.

Bibliografía

Barato, J. (15 de 3 de 2012). El caso del Aeropuerto de Denver: Los Hábitos de un Director de Proyectos Eficaz. Obtenido de http://jose-barato.blogspot.com/2012/04/el-caso-del-aeropuerto-de-denver.html

DeMarco, T., & Lister, T. (2013). Waltzing whit Bears: Managing risk on software projects. Addison-Wesley.