第190回： 「ソフトウェアテストしようぜ」7 洗濯機（後編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「洗濯機」のソフトウェアテストのとっかかりの話を書きました。
というのは、リナさんから以下のツイートをいただいたからです。
次回のテーマの洗濯機むずかしすぎて無理でした😭洗濯機の普通普通じゃない。。。洗濯板ならギリギリわかるかもしれない
— リナ？ (@____rina____) August 7, 2022
第188回： 「ソフトウェアテストしようぜ」5 扇風機｜Kouichi Akiyama #note https://t.co/RNN5M1vpQx
この「むずかしすぎて無理」（もちろん、謙遜されてのツイートですが……）という感覚ですが、私はテストをつくるときに謙遜なしでいつも同じようなことを感じています。
私は【難しいから面白い】と思うことにしています。
そう思ったうえで、「自分はどのようなとっかかりからテストをつくっているかな？」とふりかえって書きました。
結果としては、前回の「おわりに」に書いたとおり、
私はテストを考える前に、その製品の企画書を読み込み、競合機のウェブページを読み込みます。
それはテスト対象が与えようとしている「価値」について、細かく言うと、「利用者の利便性（GAIN）を高める機能」と「利用者の苦痛（PAIN）を減らす機能」を知ったうえで評価をしたいからです。
に思い至りました。
GAINとPAINを書き出していると、テストをしたいことがモリモリわいてきます。（笑）
きちんと学びたい方は、この辺のサイトなどを一読したうえで、バリュー・プロポジション・キャンバスという図を描くと良いと思います。
書籍で学ぶときには、以下の本となります。
※ Kindle版をリンクしましたが、紙版の方が使いやすいです。また、本に期待しすぎないようにしてください。情報としては上でリンクしたサイトからそんなに増えるものではありません。
ですから、知識よりも実践すること、実践した後に記事や本を読みなおすことが大切です。
「バリュー・プロポジション・キャンバス」で検索してフォーマット（例えば以下）を入手して、あとは、みんなで付箋をペタペタ貼って侃侃諤諤話し合うのがいいと思います。
「顧客の悩み（ペイン）は提供する機能（ペインリリーバー）で本当に取り除けるかな？ その確認のテストはどうしたらいいかな？」って話し合うことが大事です。
「バリュー・プロポジション・キャンバス」をつくってみたらJaSST nanoで発表すると、みんなの参考になって良いのではと思います。
今回は洗濯機のテストの続きです。ステップ1まで終わりましたので、ステップ2からです。
≡ テストを作成する（ステップ2）
第2回で書いたとおり、ステップ2は、「仕様を網羅するテスト」です。
仕様はマニュアルにありますが、使用者ができることは操作パネルにあることです。
仕事で、テストをするときには、「誤差因子」を考慮したテストもします。
操作パネルはあくまでも「信号因子」（＝ お客様の意思、、、洗濯機への指令）です。
「洗濯物の種類」とか、「設置環境」のような「誤差因子」（＝ お客様の使用条件、、、6W2Hや3W……下記例参照）に対してどれだけロバストか（＝期待通りに働くかどうか）を評価しますが、それは、ソフトウェアの評価というよりシステムの評価となります。
この辺の品質工学の考え方をしっかりと理解したいときには、『そもそも品質工学』が分かりやすくて、正しいことが書いてある（残念ながら世の中には、正しくない品質工学もどきを教えるコンサルタントもいらっしゃるのです……）のでお勧めです。
■ 表のテスト
結論から書けば、今回は、「シーケンスカバリングアレイ」というテスト技法で仕様を網羅するテストをつくります。
今回、網羅したいことは「操作の順番」です。操作パネルを見ると「ふろ水」、「水流」、「水位」、「予約」、「洗い」、「すすぎ」、「脱水」、「コース」、「スタート・一時停止」、「切」、「入」の11個のボタンがあります。例えば左から順番に操作する等、想定した操作では問題がないのに「ある順番で操作すると不具合が出る」といったバグを見つけたいからです。
「スタート・一時停止」、「切」、「入」の3つのボタンについては洗濯条件を設定するためのボタンではありませんので外して考えます。
また「コース」ボタンは「洗い」（1分～12分まで1分単位）、「すすぎ」（1回～4回）、「脱水」（なし、1分～9分まで1分単位）について、それぞれのコースに合わせたプリセット値を設定してくれるもので、はじめに操作することが決まっているので外します。
それでも、「ふろ水」、「水流」、「水位」、「予約」、「洗い」、「すすぎ」、「脱水」の7個の洗濯条件設定ボタンが残ります。
※ コースボタンと「洗い」、「すすぎ」、「脱水」の関係は、本当はもう少し複雑です。（そこだけを抜き出したテストが必要です）
さて、操作のテストといえば、この連載の第3回、第4回で状態遷移図をつくってGIHOZに入れてテストケースをつくったことを思い出します。
第4回の状態遷移図とGIHOZが生成した状態遷移表を網羅するテストを再掲します。
洗濯機の操作パネルの状態遷移図をGIHOZで描いてみます。
状態は「洗濯条件の設定」の一つですが、イベントは、上に書いたとおり「ふろ水（の条件設定）」、「水流」、「水位」、「予約」、「洗い」、「すすぎ」、「脱水」の7個です。
できあがった状態遷移図はこちらです。
状態遷移図を書いたら、テストケースを生成しましょう。「状態遷移表とテストケースを更新」ボタンを押すだけです。GIHOZ、すばらしいです。
7件のテストケースが生成されましたが、順番らしいものはでてきません。
そりゃそうです。有効遷移と無効遷移のテストケースをつくるだけですから。順番をつくりたいなら、生成するテストケースに「1スイッチテスト」を加えて「状態遷移表とテストケースを更新」ボタンを押します。
49件のテストケースが生成されました。
「ふろ水」、「水流」、「水位」、「予約」、「洗い」、「すすぎ」、「脱水」の7個のイベントの前後関係なので、7×7=49です。
こちらの49件のテストケースを実行すれば、任意の2つのイベント（操作）の前後関係が網羅的にテストできます。任意の3つなら「2スイッチテスト」を加えて「状態遷移表とテストケースを更新」ボタンを押せばよいです。
343のテストケースが生成されました。単純な表ですが、手作業でつくると誤りが起こりかねないのでツールの有り難さを感じます。
7個のイベントを3回選んだことなので、7×7×7=343です。
扇風機のテストの回で、
難しいテスト技法を駆使したテストもいいけれど、全数テストができるなら、何も考えずにそちらに振ってしまおう。
と書いたとおり、この343件のテストケースを実施するのもありです。また、「同じ操作を繰り返す必要があるか？」ということに気が付いて「同じ操作を繰り返さない」という前提に立てば、
7×7×7=343 を
7×6×5=210
に減らすことができます。2回目のイベントは1回目のイベントを除いた6つになり3回目は更に一つ減って5個のイベントから選ぶことになるからです。
でも、「洗い時間」、「すすぎ回数」と設定した後に「洗い時間」の設定を変えたくなることだってありますので、『同じボタンは押さないことにしていいのかなあ？』と、疑問が残ります。
以上のことから、私なら343件のテストを実施します。
ところで、343件のテストには時間がかかります。
実際に洗濯をしたら、“すすぎ”に時間がかかるので、1回のテストに結果確認を含めて平均で1時間かかるとして、343時間です。1日5時間で67日です。
※ 「1日5時間」というのは、私がテストマネージャーをしていたときの見積もり方法です。テスト設計者が計算で求めたテスト時間の見積もり総和を5で割ることで、そのテストが何日かかるかを計算します。そして、その値をテスト工期の計画値に使います。
67日も操作順序のテストはしたくないので、「操作の順番によらず、その設定項目が洗濯機の動作に使われる」ことを確認できるように「観測容易性」、「制御容易性」、「分解容易性」を高めるテストツールをつくっておいて、テストをすることでしょう。それでも（1分/テストケースになったとしても）、6時間かかります。
（自動化すると思います）
以上のことから、343件のテストはするとしても、実際に洗濯を行うテストはできそうにないので、シーケンスカバリングアレイというテスト技法を合わせて使用します。どんな技法かは、以前書いた資料をご覧ください。
要点としては、例えば、aからgの7個の操作の順番を考えたときに、
全ての順序： 7×7×7×7×7×7×7=823,543
重複無し： 7×6×5×4×3×2×1=5,040
任意の3つの全順序： 12
と網羅基準を変えることでテストケースを減らしている技法です。（どの網羅基準が適切なのかはテストのコンテキストによって違います）
ただ、上記のPDFにあるNISTのリンク先のページはすでになくなっています。今のページはこちらです。
手順としては、こちらのウェブサイトの「SEQUENCE COVERING ARRAY LIBRARY」のところにある「test.3.x.csv」（xは操作数）というファイルをダウンロードして使います。今回でしたら7個の操作なので「test.3.7.csv」です。
ファイルをエクセルで開くとこんなデータです。
あとは、中にある7個の数字（０～6）を操作に対応させるだけです。
設定する値の組合せまで考慮すると、結果としては、以下の表の16回のテストを行います。テスト件数が少ないので、実機を用いて洗濯をして、じっくり観察します。
テストの実行時には、一番右側の“順番”列（この列がシーケンスカバリングアレイのtest.3.7.csvに対応します）を見て、操作する順序を把握して、操作するときに、他の列のセル内の値をセットします。
操作を3つ取り出すと、その全順序（3! = 6種類）が一番右の列にある下表に抜き出した12のパターン（13行以降は繰り返しなので）のどこかに含まれています。
『なんか難しそうなテストだなあ』と思われたかもしれません。こんなテストをしなくていいことをレビュー等で保証出来るともっと良いと思います。
実務として、このテスト技法（シーケンスカバリングアレイ）を使いこなしてほしいとは思っていません。実務的には、順序のバグの有無が気になる操作対象を5個に絞って、GIHOZの状態遷移テストで2スイッチテストを設定して、125のテストケースをつくって実行するほうが良いと思います。
どうしても操作対象を絞れないときにシーケンスカバリングアレイがあったなあと思い出してトライしていただければ十分です。その判断ができるために違いや考え方が伝わるといいなと思って書きました。
■ 裏のテスト
今回も、意地悪な条件を考えます。
気になるのはもう少し大きなレベルのユースケース（特に、代替フローと例外フロー）です。ユースケーステストについては、こちらをお読みいただければと思います。洗濯を途中で止めて、設定を変更して再開するテストなどをしたいです。
また、チャイルドロック（安全のために動作中は洗濯機の蓋が開かない機能）についても、健康被害につながりますので念入りにテストをしたいです。
≡ 次回のお題
次回のお題はこちらです。
CDプレイヤーです。操作は、CDを差し込んだらあとはリモコンだけです。リモコンはこちらです。
マニュアルは下図のとおりです。
ああ、私のは古いので今の仕様と若干違うけど、細かいことは気にしない。
これまでの例題と比べ、機能が豊富なので、いきなりテストをつくるのは困難と思います。
まずは、テスト分析からとなります。
テスト分析とは？ と思われた方はテスト設計コンテストのチュートリアル動画をみるといいですよ。
≡ おわりに
今回は、「洗濯機」の仕様を網羅するテストがテーマでした。
状態遷移図は、操作の順番に制約をかけたものだけれど、今回のように、どの順番でも構わないつくりになっていることが多いものです。その方が、ユーザーは便利ですから。
私の経験では【ユーザー認証】について、“先に認証しておけば動くのに、あとから認証したときには動くはずの機能が動かない”なんてことがありました。
さて、次回のCDプレイヤーですが、テスト分析という普通はあまり考えないかもしれないけど、したほうがよいプロセスの説明となります。いきなりテストケースをつくりたいところなんですが、ぐっと我慢です。
先に書いておきますが、「テスト分析＝マインドマップ」ではありません。相性が良いのは確かですし、次回、私もマインドマップを描くと思うけど。