[応用編] アクアリウムエンジニアリング(2/3) テスト計画と開発局面 [再利用]

なぜか、こんな先まで続いてしまった第三弾。”[応用編] アクアリウムエンジニアリング(1/2) 要件定義から設計局面 [再利用] | oshiire*BLOGoshiire*BLOG” の続きです。しかも、まだ次回に続きます。おい。

今日は実際の手を動かす局面になりますね。開発(構築) とテストの計画です。
想定した作業どおりに進めれば良いだけなので、説明自体は楽なのですが、テスト計画について先に述べておきます。

1.テスト計画

今まで、全くといって良いほどテストについては述べていませんでしたが、時間軸でいくと、開発の局面に入るときにはテストの実施内容は決定していて然るべきです。
設計局面にて、並行してテストの実施計画も作っていかなければなりません。そうでなければ、開発したものを作ってからテストの計画を始めるということになります。できあがったものを目の前にしてからテスト計画をするのでは、だいぶ遅すぎますので、効率よく実施するためには開発までの曲面で作成することが基本です。

1-1.テストって何をするの?

そもそもの話ですが、「テストの実施内容」はどうするべきでしょうか。
テストの局面には、単体テスト・結合テスト・システムテストとありますが、一体、各局面で何を確認するのでしょうか。

IT開発の場合、単体テストでは開発したアプリケーションのモジュールテスト、結合テストでは各モジュールをつなげて、機能として実装できているかどうかのテスト、システムテストは運用されたことを想定して、オンライン業務、オフライン業務、運用機能など、月次、年次機能も含めて実際にサービスを一部に提供して実施すると認識されているのではないでしょうか。
この認識は正しいのですが、各テスト項目はどのように策定しますか?
これまでの経験? 思いつき?

実際に経験や、同等の業務アプリでの過去事例などから、テスト項目を策定するケースはあるでしょう。ただ、論理的ではありません。そのテストの網羅性はどうやって担保するのでしょう。そのテストを実施する意味はあるのでしょうか? 本当に必要なテスト項目とは何か?

先に述べたように、各局面は「追跡操作性(トレーサビリティ)」がなければいけませんと説きました。では、テスト項目はどうやって、トレーサビリティをもって策定するのか。

1-2.V字モデル

IT開発案件の品質保証モデルとして「V字モデル」というものがあります。Vモデルとも呼ばれています。
テストを実施して、その機能の品質を保証するにあたり、要件定義・設計局面とテストの局面とを連携して項目を策定するアプローチです。

各テスト局面でのテスト実施項目は、対局する局面で決定した内容を元に、テストの項目を割り当てる方式です。単体テストであれば、内部設計での項目が正しく構成されているかどうかを確認しますし、結合テストでは外部設計を、システムテストでは要件定義された要件が正しく実装されているかをテストすれば良いわけです。
従って、各局面で定義・設計した項目について、正しく動作するとどうなるか、エラーが発生した場合にどうなるかを決定しておけば、それがそのままテスト項目となります。

例えば、内部設計で「Aモジュールの機能は、Aの入力に対してX、Bの入力に対してYが返されること。A,B以外の入力についてはエラーを発生させ、停止する」とあれば、そのモジュールの単体テストでは、A,B の入力と、それ以外の入力に対して、期待した結果が帰ってくるかどうかをテストすれば良いわけです。ただ、A,B 以外の入力範囲をどこまでにするかは、そのモジュールへの入力が想定されるもの全てをテストケースとして準備することが望ましいです。サンプリングテストの場合、漏れがあった場合のことをどのように担保するのかは、別途決めておかなければなりません。

では、これらをふまえて、実際の開発・テストをどのように実施したかについてご説明しましょう。

2.開発(構築)

ITプロジェクトでの「開発(構築)」とは、基盤の構築と、アプリの開発が基本です。機能要件を実現するためのアプリケーションの開発と、そのアプリケーションを非機能要件を考慮して実現する基盤の構築、と言うことです。

目的

これまでの要件定義・設計でデザインした生体を入れるための器(水槽)と、生体・水草の準備をすること

ゴール

生体を入れるための水槽で水が立ち上がり、生体を入れる準備ができあがること

2-1.基盤の構築

開発と構築は基本的に並行して実施されることがほとんどですが、アプリケーションができあがって、テストをしたい、といった段階で基盤ができあがっていることが条件になっているケースが多いです。そのため、基盤構築→(基盤)単体テスト→(基盤)結合テストが先に実施されてから、アプリケーションの投入と結合テストが実施される流れとなっています。アプリケーションの単体テストは、別途準備した開発環境や、開発機自体で実施されることがほとんどでしょう。単体テスト用に基盤を準備できるところはお金があると言って過言ではありません。

さて、基盤を準備しましょう。まずは水槽です。水槽を綺麗に洗って、底砂や石・岩をレイアウトにあわせて入れ、少し水を入れてから、水草を植えます。
おや? と思われた方、正解です。

おや? について説明します。

2-1-1. 機能要件・非機能要件と、基盤・アプリケーションとの関係性

「水草を機能要件とする場合」でも、水草は基盤と同じ扱いになります。
水草は、基本的に非機能要件です。生体を末永く運用するためのろ過、または綺麗に鑑賞するための背景として存在します。しかし、「水草水槽」というように生体ではなく、「水草」がメインの場合、その「水草」が「機能要件」たり得ます。しかし、基盤の構築中に、水草を入れなければなりません。これはどういうことか。

ITプロジェクトで考えましょう。一般的に、非機能要件として取り扱われる、「監視」や「バックアップ」など運用系の基盤が存在します。これらは、アプリケーションの稼働自体では、実際には不要ですが、基盤を安定して稼働させるため、不具合の発生したときに即復帰するために必要な機能です。
実は、これらは「機能要件」として取り扱われるケースがあります。既に稼働しているシステムにおいて、運用管理の強化、可用性の向上といったプロジェクトが存在します。過去には、スモールスタートと言えば、運用系の機能を取っ払って、ひとまず、アプリを動かしてみて後で考える、と言うことがありました。このように、後付けで運用管理面を強化する場合、そのプロジェクトでは、元々、非機能要件として定義される機能が、「機能要件」として扱われることになります。

このような場合でも、バックアップや監視の機能は、基盤と同じ段階で構築すると考えられます。

従って、水草を基盤構築の段階で入れてしまうこと自体は、なんの問題もありません。ただ、生体は後になります。例え、生体が非機能要件だとしても、それは「運用管理」の機能を補うための「機能要件」として取り扱えば、不整合なく考えられないでしょうか?
例えば、「可用性向上」の機能として、サーバを複数台設置するとした場合、既に稼働しているアプリケーション自体がそのままで稼働するとは限りません。負荷分散や、機器のスイッチを考慮して稼働するアプリケーションとして、再編が必要な場合もあります。これは、ある意味「非機能要件」を実現するための「非機能要件」になりえますが、アプリケーションであることには変わりないため、「機能要件」として取り扱われているケースがほとんどでしょう。

このように考えると、「生体」は「アプリケーション」、「水草」は「運用機能」とすることで、納得感がありそうです。

さて、水草まで入れたら、水を蓄えます。ろ過装置やヒーター、クーラー、エアレーションなどを設置すれば、一旦完成です。

2-1-2.水の立ち上げ

ITプロジェクトと少しちがうのは、基盤の準備ができあがってから、すぐに生体を入れてしまって良いかどうか、と言う点になります。

これは、水槽内の水は、バクテリアがほとんど居ないため、生体を入れることで、その生体自体にダメージがあり、即お亡くなりになるケースがあります。
そのため、「水を作る」という作業が必要です。これは、何かをするというよりも、主に時間が解決してくれる事象ですが、しばらく、なにもせずに運用して、バクテリアの豊富な水が立ち上がるまで待つ必要があります。水槽内でどのようなことが起きているかは、ぐぐればしぬほど出てくるので、そちらでお任せします。

この、「水の立ち上げ」を早くするためにパイロットフィッシュをいれることもありますし、マグロの刺身を入れるケースなどもありますが、これ自体も「(基盤)構築」の一環です。
アプリケーション機能としての「生体」をこの時点でパイロットフィッシュとして導入し、早く運用を開始するというケースもあります。

この辺りは、各自、導入する生体の強さで判断いただきたい部分ですね。アカヒレを買いたい人はおめでとうございます。立ち上げた瞬間から元気に生きてます。 ^[I]むしろ、アカヒレは漏水以外で死ぬと思えない

「水の立ち上げ」期間は、何もしないでぼーっとしておくのかというと、ここはチャンスです。基盤の単体・結合テストを実施しましょう。3. でお話しします。

2-2.アプリの開発

そもそもアプリ(生体)の開発ってなんぞや。とありますが、これには二つあります。

1. アクアショップで生体を買ってくる
2. 湖沼・川で生体を漁って(釣って)くる
3. 既存の成魚から繁殖させる

一つ目がサービスの購入で、二つ目がパッケージ品を組み合わせるパターン、三つ目がSI開発ってヤツになりますかね。

2-2-1.サービス購入

カンタンです。サービスを買ってきます。

アクアショップへ足を運んで、実際に生体を見るも良し、ネット通販で箱買いするもよし、とにかく「買う」ことです。
ITプロジェクトでも、サービスになった製品をかって「はい、おしまい」というケースありますよね。

いや、ありません。

そうです、例えサービスでも多少の「カスタマイズ」は必要です。では、生体のカスタマイズとはなんだろうか、というと、これは「トリートメント」や「水合わせ」「餌合わせ」の状態が、それに近いのではないでしょうか。購入したサービス(生体)を、家の環境に合わせるために、時間をかけて「水合わせ」してみたり、「塩浴」「薬浴」といったトリートメントにより、サービス自体が既存の基盤(自分の家の水槽)へ影響が発生しないように、寄生虫の有無を確認します。生体を、自分の家の環境に合わせていくことを「カスタマイズ」と呼びましょうと言うことです。無理矢理感があると思っても気にしない、スルーできるのが大人の対応です。

2-2-2.パッケージ開発

少し難しいですが、取ってくるだけですみます。よくいう「ガサる」ってヤツです。

ただ、どこへいけばいいか(どこから買えばいいか)、ほしい生体が手に入るか(必要とする機能を充足しているかどうか)、家の水槽で飼えるかどうか(そのパッケージ動作の仕様を満たす基盤が準備できるかどうか)など考慮点があります。パッケージの内容に精通していない場合、できそうだと思って買ってみたら全然仕様を満たしていない、要するにとってきた生体が実はちがうものでした、なんてことはザラです。

特定のサービスの様に欲しい機能を明示して、すでに組み合わされて提供されていれば、見て欲しいものを買えば良いのですが、実装しようとしている機能を本当に充足しているかどうかはスペシャリストの力が必要になる場合が多いでしょう。素人は、某ルー大柴のように普段からガサっている人たちとついてまわって、ほしい生体を手に入れる様にしなければなりません。そのための道具やガサりかた(パッケージの内容へ精通する知識)を学んでおかないとなりません。

もちろん、パッケージにもカスタマイズは必要となります、ね。水合わせは、もっと重要です。寄生虫などの問題もブリード個体より問題があるでしょう。課題点が多く、導入が難しいという点でパッケージ製品に似ていると、勝手に個人的に感じてます。

2-2-3.SI開発

何もないところから生体を生み出すことはできないので、成魚(開発者)や卵(フレームワーク)を準備して、新たな生体を準備する手法です。

成魚をつかって、卵を孵化させる方法は、その生体にもよりますが、簡単なものとほとんど不可能なものとに分かれます。メダカなどは簡単な部類ですが、ミナミヌマエビやラムズなどは、開発する気がなくても勝手にどんどんと産みだしていってくれるので、エンドユーザー(私自身)泣かせです。時と場合によっては、大量のエラーログ扱いです。かと言って、監査を考えると、その大量のエラーログも破棄できませんが。

そして産まれるは「卵」です。卵胎生の生体であれば、卵ではなくいきなり稚魚が出てきますが、稚魚の段階でもまだ完成していないので、本水槽へ突っ込めるまでが開発と考えてください。「うっさい、産まれたらすぐに入れるんだ」っていう方は、それも一つの方法です。単体飼いであれば問題ないでしょう。また、混泳状態では、そのサバイバルも含めての開発だとも考えられます。ドMですね、嫌いじゃないです。

ということで、「卵」や「稚魚」はまだ完成形ではありません。個人的は、「フレームワーク」と考えています。
それ単体を放置していてもできあがるケースはありますが、ほとんどたいていの場合、「勝手に」やっているわけではなく自動的に生体が孵化して育成するまでを「自動化」しているだけです。夢の自動化開発ですね、嫌いじゃない。

一般的に、「卵」は適温でかびないように時間をかけ、稚魚となってからは、稚魚でも食べられるものを準備して、☆にならないように育てていきます。本水槽へ行けるような状態までの育成自体が「開発」局面なのです。これらは、準備する生体(機能要件)に従って、短くも、長くも、カンタンにも、複雑にもなります。みなさまの力量に応じて、挑戦してくださいませ。私はまだ素人なのでやりません。

3.今日のまとめ

今日はここまでです。

理由は疲れたからです(読んでる人が)。

• テスト計画は V字モデルに従って、要件定義・設計に応じたテスト実施内容を準備しよう
• 生体(アプリケーション)を入れるための水槽(基盤)を準備しよう
• 生体(アプリケーション)を開発する手段には、完成品の購入と、自分で作り上げる2種類がある
• 自分の力量にあわせた開発を実施しよう

ではまた、そのうち。後は、テスト局面ですね! (やっと(‘A`) )

[tmkm-amazon]B00GS5ONQ8[/tmkm-amazon]