Informe final de Quality Assurance

Transcripción

1 Proyecto ScrumCeption Informe final de Quality Assurance Hernán Esteves 23 de noviembre de 2015 Historia de revisiones Fecha de la revisión Versión Descripción Autor 20/10/ Version inicial Hernan Esteves 21/10/ Análisis por sprint y Code score Hernan Esteves 22/10/ Desarrollo por sprint y evaluación del autor Hernan Esteves

2 Índice 1. Resultados finales de calidad Evaluación de los atributos de calidad Mantenibilidad Usabilidad Seguridad Actividades de calidad realizadas vs planificación Código Documentación Evaluación por sprint 4 Sprint Sprint Sprint Sprint Sprint Sprint Sprint Evaluación final del responsable 6 Informe final de Quality Assurance 2

3 1. Resultados finales de calidad El cliente manifestó la necesidad de contar con un producto que satisfaciera los siguientes atributos de calidad: Mantenibilidad Usabilidad Seguridad en los datos 1.1. Evaluación de los atributos de calidad Mantenibilidad Para la evaluacion de la mantenibilidad se utilizaron las métricas brindadas por CodeClimate y se utilizaron estándares de codificación tanto para JavaScript como para Ruby. Los resultados finales del GPA de CodeClimate son los siguientes: Figura 1: Code score over time Como se puede observar, en el último tramo, el puntaje disminuyó mucho, obteniendo un 1.74 en el peor caso. Esto se puede relacionar con la cantidad de lógica introducida en el sprint 3. En el sprint 4 el equipo se propuso corregir esto y aumentar el puntaje, no aceptando PRs que lo disminuyeran. El puntaje aumentó nuevamente cuando se realizó el rediseño del modelo. Usabilidad La usabilidad y lo amigable de la interfaz fueron evaluados directamente con las impresiones del cliente, nuestras y de la directora del proyecto. Además, para evaluarla de forma objetiva, se realizó un test de usabilidad en la semana XX Informe final de Quality Assurance 3

4 con dos personas de la empresa que nunca habían visto el producto. Esto aportó significativamente en la usabilidad final lograda. De todas maneras, al no ser planificada con anticipación suficiente, se hubiera deseado poder realizar dos pruebas de usabilidad: una al principio y otra al final. Seguridad La seguridad en los datos significó guardar las contraseñas encriptadas de los usuarios en la base de datos y en caso de requerir autenticación con otro sistema (como fue el caso de JIRA) se consultó al cliente para que seleccionara entre los dos métodos de autenticación Actividades de calidad realizadas vs planificación Actividad Semana/s de realización Semana/s de realización planificado Estandarización de documentos 2 No planificada Plan de calidad 3 3 Ajuste del plan de calidad 9 4 a 12 Revisión de documentos Todas Todas Inspección de código 7 a 14 7 a 14 Test de usabilidad Revisión de ajuste al proceso 4 a 12 4 a 12 Relevamiento de atributos de calidad 2 y 3 2 y 3 Código Para esandarizar el código se definieron estándares de codificación tanto para JavaScript como para Ruby. En el caso de JavaScript se utilizó Closure Linter y Ruby se utilizó la guía en cita. Documentación Para la documentación se optó realizar plantillas predefinidas en L A T E Xcon el fin de eliminar el trabajo de formateo. Esto implicó un mayor esfuerzo inicial de elaboración de las plantillas pero a largo plazo fue muy beneficioso ya que no hubieron problemas de formateo en las revisiones posteriores. 2. Evaluación por sprint Sprint 0 Este sprint tuvo una duración de 3 semanas y consistió en el relevamiento de requisitos. Informe final de Quality Assurance 4

5 Los estándares de documentación definidos impactaron negativamente con el proceso, haciendo la documentación y revisión tediosa debido al costo del formateo de los mismos. Por lo tanto, se definió un nuevo estándar en la documentación con el fin de acabar con la carga de formatear los documentos cada vez que se revisaban. En el futuro esto ayudó al proceso en forma sustancial. Aquí fue realizada la primera versión del plan de calidad. Sprint 1 Los procesos en este primer sprint fueron evidentemente inestables, debido a que es la primera vez que se trabaja en un proyecto Scrum por parte de los integrantes. El mayor problema identificado en este sprint fue que se invirtió mucho tiempo en estudio de las tecnologías, que hubiera sido deseable en el sprint anterior. Se definieron subgrupos de trabajo, siguiendo la metodología ágil, y esto sin dudas mejoró el apego al proceso. En este primer sprint ocurrieron problemas en los mensajes de los commits (mensajes inadecuados), lo cual se corrigió a futuro para mantener una historia limpia de los commits. Sprint 2 En este segundo sprint, los procesos siguieron siendo inestables pero cada vez ajustandose más. Por ejemplo, se subdividió el grupo para la realización de tareas, lo cual fue escencial para trabajar en forma más ágil. Sprint 3 Este sprint puede considerarse que es el que tuvo el menor rendimiento de todos. Este fue un sprint singular, el cual fue dedicado expresamente a corrección de bugs. Es algo que no debería haber sucecido, y una evidencia de que se necesitaba más testeo en cada sprint para entregar un producto de calidad. En el mismo, se realizaron tareas a la que el equipo nunca se había comprometido con el supuesto objetivo de adelantar trabajo; lo cual se puede decir hoy que algunas fueron en vano ya que en los sprints posteriores nunca se acordó con el cliente la realización de esas historias. Esto fue un punto de inflexión en el proyecto. Fue un sprint donde el trabajo fue dejado a último momento y se sobrecargó al equipo de testing. La revisión de PRs no estaba siendo ágil, por ende se asignaron más recursos en la segunda semana y se obtuvieron mejoras. En este sprint, sin embargo, se incorporó el testeo de frontend inicial con Karma. En las retrospectivas hechas en este sprint se identificaron todos estos aspectos negativos que fueron mejorados en los próximos. Informe final de Quality Assurance 5

6 Sprint 4 Este cuarto sprint fue un sprint normal, tranquilo, sobretodo en la primera semana, aunque en la segunda semana se siguió cumpliendo la ley de Parkinson. Todas las cosas detectadas en las retrospectivas anteriores se mejoraron. Este sprint involucró un rediseño en la interfaz a pedido del cliente, ya que no se sentía a gusto con la misma. En la demo del sprint se pudo apreciar la satisfacción del cliente con el incremento en la usabilidad que esto brindó. El problema principal en este sprint fue que todavia se mantenía el diseño erróneo inicial, y el código tuvo su pico más bajo con un puntaje de Como SQA, hubiera sido deseable poder evaluar la posibilidad de establecer requerimientos en el GPA de CodeClimate para aceptar los PRs antes y no a esta altura. Sprint 5 Un sprint que involucró un refactoring en el diseño, lo cual fue un gran empujón para la calidad del código y mantenibilidad del mismo, aunque obviamente implicó un gran esfuerzo a esta altura. Este sprint también incluyó el test de usabilidad y como consecuencia, reajustes de interfaz para incrementar aún más la usabilidad del producto. Como aspecto negativo en los procesos, puedo mencionar la falta de pair programming entre los integrantes. La subdivisión de grupos no fue explícita y hubieron historias grandes asignadas a integrantes particulares. Sprint 6 Este sprint fue el de menor duración (1 semana) y el final. Como tal, se centró en incorporar features pequeńas, llegar al cubrimiento de testing requerido y dejar un sistema estable. Se realizaron testeos finales exhaustivos y se encontraron bugs importantes que fueron corregidos obteniendo un producto final con un nivel de estabilidad suficiente. 3. Evaluación final del responsable Como responsable de Quality Assurance, considero que el producto obtenido satisface los atributos de calidad propuestos destacando que aún se pueden mejorar mucho dichos atributos, especialmente el de mantenibilidad, el cual considero aceptable. Como aspecto que considero importante a mencionar, la falta de comentarios por parte de los desarrolladores fue grande y es algo que se podría haber ido notificándo con mayor frecuencia para poder incorporar el buen hábito, y de esta forma la calidad del producto. El diseño inadecuado realizado al comienzo del desarrollo fue el causante del mayor impacto negativo en la mantenibilidad lo cual nos deja claramente una moraleja. Como integrante presencial de las demos, considero que tuvieron un rendimiento inaceptable; no fueron preparadas en su totalidad, y aunque se reiteró esto en varias ocasiones y se obtuvieron mejoras, no superaron un nivel aceptable. Informe final de Quality Assurance 6

7 A comienzos del desarrollo, los procesos seguidos tuvieron muchas desviaciones respecto a las metodologías ágiles pero esto se fue ajustando y mejorando en el correr de los sprints. Como aspectos a destacar, fueron la separación de tareas en subgrupos y log diario por Slack. La estimación de las tareas tuvo una mayor precisión que se notó con el correr del tiempo. Cabe destacar también la incorporación de deploys directamente en Heroku por cada PR hecho. Respecto al testing, considero que hubiera sido escencial el desarrollo de tests de integración automatizados que cubran los flujos suficientes de la aplicación para que todos los integrantes puedan aplicarlos, lo cual no fue logrado en su totalidad. Sin embargo, hay que destacar la calidad en la documentación, registro y análisis de las pruebas funcionales realizadas a lo largo de las semanas. La integración continua con CodeClimate y Circle CI fueron fundamentales para obtener un producto de calidad. Es importante mencionar también que se logró realizar el test de usabilidad, que estamos convencidos de que fue una gran ayuda para aumentar la usabilidad. Si bien pudieron haber muchísimas mejoras, estoy conforme con el producto que hemos logrado y esperamos que el cliente también :) Informe final de Quality Assurance 7