Salut Je m'appelle Misha et je suis QA senior avec une expérience commerciale de plus de 6 ans. Maintenant, je travaille dans Provectus, mais j'ai commencé mon parcours de testeur en tant qu'étudiant lorsque j'ai participé à des tests alpha et bêta de divers jeux. À un moment donné, je me suis dit: «Pourquoi ne pas commencer à faire cela professionnellement?» Et c'est parti. Pendant ce temps, j'ai réussi à participer à divers projets: des start-ups aux entreprises, des petits jeux éducatifs aux énormes applications avec une forte logique métier.
Mais souvent, j'ai été introduit dans de petites équipes, dans lesquelles il y avait 5 développeurs pour 1-2 testeurs et, en règle générale, il y avait beaucoup de chaleur dans le projet. En fait, je veux partager avec vous comment apprendre à comprendre où vous êtes et comment commencer à avancer dans la formulation des processus d'AQ.
Tout d'abord, vous devez comprendre sur quel projet vous êtes.
Ayant acquis de l'expérience en participant à des projets, je les diviserais sous condition en 3 types:
- projets sans test;
- projets soumis à des tests inéquitables;
- projets de test.
Au moment de mon implication, chacun d'eux était à son stade de développement. J'ai commencé à observer ces situations et j'ai commencé à développer ma vision - comment promouvoir les processus de test sur celles-ci. Après un certain temps, je suis tombé sur le modèle de maturité, et elle s'est couchée une à une sur mes bases. Cela a renforcé ma conviction que c'est l'endroit où aller.
Qu'est-ce que le modèle de maturité
Et ici, je suis très intelligemment insérer une citation de
Wikipedia :
Intégration du modèle de maturité des capacités (CMMI) - un ensemble de modèles (méthodologies) pour améliorer les processus dans les organisations de différentes tailles et activités. CMMI contient un ensemble de recommandations sous forme de pratiques, dont la mise en œuvre, selon les développeurs du modèle, vous permet de réaliser les objectifs nécessaires à la pleine mise en œuvre de certains domaines d'activité.
En bref et simple, il s'agit d'un ensemble de modèles qui montrent à quel point les processus sont bien organisés dans l'organisation selon certains critères. Ayant une telle évaluation, on peut évaluer sobrement s'il vaut la peine de donner l'une ou l'autre commande à un entrepreneur particulier.
En fait, à partir de là, le développement du modèle de maturité a commencé. Dans les années 80, le département américain de la Défense s'est rendu compte qu'il ne pouvait pas évaluer avec précision la qualité du travail des sous-traitants en développement logiciel. Et puisque cette structure gouvernementale est également d'un tel niveau, c'est inacceptable. L'argent appartient à l'État, les délais sont clairement définis et un logiciel fiable pour les armes permettra à tout le monde de dormir plus paisiblement. Sur cette base, le ministère a chargé l'Institut de génie logiciel de créer un tel système de notation et un an plus tard, le premier questionnaire a été créé et 4 ans plus tard, la première version du modèle a été créée.
Niveaux du modèle de maturité
Il s'agit de 5 niveaux au sein desquels le travail / la fiabilité / la stabilité de l'entreprise est évalué.
Où dans le modèle de maturité teste
Pour les testeurs, il existe un MM spécial, appelé TMMi. Il contient également 5 niveaux, sur lesquels je voudrais m'attarder plus en détail et considérer ce qui est typique de chacun d'eux.
Le premier niveau est "Débutant"Au premier niveau, les tests ne sont pas structurés et chaotiques. Il n'y a pas d'environnement stable pour prendre en charge les processus de test. L'équipe ne fait pas attention à la planification et aux normes.
L'objectif principal est de livrer le produit à temps sans problèmes critiques, car les tests ne sont utilisés ici que pour montrer que l'application fonctionne sans problèmes majeurs. Souvent, le succès de tels projets dépend uniquement de l'héroïsme et des compétences des individus, plutôt que des processus établis.
En conséquence:
- pas de documentation de test;
- le produit est instable;
- refus de processus lors de situations problématiques;
- les tests ne sont rien d'autre qu'une aide au débogage.
Deuxième niveau - «répétable»Au deuxième niveau, le test devient un processus contrôlé. La discipline et les progrès réalisés garantissent le maintien de ces pratiques en période de stress. Les tests sont toujours considérés comme l'activité qui suit le développement. Les plans de test sont élaborés et mis en œuvre, à l'aide desquels ils déterminent clairement quel type de test est nécessaire, quand et par qui.
L'objectif principal est de s'assurer que le produit répond aux exigences spécifiées.
En conséquence:
- il existe les principaux types et types de tests (intégration, modulaire, régression, acceptation);
- plans de test mis en œuvre;
- les activités de test sont surveillées et contrôlées;
- le processus est documenté et peut être répété.
Troisième niveau - «défini»Au troisième niveau, le test n'est plus considéré comme une activité après la programmation. Les tests sont entièrement intégrés au projet. La planification des tests est effectuée à des stades antérieurs et est fixée dans le plan directeur. Des tests non fonctionnels (par exemple, l'utilisabilité) sont en cours d'introduction.
En conséquence:
- les tests commencent par la phase des exigences;
- des activités sont ajoutées qui vous permettent de travailler plus efficacement (formations internes, revues supplémentaires);
- des tests non fonctionnels sont en cours d'introduction.
Quatrième niveau - «Mesurable»Au quatrième niveau, les tests sont un processus bien défini, bien établi et mesurable. Le test est perçu comme une évaluation et comprend toutes les opérations du cycle de vie du développement logiciel. La pratique de mesurer la qualité des tests est en cours d'introduction. Ces mesures sont utilisées pour prédire les performances et le coût des tests.
En conséquence:
- les tests en tant que processus mesurable;
- les mesures sont utilisées pour la prévision;
- l'équipe cherche des moyens de rendre le processus de test plus efficace.
Cinquième niveau - «Innovant»Au cinquième niveau, toutes les approches et tous les processus sont bien établis. L'équipe ne s'arrête pas à ce stade, mais continue d'améliorer systématiquement les processus, en essayant constamment de réduire le temps du cycle de test et le time-to-market sans compromettre la qualité du projet. Les tests se concentrent sur la prévention. L'automatisation est ajoutée pour une utilisation plus efficace des ressources.
En conséquence:
- amélioration continue des processus;
- se concentrer sur la prévention et l'optimisation.
Comment la connaissance de cette structure aide
Cas n ° 1. Tests déloyauxUne fois, je suis arrivé à un petit projet où les tests ont été effectués par un client, ses amis ou un chat. Après avoir évalué la situation et examiné le modèle, nous pouvons comprendre que nous sommes au niveau 1 et que nous devons nous concentrer sur le niveau 2 lors de la planification des activités. Après avoir mis Jira en ordre, où il y avait un grand nombre de bogues (dont la plupart étaient des doublons ou non reproductibles), j'ai commencé à compiler la documentation de test sous forme de listes de contrôle et à organiser les processus de test de base. Tels que les tests de régression et les contrôles d'intégrité lors de changements majeurs.
Cas n ° 2. Sans testÀ mon avis, les projets de ce type peuvent être dans trois cas:
- le projet ne fait que commencer;
- il n'y avait pas besoin d'un testeur sur le projet alors qu'il y avait un peu de fonctionnalité;
- L'équipe full-stack a comblé le manque de testeurs avec une révision de code de qualité et des tests de développement.
Une fois dans l'un de ces projets, vous pouvez souvent voir l'avantage du fait qu'il est à un niveau zéro secret. Nous pouvons sauter par-dessus le premier niveau et tout faire immédiatement qualitativement avec un bon sens, un sentiment, un arrangement, guidé par les objectifs du second. Souvent, nous pouvons mettre en œuvre des plans de test, sur la base desquels tous les types de tests nécessaires seront effectués. Vous pouvez immédiatement identifier le même flux de travail avec l'équipe de développement, qui est absent sur les projets du premier cas.
Cas n ° 3. Les tests ont étéEn vérité, le cas le plus rare: un homme, en raison de certains événements, a décidé de changer son équipe / département / travail et vous donne ses propres idées. Dans cette situation, vous avez déjà un système établi d'interaction avec les développeurs, une certaine base de documentation de test. D'autres voies de développement peuvent inclure l'amélioration du processus établi ou le passage au troisième niveau - introduire des tests à des étapes antérieures ou ajouter des tests non fonctionnels.
Affaire numéro 4. Trois en unLorsque je suis arrivé à mon projet à Provectus, j'étais confronté à une situation dans laquelle il n'y avait que peu des trois cas décrits ci-dessus. Comme dans le cas n ° 1, la première chose à faire a été de remettre Jira en ordre. Comme dans le deuxième cas, il a été décidé de tout faire immédiatement avec une grande qualité afin d'être immédiatement guidé par le deuxième niveau. Par conséquent, j'ai immédiatement commencé à développer la documentation des tests et à mettre en œuvre des outils de gestion des tests. J'ai également essayé de tirer le meilleur parti des artefacts des itérations passées, comme ce fut le cas dans le troisième cas.
Après un très court laps de temps, je peux dire en toute sécurité que nous allons déjà délibérément au troisième niveau - même des tests connectés au stade des exigences commerciales :)
Conclusions
D'après mon expérience, la plupart des projets ukrainiens, ainsi que des projets qui ne sont pas conçus depuis longtemps, peuvent être mis en service avec succès au niveau 3. Mais si vous avez un projet à long terme, les possibilités de l'améliorer sont infinies et vous pouvez être guidé en toute sécurité par les réalisations des plus hauts niveaux.
En conclusion, je voudrais dire que le but de cet article n'était pas tant de montrer comment travailler avec le MM ou TMM classique lui-même, mais qu'avec son aide, vous pouvez clairement comprendre à quelle étape du projet vous êtes impliqué, et quels mouvements prendre et qui n'en valent pas la peine. De plus, en prenant ses principes comme base, vous pouvez créer votre propre modèle, qui peut être appliqué non seulement dans le développement, mais aussi dans divers domaines de la vie. Et surtout - il est testé et fonctionne :)