Ingeniero QA: Organizando un workflow QA

Compartir esta publicación

En este artículo compartiré mis experiencias como ingeniero QA organizando un workflow QA desde 0 dentro de un proyecto. Aquí podrás encontrar respuestas a preguntas frecuentes como: cuál es el propósito de tener un ingeniero QA en un proyecto, qué hacer si eres el único QA en un proyecto o cómo organizar el proceso QA de un proyecto.

Un primer punto muy útil y recomendable es hacer las preguntas adecuadas a la persona adecuada. El segundo punto es proponer tu solución, tu visión sobre la resolución de problemas que pueda ser discutida de antemano.

Las preguntas que puedes hacerle a tu jefe pueden ser:

  • Cuál es la estructura de la empresa, quien es responsable de qué.
  • Con qué expectativas contrata una empresa a un ingeniero QA.

Creando una Estrategia QA

I·Introducción a la Quality Assurance

Una buena manera de recordar a tu equipo qué significa Quality Assurance (QA) es preguntarles precisamente qué significado le darían ellos. Creedme, siempre hay alguien que no entiende qué significa QA aplicado al mundo del desarrollo de software. Lo he vivido en primera persona: a la pregunta de “¿sabes qué significa QA?”, un tipo me respondió “sí, claro, es alguien del equipo de apoyo, el responsable de “preguntas y respuestas”. Me quedé en shock. ¿De verdad? Confundió Quality Assurance (QA) con Questions & Answers (Q&A), y tenía más de 5 años de experiencia como programador 🙂

 

A lo largo del artículo usaré algunas citas sobre términos QA frecuentes sacadas de distintas Wikis, ISTQB, etc…

  Test de accesibilidad

Si quieres dejar claros algunos puntos a tu equipo, esta cita te puede resultar muy útil:

Las pruebas son parte del QA. Nos permite determinar el nivel de calidad de las features que estamos evaluando. No es solamente responsabilidad de los testers hacer QA. El equipo entero puede y debe contribuir para asegurar un nivel de calidad óptimo de los productos y servicios que se entregarán.

II·Explicación de una Estrategia QA

La segunda parte es explicar el propósito de un plan estratégico QA a tu equipo.

La Estrategia de Pruebas es un documento en evolución que detalla los procesos y maneras en que vamos a asegurar la calidad de nuestro producto en adelante.

Este es un documento que que puedes usar en tu ciclo diario de desarrollo en un proyecto. Llegados a este punto puedes hablar más en profundidad acerca de la Estrategia de Automatización de Pruebas, Plan de Pruebas, Enfoque de Pruebas (definir el proceso de pruebas, niveles de pruebas, roles y responsabilidades de cada miembro del equipo por cada tipo de test definido en el plan (unitarias, de integración, de sistema, de regresión, etc… )).

III. Explicación del Enfoque de Pruebas

¿Qué es el Enfoque de Pruebas? Para ahorrarte tiempo leyendo terminología típica sacada de internet, permíteme simplificarlo con una sencilla frase: El Enfoque de Pruebas es cómo se llevarán a cabo el test. Para hacerlo aún más claro, vamos a comparar estos dos términos: Enfoque de Pruebas y Estrategia de Pruebas. La Estrategia de Pruebas – es qué vamos a testear; qué recursos necesitaremos y qué riesgos deberemos evitar. Por otro lado, El Enfoque de Pruebas – es cómo vamos a hacer el test; una lista de escenarios que vamos a cubrir.

  ¡Primero el proceso!

Típicamente se usan estos dos Enfoques – Proactivo y Basado en riesgos:

Proactivo – Significa que el proceso de diseño de pruebas se inicia lo más temprano posible de cara a encontrar y arreglar los defectos antes de crear la build.

Basado en riesgos – Se basa en la idea de que podemos organizar nuestras pruebas de forma que se reduzca el nivel residual de riesgo del producto cuando se envía el sistema. Las pruebas basadas en riesgo se usan para priorizar y enfatizar las pruebas apropiadas durante la ejecución.

IV·Explicación del Proceso de Pruebas

El Proceso de Pruebas típico incluye los siguientes pasos:

  • Planificación (determinar el alcance)
  • Análisis y diseño (condiciones de pruebas, diseñar las pruebas)
  • Implementación y Ejecución
  • Reportar

En resumen, para un Ingeniero QA esto se traduce en la siguiente lista: empezar planificando, seguir trabajando en la documentación, crear los casos de pruebas y acabar el proceso con la ejecución, reporte y retro.

Otro punto del Proceso de Pruebas es definir quién es el responsable de cada tipo de Nivel de Pruebas (p.e. Puede ser que los desarrolladores sean responsables de las pruebas de carga e integración, y el QA cubra las pruebas end-to-end) y definir la Estrategia de Automatización QA.

Las responsabilidades en un proyecto es uno de los elementos más importantes que afectarán sus posibilidades de éxito. En los proyectos actuales de desarrollo de software cada trabajador es parte de un gran sistema. Así, podemos tener en cuenta que cada miembro del equipo es un tester, y el Ingeniero QA es el mayor experto en la funcionalidad del producto y la estabilidad del sistema. Su principal misión – evitar los bugs y satisfacer al cliente final con un producto final eficiente.

  Framework Cypress: Una Navaja Suiza para tus Tests

Para la interacción entre miembros – una de las técnicas más útiles es el Three amigos agile approach.

Colaboración entre Negocio, Desarrollo y QA

  1. Negocio — ¿Qué problema debemos solventar?
  2. Desarrollo — ¿Cómo podemos crear la solución al problema?
  3. Testing — ¿Qué puede pasar durante el proceso?

V·Documentación

Hoy en día casi todo el mundo trabaja con metodologías Agile Scrum methodologies, con sprints de 2 semanas, etc… Así que es muy recomendable tener una documentación bien hecha donde se describa cada paso del trabajo diario. Por ejemplo, un workflow detallado que incluya definiciones de “hecho”, glosario de términos, etc…

En conclusión, me gustaría decir que deberías cuidar mucho tu documentación, la cual debería estar al día. También mencionar que la comunicación siempre es la clave, así que explica a tus colegas sobre el maravilloso mundo del testing, y no dudes en hacerles preguntas. Y eso es todo, amigos 😉 Happy Testing.

One Comment

  1. Alba

    Me ha gustado el post mucho.
    Quería preguntarte, si me podrías dar alguna noción sobre las estimaciones del QA junto a las del equipo.
    Estimar juntos la historia o por separado?
    Juntos, cómo sería? Pues los diferentes desarrolladores al no tener conocimientos de QA no sabemos cómo estimar el global de la tarea, nuestro trabajo y el de la QA en este caso.
    Muchas gracias de ante mano.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Suscríbete a nuestro boletín de noticias

Recibe actualizaciones de los últimos descubrimientos tecnológicos

¿Tienes un proyecto desafiante?

Podemos trabajar juntos

apiumhub software development projects barcelona
Secured By miniOrange