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

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

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以外の一意の素数を使おう

はじめに

本記事は、ソフトウェアテストの小ネタ 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日)までしかないので…」という考慮をする必要がないという前提を置いています。

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

はじめに

本記事は、ソフトウェアテスト 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

JaSST Review'22 って結局何やるの?と疑問を持っている人への知りたいこと別リンク集 #JaSSTReview

ざっくりと、知りたいこと別にリンクを貼ってみました。

JaSST Review'22の公式サイトを知りたい人へ

www.jasst.jp

JaSST Review'22内容を簡潔に1枚の画像で伝えて欲しい人へ

JaSST Review'22開催の想いや、どんな聴講者を対象にしているのか知りたい人へ

speakerdeck.com

JaSST Review'22の講演内容や講演者について知りたい人へ

nihonbuson.hatenadiary.jp

JaSST Review'22のワークショップの内容を知りたい人へ

nihonbuson.hatenadiary.jp

JaSST Review'22への参加申込方法を知りたい人へ

www.jasst.jp

【翻訳記事】BDDの考案者が執筆した記事「テストについて話し合わなくてはならない」を翻訳しました!

目次

  • 目次
  • はじめに(本記事の見どころなど)
  • テストについて話し合わなくてはならない
  • テストの目的
    • 「うまくいかないかもしれないものは何ですか?」
    • なぜテストをするのですか?
    • この場合に限り……
  • テスト駆動開発 〜テストについて語る前に説明が必要です〜
  • テストについて話しましょう
    • なぜすべてのテストを自動化しないの?
    • テストカバレッジは有用な指標ですか?
    • 「テストをシフトレフトする」とはどういう意味ですか?
    • いつ、どこでテストすべきですか?
    • 十分なテストとはどれくらいですか?
  • おわりに

はじめに(本記事の見どころなど)

今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」(原題は「We need to talk about testing」)を翻訳したので紹介します。

dannorth.net

本記事はDaniel Terhorst-North(Dan North)が書いた記事です。Dan NorthはBDDの原典ともいえる記事「Introducing BDD」(日本語訳の記事「BDDの導入 - Dan North」)を書いたことでも有名です。

本記事では、Danが考えたテストの目的を提示した上で、自動テストやTDDに対する誤解について語っています。そしてテスターに対する本当の価値についても、敬意を持って語っています。

Danはテスターではなくプログラマーでありながら、ここまでテストのことについて語っていることが素晴らしいと思い、翻訳することにしました。

これ以降は元記事を翻訳したものになります。

続きを読む

レビューのワークショップを行います! #JaSSTReview

10月28日にJaSST Review'22(ソフトウェアレビューシンポジウム)を開催します!

www.jasst.jp

今年は、JaSST Reviewでは初めてワークショップを行います。

ワークショップの内容

「レビュー」というと、個々人の今までの経験に頼るという面が非常に多い分野だと感じています。JSTQBでも、レビュープロセスは存在していますが、「個々のレビュー」という表現しかしておらず、その中でどのような思考プロセスを行うかは記述していません。

JSTQBには「個々のレビュー」に対しての具体的な思考プロセスを記述していない

一方、テストプロセスについては具体的な思考プロセスを記述しています。

テストプロセスについては具体的な思考プロセスを記述している

そこで、テストプロセスを真似ることでレビュープロセスも具体的なプロセスを記述できるのではないかと考えました。

レビュープロセスもテストプロセスと同様に具体的な記述ができるのではないか?

これをワークショップ形式にして皆さんに体験しながら学んでもらおうと考えたのが今回のセッションです。

※なお、ここまでに描いたプロセスの記述と、当日のワークショップで区分けしている記述は異なっています。あくまでも、分かりやすさ重視のため、本記事ではテストプロセスに当てはめた場合で記述しています。

ワークショップに参加される方々へ

今回のワークショップは(おそらく)初めて、レビュープロセスを体系的に体験して学んでもらうコンテンツとなります。

そのため、今までレビューに慣れているかどうかは関係ありません。むしろ、今までレビューで悩んできた人に向けて少しでもヒントになればと考えております。

なので、ワークショップに参加できる時間を確保できる方は、ワークショップの参加をご検討いただければと思います。

なお、ワークショップ参加にはレビューの経験の度合い以外にいくつか条件があります。以下の条件に当てはまらない方はワークショップ見学を推奨いたします。

  • ワークショップの開催中(10月28日 13:00〜16:15)、時間を確保できる方
    • 今回はグループワークも行います。そのため、ワークショップ参加中、他の用事で一時的に離席されてしまうと他の方にご迷惑がかかります。一時的な離席の予定が既にある方はご遠慮をお願いいたします。
  • Google Meetを使うことができる方
  • miroを使うことができる方
    • セキュリティ上の問題でアクセス制限がかかる方はご遠慮をお願いいたします
  • 事前に資料をご確認いただく時間の取れる方
    • 今回は時間の都合上、事前に資料を確認いただきたいと考えております。当日までに確認する時間が一切取れない方はご遠慮をお願いいたします

ワークショップを見学される方へ

今回、ワークショップに参加できない方向けに、ワークショップの見学枠も設けております。見学される方は、Google Meetやmiroに接続できる環境でなくても十分楽しめると思います。

ワークショップに参加ができない方は、見学もご検討くださいませ。

おわりに 〜参加をご検討いただいている皆様へ〜

参加登録はこちらになります。

www.jasst.jp

また、ワークショップ以外の部分も含めて、今回のシンポジウムでお伝えしたいことをスライドにまとめました。参加に悩んでいる方はご参考にしてください。

speakerdeck.com

皆様のご参加をお待ちしております!