自己紹介
二木
吉澤
- 日本(にっぽん)電気
- デバイス経験が多い
- IoTの下支え中心
- 最近は品質向上活動
- IoTは何をテストするのかよくわからなかった
辰巳
- ソフトウェアの検査
- SQuBOKに関わっていたり
- テストの歴史的な話
- 昔からテストをやっていた人からの意見を言いたい
IoTの定義
- インターネット上のサービスと接続されたデバイスあるいは相互接続されたデバイスによって実現されるサービス
- デバイスとサービスは他の組織が提供することを相互接続して利用することがある
keynoteより
- ハッカーがハンドルから手を話しても自動操作しているのを使うことで事故を起こさせる
- ジープ
- ISOでも3層ドメインになっている
- 入り組んだサービスについてもISOでモデリングされている
デバイス側もどういうふうにやり取りするのかはISOやIECでモデリングされている
これらからどんな課題があるのか
二木
- ジープのハッキングした人達はセキュリティのメンバー
色々な管理項目が増える
- 例えばアイデンティティ管理とか
- いっぱいありすぎて蜘蛛の巣のようになる
近未来のIoTワールド
- Cloudブローカーみたいにサービスブローカーが出てくるかも
- デバイスとサービスのひも付けの間にデバイス管理をするレイヤーが挟まるだろう
雲の上から見たIoT
- IoTもサプライチェーンを構成していくだろう
- IoTは閉じた世界ではなくなるだろう
- ワイパーを動いているかどうか見てその地域の天気を調べる仕組みとかしている
- 想定を超えた使われ方をしていくかも
- セキュリティ屋の心配事
吉澤
- デバイス側から話す
- デバイスに求められる機能は3つ
- センサ
- アナライズ
- アクチュエータ
- 従来は限られた世界でちゃんと動くこと
- お約束に従ってちゃんと動くことを保証すれば良い
- IoTになっていくことで、効率化しないと大量のデータを処理できないのではないか
- それとともにセキュリティも気をつけなければならない
- 得体のしれないものとつながる脅威
- 外からの脅威によって
- バルス
- 内部の脅威
- 保証されない
- 意図しない年数使われる
テスト
- 今まで以上に一つ一つがきちんと動いていることを保証する（十分性の保証）
- 今まで以上に行わなくてはならない
- セキュリティ
- 大量データや環境などを含めた組み合わせテスト
- 通信制の確保
- データをチェックする境界線
- 自分はどこまでテストすれば良いのか
二木
- どこまで想定外を排除できるか
- 自分のところはきちんとテストする
- 仕様にこういうデータは入ってこないんだからチェックしなくて良い！と言われた
- セキュリティも製品やサービスの一部だという意識を
- 脆弱性は基本的にはバグである。
- パフォーマンスや運用に影響をあたえるものが脆弱性である
- 設計時にセキュリティ機構を組み込む
- 実装時のバグ潰し
- APIに対する異常な取り扱いに対する体制のチェック
- 500エラーで返されるとしめた！（サーバーエラーになっている可能性あり）と思う
- リスクの高い使われ方を如何に潰していくか（サーキットブレーカー）
- APIを使ってごっそり抜かれないように、必要以上のところへのアクセス制限をかける
- 大量データを抜けないかどうかもテストの観点
辰巳
- ビジネスの観点からアプローチを披露して欲しい（松岡）
- つながった上でIoTをどうやってやるのかという観点
- 使う側/活用する側のシステムのテスト
課題
- テストの対象の見極め
- 上位から見て着目すべきところは？
- ビジネス視点での評価
- IoTはビジネスチャンスとして考えた時に、テスターとしての役割は？
課題解決のために
- テスターが持つべきスキル/素養
- テスト技術の研究成果の活用
- 例えば、コンポーネントTesting技術の適用とか
- つなぐための標準化、規約化への関与
- テストのための仕組みも標準の中に取り込む
- テスターからの積極的な提言が必要
- テストのための仕組みも標準の中に取り込む
- 組織的な取り組み
- テスターの専門分化
- より深くやるテスターが必要になる
- デベロッパーとテスターの役割分担の追求
- テスターの専門分化
- テスト環境、標準化検証環境の整備
- テストラボ
- 標準検証スイート
- テストのエコシステム
- オープンイノベーション的テスト連携モデル
Jon
- 二木さんが提案していた脆弱性とかを悪いことする人達はお金になるので一生懸命研究すると思うので、頑張ろうとするでしょう
スペースシャトルのような巨大アプローチの中でどういう風にしたら良いと思うか
過去の大型案件を考えると、小さなエリアに分けてそれをだんだん組み合わせてやる
- テストは何階層もあり、デバイス、メーカー、ドメイン、政府のテストがあると思う
- 製品レベル（モバイル）、ネットワーク、IT、クラウド、全てを組み合わせてIoTのテストになる
- プロセスレベル、プロダクトレベルなど、各レベルで標準化しなければならないが、策定までには時間がかかるだろう
- フェールセーフのためのサーキットブレーカーを入れるのは良いことだと思う
- IoTの世界においては、大型のシステムでは故障に直面すると思う。
- ユーザーがデバイスに接続方法が様々あり、全てのレベルでテストベッドが必要
- IoTと一口で言っても、サイバーと物理的な世界でのものなので、生命にも関わったりすることがある
松岡
- 脆弱性はバグなのか、バグでないのか
- 私は二木さんと吉澤さんの両方の経験を把握している
- 脆弱性はバグと捉えている
- バグではなく仕様上の欠陥ということもある
- 上位から降りてきたもののフォーマットが自分が用意しているフォーマットと全然違ったことが
吉澤
- 「標準」が今は無いが、標準を使って複数テストすると思うが、標準を使わなくなった世界ではどうするか？
- 困りますね
- 標準があれば一つ一つ確認はできる
- ただし、標準があっても、捉え方が違ってしまうと希望通りの性能が出せるか微妙ではある
- 現に上の人と下の人で変わってきてしまうと思う
辰巳
- 標準化はまだまだこれからだと思うが、プロジェクトは進むよね？その上でどうすれば良いのか？ビジネス側では何を見れば良いのか
- おそらくTry and Errorでやらなければならない
- お客様に迷惑がかからないように
- 検証とかで抑えていかなければいけない
- こういう時にテスターの出番かも
- OSが安定していない時に、どういう風に回避しつつ運用で安定していくか考える
- IoTの世界なので、膨大なパターンが有る中では難しいかも
Jon
- アメリカ政府には沢山のカウボーイがいました
- フロンティアだよと言いたいんだろう（松岡）
松岡
- マイクロソフトのOSのVerUpを抑えるようにした回避策とかはある
- ビジネス面から見れば、確かに回避策のアプローチを取らなければならない
- 大きな塊の中でどうやってテストをやっていく時に、どういう形で担保するようなテストをシステムレベルでやれば良いのか
Jon
- 私がおすすめするのは、色々なものを組み合わせてテストする方法
- アメリカでの面白い取り組みとして、大規模なしくみを自動テストで保証するために多くの組み合わせで保証した
- まだまだ我々も学習中ですが、それが役に立つと思う
松岡
- 標準化、規格化について、
- セキュリティはまだまだ進んでいないのでは？
二木
- 一部、セキュリティに関しての動きはあるが、一つの形を作るのは難しい
- 個別の分野ごとにセキュリティの規格が定まってくるのではないか
吉澤
- 標準が変わったら？
- やり直し。仕様の中に紛れ込むので難しいところはあるが
Jon
- やり直しという考え方は正しいと思う
- Agileという考え方が重要
松岡
- reworkも含め、テストも進めていかなければならない
- IoTのテストをするときに、どんなことをrequirementする必要があるか
Jon
- 時間、場所、コンテキスト、コンテントに関する認識をした上でテスターはやらなければならない
吉澤
- ソフトウェアの設計でちゃんと対応していれば良い。
- 標準が次々に変わるとわかっていれば、その部分についてだけテストを変えることは良いことだと思う
まとめ
- Jonが言ったように、IoTが動く仕組みやそれに伴う制約をきちんと理解し、標準が変わる変わらないも認識した上で、IoTのテストを頑張らないといけない
- 個別のテストの話として、脆弱性をテストする基本的なテクニックはやっていかないといけない
- 責任分割点は難しいが、サービスを提供して、満足させるところがどこまでなのかを可視化できるかどうか
- 可視化されるためのテスト
- お金に関わる話なので、ここまでは大丈夫という線引をしなければならない
- 今後のプロジェクトの中で、一つの指針としてここでの話を活用して欲しい
辰巳
- 自分の思いは問題解決のためにというところ
- IoTはチャンスではあるので、テスターとしての腕を磨いて欲しい
吉澤
- 松岡さんから可視化が大事、そのためにテストがあると言っていた。その中でJonのリストが役立つ。
二木
- どこまでやれば良いか？とよく聞かれるが「リスクベースで考えましょう」と答えている
- どんなインパクトがあるか
- 医療系や車では人命に関わる
- 個人情報に関わる
- 繋がっているデバイスの数
Jon
- IoTが訪れる間、発生する変化に楽しんで欲しい
質問
標準化について。IoTは新しい技術が出てきてChangeすると思うが。標準化と変化、どちらが速いと感じているか
- 標準の問題は合意形成に時間が掛かるということ。かなりの遅延が怒ると思う
- 製品の標準化は自然淘汰が多いので、時間がかかる
- だから、「変化を楽しめ」というメッセージを言った
変化を楽しんでいる間、よくわからない状態でやるテストとしてユースケースで攻める、組み合わせをオートメーションする手法があると言っているが、ユースケースを元にしたSearch Based Testingということか？
- 組み合わせテストの背景としては自動化のレベルを上げたい
