Para hacer uso de cualquier formato:
Pendiente = estatus inicial de un bug reportado Probar = bug puesto por el desarrollador como listo para probar nuevamente Sin error = el desarrollador vio lo reportado y en su ambiente y flujo de pruebas no hay error alguno en lo reportado Revisado / Rechazado = QA lo reviso y lo rechazo, revisar comentarios Resuelto = QA lo reviso y dictamina que el bug esta resuelto
Con este documento se busca explicar las competencias que debe tener un Tester que asegura la calidad de un proyecto de cualquiera que se su naturaleza
-Establecer las competencias, responsabilidades e importancia de este rol para Rootstack
-Definir ruta de procedimiento para el flujo general de pruebas
-Garantizar la calidad y seguridad del desarrollo
Los QA's en un proyecto: Estar en todos los Scrum's semanales, el PM es responsable de liderar la sesión para que sea productiva a nivel de objetivos para el desarrollador y QA, es decir debe de dirigir la comunicación de lo que se espera a nivel de QA y desarrollo de software.
No deben de estar en todas las sesiones de la semana, solo deben de estar en el scrum, el objetivo es que en el scrum se comuniquen todos los objetivos a nivel de forma del software, por lo cual el QA debe de quedar claro de lo que debe de probar
Van a ser más auto suficientes de poder probar en cualquier momento ya que no necesitan feedback a fondo del PM en cuanto a forma ni cuando las cosas se deben de probar ya que para eso el QA está en el Scrum.
Todos los user story deben estar bien documentados
Partiendo del Kickoff el QA recibe la información detallada de cada tarea / requerimientos, en donde define para cada uno de ellos lo siguiente:
Partiendo del tipo de tarea se debe clasificar cada una de ellas según su tipo, es posible que una de ella se deba considerar en los tres tipos y en ese sentido se debe considerar
https://docs.google.com/document/d/1aVFQOuZehDD0SekwWOpBB1m1dxg_Hi_MB1WwQwq0Vs8/edit?usp=sharing
https://docs.google.com/spreadsheets/d/1fWzDWjsZwDTJpfclF82wKzV8SMnHjqUHo1-x-4f6bVM/edit?usp=sharing
-El equipo de desarrollo genera el PR , el TL revisa el código y pasa la tarea a la columna de QA
-Al recibirlo se ejecuta los pasos de las pruebas
-Evaluar el estado de las tareas para saber de ellas qué es lo que se espera probar
-Si se hace una prueba en entorno móvil se espera que si hay un sitio web relacionado a ella, en primer lugar sea probado el sitio web
-Si se reporta una incidencia:
-Define la categoría del bug: Funcional, No funcional o Visual -Se revisa y analiza el log del sistema -Prioridad: P1: Detiene la aplicación, error fatal, se afecta la integridad de la data. Error visual muy evidente que afecta considerablemente la navegación/experiencia del usuario. P2: Error no tan grave funcional (se puede usar la aplicación y el error está limitado. No se afecta la integridad de la data.). Errores visuales evidentes pero que no afectan considerablemente la navegación P3: Error visual menor (detalles no tan evidentes) -Pasos para reproducir: Importante destacar cómo fue el paso a paso para poder replicar el error en ambiente de desarrollo Tecnologia Navegador/Version, Sistema operativo Evaluación de logs del sistema Screenshots/video Screenshot si es un detalle visual Video si es un error funcional o si hay alguna animación (a nivel visual) Cuando se corrige un error se debe volver a probar todo de manera que se garantice la integridad de las tareas ya probadas -Cierra / funcionalidades probadas *Funcionalidades: *Se debe grabar un video desde Browserstack para poder cerrar y dejar una evidencia en cada funcionalidades. Estos videos pueden ser usados para enviarselos al cliente como sustento. *En estos videos se debe demostrar que la funcionalidad sirve bien y soporta errores. *Se documenta en Jira y se pasa nuevamente a revisión *Se documenta en el https://docs.google.com/spreadsheets/d/1fWzDWjsZwDTJpfclF82wKzV8SMnHjqUHo1-x-4f6bVM/edit?usp=sharing *Si no se reporta Bugs pasa a la fase para aprobación de tareas -Aprobación de las tareas - Se reportan explícitamente de manera escrita y/o visual los resultados esperados en las pruebas para cada tarea - Se reporta al PM que la tarea fue probada y sin bugs para que este pase la tarea a la fase de aprobación / aceptación hacia el cliente
En Rootstack el QA está situado del lado del equipo técnico pero que garantiza que el negocio sea asegurado validando que los criterios definidos por el cliente sean cubiertos. Cuando se realiza esa evaluación hace posible que las tareas y/o requerimientos sean traducibles en criterios de aceptación entre el desarrollador y el cliente. En Rootstack el QA detecta y previene las fallas
A parte de todos los atributos de cualquier integrante de Rootstack se espera de nuestros PM:
End of day Es una práctica indispensable para un integrante de la organización, esto permite dejar explícita todas las tareas realizadas en el día de tal manera que el PM y las personas responsables están anuentes del estado de cada una de ellas. La práctica sería la siguiente: - 5 minutos antes de cerrar el día enviar un correo con lenguaje claro y sencillo a tu PM con la siguiente información:
1. Asunto: EOD 2. Contenido * Qué trabaje: * Qué terminé: * Cuales fueron los bloqueos: * Qué voy a trabajar:
Evalúan cómo funciona el sistema, o sea, su desempeño, usabilidad, mantenibilidad, confiabilidad, portabilidad, estrés
Evalúan nuevamente la aplicación después de haber identificado un Bug y su respectiva corrección
Debe considerarse:
Evalúa el sistema en el ambiente de producción en todos sus ámbitos, Funcionales, No funcionales y visuales