Fran 🐝 Brizzolis en Marketing y Producto, beBee en Español, Informática y Tecnología Global Brand Ambassador • beBee Affinity Social Network 23/4/2018 · 10 min de lectura · 28,3K

BeBee y su nueva plataforma... ¿Cómo desarrollar un nuevo software y no morir en el intento?

beBee y su nueva plataforma...   ¿Cómo desarrollar un nuevo software y no morir en el intento?



Hola abejas, es en estas fechas cuando se cumplen (¡ya!) 2 "intensos" años desde que me incorporé a beBee, y como en años anteriores quería hacer algo “especial”, pero sin dejar de ser fiel a mi temática habitual.

Además, quería "aprovechar la ocasión"  para agradecer de alguna forma, y “homenajear” muy humildemente a todo el equipo de beBee, por su gran paciencia, esfuerzo y dedicación, porque los usuarios podemos llegar a ser muy pesados y desconsiderados a veces, y no sabía cómo hacerlo, ni sobre qué escribir.


Al final la solución a esta falta de inspiración fue sencilla, sólo tuve que hacer un repaso de la evolución y la situación actual la colmena en las últimas semanas para tener claro sobre qué escribir, de tal forma, que a la vez pudiese servir de reconocimiento a la gran labor y al enorme esfuerzo de todos y cada uno de los componentes de la plantilla de beBee, desde los “jefes”, hasta los “botones”, por decirlo de alguna forma.


Así que voy a hablaros, del desarrollo de software,  y de las distintas pruebas que se realizan, antes de que la versión final y definitiva llegue a nuestros dispositivos móviles y ordenadores personales.

Todos hemos notado y “sufrido” (en estas últimas semanas) los inconvenientes de lo que puede suponer el desarrollo de una nueva plataforma para nuestra querida colmena, pero por mucho que nos incomode, debemos pensar que esto es consecuencia directa del gran éxito de beBee, y de su gran crecimiento que, entre otras cosas, presiona mucho, y obliga a tener que hacer muchas más mejoras de las inicialmente previstas, y desde luego, en mucho menos tiempo, lo que a su vez genera también nuevos fallos y equivocaciones, que sufrimos todos.


Si puede molestarnos un mal funcionamiento de algo como usuarios, ¿podéis llegar a imaginar lo que puede suponer esto a los distintos miembros del equipo de beBee?, que se ven presionados por todos nosotros, por el mercado y la "actualidad", por los respectivos superiores de cada uno, y también por los inversores, que han depositado su confíanza y su dinero en un proyecto, con el que desde luego quieren obtener beneficios, ya que no son ninguna ONG.


Podéis estar bien seguros de que desde luego, ni es fácil, ni mucho menos agradable, y para que tengáis una “ligera idea” de la ingente cantidad de trabajo y esfuerzo que supone todo lo que están realizando, es para lo que escribo este artículo, que espero y deseo leáis con la misma atención y cariño (por ellos) que he puesto yo al hacer este post, teniendo en cuenta que yo no soy ningún profesional del desarrollo de software, por lo que puede ser que el artículo pudiera contener errores, por los que anticipadamente pido perdón a los verdaderos expertos y profesionales del tema, como puedan ser los propios miembros de beBee, y demás usuarios y profesionales que hay con grandes conocimientos del tema.


Escrito por mí, con todo el cariño y admiración que me ha sido posible para todos vosotros, chic@s de beBee, y por supuesto, “resumido y domesticado” también por mí, con el mismo cariño y respeto a todas las abejas de beBee, sean conocidas o no, seguidoras o no, veteranas, o bien recién llegadas, todo esto es también por supuesto para todas y cada una de las abejas de beBee.






¡Va por todos vosotros chic@s!


Los test antes de lanzar la versión definitiva de un programa informático no son algo opcional, ni mucho menos, el éxito y el “desempeño” y la calidad y fiabilidad de nuestro programa dependerá en buena medida de las pruebas a que sometamos a la versión previa de cada programa, y de los “malos ratos” que hallamos pasado, tanto nosotros, como los usuarios, ya que NUNCA se consigue el “software perfecto” a la primera (ni muchísimo menos), y hay que seguir mejorándolo, incluso después de haberlo sacado al mercado.

Esto que os parece a muchos una verdad “obvia”, sigue siendo, sin embargo, uno de los temas pendientes en el mundo del desarrollo de aplicaciones de software, mucho más habitual de lo que me gustaría, y de lo que pudiera parecer.

Desarrollar un software sin hacer pruebas es como hacer funambulismo sin red de seguridad, y además representa una fuente de errores y malas prácticas, además de asegurarse un fracaso prácticamente seguro.

Voy a intentar mostraros algunos de los conceptos básicos de las pruebas que se deberían hacer, de acuerdo con la opinión generalizada de los profesionales de este sector, pero tened en cuenta que yo no soy ningún desarrollador, ni mucho menos un profesional de esto, sólo soy un modesto teórico y apasionado del tema.





¿Por qué hacer pruebas?


Hacer pruebas es la forma de asegurarse de que lo que queremos que haga nuestro programa, lo haga eficazmente y de forma “estable”, y lo haga, desde luego, sin errores.

Los fallos y errores son inevitables, más todavía si sólo los intentamos evitar con nuestras propias capacidades, por eso debemos valernos de otras “herramientas”. Hay software que nos ayuda a “corregrir software”.

Cuando se escriben miles y miles de líneas de código (a veces hasta millones), e incluso en lenguajes diferentes, y por lo tanto, con diferentes “reglas ortográficas”, una simple “,” o un “espacio”, de más o de menos, o en el sitio equivocado, puede hacer que el software no funcione, o peor todavía, que funcione mal, con lo cual el error “concreto” podría pasar desapercibido, sabríamos entonces que hay un mal funcionamiento, pero no tendríamos una idea de qué tipo de fallo en el código lo está causando, y en qué parte del código podría estar.

Es aquí, cuando debemos tener en cuenta que hay también “dependencias”, por lo que, lo mismo que un error aquí, se puede reproducir también allí, dado que la "instrucción errónea" se puede estar utilizando en varios procesos distintos, tendremos que saber qué dependencias tiene esa instrucción, para corregirla en todos los procesos donde se ejecute, esto es lo que se llama "refactorización", y nos permite corregir un error en el código, teniendo las dependencias que pueda tener la esa instrucción erronea, de tal forma, que será totalmente corregida "donde sea necesario", pero sin afectar al comportamiento satisfactorio del programa.


Afortunadamente, antes de escribir el código, se ha de "diseñar" el programa, utilizando diferentes gráficos, donde “se ve el funcionamiento” del software, y todos “métodos” (instrucciones, funciones)  que nuestro software va a necesitar para funcionar correctamente, y todo esto se ha de hacer antes de empezar a escribir el código, propiamente dicho tal y como lo conocemos. Esto es lo que se denomina UML (Unified Modeling Language), que en español significa Lenguaje Unificado de Modelado, y del que seguro que nuestro apreciado  Federico 🐝 Álvarez San Martín   sabe muchas cosas, y nos puede contar muchas "historias para no dormir".




Existen los “Entornos de Desarrollo Integrado” (IDE), que son como unos editores de texto “especiales” que nos avisan de errores “ortográficos” y “gramaticales”, sugiriéndonos además alternativas posibles, para una mejor “redacción”.

Si a eso añadís, que “ese texto” estará seguramente escrito por más de una persona, la cosa puede ser muy complicada, y por eso se deben establecer una “normas previas” de cómo escribir que, para que todo el mundo lo haga de la misma forma y, además, las líneas de código se deben comentar, para facilitar la corrección y el entendimiento posteriormente.





Como curiosidad os diré que Linux OS puede tener unos 300 millones de líneas de código, Mac OS unos 90 millones, y Windows XP tenía unos 45 millones. Si no se siguieran ciertas normas de escritura, ni se hicieran comentarios de qué se pretende hacer en esta o aquella parte (módulo, líneas) del código, os imagináis cómo sería corregir un error de código 3 años más tarde, y sin ni si quiera haberlo escrito vosotros… Sería algo IMPOSIBLE. Las pruebas no son opcionales. Un software sin pruebas es una bomba a punto de estallar.

¿A qué desarrollador no le habrá pasado que ha dejado su código medio año en un cajón, y a la vuelta de ponerse a toquetearlo tener la sensación de que lo ha escrito otra persona?


Yo mismo, en un curso de programación de sistemas, cuando realizábamos un "sencillo" (para mí era todo un mundo) programa sin entorno gráfico y escrito en lenguaje Java, que representaba un vídeoclub (con todas sus operaciones y funcionalidades habitules)... Cuando meses más tarde quise mejorarlo en casa "tranquilamente", al ver el código de nuevo, era como si lo hubiera escrito otra persona, y casi tuve que volver a rehacerlo desde cero.


No reconocemos a nuestra propia criatura. Y no hablemos cuando estamos integrados en un equipo, o recibimos el “regalito” de soportar o evolucionar un código heredado.

Por ello, las pruebas son imprescindibles, ya que nos permiten garantizar que las aplicaciones cumplen las funcionalidades que se esperan de ellas y las expectativas de calidad (no sólo de código) ayudando a encontrar esos errores o defectos que aún no se han descubierto, reduciendo el costo del desarrollo, el de propiedad para los usuarios, y generando confíanza en los clientes al conseguir evitar los molestos errores de regresión.

Eso, sin hablar de la sensación creciente de seguridad que necesitamos tener conforme más cerca estamos del despliegue del nuevo software, ya que cuanto más código tengamos, más pruebas tendremos que hacer, para asegurarnos de que “todo” funcione correctamente.






El “universo” de los tipos de pruebas


Las pruebas también tienen una cantidad inacabable de diferentes tipos, versiones, evoluciones y clases, de la misma forma que el software en general, aquí os detallo algunas de las más habituales, importantes e imprescindibles.


Prueba unitaria:  Las pruebas unitarias son pruebas automatizadas que verifican la funcionalidad en el componente, clase, método o nivel de propiedad.

El objetivo principal de las pruebas unitarias es tomar la pieza más pequeña de software comprobable en la aplicación, aislarla del resto del código y determinar si se comporta exactamente como esperamos. Cada unidad se prueba por separado antes de integrarlas en los componentes para probar las interfaces entre las unidades.

Las pruebas unitarias deben “escribirse” antes (o muy poco después) de escribir un método, siendo los desarrolladores que crean la clase o el método, quienes diseñan la prueba.


Pruebas de integración:  Las unidades individuales se integran juntas para formar componentes más grandes. En su forma más simple, dos unidades que ya han sido probadas se combinan en un "nuevo" componente integrado y se prueba la interfaz entre ellas.

Las pruebas de integración o de “componentes”, identifican problemas que ocurren cuando las unidades se combinan. Los nuevos errores que surgen, probablemente estén relacionados con la interfaz entre las unidades, en lugar de ser errores exclusivos de las propias unidades, simplificando la tarea de encontrar y corregir los defectos.


Pruebas de regresión:  Cada vez que se realizan cambios en un proyecto, es posible que el código existente no funcione correctamente, (como funcionaba antes) o que se presenten errores no descubiertos previamente. Este tipo de error se llama regresión.

Todo el proyecto debe someterse a una regresión, que es una nueva prueba completa de todo un programa modificado, en lugar de una prueba de sólo las unidades modificadas, para garantizar que no se hayan introducido errores con las modificaciones.

Este tipo de pruebas debe ser automatizado, porque puede estar compuesto por decenas o miles de pruebas unitarias, de integración o más.

Una versión menos costosa, podría ser construir pruebas que repliquen las acciones que provocaron la regresión, y comprueben que han sido corregidos al no volver a sucederse los errores, además de añadir test unitarios que nos aseguren que el código donde se ha corregido la regresión funciona correctamente.


Pruebas de funcionalidad:  Son pruebas automatizadas o manuales que verifican las funcionalidades de la aplicación o módulo ya construidos, pero desde el punto de vista del usuario final, con sus diferentes roles, para validar que el software hace lo que debe y, sobre todo, lo que se ha especificado.

En su versión automática son pruebas que se automatizan para "ahorrar tiempo". A partir de los casos de prueba de las pruebas manuales, se automatizan otros casos de prueba para que se repitan en las ejecuciones. Esos casos suelen ser los más importantes de los módulos o procesos de negocio "vitales" de la aplicación. Es decir, son los procesos que siempre tienen que funcionar, y que bajo ningún concepto pueden fallar. El objetivo de las pruebas funcionales automáticas es comprobar que no haya regresiones.

En el caso de las pruebas manuales, éstas las ejecuta un tester (o varios) como si fuese un usuario, pero siguiendo una serie de pasos establecidos en el plan de pruebas, diseñado en el análisis de los requisitos, para garantizar que el software hace lo que debe (casos positivos), que no falla (casos negativos), y que es lo que el cliente ha solicitado.

El tester realizará las acciones indicadas en cada paso del caso de prueba, comprobando que se cumple el resultado esperado. Si el resultado es distinto, se reportará un defecto con todo detalle: descripción, datos utilizados, capturas de pantalla, etc. para poder replicar el error si es necesario, y facilitar la solución.

El mayor problema con el que se enfrentan las pruebas funcionales para ser automatizadas es su fragilidad. Cada prueba puede testear miles de líneas de código, centenares de integraciones, y una interfaz de usuario cambiante. Llegando a no ser  "sostenible" en su totalidad y de acuerdo con su objetivo y su definición, el coste y mantenimiento.



Buscando el límite de las aplicaciones


Ahora viene la parte de operaciones, donde también se deben probar de forma automática las capacidades y debilidades del software y de la plataforma sobre la que corre (infraestructura y dependencias), llevándola al límite, para comprobar su disponibilidad, estabilidad y resiliencia.


Pruebas de estrés:  En el caso de ser pruebas realizadas a pequeña escala, en las que un usuario único ejecuta una aplicación web o una base de datos con sólo un puñado de registros, podrían no revelar problemas que suceden cuando la aplicación se usa en condiciones "reales".

Las pruebas de estrés buscan los límites funcionales de un sistema. Se realizan sometiendo el sistema a condiciones extremas, como volúmenes de datos máximos o una gran cantidad de usuarios y procesos simultáneos. También se utilizan para, una vez llevado el sistema al colapso, poder comprobar su funcionamiento continuado por encima de su límite y, una vez liberado de la carga, evaluar su capacidad de "resiliencia", volviendo a su estado óptimo de funcionamiento.


Pruebas de rendimiento:  Determinan la capacidad de respuesta, el rendimiento, la confiabilidad y/o la escalabilidad de un sistema bajo una carga de trabajo determinada.

En aplicaciones web, las pruebas de rendimiento, a menudo están estrechamente relacionadas con las pruebas de estrés, realizando comprobaciones como la medición del retraso y la capacidad de respuesta bajo una carga pesada. En otras aplicaciones (escritorio y aplicaciones móviles, por ejemplo), las pruebas de rendimiento miden, tanto la velocidad y la utilización de recursos, como el espacio en disco y la memoria.

Guardando convenientemente todos los resultados de las pruebas de rendimiento durante un plazo de tiempo, podremos conocer el estado de salud de la aplicación, pudiendo obtener tendencias y previsiones de funcionamiento; y optimizando cada despliegue según el rendimiento necesario en cada caso.


Pruebas de seguridad:  Validan los servicios de seguridad de una aplicación, e identifican posibles fallos y debilidades.

Muchos proyectos utilizan un enfoque de caja negra para las pruebas de seguridad, lo que permite a los expertos, sin conocimiento del software, probar la aplicación en busca de agujeros, fallos, exploit y debilidades.


Como véis, el "universo" de las pruebas es inmenso, siendo una de las ramas de la informática que requiere de una especialización específica.







No es lo mismo programar que escribir código


Es una opinión generalizada entre los profesionales del sector, el hecho de que existe una gran diferencia entre programar y codificar, en referencia al diseño y creación  de aplicaciones informáticas.

El acto de programar es más bien, organizar, planificar, y estructurar mediante algún tipo de metodología y algoritmos, la solución óptima a una necesidad o problema planteado. Y codificar es escribir código en un lenguaje informático, para dar instrucciones a un ordenador, para que realice las actividades requeridas, a ser posible de manera más rápida y eficiente.

Cuando decimos, vamos a programar, en realidad lo que estamos diciendo es, que vamos a organizarnos de la mejor manera para buscar la mejor solución antes de sentarnos frente a nuestro ordenador a escribir código, sin tener una base sólida de qué resultado queremos que ordenador nos devuelva, y que sea satisfactorio para nosotros.



Puntos importantes en el diseño de un programa


1º. Debemos analizar lo que nos pide el cliente, para no hacer más de lo necesario, aunque siempre es bueno que lo que hagamos tenga valor añadido. No se trata de hacer simple y "estrictamente y exactamente" lo que el cliente quiera, por que podría pedirnos "cosas imposibles", o totalmente fuera del presupuesto, no debemos hacer algo que no sirva adecuedamente al cliente, o no pueda pagar.

Somos nosotros los que tenemos los conocimientos, y seguramente podamos dotar de una mejor funcionalidad al software, que no nos haya solicitado el cliente, y que contribuya a un mejor funcionamiento posterior, con nuevas actualizaciones. El software debe estar abierto a futuras nuevas funcionalidades, y debe ser por lo tanto escalable, debe poder seguir "creciendo".


2º. Primero de todo, deberíamos centrarnos en que la solución “general” sea satisfactoria, y después de haber logrado el objetivo, preocuparnos entonces por la interfaz gráfica (GUI), ya que antes de "perder el tiempo" en que nuestro programa se vea bonito, debemos hacer que funcione correctamente. Y el que funcione no sólo implica que no tenga errores de compilación, sino que también que muestre los resultados reales de lo que se espera.


3º. Buscar todas y cada una de las validaciones y/o restricciones (qué se puede hacer, dónde y cómo) que se le puedan aplicar para que el usuario final no cometa errores que hagan que nuestro programa tenga fallos fatales como abandono inesperado del sistema o pérdida de información.


4º. Hacer un algoritmo preciso y detallado de los pasos que dan la solución.


5º. Hacer un diagrama de flujo que represente todos y cada uno de los pasos indicados en el algoritmo.


6º. Puede ser conveniente hacer un "pseudocódigo" (código escrito en base al lenguaje humano) que se utilizaremos (como referencia) para escribir luego el código de la solución al problema planteado.


7º. Utilizar el mejor lenguaje de programación, para escribir el código de la solución al problema. El mejor lenguaje de programación, no es el de la mejor tecnología, puede no ser el más actual, ni tampoco el de mejores propiedades, el mejor lenguaje para un programador, siempre es y seguirá siendo, el que uno como programador mejor domina y trabaja, ya que, bajo este simple concepto, no perderemos mucho tiempo en primero conocer el lenguaje, su sintaxis, y luego aplicarlo.

Aunque hoy en día esto es secundario, los desarrolladores y sus equipos conocen varios lenguajes distintos, ya que se componen de varias personas, especializadas en diferentes lenguajes, y en función del tipo de software, y cómo y dónde se va a ejecutar, será mucho mejor utilizar uno u otro, ya que cada lenguaje posee capacidades distintas, incluso se pueden usar diferentes lenguajes, en diferentes areas del software que estemos desarrollado.


8º. También deberemos estar muy atentos a la evolución posterior del programa que hemos desarrollado, para poder ofrecer una buena solución de mantenimiento posterior, (normalmente es en el mantenimiento donde está el verdadero negocio), cuando ya esté completamente operativo en el cliente.


9º. Deberemos también actuar como si fuéramos usuarios finales y así hacer todas y cada una de las pruebas necesarias al programa antes de entregarlo, y también se pueden escoger usuarios finales reales, y pedirles que utilicen el programa de la misma forma que lo harían posteriormente, cuando el programa estuviera implementado y operativo en su “entorno real”.


10º. En el caso de que alguna vez no podamos o sepamos encontrar una solución a un determinado problema, buscaremos siempre ayuda, preguntando, consultando a otros profesionales, y también, investigando en internet o en libros y publicaciones especializadas, ya que seguro que ese mismo problema (o uno muy similar) le ha ocurrido antes a alguien.





"That's all folks"...


Espero y deseo que os haya gustado. Ahora es vuestro turno si queréis hacer algún comentario...








Referencias


https://es.wikipedia.org/wiki/Proceso_para_el_desarrollo_de_software

https://es.wikipedia.org/wiki/Entorno_de_desarrollo_integrado

https://proyectosagiles.org/que-es-scrum/

https://openwebinars.net/blog/que-es-la-metodologia-agile/

http://blog.eltallerweb.com/diferencias-entre-ui-y-ux/

https://es.wikipedia.org/wiki/Lenguaje_unificado_de_modelado

https://foroalfa.org/articulos/que-es-ser-un-disenador-ux

https://crearsoftware.com/tag/resiliencia/

https://es.stackoverflow.com/

https://testingbaires.com/pruebas-caja-negra-enfoque-practico/

https://es.wikipedia.org/wiki/Refactorizaci%C3%B3n

https://blogthinkbig.com/cuantas-lineas-de-codigo-hay-en-windows-facebook-o-google

https://es.wikihow.com/ser-un-Beta-tester

https://pruebasalfaybeta.blogspot.com.es/

https://ing-sw.blogspot.com.es/2005/04/tipos-de-pruebas-de-software.html

http://www.monografias.com/trabajos36/pruebas-de-aceptacion/pruebas-de-aceptacion2.shtml

https://es.ccm.net/contents/223-ciclo-de-vida-del-software



dana patricia 5/7/2018 · #45

Hola
oferta de préstamo de dinero entre los individuos
Póngase en contacto conmigo por correo electrónico: dominiquemirada@hotmail.com
Ofrecemos simple, rápida y fiable monetario préstamos que van desde 4.000 Euros a 3,500,000 Euros para serios y honestos de la gente que necesita el dinero a una tasa de interés anual de 2%. Para obtener más información, póngase en contacto conmigo por correo electrónico: dominiquemirada@hotmail.com

0
Lily Hq 4/7/2018 · #44

hello, Federico, I don't know you, if you know me, please write down, where and when, and can you introduce yourself? what is the relationship between you and @Larry Boyer, 🐝 Brand Ambassador.? ( https://www.bebee.com/bee/larryboyer?t=posts )

and please write down any question and opinion about my comments. :-)

P.S I pasted your comment from there ( https://www.bebee.com/bee/larryboyer?t=posts ) to here

"These comments can only be deleted by the author of the content comments. It's spam. We report it Thank you very much."

0
Fran 🐝 Brizzolis 3/7/2018 · #43

#42 Gracias tod@s por la gran acogida, nunca imaginé que fuera a tener tantas lecturas... Sois muy muy grandes!

+2 +2

Recuperamos esta miel tan buena. Gracias Fran!

+1 +1

Médico/Psiquiatra/Psicológo/mestreDoutor/Bacharel em Ciências Aeronáuticas/General de Divisão do exercito Brasileiro da Reserva

Experiência (18 anos)
mecanico de motos
em marcelo motos
dezembro de 2000 - Atualmente (17 anos 7 meses) Mato Grosso do Sul
Jose Marcelo Pereira Moreira - 22450930000180
CNPJ: 22.450.930/0001-80
Razão Social: Jose Marcelo Pereira Moreira
Nome Fantasia:
Número: 414
Bairro: Santo Antonio
Município: Barra do Garcas
UF: MT
Contatos
Telefone: (66) 9237-9710

-4 -4

#39 Hola William. Pues buscar ofertas de empleo en la sección de Empleo. Además puedes completar tu perfil y crear contenido relacionado con tu sector, para tener más oportunidades profesionales :)

+2 +2
William Suarez 2/7/2018 · #39

Hola me llamo William y busco trabajo en la minería,tengo licencia b y soy soldador y plomero,disponibilidad inmediata 

-1 -1
Fran 🐝 Brizzolis 10/5/2018 · #38

Gracias por compartirlo chic@s! Me alegro de que os haya gustado tanto... Un fuerte abrazo.

0