IVECテスタークラス シラバス読解Part14
はじめに
今回がIVECテスタークラス シラバス読解最終回です。
IoT関連は私にとっては未経験領域で少しとっつきづらい内容ですが、それでも読解していきます。
5. 専門テスト知識・スキル
5.2. IoT(Internet of Things)関連
IoT テスト環境の準備
IoTのシステム構成やテスト環境構築を理解する
IoT のテストで準備すべき環境には以下のようなものが挙げられる。
・物理デバイスのセットアップ
・利用環境を模倣したネットワークの環境準備
・テストデータの生成
・テストツールの使用方法
・エビデンスの取得方法
テスト計画に基づいてデバイスやツールのマニュアルを用意し、事前に内容を把握しておくことが重
要である。
IoT機器に関しては、ハードとインフラが両立することでテストが可能になるため、テストを行うに当たっての環境構築はテスト計画段階でまとまった期間を設けておくこと。
また、IoT機器は検証対象の機材毎に多種多様な場所や環境で利用されるため、どういった環境でのテスト実施を想定するか洗い出しを行い、ステークホルダーとの間で合意を得た上でテスト環境の構築が必要になる。
IoTテスト環境の動作を確認する
デバイス、センサー、通信ネットワークなどが連携し適切に動作することをテスト実行前の段階で確
認することで、スムーズなテスト実行への移行が可能となる。
IoT機器をテストする時は、事前の動作確認でテストできる状態かをチェックが必要になる。
いきなりテストを行うも機器が想定通りに動かず、テストの進捗がありませんでしたは通用しないので、動作確認段階でテストできる状態かを確かめ、その時に課題が出てきたら開発チームやステークホルダーへその旨を打ち上げ、解決策を共有してもらうこと。
IoTテスト実行の条件やデータを準備する
IoTデバイスの動作する環境や処理するデータ、条件を準備する。
正しい結果を得るためには、条件やデータがリアルタイムかつ連続的に変化することを理解する。
IoTデバイスを動かすためにインフラだけではなく、データが必要な場合はテスト設計の段階で、洗い出しはタスクに入れる必要がある。
テスト実行中にデータ不足に陥らないよう、テスト実行前の段階で開発チームやステークホルダーと、テストに必要なデータのすり合わせを行った方が抜け漏れをなくせると考えている。
IoTテストの実行
IoTデバイスと連携する各システムでテスト実行結果を確認する
テスト仕様書に従い、各システムで異なる確認ポイントを理解する。
また、インシデントが発生した場合、原因と影響を把握する手段として充分なログ情報の収集と分析
が必要になることがある。
テスト実行はテスト設計時に定めた優先度を沿って実施する流れだが、以下のテストを行う際はリソースやデータを用意できず、テスト終盤になって慌てて実施することがないよう、テスト設計段階でそれらのテストの優先度を考慮しておくべきである。
- IoT機器を複数台・最大台数つなげて行うテスト
- 大量のデータが必要なテスト
- 故障時、メンテナンス時の振る舞いを確認するテスト
また、リソースやテスト環境がテスト期間内に準備できない場合を想定し、代替手段での検証(シミュレーター)が可能かについても、テスト計画段階でステークホルダーと合意を得る必要がある。
IoTのテスト実行結果の記録
IoTデバイスと連携する各システムでテストの入出力結果を記録する
テストケースや項目数、実行結果の他、具体的なデバイスや環境、使用したデータを記録する。
記録する際に、条件やデータがリアルタイムかつ連続的に変化することに注意する。
テストエビデンスの残し方はテスト計画書内で定義し、それに則って必要なデータの記録を行うこと。
IoTテストで発生した不具合報告
結果として不具合現象が確認された箇所と内容と、そこに至る途中経過で確認された事象も併せて報
告する
使用したデバイス情報(バージョン情報や仕様など)、通信プロトコル、ネットワークの通信速度など
原因解析に必要な情報をすべて報告する。
不具合報告時のルールは他のテストと変わりはなさそうだが、不具合起票する際にIoTのテストならではの情報がある場合は、その情報も盛り込んでおくことで開発チームは原因の特定にスムーズに取りかかることができる。
他のテストで使用していた不具合起票のフォーマットを使い回すと、抜け漏れの発生に繋がりかねないので、不具合起票時のフォーマットについても、事前の合意を得た上で運用すること。
テスト環境と不具合現象の再現性の確認について理解する
不具合起票のときに対象不具合の再現性を確認する場合には、対象システムに接続されている機器の
種類だけでなく各機器の状態を確認する必要がある。なぜならば、テスト実施者の環境では不具合現
象が再現するが、開発者の環境で再現させようとした場合には再現しないということが往々にしてあ
るからである。
様々な機器がつながる IoT システムにおいては、不具合原因の特定と改修をスムーズに実施するため
にも、接続される各機器の設定や状態(待機中なのか動作中なのかなど)などが不具合現象の発生条
件となっているかを確認することが必要である。
不具合起票時の情報提供において、通信やハードウェアも絡んでくるため、最低限の情報のみ提供した場合、開発チーム側で不具合を再現できない可能性も踏まえて、どんな情報を載せるかはフォーマットを決める段階ですり合わせておくこと。
また、不具合起票時のフォーマットを充実させるだけでなく、テストチーム側で不具合が発生した際の動画やスクリーンショットの撮影も可能な限り打診した方が原因の特定に近づけるかもしれない。
おわりに
合計14回に渡ってのシラバス読解でしたが、最後までやりきることができました。
文章を書くという習慣付けのためと、ソフトウェアテストに関する記事を書いてみようという気持ちから、実務寄りIVECシラバス読解を進めてまいりましたが、記事を書いていて特に業務で忙しくもない中で途中で間が空いてしまったのはもったいなかったなと痛感しております。
『鉄は熱いうちに打て』という言葉があるように、自身の熱量が高い中で継続してやることの難しさを実感しましたが、同時に最後までやりきれたことには満足しております。
今後もこうしたソフトウェアテストに関する書籍や資格関連のシラバス読解など、ソフトウェアテストに関する情報発信を継続していきたいと考えております。
Discussion