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

¡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.

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