Aprende QTP (UFT)
Nuestro fundador, Ankur Jain, comenzó este sitio web hace unos 14 años en 2006. Debido a su amplia experiencia con la herramienta QTP (QTP fue originalmente una herramienta de prueba de software automatizada por Mercury. QTP se conoce ahora como UFT One), quería que este sitio web se convirtiera en una ventanilla única para los estudiantes de QTP. Es con su amor y motivación, el sitio todavía va fuerte y visitado por varios miles de principiantes UFT a los usuarios avanzados cada día.
Desde el momento del lanzamiento de este sitio, varias cosas han cambiado en el mundo QTP. HP adquirió Mercury – la compañía original que desarrolló QTP. QTP se convirtió en UFT cuando HP decidió fusionar las pruebas de GUI y API en una sola herramienta. Lee la historia completa de QTP y UFT. HP se dividió en dos empresas HP Inc y HPE. Mientras tanto, durante todos estos años, HPE introdujo varias innovaciones en el software UFT. En septiembre de 2017, el giro de HPE se fusionó con Micro Focus.
El equipo de LearnQTP se dio cuenta de que – aunque nuestros artículos más antiguos seguían siendo relevantes – hay una necesidad de un nuevo conjunto de tutoriales UFT para las últimas versiones de UFT. Por lo tanto, lanzamos el nuevo conjunto de tutoriales UFT para los principiantes a los usuarios avanzados de UFT. Empezaremos desde cero y poco a poco iremos construyendo hacia temas avanzados.
Estos tutoriales de UFT estarán estructurados de tal manera que incluso un principiante absoluto en pruebas de software automatizadas sería capaz de seguirlos. Los tutoriales serán a tu propio ritmo, no habrá presión. Puedes marcar el enlace y volver a ellos cuando te apetezca aprender. Incluso puedes descargar los tutoriales UFT gratuitos en PDF que estarán disponibles en la parte inferior de cada artículo, para que puedas aprender incluso cuando estés viajando o no tengas una conexión a Internet que funcione.
Antes de sumergirnos en UFT, vamos a repasar una cartilla sobre las pruebas de software y cómo y cuándo automatizamos las pruebas de software.
¿Qué es la prueba de software?
Un renombrado experto en pruebas de software, el Dr. Cem Kaner, define las pruebas de software como –
Una investigación técnica del producto bajo prueba llevada a cabo para proporcionar a las partes interesadas información relacionada con la calidad
Para explicarlo mejor, las pruebas de software son un proceso en el que un probador/equipo de software ejecuta un programa o un sistema para encontrar errores o defectos, para mantener la corrección y fiabilidad de un programa.
Las pruebas de software también validan y verifican el programa para comprobar si se cumplen los requisitos empresariales y técnicos, y si funciona como se espera.
En la verificación, los probadores se aseguran de que el sistema cumple con los estándares y procesos de la organización, y responden a la pregunta «¿Hemos construido el sistema correcto?» Por sistema se entiende una o varias aplicaciones de software que dan soporte a una función empresarial. Los probadores se aseguran de que el software, el hardware, la documentación y el personal cumplen juntos mediante la revisión o los métodos no ejecutables.
En la validación, los probadores se aseguran físicamente de que el sistema ha cumplido con todos los requisitos del negocio y de los usuarios, y de que las características y funcionalidades funcionan como se han diseñado. La validación se realiza ejecutando las funciones del sistema mediante una serie de pruebas que pueden ser observadas y evaluadas por los probadores. Además, la validación se concentra en la pregunta «¿Construimos bien el sistema?»
¿Por qué debemos realizar pruebas de software?
En las pruebas de software, el objetivo principal es encontrar defectos. Podemos considerar que un determinado estado es un defecto si no cumple con lo que se espera que haga. Encontrar defectos en las pruebas en las primeras etapas del Desarrollo de Software reducirá o evitará el riesgo de fracaso, el coste de mantenimiento, el coste de la corrección de defectos, y la entrega de un mejor programa para el usuario.
Ejemplo: El número de expediente debe aceptar 12 caracteres numéricos. Si los caracteres introducidos son inferiores o superiores a los requeridos, aparecerá el mensaje «Invalid Entry. Por favor, vuelva a introducir el número de expediente», pero el usuario introdujo 10 caracteres para el número de expediente y el programa devolvió un error de excepción en lugar de un aviso para notificar al usuario sobre los caracteres mínimos requeridos.
Otra razón es producir un programa de calidad. En las pruebas de software, el probador/equipo de software no puede mejorar la calidad, sólo puede medirla. Desde el punto de vista de TI, la calidad significa la conformidad y las características de los requisitos de un programa basado en los requisitos técnicos y de negocio se cumplen. Desde el punto de vista del usuario, la calidad significa que el software es apto para su uso. La calidad del software varía de un programa a otro, ya que tienen su propia funcionalidad y usabilidad. Un probador de software necesita asegurarse de que se cumplen los puntos de vista de TI y del usuario para la calidad.
¿Qué es la prueba de software automatizada?
La prueba de software automatizada implica la automatización del proceso manual a través de la escritura de scripts de prueba que harían las pruebas y se pueden ejecutar repetidamente.
La automatización de las pruebas se utiliza para controlar la ejecución de las pruebas, comparar los resultados reales y los esperados, el establecimiento de condiciones previas, y otras funciones de control de pruebas y de informes de pruebas mediante el uso de software.
¿Cuándo automatizar la prueba de software?
Una creencia común que vemos entre los profesionales de las pruebas es que la automatización, por alguna magia, aumentará la calidad de las pruebas.
Hay un momento y un lugar para todo. Si una prueba PUEDE ser automatizada no significa que DEBE ser automatizada. Aunque, este es un sitio web de pruebas automatizadas, uno pensaría que denunciaríamos las pruebas manuales. Sin embargo, no es el caso.
Click To Tweet: Si una prueba PUEDE ser automatizada, no significa que DEBE ser automatizada http://ctt.ec/bLk49+ vía @LearnQTP
Las pruebas manuales y automatizadas van de la mano y deberían complementarse. Pedimos a nuestros aprendices y lectores que se aseguren de automatizar una prueba sólo cuando sea realmente necesario.
Aquí hay algunos escenarios en los que la automatización se considera una gran opción:
- Pruebas de regresión/Pruebas repetitivas: Una regla de oro para la prueba manual a automatizada es que, si sus pruebas necesitan ser ejecutadas periódicamente, son un buen candidato para la automatización. Sin embargo, hay que tener en cuenta algunas advertencias. Hay que sopesar los costes de la creación de pruebas automatizadas frente a los esfuerzos de las pruebas manuales. Los costes incluyen la complejidad de la automatización, el tiempo necesario para crear y mantener los scripts de automatización y, por supuesto, el tiempo y el dinero necesarios para formar a los probadores en una herramienta determinada.
- Múltiples vales de datos: Necesita ejecutar el mismo conjunto de acciones para varios valores de datos.
- Pruebas manualmente inviables: Se necesita que su aplicación sea sometida a pruebas de estrés para un millón de impactos en cuestión de pocas horas. No se puede hacer manualmente, necesitaría una herramienta de pruebas de carga.
- Las mismas pruebas diferentes navegadores o sistemas operativos: Usted querría que su aplicación web se viera bien en todos los navegadores y sistemas operativos comúnmente utilizados. Si usted tiene un conjunto de pruebas que contiene 50 casos de prueba que necesitan ser probados con 20 conjuntos diferentes de valores en 3 conjuntos diferentes de navegadores y 2 sistemas operativos. Esto hace que el total de ejecuciones de pruebas sea de 50*20*3*2= 6000. Tiene sentido automatizar estos casos de prueba.
- Pruebas en móviles: Con toneladas de teléfonos móviles disponibles en el mercado, sería casi imposible realizar pruebas manuales en todos los dispositivos. Empresas como Amazon han ideado enfoques innovadores para este problema, por lo que ponen los dispositivos reales en la nube y usted puede probar su aplicación en los dispositivos con scripts automatizados. De nuevo, un candidato ideal para la automatización de pruebas.
- Tutorial 1: Introducción a las pruebas de software
- Tutorial 2: Introducción a UFT
- Tutorial 3: UFT Add-ins y Add-in Manager
- Tutorial 4: Todo sobre los menús de UFT
- Tutorial 5: Guía completa de los paneles de UFT
- Tutorial 6: Graba tu primer script de UFT
Confiamos en que os haya gustado esta cartilla sobre pruebas de software y hayáis entendido cómo decidimos automatizar las pruebas de software para un escenario determinado. En el próximo tutorial comenzaremos con la instalación de UFT y discutiremos los fundamentos de la herramienta – Tutorial 2: Introducción a UFT.
Puede consultar el conjunto completo de tutoriales de UFT cubiertos hasta ahora utilizando los siguientes enlaces:
Ingresa tu nombre y tu correo electrónico a continuación y nos aseguraremos de enviarte los tutoriales tan pronto como estén listos.
Te toca a ti. Cómo te decides por las pruebas automatizadas?
Si quieres estar al tanto de más artículos sobre UFT (QTP). I recommend you to subscribe by Email and have new UFT articles sent directly to your inbox.