Es hora de hablar de Calidad

QA Lovers® está especializada en el estudio, definición e implantación de servicios de pruebas de software. Somos expertos en implementación de procesos y metodologías de control de calidad que eficientan proyectos y mejoran el día a día de las personas.

Únete a la Comunidad Newsletter mensual

Ayudamos a...

Eficientar

Gracias a la experiencia a lo largo de los años, hemos dado forma a una metodología única con la que ayudamos a mejorar procesos de QA: QCIM® (Quality, Control, Intelligence, Methodology).

Más info

Mejorar

Estudiamos la madurez y situación inicial de empresas en relación a pruebas de software, además de crear, diseñar y poner en marcha procesos de eficiencia profesional.

Más info

Garantizar

Realizamos todo tipo de pruebas de software y ponemos todo el empeño en nuestro principal objetivo: asegurar la calidad global del producto a lo largo de todo su ciclo de vida.

Más info

Formar

Somos especialistas en formación y certificación, por ello, ofrecemos el único Master de QA del mercado. Además, contamos con formación personalizada y adaptada a cada persona.

Más info

El Blog

Mostrando entradas con la etiqueta Plan de Pruebas. Mostrar todas las entradas
Mostrando entradas con la etiqueta Plan de Pruebas. Mostrar todas las entradas

14 de septiembre de 2019

¿Cómo podemos estimar nuestros ciclos de pruebas?

Cuando hablamos de estimar pruebas, sabemos que no es una de las tareas más sencillas que podemos hacer, más que nada, porque son muchos los factores que afectan a ello.


Uno de los factores que más cohíben una estimación son las fechas, que ya suelen estar marcadas y nos hace que nos tengamos que ajustar a tiempos predefinidos y encajados en ciclos de desarrollo y de vida del producto que queremos probar.

Existen una serie de técnicas que podemos poner en práctica para que podamos estimar, más o menos, de una manera coherente y acertada, pero siempre cogiéndolo con pinzas.

Si estamos trabajando en un entorno Agile, para estimar, lo primero que tenemos que tener son las historias de usuario o las especificaciones funcionales, libre de dudas y con toda la información posible para determinar nuestro plan de pruebas o al menos, su esqueleto.

Si, por el contrario, existen dudas ya sean funcionales o a nivel técnico, debemos de mantener las conversaciones necesarias para que todo quede claro.

Una vez tengamos ese punto claro, que quizá es el más importante, debemos de tener unos porcentajes de aumento sobre lo que nos lleve la simple ejecución de las pruebas. Estos porcentajes deben de darse utilizarse con el análisis inicial de las pruebas, la obtención de los juegos de datos, la posible instalación del entorno (si no la realiza el equipo de DevOps), la propia ejecución y todo el ciclo de vida de los defectos.

Tras ello, también podemos tener tiempos de periodos de gracia o garantía sobre lo que se ha puesto en producción, además de las pruebas de regresión mínimas entre despliegues.

La primera etapa, como ya hemos comentado, es el análisis de los requisitos y el diseño del esqueleto del plan de pruebas, cosa bastante complicada de estimar, pero usando unos porcentajes, podemos determinar que nos llevará un 5% de las jornadas que lleve la especificación de los mismos. También es cierto, que, con los años y la experiencia, esto suele salir solo y ya solo con ver el documento por encima, ya puedes determinar lo que te va a llevar todo este trabajo.

Si hablamos de la obtención de un juego de datos coherente y adecuado para la realización de las pruebas, es casi “impepinable” el hablar de porcentaje, ya que dependerá de donde se saquen los datos, como serán de complejas las consultas y cual es la cantidad de casuísticas que hay que simular para realizar las pruebas completas.

De cara a estimar la ejecución de los casos de prueba, siempre me suele basar en la misma premisa, tomar una media entre el caso de prueba más largo y el menor, dando como resultado, habitualmente unos 6 o a 10 minutos máximo, posibilitando que una batería de unos 70 u 80 casos se pueda realizar en 3 jornadas (siendo los casos de prueba medios y con una complejidad normal).

También, se puede realizar una métrica con una primera ejecución exploratoria, haciendo un pequeño reconocimiento a la aplicación y verificando su complejidad, de esta manera, sabremos, a grandes rasgos, el tiempo de media que nos puede llevar la ejecución de los casos de prueba.

Hablando sobre la gestión completa de los defectos, dependerá, habitualmente de la cantidad de ellos que encontremos en las pruebas, pero haciendo una media básica, debemos de aumentar al tiempo de ejecución un 15% de apertura, reprueba y cierre de defectos. Esto, lo suelo detectar ya que, con una estimación muy a alto nivel y poniéndome en el peor de los casos (si el desarrollo se ha realizado adecuadamente) suelen fallar un 30% de los casos de prueba.

Del resto de aproximaciones, debemos de tomar las mismas técnicas, aumentando en porcentajes con nuestras experiencias pasadas, ya sea, en las pruebas de regresión al poner en producción o en otras tareas habituales en nuestro trabajo.

Lo esencial, es que podamos ir valorando diferentes tiempos que aumentarán o disminuirán en base a las entregas, sprint o ciclos de trabajo y que nos darán, poco a poco, información mucho más veraz sobre tiempos y donde irnos acercando, de manera más adecuada a la realidad de nuestro proyecto y de los futuros que podemos probar.


11 de enero de 2019

Detallando un plan de pruebas

El plan de pruebas es un conjunto de casos de pruebas que se encarga de probar una funcionalidad completa de un producto o software en concreto. Es una guía para la realización de las pruebas, con la ejecución de los casos de prueba y en base al resultado de los mismos, sabremos si el software cumple con las necesidades establecidas en el proyecto y cubre los estándares de calidad definidos.


Un plan de pruebas es la herramienta general de los profesionales dedicados a QA y a Testing y define el marco de trabajo en el que deben de apoyarse para que su trabajo sea efectivo y adecuado a lo largo de toda la vida del proyecto y del ciclo de vida del software.

Debe de realizarse a partir de los requisitos aportados en el proyecto o en las historias de usuario, depende de la metodología que se utilice. Además, se deben de realizar a partir de las especificaciones, del diseño funcional, del prototipado y de los casos de uso, entre otra documentación que se pueda obtener dentro del proyecto.

Un plan de pruebas es un elemento que debe de estar vivo a lo largo del proyecto, ya que se suelen añadir nuevas funcionalidades o requisitos y estos deben de ser cubiertos a lo largo de la vida del desarrollo del mismo.

De cara a garantizar que se cubre todo, se deben de identificar funcionalidades existentes (que se suelen sacar de toda la documentación y de reuniones que se realicen con el equipo y con cliente), pero hay una serie de componentes que pueden verse afectados por la arquitectura realizada en el proyecto y hay que tener en cuenta todo.

Hay dos tipos de modificaciones o ampliaciones dentro de un plan de pruebas, que han de tomarse en cuenta para que se pueda cubrir toda la funcionalidad existente:
  • Funcionalidades de usuario final: cuando se agregan nuevos módulos, pantallas o flujos en las funcionalidades que son utilizadas por el cliente o se ven visualmente.
  • Funcionalidades internas: son cambios internos que mantienen todos los elementos visuales de la misma manera, por lo tanto, el cliente final no observa ninguna modificación, pero al modificar componentes o flujos internos, como accesos a base de datos o a capas de lógica de negocio, deben de cubrirse con casos de pruebas dentro del plan de pruebas y cubrir toda la funcionalidad de este tipo.
Cuando se ejecuta un plan de pruebas al completo, quiere decir que se han ejecutado todos los casos de prueba que estaba adjuntos al mismo y en base al resultado de ellos, nos da el resultado final de plan de pruebas, pudiendo dar el OK final a la funcionalidad, módulo o software que se ha probado o el KO, abriendo los defectos oportunos y esperando a que sean solucionados para volver a ejecutar los casos erróneos y dar el OK definitivo si todo funciona como debe de funcionar.

No hay una pauta general para realizar un plan de pruebas, pero si que existen organismos como ISTQB, que nos dan unas pautas bajo su criterio. Cuando realizamos un plan de pruebas, el foco se debe de centrar más en el número y forma de los casos de prueba que lo completan y el resultado aportado en su ejecución, además, de centrarse en el objetivo para el que ha sido realizado y, despues, ejecutado.

Tres palabras nos definen

Integridad

  • Trabajamos sobre la honestidad y la honradez.
  • Sólo te proporcionamos lo que de verdad necesitas.
  • Siempre buscamos como cubrir tus necesidades.

Ética

  • Trabajamos sobre una conciencia de responsabilidad.
  • Adquirimos un compromiso con cada tarea realizada.
  • Nuestra satisfacción es el trabajo bien hecho.

Sostenibilidad

  • Exportamos conocimiento y somos una comunidad.
  • Creamos un entorno colaborativo en todo lo que hacemos.
  • Pensamos en personas y su talento, no en números y cifras.
587 Publicaciones
Exportamos todo lo que aprendemos
5576 Seguidores
Hacemos comunidad entre tod@s
3285 Días
Seguimos aprendiendo a diario

¡We will rock you!

QA Global®
tu tranquilidad nos motiva
QA Security®
Tecnología para protegerte
QA Insurance®
Cuidamos de tu futuro
¿Colaboramos?
Nos interesa saber tu proyecto

¿Hablamos?

Cuéntanos como ayudarte

Si quieres más información sobre lo que hacemos, necesitas ayuda o quieres hablar con nosotr@s, solo tienes que ponerte en contacto.

Teléfono:

(+34) 648 961 876