天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

ATN#17 「アジャイルテストの4象限とテストピラミッドを意識して効果的なテストを見つけていく夜」に参加してきた

wingarc1st-spqi.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

アジャイル開発が主流となる中、テスト活動にもアジャイルの波が押し寄せています。 しかし「アジャイルなテスト」とはなんたるかを理解し、それを実践するのは容易ではありません。

今回のAgile Testing Nightは前回大盛況だった「ATN#15 探索的テスト&ペアテストでアジャイルテストを味わってみる夜」を経て、さらに一歩踏み込んだアジャイルテストのプラクティスに迫っていきます。 ゲストは前回からに引き続きグレゴリさんとJBさんが登場! 2人の豊富な経験と実績に裏打ちされたアジャイルテストの世界を案内していただきます。 前回同様ミニマムなワークもご用意いただいていますのでお楽しみに(見学も大歓迎)。

本イベントでの体験は、進化し続ける開発の現場に立ち向かう勇気を私達に与えてくれることでしょう。 今宵、進化の夜が幕を開けます。アジャイルテストの世界へ一緒に飛び込みましょう!

www.yamaneco.co.jp

会の様子

マインドセット

最初にアジャイルテストに取り組むにあたって必要なマインドセットの転換について話がありました。

グレゴリーさんは、QAメンバーにまつわる採用面接をしたそうですが、その際にアジャイルテストに馴染んでいないようなQAは「我慢強さ」「システマティックに考える能力」を挙げたそうです。
しかし、このようなマインドセットは自動化されたテストに取って代わられるリスクもあるため、転換の必要があるんじゃないか?という話をされていました。

転換の具体的な例としては、

  • 考え方(唯一の正解がある→状況に応じて多くの選択肢を持つ)
  • 責任(テスターがバグの発見に関して責任を担う→チーム全体がバグの発見に関して責任を担う)
  • スキル(ミスを許さずシステマティックに細部に拘る→コミュニケーションを取りながらドメイン知識や技術的な理解をスキルとする)

が挙げられていました。

アジャイルテストとは

アジャイルテストとは、一言で言えばアジャイル開発の支援を可能にするテストだ、という話がありました。

その上で、Testing manifestoの説明がありました。

  • 最後にテストするよりもずっとテストし続ける(テストはドキュメント作成などと並行して実施)
  • バグの発見よりもバグの防止(当然だが、バグを発見する前よりもバグが作られるのを防止する。BDDや実例による仕様など、バグ発見に使えるプラクティスもある)
  • 機能性をチェックするよりもチームが理解している価値をテストする(コンピューターは単純なテストに飽きないので、チェックは機械にやらせる)
  • システムを破壊するよりも最高のシステムを構築する(WFで最後にもぐら叩きをやらないようにする)
  • テスターの責任よりも品質に対するチームの責任(QAが品質の全責任を担わない)

テスト自動化

早く高品質なプロダクトを取り組むためには、すべきテストは非常に多いため、アジャイル開発においてテストをすべて手動でやるのは現実的ではないという話がありました。
そこでテスト自動化が必要になってくるわけですが、テスト自動化をする際にはテストの目的をもっと知ることが重要だということで、まずは自分たちのプロダクトに対して興味を持つのが重要だということです。

また、テスト自動化をするためにはインフラ基盤や新しいプロセスに慣れる時間、完成の定義などが必要になってくるため、場合によっては組織全体に変化を起こしていくような必要があるというお話も出ていました。

テストピラミッドのレベルが上下することでテストの特性はどう変わるか?

テストピラミッドの上の部分に行くにつれて、テストの特性はどう変わるのか?という質問があり、じゅんぺーさんや荒川さんや参加者がワークをしてくれました。以下のような意見が出ていました。

  • 「そのシステムを誰が使うか?」みたいなユーザーの解像度が上がっていく
  • バグ検出時の修正コストが上がっていく
  • 実装のしやすさが上がっていく
  • メンテナンスコストが上がっていく
  • フレイキーなテスト数が上がっていく
  • 実行時間が上がっていく
  • 手戻りのコストが上がっていく
  • 実装のしやすさが上がっていく
  • (バグが見つかった時の)プロジェクト担当者の罪悪感

アジャイルテストの4象限

「ビジネス - 技術」と「チームを支援 - プロダクトを批評」の軸(Q1, Q2, Q3, Q4)にしたがって、様々なテストがマッピングされていきました。

Q1(基本的に自動化するもの)...単体テストコンポーネントテスト

Q2(自動化するものも手動で実施するものもある)...実例テスト、シミュレーションテスト、パフォーマンステスト

Q3(手動で実施)...アルファベータテスト、パフォーマンステスト、ストーリーテスト、ユーザビリティテスト、UAT、プロトタイプ、探索的テスト

Q4(ツール)...コンポーネントテスト、負荷テスト、機能テスト、セキュリティテスト

テストプランニング

テストプランニングを架空のシステムで実践してみるワークがありました。Gukki-さんと工藤さんが参加してくれました。

ワークの詳細(どういうワークだったのか?どんな回答が出たのか?)は省略しますが、ワークが終わった後に以下のような話が出ていました。

  • 「〜という意味で良いですか?」「〜という言葉を今後使っていきましょう」といったコミュニケーションが取れていた
  • 会話のキャッチボールが上手にできて認識のすり合わせがうまくいった
  • 受け入れ条件とテストプランニングのシートをいったりきたりしながら会話したので、これを繰り返していければ一定レベルの品質が担保できるようなテストになると思った

告知

www.yamaneco.co.jp

www.scrumfestniigata.org

会全体を通した感想

どのようにアジャイルテストを説明するのか聞けて面白かったですし、他の方のワークショップの様子を見ることができたのも非常によかったです。

特に、QAエンジニアではない工藤さんとGukkiさんがコミュニケーションを有効に取りながらテストプランニングをしている様子が印象的でした。