第191回： 「ソフトウェアテストしようぜ」8 CDプレイヤー（1. テスト分析の前編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「洗濯機」のソフトウェアテストの後編を書きました。
内容は、「操作順序を網羅しよう」でした。
トラブルのクレームが入った時に、「こういう順番で操作したら、したいことはできませんか？」と提案をして解決してしまうことがあります。
「回避策」ってやつです。バグを迂回して回避することによってユーザーの目的を達成します。
たまにしか行わないことなら案外「次回からそうするよ。ありがとう」と言ってもらえます。（言われた私は、テストで見逃していたことが心苦しいのですが、それはそれとして、応急処置として「回避策を提示すること」は大切です）
このようなバグは、恒久対策（バグ修正）を実施しておかないと、忘れたころに、再発して「あちゃー」となります。特に同一の職場の別のユーザーで発生すると「またか」と叱られます。
開発側からすると、「どうして、そんな使い方をするかな～」って言いたくなるケースもあります。
入社直後に新人教育の一環でコールセンターで電話応対業務を体験しました。
そのときに、「（お客様は）そんなイレギュラーな使い方をするんだ。マニュアルを読んでよ」って思いました。いや、当時は、【お客様の使い方が問題】とまで思いました。もちろん、思うだけで口には出しませんでした。
今思えば、お客様は、「1ステップでも手順が少なく済むと思えば、その順番で操作する」ものですし、「前提条件が整っているかを事前にチェックするよりも、取りあえずやってみて、なにかが不足していたら親切なメッセージで教えてよ」と思うものです。
私だって「インクの残量を確認せずにプリント指示」します。
そこで、前回は、操作順序を網羅する方法として状態遷移図を描いて2スイッチテストをつくる方法について説明しました。GIHOZを使えば一瞬で正しい表ができるので、お勧めです。
ええと。GIHOZ（青い会社＝ベリサーブさん）の回し者ではありません。
青い会社の本社は、私が働いている会社の最寄り駅（神田）の二駅先（水道橋）にあるらしいけれど、行ったことはありません。
西新宿に本社があったころには何度かお邪魔したのですが、もう会議室を借りての勉強会もすっかりなくなってしまったので、行く用事がなくなってしまいました。
GIHOZが提供しているテスト設計ツールのなかでは、この連載で何度も使わせていただいている「状態遷移テストツール」が好きです。「ペアワイズテストツール」も「パラメータ・値」をエクセルからGIHOZのテーブルへコピペできることを発見してから少し好きになりました。
「GIHOZ」はこの連載の「CDプレイヤー」の次のテスト対象にしようかと思っています。ウェブアプリのテストとしてちょうどいいから。
ところが、この方法（2スイッチテスト）にはテストケースの数がそこそこ多くなるという弱点があります。
k個の操作があるときに、3つの操作順序に限定しても、1番目と2番目と3番目の操作を自由にk個の操作から選べるわけですから、kの3乗個（k×k×k個）のテストケースとなります。4→64、5→125、、、下表のとおりです。
自動化をする（ロボットにボタンを押してもらう）としても、7個の操作対象について3つの全順序の網羅（343件）が私の我慢の限度です。
°(° ˆᴗˆ °)°｡
そこで、シーケンスカバリングアレイというテスト技法を紹介しました。シーケンスカバリングアレイを使えば、操作対象が10個あったときでも、網羅的観点で優先すべきテストを14件に絞り込めるからです。
シーケンスカバリングアレイで絞り込んだ14件のテストだけ実行すれば良いのかどうかは、テストの状況次第です。
状況次第ではあるのですが、10×10×10＝1000件のテストが必要な場合でも、シーケンスカバリングアレイの14件のテストを先に行っておくことは早期に重大なバグを検出するためのアイデアとしては悪くありません。
私はテストを考えるときにいつも「将棋崩し」という遊びをイメージします。全体を見て、取りやすくて高得点の駒を探してそこから取るイメージです。
もっとも、「そもそも、そんなに多くの操作対象の順序を気にする必要があるアーキテクチャーにするな」という話はあります。正論で王道です。
しかしながら、開発がかなり進んでから追加要求があって実装した機能は操作順序の考慮が不足していることが多いです。
開発途中の追加機能（いわゆる仕様変更＝仕変）が多数あると追加機能の単体テストは通っても、組合せや順序関係のテストが大変です。
こちらも、「仕変を許すな」という意見は正論としてあります。
私は、システムにセキュリティを高める仕組みを後付けして失敗しているところを何度も見ています。「ココだ！」というポイントを押さえてセキュリティ機能を実現していないソフトウェアをテストするときには十分に注意しましょう。
さて、今回はCDプレイヤーがお題です。CDプレイヤーはこれまでの題材よりも複雑なので【テスト分析】プロセスに絞っています。
絞っても長くなってしまったので、テスト分析の前半（テストアイテムの識別）だけとなります。
それでも今回は、いつもの倍の長さになってしまっています。
≡ お題（CDプレイヤー）の説明
今回のお題は、CDプレイヤーです。操作は、CDを差し込んだらあとはリモコン操作だけです。（本体にはボタンが付いていません）
リモコンのマニュアルはこちらです。
日本語のマニュアルもありました。
Ⅳになって、さらに機能が進化していますね。
私のは無印、、、30年位前に買ったものです。動く部品が少ない（CDを回転させる箇所だけ？）から故障したことがありません。今はスマホで音楽を聴いているのでほとんど使わなくなりました。
で、上の英語のマニュアルがⅢ用で下の日本語のマニュアルはⅣ用ということです。Ⅳは、Bluetoothとつながるのか。いいなあ。
でもAUXはなくなっているのか。
……そもそもⅣ自体、2015年の製品のようなので、今となっては中古しか買えないかも。
≡ テスト対象を理解する
毎回書いていますが、テストをつくる前に、テスト対象を理解することが何より大切です。
■ 機能を書き出す
私は、初めにテキストエディタを開いて機能を書き出します。今回なら、上のマニュアルをみてボタンの意味を書いていきます。抜けもれのないように左上から順番に。
今回は、リモコンでしたのでボタンから「機能」を探しました。これまでの例題でもリモコンが多かったですが、それは偶然ではなく、「リモコンはソフトウェアへの入力装置」だからです。エアコンもリモコンが無いと詰んでしまいますよね。
これが、PCやスマホのアプリケーションなら「メニュー」（リボンも同じ）になります。このときもメニューを順番に書き出します。さらに、「ｘｘｘ…」と「…」が付くメニューは選択するとダイアログが開きますから、その上のリストボックス等も書き出します。
キーボードショートカット一覧が付いているアプリケーションマニュアル（や仕様書）があったらラッキーと思います。何故なら、ショートカットは良く使う機能に短いショートカットを、あまり使わない機能に複雑なキーの組合せを持つショートカットを使うからです。
ファンクションキー、コントロールキーと何かのキー、Altと何かのキー、コントロールキーとAltキーを押しながら、、、とだんだん使用頻度が下がるようにつくられています。
機能のリストを書き出しながら「へぇ？そうなのか」、「ちょっと気になるな」と思ったことはメモしておきます。（今回はメモを太字にしています）
仕様書に書いてあっても写経（タイプ）します。同じ内容でも目で読むだけより書き写した方が記憶に残りますし、気づくことも多いからです。
このあたりは人によって違うところだと思います。書くよりも2回読んだ方が頭に入るという人もいるでしょう。
声に出して読むといいっていう人もいました。
私は、仕様そのものを書き写すことよりも、その仕様の意味（や要求）を書くことが多いです。
こんな感じです。
電源
・電源のオン・オフ
・アラームの停止（電源ボタンでアラームが止まるって変）スリープ
・アラームのスヌーズ（SleepボタンでSnoozeするってわかる？）
・おやすみ機能 10-90分（ソースが何でも働く？）
・アラーム音の選択（なぜこんなに目覚まし機能が充実してる？）ミュート
・音を消す（ミュート状態でCDからラジオに切り替えたらどうなる？）
・消した音を戻す（間に別の操作が入っても大丈夫？）ラジオ
・ラジオをつける
・FMかAMを選択する（前回どちらだったか覚えている？）CD
・CDをつける（CDを差し込んだら動き出す？ いつ使う？？ ラジオやAUXからの切り替えのみ？？？ ラジオからCDに切り替えたら再生も始まる？？？？ CDを聴いているときに押したらどうなる？？？？？）AUX
・外部装置を聴く（ステレオとモノラルでテストを分ける？）音量
・音量の上下（最大＋1上押する）プリセット
・押す：プリセットしたラジオ局を呼び出す
・押し続ける：ラジオ局のプリセット設定をする頭出し/トラック
・押す：ラジオとCDの次の場所や前の場所に飛ぶ（最後の次や最初の前は？）
・押し続ける：ラジオ周波数とCDトラックの早送り・早戻しプレイ/一時停止
・CDの再生
・CDの一時停止停止/イジェクト
・1度押し：CDの停止
・再押し：CDの取り出し（（イジェクト直後の）CDを吸い込む機能もあるかな？）Tune/MP3
・押す：ラジオとMP3のフォルダー移動
・押し続ける：ラジオとCDの早送り、早戻し（トラック移動との違いは？ MP3のこと知らなすぎる！）タイム
・時計の時刻設定のときの時刻変更
・アラームの設定のときの時刻変更プレイモード
・シャッフル、リピートへの切り替え（MP3のフォルダー単位のリピートは？ シャッフル＋リピートできる？？）
・TALK RADIO mode（なにこれ？）アラーム
・アラーム時刻のセット
・アラーム機能のオン・オフ
太字のところは、ピンポイントでテストします。
マインドマップを描くこともあります。
テキストエディタでタブインデントしておけば、コピペで一気にfreemindツールに張り付けることができます。
自分がやりやすい方法が一番と思います。
マインドマップを描いたあとに、短い単語にすることと、MECEに気を付けてノードの追加や削除をします。マインドマップを描いたあとには、テキストファイルは捨てます。（二つ同時にメインテナンスするのは面倒だからです）
そうそう、マインドマップって、描いた人以外には恐ろしいほど伝わらないから。気をつけて！
JSTQB的には末端のノードを【テストアイテム】と呼びます。末端のノードとは、テスト対象を単体テストを考える粒度まで分割した結果として見つかった「小さなテスト対象」のことです。
■ 上の作業は何をしたのか？
“はじめに”のところで、「今回は【テスト分析】プロセスのお話しです」と書きました。実は上で行った「機能を書き出す」という作業はテスト分析の一部です。機能を書き出した結果として、【テストアイテム】をみつけることができたのですから。
「なーんだ。そんなこといつもしているよ。テスト分析ってもっとモデル化したり、ペルソナをつくってユーザーのオペレーショナルプロファイル（ユーザーの使用頻度や業務課題）を分析して数式をつくったり、何らかのルールでテストの優先順位をつけたりする難しいアクティビティなんじゃないの？」と思われている方もいらっしゃると思います。
もちろん、ソフトウェア工学で出てくる「要求分析」などの技術を使いこなして、そのようなテスト分析を行うのは良いことです。
でも、テストよりも要求分析に興味があれば、そちらの仕事に従事できるように要求工学を学んだりBABOKやREBOK（Requirements Engineering Body Of Knowledge）を読んだり、大学に入りなおして勉強したりして上流工程の仕事に就いた方が良いと思います。そしてテストがしたくなったらまた戻ってきたらいいです。
このようなことを書きますと「要求工学の知識はテストに不要」と、、、「プログラミングができなくてもテストエンジニアになれますか？」という定番の質問（FAQ）と同じようなことをいう人が現れます。でも、どちらもそういうことではありません。
要求工学もプログラミング技術もソフトウェア開発の中でテストと隣接する技術ですから知っていればテストに大いに役立ちます。
ただし、全くプログラミングや要求工学に興味がない人でも素晴らしいテストを思いついて実施する人もいます。←そこをゴッチャにしない！
あと、テスティングを含め、それぞれの技術領域のプロになるのは大変だけれど、例えばプログラミングなら千行くらいの「プレゼンタイマー」とか、「Twitterもどき」とかをつくるアマチュアプログラマーになるのは簡単（数日～数週間の努力？）です。そして、そのようなアマチュアプログラマーやアマチュア要求工学者レベルの知見でも全くないよりはずいぶんとテストに役に立つものです。だから「本業にこだわらず、色々と首を突っ込んで味見してみた方がいいよー」といつも思います。
逆にビジネスアナリストやアーキテクトやプログラマーがテストを少し学ぶことも有効だと思っています。
「テストをするときに、テスト対象のソースコードを見たいです」という人の方が転職時にも有利だと思いますが、そのくらいなら努力すればなれます。プロのプログラマーになるためには努力だけでは無理で、プログラミングが大好きで続けても苦にならないという資質が必要です。（そうでない、サラリーマン・プログラマーもたくさん見てきたけど、あまり幸せそうにはみえませんでした。）
なんてこと思っていたら、榊原さんがいいことつぶやいていました。
I can accept failure, everyone fails at something. But I can’t accept not trying. - Michael Jordan
— Akira Sakakibara (@AquilaDC) August 24, 2022
名言だ。名言だよ。
「失敗してもいい、誰だって失敗するさ。でも、挑戦しないのはだめ。- マイケル・ジョーダン」でしょうか。
余談が長くなってしまいました。
書こうとしていたことは、「どんな機能があるか書き出そう」でしていたことの意味です。
これまでしてきたことは、「リモコンのボタンの機能を書き出す」ことでした。
サクッとソフトウェア工学の基本を勉強したいという人は、以下のサイトの石川先生の講義資料を読むといいですよ。
■ 分割方法
大きくて複雑な「テスト対象」を小さくて考えやすい「テストアイテム」に分割するときには以下の4つの方法があります。（多くの人が言っているので、誰が最初に言い始めたのか見つけられませんでした。清水吉男さんも似たようなことを仰っていました）
構成で分割する
今回やった方法はリモコンの構成がボタンからなっていることを使って、CDプレイヤーの機能を分割しました。
パソコンやスマホのアプリケーションなら「メニュー」で分割してもいいですし、扇風機なら「羽根」、「操作パネル」、「モーター」といった構成部品に分割してもいいです。
外部仕様書なら機能が並んでいることが多いですから、機能で分割してもいいです。時系列で分割する
時系列は分割するよりも、1で見つけた構成要素をグルーピングし、使う順番に並べるときに使うことが多いです。あとでCDプレイヤーの結果を示します。
カスタマージャーニーマップとかユーザーストーリーマッピングとかの手法を参考に、でも、フォーマットなんて気にせずに、大雑把に時系列にシステムを使用するときの流れを書いてそこに細かい機能を張り付けていきます。例えば、宿泊予約システムなら「宿泊情報の提供」→「予約申し込み受付」→「予約」→「リマインダ」→「精算」などの流れがあり、例えば「予約申し込み受付」のなかに「空き部屋検索」や「人数、宿泊日の入力」などがあり、、、と時系列で考えて分割する方法です。状態で分割する
CDプレイヤーですと音楽の再生状態などで分割します。「CD再生中の状態のときにセットしておいたアラーム時刻になったらアラームが鳴動すること」などのテストをつくります。
また、上に書いた宿泊予約システムなら、宿泊のステートには、「未予約」、「予約」、「宿泊中」、「宿泊後」、「代金支払後」といった状態があって、「代金支払後」でないと領収証を発行する機能は使えないとか、そういうことがありますので、テストします。
また、開発者は状態よりもプロセス思考で処理の流れをプログラミングすることが多いですから、テスト側では状態で分けてテストをすると、「ユーザーが退会すると、そのユーザーの領収証を発行する方法がない」といったバグ（仕様の不備？）が見つかることがあります。共通と固有で分ける
こちらも2と同じで、構成要素をグルーピングする（これを綜合といいます）ときに使います。「母体と派生」もこの一種です。
CDプレイヤーでは「音を鳴らす」という共通部分とCD/ラジオ/AUX/アラームという固有部分に分けてテストをつくります。
というように、分割をするときには、上記の4パターンを意識するとうまくできます。基本は構成を使って要素に分けて、それを時系列のカスタマージャーニーマップに張り付けるのが良いと思います。
■ CDプレイヤーを時系列で分割
それではCDプレイヤーで実施してみます。
上に書いたとおり、「時系列で分割」は、実際には、見つけた構成要素を「時系列でグルーピング」する作業となります。
結果はこんな感じです。
こちらの表ですが、次回実施する「テストアイテムのグループ間の関係からテスト条件を見つける」作業のときに使用します。
と、今回は料理で言えば下拵えでした。ちょっと大きいテストのときにはあとで効いてくるのでおすすめします。
≡ おわりに
今回は、「CDプレイヤー」のテストがテーマでした。大きなテストとなるので、テスト分析の、それも前半だけを行いました。
以下は、ASTER主催のテストセミナーで2020年あたりから私がテストケースをつくるまでの流れの概要を説明するために使用しているPFDです。
今回は「② 分析1」のところについて書きました。②では、テスト分析の前半にあたり、「テスト対象をテストアイテムに分割」するところまでを行います。その後、上述のようにゆるく時系列でテストアイテムの再構成をするのですが、ASTERセミナーは初級者向けなので、そこまでは説明していません。
JSTQBでは「テスト分析した結果、テスト条件が得られる」としています。
ということで、次回は「③ テスト分析2」の「テストアイテムからテスト条件」を見つける作業について書きます。具体的には、
個々のテストアイテムからテスト条件を見つける
テストアイテムのグループ間の関係からテスト条件を見つける
の2つの話を書く予定です。
「① 準備」の内容が気になる人がいらっしゃるかもしれませんので、説明のスライドだけ張っておきますね。（ついでに「② 分析1」も）
「HAYST法じゃないんですね？」という声が聞こえた気がするけど気にしない。
