ソフトウェア・テストpress vol.2

ソフトウェア・テスト PRESS Vol.2

ソフトウェア・テスト PRESS Vol.2

先日購入した書籍を順調に読んでいます。
今のところ2/3ぐらいでしょうか。


感想はというと、仕事に使えるぐらい実践的かつ
テストとは?という知識を体系的に学ぶキッカケになるなと
感じました。

    • 開発で死にそうなときに死にそうな思いをしてテストケースを作って、オペレーターさんに打ち込んでもらった記憶しかありませんから。



まず、ガツンときた内容はというと
インスペクション担当者の思考順序です。
担当者が何を考えてテストをしていくかフロー化したものです。
わがPJの愚痴と共に紹介してみます。


先に説明しておくと、

  1. ここの見出しレベルには、書籍から引用した見出し。
    • 書籍から引用した小説明
      • 自分(こると)のPJに対する愚痴、事実等々。
        • さらに愚痴

と言う按配です。

  1. 成果物の全体像を把握する。
    • 資料の目次、成果物の種別、ハイレベル・ユースケースなどから対象成果物が存在することを確認する。
      • 資料の目次や成果物の種別の把握が中々できない。詳細設計書のはずなのに、基本設計書と詳細設計書が混在してます。(作成日から判断)
      • また、お客様起因による大設計書の見直し対応版と未対応版が混在してます。
        • #チェックしている仕様書は何なんだ?(着たばかりの時思ったこと)
  2. プロセス上の欠陥がないことを検証確認
    • プロセス上作成する予定になっている成果物体系そのものの欠陥を検証する。
    • 作成日付・作成者に着目し、各種成果物の作成順序を検証する。
      • 詳細設計工程にも拘らず、作成日付が基本設計書のものでした。案の定、品質悪し。
      • 基本設計書と詳細設計書が画面説明と帳票項目説明が2重に記載されてます。修正も2重。
  3. プロジェクト管理上の問題がないことを検証する。
    • 成果物が作成途中でないことを確認する。
    • 成果物が完成しているが、課題ペンディング事項ばかりでないことを確認する。
      • 成果物自体に、要調査とか噴出しが残っている。明らかに作成中。
      • 課題管理表は見てないのでなんとも言えず。見たら、指摘項目が増えそうで怖い。
      • 周知メールを見てみると、バッチ処理におけるエラー件数の数え方の調査をしてました。
  4. 1〜2人でサンプリング検証する。
    • 短い時間を設定し、個人で仕様書をサンプリングする。
      • 検証計画が明確になる前にチェックを実施する人数が激増。
      • 計画やチェック観点を作る前にチェック作業に着手・・・。サンプリングなんてやっている時間なし。
  5. 詳細検証
    • 単一ノ成果物が作成者に依存せず均質であることを確認する。
    • 複数の成果物に矛盾不整合がないことを確認する。などなど
      • 今の作業です。
      • 単一ノ設計書のなかで問題激多い。
      • いわんや、複数の成果物では・・・。オンラインとバッチとファイルとデータベースと帳票と・・・。
      • 基本仕様書と詳細仕様書で書かれていることが違うしなぁ・・・。どれを基に作業したかわからない。
  6. 検出欠陥に対する総評をまとめる。
    • 欠陥の偏在性・傾向・トレンド・原因分析を行う。
      • 品質保障部門の人が作業。・・・してくれるはず。ちなみに朝会で前日の内容報告が実施された際には、部長が【一刀両断】の分析をされる。
        • 両断されるのはチェックしている面々。情けなくてやり気が両断。心の中で呆れ返る。誰か突っ込め。絶対冗談だ。
      • 品質保証部門の人が、以前と同じ傾向のエラーばかりだ・・・。と言っていたので、問題を起こしたPJは、改善されない限り同じエラーばかり実施するのだろう。
  7. 対策を立案する。
    • 上記の分析結果より、主原因別に対策を立案する。
      • 私たちはチェックメンバーでしかなくて、エラー箇所を指摘する人のはず。ナのでエラー傾向から分析してください。問題PJの面々。
  8. 再発防止策を検討する。
    • その欠陥に対する再発防止策を検討する。
    • その欠陥に対する再発時の検出方法を検討する。
      • 以前起きたエラー傾向が直っていないとすると・・・。だめやん。
  9. 対策の実施状況をトラッキングする。
    • 対策実施状況を追跡する方法(=評価指標)を決定する。
    • 立案した対策が実施されていることをどうやって追跡するかを検討する。
    • その欠陥が再発した場合、どうやって検知するか測定指標を検討する。
      • 参照先エラーが1コメント/5枚を超えたらまずいですなぁ。

って感じでした。がつんと来た場所は、ことごとく問題が起きているところですね☆(泣き笑い)
続く。