リリース判定基準・テストの種類３つ目はRAS機能
- 1. テストの種類の３つ目はRAS機能テストの実施状況
- 2. RAS機能に関するテストの実施状況
- 3. Reliabilityのテストは安定性の確認テストで代用する
- 4. Availabilityは保守時間や再起動時間の確認ができているか
- 5. 宅内の端末と局舎の装置の違いには注意して
- 6. Serviceabilityは不具合が起きた時の調査機能の確認
- 7. 発生した時に何が起きてたのか、まずは情報集め
- 8. Serviceability の品質は要注意
- 9. 実はServiceability はテストがし難い
- 10. 何はともあれ、テストしてるか？ 程度の確認
- 11. テストの種類、次はバージョンアップテストです
テストの種類の３つ目はRAS機能テストの実施状況
この一連の記事ではテストの品質を判定する時にどんな種類のテストをしているかという視点でテストの種類紹介しています。前の記事で紹介した安定性と堅牢性に次いで確認るのはRAS機能のテスト状況です。 安定性や堅牢性と重なる部分も多いのですが、最近はRAS機能という言葉で纏められる事も多いので、グータラ親父はテストの種類を確認する項目としても使ってきました。
RAS機能に関するテストの実施状況
ところでRAS機能とは何でしょう？ 一般的には Reliability Availability Serviceability の頭文字をとってRAS機能とよばれていますが、ソフトに当てはめると具体的にはどん機能の事でしょうか。
簡単に言うと、故障が少なくって、もし故障しても素早く回復して、安心して長く使えるように保守ができる、という機能です。 グータラ親父は、リリース判定の時のテスト品質の確認としては、このRAS機能の状態を確認するテストが計画されて実施されているかどうかを確認していました。
要求仕様書にRAS機能が明記されていれば、その仕様を満たすかどうかを確認するテスト項目があるばずですので、あまり注意する必要はありません。 しかし、要求仕様にRAS機能が明記されていない場合にはどうましょうか？
そのような場合でも、製品が提供される市場で要求される常識的なレベルのRAS機能が搭載されているか、とか、会社や組織として必要と定めて居るRAS機能のレベルが実現されているか、などの確認は必要です。これは、品質管理の世界では当たり前品質とよびます。
ですので、例え要求仕様書にRAS機能についての記載がなくても、RAS機能がその会社にとっての当り前品質を満たしているかを確認するテスト項目があるかどうかが、RAS機能の確認という視点でのテスト品質の良否を判定する基準になります。
Reliabilityのテストは安定性の確認テストで代用する
RはReliability （信頼性） の略で、故障や障害、不具合の発生しにくさの事です。 ハードにウエア関係する事も多いので、稼働時間当たりの障害発生回数(MTBF：Mean Time Between Failures)で表すこともあります。
ソフトウエアに関して言えば、前に出て来た安定性が考え方として近いですね。 ですので、グータラ親父はソフトウエアのリリース判定時には、Relaibility のテストの状況の確認には安定性を確認するテストの状況確認で代用して、RAS機能については残りのＡとＳについてのテスト状況を確認していました。
Availabilityは保守時間や再起動時間の確認ができているか
A は Availability （可用性）の略で、稼働率の高さ、障害や保守による停止時間の短さを表します。 全体の時間に対する稼働時間の割合(稼働率)などの指標で表す事もあります。
何等かの障害が発生した時の再稼働するまでに経過した時間などが、稼働していな時間に相当するので、この稼働していない時間が少ないほど、Availability は良いという事になります。 稼働していない時間といのは、その機器の連続した運転の時間と比較して初めて、長い/短いを判断できるので、連続運転時間というのも重要なのですが、まあ一般的には１ヶ月とか１年を考えれは良いでしょう。
それではここでも、無線LANルータを例にして、連続稼働時間を１年程度とした場合の Availability を計算してみましょう。
無線LANルータは一度設置すれば殆ど動き続けるのですが、まあ１年に１回はファームウエアの更新があると仮定してみましょう。 また、１年に２回は何かのハングアップが発生するけれども、ハングアップをウォッチドッグ機能で検出して自動リセットによるリカバリ機能が組み込んであると仮定しましょう。
このように仮定を置いた場合の Availability の計算値は以下となります。
- 無線LANルータの連続運転時間 ：8,760時間＝365日
- 無線LANルータが未稼働となっている時間 ：0.83時間＝50分
内訳は、１年に１回のファームウエアの更新の時間 （30分）と、ハングアップ発生から再起動し通常サービスが再開されるまでの時間２回分（10分+ 10分） です
この値から、無線LANルータの1年あたりの Availability は99.99 % （100X(8760-0.83)/8760) になります。
宅内の端末と局舎の装置の違いには注意して
どうですか、99.99% って結構良さそうな値ですね。 これは、宅内に設置される端末で、定期保守のような未稼働時間が必要ないので、この様な良い値になります。
一方で、この無線LANなどの対抗装置として局舎に設置されている集合装置では、Availability はどうなるでしょうか？ 一般的に、集合装置には色々なユーザの設定情報等を保持しているので、通常は定期的に保守点検作業が発生します。 保守点検作業の中で、機器の故障点検や各種データのバックアップなどの、装置を安定に動作させるために必要な定期点検が行われます。
定期的な保守点検の作業なので、作業に結構な時間が掛かります。 例えば、１年に１回24時間の保守点検作業が必要で、その間サービスを停止する必要がある場合で、先ほどと同じ様に Availability を計算すると、99.7% （100X(8760-24)/8760) になります。 この様に、ファームウエアの更新時間や保守点検の時間が Availability に影響します。
ですので Availability に関するテストというのは言い換えると、ファームウエアの更新処理や保守点検等の未稼働の作業に掛かる時間やハングアップの回復処理に掛かる時間を測定するテストともいえます。
グータラ親父は、リリース判定時のテスト品質の確認としては、このような Availability の状況を確認するテストが実施されているか、という事を確認していました。 テストの量とか内容までは踏み込まなかったのですが、このような Availability の実力を確認するためのテストが実施されているかどうかを、テスト品質の判断の一つとしていた、という事です。
Serviceabilityは不具合が起きた時の調査機能の確認
最後のSは Serviceability （保守性） の略で、障害復旧や保守作業のし易さを表します。障害発生から復旧までの平均時間(MTTR：Mean Time To Repair)などの指標で表すこともありますが、ソフトウエアの観点でいうと、市場で発生した不具合の原因を調査するための機能という面が強いです。
市場で不具合が発生してそれがソフトウエアのバグに起因する可能性が高い場合、皆さんはどうしてその原因を突き止めますか？ 同じ現象が社内で再現できれば、いろいろな手段で原因を調査する事ができるので、あまり悩む必要はありません。 でも、再現しない時はどうしましょう？ 再現しないけど、どうしても不具合の原因を解明して対策版ソフトを作らないといけないような状況になったら、どうしますか？
発生した時に何が起きてたのか、まずは情報集め
原因を推定するために、市場で不具合が起きた時の情報をなんとか集めないといけませんね。 そうです、製品に仕組んでおいたエラーログの解析だとか Unix 系のOSであれば Core Dump の解析だとかの調査手段を取る必要があります。
そのためにはまず、エラーログや Core Dump のデータを手元に回収する事が必要です。 製品の二次記憶領域にエラーログや Core Dump を格納しておいたり、ネットワークに繋がっている製品ならネットワーク経由でエラーログや Core Dump を取り寄せたり、場合によってはネットワーク経由で装置に入り込んでの遠隔診断とかができれば、色々な情報が取り出せて、原因推定をすすめられます。
ソフトウエアの面から見た Serviceability は、このような市場での不具合を調査するための機能です。 大まかに分けて、エラーログやCoreDump の収集などのようなオフライン系の機能と、遠隔診断などのオンライ系の機能とに分かれます。 また、遠隔操作によるファームウエアの更新も、Serviceability の機能に含める事も多いです。
Serviceability の品質は要注意
このエラーログの収集だとか遠隔診断とかの機能ですが、ソフトウエアの品質面では、実は２のの面で注意が必要です。 １つ目は、通常の機能よりも高い品質が必要という事で、２つ目は品質を確認するためのテストが実行し難いという点です。
通常の機能よりも高い品質がなのは何故でしょうか？ Serviceability の機能を使う場面を想像してみましょう。 何か実運用の現場で今まさに問題が起きていて、その原因を調査するために Serviceability の機能を使う事が多いですね。 当然、お客様からは調査と対策を早急に進めるように要求も来ている事が多いです。 そのような場面で、Serviceability の機能にバグがあって想定通りに動かないと、、、あまり考えたく無い状況に陥りますね。
Serviceability の機能は、実は交通事故の現場に駆けつけてくれる救急車にも似ています。 現場で確実に動作して、状況を把握し、対策を進める必要があります。 通常のサービス提供の機能よりも一段高いレベルでの品質が要求されます。
そして、この一段高いレベルでの品質を要求するのは、お客様ではなくて、不具合の調査・対策をする開発者自身の事が多いです。 ですので、仕様書に Serviceability の機能についての品質レベルの記載が無くても、開発者は自分自身のために、Serviceability に関する機能では高い品質レベルを達成しておく必要があります。
実はServiceability はテストがし難い
そして、Serviceability の品質を高めるために充分なテストをしようと考えた時に、２つ目の注意点が顔を出します。 例えばエラーログの機能のテストを例に考えてみましょう。 エラーログですので、何かのエラーが起きたらそのエラーの内容とか発生時刻をログに記録する機能ですね。
つまりエラーログの機能をテストするには、エラーが起きる事が必要なのです。 簡単に起こせるエラーなら良いのですが、エラーログの中にはめったに起きないようなエラーも多数あります。 簡単に起きるなら、リリース前のテストで発生させて、そもそもエラー対策の処理を組み込んでしまえば良いのです。
ですので、実運用で必要になるエラーログは、そもそもとっても起きにくいエラーなのです。 という事は、何か工夫しないとエラーが起きないので、エラーログの機能が正しく動いている事を確認できないのです。 これのように、テストそのものが実行し難いというのが、Serviceability の品質を確認する上での２つ目の注意点です。
何はともあれ、テストしてるか？ 程度の確認
こう考えてくると、Serviceability に関するテストは製品毎に要求される品質レベルも仕様書に書いてなくて不確実な事も多く、品質を確認するテストの実施が難し事が多いことが判ってきます。 ですので Serviceability に関するテストは、一概にどのレベルに達していれば良いかという判断基準が決めにくいという面があります。
この様な場合には、グータラ親父はあまり深く考えずに Serviceability を確認するテストが実施されているかどうかの程度の表面的な確認だけで、リリース判定時のテスト品質の判断の一つとしていました。
テストの種類、次はバージョンアップテストです
テスト品質の良し悪しを判定する時に、実施したテストの種類をみるのですが、RAS機能テストの次は ソフトの品質保証の最後の砦となるバージョンアップ機能のテストです。 次の記事に紹介していますので、興味のある方はご覧ください。