はじめに
このページは、RSGT2021で参加したセッションのレポートを書いたものです
https://2021.scrumgatheringtokyo.org/
このセッションの概要
【タイトル】
キーノートセッション：What’s Testing Got to do with Quality?
Janet Gregory
Day2 10:00～11:30
【Confgineのセッションページ】
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14730/whats-testing-got-to-do-with-quality
感想
めっちゃ良い！学びの深い講演でした！！！
キーワードをピックアップ
- 品質についてチームで会話を始めよう
- プロダクト品質は定性的。ユーザによって品質に測定指標や優先順位が変わる
- いつ、何の品質を評価するのか？それは誰に向けたものなのか？を間違えないように！
- Quality Slider を作ろう！
- 品質は全員の責任
セッションメモ
イントロ
自己紹介
経歴
プログラマー → ウォーターフォール開発のQA担当 → アジャイルに転向 → アジャイルテストに関して講演活動＆執筆
引用ワード
エドワードデミング氏（14の経営原則
Quality is everyone's responsibility
グレゴリー氏
If you focus on quality, the speed will come.
If you focus on speed, quality gets lost.
Today's Message
To show how we develop our products can influence how we view quality
Or maybe, how we view quality can influence how we develop our products
We can change the conversation!!!!
Test/Quality 関係はあるが同じものではない
1. Quality
どれが一番Qualityが高い？
緑茶／抹茶／紅茶
→人によって分かれる
お気に入りをどうやって選んだ？
味？好み？
お茶の品質を考えた？茶葉の産地とか、日照時間とか、乾燥方法とか、、、
緑茶にも、等級がある。例えば、抹茶は一番等級が高い。
次に、価格を付け加えてみる
緑茶150円／抹茶400円／紅茶250円
金額、一緒に受けるサービス、飲む場所、
どんなことが言われている？
Jerry Weinberg氏、Modern Testing 5th principle、リーンスタートアップ
→共通していること：一貫性、お客様に評価してもらう
ここで、「お客様」って？
視点を変えてみよう
David A. Garvin 1980年頃に言われたこと
をベースに、Janet氏が作成
5 approaches to quality
https://janetgregory.ca/part-3-testing-vs-quality-management/
お茶の例でいうと
最初：ユーザベース（好み）
次：価格が入って、価値ベースの視点が入った
会社視点：どれだけの利益を出さねばならない
例えば、スタバ
駅の売店よりも高い価格で売っている
どれだけの顧客体験を生み出すことができるのか？
What is your focus?
プロダクトを作るときに一番重要なのは？
株トレーディングシステムに携わっていたとき
バグレポートがあがってきた。「文字が小さすぎる」
最初、トレーダーから上がってきた問題だと思っていた
サポートが、レポート本人にもヒアリングに行った
↓
フォントは完璧
これでトレーディングできる
一方で、問題は、スーパーバイザーにとっては、文字が小さい！
↓
これは私たちの問題なのか？
結果、スーパーバイザーは横に座ればいいよね、ということになった。
ここで大切なことはなにか？
何にフォーカスするか！
- People
- Process
- Product
2.Test
テストはプロセスの一部
プロダクトのリスクを理解すること
多くの人は、テスターはマインドが違う、という。これに対しては懐疑的。
テスターは常に質問している。批判的な見方をしている。それは事実。
Testingの定義
Testting/Software testing
What is testing?
・フィードバックを提供する
バグを見つけるのもそのひとつ
・隠れた前提条件を特定していく
旅行での経験
「水の上を車が走ってるよ」
「いや、そんなことない！」
「お父さん、目線を子供に合わせてみてよ！」
「あぁ、確かに車が水の上を走っているね」
「お父さんの目線まで抱っこしてあげて。なるほど、橋の上を車が走っているんだね」
→目線を合わせよう！！
・Give information about the state of the product
セーリングしている
新しくインストールしたものをテストしたい
動画を見たりして探そうとした
彼は商品の状態を知りたかった
周りの人は「とにかく使ってみればいいんだよ」と言っていたが、そうはしなかった
・Helps identify and mitigate product / business / technical rist
このパーツのリスク。海上でトラブルが起こると困るもの。
だとするととにかく使ってみよう、とならないこともある
・Aseseses quality（assuming we know what that means）
NOTE：
Testing does NOT assure/ensure quality
as indicated by the previou definition
バグを見つけたとして、そのバグがFixされる保証はない
Agile testing quadrants（4象限）
上２つは、ビジネス側
ビジネス側の人
→結果を気にする
一方で、技術側のテストについては理解が難しいだろう
下２つは、技術側
→ユニットテスト、パフォーマンス
右側
Critique the product
左側
Guide Development
右下のテストは重要！
Quality Attributes
品質の属性がいくつもある。当たり前と思われている品質は必ずテストいなければならない
医療機器のようなものは、非常に高い
データ。スマホやクレジットカードを持ち歩いているか？
お金を送金するとき、うまく機能すると信頼しているよね？
安全は当たり前と思っている。一方で、テストの品質チェックで見落とされがち
Testを通して、Qualityをどうやってサポートしていくか
リリース直前にTestするのっていいの？
いつTestする？
Shift Left？ Shift Light？
→あんまり好きじゃない！
開発は線形のものじゃない。ループするもの
どこでもテストする！DevOpsの無限ループ構造
ループについてみていく
アイデアの着想
ブレインストーミング＞発見＞アイデアテスト
いいアイデだったら、プランニングに入る
いまいちだったら止める
この段階でのTest。
・隠れた前提をあぶりだす
・様々な視点で質問をする
・プログラミングを始めるまえのテスト！
Build・Integrate
これらは、テストとして認識されやすいですね
・TDD
・コード分析
・机上テスト
◎探索的テスト
・テスト自動化
◎ユーザ受け入れテスト
この中で、◎の２つが、プロダクトの品質に関わるもの
それ以外のテストは、どのように作るか、に関わるもの
デプロイメント・フィードバックフェーズ
デプロイメントは自動化する！
お客様がどのように使っているか、フィードバックを得る。学ぶ。
そして左上側、アイデア着想のフェーズにフィードバックする
フィードバックループ
品質評価するようなフィードバックループを回したい
そのためには、何かの測定値、メジャー可能な何かが必要
測定
品質の良さ
これは分かるよね
例えば、このRSGTを１～５で評価すると？
１～５：５が最高ってどうやって認識した？
測定の一貫性
「みなさんがチーム・組織をどのように評価しますか？測定してみてください」
→サイクルタイム？
バグ数？
手戻り率？
※これらは、プロダクトの品質を評価できない。
プロセス品質に使える軸だった
プロセスの品質評価は、もっともっと簡単だった
Goodhart'sの法則
"When a measure becomes a target, it ceases to be a good measure"
評価基準をテストのカバレッジ
プログラマーの多くが、ずるをしだした
単体テストをやるとき、やるべきより質の低いUTをした。Assert＝trueにした。なんとまぁ。。。
プロダクトの品質をどうやって測る？
・Effectiveness
・Efficiency
・Comfort
・Trust
・Flexibility
・Context completeness
価値ベースであるだけでなく、特定のユーザベースにもなっている
ターゲットとするお客様によって、評価が変わる
例えば…
電力会社。競争相手が少ない。
一方で、競争相手がたくさんいるなら、
提案：Quality スライダー
https://janetgregory.ca/part-4-testing-vs-quality-management/
品質に関する会話をチーム内で行った方が良い
品質の属性にどんなものがあるかを出してみよう。
（お客様、ステークホルダーなどなど）
Qualiry スライダーを作る
品質属性と、１～１０の評価
これをチームメンバ各自で描いてみる
認識の一致、差分を見る＆会話する
何が把握できていないのか、も確認することができる
まずはチームレベルで。お互い信頼しているはずあから。
同じことを、ステークホルダーやお客様などに広げていこう
組織の中の上の人たちに広げていくのも良い
Qualityの会話を組織の中に浸透させよう！
まとめ
Qualityに関する会話を始めよう
・コーディングする前に！
・CXを考えよう
・プロダクトが機能することではなく、お客様のニーズを満たすことが重要
・じゃないと、どういうテストをするのか、どういうリスクを見つけるのか、分からない
Qualityは全員の仕事
・チームとしてQualityを埋め込む
・何を測定しているのか。プロダクト品質？プロセス品質？
・プロセス品質は大切だけど、プロダクトの品質につながるわけではない！
自信をもってリリースしよう
神頼み？
夜も眠れない？
そんな状態でリリースするもので良いの？？
Qualityについて認識しよう
Qualityと聞いたときに何を思うのか、自己理解をしよう！
QAコーナー
Testの効果について
・会話を始める
・チームみんなの理解を揃える
・認識のズレを発見する
などのツールとして有効である！
Qualityは主観的だと言われているが、今後は客観的に測定できるようになるのか？
客観的な測定値はしらないけど…
ひとつあるのは、お客様がレポートする欠陥としてのバグ
文脈が大事。あるプロダクトで認証プロセスが必要。例えば飛行機のソフトウェアは満たさねばならない基準がある。この辺は客観的なものもある。
でも、こういう文脈が無ければ、主観的なものになっていく。
品質に関する会話
品質の指標は変わっていく
なので、繰り返し会話していく必要がある
ふりかえりなどが重要！
AIの発展がどのような影響を持つ？
専門分野ではないが…
テスターとしてAIを使った場合の制約をわかっている必要がある。
例えば、多様性が考慮に入れられているのか？そのデータがあるのか？
などは考えてみてもいいおかなぁ
↓
探索的テストはまだまだ人間がやらねばならないと思うが、チェックはAIで代替できるかも。
↓
これも文脈に依るんだろうと思う
質にフォーカスしたらスピードはついてくるが、逆はそうではない。日本企業は、保守性にフォーカスしている。誰も使わないような高品質なものを作っている
品質の属性は大きく変わる
例えば、誰かが買ってくれるか、という視点でテストをしているなら、適正な評価項目がある
↓
経営層にレポートするときに、クオリティスライダーの項目が時間によって変わる
ラフに作って捨てるときに躊躇しないように
PoCは使い捨て。学んだら捨てる！そういうものだと理解する必要がある！
無限ループの左上はPOの領域だと思う。チームメンバにテストの専門家がいる場合、どうやってPOと連携したり、ユーザの反応を知っていける？
少なくともプログラマの中から１人・テスター１名・POの３名で会話をする
望ましいのはチーム全員で！
２人だと、説明するこから誤解が生まれるかもしれない
全員が加わっていれば、誤解は早く見つかる可能性がある！
～おわり～