開発ツールの本来の目的を考える

はじめに

今回「開発ツールの最新動向に関して一筆」…というのが、編集部からいただいたお題でした。一口に最新動向とは言っても「オープンソースvs 有償ツール」とか「クラウド対応」などさまざまな切り口があり、何を書こうかと少々迷っていました。

しかし、こういうときは原点回帰が大事です。「そもそも開発ツールとは、開発者の作業負担を軽くするツールである」と位置づけると、「開発作業を阻害する要因」をどう捕らえているかで、大きな流れが見えてきます。

筆者が所属するRationalというIBMのソフトウエアブランドは、創立期から含めると30年以上もの間、開発者のためにさまざまな“道具立て”を提供してきました。近年、Jazzテクノロジーと称する技術基盤を新たに構築していますが、このコンセプトを見ると、これから対処すべき「開発作業を阻害する要因」が見えてきます。

本連載では、ひとつの切り口として、このJazzテクノロジーを通して、これからの開発ツールが備えるべき要件を考えてみたいと思います。

動画：GUI自動化テストツールの動作例

開発ツールの分類学（1）

「開発ツールは今後どこに向かっていくのか？」を論じる前に、「これまでは、何を課題としてきたのか？」を振り 返ってみましょう。

個人の生産性を高める

「開発ツール」という言葉からまず真っ先に思い浮かぶイメージが、「生産活動を直接効率化する」というものでしょう。

筆者が20数年前にソフトウエアエンジニアとしてキャリアを開始した当初は、紙に書かれた設計図から、エディタ+コンパイラ+デバッガの3種の神器でし こしことコードを書き興したものです（世間ではGUIベースのツールが出始めたころで、指をくわえて横目で見ていたものです /；o；）。

設計図からコードを書き興すには、不完全ながらある程度変換のパターンが存在します。開発ツールの切り口のひとつは、以下に挙げるような“生産の効率 化”です。

• グラフィカルにGUIを作成すると、それを元にコードを生成する。
• 各種の設計ダイヤグラム（UMLのクラス図やER図）から、それを反映した実装コードを生成する。
• 生テキストでは詳しい人にしかわからない各種の設定ファイルを、ダイアログで設定する、等々。

“パターンを自動化する“という意味では、「定型的な作業を自動化する」という切り口もあります。代表的なモノは、GUIのテストツールでしょう。

アプリケーションがGUIを備えるようになって開発者の手間が増えたのが、テスト工程でした。”テスト手順書“にしたがって、テスターが「リストからあ るデータを選択」し「登録ボタンをクリック」し、「画面が切り替わった」ら「売り上げ欄が正しい値かを確認」する…この類の決まりきった手順を実施し続け るというのは、人が不得手とするものの代表です。

一見楽な作業に見えますが、しばらく続けると以下のような問題が発生してきます。

• 件数が増えてくると、集中力が続かず、操作ミスのほうが無視できなくなってくる。
• 同じテストを繰り返していると、きちんと確認せず、思い込みで「確認したような気になる」、いわゆる“みなし”が発生する。
• なにより、手順のひとつひとつをテスト手順書と首っ引きで作業するので、とにかく時間がかかる。

時間がかかる割に、精度や再現性は決して高いとは言えません。これらを解決するのがGUIの自動化テストです（利用シナリオの視点で、“機能テストツー ル”や“回帰テストツール”と紹介されることもあります）。

自動化テストは、GUIオブジェクトとそれへの操作指示（クリックやデータの入出力）、チェックポイントの組み合わせを、何らかのスクリプトという形で 作成し、このスクリプトを自動的に実行するというものです。

スクリプト記述として何を使うか（XML、Javaプログラム）、スクリプトの作成を手作業で行うのか操作を記録するのか、ツールによってさまざまなや り方がありますが、一度準備ができてしまうと、実行効率は人の手に比べて十倍以上…ということも珍しくなく、非常に有効です。

上記のように、自動化はその適用範囲を着々と広げています。同様な仕組みでWebアプリケーションへの負荷テスト・性能テストでユーザーの操作シナリオ を自動実行してみたり、コードを解析したりして、単体テスト環境を作成するツール等の発展が今後も期待されます。