Es hora de hablar de Calidad

QA Lovers® está especializada en el estudio, definición e implantación de servicios de pruebas de software. Somos expertos en implementación de procesos y metodologías de control de calidad que eficientan proyectos y mejoran el día a día de las personas.

Únete a la Comunidad Newsletter mensual

Ayudamos a...

Eficientar

Gracias a la experiencia a lo largo de los años, hemos dado forma a una metodología única con la que ayudamos a mejorar procesos de QA: QCIM® (Quality, Control, Intelligence, Methodology).

Más info

Mejorar

Estudiamos la madurez y situación inicial de empresas en relación a pruebas de software, además de crear, diseñar y poner en marcha procesos de eficiencia profesional.

Más info

Garantizar

Realizamos todo tipo de pruebas de software y ponemos todo el empeño en nuestro principal objetivo: asegurar la calidad global del producto a lo largo de todo su ciclo de vida.

Más info

Formar

Somos especialistas en formación y certificación, por ello, ofrecemos el único Master de QA del mercado. Además, contamos con formación personalizada y adaptada a cada persona.

Más info

El Blog

Mostrando entradas con la etiqueta Scrum. Mostrar todas las entradas
Mostrando entradas con la etiqueta Scrum. Mostrar todas las entradas

21 de enero de 2019

Unir automatización e integración continua es indispensable.

Cuando nos liamos la manta a la cabeza y tenemos una suite importante de pruebas automatizadas además de un sistema de integración continua, es casi obligatorio, el unirlo todo y hacerlo funcionar a la par.

 
En muchas ocasiones, me encuentro con que hay verdaderos mundos de pruebas automáticas, pero no existe una integración con un sistema de este tipo, cosa que hace, que sea difícil el mantener la calidad como queremos. Todo esto es muy bonito, pero si que es cierto que muchas veces no está todo integrado porque las pruebas tardan demasiado, no están suficientemente optimizadas o los resultados obtenidos no están claros o dejan las trazas suficientes para averiguar posibles problemas.
 
Una táctica muy buena para comenzar a integrar nuestras pruebas con un sistema de integración continua es el separar las pruebas por pesos o tallas (algo parecido como lo que se hace con las historias de usuario). Un ejemplo de organización puede ser esta:
  • Talla XL: Son pruebas que se deben de ejecutar una vez a la semana, tardan mucho en finalizar, pero su valor es alto. Cubrirán por completo la batería realizada y darán el OK definitivo al software que estemos probando.
  •  Talla L: Pruebas que se ejecutan en más de una hora y que deben de ejecutarse una vez al día. Estás baterías de pruebas son más optimas por la noche, para que si existe algún error, cuando llegue el equipo, podrá solucionarlo.
  • Talla M: Estas pruebas son las que están por debajo de una hora y que pueden ejecutarse de manera continua en el software que queramos probar. La táctica ideal es ejecutarlas en la compilación en curso y esperar a que exista una nueva compilación para volverlas a ejecutar.
  • Talla S: Son pruebas que se ejecutan de manera muy rápida (en menos de 5 o 6 minutos) pero que forman parte indispensable del KO o KO de la compilación en cuestión. Deben de ser muy rápidas porque los desarrolladores sabrán inmediatamente el resultado y podrán solucionarlo ágilmente. Estas pruebas se ejecutan de manera constante para saber que la compilación sigue en orden.
 
Aunque parezca redundante, el tener una suite de pruebas que se ejecute constantemente nos dará resultados inmediatos en las pocas líneas de código que se realicen en esa jornada y si existe algún error, se acotará de manera mucho más sencilla.
 
Estas pruebas, que hemos seleccionado con sus tallas correspondientes, deben de ejecutarse en diferentes estrategias para que los resultados y su efectividad sea total y garantice lo que estamos haciendo. Vamos a revisar algunas:

  • Automatizar es vivir. En muchas ocasiones cuando alguien realiza un cambio, tira algunas líneas de código o finaliza el trabajo que tenga que hacer, ejecuta las pruebas para verificar que todo sigue en orden. Para estos casos, tenemos las pruebas automáticas ejecutadas de manera constante, a las que se les van añadiendo nuevas pruebas para ese código en concreto o esa funcionalidad y así sabremos siempre que todo sigue en orden. Por ejemplo, si tenemos una suite de integración continua, estas deben de ejecutarse cuando se hace cualquier commit y se detectan cambios, tanto en local como al subir al repositorio.
  • Mejor suite pequeñas. No hay que obsesionarse con hacer grandes suites de pruebas que tengan que probar todos los resquicios totalmente, es importante realizar bastantes pruebas de tamaño S y colocarlas en una suite pequeña que se ejecute de manera muy rápida y ágil.
    Esta estrategia unida a un entorno Agile con Scrum, tiene un valor enorme ya que trabajamos con historias de usuario que se pueden atomizar y cubrir con este tipo de pruebas. Además, en integración continua el tiempo es oro, por lo tanto, rapidez y al grano a la hora de probar.

  • Una buena configuración nos ahorrará un tiempo muy valioso. Cuando se va a ejecutar una prueba, primero hay que realizar una configuración. Siempre se puede optimizar este paso para que la ejecución sea más rápida y por lo tanto se devuelva el resultado. En muchas ocasiones, pruebas que se ejecutan mediante la interfaz de usuario pueden optimizarse si se prueba a través del API, ahorrándonos timeout, problemas de red y de carga o incluso de apertura del navegador o del ejecutable que corresponda. La ejecución de estas pruebas mediante los ciclos de integración continua nos puede ayudar a mantener estándares que valoremos en el proyecto y, sobre todo, a saber, que se ha roto casi en el momento, cuidando de evitar problemas mayores cuando ponemos todo ese código en entornos de preproducción o de UAT. 
 
Si, además, unimos estas pruebas a una serie de ejecuciones en herramientas como SonarQube, garantizamos que nuestro código, además de no contener defectos, será óptimo y seguro.

23 de abril de 2018

Épicas e Historias de Usuario en proyectos ágiles

Cuando trabajamos con metodologías ágiles, hablamos, principalmente de dos elementos donde confluye todo el ciclo de vida del proyecto: las épicas y las historias de usuario.


Estos dos elementos de trabajo son los que nos permiten realizar todo el esfuerzo y serán los que le darán una visibilidad total a los clientes a lo largo de los sprints.

Las historias de usuario, aparecieron por primera vez en 1999, en un libro de programación extrema (XP) y desde entonces, su progresión y utilización es cada vez mayor.

Muchas veces, tenemos la sensación de que trabajar con historias de usuario o con Scrum es algo novedoso o que está emergiendo ahora mismo, pero la realidad es muy diferente. Son metodologías y procesos de trabajo que llevan muchos años entre nosotros y se llevan utilizando y mejorando muchísimo tiempo.

Vamos a tratar estos dos elementos con detalle, en los siguientes puntos. Comenzamos con las épicas:

Por definición: son historias de usuario demasiado extensas y que se deben de disgregar y separar en otras más pequeñas, con valor propio y que se realicen dentro de un sprint. Son los elementos superiores que agrupan al resto. En los siguientes puntos, se detallan en profundidad las acciones que se realizan dentro de ellas.

Las épicas tienen un valor global, por sí mismas, de cara a cliente y cumplen los siguientes criterios de manera obligatoria:

  • Aportan un valor empresarial o de negocio.
  • Son estimables de cara a disgregarse en diferentes historias de usuario y tareas que entren en un sprint.
  • Son comprobables. El cliente debe de poder comprobar el valor real de la épica.


Las épicas forman parte de la planificación que se ha cerrado con el cliente y, por lo tanto, son los hitos más importantes que hay que cumplir para que el proyecto se desarrolle en fecha y con garantía. 

Estas épicas, a su vez, si establecemos un proceso de control de calidad, deben contener diferentes controles que aplican a cada área y que se encargan de medir el trabajo realizado y entregado por las mismas y si ha sido correcto o no, posibilitando la mejora continua dentro de cada sprint.

Como segundo elemento, y más importante, dentro de un proyecto, hablamos de historias de usuario. Estas, nos permitirán abordar los diferentes desarrollos que realicemos de una manera mucho más sencilla que con otro tipo de elementos de trabajo.

Una historia de usuario es un elemento con valor de negocio por sí mismo. Junto con las tareas, engloba y forma cada épica (si fuese necesario) y son atómicas, es decir, se pueden poner en producción por sí solas y aportan el valor suficiente a cliente para su utilización.

Las historias se completan a través del documento funcional (o requisitos funcionales) y tienen que contener toda la información posible para que las diferentes áreas puedan trabajar de la manera más adecuada.

Una historia de usuario tiene que cumplir los siguientes criterios:

  • Ser atómica, para entrar en un solo Sprint. Aunque puede retrasarse y postergarse, puede llegar el momento en que una historia pueda separarse en dos o en las que sean necesarias.
  • Tener valor por sí misma, de cara al cliente, a la hora de finalizar y desplegar en producción.
  • Ser estimable. La definición tiene que ser suficiente para que las áreas de trabajo proporcionen una estimación idónea en las reuniones de inicio de sprint.


Además, un método para realizar unas buenas historias de usuario pasa por seguir el procedimiento INVEST, que veremos en otro artículo.

La historia de usuario tiene que contener de manera obligatoria y lo más específicamente posible una buena definición, unos criterios de aceptación y toda la información adjunta que sea posible.


Si trabajamos en proyectos con metodologías ágiles, estos dos elementos serán los más importantes y con los que debemos de interactuar de manera constante, dedicando parte del esfuerzo en que se cumplan y se completen adecuadamente por todos las personas involucradas en el proyecto.

Tres palabras nos definen

Integridad

  • Trabajamos sobre la honestidad y la honradez.
  • Sólo te proporcionamos lo que de verdad necesitas.
  • Siempre buscamos como cubrir tus necesidades.

Ética

  • Trabajamos sobre una conciencia de responsabilidad.
  • Adquirimos un compromiso con cada tarea realizada.
  • Nuestra satisfacción es el trabajo bien hecho.

Sostenibilidad

  • Exportamos conocimiento y somos una comunidad.
  • Creamos un entorno colaborativo en todo lo que hacemos.
  • Pensamos en personas y su talento, no en números y cifras.
587 Publicaciones
Exportamos todo lo que aprendemos
5576 Seguidores
Hacemos comunidad entre tod@s
3285 Días
Seguimos aprendiendo a diario

¡We will rock you!

QA Global®
tu tranquilidad nos motiva
QA Security®
Tecnología para protegerte
QA Insurance®
Cuidamos de tu futuro
¿Colaboramos?
Nos interesa saber tu proyecto

¿Hablamos?

Cuéntanos como ayudarte

Si quieres más información sobre lo que hacemos, necesitas ayuda o quieres hablar con nosotr@s, solo tienes que ponerte en contacto.

Teléfono:

(+34) 648 961 876