Вы находитесь на странице: 1из 9

HIPTEST

Hiptest es una plataforma de pruebas de colaboracin en la nube, el cual


permite al equipo entregar un software de aceptacin.
Proporciona un entorno de tiempo real para disear, ejecutar y refactorizar las
pruebas. Y por ltimo permite automatizar las pruebas que se convierten en
especificaciones vivas de la aplicacin.
Hiptest pretende ser utilizado por todos los miembros del equipo de entrega de
software: los clientes, los expertos de dominio, gerentes de producto, testers y
desarrolladores.
En primer lugar, creemos que las herramientas no deben de tener limitaciones
para adoptar un proceso especfico. Y en el mundo actual de la implementacin
continua, procesos de desarrollo estn evolucionando rpidamente, por lo
tanto, se ha diseado Hiptest para ser abierto y flexible para que se pueda
usar el proceso que sea adecuado para usted.
Glosario
Antes de empezar, aqu hay un pequeo resumen de los principales trminos y
conceptos utilizados por Hiptest.
Escenario - Un escenario es una secuencia de pasos que representa un
comportamiento de la aplicacin como se esperaba por el usuario. Un
escenario puede ser manual y / o automatizado.
Accin palabra - una palabra de accin es una secuencia de pasos que
pueden ser reutilizados en mltiples escenarios como una funcin. Se define el
lenguaje especfico de dominio (DSL) del proyecto. Es el lenguaje comn
compartido por el equipo y se utilizan como bloques de construccin para crear
escenarios.
Datatable - Para un escenario con parmetros, es posible definir varios
conjuntos de valores (es decir, Datatable). Una prueba ser generada para
cada valor.
Test - Si un escenario no tiene ninguna tabla de datos, se generar una
prueba. Si un escenario tiene una tabla de datos con los N conjuntos de
valores, que va a generar N pruebas. As que, bsicamente, el escenario es una
descripcin de alto nivel del comportamiento de la aplicacin. La cual genera
una o ms instancias de prueba que sern ejecutadas.

Test Run un Test run es un conjunto de pruebas que se van a ejecutar. Cada
prueba tiene un test run y se pueden aadir uno o ms resultados de la prueba
para realizar un seguimiento de su progreso y ejecucin de la misma.
Hiptest editor Hiptest editor es una aplicacin de cdigo abierto que genera
secuencias de comandos para varios marcos de automatizacin de pruebas
como RSpec, JUnit, TestNG, Robot Framework, cucumber, etc....

Nuestra filosofa de pruebas

Aunque HipTest es una plataforma nueva nuestro equipo esta en el negocio de


desroolo y testing durante mas e 10 aos. Hemos comenzado nuestro viaje
con lel proceso de cascada agil en 2006 y trasladado a devobs en 2011.
Desplegamos continuamente nuevos desarrollos en la produccin esto significa
que hacemos uso de entre 1 a 10 pequeos incrementos cada dia, esto nos
permite tener una retroalimentacin temprana de los clientes hacer pruebas a /
b y reacionar rpidamente cuando tenemos que entregar una correccin de
errores ----- durante este viaje uno de los temas mas difciles de tranformacion
fue la necesidad de revolcionar nuestras pruebas, en algunas era el despliegue
continuo y aqctualizaciones no hay tiempo para que el equipo de QA
identifique un problema y lo regrese a desarrollo.
Aqu es donde se ha encontrado el (BDD) Manejador del comportamiento de
desarrollo un enfoque muy eficiente en los ltimos aos, permite alinear al
equipo en l oque ebemos construir y probar antes.

Los escenarios son especificaciones de requisitos que se comportan como


pruebas e aceptacin ejecutables.
Los escenarios son la definicin de STOP para los desarrolladores
Los escenarios se escriben preferentemente antes del desarrollo y en base a un
lenguaje de dominio de negocio.
Los escenarios se confirman con los stakeholder y se automatizan.
Los escenarios deben ser refactorizados y revisados de forma continua al igual
que el cdigo.

Estas buenas prcticas haen que nuestras pruebas sean legibles y fciles de
mantener (activo valioso). Pero esto no es suficiente tambin es necesario un
circuto de retroalimentacin muy corto y esta es la razn por la cual nuestras
puerbas de aceptacin estn automatizadas e integradas en el proceso de
integracion continua.
Hasta ahora hemos tenido xito en la entrega de un software que trabaja en el
nivel de calidad requerido y coin la velocidad y la escala de DevOps entre los
factores calves del xito mencionaremos:
-

BDD
Refactorizacin
Integracin continua

Se trata de un alrgo viaje, no hay un acceso directo y no se l opeude hacer


bien a la primera nosotros seguimos intentando para mejorar.
Ennuestro equipo todo el mundo actua como programador y tester.
Por lo general el PO ya escribi los criterios de aceptacin con Hiptest antes de
empezar el desarrollo. Las pruebas son utilizadas por el propietario.
Cualquier persona el equipo puede contribuir al proyecto mediante la adcion de
HIPtest escenarios de edicin y las palabras de accin.
Durante el desarrollo escribimos las pruebas unitarias y de integracin con
RSpec y QUnit para probar nuestro cdigo Ruby y Javascript.
Para automatizar las pruebas de aceptacin utilizamos el servicio editorial
Hiptest para generar cdigo Ruby / RSpec
Todas nuestras pruebas de aceptacin son las pruebas de la interfaz grafica
por lo que tambin se integran cdigo de selemiun a raves de la biblioteca
WATIR.
Todas nuestras pruebas (unitarias, integracin y aceptacin) se integran en un
proceso continuo despliegue. Cuando un cambio es empujado a nuestro
repositorio de cdigo git, enva una integracin continua ejecuta todas las
pruebas para asegurarse de que todo funciona como se esperaba. Si alguna
prueba falla, el equipo es notificado para que podamos solucionar el problema.
Si se superan todas las pruebas, a continuacin, la nueva versin se ha
implementado en la produccin.
Envos estado actual de construccin se puede ver en esta placa: Estado de
creacin
Las pruebas no son la nica manera con la que validamos nuestras

caractersticas. Una vez que el proceso de desarrollo se lleva a cabo, otro


miembro del equipo validar la funcin con pruebas exploratorias y revisin de
cdigo. Esta etapa del proceso tambin conduce a veces a la creacin de
nuevas pruebas (pruebas de regresin no si se encuentra un error o prueba
unitaria si un caso especial no se prob).

Pasos para iniciar


Paso 1. Crear un Proyecto
Ir a la lista de proyectos. Para crear un nuevo proyecto, haga clic en el botn
New y escriba el nombre (Paos Test) Y haga clic en Crear. A continuacin, se
accede directamente al panel de tu proyecto.

Paso 2. Creacin de un escenario


Ir a la pgina de escenarios usando el men de la izquierda. Crear un nuevo
escenario llamado de Login.

Puede aadir una descripcin para este escenario.


A continuacin, empezar a escribir su primer paso, una accin: "Loguearse con el usuario
Paola con el password COlosa123" y haga clic en Crear accin.
Agregar un segundo paso, Compruebe que el usuario se loguea" y haga clic en Crear
resultado.
Enhorabuena, usted ha creado su primer y simple escenario! Vamos a ejecutarlo.
Paso 3. Ejecutar un escenario
Ir a la pgina de las ejecuciones de prueba usando el men de la izquierda. Crear una nueva
prueba denominada Test 1 Sprint.
crear realizacin de la prueba
Seleccione su prueba de funcionamiento.
mi nueva prueba de funcionamiento
Seleccione la prueba de inicio de sesin y haga clic en el botn Agregar resultado.
Establecer el resultado en pasado.
aadir un resultado de la prueba
Se puede ver que el estado de la prueba ha sido actualizado en la columna izquierda. Haga
clic en el nombre de prueba de funcionamiento (columna izquierda) para ver el resumen.
Fin de la excursin!
Ests listo! Ahora usted puede comenzar su primer proyecto. Tambin recomendamos a
conocer otras caractersticas clave de Hiptest como palabra de accin, refactorizacin y
editor Hiptest si va a automatizar sus pruebas y se integran con su proceso de CI

Automatizar tus test

Escribir pruebas con Hiptest es agradable, lo que les permiti que se ejecuten
automticamente es an mejor. Para facilitar esta transicin, hemos creado la
herramienta de editor de la prueba del VIH, que transforma sus escenarios
Hiptest en pruebas ejecutables en varios idiomas (Java, Ruby, Python ...) y el
marco de prueba.
Esta documentacin le ayudar a ATRAVES el proceso de conseguir sus
escenarios Hiptest en pruebas automatizadas. Hay cuatro pasos en este
proceso, cada uno de ellos se describe en una de las siguientes pginas:
Seleccionar un enfoque a nivel de acoplamiento: Este paso define qu tan
cerca sus Hiptest escenarios y sus pruebas ejecutables estarn cerca
Estructura de su proyecto: un proyecto diseado para la automatizacin debe
seguir algunas reglas con el fin de simplificar sus actualizaciones crear
secuencias de comandos ejecutables: cmo usar editor hiptest para
transformar sus pruebas en los ejecutables integrar con su proceso de
integracin continua: el ltimo paso es integrar sus pruebas hiptest en su
proceso de CI con el fin de obtener los resultados de vuelta en Hiptest
Echa un vistazo a esta demostracin en vivo para ver cmo automatizar e
integrar escenario 1 con su CI:
Definir el nivel adecuado para sus palabras de accin
Automatizacin con Hiptest editor - el nivel de acoplamiento
Un aspecto crtico durante el diseo del proyecto ser elegir el nivel de
acoplamiento del proyecto (en comparacin con la estructura de
automatizacin). Usted tiene principalmente dos opciones: acoplamiento fuerte
o flojo. Ambos mtodos tienen ventajas y desventajas que detallaremos a
continuacin. En cualquier caso, no se preocupe demasiado acerca de la
eleccin, no es una definitiva y siempre es posible pasar de una solucin a la
otra.
Para demostrar cmo escribir pruebas de estos dos enfoques, usaremos uno de
nuestro propio escenario de prueba para Hiptest, en el que nos aseguramos de
que un usuario puede cambiar su nombre en el sistema. El escenario es el
siguiente:

El acoplamiento flexible
La idea principal de la articulacin flexible es evitar la integracin de
contenidos relacionados con la automatizacin dentro de los escenarios de
prueba de la cadera y las palabras de accin. Eso significa que el nivel ms
bajo de las palabras de accin describir acciones en el sistema bajo prueba
(login, registro, crear el proyecto ...) y tendr que ser implementado por el
equipo de automatizacin.
Las palabras de accin utilizados en "Cambiar perfil" se ver de la siguiente
manera:

Nota: Haga clic en el nombre de usuario y haga clic en los botones de perfil no se muestran
aqu, pero son simples palabras de accin con un paso de accin que describen la accin a
realizar.

Como se puede ver, las acciones descritas por las palabras de accin son bastante genrico
y cada uno tendr que ser aplicado manualmente por un revelador con el fin de tener la
prueba de funcionamiento automatizado. Esto pide ms trabajo durante el proceso de
ejecucin, sino que hace que sea posible escribir dos implementaciones de la misma palabra
de accin (por ejemplo, si haba una versin de la aplicacin mvil de Hiptest, podramos
escribir una aplicacin para la versin web y otro para el mvil versin y utilizar los
mismos escenarios de prueba para ambos).
acoplamiento fuerte
La idea aqu es la integracin de la automatizacin en el interior Hiptest. Eso significa que
la prueba y el equipo de automatizacin de los dos para trabajar en el proyecto Hiptest. Con
este tipo de proyectos, el nivel ms bajo de la palabra de accin describir las tareas
automatizadas (Click, llenar texto, URL abierta ...) y ser llamado por las palabras de
accin de alto nivel.
Con nuestro ejemplo anterior, las palabras de accin se vera as:

Como se puede ver, cada palabra de accin llama a las palabras de accin ms
bajas que llamamos "accin palabra API". Cada uno fue etiquetado con
"Automatizacin: api" para que puedan ser filtrados fcilmente como se ve en
esta captura de pantalla:

Cada una de estos palabra de accin contienen un solo paso que describe la
accin que realiza.
La principal ventaja de esta solucin es que la aplicacin se reduce a su
mximo, ya que slo las palabras de accin API tendrn que ser aplicado
manualmente. Dicho esto, este trabajo tendr que hacerse dentro Hiptest y el
equipo de automatizacin tendr que trabajar directamente en Hiptest para
crear el contenido del nivel ms alto de las palabras de accin.
Otro inconveniente de esta solucin es cuando el escenario de prueba necesita
muchos accesorios. Por ejemplo, en Hiptest, tenemos una prueba de
comprobacin de que la estructura de carpetas creada en escenarios se replica
al crear una ejecucin de prueba. As que tenemos una palabra de accin
llamado "Cargar proyecto con la estructura de carpetas". Esta palabra de
accin no se implementa mediante el uso de las llamadas a palabra de accin
de la API, ya que sera demasiado tiempo para crear cada elemento de la
prueba y luego crear la realizacin de la prueba (y esta parte no es objeto de la
prueba, pertenece a otras pruebas asegurando el proceso de creacin de
carpetas y escenarios funciona como se esperaba). Por lo que esta palabra de
accin accesorio se considera como una palabra de accin de la API y se lleva a
cabo manualmente, aunque en realidad no pertenecen a la misma clase de
palabras de accin como "clic" o "Abrir URL".

Вам также может понравиться