ソフトウェア開発の際は「ソフトウェアテスト」によってバグや不具合を見つけて修正してからリリースに踏み切ることが多いといいます。

ただ、近年はブラウザだけでなくモバイルアプリも加わってソフトウェア開発の大規模化・複雑化が進み、テストの比重は年々大きくなってるとのこと。

今回から始まる連載では、ノーコードでソフトウェアテストの自動化を実現させる、AIテスト自動化プラットフォーム「MagicPod」を運営する株式会社MagicPodのメンバーに、「ソフトウェアテスト自動化の今とこれから」を3回にわたって解説していただきます。

第1回目では、長年ソフトウェアテストに関わってきた経験を持つ、MagicPodのテックリード（エンジニアチームのリーダーとなる役割）である玉川紘子氏に、ソフトウェアテストの種類やテスト自動化の向き不向き、テスト自動化の先に見えてきたことについてご寄稿いただきました。

第2回はこちら
第3回はこちら

ソフトウェアテストとは何か

ソフトウェアテストは、ソフトウェアが正常に動作するかどうかを確認する作業のことで、ソフトウェアの品質を保つために欠かせない工程の1つです。

ソフトウェアテストをおろそかにすると、例えば「ログインできない」「押しても反応しない」「間違ったページに飛んでしまう」といったバグや不具合が起きるサービス・プロダクトの提供につながってしまいます。

そのため、ソフトウェア開発ではソフトウェアテストによってバグや不具合を見つけて修正し、改善した状態でリリースするように心がけています。

ただ、現在主流になっているアジャイル開発（*1）では、短期間に何度もリリースが行われるため、その度にテストを実施しなければいけません。

また、ブラウザだけでなくモバイルアプリも加わってソフトウェア開発の大規模化・複雑化が進み、テストの種類が増えることで、その比重は年々大きくなっています。

「それならテストをたくさんすればいい」という話になりますが、そうすると「誰が」「どのようにテストをするのか」という問題が出てきます。

一口にテストと言っても、ユニットテストや機能テスト、回帰テスト、探索的テストなど、様々な種類があります（各テストの内容については後述します）。

機械が得意なテストもあれば、人間でないと実施できないテストもあります。「手動で実施しているすべてのテストを自動化して機械に任せばいい」という単純な話ではありませんし、そもそもテストの設計は専門スキルを持った人が行わないとうまくできません。

*1…ソフトウェアを素早く提供することを重視し、小単位で実装とテストを繰り返すシステム開発手法

ソフトウェアテストの種類

テスト自動化は「誰がどのようにソフトウェアテストをたくさんするのか」の答えの1つとなりますが、先ほども書いた通り、一口にテストと言っても自動化に向いているもの、向いていないものがあります。

その説明をする前に、まずはソフトウェアテストにどのような種類があるのか「テストレベル」「テストタイプ」の2つの軸で紹介します。

1. テストレベル

テストの粒度とも言うべき「テストレベル」は、「コンポーネントテスト」「統合テスト」「システムテスト」の3つに分かれます。

「コンポーネントテスト」はモジュールやコンポーネント単位で行う最小単位のテストで、それらを組み合わせて正常に動作するかを確認するのが「統合テスト」です。そして、システム全体が仕様書通りに動くかを確認するのが「システムテスト」です。

ここで挙げたのはJSTQB（Japan Software Testing Qualifications Board：日本におけるソフトウェアテスト技術者資格の運営組織）でも採用されている用語ですが、開発の現場ではコンポーネントテストの代わりに「単体テスト」「ユニットテスト」、統合テストの代わりに「結合テスト」といった言葉も非常によく使われます。

ウォーターフォール開発（*2）では単体テストからシステムテストへと進み、発注者に完成形の「受け入れテスト」をしてもらって、問題がなければ納品となります。

一方、アジャイル開発では短期間のサイクル（スプリント）を繰り返すので、各スプリントごとに様々なテストレベルのテストを行います。

また、以前のスプリントで動作していた機能が次のスプリントで不具合を起こしていないかを確認する「リグレッションテスト（回帰テスト）」も重要です。

*2…開発プロセスを複数の工程に分けて、順番に進めていくシステム開発手法

2. テストタイプ

テストを目的別に分類したものが「テストタイプ」で、こちらは大まかに4種類あります。

この中にもいろいろな種類があり、例えば「非機能テスト」では以下のようなテストを行います。

・ユーザビリティテスト︰ユーザーの使いやすさを確認
・セキュリティテスト︰システムの脆弱性・堅牢性を確認
・ストレステスト︰過負荷に耐えられるかを確認
・パフォーマンステスト︰処理速度などを確認

テストレベルとテストタイプによる分類以外にも、特徴的なテストの種類がいくつかあります。意外な由来を持つ用語もあって面白いですね。

テスト自動化の向き・不向き

大まかにテストの種類を紹介しましたが、テストにもいろいろな種類があるのを理解していただけたかと思います。それらの中で自動化に向いているテストの特徴は、以下の通りです。

・繰り返し行う
・検証項目が多い
・手順が決まっている

先ほど紹介したテストの中で挙げるなら、「リグレッションテスト」（回帰テスト）が当てはまります。仮にそういったテストを手動で行おうとすると、アジャイル開発ならスプリントごとに膨大な手間と時間が必要になってしまいます。

開発サイクルを速く回したいのにテストがボトルネックになって進まないという課題が浮き彫りになったことで、「スピードと品質を両立させるためには自動テストが不可欠」という考え方が広まりました。その流れにテスト自動化ツールである「MagicPod」が少なからず貢献できていることは、とても喜ばしく思います。

一方、自動化に向いていないのは先ほどの特徴と逆の特徴を持つテストです。例えば「使う機会が少ないテスト」「変更が多いテスト」などが挙げられます。

「使う機会が少ないテスト」を自動化した場合は設計する労力、「変更が多いテスト」を自動化した場合は修正する労力がかかり、手動よりも高コストになってしまうかもしれません。

また、テストの中には、サイトやプロダクトの使い心地をユーザー視点で確かめる「ユーザビリティテスト」といった“人が実施するからこそ効力を発揮できるテスト”もあります。

近年注目されているAIの活躍にも期待したいところですが「想定していないバグを事前に察知するゴッドハンドのような人」の代わりができる日は、まだまだ先のことでしょう。

ちなみに、私が参加していた「テスト自動化研究会」というコミュニティでは以下のような「テスト自動化の8原則」というものを公開しているので、参考までに紹介しておきます。

1. 手動テストはなくならない
2. 手動でおこなって効果のないテストを自動化しても無駄である
3. 自動テストは書いたことしかテストしない
4. テスト自動化の効用はコスト削減だけではない
5. 自動テストシステムの開発は継続的におこなうものである
6. 自動化検討はプロジェクト初期から
7. 自動テストで新種のバグが見つかることは稀である
8. テスト結果分析という新たなタスクが生まれる

※参照︰テスト自動化研究会

自動テストのコード作成は“誰もやりたがらない領域”だった

私が専門的にソフトウェアテストと関わるようになったのは、10年ほど前です。

当時から「プログラムを書かずにブラウザ操作を記録し、自動で繰り返すようなツール」はありましたが、どうにもかゆいところに手が届かず、「何だかんだ言っても人間がテスト用のコードを書くのが正しい」という考えが主流でした。

ただ、自動テストのコードはちょっとしたデザインの変化や実行環境の違いで動かなくなってしまうことが多く、メンテナンスがしづらいという傾向があります。

そのため、普通のテスト担当者からするとコードを書くのが大変、開発者からするととにかく面倒で楽しくない、“誰もやりたがらない領域”という印象でした。

テスト自動化ツール「MagicPod」の開発

前職ではいろいろな会社で自動テストの導入コンサルをさせてもらいました。

どれも貴重な経験でしたが、だんだんと「田植えばかり繰り返している」ような気がしてきて、「農耕器具のように作業が楽になって、生産性も上がるテスト自動化ツールをつくりたい」と思うようになりました。

そんなときに代表の伊藤から「こういうものをつくろうと思っている」とMagicPodの構想を教えてもらったのですが、正直「先にやられた！」と思いました。

しかし、実際にMagicPodの開発が始まって「一緒にやりませんか」とお誘いをいただいた際は、私なんか見向きもされないと思っていたので「誘ってくれるんだ。ラッキー！」と思いました（笑）。

あれから4年ほど経って、自分がつくれると思っていた以上のところまできている気がします。ノーコードでテストを自動化できるということは重要ですが、そのせいで開発のエンジニアにとって使いにくくなってしまっては本末転倒だというのが、MagicPodに触れるまでの懸念でした。

昔から“コードを書くか、自動記録するか”という対立があり、「自動記録すると簡単に自動化できるけどメンテナンスしにくい」「コードを書くと最初は難しくてもメンテナンスしやすい」という、それぞれにメリット・デメリットがありました。

MagicPodは双方のいいとこ取りをしたイメージです。

※YouTubeでMagicPodの紹介動画を公開しています。ご覧いただけると嬉しいです。

テスト自動化の先に見えてきたこと

実用的なテスト自動化ツールが出てきたことでテスト自動化のハードルが下がったように思われるかもしれませんが、何でもできるということは「何をするか、何をしないかの判断が重要になる」ということを意味します。

「こういうテストは自動化が必要で、こっちは手動で」といった振り分けをしたり、テスト結果を分析したりするなど、自動テストが当たり前になったことでQA（Quality Assurance：品質保証）に求められるスキルセットが高度化しています。

少し前にTwitterで話題になっていた「QA不要論」は、自動化のハードルが下がった（ように思える）流れの中で「開発者だけでテストも含めてすべてをカバーできる」という発想から生まれたものでしょう。

もちろん、私は不要とは考えていません。QAエンジニアの必要性がきちんと認識され、その価値が高まっていくほうがいいと思っています。

ただ、話題になるというのは、それほど存在感が高まっている、重要性が正しく認識されるようになってきたということかもしれません。

今後は、例えば求人の際に「MagicPodが使える人は高い給料で雇います」となるように、MagicPodがテストエンジニアの価値を高める一翼を担えたらいいなと考えています。

次回は海外事業部長セティ クナールよりグローバルのソフトウェアテスト自動化について紹介します。

＜著者プロフィール＞

玉川紘子
株式会社MagicPod テックリード

東京大学大学院情報理工学研究科修了。Webエンジニアとしてキャリアを積んだ後、テストエンジニアに転向し、JenkinsやSeleniumを組み合わせたCI・自動テスト環境の構築・運用を支援。2019年よりMagicPodに入社しMagicPodの開発に従事。「初めての自動テスト」翻訳、「Seleniumデザインパターン & ベストプラクティス」監訳。的確かつさり気ないフォローで、周囲から絶対的信頼を置かれる。コープの力を借りながら、子育てと仕事の両立に日々奮闘中。

■AIテスト自動化プラットフォーム「MagicPod」について

「MagicPod」は、モバイルアプリテスト、ブラウザ（Webアプリ）テストの両方に対応したAIテスト自動化プラットフォームです。プログラミングなどの特別なスキルがなくても直感的に使うことのできるデザイン、クラウドでのサービス提供によるメンテナンス性の高さ、AI技術を活用した自動修正によるテストプログラム修正の手間削減などによりリリースサイクルの高速化を支援します。IT業界のリーディングカンパニーを中心に、すでに500社以上の企業が導入しています。