Menú

Cómo realizar pruebas de productos de software: procesos y métodos detallados con ejemplos

how perform software product testing detailed process

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Los productos de software necesitan su propio enfoque único para realizar pruebas de forma adecuada y correcta. A menudo, los equipos los tratan como cualquier otro software (es decir, aplicaciones internas creadas para un cliente o equipo específico; no accesibles para el público en general; no generan ingresos) y ese es el punto de partida del problema.

Las pruebas de productos de software necesitan un estilo y una estrategia de prueba personalizados para agregar valor. El desarrollo y mantenimiento de productos de software es en sí mismo un ecosistema complejo y para prosperar, los evaluadores deben adaptarse.

Permítanme tomarme un momento para explicar por qué es importante y por qué creo que el desarrollo de productos es complejo, complicado y compuesto, incluso en el mejor de los casos.

Cómo probar el producto

Lo que vas a aprender:

Desafíos del desarrollo de productos de software:

Estos son algunos de los desafíos que enfrentan los equipos de desarrollo de productos de software:

#1)Falta de control sobre la demografía de los usuarios, dispositivos, entornos, plataformas, etc. : Los productos de software, a diferencia del software creado para partes interesadas específicas, no se utilizan en situaciones controladas y predecibles. Hay demasiados factores para tener en cuenta.

#2)Visión de producto brumosa : El comportamiento y las funciones del producto cambian constantemente y el camino hacia la madurez no es claramente visible. O el producto está creciendo demasiado rápido que se sale de control y los equipos no saben lo que está sucediendo.

#3)Líneas de tiempo agresivas : Debido a la fuerte competencia en el mercado de productos de software, las cosas tienen que moverse a una velocidad vertiginosa y los equipos deben ir un paso por delante de sus pares. De lo contrario, seguramente perderán frente a la competencia.

#4)Miedo al fracaso : Los productos de software suelen ser innovadores. Entonces, su éxito no siempre es un hecho. Esta es la razón por la que las empresas no pueden hacer todo lo posible en términos de presupuesto, tecnologías, infraestructura, etc. A menudo tienen que reprimirse para obtener cierta inmunidad frente a fallas o incluso para alcanzar el punto de equilibrio.

#5)Falta de retroalimentación procesable: Dado que no hay partes interesadas o usuarios comerciales o clientes, por así decirlo, es difícil entender qué puede o no gustar al usuario final. Las empresas están constantemente jugando un juego de adivinanzas y, a menudo, tienen dificultades para cerrar la brecha entre lo que quieren para el software y lo que quieren los clientes.

Estos desafíos afectan todas las áreas de desarrollo, marketing y mantenimiento de productos, y también tienen un impacto inherente en las pruebas de productos.

Para salir adelante en el juego, este tipo de pruebas debe tener en cuenta cinco puntos clave:

  • Velocidad de desarrollo y lanzamientos
  • Objetivos de producto a corto y largo plazo del producto
  • Alcance y naturaleza de la competencia
  • Públicos objetivo y sus entornos
  • Requisitos - Funcional, rendimiento, seguridad, usabilidad, configuración, etc.

Antes de entrar en más detalles, comprendamos el ciclo de vida del producto (este es un ciclo de vida del producto genérico y no específico de los productos de software, pero el software sigue un patrón similar):

ciclo de vida del producto

Una buena estrategia / enfoque de prueba de producto debe tener en cuenta la etapa actual del producto en su ciclo de vida.

Leer también => Cómo redactar un buen documento de estrategia de prueba

Ejemplo: El producto de una empresa XYZ es un software de seguimiento de defectos llamado 'TrackFast'. Es un producto nuevo y la primera versión se lanzará como una solución en la nube y en las instalaciones. TrackFast funciona como cualquier otro sistema de gestión de defectos y está diseñado para el acceso móvil y web. Actualmente, hay sprints de 2 a 4 semanas en los que el producto se crea en partes. Usted está en el equipo de pruebas que prueba 'TrackFast' antes de que llegue a sus clientes. La prueba implica comprobar la funcionalidad, el rendimiento y la seguridad.

cómo instalar el complemento svn en eclipse

En resumen, estos son los parámetros con los que está trabajando. O si lo prefieres, este es tu contexto

Los parametros

Veamos cómo probar en cada etapa. Este es prueba de producto proceso, método o ciclo de vida en cada etapa.

Etapa # 1) Introducción del producto

Dado que esta es la primera vez que TrackFast saldrá al mercado, la idea es dar una buena primera impresión. Así que no dejes piedra sin remover. Pruebe todo y desde todos los ángulos. Además de eso, sienta las bases para futuras pruebas.

Una buena estrategia de prueba en este punto debe incluir lo siguiente:

  • Pruebas que validan los objetivos a corto plazo de TrackFast. “Qué se necesita para enviarlo correctamente” debe estar a la vanguardia del esfuerzo de prueba. Crear Pruebas de extremo a extremo (front-end, middleware y backend) para realizar pruebas exhaustivas de cada función
  • Pruebas que comparan TrackFast con la competencia (Lo ideal es que este sea el trabajo de los propietarios de productos, pero como probadores podemos sumar nuestros dos centavos. Además, este paso es más fácil si el software ya tiene algunos pares. Por ejemplo: Es fácil comparar TrackFast con Bugzilla o JIRA o otros sistemas heredados . Pero digamos que estoy creando una aplicación que hace algo inusual, como poder predecir cuándo un bebé tiene hambre o está de mal humor :), puede ser difícil encontrar una aplicación que pueda usar como línea de base)
  • Plataforma, navegador y dispositivo pruebas de compatibilidad
  • Pruebas para facilitar la instalación , configurar y ponerse al día
  • Pruebas de rendimiento, seguridad y usabilidad
  • Pruebas de integración si interactúa con otros sistemas. Un ejemplo simple de integración es que los sistemas de seguimiento de defectos a menudo interactúan con los clientes de correo electrónico para enviar notificaciones.
  • Planificar la regresión - Es una buena idea marcar o marcar las pruebas críticas que cree que serán parte de futuros ciclos de regresión y pensar en automatizarlas para futuras versiones.
  • Planifique los problemas conocidos (los agregará a la lista de trabajos pendientes o los manejará como CR, etc.)
  • Flexibilidad para cambiar cuando el producto pasa a la siguiente etapa del ciclo de vida.

A veces puede ser una larga espera antes de que se apague el producto, así que use todo el tiempo que tenga para hacer un trabajo lo más completo posible.

En esta etapa, aunque hay una parte del producto lista al final de los sprints de 2 a 4 semanas, la mayoría de las veces cada sprint no da como resultado el código enviado. Por lo tanto, nunca considere la última prueba de sprint 'hecha y entregada'. Repite las pruebas críticas con cada sprint hasta el lanzamiento. Con cada sprint, prueba todo el producto que tienes hasta ese momento.

Etapa # 2) Crecimiento del producto

Después de la presentación inicial del proyecto, si todo va bien, espere una afluencia de actividad porque el crecimiento del producto es un carril de ritmo rápido. Ahora estás nadando junto con los grandes tiburones y, a menos que sigas el ritmo, te engullen.

Aquí, las versiones se acortan, las mejoras realizadas en el software aumentan en número y el grado de regresión casi se vuelve inmanejable.

La estrategia de prueba del producto debe funcionar con el ritmo al que avanza el desarrollo del software y no debe convertirse en un cuello de botella.

Estos pueden ayudar:

  • Tenga en cuenta los objetivos a largo plazo del proyecto. No se trata de superarlo ahora. Se trata de vivir con las características y prosperar con ellas.
  • Prueba temprana Considere TDD o BDD en lugar de aplazar las pruebas hasta el final con nuevos requisitos
  • Automatizar la regresión y fortalecerla – Cree una suite de regresión automatizada en su lugar para que no se quede con minas terrestres sin probar en su sistema
  • Si los propietarios de su negocio / producto quieren involucrarse con las pruebas, considere una herramienta de automatización basada en el lenguaje empresarial como Cucumber.
  • Mantenga la usabilidad y el diseño del sitio es fundamental para sus pruebas. Porque cuantas más funciones agreguemos, más limpio debería verse el sitio
  • Realice pruebas de rendimiento y seguridad cuando se haya producido una versión importante o se haya realizado un cambio significativo en la arquitectura. (Nuevo servidor incorporado, etc.) La mayoría de los sistemas de software no lo necesitan con cada lanzamiento.
  • Mantente en contacto con la competencia y conoce la visión del producto
  • Adaptar la prueba de pares , para recibir comentarios y soluciones inmediatas. Incluya al propietario del producto cuando sea posible
  • Planifique cambios y problemas conocidos
  • Intente tener en sus manos los comentarios de los clientes y verifique si se pueden rastrear como una sugerencia de mejora para mantener el crecimiento constante. (una vez más, esta no es la responsabilidad principal del equipo de control de calidad, pero todos cuentan)

Etapa # 3) Madurez del producto

Felicitaciones porque su producto ha llegado tan lejos. En este punto, las funciones no cambian con tanta frecuencia. El equipo de producto estará más enfocado en generar más negocios o sus esfuerzos de marketing. Sin embargo, el desarrollo y las pruebas de productos no tienen por qué detenerse, ya menudo no se detienen.

Por lo tanto, el equipo de pruebas puede:

  • Trabaje para madurar su estrategia de prueba. En este punto, sus conjuntos de regresión, métodos de diseño de pruebas y prácticas de gestión de pruebas deben funcionar como máquinas bien engrasadas.
  • Concéntrese en los detalles más finos. Porque en general el producto funciona y está funcionando bien, pero como dicen: ' Dios esta en los detalles' - encontrar incluso el más pequeño de los problemas que pueden mejorar la calidad del sistema
  • Considere los comentarios de los clientes
  • Pruebe el rendimiento y la seguridad periódicamente
  • Tenga en cuenta los nuevos dispositivos, plataformas y navegadores que podrían haber salido al mercado desde la última vez que lo probó
  • Pruebe el manual del usuario y las páginas de preguntas frecuentes porque ya tiene tiempo y puede permitírselo.
  • Experimente con un nuevo producto, herramientas de prueba, servicios o un proceso porque ahora puede hacerlo.
  • Pruebe el proceso de instalación con cada versión, por pequeña que sea, y obtenga estadísticas sobre lo fácil o difícil que es para el usuario final.

Hagas lo que hagas, no seas complaciente.

Etapa # 4) Declive del producto / Regreso al crecimiento del producto

Los propietarios de productos y las empresas son inteligentes en estos días y saben muy bien que no pueden mantener su producto igual y esperan que los usuarios sean leales. Las cosas se mueven demasiado rápido y también los productos.

Entonces, TrackFast no puede sentarse y relajarse. Si necesita tener una presencia continua en el mercado y seguir siendo líder, debe evolucionar. Me guste o lo odie, Facebook comenzó como una simple red social para conectar personas y es una gran plataforma de software en sí misma que se integra con un millón de otras cosas y se mantiene al día.

TrackFast también tiene que evolucionar. Después de demostrar que es un sistema de seguimiento de defectos confiable y efectivo, tiene que evolucionar o disminuirá. Por lo tanto, la empresa XYZ decide mejorar TrackFast convirtiéndolo en un sistema de tickets general que puede usarse para rastrear cualquier incidente o caso por parte de la empresa que no sean equipos de prueba / TI (algo como JIRA) y no solo por defectos en el proceso de desarrollo de software. .

La rueda ha dado un giro completo y usted se encuentra tratando el sistema como uno nuevo y sigue la estrategia que discutimos en la sección Introducción del producto. Solo que ahora tiene más experiencia y está más familiarizado con el ejercicio. Pero recuerde, con cada nuevo turno viene un nuevo desafío. Así que mantente alerta :)

referencia indefinida a la función c ++

¿Qué lo convierte en un probador de productos exitoso?

  • Probadores de productos deben tener un agudo sentido comercial, comprensión de los modelos de desarrollo de entrega rápida y deben ser probadores expertos que no tienen miedo de experimentar con herramientas y convertirse en programadores si es necesario. Estas cosas pueden tener un impacto positivo en cualquier tipo de prueba, pero son una necesidad absoluta en este tipo de pruebas.
  • Otra cualidad importante es que El probador de productos debe creer en el producto. y realmente quiero que tenga éxito. Cuando yo, como evaluador, pienso que el software es basura total, hay pocas esperanzas de que haga algo para mejorarlo.
  • Comparta la visión del propietario del producto / negocio . A menos que sepa hacia dónde se dirige el producto y cómo va a evolucionar, las pruebas serán muy limitadas.
  • Las habilidades multifuncionales son beneficiosas - Saber cómo probar la base de datos, cómo realizar evaluaciones comparativas de rendimiento, cómo habilitar certificados de seguridad, cómo implementar, etc. Sea curioso y explore .
  • No establezcas límites - No crea que evaluar el manual del usuario o consultar las preguntas frecuentes no es su trabajo y un redactor técnico debería encargarse de ello. Bueno, deberían y lo harán. Pero cuando lo ve como un conocedor interno como alguien que conoce el producto de adentro hacia afuera, sus comentarios son muy útiles.
  • Busque comentarios de los usuarios finales. El siguiente gran grupo de personas que realizan pruebas después de usted son los usuarios en tiempo real. Conozca y comprenda el tipo de problemas que enfrentan. Esto le ayuda a mejorar el diseño de su prueba para que la próxima vez sepa qué hacer para evitar esos problemas.
  • Trabaja rápido y toma decisiones
  • Evite la deuda técnica . En una situación de prueba y desarrollo rápido, es fácil probar exclusivamente de forma exploratoria y perder el marco de referencia para las versiones futuras. No dejes que esto suceda. Mantenga la documentación esquelética para que pueda rastrear, rastrear y medir

La mayor diferencia entre el software de prueba creado como servicio y el software creado como producto es que, en el primero, una vez que se llega a la estrategia de prueba, se aplica para todas las pruebas posteriores.

Sin embargo, para un producto, la estrategia de prueba debe cambiar dependiendo de la etapa del ciclo de vida actual en la que se encuentre el producto y los cambios en la dinámica del mercado (nuevos dispositivos, nuevos navegadores, etc.). La estrategia de prueba de productos debe ser mucho más flexible para cambiar.

Sobre el Autor: Este artículo es publicado por Swati S., miembro del equipo de STH.

Esperamos que este artículo te haya sido de utilidad. No dude en publicar sus comentarios, preguntas y comentarios a continuación.

Lectura recomendada

^