8. Gestión de calidad
8.3 Aseguramiento de calidad
d de una iteración Revision de codigo
Código revisado Pull request, revisión de a pares
Sprint review
Mejoras en los
procesos
Sprint backlog, código fuente
Sprint retrospectiv e
Mejoras en los
procesos
Sprint backlog, código fuente
Implementa
ción de
pruebas unitarias
Pruebas unitarias codificadas
Product backlog,
Testing
Diseño de casos de prueba
Planilla de casos de prueba
ESRE
Pruebas de usabilidad
Reporte de pruebas de usabilidad
Pruebas de usabilidad / Prototipos
Pruebas de portabilidad
Reporte con lista de incidentes
Jira, Plan de pruebas
Verificación con testing funcional
Reportes de ejecución de testing
Aplicación, Plan de pruebas
Validación con pruebas con usuarios
Pruebas con usuarios y prototipos
Aplicación
Tabla 27: Actividades del plan de calidad.
mismo tiempo, le permite al equipo reducir la cantidad de errores y en caso de que aparezcan que todos sepan cómo corregir esos defectos.
8.3.1. Uso del inglés
Todo el código fue desarrollado en el idioma inglés, si en algún momento es necesario incorporar nuevos desarrolladores al equipo, la comprensión del código no será un problema ya que el inglés es el idioma estándar para el desarrollo.
8.3.2. Estándares de código
Debido a que en el proyecto se manejan códigos con dos lenguajes diferentes, fue necesario aplicar ciertos estándares para obtener un código mantenible. A su vez, el equipo siguió varios de los estándares que se plantean en el libro Clean Code de Robert C. Martin[59].
Específicamente, los estándares seguidos para cada tecnología fueron:
Tecnología Estándar
Flutter Flutter: Best practices and tips[60]
Ruby on Rails Rails Development: Coding Conventions & Best Practices[61]
Tabla 28: Estándares de código.
8.3.3. Estándares de documentación
La Universidad ORT Uruguay provee de ciertos estándares que espera que todos los proyectos de final de carrera cumplan. Estos mismos fueron los que el equipo siguió para el desarrollo de la documentación. Los estándares aplicados fueron:
Documento Descripción
302-Fi Normas específicas para la presentación de trabajos finales de Carrera de la Facultad de Ingeniería.
303 Hoja de verificación de formato de trabajos finales de carreras de la facultad de ingeniería.
304 Normas para el desarrollo de trabajos finales de carrera.
306 Orientación para títulos, resúmenes o abstracts e informes de corrección de trabajos finales de carrera.
Tabla 29: Estándares de documentación 8.3.4. Estándares para control de versionado y repositorios
El equipo decidió que el backend y el frontend de la aplicación estuvieran cada uno en un repositorio separado. Para ambos proyectos se utilizó Github. Por otra parte, para el manejo de la documentación a lo largo de todo el proyecto se utilizó Google Drive.
8.3.5. Revisiones
Las revisiones fueron de vital importancia a lo largo de todo el proyecto para poder detectar oportunidades de mejora en el producto y en el proceso.
Para las revisiones de código, el equipo utilizó la funcionalidad de pull request que ofrece Github. De esta forma, antes de que se subiera al repositorio lo que cada integrante programe, tendría que ser aprobado por los otros dos integrantes, esta modalidad se denominacode review.
Por otro lado, se realizaron distintas revisiones, algunas de estas fueron con el cliente, las cuales se hacían como parte de sprints reviews y también al final de cada release se hace una revisión más grande yendo a probar el producto que se tenía en ese momento al bar. A su vez, también se realizaron otros tipos de revisiones en las cuales distintos expertos de la universidad hacían comentarios sobre el proyecto.
De estas revisiones con expertos, la primera fue con Gastón Mosques, quien le
atributos de calidad más importante dentro del proyecto, por lo que aportó mucho y se tuvo especial énfasis en la misma. Por último, pero no menos importante, el equipo tuvo una revisión con Amalia Álvarez, para relevar las actividades que se realizaron para el aseguramiento de calidad del proyecto.
Finalmente, el equipo cumplió con las tres revisiones formales que la Universidad ORT fija a lo largo del proyecto. Las misma constan en presentar los avances que el equipo realizaba a lo largo del tiempo y se recibe una devolución la cual sirve para detectar áreas a mejorar.
Estas revisiones fueron primero con Leonardo Scafarelli, luego con Rafael Bentancur y por último con Amalia Álvarez. Para todas estas se realizaron informes los cuales se encuentran en el Anexo 12.1. Informes de revisiones
Por último, una vez puesto el piloto en marcha en el bar, se le realizó al cliente una entrevista de satisfacción. La misma constó en una serie de preguntas y respuestas con el fin de poder evaluar el trabajo que se realizó desde la perspectiva del cliente.
La misma se puede ver en el Anexo 12.11. Entrevista de satisfacción del cliente.
8.3.6. Validación
El equipo consideró crucial que las validaciones sean realizadas por potenciales usuarios, por lo que se mantuvieron varias instancias de evaluación con potenciales usuarios finales, tanto como en la etapa de ingeniería de requerimientos como luego durante el desarrollo.
8.3.7. Pruebas
8.3.7.1. Pruebas unitarias
Una de las formas en la cual el equipo se aseguró que estaba construyendo un software de buena calidad fue mediante la implementación de pruebas unitarias sobre todas las funcionalidades del backend. Esto implicó el desarrollo de pruebas unitarias para cada una de las historias de usuarios relacionadas albackendque se encontraban en cadasprint.
Ruby on Rails tiene la ventaja de que al momento de crear el proyecto por defecto ya crea un directorio específico en el cual se pueden implementar todas las pruebas del sistema. El equipo aprovechó esta funcionalidad de rails y por lo tanto todas las pruebas fueron realizadas allí sin la necesidad de utilizar unframeworkde terceros.
Antes de subir el código al servidor, las funcionalidades nuevas programadas tenían que haber pasado todas sus pruebas unitarias correspondientes para así de esta forma poder reducir riesgos de incidentes y al mismo tiempo mejorar la calidad del código.
8.3.7.2. Pruebas funcionales
Con el fin de asegurarse que todas las diferentes pantallas del frontend iban funcionando de forma correcta a medida que se iban implementando, el equipo optó por hacer pruebas funcionales periódicamente a todo el frontend del sistema. De esta forma, en conjunto con los otros tipos de pruebas, se aseguró el sistema en su completitud (frontendybackend) estuviese probado.
A continuación, se deja un ejemplo de un caso de prueba funcional realizado:
Identificador CP32.2
User Story asociada US32
Descripción Agregar producto a carrito
Pasos Ingresar a la aplicación
Seleccionar un producto del carrito
Seleccionar cantidad de ese producto a agregar Click en ‘Agregar al carrito’
Resultado esperado El producto se agrega al carrito correctamente Tabla 30: Ejemplo de caso de prueba funcional.
diferentes dispositivos de iOS y Android en diferentes resoluciones. Por otra parte, también se probó en distintas tablets la terminal autoservicio para asegurarse que no solo funcionara correctamente en un dispositivo. A continuación, se deja evidencia de estas pruebas:
Dispositivo Aplicación Sistema operativo
Tamaño pantalla
Captura
Nexus 9
Terminal Autoservicio
(Flutter)
Android 8,9’’
Pocophone x3 nfc
Aplicación móvil (Flutter)
Android 6,67’’
Pixel 3 XL Aplicación móvil (Flutter)
Android 6,3’’
iPhone 12 Pro Max
Aplicación móvil (Flutter)
iOS 6,7’’
Nexus 9
Aplicación comandas
cocina (Flutter)
Android 8,9’’
Tabla 31: Pruebas de portabilidad.
8.3.8. Satisfacción del cliente
Fue de suma importancia la buena comunicación que hubo con el cliente a lo largo de todo el proyecto. A través del grupo de WhatsApp, y también mediante las conversaciones que se mantuvieron en el bar, se iba recibiendo retroalimentación continua del cliente.
Esto fue crucial para llegar a un producto final en el cual el cliente se sintiera satisfecho con el mismo, era muy importante que el cliente se sintiera parte de este desarrollo y pudiera ir opinando a lo largo de todo el proceso sobre posibles mejoras y nuevas funcionalidades.
Fue así como una vez finalizado el tercer release y puesto en marcha el piloto, el cliente sintió que el software desarrollado por el equipo le aportaba valor a su
Una vez finalizado el proyecto, se le realizó una entrevista al cliente con el fin de evaluar el trabajo realizado por el equipo desde su perspectiva.
La entrevista se puede ver en el Anexo 12.11. Entrevista de satisfacción del cliente.