デイリー日々

生活ライフ

LLMとサグラダ・ファミリアとSaaSプロダクトとQAエンジニアと

※要約(長いので)
LLMが発達してQAエンジニアが追いやられていることに悩んでいましたが、プロダクトの前提を考えることで何となく方向性が見えました。というお話です。

いまだに「QAエンジニアってなんだろう」を考える日々です。

というのも、今年に入って以降のLLMとバイブコーディングの隆盛が想定以上に凄いからです。3月もここまでとは思っていなかったし、5月も凄すぎてよくわかんなかったし、今は…もう全てを理解することは諦めて、「そういうものなんだな」と思うに至っています。

ここまで進歩しなければここまで悩むこともなかっただろう、と思いますが、まあそういうことになってしまったならしょうがない。かといって考えないで仕事できるほど朗らかな人間でもない。

なぜ悩むか、って、QAエンジニアとしての自分の存在意義がわからなくなる/なくなるからです。
QAエンジニアの職務には「(テスト等を用いることで)プロダクトを正しく作れるようナビゲートする」性質があります。バイブコーディングが進めば、この領域に開発エンジニアが染み出して来ることは容易に想像できます。LLMがコーディングするなら、人間の業務はドメインエキスパートとしてLLMの成果物をレビューする方向にシフトするはずです。
最初こそテスト技術についてはQAエンジニアは一日の長がありますが、テストは大概が枯れた技術ですから、「QAエンジニアいらなくない？」と言われるのもすぐでしょう。
ましてや私はQA畑ではないので、ただの劣化エンジニアです。

自分の存在価値がなくなる。
厳しい現実を突きつけられてしまったな、と思いました。

TVerで博士ちゃんの世界遺産サグラダ・ファミリアSPを観ました。

tver.jp

「最近テレビ面白くねえなあ」と思いながらダラダラとテレビやらサブスクしてるやつやらザッピングして、TVerで目に止まったのが芦田愛菜ちゃんがバルセロナに行った回で、そのまますっかり引き込まれて観ました。

終わりの方に、外尾悦郎氏へのインタビューがあります。日本人にしてサグラダ・ファミリアの主任彫刻家の方です。
これがまた…シビレるインタビューでした。なんかゴチャゴチャいうのも野暮です、TVerで見てください。

インタビューの中で、「サグラダ・ファミリアの"完成"についてどう思うか？」という問いに対しての外尾氏の回答に、個人的に示唆を受けたところがありました。
曰く、「"完成"ということについてもっと考えるべき。常にいいものが出るなら完成ではない。人間が作るものに完成はない。」とのことでした。端折りまくってるのでTVerで見てください。

話を聞きながら、「これSaaSプロダクトにも通ずるな」と思うわけです。我々は日々完成しないものを作っているのです。
そもそもこれまでは完成する/しないを考えることもなかったわけですが、完成することがないのは明らかです。

我々の取り扱うプロダクトは完成しない。ならそれを前提として自身の指針や行動を考えるのはどうだろう。と思ったわけです。

「完成しない」ということに立脚すると、プロダクト開発に出てくる主要なアクターの考えることはこんな感じでしょう。

  • ビジネスサイド・PdM: これから先どのように良くしていくか
  • 開発エンジニア(デザイナー・SRE等含む): 今どのように良くしていくか

じゃあQAエンジニアの考えるべきことは、「これから先」を「今」に正しくつなげることなんじゃないか？と思いました。
これから先こういうことをプロダクトに盛り込みたい、ならこれを明らかにしておかないといけないよね、こんなものを用意しておかないといけないよね、ということをPdMや開発エンジニアと協力して進めることが必要かな、と。

これは、シフトレフト・シフトライトをより推し進める、ということかもしれません。「今」実装するにあたって必要なテストは多分もうLLMと開発エンジニアが作りますから、そこにQAエンジニアは不要になるはずです。「これから先」必要になる対応に対して、先んじて分析して、先んじて品質・正当性を保証できる方法を用意して、「今」実装できるようにする、そんな動きだと思います。
テストエンジニア志向のQAエンジニアならテスト分析・計画・設計を先にやっておくこと、SETならテストの実行環境を含むパイプラインを整備しておくこと、あたりから始めることになるのでしょうか。どちらにせよ、開発エンジニアより先を見通していないといけないでしょうね。

プラス、より良いものにできる、ということに貪欲になる必要がありそうです。アジャイル開発の「こうなっていればアジャイル開発を体現できている」というものはなく、常に磨き続けるところに本質があるところに通ずると思います。チェックポイントとして「完成」というものがあったとしても、それは綻びの始まりかもしれない。

ということで、なんとなく目指すべき方向性が見えた？かも？というお話でした。

再三書いてますが、博士ちゃんの世界遺産サグラダ・ファミリアSP、TVerで見てください。
時間がなければ外尾悦郎氏へのインタビューだけでも。2:25あたりです。
私にはブッ刺さりまくりました。上に書いたこと以外も示唆に富む内容です。是非。

三十代半ば過ぎの気付き - 損していた話

いい歳になってきたんですが、いまだに「そうだったのかあ」と思うことがぽつらぽつらありまして。という記録をしていこうと思いました。

のっけから汚め？な話です。すみません…でも結構衝撃を受けたのです…

トイレットペーパーは使い方を知らないと損をする

今までこうやって巻いてました。

ちゃんと図をこしらえました

で、気づきました。
この巻き方、シングルのトイレットペーパーだとガサガサの方が表にくるんです。

気づいたときは、もう愕然としましたね。今までだいぶ損をしていたぞ。と思いました。
私はお腹がゆるいほう(過敏性ﾅﾝﾀﾗｶﾝﾀﾗもち)なので、人よりだいぶ損をしています。

ちなみに、周囲に尋ねてみたところ、意外とみんなちゃんと巻いてない、ということがわかりました。両親ともｸｼｬｸｼｬｯとしてました。えっワシャ誰に倣って巻いてたんだ？

LT「QAエンジニアを諦めつつある」こぼれ話

先月また歳をとりまして…三十代半ばすぎ、めっちゃ具合悪いですね…
というわけで元気が出なくてまとめてなかったんですが、ふりかえりのために記事にしとこうと思いました。

イベントについて

QA engineer at a Startup vol.12に呼んでいただきまして。話してきました。発端はこの記事ですね。

blog.dashi-no-ajiwai.net

資料はこちらです。

speakerdeck.com

トーク内容(抄)

  • 「QA = テスト」ではない、みたいな議論は30年以上なされており結論は出ないので、"QAエンジニア"像は自分で決める
  • 品質は主観的で相対的、誰の視点で品質を捉えるか？ということを考えてみる
  • 限られたリソースで最大限コミットするために、好きなこと・やりたいことをやる
    • スキ😊パワー を活かす

よもやま

"QAエンジニア"という職種名と実情

そもそも職種名がアレですよね…*1とずーっと思ってるんですが、お話しした通り、もう30年はモメてるっぽい職種名ですからね…。

QAエンジニアという職種とそれに包含されるロールについては、QMファンネルと呼ばれる整理も有名かと思います。

www.slideshare.net

ただ、これも「(狭義の)テストをする」ことをベースとしたものなので、「(狭義の)テスト苦手！したくない！🥺」という私にとってはあまりしっくりこないものでありました。私が一番やりたいのは ソフトウェア自体(と付随してそのテスト)の可塑性を高めて変化に追随できるようにしつつ、堅牢性を評価できるようにする というようなものなのです。SETでもないです。

ということで、もういいや！QAエンジニアだけど(狭義の)テストしねえ！とヤケになって記事書いたのが今回のLTにつながりました。

あと、こういう痛快な会話もありました。本当にそうですね、って思ってます。まあ私はQAエンジニアという職種を隠れ蓑にしているので若干後ろめたいですが。

「テストをしない」ということ

いや、「テストをしない」というのは詭弁です。わかっています。わかっているのです…。
というのも、やはりQA界隈の"テスト"というものが広すぎるからです。なので、前の節ではあえて"(狭義の)"をつけていました。テスト、と言った場合、(特に動的テストの)テスト分析〜実施とその周辺が一般的だと思います。

ISTQB Glossaryによる"テスト"の定義がコチラです。

コンポーネントやシステム、および関連する作業成果物の品質を評価するための、ソフトウェア開発ライフサイクル内のプロセス。

「品質を評価するためのプロセス」がぜ〜んぶテストだ、と言っているわけです。なのでここのレベル感が各々違うので、ちょいちょい認識の齟齬が生まれるんですよね。
(かくいう私も「レビューもテスト」みたいな文言に触れた時は「えぇ〜」って感じでした。開発エンジニア上がりだとそう思いやすいのでは)

ということで、LTではまとめの方で話したのですが、上記定義のテストをマインドとして持っていれば、それはQAエンジニアなのではなかろうか、と思っています。

さいごに

時間を割いて聞いてくださった皆さま、そしてQaaS運営の皆さま、ありがとうございました！
特に誰かに刺さることも期待せず、「こういう道もあるのではなかろうか」という自己肯定のためのLTでしたが、結果話してよかったと思います。

QAエンジニアしていると、(狭義の)テストに関連する業務が主ではあるのですが、それ以外の道もありそうだと伝われば幸いです。

↓アイキャッチ用画像です、新潟行く機会があればラーメンを食べるといいですよ

*1:個人的にはSREも微妙だと思ってます。reliabilityを考えるのはインフラだけではないだろう、という感じです。

QAエンジニアを諦めつつある(今更JaSST'25 Tokyoの感想)

なんか、肩の荷がおりてきました。

一応"QAエンジニア"と5年ほど名乗っています。
特にQAエンジニアになるために必要な資格なんてないので、問題はないはずです。
(JSTQB FLすらも持ってないです)

なんですが、ずーっと負い目があったんですよね。「テストを作る」という経験が乏しいので。

元々C++のエンジニアをやっており、ダサいテストに辟易し、「テストは自動化できるものはした方がいい」と思ってコンバートしての現職です。
なので、「自動化する」ということにwillがあったものの、どういうテストを作るべきか？という部分は後付けでした。

それを5年ほど引きずってきました。

そして迎えたJaSST'25 Tokyo。たくさんのセッションとたくさんの人たち。
QA界隈に拭えない抵抗感があったんですが…割とどうでもいいのかもしれないと思いました。

みんなそれなりにテストの話はしていたんですが、それよりは「AI時代どうする」とか「組織課題どうする」とかそういう話が多くて、別にテストに閉ざした話だけではなく、「どうしていこっか」「こうしたらちょっとよかった」という感じでした。

あああ、凝り固まってたんだ、と思い知らされました。

QAエンジニアたるものテスト設計ができなければならない、テスト分析で疎にして漏らさずのモデリングができないといけない、テスト計画で適切にテストレベル設定ができていないといけない、テスト実装・実施して不具合分析できないといけない….
なんて勝手に思って勝手に負い目を感じていたんだな、と。

もちろんQAエンジニアとしてのコアコンピタンス？コアスキル？としてのテストの考え方は必要ですが、別に「絶対にバキバキにできないといけない」ものでもなく、それなりに理解できていればいい、のかもしれない。

なあ〜んて思ってのJaSST'25 Tokyo打ち上げ。同僚QAエンジニア2人に「テスト設計できないんよ」と吐露しまして。

「知ってる」
「うん、できないよね」
「やろうと思えばできるでしょ、やろうと思わないだけで」

痛快なコメントをくらいました。が、晴れやかでした。もうテスト設計とか、おれやんなくていいや！って感じです。正直やりたいと思わないし、得意じゃない、たぶん。

ということで、ワタシ、(今まで思ってた一般の)QAエンジニアになることを諦めることにしました。
(狭義の)ソフトウェアテストはしないけども、その代わり開発エンジニア・ビジネスメンバーが自動テストを読みやすい作りやすいとか、CI/CDパイプラインが元気に動いてリグレッションテストしながら自動でプロダクトがデプロイされるとか、プロダクトコード自体の品質がいいとか、品質改善につなげられるモニタリングするとか。

考えてみれば、元々エンジニア上がりだというのをあまりアドバンテージにしてこなかった(逆にQA畑でないことだけ考えていた)のかもしれないなあ、という感じです。労せず普通にソースコード読み書きできるQAエンジニアって多くないのに、それを捨ててテストエンジニアになる必要はなかった。

しかも、別にSET(Software Engineer in Test)でもないな、という感じです。テストだけをエンジニアリングするわけではなく、普通にプロダクトコードとかデプロイパイプラインとかにも携わっていきたいので。なので、「SET寄り」ではあるけどもSETではないな、という感じです。

じゃあなんて名乗るか？っていうと、結局QAエンジニアなんですよね。「品質良くしたい」というのは同じなので。QAエンジニアって元々ファジーで雲を掴むようなぼやけた職種なので、それを隠れ蓑にしようと思ってます。

ということで、肩書きはQAエンジニアのままだけど、内部的には大きな変化があったよ、というお話でした。今後ともご贔屓に！

同僚QAエンジニア2人には日々刺激をもらっていますが、特に今回は触媒として私に大きな気づきを与えてくれました。いつもありがとうね！

↓アイキャッチ用画像です、アナザースカイでパクソジュンが来てた青島！

わたし、健康になります

※このブログは技術以外の話もしますよ

三十代既婚男性と健康

結婚して、三十代になって早6年くらい経ちました。「もうモテとか見てくれとか気にしなくていいんだあ」という安心感のぬるま湯に浸かって6年。もはや腹の凹まし方も忘れつつあります。

そして…案の定色々崩れてきています。見た目だけではなく。

体重はコロナ禍頃から高止まり、ピークよりは多少落としたものの、学生時代(15年くらい前)の「このライン超えたらヤバい」を超えています。
体脂肪率も20%台前半。そうです私が軽肥満です。

健康診断はC判定、肝臓の数値が高めです。
毎度「食い過ぎだ、運動をしろ」と書いてあります。Yes, I know, I know, I understand...

今年は3ヶ月で肋間筋断裂→ぎっくり腰をやらかしました。しかも治りが遅い。もうグニャグニャです。
立てば腰痛座ればため息、歩く姿はおじいさん。

決めました。

わたし、健康になります。

モチベーション

コチラなんです。

www.youtube.com

最初は「ほ〜ん」と見ていましたが、4ヶ月経ったあたりで明らかに体がパキッとしてるな？？？と思いました。
というわけで、ここまでやらないまでも、ちょっと頑張ろうと思ったわけです。

この方も「おすすめできない」「量も回数も半分にした方がいい」とのことでした。

www.youtube.com

ということでまずはダウンサイジングして行います。

やること

エンジニアの端くれなので、SMARTな感じの行動指針を立てます。

  • 週に2日以上、5km以上のジョギングをする
  • 週に2日以上、ジムで筋トレをする

まずは「できるようにする」なので、結構ハードルは下げています。そうしないと折れちゃうから…。

当面の目標

コチラもSMARTな感じの目標にします。

  • 4月中にジョギング平均ペースを 9:00/km にする

今日走ったら9:20/kmでした。遅い？運動経験なし小デブをナメないで頂きたい。

当面体重・体脂肪率は(測定しますが)追いません。多分一喜一憂することになりますからね。

がんばらないこと

食事は、できるだけ脂肪を控えめにしますが、ガチ食事制限みたいなものはしません。

いや、「運動より食事のほうが大事」っていうのはよく聞くし知ってるんですよ。
でも、日々の楽しみ奪われちゃうのはつらいのですよ…作るのも食べるのも好きなので…。

乗ってきたらあすけんとかやります。

次回定期報告

5月頭予定です。報告がなければ「ダメだったんだな」と思ってください。

今年こそ！夏までに！パキッと！するぞお！

自動テストと初期化 - (3)初期データの勘所

※続きものです。前のやつはコチラ、最初の記事はコチラです！

はじめに

初期化がいかに大事なのか、2記事に渡って書いてきました。
ようやく、実際にどうするべきか？というところを書いていきます。

また「世界」の話が出ます。別のいい言い方が思い浮かばないので…ご容赦ください！

データの捉え方

ズバリ、ルートオブジェクトがあるかどうかによって並列性などの考え方が変わってきます。

ルートオブジェクトあり

一つルートとなる何かがあり、それに紐づいてデータができているパターンです。逆に言えば、全てのデータをたどると、最終的にルートとなるデータにたどり着きます。
toBのSaaSのプロダクトだとこの形式が多いかもしれません。

プロダクト例 ルートオブジェクト
病院カルテシステム 病院
BIツール 企業/法人

この場合、ルートオブジェクトが異なるものは独立しているので、それぞれの「世界」にそれぞれルートオブジェクトがあり、紐づくデータが含まれるわけです。このパターンは並列化も容易です。

それぞれの「世界」が干渉しないため、「世界」ごとにconstruct / destructしてテストを実施することができます。

ルートオブジェクトなし

分散型、とでもいうのでしょうか。ある「世界」にN個のオブジェクトがあったり、オブジェクトとオブジェクトがN対Nで結びついたりしているものです。

プロダクト例
証券口座システム
社内管理システム

私が業務で扱っているのは「ルートオブジェクトあり」のものなので、この「ルートオブジェクトなし」のものについてはあまり明るくないです…。
今扱っているプロダクトに「社内管理画面」があり、そのテストの知見を少し書きます。

コチラは若干面倒で、「世界」を区切るのが面倒です。そのため、このパターンだと実行順序性などを考慮する必要があります。

例えば、BIツールSaaSプロダクトの導入企業管理システムで「導入社名で検索する」ようなユースケースがあると思います。このとき、テストを並列実行すると、各テストストリームで似た名前の社名を使用している場合にテスト実行のコンテキストによって表示される導入社の件数が異なることがありえます。

結局どうしたらいいの？

基本戦略は大体こんな感じです。

  • ルートオブジェクトあり / なしで分ける
    • あり: 「世界」ごとにシナリオを分け、並列実行する
    • なし
      • 並列実行せず、ルートオブジェクトなしシナリオだけ直列実行する(最低限にする)
      • プロダクト環境も並列化し、テストストリームごとに一つのプロダクト環境をアサインし、干渉しないようにする

ルートオブジェクトがあるものは並列化し放題なので、基本的にルートオブジェクトがあるものを起点に考えるといいと思います。
また、ルートオブジェクトなしパターンでも、細かくみていけばルートオブジェクトありパターンにすることができます。例えば証券口座システムでも、一つの証券口座をルートオブジェクトとみなし、その情報の設定などをテストすることができます。
さらに、ルートオブジェクトありパターンでも、ルートオブジェクトが常に同種とは限らないこともあります。電子カルテシステムなら通常は病院がルートオブジェクトですが、医療法人(複数病院を保持する)をルートオブジェクトとすることも考えられますし、病院内の1つのカルテをルートオブジェクトと考えて診断内容・投薬内容などを記載することも考えられます。

実例

電子カルテシステムのテストで、setupをスクリプト的に行なったものとして記載します。今私が携わるプロダクトでも同じように初期化スクリプトを作成しています。

/* ルートオブジェクト(病院)のinsert */
const hospital_id = await DB.insert(
  'hospitals',
  [
    {
      'name': 'dummy病院',
      ...
    },
  ]
);
/* 付帯データのinsert */
// (病院の)医師
const doctor_id = await DB.insert(
  'doctors',
  [
    {
      'name': 'ドクターX',
      hospital_id,
      ...
    }
  ]
);
// (病院の)患者
const patient_id = await DB.insert(
  'patients',
  [
    {
      'name': '患者A',
      hospital_id,
      ...
    }
  ]
);
// (患者の)カルテ
const karte_id = await DB.insert(
  'kartes',
  [
    {
      hospital_id,
      patient_id,
      ...
    }
  ]
);

ルートオブジェクト(病院)から芋づる式に付帯データまでつながっているのがわかるかと思います。逆に言えば、このようにルートオブジェクトから全てがつながっていなければ、ルートオブジェクトなしパターンです。

なお、このとき、teardownは逆順(付帯データ→ルートオブジェクト)としたほうがいいです。ID類を内部にストアしておいて、自動teardownを作成することもできます。
というより、そもそもteardownをする必要もないかもしれません。全て個別の「世界」で完結していれば不要です！

いかがでしたか？

初期化について3記事に渡って書いてきました。さすがに読んでて疲れますね〜。でもここに書いたのがほぼ全てです。

本当に、初期化を制すことができれば、自動テストも怖くないです。初期化がうまくできれば、あとはテスト内容に注力できます。これは結構強力だと思うんです。特にUI使うテストだと安定化させるために何回も実行する必要があるので、再実行が容易なことが実質必須です。そういったことも結局初期化がうまくできているかどうかです。

というわけで誰かの役に立てたらいいなと思います。幸あれ！

自動テストと初期化 - (2)並列実行性・再実行性

※続きものです。前のやつはコチラ、次のやつはコチラ！

はじめに

自動テストを正しく並列実行できるよう、容易に再実行できるようにするためには、テスト開始時の初期化をうまくやることが重要です。
私の今までの経験から、どうすればうまくいきやすいか書いておきます。

並列実行性・再実行性の実際

並列実行性

並列実行ってそんなに重要？と思う方もいると思います。めっちゃ重要です。

テスト実行時間を考えたとき、直列でのみ実行していると、リニアに伸びていきます。
UIベースのテストであれば、1シナリオ30秒程度として、120シナリオで1時間になります。
120シナリオも作らない？自動化が進むにつれ120シナリオなんてすぐに到達します。
1時間くらいだったら待つ？システム全停止してhotfixを入れて、急がないとビジネス的価値を毀損するのに待つことができますか？

並列実行を前提としていれば、リソース量さえ増やせれば、実行時間は(総テスト時間) / (並列数)で済みます。
ちなみに、現在携わっているプロダクトのテストは、200シナリオ4並列で30分を切ります。分割・最適化の最中なので、それが完了すればもっと並列数を増やしてもっと短時間で実行できるようになり、CIでも軽量に回せるようになります。

そして、忘れてはいけないのは、並列実行前提で作られていないテストを並列実行するのはかなり厳しいということです。実質無理です。
実行順に依存していたり、データ構造に依存していたり、失敗する理由が大量にあります。

ということで、最初から並列実行できることを前提とした初期化システムにしておいた方がいいです。自動テストが成功するかどうか、ここにかかっていると言っても過言ではないです。

再実行性

再実行ってそんなに重要？と思う方もいると思います。めっちゃ重要です。

UIベースのテストはどんなに丁寧に作ってもFlakyです。APIのレスポンスが100ms遅延しただけでFAILします。0.1秒ですよ！
Flakinessをテストで吸収するための最も手っ取り早い方法が、リトライ設定を入れることです。不安定なテストでも3回もリトライすればそれなりに動くはずです。

しかし、ここもまた初期化の壁が立ちはだかります。固定IDでデータをinsertして初期化する仕組みにしていると、再実行時には「すでにあるよ」エラーになります。upsertでうまく避けるようにしたとしても、前回の実行で何かレコードができていると、勝手にリレーションができてしまい、表示が変わってFAILします。

さらに、テストを作っている間、動かして様子を見て変更して動かして…ということを繰り返します。そのとき、簡単に再実行できる仕組みを作っておかないと、本当に面倒です。以前はテスト実行後にDBを自動で吹っ飛ばすようにしたこともありましたが、そうするとDBコンテナが正しく立ち上がるまでテストできず、イライラしました。

ということで、最初から再実行できることを前提とした初期化システムにしておいた方がいいです。自動テストが成功するかどうか、ここにもかかっていると言っても過言ではないです。

実際どうするべきか

前回の記事の「世界」を用います。表現として好みでなければ、「状態」などと読み替えてください。

「世界」を構築する

簡単に言うと、「テスト実行ごとに独立した『世界』を作り出し、その中でテストが完結するようにする」と言うのが要点です。図にするとこんな感じです。

2並列実行してストリームが2つ生成されると、(テストランナーにもよりますが)各ストリームに適宜テストシナリオが割り当てられ、実行されます。そのシナリオごとに、「世界」が生成されます。その「世界」には、シナリオを実現できる最低限のデータを設定します。
前回の記事に倣った例(カレンダーの月曜始まり/日曜始まりをトグル)であれば、「カレンダーを表示できるユーザー」だったり、「カレンダーそのもの」だったり、それから「月曜始まり/日曜始まりを設定する何かしらのデータ」とか、です。

そして、重要なのは、これらの「世界」は全て独立しているというのが重要です。それぞれの「世界」が独立していれば、並列実行時に順序を組み替えたり、並列数を増やしたり、FAILしたときに再実行しても問題なく実行できます。

また、同じシナリオであっても、実行されるごとに別の「世界」が生成されることが大事です。テストがFAILし、再実行されたときのことを考えます。

世界1でFAILして、その再実行した世界1'が全く別のものであれば、全く別のテストと同様に実行することができます。そうでないと、例えば「カレンダーに予定を登録する」のようなステップがある場合、「世界1でFAILする前に入力した予定が世界1'で出てきてしまう」ようなことが起こりえます。こうなると、テストがFAILするのはもちろん、FAILしたときの原因の分析などが非常に面倒になります。

どうしたら実現できるか？

動的にデータを作成・挿入するに尽きます。

かつてCSVでデータを作成することも試しましたが、その場合固定IDとなってしまい、再実行時など「独立した『世界』」を初期化時に作成することができませんでした。したがって、何かしらスクリプト等で動的に作成した方がいいです。私は現状、TypeScriptで動的importを用いて実現しています。

カレンダーの例では、このような感じになるでしょうか。

  • ユーザーを挿入する: user_id を取得する
  • カレンダーを挿入する: user_id を用いる → calendar_id を取得する
  • 月曜始まり設定を挿入する: calendar_id を用いる

また、「基本的なデータをまとめておいた『世界』のスクリプト」を用意しておく、というのも便利です。そうすれば、今回のカレンダーの例は「月曜始まり設定を挿入する」くらいでOKになります。

いかがでしたか？

より具体的に「世界」を構成することによって、並列実行性・再実行性を担保し、テスト開始時の初期化をうまくやる方法について記載しました。
そして、今回記載したことは、現に私が運用して強力さを体感しています。開発エンジニアからの評価も良好です。

次は初期データ構成の勘所について書こうと思います。今扱っているプロダクトでしか実例がないので自信がない部分もありますが…まあ大丈夫でしょうたぶん〜！