10Xに入って1年半でやったこと・感じたこと

ふりかえり アドベントカレンダー

はじめに

10X 2年目のブロッコリーです。この記事は10X アドベントカレンダー 2024の9日目の記事です。

昨日はAnalytics Engineerのtenajimaさんが「入社エントリからの差分、入社1年9ヶ月目の現在地」という記事を公開しています。

10Xの推しポイントは、案件受注前の状況から問い合わせ内容まで、なんでもSlack上で見える状態になっていることです。

本記事では、2023年5月に入社して1年半経った私が、今までどんなことをやってきたのか書いていきます。いわゆる在職エントリーです。自分にとっても良いふりかえりになるかなーと思っています。

目次

在職していてどう感じているのか

最初に、現在在職していての感想を書きます。

入社時に期待していたこと

前職までよりも小さい組織で、開発者やビジネスチームと協働して仕事を進められそうだったからです。また、シフトレフトなテスト活動を目指している点も期待していました。

入社してどうだったか？

入社時に期待していた通りでした！

1人のエンジニアとして見てもらえている

「QAさん」ではなく、「ブロッコリーさん」として、開発者やビジネスチームと協働して進められている気がしています！実際に進めた結果については、本記事の後半部分をご覧ください。

プロダクトをどのように使ってもらえているのか気にしながら開発できている

プロダクトで新しい機能を開発している際、それがどのように使われることになるのか気にしながら開発できています。ただ単に作るだけでなく、「それが機能として使われていることを確認するためにはどういうログを仕込めば良いか」を開発時点で議論して進められているのは非常に良いなと思ってます。

経営陣ともフラットに話せている

経営者ともわりかしフラットに会話できているかなと思ってます。10X アドベントカレンダーの初日を担当したCFOの山田さんとは、日ハムの話題で盛り上がったりしました。もちろん、雑談だけでなく仕事の話もします！

最近は、新規事業関連でCEOのyamottyさんと会話する機会も増えてます。

情報の透明性が高い

冒頭の推しポイントにも書いている通り、様々な経過状況がSlack上で逐一見えている透明性はすごい良いなと思っています。開発するに至った背景情報を知る上で非常に助かってます。

仕事に集中できる環境が整っている

福利厚生も満足しています。特に、子供が病気になったときに、病児保育の費用補助が受けられるのは、仕事に集中できて非常に助かってます。

10Xから転職したい気持ちはあるか

以前の記事で書いている通り、「転職意向が無くてもどんどんカジュアル面談を受けるべき」というスタンスでいるので、転職サービスからのスカウトを受け取ったりもしているのですが、いただいたメッセージと10Xを比較して、改めて10Xで働き続けようと感じています。

ということで、総じて満足して働いてます！

在職中にどんなことをやったのか

上記で在職した感想を書きましたが、ここからは1年半で実際にどんなことをやったのか書き連ねてみます。

テストプロセスを観察した

入社して最初にやったこととして、どんなテストプロセスを経てテスト活動を行っているか観察しました。そしてプロセス改善を試みました。

詳しくは記事にしていますので、そちらをご覧ください。

nihonbuson.hatenadiary.jp

新機能のQAに明け暮れた

テストプロセス改善を行った後は、リリース予定だった新機能のQAを行っていました。開発者やPdMとの距離が近く、分からないところはすぐに聞けたのが非常に助かりました。

実際にリリースした機能はこちらです。切り替え対象となっている「シングルピッキング」の機能開発のQAに携わっていました。

prtimes.jp

パートナーの現場に行ってアプリの利用状況を観察した

2023年10月10日。それは私にとって、10Xに入ってから最も印象に残った日の1つです。

実際に店舗に行き、我々が開発しているアプリを使っている様子を観察しました。

この経験によって、

  • 我々が開発している内容が本当に役に立っているのか
  • 現場での運用上の工夫は何か

などを自分の目で見ることができました。

この経験について詳しくは、カンファレンスの登壇資料に記載しました。

speakerdeck.com

Feature Flagを活用するようになった

2024年に入って、Feature Flag(Toggle)を積極的に活用するようになりました。

できるだけmainブランチとの差分を少なくするためにRelease Flag(Toggle)として活用したり、少しずつ計画的にパートナーへ適用するためにOps Flag(Toggle)として活用したりしました。

詳しくは、以下の執筆記事にまとめたので、そちらをご覧ください。

agilejourney.uzabase.com

QAのEMになった

2024年の下半期には、QAチームのEMにもなりました。

普段の業務もこなしつつ、どうすればQAチームメンバーが良い方向で進めていけるかを考えていきました。

詳しくは先日12/4にイベントで発表したので、その資料をご覧ください。

speakerdeck.com

新規事業のQAも担当した

現在は、新規事業のQAも担当するようになりました。

こちらについてはまだまだこれからなので、何も示せるものがないのですが、日々新しくなっていくアプリに対してのQAを考える毎日です。

実際に新規事業の開発をしているみんなでワイガヤしている様子は以下の記事内の写真にあります。

product.10x.co.jp

Podcastのホストになった

10Xが運営しているPodcast「10X.fm」の企画の1つ「QA部屋」のホストになりました。

QA部屋の最新エピソードはこちらです。

open.spotify.com

おわりに

今回は入社して1年半でやったことをつらつらと書いてみました。

こうやってふりかえってみると、業務はどんどん行いつつ、やったことに対してアウトプットを示してきた1年半だったなーと思えました。

10Xではソフトウェアエンジニアを募集しているので、今回の内容を見て「興味がある」「一緒に働いてみたい！」と思った方は、ぜひ採用ページもご覧ください。

ソフトウェアエンジニア(SWE) / 株式会社10X

テスト自動化の前に大切にしていることについて発表してきた

アドベントカレンダー 技術 発表 勉強会 BDD

はじめに

この記事はソフトウェアテスト Advent Calendar 2024の8日目の記事です。

昨日、登壇してきました

昨日、ソフトウェアテスト自動化カンファレンス2024というイベントで登壇してきました。

登壇資料はこちらです。 speakerdeck.com

「振る舞い駆動開発（BDD）におけるテスト自動化の前に大切にしていること」と題して、BDDにおける大切な「発見(Discovery)」と「定式化(Formulation)」について発表してきました。

今回の発表を行ったきっかけ

今回このような発表を行った理由は、BDDについて考えている人たちが訴えているBDDの3つの要素が、あまり世の中に浸透していないと感じているからです。

特に、BDDというと「自動化(Automation)」の部分ばかりに目が行きがちですが、それ以前に「発見(Discovery)」と「定式化(Formulation)」を行うことの重要性も今回強くお伝えしました。

発見(Discovery)では、具体例を重視する

発見(Discovery)では具体例を用いることが大切であることを伝えました。

登壇資料には載せられていませんが、発表時に示した具体例の大事さを伝える動画は、Cucumber School Onlineにて無料で見れますので、気になる方はこちらをご覧ください。

school.cucumber.io

もしくは、YouTube上でも一部公開していますので、そちらをご覧ください。

www.youtube.com

定式化(Formulation)ではシナリオを改善する

定式化(Formulation)では読みやすいシナリオ作成に注力することが大切であることを伝えました。

その中でBRIEFの原則について紹介しました。

BRIEFの原則については、過去に当ブログで紹介しているので、そちらもご覧ください。

nihonbuson.hatenadiary.jp

今回の発表では、以下のテストシナリオの改善を試みました。

改善の過程は今回の発表資料をご覧ください。

おわりに

今回はソフトウェアテスト自動化カンファレンス2024で発表した「振る舞い駆動開発（BDD）におけるテスト自動化の前に大切にしていること」の中身を紹介しました。

個人的に今回の発表の考え方は、BDDだけに限らず、自動テストを作成する上でも大事な考え方かなと思っています。

以前に「テストコードにはテストの意図を込めよう」という発表で、「自動テストはテストプロセスのテスト実装を注力しがち」「自動テストを作成する際にも、テスト分析やテスト設計を考えよう」という話をしました。

今回のDiscoveryやFormulationを大事にしようという話に通ずるところかなと感じています。

ぜひ、BDDを利用している人もそうでない人も、自動化の前にDoscoveryやFormulationのような考え方を取り入れてみてください。

品質管理チームのエンジニアリングマネージャーとして大事にしていることについて発表してきた

アドベントカレンダー 発表 勉強会

はじめに

この記事はソフトウェアテストの小ネタ Advent Calendar 2024の5日目の記事です。

昨日、登壇してきました

昨日、Nihonbashi Test Talk #3というイベントで登壇してきました。

登壇資料はこちらです。

speakerdeck.com

今秋から品質管理チームのエンジニアリングマネージャー（EM）になったけど、何を大事にすべきなのかをきちんと言語化してなかったなーと思ったので、言語化して発表資料にまとめました。

QAエンジニアは自らの発信力が足りないことが多く、自分がやったことをうまくアピールできていないと感じていたので、その補助する役目としてのEMになれば良いかなと思っている今日この頃です。

本記事では、発表に至る想いについてを書いてみます。

日々の1on1と自己評価シートは繋がっている

私は以前にビジョナル株式会社で働いていました。ビジョナル株式会社の主力サービスはビズリーチですが、私は一時期HRMOSの開発に携わっていました。

hrmos.co

このHRMOSですごい良い製品だなと感じているものとして、1on1と目標や自己評価をシームレスに繋げられている点があります。

私自身はHRMOSから離れてしまいました（転職した）が、この思想は今でも活用しています。

なので、自分がEMとしてメンバーと1on1をする際は、目標や自己評価を意識できるように仕向けています。

なお、仕向けるぐらいが大事で、「目標は達成できてるの？」と詰めるようにしないことが大切です。

日々の業務の話や、その時の思考過程を開示してもらって、それを私は1on1メモにできるだけ書き留めるようにしています。また、そこから得られる普遍的な話や知識を伝えるようにしています。そんな話を今回の発表ではお伝えしました。

スライド21ページ

自己評価シートと職務経歴書は繋がっている

さらに自己評価シートと職務経歴書も繋がっていると思います。自分で「こんなことやったよ！」と言語化できるようにしておくことは、評価時の材料になるだけでなく、職務経歴書にも書くことができるはずで、それは本人のキャリアにもつながる話だと思っています。

なので、普段の1on1の中で「その話は職務経歴書に書いておいた方が良いよ！」と積極的に伝えるようにしています。

もちろん、これは転職を推奨・斡旋しているのではありません。職務経歴書にぜひ書いてもらって、他の会社の動向も気にした上で*1、「それでも10Xに残りたいと思った」と言ってもらえるように環境を整えたいと思っています。それも私なりのEMの役目ですかね。

*1:前職で入社初日に、直属の上長に「カジュアル面談にはどんどん行った方が良いよ」とアドバイスを貰った経験は、私がEMになった際に本当に役立っているなと思ってます。

自分の発言に謝罪をしつつ、私がお勧めするソフトウェアテストの本の特徴を言語化する

はじめに　〜この記事を書くきっかけとなる発言と謝罪〜

先日、X上にてこのようなポストをしました。

これに対して、末村さんから次のような指摘をいただきました。

有用な指摘ありがとうございました！この指摘はごもっともです。この指摘から言える私の落ち度は次のようなものです。この場を借りて、謝罪させてください。

  • 「地雷な本」というパワーワードを使ってしまった
    • 特にこの表現は表現の自由を侵害していました。本当に申し訳ございませんでした。
  • 具体的にどのような本が「地雷な本」だと考えているのか分からない形で記載していた
    • それにより、ソフトウェアテストの本を執筆している人に不快感や不安を与えてしまったかもしれません。こちらも申し訳ございませんでした。
  • 「出版社通してフィードバックする」は既に行なっているが、それが見えない形でのポストになってしまっていた

その後、じゃここんぶさんから、地雷な本の公開についての議論をいくつか行いました。その中のポストの1つがこちらです。

せっかくこのようなご指摘をいただいたので、じゃここんぶさんの「お勧めできない理由の公開」とは若干異なる形にはなってしまうのですが、「お勧めできる本の特徴」として自分なりに考えてみたいと思います*1。

なお最初に示した、表現の自由を侵害しているポストについては、本記事が出て皆さんの目にある程度触れてから、ポスト自体を消去したいと思います。本記事で謝罪したとはいえ、私が発言したという事実は変わりませんので、消去後はポストのスクショを本記事に載せ続けたいと思います。

お勧め度合いの違い

本記事におけるお勧め度合いの違いについて簡単にまとめたものが次のようなものになります。

  • 共通してお勧めできる本…共通して本当にお勧めできる本
  • 個人的にはお勧めできる本…人によっては考え方が違うかもしれないけど、この本で理解しても後々の苦労にはならないので、私だったらお勧めする本

今回の対象について

今回は「初学者に本をお勧めするとしたら…」という前提で書いています。

また、私の得意分野であるソフトウェアテストの本を想定して書いています。

共通してお勧めできる本の特徴1…参考文献が充実している/しっかりと明記してある

参考文献の充実度は重要な要素です。独自の考えを突き進んでいることが少なく、また考え方が違うと読者が感じても、すぐに原典に当たることができます。

ソフトウェアテストの本ならば、ISTQB（JSTQB）のシラバス、ISO/IEC/IEEE 29119、IVECのシラバスなどが参考文献として載っていて良いはずです。これらの情報を避けて執筆する方が難しいです。

例外：古典書

今回の件で、以下のようなポストも貰いました。

古典書（昔に刊行された本）は例外（参考文献が多くなかったとしてもお勧めできる可能性が高い本）だと思っています。なぜならば、仮に参考文献の記載が少なかったとしても、そもそも執筆時に参考にできる情報がなく、自らの経験による部分が大きいからです。ISTQB（JSTQB）のシラバスでは、Myersの『ソフトウェア・テストの技法』を参考文献として挙げているぐらいです。Myersの『ソフトウェア・テストの技法』自体は「初学者にお勧めする本」としては難しいかもしれないですが、良い本だと個人的には思っています。

共通してお勧めできる本の特徴2…問い合わせをすると誠実な対応を貰える

本を書き上げる上で、ミスが発生するのは当然です。そのようなミスについて指摘があった場合に、誠実に対応していただける本はお勧めです。正誤表を載せる等の対応に繋がり、間違った内容が極力広まらなくなります。このように対応してくれる本はぜひお勧めしたいです。

「どうして共通してお勧めできる本の特徴なのか？」と思われるかもしれません。過去の経験上、問い合わせの対応によって劇的に変わった例を知っているので、「共通してお勧めできる本の特徴」に挙げさせてもらいました。

個人的にはお勧めできる本の特徴1…一般的に知られている考え方や呼び方での説明になっている

先ほど書いた「ISTQB（JSTQB）のシラバス」「ISO/IEC/IEEE 29119」「IVECのシラバス」で広く知られている考え方で説明している本はお勧めできます。

本によっては、広く知られた考え方とは違う、独自の考え方や呼び方で書かれている本もあります。それらが「初学者が1冊目に読む本」としては読みやすく感じるかもしれません。しかし、そこからさらに別の本で勉強しようとすると、「他のどの本も考え方や呼び方が異なっているため、1冊目の本だけが頼りになる」もしくは「2冊目以降の本を読むために結局学び直す」ということになります。呼び方が異なっている場合は、「1冊目の本ではXXXと書いてあったこの用語は、2冊目以降の本ではYYYと書いているから…」とマッピング表を作ることになります。

そのため、一般的に広く知られている考え方・呼び方で説明している本をお勧めしています。

独自の考え方や呼び方を否定するつもりはない

もちろん、独自の考え方や呼び方自体を否定するつもりはありません。ある程度学習して、広く知られた考え方を学んだ人が読む分には有益だと思っています。しかし、今回は「初学者に本をお勧めするとしたら…」という前提で書いているため、そのような初学者に対してだと独自の考え方や呼び方ではなく、一般的に知られている考え方や呼び方での説明になっている本をお勧めするかなと思います。

個人的にはお勧めできる本の特徴2…一般的に知られている用語を用いて、独自の解釈をしているが、どこからが独自の解釈なのか分かりやすくなっている

よく知られている用語を用いていても、途中で独自の解釈が入ってくる場合があります。その際に、独自の解釈であると分かるような記述がある本は丁寧で、お勧めできる本だと思っています。

もちろん、著者が独自の解釈として捉えていない可能性があります。その場合は、「共通してお勧めできる本の特徴2…問い合わせをすると誠実な対応を貰える」と重なることで、後々修正が入ることができます。

個人的にはお勧めできる本の特徴3…レビュアーが多い/多様である

レビュアーが多いと、無意識に独自の解釈を進めたり、考え方が間違っている場合にストップがかかります。

レビュアーについては著者名に記載されないため、謝辞があるか確認すると良いでしょう。

また、複数の会社の人からレビュアーが入っているか確認すると良いと思います。ソフトウェアテストという分野においては、コンテキストが違うことがかなり多いため、レビュアーが全員同じ会社の人の場合、その時点で偏ったコンテキストで本が書かれている可能性があります。

私もお勧めできない本の執筆者になる可能性がある

途中でも書いたように、著者本人は無意識に書いているが実は参考文献があったり独自の解釈をしている可能性は大いにあります。私自身も何冊かの本を翻訳したり執筆したりしていますが、既にそのような事態になっているかもしれません。

そんな時に助けになるのが、周りの方からのレビューだったり、出版後の読者からの指摘だったりします。

例えば、「シフトレフトなテスト活動」については、最初はうまく区別せずに発表していた自覚があります。井芹さんは、その部分を整理して『Software Design 2024年2月号』に記事を寄稿してくださりました。

本当にありがたかったですし、これをもとに、以前の私の記載内容や発表資料を訂正できています。

また今回の件についても、末村さんが声を挙げてくれたからこそ私自身も落ち度に気付くことができました。こういった指摘をくださる方が身近にいてくれて本当に良かったなと思っています*2。改めてありがとうございました。

私も翻訳本を書いたり、発表資料を作成する立場です。こういった周りの人の助けを借りつつ、今後も「お勧めしたい」と思ってもらえるように、私自身、これからも精進していきたいです。

おわりに　〜お勧めする本は具体的には何なのか？〜

ここまでは、お勧めする本の特徴を記載してきました。

「それじゃあ、具体的には何がお勧めの本なの？」という質問ですが、これは冒頭のXのポストにも挙げたように、kazuさんの資料の中でうまくまとめてくれています！

デブサミ2023 / テストを学びたい開発者のためのソフトウェアテスト読書マップ / Software Testing Reading Map for Developersより

こちらに載っている本は、私個人としてもお勧めの本が多いので、ぜひ参考にしてください！

*1:じゃここんぶさんからは、「お勧めできない本の特徴について公開してほしい」と質問が入ったのですが、表現の自由を守りつつ、かつポジティブな形で残したいと考えたため、お勧めできる本の特徴の記載にしています

*2:末村さんとは以前から親交があり、私が末村さんの執筆本のレビュアーになったりしています。それぐらいの間柄でありながら、このような指摘を貰えて本当にありがたかったですし、それによって裸の王様状態だった私を救ってくれたと思っています

適切な形でのテストシナリオの書き方やBDD/ATDDを学ぶ上で最適な書籍『The BDD Books - Formulation』を翻訳して出版しました！ #bddbooks

BDD 翻訳 技術

2021年5月に出版された『The BDD Books - Formulation』日本語に翻訳してLeanpubにて出版しました！

表紙はこんな感じ。

書籍紹介および購入はこちらから。

leanpub.com

原著はこちら。

なお、本書籍はThe BDD Booksシリーズの2冊目となります。シリーズ1冊目『The BDD Books - Discovery』については日本語版を公開済みです。詳しくはこちらをご覧ください。

nihonbuson.hatenadiary.jp

本記事では、この本がどんな内容なのかを書きます。

目次

どんな想いで翻訳・出版に至ったか

本書の「Daniel Terhorst-North*1による序文」と「訳者まえがき」に書いた内容を一部抜粋して紹介します。

Daniel Terhorst-North による序文（一部抜粋）

議論の余地はありますが、定式化(Formulation)は BDD の分野の中で最も理解されていません。コラボレーションと共通理解については多くのことが書かれていますし、ほとんどの人が自動化から BDD を始めます。私の考えでは、定式化こそ BDD の真の力と影響を与える場所です。

訳者まえがき（一部抜粋）

本書籍は3冊ある「The BDD Books」シリーズの2冊目です。

（中略）

1冊目では「business」という単語が多く登場しており、ビジネスチームと協調して作り上げていくことの大切さを語っていました。

本書籍でも、引き続き「business」という単語が多く登場しますが、意味合いが少し異なります。ビジネスチームのメンバーも読みやすいシナリオの作成に重点を置いています。「readable」という単語が多く登場しており、「ビジネスチームが読みやすい形にすることが目標」と何度も書いています。つまり、「リーダブルコード」ならぬ「リーダブルシナリオ」を目指しているのです。

本書籍を読み、実践することにより、「書いてあるシナリオが読みにくい」「どうして必要なのか理解できないが、存在しているので一応テストをしている」という漠然とした不満を解消できるかもしれません。

コードの実装に関する書籍は数あれど、実装の前提となるシナリオをどこまで具体化して書くのかについて述べている書籍はあまりありません。

Daniel Terhorst-North による序文および訳者まえがきの補足

BDDに対する誤解

現在、誤解があるまま、BDDという考え方が広がっているように感じています。

Cucumberコミュニティ（Given/When/Thenの記述方式であるGherkin記法をメンテナンスしているコミュニティでもあります）が書いた記事「Behaviour-Driven Development」では、BDDを以下の3つのプロセスに分けて表現しています。

よく「BDD」というと、「Given/When/Then を用いて自動テストを書くこと」とイメージされることが多いです。場合によっては、「BDDで書く」と表現している例も見たことがあります。しかし、それは上の図の「Formulation」の一部と「Automation」を指し示しているに過ぎません。

そうではなく、自動テストを書く以前に行うべきことが多々あることを本書籍およびBDDの推進者たちは訴え続けています。

そんなBDDにおいて一番重要なのが「Discovery」であり、BDDで一番理解されていない部分が「Formulation」です。

Formulationとは何か

Formulation（定式化）とは、Discoveryで示した考えるべき内容を、どのようにテストシナリオに落とし込めば良いかを考えるプロセスです。この時、自動化している形になっていることが必須ではありません。

それでは、具体的にどのようなことをやっていくのでしょうか？

本書籍では、以下のテストシナリオから始まります。

Scenario: 注文テスト
Given 時刻は"11:00"です
Given お客様は"http://test.wimp.com/"にアクセスします
And 彼らは"SearchText"に"マルゲリータ"と入力します
When 彼らは"検索"を押します
Then "SearchResults"内に"マルゲリータ"が表示されるはずです
And 彼らは"サイズ"から"中"を選択します
When 彼らは"買い物カゴに追加"を押します
Then "BasketItemCount"の中に"1品"と表示されるべきです。
When 彼らは"チェックアウト"をクリックします
And 彼らは"DeliveryInstructions"から"店頭受け取り"を選択します
And 彼らは"PaymentOption"から"受け取り時の支払い"を選択します
And 彼らは"OrderName"に"Marvin"と入力します
And 彼らは"ContactPhoneNumber"に"12334456"と入力します
When 彼らは"注文を送信"を押します
Then "SuccessMessage"が表示されるはずです
Then "ErrorMessage"は表示されないはずです
And "SuccessMessage"内に"ご注文ありがとうございます! "と表示されるはずです
And "CollectionTime"内に"11:20"が表示されるはずです
And "TotalAmount"内に"$14"が表示されるはずです

これはどんなテストを意図したものなのでしょうか。そんな疑問を明らかにしていきながら、このテストシナリオを改善していきます。

BDDに限らず、テストシナリオの改善にも役立つ

本書籍は、BDDやATDDを導入していない読者にとっても、テストシナリオの改善に向けて大いに役立つ書籍です。

以前に、「テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則」という翻訳記事を公開しました。

nihonbuson.hatenadiary.jp

本書籍では、このBRIEFの原則を、具体的にどのように適用してテストシナリオを改善していけば良いか、具体的に書かれています。

なので例えば、シナリオテストとなる手動テストでのテスト手順書を書くにあたっても本書籍は大いに役立つでしょう。

謝辞

本書籍の日本語翻訳版を公開するにあたり、今回も下記のたくさんの方々にサポートいただきました。本当にありがとうございました！

  • こま(@koma_koma_d)さん
  • 伊藤由貴(@yoshikiito)さん
  • 浅黄友隆(@tom_asa)さん
  • Tomoya Suzuki(@anchor_cable)さん
  • てらひで(@terahide27)さん
  • 山口鉄平(@teyamagu)さん

さいごに

繰り返しとなりますが、本書籍はテストシナリオの改善にも活用できるおすすめの本です。

内容も一部会話形式になっており、非常に分かりやすいと思いますので、興味のある方はぜひご購入の検討をお願いします！

*1:ちなみにDaniel Terhorst-Northは、BDDという言葉の提唱者です

「リバースモデリングを行ってテスト設計する」は、単純にリバースしてないと気付いた話 #WACATE

はじめに

先日、WACATE 2024 夏というワークショップを開催しました。私はWACATE実行委員長として運営に携わり、準備を行ってきました。

WACATE 2024 夏の開催内容およびWACATEという団体について詳しくは、以下のページをご覧ください。

wacate.jp

WACATE 2024 夏では「テストケースには、必ず作った人の意図が存在する」というサブタイトルを付け、テスト実装からテスト分析へとテストプロセスをさかのぼる（＝リバースする）過程を体験してもらいました。

ワークショップを作成するにあたり、テストプロセスについて今までより深く考えられた（気がする）ので、本記事で言語化して書き残しておきたいと思います。

前提知識：テストプロセスとは何か

ISTQB（ソフトウェアテスト技術者資格認定）では以下のようにテストプロセスを定義しています。

ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03を参考に作成

今まで「テスト実行」と「テスト実行のための準備」ぐらいにしか分けていなかったテストのプロセスを、JSTQBではいくつものプロセスに分けて表現しています。

その中でも、「テスト分析」「テスト設計」「テスト実装」「テスト実行」は、単一のテスト対象に対してでも活用できる部分だと思っています。*1

この4つのテストプロセスのうち、テスト実行を除いた3つに着目すると、以下のようなインプット/アウトプットで作成できるでしょう。

各テストプロセスとそのインプット/アウトプットの例

本記事では、上の画像で表したテストプロセスとインプット/アウトプットを用いて説明します*2。

テストプロセスをリバースするとはどういうことか

今回のWACATE 2024 夏では、前提知識で書いたテストプロセスのうち、「テスト手順書（テスト実装の成果物）」しか手元にない場合に、テスト設計やテスト分析にさかのぼる（＝リバースする）ことを参加者に体験してもらおうと考えました。

この時、どのようにリバースすれば良いのでしょうか？単純に逆の順番で行えばできるのでしょうか？

逆順に行えばできる？

上の図の赤矢印のように辿ると、「テスト手順書からテスト実装を行うことで、テスト設計成果物を作成できる」と読み取れます。果たして本当にそんなことが可能なのでしょうか？私は違うと思っています。

少なくとも、「テスト手順書をインプットとしてテスト設計を再度行い、テスト設計成果物を作成する」ということになると思います。

テスト手順書（テスト実装成果物）からテスト設計成果物をリバースする流れ

「テスト設計」を細分化する

「テスト設計を行う」という部分をもっときちんと考えるため、テスト設計というプロセスをさらに細分化することを試みます。すると以下のように考えることができました。

テスト設計のプロセスの細分化

上図のうち青囲み部分が、元々「テスト設計」と呼んでいた部分です。今回は「テスト設計技法選択」「テストモデリング」「カバレッジアイテムの導出」という3つに細分化できました。

テストモデリングとは何か？

テストモデリングとは、テスト設計技法などを用いて、テストの視点で図式化、視覚化する行為のことです。詳しくは、今回の WACATE 2024 夏での発表資料をご覧ください。

speakerdeck.com

カバレッジアイテムとは何か？

JSTQBの用語集によると、以下のように書かれています。

テスト技法を使用して、一つ以上のテスト条件から導出される属性または属性の組み合わせ。テスト実行の完全性を測定するために使用する

例えば、同値分割法におけるカバレッジアイテムは代表値になります。境界値分析におけるカバレッジアイテムは境界値になります。デシジョンテーブルにおけるカバレッジアイテムは、出てきたパターンになるでしょう*3。

各テスト技法とカバレッジアイテムの関係性

上図の赤丸の部分がカバレッジアイテムになります。

そして、出てきたカバレッジアイテムを元にテスト手順書を作成していると考えることができます。例えば、同値分割というテストモデリングによって同値パーティションを作成し、それを元に境界値分析を行うことで境界値を見つけ出し、その境界値を用いてのテスト実装を行うことでテスト手順書のケース1つが作成できると考えられます。

改めて、テストプロセスのリバースを考える

テスト設計というプロセスを細分化したうえで、改めてテストプロセスのリバースを考えます。すると、テスト手順書からカバレッジアイテムを導き出すのではなく、それ以前の「テスト設計技法の選択」や「テストモデリング」から行っていると思われます。

テスト手順書（テスト実装成果物）からカバレッジアイテムをリバースする流れ

つまり直前のプロセスに戻れば良いのではなく、結局はテスト設計のプロセスの初めから行っているのです。

しかし、元々のテストプロセスには（当然ながら）「テスト手順書」と「テスト設計技法選択」を結ぶ線は存在しません。つまり、ここはリバースモデリングの実施者が自ら想定しなくてはいけない部分なのです。ここは完全に想像の世界になってしまうので、ましてや前任者といった自分ではない他人が作った場合、元々の想定と違うテストモデルができる可能性が大いにある部分です。これこそがリバースモデリングする上で大変な部分でしょう。

おわりに：そもそもテストプロセスをリバースするのはアンチパターン

本記事では、テスト実装の成果物であるテスト手順書からテスト設計の成果物をリバースして作る際のプロセスについて書きました。

しかし、そもそもリバースしてテスト設計の成果物を作ること自体がアンチパターンだと思います*4。

テスト実装の成果物以外は何もないところからテスト設計を想定しろということ自体が無理難題です。WACATE 2024 夏では、リバースすること自体の難しさを参加者に体験してもらいました。その経験を反面教師にして、きちんとテストプロセスに沿った成果物を作成することが大事だと理解してもらえたのではないかと思います。

なお、テストプロセスに沿った成果物について、個人的には「テスト分析」の成果物を残しておくことをオススメしています。一般的に、成果物の作成されやすさは、

テスト実装成果物（テスト手順書など）＞テスト設計成果物＞テスト分析成果物（テスト条件）

の順ですが、個人的には

テスト分析成果物（テスト条件）＞テスト設計成果物＞テスト実装成果物（テスト手順書など）

の順で残しておくべきだと思っています。なぜならば、後追いでテスト作成の経緯を追うときに、同じ思考順にできる（リバースして考えることがなくなる）ため、再現性のあるテストに向かいやすいと思っているからです*5。

本記事を通じて、テストプロセスをきちんと理解することが少しでも大切だと感じてもらえれば幸いです。

参考：テストプロセスを用いて、テストケース作成の思考を整理しよう(WACATE 2022 冬の発表資料)

speakerdeck.com

*1:逆に、「テスト計画」「テストのモニタリングとコントロール」「テスト完了」は、複数のテストを行う際に効果をより発揮できるプロセスだと感じています

*2:なお、この中で「テスト条件」が馴染みのない言葉かもしれません。本記事上では「何をテストしたいのかを書き記したもの」ぐらいに捉えておいてください。詳しく知りたい方は、JSTQB FLのシラバスをご覧ください。

*3:「カバレッジ」という単語から「テストコードを実行した際に測定できるコードカバレッジ」をイメージされる方もいると思います。コードカバレッジはコード1行1行がカバレッジアイテムとみなすことができるでしょう。

*4:アンチパターンである旨は、WACATE 2024 夏の中でもお伝えしました

*5:特に、テスト設計を学んでいればいるほど、再現率は高くなると思います

QAエンジニアから見た『データモデリングでドメインを駆動する』書評

技術

はじめに

本記事は、今年発売された書籍『データモデリングでドメインを駆動する――分散／疎結合な基幹系システムに向けて』を読んだ感想と、QAエンジニアである私*1が日々の業務で役立ちそう（既に役立った）部分を紹介します。今のところ、本書籍は2024年のベストバイな気がします。

gihyo.jp

本記事で一番伝えたいこと

  • データモデリングについての考えが深まるぞ
  • 開発者が読むともっと役立てることができると思うぞ
  • QAエンジニアである私が読んでも役立つぞ

読み始めてすぐに「良い買い物だった」と思って思わずポストしている様子

目次

本書籍で良かったこと：データモデリングをするにあたっての整理と用語の提案がすごい

本書籍では、データモデリングをするにあたっての思考の整理が素晴らしかったです。また、整理するにあたり、筆者の考えを元にした様々な用語の提案がされています。その提案は具体例を添えて語っており非常に分かりやすく、かつ納得のいく提案に感じました。本記事では、特に響いた部分を記載します。

SoAとSoMという整理

一般的に、「SoE（Systems of Engagement、関わり合いのシステム）」と「SoR（Systems of Record、記録のシステム）」という区分がよく聞かれます。SoEとSoRの詳細な説明は他記事に任せるとして（ググれば出てきます）、本書籍ではSoRをさらに「SoA（Systems of Activities、活動のシステム）」と「SoM（Systems of Management、経営管理のシステム）」に分けて整理しています。このSoAとSoMという考え方が、書籍全体の核となっています。

書籍の中で、「なぜSoRをSoAとSoMに分けて考えるべきなのか」に明確に答えています。書籍内に書かれている分かりやすい題材を元に、私は「SoAとSoMは、関心を持っている対象も、データとしての表現の仕方も異なっている」ということを理解できました。

詳しくは書籍を読んでもらえればと思います。書籍全体で語っているものの、第4章と第5章あたりを読むと特に理解できるかもしれません。

「残」という概念

筆者は、書籍の中で「残」という概念を提案しています。書籍を読んで理解した範囲内で、「残」について説明してみたいと思います。以下で載せている例は、書籍内の表現ではなく、私が勝手に例示している点にご注意ください。

例えば、ECサイトで何か商品を購入した場合を考えてみます。この時、クレジットカード会社から入金がされた時点でECサイトの運営会社においてはお金について作業が残っていません。これを「お金の残が無い」と表現します*2。一方で、購入が発生した時点ではまた商品のお届けがされておらず、商品の残作業があります。対面の販売のようにお金と商品がリアルタイムで交換されているわけではないからです。この時、「注文商品については残がまだある」と表現しています。

このように、1つの注文を見ても、商品にはタイムラグが生じます。本書籍では、これを「残」という概念で表現しています。また、注文という部分以外にも目を向けると、在庫管理についても「残」が発生するかもしれません*3。この「残」の管理をする（「残」が発生してから解消されるまでを管理する）ために、システムを導入しているといえるのです。

私の拙い説明ではイメージしづらいかもしれません。ただ個人的には、書籍を読んで、この「残」という概念は非常に腹落ちしました。書籍では私の数倍うまく説明していますので、詳しくは書籍を読んでください。第4章あたりに書いてあります。

データベース設計とは違う「データモデリング」という考え方

一般的に「どのようにデータを扱うか」と考えると、データベース設計に注目しがちです。しかし、本書籍では、データベース設計とは別の「データモデリング」という考え方を丁寧に説明しています。あくまでもデータモデリングは帳簿のデザインであると解説しています。それにより、データベース設計で発生する技術的関心事と分離を行うこともできます。

しかし同時に、本書籍では「データベース設計が不要である」とは主張していません。どのように使い分けて行なっていくのかについても本書籍では丁寧に説明していますので、詳しくは書籍を読んでください。第3章や第11章あたりと第8章の一部に書いてあります。

QAエンジニアとして、業務に役立てそうなこと

私はQAエンジニアです。開発者とは違い、システム自体を開発していません。そんな私にとって、「どのように開発者が設計をしているのか」という部分以外に、本書籍の内容が役立てる（応用できる）部分があるように感じました。それを述べていきます。

「業務プロセスは業務機能を横断する」をシステムテストに応用する

「2.2 活動のシステム(SoA)は現場活動を支える」の中では以下のように解説しています。

業務機能の分割は「残」に基づく

業務プロセスは業務機能を横断する

これをテストレベルに当てはめると、業務プロセスのテストがシステムテストレベルに当てはまるように感じました。業務機能の分割を行い、テストをした上で、業務プロセスのテストを行うのは理にかなっていそうな気がしました。特に図2-2-2のような表現は勉強になりました。

書籍内の図2-2-2

データモデリング作成時の思考とテスト要求分析時の思考は似ている

「3.2 ユーザーインタフェース設計だけでは帳簿をデザインできない」の中で以下のように述べています。

画面や帳簿のデザインは、業務の流れ（ユースケース）に依存します。一方で、帳簿の構造は、基本的には業務の流れに依存しないようにデザインするほうが良いのです。

画面や帳票の設計は帳簿デザインではないと述べましたが、逆に帳簿のデザイン--データモデリング--に際して、画面や帳簿のスケッチを利用することは、有用ですし、多くの場合、極めて重要でさえあります。

これは私がテスト要求分析を行う時の思考に似ていると感じました。私が行なっているテスト要求分析の考え方については以下をご覧ください。

speakerdeck.com

イケてない部分

ここまで良かったことを書きましたが、イケてないと感じた部分も書いておきます。ただしどれも技術的におかしいことを書いているわけではなく、言いたいことをうまく伝えきれてないなーと感じた部分です。

「帳簿」という言葉から受け取るイメージに乖離がある

私が商業に詳しくないが故かもしれませんが、私の中では「帳簿＝会計帳簿」というイメージが強く、「会計帳簿以外にも帳簿の概念がある」ということを理解するまで時間がかかりました。

「データモデリング」と「データベース設計」の区別が付いていない読者へのフォローが少ない

「データモデリングでドメインを駆動する」という書籍名だけだと、「データベース設計の本かな？」と想像してしまいました。データベース設計の本だと感じて手に取らない人が出てきたら勿体ないと感じました。

データベース設計とは違うということは「はじめに」で1行だけ述べており、その後は第3章まで読まないと理解できませんでした。例えば「1.2 データモデリングはなぜ必要なのか」でフォローしても良いように感じました。

第5章の説明が難解

第5章「経営管理のシステム(SoM)」が他の章に比べて少し読みづらかったです。

この点については筆者も認識している点なので、ここでは詳しく言及しません。

おわりに

最後に「イケてない部分」を書きましたが、総じて非常に良い本だと感じました。今のところ、2024年のベストバイな気がします。

QAエンジニアにとっても、実装から目を離し、業務から見つめ直せる点で、有用だと思います。

ちなみに、5/28に本書籍の読書感想会のイベントがあるようなので、気になる方はこちらもぜひご参加くださいませ！*4

kichijojipm.connpass.com

*1:厳密にいうと、役立ったのはテストエンジニアリングの部分

*2:エンドユーザーからすると、クレジットカードの引き落としが発生するまではお金の残があるかもしれませんが

*3:出荷指示から出荷までの間には「残」があるでしょうし、製造指示から製造完了までも「残」があるでしょう

*4:私は発表者ではないけど