El inteco, Instituno Nacional de Tecnología de la comunicación, ofrece cursos online gratuitos en calidad sobre Software. Los cursos tienen una duración aproximada de entre una y cuatro horas, dependiendo del curso, aunque son muy fáciles de leer y os puede llevar media hora completar uno. Así que, como os podréis imaginar, los cursos son a nivel introductorio, no entran en demasiado detalle. Pero bueno, están bien para gente que esté comenzando en este mundillo. Yo he estado haciendo varios de ellos, “desarrollo ágil“, “Introducción a la gestión de Servicios” y otro sobre “modelos de ciclos de vida” y estuvieron bien. A ver, esto es como todo, si tienes varios años de experiencia en desarrollo con metodologías ágiles probablemente el curso no os cuente nada nuevo. Adjunto el link al catálogo de cursos:

https://formacion-online.inteco.es/inscripcion/

Además, para los que no conocéis el inteco, tienen un sección en su web sobre calidad de software que os puede resultar muy interesante. En esta sección encontraréis templates, guías de buenas prácticas, etc…además de un amplio catálogo de servicios.

Referencia:
http://www.inteco.es

Inés Toribio publicó esta mañana un post en el grupo de “Valencia Testing” que creo que debe de ser comentado en la página principal. Como ella misma menciona en su post ayer hubo una charla en Valencia a cargo de Agile Levante sobre Metodologías de implantación de calidad focalizada en “Agile Methodologies”. He estado leyendo el material titualdo “Calidad e integración contínua. Una Introducción” y la verdad que creo que debe de ser compartido porque os puede ser de mucha ayuda. La charla y el material fúe desarrollado por Carles Climet en su blog bajo la sección de “materiales“.

Como dice Inés en su post: “Chapó!!! Ojalá todo el mundo viera la necesidad de ver que compartir conocomientos sin esperar una transferencia bancaria a cambio es enriquecedor. Muchas gracias a todos los que ayer estuvisteis allí me disteis un subidon de moral y de ánimos , sobre todo , cuando uno piensa que está solo.“

Referencia:

]]> http://www.softqanetwork.com/charla-de-carles-climent-en-valencia-sobre-calidad-e-integracion-continua-una-introduccion/feed 2 http://www.softqanetwork.com/implementacion-practica-de-risk-based-testing-en-vuestra-organizacion http://www.softqanetwork.com/implementacion-practica-de-risk-based-testing-en-vuestra-organizacion#comments Thu, 05 Jan 2012 01:56:36 +0000 Javierpello http://www.softqanetwork.com/?p=4893

Vamos a empezar el 2012 hablando de “riesgos” y más concretamente en lo que se conoce en el sector por “Risk-Based Testing” (Testing basado en riesgos), aunque en esta ocasión quería darle a este artículo una visión práctica de mí experiencia profesional en el tema. No me gustaría entrar demasiado en la teoría y si en los problemas reales que os podrías encontrar antes y durante la implantación de un proyecto de estas características en vuestra organización. Es decir, que realmente podáis ir a vuestra organización e implantarlo en vuestros proyectos. Hay mucha literatura escrita sobre esta materia, entra la que destaca un artículo escrito por James Bach allá por 1999 titulado “Heuristic Risk-Based Testing“.

Hace un par de meses tuve la oportunidad de trabajar, conjuntamente con Ewout Van Driel, en la implantación del “Risk-Based Testing” en los proyectos de la empresa en la que trabajaba con el propósito de alcanzar el nivel 2 de TMMi (Test Maturity Model Integration). El TMMi de nivel 2 exige tener Risk-Based testing implantado en tu organización para conseguir el nivel (entre muchas otras cosas, claro). Dicho esto, vamos al grano, lo primero que tenéis que pensar es, ¿cuál es mi motivación? ¿Porqué quiero hacer Risk-Based Testing? y lo que es más importante, ¿está mi empresa lista para implementar Risk-Based testing?. ¿Porqué pongo estas cuestiones encima de la mesa? por una razón obvia pero muy importante, a la hora de enfrentarse a un proyecto de estas carácterísticas si vuestra empresa no está preparada, no entiende y no “compra” los beneficios del “Risk-Based testing” estáis perdiendo el tiempo y vuestro proyecto fracasará. Cada cosa tiene un “timing”, no intentéis ir demasiado rápido, aseguraros que vuestra empresa tiene un nivel necesario de madurez para implementar algo así. Hace dos años intentamos introducir el “Risk-Base Testing” en la organización, el proyecto fracasó porque no era el momento adecuado, todavía no teníamos la madurez necesario para implementarlo…primero era necesario dar otros pasos previos.

Así que, vamos a definir rápidamente que es el “Riesgo”“:

¿Porqué necesito “Risk-Based Testing”? Partiendo del supuesto que para cualquier aplicativo software con un tamaño significativo, el número de combinaciones de casos de prueba que, teóricamente, podrían ser ejecutados pueden ser enormes sino infinitos, debemos de tener un mecanismo como el “Risk-Based Testing” para evaluar y priorizar nuestro testing. Lo importante es que el riesgo es un problema que podría suceder, que todavía no ha sucedido y que existe la posibilidad de que algo malo ocurra, lo que puede provocar un impacto en nuestro negocio. Por tanto es necesario identificar los riesgos, los posibles impactos y definir casos de prueba que los mitiguen.

Los beneficios son claros e inmediatos, ya que nos ayudará en el diseño de los test cases y en la priorización de las ejecuciones. Otros beneficios destacables:

• Ayudarás a todos los miembros del equipo a entender los riegos de las funcionalidades implementadas en la “release” y las acciones de mitigación que haremos mediante el testing.
• Proporcinar a negocio con información objetiva para tomar decisiones basándose en los riesgos.
• Ayuda en la definición de la severidad de los defectos.
• Mejores planificaciones de prueba. Nos ayudará a la hora de definir nuestro test plan.
• Uso efectivo de recursos.
• Nos ayudará en términos de “cost effective testing”

¿Cómo hacemos el análisis? El análisis debemos hacerlo lo antes posible y siempre previamente al diseño de nuestros test cases. Para hacer el análisis consideraremos dos factores:

• Business Criticality, o como de crítica es una funcionalidad para nuestro negocio. Esta parte es puramente de negocio y debe de ser proporcionada por nuestros “business partners”. Del factor “Business Criticality” obtendremos como resultado tres valores posibles, A – Crítico, B – Importante, C – “Nice to Have”.
• Failure Probablility, o probabilidad de fallo que vendría más ligado a la complejidad técnica. Como de probable es que un requisito falle de alguna manera. Esta información será proporcionada por nuestro equipo técnico. Del factor “Failure Probablility” obtendremos como resultado tres valores posibles, 1 – Alto, 2 – Media, 3 – bajo

Por tanto al final de nuestro análisis tendremos nuestras peticiones de negocio o nuestros requisitos distribuidos en una Boston Matrix en función de la ponderación de los pesos obtenidos en el análisis. Por ejemplo: A1, B3, A2…lo que nos indicará la cobertura de pruebas que debemos realizar. En este caso que estoy exponiendo sería “Completa“, “Parcial“, o “Básica“. Por tanto, debéis definir que es completa, que es parcial y que es básica para vuestra organización.

Pasos que debemos seguir:
1) Definir nuestro “Risk-Based Testing Approach“, es decir, debemos de tener muy claro que es lo que queremos hacer, que herramientas vamos a usar o que criterios usaremos para definir nuestro “Business Criticality” y los criterios que usaremos para nuestro “Failure Probability”.

2) Definición del proceso. Debemos de definir cuales van a ser las personas que participarán en cada una de las fases del proceso, cuales son los inputs y los outputs de cada proceso, en que momento vamos a recopilar la información, quien hará el análisis…etc. Recomiendo que la recogida de datos de nuestra “Business Criticality” debería ser obtenida en nuestra fase de elicitación o gestión de requisitos y nuestros criterios de “Failure Probability” durante la fase de diseño.

3) Definición de criterios tangibles, criterios a los que podamos dar un valor y cuantificar. Estos criterios los definiremos tanto para “Business Criticality” como para “Failure Probability”. Si simplemente definimos criterios como “Prioridad: Alta, media o baja”, no estamos aportando ningún valor. Debemos buscar criterios como “Frecuencia de uso”, “Tipología de usuario”, “Motivación para negocio”, “Complejidad técnica”, “impacto en el aplicativo”…etc. Por supuesto dependiendo del sector o del aplicativo a desarrollar estos criterios serán diferentes, es importante que involucréis tanto a vuestros responsables de negocio como a vuestros equipos técnico para que os ayuden a definir estos criterios. Una vez tenemos los criterios les asignamos un peso, peso que puden ser por ejemplo 30, 18, y 8. Siendo 30 el más importante, 18 medio y 8 el de menor. Esta ponderación os dará unos datos muchos más reales que si usáis 5, 3 y 1 por ejemplo.

Es fundamental obtener su feedback, para que realmente se sientan partícipes en el proyecto. Al final obtendréis un conjunto de criterios, con un pesos específicos, que os ayudarán al análisis final. Conjunto de criterios que han sido definidos por todos los miembros del equipo y que no han sido impuestos por Testing. Todos se sienten partícipes del “Risk-Based Testing”

4) Involucra a los stakeholders. No debemos olvidar que los criterios que hemos definido de “Business Criticality” y de “Failure Probability” deben de ser informados por negocio y por nuestro equipo técnico respectivamente. Nosotros, como equipo de testing, recibiremos esta información, la analizaremos y enfocaremos nuestra estrategia de testing en función de dicho análisis.

5) Herramientas que utilizaremos. Lo más sencillo sería recopilar toda la información usando excel. Con un simple excel podréis obtener de negocio a nivel de “Business Request”, o a nivel de “Requirements” toda la información requerida para el análisis de vuestra “Business Criticality”.

Otras alternativa sería usar el HPQC, que tiene su propio módulo de Risk-Based. En el caso del proyecto en el que participé, usamos una herramienta de gestión de demanda para toda la parte de “Business Criticality”, dentro nuestros representantes de negocio nos informaban y proporcionaban la información y la parte de “Failure Probability” era informada en IBM Req. Pro, ya que teníamos definidos todos los atributos en la herramienta para que fuesen informados por nuestros equipos de desarrollo. Después importábamos todo los datos en un excel y obteníamos el análisis. La parte de negocio nos proporcionaba una letra, A, B o C….mientras que la parte técnica nos proporcionaba un número, 1, 2, o 3….y con eso pintábamos una “Boston Matrix” para cada petición de negocio:

Ejemplo práctico
Vamos a imaginarnos el caso en el que queremos implementar la siguiente funcionalidad o petición hecha por nuestro cliente: “Crear búsqueda de clientes avanzada“. Esta nueva funcionalidad es crítica para el negocio por lo que tendrá un peso de 30 en nuestro criterio de “importancia para negocio”, además es una funcionalidad que debe de ser implementada antes de final de año porque tiene un implicación legal, otros 30 en nuestro criterio de “tipo de motivación para negocio”….y además es usada por todos los empleados de la empresa, así que tendrá otro peso de 30 en el criterio de “Nº de usuarios impactados”. Desde el punto de vista de negocio, el una funcionalidad crítica, y tendrá asignada la letra A.

Ahora hagamos el mismo análisis desde un punto de vista técnico. Implantar esta nueva funcionalidad implica escribir un gran número de líneas de código, 30. Además tenemos que tocar varios componentes críticos de nuestro código, otros 30. Además impacta en nuestra arquitectura, 30. Finalmente obtendrá un valor de 1. Esta funcionalidad dentro de nuestra Boston Matrix estará en el cuadrante rojo, será un A1 y requerirá de un testing exhaustivo. Gracias a este análisis podemos focalizar nuestro esfuerzo en testing en las áreas que realmente necesitarán más recursos.

Ahora imaginemos que queremos implementar un nuevo campo en la búsqueda avanzada, por ejemplo: “Nuevo campo de edad en la búsqueda“. Este cambio es una mejora y no afectará al negocio, no es crítico y no es un requerimiento legal. Desde el punto de vista técnico, es fácil de implementar y no afecta a ninguno de los componentes críticos del aplicativo. Por otro lado, al no afectar a otros componentes críticos no requerirá casi de test de regresión. En el cómputo global, un requerimiento de estas características sería un C3…por tanto esta funcionalidad estará en el cuadrante verde de nuestra Boston Matrix y la ejecución de test cases será básica.

En resumen
Espero que os haya quedado más o menos claro como podríais implantar el Risk-Based Testing en vuestra organización. Es un poco complicado resumir en unas pocas líneas un trabajo que nos llevó tres meses. De todos modos, podéis contactarme son ningún compromiso si necesitáis más información. Saludos

Referencias:
– HP Quality Center 9.2 – Risk-Based Testing module

Navegando por la web Navegápolis.net (una de las web que visito frecuentemente, la cual recomiendo que visitéis) he encontrado un artículo que podría ser de vuestro interés y que quiero presentaros…se trata de “AgileBox“.

AgileBox es “un sistema de desarrollo integrado en el que se han tratado de elegir los subsistemas más utilizados actualmente (Subversion, Nexus, Jenkins, Sonar), con la idea de poder programar con los principios de eXtreme Programming: integración contínua, control de versiones, calidad de código y control de la configuración. 100% Open Source.“

En #lebrijocom Labs han creado una máquina virtual con virtualbox para que la apropiada gestión de nuestros desarrollos de software ya no sean una disculpa…está todo listo para nuestro uso y disfrute. La verdad que de todas estas herramientas la única que no conocía era Redmine, así que buscando más información sobre dicha herramienta he encontrado un análisis hecho por el “Centro de Excelencia de Software Libre de Castilla-La Mancha” que puede ser de vuestro interés. Básicamente es un gestor y planificador de proyectos…

Como este es un portal sobre calidad, aunque son importante todo el resto de piezas para tener un entorno de desarrollo y pruebas maduro, las herramientas que más nos pueden interesar son Jenkins y Sonar. Jenkis para la parte de integración contínua y Sonar para gestionar la calidad de nuestro código fuente. Personalmente nunca he trabajado con Jenkins (antes llamado Hudson), y en su lugar he trabajado con “Cruise Control” para hacer integración continua, bueno no pasa nada. Lo importante es que con ambos podemos usar el Checkstyle, Findbugs o PMD…

De todos modos, lo que me parece una pena es que hay mucha gente del sector que no conocen este tipo de herramientas, es decir, que nunca han oído hablar de ellas. Tampoco es necesario el haberlas utilizado todas, pero al menos saber que es la integración continua, que podemos hacer con ella y las herramientas que hay en el mercado. Pues bien, esta es una muy buena oportunidad de conocer no solo esas herramientas sino el pack completo. El único requisito que se necesita es tener una máquina con Ubuntu, lo cual podría ser un problema para algunos.

Referencia:

• Navegapolis.com
• AgileBox
• Centro de excelencia de Software Libre Castilla-La Mancha

Hace ya casi un año que oí hablar de la herramienta “Sikuli” por medio de mi amigo Tedi Roca, que siempre me está hablando de las maravillas de esta herramienta. Desde entonces no había tenido tiempo para descargármela y jugar con ella. Pues bien, aprovechando mi periodo vacacional he decidido dedicarle un tiempecillo para que conozcáis de cerca esta herramienta. ¿Qué es Sikuli? una herramienta de automatización de pantallas (GUI) utilizando imágenes y comparando los píxeles en pantalla para identificar objetos. La verdad que Sikuli introduce una nueva manera de hacer automatización, es capaz de automatizar cualquier cosa que aparezca en la pantalla, páginas web (con Flash o programadas en AJAX), emuladores de móviles, y cualquier aplicación bajo Linux, Windows o MacOS X. ¿Es mejor o peor que SilkTest, Testcomplete, QTP o Selenium…etc? yo diría que es diferente, depende de lo que queramos hacer….incluso diría que Sikuli nos puede servir de complemento a cualquiera de ellas. Yo soy de la opinión que no debemos cegarnos con una sola herramienta, una sola metodología o una sola forma de hacer las cosas…lo mejor es combinar para poder obtener mejores resultados.

Que me ha gustado:

• Fácil de usar. En media hora he montado un script muy sencillo para testear algunas funcionalidades de SoftqaNetwork.com, podéis ver el script un poco más abajo.
• No hay que aprender ningún lenguaje propietario nuevo. Si quieres hacer scripts un poco más sofisticadas puedes usar Python.
• El poder comparar imágenes. Lo complicado que es con otras herramientas de automatización el poder mirar dentro de un archivo que la información generada es correcta, con Sikuli haces varios pantallazos y comparas imágenes…genial!!!!
• Podréis lanzar los scripts desde la línea de comandos.
• El poder integrarlo con otras herramientas como selenium o Robot Framework me parece una opción interesante. Aun no he podido investigar en este sentido pero he visto varios ejemplos muy guapos

No me ha gustado:

• No es muy útil para entornos cambiantes. Si trabajáis en un proyecto donde la UI está cambiando constantemente, estáis perdido. Os pasaréis horas y horas cambiando imágenes.
• No se pueden crear “Test Suites”. Para mí, personalmente, es el mayor problema. Parece ser que te puedes programar tus propios scripts con Python para lanzar suites de tests, pero la funcionalidad no viene de serie y eso es un gran problema.
• En muy lento y algunas veces hace cosas raras. Lo de la lentitud es un hecho, no es una aplicación que sea rápida. Referente al tema de que hace cosas raras, algunas veces que deja “petao” el browser…y he tenido incluso que reiniciar la máquina varias veces. Me ha pasado varias veces con la rc3.
• No se puede usar los mismos scripts para diferentes navegadores. IE y firefox no siempre renderizan de la misma manera las imágenes o las css, por tanto los scripts que tenemos para ejecutarse en IE no servirán para firefox. Hacer la prueba, utilizar mi script y ejecutarlo primero con IE: App.open(“c:\\Archivos de programa\\Internet Explorer\\iexplore.exe”) y después comentar la línea y poner: App.open(“c:\\Archivos de programa\\Mozilla Firefox\\firefox.exe”).

En resumen:

La verdad que me ha gustado mucho, es muy fácil de usar y tiene mucha documentación y tutoriales donde realmente podréis ver las virguerías que se pueden hacer con esta herramienta. Por otro lado, cada empresa es un mundo y no creo que a todo el mundo le pueda servir este tipo de herramienta. Eso sí, la veo súper útil para páginas web tipo Amazon o páginas web que tengan catálogos de productos, ya que puedes compara imágenes de los productos y puedes saber exactamente si la web está mostrando la imagen de un producto o de otro. También para comparar contenido dentro de un documento, por ejemplo si al final de nuestro test cases generamos un documento “pdf” y queremos testear que efectivamente el logo de la empresa está en su sitio y que la información y textos son los que deberían ser. En fin, estoy seguro que existen muchas otras aplicaciones…yo mientras tanto, seguiré investigando en la materia…

Aquí os dejo mi script. Primera parte del script:

Segunda parte del script:

Tercera parte del script:

Abriré un grupo en la comunidad para poder seguir dialogando sobre esta herramienta, compartir scrips o resolver dudas.

Referencias y sitios de interés:

• Sikuli.org
• Robot Framework
• Python

SoftqaNetwork os desea Felices Fiestas!!!!!!!!! y prospero año nuevo. El 2011 ha sido un gran año desde el punto de vista personal y profesional, me lo he pasado muy bien en todos y cada uno de los eventos que hemos organizado desde la asociación. Este 2011 he terminado una etapa profesional muy importante y comenzaré el 2012 con nuevos retos.

Para recapitulando, este año he tenido la oportunidad de viajar a Frankfurt y participar en la conferencia “Testing & Finance 2011” con mi colega “Raul Alares“, una gran experiencia porque era la primera vez que daba una conferencia en inglés. En el trabajo tengo que hablar muchas veces en inglés en público, pero esto era algo diferente. Al final, la presentación estuvo muy bien y me he quitado ese miedo de encima.

Por otro lado ha sido un gran año para la asociación “TestQA“, durante este período hemos lanzado un nuevo evento de debates llamando debaTest (promovido por Toni Robres) que ya hemos celebrado en dos ocasiones en Barcelona: el “debaTest de Automatización” y el “debaTest de Agile Testing“.

Y por supuesto no podemos olvidarnos del evento SeasonTest, que este año lo hemos realizado en tres ocasiones. Pero lo más importante es que lo hemos realizado fuera de Barcelona, desplazándonos con nuestro invitado “Javier Lopez” hasta Valencia…una gran experiencia que ha sido posible gracias al ITI y a todos los asistentes de Valencia que participaron con mucho entusiasmo. Aquí en Barcelona entrevistamos en el WinterTest a Jordi Ascolies y en el AutumnTest a Lluis Serratosa. Todos ellos grandes amigos, así que mil gracias por aceptar la invitación al evento…y gracias a los miembros de la asociación y a todas las personas que nos han ayudado a que los eventos sean realidad. Y por supuesto, no podemos olvidar a los patrocinadores, que sin ellos sería complicado realizar estos eventos.

En en AutumnTest Valencia:

El viaje a Valencia fue bastante completo, ya que además de realizar el AutumnTest Valencia participé como ponente en el VLCTesting 2011. Un evento que espero que sigan organizando porque estuvo muy muy bien.

Por otro lado también está workinqa y SoftqaNetwork, que van a toda vela. Workinqa cada vez tiene más ofertas de empleo, y esperamos que algún día sea una referencia en el sector. Por otro lado SoftqaNetwork cada vez tiene más visitas y más personas registradas.

¿Qué me espera el 2012? espero que nuevos retos…y por supuesto seguir trabajando con mucha ilusión en la mismo línea que años anteriores!!!!!!.

Edreams me deja en tierra según ellos por culpa de un “error informático“. El pasado 13 de Octubre compré unos billetes a México, cuatro días después llamo a KLM para reservar la cuna de mi hijo y me dicen que todos los tramos están reservados excepto uno y que llame en un par de días. Unos días después llamo a KLM y me encuentro la desagradable noticia de que los billetes no existen, que tal vez fueron cancelados. Llamo inmediatamente a edreams y el servicio de atención al cliente me informa que debido a un error informático los tickets fueron cancelados al día siguiente de mi compra. ¿Cómo es eso posible si yo hablé con KML varios días despues y la reserva existía? Bueno, según edreams nos mandaron un email informándonos de la cancelación, email que no hemos recibido. Pero la cosa no queda ahí, la persona que nos atendió por teléfono nos dijo que tal vez no recibimos el email porque la dirección de correo estaba mal. ¿Estaba mal? ¿entonces como recibimos el email de confirmación de compra?. ¿Otro error del sistema? ¿¿¿¿tal vez no se estén enviando los email de cancelación?????. Les hemos pedido que nos remitan el email de cancelación con la fecha en la que fue enviado y seguimos esperando, está claro que no nos enviarán nada porque no enviaron nada de nada.

Por supuesto edreams no se hace responsable de nada y nos ofrecen los mismos billetes por 400 euros más caros, todo un detalle por su parte!!!!!! Pues nada, gracias a uno o varios errores informáticos tengo que comprar nuevos billetes y encima me constarán más caros…gracias “edreams, ya no viajaremos más contigo!!!!!”. El servicio al cliente en este país es increíble, ni se responsabilizan, ni te llaman…en fin, este sería otro tema diferente.

Muchos podríais pensar que lo que me han dicho es la típica disculpa que cualquier call center da a sus clientes cuando ocurre una incidencia, pero es la información que me ha proporcionado la empresa. “Un error informático”, el error es que ante un problema así no sean capaces de monitorizar e identificar las transacciones fallidas o canceladas para así ponerse en contacto con sus clientes y solucionar el problema. Hace un par de años tuve un problema similar con otra compañía (no recuerdo cual, una de las grandes), tenían un problema con sus sistemas…al día siguiente me llamaron y arreglamos el asunto.

Llevo 10 años comprando billetes online y es la primera vez que me pasa algo así…eso si, ellos responsabilidad cero, me devuelven los 70 eurozos de “gastos de gestión” y venga, aquí no ha pasado nada…ahora a buscar otros billetes.

Emilio Avilés (un buen amigo y ex-compañero de trabajo), CEO de la empresa “Slash Mobility“, me envía esta interesante presentación titulada: “Testing en aplicaciones móviles iOS, Android“. Una presentación de Jose Cortés que cubre los principales aspectos del testeo en aplicaciones móviles. Con el crecimiento de la penetración de las tecnologías móviles en el mercado, es incuestionable la importancia de que las empresas del sector comiencen a considerar la implantación de mecanismos o metodologías de control de calidad diseñadas específicamente para dichos entornos….en términos de rendimiento, disponibilidad, seguridad…etc.

Para los que aún no conocéis “Slash Mobility” es una joven compañía dedicada a dar servicios de tecnologías especializados en movilidad. Su misión principal es aportar, de una forma tangible para las empresas, la aproximación a las nuevas tecnologías de movilidad…os invito que visitéis su web porque siempre están organizando cursos de formación sobre desarrollo y testeo de aplicaciones móviles.