Cap 4 - QA&V QTP/UFT Introduccion (Español) Parte - 2

QA&V QTP/UFT Introduccion (Español) Parte - 2

(QA&V QTP/UFT Introduction)

4.2 Que es UFT/QTP? (Continuacion)

Se crean flujos de la aplicación y después se modifican para adaptarlas a las validaciones necesarias. Para crear un flujo se puede usar la opción de Record o utilizar programación descriptiva en ExpertView.

Los estándares de desarrollo que el cliente solicita son diferentes, por la misma razón solo se mostrara un standard base, sin embargo las especificaciones que el cliente usualmente solicita y las que por base de programador requieren son las siguientes:

• Los archivos de pruebas debe de estar debidamente documentados con su encabezado.
• Marcar el inicio y la finalización de los flujos.
• Los scripts se dividen en flujo principal y librerías.
• La prueba principal o flujo principal no debe de exceder las 200 Líneas de código. (Puede variar dependiendo del framework las líneas de comment no cuentan como línea de código)
• Las variables, funciones y sub rutinas tienen un prefijo dependiendo del tipo que sean (Tabla 2).
• Option Explicit debe de ser implementada desde el inicio del desarrollo del Script.
• Destruir los objetos una vez que termine la rutina.
• Los valores deben ser tomados de un archivo .xls, una virtual table, json file, nunca hardcode.
• Los recursos deben de tener una dirección especifica en el disco “C://” en caso de ser archivos Json, .xls, .xml, en el caso de recursos externos se debe tener la nomenclatura correcta para su rápida identificación.

Prefijo	Tipo de variable
iItemNumber	“i” para las variables enteras.
dItemNumber	“d” para los dobles.
sCountry	“s” para las cadenas de texto.
dtDate	“dt” para las fechas.
bValidation	“b” para los booleanos.
fnTimeOut	“fn” para las funciones.
subCloseBrowser	“sub” para las sub rutinas.
pGtinNumber	“p” para los parámetros declarados en Excel.

Tabla 2 Tabla de prefijos.

Fuente: (Elaboración propia).

Estas son algunas de las reglas básicas que el cliente puede solicitar al desarrollar los scripts, o que nosotros como buena practica debemos de tener claro para dar un mejor mantenimiento de código.

4.3 Características del flujo principal

En el flujo principal se pueden encontrar las funciones para cubrir los pasos creados en los test cases generadas por el equipo de manual. El procedimiento que se lleva para la elaboración de los flujos, es el análisis de los test cases almacenados en ALM en su respectiva carpeta con su determinado nombre y número de test case.

Posteriormente se separan por escenarios de prueba y se guardan en un archivo de Excel para llevar un control, esto se realiza por parte del ingeniero de pruebas automatizadas para registrar los posibles cambios en el user-story conforme avanza el sprint al igual de poder crear una traceability matrix para hacer una relación uno a uno o uno a muchos de los test cases. Una vez hecho el análisis de los test cases se eligen las test similares y se selecciona una para su ejecución manual, y de esa manera comprender el flujo que se llevará durante el proceso automatización.

Una vez que ejecutan y revisan los test cases, y no encuentra ningún defecto, comienza el proceso de diseño del flujo de pruebas. En caso de encontrar un defecto se reporta al equipo de manual para que se le de seguimiento, en caso de existencia de un defecto se procede a identificar otro flujo que no sea impactado por el tema en cuestión y poder continuar con la automatización hasta la resolución del defecto.

Una nota importante es la revisión de los test cases (se realiza en paralelo mientras se ejecutan los casos de manera manual); el ingeniero de automatización debe de reportar cualquier detalle olvidado en la fase anterior, ya sea ambigüedad, falta de datos de entrada, etc.

Tip: Siempre buscar la manera de tomar todos los Test cases con flujos similares para creación de un script y después tomarlo de base para el resto de las scripts similares, al reutilizar el código para minimizar el esfuerzo y evitar el rework.

4.4 Encabezado del flujo principal.

Esta sección contiene las características básicas del script, para el mantenimiento correctivo y preventivo del flujo de pruebas.

El encabezado del flujo principal comienza con el nombre del script y termina con la declaración de variables o parámetros.

En el header (encabezado) se puede agregar parámetros extra con el paso del tiempo, ya que se puede agregar valores al momento de darle mantenimiento, sin embargo los valores esenciales son “Script name”, “Prerequisites”, “Descripcion”, “Pre-Condition”, “Create by”, “Create on”, “Remarks”,”Parameters”.

El propósito de los campos es llevar un registro del creador del script en caso de tener que dar mantenimiento en un futuro y este pueda dar referencias del mismo.

Los campos extras son después de hacer el mantenimiento del script en caso de necesitarlo por un cambio en la UI, estos son los campos que se agregan en caso de dichos cambios,  “Changes:”, “Updated by”, “Date update”, “Reason for change”, “Brief description”.

‘**********************************************************************

‘Script name: [1]Mercury_Create new guest

´Prerequisite: None

‘Description (Script function): Create a new guest and validate the guest information.

‘Pre condition: None

‘Create by: Luis E. Fernandez

‘Create on: 10/22/2013

‘Changes: None

‘Updated by: None

‘Date update: None

‘Purpose or reason for change: None

‘Brief description (of change): None

‘Remarks:

‘TC #274655

‘TC #312390

‘Parameters: None

Encabezado de flujo principal.

Fuente: Elaboración propia (Fernández, 2014).

 En la sección de parámetros  se encuentra la declaración de las variables comunes para la elaboración de los casos de pruebas.

 4.5 Declaración de parámetros del flujo principal.

Se utiliza el Option Explicit como buena practica y mejorar la calidad del codigo, con la finalidad de  evitar la repetición de variables y posible perdida de información en las variables. Usualmente la declaración de variables es breve en los flujos principales. Las variables se pueden definir en diferentes lineas y puede agruparte por el tipo de variable que se utilizara, es decir todas las String variables en una sola linea de codigo, en otra todos los Integer, etc. Esta sección termina con la definición de las constantes.

‘Parameters:

‘*********************************************************************

‘VARIABLE DECLARATION

Option Explicit

Dim sLinkDesc, sAppLeng, sRadioButton, sTestDesc, sTestCases, sDepartNbr

Dim sFineLineNbr, iIteration, sLinkBrowser, sLinkPage, sLinkHome

‘*********************************************************************

'Define Constants

Declaración de parámetros.

Fuente: Elaboración propia (Fernández, 2014).

4.6 Definición de las constantes del flujo principal.

En la sección de parámetros  se encuentra la definición de las constantes, que serán incluidas a lo largo del script, esta sección se considera parte del flujo de pruebas debido a que ya se comienzan a llamar los parámetros establecidos por el ingeniero de pruebas automatizadas.

'Define Constants

‘Script Flow

sDTName = “Global”

Load_SpreadSheet_v1

sAppLeng = DataTable(“pAppLeng”,sDTName)

[…]

Definición de constantes.

Fuente: Elaboración propia (Fernández, 2014).

4.7 Flujo de pruebas.

Finalmente en este apartado se mandan a llamar las funciones creadas en las librerías para revisión y validación de la aplicación.

‘Login to Walmart Home:

subRunIteration()

subHOMELogin sAppLeng

subOpenBrowser

Wait 5

App_Languages(sAppLeng)

subAssembly()

Wait 10

CloseBrowser()

ExitTestIteration

Flujo de pruebas.

Fuente: Elaboración propia  (Fernández, 2014).

(Continuara)

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

Gracias.

Autor: Luis Eduardo Fernandez Rocha (Contacto Linkedin)