miércoles, 20 de mayo de 2015

Cap 3 - QA&V Ciclo de vida del Desarrollo de Software Parte - 1

QA&V Ciclo de vida del Desarrollo de Software

(QA&V Software Development Life Cycle)

En esta sección se hablará de los tipos de ciclos que existen en el desarrollo de ciclo de vida del software.

3.1 Modelos de ciclo de vida de las pruebas de software.


El ciclo de vida de las pruebas de software es requerido para tener una idea clara del resultado que se tendrá al aplicar las pruebas en un análisis real, en resumen es el proceso de desarrollo de información de un sistema con base en  la investigación, análisis, diseño, implementación, pruebas, evaluación y mantenimiento, con el objetivo de disminuir los defectos, optimizar los recursos y mejorar los tiempos de desarrollo.

3.2 Modelos Clásicos


Por ciclo de vida del software, entendemos la sucesión de etapas por las que pasa el software desde que un nuevo proyecto es concebido hasta que se deja de usar. Estas etapas representan el ciclo de actividades involucradas en el desarrollo, uso y mantenimiento de sistemas de software, además de llevar asociadas una serie de documentos que serán la salida de cada una de estas fases y servirán de entrada en la fase siguiente. A continuación se muestran los modelos clásicos de ciclo de vida del software.

                           
                                                    Fuente: (Bedoya, 2012).


3.2.1 Cascada

Es el ciclo de vida original, siendo de modo secuencial, es muy poco flexible a comparación de los demás ciclos de vida, es utilizado usualmente en proyectos donde los requerimientos están bien definidos y establecidos por el usuario, es decir con óptimos requerimientos. (Ángel, 2013)
La Ilustración 3 muestra la representación gráfica del ciclo de vida en cascada, y se puede apreciar que es un proceso de desarrollo secuencial.

                              


Ilustración 3 Ciclo de vida en cascada. 
Fuente: Elaboración Propia.

A continuación se desglosan los pasos generales y su objetivo en el proceso del modelo en cascada:


·         Requerimientos, análisis y definición de fases (Requirements):

·         Todos los requerimientos del sistema que serán desarrollados son capturados en esta fase.
·         Los requerimientos son un grupo de funcionalidades y restricciones que el usuario final pide para el funcionamiento del sistema.
·         Los requerimientos son tomados del usuario final a través de la consulta.
·         Estos requerimientos son analizados para su validación y la posibilidad de ser incorporados en los requerimientos del sistema que se desarrollará.
·         Finalmente, las especificaciones de los requerimientos son generados, con la finalidad de ser una guía de la siguiente fase del modelo.

·         Fase de diseño (Design):

·         Antes de comenzar con la codificación del programa, es de suma importancia entender lo que se va a crear.
·         Los requerimientos específicos que son generados en la primera fase, son estudiados en esta fase y se prepara el diseño del sistema.
·         El diseño del sistema ayuda en las especificaciones de los requerimientos del hardware y del software, y apoya a definir la arquitectura total del sistema, creando la entrada de la siguiente fase del ciclo de vida.



·         Fase de construcción (Construction and Testing):

·         Después de recibir los documentos de diseño, el trabajo es dividido en módulos y se comienza a codificar.
·         El sistema primero se desarrolla en pequeñas partes, llamadas unidades, que posteriormente son integradas en la siguiente fase.
·         Estas unidades son desarrolladas y probadas, unidad por unidad, con la finalidad de verificar si los módulos cumplen con las especificaciones de los requerimientos.

·          Fase de pruebas (Integration and System testing):

·         Las unidades son integradas en un sistema completo durante la fase de integración, son probadas y se revisa que todos los módulos funcionen correctamente con otros módulos, de acuerdo a las especificaciones.
·         Después de que las pruebas del software son completadas satisfactoriamente, es liberado al cliente.

·         Fase de operación y mantenimiento (Operation and Maintenance):

·         Estas fases virtualmente nunca terminan o son muy largas.
·         Generalmente los problemas en el desarrollo del sistema vienen después de que el software es liberado al cliente.

3.2.2 Cascada Modificado.



Este modelo es la combinación entre Takeuchi y Nonaka, y es similar al modelo de cascada, excepto en las fases de retroalimentación, con la variación de que la prueba es aplicada a cada una de las fases del ciclo de vida. (Hernandez, 2009)
La Ilustración 4 muestra el modelo de ciclo de vida en Cascada Modificado:






Ilustración 4 Ciclo de vida en cascada modificado.

Fuente: Elaboración Propia.


·         Ventajas:

·         Simple y sencillo de usar.
·         Fácil de manejar aun cuando el modelo es rígido al trabajar.
·         Las fases son procesadas y completadas una a una.
·         Trabaja bien en proyectos pequeños donde los requerimientos son muy bien comprendidos.

·         Desventajas:


·         El tiempo de desarrollo del sistema puede terminar mucho antes de lo planeado.
·         El software solo se utiliza hasta el final del desarrollo.
·         Existen una gran cantidad de riesgo e incertidumbres.

·         Se pasará hasta la siguiente etapa cuando se concluya la fase en la que se encuentre.

3.2.3 Modelo Incremental/Iterativo:



El modelo incremental es una forma evolucionada del modelo de cascada, el producto es diseñado, implementado, integrado y probado en una serie de pasos incrementales y este modelo de desarrollo de software es muy popular y es comúnmente utilizado en muchas compañías comerciales y sistemas de ventas.





Ilustración 5 Ciclo de vida Iterativo/Incremental.
Fuente: Elaboración Propia.



·         Ventajas:

·         Genera que el trabajo en el desarrollo de software sea rápido y sencillo.
·         Es más flexible el costo al cambiar los calendarios y requerimientos.
·         Las pruebas y la depuración son más sencillas.
·         El manejo de los riesgos es más sencillo.
·         Desventajas:

·         Cada fase de la iteración es rígida y no se puede llevar en paralelo con otras fases.

·         Los problemas son muchos cuando los requerimientos no están bien comprendidos, generando retrasos y problemas.

3.2.4 Modelo Espiral:
Es una combinación de elementos y procesos, así como también de diseño y prototipos.
En un esfuerzo de combinar las ventajas de los conceptos de top-down y bottom-up, combina las ideas del modelo iterativo y sistemático, controlado por aspectos de desarrollo en cascada.
El modelo espiral es usualmente eficiente en proyectos largos, cansados y complicados.
Este modelo está basado en la constante mejora del producto indicada por:
  • Requerimientos.
  • Análisis.
  • Diseño del sistema y software.
  • Implementación.
En cada iteración alrededor del ciclo, los productos son extensiones de productos anteriores, tiene mucho parecido al modelo de cascada, sin embargo este modelo maneja riesgos y está construido por elaboración de prototipos y simulaciones.  (Ángel, 2013)      

             



Ilustración 6 Ciclo de vida Espiral.
Fuente: (Coleman, 2010).



Ilustración 7 Partes esenciales del ciclo de vida en espiral.
Fuente: Elaboración Propia.



·         Ventajas:

·         Una alta detección y análisis de riegos.
·         En proyectos largos y de misiones críticas, su desempeño es muy bueno.
·         El software se produce al mismo tiempo que se desarrolla el ciclo de vida para mejorarlo.
·         Desventajas:

·         Es un modelo muy caro de usar.
·         Para el análisis de riesgos es requerido un alto grado de experiencia.
·         Para que el proyecto sea terminado correctamente depende directamente del análisis de riesgos.
·         No es efectivo en proyectos pequeños.


Dejare pendiente algunos otros modelos para la siguiente publicación.

Te invito a dejar tus comentarios para mejorar la información.
Gracias.

Autor: Luis Eduardo Fernandez Rocha (Contacto Linkedin)

miércoles, 6 de mayo de 2015

Cap 2 - QA&V Tipos de pruebas

QA&V Tipos de pruebas

(QA&V Test types)

Como continuación a la introducción publicada anteriormente les dejo los tipos de prueba existentes.
Dependiendo la complejidad y los requerimientos del cliente se deben tomar en cuenta diferentes tipos de pruebas, a continuación se hace mención de los más relevantes:

  • Caja negra:

Estas pruebas se concentran en lo que se espera de un módulo, es decir pretenden encontrar casos, en los que el módulo no se ocupa de su especificación.  Este tipo de pruebas no está basado en el conocimiento o diseño interno, se encarga de verificar la correcta funcionalidad del sistema.

  • Caja blanca:
En este tipo de prueba siempre se está examinando el código, están basadas en la lógica interna de la aplicación, con estas pruebas se desea “probarlo todo”,  hace una cobertura de declaraciones del código, ramas, caminos y condiciones.

  • Unitaria:
Este tipo de prueba se utiliza para probar la correcta funcionalidad de los módulos del programa, como funciones, procedimientos, módulos de clase. En ciertos sistemas también se verifican o se prueban los drivers y el diseño de la arquitectura, esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado.

  • Integración incremental:
Cuando nuevas funciones son ingresadas al sistema se hace la prueba basándose en la funcionalidad, la dependencia con otros módulos y la integración con el programa completo.

  • Prueba de integración:
Se llevan a cabo durante el desarrollo del sistema. Se  basan en las pruebas de conexiones y comunicaciones entre diferentes módulos. Estas pruebas terminan probando el sistema en conjunto.

  • Prueba funcional:
En este proceso se pretende encontrar desigualdades entre el sistema y su especificación funcional. La prueba funcional generalmente es una actividad de caja negra, para realizar esta prueba, las especificaciones del sistema se analizan,  desarrollando casos de prueba y mediante diferentes técnicas de caja negra.  (Oré B, 2009)

  • Prueba de sistema:
Este proceso es parte de las pruebas de caja negra en el cual se prueban todos los componentes del sistema desde el hardware a la documentación.

  • Prueba de fin a fin:
Esta prueba es semejante a la prueba de sistema pero esta implica la interacción con otro hardware, bases de datos y redes.

  • Prueba de sanidad:
Con base en esta prueba se determina si la nueva versión de un software está bien desarrollada y si requiere un nuevo esfuerzo en la prueba de software. Por ejemplo la nueva versión de un sistema satisface casi todas las especificaciones pero destruye la base de datos al leerla, por lo tanto se dice que este software no está en una condición sana.

  • Prueba de regresión:
Es una nueva revisión en las pruebas del programa una vez realizado algún cambio sobre un componente del sistema, para comprobar que dicho cambio no haya introducido un comportamiento  o errores adicionales en otros componentes no modificados.

  • Prueba de aceptación:
Es la prueba final, su objetivo es validar que un programa cumple con las especificaciones y con el funcionamiento correcto. Esta prueba está basada en el uso del programa por el usuario final luego de un periodo de tiempo.

  • Prueba de carga:
Se realiza generalmente para observar el comportamiento en las aplicaciones bajo cargas pesadas, esta carga puede ser el número esperado de usuarios concurrentes utilizando el sistema y que realizan diferentes transacciones durante el tiempo que dura la ejecución de los datos a probar, generalmente usadas en sitios web y en servidores con gran cantidad de datos donde se determina en cuáles puntos existen atenuación del sistema

  • Prueba de estrés:
Una prueba de carga y performance es utilizada generalmente para colapsar el sistema, está basada en la funcionalidad del sistema bajo cargas pesadas, doblando el número de usuarios que se agregan a la aplicación, así como también un gran número de repeticiones, manejo de grandes volúmenes de datos y demasiadas preguntas a bases de datos grandes hasta que el sistema colapsa.

  • Prueba de performance:
Este procedimiento permitirá asegurar el rendimiento y capacidad de la solución tecnológica empleada en sus sistemas, es una de las pruebas finales y sirve para validar los requerimientos y la calidad del software, con base en las pruebas de carga y estrés. 

  • Prueba de instalación y desinstalación:
 Este proceso determina la eficiencia de los procedimientos que instalan y desinstalan las aplicaciones del sistema.

  • Prueba de recuperación:
En esta prueba se fuerza al fallo del sistema para verificar la recuperación  del sistema después de bloqueos, fallas del hardware u otros problemas catastróficos.

  • Prueba de seguridad:
La prueba de seguridad evalúa que los mecanismo de protección integrados al sistema protejan de interrupciones inapropiadas, contra accesos, internos o externos, no autorizados, esta prueba requiere sofisticadas técnicas y herramientas.

  • Prueba de compatibilidad:
Son utilizadas para evaluar si el sistema funcionará correctamente en diferente hardware, sistema operativo y redes.

  • Pruebas exploratorias:
Son pruebas informales que se le aplican al sistema, no están basadas en ningún plan o caja de prueba y se aplican con base en la experiencia del ingeniero de pruebas. (Bec, 2007)

  • Prueba de anuncio:
Es semejante a la prueba de exploración pero los testers deben tener suficiente conocimiento sobre las especificaciones y el funcionamiento del programa antes de llevar a cabo esta prueba, por lo que requiere una previa reunión con analistas y programadores.

  • Prueba de usuario:
Se basa en evaluar si el usuario se desenvuelve satisfactoriamente en el entorno del programa y que esté satisfecho con el funcionamiento del mismo. (Testing, 2013)

  • Prueba de comparación:
En esta prueba se comparan los pros y los contras del programa con los programas creados con la competencia.

  • Prueba alfa:
Se lleva a cabo cuando la aplicación está cerca de la entrega al usuario. Se utiliza el programa de forma natural con el desarrollador observando cómo el usuario interactúa con el sistema y registrando los posibles errores y problemas de uso; generalmente se hacen pequeños cambios en el diseño de interfaces. 

  • Prueba beta:
Esta prueba se lleva a cabo por los usuarios finales del sistema, a diferencia de la alfa el desarrollador no está presente, así se puede decir que esta prueba es la aplicación real del software en un entorno que no es controlado por el programador, el usuario es quien registra los errores y problemas de la aplicación. (Pressman, 2002) (Mañas, 1994).

  • Caja gris:
El concepto de testing de caja gris es simple, se basa en la realización de testing de caja negra basado en casos de prueba realizados por personas que conocen el programa por dentro. Se entiende que de esta forma las pruebas realizadas son más efectivas porque se conocen las partes del código que pueden resultar más conflictivas: por su complejidad, por su acoplamiento con otras clases, etc.  (Pressman, 2002)

Te invito a dejar tus comentarios para mejorar la información.
Gracias.


Autor: Luis Eduardo Fernandez Rocha (Contacto Linkedin)

lunes, 4 de mayo de 2015

Cap 1 - QA Automatización de pruebas - introducción

QA Automatización de pruebas - introducción

(Automation UFT/QTP Introduction)

I. Introducción

Este articulo y la serie que le continuaran son extractos del proyecto de investigación, siendo yo el autor intelectual del mismo de cualquier manera se incluirán las bibliográfias de los lugares donde se citaron parrafos .

Este documento tiene como objetivo tener una visión general sobre la automatización de procesos y test cases con la herramienta de UFT/QTP.

Esta información la información puede ser encontrada en Internet fácilmente en ingles.
Espero y sea de ayuda a las personas que no tengan un buen nivel de ingles o simplemente a quienes gusten utilizar este blog para tener mas a la mano la información de functions, sub, etc.

Primero daré una breve introducción a los roles (o Job's) y acronicos que estaremos utilizado durante esta serie de artículos, para ir introduciéndonos poco a poco al ingles técnico.

Conceptos Básicos

  •  HP QuickTest Professional:

HP Quick Test Professional (QTP) es parte de la herramienta HP Quality Center suite, facilita funcionalidades y pruebas de regresión automatizadas para aplicaciones, servicios y entornos de software. QTP soporta VBScript (Visual Basic Script) para manipular los objetos creados para la aplicación y colocar los controles de prueba.
Hoy en día el QTP se descontinuo para dar le paso a la nueva herramienta conocida como UFT es la nueva versión lanzada al mercado por HP, sustituyendo a QTP.


  • HP Application Lifecycle Management (ALM):
Es un producto de software dirigido a acelerar la entrega de aplicaciones modernas, seguras y confiables. Es una combinación de una plataforma común, varias aplicaciones clave y un panel de control dirigido a la gestión del ciclo de vida del núcleo de aplicaciones. ALM se centra en el ciclo de vida desde el diseño hasta la preparación para la entrega a las operaciones.

Nota: Solo para aclarar que UFT/QTP y ALM son dos herramientas completamente diferentes,  una para automatizar casos de pruebas, mientras que ALM se puede llevar un registro de cada prueba realizada en cada release, es decir ALM te apoya a la gestion. Sin embargo ALM y UFT pueden relacionarse entre si. Mas adelante se explicara a detalle su relación.

  • DB2 Query Management Facility (QMF):
Cuando se generan Scripts existen diferentes maneras de tomar los datos de pruebas, una manera es generar los datos desde cero a partir de funciones, sin embargo eso afecta el rendimiento  del programa, otra manera es generar consultas directo de la base de datos, mejorando el rendimiento y la obtención de información, una herramienta que se puede emplear es QMF para crear los queries y ver los resultados que este arroja. (IBM,2013)

·      
  • Equipo de Manual: 
Son las personas encargadas de ejecutar los casos de prueba manualmente. 
También llamados Functional manual team ellos son los encargados de analizar, diseñar y crear los Test Cases (TC's).

  • Caso de pruebas: 
Los casos de pruebas o Test Cases(TC's) son los pasos a seguir para probar una funcionalidad de la aplicación, estos pueden estar escritos con un estándar para que  cualquier usuario al leerlo pueda ejecutarlo sin ninguna ayuda. Mas adelante se podrá ver un ejemplo de un TC's.
  •  ExpertView:
Es la vista a detalle del código empleado para crear el flujo de los scripts, es la manera más utilizada para tener un mejor control de los objetos. 


  •  XML:

XML es un lenguaje de marcado basado en texto. Se identifica los datos mediante etiquetas (identificadores encerrados entre paréntesis angulares: <...>). En conjunto, las etiquetas se conocen como marcas. (Microsystems, 2014)

  •  JSON:

Acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML. (Json, 2014)

  •  HTTP:

HTTP (Hypertext Transfer Protocol) es el conjunto de normas para la transferencia de archivos (texto, imágenes gráficas, sonido, video y otros archivos multimedia) en la World Wide Web.  (Rouse, 2006)


  •  Rest Client:





Es una herramienta para desarrolladores para crear y probar peticiones HTTP. Tiene diferentes modalidades de peticiones, JSON y XML.

  •  Prueba de software:

Los productos software están incrementando continuamente su presencia en muchos aspectos de la vida cotidiana, dotados cada vez de más funcionalidades y, consecuentemente, más complejos. Este incremento de complejidad conlleva la posibilidad de un aumento de fallos y errores durante su utilización que pueden acarrear consecuencias catastróficas en términos económicos, de tiempo o incluso de vidas humanas. Por tanto, existe una necesidad importante de incluir actividades de aseguramiento de calidad durante el proceso de desarrollo y mantenimiento del software.
La prueba del software es uno de los procesos fundamentales dentro del control de calidad de software. En su nivel más simplista, consiste en una ejecución de un programa bajo ciertos datos de entrada (casos de prueba), para posteriormente comparar las salidas obtenidas con las deseadas (función para la cual fue diseñado) (Tuya, Ramos Román, & Dolado, 2007).


  •  Verificación y Validación:

Las técnicas de verificación y validación son complementarias entre sí, y no la sustitución de una a la otra. Un proyecto debe estimar el tiempo y los esfuerzos requeridos para la preparación y ejecución de actividades de verificación y validación, plan del proyecto y por las definiciones del plan de pruebas (Limaye, 2009).
La validación comprende los “procesos de  evaluación de un sistema o componente durante o al final del proceso de desarrollo para determinar si satisfacen los requisitos especificados”. Usualmente, la verificación está asociada al conjunto de actividades que aseguran que el software es coherente con su especificación. Por tanto, abarca tareas tales como las revisiones e inspecciones de código. Mientras, la validación está encaminada a determinar si el software satisface las expectativas del usuario, por lo que suele estar asociada a su ejecución.
La verificación específicamente implica por parte de los desarrolladores la revisión de los planes, del código, de los requerimientos, de la documentación, las especificaciones y posteriormente una reunión con los usuarios para evaluar dichos documentos. Esto puede ser hecho con listas de chequeos, listas de problemas o walkthrough. Por otro lado la validación implica la aplicación de las pruebas del software y comienza una vez que la verificación esté completa.

  •  Walkthrough:

Es una junta informal donde analistas y usuarios evalúan las propuestas informacionales, por lo general se requiere una preparación de documentos.

  •  Inspección:

Después de haberse llevado a cabo walkthrough, se realiza una reunión formal la cual se le llama inspección, generalmente se reúne personal de diferentes sectores, principalmente analistas, programadores, e ingenieros de pruebas (testers), donde se llega un acuerdo con base en los métodos de seguridad de prueba que se llevarán a cabo.  Frecuentemente en estas reuniones se requiere de un moderador el cual es el representante de la empresa y que da a conocer a los usuarios, una lista de procedimientos de métodos de prueba y controles de calidad de las cuales el usuario debe optar por alguna de ellas, defendiendo el mismo nivel de calidad, o defendiendo él mismo el nivel de calidad (Society, 1998).

  •  Peer review:

Es un esfuerzo organizado para que los profesionales practiquen revisar la calidad y adecuación de los servicios ordenados o ejecutados por sus compañeros profesionales (Haag-Heitman & George, 2011).

  •  Defecto:

Es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora (software). Dicho fallo puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Los errores pueden suceder en cualquier etapa de la creación de software.  (Billyve,2013)


Continua en el Cap 2 - QA&V Test types (Basis/Spanish).

Autor: Luis Eduardo Fernandez Rocha (Contacto Linkedin)