Agile Testing Condensed… Yuya Kazama 著 et al. [PDF/iPad/Kindle]
友人の QA 担当者と話の流れから読書会をすることになったので、そのログ。QA も分野としては好きなのだけど、仕事が無い。
第２章：チーム全体のアプローチとアジャイルテストのマインドセット
チームとは
「チーム全体」とは、通常、デリバリーチーム（何を構築するかを理解し、それを構築し、最終的なプロダクトを顧客に届けるための責任を負う人々）を意味します
DevOps の動きでは「運用」もデリバリーの一環になるという。 DevOps の本は次にする予定だが、「（プロダクトやその価値を）理解し構築し届けて運用する」までが一つのチームでというのは、小さい組織なら当たり前だけど、大きくなると難しいというのも分かる。
Janet はデリバリーチームの外の人々を拡大家族と呼んでいます
この一文に関しては、読書会の中で「いい意味なのか悪い意味なのか？」と話にあがったが、英語版でも単に extended family となっており、まあ言葉通りの意味なのかなということになった。
品質に注目する
「チーム全体」でのアプローチとは、チームメンバー全員がプロダクトの品質に責任を負うことを意味します
テスターからすれば、当然こうあって欲しいですがなかなかそうはならないよね的な。
ここでは、「プロダクトの品質」に加えて「プロセスの品質」についても触れられていて、これらの焦点を当てることで、チームはより早く作業できるようになり、フィードバックループによって顧客に価値ある機能をテストすることに集中できるとあります。
「品質」を目標にする、つまりは「価値ある完成の定義」にテストも含めるというのは、確かにこれを同意しないとテストはおざなりになってしまうよなと感じました。
チームが欠陥に対処する方法
コーディングの完了後に欠陥を見つけるのではなく、欠陥の防止に焦点を当てる
品質の構築や、品質特性について考えることが述べられていますが、これをプロセスの中でしっかりやれれば理想的だなと思います。私も開発チームとテスト計画を作るときに、品質特性の項目を含めていましたが、たとえそれが開発の終盤であったとしても、そこで気付けるだけでデリバリー後に気付くよりは何倍もいいので役立ったと思います。
ここでは、「欠陥許容度ゼロ」についても触れられています。
読書会の中で、私が以前いたチームではここにあるように欠陥が発見されたら、まずはそれを再現するテストを書き、そこからそれをパスするコードを書くことを徹底していたことを話題にしましたが、後にも先にもそれを徹底できたチームはそこだけなので、稀有なチームだったなと思うと同時に、そのチームはそれに対して完全に同意できていたのが大きかったなと思います。
複数の視点
チームメンバーのスキルセットからなる観点を使おうということですね。
「ジェネラライズドスペシャリスト」という言葉がここで出てきますが、読書会の中で、友人が QA のカンファレンス内で、「品質に焦点を当てたチームのためには、結局フルスタックエンジニアみたいな人を揃えたチームを作らないと、実現できないんじゃないか」みたいな話題が出たと話してくれました。
私は「フルスタックエンジニア」という言葉があまり好きではないですし、定義もよく分かりませんが、まあ「なんでもできる」のだとして、そこに「テスト」も含まれるのであれば、確かにそういう人ばかりであれば理想的だろうと思います。
一方で、ここではチームメンバーのスキルセットの中からという話なので、ジェネラライズドスペシャリストであり、かつ個人特有の役割に応じたスキルセットもあるぐらいの話かなと思いました。
第３章：アジャイルにおけるテスト計画
７つあるアジャイルテストの重要な成功要因の一つは「広い視野を持つ」である
チーム
「少人数で同じ場所にいるチーム」と「大規模でグローバルに分散したチーム」では課題が異なることがまず述べられていました。
「大規模」の定義はさまざまだと思いますが、ここでは一つのプロダクトで「フィーチャーのサイロ」になることがあることが挙げられています。
そういう意味では、開発チームが 10 人を超えたあたりから、縦割りの機能別チームみたいのを作ったのは割と記憶にあるなと思います。
状況がどうあれ、デリバリーチームはすべてのテスト活動の計画と完了に責任を負わなければなりません
統合の問題や、人員の問題や、依存する他チームとの調整などもコーディングを始める前に取り掛かりたいとあります。これができたら理想だなと思います。
実際、依存する他チームとの調整とか難しいですよね、、設計のすり合わせもしないといけないけど、そうなると多少作り始めたりしたくなるし、結局他チームの人員リソースとの兼ね合いにもなってくる。
クロスファンクショナルチーム
読書会の中で「クロスファンクショナルチーム」の定義っていくつかあるよね、的な話になりました。
パッと検索しても文脈次第という感じです。
この節でのクロスファンクショナルチームは、一つのプロダクトに対して作業するいくつかのチームに対して使っているのでしょうか。
プロダクト
テストの主な目的の一つは、ユーザーとビジネスに対するリスクを特定して軽減することです。明らかに、このリスクはテスト計画のやり方に影響を与えます。
ビジネスドメインの内容から、デリバリーの方法にわたって、リスクの範囲は様々だと思います。つい、リスク分析となるとフィーチャーに焦点を当てがちですが、視野を広げる必要がありそう。
詳細レベルに応じた計画
リリースサイクルの中でチームがその「全体像」を理解しておくことが重要だと述べられています。
ストーリーに集中する開発者と、全体像を見ておくテスター、確かにこれはそうなっているような気がします。
リリース/フィーチャーレベル
ここでは、単一プロダクトに対して複数のチームが作業している場合に、チーム間の依存関係の解決や、全体のテストカバレッジを示すにはどうするかが書かれています。
テストマインドマップ・テストマトリクスが紹介されています。
アジャイルテストでの計画・管理のツール：Test MatrixとTest Mindmap - 千里霧中
以下は上記記事からの引用です。
テストマインドマップ、テストマトリクスいずれも、マネジメントとチームのコラボレーションを支えるためのモデルとして活用します。具体的には、話し合いながら、チームでアイデアを出し、チームでアクティビティを共有し、チームで進行状態を共有するための手段として、テストマインドマップ、テストマトリクスを活用しています。
テストマインドマップはよく使いますが、個人的にはテストケースの洗い出しのような形で使うことがほとんどで、このように「進行状態の共有」にまで利用することは考えたことがありませんでした。
一方で、確かに複数チームでの作業になるとこのように粒度は粗いものの、大きな視点で可視化できるツールは有用だなと思いました。
ヒント
この節のヒントに、
開発者が新しいストーリーに着手している間に、テスターや運用スタッフにデプロイに必要な準備作業をさせるような誤ちをおかさないでください。
とありますが、開発リソースを時間工数で見るような経営判断があると、「手が空いている」のような表現で、開発が終わったばかりの開発者をすぐに次のストーリーに着手させるようなことがあります。というかありました。結局テストが手戻りがあったりで、あんまりいい事ないので、ホントやらない方がいいと思います。。
ストーリーレベル
高レベルの受け入れテストから始めましょう
私はこれを実践できたことはありませんが、具体例を取得したら、それをテストにするというのはいい方法ですよね。
読書会の中で「チームがテストを計画し、各ストーリーの実装について話し合うと、テストの詳細が明らかになる」について話したのですが、テスト計画までいかなくても、ストーリーの計画ミーティングの中で、実装までざっくり話し合うチームにいた時はすごくやりやすかったのを思い出しました。
チームによっては、チームメンバーに対して「お手並み拝見」的に、ただストーリーだけ渡してやらせるチームがありますが、結局 PR で手戻りになったり、「事前に設計の相談ができるコミュニケーション能力が必要」とか訳のわからないことを言われることになるのを見たことがあります。最初から全員で実装の大体の合意しておけよ、とよく思います。
まあ、今はモブプログラミングとかで、色々カバーできるのだとは思いますが。
タスクレベル
TDD!
回帰テストの計画
回帰テストとは、システムが昨日やったことを確認することです。
なんかいいですね。友人の QA は、これが今の所一番メインの仕事らしいですが、なかなかストーリーでの機能の変更の中に、既存の回帰テストの修正までがセットになることは無いそうです。
それでも、落ちたら直してくれるらしいので、十分なのではとも思いました。
ここでは「リリースフィーチャートグル」についても触れられています。速度の速い開発チームのテストをしていると、リスク次第では先にデプロイさせて、そこからテストもありますが、リリースフィーチャートグルを使えば、顧客にデリバリーはできていないものの、より安全にテストできて良いなと思います。
