ねほり.com

何もないから何かみつかる

エンジニアによる品質保証(品質説明力編)

      2018/12/10

「バグ出しのテスト」をすれば品質が保証できると思いがちですが、そうではありません。

ソフトウェアの品質は、テスト工程ではなく開発工程で高めるものです。

言い換えると、品質向上に貢献できるのは機能の実現に関わるエンジニアです。

つまり、品質向上には「エンジニアが品質意識を持ち取り組む」事が大切なのです。

じゃぁ、ソフトウェアテストの目的って何?

従来から言われている目的

  • ソフトウェアに潜むバグを検出し、修正
  • 求められる要件を満足していることを確認

情報を収集し,アクションにつなげる活動とした捉え方

  • バグの発生状況から、未だ潜むバグの存在を推測し 品質の成熟度を判断
  • バグの作込み要因と、より上流の検証フェーズでの流 出要因を分析して、開発プロセスの問題を特定・対策

要するに、「テストして収集した情報」を使わず、現行のスケジュールを進めるのであれば、テストをする必要がありません。

それはテストをしていないのと同じことになります。

だからこそ、エンジニアに「品質説明力」スキルは不可欠

「品質説明力」とは、ソフトウェアが重要な役割を果たす製品・システムにおいて一定の品質確保が達成されている事実を、供給者側が利用者に対して十分に伝える「スキル=力」です。

tmp4

火災、落下、故障など多くの品質問題を如何にお客様に安心・理解してもらうか?は、このスキルにかかってますが、エンジニアは軽視傾向があります。

その結果、「テスト結果」だけで「品質は安定している」と説明するエンジニアがいます。

  • バグカーブが収束した
  • テスト実施100%完了
  • ○起因の不具合を発見
  • などなど

テストケースは仕様書から生成されるものであり、エンジニアに品質説明を求められる場合は「上流工程の成果物が十分でない」事を疑われると思った方がよいでしょう。

問「なぜ、仕様書の網羅性が不十分なのに、テストを行ったから大丈夫だと言えるの?」

ようするに、エンジニアが説明する必要があるのは、

  • 網羅性が不十分なのテストを実施して、何が確認できたのか?
  • 何が確認できなかったのか?
  • 目標としていた品質に対してどこまでできたのか?
  • 不具合が○件発見されたことは分かったが、で、どうなの?

です。

答「発見&流出した不具合を数でなく、不具合の中身から分析し、既に必要なリカバリプランを立てているので大丈夫です。」

このためには、発見した不具合(バグ)を分析して、要因の特定と品質成熟度を判断することが重要です。

じゃぁ、不具合(バグ)分析って何するの?

バグ分析とは、バグを織り込んだ時期の事実の把握を行い、「要因工程」の絞り込みと「バグの織り込み要因」の特定を行うことです。

バグ分析の目的は主に3種類あります。

類似バグを撲滅するバグの内容を分析し、同様のバグがあるかを把握・対策する
品質成熟度を判断するバグの発生傾向を分析して、未だ潜むバグの存在を推測し品質の成熟度・後工程や最終品質を判断する
バグを再発防止するバグの作込み要因と、上流の検証フェーズでの流出要因を分析して、ソフトウェア開発プロセスの問題を特定・改善する

品質を語る上で必要なのは「品質成熟度を判断する」ためのバグ分析です。

品質成熟度を判断するためのバグ分析とは?

最近の流行に「ODC分析(直交欠陥分類:Orthogonal Defect Classification)」があります。

ODC分析を利用すると、偏在する障害領域を特定するだけではなく、それが作り込まれた開発工程を特定する事ができます。

tmp4

これは、バグ分析の手法の一つとして有効です。

ですが、ODC分析はエンジニア視点というよりプロジェクト視点の分析手法です。

エンジニアが分析により報告する必要があるのは要因分析的手法を用いた上での「何起因(何の要求)の不具合が何故発生したのか?」です。

  • リファクタリングにより発生した不具合なのか?
  • 新機能実装により発生した不具合なのか?
  • 潜在バグなのか?
  • ハードウェア変更起因なのか?
  • OSアップデート起因なのか?
  • などなど

加えて、なぜなぜ分析を5回行うなどで「その不具合が発生した真因」は何なのか?を考察します。

新規要件の不具合が発生した
↓なぜ?
委託先が実装漏れをしてしまった
↓なぜ?
委託先の詳細設計書に記載がなかった
↓なぜ?
基本設計書の記述が不明確で、委託先が詳細設計に落とせなかった
↓なぜ?
基本設計書に一行説明があるだけなので、何を考慮するのか委託先が判断できなかった
↓なぜ?
基本設計書が自由記述になっている
基本設計書のレビューがされていない
委託先と十分なコミュニケーションがとれていない

そして、それらの混入に対する今後の対策(今回のプロジェクト向け・今後のプロジェクト向け)は何なのか?を検討します。

【今回のプロジェクト向け】
基本設計書に対するテストを再度実施
基本設計書に対するテスト網羅性を増やして実施
【今後のプロジェクト向け】
基本設計書フォーマットのテンプレート作成
レビュープロセスを導入
委託先とのQ&Aリストを作り管理

ここまで考察した上で、当初の計画通りの不具合要因しかないのか、リカバリプランは十分か?をエンジニア視点で報告します。

プロジェクトの途中にチェックポイントを設けると、不具合発見されただけで、未修正の不具合も多くあります。

その場合は不具合の真因を考察するのは難しいでしょう。

ただし「何を確認するために行ってるテストか?」が明確であれば、不具合発見時に不具合起因は推測できます。

つまり、事前にプロジェクト特性を加味した品質計画があってこそ、品質説明に納得・安心が生まれます。

tmp4

  • どんな設計をしたら品質目標を達成できるか?
  • どんなテストをしたら品質目標を確認できるか?

言い換えると、明確な品質計画や品質目標なくして、品質説明が妥当か判断はできません。

まとめ

品質は、適切な開発プロセスと技術的な根拠を、事実に基づき示し、目標を満足していることをロジックをもって説明する必要があります。

このためには「開発工程でどのように作り込んでいくのか」が重要であり、品質保証は開発している責任者(エンジニア)の義務です。

 - 2018年(社会人14年), テクノロジー, 調査結果, 品質

  関連記事

DellのVistaマシンのマザーボードの故障

2009年11月29日(日) 修理は二週間かかるそうです 動画編集で購入したDe …

bootstrapの軽量化Part2 不要なCSS定義を削除する

前回までで軽量化に関しては終了・・・。と思っていたが、やっぱり重たい。 boot …

毎年「当たり年」なボージョレ・ヌーボーをランキング

2011年11月02日(水) ボージョレ・ヌーボー・ランキング ボージョレ・ヌー …

ATRAC3(カスラック)回避をしてみたが失敗・・・

2006年07月09日(日) FIN。。。 (o^-‘)b (●^o …

東北地方太平洋沖地震で原発状況と放射能サイト作成

2011年03月16日(水) 原発状況と放射能に関するサイト作成 本日は自宅待機 …

Pythonによるシステムトレード(sbi証券ログイン)

10年前にシステムトレードをVBSで検討したが、結局何もせずに終わった。 Dee …

都川水の里公園でガサガサ・セリ摘み(千葉市若葉区)

メダカを探して自転車で千葉市内を流れる都川を上流に向けて散策していると、 &nb …

Kerasのモデル保存・利用(ディープラーニング)

Kerasを使った学習モデルの書き方に関しては、ある程度調べました。 はじめての …

「線形代数」を「不可」にして再受講するにも難しい

これ以上、日記を更新しないとさすがに後が続かないので、最近の事でも…。&nbsp …

「かごめ歌」を南光坊天海が作ったと言われているが・・・

やった~!10 年ぶりの「大吉」です! 賭け事も「吉」です。では早速祖母の家で賭 …