La importancia de incorporar pruebas a tu proyecto.

Standard

Buen día, hoy quiero hablarles de nueva cuenta de un tema que creo que la mayoría del tiempo no tomamos en serio y deberíamos.  Anteriormente ya había hecho comentarios del uso de pruebas, pero debido a que en mi experiencia, la mayoría de las personas termina diciendo “pues suena bien, pero ahorita no tenemos tiempo”, “ahorita no es prioridad”, etc.

Lo que vengo a compartirles ahora es más que cosas técnicas, son experiencias de la importancia de implementar pruebas y como pudieran empezar.

Para empezar, mi primer recomendación es implementar CUALQUIER tipo de prueba. Aunque esto suene algo simplista y “lógico”, realmente creo que como siempre, dar el primer paso es lo más importante, les explico ahora porque.

En caso de que no tengamos pruebas “formales” y que hagamos las “pruebas” como según yo, la mayoría de programadores las hacemos cuando no tenemos la costumbre, y que consiste en probar en nuestro ambiente de desarrollo la funcionalidad que vamos programando. Pero esto nos trae una serie de problemas:

  • Probamos sólo los escenarios “happy path” o ideales, dejando muchas veces de lado, escenarios que pudieran presentarse y que se salen de lo que es el flujo normal.
  • Dos cerebros son mejor que 1, siempre que hacemos pruebas en solitario corremos el riesgo de pasar por alto detalles, por ejemplo, en un formulario, tal vez no validamos que el nombre de un producto no sea vacío o que no acepte caracteres especiales o incluso que tenga limites de longitud. Si tenemos a otra persona que nos apoye con las pruebas, es más fácil que esta persona nos pregunte porque no se han validado dichos campos. Otro ejemplo es que, si es alguien con algo de experiencia en desarrollo o testing, va a mover de manera random a los controles, tratando de provocar errores, con lo cual podemos cubrir más escenarios.
  • Siempre es mejor que el usuario pruebe durante el desarrollo, esto lo cuento porque siempre será importante si queremos evitar el re-trabajo en producción, tener otra persona que funja como el usuario y haga pruebas que sólo un usuario se le ocurriría. Un ejemplo de esto es una validación de un campo que para el usuario era evidente, pero nunca se mencionó. Esto lo podemos evitar fácilmente pidiéndole que realice pruebas mientras estamos desarrollando esa funcionalidad y no ya que esté en producción.
  • Otro problema de hacer sólo pruebas “locales” es que, puede que desconozcamos algo del ambiente en servidor que nos afecte, por lo cual, siempre hacer pruebas en un ambiente real, o igual al real será muy útil.
  • Por último, normalmente si hacemos este tipo de pruebas personales, no tendremos una manera real y objetiva de evaluar el desarrollo que estamos utilizando.

Ahora, ¿Por qué digo que “cualquier tipo de prueba” es buena?

Para empezar, pues bien, esto se debe a algo muy sencillo. Pregunta a tu equipo o a ti, ¿por qué no implementamos pruebas?, la mayoría de respuestas son como las que puse anteriormente, que normalmente se basan en que “consumen tiempo” o simplemente “por pereza”. Si estas son las razones principales, pues la idea de empezar con cualquier tipo de prueba es que elijas la más cómoda de implementar para que no tengas estos pretextos. Por eso “cualquier tipo de prueba” que hagas es buena, sólo te voy a hacer las siguientes recomendaciones.

  • Dentro de lo posible, que el desarrollador y el tester sean dos individuos y no uno, básicamente, que el desarrollador sea uno y el tester otro, esto es muy evidente el porque, y es para que las pruebas sean más objetivas.
  • Agrega las pruebas como una tarea que tiene que realizarse ANTES de liberar cualquier código. Ej. si tienes un catálogo de productos, este no debiera considerarse como terminado si no se han realizado sobre el las pruebas correspondiente.
  • Define criterios de aceptación, esto se debe a que con estos, tienes de manera clara, qué tienes que probar y que resultado deben generar dichas pruebas.
  • Lleva un registro de los hallazgos producidos por las pruebas con el fin de aprender de los errores.

Pues bueno, ahora si les van un par de experiencias que he tenido con pruebas y como nos han servido para mejorar.

La primera historia es sobre in proyecto que hice hace algún tiempo, en este proyecto éramos un par de freelancers que teníamos un proyecto pequeño. En ese entonces no conocía realmente el tema de las pruebas, y mi compañero estaba por las mismas. De la misma manera no utilizábamos ni repositorios ni nada de lo que debíamos (“estábamos muy verdes”), y confiábamos mucho en el otro, obviamente nunca probamos nada de lo que hacía el otro, hasta el momento de integrar. Y ¡oh sorpresa!, todo fallaba y estaba lleno de bugs o de funcionalidad incompleta. Esto fue porque como siempre se dice “es más fácil criticar a otro que a si mismo”, y vaya que es cierto. Yo encontraba miles de fallas y detalles tanto en su código como en su funcionalidad y el encontraba miles en lo que yo había hecho. Al final esto nos hizo agregar 1 mes completo para revisar todo el proyecto y hacer pruebas y dejar algo aceptable. Dicho tiempo seguramente hubiese sido mucho menor y nos hubiéramos evitado muchos disgustos de haber realizado pruebas cruzadas durante el desarrollo y no hasta el final y como el tiempo es dinero, podemos decir que el no hacer pruebas “nos costó” 1 mes de trabajo.

Pues bien esta pequeña historia me enseñó mucho, y tal vez crean que aprendí bien la lección, obviamente no, tiempo después me tocó estar en otro proyecto donde nos fue un poco peor. Tuvimos un desarrollo de algo más de medio año, donde no se consideraron pruebas de ningún tipo, por lo cual como se imaginarán, la historia se repitió pero de una manera más triste, en esta ocasión no había muchos bugs y la aplicación “parecía funcionar de manera adecuada”, pero!!!, resultó que no, mucha de la funcionalidad no estaba implementada correctamente o que faltaba mucho desarrollo de tras de algo que “aparentaba estar funcionando” pero como nunca programamos pruebas ni realizamos pruebas en pares, etc. Al final el equipo no estaba consiente del retraso que había. Pero no todo fue triste, de esta experiencia que costó esos 6 meses de trabajo aprendimos, o mejor dicho ASIMILAMOS la importancia de hacer pruebas, nos dimos cuenta de lo siguiente:

  • Las pruebas te ayudan a capturar funcionalidad (Cada prueba tiene como objetivo validar que se cumpla una funcionalidad, por lo cual te sirven al mismo tiempo como documentación de requerimientos).
  • Las pruebas te ayudan a aumentar la calidad, cuando empiezas haciendo pruebas, terminas dándote cuenta de validaciones que debieran ser estándar, lo cual provoca con el tiempo una mejora continua.
  • Las pruebas (sobre todo las automatizadas) te ayudan a validar que TODA la funcionalidad se cumpla y que un cambio no afecte otra parte de la aplicación, y en caso de que sea así, te permite identificarla de manera más ágil.
  • Las pruebas “no cuestan, ahorran”, aquí basta con “hacer la prueba”, implementa pruebas en un proyecto y verás los beneficios en comparación de otro proyecto que no las implemente.
  • Las pruebas pueden prevenir vergüenzas con el cliente, esto es evidente, entre mejor se pruebe la aplicación, menor es la probabilidad de que se presente un bug con el usuario/cliente, lo cual siempre será bueno para tu negocio.
  • Las pruebas no son una moda, son una herramienta necesaria para garantizar la calidad.
  • Da más pereza y estrés reparar errores en producción que llevar a cabo pruebas durante el desarrollo.

Con estas experiencias que he tenido, lo que busco es transmitirles lo importante de implementar pruebas durante tu desarrollo, actualmente nuestros equipos incluyen pruebas durante todos sus desarrollos, y ellos mismos se han dado cuenta de los beneficios de llevar a cabo las pruebas.

Espero y esto les empuje un poco a incluir las pruebas como parte de su desarrollo y descubran sus beneficios, si necesitan sugerencias o tienen dudas de como comenzar, será un placer apoyarlos.

Sin más por el momento me despido, Saludos.

 

Leave a Reply

Your email address will not be published. Required fields are marked *