Contrôle de version des cas de test

Question

Le plan de test doit-il être conservé dans le contrôle de version avec le code? C'est-à-dire que le plan de test et le code sont placés sous le même système de contrôle de version et ont la même numérotation de révision. Je ne parle pas de code de test unitaire, mais d'un document de plan de test peuplé de cas de test manuels. Il existe des systèmes de gestion de cas de test basés sur le Web, mais je doute que les cas de test soient contrôlés par la version et synchronisés avec le code. Je suis à la recherche d'un système de gestion de test basé sur le Web pour mon oragnisation, car il permet un accès facile aux membres de l'équipe non-développeurs (pas besoin d'utiliser VC pour vérifier le plan de test du référentiel). Cependant, je préférerais contrôler les versions de ces plans de test, synchronisés avec les principales étapes/versions du logiciel. Je n'ai trouvé aucun système de gestion de test répondant à ce besoin. Ou je regarde dans la mauvaise direction?

Answer 1

Cela a du sens pour moi. Je m'attendrais à ce que les tests (que ce soit les spécifications manuelles ou les tests unitaires) et le code correspondant soient en accord. Je m'attendrais aussi (peut-être avec optimisme!) Que la documentation soit en grande partie en phase avec le code pour un checkin particulier. Peut-être que si vous ne pouvez pas les garder complètement en phase, vous pouvez utiliser vos mécanismes de balisage de code source (ou de branchement?) Pour identifier des ensembles de versions cohérents. Cela peut avoir plus de sens si votre contrôle de version contient des tests que vous êtes en train de réviser/construire votre base de code à atteindre (c'est-à-dire que vos tests conduisent votre code - pas une situation inhabituelle).

Answer 2

Personnellement, j'aime votre idée. Bien que les tests dans de nombreux paradigmes de développement de logiciels devraient être basés sur une spécification de la façon dont le système devrait fonctionner, pas comment cela fonctionne actuellement, et pourrait donc être développé indépendamment de votre code synchronisé. Puisqu'ils sont essentiellement des documents, ils pourraient bien fonctionner dans un système de contrôle de version de document de formalité variable.

Certaines équipes utilisent un outil tel que TestDirector pour gérer des plans de test, des scénarios de test et les connecter au système de suivi des bogues. Chaque cas de test, bug, etc. a son historique de modifications stockées dans une base de données, de sorte que vous pouvez revenir en arrière et l'examiner (et le chercher, avec un peu de travail et un peu de jiggery-pokery, comme le dirait). Cependant, nous n'avons jamais mis cela en synchro avec le code sauf aux étapes importantes où nous avons fait des gels de code, et à ce moment-là, le code + scripts est entré dans MKS Integrity (personnellement, je pense que nous avons sous-utilisé Integrity sur notre lieu de travail ... avec toute l'équipe de développement, pas seulement les promoteurs de code).

D'autres équipes écrivent simplement des documents Word et les placent dans un dossier sauvegardé. Simple, mais sur de petites équipes dans des projets pas trop grands peuvent travailler.