Commande / Traitement de milliers de défauts juste avant la sortie
Cette question m'a été posée lors d'un entretien avec une très bonne entreprise, ci-dessous je la fournirai sous la forme de notre interaction (M: moi & moi: interviewer) .Bien qu'il n'y ait pas de réponse définitive mais j'ai besoin de savoir quoi idée / réponse que l'intervieweur voulait vraiment :
I: Le scénario est vous et 2 autres sont constitués de l'équipe de test. Vous, le responsable, êtes le seul à pouvoir faire de l'automatisation, les autres ne peuvent faire que des tests manuels. Vous avez près de 10 000 bogues qui ont été soulevés et vous disposez de 4 à 5 semaines ou moins avant la livraison de ce produit. Que ferez-vous pour vous assurer que le produit est livré à temps?
M: Filtrez les bogues par ordre de priorité et retestez-les. En attendant, gardez un journal sur les fonctionnalités qui font face à plus de régression et commencez ainsi à les automatiser. Des bogues similaires ou connexes seront transmis à d'autres pour des tests supplémentaires.
I: Supposons qu'aucun des bogues n'ait été marqué par une priorité. Que vas-tu faire?
M: Je vais filtrer avec des dates. Dans tout type de SDLC, même agile, les composants de base sont développés en premier, s'il y a des bogues de base, ils doivent d'abord être corrigés.
I: (désapprobateur) Et si une fonctionnalité très importante est ajoutée dans un sprint ultérieur? Aussi comment utiliserez-vous vos coéquipiers et votre capacité à automatiser.
M: En plus de la date, en tant que testeur, je devrai connaître les fonctionnalités de base et importantes du produit jusqu'à ce jour, donc en gardant cela à l'esprit, vous trouverez les domaines de base de chaque sprint sur lesquels travailler (à propos de Team Mated a répondu la même chose comme avant).
I: Supposons que les bogues n'aient pas été marqués avec la chronologie de chaque sprint. Que vas-tu faire?
M: Je vais chercher dans la liste des bogues avec des mots-clés qui représentent les fonctionnalités importantes sans lesquelles le produit ne peut pas être publié. Je vais choisir les bugs à partir de là.
I: (Encore une fois désapprobateur) Avec un mot-clé, vous obtiendrez tellement de résultats, allez-vous les parcourir un par un?
M: (perd lentement espoir) Je vais juste parcourir le titre et décider.
I: En général, les titres ne sont pas si explicatifs, comment allez-vous gérer?
M: Je vais commencer à tester le produit moi-même et rechercher des bogues similaires auxquels je suis confronté, plutôt que d'essayer de passer par des bogues parce que je dois prendre une décision pour la livraison du produit.
I: Vous ignorerez donc ces nombreux bugs? Les parties prenantes peuvent ne pas être d'accord. (Après cela, je l'ai totalement perdu et j'ai continué à bavarder et je ne me souviens plus de ce qui a été demandé.De plus, partout, la gestion / le travail des 2 autres testeurs manuels a été demandé)
C'était une interview pour Sr SDET.
Réponses
En plus de ce que les autres réponses ont dit, je dirais que l'intervieweur cherche comment vous, en tant que nouvel ajout à une équipe, géreriez une situation sans issue. Franchement, je soupçonne que, au minimum, l'entreprise s'est retrouvée dans ce genre de situation dans le passé. Au pire (j'avoue volontiers que je suis cynique), quelque chose de similaire va être confronté à celui qui obtiendra le poste.
En tant qu'intervieweur, je voudrais quelque chose comme ça de la personne que j'interviewais:
Tout d'abord, je voudrais savoir comment ces bogues sont organisés, en particulier la priorité, la gravité et le risque. Je suppose que je viens dans cette situation et non pas que j'ai été impliqué depuis le début, car ce genre de situation suggère que les choses ont mal tourné quelque part.
Si les bogues ne sont pas organisés d'une manière qui implique la priorité, la gravité et le risque, je voudrais parler aux autres testeurs, à la gestion de projet et au développement pour déterminer les problèmes qu'ils connaissent et qui présentent le plus grand risque pour le déploiement projeté. Date.
S'il existe une telle organisation, je chercherais à parler aux testeurs, à la gestion de projet et au développement pour confirmer les bogues les plus risqués. Idéalement, je chercherais un moyen de créer une liste de bogues qui doivent être corrigés avant que le produit puisse être publié. Avec 10000 bogues, cette liste va prendre un certain temps à créer, et cela suppose qu'il n'y a pas de bogues que les testeurs n'ont pas pu trouver parce que les bogues signalés les cachent ou les bloquent.
Une fois que j'ai une idée de la gravité de la situation, je peux décider si - à mon avis - il est possible de publier l'application comme prévu. Si la plupart des bogues présentent un risque relativement faible et que les bogues à haut risque semblent être raisonnablement faciles à corriger, je concentrerais mon équipe sur les bogues à haut risque et travaillerais avec le chef de projet et toute autre équipe responsable pour obtenir le risque le plus élevé. (gravité élevée, le plus susceptible de se produire sur le terrain, et / ou bloquer des zones de l'application) bogues corrigés et testés.
Si je ne vois pas un moyen de publier le produit à temps, je commencerais à parler au chef de projet et à mon patron pour voir s'il existe un moyen de faire une version bêta limitée de fonctionnalités solides ou de retarder la publication. Puisque je suis nouveau dans le poste, je ne sais pas s'il y a des exigences contractuelles ou d'autres facteurs indépendants de ma volonté qui pourraient forcer la date de libération à être inamovible.
Je m'assurerais également qu'après la sortie, je suis en contact avec les dirigeants de toutes les équipes impliquées pour déterminer comment une telle situation s'est produite et quelles mesures nous pourrions prendre pour éviter qu'elle ne se reproduise, ainsi que comment nous pouvons travailler ensemble pour réduire l'arriéré de bogues.
Notez que rien de tout cela n'a rien à voir avec le rôle SDET. Il ressort clairement de la question que l'intervieweur s'attend à ce qu'un SDET agisse également en tant que responsable de test - je ne pense pas que ce soit une chose particulièrement bonne, et franchement, je voudrais savoir si c'est quelque chose que l'entreprise attend de son SDET.
Il convient de se rappeler que même si les entretiens sont des situations très stressantes, essayez de penser de côté et de regarder les implications des questions qui vous sont posées plutôt que de plonger. C'est difficile à faire parce que vous êtes stressé et que vous essayez de faire de votre mieux, mais si vous pouvez prendre un peu de temps pour vous demander mentalement ce que l'intervieweur recherche avec la question, vous pouvez généralement donner une meilleure réponse.
La première chose qui me vient à l'esprit est la suivante: ces tests ont-ils déjà fonctionné? Si c'est le cas, ne paniquez pas. Quelque chose a changé dans la base de code ou dans le cadre de test, ce qui provoque probablement l'échec de certains d'entre eux. Trouvez-le et voyez si vous pouvez éliminer plusieurs milliers d'échecs à la fois. Vous allez toujours avoir besoin de relire ceux qui passent à nouveau manuellement et de les vérifier, mais cela ne prendra peut-être que quelques jours.
S'ils n'étaient jamais vérifiés auparavant, je ferais toujours quelque chose de similaire - recherchez tout point commun qui pourrait vous permettre de réparer de grands groupes à la fois.
Sinon, il y a tellement de bruit que vous pourriez manquer quelque chose de critique qui échoue.
Après cela, acceptez que vous ne pourrez peut-être pas tout accéder et vous concentrer sur le chemin du code du générateur d'argent. Les choses qui doivent fonctionner ou l'entreprise se replie. Ensuite, une fois que vous en avez éliminé quelques autres, tous les deux jours ou trois, regardez s'il y a plus d'échecs groupés comme mentionné précédemment et essayez de supprimer quelques groupes supplémentaires.
Remarque: répondre à cela du point de vue d'un SDET - quelqu'un qui peut réparer la base de code incriminée elle-même.
Si l'intervieweur mentionnait des bogues et non l'échec du test (si son échec du test, référez-vous à @Lewis
Tout d'abord, avoir 10000 bogues actifs dans un produit est un très gros drapeau rouge.
Et vous ne devriez jamais sortir un tel produit. Mais si la décision de la direction doit encore être publiée,
La réponse à laquelle l'intervieweur s'attendait serait « gravité »
L'équipe doit d'abord se concentrer sur la résolution des bogues de gravité élevée s'il n'y a pas de priorités et rester faible une fois en attente si ce n'est pas une exigence urgente et n'affecte pas la logique métier réelle.
Et concentrez-vous d'abord sur l'automatisation du test de fumée, puis commencez à automatiser toutes les suites de régression
Regroupez les bogues et voyez où se produit le regroupement de bogues et testez rigoureusement ce module une fois le correctif effectué.
Avant la libération, testez manuellement tous les scénarios de test de fumée (logique des entreprises critiques)
De plus, avoir 10000 bogues peut entraîner un masquage des défauts là où ces bogues masquent certains bogues critiques dans le produit.
Donc, une fois le correctif effectué, des tests plus rigoureux devraient être effectués autour des modules pour rechercher des bogues plus critiques.
donc si j'étais dans l'interview, je répondrais comme:
- 10000 bogues dans n'importe quel projet seraient un énorme drapeau rouge, cela montre qu'il n'y avait pas de processus de correction de bogues et d'estimation appropriés en place. Je m'inquiéterais sûrement de la mise en cluster des défauts et du masquage des défauts, ce qui signifie qu'il est possible que la plupart des bogues soient concentrés sur un seul module, et que autant de bogues masquent d'autres bogues critiques qui ne seront identifiés qu'après avoir corrigé et retesté rigoureusement le module. . Et recommandera de repousser la date de sortie plus loin pour cette raison.
Alors que l'équipe de développement est occupée à corriger les bogues, nous commencerons à automatiser les cas d'utilisation des tests de fumée et les cas d'utilisation des bogues. Une fois le correctif arrivé, nous attribuerions les tâches de nouveau test aux testeurs manuels et nous effectuions nous-mêmes des tests ad hoc rigoureux sur le module pour trouver les bogues critiques masqués.
- S'il n'y a pas de priorité, il serait inutile de revoir d'abord les bogues critiques ou de gravité élevée, et également d'étudier la durée de vie des bogues et de comprendre pourquoi les bogues n'ont pas été corrigés pendant si longtemps pour aider à améliorer le processus global à l'avenir.
À propos des bogues de faible gravité, nous devons prendre une décision d'équipe sur le calendrier et sur la décision de publication de publier ou non la première version avec ces bogues, tout en documentant la même chose et les solutions de contournement si nécessaire. Fournissez également la prochaine date de publication pour le correctif possible si possible.
Donc, étant un QA senior, vous devez mettre en avant votre opinion ferme pour rester "NON" lorsque vous voyez des drapeaux rouges. Ne soyez pas trop flexible
Les autres réponses ici sont bonnes si le but de la question est de donner une réponse concrète.
Cependant, beaucoup d'enquêteurs posent des questions vagues sans réponse précise parce qu'ils veulent savoir comment vous pensez ou comprendre si vous faites des hypothèses sur la question. Ils veulent que vous leur posiez des questions de clarification pour obtenir des détails. Cela aide à guider votre réponse.
Le scénario est vous et 2 autres sont constitués de l'équipe de test. Vous, le responsable, êtes le seul à pouvoir faire de l'automatisation, les autres ne peuvent faire que des tests manuels. Vous avez près de 10 000 bogues qui ont été soulevés et vous disposez de 4 à 5 semaines ou moins avant la livraison de ce produit. Que ferez-vous pour vous assurer que le produit est livré à temps?
Quelques questions à poser:
- Quelle est l'expérience des testeurs QA manuels?
- Les testeurs manuels sont-ils expérimentés dans ce projet? Ou sont-ils également nouveaux dans le projet?
- Les 10 000 doivent-ils être réparés avant la date de livraison?
- Existe-t-il un logiciel de suivi des bogues que les équipes utilisent? Si oui, quoi?
- Comment les bogues connus sont-ils suivis? Ont-ils une priorité, une gravité répertoriée? Sont-ils regroupés / étiquetés par fonctionnalité?
- Existe-t-il des tests automatisés actuellement utilisés pour les logiciels? Si oui, combien de tests unitaires, de tests d'intégration, de tests d'interface utilisateur? Ou dois-je créer tous les tests / frameworks automatisés à partir de zéro dans un délai de 4 à 5 semaines?
- De combien de tests les développeurs sont-ils responsables? Créent-ils des tests unitaires / d'intégration?
- Les 10000 bogues sont-ils des bogues d'interface utilisateur? Ou un mélange de bogues pouvant être testés à l'aide de tests unitaires, de tests d'intégration, de tests d'interface utilisateur?
- Quels appareils doivent être utilisés pour les tests?
- Quel niveau de qualité devons-nous atteindre pour satisfaire les utilisateurs et les parties prenantes? Comment les parties prenantes perçoivent-elles la qualité?
- Comment les parties prenantes déterminent-elles un lancement de projet réussi?
- Quelle est la définition des équipes de done?
- L'équipe aura-t-elle le temps après la sortie du projet pour corriger les bogues? Ou passons-nous au prochain projet? Combien de temps aurons-nous si nous en avons le temps?
- L'équipe utilise-t-elle Agile SDLC ou Waterfall SDLC?
Il y a un nombre infini de questions que vous pouvez poser pour obtenir des éclaircissements dont vous avez besoin pour fournir une réponse bien pensée.
Et, à partir de la conversation détaillée ci-dessus, l'intervieweur a continué à vous demander des détails sur la façon d'inclure les testeurs manuels dans votre plan. Cela vous donne une idée précise de ce que l'intervieweur recherche: il ne veut pas que vous preniez entièrement la charge de tester ce projet vous-même; ils veulent savoir en tant qu'ingénieur SDET / QA de niveau senior comment vous encadrez / dirigez une équipe de testeurs de niveau junior.
Gardez à l'esprit que les entretiens ne doivent pas être un interrogatoire où vous répondez simplement à leurs questions. Les entretiens doivent être une conversation où vous pouvez poser tout ce qui aide à clarifier leurs questions.