転職したので、これからの動きを改めて整理してみる（宣伝多め）

転職しました。*1

このツイートだけで、色々と察して労いの言葉を多数いただけるって、よくよく考えるとすごい暗黙知ですね。しかもChatGPTも理解できるレベルの暗黙知のようです*2。

本エントリではどうして退職したのか、どうして今の会社に転職したのかとかは書きません*3。ただ今回の転職のタイミングは、今後の色々とやりたいことへの整理にはとても良いタイミングだなと感じたので、本エントリではこれからの動きをお伝えできる範囲で書いておこうと思った次第です*4。

結果、かなり宣伝色の強い投稿になってます。こういう話が好きじゃない人はどうぞブラウザバックしてください。

目次

昨年度から引き続き行っていること

iCARE様の技術顧問業

昨年途中から副業として、iCARE様のところでお手伝いをしています。

www.icare.jpn.com

肩書きは「フェロー（QAE技術顧問）」となってます*5。

定期的にQAEチームを中心とした社員の方の相談に乗っています。私が入った頃よりもさらに良くなってきているという実感を個人的には持っています。実際に社内でもQAEチームが評価されているという話を耳にしています。

こちらは、引き続き行っていく予定*6です。

iCAREの仕事に興味のある方、定期的に業務として私にテストなどについて相談したい方は以下から応募をご検討ください！

herp.careers

WACATE 2023 夏

半年に一度開催しているWACATEは、もちろん2023年6月も開催します！

wacate.jp

WACATEとは、テストに関する宿泊型のワークショップのイベントです。

コロナ禍になってからは宿泊は行えず、2日間のオンラインイベントでしたが、今回はコロナ禍になってから初めてオフライン開催をすることになりました！*7

テストについて2日間、ワークショップ形式で体験しながら身につけたい方はぜひご参加くださいませ！

JaSST Review

一年に一度開催しているJaSST Reviewは今年も秋頃に開催予定です。

JaSST Reviewとは、（おそらく）日本で唯一の、ソフトウェアレビューに関するシンポジウムです。

様々なジャンルの有識者に、レビューという側面で発表していただくパターンが多いです*8。

前回（2022年）の開催内容はこちら

www.jasst.jp

レビューについて色々と知見を増やしたい、考えたいという方はぜひご参加くださいませ！

CodeZine Academy講師

翔泳社様主催の「CodeZine Academy」というセミナーで講師をしています。

event.shoeisha.jp

Agileな開発にも役立つテストの考え方を、ワークショップ形式でお伝えする講座になっています。コンテンツ内容は私がオリジナルで作成したものになります。

昨年11月に既に1回開催した際の評価がある程度良かったのもあり、今年度も継続して開催することに至りました。次回は5月31日に開催予定です。

前回のセミナーについては、参加者発のレポートが上がってますので、参加検討の際は、そちらも参考にしていただければと思います。

qiita.com

www.creationline.com

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

自治体主体のセミナーでも講師を務めています。

www.aster.or.jp

上の「教育活動」のページにあるセミナーのうち、千葉開催分の講師を担当しました。こちらもある程度の評価をいただきまして、今年度も継続して開催することになっています。

こちらは「CodeZine Academy」とは違い、ASTER標準テキストを元にしてお伝えしております。また、ワークショップよりも説明中心です。

新しく行うこと

Ques登壇

5月18日開催の第20回Quesに登壇することになりました。

登壇内容は、先日書いた以下の記事が元ネタとなります。

nihonbuson.hatenadiary.jp

書籍『The BDD Books - Formulation』日本語版出版

「The BDD Books」シリーズの2冊目である『The BDD Books - Formulation』の日本語版の出版に向けて進めています*9。

1冊目の『The BDD Books - Discovery (Japanese Edition)』はこちらからご購入できます。

leanpub.com

振る舞い駆動開発(BDD)に関する内容で、日本語に訳されている数少ない書籍ですので、興味のある方は1冊目も合わせてぜひご購入の検討をよろしくお願いします！

現在、水面下で計画していること

まだ公開できませんが、他にも色々とお話をいただいています*10。

もしも公開できるタイミングになったら本ブログ/私の個人サイト/私のTwitterのいずれかでお伝えします。

おわりに 〜仕事の依頼について〜

ありがたいことに、本記事で整理して宣言しようと思ってしまうぐらいに、色々とお仕事をいただいております*11。

結果、これ以上TwitterのDMなどでお仕事の依頼を調整したり、自分ができることを個別にお伝えすることに限界を感じ始めました。そこで個人サイトを作成しました。

b-testing.net

何か仕事の依頼がある場合は、上のサイトから問い合わせをお願いします。現在すぐに動くことは難しいかもしれませんが、できる限り対応したいと思います。

これからも私ブロッコリーをよろしくお願いいたします。

*1:そういえば、前々職の退職エントリも、前職への入社エントリも書いてなかった気がする

*2:こんな出力結果になりました。ChatGPTすげえ。

*3:気になる人は直接話しかけてください

*4:宣言することによって、締め切り駆動的に自分を奮い立たせる意味もあります

*5:この話の初出は本投稿ではなく、iCARE様のテックブログ上だと思う。

*6:先方から契約終了が宣告されない限りは

*7:宿泊については今回も見送っています。次回こそはぜひ…！

*8:レビューの専門家と呼ばれるような人は殆どいないので、他ジャンルの方に講演をお願いすることになります

*9:正確にいうと、私の進捗が悪いせいで、現在まで出版に至っていないという状態です

*10:執筆系が1つ、登壇系が1つ、セミナー系が2つ、その他が1つ

*11:これだけ色々と行なっていると「ホントに本業やっているのかよ」と言われそうな気がしますが、自分のペースで無理しない程度に行なっています。登壇やセミナーは既存のコンテンツを活用していますし、執筆系は締切が非常に緩いです。大変なのはコンテンツの中身作成よりもタスク管理かもしれません。

再びCodeZine Academyで講座を開催します！

技術 勉強会

この度CodeZineさんからお誘いいただき、5月31日に再びCodeZine Academyで講座を行う運びとなりました！

event.shoeisha.jp

「開発を加速させる」に重点を置いたテストの講座です。

開発の実装を考え始めるよりも前の段階で必要となるテストの考え方や技術を、ワークショップを通じて体験していく形の講座となります。

講座で伝えたい内容について詳しくは、CodeZineさんの以下の記事をご覧ください。*1

codezine.jp

昨年11月に既に1回開催した際に、参加者からある程度良い評価をいただいたこともあり、今年度も継続して開催することに至りました。

前回のセミナーについての参加レポートが以下にありますので、参加検討の際は、そちらも参考にしていただければと思います。

qiita.com

www.creationline.com

直近ではありますが、興味のある方はご参加の検討をよろしくお願いします！

*1:記事を見て「そんなの当たり前じゃん」と思う人は講座を受けなくても十分かもしれません

AI駆動開発と現状とのギャップを示す

はじめに 〜記事執筆のきっかけ〜

先日、以下の記事についてのツイートが流れてきました。

zenn.dev

この記事の内容については、ChatGPTをはじめとするAIによるテストの可能性を示した素晴らしい内容だと思います。

ですが、果たして"今時点（元記事の執筆時点）の"出力結果*1が実用に耐えうるものになっているのか検討し、提示する必要もあると感じました*2。

そこで本記事では、テストエンジニアである私の回答例と"今時点の"AIの出力結果を比較しギャップを示すことを目的とします*3。

決して、AIによるテスト自動生成の進化自体を否定している訳ではないことを念頭にお読みいただければと思います。

結論

本記事では、"今時点の"AIの出力結果に対して、以下の結論を導き出しています。

  • 状態遷移図のテスト設計の題材では、根幹となる機能に関する不具合が含まれていた
  • デシジョンテーブルのテスト設計の題材では、デシジョンテーブルを表現できていないように見える
  • 境界値分析のテスト設計の題材では、コードの保守性があまり良くないように見える
  • 今時点のAIが作成できているのはテスト活動の一部である

目次

比較対象

比較は元記事に書かれている以下の3つの仕様に対する成果物を題材とします。これらは全てソフトウェアテスト技法練習帳に掲載されています。本記事内での掲載順は、特に重要な課題があった順となります。

  • 3.1 ストップウォッチの動作
  • 2.1 1杯目のビールの価格
  • 1.1 温度によって表示を変えるペット用室温系

使用する出力結果

AIの出力結果は、元記事の出力結果をそのまま引用します。

比較する出力結果は、私が問題を読んで書いた成果物です*4。

「3.1 ストップウォッチの動作」の比較結果

AIの出力結果

AIの出力結果は以下です。

AIの出力結果

私の成果物

私が書いた状態遷移図は以下です。

私が作成した状態遷移図

また、私は状態遷移図だけでなく状態遷移表とテストケースも作成しました*5。

私が作成した状態遷移表

私が作成したテストケース

検証結果

AIが状態遷移図とともに出力した実装物（元記事に記載あり）に対して、私が作成したテストケースを実施したところ、1件の不具合を発見しました。

テスト実施結果

不具合内容は「一時停止中にスタートボタンを押下すると、経過時間の続きからカウントアップするのではなく、0:00からカウントアップしてしまう」というものです。

これはストップウォッチの根幹となる部分の機能を損なっているといえるでしょう。

なぜこのような欠陥が埋め込まれてしまったのか考察したいのですが、本文中に書くと記事が長くなってしまうので注釈に記載します*6。

「2.1 1杯目のビールの価格」の比較結果

AIの出力結果

AIの出力結果は以下です。

AIの出力結果

私の成果物

私が書いたデシジョンテーブルは以下です。

私が作成したデシジョンテーブル

検証結果

元記事では、「見た目にはわかりやすいのですが、少々理解しにくい構造であることが難点です。」と書いています。ですが個人的にはデシジョンテーブルの目的を果たす形式での記述になっていないように見えます。

デシジョンテーブル（決定表）は、以下のように定義されています。

問題の記述において起こり得るすべての条件と，それに対して実行すべき動作とを組み合わせた表。(JIS X 0125:1986 より)

また、動作部（アクション）は以下のように定義されています。表記方法ではなく、動作部ではどんな意味を持たす表記を目指しているのかに注目して引用箇所を見てください。

アクション：

• X：アクションが発生することを意味する（Y、T、または 1 とも記述する）。

• 空白：アクションが発生しないことを意味する（-、N、F、または 0 とも記述する）。

(ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 より)

つまり、デシジョンテーブルは条件部と動作部に分かれ、動作部ではどの動作が行われるか表現することが目的といえます。

しかし、AIの出力結果は「何が条件部で何が動作部なのか分からない」「どの動作を行うのか表現するという目的が達成できていない」ように見えます。

もしも、AIの出力結果の形式で、デシジョンテーブルの目的に沿うように表現するとしたら、以下のような形を提案します*7。

デシジョンテーブルの目的に沿った出力結果

「1.1 温度によって表示を変えるペット用室温系」の比較結果

AIの出力結果

AIの出力結果は以下です。（元記事より抜粋）

describe("室温計のプログラム", () => {
  test("室温が24.0℃未満の場合、「寒い」と表示される", () => {
    expect(getTemperatureMessage(23.9)).toBe("寒い");
  });

  test("室温が24.0℃の場合、「快適」と表示される", () => {
    expect(getTemperatureMessage(24.0)).toBe("快適");
  });

  test("室温が24.1℃の場合、「快適」と表示される", () => {
    expect(getTemperatureMessage(24.1)).toBe("快適");
  });

  test("室温が25.9℃の場合、「快適」と表示される", () => {
    expect(getTemperatureMessage(25.9)).toBe("快適");
  });

  test("室温が26.0℃の場合、「暑い」と表示される", () => {
    expect(getTemperatureMessage(26.0)).toBe("暑い");
  });

  test("室温が26.1℃の場合、「暑い」と表示される", () => {
    expect(getTemperatureMessage(26.1)).toBe("暑い");
  });
});

私の成果物

私が書いたテストコードは以下です。

describe("室温計のプログラム", () => {
  describe("室温が24.0℃未満の場合、「寒い」と表示される", () => {
    it("室温が23.9℃の場合、「寒い」と表示される", () => {
      expect(getTemperatureMessage(23.9)).toBe("寒い");
    });
  });

  describe("室温が24.0℃以上26.0℃未満の場合、「快適」と表示される", () => {
    it("室温が24.0℃の場合、「快適」と表示される", () => {
      expect(getTemperatureMessage(24.0)).toBe("快適");
    });

    it("室温が25.9℃の場合、「快適」と表示される", () => {
      expect(getTemperatureMessage(25.9)).toBe("快適");
    });
  });

  describe("室温が26.0℃以上の場合、「暑い」と表示される", () => {
    it("室温が26.0℃の場合、「暑い」と表示される", () => {
      expect(getTemperatureMessage(26.0)).toBe("暑い");
    });
  });
});

検証結果

AIの作成物と私の成果物を比べると、以下の2点が異なります。

  • 境界値分析の選択が2値か3値か
  • 「未満」「以上」の表記があるかどうか（振る舞いを表現しているか、単にコードを表現しているか）

それぞれについて詳しくは注釈で説明を記載します*8*9。

実際の動作としてはどちらも正しく動きますが、テストコードの保守性という点では、AI作成よりも私が作成したものの方が良いかと思います*10*11。

さいごに〜AIが作成を担っている範囲〜

ここまで、"今時点でのAIの"出力結果に対して、さまざまな気になる点を提示しました。しかし、これはあくまでも"今時点の"出力結果です。近い将来、このような部分は改善されていくことでしょう。

ただし、テストで考えるところは今回議論しているような部分だけではありません。

例えば、JSTQBでは、以下のようにテストプロセスを示しています。

テストプロセス

このうち、今回行っていたのは主に「テスト設計」「テスト実装」の部分です。

「テスト分析」はどうなっていたかというと、実はAIへの指示命令の文章内（書籍に書いてある問題文内）に入っていました。例えば、「2.1 1杯目のビールの価格」の問題文の最後には以下のように書いてあります。

1杯目のビールの価格を表すデシジョンテーブルを作成してください。

これは、以下の指定をしていることになります。

  • 1杯目のビールの価格に関するテストを行わなくてはいけない
    • 2杯目以降のビールの価格に関するテストは行わなくて良い
    • ハッピーアワーの時間帯に関するテストは行わなくて良い
    • クーポンの同時使用枚数に関するテストは行わなくて良い
    • ビールの注がれる量に関するテストは行わなくて良い
  • デシジョンテーブルを使用しなくてはいけない
    • 状態遷移テストを行わなくて良い
    • 境界値分析を行わなくて良い

幾多ある確認したいことに対して「1杯目のビールの価格」という確認項目を指定し、幾多あるテスト設計技法のうち「デシジョンテーブル」を指定しています。

この「何を確認するか」「そのためにどんなテスト設計技法を用いれば良いか」といった部分は、まだまだAIに考えさせるのが難しい分野かなと思っています。

また、デシジョンテーブルの例や、境界値分析における振る舞いの表現のように、「物事を俯瞰的に見て表現する」「ハイレベルテストケースで表現する」といった部分はまだ苦手なのかなと感じました。

なのでテストエンジニア以外の方（開発者など）は、元記事を読んで「それじゃあ、もうテストエンジニアは必要ないね」と思わない方が良いかと思います。

またテストエンジニアの方は、そう思われないように「普段、自分はどんなことをやっているのか」という話を今まで以上にきちんと説明すべきなのかもしれません。

そして何度も繰り返し述べますが、今回の記事は"今時点の"AIの出力結果に対しての記事です。今時点の評価をしつつ、今後のAIのテスト作成の進化を応援しています！

*1:あくまでも今時点での話です。本記事は、将来のAIの進化まで否定したいという意図はありません。

*2:将棋の世界では似たようなことが起きました。Bonanzaメソッドによって画期的にAIの実力が強くなった当初、「これって人間を超えたのでは？」と言われるようになりました。それに対して、将棋連盟は「電王戦」という一般人にも分かりやすい形でプロ棋士とAIとの現在地を示しました。さらに永瀬六段（当時）は、自分自身が明らかに優勢な段階で、AI側の不具合を指摘しました（角不成の件）。これと同じような話をする必要が今回の件もあるんじゃないだろうか、というのが本記事執筆のモチベーションの詳細です

*3:今回の記事に対するツッコミに予め回答しておきます。

【ツッコミ1】そうやってテストエンジニアとしての自尊心を保ちたいだけだろ→違います。むしろ、今回検討した結果でさえすぐにAIは乗り越えてくるのでは？とさえ思っていますし、そうなることを期待しています。

【ツッコミ2】「だからAIは使えない」と言いふらしたいんだろ→違います。あくまでも今時点のAIの出力結果を比較することを目的としています。AIによる自動生成を応援する気持ちと、今時点のAIの作成物を評価する行動は両立すると思ってます。「ああ、もう今時点でテストはAIに任せれば全てOKだね」と思っていた方々が、本記事を読んで少しでも考え方を変えてもらえればと思っています

*4:本当はソフトウェアテスト技法練習帳の書籍に書かれている回答例を示した方が良いかもしれませんが、著作権の問題でどこまで載せて良いか不安になったので、あくまでも私が書いたものを示します。

*5:なお、ここで作成したテストケースは、状態遷移表を元に作成したものであり、自分でテストする場合は、実施手順の効率を考えて、手順の並び替え等を行います

*6:なぜAIがこのような欠陥を埋め込み、発見できなかったのか考察します。

【欠陥を埋め込んだ原因】仕様（問題文）には期待値を明確に記載していなかった

状態遷移図はあくまでも状態がどのように変わるのかを明記しているものです。一方で、それぞれの状態でどのような動作になっていれば良いのかが曖昧なままでした。

ちなみに元の仕様では以下のように記述されています。何かしら別の動作になるように見えますが、具体的にどのように動作するのかは明確に記載されていません。

計測準備中にスタートボタンを押すと計測が始まります

一時停止中にスタートボタンを押すと再開します

そのため、「計測中への状態の変化＝カウントアップを始める＝0:00から増やしていく」と勘違いしてしまった可能性があります。

もっと明確に定義を記載すれば、AIによる生成でも今回のような不具合を埋め込まずに済んだかもしれません。元記事で「プロンプトの最適化(プロンプトエンジニアリング)」と表現している分野の発展が必要となる未来になるかも…？

【欠陥を発見できなかった原因】テストコード内で再開時の時間経過のテストをしていなかった

今回のAI作成のテストコードの確認内容を日本語で表記すると以下のようになります。

テストコードでの確認内容

この中で、時間経過については「開始時」「一時停止時」の2つしか確認できていませんでした。そのため、欠陥を発見することもできていません。

*7:規格で定義されているデシジョンテーブルの書き方と比べて、行と列が転置している点については、現状では仕方ないかなと思っています。規格で定義されているデシジョンテーブルは1列ごとにテストパターンが書かれています。一方、ChatGPTは1行ごとに出力されるため、テストパターンを1行ごとに記述する現在の形にならざるを得ないと思うので。

*8:私が作成したものは2値の境界値分析をしていますが、AIが作成したものは3値の境界値分析をしています。2値と3値の境界値分析について詳しくは、akiyamaさんのブログ投稿を参考にしてください。

ここでは詳しい説明を割愛しますが、2値より3値の方がより注意深くテストしているといえます。私が2値の境界値分析をしている理由は、「2値では発見できないが3値では初めて発見できる不具合が今回の場合はあまり多くないのではないか」「2値の方が単純にテストコードの作成/保守コストが少ない」という2点です。

*9:AI作成のテストコードでは境界値のどのような部分を調べたいのかを読み取ることが難しいです。

数年後に機能の改修が入り、例えば"室温が26.0℃の場合、「暑い」と表示される"というテストコードだけ失敗した場合、このテストコードは何を確認したいコードなのか読み取ることが難しくなります。

この点について詳しくは、RAKUSさんのブログ投稿が分かりやすいので、そちらを参考にしてください。

*10:私自身が作成し、私が「良い」と判断しているので、読者の皆さんの意見を聞きたいところです

*11:そもそも、AI作成の場合、毎回新たに作れば良いので保守性を考える必要がないという意見もあるかもしれません。

これから実例マッピングを使おうと思っている人へお伝えしたい日本語情報のリンク集

技術

はじめに〜本記事の目的〜

2020年の4月に実例マッピングを日本語訳で紹介してから3年弱で、色々な人が実例マッピングを試しています。

本記事では、これから実例マッピングを試そうとしている人向けに、実例マッピングに関する日本語情報を提供することを目的としています。

目次

実例マッピングとは何か

実例マッピングの説明記事

実例マッピングの考案者であるMattさんが説明した内容を翻訳した記事です。

nihonbuson.hatenadiary.jp

実例マッピングの説明スライド

実例マッピングを使うタイミング、使い方、実例マッピングの成果物から見えてくることなどを説明したスライドになります。

まずはこのスライドを見ることで、どのように使うのかイメージしやすいかと思います。

speakerdeck.com

実例マッピングについて言及している書籍

The BDD Books - Discovery

BDDのプロセスの1つ「発見(Discovery)フェーズ」を行うための手法として実例マッピングを紹介しています。

この書籍内では、実際にどのように使うかの説明も物語形式で紹介しています。

leanpub.com

Agile Testing Condensed

Agileな開発の中で行うテストアプローチの方法の1つとして実例マッピングを紹介しています。

leanpub.com

実例マッピングの実践報告

試した結果を色々な方が報告しています。日本ではどのように実践しているのか、どの発表も具体例を交えて紹介しているものばかりです。

アルプ株式会社様

おそらく日本で一番、実例マッピングの実践報告をしてくださっている会社だと思います。

www.youtube.com

実践報告スライド

株式会社リンクアンドモチベーション様

使う動機や使い方について動画の中で説明してくださっています。

www.youtube.com

伊藤忠テクノソリューションズ株式会社様

実例マッピングの説明を聞いてから3ヶ月弱で実践し、事例発表してくださりました。

speakerdeck.com

株式会社サーバーワークス様

ユーザーストーリーマッピングから実例マッピングへ移る流れを含めて説明してくださっています。

blog.serverworks.co.jp

aki.mさん

実例マッピングをやった上で感じた効果と課題について、個人ブログの中で語ってくださっています。

aki-m.hatenadiary.com

株式会社永和システムマネジメント様

業務の中でではありませんが、「Scrum Inc.認定スクラムマスター研修」のコンテンツの1つとして実例マッピングを行なっているようです。

www.agile-studio.jp

実例マッピングを利用した感想

詳細な実践報告はしていませんが、使ってみた感想をツイートなどした例も多数見かけました。実例マッピングを使った生の声をお伝えできればと思い、一部を勝手ながら紹介したいと思います。

おわりに〜利用した感想をお聞かせください〜

本記事では、実例マッピングを使ってみるにあたり参考になる情報をお伝えしました。

本記事をきっかけにして実際に使ってみた場合、感想をぜひ教えていただけるとありがたいです！

テストケースの具体的な代表値には2以外の一意の素数を使おう

AdventCalendar

はじめに

本記事は、ソフトウェアテストの小ネタ Advent Calendar 2022の19日目の記事です*1。

本記事では、テストケース*2で具体的な代表値を使うときに気をつけている「2以外の一意の素数を使う」という方針について書きます。なお、この方針は私の個人的経験及び主観に基づいたものです。「必ずしもこのやり方が正しい」と主張したい訳ではないことをご了承ください。

記事では、この方針をさらに「2を使わない」「一意の数を使う」「素数を使う」の3つに分割して説明します。

目次

テストケースの具体的な代表値に2を使うのを避ける

とある大手で塾講師のバイトをしていた頃、塾で作成しているテキストに以下のような記述がありました。

.

例題）半径2cmの円の円周を求めなさい

解説）円周は直径×円周率で求められます。よって、

2×2×π=4π

答え）4πcm

この記述は「分かっている人の説明」であり、知らない人に対しては混乱を与える説明だと思います*3。「2×2」というのが、「半径×半径」なのか「半径の2倍」なのかが分かりづらいからです。

このように、「2」を用いてしまうと、「倍の値を使う」といったロジックを組んでいる場合に区別がつきづらくなってしまいます。そのため、「2」を使うのは避けるようにしています。

もちろん、必ず2を避ければ何でも良いという話ではありません。例えば、扱っているドメインで頻繁に「ポイント3倍キャンペーン」を行なっている場合は、「3」という値も避けた方が良いでしょう。つまり、特別な意味合いが含まれることが多い数字は避けた方が良いと思っています。

テストケースの具体的な代表値は一意の数を用いる

上に書いた「ドメインで頻繁に使われる数値を避ける」と似たような話です。

例えば、「商品Aを5個と商品Bを5個と商品Cを5個」と指定したとしましょう。合計の個数は「15個」が期待値であるにもかかわらず「10個」となった場合、どの商品が悪さしたのか分かりづらくなります。

私の場合「商品Aを3個と商品Bを5個と商品Cを7個」などと指定します。結果、合計の個数が「15個」が期待値であるにもかかわらず「12個」となった場合、「商品Aが加算されなかったのかな？」と推測できます。

テストケースの具体的な代表値に素数を用いる

テストケースの具体的な代表値には素数を選ぶことが多いです。

なぜかというと、例えば「10と入力する」と記述した場合、「単純に10を入力したかった」からなのか、「5の2倍の値を入力したかった」からなのか分かりづらいからです。

あくまでも「数値をそのまま用いる」ということを際立たせるために、できるだけ素数を選ぶようにしています。

注意：今回の考えはあくまでも代表値の場合の話です

ここまで話している内容は、同値分割法における代表値についての話です。それらとは別に、境界値分析における境界値は別途設定すべきだと思っています。

例えば、以下の画像のように、年月日の「月」についての入力値としては、「1」や「12」を選ぶかもしれません。

第4回 ブラックボックステスト - gihyo.jp から引用

「1」や「12」は代表値ではなく、境界値としての特別な数値を意味するからです。

一方、本記事でここまで語っていた内容は、境界値ではなく、同値分割法における代表値についてです。

年月日の「月」についての入力値について言えば、

といった選び方をするかもしれませんね*4。

おわりに

今回は、具体的な代表値を選ぶ際に気にしていることを言語化してみました。

本記事を読んで、「いや、必ずしもそうではないだろ」というような意見があるかもしれません。その際は、どういう場合に今回のような選び方をしないのか言語化してみてください。もしかしたら、そのケースは隠れた条件を持っているかもしれません。もし可能であれば、是非意見を共有してくださると嬉しいです。

補足：厳密な素数を選ぶわけではない

ここからは補足です。気になった人は読んでください。

本文中で「できるだけ素数を選ぶ」という表現をしましたが、必ずしも厳密に素数を選んでいるわけではありません。

例えば、硬貨を用いた（電子マネーではない）バスの運賃に関するテストを考えた場合、素数であることを考慮して「691円」を選ぶことはせず、「700円」を選ぶでしょう。理由は3点あります。

1. 「691」という数字が素数であるか判断が難しいため

「7」「13」ならば、素数であるということが分かりやすいですが、「691」という数字が素数であるかは判断しづらいです。

「691って素数なのかな？」と考えるのに時間がかかってしまっては意味がありません。「何かの倍数という考慮を排除したい」という目的達成のために素数を使おうとしているのに、何かの倍数かどうかの判断が難しい数字を選ぶべきではありません。

2. 「691」という数字に特別な意味があるように見えるため

テストケースの値に「691」と明記してしまうと、「この691というのは何か特別な数値で、これを選んだ理由があるのではないか？」と勘繰ってしまう人が現れる可能性があります。

3. 「691」という数字がドメインにそぐわない数字であるため

（電子マネーではない）バスの運賃というのは10円区切りであることが多いです。そんな中、1の位が0でない数字を選ぶのはドメインにそぐわない選び方だと思っています。

以上の理由より、今回の場合は「691円」という値は使わず「700円」といった値を使うと思います。ちなみに、その際も「600円」ではなく「700円」という値を使うことが多いです。「700円＝7（素数）×100円」だからです。

*1:小ネタなのに文字数多めでごめんなさい。

*2:特にローレベルテストケース

*3:個人的には、よくこんな混乱を招きそうな例題を、大手塾のテキストで記述するなーと思ってました

*4:前提として、今回はどの月を選ぶにしても同じ条件であるとしています。例えば、「2月は28日（閏年の場合は29日）までしかないので…」という考慮をする必要がないという前提を置いています。

野球を題材に品質を考えてみる

AdventCalendar 野球

はじめに

本記事は、ソフトウェアテスト Advent Calendar 2022の5日目の記事です。

本記事では、ソフトウェアテストと一緒に語られることが多い品質について、野球を題材に考えてみたいと思います。*1

ちなみに、もっときちんと品質について考える機会として、次回のWACATEがあるので、品質に興味がある方はそちらのご参加も検討してみてくださいね。（唐突な宣伝）

wacate.jp

目次

*1:ソフトウェアテストAdvent Calendarに投稿しているのに、ソフトウェアテストの話ではなくて、ごメンチ

続きを読む

CodeZine Academyで講座を開催します！

技術 勉強会

この度CodeZineさんからお誘いいただき、CodeZine Academyで講座を行う運びとなりました！

event.shoeisha.jp

今回は「開発を加速させる」に重点を置いたテストの講座です。

開発の実装を考え始めるよりも前の段階で必要となるテストの考え方を、ワークショップを通じて体験していく形の講座となります。

講座で伝えたい内容について詳しくは、CodeZineさんの以下の記事をご覧ください。*1

codezine.jp

直近ではありますが、興味のある方はご参加の検討をよろしくお願いします！

*1:記事を見て「そんなの当たり前じゃん」と思う人は講座を受けなくても十分かもしれません…w