「IoTと、テストへのインパクト」 #IoTテストアドカレ(17)

はじめに

　この記事は、IoTのテストに関するネットの記事を読んでいく、「IoTテストアドベントカレンダー」の17日目です。16日目はコチラ。

kzsuzuki.hatenablog.com

プロファイル

タイトル: 『IoT and it's Impact on Testing』
著者: Bob Crews, President and Co-founder of Checkpoint Technologies
参照サイト: Zephyr

ポイント

IoTデバイスとそのテストの特徴

Dr. John Barrettによると、IoTデバイスが備えている特徴は以下。
- ユニークな識別子
- ワイヤレス通信
- センシングや測定を行う能力
- 組み込みエレクトロニクス
モバイルデバイスのテストでは、タッチスクリーンでのジェスチャーや位置情報の検知といった、新しい考慮事項が加わった。スマートデバイスでは、センサーからの入力を考慮する必要がある。たとえばフィットネスデバイスであれば、脈拍、体温、位置、標高、運動の様子など。
デバイスは、収集したデータを人間が見られるようにしたり、モバイル機器と同期したり、クラウドにデータを送ったりする。どんな状況でも装着できることを確認するには、複雑なテストが必要になる。

テストケースの例*1

　以下のようなテストケースの例を考えてみる。

テストケース名: ヘルスフィットネスデバイス v3.2の、氷点下における、3時間の高い活動レベルでの使用
テストケースの目的: センサー機能と、長時間（3時間）の高い活動レベル（ジョギング・ランニング）を通したデータ読み取りの正確さを、氷点下（摂氏0度以下）で確認する。
テスト対象: デバイスは以下のようなモデルに合わせてプログラムされている。

性別: 男性

体重: 84Kg

身長: 183cm

テストステップ

ステップ#1

アクション: プログラム済みのデバイスをテスト対象の腕に正しく装着し、デバイスが露出している（衣服に覆われていない）ことと、確実なモニターのために肌に接していることを確認する。

期待結果: なし

ステップ#2
（以下省略）

ネットワークへの接続がまばらで、位置の特定も不完全な、雑多な現実世界でのシナリオでテストを行う必要がある。
ユーザエクスペリエンスへの配慮が必要。文字の大きさや明るさは、夜にジョギングするユーザにとって十分か？着けたまま寝るユーザにとってまぶしすぎないか？
いろいろな人を採用してくる必要がある。選任のランナー、その人の体温や脈拍を測る人・・・。
自動化は重要であるが、スマートデバイスのテストでは効果が小さくなるかもしれない。環境をシミュレートしたり、「走る」といった物理的なイベントを自動化したりするのは、ブラウザの操作よりはるかに難しい。また、法規制のある業界（たとえば医療）では、現実世界におけるテスト以外は受け入れられないかもしれない。

QAはどう変わっていくのか

テストプロセスにおいて、計画と管理が今後さらに重要になり、QAのロールも変わっていく。
- テストのニーズの把握
- テストの検討
- テストに必要な人の検討、調整
- テストの結果の分析、対策の管理
- テストに関する情報の管理と関連付け（テストリリース、テストサイクル、テスト要求、テストケース、テストスクリプト、テストセット、テスト実行、欠陥、・・・）
IoTにおいては、多彩なデバイス・ハードウェア・OS、多数のユーザ、多くのデプロイツール、リリースツールなど選択肢が極めて多い。圧倒的な数の組み合わせのテストを管理できるようにする必要がある。

所感

　これまでの資料の中では珍しく、パーソナルユースのIoTデバイスを例にとった記事でした。規格、ワイヤレスプトロコル、セキュリティといった、他の記事で声高に主張されてきたポイントにはほとんど触れず、テストの最終工程に近いところに注目した記事です。ですので、これまで有効とされてきた自動化の力も弱くなっています。現実世界における実際のユーザによるテストにおいては、自動化できる範囲がどうしても限られるからでしょう。

　一方、この工程でのテストにおいては、テストシナリオ*2が重要になってきます。
　秋山浩一さんの『ソフトウェアテスト技法ドリル』において、シナリオテストは、「さまざまな視点を織り込んだシナリオを描いてそれをテストするという方法」と説明されています。そして「シナリオに闇雲にテストの支店を入れ込むとマトリクスになってしま」うため、以下の制約を設けるとしています。

人の動きを中心にシナリオを作成する: ある人が抱えている問題がソフトウェアを使用することで解決することを確認する
狭く深くシナリオを書く: 広く浅くはそれ以前のテストで確認済みのはずなので、問題の出そうなところや重要な部分を確認する

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

作者: 秋山浩一
出版社/メーカー: 日科技連出版社
発売日: 2010/10
メディア: 単行本
購入: 7人クリック: 153回
この商品を含むブログ (19件) を見る

　数学や論理に基づくテスト技法と比べて、「正解」の難しいテストと言えるでしょう。
　シナリオテストを導出するための標準的な技法は、これ以外あまり見たことがありません。たとえば鈴木三紀夫さんの2016年12月16日の一連のツイート（たとえば以下）が参考になりそうですが、「業務」とはまた違うんですよね・・・。

2011年のときの業務シナリオテストの説明って、こういうのだったの。
「業務シナリオテストのテスト設計は、ホワイトボックステスト的なものと、ブラックボックステスト的なものがある。
業務フローを使って制御フローパステスト。シナリオ構成要素を組み合わせて、組み合わせテスト。以上」
— 鈴木三紀夫 (@mkoszk) December 16, 2016