欠陥を作りこむ機会
こんにちは。Azukaritai の村穂です。最近「デバッグの理論と実践」という本を読み始めたのですが、16章「失敗から学ぶ」に書かれていた「欠陥はどこから来たのか」というテーマの話が興味深く、日々の業務にすぐに活かせそうなことが書かれていたので note でも紹介したいと思います。
本に書かれていたことをそのまま書いているというよりは、自分の解釈も含まれているので、原文を確認したい方はぜひ書籍を買ってご自身で確認していただければと思います。
また「欠陥」というワードが出てきますが「バグ」と読み替えてもらってもいいと思います。
3つの欠陥を作りこむ機会
本には、3つの欠陥を作りこむ機会が説明されていました。
「仕様」
「プログラミング」
「品質保証プロセス」
それぞれの理由を書いていきます。
「仕様」が欠陥を作りこむ機会である理由
ざっくりまとめると、以下が理由だと書かれていました。
満たすべき要件が膨大であるため
かつ、それらの要件は相互に関連し合うため
機能要件、非機能要件など、システム開発において満たすべき要件は膨大です。また、ある要件がある要件に影響を及ぼすことがあるなど、相互に関連しています。そういった性質により、仕様が複雑になり欠陥を埋め込む可能性が高まってしまいます。
「プログラミング」が欠陥を作りこむ機会である理由
ざっくりまとめると、以下が理由だと書かれていました。
プログラムの構造上、仕様が複雑でなくても実現する手段を複雑にできてしまうため（制御の流れるパスの選択肢が多かったり、長かったり、また関与するコンポ―テントが多いほどプログラムは複雑になる）
1つのコンポーネントが満たすべき要件と制約が多いほど、そのコンポーネントの仕様は複雑になるため
仕様が複雑でなくても、プログラミングの仕方がよくない場合、処理が複雑になってしまいます。複雑な処理は、その後プログラミングをする人間の間違いを誘発しやすくなります。
「品質保証プロセス」が欠陥を作りこむ機会である理由
ざっくりまとめると、以下が理由だと書かれていました。
テストはプログラムの限られた範囲の実行しかカバーすることができない
仕様やプログラムの複雑さが直接品質保証プロセスの複雑さに繋がる
ソフトウェアテストの7原則にもある通り、全数テストは不可能です（組み合わせパターンが膨大で非現実であるため。すごく単純なソフトウェアは例外）。そのため、一部のみしかテストができないことになりますが、それにより見落とす可能性のある欠陥が出てきます。
今後の欠陥発生を抑えるために何をすればいいのか
欠陥を0にすることは現実的ではありません。しかし、発生した欠陥から学び、その後の欠陥発生を抑えることはできるはずです。本には、欠陥を作りこむ機会に対して、どのような工夫をすれば欠陥の作りこみを抑えることができるかについても説明がありました。
「仕様」に問題がある場合
ざっくりまとめると、以下の工夫が書かれていました。
仕様に対して品質保証プロセスを適用する。仕様に対してテストする。
仕様の記述を、準形式的・形式的な方法を導入して正確さを高める
自動化の度合いを高める（モデル駆動開発などの活用）
一つ目は、シフトレフトの話に近いと思います。
仕様の記述の仕方が人それぞれ異なっていると、明瞭さにばらつきが出てしまいます。あらかじめフォーマット（形式）を用意しておき、それに沿って仕様を記述することで一定の明瞭さを担保することができます。
「プログラミング」に問題がある場合
ざっくりまとめると、以下の工夫が書かれていました。
仕様を正確にする（あいまいな記述を避ける）
コンポーネント間の干渉・相互作用を制限し、複雑さを減らす
プログラムを説明する人間のためのドキュメントを用意・改善する
アサーションを仕込む（問題があった時すぐに気づけるようにする）
過去のバグから学びプログラミングスキルを向上させる
プログラミング言語を変更する
プログラミング言語は新しく出たものほど、人間が間違った記述をしづらいものになっています。プロジェクトによっても適したプログラミング言語は変わってくると思いますが、欠陥を防ぐという観点でも変更を検討してみるといいかもしれません。
「品質保証プロセス」に問題がある場合
ざっくりまとめると、以下の工夫が書かれていました。
問題の検出に失敗したテストスイートの改善（拡張）
より早く、より多くのテストを行う
コードのレビューを行い、コードの動作や役割を明快にしてもらえるような働きかけをする
分析ツールを導入し、あやしいコードを早期に検出する
カバレッジメトリクス（優先度の高いテスト範囲）を調整する
ミューテーションテストを実施し、品質保証プロセスの品質をテストする
すでに書いたように、全数テストは不可能なので、組み合わせパターンが増えてしまう前にテストをしたり（より早く、より多くのテストを行う）、欠陥から学び、テストスイートを調整する動きが重要です。
さいごに
最後まで読んでいただきありがとうございます。乱暴なまとめ方をしている部分のあるので、ぜひ書籍を実際に読んでいただくのをお勧めします。
今回の内容は JaSST nano の発表用にまとめた資料を note 向けにアレンジしたものになります。JaSST nano の発表は今回が初めてでとても緊張しました…。もし聞いていた方がおられたら、お聞き苦しい思いをさせてしまいすみません…。発表の最後でも話しましたが、バグ分析に関する知見に関してラフに雑談していただける方がおられましたら繋がりたいです！ぜひお気軽に Azukaritai へご連絡ください。
この記事が気に入ったらサポートをしてみませんか？