「バグ分類に合わせた品質評価」レポ
名古屋大学大学院情報学研究科 森崎修司 准教授
ひとこと要約
バグをあらかじめ分類しておくことでターゲットが明確になり、リスクやコストの合理性の観点から適切な品質評価方法を選択しやすくなる。
バグ分類と品質評価
ここからイベントのメモ。まずは用語の整理。
バグ分類＝欠陥タイプ
起こりそうなバグ・問題（使いづらいなど）のカテゴリを作り、それに応じて品質評価する。
バグを防ぐのと見つけるのを両方合わせて品質評価という。左から右に流れる時間軸を想定し、事前にバグを発見しようとするのをシフトレフト、事後の発見を許容するのをシフトライトという。
バグ分類と品質評価の例を2つ挙げる。
- バグ分類：境界値
境界値を間違えやすい→境界値をテストするとバグを見つけやすい
という経験則がある。
e.g. 18歳未満なら未成年、18歳以上なら成年
しかし仕様を書いた時点でコードを自動生成するなら、境界値分析ではあまりバグは見つからないのでやる意味が薄い。
➡️開発の進め方などに応じて検出の手間や影響の大きさなどから合理的な品質評価方法を検討する！
さまざまな品質評価方法があるが、ターゲットとするカテゴリのバグ・問題をいつ検出するかという判断を明示的にやるといい。
- バグ分類：アクセス集中時に不安定になる
考えられる品質評価
- 事前見積もり
- プロトタイプ
- アーキテクチャレビュー
- コードレビュー
- ストレステスト
- α, βリリース
- 段階的リリース
- リリース後に怒られる
修正コストがあまりかからず、ユーザーのリスクも小さいバグ・問題のカテゴリを特定できていればリリース後に発見・修正することも合理的な判断になる！
「こういうバグ・問題は後から修正でもいいよね」という話はしにくい部分もあるけれど、ここがチームで合意できていれば合理的な判断がしやすくなる。
まずは使ってみないと分かりにくい問題からシフトライトを始めるのが合意形成しやすい。
品質評価方法の選択
- 簡単に検出（評価）できるか
- 低コストで検出（評価）できるか
- リスク低減やユーザー価値向上につながるか
物によっては使い勝手が悪いのは実際に使ってもらわないとわからないのでシフトライトしたい
しかし品質の悪いものをリリースしたくないのでシフトレフトしたい
➡️リスクやコストの合理性から考える
バグ分類の設定方法
このセクションは駆け足だったので森崎先生のこちらのnoteもあわせて参照すると分かりやすいです。
-
(D) 問題種別を直接選定する
-
(D-1) 過去の指摘リストからカードを含む指摘を検索
似てる内容の指摘をまとめてバグ分類にすることで力を入れて品質評価方法とする -
(D-2) 類似アーキテクチャから見つける
アーキテクチャが同じなら起こりえるバグも似ている
A系統、B系統2つの統括があり、１か所にまとめるようなシステムにはバグが起こりやすい場所がある
小売業のシステムでも車載システムでも同じように、各系統とその統括の通信が遅い場合や片方で障害が発生したときの集約箇所は要注意
-
-
(I) 保証すべき内容を明らかにし、それを損なうバグ分類を選定する
- (I-1) 既知の価値（提供すると言っているor提供できていないとわかっている）から、その提供を損なう問題種別を選ぶ
- (I-2) ドメインの観点から保証すべき内容から選ぶ
公共交通機関の座席予約システムなら
予約と対応する座席に過不足がない 当たり前だけどすごく大事
短時間で簡単に予約できる
長いスパンで保守できる 公共交通機関の路線は長期間存続するものなので
これらが阻害されていないか？
事例
-
プログラミングで注意が必要な部分をモデル図から特定
７製品のテストで見つかったバグから注意が必要な箇所を特定
モデル図から注意すべきところが次もわかるのでコーディングするときに気をつける -
自動車の自動運転ソフトウェア開発
テストフェーズごとにどんな分類か考える
単体テストで見つかるバグを車載テストで見つけると勿体無い
シフトレフトする
乗り心地はシフトライトかな
CIで登録順ではなくバグが見つかりそうなテストを優先実行するとテスト時間が短縮できる 👀 -
可読性の度合いからリファクタリングの優先順位見極め
if文だらけのコードと命名の問題があるコードどちらが読みにくいか？
名前に問題がある方が複雑な構造より読み間違える
読解時の読みにくさの感覚は逆で、if文だらけの方が読みにくいというアンケート結果
読みやすいと感じるからと言って読み間違えないとは限らない！ 👀
Q&A
-
発生したバグの分類はどのような基準で行うか
発生した順に具体例から抽象化していく→要因別 -
どのタイミングでテストするかのトレードオフをどう考えるか
修正コストが大きい、修正時間がかかるなどプロダクトの特性に応じて -
LLMを品質評価に使えるか
使える（詳細は機密） -
分類の設定方法として事業に適したアプローチはあるか
どういうメンバーでやるか、委託するか、合意がしやすいかといった開発体制によって変わる 👀
複数人になることで必要な手続きが増えたりする -
どのような基準で検出可能と判断するか
検出方法が設計できれば検出可能と判断する -
アジャイルでどうやってバグ分類するか
現在進行形で困ってる -
バグ分析の頻度
あまりやりすぎるとしんどい
気づいたときにちょくちょくやる
開発の仕方や体制が変わった、機能が変わってしばらくしてからやる -
使用ドキュメントがなくQAのキャッチアップの時間がかかる
先に重要なところを教えて重点的にやってもらう -
シフトレフトの検討ばかりでシフトライトの話が出ない
シフトライトの話はリリース前に考えても仕方ないと合意しやすいものから
見つかっても大したことがないUIの違いなどから -
開発側と品質保証側の視点をうまく組み合わせて方向を一致させるには
ユーザーにとっての価値について合意する -
カナリアリリースでバグが見つかった場合どこまで戻すかにルールはあるか
ルールはないので合意するしかない
戻しやすさで決める
さっさと戻した方が早く一次対策できる
根本的な対策は別の時間軸で考える
論文で検証されたルールはない
「30分間のエラーレートがN％以上ならここまでロールバックするルールにしている」というコメントが
文献リスト
Discussion