ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

『TestSphereの遊び方を考える会』の第1回をやりました!

 こちらで予告した『TestSphereの遊び方を考える会』の第1回をやったので、レポートです。

www.kzsuzuki.com

 付き合ってくれたメンバーは、オムそばさん、ネモさん、ばんさん、リナさん、あさこさんです。ありがとうございます。

f:id:kz_suzuki:20200802212124j:plain

目的

 前回紹介した通り、TestSphereは100枚のカードからなるデッキ。100枚は5つのカテゴリー×20枚からなり、それぞれのカテゴリーに属するキーワードとその説明、プラス3つの事例、という作りになっています。

 使い方が厳密に規定されているわけではありません。テスト計画を使う際のブレインストーミングに使ったり、会話のきっかけに使ったり、ゲームをしたり・・・と、さまざまな使い方のアイデアがあります。
 今回の『考える会』では、オンラインを前提に、どのように遊べるかをみんなで考えよう!ということで企画してみました。

いきなり「??」となる・・・

 上に書いたようなTestSphereざっくり情報をみんなに伝えただけで、「さあどうよ?」って投げだしたわたしのファシリテーションが悪いのですが、遊びを考える以前にいろいろな障壁が明らかになりました。

まず、英語が・・・

 やっぱり英語ですね。さくっと読めない。
 一定量の英文なら多少わからない単語があっても補完できたりするのですが、それぞれが短文なので、一語でもわからないとけっこう厳しい。

 というかですね、文章以前にキーワードの単語自体がわからないこともあるんですよ(恥)。
 たとえば、「感情」カテゴリーの、「TENACIOUS」。  キーワード時点で「いや、何よ?」となると、ゲームの入り口にも立てていないんです。

 なおこの問題はリナさん発案により、Google先生に解決していただきました。  AndroidだとデフォルトでGoogleレンズがついてるんですかね。iPhoneの場合はGoogle翻訳でこれができます。まあ翻訳の精度はいまいちですが、ざっくりわかる。

f:id:kz_suzuki:20200802212023j:plain

キーワードも思いのほかわからない

 100枚あるといっても、テストに関係するトピックなんだから、だいたいはわかるべ!とか油断していると、「パターン」カテゴリーの「IKEA-EFFECT」(IKEA効果)が出てくる。聞いたことある気がするけれど、わからない。
 英語を乗り越えても、次に知識不足にやられる感じです。

 ちなみにIKEA効果とは。

自分が作ったものや関与したプロジェクトに対して、その価値を過大評価する心理効果のこと。 人は手間をかけることで思いや愛着が強まり、自分のみならず他人にとっても高い価値を持つものと錯覚する効果がある。
イケア効果とは 意味/解説 - シマウマ用語集

 なるほどなるほど。
 このカードが属するサブカテゴリーは「Bias」で、心理学的バイアスについてのキーワードがたくさん出てきます。確かにテストにおいては必要な知識ですね。
 ですが、普通に知らないキーワードだらけです。まあこれは、お勉強の一つと捉えればいいでしょう!

カテゴリーに違和感

 「技法」カテゴリーの一つに、たとえば「PAIRWISE TESTING」(ペアワイズテスト)があります。これすんなり来ますよね。
 一方で、「CHARM」(魅力)。魅力? 魅力が、技法? 「KNOWLEDGE」(知識)が、技法?
 これは、カテゴリー「TECHNIQUES」を暗黙の裡に「テスト設計技法」と解釈している自分たちが狭いということで、日本語でいう「テクニック」と理解した方が自然かもしれません。

 「テクニック」には実は3つのサブカテゴリーに分かれています。「プロダクトレベル」「プロジェクトレベル」「個人レベル」。
 プロダクトレベルにはいわるゆテスト設計技法的なものが並んでいます。「個人レベル」は、コミュニケーション能力的な個人の技術が。また「プロジェクトレベル」には、「ペアテスト」「要求工学」といった、それ以外の技術が並んでいます。
 カテゴライズにちょいと癖があるので「ぬ?」となりがちなのですが、それを解釈するのも楽しみの一つです。

 要は、「どんなカードがあって、どんなことが書かれているか」をみんながある程度知らないと、なかなか遊びづらいということですね。
 ということもあって、まずはみんなで、100枚を一通り読んでみました。理解できなさそうなものはさっと飛ばして。すると、各カテゴリーの意味しているところがぼんやりとわかってきて、「まあ、遊べそうかも」という雰囲気になってきます。

どんな遊び方ができるのか?

キーワードを推測するゲーム

 まず、アナログゲームに詳しいオムそばさんからは、「キーワードは隠しておいて、カードに提示された3つの例からキーワードを推定する」という形に基づく遊び方を、2種類していただきました。発想から形にするまでの速度が速すぎる・・・。
 課題としては、(キーワードなどを隠す関係上)物理カードで遊ぶのは難しいというものがあり、電子化が必要かなあという話になりました。で、そうすると権利関係が・・・という課題も出てきてしまいます。物理でも、ちょっと工夫してうまくやれないかな?

「ダウト」っぽいゲーム

 嘘をつく人とそれを見破る人に分かれるゲームです。
 カードを数枚ランダムに選んで、嘘をつく人は「それぞれのカードのキーワードに対し知識や経験を有しているていで」説明する。見破る人は、どれが真実でどれが嘘かを見破る、というものです。
 あるいはゲームにしなくても、キーワードについて「できる」「できない」、「知ってる」「知らない」を話すことで、メンバーがどんなスキルを持っているかの理解にもつながるかなと。

感情の起伏を語る場

 「感情」カテゴリーには、さまざまな感情のカードがあります。この中から、プロジェクト当初に感じていた感情、途中段階での感情、現時点での感情を選んで、なぜそのような変化が起こったかをふりかえりの場などで語る。というものです。ゲームというよりは、コミュニケーションですね。

 また、たとえば「COMFORTABLE」は positive feeling のサブカテゴリーに入っていますが、「comfortable zone」というフレーズの中では negative な意味にもなりえます。それぞれの感情は本当に positive / negative なのか、という観点で意見を交わすのも面白いのではないか、という話をしました。

オーソドックスなゲーム

 1枚めくって、そのキーワード(または三つの例の中のどれか)に絡むエピソードを語る、というものです。
 これは一番直観的でシンプルな使い方だと思います。キーワードを知らなければスキップしてもいいですし、わかる人が教えてもいいですし、みんなわからなければ調べて「あーーー」となるのも楽しい。

 ただこれだと、カードの枚数100枚で同じエピソードになってしまいがち。中級者(何の?)は2つのカテゴリーからそれぞれ1枚ずつをめくって、その2枚の両方の要素を含んだエピソードを語る。これだと、5C2 *20 *20 = 4000パターン(たぶん)になるので、同じパターンが出ることは少なくなるでしょう。

 昨日わたしが引いたのは、探索的テストにおける「TOURING」(ツアー、「テクニック」カテゴリー)と、上述の「COMFORTABLE」(快適、「感情」カテゴリー)です。
 なお「探索的テストツアー」については、以下で記事を書きました。

www.kzsuzuki.com

 探索的テストの実行について以前N社のKさんから「探索的テストをあまり自由にやってもらうと、過去にバグを見つけたときのパターンばかりがんばって、それ以外のことをやらなくなる」というお話を聞いたこともあり、「過去にうまくいっていた快適なやり方を抜け出すために、探索的テストにおける攻め方を分類したツアーって役に立つよね」というお話をしました。まあこれは偶然、うまいエピソードを見つけられましたが、なかなか難しいかもしれませんね。

前の人から話をつなげていく

 こちらは、カード自体は1枚なのですが、代わりに「前の人のエピソードから何か1つ言葉を拾って、その言葉とカードを組み合わせたエピソードを語る」という形です。例を説明したいんだけれど、自分の回答を忘れてしまった・・・。
 2枚引きより自由度が上がりつつ、話がつながっていくということで少しゲーム性もあり。個人的にはこれが一番面白かったですね。

さあ、やってみよう!

 ということで、ちょいハードルはあるけれど、けっこう遊べるんじゃないかなという。

 実際、こんな感じです。まあ、慣れは必要ですね!

 ということで、TestSphereで遊んでみたい方、声かけてください~。5~6人集まったら遊びましょう。流れがきたら日本語化プロジェクトやるか!

TestSphereというカードデッキを買ってみたので、みんなで遊び方を考えよう!

 TestSphereというカードデッキを買ってみましたので、紹介します。
 遊び方を考えたいので、みなさんご協力ください。

f:id:kz_suzuki:20200726153507j:plain
一瞬、ちょい箱ボロいな!?と思ってしまった
f:id:kz_suzuki:20200726153429j:plain
中はちゃんと包装されていた

TestSphereとは

 Ministry of Testingというサイトが開発した、ソフトウェアテストに関するカードゲームのようなものです。

この記事の目的

 TestSphereの紹介ではあるのですが、これを使ってどう遊ぼうか(特にオンラインで!)を考えたいので、みなさん手伝ってください。
 以下の「なぜ、TestSphereを作ったのか」は、公式ページ(https://www.ministryoftesting.com/testsphere)からの翻訳です。

<翻訳> なぜ、TestSphereを作ったのか

 ソフトウェア開発の世界は進化しています。わたしたちは日々、早期のテストを行い、「シフトライト」「シフトレフト」し、かつてよりさらに深く掘り進んで、自動テストを賢く利用しながら、チーム全体が品質にフォーカスしています。
 スクラムチームの中にテストを根付かせたり、アジャイルプラクティスを通して、わたしたちの仕事はずいぶんとよくなっていることがわかります。

アジャイルチームの一員としてのテスター

 テスターは開発の一部です。チームの中で、すぐそばに座っていて、すべてのことをテストします。しかしこれには課題があります。テストの専門家が、様々なチームに分散されているということです。これはつまり、別のロールの人たちとはよく交流できる一方で、話のできるテスター同士の連帯意識を感じることが難しくなっているのです。

孤独なテスター

 チームの中で唯一のテスターにななってしまうことがあるというのが、テスターが直面するもう一つの課題です。作る側のマインドセットにじわじわと吸収されてしまい、テストが浅すぎるものになってしまうこともあります。また、テストを行っている同僚と共有できたはずのナレッジを失い、テストの新しい考え方や直観のひらめきから遠ざかってしまう危険性もあります。
 このような課題に取り組むために、TestSphereは開発されました。

中に入っているもの

 TestSphereのカードパックには、5つのカテゴリーに分けられるカードが100枚入っています。

  1. ヒューリスティックス: 問題に取り組むために考えられる方法
  2. 技法: ありうる問題を見つけるためにテストに用いている賢いアクティビティ
  3. 感情: テストを行うことで引き起こされる感情は何であれ、事実として取り扱われるべき
  4. 品質の側面: 対象のアプリケーションについて、着目するかもしれない側面として考えられるもの
  5. パターン: テストにおけるパターン。ただし、テストにおけるバイアスのように、負の意味をもつパターンも含む

 5つの次元についてそれぞれ20枚のカードがあり、カードがそれぞれテストのコンセプトを紹介しており、各3つの例がそれらのコンセプトに別々の光を当てています
 テストのアイデアを引き出し、話し、学ぶための100枚のカードと300の例というわけです。

(翻訳終わり)

現物はこんな感じ

 5つのカテゴリーごとに、現物を1枚ずつ見てみましょう。

紫 - 感情

 たとえば「ANGER (怒り)」についてはこのような内容になっています。

f:id:kz_suzuki:20200726153440j:plain
ANGER

怒り - ネガティブな感情:
人の気を昂らせるものはたくさんあります。怒りは不合理で、人を冷淡にさせることもあれば、改善のモチベーションになることもあります。

  1. 多額の投資を受けたプロジェクトで長期にわたって働いていると、人はとても感情的になってしまうことがある。彼らのストレスを発散させるには、どのような方法があるだろうか?
  2. あなたとプログラマーは、ディスカッション、拒否されたバグやフィーチャなど、いたるところで激しく言い争っている。
  3. 必要な時にしょっちゅう壊れたり落ちたりしてしまう環境に、あなたはうんざりしている。二度とそれが起きないように、今回はしっかりと対策を用意しておかないといけない。

緑 - 技法

 「ABテスト」の例。

f:id:kz_suzuki:20200726153446j:plain
A/B TESTING

ABテスト - プロジェクトレベル:
1つのコンセプトを、別の方法で行ってみるもの。両方を評価し、ベストのものを選ぶ。マーケティングでよく行われます。

  1. ある企業は、2種類の人のサンプルに対し2つの異なるメールを送る。そしてキャンペーンでは、もっとも反応の良かったものを使う。
  2. 新しいフィーチャーについて、異なるコンセプトに基づく2つ以上ののモックアップを作る。そして、ユーザからの反応がいちばんよかったものを使う。
  3. テストのミッションを達成するために、2つの戦略を提示する。チームやステークホルダーと議論し、彼らの興味をもっともひくものを選ぶ。

赤 - ヒューリスティック

 「説明可能性」の例。

f:id:kz_suzuki:20200726153453j:plain
EXPLAINABILITY

説明可能性 - 一貫性のヒューリスティック:
説明の難しいプロダクトは、ユーザにとって、理解がそうとう難しいかもしれません。

  1. FAQはドキュメンテーションより長くないだろうか。だとすると、アプリが説明困難なものである可能性がある。
  2. あるややこしい振る舞いについて説明してみよう。説明のために妙なモデル、コンセプト、スキームを持ち出さなくてはならないとしたら、その機能自体がうまくなじんでいないのかもしれない。
  3. 製品は、ツールチップやヘルプ機能を提供しているか? それは実際どう役に立っているか?

青 - 品質の側面

 「テスタビリティ」の例。

f:id:kz_suzuki:20200726153457j:plain
TESTABILITY

テスタビリティ - 保守性の側面:
あなたのテストの作業がどれだけ容易か、あるいは困難かに影響を与えるあらゆるものを指します。

  1. ゲームをより簡単にテストする方法として、しばしば「チートコード」というものがある。「最強」の状態をテストしたければ、上上下下左右左右BA、スタート、セレクト」*1を入力するとか。ただこれはショートカットだということを忘れないように!
  2. テストのための環境は十分か? その環境を何に使う? チームメンバー全員に、それが明らかになっているか?
  3. ある特定の時刻にして発生しない機能をテストするために、システムの時刻を操作できるか?

オレンジ - パターン

 「自動化」の例。

f:id:kz_suzuki:20200726153502j:plain
AUTOMATION

自動化 - アプローチ:
ロボット。心や頭脳は持っていませんが、迅速に、素晴らしい計算をこなすことができます。

  1. 同じことを50個同時に実行することのできる、性能テスト用のスクリプト。ベースラインを定めて、耐久性を設定しておくことで、結果を分析するのに役立つ。
  2. 退屈なチェック作業をしなくてはならない? 自動化して時間を作り、新しく面白いテストをしよう。
  3. ロボットは、何かをモニターするのが得意。あなたが働いている時間、寝ている時間、食べている時間、人生を楽しんでいる時間に、トラブルがないか調べてもらおう。

 このようなカードが、全部で100枚あるわけです。けっこう分厚い。

使い方の紹介

 使い方の例を、公式サイトからのかいつまんでみましょう。

1. ナレッジの共有

 引いたカードをトリガーにして、テストに関する話や経験などを話す。

2. リスクストーミング

 プロダクトやプロジェクトについての重大なリスクを洗い出すために使う。

3. TestSphereアリーナ

 基本デッキに拡張パックを追加して、UNO風のゲームに仕立て上げたもの。カードを捨てる際に、そのカードと直前のカードを関連付けるストーリーを話すというゲーム。

4. スプリントプランニング

 カードをベースにして、計画対象のストーリーに対してテストすべきことを考えていく。

5. レトロスペクティブ

 「感じたこと」が置き去りになりがちなレトロでカードを使うことで、人間としての側面も見せられるようになる。

6. インスピレーション

 テストはアートのようなもの。TestSphereを使って、次のテストに向けたインスピレーションを得る、

 また、使い方などが書かれたカードには、「アイスブレイカー」としてこんなことが書かれています。

  1. 孤独なテスターを見つける
  2. 彼らのところに歩いていって、無作為にカードを1枚引く。たとえば「同値分割」。
  3. そのテスターに、「同値分割について、何か話題や経験を教えてくれないか」と尋ねる。

 いや、どんな強メンタルだよ・・・そんなやついるかよ・・・と思いますが。。。

 「ゲーム」はこう。

  1. テスターを集めてグループを作る
  2. デッキをカテゴリーで分ける
  3. 1枚(もしくはもっと)カードをめくる
  4. めくられたすべてのカードに関して紹介できるようなストーリーを考えて、できるだけ早く宣言する
  5. 最初にストーリーを話せた人がカードをとる これを一定時間行って、最後に一番多くカードをもっていた人の勝ち

 前述の「TestSphereアリーナ」を追加してのゲームもそうなんですけれど、「速さを競う」はオンラインと相性悪そうですよね。なので、集まった人が順番になんかしゃべるようなやつにできないもんかなと。

 「ソフトウェアの品質を学びまくる」では、TestSphereで一緒に遊んでくれる人を募集しています!

*1:コナミコマンドというもののようですね。

『練習帳』の問題を解きながら、デシジョンテーブルと組み合わせテストの位置づけについて考える

old pair

 『ソフトウェアテスト技法 練習帳』の第4章「組合せテスト」*1を解き終えました。

 仕様の文章内に因子と水準が明示されているケースだけでなく、ラルフチャートを用いた因子・水準の洗い出しや、既存の仕様からの差分に着目したテスト設計などの応用にも手を伸ばしています。
 またPictMasterの使い方についても、制約条件・エイリアス・サブモデル・原型シートの機能を使えるように問題が設計されており、とてもバランスの取れた章だと思います。

 ということで、また「わたしはこう考えた」のコーナーです。

問題の内容

 問題4.5は、健康診断申し込みシステムです。
 性別、年齢に加えて、任意で追加できる検診項目(眼底検診、メタボ検診、婦人科検診、脳検診)を選んで「申込」するというもので、以下の制約があります。

  • メタボ検診と婦人科検診は、年齢が35歳以上の人のみ選択できる
  • 脳検診は、年齢が45歳以上の人のみ選択できる
  • 婦人科検診は女性のみ選択できる

 問題としては、「2因子間網羅のテストを行う」なのですが、この仕様を見て最初に頭に浮かんだテスト技法は、組み合わせテストではなく決定表でした。各因子がとる水準の組み合わせによって、システムの挙動が変わるためです。

デシジョンテーブルと組み合わせテストの目的

 デシジョンテーブルを書くと、こんな感じでしょうか。*2

f:id:kz_suzuki:20200613184527p:plain
デシジョンテーブル

 ところでこのデシジョンテーブルは、何を確認するためのテストなのでしょうか。
 それは、「プログラムの実行結果が、因子の組み合わせに依存する」仕様の確認です。
 たとえば「年齢」が同じ40歳であっても、婦人科検診を選択可能かは「性別」に依存します。この組み合わせならこれを選べる、あの組み合わせならあれを選べない、と組み合わせを確認していくのが、デシジョンテーブルでのテストです。いわゆる「有則のテスト」ですね。

 一方この問題で取り扱っている組み合わせテストは、「プログラムの実行結果が、因子の組み合わせに依存しない」仕様の確認です。 
 男性でも女性でも、20歳でも30歳でも40歳でも50歳でも、性別と年齢の具体的な値の組み合わせに関係なく、同じように「眼底検診」を選べる、ということを確認していくのが、組み合わせテストです。いわゆる「無則のテスト」です。

 ただしこの問題では、組み合わせることのできない制約(または「禁則」)があります。組み合わせ生成時に、これらの制約に相当するパターンが現れないようにしています。
 決定表で赤字のXになっている部分が、禁則に相当します。組み合わせに現れない(ようにしている)ため、個別に確認することを忘れないようにしなければなりません。

デシジョンテーブルと組み合わせテストのケースの比較

 上の決定表と同じように因子・水準と制約を設定して*3オールペアの組み合わせを生成すると、以下のようになります。

f:id:kz_suzuki:20200613212121p:plain
2因子網羅

 デシジョンテーブルにおける因子の全組み合わせ30パターン、うち許容される20パターン(〇)に比べても、2因子網羅は12ケースと絞り込まれていることがわかります。ただこれくらいなら、デシジョンテーブルに基づいて全組み合わせを確認してもよさそうですね。

 問題は、各因子の水準が多い場合です。
 練習帳では、「年齢」因子に、7つの水準を使っています。今後「任意追加項目」因子の水準も増えることを考えると、組み合わせテストによるテストケース削減が威力を発揮します。
 ただもちろんこれは、デシジョンテーブルの〇部分がすべて同じふるまいをする(つまり因子の組み合わせに依存しない)場合の話です。組み合わせによってふるまいが変わる場合は、それぞれの組み合わせをデシジョンテーブルで確認する必要があります。

ついでに、水準の選び方について

 こちらでも言及したのですが、制約に基づいて「年齢」因子を「20~34、35~44、45~60」で同値分割するのはいいとして、水準として

  • 20~33、34 (上限とそれ以外) → 代表値は 20、34
  • 35、36~43、44 (上限と下限とそれ以外) → 代表値は 35、36、44
  • 45、46~60 (下限とそれ以外) → 代表値は 45、46、60

を選んでいるのはどうも一貫性がなく、解せない点です。境界値を別の同値クラスとするのであれば、

  • 20、21~33、34 (上限と下限とそれ以外) → 代表値は 20、30、34
  • 35、36~43、44 (上限と下限とそれ以外) → 代表値は 35、40、44
  • 45、46~59、60 (上限と下限とそれ以外) → 代表値は 45、50、60

のように選ぶべきではないのかなと。この辺はみなさんのご意見を伺いたいところ。

 以下、秋山さんご意見です。いつもありがとうございます。

*1:わたしは「組合せ」「組み合せ」「組合わせ」ではなく、「組み合わせ」派です。

*2:デシジョンテーブルの形式が少し変かもしれない。「申込」ボタン押下時に挙動が判明するのであれば、検診項目も条件部の方に入るのが正しい。性別と年齢を選択した時点で「任意追加項目」で選択可能な値が変化するのであれば、この表でもいいかな。

*3:『練習帳』より因子が粗いです。

状態遷移テストの ignore と not happen について、astah*とともに整理してみる。

Dash of color!

 先日の記事で、状態遷移テストのカバレッジについて書きました。

www.kzsuzuki.com

 この記事のために利用させていただいている、モデリングツール「astah*」。このastah*で描く状態遷移表に用意されている、ignore と not happen という選択肢について、astah*内での位置づけと、テストの要否について考えてみました。

 なお本記事は、Twitterにおける秋山さんとの以下のスレッドをベースにしています。

ignore と not happen

 前回の記事に書いた通り、ignore と cannot happen はおおむね、以下のような意味を持っています。

  • ignore: 当該イベントが発生しても、発生しなかったように扱う。
  • cannot happen: 当該イベントは発生しえない。

 似ているように見えますが、前者は「イベントが発生しうる」、後者は「イベントが発生しえない」ので、根本的に違いますね。

 例を挙げて説明してみます。
 会社なんかでよくある「カードタッチで解錠するドア」を考えましょう。ざっくりこんな仕様。

  • 内側からは、タッチなしで開けられる。
  • 外側からは、タッチで解錠したうえで開けられる。
  • ドアが開いたまま、最後のタッチから一定時間経つとアラームが鳴動する。
  • アラームは、カードタッチすることで停止する。
  • アラーム鳴動中はデッドボルトが飛び出しており、そのままドアを閉めることができない。アラームを止めてデッドボルトが引っ込んだ状態にしたうえで閉じる必要がある。

 5個目の長くてわかりづらくて不自然な仕様は、説明のためだと思って受け入れてください。平行線公準のようなものです。

 ステートマシン図は以下のようになります*1

f:id:kz_suzuki:20200524170937p:plain
ステートマシン図

 astah*で自動生成してくれた状態遷移表は、以下の紫セル。
 白セルは、個別に埋めていく必要があります。ここに書かれた ignore と cannot happen の意味を考えてみましょう。

f:id:kz_suzuki:20200524171019p:plain
状態遷移表

ignore と自己遷移

 ignore は2つのセルに書かれています。

  • ドアが施錠された状態で、外からドアを開ける。
  • アラームが鳴動している状態で、外からドアを開ける。

 これらのケースでは状態が遷移しないだけでなく、何も起きません

 一方、以下のセルはどうでしょう。

  • ドアが開いた状態で、カードタッチする。
    • 「ドア開&鳴動なし」×「カードタッチ」→「ドア開&鳴動なし」

 これも同じ状態に留まりますが、アラームが鳴るまでの時間経過をリセットするアクションが内部で動いていると考えられるため、「同じ状態に遷移した」と解釈するのが妥当でしょう。

cannot happen の区別

 cannot happen はけっこう出現していますね。
 たとえば以下の2つは、まさに「起こりえない」イベントといえます。

  • ドアが開いている状態で、外からドアを開ける。
  • ドアが閉じた状態で、ドアを閉じる。

 一方、以下はどうでしょうか。

  • アラーム鳴動中に、ドアを閉める。

 これは確かに「仕様上は起こりえない」ことになっていますが、原理的に「起こりえない」イベントではありません。実装が間違っていて、仕様通りにデッドボルトが飛び出さなかったら、「閉じ」れてしまう可能性があります。この種のイベントは、cannot happen というよりは、should not happen とでも扱うのいいのかもしれません。ともあれ、2つを区別する必要があるでしょう。

状態遷移表のセルのパターン

 以上の話を整理すると、以下の5つのパターンに分けられます。

  1. イベントが発生すると、別の状態へ遷移する。(遷移)
  2. イベントが発生すると何かが起きるが、同じ状態にとどまる。(自己遷移)
  3. イベントが発生しても何も起きず、同じ状態にとどまる。(無視 = ignore)
  4. イベントが発生しないことになっている。(仕様的不可 ∈ cannot happen)
  5. イベントが原理的に発生しない。(原理的不可 ∈ cannot happen)

 カッコの中の日本語は、ここで暫定的に付けた名前です。ちゃんとした呼称があるかも。

 ではこの5つのうち、状態遷移テストで検証すべきものはどれでしょうか。
 a.とb.は「遷移」そのものなので、当然確認する必要があります。e.は起こすことができないのですから、そもそも検証不可能です。

 c.はどうでしょう。イベントを起こすことができるので、「本当に無視するか」を確認する必要がありますね。
 d.も考え方は同じです。「本当にイベントを起こせないか」を確認する必要があります。

カバレッジで網羅されるパターン

 astah*のプラグインで導出される状態遷移パスを確認してみましょう。

f:id:kz_suzuki:20200524172128p:plain
状態遷移のパターン

 導出された「遷移回数=1」の13ケースの遷移に、「無視」パターンも含まれていることがわかります。「遷移回数=2」でも同様で、ignore が2回続く(そして2回とも無視される)パターンも含まれています。

 一方で、cannot happen については、「仕様的不可」と「原理的不可」の区別がないため、起こりえない=テストできない とされ、テストケースに含まれません
 よってスイッチカバレッジのテストを行う際には、「起こりえない」がどちらのパターンなのかを峻別したうえで、「仕様的不可」については「仕様通りに動作する(イベントが発生しない)こと」を個別に確認しなければなりません。

*1:ツッコミどころはあるかもしれない。ドア開での「一定時間超過」とドア閉&解錠での「一定時間超過」を同じイベントとして扱っていいのか、とか。

英単語の発音を様々なシチュエーションで聴いて学ぶ、Youglish

 英語の勉強についての雑談です。

 英単語の中には、どうも発音がしっくりこない!というものがありますよね。
 ここ最近で思い当たるのは、rationalerational だと「理性的な」「合理的な」という意味ですが、e が付くと「論理的根拠」「理由付け」みたいな意味になります。
 ちなみに発音記号を見てみると

  • rational rǽʃənəl
  • rationale ræ̀ʃənǽl

 ・・・いや、わからんて。「伸ばす」っぽいことくらいでしょうか。

 そういう時に、発音を調べるだけならオンライン辞書でもわかります。たとえば Cambridge Dictionary ですね。

dictionary.cambridge.org

 さらに、「文章の中での使われ方」も含めて知りたいときに有効なのが、YouGlish
 無数にあるYouTube動画から、その単語を使っているタイミングを次々に見られるWebサービスです。

youglish.com

 キャプションも付いている*1ので、文脈もわかりやすい。
 TEDや著名人による演説が多いので、面白そうならそのまま観てもいいと思います。
 画面イメージはこんな感じ。

f:id:kz_suzuki:20200509063649p:plain
YouGlishのイメージ

 このサービスで、rationale は、気取った感じに「ラショナ~ル」と伸ばせばまあそれっぽくなるのかなとわかりました。発音がうまくなるわけではないが・・・。

 また先ほどオンライン英会話で初めて出会った、furlough。floral っぽいから、お花関係かしら?うふふ…と思ったら、「レイオフ、自宅待機」。。。
 意味はともかく、発音もイメージできなかったんですよね。YouGlishで確認してみると別にそんなややこしくなくて「ファーロゥ」みたいな感じでなんですけど、聴かないとわかりませんでした。

 そんな感じで、「いろんな人による発音を、いろんな文脈で聴く」ことを目的として、Youglish、お勧めします。

 なお、発音を調べてみてわかった大事な気づきは、以下の2つです。

(1) really と rarely は、一生聴き分けられない。
(2) -based って、「ベースド」じゃなくて「ベースト」じゃない!?

dictionary.cambridge.org

*1:というか、自動キャプションを付けられるからこそ、単語を拾ってこられるのだろう思いますが。