TESTING ; EL ARTE DE DESTRUIR EL SOFTWARE.

La naturaleza tiene perfecciones para demostrar que es imagen de dios e imperfecciones para probar que sólo es una imagen.  Blaise Pascal

 

El primer artículo de este nuevo y  maldición sí que va rápido este año. Es por eso que no debemos perder el tiempo y avanzar a la siguiente versión. Atrás en el tiempo hablamos de las versiones y lo importante que es etiquetar las nuevas mejoras de tu software. << Debo leerlo >>. Pues bien la pregunta ahora es quien te garantiza que tu nueva versión funciona y si la respuesta a esto es. Yo mismo me garantizo; déjame decirte que estás haciendo las cosas mal.

El Testing de Software es toda una disciplina en la ingeniería de software que permite tener procesos, métodos de trabajo y herramientas para identificar defectos en el software alcanzando un proceso de estabilidad del mismo. Este concepto nace por halla en los años 60’s y  fue a partir de la crisis del desarrollo del software. Tan mal estaba en ese tiempo.

Hoy en día el testing de software es un proceso ya incrustado en el desarrollo de software pero aunque muchos saben que existen pocos lo implementan como tal. El primer error que se comete es que el que hace le tester es el mismo programador. Las pruebas unitarias se hacen en base a lo que él sabe que no va a fallar por lo tanto no se tiene el panorama completo de la situación real de sistema o programa que se está desarrollando.

Testing se hizo para destrozar el programa, así que es catalogado como un proceso destructivo . Y en junglaCODE, creemos que las implementaciones a producción son cosas del diablo. Y aplicamos la ley de morphy. Así que tratamos de explotar todos los errores antes de pasar a productivo.

Como empezar

Debemos entender que para empezar a testear debemos tener bien definidos los requerimientos Funcionales y no funcionales. Una vez teniendo la base hay un proceso que junglaCODE usa:

  1. Análisis de Requerimientos
  2. Identificación de funcionales interactivas.
  3. Definir criterios de aceptación
  4. Probar
    1. Procesos internos “dentro del código”
    2. Procesos externos “En las interfaces”
  5. Backlog de Issues de errores.
  6. Análisis de entornos de implementación
  7. Probar funcionalidades interactivas.
  8. Backlog de Issues de mejoras.

Para este proceso se tienen de muchas técnicas las cuales usamos en cada proceso.  Entre ellas se encuentran.

Toda una tarea creativa y llena de desafío intelectual. Con un solo objetivo buscar y destuir.

Recomendaciones

http://disenio.frm.utn.edu.ar/files/El%20arte%20de%20probar%20el%20software_0.pdf

https://sites.google.com/site/metodologiareq/capitulo-ii/tecnicas-para-identificar-requisitos-funcionales-y-no-funcionales

https://apiumhub.com/es/tech-blog-barcelona/tecnicas-de-testeo-de-software/

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *