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

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

先日、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:私は発表者ではないけど

Cucumberコミュニティの消滅の危機はGherkin（Given / When / Then）記法の消滅の危機でもある

BDD 発表 技術

はじめに

先日、Nextbeat Tech Bar：第一回ソフトウェアテストについて考える会にて、「BDD(Cucumber)コミュニティが無料提供しているコンテンツの紹介と現在起きている危機」というタイトルの発表をしました。

発表資料は以下です。

speakerdeck.com

本記事では、発表時にはうまく伝え切れなかった部分を補足として書くことを目的としています。特に、Cucumberコミュニティ消滅の危機は、Gherkin（Given / When / Then）記法の消滅の危機にも繋がっているので、Cucumberを使っていない人にも影響があるということを理解していただきたいです。

目次

本記事で言いたいことを3行で

  • Gherkin記法はCucumberコミュニティがメンテナンスしている
  • Cucumberコミュニティが資金難で消滅してしまうと、Gherkin記法もメンテナンスされなくなる
  • Gherkin記法の標準がなくなってしまう恐れがある

Gherkin記法とは何か

Gherkin記法とは、主にGiven / When / Thenで書かれた、シナリオ記述フォーマットの1つです。

例えば、以下のように記述します。

Feature: 自動販売機

    Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る
        Given 自動販売機がある
        When 550 円を入れる
        And 120 円の "コーラ" を選択する
        Then "コーラ" が出てくる
        And 430 円が出てくる

Cucumberを使っていなかったとしても、Given / When / Thenが書いたシナリオを使っている人はいるのではないでしょうか？

Gherkin記法はCucumberコミュニティがメンテナンスしている

Gherkin記法は、Cucumberコミュニティの配下にある以下のリポジトリ上でメンテナンスしています。

github.com

このリポジトリ上では、記述ルールの定義や、各プログラミング言語の対応や、各自然言語の対応をしています。

各プログラミング言語ごとにディレクトリを分けて管理している

gherkin-languages.json内で、各自然言語でも使えるようにしている

Cucumberコミュニティが資金難で消滅してしまうと、Gherkin記法もメンテナンスされなくなる

今回の発表でも示したとおり、現在Cucumberコミュニティは資金難に陥っています。

もしもコミュニティが消滅してしまうと、Cucumberというツールのメンテナンス以外にも、BDDの学習コンテンツ*1のメンテナンスや、Gherkin記法のメンテナンスがされなくなる恐れがあります。

Gherkin記法の標準がなくなってしまう恐れがある

実際に、Cucumberコミュニティが消滅する時には、きっと他コミュニテイがGherkinのリポジトリのメンテナンスを引き受けるでしょう。

しかしメンテナンスを引き受けることが叶わなくなった場合、Gherkin記法の標準が無くなってしまいます。

そうなると、以下のようなことが発生するでしょう。

  • 今までGherkin記法を用いていた各サービスが独自の使い方をするようになる
  • Gherkin記法に関する更新を入れたい場合には、Gherkin記法を用いたサービス全てに変更を入れる必要が出てくる
    • 例）Gherkin記法の用語の日本語訳を追加したい
  • とあるGherkin記法を用いたサービスから、別のGherkin記法を用いたサービスへ移行しようとすると、うまく動かなくなる部分が出てくる

このように、Cucumberコミュニティの存続の危機は、Gherkin記法の混乱にもつながる可能性があるのです。

おわりに

本記事では、Cucumberコミュニティの存続の危機が、Cucumberというツールのみならず、Gherkin記法にも影響するという話を書きました。

また、CucumberコミュニティはGherkin記法以外にも、BDDの発展や正しい理解にも一役買っています。なので、そういう面でもコミュニティ消滅を避けられると良いなと思い、今回の発表および本記事を書きました。

ここまでの内容を見て、少しでも貢献したいという方はぜひ寄付をお願いします。単発の寄付でもOKです。以下のページで寄付を募っていますのでよろしくお願いします！

opencollective.com

*1:Cucumberコミュニティは無料のBDDの教育コンテンツを本当に充実させています！例えばCucumber Schoolはその1つです。

school.cucumber.io

Googleスライドで紙芝居的に強調する場所を示すコツ

勉強会 発表 Developers Summit

はじめに

先日、Developers Summitで講演してきました*1。

event.shoeisha.jp

発表スライドはこちら

speakerdeck.com

このスライドを作成する際に使った、紙芝居的に強調する方法をご紹介します。完成形はこんな感じです。発表スライドのp9とp10が該当します。

なお、今回の元画像はryuzeeさんのプロダクトマネジメントの”罠”を回避しよう のスライドから拝借しています。

作り方

1.強調する前の画像を作成する。

2.画像をクリップボードにコピーする

3.半透明のオブジェクトを作成する

Googleスライドでは、透明度も含めてカラーコードが指定できます。私の場合、黒背景の半透明の場合（今回の場合）は「#000000bf」を、白背景の半透明の場合は「#ffffffbf」を指定しています。

黒背景の半透明のオブジェクトを画像の上に貼った状態

4.手順2でコピーした画像を貼り付ける

5.手順4で貼り付けた画像と手順1の画像の位置を揃える（ガイドが表示されるので、簡単に揃えられるはずです）

6.【今回のポイント！】画像を選択し、メニューバーにある「画像を切り抜く」のアイコンをクリックする

「画像を切り抜く」のアイコン

7.【今回のポイント！】強調したい場所のみに範囲を狭める

8.範囲を狭めたオブジェクトの外枠に色を付ける

完成！

おわりに

今回は紙芝居的に強調する方法をご紹介しました。

今回の場合以外にも、「画像を切り抜く」は様々な装飾に活用できますので、ぜひお試しあれ！

*1:ちなみに、今回のDevelopers Summitではもう一つセッションを持っていました。そちらについては別記事をあげていますので、気になる方はそちらもどうぞ！

nihonbuson.hatenadiary.jp

Developers Summitの新人研修セッションの中で「新人研修マニフェスト」を発表しました #devsumi

勉強会 技術 発表 Developers Summit

はじめに

先日、Developers Summitで、及部さん、やっとむさんと一緒に新人研修に関するパネルセッションを行いました*1。

event.shoeisha.jp

その冒頭で、新人研修マニフェストを発表したので、ここでも紹介します。

新人研修マニフェスト

新人研修マニフェスト

テキストにもしておきます。

  • 新人研修の充実よりもエンジニア人生の充実を
  • 包括的なカリキュラムよりも学び方を学ぶことを
  • 教えるよりも一緒に学ぶ関係性を
  • 計画に従うことよりもリアルな現場体験を

価値とする。
左記のことがらに価値があることを認めつつ、わたしたちは右記のことがらにより価値をおいています。

マニフェスト誕生の経緯

このマニフェストは、今回の新人研修セッションを行うにあたり、事前の打ち合わせの内容をもとに及部さんが作成したものです*2。

当日にパネルディスカッションをやっていても、各登壇者がこのマニフェストに書いた内容を大切にして新人研修を行っているなと改めて感じられて*3、「及部さんの言語力すげー」となってました。

おわりに

今回は登壇者3人が共通して大事に思っていることをもとに新人研修マニフェストを作成してみました。

もしも、「こんなことも大事なんじゃね？」とか意見がありましたら、フィードバックくださいませ！

追記

既に頂いてたコメントに対しての私の考えを書いておきます。

調べ方を教えるのも重要なんじゃない？

それも含めて「リアルな現場体験」の中に包含するかもしれないです。

いくら特定分野の調べ方を教えたところで、別分野では調べ方が分からなければあまり意味がないかもしれません。「○○は社内用語だよ」と伝えてもキリがないです。

それよりかは、リアルな現場を提供した上で、それを調べるという体験がやはり重要かなと考えています。そこで、うまく調べられなかったという経験も大事かなと思っています。「こうやって調べれば良いんだよ」という、予めの「計画に従うこと」を目指していない気がします。

テストとか品質に対してこのマニフェストは難しいんじゃない？

はい、難しいと思います。kawagutiさんが似たようなことを仰ってた。

なので、「教える」となることが多い中でも、どのようにすればマニフェストの内容に近づけるのかを考えるのが腕の見せ所ですね。

*1:今回のDevelopers Summitでは、私個人の公募セッションもありましたが、そちらについては後日記事を書く予定です。

event.shoeisha.jp

*2:なんか、私がブログ記事でこの新人研修マニフェストを公開しちゃってますが、©︎TAKAKING22として良いと思うぐらいです

*3:実際、聴講者もそのように感じていたようです。