タグ

project managementとtestに関するimai78のブックマーク (2)

  • 【連載】実践ソフトウェアテスト考現学 (2) 調査から見る日本のシステムのクオリティ | エンタープライズ | マイコミジャーナル

    調査データは楽観的だが…… 実は諸外国に比べても、サービスイン(または稼働)後の不具合の数から言えば、日人が作るシステムの品質は決して悪くはないようです。 表1のデータは日海外との不具合(欠陥)の数の違いを示した調査結果です(※2)。 このデータは、発注側、受注側の両者が開発の初期からサービスインに至るまで、様々なもどかしさを抱えながらも、そこをうまくすり合わせた結果「欠陥」の少ないシステムを作り上げているということを示している可能性があります。 "欠陥を抑え込む開発を行うためには、しっかりとした品質保証の体制を持つことが必要であることは、言うまでもない" このような考え方がシステム開発を行う組織のトップダウン(経営層)、ボトムアップ(現場)の両方から理解されるとともに、組織体制にも反映されつつあるようです(図1)。この結果として、品質保証に携わる専門スタッフのプロジェクトへの関与が

  • テストにも多角的な視点を(218~224日)

    前回に続き、「テスト」を巡るさまざまな事項や課題を取り上げる。テストにも顧客の立場に立った、多角的な視点が欠かせない。そして稼働後の事故防止につながるバグ情報の分析と活用も重要だ。 テスト中に偶然、変な現象が発生したが、発生条件や経緯が不明確で不良とは断定しにくい場合も出てくる。それでも、「こんなあいまいな事故報告では設計者も納得しないから報告しないでおこう」と無視するのはやはりよくない。あいまいな事象でもせっかく見つかったのだから問題点として取り上げ、報告しておく必要がある。 確認のため再テストしても再現せず、原因究明もできなくて、最終的には何の対策も打てないかもしれないが、重大な事故の前兆である可能性もあるのだから、見つけたものは根拠薄弱でも設計者にきちんと伝えたいものだ。 総合テスト段階になると、システムの品質は安定してくるが、それでも週に1回とか、月に1回とか事故が発生し、顧客から

    テストにも多角的な視点を(218~224日)
  • 1