ねほり.com

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

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

      2019/11/13

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

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

[参考]Foundations of software testing ISTQB certification

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

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

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

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

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

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

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

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

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

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

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

tmp4

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

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

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

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

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

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

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

です。

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

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

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

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

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

品質成熟度を判断する(現品質の推定、後工程・最終品質の予測)バグの発生傾向を分析して、未だ潜むバグの存在を推測し品質の成熟度・後工程や最終品質を判断する。それにより後工程の作業内容や作業スケジュールの調整を行い、最終品質が要求レベルに達するようにする。
バグを再発防止する(開発プロセスのカイゼン)なぜ作り込んだのか<作り込み原因>と、なぜ作り込んだバグをレビューやテストで見逃してしまったのか<見逃し原因>の分析から真因を特定し、改善&未然防止を行う。

※ 独立行政法人 情報処理推進機構(IPA)より

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

ですが、重篤問題に関しては「バグを再発防止する」観点での分析結果を求められる事もあります。

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

不具合分類で全体傾向と深堀り不具合を把握

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

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

tmp4

これによりテスト結果だけでは分からない不具合の特徴は見えてきますが、これだけでは足りません。

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

エンジニアには、要因分類手法を用いた上で「何起因(何の要件)の不具合が何故発生したのか?」が求められます。

不具合分析による真因発見と改善・未然防止

次に、なぜなぜ分析等を行い「その不具合が発生した真因」は何なのか?を分析します。

抽象的な真因に辿り着かぬように、具体的な不具合例で行いましょう。

CPU Post processorとAudio Driverの間で、Shared memoryのStatusのミスマッチが発生した状態でリリースされた
↓なぜリリースされたか?
〈エンジニア観点では?〉
[why1] Suspend/Resume機能の処理を守る必要があったが、タイミングにより順序性が守れなかったため
〈テスト観点では?〉
(省略)
↓なぜ順序性が守れなかったか?
[why2] 終了処理をしたと勘違いし、返信していなかったため
↓なぜ勘違いしたか?
[why3] 終了処理に対する他のモジュールの順序性を考慮できてなかった
↓なぜ考慮できてなかったか?
〈設計者観点では?(作り込み原因)〉
[why4] 順序性を守らなければならないThread間のエンジニアの理解(意識)が欠如していたため
〈レビュー者観点では?(見逃し原因)〉
(省略)
〈エンジニアテスト観点では?(見逃し原因)〉
(省略)
↓なぜ欠如していたか?
[why5(真因)] エンジニアがThreadを理解(意識)した開発ができる仕組みがない

なぜなぜ分析で個人の問題にすることは止めましょう。

真因は個人ではなく設計、組織、プロセスにあります。

最後に、真因に対する対策を出します。

【今回のプロジェクト向け】
Audio関連の探索テストや信頼性評価、ランダム試験を拡充し、個別の不具合修正することで乗り切る
【今後のプロジェクト向け】
設計者がThreadを理解(意識)した開発ができる仕組みを作る
→Multi-Thread Warrant Designを利用したアーキテクチャにリファクタリングする

すぐに「○○の観点をレビューに追加する」という対策になりがちですが、これはレビュー者が疲弊するだけです。

また、ヒューマンエラーは必ず発生します。

真因として辿り着くべきは、「不具合を出さない、あるべき設計構造って何?」です。

まとめ

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

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

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

tmp4

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

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

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

  関連記事

確定申告消費税未納の督促状が来た・・・

NTTドコモの基本使用料を最安値にしようとドコモショップへ。自分が「ベーシックプ …

Which holding a wine glass is better, by stem or by bowl?

Most all of Japanese understand that hol …

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

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

2018年の挨拶&昨年の反省

大晦日にランチでパスタ屋の駐車場にマイカーを停めていた。 ここまでは、普通の光景 …

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

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

現在のティラノサウルスの羽毛で覆われていた説は生ぬるい

歴史なんて、全くアテにはならない。 権力者によって作られたもの(士民工商なんてな …

日経ビジネス調べの「ベンチャー社長の平均像」

February 12, 2005 我が大学に通うものなら気になる、この看板。 …

AWS Summit Tokyo 2013 は飯が食べれず

仕事をサボってAWS(Amazon web service) Summit To …

MSX : 超戦士ザイダー バトルオブペガスの攻略方法

MSXとは? 「MSX」と言うコンピュータをご存知だろうか?  &nb …

「課題」は何?(1)(問題・施策との違いとイシューの関係)

「大企業病」という言葉を知ってますか? 一般的な説明は次のとおりです。 保守的で …