2024年の活動をふりかえる

発表 勉強会 ふりかえり

年の瀬です。

昨年末に同様の記事「2023年の活動をふりかえる」を出して、良いふりかえりになったなーと感じたので、今年もふりかえってみたいと思います。

目次

本業

昨年5月から引き続き株式会社10Xで働いています。

10x.co.jp

品質管理チームのメンバーとして手を動かしている一方、今年の途中からエンジニアリングマネージャーも兼務するようになりました。

10Xでやったことについて詳しくは、先日記事を書いたのでそちらをご覧ください。

nihonbuson.hatenadiary.jp

副業

いくつか副業をさせてもらってます。その中で、公開できるものを記載しておきます。

Graat様でのコンサル業

昨年時点では公開できなかったのですが、実は前々からGraat様でもお世話になっていました。Graat様、電通大のにしさん、私で共同研究をしていました。

主にAgileにおけるテスト活動について議論していました。成果については今年のSQiPシンポジウムで発表がありました。

品質保証活動をアジャイルプロセスに溶け込ませるためのテスト活動の再構築と、それを支えるアジャイル・エンジニアリングの活用

MonotaRO様でのコンサル業

今年からMonotaRO様でテストや品質の相談に乗っていました。

テストプロセスやテスト設計に関する勉強会を開いたり、日々の業務の壁打ち相手になったりしていました。

Aidemy Business講師

株式会社アイデミー様のオンラインDXラーニング「Aidemy Business」の中で、ソフトウェアテストに関するオンライン学習コンテンツを提供しました。

aidemy.co.jp

CodeZine Academy講師

一昨年の秋から定期的に、翔泳社様主催の「CodeZine Academy」というセミナーで講師をしています。

event.shoeisha.jp

今年はオフライン開催も行いました。

ありがたいことに、毎回多くの方にご参加いただいており、3,4ヶ月に1回のペースで開催できてます。次回の開催も計画中です。

ASTER標準テキストを用いた自治体主体のセミナーの講師

自治体主体のセミナーでも講師を務めています。千葉で開催しているセミナーの担当です。こちらも3年目になります。

www.aster.or.jp

年2回開催しておりますが、こちらも毎回満席近くのご応募があります。

社内講演

その他、単発での社内講演もいくつか受け持ちました。

運営

コミュニティ活動を中心とした運営をしています。

WACATE

ソフトウェアテストの合宿型ワークショップ形式勉強会であるWACATEに実行委員長として携わっています。

毎年6月と12月に開催しています。最近はありがたいことに実行委員の数も増えまして、よりチーム運営を意識しながら開催しております。

wacate.jp

レビュー研究会

レビューの体系化を目指して、1ヶ月に1回程度集まっています。もう少しで良い感じに言語化できそうなところまで来ています。

www.aster.or.jp

Developers Summit コンテンツ委員

翔泳社様主催のDevelopers Summit（通称：デブサミ）で、次回の2025年からコンテンツ委員を拝命することになりました。

主に、公募セッションの選定や、招待セッションの企画などで関わり始めました。

執筆

いくつか執筆をしました。

雑誌『Software Design』寄稿

技術評論社様が出版している雑誌『Software Design』に2回寄稿しました。

『Software Design2024年2月号』

テスト設計についての記事を寄稿しました。 gihyo.jp

『Software Design総集編【2018～2023】』

冊子自体は過去の発行の総集編ではあるのですが、今回の書き下ろし特集として、生成AIとテストについての記事を寄稿しました。

gihyo.jp

Findy Engineer Lab 寄稿

Findy様が運営しているメディア「Findy Engineer Lab」にて2つ寄稿しました。

高速道路の出口案内のようなQAエンジニアでありたい ─自動テストより前にやるべきことがあると気づいた話

私の今までのキャリアやQAエンジニアとしての考え方についての記事を書きました。 findy-code.io

あなたのキャリアに影響を与えた本は何ですか？ 著名エンジニアの方々に聞いてみた【第四弾】

オススメの書籍についての記事を書きました。 findy-code.io

Agile Journey寄稿

UZABASE様が運営しているメディア「Agile Journey」にて寄稿しました。継続的テストモデルについての解説と、このモデルから見たシフトレフトなテスト活動/シフトライトなテスト活動についての記事を書きました。

agilejourney.uzabase.com

agilejourney.uzabase.com

登壇

いくつか登壇をしました。

依頼を受けて登壇したもの

運営側として登壇したもの

公募して登壇したもの

Podcast

Podcastも少し収録しました。

10X.fm

私が現在所属している株式会社10XのPodcast「10X.fm」の企画「QA部屋」でモデレーターを務めてます。毎回ゲストを招いて、今までの経歴やテストに関する話をしています。

2024年に出したエピソードは以下の通りです。 open.spotify.com

open.spotify.com

open.spotify.com

おわりに 〜今年のまとめと来年の抱負〜

今回は1年間の活動をふりかえってみました。こうやってふりかえってみると、年々社外活動を増やしているなーと感じてます。また、記事の寄稿が非常に多くなったと感じた年でした。

個人事業主としてのサイトb-testing.netでは、過去の講演実績を時系列順にまとめているのですが、だんだん長くなってきてます。 www.b-testing.net

来年も引き続き、依頼いただいたものは極力受けたいと考えてます。ご依頼は以下でお受けしております。

www.b-testing.net

来年に向けては、今年から継続している内容に加えて、まだ公開できない仕事もいくつかいただいているので、もう少し公開できると良いなーと思ってます。

あと、ここまで来ると法人化しといたほうが良いかもと感じている今日この頃です。

それでは2024年、お疲れ様でしたー！

河野大臣（当時）のポストから西暦のテストについて考える

テスト設計 技術

はじめに

本記事はソフトウェアテストの小ネタ Advent Calendar 2024で投稿することを忘れていたが、2024年に起こった出来事なので、今年中に公開しようとした記事となります。

本記事執筆のキッカケ

当時、デジタル大臣だった河野太郎氏がこんなポストをしていました。

このポストから学べることがいくつかあるので、考えてみたいと思います。

目次

学びその1：上の役職の人が声をあげると最優先課題になる可能性がある点

今回の場合は直属の上長では無いですが、デジタル大臣が声をあげた結果、その課題の優先度が最優先となってしまうかもしれません*1。

このような事象は度々発生します。

課題自体は解決できるかもしれませんが、そこにかける工数によって、他の課題解決に割ける時間が減ってしまうことこそが問題です。

学びその2：主観で課題を述べている点

今回のようなUI面での指摘は、主観で述べていることが多いです。その結果、優先順位を付けるのが難しくなる可能性があります*2。

今回の場合、どうすれば良いのか

QAや専門家が今回の点を指摘する場合は、今回の事象のどのような点が問題なのか/どのような部分をテストすべきか言語化するところから始めるべきかもしれません。

テスト条件

「何をテストすべきか」を示すものをJSTQBでは「テスト条件」と呼びます。*3

今回の場合、生年月日の選択肢に対してのテスト条件を考えてみます

現実的な選択肢を提示しているか

この方が述べている通り、最高齢の方（1908年）よりも昔の西暦を選択肢にする必要はないかもしれません。特に日本の場合は戸籍がしっかりしているので、さらに昔の西暦に更新される（最高齢の方が発見される）ことはないでしょう。また仮に発見されたとしても、その選択肢を使うのは1人だけですので、例外的な運用で処理しても良いかもしれません。

利用者のボリュームゾーンあたりを選択肢としているか

この方が述べている通り、利用者のボリュームゾーンあたりから選択肢が始まっているかを考えてみるのも良いかもしれません。

デフォルトの選択肢を空欄にしているか

より多くの利用者が操作しやすいということを考えると、最初から一番多いボリュームゾーンの西暦を選択した状態で始めるのが良いと考えるかもしれません。しかし、空欄にしていないと、選択するという意図をせずとも次に進めてしまうという別のトラブルが考えられます。

必須項目であり、確定申告という公的書類を作成することを考えると、元々の実装通り、デフォルトの選択肢は空欄であることが好ましいように思えます。

おわりに

今回は河野大臣（当時）のポストを元に、確定申告の西暦選択におけるテストについて考えてみました。

今回の事例には直接当てはまらないかもしれませんが、先日行われたWACATE 2024 冬にて、ユーザビリティの作り込み方についてのワークショップがあったため、参考として貼っておきます。特に資料後半の「人間中心設計によるライフサイクル」が参考になるかと思います。

speakerdeck.com

*1:なお、個人的には全く興味を持っておらず見ていないよりは、河野大臣のように見てもらっている方がありがたいと思います。問題はそれが伝え方によって最優先になってしまう点です。

*2:これは「河野大臣の指摘の仕方が良くない！」と伝えたいわけではありません。専門家でもない一般ユーザーが指摘をすること自体は否定されるものではありません。ただし、専門家が同様の指摘の仕方をしていた場合は改善点がありそうな気がしているので、今回話題にしています。

*3:JSTQBではテスト分析の成果物として定義されています。JSTQBの最新版シラバス（ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02）には以下のように書かれています。

テスト分析の作業成果物には、（優先順位を付けた）テスト条件（例えば、受け入れ基準など、4.5.2 項参照）、およびテストベース内の欠陥についての（直接修正しない場合の）欠陥レポートが含まれる。

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という言葉の提唱者です