Somos el altavoz para tus ideas

QA Lovers Community®, es una iniciativa colaborativa sin ánimo de lucro donde exportamos conocimiento, apoyamos y ayudamos a personas

Únete a la Comunidad Contáctanos por email

Nuestras iniciativas...

QA♥ Slack

Ayudamos a personas que trabajan en el mundo de la Calidad. Colaboramos tod@s desde nuestra comunidad de Slack, que sirve de incubadora de ideas.

Únete

#WomenQA♥

Nuestra comunidad apoya incondicionalmente a las mujeres que trabajan en Calidad, trabajamos siempre en varias iniciativas para dar toda la visibilidad posible.

Más info

Helppiness

Generamos un entorno colaborativo donde dar salida a las ideas que tengas, tod@s ayudamos y tod@s colaboramos de persona a persona, desde el respeto.

Colabora

¿Alguna idea?

Si tienes algo en mente, donde podamos ayudarte, algo que te apetezca hacer y esté relacionado con la Calidad, no dudes en ponerte en contacto con nosotr@s.

Contacta

El Blog

lunes, 25 de marzo de 2019

Informe de la salud de Internet 2018 - Mozilla


Mozilla, ha creado un informe sobre la salud de Internet ha lo largo del año pasado. Este informe, está basado en una serie de investigaciones que revisan que está ayudando y que está afectando a Internet en 5 pilares.


1.     ¿Es seguro Internet?
Basándose en una web segura y libre, la investigación principal se basa en datos robados, contraseñas problemáticas y posible falta de confianza en los sistemas que nos protegen.

2.      ¿Es abierto y libre?
En este punto nos cuentan que internet es participativo e innovador, pero la apertura no está del todo garantizada, siempre pueden existir ataques y problemas

3.     ¿Es amigable?
No tratan temas como el acceso a internet, como tal, si no que si este acceso es seguro y valioso para todos sus usuarios.

4.     ¿Quién puede triunfar en él?
Se basan en diferentes habilidades que tienen que tener los usuarios para participar en el mundo digital, entre la lectura y la escritura.

5.     ¿Quién lo controla?
Sabemos que unos pocos actores lo dominan todo, pero Internet va más allá de aquellos que lo hacen.

Este tipo de iniciativas me parecen brutales, son algo muy necesario y que ayuda a que Internet sea vista con otros ojos, incluso que sea un poquito más libre. Además, nos hacen participes de la iniciativa, y podemos ayudar a realizar diferentes cosas relacionadas con el tema.

Puedes descargarte el informe completo desde aquí.

jueves, 14 de marzo de 2019

Mi primera experiencia automatizando con Robot framework - Jorge León Delgado


Antes de empezar con el artículo, explicaros que es Robot Framework y porque lo elegí como herramienta para automatizar las pruebas, os cuento el contexto en el que me encuentro y cuales son mis funciones actuales.


A mediados de noviembre, comencé a trabajar en mi actual empresa, tenia como objetivo poner en marcha un departamento de QA con lo que eso conlleva:

·       concienciar a toda la gente de la importancia de la calidad,

·       evitar la llamada “reticencia al cambio”,

·       formar el equipo de QA y,

·       temas más técnicos como: selección de herramientas.

El mayor problema, venía a la hora de elegir una herramienta para automatizar pruebas funcionales de interfaz. Con Selenium, tuve una breve experiencia en un proyecto de 3 meses, en el que aprendí más bien poco. A esto se une que yo nunca he trabajo como programador, tengo formación, pero mis conocimientos son mínimos y en mi zona hay pocos especialistas en el tema.

Con otro tipo de pruebas automatizadas, si me he peleado más, como: pruebas de rendimiento con Jmeter y de API con SoapUI.

Una vez contada esta bonita historia e introducidos en “mi contexto” entremos en materia…


¿Qué es Robot Framework?

“Robot Framework es un marco de automatización de pruebas genérico para pruebas de aceptación y desarrollo basado en pruebas de aceptación. Es un marco de prueba basado en palabras clave que utiliza la sintaxis de datos de prueba tabular.” (Fuente Wikipedia)

Es un framework open source, utiliza el enfoque de prueba basado en palabras clave (keyword-driven testing). Sus capacidades de prueba pueden ampliarse mediante bibliotecas de prueba implementadas con Python o Java, y los usuarios pueden crear nuevas palabras clave de alto nivel a partir de las existentes usando la misma sintaxis que se usa para crear casos de prueba.

Os dejo por aquí el enlace de su página oficial: https://robotframework.org/


DAR Herramientas de automatización

Como os he comentado en el primer punto, tenia que elegir una herramienta de automatización teniendo en cuenta que ni yo, ni las personas de mi equipo tenían conocimientos en programación. Esto, hacia que directamente descartara la herramienta más conocida de automatización de pruebas: Selenium.

Realice un DAR (Decision Analysis and Resolution) con varias herramientas, evaluando los siguientes criterios:

·       Programming skills

·       Precio

·       Basada en Selenium

·       Compatibilidad con:

o   Herramientas de gestión de pruebas

o   Jira

o   Jenkins

o   Linux

Tras realizar el DAR, me quedaron dos herramientas con las que hice varias pruebas de concepto, una de ellas era Robot Framework.

Los criterios que seguí para evaluar estas herramientas en las pruebas de concepto eran los siguientes:

·       Facilidad de aprendizaje

·       Instalación y configuración

·       Grabación de prueba/creación del script de prueba

·       Tratamiento de los datos de prueba (por fichero, desde base de datos…)

·       Organización de las pruebas siguiendo el modelo Page Object

·       Ejecución de la prueba

·       Informes

·       Soporte y comunidad


Razones para elegir Robot Framework

Tras finalizar las pruebas de concepto con estas dos aplicaciones, me decidí a elegir Robot Framework por:

·       Su facilidad de aprendizaje: aunque la otra herramienta que probé también era muy intuitiva, incluso tenia una interfaz gráfica y un grabador de pruebas, me pareció mucho más sencilla la sintaxis tabular.

·       La instalación es por línea de comandos, pero es muy sencilla y es compatible con los sistemas operativos más conocidos (Windows, Linux, OS X…).

·       Selenium: robot framework esta basado en librerías y la más usada es Selenium2Library que como podéis deducir, está basada en Selenium.

·       Informes y evidencias de pruebas: Son muy claros y comprensibles. Se realiza una captura de pantalla al fallar la prueba.

·       Su comunidad de usuarios es muy muy extensa, teniendo incluso un canal de Slack propio con usuarios muy activos por lo que el soporte es casi inmediato.

·       Potencial: tiene una colección de librerías muy amplia dando un amplio margen para poder realizar cualquier tipo de pruebas, por ejemplo, existe también una librería basada en Appium permitiendo también extender la librería de Selenium.

Inconvenientes

No todo iba a ser bonito. Os cuento las pegas que me he encontrado en estos 4 meses automatizando con el Robot:

·       La estrecha relación con Selenium hace que se hereden los problemas conocidos de esta herramienta: localizadores, tiempos de espera…

·       Editores. Disponemos de varios editores compatibles, pero ninguno me ha acabado de llenar (Ride, RED, Pycharm, Sublime)

·       Evidencias de prueba. No es posible grabar en vídeo las pruebas falladas. Para mi es más que suficiente que se haga solamente, pero algunos desarrolladores lo ven necesario.

Como os dije al principio, no soy un experto automatizando pruebas, sin embargo, me ha sido relativamente fácil crear un conjunto de pruebas automatizadas para una aplicación en un par de meses. Por lo tanto, creo que Robot Framework es una herramienta muy a tener en cuenta dentro de los RPA actuales y con un funcionamiento y una curva de aprendizaje muy sencillos.

En breve, os podré contar más experiencias sobre el trabajo realizado con esta herramienta. Si tenéis alguna duda más al respecto, podéis encontrarme en la comunidad de QA Lovers.
 Jorge León Delgado

martes, 12 de marzo de 2019

QATalks 2 - Aurelio Gandarillas Cordero, Quality Expert en MTP

Nuestro segundo QATalks, es para Aurelio Gandarillas, una eminencia en el mundo del testing y la calidad del software.
Actualmente es Quality Expert en MTP y fue ganador de la mejor ponencia de ExpoQA 2018.



Para nosotr@s es un grandísimo honor el poder haber realizado esta entrevista a Aurelio, para QA Lovers Community. Desde aquí, le damos las gracias y esperamos que sea la primera colaboración de muchas.

1. A lo largo de tu extensa carrera, ¿cómo ha cambiado el panorama de testing y QA hasta actualmente?

Hay dos factores que han marcado la diferencia en la evolución del testing en los últimos años, el primero es la automatización y el segundo la especialización del tester.
Es curioso como existiendo las técnicas del testing desde hace más de 40 años ha sido en los últimos 10 años cuando ha habido una gran evolución del testing en España.

En los años 80 y 90 no existía conciencia por las técnicas y la estrategia de prueba, al menos en el entorno del desarrollo que yo conocía. Se desarrollaba el software y se hacían pruebas funcionales basadas en la experiencia de cada persona, equipo o empresa. En esos tiempos no existía el rol del tester y era el equipo de desarrollo era quien pensaba y diseñaba las pruebas. También eran tiempos donde el software tenía una tecnología más simple y una utilización más limitada. Los productos tenían ciclos de vida de años y se trabajaba con la calidad en el largo plazo. Obviamente no es la situación que conocemos como adecuada, pero el mercado permitía desarrollar así.

Para mí la aparición del rol del tester ha sido en el siglo 21 concretamente en los últimos 15 años, aunque fuera de España quizás se tuvo convivencia de la necesidad de este rol mucho antes, en la segunda mitad de los años 90. En esa segunda mitad de los años 90, aparecen referencias, publicaciones, estándares como ISTQB, paradigmas como la orientación a objetos y marcos de referencia como Extreme Programming o TDD. Todas ellas con lo que considero un denominador común, desarrollar software que tenga viabilidad económica para ser probado. Es decir, se tomaba conciencia de la importancia del testing en un desarrollo software como mecanismo para asegurar que el software aportaba valor al negocio que lo usa y no le causa problemas.

Pero el siglo 21, y concretamente en los 10 últimos años, el software tiene una relevancia extremadamente alta e incluso su presencia es crítica para los negocios. Hay empresas que son lo que son, por que existe un software que las hace viables. El impacto del software en nuestra sociedad actual es sencillamente demoledor. Hoy podemos realizar infinidad de gestiones desde cualquier lugar del mundo y realizar actividades que hace pocos años eran sencillamente inimaginables sin determinadas aplicaciones.

Pero precisamente ese incremento exponencial de la dependencia del software que afecta a personas, empresas y sociedad debe alertarnos de la necesidad de valorar qué efectos tiene un software que funciona mal y cómo podemos evitar el daño producido. Ya no estamos hablando de la incomodidad de un programa que nos deja "tirados". Estamos hablando de la continuidad de los negocios, así como el bienestar y la integridad de las personas.

Este es el área que yo considero como central en el rol del tester profesional.

A pesar de este evolución del software he conocido muchos proyectos de hace menos de 15 años donde no existía el rol del tester ni se le consideraba necesario. Incluso en algunas ocasiones se veía como una actividad temporal y mínima dentro del proyecto de desarrollo
En estos días y debido principalmente a la facilidad de comunicación, la existencia de eventos y comunidades como la de QAlovers, creo que se tiene mejor conciencia del rol del tester. Es raro que existan proyectos de desarrollo software donde el tester no esté desde el inicio de manera permanente. Pero aún se necesitan más y mayores cambios en el testing.

2. Creo que tienes una visión diferente de lo que es QA o Quality Assurance en el mundo de la calidad software ¿me lo podrías explicar?

Esta idea viene de mis primeros estudios universitarios como Ingeniero Industrial en Electrónica en los años 80 y que está fuertemente reforzada por la actividad que realizo en MTP, la empresa para la que trabajo desde hace 15 años, así como de los contenidos de estándares y certificaciones en materia de Testing y Calidad de Software
Para mí, existen tres grandes áreas de actividad en materia de Calidad:
  • Detección del defecto o control de calidad (Quality Control / QC): El producto tiene una posible anomalía (error) y hay que tratar de evidenciarla, encontrarla y corregirla. Quizás, y de forma incorrecta, se asocia al tester sólo esta labor. En cualquier caso, lo fundamental de esta tarea es el testing temprano, es decir, que el tiempo entre la inyección del defecto y su detección sea lo antes posible (minutos o como mucho, horas).
  • Prevención del defecto o aseguramiento de la calidad (Quality Assurance / QA): El defecto aún no se ha inyectado en el producto, pero se realizan tareas que minimizan que esto ocurra. La fuente de información de esta tarea son los errores ya cometidos (que curiosamente suelen ser detectados por las pruebas y las revisiones). Es decir, una adecuada aplicación de QA debería dar como resultado un proceso de desarrollo que cambia continuamente en base a la información facilitada por los testers. ¿Cuantos testers pueden decir que el proceso de desarrollo o la organización cambia por el resultado de su trabajo?  Esto daría para un interesante debate.
  • Gestión de la calidad (Quality Management): Esta área de actividad tiene como foco dotar al producto de la calidad adecuada al uso y optimizar la organización para lograrlo. Es la capa más estratégica de la calidad y fuertemente vinculada al negocio. Existen metodologías, normas y buenas prácticas que describen su aplicación (ISO 9001, CMMi, TMMi, ISO 29119, Nivel expert de ISTQB, etc..) pero hoy su aplicación ha quedado desgraciadamente en un proceso testimonial. Me apasionan las metodologías, normas, framework y buenas prácticas. De hecho, tengo un trabajo de recopilación al respecto https://metodologia.es que algún día terminaré. Esta área daría para otro interesante debate

3. A día de hoy, a nivel “acogida” de perfiles de testing en las empresas ¿lo ves mejor o seguimos estancados en el pasado?Creo que el nivel de acogida del tester dentro de los proyectos y la de las empresas ha mejorado significativamente en los últimos años. Recuerdo tiempos donde el tester se veía como algo molesto e incluso como una actividad no deseada. Queda algún "reducto" donde ocurre, pero, por suerte, es algo anecdótico.

Hoy en día prácticamente ninguna empresa con un proyecto de desarrollo de producto y sobre todo desarrollo software se plantea un equipo sin que existan la actividad de testing.

También detecto un incremento en la madurez de los proyectos, donde se está sustituyendo el clásico "lo pruebo al final", por una actividad de testing mucho más integrada con el desarrollo y aplicada en todo el ciclo de vida de desarrollo software. esto ha sido un cambio fundamental en los últimos 10 o 15 años, pero en lo que hay mucho trabajo por delante, según me cuentan mis alumnos :-)
También la percepción del rol del tester ha cambiado y yo creo que principalmente en los últimos 5 o 6 años. Al inicio del milenio, el tester era más reactivo y su actividad principal la realizaba al final de la construcción del producto principalmente de manera manual.

Hoy en día la labor del tester está progresivamente cambiando hacia la prevención, es decir el tester aparece al principio del proyecto con el foco de prevenir tanto como sea posible la inyección de defectos durante el proceso y de detectarlos lo antes posible. Sin embargo, a mi modo de ver, este cambio es mucho más lento de lo que el desarrollo software actual necesita.

La aplicación de enfoques de desarrollo agile y la automatización, están provocando que el tester se incorpore como uno más del equipo de desarrollo, aunque queda mucho trabajo por realizar para llegar al objetivo de que sea habitual que el tester esté equiparado al resto del equipo de desarrollo.

4. Como Quality Expert en MTP, ¿cómo ves el futuro próximo en la compañía?, ¿Qué tecnologías se asentarán y se usarán en los proyectos?

Bueno se habla mucho del futuro del testing sobre todo en conferencias, seminarios y artículos, pero creo que antes de hablar de ese futuro deberíamos terminar de afianzar nuestro presente. Hoy siguen existiendo proyectos donde el software y las pruebas siguen atascados en modelos con rentabilidad inadecuada.

Una de estas ideas que considero que deben cambiar es que aun se piensa que las pruebas es cosa sólo para los testers. El testing es responsabilidad de todo el equipo y el desarrollador es uno de los roles que más testing deben hacer. También el negocio debe implicarse en el testing y en la calidad software, obviamente contará con el apoyo de los especialistas, pero la calidad del producto es un problema del negocio.

También me gustaría que, en un futuro muy cercano, el equipo de desarrollo vea el testing como una fabulosa herramienta para que el desarrollador crezca profesionalmente y mejore su productividad. Es habitual en algunos equipos desarrollo pensar que el testing es un freno, una pérdida de tiempo, cuando en realidad se ha demostrado que una buena arquitectura de software y una buena estrategia de este testing son los mejores aceleradores del ciclo de desarrollo software. ¿cómo demostrar esto? muy sencillo, solo hay que analizar propuestas como scrum, enfoques agiles, Extreme Programming o TDD. Sin embargo, el testing para desarrolladores sería objeto posiblemente de otro debate y bastante largo así que ya tenemos materia para otra ocasión.

En cualquier caso y tratando de responder a tu pregunta, el futuro del testing pasa por una elevadísima automatización. No se trata solo de automatizar las pruebas, el diseño de los casos de prueba o incluso la estrategia de las pruebas.  El tester va a tener que ser conocedor de todo tipo de herramientas y tecnologías de automatización de pruebas y del proceso de desarrollo porque van a formar parte de su día a día y debe incorporar dichas herramientas a su actividad.

Casi todos los tester, conocen lo que significa la automatización de pruebas, pero no todos conocen el testing basado en modelos o propuestas que donde los diseños de los casos de prueba vienen de especificaciones. Quizás algunos puedan conocer prácticas como BDD o Gherkin como lenguaje para automatizar casos de prueba partir de funcionalidades de negocio o del lenguaje natural. Pero este tipo de aplicaciones van a ir más allá y en el futuro existirán herramientas que permiten obtener los casos de prueba automatizados directamente de especificaciones modelos de negocio y de comportamientos del sistema. Estas herramientas aún están en proceso de creación y de optimización, pero el ritmo de crecimiento tecnológico es elevadísimo y posiblemente muy pocos años esto pase a ser nuestras herramientas.

Y por último en la automatización del proceso de desarrollo, bien por aplicación de propuestas como DevOps u otro tipo de propuestas que puedan aparecer en el en el futuro, van a generar unos procesos de construcción de Software donde la cantidad de datos generada va a ser increíble. Es decir, el proceso de desarrollo software va a tener su propio Big Data ahí es donde la inteligencia artificial, los sistemas expertos y las herramientas de análisis de datos van a poder ayudar al tester y a los responsables de calidad en los mecanismos para poder hacer las mejoras tanto del proceso como del producto. Probablemente el tester se convierta en lo que realmente debería ser, prevención de calidad (Quality Assurance) debido a todas estas mejoras.

Podría indicarte referencias de cómo en MTP, hace 10 o 15 años, hablábamos, aplicábamos algunas de estas propuestas. pero no hubo mercado suficientemente maduro para aplicarlas y quizás hoy en día el mercado tenga que madurar más para que ese posible futuro sea una realidad. Como decía al principio de esta pregunta, hay que tener la vista en el futuro, pero nuestro presente requiere aún de mucho trabajo.

5. ¿Soléis usar algún tipo de metodología en concreto o adaptáis según proyecto o cliente? ¿con cuál sientes que QA ha encajado mejor?

MTP ha apostado desde hace muchos años por las propuestas de ISTQB que ya tiene más de 20 años de vigencia y en los últimos 15 años por modelos de gobierno de la calidad como TMMi. En base a estas propuestas y nuestra experiencia damos cobertura a las tres áreas que he mencionado antes; QC, QA y QM.

Existen otros modelos, aunque no muchos más, pero yo creo que estas dos propuestas son claves en el mundo de la calidad software sobre todo cuando se hace un enfoque a la prevención
Nuestros modelos y servicios siempre han sido adaptables. Es imposible crear una propuesta metodológica, un proceso o una herramienta que sirva sin modificación para cualquier tipo de negocio, cualquier tipo de cliente, o incluso para cualquier tipo de proyecto. Si algo nos ha caracterizado ha sido la flexibilidad y la adaptabilidad.

Precisamente adaptabilidad es lo que yo considero como la adecuada traducción de la palabra inglesa Agile, tan vigente en la actualidad. Creo que la adaptabilidad ha caracterizado siempre MTP, por tanto, en mi opinión, pienso que MTP lleva 20 años siendo ágil, aunque quizás el mundo de la agilidad haya entrado con fuerza en los últimos 5 años en España.

En todos nuestros proyectos y clientes hay una fase inicial de diseño del servicio y en esa fase de diseño se analizan las necesidades, así como las casuísticas del cliente y del producto para ofrecer una adecuada estrategia de servicio en base a su mercado, su producto, su presupuesto y su nivel de madurez. Obviamente, esa adaptación es una actividad permanente durante todo el ciclo de vida del proyecto o del servicio.

Nuestra forma de trabajar está inspirada en muchas propuestas metodológicas, normas, buenas prácticas, enfoques, marcos de referencia. Digamos que creamos nuestro estilo, pero desde sólidas bases de conocimiento.

6. ¿Qué ramas o caminos, basados en la calidad, te gustan más? ¿eres de los que cacharrean a nivel más técnico o te gusta más la rama procedimental y de gestión?

¡Bueno a mí lo que más me gusta es no trabajar! Obviamente, es una broma…(risas).

Bueno para mí, el trabajo es una actividad que, si tuvieses la oportunidad, no harías pero que obviamente la desarrollas porque necesitas un medio de vida. Aquellas personas que pueden desarrollar una actividad que les apasiona, que les gusta y encima obtener ese medio de vida necesario, yo los considero auténticos afortunados.

Curiosamente en la profesión de testing es donde más personas me he encontrado con esta condición, gente que les apasiona su trabajo y que se consideran felices al realizarla.
En cuanto a lo que a mí me gusta, la verdad es que tengo la sensación de no he tenido una carrera profesional planifica, sino que han sido las circunstancias de los proyectos en los que he estado los que me han ido llevando a realizar todo tipo de actividades. Cada vez que ha aparecido una oportunidad interesante, he ido a por ella.

Creo que si tuviese que definir que es lo que más me gusta de mi profesión lo definiría con una palabra, crear. Realmente la creación o la realización de un producto, un proceso, una actividad, algo que antes no estaba hecho y que de alguna manera crea una innovación, un proceso o producto nuevo, es lo que más me atrae. La rutina, desde luego, es una de las cosas que peor llevo. Alguien podría pensar que con esta vocación es difícil poder trabajar en el mundo del testing. Pues creo que no.

Creo que la labor del tester, su labor principal, es innovar en pruebas. Quiero decir que se puede ser tester y estar continuamente creando casos de prueba, estrategias, desarrollando herramientas, automatizando, creando mecanismos de validación nuevos en el producto. Para mí realmente ese es el verdadero rol del tester, una combinación de estratega e innovación en casos de prueba, aunque por desgracia no es muy habitual esta actividad. Por tanto, veo muy difícil que aplicando lo que yo entiendo por tester uno pueda caer en la rutina o en el aburrimiento.

Otra actividad que me gusta realizar son el estudio y aplicación de metodologías, normas, marcos de referencia, buenas prácticas y, especialmente, los enfoques ágiles. Realmente muchas de las "novedades" que descubrimos actualmente llevan años, o incluso décadas, creadas. Lo que realmente veo que tiene un enorme valor es la forma tan sencilla, eficiente e incluso divertida de aplicarse en la actualidad. Es sencillamente apasionante analizar propuestas, ya veteranas como Scrum, o propuestas más actuales de escalado ágil, comparándolas con metodologías del siglo 20.

7. El año pasado, fuiste el ganador de la mejor ponencia en ExpoQA, a lo largo de todos estos años, ¿cómo has visto la evolución de los contenidos que se pueden ver los eventos? ¿estamos hacía caminos demasiado técnicos?

 Respecto a los eventos, yo creo que miran hacia el futuro, hacia la innovación, hacia elementos nuevos, y es necesario, positivo y lógico que tengamos este tipo de visión a medio y largo plazo para que el mercado puede evolucionar.

Pero echo en falta más casos de éxito que marquen un camino real y útil a otros, así como casos de fracaso, es decir, errores que no deberíamos volver a cometer en el mundo del testing. No me gusta que el 100% de una presentación se centre en lo que una empresa es y en lo que puede ofrecer. Las presentaciones de hace 20 / 30 años eran de este segundo tipo, pero en la actualidad ya es muy habitual que pongan como condición para un evento hablar de experiencias útiles para otros.
Lo que me sorprende gratamente es que no solamente existe un evento de testing de manera anual. Existen varios eventos importantes en varias ciudades de España algunos de ellos de carácter internacional que en una de sus ediciones se ha celebrado en ciudades españolas. También me llama especialmente la atención como el colectivo de testers ha creado una comunidad con mayor crecimiento en madurez y tamaño, que en otros colectivos.

Sin embargo, el cambio que considero más significativo está en la evolución de las ponencias. Aunque se debería avanzar más, se pasado de ponencias centradas en las posibilidades de una compañía, a ponencias centradas en la aportación a un colectivo.

Otro aspecto interesante es el perfil y la media de edad de los ponentes. Me agrada ver cómo cada vez hay más profesionales que hablan de grandes experiencias en público con una edad relativamente joven.

Quizás, en unos años, desaparezca el típico formato de trasparencias y de comunicación unidireccional de un orador en pie hacia un público sentado. Parece algo difícil de imaginar, pero seguro que habrá cambios.

8. Para finalizar, ¿Vuelves a la carga este año en ExpoQA? ¿Puedes darnos un avance de lo que vas a tratar en tu ponencia?

Bueno eso de adelantar los secretos dicen que no es una buena práctica. Hay que guardarse unos cuantos ases en la manga. Intentaba ser una broma, pero es complejo trasmitir humor con un texto. Voy a tener que practicar más...(risas).

Puedo comentar lo que está publicado ahora mismo. Se trata de hablar de como la inteligencia artificial va a ayudar al tester. De hecho, creo que lo va a transformar.
La idea de la transformación digital la entiendo como ese cambio cultural y de mentalidad de las personas provocado porque ahora tenemos tecnologías que nos van a obligar a trabajar, pensar y realizar las tareas de otra manera. La tecnología no sólo nos permitirá hacer las mismas cosas de una manera más sencilla y rápida. Para mí el cambio fundamental es que hará innecesarias algunas de las tareas que hacemos actualmente y nos requerirá que hagamos otras nuevas. Esto puede dar un poco de vértigo, pero me temo que es imparable y la historia nos dice que con alta probabilidad es mejor para todos.

Vamos a una sociedad altamente tecnificada con ciclos de vida de productos y servicios cada vez más rápidos. Está alta tecnificación va a obligar al tester a una cualificación técnica muchísimo mayor de lo que estamos acostumbrados.  Si la automatización de pruebas de alguna manera obligaba al tester a enfrentarse a la programación, la aplicación de un proceso de desarrollo software basado en DevOps le hace implicarse en los procesos de negocio y de desarrollo, en la tecnología, en la arquitectura y en la seguridad.

La inteligencia artificial realmente va a ser lo que decante al tester como estratega y profesional que previene los fallos. Esto no implica que debamos ser expertos en inteligencia artificial, sino asumir que formará parte de nuestra profesión. Por ejemplo, yo no sé construir una casa o un coche, pero soy perfectamente capaz de usarlos y saber sin son adecuados para mis necesidades. Muchas gracias.

martes, 5 de marzo de 2019

Las dimensiones de la Calidad


Si hablamos de dimensiones, en QA, tenemos que saber que son algunas características que debe de enumerar el software en base a unos criterios que especifiquemos.


Fueron creadas por David Garvin y sugieren que deben de tomarse en cuenta, adoptando un punto de vista multidimensional.  Estas dimensiones no fueron diseñadas, únicamente, para la calidad del software, si no que son a nivel general. En un principio, fueron 8. Y se han ido ampliando con el paso del tiempo.

Como ya hemos hablado más veces, la calidad es un concepto difícil de definir con precisión. Con estas dimensiones podemos analizar la calidad y darle una entidad concreta.

Algunas de las dimensiones que se utilizan actualmente son las siguientes, en orden alfabético:

·      Accesibilidad: si el software puede ser usado por cualquier persona de manera cómoda. Se incluyen las herramientas que mejoran la accesibilidad, como, por ejemplo, el reconocimiento de voz o las lupas de zoom.

·      Compatibilidad: si el software se adapta correctamente a diferentes entornos, sistemas operativos, navegadores…

·      Concurrencia: si se atienden, a la vez, varias solicitudes al mismo recurso, en el mismo momento.

·      Eficiencia: si el software funciona como debe y logra aportar soluciones sin desperdiciar recursos, esfuerzo, tiempo, dinero o energía.

·      Escalabilidad: Si se puede aumentar o disminuir el rendimiento en base a la demanda de procesamiento.

·      Fiabilidad: Si el software puede realizar la función requerida sin errores.

·      Funcionalidad: si se realizan las funciones dentro de lo especificado o deseado.

·      Instalabilidad: si el software se puede instalar en un entorno específico.

·      Localizabilidad: si podemos usar el software en diferentes idiomas, zonas horarias…

·      Mantenibilidad: si el software puede modificarse de manera sencilla.

·      Portabilidad: La capacidad del software para transferirse de un lugar a otro y seguir funcionando con normalidad.

·      Rendimiento: La velocidad de carga al realizar una acción en concreto.

·      Seguridad: si el software es difícil de hackear y tiene bien protegida la información que maneja.

·      “Testabilidad” o Probabilidad: Si el software puede probarse fácilmente.

·      Usabilidad: Si el software puede usarse correctamente.

Tres palabras nos definen

Integridad

  • Colaboramos sobre la honestidad y la honradez.
  • Nos intentamos ayudar en todo lo que necesitemos.
  • Siempre buscamos como aportar a las personas.

Ética

  • Colaboramos sobre una conciencia de responsabilidad.
  • Adquirimos un compromiso si aceptamos ayudar.
  • Nuestra satisfacción es la colaboración bien hecha.

Sostenibilidad

  • Exportamos conocimiento, colaboramos y somos una comunidad.
  • Creamos un entorno colaborativo entre todas las personas.
  • Las iniciativas son realizadas por personas para personas.
189 Colaboradores
Ayudamos en todo lo que podemos
5576 Seguidores
Hacemos comunidad entre tod@s
92 Días
Y seguimos ayudando a diario

¡Somos personas!

Víctor Gómez Adán
President | Founder
Sandra Gómez Adán
Co-Founder | Collaborator
Estefanía Fdez. Muñoz
Collaborator
Ignacio Lopez Carrillo
Collaborator

¿Hablamos?

¿Quieres colaborar?

Si quieres colaborar, ayudar o tienes en mente algo en lo que podamos ayudarte, no dudes en ponerte en contacto con nosotr@s.

Dirección:

Spaces Río Madrid - Calle de Manzanares, 4

Email:

hola@qalovers.com

Teléfono:

(+34) 648 961 876