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

13 de abril de 2019

Validando código obvio

Cuando estamos involucrados en un proyecto, tirando de líneas de código como locos, en muchas ocasiones, nos entran dudas de que es lo que debemos de probar, que casuísticas son las que deben de generar test que nos hagan saber si lo que estamos haciendo, es lo que debería.



En la gran mayoría de ocasiones, siempre vamos a probar lo que creemos que va a fallar, lo obvio y lo que nos genera dudas, de esta manera, nuestro cerebro enlaza que están cubiertas las zonas oscuras de nuestro código y por lo tanto, la calidad estará garantiza. Pero, la pregunta del millón es: ¿cubrimos cosas obvias o que nosotros creemos, o estamos seguros de que funcionan?

Habitualmente, lo que sucece es que estas cosas “obvias” no se comprueban, las damos por hechas y por validadas. Nuestra “humanidad” nos dice que no son necesario validarlas, nuestro cerebro nos ahorra tiempo, que no tenemos y confiamos en ello, en que funcionará e irá bien.

Cuando estamos tirando lineas de código y nos liamos a realizar test unitarios, pensamos en un montón de cosas que son demasiado obvias para probar y nos centramos en los casos complejos. Esto nos lleva a que si falla algo obvio, el tiempo de encontrar el fallo y solucionarlo nos llevará más tiempo, porque claro, lo obvio...no debería de fallar.

La estrategia a seguir es muy sencilla. Todo código tiene, siempre, una serie de secciones que se van repitiendo, y que, por ejemplo, son: un login, un botón acceder, un menú de secciones, una sección de contacto...un número limitado de módulos que suelen existir en todo proyecto y debemos de tener categorizados, ya que, habitualmente, los códigos pueden reutilizarse.

Si tenemos una categorización de módulos, podemos tener una serie de test ya creados que prueben estos módulos “obvios”, y que simplemente, tendremos que ajustarlos al proyecto que aplique y lanzarlo para ver su resultado.

Si contamos con una batería de test genérica que pueda validar una serie de módulos que suelen utilizarse habitualmente, lo único que tenemos que hacer, es ampliar esta batería con los casos diferenciales y que no son obvios y tendríamos una gran cantidad de código ya probado y garantizado para que las personas de QA puedan validarlo y darle el OK definitivo.

Lo más importante, siempre, es tener estrategias de pruebas a nivel de código, que nos mantengan una exigencia y una calidad en nuestro trabajo y que junto a las nuevas formas de trabajo en entornos DevOps, con las herramientas de análisis de código, como SonarQube, podamos mantener unos estándares adecuados en el código que generamos.

18 de marzo de 2019

Estrategia de pruebas para dispositivos móviles y navegadores

La necesidad que tenemos de realizar validaciones en dispositivos móviles es ya una realidad. Todas las empresas tienen ya presencia en ellos ya sea por tener apps nativas como portales responsive.



Ahora mismo, una mala app en un dispositivo, es el detonante perfecto para que una empresa pierda mucho dinero y tenga menor presencia en relación a sus competidores.

Esto, lo sabemos todos nosotros, ya que, si instalamos una app en nuestro dispositivo y esta tiene un mal funcionamiento, es lenta o falla, directamente buscaremos una alternativa y la desinstalaremos. El usuario medio, es realmente exigente y eso se demuestra cada día en que, los smartphone actuales tienen unos procesadores muy potentes.

La demanda actual de dispositivos y aplicaciones móviles, nos hace tener estrategias de validación para dispositivos, teniendo en cuenta que debemos obtener un nivel de exigencia aún más alto. 

Lo primero que debemos de hacer es estudiar el mercado, y herramientas como NET Marketshare, nos da exactamente eso: que dispositivos, navegadores y sistemas operativos son los más utilizados. Así vamos cubriendo, poco a poco, la demanda y utilización actual.

Este portal, nos ofrece diferentes gráficas, datos y detalles actualizados, que nos dan una idea global de por donde se mueve el mercado y donde tenemos que atacar. Evidentemente, no podemos tener todos los móviles ni creo que desembolsar grandes cantidades de dinero, sea eficiente, ya que, en muy poco tiempo, ese parque de dispositivos se habrá quedado anticuado.

Cuando realicemos las búsquedas necesarias o que nos ayuden y tengamos un número que consideremos adecuado de dispositivos, que vendrá dado por el tipo de proyecto y los usuarios potenciales que van a usar la aplicación, en concreto, debemos de ver que sistemas operativos son los más utilizados. Habitualmente, estaremos hablando de Android e iOS en diferentes versiones, donde iOS tiene un nivel de actualización y utilización de la última versión, muy superior a Android.

En este último, la actualización del sistema operativo suele ir de la mano de los últimos modelos de dispositivos del mercado, que no todo el mundo tiene o compra. Son dispositivos más longevos, pero menos actualizados.

Una vez hemos obtenido los datos adecuados para nuestra aplicación, procedemos a realizar una tabla, donde mezclaremos los dispositivos con las versiones y seleccionando tablet y smartphone entre ellos, posibilitando que todas las versiones estén probadas en diferentes dispositivos con tamaños, también, diferentes.

Mi recomendación es que solo repitáis tamaño de pantalla en dispositivos diferentes, por ejemplo, un Samsung Galaxy y un iPhone, no dos iPhone con distintos sistemas operativos. 

De esta manera, obtendremos alrededor de 15 dispositivos distintos, con tamaños, resoluciones y pantallas diferentes con todos los sistemas operativos seleccionados, sin repetir ninguno.

Por ejemplo, una versión bastante eficiente de dispositivos y sistemas operativos utilizados a día de hoy, sería la siguiente:


Con esta tabla, a expensas de algún modelo más novedoso que aparezca en breve, podemos comenzar a trabajar sin ningún problema, sabiendo que cubrimos mucha cuota de mercado con un abanico relativamente pequeño de dispositivo. Esto lo hacemos, ya que estamos trabajando con modelos muy nuevos y algunos más antiguos, que estén más afianzados en los hogares, como por ejemplo la Tab E que data del 2015 aproximadamente.

Para el tema de navegadores, hacemos lo mismo, cubriendo tantos sistemas operativos y dispositivos como existan en el mercado. Aquí, la tasa de actualización es altamente superior y además, jugamos con que, los navegadores suelen actualizarse directamente, sin preguntar.

Podemos comenzar con una tabla similar a esta:


Lo bueno que tiene este tipo de pruebas de compatibilidad, es que podemos utilizar máquinas virtuales, Amazon Workspace o alguna otra herramienta similar que nos permitirá tener una buena batería sin tener la necesidad de comprar o adquirir muchos dispositivos físicos.

Si ya queremos comenzar a automatizar, no os olvideis de herramientas como Appium. Hay un artículo muy completo, que escribío nuestra compañera Estefanía Fernandez Muñoz, que habla sobre todos estos temas. Lo podéis leer aquí.

Podéis tener más ideas de como comenzar las validaciones de dispositivos móviles, que herramientas existen y cómo utilizarlas, adquiriendo uno de mis libros, en los que trato más en profundidad todos estos temas: El arte de asegurar la calidad en proyectos software.

15 de enero de 2019

El futuro de las pruebas de software

De hace diez años a ahora, las pruebas han evolucionado exponencialmente en base a las herramientas que se utilizan, la manera en que se aplican y la mentalidad de las empresas que cada vez las tienen más en cuenta.


Hemos pasado por utilizar Excel para hacer casuísticas, o planes de prueba, a utilizar herramientas de test management, también de estar en equipos independientes, a formar parte de los equipos de desarrollo, con las metodologías ágiles y sobre todo de ser uno de los pilares del ciclo de vida del cualquier producto. 

Ahora somos los que probamos el software, evaluamos posibles riesgos, ayudamos en la implantación y seguimiento de la metodología, de procesos y creamos estrategias de pruebas, también somos los perfiles que ayudamos a poner en producción cualquier producto con la garantía que quiere y necesita cualquier cliente.

Pero, en este año, la tecnología está llegando a su próximo límite y ello nos obliga a actualizarnos y a mirar de cerca todo esto.

En primer lugar, tenemos ya aquí, la inteligencia artificial. Es la nueva moda, lo que ahora está en boca de todos y es el futuro cercano de la tecnología, ¿Quién no tiene o ha pensado en comprarse un Echo con Alexa?

Si hablamos de pruebas, nos encontramos con herramientas que aprenden automáticamente de la cantidad de pruebas que realizamos y automatizamos, cuanto más tengamos, más aprende y más nos ayudan los algoritmos a que el producto esté probado y con garantía de subir a producción.
Una buena manera de utilizar la inteligencia artificial es no dejar que nuestras pruebas comiencen a fallar si en el desarrollo se cambia algún atributo, por ejemplo. Gracias a ella, podemos observar el directorio de atributos y la misma inteligencia artificial, lo cambiará y nuestras pruebas nunca dejarán de funcionar.

También podemos esperar que la integración de las pruebas con los ciclos de integración continua sea mejores, que personas no técnicas puedan automatizar o que las pruebas sean más sencillas y su mantenimiento también.

Otro punto clave de lo que puede llegar a ser QA, es utilizarla como servicio. En los últimos años, muchas empresas están utilizando este sistema para solventar problemas en sus productos y así garantizar todo su software de mejor manera. 

Tenemos un gran abanico de servicios como dispositivos móviles, redes, tester y máquinas virtuales que se pueden contratar como servicio y solventarnos algunos problemas de crecimiento de equipo, de cuello de botella y de tener grandes máquinas para mantener nuestras pruebas automatizadas. Ahora mismo, con este tipo de soluciones, nos encontramos con que eso ya no es problema, y se contratan bajo demanda y según las necesidades que se tengan. Siempre opto por que las empreas tengan sus propios equipos de QA y que trabajen mano a mano con todas las personas, pero a veces, si tenemos muchas cosas en paralelo, nunca viene mal tener un servicio de un tercero que nos proporcione una mano amiga para probar y garantizar todo como debemos.

A nivel colaborativo, podemos hablar de DevOps como el gran aporte de estos últimos años, asegurando automatizaciones, monitorización y una administración de la infraestructura mucho mejor y más segura. Lo que nos depara el futuro en este terreno es el trabajo con TDD para automatizar desde el inicio, también debemos de crecer a nivel de tareas en integración y despliegue continuo y que se alineen mucho más con los ciclos de vida del software.

Para que todo esto se cumpla, es necesario que los niveles de colaboración sean mayores, y que los entornos donde probamos estén estendarizador, permitiendo obtener unas pruebas realmente férreas y seguras, garantizando todo lo que tenemos encima de nuestro tejado. Si tratamos el tema de la colaboración, es imprescindible el que todas las personas que participen en el proyecto, tengan en la cabeza la palabra calidad y aseguramiento de la calidad, y generar una cultura que trate de unificar criterios, trabajar mucho más unidos y que tengamos en cuenta todos los ciclos de prueba para poner algo realmente bueno en producción, sin esta colaboración, todo lo que venga en el futuro no tendrá sentido.

Por otro lado, tenemos el “malogrado” internet de las cosas, donde no llega a cuajar o a aterrizar del todo, pero que, si se nos pone delante el caso, debemos de probar, al igual que cualquier aplicación. Para ello, es importante, que en un futuro contemos con unas baterías más férreas de pruebas de integración, comprobando que todas las casuísticas con todos estos aparatos, estén cubiertas y no falle nada entre ambos. Es una tecnología, que, aunque no está cuajando ahora mismo del todo, estoy seguro que en unos años, volverá con fuerza y cualquier aparato que podamos tener en casa, estará conectado y podremos interactuar con ella, así que, a corto o medio plazo, debería de ser un punto de control en cualquier organización y preparar a los equipos de QA es imprescindible para ello.

En todo este tiempo, los avances que se están teniendo en tecnología han influido y seguirán influyendo en la forma que tenemos de realizar pruebas y también, provocando que muchas empresas estén tomando estrategias diferenciadoras, utilizando, por ejemplo, robots de pruebas (que están monitorizados por personas de QA), pero que sin un orden y una visión hacía el futuro, cualquier organización le será muy complicado el estar en la cresta de la ola. 

Desde hoy, es imprescindible, que cualquier equipo de QA esté preparado para lo que está por llegar y comience a fortalecer pilares como la inteligencia artificial, la robótica, las pruebas de integración y el, de momento llamado, DevOps.

3 de diciembre de 2018

Agile or not Agile, that is the question...

Llevo años escuchando en todos los sitios que son ágiles, que trabajan en Agile…pero cuando te adentras un poco más profundo, descubres, que no es oro todo lo que reluce.

Cuando se habla de Agile, lo primero que se nos viene a la cabeza es un entorno colaborativo, historias de usuario…o sea, una vuelta completa a lo que es un equipo de desarrollo. Cuando empezamos a trabajar de este tipo, la directiva es la primera que ve reticencias, y es a la primera que tenemos que convencer.

Una directiva, habitualmente, manda, crea tareas, las distribuye, prioriza a las personas y tiene la batuta de una empresa, pero cuando trabajamos en Agile, esto empieza a cambiar y hablamos de “producto poner”, que es quien va a coger la batuta del equipo.

Un cambio de mentalidad importante, viene, cuando se aprende a que la directiva tiene que ser capaz de quitarnos de en medio, problemas y obstáculos y tiene que dejar la batuta a otra persona, olvidándose de manejar nada. Como bien dice la frase, contrata a las personas que saben para hacer su trabajo, no te metas, y verás los resultados flotar en poco tiempo.

Este cambio de mentalidad suele venir a través de una confianza mutua, pero es complicado de conseguir. Honestamente os digo, que la mejor manera, es demostrar resultados.

Si se confía en el trabajo de los profesionales a los que contratas y le das un entorno adecuado y los motivas, los resultados vendrán solos, y esto hará que la confianza crezca, al final es una especie de simbiosis que crece y crece, sin parar.

Cuando se demuestra confianza en el equipo, estos, se sienten capacitados para auto organizarse y para dar lo mejor de si en los proyectos. Si se dan una serie de pautas y un proceso ordenado y robusto, el crecimiento profesional de las personas es enorme, esto lo he vivido con muchas personas que han pasado por mi equipo y me enorgullece ver como toman su propio camino y son enormes profesionales del sector.

Otra de las grandes bazas con las que debemos de jugar es con la libertad. En muchos sitios se piensa que la libertad es peligrosa y que muchas personas tienen la idea de “dar la mano y te cogen el brazo” y yo sigo, si, pero hasta cierto punto. Hay que saber manejar esa libertad y dar confianza por encima de todo, y que cada uno, se la gane y la mantenga en base a sus resultados y a que su trabajo esté siempre listo. Si la libertad que “se ganan” es alta, tienen muchas probabilidades de probar cosas nuevas y de tirar hacía adelante mucho más fácil, solventando problemas, sin dudarlo.

Implantar Agile, es una manera de enfocar esa profesionalidad en las personas, de darlas esa libertad, esa profesionalidad y esa manera de seguir su camino sin ponerles trabas. Junto a estas pautas, anteriormente escritas, Agile es uno de nuestros grandes aliados por el formato de trabajo que nos permite realizar, y, sobre todo, que genera la confianza de ser una metodología reconocida, comprobada y que lleva muchos años dando alegrías a las empresas que lo aplican y lo implementan de la manera adecuada.

28 de noviembre de 2018

Pautas mínimas para definir una estrategia de automatización en un proyecto

¿Cuándo debemos de automatizar y cuando no?, ¿usar Selenium es la alternativa perfecta?, ¿existe un criterio en común para automatizar pruebas?


Estas preguntas y otras 1000, nos rondan la cabeza cuando entramos en el mundo de la automatización. Vamos a dar forma a algunos y a determinar los mínimos que debemos de cumplir, cuando tenemos que empezar a automatizar.

Lo primero, evidentemente, es valorar la herramienta de automatización. La más conocida, a día de hoy, es Selenium, un estándar para automatizar acciones dentro de un navegador, que “copia” los movimientos que puede hacer una persona en la pantalla. La comunidad de esta herramienta es brutal y a través del API de código abierto, se han realizado muchos plugins y mejoras que se utilizan actualmente en infinidad de proyectos.

Ahora bien, esta herramienta hay que utilizarla con inteligencia, si no, no vale de nada. La estrategia idónea que se debe de utilizar ahora, es automatizar una serie de test (ya sean de regresión o no) e introducirlos en el ciclo de integración o despliegue continuo. Esto nos determinará si es todo correcto y si no es así, no se desplegará al entorno correspondiente.

Lo más sencillo, para comenzar a automatizar un proyecto, es coger la batería manual de regresión y empezar a automatizarla. Esto nos ayudará a cubrir si algo se ha roto con la entrega actual.
Otro de los puntos que debemos de tratar es la integración o el despliegue continuo. Esta forma de trabajar ha venido para quedarse, y debemos de conocerla muy bien y, sobre todo, aprovechar los puntos fuertes que nos permiten el tener un control total de si se despliega o no, en base a los resultados que nosotros aportemos.

Los servicios de integración continua, nos permiten automatizar tareas que se realizaban manualmente por personas, habitualmente, administradores de sistemas y que ahora en un solo click, es posible el realizarlas.

La labor de las personas de QA es saber como funcionan los servicios de CI para tener un control total sobre los despliegues y poder aunar esto con las pruebas automáticas, permitiendo que no se ponga en producción un software defectuoso. Además, se agilizan las tareas de solicitud de despliegues o de espera a poner el software en el entorno de pruebas, ya que, la persona que valida, puede realizar el despliegue por si misma, validando los defectos que se han solucionado. Esto, es una relación directa con la automatización, pero sin tener que programar, simplemente, llamar a servicios que hacen las labores automáticas por nosotros mismos.

Otro punto que debemos de controlar es el acceso al historial de cambios e integraciones. Esto, desde el ámbito de QA, nos puede ayudar a saber que se está realizando en cualquier momento. Esto, unido a la iteración con desarrollo, para la realización de pruebas unitarias, nos lleva a que el código fuente esté mucho más cubierto y garantizado.

Hay infinidad de estrategias de automatización y de ponerlas a punto en un proyecto, pero cubriendo una serie de mínimas pautas o puntos, como los anteriores, tenemos bastante terreno cubierto y, al menos, podemos comenzar con una base sólida y unificada.

25 de noviembre de 2018

Una cobertura de código del 100% no tiene porque ser suficiente

Cuando el código está cubierto al 100%, muchas veces nos planteamos, porque hay gente que se dedica al probar el software que estamos realizando.
 


El planteamiento inicial, viene dado por herramientas tipo SonarQube, donde solemos dar por buena, una cobertura del 80% del código. Esto es un éxito total y un orgullo para los desarrolladores, pero, ni un 100% es suficiente.

Si tenemos una cobertura del 80%, incluso de un 100%, que es casi imposible de conseguir, lo asociamos a un código de alta calidad, a un código completamente probado y esto es totalmente engañoso. Una cobertura del 100%, no significa que la calidad sea alta, ya que las pruebas no pueden ser correctas, puedes estar incompletas o puede ser que les falten datos.

Cuando se realiza una prueba, si hay algún camino que no se cubre porque no tenemos toda la información o todas las casuísticas que realiza un profesional de QA, ya tenemos caminos sin probar de los que pueden salir fallos. Además, las pruebas no podrían verificar la funcionalidad del código, una ejecución de una batería de test, podría no ser suficiente. 

Una de las estrategias a seguir, es que las pruebas unitarias se centren en probar temas aparte de la calidad general, la experiencia de usuario y la aceptación, y que esto lo haga un tester, pudiendo hacer que las pruebas de código validen los datos. Esto hará que la funcionalidad pueda ser correcta y gracias a las pruebas del tester, también las requisitos.

Un problema de la cobertura del código, siendo o no, al 100%, puede ser que no cubran lo que esperamos o sean incorrectas, una prueba puede estar OK, pero puede estar ejecutándose sin probar absolutamente nada.

Las pruebas deben de ser efectivas, deben de ser valiosas y aunque tengamos un porcentaje alto, no quiere decir que el código esté probado totalmente. El valor que aporta del desarrollador es que tiene un control total del manejo de las excepciones y puede inyectar condiciones necesarias para probar nuestros errores, ya que el API es cosa suya.

Aunque en muchos foros todo tiende a automatizar, a pruebas de integración, unitarias, pero los tester son muy necesarios para revisar el software y asegurarse de garantizar la calidad total. El complementar las pruebas del desarrollador con las del tester, es el caballo ganador de la calidad, porque se identifican áreas que cada uno puede cubrir y puede optimizar, haciendo que la calidad total entre ambos, si puede ser un 100% real.

4 de octubre de 2018

Midiendo la productividad sin renunciar a la calidad

Desde hace un tiempo, me viene rondando un tema que se anda solicitando en las empresas de software: la medición de la productividad.

Cuando hablamos de software y de código es tremendamente complicado sacar esta medición, y como bien dice Javier Garzas, muchos métodos que parecen típicos (como puntos función), no son del todo fiables en este ámbito.



La productividad, tiene que entenderse como eficiencia y efectividad en el trabajo. Entendiendo esto, tenemos dos grandes ramas donde apoyarnos.

La medición de la eficiencia se puede trasladar a eficiencia de recursos o de flujo.
A nivel de recursos, queremos mirar como maximizar la utilización de las personas, por lo tanto, lo ideal es observar las horas consumidas de esa persona, en concreto, en una tarea. Esto, tarea por tarea, nos dará el resultado de la eficiencia de ella, en el proyecto.

Si esta suma, la contrastamos con la estimación que se dio en la hoja de carga, nos encontraremos con una medición realmente eficaz de si estamos acertando o no. El resultado, nos proporciona un kpi de desvío, que es exactamente: diferencia de horas estimadas contra las horas consumidas, dividido por las horas estimadas.

Por ejemplo, si Pedro estima 5 horas una tarea, y consume 10, según este kpi, tendremos que Pedro cuenta con un -1, por lo tanto tiene una desviación importante sobre la estimación inicial.

Esta medida, a priori, puede parecer muy sencilla, pero si la asociamos al tiempo que tardamos en completar una historia de usuario, la cosa cambia. Para ello, usaremos Cycle Time, que es el tiempo desde que se empieza una tarea hasta que se termina.

Conseguir una mejora de este método cuya repercusión en los resultados sea mayor que la inversión económica realizada y, sobre todo, sin pérdida de calidad en el resultado final, debe ser el objetivo de cualquier empresa.

El punto más importante, es que no se debe de supeditar, bajo ningún concepto la calidad del software. De nada vale entregar antes y que el resultado sea peor, costándonos una inversión posterior y un esfuerzo, para solucionar los defectos y ajustar aspectos funcionales que hemos hecho a medias.

En relación a la eficacia, es el punto más complicado de medir. Para ello, necesitamos conocer en valor que estamos aportando a cliente y esto, en muchas ocasiones suele ser subjetivo y relativo.

Lo que si podemos medir es la cantidad de veces que los usuarios utilizan la funcionalidad, tanto a nivel de mapas de calor, con los clicks generados o investigando los logs o base de datos con las llamadas realizadas. A esto, si le sumamos formularios de feedback y petición de mejoras que se puedan añadir al backlog, nos darán información muy útil para medir este dato.


Estos valores, siempre se deben de medir a nivel de equipo de trabajo y no por persona y resulta una potencialidad de la mejora continua y de la cultura de calidad de las empresas que nos aportará positividad en los equipos y en las personas de nuestra organización.

20 de julio de 2018

El principio de resiliencia

Hace ya unos meses, me encontré con el principio de resiliencia y como aplicarla.


Este principio dice que tenemos una capacidad de adaptación positiva para afrontar las situaciones adversas. He de reconocer que suelo tender a la negatividad fácil y de manera automática, por lo tanto, la aplicación me ha resultado muy buena y me ha dado resultados inmediatos.

El activar y realizar este principio nos lleva a dar un giro total a situaciones que tienen un grave riesgo de que el resultado sea negativo.

Existen tres focos o modelos a seguir:

  • Compensatorio: cuando se habla de factores que son estresantes y que pueden ser contrarrestados por cualidades personales o fuentes de apoyo.
  • Inmunidad: la línea que separa el estrés y la protección es modulable en base a la adaptación. Cuanto mejor nos adaptemos menor es el riesgo.
  • Desafío: cuando tratamos el estrés como estimulante de competencia. Existe una relación curvilínea que debemos de controlar en base a esta competencia y la bajamos en base a lo que queremos conseguir.

La mejor manera de reducir el impacto de riesgo es que la persona altera el significado del mismo, modificando la participación en la situación o reducir las situaciones negativas que se pueden producir en cadena y que nos introducen en el riesgo de perpetuar los efectos del problema.

Esto, unido a que debemos de mantener la autoestima y la autoeficacia hace que las experiencias o momentos clave de una persona se desarrollen en entornos adaptativos y marquen continuidad en la trayectoria vital.

Por mi parte, os puedo decir, que aprendiendo a dar giros de 180 grados frente las adversidades y tomárselas como retos, la perspectiva cambia muchísimo. He conseguido llegar a casa con la mente más descansada y el nivel de estrés a descendido drásticamente y he podido comprobar que las decisiones tomadas son mucho más rápidas y ágiles.

Resumiendo y para que tengamos todos la misma idea, las personas resilientes son aquellas que están expuestas a una serie de factores de riesgo y tienen la capacidad de utilizar focos o modelos “protectores” que sirven para sobreponerse a la adversidad, crecer y desarrollarse adecuadamente, llegando a obtener una madurez  rápida y competente pese a las adversidades.

12 de julio de 2018

La felicidad en el entorno laboral

Una de las cosas más importantes dentro del mercado laboral es la felicidad. Parece mentira, pero es así.

La felicidad es la gasolina de nuestra vida y lo que puede cambiar la percepción de “he tenido un día provechoso y lleno, a un día de mierda”. Es lo que puede hacer que lleguemos a casa con la mejor de nuestras sonrisas y tengamos un fin de día tranquilo y a gusto o que lleguemos agobiados, intranquilos o con sensaciones no confortables.



La felicidad está descrita como: “Estado de ánimo de la persona que se siente plenamente satisfecha por gozar de lo que desea o por disfrutar de algo bueno”. Tan solo con eso, nos damos cuenta de su importancia en todos los sentidos y más en el que nos ronda ahora mismo, el profesional.

Cuando estamos felices hacemos un trabajo excelente, estamos más motivados, rendimos más y aumenta la endorfina, la hormona capaz de todo esto. Y si nuestro cuerpo y mente son felices pasa todo esto:

  • Se Promueven la calma, la paz y generamos un estado de bienestar.
  • Vamos a tener mucho mejor humor.
  • El dolor disminuye.
  • El proceso de envejecimiento se ralentiza.
  • Tenemos más potenciadas las funciones del sistema inmunitario.
  • Se reduce y regula la presión sanguínea.
  • Se contrarrestan los niveles elevados de adrenalina asociados a la ansiedad y ayudan a reducirla.

Si tenemos altos todos los puntos anteriores, lógicamente el trabajo que realicemos será mucho mejor.

Ahora bien, todo esto está genial, es muy bonito, pero nuestro día a día es muy distante a todas estas ideas. ¿Que debemos hacer para cambiarlo?

Lo primero es dejar de desear y de ver lo que queremos constantemente. Hay que vivir con los recursos que disponemos hoy y trabajar para que lleguen cosas nuevas.

Hay que conectar física y emocionalmente con los compañeros y responsables. Es la base de todo, el contacto y el trato es pieza esencial para ser feliz y que te hagan feliz. Ser cordial, amable, respetuoso, son la base de todo. Hay que grabarse a fuego el tener siempre una sonrisa por bandera.

Muchas veces caemos en la protesta en la negación y en el malestar, es innato del ser humano, pero debemos de cambiar esto e ir siempre con pensamiento positivo y rodearte de personas que tengan esta mentalidad. La negatividad debe de quedarse de lado y hacer oídos sordos. Es un punto muy complicado y que, si os soy sincero, a mi a veces me cuesta gestionar, pero los resultados son espectaculares y la motivación aumenta exponencialmente. Poner todo el empeño en cumplirlo.

Otro punto muy importante y que lo pongo en práctica muy a menudo y funciona a la perfección es el de compartir las preocupaciones. Siempre voy con la verdad por delante, hablo sin tapujos y digo lo que me preocupa o lo que puede llegar a ser un problema en el corto o medio plazo. En más de una ocasión se han solventado situaciones complicadas por adelantarnos a ellas con el mero hecho de hablar y comunicarse de este modo.

Hay que ser flexible, comprensible y abierto a lo cambios. El futuro es un cambio constante y hay que reinventarse siempre, aunque esto lo tomemos siempre con incertidumbre y pánico. 

Dentro de esto y es algo que me enseñaron hace poco y estoy en fase beta aprendiéndolo, es practicar resiliencia. Que básicamente, se trata de saber que talento y potencialidades tenemos, nuestras limitaciones y defectos y afrontar los retos con objetividad y perspectiva. Os puedo decir que desde que lo pongo en práctica, estoy cambiando mi manera de pensar y actúo más rápido y ágil frente a adversidades. 

La felicidad es algo que viene solo, si lo trabajamos un poquito, ponemos en práctica algunas pautas y sobre todo, somos nosotros mismos y actuamos como tal.



23 de junio de 2018

Pruebas, calidad y procesos, conceptos a tener en cuenta.

A la hora de enfrentarnos a la realidad del mercado profesional actual en base a QA y todo lo relacionado con ella, hay ciertos conceptos e ideas que no se tienen del todo claras.

Habitualmente, si hablamos de QA lo confundimos con testing, con gente probando como minions o gente automatizando como locos. Es un término y un concepto totalmente erroneo y que está lejos de su verdadera realidad.

El concepto de QA va más allá de lo que son las pruebas, es una garantía de que en la compañía se están haciendo las cosas como se debe, de que se siguen los estándares de calidad y de que las personas trabajan adecuadamente y mejor cada día que pasa.

El testing o pruebas, entran dentro de lo que es QA y es una ligera y pequeña pieza dentro del proceso, algo que si no se cumple o no se hace bien, el resto se cae. 
Es la ley de los eslabones de la cadena que tanto he hablado a lo largo y ancho de mi vida laboral.
Entre lo que es QA y lo que es testing se encuentra el control de calidad o QC, que de encarga de que se están cumpliendo los hitos o controles dentro de un proyecto. Es un proceso o pautas implementadas a lo largo del ciclo de vida del producto en si.

Ahora bien, todas estas piezas y pautas que hay que dar no funcionan de la noche a la mañana ni se engranan automáticamente. Es necesario un tiempo de estudio, un tiempo de prueba y error y un tiempo, que es lo que verdaderamente complica las cosas, de enseñanza al resto de profesionales que serán partícipes de que todo de realice adecuadamente.

El apoyo y la paciencia es la base fundamental de todo ello y sin esto, es prácticamente inviable el montaje de algo que demuestre que de verdad se están dando los pasos adecuados. Tenemos que ser completamente estériles a lo que surge alrededor y tener un único camino dibujado para que todos andemos por él.

Para introducir un verdadero proceso de QA, que en muy pocas empresas se cumple y se realiza (en base a una pequeña encuesta que realicé hace poco), hay que tener la capacidad de saber esperar y mirar al pasado, justo antes de que no existiera ninguna pieza y veremos que hay muchas carencias que están resueltas y que estábamos a años luz de ahora. El margen de mejora es siempre infinito, pero, la realidad, y aquí pongo la mano en el fuego, es que todo funciona mejor. 

Si ponemos cara a estos tres conceptos, y los entendemos adecuadamente, tendremos un terreno enorme ganado, donde sabremos que debemos impulsar en cada momento y cuales son las necesidades de nuestra empresa cuando consideremos.

En la unión está la fuerza y si todos tenemos la mentalidad de la ganancia que aporta QA en el medio plazo, no en el corto, la potencia que obtendremos en nuestra compañia será enorme y viviremos muchísimo más tranquilos.

28 de noviembre de 2017

Estrategia de entornos y control de calidad

Si se diseña una buena estrategia de calidad, de manera obligatoria, tiene que venir de la mano de unos entornos de pruebas.



Estos entornos tienen que adecuarse a las especificaciones acordadas, ajustarse a lo que vamos a probar en cada uno y acoplarse a las personas que accederán a ellos. 

Lo primero es saber cuantas etapas o fases de control de calidad podemos utilizar o podemos ser capaces de introducir en el proyecto y por lo tanto donde se situarán estas respecto a los entornos disponibles o diseñados para ellas.

En principio, y de manera genérica para casi cualquier proyecto, acabaremos teniendo los siguientes entornos:

  • Entorno de desarrollo: habitualmente se situará en local, en el ordenador de cada profesional y, se alimentará de una rama o de un repositorio de código determinado. El desarrollador es el dueño y señor del mismo, pero, tiene la responsabilidad absoluta de que cuando suba el código a la rama principal o al repositorio, lo que ha realizado, funcionará adecuadamente. Se podrá apoyar en la ejecución de los casos de prueba o de criterios de aceptación. Podrán existir tantos entornos de desarrollo como se considere o sea necesario.
  • Entorno de PRE: este entorno será donde se haga el núcleo central de las pruebas. Un entorno estanco, controlado y que será revisado periódicamente para que no tengamos regresiones o defectos bloqueantes que hagan ruido. Debe de existir, al menos, uno. Y se podrán replicar, aunque ya tienen costes. Además, debe utilizar una réplica exacta y actualizada periodicamente de la BBDD de Producción, para que las pruebas se realicen con los datos más reales posibles. Tampoco es necesario que se replique la infraestructura de PRO.
  • Entorno de QA: este entorno es el de certificación, donde nos aseguramos que el cliente pueda entrar y certificar, realmente, que sus criterios de aceptación se cumplen y el desarrollo está para subir. Este entorno replicará PRO y BBDD de PRO.
  • Entorno de ST: este entorno se utiliza para certificar diferentes integraciones con terceros (si fuese necesario) y que simplemente, pueda solaparse con producción para desplegar una nueva versión de código.
  • Entorno de PRO: es el entorno principal, el más importante, el que utilizan los clientes y por lo tanto, el que tiene que tener la última versión de código estable, validado y certificado. La BBDD será la que mande y de la que se replicarán las demás.

En la mayoría de los casos, esté es un esquema habitual en todos los proyectos y donde se deben de realizar diferentes validaciones, certificaciones y poner a punto los desarrollos nuevos que pondremos a disposición de los clientes.

Sin una buena estrategia de entornos, la estrategia de control de calidad no tiene ningún sentido, tienen que ir de la mano y apoyarse entre ellas, siendo indispensable, sobre todo, que los entornos, a partir de desarrollo, sean estancos y con las integraciones y despliegues totalmente controlados y dando el visto bueno, únicamente, el responsable de los mismos.

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