Je dirais qu'il y a toutes les raisons pour une personne QA à pas avoir une connaissance détaillée de l'intérieur de la façon dont fonctionne votre application. Le personnel d'AQ devrait avoir à peu près le même niveau de compétence en informatique que votre public cible. La raison en est simple: plus une personne chargée de l'assurance qualité connaît la manière dont votre application est créée, plus elle risque d'éviter les problèmes d'utilisabilité normaux que rencontreront vos utilisateurs habituels. QA ne consiste pas uniquement à tester le bon fonctionnement de l'application. Il devrait également s'agir de tester si elle est compréhensible par votre utilisateur moyen et donc réellement utilisable.
MISE À JOUR
Cela devenait trop long pour tenir dans une boîte de commentaire.
En ce qui concerne les questions de @ testerab.
Je définis l'AQ comme la personne ou le groupe responsable de s'assurer 1. que les exigences opérationnelles sont respectées; et, 2. les fonctions de l'application en ce qui concerne ces exigences sont exemptes d'erreurs. D'où le surnom "Quality Assurance". Un troisième élément qui, selon moi, appartient à l'assurance qualité est simplement la convivialité.
Ils doivent avoir une compréhension des besoins de l'entreprise, ce qui signifie qu'ils doivent travailler de pair avec les analystes d'affaires et les utilisateurs finaux (le cas échéant). Les meilleurs membres de l'AQ avec qui j'ai travaillé ont été embauchés dans ces régions. Les pires membres de l'AQ que j'ai vus étaient des développeurs ou ont été formés en tant que tels. Les personnes qui ont déménagé de Tech Support ont également tendance à faire de bons membres QA car ils connaissent exactement le type d'ordures qu'un utilisateur final va essayer.
Il existe de nombreuses classes d'applications. De loin, le plus commun est l'entrée de données glorifiée. Vous avez des écrans dans lesquels les informations sont saisies et les boutons sont enfoncés. L'information est ensuite stockée et/ou acheminée à l'endroit où elle doit aller. Tout de MS Word aux CRM tombe dans cette catégorie.
Par conséquent, le travail d'une personne chargée de l'assurance qualité consiste à vérifier d'abord que l'application acceptera les entrées souhaitées et exécuter les fonctions souhaitées. Une étape secondaire consiste à soumettre les mauvaises entrées et à vérifier que l'application répond de la manière souhaitée. par exemple. il ne gonfle pas et ne laisse pas passer les mauvaises informations. Les outils de test automatisés fonctionnent très bien dans ces cas. Une dernière partie est de décider si cette fonction doit être enterrée à trois niveaux de profondeur ou est-ce quelque chose qui devrait être plus facile d'accès.
Aucun des éléments ci-dessus n'oblige la personne chargée de l'assurance qualité à lire le code ou à manipuler les bits.
Certains systèmes n'ont pas de composant d'interface utilisateur. Pour ces derniers, il appartient au développeur de fournir un harnais de test qui permettra à une équipe d'assurance qualité de soumettre des données et d'examiner les résultats. Cela couvre les services Web et tout type d'EDI que vous pouvez imaginer.
D'autres systèmes sont des API en eux-mêmes. Ceux-ci exigent soit une personne de QA qui soit assez bien informée pour implémenter elle-même ces appels d'API, soit que les développeurs fournissent des moyens de les appeler facilement et d'enregistrer les résultats. Dans ce cas, il est préférable que l'équipe de contrôle qualité puisse faire sa propre programmation mais, une fois de plus, ne pas avoir accès au code sous-jacent. Le problème avec l'examen du code réel est qu'il tend à amener une personne à se concentrer sur ce qu'elle voit. C'est mauvais.Au lieu de cela, ils devraient être mentalement libres de ces limites artificielles afin qu'ils puissent aveuglément taper "ABC" dans une zone de texte qui attend l'entrée numérique.
En ce qui concerne « voir » le code afin de savoir quoi tester, c'est un problème tout à fait différent et qui est mieux résolu par les développeurs formés dans un cadre de révision du code. Le but ici est d'identifier les erreurs possibles, les meilleures pratiques, les échecs de sécurité, etc. Les personnes de QA sont rarement capables de ce niveau d'analyse car elles exigent que quelqu'un soit un développeur actif.
En ce qui concerne SDETs: Si votre produit a ou est, une API ou une fondation qui devs utilisent pour construire d'autres choses, alors vous voudrez peut-être une ou plusieurs personnes dédiées à la mise en œuvre de logiciels autour de lui afin de soutenir la régulière Groupe d'assurance qualité Je suis sur la clôture quant à la nécessité de ce rôle et je crois que cela pourrait être un projet par décision de projet.
Je crois qu'il y a deux groupes qui sont mieux qualifiés pour tester les API. Ce sont les utilisateurs finaux qui sont déjà en train d'implémenter et d'autres développeurs dans l'entreprise qui l'a construit. L'alimentation des chiens est maintenant une pratique courante et est très rentable. Après tout, si cela ne fonctionne pas, vous pouvez être sûr qu'il sera réparé rapidement. Pour les utilisateurs finaux, tant qu'ils voient cela comme une véritable conversation dans laquelle l'équipe de développement est réceptive, ils seront heureux de "tester" pour vous.
J'ai été dans les trois situations et en tant qu'utilisateur final, j'ai l'impression d'avoir accès aux développeurs d'origine va un long chemin à résoudre les problèmes. Surtout quand ils utilisent également le produit. Le montant de la mauvaise traduction pour les gens de l'AQ normalement associés à ces projets est tout simplement horrible.
En résumé, j'ai travaillé avec toutes sortes de personnes chargées de l'assurance qualité. De ceux que vous vous demandez comment ils ont réussi à conduire au travail à des superstars qui étaient très habiles à trouver ces cas de coin qui ont causé des applications à étouffer.
Les caractéristiques des meilleurs étaient les suivantes: 1. n'ont jamais été programmeurs; 2. compris l'affaire; 3. compris exactement ce que les utilisateurs finaux ont fait au jour le jour. 4. Honnêtement préoccupé par ceux qui sont soumis au logiciel.
Les traits des plus mauvais inclus: 1. avaient été programmeurs ou pensaient qu'ils étaient; 2. n'a pas compris l'affaire; 3. jamais rencontré un utilisateur final; 4. utilisé trop souvent le mot «idiot»; 5. rattrapé dans la mécanique de la façon dont cela fonctionnait au lieu de savoir si c'était même utilisable.
J'aurais dit que votre équipe d'assurance qualité faisait probablement des tests plutôt mauvais dans ce cas - peut-être même pas du tout, mais simplement confirmer. Cela arrive, mais ce n'est certainement pas quelque chose auquel aspirer. – testerab