![見出し画像](https://assets.st-note.com/production/uploads/images/84166765/rectangle_large_type_2_36c359ff9efe5216ae08d63f12eacf97.jpeg?width=1200)
第188回: 「ソフトウェアテストしようぜ」5 扇風機
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は、「シーリングファン」のソフトウェアテストの話を書きました。
内容としては、「ファンとライトの関係は無則だから、まずは、別々に状態遷移テストをして、そのあとに手を抜いた組合せテストをしよう」という話でした。
「テスト技法なんて知らないよー。」と思われた方もいるかもしれません。そうですよねー。長文でしたし。
けど、「状態遷移テスト + 組合せテスト」は、色々な場面で使うことが多いですし、めんどくさいテストケースの生成はGIHOZがやってくれるので、状態遷移図とラルフチャートが描ければ、、、ってそこが深かったりするのかもしれないけど、、、トライしてみてください。
何度かやってると自信がつくものですよー。
ということで、今回は必ずしもテスト技法を必要とはしない簡単なお題です。
≡ お題(扇風機)の説明
前回の再掲になりますが、お題の説明です。
![](https://assets.st-note.com/img/1659771628869-r8D1O0PFpa.png?width=1200)
キャッチイメージを見ての通り、我が家の扇風機がお題です。
実は、私、扇風機が大嫌いなんです。部屋が暑いのは辛いのでエアコンは好きなのですが、扇風機の風にあたるのは嫌いです。
私が子供のころには、学校(小・中・高)にはエアコンはありませんでした。冬は“だるまストーブ”でしたし、夏は窓を開けていたし、本当に暑い時期は夏休みでしたから。
ひょっとしたら当時でも私立にはあったのかもしれません。
でも私にとっては、その当時、エアコンと言えば、デパートと図書館です。
我が家にエアコンが来たのは高校生になってから。それまでは扇風機でしたので、扇風機大好きな子どもでした。
嫌いになったきっかけは、「扇風機に当たりながら寝ると体温が奪われて死ぬ」とテレビで知ったこと。これ、あながち嘘(都市伝説の類)ではないそうです。
今では、扇風機の風に当たるのも嫌という体質になってしまいました。
ということで、上の写真の扇風機も触ったことすらありませんでした。
だいたい、扇風機って風に当たって涼しいだけじゃないですか。外からの電気をモーターの回転に変えているのだから、部屋の温度は、むしろ上がるはずです。
エアコンと前回のシーリングファンで空気を攪拌するだけのほうがいいんじゃないかなあ。
無駄話はさておき、扇風機のテストですが、意外と機能が多い(知らなかった!)ので、「タイマー」機能のみをお題とします。
マニュアルのタイマー部分の記載はこちらです。
![](https://assets.st-note.com/img/1659772689375-DYKymKH1xl.png?width=1200)
![](https://assets.st-note.com/img/1659772706832-Y1LkLTCvxF.png)
≡ テスト対象を理解する
毎回書いていますが、テストを作る前に、テスト対象を理解することが何より大切です。
でも、今回は嫌いな機器なので気が乗りません。
といってもいられませんので、タイマー関係で気になる個所をピックアップします。
![](https://assets.st-note.com/img/1659772959188-Ph0yzl8IWr.png?width=1200)
図まで描いちゃって怪しいですよね。仕事で仕様書を読むときにも図を見て、『ああ、これは開発者が頭を整理するために描いたものだな』って思ったら図に描かれた内容を理解するようにしています。
今回、タイマーでできることは、「入りタイマー(1,2,4,6)」と「切りタイマー(1,2,4,6)」の設定だけです。
1, 2, 4, 8ではないことも気になるといえば気になるけど、こんなところでわざわざシフト演算で実装する人はいないだろうとも思います。
≡ テストを作成する(ステップ1)
それでは、今回も2ステップに分けて、テストを作っていきます。まずは、“私はこういうテストを考えた”ってことを書きます。
今回は、
設定のキャンセル
をテストしたいと思いました。
![](https://assets.st-note.com/img/1659773366499-aotCaceTXu.png?width=1200)
と
![](https://assets.st-note.com/img/1659773411317-0vLXZWFN1a.png?width=1200)
があるのに、「キャンセル」する方法がメインの枠部分に書いていないからです。
![](https://assets.st-note.com/img/1659773550864-0PKk3njFcX.png?width=1200)
上のように「ご注意」に「時間変更できません。設定後の解除・変更の場合は、一度運転を停止してください」と書いてあります。(付加的に書かれたところにバグが潜んでいることがよくあります)
きっと仕様書にも同じようなことが、同じような場所に書いてあるに違いありません。そして、開発者が仕様書を隅から隅まで熟読するとは限りません。
私の感覚では「OK」ボタンで時間を確定した後に、「OK」ボタンを押したら「時間を確定する前の状態に戻る」仕様もありと思います。
エレベーターの「階」ボタンだって、降りる階の番号を押し間違えたら、連打することで解除できるじゃないですか。
扇風機の開発者が、「そういうもの」と変わらないと誤解しているかもしれません。
で、試してみました。結果は、マニュアル通りで「OK」ボタンの“再押し”や“連打”ではキャンセルできませんでした。(さすが、日立製!?)
≡ テストを作成する(ステップ2)
次にステップ2です。
■ 表のテスト
これまで、FRAM(第2回)、状態遷移の1スイッチテスト(第3回)、状態遷移表のテストとペアワイズテスト(第4回)と続いてきたので、「網羅的なテストにはテスト技法を使う」と思い込んでしまわれた方がいらっしゃるかもしれません。
実は、私はそう思っていました。
ところが、以前も書きましたが、「巨大化しないのなら、デシジョンテーブルを作らずに全組合せのマトリクスを作ってテストする方が良い」です。
どこからが巨大? という話もありますが、実際のところ、全組合せはすぐに1000とかになりますので、「全組合せでもいいや」って思ったら全組合せにして、「全組合せは無理」って思ったら【適当に間引くのではなくテスト技法を使って合理的に絞り込む】ことをお勧めします。
それで今回のケースは、上に書いたとおり、
今回タイマーでできることは、「入りタイマー(1,2,4,6)」と「切りタイマー(1,2,4,6)」の設定だけです。
入りタイマーと切りタイマーの値の組合せは、4x4(設定しないを含めても5x5)しかありません。
また、ボタンは2つなので、順序も「入設定 → 切設定」と「切設定 → 入設定」の2通りしかありません。
単純に全組合せと全順序を作っても、5x5x2=50パターンです。
私なら、Excelでこんな2枚の表を作ってテスト漏れが無いようにチェックしながらテストします。
![](https://assets.st-note.com/img/1659775732023-sEG5uqOngi.png?width=1200)
この表を作るのに5分もかかりませんでした。期待結果を埋めてからテストするので実際にはもう少しかかるけどトータルで10分もあれば楽勝です。
テスト実行するときに「待ち時間」がかかるけど、扇風機を50台用意したらいいんです。
仮に、タイマーが「1分刻みで6時間まで設定できる」という仕様でしたら、360x360x2=259,200となりますので、全数テストなんてやってられません。
そういう時には、テスト技法を使うしかありません。設定時間を同値分割してデシジョンテーブルテストをするかな。
「360x360x2=259,200という複雑なときには同値分割して代表値だけテストして、5x5x2=50と簡単なときに全数テストをするなんて、つくる側の都合だよね? それって変じゃない?」と思われた方もいらっしゃるのではないでしょうか?
当然の疑問です。
でも、簡単な普通の扇風機は、5,000円と安いけど20万台売るからトータル10億円の売上で、複雑な方は50,000円と10倍高く売れるけど200台しか買い手がなければ、トータル1,000万円の売上、、、だったとしたらどうでしょうか。
テストをするときには総売り上げに対してどれだけテストにお金をかけられるかを考えることが大切です。
総売り上げに対して4%テストに投資するぞとしたら、4,000万円と40万円となります。
また、20万ユーザーもいたら思いもよらない使い方をする人もいるでしょう。しかも、全世界に安心して(サポートコストをかけずに)売るとしたら、、、そう考えると全数テストも悪くない選択です。
また、簡単な機能の設計と実装は経験が少ない新人に割り当てるものです。そして新人さんは思いもよらないことをしでかすものです。
例えば仕様に書いていない【前回の設定内容を記憶しておく】などです。……よかれと思って。
そうやって成長していくのですから、そこはテストの方で「どんな球が来ても取ってやるから安心しろ」っていう戦略が良いと私は思います。
■ 裏のテスト
今回も、意地悪な条件を考えます。
ボタンの同時押しとかでしょうか。まぁ、テスターならボタンを見たら「同時押し」と「連打」と「長押し」はやってみますよね。
あとは、タイムアウト(設定は1分以内)の仕様が1だけではなく、2, 4, 6のときにも正しく働くことを確認するかなあ。「長押し+タイムアウト」の合わせ技とか。
≡ 次回のお題
次回のお題はこちらです。
![](https://assets.st-note.com/img/1659790621876-NixQ6WLWGk.jpg?width=1200)
洗濯機です。
マニュアルはこちらです。でも、洗濯機のマニュアルなんて読みませんよね。
普通の洗濯時のテストを考えてください。
≡ おわりに
今回は、「扇風機」のテストがテーマでした。
難しいテスト技法を駆使したテストもいいけれど、全数テストができるなら、何も考えずにそちらに振っても良いと思います。
自動化できたらなおよいですし。
本文に出てきたように、何十万ものテストケースになったら自動化する場合も、テスト技法を使って有効なテストケースに絞るほうが良いです。そうしないと、バグがあったときに、同じ原因のバグが大量に報告されるからです。
さて、次回の洗濯機ですが、テスト技法を使うと思います。
こうしてお題にしてみると、ナショナル、ODELIC、日立、東芝と色々なメーカーに囲まれています。組み合わせて使うAV機器は同じメーカーで、、、ということもないなあ。
(テレビは東芝のREGZAで、Blu-rayはパナソニックのDIGAだから)😅
◀前の記事へ 次の記事へ▶
この記事が気に入ったらサポートをしてみませんか?