はじめに
QAエンジニアにとってアジャイルとはどのようなものなのか、アジャイルの現場におけるQAエンジニアの活動とはどのようなものになるのか、Agile TPIのWhitepaperから読み解いてみたいとおもいます。
Agile TPIとは
Agile TPI は Sogeti社が提供するテスト改善フレームワーク（TPI NEXT®）の Agile版です。こちらのリンク先から必要なテンプレートを入手することが出来ます。
https://www.tmap.net/building-blocks/agile-test-process-improvement-agile-tpi
引用について
以下の引用文は「Whitepaper - Agile TPI Japanese v1.0.pdf」より抜粋しています。
「概要 - Agile、スクラム、TPI」 より
アジャイル方法論は、テスト駆動開発や探索的テストといったテストの見地から、多くのすばらしい実践例を前面に押し出してきた。同時にプラクティスは、テストの全体的なアプローチやプロセスがアジャイルプロジェクトにおいてはまだまだ満足いくものとはいえないことを示している。
テストアプローチやプロセスがいつでも完全ではないことは現場のQAに携わる人であれば誰もが実感することかと思います。一方で、自分の考えによって様々なプラクティスを試すことができるのはこの仕事の醍醐味でもあります。そのような視点において、アジャイルの現場はより自身の能力を発揮しチームに貢献する姿勢が求められるように感じられました。
「概要 - 開発者かテスト担当者か」 より
我々は各チームメンバーが正しいやり方でテスト活動を行う能力があるという状況を目指している。つまり、テスト担当者を名乗るならば、それはテスト活動をするチームメンバーを意味する。スクラムチームにおけるテスト作業はチームの活動である。
Agile TPIが想定するアジャイルの手法はスクラムですが、基本的な役割についてはどのような手法を取っていようとも大差はないはずです。スクラムにおけるメンバーは開発者以外の特別な役割を持たないとされているものの、ことQAにおいてはテストのプロフェッショナルとしてその能力を発揮することが望ましいことには変わりないはずです。テスト担当者はQAという役割を持たないが、スキルと技量をもってチームに貢献する存在であるはずです。
「1.イントロダクション - 1.1 改善の必要性？」 より
テスト活動は各ソフトウェア開発プロジェクトの中で重要な役割を果たすが、いわゆるウォーターフォール開発環境であるか、よりアジャイルでイテレーティブな方法が採られる環境であるかを問わない。ソフトウェアプログラム、システム、または完全なエンドツーエンドの IT ソリューションであっても、組織には欠陥や不備のリスクがある。それがテストをする主な理由の一つである。テスト活動のもう一つの重要な原動力は、IT プロダクトにおいて、ユーザーとビジネスの観点から確信と信用を得ることである。ゆえに、「テスト」はプロダクトとソリューションの品質への深い洞察を生み出す必要があるのである。
アジャイルだからといって特別なテスト活動をしなければならないわけでは無いということは理解できました。一方で、「品質への深い洞察力」については、新たに強化していかなくてはならない事柄のように感じました。仕様書が無いと期待値がわからないので検証項目がつくれない等といったレベルではアジャイルの現場で私達は生き残れないかもしれないとも感じました。チームメンバーはすべて開発者であり、QAエンジニアもその例外ではないのだと思います。
「１．イントロダクション - 1.2 区切りはあるが分離しないテスト活動」 より
この職責はテスト担当者（またはむしろテスト活動を行う開発者）に同僚の開発者たちをコーチするユニークな機会を与えるだろう。テスト担当者の経験から、自身の活動のみならず、チーム全体の活動を改善することができる。このため、アジャイル環境におけるテスト活動を区別したのである。それは、テスト活動を切り離したりするのではなく、他の開発活動と可能な限り同程度の強さを持たせたいからである。
テスト活動の重要性を示すような文書だと思いました。アジャイルマニフェスト風に言うならば、「QAよりもテストを」といったところでしょうか。QAエンジニアもアジャイルの現場においては開発者の一員としてテスト担当者の活動を行うが、同時に、他の開発者もテスト担当者として活動を行うということだと思います。QAエンジニアはテストスキルを他のテスト担当者に浸透させ、チームの開発者は誰もが同等のテスト担当者スキルを有する状態を作り出す必要があると考えられます。
「3.改善のための戦略 - 3.3 アジャイルとウォーターフォールのハイブリッド」 より
ウォーターフォールとアジャイルの両者が混在している状況ではウォーターフォールのための TPI NEXT®モデルとアジャイルのためのAgile TPI モデルを使用することを推奨している。両モデルのアセスメント結果を比較することで、何が必要な改善として求められているかという十分な判断材料を得ることができる。
今、私達の組織はまさにこのような状況にあると言えそうです。大きな管理視点ではウォータフォールのように扱われる一方で、現場レベルの活動は各種ツールの導入によりアジャイルに近い動きを取っていることが多いです。とはいえ、スクラムを完全に導入して運用しているチームは私の知る限り見たことがありません。過去に私が今の組織に参画した時に所属したチームはスクラムマスターを有し、まさにそれを運用していたものの、その現場は個々の力量が必要とされる難しい環境でした。結果として、今のような作り方が組織の中で一般的に定着（というか生き残っている）したということなのかもしれません。組織によってアジャイルのあり方はそれぞれにあっていいし、それに適合したプラクティス（実践）を常に模索し続けていくのだと思います。
「4.テストの潜在能力の改善 - 4.1.3 ソフトスキル - リスクベーステスト」 より
ウォーターフォールよりもアジャイル開発で求められる原則は「いいものはそこそこいいだけ」ということである。このことは、要件、あるいは要望としてのスコープや機能に達しないリスク、欠陥のリスクがあるだろうということである。テスト担当者として、喜んでチャンスをとり、リスクをとるべきであるが、よりよいのは、リスク駆動で考え行動することである。
課題があってもリリースしなくてはならないという局面において、リスクベースの考え方は非常に重要です。リスクの高いフィーチャに対してより多くのテストリソースを割り当てることで当該リスクを軽減する。テスト活動とはリスク軽減活動そのものであるという考え方が必要になってくるでしょう。ここで重要なのは、QAという視点で何ができるかということを考えることです。エビデンスを残さないテストにおいては品質リスクを可視化することが困難です。例えば、そこにかけた時間で表現するとかでしょうか。こうした問題は管理ツール等のシステム化によって解決していくことが望ましいと考えます。QAエンジニアはリスクベーステスティングと品質リスク分析のスキルを身につける必要があると思います。
「4.テストの潜在能力の改善 - 4.1.3 ソフトスキル - チームメイトへの信頼と尊敬」 より
かつてはテスト担当者として批判的になり他の人が起こしたミスを躍起に探そうとしていたかもしれない。それはよいことであり、それがテスト担当者として求められていたことであった。しかし、それをするにあたってそのミスをした人、アプリケーション内に欠陥を起こした人に対し常に敬意を払おう。そしてそういった人がこれらのミスから学び、成果物を改善できると信用しよう。さらに、仕事がうまくいった場合にはほめよう。そうすれば、よい品質を提供するための手助けに対して、あなたが尊敬されるようになる。
別に他の人のミスを探そうとしていたわけではないが、開発者から見ればそう捉えられる可能性があるでしょう。ソフトウェアの不具合を見つけるという行為はその不具合自体を見つけることに価値があるわけですが、その原因を分析していく過程において人のミスに行き着き、そのミスをした個人に行き着くことは否定できません。だからこそ、テスト担当者はチームメンバーへの信頼と尊敬をもって日々の業務にあたるのです。同じ品質の良いソフトウェアをつくるという共通の目標をもって事にあたるのです。アジャイルの現場においてはよりチームが一体化する中でそういったコミュニケーションは取りやすくなりそうです。私達もより一層このようなマインドに軸足を移す必要があると考えます。
「4.テストの潜在能力の改善 - 4.1.4 コーチとしてのテスト担当者」 より
テスト担当者は他の専門分野に対してのコーチとしてふるまうことができる。アプリケーションライフサイクルの異なる局面において、テストエンジニア、テストマネージャ、テストチームのリードなどの役割からテスト担当者に得られる知識は、アジャイルチームと外部のテストチームにメリットをもたらしうる。
チームメンバーの誰もがテスト担当者であるアジャイルの現場において、QAエンジニアはテストスキルを有するテスト担当者として他のテスト担当者にテスト活動をコーチする役割があるとも言えます。そうであるならば、私達はテストのスキルを他のメンバーに伝えるスキルも必要とされるということになるでしょう。これはアジャイルの現場においてこれまでにはなかった新しい役割のように思えました。
おわりに
ここまで読んでいただき、ありがとうございました。私のひとりごと記事になってしまいましたが、内容に共感いただけたなら嬉しいです。