Tips para progresar en QA Testing de software.

  1.  Ser eterno estudiante: Estar siempre al tanto de todos los ámbitos del testing de software.

  2. Investigar nuevas ideas: Presenta al equipo de testing nuevas ideas e investiga.

  3. Sin miedo a exponer problemas: Propón nuevos problemas para dar mayor al proyecto y al cliente.

  4. Siempre tener evidencia de los tests: Guarda como archivos locales o como fuere, mantén constancia de todos tus tests.

  5. Mantener buena relación con los departamentos: Sobretodo con los de desarrollo, dado su conocimiento pueden ayudarnos a detectar las áreas de mayor riesgo de fallo en el software.

  6. No tomar las decisiones de la gerencia o del equipo de desarrollo de forma personal: Es mejor no influir de forma directa en decisiones de negocio o mercado, sobre las versiones que se vayan sacando. Pero sí es necesario alertar al equipo de la luz verde o roja que se pudiera dar. No tomemos a lo personal si la gerencia decide lanzar una versión al mercado con errores de los que hemos alertado, pues si hemos alertado, hemos cumplido con nuestro deber. 

  7. Proveer constantemente información sobre el estado de los errores y el estado de salud del sistema.

  8. Navega entre dos aguas: Crea los reportes técnicos o bugs, hablando entre el idioma del equipo y el idioma de los usuarios. Tenemos que comunicarnos de forma eficiente y óptima con el equipo empatizando con la perspectiva del usuario.

  9. Domina el negocio de la app que estás probando: Explora toda la aplicación, conócela mejor que nadie, date cuenta de errores importantes a la hora de enfocar las pruebas. Haz lo posible dentro del software y explóralo profundamente. Debes ser el miembro de la empresa que mejor conoce el uso del software sobre el que trabajas.

  10. Muestra tu trabajo: El QA Testing tiene tendencia a ser infravalorado en las empresas del desarrollo de software. Por lo que si eres un QA de automatización, muestra la ejecución de las pruebas y sus resultados en reuniones de retrospectivas. Por ejemplo, para el caso de proyectos ágiles, si eres un tester manual tienes que enfocarte en sacar la máxima cantidad de fallos high / críticos con el resultado consistente del informe de pruebas, puesto que esto muestra la importancia del desarrollo de software.

    Extra tip: Aprende a ejecutar diversos tipos de prueba y especialízate en una de ellas.
    Por ejemplo yo empecé como LQA Tester, pero tras casi 2 años, ahora trabajo de QA XR/VR/MR tester. ¿Qué otro tipo de pruebas me depararán proyectos futuros? 🤔🧪.
    ¡¡Solo sé que por ahora y junto a mi equipo, quiero y debemos ser el mejor depa de XR Testing de toda España!!

Comentarios

Publicar un comentario

Entradas populares de este blog

Ciclo de vida del defecto

 New > Assigned > Open > Fixed > Re-Test > Closed. Se abre el bug, se asigna a un lead, el lead lo asigna a un desarrollador, el desarrollador decide si lo soluciona, o bien, si lo deja pasar. Se manda para Re-testear desde dev a qa para verificarlo (estilo regresion), y si se ha solucionado, finalmente se pasa a closed/cerrado. Si se cierra entonces no se vuelve a reproducir más. A no ser que aparezca en nuevas actualizaciones. Hay que tener en cuenta que, al abrir el bug, el mismo puede aparecer duplicated /duplicado si se ha subido dos veces.  También puede rejected /rechazarse por alguna razón desde el departamento de desarrollo, pero si el QA considera que es un defecto, puede volver a reabrirlo y mandarlo de vuelta a desarrollo. Deferred , significa que el desarrollador lo rechaza, pero por alguna razón en concreto, por ejemplo, porque es un error que se conoce desde desarrollo y se va a solucionar para nuevas versiones (se usa muy poco, ya que el QA no ...
Leer más

¿Cómo integramos el software?

Para integrar pruebas en metodologías de software testing, podemos: Integrar componentes, para la creación de la batería de pruebas. Establecer una estrategia de integración de dichas pruebas para la batería de pruebas. Preparación del ambiente de prueba con un servidor y herramienta. Como por ejemplo, Qase. Establecer pruebas para cada actualización, por ejemplo los Test Run y basarnos en Test Plans. Además, existen otras 2 formas de integración del software. Pruebas Big-bang , llamadas así porque basa las pruebas en diferentes módulos o áreas dentro del proyecto. Por ejemplo, en LMDance, podría basarse en áreas de HUD/UI, o bien creación de perfiles, o bien Gameplay, o pruebas de conexiones.  Estas pruebas Big-bang, hacen hincapié en áreas independientes, como las ya mencionadas en el párrafo anterior. Por ello probamos el programa de manera completa e íntegra.  Pruebas Acendentes/descentes , más organizadas porque no van por áreas sueltas, sino que se prueba el software apa...
Leer más

Principios en pruebas de Software.

- Uno de los principios elementales del software testing, es que las pruebas muestran la cantidad de errores posibles, la cantidad de defectos. Pero no su ausencia.  Por ejemplo, para Samsung, el galaxy note 7 tuvo que ser retirado del mercado debido a que éste se incendiaba o explotaba tras cargarse durante varias horas. - Las pruebas exhaustivas son imposibles de realizar, o bien no existen. Un claro ejemplo, en cualquier proyecto de CHESS / ajedrez, habrían de realizarse infinitas pruebas respecto a los posibles movimientos.  Según IBM, corregir un defecto encontrado en post-producción, costará 30 veces más que en su etapa temprana. - Probar en la proporción adecuada, teniendo en cuenta la regla 80-20, el 80% de los fallos se podrían encontrar en un 20% de modos. - Cuidado con la paradoja del pesticida.  - Las pruebas dependen del contexto: No es lo mismo realizar pruebas que tiendan a perder vidas humanas, software médico, o económico, que probar una web que registre ...
Leer más