人類よ！これがアジャイルテスティングだ！QAテックリードが語るアジャイルQAの実践とは何か？
しげるイベント情報
まとめ
3つの力を磨くことで、アジャイルのような変化が多い開発現場でも対応できる
人
- 探索テストの重視
- テストエンジニアを精鋭化し、その能力を発揮させアジリティを上げる
開発技術
- 開発スキルのアジリティを上げる
- テストの保守性向上
- テスト自動化
- テスタビリティの向上
テスト設計力
- 少ない手間で有効なテスト
- 本質的な仕様やリスクを読み取ってピンポイントで対応
しげる実践アジャイルテスティング
- 発表者： 井芹 洋輝さま
SET/SETI の役割と責任とは？
SET = テストの業務優先度を高めた開発者
テスト自動化/CICDなど、DX(Developer Experience)をあげていく、必要性が見えてきて担当がアサインされた。
Googleがいい名前をつけてくれて、ここ10年弱の間にできてきた。
テストエンジニア→SETになった
テストエンジニアとSETの違い
小さな規模だと一致する。大規模になると監査とか入ってくるので、QAの意味が分かれてくる
しげる今のお仕事の役割とお仕事は？
- トヨタのSETのテックリードとは？
テックリード
アジャイルだったり、テスト分析だったりのフォローをしている。
自動化も担当する。システムテストの分析だったり
会社を代表した意見ではない。車のコックピットシステムの開発（ナビとか）を内製している。
コックピット部分ってことはハードも関わってくるが、ソフトの部分を担当している。
-
ハードはアジャイルではないが、どうしているか？
- ハードはアジャイルな部分ではないが、なるべく合わせている
- ハードはUI/UXが大切なので、プロトタイピングを重視している
-
規模は？
- かなり大きい
TPS（トヨタ生産方式）の部分
トヨタ生産方式を利用して、より良いものをしている。
TPSは、リーンより本質的なものを定義して、実際に使うものはリーンに近いものになっている。
基本的な知識がないと難しい部分がある。現場改善の手法の一つとしてTPSがある。
スクラムマスター？リーンが動いているのを確認するので、リーンマスターみたいな役割だと思っている。
実際に使っているのはTPSなので、TPSマスターみたいな感じだと思う。
自動車業界の一般的な話ではなく、特殊な環境かもしれない。
しげるアジャイル開発におけるQAエンジニアの役割と責任とは？
QAエンジニアの定義にはブレがあるので、プロダクトの保証を確保する人をQAと定義する。
品質を確定するために、サポートしたり補償・レビューしたりするのがQAエンジニアの役割。
アジャイルならではの3つの方向性がある。
1. ユーザー観点での妥当な継続的なフィードバック
QAエンジニア自体がプロダクトに詳しくなる
Q. フィードバックはQAエンジニアじゃないとだめ？
みんなで作っていくことが大切
QAエンジニア = ファーストユーザーなので、エンジニア/PMにはやく意見を伝えていくことが大切
2. 迅速なフィードバック
QAを高速化していく技術
- 自動化
- 探索的テスト
Q. 自動化テストは大切だが、探索的テストが大切な理由は？
ユニットテストと探索的テストも必要である。
スクリプトテストだと大変なので、探索的テストが必要になる。
スクリプトテストの負担を減らすために、探索的テストを充実させた方が将来的なことを考えると効率が良い。
Q. 探索的テストは難易度高くないですか？
テストエンジニアの精鋭化ができていないと難しい。
テクノロジー的な技術力もあるし、経験値的な技術力もある。
→プロダクトの知識・欠陥の知識も必要になる
開発者のリスクを読み取る知識も必要になる
3. チーム全体で品質保証
仕組みか作りが必要になる
- QAのテスト/自動テスト/エンジニアのテスト全てでフォローしていく
Q. プロセスが早い場合は、QAエンジニアが守るのが難しくなる？
QAがボトルネックになる話を聞くが、みんなで解決する必要がある。
しげるアジャイルテスティングとはなにか？
アジャイルテスティングは2種類ある
実践アジャイルテスト
- テストそのものがアジャイルの原則に則す
- 開発がアジャイルでなくても実践できる
ISTQB
- 継続的かつ高品質なフィードバック
- 反復的なプロダクトの作り込みへの対応
Q. ISTQBの方が良い？
テスト自信のアジャイルも大切だが、アジャイル開発を支えていくことが大切だと思っている。
Q. テストがアジャイルになるって誰がハッピーになるんだろう？
自分たちがハッピーになるだけではないのか？
実践アジャイル = 開発もアジャイルだし、QAもアジャイルな働き方をしていく
Q. スプリントレビューもしていく？
一つの手段なので、スプリントレビューに限らない話
「スプリントレビュー = 成果物・プロダクトの妥当性」を考える必要があるがどうなんだろう
スプリントレビューは、プロダクトオーナーがまとめる。プロダクトオーナーが正しくプロダクト開発が進めているか確かめるために行っている。
スプリントレビュー = POレビューの位置付けで認識している
Q. アジャイルは厳格に守るべきなのか？
アジャイルテストは手順書通りにすればいいわけではない。
マインド・チーム文化を醸成することが大切
あくまで、心掛けとか仕組みの部分でなので、手順書通りに実践するだけではできない
しげるアジャイルテスティング実現のためのプラクティスは何か？
ベストプラクティスはあるかもしれないが、それだけでは足りない
規模とそして大きいので、10万項目だったり、1サイクル1ヶ月とかかかってくる
それぞれの機能にfeatureチームがあり、 各チームにテストエンジニア を送り、横断的なテストチーム もある
各チームにテストエンジニア は、featureチーム内で、アジャイルテストをサポートする
横断的なテストチーム は、横断的な結合部分だったりをフォローする
現場の需要に応じて今の形になっている
Q. ゲートとしてのQAはない？
大規模なところがゲートの役割になっている。一度にするのは大変なので、小出しにしてテストできるようにしている。
Q. フロントローディングってシフトレフトの考え方に近い？
やっていることはフロントローディングに近い
フロントローディング：テストを最初にしていく。Wモデルに近いかも
シフトレフト：仕様立案時点からQAがフォローに入っていく
しげるQ. スクリプトテストと探索的テストの比率は？
QAチームがするのは、ほぼ100%探索的テスト
大規模なテストはスクリプトテストになる
自動車業界は求められる品質が高い。
やることはチャーター付きの探索的テストを行なっている
Q. 先行開発と量産開発はどうやっている？
両方しているので、大規模なテストを行なっている
Q. アジャイルでは仕様書がな部分もあるがどうしているか？
他の会社と比べてドキュメントが多い会社
ユーザーストーリーがしっかりしているので、ドキュメント量は多い
Q. 開発チームとQAチームはストーリーポイントを出している？
開発とQAのポイントを分けず、合算したストリーポイントして行なっている
しげるアジャイルテスティングをどうすればいいのか？
文化として醸成する必要があるので、時間がかかる。
ユーザーの声をテストに反映させるとかが必要になってくる。
開発とPOとのコミュニケーションを大切にする
テストのアジリティも上げる必要がある。テストの自動化と探索的テストが必要になってくる。
手順通りにやるではなく、方向性に向かって進めていくことが大切
しげるテストのアジリティ
次の3つが大切になる
人
- 探索テストの重視
- テストエンジニアを精鋭化し、その能力を発揮させアジリティを上げる
開発技術
- 開発スキルのアジリティを上げる
- テストの保守性向上
- テスト自動化
- テスタビリティの向上
テスト設計力
- 少ない手間で有効なテスト
- 本質的な仕様やリスクを読み取ってピンポイントで対応
Q. テスタビリティとは？
テスト容易性とかになる
- テスタビリティがなぜ重要か
アジリティを上げるために必要であり、スピードを上げるように必要
項目が少なくなり、作成 & 実行の時間が少なくなる
実現アプローチ例
- テスト障害となる要因は小さくし、分離・置換可能にする
- 必要な観測点・制御点を設ける
- 契約による設計の推進で、凝集度を適切にする
- 接合点を設けてからテスタビリティを拡張するなど
しげる質問タイム
Q. マインドセットや考え方を開発チームへ浸透させるために行った方法はありますか？
同じチーム内に、同じマインドセットを持った人がいるが、開発のfeatureチームとの繋がりについてどうするか
サーバントリーダシップみたいな、尽くす姿勢が大切で、ユーザーストーリーの上流からサポートしていくことが大切。
Q. リグレッションテストの自動化などは、どのようなことを意識されているのでしょうか？
テストしやすいように、テストの保守性を意識することが大切
変化に対応するために考えることが大切
全体のテストアーキテクチャを綺麗にしておく。全体構造がどうなっていて、どこに影響するか・どこを追加するかがわかるようにするべき
Q. チーム員のスキル向上のモチベーションはどのように維持・向上させていますか？
属人的な要素が強いので、良い人を集める前提がある。チームで良い文化を作っておいて、新しい人が入ってきたときにいい文化に引っ張られるようにする
Q. 良いQA/良いエンジニアの定義とは？
アジャイルを進めることができる妥当な開発ができる人が大切。
手順ではないので、心掛けとかが大切
Q. 原則を関係者に共有するためにやっていることを教えてください
ミッションなどを明文化して、進めていく。
ミッションは、定期的に変わる？
→最初は変わるかもしれないが、原則なのでだんだん固まっていく
Q. 手動テスト、自動テスト、探索的テストの比率は、(感覚的に)何対何くらいでしょうか？
仕事に関わることなので、あまり言えないが大半は手動になっていて、大切な部分に関しては自動テストになっている。量産化の部分ではあまりテストをしていない。
求められる品質・サイクルに依存する
Q. 探索テストはどれくらいの完成度で始めるか？
一般的なユーザーストーリーテストと同じ。基本的なシナリオを準備指定置くくらいの準備
Q. １人目のQAとしてジョインした場合、環境作りも含めどんな作業からはじめていきますか？
既存のテストのフォローになることが大切。チームのためになることが大切。
しげる現在課題として認識しているものは何か？どう解決しようとしているか？
スプリント内でテストが収まらない。
大規模なので、全体整合が取りづらい。全体整合が取れていないと無意味なテストが増えている。
コンパクトなテストはコンパクトで難しい。
→コンパクトな中で、どう保証するかが難しい。大は小を兼ねるではない。
3方向からアプローチしている
テストチームの基礎力を上げていく
テストメンバーのアジリティーをあげる
最後にまとめない
負荷・リスク対応・バグ出しを最初にする→フロントローディングが大切
テストアーキテクチャの考え方が大切
プロジェクトに対して、どうしていくか・どこをテストしていくかが大切
Q. テストアーキテクチャとは？
テスト環境のアーキテクチャ・テスト構造の全体構造の2つのことを指している
大規模になると全体感を見る必要がある
しげるこれからのテストや品質はどうなっていくのか？人類はどうあるべきなのか？
業界に連動しているので、日本の業界がどうなるかが大切。
製造業・エンタープライスでも、品質が求められている。
ポストスクラム・スクラムは古いと言われているが、原則的な部分は変わらない。
自ら精鋭になっていく必要がある。
マネジメント：手順手法ではなく人をよくする
現場：自分を磨く必要がある