En el entorno de testing automático E2E* a lo largo de los años se han dado a conocer muchas tecnologías para su desarrollo tanto por el mismo equipo de Flutter como de desarrollo externo por parte de comunidades que ven el potencial de la herramienta.

Hoy veremos una herramienta de este último grupo, Maestro.

*(End To End, donde de forma resumida se prueba como QA desde el punto de vista de un usuario el recorrido de un punto X a un punto Y de la aplicación).

Sobre el testing automático en Flutter

Para decidir si nos decantamos por una tecnología u otra a la hora de automatizar los casos de prueba de nuestra aplicación, primero debemos comprender bien qué es exactamente el “testing automático en flutter”.

Centrándonos en el “end to end”, flutter nos ofrece la librería flutter_test y bdd_widget_test. Dos herramientas que, ubicándose dentro de la aplicación que estamos desarrollando con el total acceso a los distintos widgets, páginas y líneas de código nos ofrece un gran control de todo lo que ocurre dentro de ella y es la solución número uno para el testing unitario en flutter.

También ofrecen compatibilidad con Cucumber, haciendo de nuestro testing algo mucho más legible para usuarios no tan técnicos gracias al lenguaje Gherkin que ofrece.

Si bien ofrece todo esto, si que hay que tener en cuenta algo ineludible. El gran conocimiento que requiere del tester sobre flutter, las librerías antes mencionadas y Cucumber, que suele ser la gran montaña a escalar a la hora de afrontar el QA de nuestro proyecto.

Y para solucionar esto entra Maestro en juego.

Maestro, efectividad en la simplicidad

Escrito en base a Appium, Espresso, UIAutomator y XCTest entre otros, mediante el llamado “Flow” (La definición de los pasos del usuario en la aplicación) ofrece un testing que de forma muy sencilla e inmediata nos permite empezar a correr tests donde sea, ya que no es inherente al proyecto sino una ejecución externa.

Esta ejecución ocurre a través de un formato .yaml (un lenguaje pensado para la fácil lectura y escritura para personas sin conocimientos extensos en términos técnicos).

Está diseñado de una forma la cual, a través de los comandos que ofrece puedas de manera sencilla no solo detectar cualquier emulador que se esté reproduciendo en pantalla sin necesidad de vincular nada, también de encontrar de manera rápida los distintos widgets que nos hagan falta para completar el recorrido deseado para el test.

Para compensar la falta de compatibilidad con el modelo POM y Cucumber, Maestro ofrece la posibilidad de organizar una estructura de ejecuciones anidadas unas llamado “Nested flows”. Con la ayuda del comando “runFlow”, que, siempre que la anidación sea correcta, nos permite ejecutar archivos de Maestro por separado, lo que facilita enormemente a la reutilización de código y la posibilidad de organizar una estructura fácil de comprender y manejar.

En profundidad sobre Maestro, sus ventajas y desventajas.

Simpleza demasiado simple

A la hora de ahondar en Maestro vemos que de un rápido vistazo ya hemos visto todo, y esto es bueno y malo. Este tema es quizá el mayor punto de inflexión que se puede tener.

Tales cosas como la implementación correcta de un Page Object Model, Cucucmber, conexión con base de datos y adiciones más avanzadas no son posibles para Maestro, no tal y como se plantea en el resto de los sistemas.

Por eso es fundamental priorizar la complejidad de la aplicación a trabajar antes de elegir la herramienta, que es muy potente y con muy buena proyección, pero también relativamente nueva.

Lenguaje humano

En Maestro se aprende rápido, no hacen falta conocimientos avanzados gracias al uso del lenguaje .yaml. También ofrece la posibilidad de ejecutar comandos con javascript, lo cual ofrece una capa extra de profundidad bastante interesante.

Este simple código ya nos permitiría abrir una aplicación en un dispositivo y simular la pulsación de un botón.

En las librerías anteriormente mencionadas esto sería enormemente más complejo.

Multitud de entornos

No solo nos ofrece la ayuda de la portabilidad del testing al no pertenecer al proyecto base, sino que la herramienta al detectar tanto dispositivos conectados como emuladores simulados por parte de Android Studio (Dispositivos Android) como XCode (Dispositivos IOS).

A cambio de esta comodidad, Maestro pierde en herramientas a mano por parte del tester, al no poder acceder a cosas que existen dentro del proyecto base.

Maestro en WATA Factory

Maestro es una herramienta la cual WATA Factory ha reconocido su utilidad y proyección a futuro. La facilidad que ofrece a la hora de desarrollar test es algo que no se ve en otras herramientas y, aún no estando en algunos proyectos debido a sus respectivas complejidades, siempre se tiene en el punto de mira a la hora de hablar del testing automático en futuras aplicaciones de Flutter.

The post El futuro del testing automático E2E en Flutter: Maestro appeared first on WATA Factory.

A la hora de definir las bases de calidad de software y testing de un proyecto, sobre todo cuando se trata de aplicaciones web, decidir cuáles serán las tecnologías a usar para automatizar nuestras pruebas se convierte en un verdadero desafío. Más si cabe cuando tenemos que elegir una tecnología para testear nuestro frontend.

Si nos centramos en los tests E2E (end-to-end), con los cuales simulamos el comportamiento e interacción de un usuario real por medio de pruebas a la interfaz de usuario de nuestro proyecto, aparecen conocidas tecnologías como Selenium, Protractor o Playwright.

Pero si hay un framework de testing que está ganando popularidad gracias a su facilidad de uso y ventajas sobre los anteriores, ese es Cypress.

¿Qué es Cypress?

Cypress es un framework open source para el testing automático del frontend de aplicaciones web basadas en JavaScript. Su uso no solo se limita a las pruebas E2E, sino que también permite la creación de pruebas de integración o unitarias.

Dado que dispone de sus propias librerías de aserciones, comandos customizados y otras funcionalidades interesantes (como disponer de un dashboard para debugar y ejecutar nuestros tests), Cypress se confirma como un framework versátil adaptado a las características de la web moderna.

Todo ello partiendo de una arquitectura construida desde cero: no se necesita partir de Selenium.

Esto nos permite trabajar con un framework que no requiere la instalación de herramientas y librerías externas para poder empezar a crear nuestros tests.

¿Por qué Cypress?

Debido a la evolución de las aplicaciones web y al surgimiento de frameworks basados en JavaScript más actuales y modernos como Angular, Vue o React, también han evolucionado los frameworks de pruebas E2E. En este punto, dada la versatilidad y facilidad de uso que ofrece Cypress, es de esperar la popularidad que ha ganado desde su creación.

Otra característica interesante de Cypress es que este framework ejecuta la lógica de nuestros tests en el mismo ciclo de ejecución que la aplicación. Por debajo de Cypress se ejecuta un proceso de NodeJS que responde a los eventos de nuestra aplicación en tiempo real, y todo sin la necesidad de usar WebDriver para la ejecución de nuestras pruebas.

Cypress también nos facilita el trabajo a la hora de desarrollar los tests, ya que sólo es necesario tener conocimientos básicos de JavaScript para poder empezar. También se utilizan aserciones de otros frameworks de testing conocidos como Chai y Mocha.

Y por supuesto, otro de los motivos destacados para usar Cypress es poder disponer de su dashboard, que no es más que una interfaz gráfica donde podemos ver el proceso y ejecución de nuestros tests en tiempo real como si estuviéramos en la piel del usuario, de modo que podemos debugar y tener un visionado directo de los errores aparecidos en nuestras pruebas.

Características relevantes de Cypress

Cypress posee muchas características que son ventajosas con respecto a otros frameworks, y que nos puede ayudar a tomar la decisión de usarlo como nuestra herramienta de pruebas E2E en proyectos web.

1. Estado actual del framework y curva de aprendizaje

Cypress es un framework todo-en-uno actual y moderno, que dispone de buena documentación, una comunidad activa y continuas actualizaciones.

Ofrece una rápida puesta a punto del framework en nuestro proyecto, gracias a que la instalación es rápida y apenas requiere configuración. Las pruebas se escriben en JavaScript y la librería de Cypress dispone de comandos descriptivos y concisos.

Todo esto contribuye a una curva de aprendizaje llana, tanto para el equipo de desarrollo como para el equipo de QA.

2. Integración (o no) con otras tecnologías

Cypress no requiere de la integración de Selenium, ya que dispone de una arquitectura que parte de cero. En general tampoco necesita integrarse con otras librerías y frameworks externos, pero podemos hacerlo si queremos extender la funcionalidad del framework con tecnologías conocidas como Mocha, Chai o jQuery.

También funciona con cualquier librería o framework basado en JavaScript que corra en un navegador.

3. Interacción con los navegadores

Con Cypress no sería necesaria la instalación de un navegador gracias al navegador headless (sin interfaz gráfica), lo cual permite ejecuciones más rápidas y en menor tiempo. Gracias a esto, no sería necesario tener un navegador instalado para correr las pruebas E2E por Integración Contínua.

Por otro lado, no necesitamos ejecutar un WebDriver en Cypress, ya que nuestras pruebas se ejecutan dentro de un navegador a través de un proceso de NodeJS.

4. Esperas automáticas

Al usar Cypress no es necesario añadir esperas arbitrarias entre comandos y aserciones ya que éstas se hacen automáticamente, por lo que no es necesario utilizar wait y async en nuestras pruebas.

5. Dashboard útil y sencillo

Cypress dispone de un dashboard fácil de usar e intuitivo con la que debugar e interactuar entre los pasos de nuestros tests.

El dashboard nos ofrece dinamismo ya que no es necesario relanzar los tests, los cambios se ejecutan automáticamente y se reflejan al instante en cuanto guardamos el los avances de nuestro fichero.

6. Reporting legible y versátil

El resultado de los tests por consola y dashboard en Cypress es muy descriptivo. Además, hay muchas opciones para reportar los resultados de nuestros tests, así como la posibilidad de generar de capturas de pantalla y grabar vídeos de manera sencilla.

Cypress en WATA Factory

En WATA Factory ponemos el foco en asegurar la calidad de nuestro software, por eso consideramos fundamental hacer un buen estudio de las herramientas de testing que empleamos en nuestros proyectos, y consideramos que incorporar Cypress es una actual y óptima elección para testear nuestras aplicaciones web basadas en JavaScript.

The post Automatización de pruebas E2E con Cypress: una solución elegante y accesible appeared first on WATA Factory.

En este artículo hablaremos sobre Codeception, una de las herramientas que utilizamos para la automatización de pruebas para nuestros proyectos web implementados en PHP.

¿Qué es el testing automatizado?

En el ámbito de las pruebas de software, cuando hablamos de testing automatizado, nos referimos a conseguir que las pruebas que se realizan de forma manual puedan ser ejecutadas de forma desatendida, por medio de alguna herramienta que realice el proceso automáticamente, y como ya mencionamos en un articulo anterior, hacer que se mejore el proceso pero sin suplir al 100% el beneficio del testing manual.

Si podemos hacer que los tests sean ejecutados por un ordenador, entonces conseguiremos ejecutarlos de forma continuada según vayamos desarrollando la aplicación.

¿Por qué el testing automático es interesante para nosotros?

En WATA Factory nos vimos en la necesidad de implementar este tipo de pruebas ya que la evolución de nuestros proyectos requería de nuevas funcionalidades, que debían ser probadas en conjunto con las ya existentes para continuar asegurando la calidad de nuestros productos.

La automatización de pruebas trae una serie de beneficios que ayudan a elevar el nivel de calidad del producto y también a disminuir su coste, ya que la repetición de pruebas no supone una inversion grande de tiempo en las fases de mejora o evolución del producto.

Algunas de las ventajas que hemos conseguido en WATA Factory con la implementación de las pruebas automatizadas son:

• Verificar de forma automática que las especificaciones que se han definido se cumplen, haciendo uso de BDD (Behavior Driven Development). Uno de sus grandes beneficios es que nos permite mantener un lenguaje común entre el cliente y el equipo de desarrollo, detallando casos que verifican que el comportamiento del código es correcto desde el punto de vista del usuario.
• Reducir el número de bugs, ya que aseguramos que tanto la nueva funcionalidad como la antigua continúan trabajando correctamente.
• Ganar tiempo probando, ya que evitamos las tareas repetitivas, y aseguramos que los nuevos cambios en nuestra aplicación no afectan en otras partes del sistema.
• Crear una buena documentación.
• Y hacer que el trabajo en equipo sea más sencillo y seguro.

Para comenzar con el desarrollo de las pruebas automatizadas estuvimos investigando sobre frameworks de pruebas y descubrimos Codeception, que reunía todo lo que necesitábamos en una sola herramienta.

¿Qué es Codeception y cómo podemos instalarlo?

Codeception es un framework de pruebas para PHP cuyo objetivo es crear tests legibles que describan acciones desde la perspectiva del usuario. Nos permite hacer pruebas de aceptación, funcionales y unitarias.

La clave de Codeception son sus actores. Codeception entiende los tests como acciones que ejecuta una persona. Como resumen, un UnitTester ejecuta acciones y testea código, un FunctionalTester prueba la aplicación en su conjunto, y un AcceptanceTester interactúa con la interfaz.

Cada Actor ejecuta Steps, que son instrucciones individuales dentro de un escenario. Las instrucciones que puede generar un Actor se agrupan en módulos: PhpBrowser, WebDriver, DB, FileSystem, etc.

Para su instalación seguimos los pasos descritos en la documentación oficial.

Con la instalación se crea una carpeta llamada tests, y dentro de esta carpeta se crea una estructura básica para codificar los diferentes tipos de pruebas.

Como ejemplo vamos a testear el clásico Login. Aunque son mas los escenarios que detallar en esta prueba solo mostramos alguno de ellos para no extenderlo.

Para crear el test se ejecuta el comando:

php vendor/bin/codecept g:feature acceptance Login

Esto creará una fichero ‘.feature’ en el que escribiremos nuestra historia de usuario en un lenguaje formal llamado Gherkin con la particularidad de que podemos ejecutar estos escenarios como pruebas automatizadas.

Feature: Login page
Check that the user can access correctly with correct credentials, in other case a warning text is shown.
 
Scenario: User inserts empty password and empty username
   Given I am on login page
   When I fill fields with empty value
     And I click on login button
   Then I see the entered user data are not correct
 
Scenario: Successful access with valid credencials
   Given I am on login page
   When I fill the fields with correct credencials
     And I click on login button
   Then I see Welcome Dummy Name

Los escenarios se escriben paso a paso usando «Given-When-Then».

• La parte GIVEN son las condiciones previas para la pruebas. Desde donde partimos.
• La sección WHEN es ese comportamiento que estás especificando, es decir las acciones que necesitamos.
• Y finalmente THEN que es la parte donde obtenemos el resultado esperado.

Definiendo las pruebas

Nuestro próximo paso será definir y transformar el archivo de características en una prueba válida. Los definiremos en el archivo del AcceptanceTester.

Para conseguir los pasos necesarios se ejecuta el siguiente comando:

php vendor/bin/codecept gherkin:snippets acceptance

Para implementarlos como estamos en la suite de aceptación usamos WebDriver como modulo, ya que nos permite la interacción con el navegador. Esto significa que podemos utilizar sus métodos dentro del archivo Tester, como hacemos con las pruebas de escritura usando

$I->

Se puede emplear diferentes métodos que ya están desarrollados (por ejemplo amOnPage o click). Cada paso del escenario Gherkin se extenderá con los métodos definidos en Codeception.

Vamos a mostrar cómo puede ser implementado en nuestro caso:

/**
 * @Given I am on login page
 */
public function iAmOnLoginPage()
{
    $I->amOnPage('/login');
}

/**
 * @When I fill fields with empty value
 */
public function iFillFieldsWithEmptyValue()
{
    $I->fillField('#username','');
    $I->fillField('#password','');
}

/**
 * @When I fill the fields with correct credencials
 */
public function iFillTheFieldsWithCorrectCredencials()
{
    $I->fillField('#username','correctUsername');
    $I->fillField('#password','correctPassword');
}

/**
 * @When I click on login button
 */
public function iClickOnLoginButton()
{
    $I->click('Login');
}

/**
 * @Then I see the entered user data are not correct
 */
public function iSeeTheEnteredUserDataAreNotCorrect()
{
    $I->see('the entered user data are not correct');
}

/**
 * @Then I see Welcome Dummy Name
 */
public function iSeeWelcomeDummyName()
{
    $I->see('Welcome Dummy Name,');
}

Finalmente ejecutamos nuestro archivo .feature con el comando

php vendor/bin/codecept run acceptance Login.feature --steps 

para ver que Given/When/Then se amplían con subpasos y muestra el resultado esperado sobre la ejecucion.

Acceptance Tests (2)
-------------------------------------------------------------
Login page: User inserts empty password and empty username Signature: User inserts empty password and empty username
Test: App/Tests/surveys/Login.feature:User inserts empty password and empty username

Scenario -- 
Check that the user can access correctly with correct credentials, in other case a warning text is shown.

Given i am on login page
   I am on url "https://###########/login"
When i fill fields with empty value
   I fill field "#username"," "
   I fill field "#password"," "
And i click on login button 
   I click "LOGIN"
   I wait 5
Then i see the entered user data are not correct 
   I see "the entered user data are not correct" 
PASSED 

Login page: User inserts proper information - Successful access with valid credencials 
Signature: Successful access with valid credencials 
Test: App/Tests/surveys/articulo_test.feature: Successful access with valid credencials

Scenario --
Check that the user can access correctly with correct credentials, in other case a warning text is shown.

Given i am on login page 
   I am on url "https://########/login"
When i fill the fields with correct credencials 
   I fill field "#username","correctUsername"
   I fill field "#password","correctPassword"
And i click on login button 
   I click "LOGIN"
   I wait 5
Then i see welcome dummy name 
   I see "Welcome Dummy Name,"
PASSED 
-------------------------------------------------------------
Time: 19.57 seconds, Memory: 18.00 MB OK (2 tests, 2 assertions)

Son muchas las ventajas que nos ofrece esta herramienta, además también cuenta con una aplicación, conocida como Webception, en la que el cliente puede ejecutar todos los test desde el navegador y así poder seguir el estado de su aplicación.

The post Introducción a las pruebas automatizadas con Codeception en proyectos PHP appeared first on WATA Factory.

Es decir, conseguiremos controlar si el proceso de desarrollo, la arquitectura empleada o los algoritmos empleados siguen una estructura adecuada, un patrón que nos permita un fácil mantenimiento del producto.

¿Qué es SonarQube?

SonarQube es una de las herramientas más usadas para revisar código, detectar bugs, vulnerabilidades y otros problemas dentro de nuestro proyecto. Permite el análisis de código que se encuentre escrito en los principales lenguajes de programación (Java, PHP, JavaScript, C#, HTML, etc.).

SonarQube se integra como un fichero más dentro del proyecto a analizar y, si el pipeline en el que se lanzan las tareas está correctamente configurado, la inspección del código se hará automáticamente cada vez que hagamos un cambio en alguna parte de dicho proyecto.

Como se muestra en la imagen, el escenario típico en el que mejor puede entenderse su utilidad es el que contiene tres fases claras: 

• Desarrollo – El código es actualizado en el repositorio por los desarrolladores. Antes de solicitar al servicio de SonarQube que analice los cambios, ellos pueden disponer de feedback inmediato gracias a la herramienta SonarLint, que puede ser integrada en los IDEs.
• CI/CD – Al incluir los nuevos cambios en el repositorio, las herramientas de Integración Continua comprueban y construyen el código, y ejecutan las pruebas. Acto seguido se hace la llamada al escáner de SonarQube para que analice los resultados de algunas de esas pruebas y el código como tal. 
• Plataforma de SonarQube – Una vez realizado el análisis del proyecto, los resultados son almacenados en la plataforma y en función de las condiciones de calidad que se configuren, podrá informarse a los miembros del equipo si deben solventar alguna carencia.

Para los diversos proyectos que se realizan en WATA Factory, nos hemos decantado por usar la edición Community, la cuál es libre y de código abierto. Sin embargo, existen otras alternativas de pago que te facilitan la instalación y mantenimiento del servicio de SonarQube por parte de la misma compañía. Para el caso de la versión Community, ésta puede ser instalada en dos modalidades:

• Local – El desarrollador podrá montarse el servicio de SonarQube en su localhost para poder analizar su código sin necesidad de alojarlo en ningún servidor externo o remoto. 
• Remoto – El servicio de SonarQube se encontrará alojado en un servidor remoto dónde se podrá acceder a través de credenciales generadas por el administrador del servicio.  

En función de las necesidades y del tamaño del proyecto (miembros, recursos o servicios a los que acudir), podrás elegir la opción más adecuada según tus circunstancias.

Conceptos generales 

Para entender un poco más la relevancia que tiene el uso de esta herramienta, vamos a detallar los conceptos generales que van a aparecer en la plataforma: 

1. Usuarios y grupos: Al igual que en cualquier entorno, vamos a poder definir usuarios que se organicen en grupos. Cada uno de ellos con una serie de privilegios que les permitirán desde solicitar el análisis de un proyecto hasta validar o cancelar falsos positivos en los análisis realizados. 
2. Proyectos: Para poder realizar el análisis de nuestro código, tendremos que generar un proyecto en la plataforma dónde indiquemos los parámetros que van a identificar nuestro proyecto software. Dichos parámetros, en función del lenguaje que estemos usando en nuestro proyecto, se deberá indicar de una manera u otra. Dentro de estos proyectos encontraremos el análisis de cada uno de ellos, conteniendo los siguientes datos: 
3. Bugs: Errores en el código que deben ser resueltos lo antes posible. 
4. Vulnerabilidades: Puntos del código que se encuentran abiertos a ataques externos y que pueden poner en peligro la integridad y seguridad del proyecto. 
5. Hotspots: Puntos del código que deben ser revisados para evitar problemas mayores, no tienen porqué poner en peligro la seguridad del proyecto. 
6. Code smells: Elementos que hacen que el código sea poco legible o difícil de mantener. 
7. Cobertura: A partir de los reportes de los tests unitarios ejecutados, SonarQube importa los resultados y muestra la cobertura de ellos. 
8. Duplicaciones: Número de bloques, ficheros y líneas duplicadas detectadas. 
9. Total de líneas: Total de líneas de código del proyecto. 
10. Lenguajes: Lenguajes de programación que son usados en el proyecto. 
11. Estado actual: Fail/Passed, dependiendo de los valores establecidos en el perfil de calidad que se le asocien. 
12. Tags: Etiquetas que se le han asignado al proyecto. 
13. Hora del último análisis: Registro de cada uno de los análisis realizados. 
14. Perfiles de calidad: Dependen directamente de las condiciones establecidas en los Quality Gates, las cuales van a indicar cuáles son las reglas que deben seguirse en cada uno de los lenguajes disponibles en SonarQube. Las condiciones de los perfiles de calidad reflejarán límites en cuanto a mínimos de cobertura, líneas duplicadas, índice de seguridad o índice de mantenibilidad. 

Como podemos ver, el reporte y la información generada es muy amplia, lo que nos permite tener una visión muy precisa del estado de nuestro proyecto.

En WATA Factory hemos establecido SonarQube como una herramienta más y ha permitido la mejora de la calidad del código y también, un aprendizaje indirecto de los desarrolladores. Ya que con cada uno de los reportes se aprende qué malas prácticas deben evitar y cómo solventarlas con las propuestas ofrecidas por la misma herramienta, gracias a las reglas definidas en los Quality Gates. En futuros artículos, veremos cómo configurar nuestro proyecto para poder analizarlo con SonarQube de forma automática desde un pipeline. 

The post SonarQube: Cómo mantener la calidad de tu código durante un proceso de CI/CD appeared first on WATA Factory.

Como ya vimos en un artículo anterior, dentro del software testing podemos encontrar dos tipos de pruebas: pruebas manuales y pruebas automatizadas. 

En este artículo, vamos a explicar cuáles son las características, ventajas y desventajas del testing automático en un proyecto software. Para preparar el contenido de esta entrada, he complementado mi experiencia personal con la de diferentes compañeros de nuestro equipo en WATA Factory.

Recomendaremos qué aspectos son los más importantes a tener en cuenta para que el camino al éxito sea lo más fácil y rápido posible. 

Características del testing automátizado 

El testing automático es la técnica que se basa en las acciones desarrolladas por las herramientas de automatización de pruebas. Uno de sus principales objetivos es mejorar el proceso de pruebas de un proyecto software siendo el complemento de mejora de las pruebas manuales. 

A día de hoy, las pruebas automáticas nunca pueden suplir al 100% el beneficio que nos aportan las pruebas manuales. La automatización sólo mejora el proceso de testing ofreciendo ventajas como las pruebas paralelas, el reporte automático, la eliminación de tareas repetitivas para los testers manuales o la reutilización de escenarios de tests. Pero actualmente, el software testing de un proyecto no puede ser cubierto totalmente sólo por las pruebas automáticas. 

Para este tipo de pruebas, la responsabilidad del proceso recae totalmente sobre la herramienta seleccionada y los scripts diseñados por el tester para esa Application Under Test (AUT).  Al contrario que con las pruebas manuales, las automáticas no pueden ser aplicadas en cualquier ámbito. En concreto, la aplicación del testing visual y de UI de forma automática deja aún mucho que desear. Ya que existen proyectos en los cuales se están desarrollando cada día mejores herramientas basadas en la IA, pero no consiguen cumplir todos los objetivos deseados. 

Atendiendo a estos datos, podemos identificar las principales ventajas e inconvenientes del testing automático:

Ventajas

Al contrario que con las pruebas manuales, las pruebas automatizadas nos permiten paralelizar muchas rutinas de trabajo. La planificación de ellas va a ofrecer un gran abanico de posibilidades para mejorar la calidad del producto. Con un mayor nivel de detalle, podríamos decir que todo lo que nos ofrece el testing automatizado es: 

• Velocidad: el tiempo de ejecución es menor. 
• Confiable: se pueden abarcar más permutaciones y caminos en el AUT. 
• Eficiencia: se ejecutan más tests en menos tiempos y se mejora la cobertura del AUT. 
• Los tests son ejecutados automáticamente a partir de los scripts. 
• Los tests pueden ser reutilizados en diversos escenarios. 

Desventajas

Por otro lado, la aplicación de esta técnica de testing conlleva una serie de consecuencias. Entre ellas, la más destacada es la necesidad de tener un equipo de testing más formado en aspectos técnicos para el diseño de los scripts. Y como hemos comentado previamente, las limitaciones que debemos controlar en diversos ámbitos como es el testing de usuario. Si analizamos estas desventajas, podríamos obtener el siguiente listado: 

• Los testers necesitan tener conocimientos técnicos para poder implementar los scripts de tests. 
• No puede aplicarse en todos los tipos de pruebas posibles. Por ejemplo, testing visual. 
• Si los scripts no son correctamente diseñados, podemos generar falsos negativos que reduzcan la fiabilidad de los reportes. 
• No podemos automatizar aspectos como el nivel de usabilidad o cuán intuitivo es la AUT. Necesitamos del test manual para ello. 
• Recomendado para proyectos estables y de larga duración debido a la inversión técnica que debe realizarse. 

El uso del testing automatizado es cada día una tendencia más habitual entre los diversos equipos software debido a las numerosas ventajas que ofrecen. Ya que a pesar de las posibles desventajas que debemos afrontar, el resultado obtenido de su buena aplicación es siempre positivo. 

Sin embargo, partiendo de todos estos detalles que hemos analizado, es necesario que por la parte del tester automático se tengan en cuenta dos aspectos muy importantes: la selección de una buena herramienta de automatización de pruebas y el correcto diseño de los scripts de prueba. En futuras entradas analizaremos cómo podemos hacer frente a estos retos y cómo poner en práctica este tipo de testing dentro de nuestros proyectos. 

The post Automated testing: características, ventajas y desventajas appeared first on WATA Factory.

Conforman todo un ciclo paralelo dentro del desarrollo software y dicho ciclo es conocido como el Ciclo de Vida del Software Testing (CVST).  

Dentro del CVST podemos encontrar pruebas de dos naturalezas diferentes: pruebas manuales y pruebas automáticas. En el caso de las pruebas manuales, la actividad es desarrollada al 100% por el tester. Y en el caso de las pruebas automáticas, sólo un porcentaje de dichas actividades es desarrollada por dicha persona, ya que el resto es realizada por herramientas de automatización. 

Características del testing manual 

El testing manual es la técnica más utlizada a lo largo de la historia del desarrollo de software. Es la primera que permitió la aplicación de pruebas en diferentes niveles: unitario, integración de componentes, interfaz de usuario… Sin embargo, a pesar de que cualquier tipo de prueba puede ser aplicada con las pruebas manuales, esto genera ciertos inconvenientes. Veamos las características con un mayor nivel de detalle: 

Pros:

• Cualquier tipo de test puede ser realizado con pruebas manuales. De hecho, la calidad a nivel de interfaz de usuario (o user-friendly) sólo puede ser controlada por esta categoría de pruebas. 
• Permite analizar escenarios más complejos gracias a la inventiva que puede desarrollar el tester durante su aplicación. 
• El riesgo de detectar un falso negativo es muy bajo debido a la interacción directa con el sistema a probar. 
• Los testers no necesitan tener conocimientos técnicos para poder poner en prácticas las pruebas a realizar. 

Contras:

• La ejecución de las tareas es muy lenta debido a la dificultad de algunos escenarios. 
• El tester debe ser creativo, paciente y con iniciativa para poder encontrar situaciones que pongan a prueba las características del producto. 
• Consume mucho tiempo a la hora de completar las tareas. 
• Muy tedioso debido a la realización manual de todos los pasos que suponen cada una de las pruebas. 
• Es difícil cuantificar el nivel de cobertura de pruebas que tenemos con la realización de este tipo de pruebas.

Cómo ponerlo en práctica 

En WATA Factory tenemos un amplio historial de proyectos en los cuales hemos puesto en práctica las tecnicas de testing manual para poder asegurar y garantizar los niveles de calidad de nuestros productos. 

Cada proyecto tiene unas características diferentes y su puesta en práctica conlleva un análisis de los recursos y requisitos que debemos controlar. Por ello, a la hora de comenzar a aplicar el testing manual se recomienda aplicar los siguientes pasos: 

1. Análisis del sistema: definición de los requisitos funcionales y no funcionales a probar. 
2. Análisis de los recursos con los que disponemos: personas, equipos, tiempos, etc.
3. Planificación de las pruebas manuales a desarrollar: tipos y tiempos de ejecución.
4. Ejecución de las pruebas.
5. Documentación de los resultados obtenidos: reportes de bugs, informes de resultados y requisitos analizados.

Muchos de estos pasos son comunes al proceso de CVST, pero en el caso del testing manual, su aplicación y ejecución es bastante secuencial. 

Por ello, dentro de nuestros proyectos estamos comenzando a aplicar técnicas de testeo automatizado, con las cuales conseguimos reducir los inconvenientes derivados del testeo manual y así aumentar la calidad de nuestros productos. 

The post Manual Testing: aplicando pruebas manuales a un proyecto de software appeared first on WATA Factory.