開発フレームワークはEoTをも推進できる

十数年前までは,プログラマに全てのコードを記載することが当たり前だった。数年前までは,何らかのフレームワークを独自に(クラスの継承を使って)拡張することで,プログラマの作業の負担を軽減することが当たり前だった。そして最近は,オープンソースプロダクトを複数束ねて使用することによって,プログラマの作業の負担を軽減することが当たり前になった。

ちょっと視点を変えて,開発環境はどうだろうと振り返ってみると,「テキストエディタ&コンパイラのみで頑張った時代」から,「統合開発環境の登場」,「CASEツールの導入」,そして何らかの「業務に特化した開発環境を購入し組み合わせて使う」,といった時代遷移があった。

そして今日のEclipseの台頭。これが時代をさらに変化させ,今後は「案件に適合した案件ごとの開発環境の準備と利用」が加速されるはずだと睨(にら)んでいる。Eclipseのプラグイン機構と拡張ポイント機構による柔軟性や拡張性の結果,またオープンソースプロダクトの多岐にわたる登場の結果,安価に,手軽に,案件独自の「開発フレームワーク」を作り出すことができる時代が到来している。

この「開発フレームワーク」は,目の前の案件に特化して必ず存在する「規約」をEclipseプラグインとして織り込み,開発者に制限を与えるというものだ。これにより開発手法や成果物に秩序が生まれ,納品後の保守のコストがほぼ100%計算できるようになる(もちろん従来よりもコスト削減された形で)。これについては,「 JavaOne Tokyo 2005 “Call for Papers”申し込み」 by arclampでエントリされているように,JavaOneのセッションとして応募した(残念ながら不採用)。このエントリに書かれたabstractを読んでいただければ,開発フレームワークの魅力が伝わると思う。

さて,開発フレームワークと聞いて,普通は「超実装寄りなもの」として捉えると思う。かくいう自分もそうだったし,いまやっている案件でも,実装作業や納品後の保守を考えて,開発フレームワークを仕立て上げた。

しかし,開発は実装だけではない。試験もある。というか,試験の方が重要だ。

近年EoD(Ease of Development)が叫ばれているが,「 実装とテストの微妙な関係」のエントリでEoT(Ease of Tesing)という言葉を使ったとおり,試験の容易性をも考えていくことが開発プロジェクトの成功を握っていくと思っている。試験の準備作業は,実装の作業量よりも多く,そして重要だ。そんな作業を軽減してあげることも,開発フレームワークでできるはず,だと思う。

例えば,画面設計書には「○○をすると△△機能を実行する」という記述が行われるだろう。さらに機能設計書には「成功すれば□□画面を表示する」という記述がされるはずだ。これらの設計書がExcelファイルで書かれていたとすると,開発フレームワークは,各Excelファイルを読み込んで,一旦以下のような中間形式に落とす。

version=”1.0” encoding=”UTF-8”?

              

    

           

      

    

           

      

    

           

      

    

  

              

    

           

      

    

           

      

    

           

      

    

           

      

    

  

screen要素が画面を表し,action要素が機能を表す。そしてcall要素で,何をするかを記述している。各画面でどの機能,どの画面が呼び出されるのか,機能の処理結果によりどの画面が表示されるかを解析することにより,自動的に以下のようなテストシナリオを開発フレームワークは提供することができるはずだ。

  • (entry) -> ログイン画面 -> (ログインボタン押下) -> [ログイン処理] -> {認証成功} -> メニュー画面 -> (パスワード変更リンククリック) -> パスワード変更画面 -> (変更ボタン押下) -> [パスワード変更処理] -> {変更成功} -> メニュー画面
  • (entry) -> ログイン画面 -> (ログインボタン押下) -> [ログイン処理] -> {認証成功} -> メニュー画面 -> (パスワード変更リンククリック) -> パスワード変更画面 -> (変更ボタン押下) -> [パスワード変更処理] -> {変更失敗} -> パスワード変更画面

  • (entry) -> ログイン画面 -> (ログインボタン押下) -> [ログイン処理] -> {認証成功} -> メニュー画面 -> (パスワード変更リンククリック) -> パスワード変更画面 -> (戻るボタン押下) -> メニュー画面

  • (entry) -> ログイン画面 -> (ログインボタン押下) -> [ログイン処理] -> {認証成功} -> メニュー画面 -> (社員登録リンククリック) -> 社員登録画面 -> (確認ボタン押下) -> 社員登録確認画面 -> (登録ボタン押下) -> [社員登録処理] -> {登録成功} -> メニュー画面

  • (entry) -> ログイン画面 -> (ログインボタン押下) -> [ログイン処理] -> {認証成功} -> メニュー画面 -> (社員登録リンククリック) -> 社員登録画面 -> (確認ボタン押下) -> 社員登録確認画面 -> (登録ボタン押下) -> [社員登録処理] -> {登録失敗} -> 社員登録画面

  • (entry) -> ログイン画面 -> (ログインボタン押下) -> [ログイン処理] -> {認証成功} -> メニュー画面 -> (社員登録リンククリック) -> 社員登録画面 -> (確認ボタン押下) -> 社員登録確認画面 -> (戻るボタン押下) -> 社員登録画面

  • (entry) -> ログイン画面 -> (ログインボタン押下) -> [ログイン処理] -> {認証成功} -> メニュー画面 -> (社員登録リンククリック) -> 社員登録画面 -> (戻るボタン押下) -> メニュー画面

  • (entry) -> ログイン画面 -> (ログインボタン押下) -> [ログイン処理] -> {認証失敗} -> ログイン画面

もちろん設計書のレビューが行われているという前提がないと,設計書からの自動生成を試験で使用することはご法度だが,もしその前提が成り立てば,テストシナリオの自動生成はかなり魅力的だと思うのだが,自分だけだろうか?試験で一番怖いことは「抜けがあること」だ。それを防ぐためにコンピュータに作業を頼ることは非常に理に適っている。実際にはこんなに単純ではないと思うが,例えば機能の失敗条件を設計書から自動的に拾うことができれば,もっと細かなテストシナリオを出力することができるだろうし,かなりEoTの実現に近づくと思う。そして,設計書を育てることで,自動的にテストシナリオも育てられることになり,きっと「ここをやれば機能追加の影響を受けた部分の試験がカバーできる」といった情報も提供でき,継続的な保守作業,すなわちEoTができるようになるはずだ。

僕は信じている。これは理想論じゃない,と。

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて