RSGT2021 Day2メモ
RSGT2021初日に参加したセッションのメモ。
※記憶に残ったもの、かつ解釈を加えたりしているので、純粋な記録ではありません。
What’s Testing Got to do with Quality?
DragonFire Inc. Agile Coach Janet Gregory
What's Testing Got to do with Quality? - Regional Scrum Gathering Tokyo 2021
クオリティは皆の責任。
品質が上がれば生産性は自動的に上がる。
品質の定義
「品質」の定義は難しい。（どのお茶がほしいか、という問い）
抹茶の品質は高いかもしれないが、好みじゃない人もいる。
品質はプロダクトによって異なる。
製造ベース＜製品ベース＜ユーザーベース＜価値ベース＜超越的
金融系システムを作っていたときに「フォントが小さい」というクレームが立て続けにあった。
システムは設計を満たしていた。クレームの原因がわからずユーザを訪問して確認した。
「Traderにとっては完璧だが後ろに立つSupervisorから見えない。小さすぎる」というものだった。
品質とはなにか？製品？人？プロセス？
ソフトウェアテスト
完成度や品質を調査、評価するプロセス
What is tesing? according to Janet
- フィードバックを返す
- 隠れた前提条件を特定す
- 製品の状態に関する情報が得られる
「車が水の上／橋の上を走っている」
という父子のエピソード。
視点が違うと見えるものが違う。テストをするには同じ目線になる必要がある。
歩み寄り、共通理解が重要。
Agile Testing Quadrantsの4象限
右側は不具合を見つけるためのもの。左側は不具合を出さないためのもの。
測定してフィードバック
チーム・組織に対して
Goodhart's law
指標が目標になったとき、それはもはや指標にならない」
カバレッジ80%を目指すために細工する、テストケース数やバグ数を満たすためにテストを設計する、などは違う。
参考：
品質を定義する
プロダクトによって求める品質は異なる。
複数の指標があり、製品によって求めるレベルは違う。
開発を始める前に対話することが必要。
Q&A
- Janetのいうテストはコミュニケーションツールとしての側面を持つのか？
- 「コーディングしてからテストするのをやめろ」と言う。 テストは設計やスコープなどの上位概念を含む。コーディングは活動。
- コミュニケーションは増えると思う。
- スクラムチームにテストの専門家がいる場合、POとどう関わるべきか？∞ループの側を担うことになる。
- コミュニケーションミスを生まないために開発チームと会話する際は3人組にするとよい（PO, QA, Dev)
スクラムにおける「完成」とはなにか？
Attractor Inc CTO / Agile Coach Ryutaro YOSHIBA (Ryuzee)
プロダクトとは？
価値を運搬するもの（プロダクトマネジメントでの定義）
プロダクト＝ソフトウェアではない。サービスなど多くのものを含む。
プロダクトバックログに含まれる可能性があるもの
- ソフトウェアの顧客向けの部分
- ソフトウェアの内部向けの部分
- プロダクトに関係するソフトウェア以外のもの
- プロダクトの将来の価値を生み出すもの（検証、実験、etc)
よくあるソフトウェアの完成の定義を作っても、バックログアイテムに画一的に適用できない。
※カバレッジ、ドキュメント、クロスブラウザ、etcを完成の定義とした場合
各領域に完成の定義を用意する。
枠組みを作って埋めること以上に、「共通理解」こそが透明性を生む。重要。
共通理解がすべて。
完成の定義をいつ作るか
スプリント1開始前が望ましい。
完成の定義をどう作るか
組織の標準があるならそれに従う。プロダクトの種類によって追加したり変更する。
組織の標準がないならスクラムチームで作る。
完成の定義をどう守るのか
- 全員が完成の定義の内容を理解しなければならない。
- 誰でも見える形で文書化する。
- 完全に記述することは不可能なので、レビューなど曖昧さや解釈の余地は残ってよい。
- 自動化できるものは自動化する。
- スプリントレトロスペクティブなどをきっかけに改善していく。
アジャイル戦略論 「チーム作りの巻」
Yosuke Matsuuraさん, Yasunobu Kawaguchiさん, Ken Matsumotoさん
要約・概要
- 成果の上がるチーム = 継続的なカイゼン文化 × 信頼関係の構築 × 成功体験の積み上げ
- チーム作りの6ステップ。以下6stepに沿ってまとめ。
- 一人目の仲間を作る
- 話し合いながらアウトプットする
- ものの置き場を確保する
- 成果をアピールする
- やったことをふりかえる
- 技術的負債を解消する
話し合いながらアウトプットする
- 圧倒的な量の失敗や経験をして改善し続けることで、質に転化するスピードが早くなる
- アジャイル開発は失敗や経験に重きを置いて、質に転化するスピードを早めている
ものの置き場を確保する
- ワーキングアグリーメント。共通認識を作る。
- 作ったものは全員が見える場所に置いておく。
- 置き場所にはこだわる。チームが見ない場所に置いても意味がない
やったことをふりかえる
- ふりかえる
- うまくいったこととカイゼン点を整理できる
- 改善を繰り返す
- システムの不具合を直すわけではなく、不具合が生まれるプロセスを直す
- なるべく高頻度(1日に1回, 15分に1回)にふりかえりする
- 心理的安全性がある場でふりかえりすること
- 全員が話すことが重要
技術的負債を解消する
- 目先の利益のために長期的な生産性を犠牲にした結果、チームが持続できなくなる
- トレードオフスライダーを作る
- 市況によってトレードオフは変化する。定期的に見直しをする。
- 技術的負債は可視化する(https://www.servantworks.co.jp/2020/making-tech-debt-visible/)
- ビジネスサイドの人への説明に有効。技術的負債を金額として表してみたりすると、納得してもらいやすい。
Scrumチームに「テストは単純作業ではなく創造的な活動だ」という意識を浸透させて良品質＆低コストの製品を作るようになるまでの物語
QA Engineer BizReach Inc. Yuya Kazama
https://speakerdeck.com/nihonbuson/agile-testing-essence-20201117 speakerdeck.com
事例1：仕様のリファインメント
実例をともなった会話をもとにコーナーケースの使用などを明確化。
事例から学ぶ実例マッピングのやり方 / Example Mapping
実装前にテストの考え方を取り入れる効果
コーナーケースなどテストの要点を抑えて開発される。 余計なバグやチケット起票、修正などの工数がかからない → 質によってスピードも改善
事例2：テスト実行
テスト実行までの過程
テストプロセス（JSTQB)より
分析＞設計＞実装＞実行
よくあるテスト設計レビューでは「テスト分析」としてテスト項目にフォーカスしがち。
「テスト設計（どうテストするか）」も重要。
「テストケースをへらす設計」の重要性。
※事例として、ケースを減らした上で不具合数も増えない
テスト活動の納得感を持ってテストケースを激減させた話 #D3QA / Improving convinced testing activities
品質の作り込み
テストを減らせるかどうか、は設計レベルの話。 その時点でテストケースを考えるとともにことで開発時に余計なロジックを書かなくて済む。
テストマニフェスト
