読者です 読者をやめる 読者になる 読者になる

ソフトウェア開発でクリティカルな障壁となるQAやテスト

 先日、実行委員として第二回Androidテスト祭りに参加させて頂きました。今回はレポート係も担当したので後ほどCodezineに報告記事を掲載する予定です。
 なお今回改めて実感したのが「QAやテストが、ビジネスにとってクリティカルな障壁となっている」という現状です。その実感は自分のいる医療産業でも感じることですが、Android開発では違った理由からそうなっているのが興味深いと感じています。

Android開発の現状

 ちょっと前置きが長くなりますが、まずAndroid開発では開発で取り得る選択肢が多種多様になっています。例えば多種多様なツールやフレームワーク、情報、ライブラリ、サービスなどがあり、それらを組み込むことで色々な機能を実現できます(例えばDropBox APIを使えば共有ストレージ機能を実現できますし、Twitter APIを使えばSNSとの連携も実現されます)。こうなっている背景として以下があります。

  • ここ数年のAndroid携帯の爆発的普及の影響で、Android開発に多数のツールベンダ・サービスベンダ等が参入してきています。結果、Android開発を支えるウェブサービス、開発ツール、受託、テスト等々が次々と出てきています。
  • フィーチャフォンやApple製品の垂直統合型開発に対し、Android開発はオープンソース文化を伴うオープンイノベーション型開発の傾向を強く持っています。そこではFLOSSプロジェクトや個人活動により様々なツールやライブラリ、フレームワークが作られているほか、Eclipseなど既存のオープンソースの活用も活発に行われています。
  • Android開発は、Javaという普及言語、Eclipspeという無償の普及IDEを標準で採用しているほか、技術情報の公開も活発です。そのため開発者が取り掛かりやすい分野となっており、その需要に応じてサンプルや教材、情報などがあふれています。

 こうした背景があるので、Android開発ではアプリの競争力向上につながる機能の実現が比較的容易です。

Androidアプリケーション開発の問題

 が、実現が容易といっても、実際にビジネスとしてそれを市場に投入するとなると困難が伴います。Androidアプリケーション開発では特に以下の問題が深刻化しているためです。

  • 深刻なフラグメンテーション問題。Android端末ではアプリケーションの実行環境の組み合わせが爆発しています。複数のOSバージョンが共存しています。多くの種類のAndroid携帯が存在しますし、タブレットや音楽機器、PCなど携帯電話以外の端末も存在します。また将来的な面でも、OSバージョンは頻繁にメジャーアップデートされ、携帯メーカはそれを受けて定期的にOSアップデートを促し、さらに端末も増え続ける見込みです。
    より多くのユーザをターゲットとする場合、市場投入するアプリケーションがきちんとユーザの端末で動くと保証するのが大きな負担となります。
  • セキュリティリスク。Androidの機能は開発者とユーザに開かれており、リスクある機能もユーザの許可(よく理解せず流れで許可を与える場合も多いので、十分に機能しているとは言い難いです・・)と開発者の裁量で操作できます。
    しかし一方でAndroidの端末はしばしば、個人情報やアカウント情報などセキュリティが求められる情報・機能を管理しています。またAndroidやウェブの文化としてマルウェアセキュリティホールのリスクも相対的に高いです。
    そのため開発者のミスや知識・技術力不足により、ユーザをセキュリティリスクに晒してしまう危険性を持っています。例えば自分のアプリケーションは何もやっていなくとも、パーミッションに設定ミスがあると他のマルウェア等から踏み台にされて端末内の情報やデータを悪用される可能性がありますし、SDカード上のデータやアプリケーション間インテントにプライベートな情報などを直書きすると、解析によってそれを抜き取られる可能性もあります。
    このようにセキュリティの責任が開発者側に偏重されている現状から、Android開発ではしばしばセキュリティ品質の保証に力を入れなければならなくなっています。
  • Google Playの文化。Androidのアプリケーション市場は爆発しており、日々めまぐるしくアプリケーションが入れ替わっていますし、アプリケーションが成功するとその模造アプリケーションが多数出現する風潮が生まれています。また特に日本のGoogle Playでは、アプリケーションにバグがあるとリリース時や大きなイベント時(OSアップデート等)に低評価やネガティブコメントが殺到する傾向もあります。
    そうした背景故に、スタートアップや大きなイベント時のタイミングで、きちんとアプリケーションの品質が保障できていないと、競合の後追いやネガティブレビューでチャンスを損なってしまう可能性もあります。

QAやテストがクリティカルな障壁となる

 上記のような背景があるため、ビジネスとしてのAndroidアプリケーション開発では「作るのは簡単だが、そのテストや品質保証を行うのが困難」という傾向が特に強まっていると感じます。
 そこではQAやテストがビジネスのクリティカルな障壁になりがちで(もちろんまず優先すべきはアプリケーション自体の競争力ですが)、例えば以下のような傾向が出てきます。

  • 多数のバージョンや端末での動作保証を実現するテスト体制を構築できなければ、アプリケーションのユーザは限られてしまいますし、バージョンアップへの対応が困難になる点でアプリケーションのライフサイクルも短くなります。
  • 適切な品質を確保できるテストプロセスを構築できなければ、スタートアップで悪評が集まる等して躓いたり、セキュリティ上のトラブルを起こしたりする可能性も高まります。またアプリケーションの競争力を高める機能やUIの実現が可能となっても、その動作保証ができないという理由で採用しずらくなることがあります。
  • 軽快なテストやQAを実現できなければ、OSのバージョンアップ、話題のウェブサービスAPI公開、ライバルアプリケーションへの後追いといった機会で遅れをとることになります。


 逆に上記のような問題を克服できれば、Androidの膨大な資産を柔軟に活用しつつ、より多くのユーザを対象に、長期的にアプリケーションを提供できるようになります。
 ただその実現にあたっては、前述のようにAndroid開発では諸々障害が存在していることから、当然ながらテストやQAの中で閉じた改善だけでは困難です。そこでは例えば以下のような、ソフトウェア開発ライフサイクル全体でテストやQAを支える改善が要求されると感じます。

  • 製品への要求としてテスタビリティ(特にフラグメンテーション対策としてテスト自動化)を意識する必要があります。テストの障害は開発上流から取り除くべきですし、テストのインフラ(例えばテスト自動化用インターフェース)を設計段階から積極的に組み込むべきです。フレームワークやサービスを選ぶ際も、テスタビリティを選択の指針の1つにする必要もでてくるでしょう。
  • 有限な時間や予算を効率的に使うためのリスクマネジメントも重要です。セキュリティや動作不良等ユーザに対するリスクをピックアップ・特定し、リスク軽減手段の組み込みや、リスクの重大度に基づいた有償サービスの部分導入といった工夫が有効になります。
  • テストの前倒しも重要です。テスト実施の前倒しでテストの障害を明らかにしたり、テスト分析やテスト設計を前倒しして、テストの品質やテスタビリティの向上にフィードバックをかけるといった対策が有効になります。
  • テストプロセスの現代化も重要です。テスト観点をよく分析し、開発を適切に支えるテストレベルやテストフェーズを計画したり、テスト設計にブレークダウンして効率的かつ網羅的なテストを作成したりするといった対策が有効です。これはリスクマネジメントやテストの前倒しを支える点でも重要な改善になります。


 こうしたテストやQAの考え方は、「より製品の品質を高める」という目的だけでなくて、「軽快な開発をより軽快にする」「より製品の競争力を高める」「製品仕様の選択肢を広げる」という攻めの要素も多く含んでいます。
 そこでは「テストの網羅度を高める」「工程レビューを厳格化する」とかいったありがちな足し算志向だけでは駄目で色々面倒な問題も抱えていますが、逆に同時に挑戦しがいのある課題に事欠かないとも言えます。特にAndroid開発は巷の大規模なクラウドサービスやOSなどと違い、個人や中小企業でも開発当事者になれる分野です。障壁となったQAやテストに対して、自分としても色々考えていきたいですし、仲間や業界がどのように進んでいくかもすごく興味を持っています。