Guidelines QA

1. Formato de prueba básico: Este formato permite elaborar los casos de pruebas básicos para cualquier sistema https://docs.google.com/document/d/1aVFQOuZehDD0SekwWOpBB1m1dxg_Hi_MB1WwQwq0Vs8/edit?usp=sharing
2. Spreadsheet de pruebas: Este formato permite elaborar un caso de pruebas básico especial para pruebas con entornos web https://docs.google.com/spreadsheets/d/1fWzDWjsZwDTJpfclF82wKzV8SMnHjqUHo1-x-4f6bVM/edit?usp=sharing

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

Partiendo del Kickoff el QA recibe la información detallada de cada tarea / requerimientos, en donde define para cada uno de ellos lo siguiente:

• Roles / Usuarios
• Validaciones
• Pre-requisitos
• Recursos

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

• Aspectos funcionales
• Aspectos No funcionales
• Aspectos visuales

• Dependiendo de la envergadura del proyecto se debe evaluar si la prueba se basa en el desarrollo del user Story o en la elaboración de los casos de prueba
• Documento de prueba básico:

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:

• Productividad
• Analítico
• Crítico
• Práctico

• La capacidad de abstracción para analizar y entender el comportamiento del desarrollo en diferentes circunstancias para no solo detectar fallas sino prevenirlas
• Capacidad comunicativa de forma oral y escrita para interactuar con los desarrolladores y usuarios así como también para documentar los casos de prueba
• Visión para el modelado de las simulaciones para las pruebas
• Debe crear un entorno de pruebas idóneo lo más ajustado a las condiciones reales
• Debe definir lo más ajustado a la realidad los tiempos de pruebas, cuando se realizan pruebas precipitadas se dejan escapar las fallas
• Debe tener un pensamiento crítico para evaluar y analizar, hacer deducciones y definir los criterios que aportan calidad a la solución de las tareas
• Debe ser pragmático para ejecutar las tareas evaluando la relación de esfuerzo, alcance del proyecto y calidad

• Analiza las tareas / requerimientos
• Genera el documento de diseño de casos de prueba definiendo los tipos de pruebas
• Ejecuta las pruebas
• Reportar un bug

   1. Asunto: EOD
   2. Contenido
    * Qué trabaje:
    * Qué terminé:
    * Cuales fueron los bloqueos:
    * Qué voy a trabajar:

• Browserstack
• Servidor de pruebas
• Dispositivos (complementaria para ver problemas que no se pueden reproducir en browserstack)

• Son aquellas que que evalúan lo que el sistema debe hacer
• Las Funcionalidades pueden estar descritas en las especificaciones de requerimientos, especificaciones funcionales, casos de uso e inclusive no estar documentadas
• Los casos de prueba se definen a partir de estas funciones o características, así como su interoperabilidad entre sistemas
• Flujo: Tener claro por cada ticket como hacer la tarea. Una vez que se tiene el flujo, hay que interactuar con todos los elementos posibles y de maneras distintas:
  • Formularios: Probar llenando el formulario bien, con data incorrecta, haciendo errores adrede, saltando validaciones, dejándolo vacío, llenándolo a medias, etc. Hay que probar todos los botones, todas las posibilidades.
  • Roles: tener en cuenta que hay tareas que necesitan un rol en específico. Si es así, igualmente intentar con otros roles para validar permisos. Si hay alguna funcionalidad que debe estar limitada por permisos, igual tratar de ejecutar la acción a la que no se tiene permiso
  • Probar con distinta data y ver cómo se comporta la aplicación
  • Simular casos no reales de data ingresada: buscar el punto de quiebre de la aplicación
  • Hacer un flujo varias veces y validar que sea consistente los resultados
  • Estar pendiente de la integridad de la data: lo que se ingresa es lo que se debe mostrar

Evalúan cómo funciona el sistema, o sea, su desempeño, usabilidad, mantenibilidad, confiabilidad, portabilidad, estrés

• Revisar las páginas implementadas contra los diseños. Tener en cuenta los siguientes elementos:
  • Tamaño/Proporción de los bloques: Puede que los bloques no miden exactamente lo mismo que el diseño pero debe guardar la proporción. Estos deben ser casos justificados: el diseño no está hecho sobre un sistema de grid, el diseño no contempló algún factor. Revisar posición dentro del diseño, si guarda espacio con los elementos adyacentes
  • Tipografías: Revisar el tipo de fuente, el tamaño del texto, el color del texto, el peso (negrita, regular, delgada). Revisar el espaciado entre el texto y los elementos adyacentes
  • Botones: Revisar estados (normal, hover, focus)
  • Inputs: Revisar placeholders, revisar cuando hay texto (data) ingresada, revisar estados de los campos (error, validado)
  • Imágenes: Revisar calidad de imágenes, tamaños, proporciones, compararlo contra el diseño. Header/Footer: Revisar tamaños, comportamiento, espaciados entre menu items, interlineado entre enlaces, sombras.
  • Probar como un usuario autenticado y como un usuario anónimo
• Diseño responsivo
  • Tamaño textos: idealmente el tamaño de los textos deben cambiar a medida que la pantalla cambia: si es una pantalla chica no deberían haber textos ni muy grandes ni muy chicos.
  • Posición de elementos: En pantallas reducidas se tiende a poner elementos uno encima del otro y priorizar contenido importante.
  • Formularios: Se debe tratar de que los inputs ocupen el ancho del dispositivo en móviles. Para tablets se pueden manejar labels a los lados de los inputs. Debe ser fácil de poder seleccionar cada input e ingresar data.
  • Para temas visuales, se puede usar el simulador del navegador o un simulador de dispositivo. Para probar un comportamiento o un flujo, idealmente se debe usar un dispositivo real para probar. No siempre el simulador del navegador servirá porque se interactúa con el mouse.
  • Menús: Analizar comportamiento, estructura y estilos de un menú para dispositivos móviles. Fijarse en animaciones y transiciones que a veces no son fluidas.

Evalúan nuevamente la aplicación después de haber identificado un Bug y su respectiva corrección

Debe considerarse:

• La prueba nuevamente de la tarea que fue reportada
• La prueba de los componentes relacionados a esa tarea

Evalúa el sistema en el ambiente de producción en todos sus ámbitos, Funcionales, No funcionales y visuales

• Cuando se realiza la migración a un nuevo servidor se debe evaluar el comportamiento del sistema en el nuevo servidor
• Si las pruebas son de actualización de plataforma se debe probar que todos los módulos vinculados al sistema hayan sido articulados exitosamente
• Si se realizó una desincorporación de algún módulo se debe verificar que este no haya rotos el flujo o interacción de otros módulos en el sistema