上流工程のバグは、下流工程で増幅する
皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。 上流工程ほどいいかげんな品質管理 ソフトウェア開発でよくいわれることに、「上流工程のバグは、下流工程で増幅する」がある。要件定義や基本設計で間違いがあった場合、最終テストの段階でその間違いに気付き、プログラムを修正すると、相当大きな工数がかかってしまうということだ。この工数は、詳細設計よりも基本設計、基本設計よりも要件定義と、（バグの発生が）上流工程になればなるほど大きくなる。 従って、理屈上は上流工程ほど品質チェックを厳重に行わなければならないはずだ。しかし、実
QA: 国民宿舎はらぺこ 大浴場
職場で QA という言葉を使ったら、思ったとおり通じなかった。あの状況を見る限り、無理もないか、とは思ってたけど。とりあえず、QA について、おいらのキャリアで身についていることをメモっておこうと思う。 QA とは? Quality Assurance の略。品質保証。 ソフトウェア開発における QA 基本的には、以下の4つの観点に基づいて行われるべきである。 期待通りに動作すること。 リソースリークが発生していないこと。 パフォーマンスが十分であること。 上記を証明するすべてのテストにおいて、カバレッジが満たされていること。 行うべき作業は主にテスト（動作検証）だが、テストをすれば QA が満たされたということにはならない。どのようなテストを行い、その結果がどうなったかを文書にまとめ、報告できる状態にすることで、初めて QA は満たされたと看做すことができる。 要求に対する QA 「1.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
