Page Object

 ¿Qué es un Page Object?

Page Object es un patrón de diseño con el cual buscamos crear un objeto que sirva como una capa de abstracción para las interacciones que se pueden efectuar en una página web. Es decir, un page object debe proveer una manera simple para interactuar con una página web encapsulando sus funcionalidades y características.

¿Por qué usar page objects?

Los page objects nos entregan una manera sencilla de interactuar con las páginas web que queremos verificar en nuestros tests. Esto le quita mucha complejidad a nuestros tests, ya que nosotros para realizar acciones u obtener datos de la página web, solamente debemos llamar los métodos del objeto. Esto reducirá dramáticamente la cantidad de código en nuestros tests. Disminuyendo sus complejidad, mantenimiento y facilitando el patrón AAA (Arrange, Act y Assert.).

Consejos para el manejo de elementos.

Campo de texto (Input text y text areas).

Usualmente los campos de texto son elementos html que aceptan texto libre en su interior.

Extracción de datos.

Se debe tener un método para extraer el contenido de dicho campo y retornarlo como un String.

Asignación de datos.

Se debe tener un método para poder ingresar datos a ese campo. Lo ideal es que este método reciba un String como parámetro

Radio buttons.

Los radio buttons son un conjunto de elementos que comparten el atributo name y se diferencian entre ellos por el valor que ellos contienen.

Extracción de datos.

Se debe tener un método que retorne el valor del botón seleccionado de la familia.

Asignación de datos.

Se debe tener un método que debería ser capaz de seleccionar el elemento de la familia mediante un parámetro de texto que concuerde con uno de los elementos de la familia.

Checkboxes.

Los checkboxes son elementos que pueden ser clickeados para  cambiar su estado a 'checked'.

Extracción de datos.

Se debe tener un método que retorne True o False.

Asignación de datos.

Se debe terner un método que asigne mediante un parámetro booleano para cambiar la selección de dicho objecto. True para que pase a estar 'checked' y False para remover remover el atributo 'checked'.

Listas desplegables (Selects).

Las listas deplegables son elementos que contienen opciones para ser seleccionadas por el usuario. Las opciones tienen dos principales características, una es el texto visible y la otra es el valor de la opción. Dichas características no siempre comparten valor.

Extracción de datos.

Se debe tener métodos que retornen el valor, texto o índice de la opción seleccionado en la lista desplegable.

Asignación de datos.

Se debe tener métodos para poder seleccionar la opción por valor, texto o indice.

Conclusión.

El page object es un patrón de diseño que nos ayudarás a disminuir la complejidad de nuestros tests. Debido a que nos entregará menos código por mantener, mayor abstracción en nuestras pruebas y una complejidad menor en nuestros tests.

El costo de los bugs

El software no es un producto que aparece por arte de magia. Generalmente es planeado y pasa por varias etapas antes de ser lanzado. Por lo tanto, pasando por su planificación, desarrollo, testeo y lanzamiento, existe la posibilidad de encontrar bugs en cualquiera de estas etapas. En la siguiente figura se grafica qué tan caro es arreglar un bug dependiendo de la etapa de desarrollo en donde es encontrado.

El costo de arreglar un bug tiende a aumentar de manera exponencial como se puede apreciar en la figura. Dicho esto, si encontramos un bug en la etapa de diseño el costo de arreglarlo será bajo. ¿Pero que pasa si ese problema aparece en la etapa de testeo? dependiendo del proceso de desarrollo que se está utilizando esto puede variar. Trabajando con scrum, la tarea con problemas puede ser devuelta fácilmente a desarrollo, pero ésta de todas formas consume tiempo, pero no es lo mismo en el caso de un proceso de desarrollo más lento en donde los cambios se pasan a un servidor de prueba una vez al día.

Otro caso para analizar es cuando el cliente se encuentra cara a cara con un bug, como muestra la figura, el costo es 100 veces mayor a que si este hubiese sido encontrado en diseño. ¿Por qué será tan caro? La respuesta es simple, un bug encontrado por el cliente debe ser arreglado de manera inmediata en la mayoría de los casos, por lo tanto, la característica recién lanzada será retornada al proceso de desarrollo, en consecuencia a esto, la carga de trabajo aumentará considerablemente para el equipo. Además en algunos casos será necesario enviar el arreglo a producción antes de la fecha en que regularmente se hace, lo cual agrava más este escenario, ya que se debe aplicar todo el esfuerzo de un lanzamiento en una fecha no prevista.

Como pudimos apreciar, encontrar errores en etapas avanzadas del proyecto pueden ser perjudiciales para el equipo en términos de tiempo, esfuerzo e incluso dinero. Para evitar estos problemas es necesario utilizar estrategias preventivas como tests de regresión o unit testing en el lado de los desarrolladores. En síntesis, es esencial esforzarse desde el comienzo del proyecto en la búsqueda o prevención de bugs, para así poder capturar la mayor cantidad de errores en las etapas de diseño y desarrollo. 

Definición de un bug.

Llamar bugs a todos los problemas encontrados en un software puede ser la manera más simple de hacerlo, pero en definitiva no es una definición completa. Para entregar la definición correcta es necesario comprender qué es un problema y cómo estos se presentan dentro del software.

El primer término que nos ayudará con esto es especificación de producto: Una especificación de producto, comúnmente mencionado como especificación o spec, es un acuerdo entre todo equipo de desarrollo de software. Esto define el producto que se está creando, detalla qué debe ser, cómo debe actuar, qué debe y que no debe hacer. Este acuerdo puede ir desde un entendimiento verbal hasta un documento formal.

Ahora que hemos definido que es un spec, detallaremos las cinco principales reglas que ocurren cuando un bug aparece:

1. El software no hace algo que la especificación del producto dice que debe hacer.
2. El software hace algo que el la especificación del producto dice que no debe hacer.
3. El software hace algo que el la especificación del producto no menciona.
4. El software no hace algo que que la especificación del producto no menciona, pero debería.
5. El software es difícil de entender o usar, lento o simplemente incorrecto.

Para comprender mejor estas reglas, las pondremos en práctica testeando las funcionalidades de una supuesta calculadora que se está desarrollando.

El spec principal de nuestra calculadora es que en ella se pueda sumar, restar, dividir y multiplicar sin ningún problema. Si al momento de testear la calculadora descubrimos que estos cálculos no se están haciendo correctamente, por ejemplo: restas con resultados negativos congelan la aplicación. En este caso estaremos enfrente de un bug causado por la primera regla.

Otro spec del producto dice que la calculadora nunca se debe congelar, crashear o bloquear. Si al momento de apretar teclas de manera aleatoria, creando cálculos aritméticos sin sentido, la calculadora se bloquea. Estamos ante un bug causado por la segunda regla.

Como indicamos en el primer problema, la calculadora debe poder sumar, restar dividir y multiplicar. Supongamos que el desarrollador agregó la funcionalidad para obtener la raíz cuadrada de un número  porque pensó que sería una característica genial. El problema es que esto nunca fue especificado, por lo tanto, esta nueva característica se convierte en un bug siguiendo la tercera regla.

El caso de la cuarta regla es un poco especial, debido a que estamos ante un enunciado que posee doble negativo. Supongamos que nuestra calculadora funciona correctamente cuando se hacen divisiones que tienen resultados con pocos decimales. pero al momento de testear exhaustivamente las divisiones nos damos que cuando el resultado tiene más de 10 dígitos en su decimal la fuente de la calculadora se torna pequeña e ilegible. En este caso estamos ante un problema de usabilidad que obviamente nunca se mencionó en la especificación del producto. Dicho bug es causado por la cuarta regla.

En el caso de que nuestra calculadora sea difícil de utilizar, posea teclas muy pequeñas, su texto sea ilegible, su configuración sea muy compleja, etc. En síntesis, cualquier problema que no luzca correcto, afecte su usabilidad o arruine la experiencia del usuario final será bug causado por la quinta regla.

Como pudimos ver con los ejemplos mencionados, los bugs pueden aparecer de diferentes formas en un software, por lo tanto un bug es una falla, algo no especificado, inconsistencias o problemas que afectan la experiencia del usuario al utilizar el software.