Pourquoi avez-vous besoin d’un contrôle qualité Salesforce ?

🚀 Imaginez votre projet Salesforce avec et sans un spécialiste QA. Pouvez-vous voir la différence? Aujourd'hui, nous voulons parler de Assurance qualité dans Salesforce, les avantages et les inconvénients, les défis commerciaux et les lacunes en matière de communication, et comment les éviter.

Que fait habituellement le contrôle qualité de Salesforce ?

Un testeur d'assurance qualité Salesforce est un spécialiste chargé de résoudre les problèmes rencontrés sur les projets, de planifier et de mettre en œuvre différentes étapes d'assurance qualité, de se lancer dans la tâche pour la comprendre et de déterminer les résultats que le client souhaite réellement au final.

Pourquoi avons-nous besoin d’une assurance qualité dans le développement ?

Tout d'abord, imaginons comment le réel Développement de la force de vente processus peut être mené. Par exemple, nous avons à nos côtés une équipe de trois développeurs Salesforce et un chef de projet. Dans Jira, le chef de projet crée des tickets pour les développeurs qui doivent être exécutés. Chaque ticket comprend une description du travail. Colonnes d'étapes à faire, en cours et terminées. En conséquence, le client peut voir ces tâches dans une colonne terminée sur un tableau de bord et penser que le travail est terminé. Mais ce n'est pas. En fait, une fois la tâche accomplie, cela ne semble pas être le cas. La tâche est terminée et se prépare pour les tests.    

Nous avons les exigences nécessaires pour développer une page Web avec des boutons, différents types d'utilisateurs peuvent se connecter, etc. Tout est décrit dans la tâche. Lorsque la tâche est terminée, elle passe dans la section « Terminé ». Mais nous pouvons être coincés dans une situation où le développeur en a créé un et le client en a demandé un autre parce que le développeur n'étudie pas le problème du client et a simplement clôturé la tâche requise, l'étendue du travail n'était pas suffisamment correcte. En conséquence, nous pourrions avoir du noir et blanc.   

Parfois, il n'y a aucune description d'une tâche. Un chef de projet remplit le ticket en fonction des informations du client parce qu'il n'y a pas assez de temps ou que le client ne sait pas ce qu'il veut réellement. Par conséquent, ces tickets sont souvent développés avec très peu d’informations sur la marche à suivre.  

Voici un spécialiste de l'assurance qualité. C'est une personne qui peut, d'un côté, s'impliquer dans le travail à l'étape « Terminé », et de l'autre côté, l'assurance qualité commence à partir de l'étape « À faire ».    

Quels problèmes avez-vous rencontrés ?

Les clients souhaitaient que les développeurs testent eux-mêmes ce qu’ils avaient déjà fait. De leur point de vue, c'est logique. Par exemple, lorsque vous découpez une robe, vous pouvez vérifier si le motif est correctement réalisé. Cependant, une telle approche ne fonctionne pas en développement. Au moins, les développeurs utilisent leurs compétences techniques pour terminer les tâches d'une manière dont ils comprennent les exigences. C'est ça. Mais il me semble erroné et analphabète de n'embaucher qu'une équipe de développeurs et un chef de projet si cela est nécessaire. Il existe généralement des écarts entre les activités des clients, le développement de Salesforce et les développeurs.

Pouvez-vous partager quelques idées sur la façon de réussir un contrôle qualité ?

🧩 Plus le contrôle qualité est expérimenté, meilleurs sont les résultats que les clients peuvent obtenir.

Un AQ expérimenté pose des questions de clarification pour éviter les problèmes au début du projet. Par exemple, il se peut que cette estimation ne soit pas correcte. Au tout début, c'est une estimation. Nous avons une petite description qui peut être terminée en quelques heures. D'une manière ou d'une autre, vous décidez de poser une question de clarification, et il s'avère qu'il y a plus de description à faire, c'est une autre estimation.     

🧩 Mieux le contrôle qualité connaît le produit, plus le testeur sera susceptible de vous aider. Et rendre le processus de développement plus efficace.

Passons en revue les prochaines étapes du développement logiciel : exigences, analyse, conception, codage, tests, déploiement. Il est fort possible qu'une telle image soit présente dans l'esprit du client. Si une telle personne pense qu'il y a tellement de travail à faire et qu'il n'y aura peut-être pas besoin de testeurs, les développeurs peuvent gérer tous les problèmes eux-mêmes, alors pourquoi devrais-je payer trop cher alors ? En réalité, cela ne fonctionne pas comme ça. Un AQ compétent doit être présent à chacune des étapes.  

🧩 Le QA devrait être plus attentif qu'un développeur.

J'ai trouvé un problème, on met le ticket en 'To Do' ou on le rejette. Dans tous les cas, il peut y avoir plusieurs cercles avec une seule tâche.  

🧩 Un bon QA est QA plus BA.

Si votre client travaille déjà avec un analyste commercial, il suffira d'un ingénieur d'assurance qualité pour tester les tâches terminées par un développeur. Mais si nous parlons de la situation inverse, ni BA ni PM ne travaillent, quelqu'un devrait recueillir les exigences. Si le processus de recueil des besoins est correctement mené, il sera pour moi plus facile de faire des tests. Comprendre ce qui a été fait et ce qui n'a pas été fait.   

Si vous considérez BA comme un spécialiste responsable de l’analyse et qui est un expert des processus métiers. Il n'est pas nécessaire de remplacer BA. Mais si nous parlons de quelqu'un qui est impliqué dans un projet, qui peut aider à gérer la paperasse, créer un plan de test, utiliser Confluence, mettre à jour les informations, etc. Vous pouvez déléguer ces tâches au QA.