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 control de calidad. Mostrar todas las entradas
Mostrando entradas con la etiqueta control de calidad. Mostrar todas las entradas

13 de abril de 2019

La planificación de un proyecto debe de ser entre tod@s

Al realizar una planificación en un proyecto, es realmente importante el hacerla entre todas las personas del proyecto. Cada una, pondrá su granito de arena y entre tod@s, será más facil el poder planificar las jornadas correctas y adecuadas.

La persona encargada del desarrollo, revisará adecuadamente toda la información y facilitará unas jornadas mucho más aproximadas que las que le pueden dar. También, la persona que realice las pruebas, hará igual, contando igualmente, con la gente de diseño, de SEO y de cualquier otra área involucrada en el proyecto.





La planificación debe de estar acorde con ese rango de fechas y adecuarse al número de personas que trabajen en el equipo. No es lo mismo una planificación adecuada y completa para realizar un ciclo completo de pruebas y que los defectos que aparezcan, los solucione una única persona, que no que tengamos a todo el equipo solucionando problemas, porque la entrega no es del todo correcta.

Una planificación adecuada nos dará un periodo correcto de desarrollo, con su periodo de validación, su escritura de test unitarios y dando tiempo a dejar el código limpio y mantenible, no solo es cuestión de entregar a tiempo, sino que conlleva mucho más que eso.  La planificación sirve para que cada área involucrada, pueda realizar su trabajo adecuadamente, con tiempo y sin hacer peripecias (que son las que luego nos penalizarán a la hora de entregar).

Si el tiempo es adecuado para un ciclo completo de pruebas, nos dará tiempo a realizar una buena batería, haremos una automatización completa y de todo lo que sea necesario, también, desde desarrollo, solucionarán los defectos de manera adecuada y con sus test unitarios integrados.


De esta manera, el proyecto se convertirá en algo sostenible, mantenible y con un código de calidad y acorde a lo que queremos entregar a cliente . Esto generará que la confianza del mismo y la positividad de las personas del equipo, aumentará y posivilitará que se hagan las cosas mejor a lo largo de las entregas.

Para realizar una buena planificación, hay que consensuar con todo el equipo, reunirse y hablar con todos las áreas implicadas, llegando a diferentes acuerdos, haciendo convivir la parte de negocio con la de desarrollo y calidad, adecuando todas las cuestiones a las necesidades reales y lógicas y como hemos dicho, anteriormente, hacer todo con sostenibilidad y de una manera adecuada. 

Cuando hablamos de necesidades reales y lógicas me refiero a que debemos de realizar una serie de priorizaciones para comprobar que es lo importante, lo crítico y lo antes necesario y así afianzar y facilitar una información adecuada al cliente.


La consensuación y el acuerdo entre tod@s es la base fundamental de un proyecto y el hablar y dirigir el proyecto para todas las personas, es indispensable para alinear a todo el mundo, para tener unos objetivos comunes y que el camino sea lo más sencillo posible.


El apoyo de todas las personas es algo totalmente fundamental a la hora de que el proyecto salga como debe de salir y no dejar a nadie detras o vendido es algo que debemos de realizar todas las veces que pueda surgir una situación así. 


Una planificación inicial y en cada entrega realizada por todo el equipo, hace que el proyecto se humanice, se forme un entorno colaborativo y la alineación entre personas, sea adecuado y positivo.

1 de abril de 2019

La importancia de un entorno estable de Testing

Cuando nos encontramos en un proyecto donde no se da importancia a los entornos y no tenemos una estabilidad, la realización de las pruebas no es óptima y no podemos garantizar al 100% nuestro trabajo.

Y si, has leído bien. En la época de Docker, integración continua, devops…etc, etc…aún nos encontramos con sitios donde no existen entornos de pruebas estables y decentes, que aseguren la correcta ejecución de nuestras pruebas.


Con un entorno inestable, un tester, reporta falsos negativos o tambien positivos, reporta errores que al final no lo son, nos dificulta la tarea de acceder correctamente a ciertos módulos de la aplicación y sobre todo hará que nuestras tareas se ralenticen o tengamos que reprobar defectos que ocurren por la inestabilidad.Esto, sucede exactamente igual que si hablamos de automatización. En un entorno en ese estado, la batería de pruebas fallará y nos encontraremos con que no se ha realizado el despliegue en el ciclo de CI apropiado.

Una de las peores cosas que nos puede suceder (aparte de no poder acceder al entorno) es que nos encontremos con falsos negativos o falsos positivos. Un falso negativo es en realidad un defecto que no es defecto en sí, un defecto que sucede por la inestabilidad del entorno, por incoherencia de datos o porque un despliegue puede haber estropeado el entorno y nos frene totalmente la realización de pruebas. Un falso positivo, nos puede ocurrir cuando creemos que está OK y en realidad no es así, dándonos bastantes quebraderos de cabeza.

Otro de los problemas que nos encontramos con los falsos negativos o positivos, es que si llegamos a abrir esos defectos y luego no ocurren, tendremos un peloteo con nuestros compañeros de desarrollo y ambos, perderemos bastante tiempo.

Para optimizar y garantizar nuestro trabajo al 100% necesitamos lo siguiente:

  • Un entorno lo más parecido al de producción posible.
  • Datos “reales” o en su defecto muy similares a los que podamos encontrarnos en producción. Con la nueva ley de protección de datos, hay que ofuscarlos obligatoriamente.
  • Una base de datos con las mismas características que la de producción.
  • Que el entorno sea únicamente de testing, que no tenga interferencias de desarrollo de ningún tipo.

Muchas veces, puede ocurrir que un entorno inestable pueda reportarnos la pérdida de muchas horas de trabajo y por lo tanto, que el visto bueno de la versión a desplegar se retrase por la falta de validación o incoherencia en sus datos.

En muchos casos, el entorno de pruebas es también un entorno de desarrollo, cosa que jamás debería de suceder, ya que si por un casual, se integra algo incorrecto y es propagado a este entorno y se cae o deja de funcionar, las pruebas se verán puestas en riesgo, además de que se necesitará una validación continua de todas las pantallas ya que no sabremos exactamente qué es lo que se toca y lo que no. Esto, aunque parezca mentira, es el pan de cafa día de much@s compañer@s y no suele ser por gusto, si no que, sus empresas no son lo suficientemente maduras para aportarles procesos de QA adecuados y tienen que luchar a contracorriente, día tras día, para sacar su trabajo adelante.

Lo ideal, en un entorno de testing es tener versiones cerradas cada cierto tiempo y ciclos de CI con baterías de pruebas automáticas. Pongamos un ejemplo práctico:
Desarrollo termina una serie de tareas e integra en su entorno, ejecutando los test unitarios y de integración oportunos. Así constantemente, con varias de estas tareas hasta completar una historia de usuario. Testing,  lanza su automatización y mientras, sigue realizando pruebas con su propia versión, en su propio entorno, de momento inalterable.

Una vez que la persona de  testing da el OK a esa versión, esta se sube al siguiente entorno de certificación (si existe)  o se despliega a Producción. La validación finaliza y se puede garantizar que esa versión en concreto está OK y es 100% funcional. Esta labor, se puede realizar de manera más tradicional en entornos en los que aún no existe devops o ciclos de CI y también en entornos con integración continua que manejen correctamente el versionado, a través de Jenkins o similar.

Así, una vez que testing ha dado el visto bueno, avisará al desarrollo para que despliegue  esa nueva versión para poder probarla en el entorno de pruebas (o en su defecto, se desplegará automáticamente si los test están en verde). De esta manera, mientras tanto,  desarrollo podrá seguir integrando sin problema en su entorno y sin interferir en los demás.

Trabajando con versiones cerradas y atómicas, hacemos que las subidas puedan estar mucho más controladas y podemos acotar las pruebas mucho más, sabiendo exactamente a que atacar y donde reforzar la validación.

Cuando estemos en un proyecto de cualquier tipo, siempre debemos de luchar por que tengamos nuestro propio entorno, así podemos asegurar, casi en su totalidad, una calidad realmente buena en el trabajo que realizamos y que los factores externos no estropeen nuestras pruebas.

7 de febrero de 2019

Como probar correctamente un eCommerce

Cuando vamos a lanzar una tienda online, tenemos que poner el foco en saber cuando vamos a realizar la primera acción para que empiecen los usuarios a utilizarla de manera masiva. Muchas veces, pensamos que el momento más crítico es cuando la ponemos en producción, pero no es así.



Cuando publicamos una página web o un ecommerce, el tráfico será nulo, ya que nadie tiene acceso y no sabe la URL para navegar hacia ella, por lo tanto, el momento en el que empezamos a publicitarla, es cuando las visitas comenzarán a subir y se moverá por la red.

Antes de ponerla en producción, evidentemente, hemos realizado las pruebas pertinentes y sabemos que no existen o no deberían de existir defectos, pero en ese periodo de falta de visitas, podemos aprovechar para realizar alguna que otra prueba definitiva. Siempre recomiendo que se realice en un entorno de post-producción o con una clave de acceso, pero si nos vamos al plano real, a veces, esto no se puede hacer.


La integridad de nuestra marca y el buen uso que proporcionará nuestra tienda a los clientes es la mejor cara que podemos ofrecerlos

Para que las pruebas sean efectivas, lo primero es que el hosting sea el que vamos a utilizar definitivamente ya que, al pasar de un servidor a otro o de un plan de hosting en la nube a otro, pueden variar las condiciones y el entorno donde se ejecutará nuestra tienda online.

Estas pruebas las pueden realizar los propios clientes ya que se conocerán el negocio a la perfección y podrán recorrer todos los caminos de una manera rápida.

Estas pruebas se denominan test de usabilidad, ya los explicamos anteriormente y consisten en coger a varias personas, que serán clientes o usuarios finales y se les hace realizar acciones en el ecommerce. Habitualmente, lo ideal, es que realicen procesos de compra.

Durante estas acciones, hay que observar, apuntar lo que hacen y fijarse muy bien, ya que quizá diseñaste algo que en tu cabeza es lo más usable del mundo, pero realmente no lo es tanto, ojo con esto. Este tipo de pruebas durarán unos 15 minutos.


También, se suelen realizar test A/B, que consiste en probar distintas versiones del ecommerce para ver cual tiene mayor ratio de conversión a venta.

Otros test que se realizan son los de cabecera, que consisten en enseñar a un usuario la cabecera del ecommerce en unos 5 segundos y preguntar, después, que se vende y si ha entendido el mensaje.

Lo que, si que suelo utilizar muchas veces, son test de mapas de calor, que nos “pintan” las zonas de la web por donde más pulsan los usuarios y cuales no. De esta manera, podemos plantear un cambio de botones o resaltar alguna sección en zonas de más uso.

Si queremos rizar el rizo, existe un tipo de prueba que es la de los tres click, donde cada usuario podrá hacer cualquier acción de nuestro ecommerce en tan solo tres click.

Uno de los problemas más recurrentes en ecommerce es la compatibilidad con navegadores y dispositivos, ya que, el hecho de no poder finaliza la compra en uno de ellos, nos puede llegar a ocasionar perdidas millonarias.

si intentas comprar un producto y no puedes…el ecommerce, por muy bonito e intuitivo que sea, no servirá de nada

Es muy importante probar con una buena batería de dispositivos, entre ellos tablet, Smartphone de diferentes tamaños y sistemas operativos y sobre todo tener un buen abanico de navegadores con los que acceder y comprobar que todo se puede realizar en todos los sitios.

Un problema que nos solemos encontrar con la compatibilidad en navegadores es que las fuentes no las trata cada uno de la misma manera o que el CSS no se visualice correctamente. Puede parecer que son cosas de menor importancia, pero si hay algo movido o descuadrado, da una imagen de dejadez que, al menos a mi, no me gusta nada.
Actualmente, si queremos estar a la última, nuestro ecommerce tiene que ser Responsive, es decir, se tiene que acoplar a todos los dispositivos móviles, y en una web habitual es más sencillo, pero ser capaz de ajustar las fotos y textos de diferentes productos, a veces, suele ser un quebradero de cabeza para diseñadores, desarrolladores y Testers.

Otro punto muy interesante a validar y que a veces damos como menos importancia, es la comprobación de los textos. Una palabra mal escrita o con alguna falta de ortografía, es algo imperdonable y que da muy mala imagen, por lo tanto, es una de las cosas más importantes que debemos de mirar, antes de nada. También, está bien que se repasen todas las imágenes y el favicon.

Y, por último, que menos que comprobar los formularios y las formas de pago. ¿Qué repercusión puede tener que un usuario no pueda contactar con nosotros o no pueda suscribirse a la newsletter? Pues si os soy sincero, enorme. Si me pongo en la piel de un usuario e intento contactar con alguna empresa y no puedo, mi cabreo será bastante grande, así que es algo a lo que hay que poner hincapié.

Sobre las formas de pago, es evidente, si intentas comprar un producto y no puedes…el ecommerce, por muy bonito e intuitivo que sea, no servirá de nada.
Tras ello, podemos revisar el archivo robots.txt, la página 404, diferentes divisas o idiomas…etc, etc…

Como veis, las pruebas a realizar no son triviales y agrupan una gran cantidad de variantes, por lo tanto, no debemos de escasear con el tiempo en el que las realicemos ni intentar pasar por alto alguna. La integridad de nuestra marca y el buen uso que proporcionará nuestra tienda a los clientes es la mejor cara que podemos ofrecerlos.

5 de enero de 2019

La clave de la filosofia DevOps es la calidad

Desde hace varios años venimos hablando de DevOps, una filosofía de trabajo (aunque muchos piensan que es una metodología o un proceso), que ha acelerado brutalmente la tasa de cambio que puede tener un software. Sorprendentemente, en España, estamos a años luz del resto del mundo y aunque hablamos de esta filosofía, muchas empresas no trabajan con ella de manera adecuada o lo confunden con poner en producción algo rápido y sin ninguna garantía.


Evidentemente, para paliar estas situaciones, la calidad debe de ser un pilar fundamental dentro de esta filosofía de trabajo y al aplicar entornos de entrega continua, debemos de tener en cuenta que el ciclo de producción es mucho más corto y tenemos claros unos objetivos inamovibles: desarrollar, probar y poner en producción.

Si la idea es correr mucho, teniendo un equipo de desarrollo modélico, con unas pruebas unitarias y de integración de diez, pero este gran desembolso de dinero se ve frustrado por que al poner en producción el producto, hay un fallo, nada de esto sirve y el dinero y esfuerzo invertido se vendrá abajo.

Si queremos poner algo en producción, es completamente imprescindible la realización de pruebas, y no solo unitarias, si no funcionales y no funcionales. Actualmente, lo que veo, es que incluso desde el mundo del Testing, nos estamos olvidando de las pruebas funcionales, obcecándonos en la realización de pruebas de integración (o unitarias), como las basadas en Gherkin y que, personalmente, os digo, no cubren todo lo que se debe de cubrir, y nos veremos con sorpresas desagradables en producción.

El ciclo completo de pruebas debe de ser completo, teniendo pruebas unitarias, de integración, manuales funcionales y automáticas (basadas en las manuales), sin contar con las no funcionales que nos darán buena cuenta de la seguridad y del rendimiento (entre otras muchas cosas) de lo que estemos probando. No nos olvidemos de que, aunque molan mucho y es más divertido el automatizar todo y solo centrarnos en ello, hay un amplio abanico más de pruebas que se deben de realizar y cubrir.

En un entorno de entrega continua, no nos podemos olvidar de la realización de pruebas en el API, además de todas las mencionadas anteriormente.

El perfil de la persona de QA no solo debe destacar por la realización de las pruebas realizadas, si no que debe de brillar a la hora de evaluar criterios de aceptación, definir estrategias de pruebas o cubrir todas las casuísticas posibles a lo largo del entregable. Esto, unido a los perfiles de desarrollo, harán que se forme una mentalidad de Cultura de Calidad temprana, que será lo que nos permitirá producir de manera segura, garantizada y adecuada.

Dentro de un ciclo de DevOps, debemos de descartar el uso de pruebas manuales al completo, ya que es imposible cubrir la velocidad requerida a lo largo de cada entrega, por lo tanto, si que debe de ser un acompañamiento de cara a la realización de pruebas exploratorias, pero se debe de compatibilizar con baterías automatizadas que puedan utilizarse en dispositivos móviles y en ordenadores.

Es importante, tener claro, que la idea de DevOps no se convierta en un entregar rápido y corriendo sin tener la garantía y la calidad que nuestros clientes nos demandan. Como todos sabemos, el boca a boca positivo es el éxito asegurado y eso se consigue con unos clientes satisfechos y que puedan utilizar nuestro producto de la manera adecuada.

20 de diciembre de 2018

Preparar unas pruebas de stress efectivas

Cuando queremos realizar pruebas de stress tenemos que tener clara su efectividad, y más en una época en la que una caída en un servicio o en un producto nos puede llevar a pérdidas millonarias.


¿Qué ocurre cuando tenemos un servicio de primera necesidad, como la luz o el gas y en una zona de la ciudad o pueblo donde vivimos se va? Que la gente va a entrar como loca a la página para intentar comprender que ocurre y que se lo solucionen. También ocurre con la compra de entradas o cualquier otro evento masivo.

Lo primero que tenemos que hacer es centrarnos en unos requisitos básicos:
  • La fuente de tráfico tiene que estar en lista blanca, para que no se considere un ataque y la prueba se bloquee.
  • Recopilación de métricas de rendimiento a medida que aumentamos el número de usuarios. De esta manera comprobamos la degradación.
  • Escenarios donde empujar miles de usuarios de prueba contra el sitio web.
  • Tener la capacidad de ejecutar las pruebas fuera del horario “normal”, donde el tráfico es bajo.
  • Hacer las pruebas repetibles y rentables (que no nos cueste mucho el retocarlas o poder reutilizar todo lo que podamos).
Una vez que tenemos cubiertos unos básicos, lo que tenemos que hacer es buscar una herramienta de pruebas de estrés válidas para nuestras necesidades. Tenemos que pensar cuantos usuarios necesitamos y con que frecuencia los lanzaremos. Debemos de tener en cuenta cuantas veces se ejecutarán las pruebas para observar que los despliegues realizados en el producto o cambios en la infraestructura, no han afectado al rendimiento.

Lo ideal es seleccionar dos o tres proveedores para hacer una primera prueba. Habitualmente, se realizan pruebas gratuitas y podemos evaluar cual nos vale y cual nos proporciona resultados lo más cercanos a nuestras necesidades. Una vez que tenemos controlado esto, tenemos que valorar la dificultad de manejo de las herramientas, y que no nos lleve demasiado esfuerzo el poder montar escenarios y lanzarlos.

Cuando queramos realizar las primeras pruebas, lo habitual es hacerlas durante el fin de semana, ya que las cargas de clientes suelen ser más bajas y sobre todo verificar que no existe ningún problema para que la prueba impactase en los clientes o en la infraestructura. También, debemos de probar las primeras ejecuciones en un entorno controlado, por si existiese algún error que nos tumbe el entorno completamente.

A lo largo de la ejecución de las pruebas, se debe de supervisar cuidadosamente a los servidores, para detectar problemas, cuellos de botella y averiguar si tenemos algo grave que solucionar de inmediato.
Cuando se finalizan de hacer las pruebas, habitualmente se encuentran mejoras en los servicios durante cargas enormes de usuarios o aumentar la capacidad de manera progresiva para que no acabemos con el producto caído y con los clientes vendidos.

Muy importante para que las pruebas sean realmente efectivas, es el buscar escenarios reales y con los que los usuarios se vean identificados. No tiene sentido el hacer caminos sencillos, poco concurridos o que no hagan, exactamente, las combinaciones habituales de nuestros clientes.

Una prueba de stress es algo sencillo de realizar, pero complejo en su análisis y preparación a nivel global, ya que, tenemos que tener claros muchos puntos para que la efectividad de las mismas sea positiva y no nos den resultados vacíos y que no nos digan nada. 

Una buena combinación de estas pruebas y de una lectura correcta de resultados, pueden ayudar a que nuestro software esté preparado para cualquier tipo de imprevisto.

17 de noviembre de 2018

Estrategias de validación de código entre desarrollo y QA


En los últimos años, las pruebas son muchísimo más complejas de lo que venían siendo. Ahora hay test unitarios, pruebas de integración, pruebas de humo, pruebas automatizadas tanto con Selenium, por ejemplo, o ahora involucrando RPAs y, por supuesto, Testing manual, una pieza clave que no se tiene que perder jamás (aunque muchos piensen que ya está muerto, aunque ya escribiré un artículo tratando el tema).


Todas estas pruebas son muy diferentes entre si, pero tienen algo en común: el tiempo. 

A lo largo de toda mi vida laboral, os puedo asegurar, que en ningún momento he vivido un proyecto en el que, poniendo en una balanza los tiempos y entregas de otras áreas de trabajo, han sido comparables a lo que hemos tenido en QA. Habitualmente se le da poco peso, prisas, somos el último eslabón y se nos recorta este maravilloso elemento tan escaso en nuestra sociedad actual: tiempo.

¿Cuál es la solución para ello? Si te dedicas a QA, pensaras lo mismo que pensamos el 99% de nosotr@s: aprietas el culo y sacas el trabajo con sudor y sangre. Pero, evidentemente, esta no es la solución ni lo que debemos hacer. En estos tiempos en los que está tan de moda la integración continua, el DevOps y la entrega constante, nuestras estrategias deben de cambiar y adaptarnos al futuro y a un tipo de revisión algo diferente de lo habitual, manteniendo la esencia.

Una de las ventajas de las nuevas tendencias en el desarrollo de software, es la entrada en valor de los microservicios, que nos aportan un aislamiento y podemos tratar paso por paso y en etapas, los diferentes servicios del software, sin que se vean afectados el resto ni pongamos en peligro todo el proceso completo.

Otra de las ventajas de estas nuevas tendencias, es que, si se realiza una estrategia adecuada, el código y la cobertura puede llegar a ser muy alta, y tener una batería de pruebas muy completa y con resultados muy buenos. Involucrando esta estrategia en el plan de integración continua, podemos obtener unos resultados óptimos y la calidad del proyecto aumentará.

Lo más importante, ahora mismo, es que, dentro del marco de la integración continua, entrega continua o DevOps, como lo queráis llamar, aunque sean términos diferentes, es tener muy clara esta estrategia, y sobre todo definir ciertas pautas antes de comenzar el proyecto, tanto a nivel de cobertura de código, como de que herramienta se va a usar para la realización de los test. Esto, lo que hará, es que la funcionalidad en concreto, llegará mucho más estable y libre de códigos a las personas de QA que realizarán las pruebas posteriormente.

De cara a realizar la estrategia, nos tenemos que centrar en el estado de las pruebas que se van entregando en cada sprint o release, cosa que podemos mejorar con una evaluación sobre puntuación en las funcionalidades (o historias de usuario entregadas).

Esta evaluación se puede hacer en una pizarra con post-it, poniendo las funcionalidades del proyecto y una numeración del 1 al 5 (siendo 1 muy mala y 5 excelente) en base a la batería de pruebas realizada y el estado de las mismas.

Cuando se hace la entrega, se cogen las funcionalidades entregadas y vemos el estado. Si este es bajo, lo que haremos es priorizar las pruebas para ese sprint o entrega siguiente y aumentar la nota de la misma si se ha cumplido el resultado. La fiabilidad de estas notas las podemos comprobar con herramientas como SonarQube, donde mantendremos un porcentaje de cobertura de código y observaremos si este se eleva o no. Esta pizarra se actualiza a diario y se van poniendo riesgos o posibles pruebas que se puedan realizar y esto se le asigna a alguien del equipo, que cubrirá la prueba con un test unitario o de integración, aumentando así, la nota de la funcionalidad a lo largo del sprint.

Es muy importante el mantener unos estándares de calidad adecuados y una cobertura de test por funcionalidad lo más alta posible, tanto a nivel de porcentaje (que nos proporcionará cuando código no está probado), como a nivel de que la funcionalidad y el código que la genera realice, justamente, lo que tenga que hacer. 

Este trabajo, se debe de hacer entre desarrollo y QA, que son los que pueden aportar casuísticas de pruebas para que la funcionalidad se cubra de manera total a nivel de validación y garantizar la calidad.

8 de enero de 2018

PRR, la manera de garantizar nuestros desarrollos.

En el momento que aceptamos el incluir un proceso de calidad en un proyecto, debemos de tener en cuenta que no solo hay que centrarse en la realización de casos de prueba, ya que esto hace que invirtamos un tiempo que muchas veces no tenemos.

Lo ideal, es que pivotemos entre estos casos de prueba y una serie de validaciones complementarias que nos ayudarán a ser ágiles y ha poder garantizar que el desarrollo tiene la calidad adecuada y que esperan nuestros clientes.



Estas pruebas complementarias, son las pruebas de regresión, las exploratorias, las de humo y las automáticas.

En varias ocasiones ya he hablado de ellas, de que son, como nos ayudan y como ejecutarlas y tenemos que tener claro que hay que realizarlas de manera, prácticamente, obligatoria.

Para las personas de desarrollo os recomiendo que les inculquéis qué realicen validaciones de los casos de prueba, que les sirven de guía y si no es posible, la realización de exploratorias que les ayuden a comprobar, aunque sea por encima, el desarrollo que acaban de finalizar. Esto, evidentemente es totalmente independiente de que se realicen pruebas unitarias, de integración o incluso funcionales automatizadas, por su parte.

La validación manual, aunque esté muy de moda el automatizar, es totalmente necesaria, a no ser que sean proyectos muy maduros que lleven tiempo o tengamos un equipo que, igualmente, sea lo suficientemente maduro como para cubrir toda la batería de manera automática. Exactamente el mismo caso que si realizamos BDD o TDD.

Si nos decantamos por estrategias ágiles en nuestros proyectos, debemos de ser consecuentes con las entregas y con las validaciones que se van a realizar, dando las suficientes jornadas para lo que yo llamo: “PRR” o prueba + resolución + reprueba.

Este PRR se realiza de la siguiente manera:

  1. Prueba: se realizan las validaciones necesarias con los casos de prueba, cubriendo todas las casuísticas que hemos escrito y definido y se abren todos los defectos que veamos, fallando los casos a su vez. También debemos de realizar las pruebas exploratorias, completando y compatibilizando estos casos de prueba y abriendo todo lo que tengamos que abrir.
  2. Resolución: en estas jornadas el equipo de desarrollo soluciona todos los defectos encontrados y se cerciora de que está todo funcionando, realizando la prueba automática y completando sus pruebas unitarias para que no vuelva a suceder el fallo.
  3. Reprueba: en estas jornadas, se reprueban los defectos solucionados volviendo a ejecutar los casos de prueba y poniéndolos en estado OK si todo ha ido bien. Si esto es así, complementamos estas ejecuciones con la regresión (que debe de estar relacionada con la funcionalidad más crítica y se puede y debe automatizar) y las pruebas de humo, que nos ayudarán a comprobar que no se ha roto ninguna otra funcionalidad o desarrollo independiente

Si cubrimos todas estas casuísticas y realizamos un buen PRR, tendremos la certeza de que el desarrollo es correcto y podemos pasarlo a la fase de certificación del cliente o si no existe, lo podremos desplegar a producción con total garantía. 



20 de diciembre de 2017

Pruebas de humo como buena práctica

Las pruebas de humo, que las vengo realizando desde hace mucho tiempo, son aquellas que pretenden evaluar la calidad de un software justo antes de ser entregado para certificar.


La idea, es hacer un repaso rápido de que la totalidad del producto que se va a entregar, funciona de manera correcta. No deben de encontrarse defectos críticos o bloqueantes y si no, debería de pararse el entregable y no pasarlo a certificación por parte del cliente.

El nombre de estas pruebas proviene de las antiguas instalaciones de tuberías que estaban soldadas a mano y a las cuales se le inyectaba humo con un fuelle para comprobar que no existiesen fugas. La idea con las pruebas, es exactamente la misma.

Cuando se realizan pruebas de humo, no hay que centrar el tiro en encontrar defectos (para eso realizaremos validaciones funcionales con los casos de prueba o las pruebas exploratorias), si no que hay que poner el foco en la funcionalidad.

Este tipo de pruebas requiere de cierta agilidad y de cierto conocimiento por parte de la persona que las ejecute, ya que tiene que ir a tiro hecho y no entretenerse en saber como funciona la pantalla.

Estas pruebas se deben de estimar, aunque no se ciernan en la ejecución de casos de prueba, ya que tenemos que tener claro el tiempo total donde las vamos a ejecutar y si tenemos horas o algún día para finalizarlas, cubriendo funcionalidad en base a este tiempo marcado.

En principio y si el proyecto no lo demanda, no se debe de realizar una documentación de las pruebas, se deben de basar en el conocimiento de la persona que las realiza.

Personalmente, creo que las pruebas de humo son una de las mejores prácticas que podemos realizar para garantizar la calidad del software en un proyecto.

19 de diciembre de 2017

Controles de calidad de Front, Sonarqube y un código sostenible

Cuando utilizamos controles de calidad en un proyecto (que debería ser siempre) debemos, no solo, de implementarlos a lo largo de todo el proceso, si no que también tenemos que aportarlos en los diferentes equipos que estén colaborando entre ellos.


Para un equipo de desarrollo de Front, es altamente recomendable aportar pautas de revisión antes de entregar los desarrollos, así realizarán un ejercicio de sostenibilidad y mantenibilidad en el código.

La persona que entregue ese desarrollo de Front será la encargada y la responsable de asegurar que todos esos controles están funcionando y han sido repasados y en base a la criticidad marcada, será la encargada de solucionar los posibles problemas que se puedan encontrar.

Como posibles controles de calidad podemos encontrar lo siguiente:

  • Evitar el uso de variables globales.
  • Evitar el uso de objetos globales.
  • Realizar una revisión de la consola del navegador en busca de posibles errores.
  • Revisar la pestaña “network” de la consola del navegador (en chrome es muy sencillo) para comprobar que no se están cacheando archivos. Por ejemplo, archivos .js o .html.
  • Hacer “Profiling”: Revisando que no existen problemas de rendimiento o de memoria del navegador. En Chrome se puede realizar todo en la misma consola.
  • Revisar que el código está minificado.
  • En el propio navegador, comprobar que se están cargando los Bundles.
  • Hacer estrategia de código limpio: revisando que la notación de variables y funciones es correcta, según las guías utilizadas.
  • Revisión de constantes con mayúscula.
  • Eliminación de código duplicado.
  • Que no existan variables sin usar.
  • Revisión de magic strings para eliminarlas.
  • Módulos o componentes obsoletos.

Esto es un ejemplo de todos los controles o puntos que se pueden revisar antes de realizar una entrega para validar y evidentemente, es un paso previo a la ejecución de la validación funcional que debe de realizar el equipo de desarrollo con la ayuda de los casos de prueba.

Como podéis observar, algunos de estos puntos, son prácticamente imposibles de realizar a mano, ya que se nos iría gran cantidad de tiempo y esfuerzo. Pero, para ello, existe Sonarqube, que nos ayuda a implementar en forma de regla, todas estas cuestiones y en la build de entrega a la rama principal, se realizará un análisis estático del código, dándonos el resultado de la ejecución, de manera automática, de estos controles de calidad de front y ayudándonos a resolver todos los problemas, de una manera visual, amigable y sencilla.

Todo esto lo he aprendido con el tiempo y el trabajo, mano a mano, con Ivan Reinoso, un maestro Jedi (de los de la trilogía original, los que luchaban contra el reverso tenebroso) en esto del Front, que se preocupaba de que sus desarrollos fueran sostenibles, mantenibles y aportaba las pautas más eficientes para que el resto de equipo hiciera lo mismo.

27 de noviembre de 2017

Realizar un ejercicio de transparencia

Antes de realizar cualquier entregable, debemos de realizar una serie de informes y estadísticas que nos permitan gestionar de cara al cliente, un ejercicio de total y abierta transparencia.


Este informe o documento debe de contener la funcionalidad que se va a entregar, que número de defectos hemos ido abriendo a lo largo del sprint o iteración, y cual es la tasa de corrección aplicada.

Este ejercicio de transparencia, tendrá dos funciones: 

la primera será que no tenemos nada que ocultar al cliente, ajustando sus expectativas y siendo lo más claro que podemos ser: somos así y vamos a mejorar en un porcentaje determinado por sprint. 

En segundo lugar, nos hará trabajar mucho más fino y de manera correcta, ya que vamos a enseñar lo que hacemos, a los clientes.

Estos informes se pueden realizar en base a controles a lo largo de los sprint, basándose en hitos como la documentación, las historias de usuario, validaciones, pruebas unitarias...y una vez realizado eso, habría que determinar el número de defectos generados y detectados, y sacar gráficas de comparables con entregas anteriores.

Si la gráfica es peor, no debemos de hacer saltar todas las alarmas si no que debemos de identificar que estamos haciendo no tan bien y consensuarlo con el cliente para que nos de feedback y podamos mejorar en el futuro.

Si la gráfica sale mejor, debemos de realizar una buena documentación para poder consultarla de cara a otros proyectos, reutilizando las ideas y la forma de trabajar, que tan bien nos lleva a hacerlo todo.

El verdadero valor de hacer este ejercicio, es inculcarnos una manera, obligatoria, de hacer las cosas bien, ya que las vamos a enseñar y además, aprender junto con los clientes a retroalimentarse, mejorando juntos.

23 de noviembre de 2017

Cumplir el proceso de calidad nos ofrece buena reputación y excelentes resultados

Cuando implantamos un proceso de calidad, hay que ser consecuente con su utilización, no se puede dedicar mucho esfuerzo a plantearlo, describirlo, habilitarlo y pautarlo, y despues saltarse las reglas impuestas a la torera.


En un proceso de control de calidad, la responsabilidad recae en una persona, el lider de QA, el QA Manager, el responsable de Calidad o como se quiera llamar, y es él, en todo momento, el que tiene que decidir si algo está o no está OK para ser desplegado o entregado a Producción (o a UAT). 

Una vez que se ha evaluado que el entregable no es correcto, mediante, por ejemplo, un resultado negativo en la ejecución de los casos de prueba, se puede consensuar y priorizar que es lo que se va a solucionar antes y que se le entregará a cliente con total garantía.

Evidentemente lo que no vale y que, a corto plazo, acaba afectando a la reputación del proyecto, es mirar hacía otro lado y entregar a cliente sea como sea. Si esto sucede, podemos tener la mayor de la tranquilidad a nivel interno, pero si se habla con los usuarios finales, acaba descubriendose la verdad y solo el hecho de nombrar a la aplicación, causa escalofrios.

Cuando nuestros clientes están contentos y satisfechos de utilizar la aplicación que les ofrecemos, es cuando pueden utilizarla, semana tras semana, sin ningún problema. No cuando una semana pueden hacerlo y a la siguiente, no, porque hemos desplegado en producción una versión con regresiones.

Uno de los puntos fuertes de este proceso, es detectar que estamos haciendo mal, implementando posteriormente, una serie de mejoras o correctivos que han de cumplirse obligatoriamente para no volver a recaer en los mismos problemas en cada entregable. Es una pena, el invertir gran cantidad de tiempo y dinero en un plan complejo y completo de calidad y que todo caiga en el olvido o no se utilice como debe. Además, es realmente frustrante el tener todas las herramientas necesarias y no utilizarlas adecuadamente, llegando a mirar hacía otro lado para poder desplegar a producción, creyendo a pies juntillas que estamos haciendo lo correcto.

Si implantamos un proceso de control de calidad, tenemos que ser consecuentes con su aceptación y su utilización, aplicando cada norma, cada restricción y no hacer una calidad de cartón-piedra.


22 de noviembre de 2017

Pautas indispensables para entregar un desarrollo con calidad

Las pautas necesarias para realizar un desarrollo de calidad deben de venir acordadas y revisadas desde el principio, marcándonos reglas y pautas que debemos de seguir de manera obligatoria.


Estas pautas nos deben de facilitar el trabajo y no impedírnoslo y sobre todo no hay que buscar el control, si no que, hay que buscar que los desarrollos se realicen de la mejor manera.

Lo primero que hay que hacer es seleccionar una metodología de trabajo adecuada, no es lo mismo un proyecto vivo que no ha salido a producción que uno que está en mantenimiento, esta selección nos aportará gran parte de lo que necesitamos, dentro de ello, debemos de adaptar a nuestras necesidades, ideas que más se adecuen al proyecto.

Otro punto importante, es el tema de las estimaciones, que debemos de ajustar lo máximo posible, contando con la parte de validación, que será nuestro salvoconducto de cara a posibles fallos futuros. Un buen plan de pruebas nos garantiza la viabilidad de lo que hacemos.

A la hora de planificar, debemos marcarnos hitos que sean lo más atómicos posibles, haciendo que los entregables sean más sencillos de realizar y por lo tanto, de cumplir. Marcarnos hitos grandes, seguramente nos lleve a no hilar tan fino a la hora de entregar.

La documentación o la generación de unos buenos requisitos, nos permitirá cubrir el desarrollo con todas nuestras necesidades y debemos de enriquecerlos con lo necesario para ello. Pueden ser descripciones, adjuntos, capturas, diseños...todo lo que nos ayude a mejorar y a cumplir con lo acordado de manera correcta. Lo ideal, es realizar los requisitos básicos, los derivados y los implícitos, que nos permitirán estimar muchísimo mejor. 

Muy relacionado con esta documentación, está el diseño de la aplicación, distribuyendo la funcionalidad de manera adecuada o incluso, con una distribución orientada a objetos, nos puede permitir el éxito de los entregables. También, tenemos que tener en cuenta que la reutilización de código, que en muchos casos no se utiliza, si está bien implantada, nos ahorrará infinidad de costes y sobre todo, quebraderos de cabeza.

Tras todo ello, hay una parte importante que es, la definición de una buena arquitectura del sistema, que nos permita trabajar cómodos y de la manera más sencilla posible. Una arquitectura muy potente que entorpezca el trabajo, en vez de facilitarlo, sencillamente, no vale para nada.

Con la arquitectura, debe de venir dada una implantación de automatización de builds y una automatización de pruebas automáticas (sean unitarias o no) que nos verifique, rápidamente, que no se ha roto nada.

Como punto final, y que es transversal a todos los puntos anteriores, debemos de definir una estrategia de pruebas rigurosa y ferrea, con una buena definición de casos de prueba, que validen la funcionalidad entregada y que se entrega, de la mejor manera posible. Esta estrategia se debe de realizar de manera paralela a todo lo demás, indicando en que puntos se va a verificar la calidad y en que puntos vamos a marcar hitos para poder observar como está funcionando todo.

Una vez que hemos hablado de todo lo demás, hay que dejar claro que para triunfar en un proyecto, hay que documentar, ya que con esa documentación, tendremos la fiabilidad de que todo se ha cumplido y de que si existe un problema, podemos encontrar como solucionarlo, simplemente, leyendo o siguiendo unos pasos.

Si ha todo esto le sumamos el control de calidad, tenemos casi seguro, que el proyecto saldrá adelante con total garantía para la empresa y sobre todo, para los clientes.

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