ねほり.com

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

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

      2018/12/10

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

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

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

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

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

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

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

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

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

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

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

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

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

tmp4

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

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

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

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

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

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

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

です。

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

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

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

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

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

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

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

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

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

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

tmp4

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

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

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

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

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

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

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

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

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

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

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

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

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

tmp4

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

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

まとめ

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

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

 - 2018年, テクノロジー, 品質, 調査結果

  関連記事

小学校3年「3.9+5.1=9.0は減点」に対する歴史的背景と個人的見解

定期的に話題になる小学校教育問題。そして今ホットな話題は次のツイッター。 姪っ子 …

千葉公園のハス池でモツゴ(クチボソ)捕り(千葉県千葉市)

大人も子供と一緒に1,2組は千葉公園のハス池でガサガサしている人がいる。 ただし …

パワーポッターと賢者の転職・日々の振り返り

朝早くから遅くまで、電車の中、土日・・寝ている時間以外はずっと仕事をしてる。 た …

仁保島の14艘の牡蠣仲間の人物一覧は間違い(1/2)

直系の先祖「保田」姓の調査をはじめて約10年が経過しました。 数冊の文献に明治時 …

Kerasを使った株の利益を計算(ディープラーニング)

PytorchはLSTMが難しいらしいし、TensorFlowも難しいので未挑戦 …

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

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

漫画・映画から考えるサバイバル4つの法則

オートキャンプ協会のまとめた「オートキャンプ白書2016」によると、オートキャン …

KerasのFunctional API Modelの構造を理解する(ディープラーニング)

Kerasには2通りのModelの書き方があります。 Sequencial Mo …

常時SSL(https)化に苦戦しながらも対応

2018年7月にGoogle Chromeの新しいバージョン「Chrome 68 …

タイドプールでタコ捕り&磯遊び(千葉県・かなや編)

千葉市内に最も近く磯遊びができる場所に「金谷」があります。 と言っても富津市なの …