SSMJP-20200622-NLOG2N2

やばいバグ曲線LT @nlog2n2 Sekiguchi Toshihiro 2022/3/28 1

なぜ発表するか 2月の ssmjp で、アンケートをとった結果2位だったから。 2022/3/28 2

今日の発表する内容 • テスター、リリース判定者だったときに出会ったバグ曲線 について語ります。 • やばいバグ曲線 その１～その７ • やばいバグ曲線にさせない方法 • テスターの評価について • まとめ • 今日、発表するバグ曲線は、不具合の合計件数を縦軸、時間の経過 を横軸でグラフにしたものとします。 2022/3/28 3

単体型 2022/3/28 4

やばいバグ曲線 その１ • 特徴 異常なし バグ曲線 30 • 対策 普通にリリース判定して良し 25 不具合件数 20 15 10 5 0 0 5 10 15 テスト日数 2022/3/28 20 25 30 リリース判定 5

やばいバグ曲線 その2 • 特徴 ふつうにヤバイ バグ曲線 30 • 対策 不具合数のレポートと傾向を開発リーダーに 連絡し、設計およびコーディングを見直す。 25 不具合件数 20 15 10 5 0 0 5 10 15 テスト日数 2022/3/28 20 25 30 リリース判定 6

やばいバグ曲線 その3 • 特徴 開発中に仕様追加した場合に散見される バグ曲線 30 • 対策 以下の2択を迫られる 25 不具合件数 20 • リリース判定を見送り、バグ曲線の収束を待つ。 • 追加された仕様を見送り、仕様が追加される前 のコードでリリース判定する。 15 10 この辺で仕様追加 5 0 0 5 10 15 テスト日数 2022/3/28 20 25 30 リリース判定 7

やばいバグ曲線 その4 • 特徴 途中からえぐいテスターがプロジェクトにアサ インされた。 開発者の癖を見て不具合を見つける人だったり、 特殊環境を構築できる人だったり多種多様。 バグ曲線 30 25 不具合件数 20 • 対策 品質に難ありとして、リリース判定見送り。 バグ曲線が治まるまで待つか、設計見直し。 15 10 この辺で ゴッドハンド投入 5 0 0 5 10 15 テスト日数 2022/3/28 20 25 30 リリース判定 8

やばいバグ曲線 その5 • 特徴 リリース判定調整中に致命的な不具合が見つか る。 バグ曲線 30 25 • 対策 リリース日を伸ばして、再テスト。 打ち上げや旅行などが延期され、非常に辛い。 不具合件数 20 15 10 5 0 0 5 10 15 テスト日数 2022/3/28 20 25 30 リリース判定 9

複合型（政治的立ち回りが必要） 2022/3/28 10

やばいバグ曲線 その6 • 特徴 もはや曲線ではない。 インフラだけ社内でつくり、ベンダー製品を載 せて提供するサービスにありがち。 バグ曲線 30 25 不具合件数 20 • 対策 ベンダーコントロールしかない。 契約範囲内での品質が保ててないとして、エビ デンスや問合せし続ける。 どうしてもダメなときは、ソフトウェアの作り やシステムの設計手直し手法などを提案する。 15 10 5 0 0 5 10 環境構築 テスト設計 負荷テスト 15 テスト日数 2022/3/28 20 25 30 リリース判定 11

やばいバグ曲線 その7 バグ曲線 30 ファームウェア 25 アプリケーション 不具合件数 20 15 10 5 0 0 5 10 15 テスト日数 2022/3/28 20 • 特徴 3つ以上のコンポーネントを同時にリリース判 定するときに起こりうる。垂直統合。 傾向としてファームウェアが一番不具合件数が 多い。縦割り組織の場合、他の開発チームに政 治的圧力を掛けてくる、リーダーもいる。 • 対策 同時でのリリース判定は不可。 可能なものからリリース判定を行う。 クラウドサービス もしウォータフォールで開発しているなら、他 のコンポーネントを条件付きリリース可とし、 不具合件数が収束してないコンポーネント関連 25 30 の課題の設定を行う。 リリース判定 12

対処法 2022/3/28 13

やばいバグ曲線にさせない方法 β版テストの初期段階で大まかな不具合を大量に見つけるために、 以下のようにテストを実施します。 1. テスト計画を作成中に、シナリオテスト・モンキーテスト・負荷テストを 実施。モンキーテストには開発者と相性のいいテスター(宿敵・ゴッドハン ド)を割り当てる。 2. ざっくりとしたテスト結果を把握し、できたソフトウェアの不具合傾向を QAと開発チームで共有する。 3. 不具合傾向からテスト設計や仕様関する修正を行い、実際のテストの実施 を開始する。 2022/3/28 14

テスターの価値について 余談ですが、不具合1件ごとの価値については証明することができません。 いわゆる悪魔の証明になるケースが一般的です。 計算しやすいのは、 ・不具合が原因で保守対応にかかったコスト ・お客様への保証金 などですが、テスト工程の段階では分からないため、 不具合1件を修正したときの価値は分かりません。 よって、不具合を多く見つけたとしても、テスターへの評価は計算しにくく、 評価面談などの場で非常に困ることが多いです。 2022/3/28 15

まとめ 不具合の件数が多けりゃいいってもんじゃないことを肝に命じておいてください。 開発者の敵ですよー。 ここまで色んなバク曲線を見てきたけれど、最後に私が言いたいことは、 ソフトウェアの品質をバク曲線だけで判断することは良くないことですよー。 らーらーらーらーらーらー… 実際は、要件定義の段階で、ユーザーの要求をどれだけ満たすか、 使い勝手、保守のし易さ、レスポンス速さ、見栄え等、色々あると思います。 2022/3/28 終わり 16

スペシャルサンクス • 以下の素材やスライドデザインを参考にしました。 • プレゼンテーション用アイコン（yuyarinさん） https://github.com/yuyarin/presentation_icons • 運用自動化、不都合な真実（波田野さん） https://speakerdeck.com/opelab/20171212-automation 2022/3/28 17

• https://github.com/yuyarin/presentation_icons
• https://speakerdeck.com/opelab/20171212-automation