Mi código funciona, ¿puedo publicar ya? – Tests y test de aceptación.
La respuesta a la pregunta del título es clara: NO. Antes de la publicación, el producto/software debe haber pasado unos tests para que sea apto para su uso. En este artículo veremos que los tests tienen un lugar muy importante en el desarrollo del software pero de alguna manera son considerados como una tarea tediosa y poco atractiva de realizar. Tienen motivos para que tengan esa mala fama, pero también veremos que no todos los tests son tan temibles como nos hacen ver. Existen numerosos tipos de procesos en el desarrollo de software y a su vez, para cada proceso, existen diferentes tipos de test. Por ejemplo, según la metodología (estáticas o dinámicas), modo de ejecución (manuales o automáticas) o dependiendo de lo que se quiera verificar en la fase del desarrollo del software (funcionales o no funcionales). Estas solamente son agrupaciones grandes (y no se han mencionado todas) y cada una de ellas se puede dividir en subgrupos y niveles para realizar todo tipo de pruebas para que el software, como mínimo, funcione. Enfocándose por niveles de tests se puede hablar de 4 grandes niveles: test unitario, test de integración, test de sistema y test de aceptación. Por los nombres y el orden de enumeración se puede deducir que los niveles van de menor a mayor complejidad. Los test unitarios comprueban el correcto funcionamiento de los elementos (clases y/o métodos) de un sistema (software como producto final). En los tests de integración se comprueba si los elementos que funcionan correctamente por separado siguen funcionando cuando se ensamblan. Es decir, de nada sirve que hayan aprobado los tests unitarios si al hacer la integración de cada unidad no pasa el test de integración. Esto no solo afecta al desarrollo de software, ya que podemos encontrarnos casos donde el test de integración no ha sido superado. La imagen es un claro ejemplo de lo que se acaba de describir: dos módulos que funcionan correctamente por separado pero el resultado al integrarlos no es el deseado: 
Continuando con los tests de sistema, estos sirven para comprobar si el sistema totalmente integrado como producto final, cumple con todos los requisitos. Por último, los tests de aceptación son los que se realizan antes del lanzamiento del producto, probando todo el sistema o producto en un entorno y condiciones lo más parecidos a los de producción posibles. Dentro de este nivel también existen dos sub-tipos, los tests de aceptación de operación (OAT) y de usuario (UAT). Los tests de aceptación de operación son pruebas no funcionales, básicamente se enfocan en si el software es capaz de funcionar en el sistema o en el entorno de producción, mientras que las pruebas de aceptación de usuario se dedican a comprobar el cumplimiento de los requisitos de la funcionalidad del software que se había acordado en la planificación. Para finalizar, vamos a ver un pequeño ejemplo de la estructura de un test de aceptación de usuario. Las pruebas para test de aceptación de usuario se preparan con un lenguaje de alto nivel, a ser posible por los usuarios finales que no tienen porqué estar al tanto del proceso de implementación, si no de verificar si cumple con las funcionalidades de las especificaciones y/o requisitos establecidos, como se ha comentado anteriormente. El lenguaje que se utiliza para los tests de aceptación se llama Gherkin, y existen varios intérpretes de este lenguaje, el más famoso de todos es Cucumber escrito en Ruby, y otros como Jasmine para JavaScript, Concordion para Java, Kahlan para PHP, o Behave para Python, que es el utilizado en los ejemplos de código siguientes. 
Vamos a detallar los elementos que aparecen en la figura anterior. Feature sería el título y la descripción del test que se está realizando, Scenario describe un caso concreto que se quiere probar, es decir, cada funcionalidad donde interactúan el usuario y el sistema sería un escenario. En el escenario se describen las precondiciones, el evento y su resultado, estos se definen con las palabras Given, When y Then. And es otra palabra dentro del escenario que puede ir en diferentes partes del mismo y dependiendo de dónde se ubique, añade mayor descripción. El escenario habrá pasado el test cuando ocurra el evento (When the user books 1 videocall), dadas ciertas precondiciones (Given a new user registered with username foo@bar.com And has 3 free videocalls) y cumpla con el resultado conocido de antemano (Then the user has 2 free videocalls left). Abajo se muestra el resultado del test en Behave: 
Como se puede observar, Gherkin ayuda a que el test sea con un lenguaje natural, conciso y fácil de entender, a diferencia de otros tipos de test de más bajo nivel y para personas o equipos con conocimiento técnico. En resumen, aunque los tests parezcan pesados y poco llamativos por su extensa variedad, cada uno de ellos cumplen una función, y que aunque parezcan independientes entre unos y otros, están ligados de un nivel al próximo para garantizar el correcto funcionamiento del software, por lo que merecen que se les dé más atención y dedicación. Además, sabiendo que existen tests más amigables se puede hacer partícipe tanto a personal técnico como a no técnico en el desarrollo de software y control de calidad, ya que ambos roles juegan un papel muy importante como usuario final. 
Continuando con los tests de sistema, estos sirven para comprobar si el sistema totalmente integrado como producto final, cumple con todos los requisitos. Por último, los tests de aceptación son los que se realizan antes del lanzamiento del producto, probando todo el sistema o producto en un entorno y condiciones lo más parecidos a los de producción posibles. Dentro de este nivel también existen dos sub-tipos, los tests de aceptación de operación (OAT) y de usuario (UAT). Los tests de aceptación de operación son pruebas no funcionales, básicamente se enfocan en si el software es capaz de funcionar en el sistema o en el entorno de producción, mientras que las pruebas de aceptación de usuario se dedican a comprobar el cumplimiento de los requisitos de la funcionalidad del software que se había acordado en la planificación. Para finalizar, vamos a ver un pequeño ejemplo de la estructura de un test de aceptación de usuario. Las pruebas para test de aceptación de usuario se preparan con un lenguaje de alto nivel, a ser posible por los usuarios finales que no tienen porqué estar al tanto del proceso de implementación, si no de verificar si cumple con las funcionalidades de las especificaciones y/o requisitos establecidos, como se ha comentado anteriormente. El lenguaje que se utiliza para los tests de aceptación se llama Gherkin, y existen varios intérpretes de este lenguaje, el más famoso de todos es Cucumber escrito en Ruby, y otros como Jasmine para JavaScript, Concordion para Java, Kahlan para PHP, o Behave para Python, que es el utilizado en los ejemplos de código siguientes. 
Vamos a detallar los elementos que aparecen en la figura anterior. Feature sería el título y la descripción del test que se está realizando, Scenario describe un caso concreto que se quiere probar, es decir, cada funcionalidad donde interactúan el usuario y el sistema sería un escenario. En el escenario se describen las precondiciones, el evento y su resultado, estos se definen con las palabras Given, When y Then. And es otra palabra dentro del escenario que puede ir en diferentes partes del mismo y dependiendo de dónde se ubique, añade mayor descripción. El escenario habrá pasado el test cuando ocurra el evento (When the user books 1 videocall), dadas ciertas precondiciones (Given a new user registered with username foo@bar.com And has 3 free videocalls) y cumpla con el resultado conocido de antemano (Then the user has 2 free videocalls left). Abajo se muestra el resultado del test en Behave: 
Como se puede observar, Gherkin ayuda a que el test sea con un lenguaje natural, conciso y fácil de entender, a diferencia de otros tipos de test de más bajo nivel y para personas o equipos con conocimiento técnico. En resumen, aunque los tests parezcan pesados y poco llamativos por su extensa variedad, cada uno de ellos cumplen una función, y que aunque parezcan independientes entre unos y otros, están ligados de un nivel al próximo para garantizar el correcto funcionamiento del software, por lo que merecen que se les dé más atención y dedicación. Además, sabiendo que existen tests más amigables se puede hacer partícipe tanto a personal técnico como a no técnico en el desarrollo de software y control de calidad, ya que ambos roles juegan un papel muy importante como usuario final. 
Configuración de cookies