リリース判定基準・テストの種類４つ目はバージョンアップ機能
テストの種類の４つ目はバージョンアップ機能のテスト状況
この一連の記事ではテストの品質を判定する時にどんな種類のテストをしているかという視点でテストの種類紹介しています。前の記事で紹介したRAS機能のうちの Serviceability 機能の一部でもあるのですが、製品に搭載されるソフトにとって、バージョンアップ機能は特別に大切なので、テストの内容も注意して確認をしていました。
バージョンアップ機能のテスト状況の確認では、これまでの他のテストとは少し晴天を変えて、悪い動作環境を準備してのテストや十分な回数の繰り返しテストをしていますか、と機能の安定性を確認する具体的な項目をあげて、テスト内容にまで立ち入った確認をしています。
バージョンアップ機能だけを特別視してテスト内容まで立ち入って確認するのは、バージョンアップ機能が市場でソフトの不具合が発生した時の最後の砦だからです。
最後の砦って何の事、なぜ特別視するの？
市場で本番稼働している製品に組み込まれたソフウエアトにバグが見つかり大問題が発生した時に、製造メーカのソフトウエア開発部隊は何をしなければならないでしょうか？
まず第一に行うのが、緊急の回避策の提供です。 市場で発生している問題が、これ以上増殖しないように、使い方とか設定方法とか、今すぐにできる手段で不具合の発生を抑制する回避策を提供し、不具合による被害を最小限に留める事が最優先です。
緊急の回避策で被害の拡大を止める事ができたら、次に大急ぎで実施するのが、不具合の原因となったバグの調査と、バグを修正した改訂版ソフトの開発ですね。 そして、完成した改訂版ソフトを市場で稼働している何万台、何十万台の製品に適用して市場問題の鎮静化を図ります。
改訂版のソフトを市場で稼働している製品に適用する事ができるのはバージョンアップ機能があるからで、ソフトの不具合ではこのおかげで、市場からの全製品の回収というリコール作業をせずに問題を収束させる事ができます。 もしソフトのバージョンアップが出来ないと全製品の回収が必要になってしまうので、そうならないための市場不具合との戦いの最後の砦が、バージョンアップ機能なのです。
考えてみれば単純な話なのですが、バグが原因で市場で不具合が発生した時に、バージョンアップ機能がちゃんと動いてくれないと私たち装置のメーカ自身ががとても困るのです。 なのでリリース判定の時に特別に注意して確認しているのです。
バージョンアップ機能の確認点その１：悪い動作環境でのテスト
ではバージョンアップ機能のテストについては、何を確認しておけば良いのでしょうか？ いろいろな観点があるのですが、グータラ親父は２つの点を注意して、テスト内容を確認していました。 一つ目はバージョンアップ機能のテストを悪い動作環境をの中で実施しているかという点です。
悪い動作環境というのはちょっと判り難い表現ですね、もう少し具体的に言い直してみましょう。 バージョンアップのためにソフトを装置まで送り込む方法は色々ありますが、例えばネットワーク経由で送り込む場合を例に考えてみましょう。この場合、バージョンアップ機能は、ソフトを送り出すサーバと通信回線とソフトを受け取って書き変える端末の３つで構成されます。
良い動作環境であれば、通信回線に遅延は無くノイズものらずサーバの応答性も早く端末も安定して稼働しているでしょう。そのような良い動作環境でバージョンアップ機能が動く事をテストで確認する事は当然必要です。でもそれだけでは安心できません。
本番環境は思いもよらない悪条件もある
実際のバージョンアップ作業では、通信回線がノイズだらけで遅延も大きいような地域も存在します。 多数の装置のバージョンアップが重なるとサーバの応答性が遅くなりタイムアウトが起きる場合もあります。 端末の動作や電源アダプタが不安定でソフトをフラッシュメモリに書き込んでいる最中に電源が落ちてしまう事もあるかも知れません。
そんな事が起きた時は、バージョンアップ機能が正しく動かなくても仕方が無いと諦めるのでしょうか？ 市場で大問題が起きていて、一刻もはやく対策版のソフトに置き換えたい時には、そんな悠長な事は言って居られません。 少々の悪条件があっても、簡単には諦めずに再試行するような粘り強さがバージョンアップ機能には欲しいのです。
バージョンアップ機能が悪い動作環境でも確実に動く事の保証は、テストで確認するが一番です。なので、グータラ親父はバージョンアップ機能が悪い動作環境でもテストしてあるかを、リリース判定の時には常に確認していました。
バージョンアップ機能の確認点その２：多数回のテスト
２つ目の確認項目は、バージョンアップテストの実行回数です。 ことらは割と単純で、グータラ親父は宅内に設置する端末機器なら数千回以上、局舎に設置される集合装置なら数百回以上のテストを実施しているかという見方で、確認していました。
なぜ、同じテストを何百回や何千回も実施する必要があるのでしょうか？ 数回やれば充分のような気もしますか？ 確かに、小規模なソフトで動作が常に同じ順番・タイミングで実行されるのなら、何百回も実施する必要はありません。
しかし、最近のソフトはマルチタスクやマルチスレッドで作られているのが一般的です。 そしてタスクやスレッドの中には色々な利用から実行タイミングに揺らぎが起こります。
実行タイミングの揺らぎの元は、例えば外部との通信を行うタスクやスレッドです。これらは外部からの通信のタイミングで実行のタイミングに揺らぎが起きます。また別の揺らぎの元はフラッシュメモリへのアクセスがあるタスクやスレッドです。
フラッシュメモリは通常のRAMに比べてアクセス速度が非常に遅く、しかもその速度は同じフラッシュメモリであっても、フラッシュメモリのメモリ素子の劣化状態によって変わってきます。そのためフラッシュメモリへのアクセスがあるタスクやスレッドもまた、実行タイミングに揺らぎが起きます。
これらのタスクやスレッドは、それ以外のタスクやスレッドと連携してシステム全体としての機能を実現しています。ですので、マルチタスクやマルチスレッドで作られたソフトウエアは、実効されるソースコードが同じであっても、毎回実行の順番やタイミングには微細な揺らぎが起きているのです。
タイミングの揺らぎはバグの温床
そして、バグはこのようなタイミングの揺らぎが大好物です。普通のタイミングでは問題なく動くのですが、ごく稀に起きるような処理のタイミングで、何かの処理が少し変わってその結果思いもしなかった処理が実行されて、、、、その先でバグが笑っている、という事がよくあります。
マルチタスクやマルチスレッド環境での処理タイミングの揺らぎは、設計レビューやコードレビューやシミュレーションなどの机上検討で洗い出す事はほぼ不可能です。ひたすら実機で同じ処理を実行させ、そこで発生する揺らぎでおかしな事が起きないか、実機テストで確認するしか手はありません。
じゃ～何回テストをすれば良いか？ という点ですが、残念ながら正解は誰にも判りません。 仕方が無いのでグータラ親父は、宅内の端末なら数千回局舎の集合装置なら数百回という回数をエイヤッと決めて、バージョンアップ機能についてだけは、その回数のテストの実施を開発部門に要請していました。
そんな多くの回数のテストをやって本当に効果はあるの？ と問われたら、、、何とも言えませんとしか回答のしようは無いです、もともと根拠がある回数であはありませんので。
しかし、グータラ親父の経験では、この数百回や数千回のバージョンアップ機能で事前に発見されたバグは、両手で数える以上の件数があります。 テストの費用対効果という面から良いか悪いか、という観点では判断は難しいです。 しかし、バージョンアップ機能をソフトウエアの不具合修正の最後の砦だと考えるなら、効果があったと判断しても良いと思っています。
テストの種類、次は過去不具合の確認状況です
テスト品質の良し悪しを判定する時に、実施したテストの種類をみるのですが、バージョンアップ機能のテストの次はテストの中での過去不具合の確認の状況です。 次の記事に紹介していますので興味のある方はご覧ください。