El impacto que generan las pruebas inadecuadas de software

Cuando se desarrolla software es erróneo pensar que las pruebas deben dejarse hasta el final para determinar el funcionamiento correcto y calidad del producto. Los errores de software no se limitan a aparecer únicamente en la fase de desarrollo sino también en el levantamiento de requerimientos,  análisis, diseño e  implementación.  Y desde luego, mientras más tiempo transcurra hasta que se detecte el error más costoso será solucionarlo.

El mal diseño de un sistema, la falta de estándares y procedimientos, aunado a la poca importancia que las empresas le dan al testeo de sus productos desemboca en la generación de software defectuoso. Tal parece que la industria se encuentra muy relajada al respecto.

En la presente entrada no pretendo explicar estándares y metodologías para llevar a cabo pruebas de software, (Si bien se mencionarán) sino destacar la poca importancia que se le da a dichas prácticas y por lo tanto el impacto que generan.

Luis Vinicio León, director general de e-Quality , empresa especializada en pruebas de software, menciona que en nuestro país, la gran mayoría de las veces son los programadores quienes realizan las pruebas en lugar de que lo haga un equipo de testers a quienes se les pague únicamente por ello. Resulta irónico ser juez y parte al mismo tiempo, más sin embargo así se trabaja, es una realidad.

En el peor de los casos tales pruebas ni siquiera llegan a hacerse y al programador le basta con que su aplicación compile y que el usuario final funja como tester.

Estas malas prácticas, en conjunto, siempre concluyen en contingencias en las organizaciones, problemas de operatividad, fiabilidad y desde luego en desconfianza por parte del cliente para con la herramienta de software.

Quienes nos encontramos trabajando en la industria de T.I. seguramente podríamos listar varias situaciones que hemos presenciado a causa de fallos en los sistemas y por lo tanto hemos tenido que involucrarnos en la solución del problema, asegurar que no vuelva a ocurrir y en tratar de calmar y explicar a los usuarios lo ocurrido (Que resulta una de las cuestiones más difíciles) ya que siempre que un error de software sale a la luz y afecta la operatividad e información de la empresa, representa un costo para el negocio, significa tener que recapturar datos, repetir procesos, etc., lo cual estresa a todos.

 Existen casos muy sonados a nivel mundial donde los errores y fallos en los sistemas han sido protagonistas:

-En 1985 un equipo médico llamado Therac-25 a causa de un error de software emitió radiaciones letales a los pacientes matando al menos a tres personas mientras que otras más quedaron heridas.

-En 1998 la onda espacial Mars Climate Orbiter que fue enviada a Marte para recolectar información y transmitirla a la Tierra, una vez que arribó a dicho planeta se perdió comunicación con el satélite ya que se destruyó. Posteriormente se concluyó que tal inconveniente se debió a un problema de compatibilidad entre las unidades de medida utilizadas en el software.

-En 2003 una parte de Estados Unidos y Canadá se quedaron sin electricidad por más de 7 horas y en algunos lugares hasta por días. La causa del apagón fue una falla en el software de alarma del control de energía.

-En 2014 uno de los bancos de Escocia fue multado con 56 millones de libras esterlinas luego de que por un error de sistema se bloquearan las cuentas bancarias de al menos 6 millones y medio de clientes.

Estados Unidos informó en el año 2015, en la encuesta Statista que el 43% de los errores en la información es a causa de software mal probado; inclusive en años anteriores reportó que la pérdida del 1% (60 mil millones de dólares) del PIB se debió a la mala calidad de los sistemas utilizados.

 ¿Cómo lograr entregar al cliente un software de calidad?

Los datos anteriores demuestran la forma en que llegan a impactar las malas o nulas pruebas de software; por lo tanto es de suma importancia que desde el inicio del proyecto, es decir, desde que se hace el análisis y el levantamiento de los primeros requerimientos con los usuarios, se establezca un proceso de pruebas y se adopte durante todo el ciclo. Desde luego es preferible que un tester lleve a cabo tal tarea y que no sea visto como villano sino todo lo contrario.

El estándar internacional ISTQB (International Software Testing Qualifications Board) establece una serie de principios que pueden aplicarse para llevar a cabo pruebas de software, las cuales menciono a continuación:

• Las pruebas demuestran la presencia de errores: Llevar a cabo testing y no identificar errores no significa que tu código esté libre de ello.   
• No es posible probar todo el desarrollo: Resulta complicado hacer pruebas integrales de todas las opciones y procesos del sistema, puede haber miles de condiciones; en su lugar priorízalas y ve probando en orden de riesgo e importancia.
• Comienza con el testing cuanto antes: Si las pruebas se hacen desde las etapas más tempranas será más fácil y barato corregirlas y así te aseguras de que no se irán “arrastrando” a otras etapas.
• Los errores siempre se agrupan: Una vez que detectes algún detalle en tu código es seguro que enseguida de éste haya otro ¡Revisa con minuciosidad!
• La paradoja del pesticida: Si ejecutas siempre las mismas pruebas de software disminuirás únicamente aquellos bugs para los cuales fue hecha la solución pero dejarás intactos aquellos que tu método no es capaz de detectar. Entre más variabilidad mejor.
• La prueba depende del contexto en el que se aplica: Ningún desarrollo es igual a otro, por lo tanto no te empeñes en generar el mismo testeo de una aplicación para móviles en un desarrollo de escritorio.
• ¿Asumes que tu software está libre de errores? ¡Cuidado!: El hecho de que tus usuarios estén satisfechos con el funcionamiento y estabilidad del sistema no significa que ya no haya ningún error oculto por ahí. Todos los desarrollos los tienen y de momento tendrás más tiempo para identificarlos.

“La calidad de un producto de software
depende de la calidad del proceso que lo
genera.”

 Watts Humphrey.

Hasta la próxima entrada, saludos.

Imágenes tomadas de freepik.com

Consejos Básicos para Implementar Software ERP

Los sistemas ERP (Enterprise Resource Planning) han venido evolucionando a raíz de sistemas antecesores como MRP (Planeación de la Capacidad de Materiales), MRP II, MES (Manufacturing Execution Systems) entre otros y desde luego, a partir de la demanda de las empresas.

A principios de la decáda de los 90’s surgió la necesidad de automatizar los sistemas de manufactura que operaban en las organizaciones, ya que requerían una amplia intervención del usuario para su funcionamiento; fue así como surgió el desarrollo y la implementación de los sistemas ERP, aunque al principio no todo fue miel sobre ojuelas. Había que enfrentarse a una nueva tecnología ante la cual tanto los consultores de T.I. como las empresas carecían de experiencia y además los vendedores de software no conocían del todo el producto. Imagínese usted la cantidad de implementaciones problemáticas que se debieron haber suscitado.

Con el paso del tiempo estos acontecimientos mejoraron visiblemente pero no significa que hoy día todas las implementaciones de software sean exitosas. Existe una gran cantidad de cuestiones que atender de parte del negocio y de los consultores involucrados en el proyecto con el fin de lograr los resultados deseados, es por eso que en esta ocasión te comparto, en base a mi experiencia, algunos consejos que puedes aplicar antes, durante y después de una implementación de software. Aplican tanto si eres el líder del proyecto o el consultor que se encargará de guiar la implementación de la tecnología.

1. Entender al negocio

Las empresas buscan un sistema de información que cubra sus necesidades, se adapte a su giro, a sus procedimientos  y principalmente, al menos en México, que cumpla con las obligaciones propuestas por la autoridad (Facturación, Contabilidad y Nómina Electrónica), es por ello que el primer paso es identificar la herramienta correcta, aquella que pueda ajustarse a lo que realmente requiere el negocio. Analiza si conviene adquirir un software empaquetado (Que ya sea comercial y se use en otras industrias) o si desean un desarrollo a la medida (Un sistema único y creado especialmente para la empresa). Para ello:

 * Investiga y compara distintos sistemas y proveedores.

 *  Identifica casos de éxito o de fracasos que hayan tenido con otras empresas.

 * Lista todas las necesidades del negocio y pregunta al asesor si su sistema cumple con ello o   bien,      que tan complicado sería que se desarrollara de acuerdo a como lo ocupan.

 * Solicita demostraciones del sistema (Durante la demo pregunta, pregunta mucho).

 * Si eres el desarrollador o el consultor sé sincero acerca del alcance del sistema y si éste se adapta al giro de la empresa. Más vale ser honesto desde el inicio en lugar de implementar una herramienta que no encaja con la naturaleza del negocio y se fracase en el intento.

2. Definir un plan de trabajo realista

Una vez que se tiene claro el sistema que se implementará se debe definir un plan de trabajo entre dirección general, líder de proyecto y asesores. No propongas ni estimes tiempos que no puedan cumplirse y trata de incluir ciertas holguras entre los entregables ya que siempre ocurren situaciones que atrasan la implementación del proyecto. Te recomiendo que el plan de trabajo se apegue a la metodología que proponga el consultor ya que es la persona quien conoce los pasos que deben seguirse, pero las fechas y entregables acuerdenlas en conjunto.

3. Mentalizar al personal sobre el cambio

Algo escencial para que una implementación de sofware sea exitosa es contar con la aceptación y visto bueno de parte de todos los involucrados (Directivos, líder de proyecto, jefes de área y usuarios finales). Desde el inicio se debe motivar al personal, hacer equipo con todas las áreas y asegurar su compromiso.

Siempre existirán personas renuentes al cambio que están costumbradas a trabajar en una misma tecnología desde hace años y la idea de cambiar de herramientas de trabajo los aterra tanto que se muestran poco accesibles; prepárate para escuchar la frase “Es que en mi sistema anterior…”

La clave es identificar de inmediato a esas personas con el propósito de platicar con ellos, explicarles los beneficios que se adquirirán con el nuevo software, mostrarles casos de éxito y ganar su confianza; Si ya intentaste de todo y la mala actitud no cambia, me apena informarte que esas personas representan un riesgo para el proyecto y lo más sano es separarlas.

"No hay nada más difícil de llevar a cabo, de éxito más dudoso y de manejo más peligroso, que el iniciar un nuevo orden de cosas. Pues el reformador tiene enemigos en todos los que se benefician con el viejo orden, y tibios defensores en todos los que se beneficiarían con el nuevo orden".

                                                                                                                          El Príncipe, Maquiavelo. 

4. Conocer los procesos del negocio, mejorarlos, estandarizarlos ¡Y documentarlos!

El inicio de una implementación de software representa múltiples ventajas para una empresa ya que no solo se buscará agilizar las actividades que se llevan a cabo sino también conocer a detalle qué se hace, cómo se hace, para qué se hace, cómo se controla, a quién(es) se le reporta y cómo se puede mejorar.

Llevar a cabo un buen diagnóstico previo al arranque te permitirá encontrar una respuesta puntual a cada una de las preguntas anteriores. Date el tiempo suficiente para conocer cómo funciona el negocio, de esa forma podrás identificar áreas de oportunidad para ir atacando poco a poco.

Entrevista a los usuarios sobre sus funciones y procedimientos, solicítales ejemplos, reportes, etc., todo lo que consideres útil. Reúne a responsables de las áreas involucradas para que puedas escuchar un sentir común y puedas comprenderlos mejor. Sugiere y acuerden mejoras (Aprovechar el arranque para depurar información también es muy importante) y por favor, considera documentar dichos procesos desde el inicio del proyecto. De esa manera se definen con exactitud los pasos que se deben seguir para llevar a cabo una actividad, minimiza confusiones, se fomenta la mejora continua y cuando se integre una nueva persona al proyecto ahorras tiempo y dinero porque ya se cuenta con una herramienta que explica a detalle los procesos de negocio.

5. Asegurarse de que todos comprenden lo que deben hacer y cómo lo deben hacer

Las reuniones con todos los involucrados en el proyecto de implementación son fundamentales. En ellas se definen nuevas formas de trabajo así como los catálogos y datos que requiere el sistema para arrancar (Productos, clientes, proveedores, saldos iniciales, etc.).

Acuerden nomenclaturas de codificación de la información, fijen fechas de entrega y responsables por área y módulo. Una vez que se tengan listos los catálogos revisa que la información es correcta y su estructura es tal cual como se definió, de lo contrario no capturen nada en el sistema hasta que se haya corregido (Creeme, te ahorrará muchos problemas).

Cuando se capacite a los usuarios en el uso del sistema asegúrate de que comprenden las opciones y funcionamiento de los módulos, así como los pasos que deben seguir para llevar a cabo sus actividades; al final de la sesión realiza una bitácora acerca de lo que se explicó y pide que la firmen así queda la evidencia de que la explicación se dio (Son muy comunes los comentarios “No recuerdo que me lo hayan explicado, por eso no lo hice, porque no sé como funciona”).

Facilítales manuales de usuario y la confianza para que puedan preguntarte sobre las dudas que tengan aún después de las capacitaciones.

6. Hacer un plan post implementación

Una vez que el negocio ya se encuentra trabajando con el nuevo sistema no significa que la relación Empresa-Consultor deba terminar, al contrario, existen puntos que durante el proceso de implementación no son tan urgentes pero sí importantes y que siempre quedan en veremos y la fase post implementación es ideal para poder aterrizarlos.

En esta fase busca reunir requerimientos adicionales y funcionales, centrarte en áreas específicas, resuelve dudas de los usuarios y refuerza controles. Al final de cuentas el ciclo de vida del software se trata de un proceso iterativo y se puede comenzar cuantas veces se considere necesario aunque claro, con la certeza de generar valor al negocio y con entregables que lo demuestren.

Consejos Generales

• Asegúrate de comprender las necesidades y dolencias de la organización.
• Apégate a una metodología.
• Entrega documentos sobre el avance del proyecto periódicamente, manten a dirección muy bien informado (No olvides incluir limitantes y riesgos del proyecto).
• Recuerda: Ninguna implementación es predecible e igual a otra.
• Paciencia, no todas las empresas están preparadas para el cambio.

     ¡Hasta la próxima entrada!

      

      Saludos.

      

      Ing. Guadalupe López

h      Fuente imagenes: freepik.com