1.What le « logiciel est-il de la garantie de la qualité » ?
La QA de logiciel comporte le procédé entier de développement de logiciel - surveillant et améliorant le processus, s'assurant que toutes les normes et procédures convenues sont suivies, et s'assurant que des problèmes sont trouvés et traités. Elle est orientée au « empêchement ». (Voir la section de livres pour une liste de livres utiles sur la garantie de la qualité de logiciel.)
2.What est « logiciel examinant » ?
L'essai implique l'opération d'un système ou d'une application dans des conditions commandées et évaluer les résultats (par exemple, « si l'utilisateur est dans l'interface A de l'application tout en à l'aide du matériel B, et fait C, alors D devrait se produire »). Les conditions commandées devraient inclure des conditions normales et anormales. L'essai devrait intentionnellement essayer de faire des choses tourner mal pour déterminer si les choses se produisent quand elles ne devraient pas ou les choses ne se produisent pas quand elles devraient. Il est orienté à la « détection ».
Les organismes changent considérablement dans la façon dont ils assignent la responsabilité de la QA et de l'essai. Parfois ils sont la responsabilité combinée d'un groupe ou individu. En outre le terrain communal sont des équipes de projet qui incluent un mélange des essayeurs et des lotisseurs qui travaillent étroitement ensemble, avec des processus globaux de QA surveillés par des chefs de projet. Il dépendra la taille d'une quelle le meilleur des ajustements organisation et la structure d'affaires.
3. Que quelques échecs principaux récents de système informatique sont-ils provoqués par des erreurs de programmation ?
* Les médias rapporte en janvier de 2005 ont détaillé des problèmes graves avec un gouvernement de profil haut de $170 millions États-Unis IL projet de systèmes. L'essai de logiciel était l'un des cinq domaines problématiques principaux selon un rapport de la commission passant en revue le projet. Les études étaient en cours de déterminer ce qui, le cas échéant, partage du projet pourrait être récupérée.
* En juillet 2004 les journaux ont signalé qu'un nouveau système de gestion d'assistance sociale de gouvernement au Canada coûtant plusieurs centaines de million de dollars ne pouvait pas manipuler une augmentation simple de taux des indemnités après avoir été rendu opérationnel de phase. Censément le contrat original a tenu compte de seulement 6 semaines de contrôle de réception et le système n'a été jamais examiné pour sa capacité de manipuler une augmentation de taux.
* Des millions de comptes bancaires ont été effectués par des erreurs dues à l'installation insuffisamment d'examiné intègrent dans le logiciel dans le système de traitement transactionnel d'une banque nord-américaine importante, selon des rapports de nouvelles de mi-2004. Les articles concernant l'incident ont déclaré que cela a pris deux semaines pour fixer toutes erreurs résultantes, que les problèmes additionnels ont résulté quand l'incident a dessiné un grand nombre d'attaques phishing d'E-mail contre les clients de la banque, et que tout le coût de l'incident pourrait excéder $100 millions.
* Un bogue dans le logiciel de gestion d'emplacement utilisé par des compagnies avec un pourcentage significatif du trafic de World Wide Web a été rapporté en mai de 2004. Le bogue a eu comme conséquence des problèmes d'exécution pour plusieurs des emplacements simultanément et a exigé la neutralisation du logiciel jusqu'à ce que le bogue ait été fixe.
* Selon des rapports de nouvelles en avril de 2004, une erreur de programmation a été déterminée pour être un contribuant important 2003 à l'arrêt total du nord-est, le plus mauvais échec de système d'alimentation dans l'histoire nord-américaine. La perte impliquée par échec de courant électrique à 50 millions de clients, à arrêt obligatoire de 100 centrales électriques, et à pertes économiques estimées à $6 milliards. Le bogue était censément dans un système fournisseur-fourni de surveillance et de gestion de la puissance de l'entreprise de service public, qui ne pouvait pas correctement manipuler et rendre compte d'un confluent peu commun des événements au commencement localisés. L'erreur a été trouvée et corrigée après avoir examiné des millions de lignes de code.
* Début 2004, les rapports de nouvelles ont indiqué l'utilisation intentionnelle d'une erreur de programmation comme outil de contre-espionnage. Selon le rapport, au début des années 80 une nation a surreptitiously permis au service de l'espionnage d'une nation hostile de voler une version de logiciel industriel sophistiqué qui intentionnel-avait ajouté des pailles. Ceci a par la suite eu comme conséquence la rupture industrielle principale dans le pays qui a employé le logiciel défectueux volé.
* Un détaillant important des États-Unis a été censément frappé avec une grande amende de gouvernement en octobre de 2003 dus aux erreurs de site Web qui ont permis à des clients de regarder les ordres en ligne d'un anothers.
* Les histoires de nouvelles en automne de 2003 ont déclaré qu'une compagnie de fabrication a rappelé tous leurs produits de transport afin de fixer un problème logiciel causant l'instabilité dans certaines circonstances. La compagnie a trouvé et a rapporté le bogue lui-même et lance le procédé de rappel dont une mise à niveau de logiciel a fixé les problèmes.
* En janvier de 2001 journaux a rapporté qu'un chemin de fer européen important a été frappé par les répercussions du bogue de Y2K. La compagnie a constaté que plusieurs de leurs plus nouveaux trains ne courraient pas en raison de leur incapacité d'identifier la date « 31/12/2000 » ; les trains ont été démarrés en changeant les arrangements de la date de système de commande.
* Les rapports de nouvelles en septembre de 2000 ont raconté un fournisseur de logiciel arrangeant un procès avec une grande société de prêt immobilier ; le fournisseur avait censément fourni un système de traitement en ligne d'hypothèque qui n'a pas répondu à des caractéristiques, a été livré tard, et n'a pas travaillé.
* Début 2000, des problèmes principaux ont été signalés avec un nouveau système informatique dans une grande zone suburbaine d'école d'Etat des États-Unis avec les étudiants 100.000+ ; les problèmes ont inclus 10.000 cartes et étudiants incorrects de rapport à gauche échoués par les systèmes échoués d'enregistrement de classe ; le CIO de la zone a été mis le feu. La zone d'école a décidé de le rétablir est original 25 ans - vieux système pendant au moins une année jusqu'à ce que les bogues aient été établis du nouveau système par les fournisseurs de logiciel.
* En octobre de 1999 $125 millions le vaisseau spatial de navette spatiale de climat de la NASA Mars était censé pour être perdu dans l'espace dû à une erreur de conversion de données simple. On l'a déterminé que le logiciel de vaisseau spatial a employé certaines données dans les unités anglaises qui devraient avoir été dans les unités métriques. Parmi autre charge, la navette spatiale était de servir un relais de communications pour la mission polaire de Mars Lander, qui a échoué pour des raisons inconnues en décembre 1999. Plusieurs panneaux de investigation ont été assemblés pour déterminer les échecs de processus qui ont permis à l'erreur de disparaître non détectée.
* Les bogues dans le logiciel soutenant un grand réseau informatique à grande vitesse commercial ont affecté 70.000 clients d'affaires pendant 8 jours en août de 1999. Parmi ceux affectés était le système de télétransactions boursières du plus grand échange à terme des États-Unis, qui a été arrêté pour la majeure partie d'une semaine en raison des pannes.
* Les rapports de nouvelles du janvier 1998 ont raconté des problèmes logiciels à une compagnie importante de télécommunications des États-Unis qui a eu comme conséquence aucuns frais pour des appels de fond pendant un mois pour 400.000 clients. Le problème a disparu non détecté jusqu'à ce que les clients aient appelé avec des questions au sujet de leurs factures.
4.Why est-il souvent difficile que la gestion devienne-t-elle sérieux au sujet de la garantie de la qualité ?
* La solution des problèmes est un processus de haut-visibilité ; l'empêchement des problèmes est bas-visibilité. Ceci est illustré par une vieille parabole : En Chine antique il y avait une famille des guérisseurs, un de qui a été connu dans toute la terre et a utilisé en tant que médecin à un grand seigneur.
5.Why le logiciel a-t-il des bogues ?
* Malentendu ou aucune communication - quant aux détails de quelle application devrait ou ne devrait pas faire (les conditions de l'application).
* Complexité de logiciel - il peut être difficile comprendre la complexité des applications courantes de logiciel pour n'importe qui sans expérience du développement de logiciel de moderne-jour. les applications Multi-à gradins, le serveur de client et les applications réparties, les communications de données, les énormes bases de données relationnelles, et la taille fine des applications tous ont contribué à la croissance exponentielle de la complexité de logiciel/système.
* Erreurs de programmation - les programmeurs, comme n'importe qui autrement, peuvent faire des erreurs.
* Les conditions changeantes (si documenté ou non documenté) - l'utilisateur peuvent ne pas comprendre les effets des changements, ou peuvent les comprendre et demander de toute façon - la conception, la remise à plus tard des ingénieurs, effets sur d'autres projets, fonctionnent les besoins en matériel déjà réalisé qui peuvent devoir être refaits ou jetés dehors, qui peuvent être affectés, etc. S'il y a beaucoup de changements mineurs ou dépendances connues et inconnues des changements de commandant, parmi des parties du projet être susceptible d'agir l'un sur l'autre et de poser des problèmes, et la complexité des changements coordinating peut avoir comme conséquence les erreurs. L'enthousiasme du personnel de technologie peut être affecté. Dans quelques environnements à changement rapide d'affaires, les conditions sans interruption modifiées peuvent être un fait de la vie. Dans ce cas-ci, la gestion doit comprendre les risques résultants, et les ingénieurs de QA et de contrôle doivent s'adapter et plan pour que l'essai étendu continu garde les bogues inévitables de manquer de commande - à voir « ce qui peut être fait si les conditions changent sans interruption ? » dans la partie 2 du FAQ. Voir également les informations sur des approches « agiles » telles que XP, aussi dans la partie 2 du FAQ.
* Pressions de Temps - l'établissement du programme des projets de logiciel est difficile au mieux, souvent exigeant beaucoup de conjecture. Quand les dates-limites apparaissent indistinctement et le craquement vient, des erreurs seront faites.
* moi - les gens préfèrent dire des choses comme :
* * « aucun problème »
* * « morceau de gâteau »
* * « je peux fouetter cela dehors en quelques heures »
* * « il devrait être facile de mettre à jour ce vieux code »
* au lieu de :
* * « qui ajoute beaucoup de complexité et nous pourrions finir vers le haut de faire beaucoup des erreurs »
* * « nous n'avons aucune idée si nous pouvons faire cela ; nous nous envolerons la »
* * « je ne peux pas estimer combien de temps elle prendra, jusqu'à ce que je jette un coup d'oeil étroit à lui »
* * « nous ne pouvons pas figurer dehors ce que ce vieux code de gaine en premier lieu »
S'il y a trop peu réaliste de « aucun problème », le résultat est des bogues.
* Code mal documenté - il est dur pour maintenir et modifier le code qui est mal écrit ou mal documenté ; le résultat est des bogues. Dans beaucoup d'organismes la gestion ne fournit aucune incitation pour des programmeurs pour documenter leur code ou pour écrire clairement, code compréhensible et maintenable. En fait, c'est habituellement l'opposé : ils obtiennent des points la plupart du temps pour s'avérer rapidement le code, et il y a sécurité d'emploi si personne autrement ne peut la comprendre (« s'il était difficile d'écrire, il devrait être difficile de lire »).
* Les outils de développement de logiciel - outils visuels, bibliothèques de classe, compilateurs, outils scripting, etc. présentent souvent leurs propres bogues ou sont mal documentés, ayant pour résultat les bogues supplémentaires.
6.How les nouveaux processus de QA de logiciel peuvent-ils être présentés dans une organisation existante ?
* Dépend beaucoup de la taille de l'organisation et des risques impliqués. Pour de grands organismes avec (en termes de vies ou propriété) des projets à haut risque, la gestion sérieuse achètent est priée et un processus formalisé de QA est nécessaire.
* Là où le risque est inférieur, la gestion et d'organisation achètent et l'exécution de QA peut être une plus lente, processus d'étape-à-un-temps. Des processus de QA devraient être équilibrés avec la productivité afin de garder la bureaucratie de sortir de la main.
* Pour de petits groupes ou projets, un processus plus ad-hoc peut être approprié, selon le type des clients et de projets. Beaucoup dépendra des fils d'équipe ou des directeurs, rétroaction aux réalisateurs, et à assurer à communications proportionnées parmi des clients, des directeurs, des lotisseurs, et des essayeurs.
* La plupart de valeur pour l'effort sera souvent dans (a) des processus de gestion de conditions, avec un but des caractéristiques de condition précises, complètes, testables incorporées dans les conditions ou la documentation de conception, ou dans « agile » - dactylographier à des environnements la coordination continue étendue avec des utilisateurs, (b) des inspections de conception et des inspections de code, et (c) post-mortems/retrospectives.
7.What est vérification ? validation ?
* La vérification implique typiquement des revues et des réunions pour évaluer des documents, des plans, le code, des conditions, et des caractéristiques. Ceci peut être fait avec des listes de contrôle, des listes de questions, des walkthroughs, et des réunions d'inspection. La validation comporte typiquement l'essai réel et a lieu après que des vérifications soient accomplies. Le terme « IV et V » se rapporte à la vérification et à la validation indépendantes.
8.What est un « walkthrough » ?
* Un « walkthrough » est une réunion informelle pour l'évaluation ou les buts informationnels. Peu ou pas de préparation est habituellement exigée.
