Cette fois-ci quelques réflexions sur le QA d'un cws contenant des nouvelles fonctionnalités.

C'est assez long de faire la QA sur ces parties du code que sont les nouvelles fonctionnalités car il y a pas mal de tâches à effectuer en dehors de simplement vérifier les issues qui font partie du cws.

Tout d'abord, lecture des spécifications (5 dans ce cas). C'est drôle que les développeurs n'aiment pas écrire les spécifications parce que tout le travail de la QA, de la localisation et de la documentation de l'aide, découle ensuite de ces spécifications. Sans celles-ci, impossible d'avoir une vision cohérente des diverses issues qui regroupent la fonctionnalité, pas de vision ux, pas de possibilité d'anticiper la localisation et la documentation avant qu'elle soit implémentée, donc trop tard pour faire un travail de qualité en amont et voir, pendant les tests, si c'est complet et implémenté de façon correcte.

Ensuite, ou en même temps, build des versions Linux et Windows. Là, gros problème, la ferme de bots que nous utilisons est saturée lorsque nous arrivons en période proche du features freeze. Cela fait 28 versions en attente de build pour Windows (à raison d'environ 6 h par build ça donne une idée du délai avant que la sienne soit dispo), idem pour Linux et pire pour Solaris. Il faut donc que nous fassions quelque chose pour ces bots, soit que le process d'utilisation soit plus cohérent, soit que nous en ayons plus.

Une fois les builds dispo, les VCLTestTools doivent être créés, ce n'est pas ma partie ;-) afin que la nouvelle fonctionnalité dispose des tests automatiques. Je me suis donc mise à la rédaction des TCS, tests manuels, qui permettent de tester tous les cas de figure de l'utilisation de la fonctionnalité en fonction de leur description dans les specs. J'ai donc écrit 3 TCS relatifs à plusieurs issues. En même temps que réaliser les tests que j'écrivais. C'est assez long, en cumulant les temps, c'est environ 3 jours d'écriture et de tests.
Viennent ensuite les tests automatiques, mais là, c'est connu, c'est environ trois jours entre le run, la vérification, le re-run et la mise en ligne sur QASTe.
Une fois que chacun a fini sa partie : automation, tests manuel, documentation de l'aide, le cws est approuvé par le QARep et l'intégration sera faite dans la prochaine version. Il faudra alors de nouveau tester les issues à l'aide des TCS et vérifier que tout se comporte comme annoncé dans les specs dans le master.

Tout est lié : les issues renvoient vers les TCS et les specs, les specs renvoient vers les issues et les TCS, les TCS renvoient vers les issues, les specs et l'automation. Pour exemple, voir l'issue 7049.

Ce lien permet alors à la localization de prendre le relais avant même que les fonctions soient intégrées dans la version et de s'assurer que la traduction, bien que complètement hors contexte, soit cohérente et exacte.
À nouveau, c'est un beau travail d'équipe, et je suis très contente d'avoir pu contribuer dans les délais à ce que ces nouvelles fonctionnalités soient intégrées à la 3.2. Un grand merci à l'e-team qui m'a aidée tout au long des étapes :-)