Les startups devraient avoir une QA dédiée au début du processus. Souvent, QA est ajouté assez tard.
Ma question en deux parties est:
13 Réponses :
En tant que développeur unique pour un démarrage, laissez-moi fournir mon avis:
La plupart des programmeurs que j'ai travaillé avec (y compris moi-même) ne sont pas parfaits pour tester leur propre travail. En tant que spécialiste unique, avez-vous le temps de créer des tests unitaires et une stratégie de test formalisée? Si oui, comment pouvez-vous équilibrer cela contre les demandes d'ajouter des fonctionnalités?
Au début, je viens d'ailé, l'application était assez petite et elle était suffisamment nouvelle que j'étais preety bien de le faire passer. Après la première année, je devais créer une liste de contrôle de scénarios pour que je puisse travailler. Aujourd'hui, j'ai un stagiaire à temps partiel qui utilise ma liste de contrôle. En démarrage, nos clients doivent venir d'abord, nous ne pouvons pas perdre une seule ... ce qui rend difficile. Ce que nous faisons est de fournir une prise en charge du premier knotch. Certains des clients ont mon numéro de cellule. Donc, les fonctionnalités viennent vraiment en premier, nous validons aucun défaut majeur, puis nous réagissons très rapidement.
Bien que j'aimerais avoir ce que le projet de loi suggère, et j'ai eu une équipe d'assurance qualité qu'ils seraient impliqués dans la conception de la go-go. (Dans les autres entreprises, nous avons travaillé, nous avions l'habitude d'avoir une assurance qualité sur toutes nos réunions de conception initiales). En tant que startup, vous devez être agité et vous assurer de ne pas manquer une opportunité car votre devoir doit rigourer un processus.
@JOSH: Oui, mais vous devez également avoir une culture d'équipe et qui reconnaît l'importance de l'AQ. À beaucoup de gens, les QA ne sont pas respectés à cause des préjugés; Ils sont considérés comme des techniciens qui ne sont pas suffisamment qualifiés pour obtenir des travaux de codage. C'est la culture que nous devons changer. Si vous avez des membres QA qui ont à la fois des côtelettes techniques et du soutien de l'équipe, cela peut fonctionner.
Je vais offrir une vue non conventionnelle:
Les premiers membres de l'assurance qualité de bord devraient avoir la compétence de raconter l'équipe de développement lorsqu'ils n'ont pas précisé le projet (et les aidant à atteindre cet objectif).
Pour moi, l'assurance de la qualité n'est pas simplement des tests. Le test est le contrôle de la qualité (QC). Mais vous ne pouvez pas concevoir de tests pour un produit si vous ne savez pas de quoi il est censé faire. C'est une situation qui est trop courante dans un environnement de démarrage - les codeurs frappent furieusement sur un projet sans décider de ce qu'ils construisent.
Le processus d'assurance qualité commence avant le codage:
C'est pourquoi je dis que la première activité de l'assurance qualité devrait être impliquée dans la phase de spécification des exigences.
C'est une déclaration triste que votre opinion est, en fait, non conventionnelle. Cela a été mon mantra à la fois de très grandes et très petites entreprises, mais je l'ai rarement vu bien exécuté.
@ERIC: Ma conviction est que les gens veulent résoudre des problèmes technologiques à l'aide de la technologie. Mais la définition des exigences nécessite un jugement humain, il ne peut pas être automatisé. Il est difficile de décider "Cette fonctionnalité est intégrée, cette fonctionnalité est sortie" mais elle peut être la seule chose la plus importante que nous puissions faire dans le but de la qualité.
@Bill: accepter 100%. Non seulement en contre, mais aussi "cette fonctionnalité n'est pas définie assez clairement que toutes les parties prenantes partagent une compréhension commune de ce qu'elle devrait faire." Que l'un des problèmes provoque des années de développement inutiles des travailleurs.
@ERIC: La solution la plus courante pour cela dans une startup est qu'il existe une personne qui a une vision et le rôle du dictateur bienveillant. : -) Si cette personne aussi a une certaine discipline de discipline pour résister au "Second System Syndrome" (cf. Le mois mythique mois), alors il peut tous se réunir.
@Bill: Comment trouvez-vous des personnes QA qui peuvent bien exécuter ce rôle englobant?
@ERIC: Je n'ai pas compris la réponse à cela. Dans l'expérience, il est difficile d'obtenir de bonnes personnes dans les carrières de l'AQ (aucune infraction destinée à @CLEE), car la QA a un prestige inférieur et un salaire inférieur à celui de la R & D. Peut-être que la réponse est celle du livre de Joel Spolsky, "Smart et obtient des choses." C'est-à-dire que vous n'engagez pas un expert en QA entièrement formé, vous engagez quelqu'un qui est prêt à grandir, puis de les cultiver.
Une autre idée: trouvez un ingénieur logiciel ancien et expérimenté qui sait bien travailler avec les autres et sait écrire de bonnes spécifications d'ingénierie. Ils n'ont pas nécessairement besoin de connaître les dernières technologies de cœur, car la définition et l'écriture des exigences sont des compétences indépendantes de technologie (sans parler de communication). Le rôle "Mentor Qa" pourrait être une excellente occasion de contrer l'âgisme dans l'embauche.
@Bill: Les deux sont de grandes suggestions, merci.
Oui, mais trop de développeurs prennent des tâches QA elles-mêmes éliminant ainsi la séparation entre développement et planification.
@djangofan: Je suis un fan de développement axé sur les tests (commencez par tests, et vous n'êtes pas fait avec votre affectation de codage jusqu'à ce que vous ayez une bonne couverture de test et que des tests passent sur un serveur de construction). Cependant, ce n'est pas un QA. Il suffit de retirer les bugs les plus flagrant afin que QA puisse se concentrer sur les plus intéressants :-)
QA peut être utile, mais jusqu'à ce que vous ayez le financement pour vous assurer que le produit devrait être terminé, l'ajout d'un corps juste pour le test est risqué. Si l'ajout d'un nouveau développeur vous aidera à garantir que le produit est effectué avant que le financement s'épuise, vous devrez peut-être modifier les priorités et obtenir un nouveau développeur.
Les développeurs peuvent avoir besoin de qa, mais si tel est le cas, la personne qui a fait le développement d'une fonctionnalité ne devrait pas le tester.
Vous voudrez peut-être que votre personne d'assurance qualité soit également responsable de la construction d'intégration continue, par exemple, il peut donc avoir besoin de porter plusieurs chapeaux, car tout le monde dans l'équipe portera également plusieurs chapeaux. Trouvez quelqu'un qui peut être très flexible, afin qu'ils puissent aider à libérer les développeurs à faire leur développement.
C'est une idée intéressante d'avoir la personne QA aussi CI. Au moins, s'ils sont capables de gérer ce processus d'une perspective de compétences (ou au moins initiative / apprenant rapide), il offre davantage d'options pour gérer les pics de la demande sur les programmeurs vs. QA.
Pour une start-up, les spécialistes ne sont pas très utiles. Outre la quantité de travail QA nécessaire si vous avez un ou deux développeurs? Ensuite, vous pouvez les faire parler avec des clients possibles et obtenir de meilleures exigences et être plus agile.
Dès que votre entreprise a une taille suffisante et une rentabilité pour permettre une spécialisation.
La plupart des petites entreprises exigent que les gens soient généralistes et porter plus d'un chapeau.
Aucune réponse magique ici, mais la principale chose pour une petite entreprise est que chaque personne doit apporter plus de revenus qu'il n'est payé; Les multiples sont meilleurs que les incréments. C'est un fait, peu importe combien il veut des testeurs indépendants.
J'imagine que les petites entreprises devraient être créatives et faire des choses comme demander à des amis de tester des versions alpha pour des cartes-cadeaux au lieu d'argent ou de travailler avec un client de confiance.
Un modèle différent est que c'est le propriétaire qui porte plusieurs chapeaux et embauche des spécialistes.
Il existe généralement des points de vue différents sur lorsque le démarrage est "de taille suffisante". Les fondateurs veulent souvent garder les effectifs pour gérer le taux de combustion, tandis que l'équipe informatique souhaite que quelqu'un soit en plus testé, testez le code. Les deux sont des préoccupations légitimes. Comment allez-vous frapper l'équilibre?
En tant qu'ingénieur QA par échange, je dirais que c'est bon d'avoir une QA dédiée dès que vous pouvez le balancer. Au cours du cycle de développement initial, QA apportera une perspective différente de la planification des fonctionnalités - à quelle vitesse devrait-elle fonctionner? Quelle est la hauteur d'échelle? Combien d'utilisateurs peuvent-on un support d'installation simultanément?
Un bon ingénieur QA trouve constamment de nouvelles façons de casser les choses. Ayant toujours mis l'accent sur le début, c'est toujours mieux que d'apporter une QA plus tard dans le processus, démoralisant les Devs qui ont pensé qu'ils étaient très bons jusqu'à ce que les nouveaux membres de l'assurance qualité pipissent des centaines de rapports de bugs sur eux, qui doivent ensuite être triagiles (est C'est même un bug? Si QA avait été impliqué dès le début, ils savaient que c'est le comportement prévu! etc), puis réellement fixé.
Et, soyons honnêtes ici ... Si nous parlons une start-up, ils ne vont pas écrire des plans de test ni produire une automatisation utile. Les plans de test sont géniaux une fois que vous avez un produit stable et que vous avez des assurances que toute l'interface utilisateur ne changera pas, et l'automatisation est idéale pour attraper la régression, mais pendant le développement initial, il n'y aura pas être Toutes les régressions parce que vous n'avez pas encore expédié de régresser de.
Vraiment, les compétences importantes Un bon ingénieur d'assurance qualité a besoin de la communication, de l'obstination et de la capacité de venir rapidement rapidement. Si la QA trouve un bogue mais ne peut pas expliquer clairement et concistablement comment cela s'est passé, ce qu'ils faisaient et comment le reproduire, leur utilité diminue rapidement.
J'apprécie vos commentaires, en particulier sur la manière dont le rôle doit évoluer au fil du temps en raison de la nature changeante du logiciel (ensemble de fonctionnalités instables et d'évolution rapide tôt, plus stable, comme étant la maturation du produit).
Typiquement, qa n'est pas nécessaire avant la suite de 1.0 et le produit a un flux de revenus.
Il a juste besoin de "travailler".
Comment savez-vous si "ça marche"? Mon patron, qui a commencé par tester le code lui-même, disait que "vous obtenez ce que vous inspectez."
@Zengeneral, je suis d'accord à contrecoeur (malgré mon autre réponse), car il est souvent vrai qu'un projet logiciel "fait de droite" prend trop de temps pour atteindre le marché des besoins en entreprise d'une start-up.
@Chrisw "ça marche" quand il gagne de l'argent. En tant que gars logiciel, cette attitude est nulle. En tant que dirigeant d'affaires en regardant les visages affamés des employés, c'est le meilleur parcours pour une startup.
Ah oui. Je pensais à l'ancien temps, où vous avez expédié des distributeurs, où tirant une libération (parce que c'était une buggy) serait coûteux (les distributeurs renvoyant votre produit en boîte, et la perte de visage), et vous avez donc voulu savoir avant Vous l'avez expédié si cela fonctionnait.
Je suis un fort croyant dans le développement de logiciels Agile et Lean. Veuillez trouver ici quelques devis de la fabuleuse Mary Poppendieck sur les défauts:
et un dernier:
Donc, pour répondre à vos questions, mon point de vue est le suivant:
@Pascal: J'aime la façon dont vous avez incorporé le processus de qualité dans le processus de développement. Votre réponse est conceptuellement similaire à celle de Bill, mais vient à la question d'un angle différent.
L'idée est en effet d'effectuer toutes les tâches nécessaires pour obtenir un logiciel potentiellement livrable (il s'agit de la "définition du fait") lors de chaque itération. L'objectif est de limiter le nombre d'éléments de travail en cours de traitement, qui est une clé pour réduire le temps de cycle (voir la loi de Little et la théorie de la file d'attente) et devenir plus réactif aux commentaires.
Il y a des tonnes de ressources disponibles en ce qui concerne l'AQ, les testeurs, etc. et votre question (une très bonne) n'a pas de réponse simple. Il n'y a pas de formule magique pour quand, combien, où et à quelle heure ils sont impliqués dans le processus, etc.
Probablement la première chose que vous devriez comprendre est ce que sont vos besoins réels. La plupart des gens (malheureusement) assimilent QA à juste tester. Le test n'est qu'un aspect d'une équipe QA. La plupart des gens commencent par des testeurs dédiés avant de devenir une "vraie" équipe d'assurance qualité.
L'assurance qualité est davantage sur la maintenance préventive, tandis que les tests sont davantage sur la recherche de faits.
Êtes-vous après des testeurs ou quelque chose de plus?
En ce qui concerne les compétences des testeurs, la compétence numéro une est un expert du domaine du produit. Tout le reste est secondaire.
Je suis d'accord à 100% que QA devrait se concentrer sur la prévention des erreurs (beaucoup) de se produire. C'est aussi un très bon commentaire sur l'expérience de domaine. Je pense que cela est souvent négligé car il y a souvent une mentalité de corps d'embauche à faire des tests plutôt que de recruter des experts pour mener l'effort de qualité.
Selon moi, la réponse est la suivante:
En ce qui concerne la première question, la QA devrait être impliquée pendant l'analyse des exigences. De cette manière, les QA peuvent s'asseoir avec le programmateur pour discuter avec l'ingénieur du système pour mieux comprendre les exigences. Dans ce processus, les QA auront une vision claire de l'exigence et d'où wirte les cas de test lorsque le programmeur va pour le codage.
En conséquence, le programmeur et la QA finiront leurs travaux respectifs en même temps.
En ce qui concerne la deuxième question, l'AQ devrait avoir une assez bonne connaissance de l'environnement qu'il doit travailler, des méthodologies de test ainsi que des connaissances de base des tests d'automatisation. S'il s'agit d'un projet de démarrage, il aura le temps de travailler à l'automatisation et d'automatiser davantage les cas de régression et de test de santé mentale. Cela permettra ainsi de gagner du temps et des efforts aussi de l'argent pour la gestion pour livrer le produit.
Avant de disposer d'une assurance qualité, vous avez un responsable de produit avec la vision et l'organisation et vous avez du développement. Avant de charger votre première personne d'assurance qualité, le responsable de produit doit mettre sur le chapeau d'assurance qualité et pouvoir définir les exigences et obtenir les choses avec un cadre de test initial. Ensuite, comme le projet est à l'abri de la petite enfance, vous pouvez louer QA pour commencer à prendre des tâches de gestion de projet à partir du gestionnaire de projet. L'important est d'embaucher une qualité de manette QA et de produits qui sont suffisamment qualifiées afin que le développement ne nécessite pas de mettre sur les chapeaux d'assurance qualité ou de conception.
La plupart des startups que j'ai vécues travaillant dans rarement ont une personne d'assurance qualité / test à plein temps.
Une option, comme mentionné, est d'obtenir quelqu'un qui peut porter des chapeaux de Mulitiple.
Une autre option serait de les embaucher en tant qu'entrepreneurs ou pigistes comme si nécessaire.
Il y a aussi l'idée des tests provenant de la foule à considérer ou à trouver quelqu'un qui peut travailler à distance si cela convient à votre modèle d'entreprise.
Quand faut-il dédié QA d'abord faire partie d'un effort de démarrage et pourquoi?
ans ANS: Je fais moi-même un QA pense, QA doit toujours être impliqué de la start-up depuis sa question de l'assurance qualité. Une QA a besoin de connaître l'ensemble du processus, du comportement de chaque composant impliqué dans le produit.
La tâche principale d'une QA est comme suit:
a) Collecte des exigences du client.
B) en passant par les exigences et comprendre les besoins, car sadite "Le client est le roi".
c) conçoit le plan de test, les cas de test, l'estimation des efforts en fonction des informations recueillies, etc.
d) Tester enfin et dépôt de bogues (REMARQUE: Fichez clairement le bogue, mentionnez le test à reproduire).
Les points mentionnés ci-dessus expliquent clairement pourquoi une QA doit être impliquée de la phase de démarrage.
Q2) Quelles compétences les premiers membres de l'assurance qualité ayant (créer et exécuter des scripts de test, l'automatisation des tests en utilisant des outils courants, écrire des tests d'unité, planifier et exécuter des tests de charge et de stabilité complexes, etc.)?
1) La compétence la plus importante d'une QA devrait avoir est 2) Sur la base de l'exigence écrit des cas de base de l'interface utilisateur et des fonctionnalités de base.
3) QA devrait également être capable de différencier ce qui est dans la portée des tests et ce qui n'est pas.
4) Selon la date limite, devrait être capable de filtrer les priorités de P1 tests-cas et d'exécuter ces premiers.
Il y a un journal de grandes idées ici. Je conviens qu'il est préférable de démarrer QA dès que possible. En ce qui concerne une partie de la tactique, je suis d'accord avec Snehal Mohite et ajouterais un Q3.
Q3) Construisez votre QA pour être agile et automatiser autant d'efforts manuels que vous le pouvez. Assurez-vous que vous avez des "outils du commerce" pour aider à faciliter les choses pour un groupe plus petit d'accomplir. Par exemple, l'ajout d'outils tels que Applitools Eyes pour activer les tests visuels à côté de vos tests fonctionnels. Cela peut vous aider à faire plus avec moins. Obtenir votre équipe a commencé avec les bons outils peut aider à créer une base solide pour vous et vos clients.