アプリ開発やサイト制作のスマホ端末実機検証・テスト-Remote TestKit

テストの自動化と「Remote Testkit」



テストの自動化と「Remote Testkit」

1.はじめに

みなさんは、プログラムを書く事は好きですか? おそらく、この記事を読むみなさんは、職業的にプログラムを書いたり、なんらかの形で日常的にソフトウエアの開発に従事されている方だと思います。多くの人はプログラムする事に、ものづくりの楽しさや学ぶ事の喜びを感じながら、日々コードを書いているのではないでしょうか。 みなさんは、プログラムをテストする事は好きですか? おそらく、みなさんの多くは「好き」と言わないと思います。それより積極的に「嫌い」「単調だ」「苦痛だ」という意見も多いのではないかと思います。ただし、今日のソフトウエアの複雑さと社会的重要性から、テストが不要だ、と断言するエンジニアはほとんどいないと思います。多くのエンジニアはテストの重要性を十分認め、これは単に楽しみのためのプログラムではなくて、必要だから、と自分に言い聞かせながらテストをやっているのではないでしょうか。 この差は一体どこから生じるのでしょうか?また、この様に単調なテスト業務を皆さんが大好きなプログラムを書く事のようにする事はできないでしょうか?さらに、プログラミングと比較して労働集約型になりがちで生産性が高いとは言えないテスト業務の効率をもっと高めることはできないでしょうか? この記事はそんな皆さんに、ソフトウエアのテストをもっと効率よく、もっと積極的に、さらに欲張って、スマホの開発を楽しくするためのヒントを書いていきたいと思います。また、この記事では、スマホアプリの開発で最先端の技術を集約した「Remote TestKit」が、快適で効率のよい開発にかかせないツールである事を示していきます。

2.ソフトウエア開発プロセスとテスト

ソフトウエアの開発では主に以下の様な手法で開発を進行し、作成したコードをテストし、その品質を評価します。 ・「V字モデル」 ・「テスト駆動開発(TDD)」 1)V字モデル 「V字モデル」は、伝統的なソフトウェア開発手法です。 「V字モデル」は、開発工程を「設計する工程」→「実装(コーディング)」→「テストする工程」のフェーズで実施します。 V-test
図1.V字モデル
このモデルは大変実績のある有名なモデルです。ただ、設計する工程とテストする工程が分離しており、リソースを比較的多く必要とし、規模も大きくなります。そのため、バグなど不具合の把握とその修正の工程が分離し、修正までの時間も長くなります。つまり不具合を修正するための「フィードバック・ループ」が長く、応答するスピードも遅いと言えます。

3.テスト駆動開発(TDD)

テスト駆動開発(TDD)は、アジャイル開発の実践手法の1つとして2010年頃から導入されつつある手法です。 キーポイントは「テストファースト」です。これは、コードを実装する事(コーディング)に先立ち、テスト用のコードを作成する事を意味します。TDD は、この「テストファースト」に則った、開発手法の事です。手順を以下に示します。 1.実装すべき機能からTODOリストを作成する。 2.TODOリストから、テストコードを作成する。 この時点では、プログラムの本体部である、コード実装はまだ作成しません。それより先に通常のプログラムスタイルでは脇役であることが多い、テストコードを先に書きます。 3.ブランクのコード実装を行う(レッド)。 「ブランクのコード実装」とは、例えば、クラスと最小限のメソッドだけを定義して、メソッドの中身は、ほとんど何も書かない様な事です。したがって、この時点でテストを行っても、その結果は、当然エラーとなります。この工程でエラーがある事を「レッド」と呼びます。 4.上記のテストでエラーがなくなる様に最低限のコード実装を書いていく(グリーン)。 先ほどのブランクのコード実装の中身を、そのモジュールが最低限の振る舞いを満たす様に充実させて行きます。この作業により、このモジュールは、ついにはエラーを出さなくなるでしょう。この工程でエラーがなくなった事を「グリーン」と呼びます。 5.最低限のコード実装の内容を見直し、よりふさわしいコードに書き直す(リファクタリング)。 上記4.の工程では、必要最低限でコード本体はかろうじて動作しているだけにすぎません。プログラマはこの工程で、オブジェクトとしての実装コードを「あるべき姿」を考え、最適化していきます。 TDD-test
図2.テスト駆動開発(TDD)の手順
TDDでは、最初にオブジェクトとしての実装コードにふさわしい振る舞いをルールとして規定し、次に実装コードがこのルールを満たす様に作り上げていく作業を実施します。ここで「オブジェクト」と明記した様に、この手法は、オブジェクト指向と親和性が高く、実装コード/テストを一対とした「小さなフィードバック・ループ」を構成しています。そのため、該当する箇所の不具合・改善までの応答期間を大幅に短縮できます。 反面、TDD はプログラマがテストコードも作成するため、導入初期には工数が増えることになります。さらにオブジェクト指向の考え方を縦横に駆使するため、いままでとの文化の違いや考え方の切り替えに戸惑ったり、苦労することも多い様です。また当然のことながら、プログラムで対応することが難しい箇所は、TDD でも管理することは困難となります。一般的にTDD は V字モデル の単体(モジュール)テストの箇所で採用されます。プログラムで対応することが難しいというのは、コンピュータでの制御が及ばない範囲である、「(物理的な意味での)モノ」や「人」などを意味します。具体的には、人が手で操作しないとアクセスできない携帯電話やスマホ、属人化した作業プロセスなどを指します。

4.これからのテストと Remote TestKit

このTDD のループ構成は、ロボットなどの開発で用いられる制御理論の様に単体テスト → 結合・機能テスト → システムテストへとループ構成の範囲を広げていく事が可能でしょう。これは、ノーバート・ウィーナーが提唱したサイバネティックスをソフトウエアの開発に適用した例と言えるでしょう。 最近、Jenkinsなどの継続的インテグレーションツール(CI ツール)が注目を浴びています。 このツールをハブとし、さらにコンパイルの自動化や Selenium などと連携することで、各種のサイト・アプリ開発が自動化できます。 一方、「Remote TestKit」は、ネットワークを介し、スマホ実機にアクセスするサービスです。 このサービスは、手元になくても、たくさんのスマホを使った試験環境を提供します。そのため開発者はたくさんのスマホを用意する手間や、コスト、それを用意する場所に制約されなくても実機テストをできる、というメリットがあります。さらに、これ以上に大きな可能性を持つのが、「ネットワークを介し、スマホ実機のUIにアクセスできる」ということです。 ・ソフトウエア的な開発手法のTDD ・ネットワーク上でつながる各種 CI ツール ・ネットワークでUI操作できるスマホ実機 つまり、上記で述べたほぼすべての開発に関するアイテムがネットワークを介して1つのシステムとして運用できるという事になります。しかも、この一連のシステムの中の主役であるスマホは、単なるスタブや仮想のオブジェクトではなく文字通りの「実機」です。このことから、「Remote TestKit」は、いままで困難だった実機を使ったテスト自動化まで、ITに於ける検証の可能性を広げることにもなるでしょう。

5.この記事で紹介すること

次回から、具体的にオープンソースの各種CI ツールの使い方の紹介と、これを「Remote TestKit」と連携させることで自動テストのエコシステムを構築する手法を紹介していきたいと思います。 それでは、宜しくお願いします。

執筆者 丸地弘城

用語集

サイバネティックス 通信工学・制御工学を融合し、機械工学、システム工学、生理学、社会学などの幅広い分野を統一的に扱う学問。ノーバート・ウィーナー(1894~1964)提唱。 Jenkins オープンソースの継続的インテグレーションツール。 継続的インテグレーション(CI、Continuous Integration) ビルド、テスト、ドキュメント作成などを継続的に実施する事で、開発作業の各種品質をより良くする生産活動の事。 Selenium Webアプリケーション用テストツール。このツールはブラウザそのものの操作を記録し、実行できる。 ノマド(nomad) 遊牧民。転じて、ITを駆使したオフィスや組織以外の様々な場所で仕事をするワークスタイルの事。 デプロイ 開発したソフトウェアをターゲットとする環境に展開し、可動可能にする事。 広義にはインストールに近い意味を持つが、それに加え、関連モジュール、設定ファイル、アクセス制限などターゲットとなるシステム 全体がサービスを提供できる様するための各種設定を行う事も含む。

参考文献

Jr.,フレデリック・P. ブルックス、「人月の神話」、ピアソンエデュケーション ケントベック、「XPエクストリーム・プログラミング入門」、ピアソンエデュケーション 高橋 寿一、「知識ゼロから学ぶソフトウェアテスト」、翔泳社 石原 一宏、布施 昌弘「いちばんやさしいソフトウェアテストの本」、技術評論社 石原 一宏、田中 英和 (著)、田中 真史「ソフトウェアテストの教科書」、ソフトバンククリエイティブ 大西 建児、「ソフトウエアテスト実践ガイド」、日経BP社 Mark Fewster, Dorothy Graham 他「システムテスト自動化 標準ガイド」、翔泳社 (株)テクノロジックアート、長瀬嘉秀他「テスト駆動開発」、東京電機大学出版局 Steve Freeman、Nat Pryce、「実践テスト駆動開発」、翔泳社