Regional Scrum Gathering Tokyo 2021 Day 2 「What’s Testing Got to do with Quality?」

202/01/07に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14730/whats-testing-got-to-do-with-quality

チーム参加してきました

aslead Agile のチーム「オキザリス」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。

今日のメッセージ

• 品質を保つためにどのように開発をしているのか
• 品質とテストは混同されがち
• 最後に品質の測定方法を話していく

品質は曖昧で説明しづらいもの

• Q. 3つのお茶に中からどれを選ぶか
  • 緑茶
  • 抹茶
  • 紅茶

味？好み？品質？等級？茶葉の日照時間？そういったことを考えたか？
価格を考慮するとどうか？

品質とはだれかにとっての価値である

少しシンプルすぎると思うが、共通しているのは一貫性。
そのときの”誰”というのはお客さんによって違うのでは？

品質の視点

• プロダクト視点
• プロセス視点
• 顧客の視点
• 社内と社外の視点

5 approaches to quality　（David A. Gravin）

1. 製造ベース
2. 製品ベース（正しいものを作っているか？）
3. ユーザベース
4. 価値ベース
5. 超越（一目見ただけで質が良いものだとわかる）

お茶の例は「どれが好きか？」という点でユーザベース。
価格が付与された場合は「価格は？利益は？」という点で価値ベース。

異なる視点から質を見ていくとコンフリクトすることがある。

何にフォーカスするか？

かぶとりひき株取引のシステムについてフォントが小さいとバグレポートが繰り返し報告された。クライアントからの仕様は満たしていた。
報告者はトレーダだと思っていた。確認した結果、「フォントは完璧。クライアントはすべての情報が見えている。問題はトレーダーの後ろで観察している人たち。」
開発者はトレーダーの後ろに観察者がいることを知らなかった。
そのステークホルダーがいることを見逃したのは開発者の問題だったのか？

**「誰がステークホルダーなのか？」**というのがポイント。

人、プロセス、製品のどれにフォーカスするか？

テストはプロセスの一部

テスターは考え方が少し違うと思われがち。
テストはプロセスの一部といったが、製品や人にもかかわるのかもしれない。

テストの定義は、「品質やパフォーマンス、安定性をチェックする」
→これはソフトウェアには当てはまらない

ソフトウェアテストの定義は、「調査、評価、質や完全性を再確認する一連のプロセス」
→これも少し曖昧

テストとは何か？

• フィードバックを得る
• 隠れた前提条件を見つけ出す
  • 複数の視点から見ると、一つのものも全く違うように見える
  • テストは、同じ視点で一つのものを見ていく、目線を合わせる行為
• プロダクトの状態についての情報を得る
• 製品のリスクだけでなく、ビジネス・技術的なリスクを再定義することができる
• 品質を評価する（我々がそれが何かを知っている前提）

テストは品質を担保するものではない
バグが見つかったとしても、それを直すかどうかはわからない。

Agile testing quadrants

guide development ↔ critique the product
business facing ↔ technology facing

Business Facingの二つはビジネス寄りのテスト
Technology Facingの二つは技術的なテスト、ビジネス側は結果を気にするが、中身は把握できない

Critique the Productは不具合を見つけるもの
Guide Developmentは不具合が起こらないようにするもの

4象限に含まれるすべてのテストが必要

品質の属性はたくさんある

• Safety
• Security
• Performance
• Reliability
• Usability
• Privacy
• Data integrity
• Accessibility(a11y)
• Recoverability
• Localization

これらの項目は顧客にとって「担保されて当たり前」という項目もあり、どうテストに盛り込むかを考える必要がある
また、テストの倫理を考えることも必要

いつテストを始めるべきか

シフトレフト、シフトライトで表されるように、開発プロセスを直線的に考えるべきではないと思っている。
開発プロセスは無限に続くもの。
無限ループのように、色々なプロセスでいつでもテストができる状態であるのがよい

ブレストや計画の段階（Testing early）

アイデアを出したところで、そのアイデアをテストしてみる。
アイデアがよさそうであれば、計画に移行すればよい。

不具合が入らないようにするためのテスト。
どんな品質の属性があるのか、会話しながら深堀していく。
プログラマが開発に入る前にテストを渡す。

開発段階

ほとんどの人はテストというと、このテストのことを想像する。

• TDD（テスト駆動開発）
• コード解析
• "show me" （チームメンバに対してコードを説明してバグを見つける）
• 探索的テスト
• 自動テスト
• ユーザ受入テスト

上記のうち、探索的テストとユーザ受入テストが品質にかかわるもの。

デプロイ段階

迅速なフィードバックを得るために、できるだけ自動化する。
顧客のインタラクションを観察し、分析して学ぶ。
顧客のリアルな振る舞いをもとに情報を得る。

何かの測定値がなければ品質のレベルがわからない。

どう品質を測定するか？

測定は簡単ではない。

Q. カンファレンスに1から5で点数をつけるとしたら、どこにつけるか？
1につける人もいるし、5につける人もいる。そもそも1が最高なのか、5が最高なのか。
全員が同じ考え方をしない、という一貫性の問題が出てくる。

どうやって一貫性を持ったうえでコメントをもらうことができるのか？

Q. チームや組織はプロダクトの品質をどう評価するか？

• Cycle time
• Number of bugs
• Severity of bugs
• Build radiator is green
• Number of automated tests
• Rework rates
• Test coverage

私たちが意識しなければいけないこと
Goodhart's law
"When a measure becomes a target, it ceases to be a good measure"

評価軸のなかには、本当に知りたいことを教えてくれないものもある。
製品の質は、ユーザが何を求めているかによる。

正しい答えは１つではない。
品質に関する会話はチーム、お客様としたほうがいい。
たとえば、「品質の属性にはどういうものがあるか」について会話してみてもいいかもしれない。
それぞれの属性について "品質スライダー"を作ってみるのも１つの方法としてどうだろうか。
そうすると、人によってどの属性を重視しているかという考えの違いがわかる。
その違いをもとに品質について会話していける。
まずはチームメンバーから会話を始めてみて、ギャップを認識する。
そこからステークホルダー、お客様へと会話を広げていくのがよい。

まずは小さく始めてどんどん大きくしていく、それがアジャイル。

まとめ

チームは品質について最初に会話しなければいけない。
そうでないと、どういうテストをするべきか、必要とされるクオリティは何かがわからない。
クオリティは全員が責任を負う。
品質の本質は複雑。

Q&A

• テストはコミュニケーションツールで、隠された前提が明らかになることで、チームの方向性やプロダクトの理解を深めるのに役立つメリットもあるツールだと理解した。

  • そのとおり。最近ブログを書いた。"コーディングしてからテスト"ではなく"コーディング&テスト"という内容のものです。

• 品質の測定値は主観的なので定義の仕方が変わると思う。今後は客観的に品質を測定できるようになると思うか？それはどのようにできると思うか？

  • 客観的な測定値は知らない。注目すべき測定値は、「お客様から報告されるバグ」の数。欠陥という意味でのバグ。ただし、これは決定的なものではないのでトレンドを見て最終的に０にしていく必要がある。また、文脈も重要。飛行機の機体チェックなんかは多くの確認項目があり、許容度がこのレンジに入らなければならないというようなものもある。なので、文脈によって客観的な評価が可能な部分もあるが、多くはやはり主観的な評価になると考えている。

• 品質スライダーはPoCやリリース前などフェーズに応じて見直したほうが良いか？

  • そのとおりだと思う。PoCで求められているものお客様へのリリース直前での評価は異なると思う。定期的なイベントにテストの戦略をテーマとして盛り込むのが良いのではないだろうか。

• AIがテスターや品質に強みを持つスクラムチームにどんな影響があると思いますか？

  • AIは専門ではないが、私見を述べるとAIを使った場合の制約をきちんと把握していないといけない。「どんなデータをテストするのか？」といったことを考えるところにはテスターがどのように関与するのかがポイントだと思う。

• 品質にフォーカスするとスピードがついてくる、スピードにフォーカスすると品質がついてこないとの話があった。日本企業は保守性にフォーカスすることが多い。誰も使わないような高品質なフィーチャーを作っていたりもする。品質の属性は変わりうるか？という先程の質問について

  • チームとして品質というものがちゃんと理解できていれば問題ない。「市場のフィードバックを求めるためのリリース」ということであれば、それはまたテスト観点が変わってくるかもしれない。

• テストの専門家はどうやってPOと連携してユーザのFBをもらったりできるか

  • 少なくともPOとプログラマーとテスター（Three Amigos）、できればチーム全員で会話するのがいい。全員が会話しておけば誤解は早い段階で解ける。

感想

• 品質の意味を正確に把握し、チーム間で共有すべきことで、品質が高まると思いました。
• プロダクトの優先度をつけることはしても、品質の優先度を意識することがあまりなかったかなと気づくことができた。
• 品質について具体例が挙げられていて、理解しやすかった。
• プロダクト開発においてこ顧客視点の大切さが説かれるのはよく耳にしますが、テストを考える点においても同じように顧客視点が必要だと認識しました。