ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

「アジャイルテストの4象限」に対するアンチテーゼ・「The Agile Rapid Testing Ecosystem」

「アジャイルテストの4象限」についてのやりとりをTwitterでみていて、James Bach、Michael Boltonの両氏が何年か前に公開していた『The New Agile Testing Quadrants』という資料を読み直してみました。

www.slideshare.net

今Twitterで話題になっているのは全然違う文脈ですが、この記事では彼らの批判と提案について紹介します。

作者について

JamesとMichaelのお二人は、『Exploratory Testing 3.0』(探索的テスト3.0)という記事*1を書かれた方でもあります。
この記事では、「探索的テストと明文化されたテストがあるという区分け自体がおかしくて、テストというのは本質的に『探索的』なんだ」という主張をされています。

www.satisfice.com

また、Jamesが所属している「Context Driven Testing」というコミュニティ(?)では、ソフトウェアテストについての国際規格であるISO/IEC/IEEE 29119に対する抵抗運動をしていました*2。彼らの考えるテストと、「プロセスやドキュメントの規格化」はまったく相容れないということだと思います。

context-driven-testing.com

このように、このお二人は、テストやテストエンジニアの価値を正しく伝えようとする意志を感じさせる一方で、かなり先鋭的な立場を取る方々だと思います*3

『アジャイルテストの4象限』に対する批判

Brian Marick氏によるオリジナルの4象限と、それを改良したJanet Gregory、Lisa Crispin両氏の4象限(『実践アジャイルテスト』を通じてより知られている方)について、おおよそ以下のような批判をしています。

Agile Testing Quadrant (https://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/)

  • 「批判(Critique)はプログラミングの支援(supporting)にはならない」ことを暗黙の前提にしている。
  • ビジネス(Business)と技術(Technology)を対置することで、両者に不要な緊張関係を持ち込んでいる。
  • チェック(これは完全に自動化できる)とテスト(これは完全には自動化できない)を混同している。テストはプログラミングと同じく、「ライブの思考プロセス」*4なのだ。
  • 「ツールを使うか使わないか」という意味のない区分をしている。テストにおいて、ツールは本質ではない。良いテスターであればどこででもツールを使う。
  • それぞれ技法を、一つの象限に固定している。どの技法であれ、どの象限とも関係がある。

うなずける部分もありますが、やや言いがかりのように感じるところもあります。

彼らの考えるフレームワーク

では彼ら自身は、どのようなフレームワークを提案しているのでしょうか。
この資料では、「4象限」への批判の後、彼らの考える軸や、アジャイル開発における流れなどいくつかのモデルが合成されていって、最終的に「The Agile Rapid Testing Ecosystem」というフレームワークを提案しています。

最終ページにそのv1.1があるのですが、これより新しいと思われる以下の絵が、ブログで公開されています。

The Agile Rapid Testing Ecosystem (https://developsense.com/rst-approach)

『アジャイルテストの4象限』の改良というよりは、まったく別モノですね。

構造としては、こんな感じです。

  1. 真ん中の部分には、アジャイル開発のコアとなる「価値観」が置かれている。
  2. グレーのラインは、「開発の活動」が時計回りサイクルで表現されている。
  3. 各頂点に、この活動を成功させるための「パターン」が置かれている。
  4. 各象限に、「価値観」と「パターン」に対応する「テストの活動」が書かれている。

「開発の活動」と「パターン」から見ていきましょう。

  • 上の活動: 作る価値のあるものを見つける。
    • 右上のパターン: 見つけながら設計を行う。
  • 右の活動: そのうちの一部を作る。
    • 右下のパターン: 作りはきれいに、シンプルにする。
  • 下の活動: 変化を心に留めながら作る。
    • 左下のパターン: 作りながら、テスタビリティも作り込んでいく。
  • 左の活動: 作ったものから学ぶ。
    • 左上のパターン: 学びながら、想像的・懐疑的に実験する。(上の活動に戻る)

次に、「テストの活動」に書かれた項目の例を挙げてみましょう。

  • 右上象限の活動: 豊富な例(examples)でプロダクトを明確にしていく、フィールドからのレポートをレビューする
  • 右下象限の活動: 低レベルのチェックを自動化する、保守性のためにリファクタリングする
  • 左下象限の活動: 内部のテスタビリティを設計する、コーディングと並行してテストを行う
  • 左上象限の活動: できあがったものを懐疑的に評価する、説得力のあるバグのストーリーを語る

ここから感じられるのは、実行するテストの種類をマッピングした「アジャイルテストの4象限」に対するアンチテーゼです。

  • テスト実行はテストの一部でしかない。その部分だけを分類して「アジャイルテスト」と呼ぶのはおかしい。
  • ツールや自動化は手段でしかない。それが本質であるかのように表現するのはおかしい。
  • チェックとテストは別モノである。
  • テストは継続的な活動である。それがまったく表現されていない。

という意志を表したものと言えると思います。

おわりに

この批判、ネガティブに捉えると、レストランに行って「サッカーボールが売っていないじゃないか」と言うようなイチャモンとも捉えられません。
一方で、「アジャイルテスト」を表現するものとして、確かに学ぶに値するものを含んでいるように思います。
みなさんはどのように感じられるでしょうか?

Created by Midjourney

*1:日本語翻訳版はコチラです。 www.kzsuzuki.com

*2:この件についての紹介記事は以下です。www.kzsuzuki.com

*3:海外のテストコミュニティの様子はよくわからないのですが、ちょいちょいイザコザのようなものが聞こえてきたりもします。わたしの見えている範囲では、日本のQAエンジニアのコミュニティは緩く広くつながっていて変な派閥もなく、幸せだなーと思ってます。

*4:live thought processを良い日本語に訳せなかった。「生放送」のliveと同じ意味なのだけれど、「生の」だとおかしいし、「生き生きとした」も何か変。