Pourquoi avez-vous besoin d’un spécialiste QA Salesforce ?

🚀 Imaginez votre projet Salesforce avec et sans spécialiste de l’assurance qualité. Voyez-vous la différence ? Aujourd’hui, nous souhaitons parler de l’assurance qualité dans Salesforce, de ses avantages et de ses inconvénients, des défis métier et des lacunes de communication, ainsi que des moyens de les éviter.

Que fait habituellement un spécialiste QA Salesforce ?

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

Pourquoi avons-nous besoin d’un spécialiste QA dans le développement ?

Pour commencer, imaginons comment peut se dérouler concrètement le processus de développement Salesforce. Par exemple, notre équipe compte trois développeurs Salesforce et un chef de projet. Dans Jira, le chef de projet crée des tickets pour les tâches à réaliser par les développeurs. Chaque ticket contient une description du travail. Les étapes sont réparties dans les colonnes « To do », « in progress » et « done ». Le client peut donc voir ces tâches dans la colonne « done » d’un tableau de bord et penser que le travail est terminé. Mais ce n’est pas le cas. En réalité, une tâche indiquée comme terminée ne l’est pas vraiment : le développement est achevé et la tâche est préparée pour les tests.

Nous avons des exigences pour développer une page web avec des boutons, permettre à différents types d’utilisateurs de se connecter, et d’autres fonctionnalités. Tout est décrit dans la tâche. Une fois terminée, celle-ci passe dans la section « Done ». Mais nous pouvons nous retrouver dans une situation où le développeur a réalisé une chose alors que le client en demandait une autre : le développeur n’a pas approfondi le problème du client et s’est contenté de clôturer la tâche demandée, dont le périmètre n’était pas suffisamment bien défini. Nous pouvons donc aboutir à deux résultats diamétralement opposés.

Parfois, la tâche n’a pas de description. Un chef de projet remplit le ticket à partir des informations du client, faute de temps ou parce que le client ne sait pas ce qu’il veut réellement. Ces tickets passent donc souvent en développement avec très peu d’informations sur le travail à réaliser.

C’est là qu’intervient le spécialiste QA. Cette personne peut, d’une part, intervenir à l’étape « Done » et, d’autre part, commencer son travail d’assurance qualité dès l’étape « To Do ».

À quels problèmes avez-vous été confronté ?

Des clients souhaitaient que les développeurs testent eux-mêmes ce qu’ils avaient réalisé. De leur point de vue, c’est logique. Par exemple, lorsque vous découpez les pièces d’une robe, vous pouvez vérifier si le patron est correctement réalisé. Pourtant, cette approche ne fonctionne pas dans le développement. Les développeurs utilisent leurs compétences techniques pour accomplir les tâches selon leur propre compréhension des exigences. Cela s’arrête là. Mais il me semble erroné et peu avisé de recruter uniquement une équipe de développeurs et, si nécessaire, un chef de projet. Il existe généralement des décalages entre l’activité des clients, le développement Salesforce et les développeurs.

Pouvez-vous donner quelques conseils pour réussir en tant que spécialiste QA ?

🧩 Plus le spécialiste QA est expérimenté, meilleurs peuvent être les résultats obtenus par les clients.

Un spécialiste QA expérimenté pose des questions de clarification pour prévenir les problèmes dès le début du projet. Il peut s’agir, par exemple, d’une estimation incorrecte. Au départ, on dispose d’une première estimation et d’une courte description d’un travail réalisable en quelques heures. Puis vous décidez de poser une question de clarification et vous découvrez que la description doit être complétée : l’estimation change alors.

🧩 Mieux le spécialiste QA connaît le produit, plus il est susceptible de pouvoir apporter son aide et de rendre le processus de développement plus efficace.

Passons en revue les étapes suivantes du développement logiciel : exigences, analyse, conception, programmation, tests et déploiement. Il est tout à fait possible que le client voie les choses ainsi : il y a tant de travail à faire, peut-être n’aura-t-on pas besoin de testeurs, les développeurs peuvent régler tous les problèmes eux-mêmes, alors pourquoi payer plus ? En réalité, cela ne fonctionne pas ainsi. Un spécialiste QA compétent doit être présent à chacune de ces étapes.

🧩 Un spécialiste QA doit être plus attentif qu’un développeur.

J’ai trouvé un problème : nous remettons le ticket dans « To Do » ou nous le rejetons. Dans tous les cas, une même tâche peut faire l’objet de plusieurs allers-retours.

🧩 Un bon spécialiste QA associe assurance qualité et analyse métier.

Si votre client travaille déjà avec un analyste métier, il suffira qu’un ingénieur assurance qualité teste les tâches terminées par un développeur. Mais dans le cas contraire, si ni analyste métier ni chef de projet n’intervient, quelqu’un doit recueillir les exigences. Si ce recueil est correctement mené, il me sera plus facile de réaliser les tests et de comprendre ce qui a été fait et ce qui ne l’a pas été.

Si vous considérez l’analyste métier (BA) comme un spécialiste chargé de l’analyse et expert des processus métier, il n’y a pas lieu de le remplacer. En revanche, s’il s’agit d’une personne qui intervient sur un projet pour aider à gérer la documentation, créer un plan de test, utiliser Confluence, mettre à jour les informations, etc., vous pouvez confier ces tâches à un spécialiste de l’assurance qualité.