バグなんて見逃しちゃえ

可観測性 テストの7原則 バ グ な んて見逃しちゃえ o b s e r v a b i l it y 監視 りふ 22/6/17 NINNO Tech Fest #7 DevOps バグフィルタ JSTQB V字モデル

皆さん、システム開発に 詳しい前提でお話しします NINNO（テクノロジーのプロでイノベーシ ョンを起こす場）ですからね

この絵を見たことある方 いますか？

Katrina Clokie / Bug Filter 🎬後日に翻訳したものを Y o u T u beを 公 開！ 💡網目が大きくなる 💡バグが成長している 4

では、 こちらはいかがでしょう？

V 字モデル 6

バグは内容によって見つけるべきタイミングが違う  “バグフィルター”と”V字モデル”は似ている  バグフィルターには、3つが追加されている（後半でお話し）  バグフィルターは、上からバグをふるいにかけていく メソッドやクラス 画 面 間 の パ ラ メ ー タ 引 き渡 し ユーザーの導線に着目 後半でお話し 7

バグを見逃すとどれくらいコストかかる の？

試算した

「コストモデル」を使った開発品質・生産性向上の取組み  IPAが出したシステム開発における1件のバグのコスト  工程よってバグ対応のコストが違い、基本設計を1としたら何倍になるか  稼働後のバグは1件あたり「240万円」 10

たっかい（ワイの年収分や…）

もっと怖いバグのコストが ある

社会的信用の失墜  コスト試算は難しいが、大きい企業だと「億」は超える  システムを使おうかな？と思っていたユーザーが使用ぜす、売り上げを失う  潜在顧客を失う 社会的信用の失墜 ∞ 億 13

どうすればいいの？

JSTQB ✓テストの7原則 早期テストで時間とコストを節約

✓テストの7原則 早期テストで時間とコストを節約  早期は、設計工程を含む  システムが動かせないとテストできないは思い込み  テスト手段はJSTQBのシラバスへ 社会的信用の失墜 ∞ 億 ここでもテストできる なるべく早くテストをする 16

こわいな…ちゃんと全部テストしよ

JSTQB ✓テストの7原則 全数テストは不可能

✓テストの7原則 全数テストは不可能  すべてのテストはすることは不可能である  下の例だと、すべてを組み合わせると、1250通り  機能は、もっとある 機能 ブラウザ O S種類 OS ver 画面サイズ ログイン Chrome iOS 14 4 ログアウト Safari Android 15 4.7 × 1250通り × 作成 Firefox 更新 削除 × × 16 5.5 Opera 8 5.8 LINE 9 6.1 19

無理や…

しかし、 巧妙なバグは必ずいる

完璧な人間なんていない  ある組み合わせだけで、発生する忍者のような巧妙なバグはいる  これを見逃すと、社会的信用の失墜に繋がる 機能 ブラウザ O S種類 OS ver 画面サイズ ログイン Chrome iOS 14 4 ログアウト Safari Android 15 4.7 × × × × 作成 Firefox 16 5.5 更新 Opera 8 5.8 削除 LINE 9 6.1 22

どうするの？

そんなの見逃してください すまんな

リリースしたい v s リリースできない  “早く”リリースができないと、社会的信用の失墜と同じコストが発生する  リリースしていない期間は、その期間で手に入る売り上げを逃す  お互いに、デッドロックがかかっている 早くリリースしないと いっぱいテストしないと 売り上げを逃がす 社会的信用を失墜する どっちが重いの？ 25

どっちがコスト大きいの？

分からないよ

けど、社会的信用の失墜を小さくできる

どうやって？

バグは、すぐ見つけて すぐ直す （リリース後でも）

早く見つけて、早く直す  社会的信用の失墜にも段階がある  バグが影響するユーザー数が小さければ、コストは小さくできる  ユーザー数は、バグが発生している時間に比例する 31

どうやってすぐ見つけるの？

ALERTING

ここからは後半戦  最初に出てきたバグフィルターに話を移す  話す：ALERTING（アラーティング）、MONITORING（モニタリング）  話さない：LOGGING（ロギング） 34

ALERTING  ALERTING は、想定外のエラーを検知する  テスト工程で見逃してしまったバグ を見つけるフィルターの役割  エラー処理は適切に なんか危ないよ！ Tryで 想定外のエラーを検知 C a t c h して Exceptionを t h r o w しな よ 35

どうやってすぐ直すの？

CI/CD

自動化できるところは自動化  CI/CDは定常作業を自動化することが目的  特に、デプロイ（リリース）はヒトの手だとミスするので自動化最優先  すぐ見つけてすぐ直しても、リリースする時間が長いと意味がない 38

一安心

JSTQB ✓テストの7原則 バグゼロの落とし穴

バグにも色々ある  バグを発生させないために、ユーザーの期待値を下げていないか 41

どうすれば期待を満たせるの？

アンケート ユーザーヒアリング

なるほど、 ユーザーに直接聞けば良いよね

が、それはダメ

ユーザーは、困ったちゃん  ユーザー（人）は、自分の期待を正確には伝えられない  しかも、設計書の行間を読んでほしい、察してチャン 言わなくても ほんとは、こっちだったけど 分かるでしょ 伝わらなかった… 46

どうやって期待を吸い上げるのさ？ （察するのさ）

MONITORING

データは嘘をつかない  MONITORING は、ログからユーザーの行動データを蓄積する  データからは、”ユーザーがシステムをどのように使用しているか”を定量で分かる  データからは、ユーザーの察して…？ が分かる A/Bテスト Metrics ユーザーの行動を蓄積 Events Logs Traces 49

可観測性・ observability の1つ

まとめ というなの宣伝

J aSST’22 N iigataを2022年7月8日（金） にNINNOで開催  テーマは、”可観測性・ observability”  基調講演は”Autify CTO 松浦様”  Githubでエンジニアを経験されて、オライリーの“入門監視”の翻訳も手がけた  freeeのクラウド障害訓練の舞台裏を”人間性”を交えて発表  SREとQAの交わり方 52

新人の方へ （JaSSTに参加して）ちょっぴり テストの世界を広げみませんか？ 会社の方へ 後押ししてくれませんか？

appendix  https://chojugiga.com/  https://www.irasutoya.com/  https://leanpub.com/testingindevops  https://system-kanji.com/posts/v-model  https://www.ipa.go.jp/  https://www.ipa.go.jp/files/000049404.pdf  https://jstqb.jp  https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf  https://togetter.com/li/1771436  https://newrelic.com/jp/blog/how-to-relic/metrics-events-logs-and-traces  https://www.jasst.jp/symposium/jasst22niigata.html  https://www.oreilly.co.jp/books/9784873118642/  https://www.itmedia.co.jp/news/articles/2203/17/news038.html 54

• https://chojugiga.com/
• https://www.irasutoya.com/
• https://leanpub.com/testingindevops
• https://system-kanji.com/posts/v-model
• https://www.ipa.go.jp/
• https://www.ipa.go.jp/files/000049404.pdf
• https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
• https://togetter.com/li/1771436
• https://newrelic.com/jp/blog/how-to-relic/metrics-events-logs-and-traces
• https://www.jasst.jp/symposium/jasst22niigata.html
• https://www.oreilly.co.jp/books/9784873118642/
• https://www.itmedia.co.jp/news/articles/2203/17/news038.html