[応用編] アクアリウムエンジニアリング(3/3) テスト [再利用]

Pocket

多分、これで一通りは終わりになると思われます。”[応用編] アクアリウムエンジニアリング(2/3) テスト計画と開発局面 [再利用] | oshiire*BLOGoshiire*BLOG“の続きです。

今回は実際にくみ上げたものを確認するための「テスト」です。テストが終われば、はれてサービスインとなります。

1.テストの実施

前回のお話の「テスト計画」を受けて、その通りにテストを実施するだけです。

目的
構築した水槽と生体が、要件と設計どおりに正しく実装されているかを確認する
ゴール
各テスト局面のテスト実施項目がすべてクリアされ、全ての機能が正しく動作すること

要件定義で決めた機能と非機能要件を満たす様に、設計が成されているはずです。それについては、「追跡可能性(トレーサビリティ)」で担保されているはずです。
したがって、その設計を確認するためのテストを全てクリアすれば、最終的に要件どおりに実装できている、と言うことになります。

では、各局面ではどのようなテスト項目となり、どのポイントについて気をつければ良いかを確認していきましょう。

1-1.単体テスト

先にも述べた様に、単体テストでは「内部設計」で定義した内部の設計が正しく反映されているかどうかを確認することとなります。
具体的に言うと、「電源のON/OFFタイマー」であれば、指定した時刻に、電源の入り・切りがなされるかどうか。3灯のライトであれば、1つずつ、2つ、3つ、どの状態でも正しく点灯し、電源オフで切れること。などになります。組み合わせてどうかと言うことではなく、その機能を持つ一つのパーツ毎に定義した内容が正しく反映されているかどうかをテストします。
構築・開発時に同時衝動的に実施することの多いものです。実際に、ウォーターフォール型のフェーズでも、「CD/UT」として開発・単体テストを同時期に実施するプロジェクトも存在します。

ものによってはこのように簡単にテストが終わりますが、ヒーターやクーラー、温度計など、それ単体で本当に正しく構成されているかどうか分かりにくかったり、それらを全て組み合わせて複数の単体テストとして実施する場合もあります。この場合、「ヒーターが設定した 25度になること」を実現する場合、水をたたえた「水槽」自身やバケツ、そしてそれを計測するための「温度計」が必要で、ヒーターの単体テストを実施するために、「水槽」にキズなく水が漏れないことと、「温度計」が正しくその水温を指し示すことを確認するテストを実施することができます。ただ、温度計もヒーターもいずれも壊れている場合もありますから、温度計は二つ以上同時にテストに利用することをお勧めします。うちも、一つだけ温度計壊れてて、最初、ヒーターが壊れてるのか、温度計が壊れてるのかよく分からないことありました。

このように、各器具において、正しく定義成されているかどうをか全て確認し、問題がなければ、単体テストは終了です。

1-2.結合テスト

結合テストは「外部設計」で定義した、複数の機能を組み合わせて実現する、ある機能が正しく構成されているかどうかを確認することになります。
先の例の続きで生きましょう。10am〜6pm の間、ライトが 3灯、点灯する機能を提供する設計がなされて、「電源のON/OFFタイマー」と「ライト」で実現されている場合です。
電源タイマーとライトを接続し、実際に 10am〜6pm の間だけライトが点灯することを確認します。タイマートライとが正しく連動し、要件にあった機能を提供していることを確認します。

他には、エアポンプとエアチューブ、エアストーンが、水槽内にちゃんとエアを供給することができるかどうか、ろ過システムが正しく作動するかどうかなどが確認のポイントとなります。
これらは、本水槽と、そこにたたえられた水とを組み合わせてテストを実施する内容で、単体テストとは異なります。

「あれ、さっき、ヒーターと水槽と温度計試してるのは」とありますが、アレは個別の単体テストを組み合わせているだけです。「ヒーターが 25度で水を温め、維持すること」は水槽の水である必要もなく、バケツに入れた水でもいいですし、計測機は本水槽へつけるものでもなくても良いのです。なんとなく、ちょっとあやふやな感じもしますが、単体テストは「個別の単一機器」のテストを実施するもので、エアポンプは単体でちゃんとエアが出てくるかどうか、エアチューブは滞りなく、空気または水が送れるか、ろ過装置は設計したとおりの割合・分量でろ材が入っているかどうかを確認するまでです。

家で一人で試しているときには、単体テストと結合テストは一緒くたになりそうではありますが、実際にはこのように線引きがあるものととらえてください。ここまで厳密に実施するかどうか、というよりも「テスト項目に網羅性があるかどうか」に重点を置いていただくほうが効率的です。
なぜ、単体と結合とで分けるかと言えば、単体から順番にテストをしていけば、どこに不具合があるかが判明しやすいということになります。いっぺんにくみ上げてからテストをすると、「エアが発生しないのは、エアポンプの所為? エアチューブ? エアストーン?」と悩むことがありません。単体テストをしていれば、その時点で各器具に問題がなかったことが分かりますから、結線自体に問題があるだろうと考えられます。

このように、単体テストから順番に、その器具(コンポーネント)の最小単位からテストを実施することで、上位のテストの担保にも繋がると言うことですね。
ただ、機械ものですから、単体テストの時には問題なかったけれども、結合テストの時に壊れた、とか言うこともありますから100%じゃありませんけどね。

1-3.システムテスト

いよいよ最後のテストです。ね。「要件定義」で定めた要件をテストすることで、今回準備したアクアリウムが、全て、要件を満たしたものが完成したと言えるわけです。

「どじょうが飼えること」という大ざっぱな要件から、一体どんなシステムテストをするのかと言ったら「生きていること」を観察するくらいしかないと思います。このテストの終了条件も、3ヶ月病気なく生き延びたという期間で見るのか、3日目からの給餌で餌を食べること、など機能的な側面で判定するのか、それはテストを実施して欲しい人が決めるべきことです。「飼育する」という状況において、要求者がどのような状態になっているコトを終了条件とするか、要件を出したときについとして定義をするべきです。そして、それはそのまま、テストの実行内容と終了条件になります。

また、このような機能要件だけではなく、非機能要件として「水槽が壊れても、他の代替水槽で延命措置がとれること」という可用性をもった場合、実際にテストをするかどうかは考慮すべき事項です。
ITプロジェクトの可用性試験でも、破壊型をもたらすものもあります。例えば、災対で、切り替えたら戻ってこられない場合、切り替えテストを行った時点で本サイトでの復帰は不可能です。まぁ、通常、ITのプロジェクトでそのような破壊型の設計は行わず、言ったり来たりのテストは実施するでしょう。…するよな?
ただ、アクアリウムの場合、機能として提供されるものは「生体」「植物」であり、破壊型になり得る可能性が高いです。まったく、同じ水質条件でなければさっさと死ぬ様な弱い生体や、網で掬うときに傷が付いて生体が☆になるケースなどもあり、こういったテストを実施することによって「生体」そのものへ影響が懸念されるケースがあります。ITでは考えにくいことですが、生体ゆえに考慮すべき点がありますので、そういった、生体へのダメージを考えたときに、代替する手段・項目でテストを完了させると言うことを考えておくことが重要です。

今回のケースでいけば「代替水槽への切替の手順が明確になっているコト」とかですね。手順書が準備できていて、生体を使わない切替のテストが実施できていることだけでも十分でしょう。

また、ITプロジェクトでも経験があると思われますが、「サイクルテスト」とも呼ばれる日回しの仮運用テストを実施する方法があります。これは、実際にある一定の期間、運用してみて、適切に運用が廻るかどうかをテストして、不慮・不足がないかを確認することです。
個人的に、水が立ち上がりきるまでを結合テストで実施して、このシステムテストの日回しテストでは、もう仮というよりも本運用に近い状態でのテストという名の本番を開始してみるのが流れ的にスマートに考えています。ただ、結合テストではホントに機能に即したテストに終始して、水の立ち上げを含む、サイクルテストを全てシステムテストの局面でやる様な方法もあります。
この辺りは要件や外部設計の深さにもよりますし、対象となる生体でもフェーズの内容を変更すべきです。したがって、この辺りは経験を積んで、適したアプローチを取ることが重要でしょう。他に経験のある方の経験則を参考にリファレンスすることも悪いことではありません。ぜひ、参考にしましょう。

2.まとめ

テストが終われば、もう、自然にサービスインしているのがアクアリウムです。「さぁ、明日からサービスを開始しますよー」とふれて廻る必要なく「できた…!!」といった瞬間から、あなたへのサービスは提供されていることでしょう。麗しき熱帯魚の生活に浸るもよし、水槽を肴に酒を飲むもよし、好きに満喫なさってください。

さて、気になった方もいらっしゃるかも知れませんが「運用設計」や「移行」というフェーズがありません。今回、作った水槽はそのまま本番としてサービスインしていますし、サービスイン後の運用についても一切触れていません。触れていないと言うことは、その事前の準備である「運用設計」も書いていないわけです。
これは不要と言うことではなく「要件に忠実に従えば、外部設計・内部設計内で運用設計もなされるはず」ということと「テストからの切り替え移行」や「誰に対するサービスインだろう」と考えたときに、あえて「移行」を取りあげる必要がなかっただけで、実際には必要なフェーズであるとも言えます。

今回、応用編として 3編に書いてきましたが、実際にもっと具体的に、詳細に体系化したものをつくって、横展開できる様にしていけたらとは考えています(まだやんのかよ)。
ので、水槽よりか、ITよりかは分かりませんが、また次回お会いしましょう(‘A`)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください