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

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

QAエンジニアならきっと学びのある『地雷グリコ』を読んでほしい

突然ですが、わたしはギャンブル物のマンガが大好きです。ギャンブルは弱いんですけどね。
そんなギャンブル物のマンガ、フィクションは、大きく2つに分かれます。

1つは、主人公が強敵たちと戦いながら強くなっていくもの。
運要素もあるのですが、経験や精神力を駆使して戦うものです。ある意味、スポーツ物やバトル物に似ています。 既存ギャンブルを下敷きにしていることが多く、たとえば麻雀の『天』『アカギ』『凍牌』がそんな感じです。直感、情熱、精神力が武器。
ギャンブルを題材に、ストーリーを重視していることが多いので、「ストーリー型」と呼んでおきましょう。

もう1つは、指定されたルールの範囲内で頭脳戦を繰り広げるもの。
そのルールにおいていかに相手を出し抜き、うまく立ち回るかが勝負になってきます。作者の考えたオリジナルゲームが出てくることが多く、ある意味ゲームが主人公とも言えるでしょう。『ライアーゲーム』『トモダチゲーム』『ギャンブルフィッシュ』『賭ケグルイ』なんかはこ地川といえそうです。論理、冷静、心理戦が武器。
こちらは「論理型」と呼びましょう。

もちろんこの「ストーリー型」「論理型」という雑なくくりはグラデーションであって、「どちらか」ではなく「どっちに近いか」という性質のものです。
またそもそもこのくくりに収まらない作品もあるでしょう。たとえば『嘘喰い』は、ギャンブルの頭脳戦と暴力バトルを組み合わせたものでした。

天-天和通りの快男児 1

天-天和通りの快男児 1

Amazon

「論理型」の傑作・『地雷グリコ』

『地雷グリコ』(青崎有吾・著)は、まごうことなき「論理型」の大傑作です。

5つの短編集が合わさって1つの作品になっており、それぞれの短編にオリジナルゲームが出てきます。そのゲーム達の素晴らしいところは、「誰でも知っているゲーム+オリジナル要素」という作りになっている点です。

書名にも入っている「グリコ」とは、そう、「ジャンケンで勝った方が、グリコ・チョコレート・パイナップルと言いながら階段を上っていく」、あの「グリコ」なのです。
ここに、「プレイヤーがそれぞれ、3つの段を選んで”地雷”を設置し、相手プレイヤーはそれを踏むと10段下がる」というルールを追加しています。
さあ、たったこれだけで、一体何が起こるというのでしょう?

グリコは、これは子供の遊び。それゆえにルールはきわめてシンプル。そこに独自ルールを一匙混ぜることで、いきなり増す深み。たまりません。
『カイジ』の「限定ジャンケン」の衝撃を思わせます。
ジャンケンという世界中の子どもが知っているゲームに、「手を使える回数が限られ、かつ時間内にその回数を使い切る必要がある」というシンプルに見えるルールを加えただけで、想像もつかない世界を描き出しました。これってまさに、「既存のものを組み合わせて新しいものを生み出す」イノベーションでは?

賭博黙示録 カイジ 1

賭博黙示録 カイジ 1

Amazon

『地雷グリコ』は、そのイノベーションを5つ生み出しています。
出てくる「元ゲーム」は以下の5つ。

  • グリコ
  • 神経衰弱
  • ジャンケン
  • だるまさんがころんだ
  • ポーカー*1

この手のって、タイトルになっている表題作だけが面白くて、後は「無理やり作ったな~」感が出がちなのですが、『地雷グリコ』は全部面白いんですよね・・。
そしてこの手のって、ギャンブルは面白いけど、文章や描写がへたくそ過ぎて・・というガッカリケースがあるのですが、文章も描写も上手で、読みやすいんですよね・・。また一人称を都度切り替える手法も、ギャンブル物フィクションとかなり相性がいいんだなと感心しました。

「論理型」ギャンブルフィクションは、何らかの言及がそのままネタバレになってしまいそうでなかなか紹介しづらいのですが、「誰でも知っているゲームをちょっと拡張して深いゲームにし、そこで緻密な頭脳戦を繰り広げる傑作」ということで、すごくオススメです。

論理型ギャンブルとQAエンジニアは相性がいいのか

さて、ではなぜ、『地雷グリコ』がQAエンジニアにオススメなのか。

論理型ギャンブルでは、「自然言語で」「ある程度複雑な」ルールが提示されます。プレイヤーはそのルールを深く理解し、ルールに隠された意図や曖昧さを見抜き、ゲームにおいて何が起こり得るかを吟味して戦略に組み入れます

ソフトウェアテスト*2では、これも「自然言語で」「ある程度(時には過剰に)複雑な」仕様が提示されます。QAエンジニアはこの仕様を十全に理解し、設計者の意図を把握して曖昧さを排除しながらも、実際のユーザやその環境において何が起こり得るかを検討してテスト設計に組み入れます

この「抽象的な記述から、ありうるケースを列挙して具体的に記述する」「特にレアかもしれないけれど、起こり得るケースを見逃さない」というところが、両者ですごく似ていると思うんですよね。

両者の対比を表にしてみましょう。ついでに、「詐欺」列も入れておきます。こうやってみると、QAエンジニアは詐欺向きなのかもしれません(突然の暴言)。

項目 論理型ギャンブル プロダクト開発 詐欺
熟考する対象 ルール 仕様 法律
立てる作戦 戦略の検討 テストケースの作成 詐欺シナリオの作成
行うこと ルールの穴を見つけて武器し、相手に勝つ 仕様上起こり得る可能性を見つけてテストする 法律の穴を見つけて相手を騙し、金を儲ける
心理 相手の思考を読み、誘導する ユーザが自然に思考するであろうことを想定する 相手の思考を読み、誘導する
バトルする主体 プレイヤー vs プレイヤー QAエンジニア vs プロダクトの可能性やユーザの多様性 詐欺師 vs 被害者

QAエンジニアの思考の習慣として、たとえばこんなものがあると思います。

  1. 数字の範囲を見たら、上限と下限を確認しろ
  2. 見慣れない用語を見たら、定義を確認しろ
  3. 条件を見たら、MECE性*3を確認しろ
  4. 「ただし」で始まるような補足、例外的なルールほど深く掘れ
  5. 開発者視点ではなく、ユーザがどのように考えるかを考えろ*4

論理型ギャンブルでも、これをそっくりの思考過程が起こります。
たとえば『天』(福本伸行・著)に「クリア麻雀」という戦いがあるのですが、まさにこれに類する驚きの結末が待っていました。脚注にネタバレを書いておきます*5

『地雷グリコ』はまさに、起こるうること、起こせることを徹底的に吟味し、それを実際に起こすことで戦いを進めていきます。
読めば、わたしが無理やり2つを結び付けているわけではないとわかっていただけるでしょう。

天-天和通りの快男児 1

天-天和通りの快男児 1

Amazon

おわりに

論理型ギャンブルのフィクションって、本当に面白いですよね。最近は、『ジャンケットバンク』をお勧めしています。

*1:ポーカーだけある意味「本格ギャンブル」ですが、手がかなり簡略化され、シンプルにされています。

*2:レビューでも同じことをします。

*3:「Mutually Exclusive and Collectively Exhaustive」、モレなくダブリなく。

*4:ソフトウェアテストでは、「心理戦」「裏をかく」は起こりませんが、「ユーザはどう考えるだろうか」「どのように振る舞うだろうか」という想定しますよね。その意味でも似ていると感じます。

*5:クリア麻雀の勝利条件は、以下の2つのいずれかを満たすことでした。➀指定された5つの役をすべて完成させること ②相手陣営のプレイヤーの持ち点を0点未満にすること。ですがこの➀と②は、排他ではありません。主人公が5つ目の役を完成させ上がった(➀を満足)時の点数が高すぎて味方の持ち点を大きく減らしてしまった(相手が②を満足)ため、勝利条件と敗北条件を同時に満たすというイレギュラーが起きました。一見排他に見える条件が同時に起こる可能性の考慮は重要です。

仕様スニペット004「サブスクリプションの自動更新」の #テスト設計パターン を考えてみる

JaSST北海道にかかりっきりで、テスト設計パターンに手をつけられていませんでした。
が、テスト設計パターンを考えることは、テスト設計という分野を今後充実させていくためにけっこう大事なことなんじゃないかと思っているので、仕様をもらえたら続けます。誰か、いい感じの仕様をくれ!!

docs.google.com

「テスト設計パターン」「仕様スニペット」って何?という方は、こちらの記事を先にご覧くださいね。

www.kzsuzuki.com www.kzsuzuki.com www.kzsuzuki.com

仕様スニペット004: 「サブスクリプションの自動更新」

第3回に続きこのネタも、かいりさんにいただきました。

以下に示す「サブスクリプションの自動更新」の仕様について、テスト観点を考えてください。

  1. サブスクリプションプランには、月次更新と年次更新がある。
    • 2024年1月1日に月次更新プランに登録した場合、次は2024年2月1日に更新される。
    • 2024年1月1日に年次更新プランに登録した場合、次は2025年1月1日に更新される。
  2. サブスクリプションの更新は、毎日定時にバッチ処理で実行される。
     ただし、特定の日付を指定して実行することもできる。

回答の例

鈴木の場合

やっぱり一番気になるのは日付なので、日付にフォーカスして考えてみました。

そもそもこの仕様1には「例示」があるだけで「ルール」が明示されていません。仕様を記述するうえでは、まずルールがあって、その理解を助けるための補足としての例示があるべき(個人の感想です)なので、例示しかない時点で設計した人と会話すべきでしょうね。

とはいえ今回は、

  • 月次更新の場合は、登録日の月mに1を足して yyyy年m+1月d日 に更新
  • 年次更新の場合は、登録日の年yに1を足して yyyy+1年m月d日 に更新

するのだろうと考えてみます。
パッと思いつくのは、以下の観点です。

  • m=1 なら m+1=2 でいいが、m=12 なら m+1 = 13 になってしまう。つまり、「年をまたぐ月次更新」はやりたい。
    • 同じ発想で、yの上限も考慮すべきかもしれないが、リスクは低い?
  • d = 31, 30, 29 のない月がある。
    • 月次更新の場合: 1/31、1/30、1/29(非うるう年)、3/31などは、mに1を足してもらうと該当する日付がない。
    • 年次更新の場合: 2/29(うるう年)などは、yに1を足すと、該当する日付がない。
  • そもそも、登録した日付によってサブスクリプションの有効日数が異なることがおかしいのでは?
  • タイムゾーン、サマータイム、時差までは考えすぎ?

仕様2の方もいろいろありそうですが・・・。

𝓜𝓪𝓼𝓪𝔂𝓾𝓴𝓲 𝓣𝓪𝓬𝓱𝓲𝓫𝓪𝓷𝓪 さんの場合

https://x.com/taiden32/status/1800775149245051085

気になる点として、閏秒及び閏年のテストがどうなるのかというのと、2/29に初回登録した時の年次更新がどうなるのかが気になりました。

うるう「秒」までは考えていませんでした。60秒の次に00秒があるケースを考慮要・・・?

やまずん さんの場合

https://x.com/55_ymzn/status/1802702136222040173

字数内ジャストアイデアで
・定時のバッチ処理なので、何件くらい処理できるかの負荷的なところを見たいです。
・更新ということなので、登録だけでなく解約があると思いますがこの辺の動作も見たいです。
・日次処理ってことですが、31日に登録した場合、次はいつになるのかが気になります。
・うるう

わたしがサボった仕様2について、非機能要件をカバーしてくれました。

また、仕様に書かれた「登録」「更新」と本来セットになるべき「解約」について言及してくれています。CRUDのように、この手の「考えられる操作の一そろい」を考えることはとても大事ですね。すると同時実行を連想して、更新のバッチ処理と解約処理を同時に行ったらどうなる?と考えていくことになると思います。

アシカ さんの場合

https://x.com/tyngw/status/1802826438825086978

解約や継続しないを選んだ後に、次回更新タイミングまでサブスクリプションを利用できることは確認したいです(よく私自身やる操作なので)

これ、わたしも今、某アンチウィルスソフトでこの状態ですw 「おいおいおいおい、もうすぐサブスクリプション期限が切れるぞ、後悔しないか?」って毎日詰められています。

やまずんさんと同じく、仕様に書かれた話からは外れるんですが、このように思いついたことを設計した人とぶつけあって、仕様を形にしていくのがわたしは好きです。

https://x.com/tyngw/status/1802829701880373656

特定の日を指定して実行というのがなかなか癖がありそう。
定時処理に失敗して、過去に遡って実行はありそうだけど、未来日も指定できるのかは気になります。

仕様2の「ただし」に書かれた手動実行、確かにバグの香りしますね。
今回はかなり情報が少ないのですが、「そもそも何のために必要な機能なのか」という目的に立ち返ることが必要な内容に思えました。

Hideo Oide さんの場合

https://x.com/hide_ramen_san/status/1802712643784024396

決済方法によるんですが、クレジットカードの有効期限切れは確認必要ですよね。

この発想は全然していませんでした。。いや、「更新が失敗するケース」は当然考えるべきなのですが、「日時」に注目しすぎている自分がいる。。
もちろん失敗はいろんな段階で起きうるでしょうから、各段階の失敗ケースをテストする必要がありますね。

おわりに

このシリーズも第4回なのですが、どうしても「情報が足りない」「仕様がよくない」の方に向きがち・・・。
いや実際そのケースもあるんですが、「テスト設計」が半分になってしまうから難しいなあ。
みなさん、もっと仕様を!

Generated By Dalle

2024年前半に読んで特によかった本

もう8月も終わりますが、2024年前半に読んだ本を振り返って、よかったな~と思うものを記録しておきます。

ソフトウェア開発

継続的デリバリーのソフトウェア工学

わたしの周りにも優れたスクラムコーチがいて、従来の発想から脱しきれないわたしに、アジャイルのエッセンスや考え方を辛抱強く共有してくれています。
そのうえで読む『継続的デリバリーのソフトウェア』は、わたしの蒙をさらに啓いてくれる良書でした。

実験主義、経験主義という言葉を軸に、「なぜアジャイルが今のような形になっているか」を繰り返し(時に冗長に?)教えてくれます。また「工学」というだけあって、単に思想的な部分だけでなく、技術的な説明も豊富です。

第4章のこのフレーズが、とても印象的です。

イテレーションの本質は、私たちが誤りを犯し、犯した誤りを正すことを認めることであり、学びを発展させ、広げていくことを認めることです。

ちょうど「失敗」について学んでいて、「失敗をどう生かすか」を考えていたわたしにとって、「アジャイルって、失敗を繰り返しまくるアプローチなんだ!」と膝を打ったのでした。
「アジャイルって、ウォーターフォールを短くして、エンジニアが好き勝手にやってるやつでしょ?」と考えがちな方にお勧めします。

ノンフィクション

評伝クリスチャン・ラッセン

クリスチャン・ラッセンという名前につきまとう、どこかうさんくさい雰囲気。そのラッセンを神格化するのではなく、そのうさんくささが何に起因するのかに踏み込んでいるのが、『評伝クリスチャン・ラッセン』です。

ラッセンの流行り廃りにとどまらず、「平成」という時代との関連性、本流美術からの扱われ方、かつて亡きものにされた戦争画との類似性など、思った以上に広いトピックを論じていて面白い。
たとえば「CR・ラッセンワールドMJ」というパチンコ台。これを単にラッセンの凋落とみるか、もっと別の背景・文脈があるとみるかで、本書では後者の立場を取っています。

日本における美術の位置づけについてもよく解説されており、タイトルで敬遠するのはもったいない良書でした。

深夜特急

『働かないふたり』という素晴らしいマンガがあるのですが、その主人公の一人である読書好きの兄が読んでいた本。

いやーこれは・・・。旅の良さがここに詰まっている
大学時代にこんなの読んでしまったら、熱に出したように旅に出てしまうんだろうなと思います。

ただ、この本で描写されているような「旅」は、現代では実現できないかもしれないなあと寂しく思ったりもします。今ほど海外旅行が当たり前でなかった時代の、無計画な旅。せめてその擬似体験を楽しめる。そんな本です。

学問

詭弁論理学

名前は固いのですが、自然言語や論理パズルなどを扱った本です。タイトルの通り、詭弁もたくさん扱っていて、その例にいちいち腹が立ってしまうのが難点です(笑)。

以下は、「相殺法」という詭弁の例。

「わたしの家の前に車を停めちゃ困るよ」
「おまえは車を停めたことがないのか?」

イラァ・・・。

ぶっちゃけ、詭弁ってけっこう強い武器なんですよね。聞けば誰もが「こいつの言い分は何かおかしいぞ」って感じるので、詭弁の使い手は嫌われる。でも、その武器の性質を知っておかないと反撃することができず、その場では言いくるめられてしまう。なので、身を守るために詭弁を知っておくことは重要だと思います。
またこの本はタイトル通り、「論理」の本でもあるので、論理学についても学ぶことができますよ。

詭弁といえば、このツイのクロコダインの詭弁(?)、とても好きです。

ビジネス

人生が整うマウンティング大全

『会議でスマートに見せる100の方法』が好きな人ならきっと気に入る、ジョークビジネス書です。
読んでいると、「ああ、いるいるこういう人!」となったり、「あ、これ自分もやってるかも・・」となります。
たとえば「時差ボケマウント」。

ロンドン→ニューヨーク→シカゴ→東京を1週間で回ったせいで、時差ボケのオンパレード。学生時代に夢見た世界一周はこんなんじゃなかった。

この「嘆いている感じ」がまたいやらしいんですよねえ・・!

これらの「事例」だけでも面白いのですが、第3章。ビジネスにおけるマウンティングの位置づけを、非常にそれっぽく語っています。
虚構新聞の文が本物の新聞みたいであるように、第3章は「いかにもビジネス書にありそうな言い回し」がすごい。たとえば

「マウント消費」の活性化が長期的な経済成長をもたらす
:
官民一体となって、マウンティングを起点とする日本発のイノベーションを生み出す枠組みを整備することが求められる。
:
マウンティング欲求を「手放す」のではなく、マウンティング欲求を「味方につける」ことを意識することを始めてみるといいだろう。

とっても、っぽくないですか? こういうの大好きです。

フィクション

FX戦士くるみちゃん

表紙で敬遠する人もいると思うのだけれど、「投資」をしている人なら胃痛が止まらない、FX投機のマンガです。とんでもない速度で含み損が増えていくシーン、チャートが思惑とは違う方向に突き抜けてしまう描写、もう見てられません。見てられないと言いながら、この作品と衝撃描写が癖になって、何度もリピってしまってます。。

「投資で人生一発大逆転できるのでは?」
「5%の利益を20回繰り返せば資産が2.5倍になる・・?」
などというグッドアイデアを思いついた人に読んでもらいたいマンガです。

AIとSF

AI大勃興時代の今まさに読んでおくべき渾身の短編集。
自分たちが生きている間に起きても何ら不思議のない事象、しかしまだ見たことのないはずの出来事が克明に描かれています。もちろんSFとしても面白い作品ばかり。特に生成AIの登場は、SFの世界を広げていると感じます。
これらはSFというより、「確定した未来」なのかもしれません。その意味で、ソフトウェア開発に関わっている人ならきっと楽しめる本だと思います。

不思議なのは、示し合わせたわけでもないだろうに、AIと仏教を組み合わせた作品が3つもある点。「意外なものの組み合わせ」はアイデアの基本とはいえ、組み合わせてみると何とも味わい深いです。

「仏師達は同時に仏像のAIへと真言(プロンプト)を彫り込んだ。」(『月下組討仏師』)

いや、熱過ぎる・・。

幻夏

これまでに読んだミステリーの中でも屈指の、「完璧な」作品の一つ。
警察が中心になるミステリーということであまり期待せず読んだのですが、素晴らしい作りでした。警察と司法が抱える問題を訴えながら、恐ろしく美しく回収されていく伏線、ミステリーとしての面白さなどが完全にマッチした作品です。

一方で、読んでいて苦しくなる作品でもあります。特に子供の話なので、親の立場になるとつらいです。
ただそれでも、単なるエンターテインメントに留まらないこの小説、ぜひ読んでもらいたいです。

おわりに

いやぁ、本って本当にいいもんですね。
2024年後半も、たくさん本を読みたいと思います。

JaSST’24 Hokkaidoの基調講演の機会をいただきました #jassthokkaido

2024年8月23日、JaSST'24 Hokkaidoが開催されました。このイベントでわたしは、光栄にも基調講演のご依頼をいただき、90分のプレゼンテーションを行いました。
拙い発表だったと思いますが、耳を傾けてくださったみなさんに感謝いたします。

www.jasst.jp

資料

資料はコチラです。

speakerdeck.com

わたしの資料はけっこう脚注が多いのですが、フォントサイズ9は、オンサイトのみなさんには識別不可能。引用元などの情報を載せていますので、復習などにお使いください。

なお、この資料の構成をベースにして、20年かけて情報量50倍で書籍化したいので、出版社のみなさんお声がけお願いします。

経緯

実行委員の中岫さんから2月に打診いただいたものの、「現場でプロダクトをバリバリ触っているわけでもない今の自分が、どんな話をできるだろう」と悩みました。
ですが、「リスキリング」というお題をいただき、「広く浅く、最近の品質保証の世界の探検を先導することはできるんじゃないか?」と考え、今回のタイトル、「ソフトウェア品質のダンジョンマッピング」というテーマを決めたのでした。

資料作成

最初「90分しゃべるほどネタは出るだろうか」

終盤「スライド10枚くらい非表示にしないと終わらん」

ってことで、「ソフトウェア品質保証」と言ったときに語るべきネタが思った以上に多いことを痛感しました。たぶん、プロのQAのみなさんから見ると、「これでカバーしたつもりかよ! 弱っ!」となるでしょう。おそらくその通りで、広さも、深さも、「ダンジョンを一通り見られたね」とは言えそうにありません。
また、それぞれのネタについて、わたしがしっかり理解しているかといえば、それもまた偽です。見る人が見たらわかると思います。

とはいえ、「QAエンジニアの仕事って、テストだけじゃないよね」という最近よく聞く話に対して、「そうだよね」を言えるくらいにはネタを詰め込めたかなと思います。

札幌へ

まあまあ早めに自宅を出たつもりだったのですが、

  1. 浜松町で降りてみたら、モノレールが運休になっている&運休にブチ切れて駅員を詰めてる英語話者をチョット助ける
  2. 別ルートで品川から羽田に向かったら、大混雑&ゆれゆれで具合の悪くなった小学生が盛大に嘔吐*1
  3. 羽田空港で手荷物検査をしようとして、チケットの買い間違いが発覚

発表中にネタとして消化できたのでよかったですが、ドキドキ大冒険でした・・。

行きと帰り、入れ替わってるーーー?

発表

最近はオンライン会議が多く、話す内容はパワポの「ノート」に書いておけば、台本として読めるんですよね。
オフラインはそれができない。一方で、「話す内容を全部スライドに書いておいて、スクリーンの方を見ながら話す」はカッコ悪い!

ってことで、話す内容がすらっと出てくるように、また時間の見積もりをするためにけっこう練習したと思います。「壇上でめっちゃスクリーン見ながら話している人」になるのは避けられたかなと。てか、後半はほぼスクリーン見ずに、やたら語っていた気がします。

↑ これやりたかったな。

とはいえ当日になると興がのり、話すつもりのなかったものを話したり、みなさんが「は?」って顔だと「もうちょい説明しよう!」となったりするので、5分ほどオーバーしてしまいました。実行委員のみなさん、ご心配おかけしました。

発表を終えて

やっぱり準備はなかなか苦しいものでした。。スライドを作れば作るほど、自分の理解の浅さや勉強不足に気づきますし、内容も「これ何が面白いんだ? こんな発表に価値はないのでは?」と思えて、自問自答大会になってしまいます。

ですが資料作成を通じて、「自分が考えるQAの仕事」「自分がこれから深めたいこと」を整理できたと思います。
「面白かったよ」(お世辞含む)と言ってくださる方も何人かいらして、少なくとも今自分でお渡しできるものの最大を出せたのではないかと信じたいところです。どなたかのヒントになれば、とても嬉しいです。

実は地方JaSSTは初参加でした。JaSST東京のような大規模イベントももちろん大きな労力がかかっていると思いますが、地方JaSSTはまた別の大変さがあるというのが、実行委員の皆さんを通じて感じられました。
わたしに声かけくださった委員のみなさんの蛮勇に感謝するとともに、今後も地方JaSSTを応援していきたいと思います。
みなさん、どうもありがとうございました。

アフィリエイトリンク

資料中で言及した書籍については最後の方にアフィリエイトリンク付きQRコードで一覧化していますので、みなさんそこから買って、わたしがまた新しい本を読むのを手伝ってください

*1:お母さんがビニール袋を渡していたので大惨事には至らず。2週間前にわたしの次男もタクシーで同じ状態になったので、優しい心でウェットティッシュを渡しました。

『#テスト自動化実践ガイド』をとっても粗く一読したので感想メモを書いた

2024年8月の『テスト自動化実践ガイド』を、著者の末村拓也さんからご恵投いただきました。ありがとうございます!

隙あれば自分語りおじさんとなり恐縮なのですが、「テスト自動化研究会」のゆかいな仲間たちと、同じ翔泳社さんから『システムテスト自動化 標準ガイド』(通称『ギア本』)と出したのが2014年。
10年経って、同じ翔泳社さんから、E2Eテスト(あるいはシステムテスト)レベルの自動化をスコープにした新しい書籍が出版されたことに、喜びを感じています。

ものすごく雑な粗読みですが、本全体をがーっと読んでみたので、感想を書いてみます。

対象読者とわたしのレベル

テスト自動化についてのわたしの知識・スキルレベルは、(恥ずかしながら)こんな感じです。

  • いわゆる開発者テストについては、書籍やネット記事の知識のみ。
  • いわゆるQAテストについては、キーワード駆動テストのフレームワークをベースにした自動テストの計画・実装・実行を、かなり昔やっていた。
  • その頃に『ギア本』の翻訳をやっていたので、その頃の一般的な知識はあった。
  • 最近の趨勢やツールは全然わからん。

本書の対象読者として、以下のように書かれています。

QAエンジニアやテスターなどのポジションで、主に手動テストの設計や実行に携わっており、これらの業務を自動化して効果的なテストを実現したい方

知識も経験も古すぎてレベルゼロなので、この対象読者にわたしは入っていると言っていいでしょう。

Twitterにいると「アジャイルなんだから自動テスト完備は当たり前でしょ」という強い光に当てられ、「うちは手動がメイン‥」という人もそれを言い出せない雰囲気がありますが、本書はそういう読者が読むのに最適だと思います。

本書のざっくり紹介

本書は3つの部からなっています。

第1部 自動テストに取り組む前に

第1部は、テストと自動テストについての一般論です。
一般論というと退屈な話になりそうなのですが、以下の点が気にいっています。

  1. テストの目的について語ったうえで、自動テストの欠点をしっかり書いている。
    特に、「手動テストをそのまま自動化しただけの自動テスト」が、手動テストと自動テストの悪いところのハイブリッドになってしまう理由がわかりやすかったです。

  2. 自動化以前に、テスト分析やテスト設計というプロセスを通して、適切なテストケースを導く必要があることを書いている。
    テスト自動化についてのネット記事を読むと、「自動化すべき理想的なテストセットは、目の前にそろっている」という暗黙の前提があるように感じることがあります。実際にはそうじゃないはずなので、「まず良いテストをそろえなきゃ」を明示してくれているのがよいです。

  3. 通説から一歩引いて、自身の考えを提示している。
    たとえば第4章のコラムでは、理想に近いとされるテストピラミッド・テストトロフィーに対してアンチパターンとされるアイスクリームコーン型のテストのバランスが、技術の発展によってはむしろグッドプラクティスになるかも、と述べられています。 通説を並べただけの本はつまらないので、著者の思想がしっかり出ている本が好物です。

第2部 アプリケーションにE2Eテストを導入する

第2部は、サンプルアプリを使ったハンズオンです。

ハンズオンは(わたしのような)初学者向けにかなり丁寧に書かれているのですが、単なる手順の羅列に留まらず、「なぜこれが必要なのか」「なぜこの順番なのか」を理解してもらうことを意識していることが伝わってきます。技術的な理由だけでなく、思想的な理由も含めて。これがいいんですよね。

また、「とりあえず最低限動かす」→「ユーザーストーリーのテストを少しずつ追加する」→「可読性を下げる要因に対処して保守性を上げる」と進んでいくのが良いです。
本書に一貫した思想として、「小さくても汚くても、まず動くものを作って、少しずつ改善しよう」というのがあって、とても好きです。

第3部 自動テストを改善するテクニック

第3部は、自動テストの改善です。

第10章・第11章は文字通り技術的なトピックで、発展的な内容を扱っています。
一方、第12章ではふりかえりを扱っています。プロダクトと同様、自動テストも、品質をモニターしながら継続的に改善していく。そのための方法です。具体的なメトリクスなどについても言及があります。

おわりに

こうして本も終わりに近づいていくのですが、「おわりに」にとても大事なことが書かれています。

それは、テスト自動化にはみんなを巻き込もうというお話です。

これは末村さん自身が、自分の使ったテストが退職後にメンテされなくなり、おそらくは捨てられていったことへの反省から来ている教訓なんですね。

今はどうかわかりませんが『ギア本』の頃は、「テスト自動化は開発業務の片手間にはできず、専任のエンジニアが必要」と言われていました。
専任チームはテスト自動化を強力に進めてくれるかもしれませんが、一歩間違えるとサイロ化の要因となり、「あいつらがやってる自動テストの意義がよくわかん‥他の人誰もメンテできんし‥」となりかねません。それを避けるために周りを巻き込み、ご利益を享受してもらい、フィードバックを受け取り、より良いものにしていかないと、単なる独りよがりになってしまうんですよね。

技術書の最後にこの話が来て、何だかグッときてしまいました。
いや、やっぱりモノ作りって「人」なのよね、と・・・。

この本に書かれていたら嬉しかったなと思ったもの

2つあります。

1点目は、作られた自動テスト群をうまく管理するプラクティスです。
プロダクトが成長し、機能が増えていくと、E2Eテストも増えていくため、「何が自動化されて、何がされていないのか」「テスト同士にどういう関係があるのか」がカオスになりそうです。
ただ、本書は「テストの責務を明確にし、E2Eテストをむやみに増やさない」ことを説いているのと、第12章ではユーザーストーリーと自動テストの関連付けなどについても言及しており、そもそも大げさな管理が必要となることを避けようとしていると言えるかもしれません。

2点目は、目の前にある手動テストのうち、どこから自動化していくかの考え方です。
大きな方針として、最低限の動作確認であるスモークテストから始めることにはなるのですが、その後に控えるたくさんのテストたちにどう自動化の優先度をつけるかの手引きがあると嬉しいなーと思いました。
実行頻度、手動での実行時間・手間、テストとしての重要度、技術的難易度、みたいないくつかのパラメータがあるんじゃないかと勝手に考えています。

感想

『ギア本』は2014年出版なので「10年」と書きましたが、実は原著の『Software Test Automation』は1999年出版。つまり25年前の本なんですよね。翻訳の際に、「内容が古すぎる」という理由で、実例の章は大きく割愛しています。

ということもあって、テスト自動化について知っておくべきことが、本当にガラッと変わっているんだなと痛感させられました。
たとえば『ギア本』では、テスト自動化のレベルとして、

  • キャプチャ&リプレイ
  • データ駆動
  • キーワード駆動

が説明されています。この考え方が今無意味になっているということはないと思いますが、キャプチャ&リプレイなんてもう説明する必要もないのだろうし、データ駆動はフレームワークが当たり前に備えているからこれまた取り立てて強調することでもないのか?と思ったりしました。
一方で、アジャイル開発のスタイルにどうアラインしていくかという戦略がより重要になり、意識されている点が興味深いです。

まだ雑にしか読めておらず、ましてやハンズオンは手付かずなので、ゆっくり2周目を読んでいこうと思います。また今回ご恵投いただきましたが、Amazonで事前発注もしており2冊になるので、職場にもっていってみなさんにも紹介したいなと思います。自動化を進めていきたいみなさんにもおすすめしたい一冊です。

というか、え?
「筆者がテスト自動化に始めた取り組んだ2018年頃の段階では」って、テスト自動化に取り組んで6年で、1冊の本を書けてしまうの?
恐ろしい才能‥! おそらくあたしがあの域に到達したのは(ビスケの画像省略)

末村さん本とギア本、嬉しい。