Successfully reported this slideshow.
Your SlideShare is downloading. ×

ssmjp 20200622 nlog2n2_ver10_public

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 17 Ad

More Related Content

Recently uploaded (20)

Advertisement

ssmjp 20200622 nlog2n2_ver10_public

  1. 1. やばいバグ曲線LT @nlog2n2 Sekiguchi Toshihiro 2020/6/9 1
  2. 2. なぜ発表するか 2月の ssmjp で、アンケートをとった結果2位だったから。 2020/6/9 2
  3. 3. 今日の発表する内容 • テスター、リリース判定者だったときに出会ったバグ曲線 について語ります。 • やばいバグ曲線 その1~その7 • やばいバグ曲線にさせない方法 • テスターの評価について • まとめ • 今日、発表するバグ曲線は、不具合の合計件数を縦軸、時間の経過 を横軸でグラフにしたものとします。 2020/6/9 3
  4. 4. 単体型 2020/6/9 4
  5. 5. やばいバグ曲線 その1 0 5 10 15 20 25 30 0 5 10 15 20 25 30 バグ曲線 2020/6/9 5 • 特徴 異常なし • 対策 普通にリリース判定して良し リリース判定 不具合件数 テスト日数
  6. 6. やばいバグ曲線 その2 0 5 10 15 20 25 30 0 5 10 15 20 25 30 バグ曲線 2020/6/9 6 • 特徴 ふつうにヤバイ • 対策 不具合数のレポートと傾向を開発リーダーに 連絡し、設計およびコーディングを見直す。 リリース判定 不具合件数 テスト日数
  7. 7. やばいバグ曲線 その3 0 5 10 15 20 25 30 0 5 10 15 20 25 30 バグ曲線 2020/6/9 7 • 特徴 開発中に仕様追加した場合に散見される • 対策 以下の2択を迫られる • リリース判定を見送り、バグ曲線の収束を待つ。 • 追加された仕様を見送り、仕様が追加される前 のコードでリリース判定する。 リリース判定 不具合件数 テスト日数 この辺で仕様追加
  8. 8. やばいバグ曲線 その4 0 5 10 15 20 25 30 0 5 10 15 20 25 30 バグ曲線 2020/6/9 8 • 特徴 途中からえぐいテスターがプロジェクトにアサ インされた。 開発者の癖を見て不具合を見つける人だったり、 特殊環境を構築できる人だったり多種多様。 • 対策 品質に難ありとして、リリース判定見送り。 バグ曲線が治まるまで待つか、設計見直し。 リリース判定 不具合件数 テスト日数 この辺で ゴッドハンド投入
  9. 9. やばいバグ曲線 その5 0 5 10 15 20 25 30 0 5 10 15 20 25 30 バグ曲線 2020/6/9 9 • 特徴 リリース判定調整中に致命的な不具合が見つか る。 • 対策 リリース日を伸ばして、再テスト。 打ち上げや旅行などが延期され、非常に辛い。 リリース判定 不具合件数 テスト日数
  10. 10. 複合型(政治的立ち回りが必要) 2020/6/9 10
  11. 11. やばいバグ曲線 その6 0 5 10 15 20 25 30 0 5 10 15 20 25 30 バグ曲線 2020/6/9 11 • 特徴 もはや曲線ではない。 インフラだけ社内でつくり、ベンダー製品を載 せて提供するサービスにありがち。 • 対策 ベンダーコントロールしかない。 契約範囲内での品質が保ててないとして、エビ デンスや問合せし続ける。 どうしてもダメなときは、ソフトウェアの作り やシステムの設計手直し手法などを提案する。 リリース判定 不具合件数 テスト日数 環境構築 テスト設計 負荷テスト
  12. 12. やばいバグ曲線 その7 0 5 10 15 20 25 30 0 5 10 15 20 25 30 バグ曲線 2020/6/9 12 • 特徴 3つ以上のコンポーネントを同時にリリース判 定するときに起こりうる。垂直統合。 傾向としてファームウェアが一番不具合件数が 多い。縦割り組織の場合、他の開発チームに政 治的圧力を掛けてくる、リーダーもいる。 • 対策 同時でのリリース判定は不可。 可能なものからリリース判定を行う。 もしウォータフォールで開発しているなら、他 のコンポーネントを条件付きリリース可とし、 不具合件数が収束してないコンポーネント関連 の課題の設定を行う。 リリース判定 不具合件数 テスト日数 ファームウェア アプリケーション クラウドサービス
  13. 13. 対処法 2020/6/9 13
  14. 14. やばいバグ曲線にさせない方法 β版テストの初期段階で大まかな不具合を大量に見つけるために、 以下のようにテストを実施します。 1. テスト計画を作成中に、シナリオテスト・モンキーテスト・負荷テストを 実施。モンキーテストには開発者と相性のいいテスター(宿敵・ゴッドハン ド)を割り当てる。 2. ざっくりとしたテスト結果を把握し、できたソフトウェアの不具合傾向を QAと開発チームで共有する。 3. 不具合傾向からテスト設計や仕様関する修正を行い、実際のテストの実施 を開始する。 2020/6/9 14
  15. 15. テスターの価値について 余談ですが、不具合1件ごとの価値については証明することができません。 いわゆる悪魔の証明になるケースが一般的です。 計算しやすいのは、 ・不具合が原因で保守対応にかかったコスト ・お客様への保証金 などですが、テスト工程の段階では分からないため、 不具合1件を修正したときの価値は分かりません。 よって、不具合を多く見つけたとしても、テスターへの評価は計算しにくく、 評価面談などの場で非常に困ることが多いです。 2020/6/9 15
  16. 16. まとめ 不具合の件数が多けりゃいいってもんじゃないことを肝に命じておいてください。 開発者の敵ですよー。 ここまで色んなバク曲線を見てきたけれど、最後に私が言いたいことは、 ソフトウェアの品質をバク曲線だけで判断することは良くないことですよー。 らーらーらーらーらーらー… 2020/6/9 16 終わり 実際は、要件定義の段階で、ユーザーの要求をどれだけ満たすか、 使い勝手、保守のし易さ、レスポンス速さ、見栄え等、色々あると思います。
  17. 17. スペシャルサンクス • 以下の素材やスライドデザインを参考にしました。 • プレゼンテーション用アイコン(yuyarinさん) https://github.com/yuyarin/presentation_icons • 運用自動化、不都合な真実(波田野さん) https://speakerdeck.com/opelab/20171212-automation 2020/6/9 17

×