テストの種類・異常回復性/保守性/ドキュメント/手順書
システムテストカテゴリの読み替えと取捨選択
この記事では、前の記事に続けて ”The Art of Software Testing “ に載っている15種類のシステムテストカテゴリを組み込みソフトのテストカテゴリとして使うために必要になる読み替えや取捨選択について、グータラ親父の考え方を紹介します。この記事では、異常回復性テスト、保守性テスト、ドキュメントテスト、手順書テスト について紹介します。
Recovery （異常回復性）テスト
異常やエラーが起きた時にその異常状態から回復する機能を確認するのが Recovery テストです。組み込み系システムにとってはこの異常回復機能は必須なのですが、グータラ親父はシステムテストカテゴリとしては Recovery テストは使っていませんでした。なぜかと言うと、各機能を確認する facility テストの中の準正常系テストと異常系テストとして実施する事にしていたからです。
Facility 機能は、その装置の持つ機能を洗い出して網羅的に確認するテストです。各々の機能のテスト設計において、その機能が正常に動作する事を正常系のテストとして確認します。さらに、設計時に想定されたエラーや異常状態に対する動作については、準正常系のテストとして確認し、設計時に想定できていなかった異常が発生した時の動作については、異常系のテストで確認します。 この、 Facility テストでの準正常系と異常系のテストが Recovery テストと同じ事をテストしているので Recovery テストというテストカテゴリは使いませんでした。
Serviceability （保守性）テスト
組み込み系システムでは、稼働中に発生した問題の原因を調査したり問題に対応したりするために何等かの保守機能が搭載されています、この保守機能を確認するのが Serviceabilityテストです。保守機能には、エラーログを記録するように装置単独で動作する保守機能もあれば、サービス提供会社の保守センターから遠隔で状況を確認したり対策版のソフトを書き込んだりする遠隔保守機能もあります。どのような保守機能が搭載されているかは、その装置の要求仕様書や要件定義書に明記されているはずですので、それらの機能が正常に動作する事を確認します。この Serviceability テストも組み込み系ソフトのシステムテストカテゴリとして必須です。
保守機能の中でも特に重要なのが、遠隔保守機能を使ったソフトのバージョンアップや再起動の機能です。組み込み系システムのソフトにバグがあった場合でも、バグを修正したソフトにバージョンアップする事ができれば、市場で稼働している装置のバグを無くす事ができます。また、バグを修正したソフトがまだ準備できていない場合でも、遠隔操作で装置を再起動できれば、エンドユーザへのサービス提供を回復できる事も多いです。
エンドユーザで何等かの問題が発生した時に、緊急回避策として遠隔で再起動をしたりバグ修正版のソフトを書き込んだりする遠隔保守機能は、この機能さえ動作していればなんとか事態が改善できるので、組み込み系ソフトにとっての品質保証の最後の砦です。だからこそ、遠隔保守機能については他のいろいろな機能よりも一段階高い品質が要求されます。そのために、Serviceability機能 のテストではその安定性について特に注意してテスト計画を作成します。
Documentation （ドキュメント）テスト
製品と一緒に出荷されるドキュメントの品質を確認するのが Documentation テストです。一般家庭向けの製品であれば取り扱い説明書が製品と一緒に梱包されて出荷されますし、運用センターで使う様な機器であれば運用マニュアルが製品と一緒に納品されると思います。どのような場合でも、その製品を使うお客様は一緒について来たドキュメントを見てその製品を使うので、そのドキュメントが間違っていると使い方が判らなくなってしまいます。そのような事が起きないように、ドキュメントが正しく作られている事と確認するのが Documentation テストです。
実はソフトの開発の終盤では、製品の表示上の改善もわりと良く発生します。一通りの機能・性能が改善されると、優先度が低かったちょっとした表現の改善にも手が回るようになってきます。その結果として、装置のGUIやCUIの案内メッセージやエラーメッセージが変更されます。メッセージがより判り易くなる事はとても良い事なのですが、ドキュメントの作成がソフトエンジニアのいる部署とは別の部署で進んでいる場合には、ソフトでのメッセージの変更がドキュメントに反映されるのが間に合わないような事も起きてしまいます。そのようなドキュメントの反映遅れを見つけ出すのも Documentationテストの役割です。
組み込み系ソフトのシステムテストでは、ソフトが製品に搭載されている事から製品そのものの品質を確認するテストに重点が置かれがちですが、製品と一緒に出荷されるドキュメントの品質もまた重要です。ですので、Documentation テストはシステムテストカテゴリとしても重要な項目です。
Procedure （手順）テスト
組み込み系システムの場合、組み込まれる全体システムの中で予め決められた一連の手順に従って動作する事を求められる場合があります。例えばセンターに設置されたサーバと通信してソフトをアップデートする場合には、以下のような手順で動作する事が求められます。
① 現状のソフトバージョンをサーバに通知してバージョンアップの要否を確認する。 ② バージョンアップが必要と判ったらエンドユーザが見えるGUIの画面に「バージョンアップしますか？」の確認画面を出す。 ③ エンドユーザが「はい」を選んだらサーバから最新版のソフトをダウンロードする ④ ダウンロードが終わったら装置を再起動して新しいソフトを有効にする。
このようなソフトのアップデート手順が決まっている場合、その手順どおりに動作する事を確認するのが Procedure テストです。他の装置やエンドユーザとのやりとりを含む手順が必要な場合には、個々の手順の間で長く待たされたり、間違った手順が実効されたりと、様々な事が起こり得ますので、それらも含めて組み込みシステムがちゃんと動作する事を確認する必要があります。機器のもつ個別の機能を組み合わせて色々な手順が作られるので総合的なテストになる場合が多いのですが、システムテストカテゴリとしても重要な項目です。