こんにちは。LINE Technology Vietnamで働いているThiです。今回の記事では、テストの最適化が必要な理由について考え、テストを最適化するいくつかの方法について紹介します。
テストの最適化が必要な理由
まず、以下の問いかけをもとにしてテストの最適化が必要な理由を考えてみます。
- ユーザーは何を求めているか
- 私たちは何をしているか
- 私たちには何ができるか
ユーザーは何を求めているか
ユーザーは何を求めているのでしょうか。答えは簡単です。ユーザーは完璧なアプリを求めています。ユーザーは小さなミスであったとしても、見つけた瞬間にアプリから離脱することがあります。この記事を読んでいる方の中にも、誤字脱字や文法ミスを発見したり、性能が良くなかったり、使い勝手が悪いという理由で使わなくなったアプリが、1つくらいはある思います。
一方、アプリを開発する側としては、ユーザーになるべく長く自分たちのアプリを使用してほしいと考えます。そのために、私たちはより体系的かつ徹底的に要件と仕様を検証し、完璧なアプリを作る必要があります。
私たちは何をしているか
私たちは、ユーザーの期待に応えるため、そしてユーザーが離脱しないように、いろいろなことに取り組む必要があります。できるだけ多くのデバイスに対応し、さまざまなOSのさまざまなブラウザに対応する必要があります。しかし、テスターの人数は限られているうえ、リリースの日程は決まっているため、時間が足りない状況になりがちです。
さらに、作業を始めるといくつかの不測の事態に見舞われます。例えば、テストの開始予定日になってもリリースが完了していなかったり、その日の真夜中ごろに行われたりします。そして、想定よりはるかに多いバグが発生したり、その多くのバグを処理しても再びバグが発生したりもします。それらのバグを処理したとしてもまたもやバグが発生するなど、何度も繰り返してバグが発生することがあります。このような悪条件のため、テスト後に確認する回帰テストを行う過程でさらに時間がかかってしまいます。このように処理すべき作業量が常に多く、さまざまな悪条件も重なりますが、私たちはそれらを乗り越えなければなりません。
私たちには何ができるか
限られたリソースと厳しい日程の中で、できるだけ最高の品質を達成するために、私たちには何ができるのでしょうか？ プロジェクトの観点から見ると、仕様やコードはもちろん、プロセスからテストまですべてのことを最適化できますが、今回はテストを最適化することに集中して考えます。ご存じのとおり、テストに必要なリソースの多くは、テストケースの準備とテストの実行に投入されます。テストの実行に投入されるリソースと時間は、テストケースの質と量に左右されるため、テストケースを最適化すると自然とテストの実行を最適化できます。
ここからは、テストケースを最適化できるいくつかの方法について紹介します。まず、テストの設計について説明し、テストの設計だけでは満たせない部分を補うためにLINEで適用している3つの方法を紹介したいと思います。
テストの設計
テストの設計について説明する前に、なぜテストを設計する必要があるかについてを考えてみます。
なぜテストを設計する必要があるのか
テストケースを作る方法は2つあります。1つ目は、個人の経験に基づいて作る方法です。この方法は、テスターが持っているシステムやドメインについての知識、テストケースを作成するスキルに依存します。2つ目は、テストケースの設計手法に基づいた方法です。設計手法には、個人の経験よりはるかに多い人々の経験が集約されています。設計手法を適用してテストケースを作成すると、個人の経験に基づいたものより多くのドメインやプロジェクトに適用できるので、同じ労力でより大きい領域をカバーできます。そのため、個人の限られた経験に頼らずに設計手法を適用する方が、テストケースをより効率よく作成できます。
建築を例に挙げてみます。以下の2つの建物は、何人かの建築家が自身の経験に基づいて直接建てたものです。これらの家を自ら建てた人は、立派な建築家に違いはありませんが、そういった作業は誰にでもできるわけではありません。また、このような何世帯も住むことができる家を建てるまでは、6年というかなりの時間がかかったそうです。
次は別の建築物を見てみます。左側の画像には、ベトナムで最も高いビルが写っています。右側の建物は、左側のように高くて規模の大きいものではありませんが、とても素敵な外観を持っています。
このような建物は、個人の経験だけでは建てられません。技術的かつ芸術的に完璧な設計が必要です。規模が大きく高いビルを建てる際、素敵な外観にしながらも機能の最適化をして、そのうえで作業を短時間で終わらせる必要があるときは、個人の経験だけでは不十分です。限られた経験だけでは、そのような建物を建てることはできません。
ソフトウェアも同じです。とても簡単なソフトウェアを時間の制約なしに開発することは、少人数の経験だけでも可能ですが、複雑な機能を持ち性能もいいソフトウェアを限られた時間内に開発するときは、設計が必要です。このような設計は、開発するときだけでなくメンテナンス時にも必要となります。バグの修正や機能の変更が必要なときにそのソフトウェアの基盤となる設計がないと、変更の影響を予測してバグを再度確認し、回帰テストを行うことに、より多くの時間が必要です。また、そのような状況はリソースと時間の無駄に繋がるでしょう。テストケースも同じです。テストケースに設計がないと、理解しにくくてメンテナンスに困り、時間とリソースの無駄に繋がるはずです。適切な設計がないと、いくらテストケースが多くても実際にカバレッジはどのくらいになるのかすぐには分かりません。また、設計が適用されているより少ない数のテストケースより、むしろカバレッジが低いこともあります。このような理由で、私たちは設計に基づいたテストケースの最適化について、真剣に考えて適用してみる必要があります。
いつ、どのような設計手法を適用するか
適切な設計手法を効率よく適用することは、簡単ではありません。いつ、どのような設計手法を適用するかについて、私たちもまだ「これが正解だ」と言える答えを発見できていませんが、さまざまなプロジェクトの経験で積み重ねてきた事例をいくつか紹介します。
EP-BVA手法の適用事例
私たちは、入力値が多くないシンプルなページにはEP-BVA1 手法を適用しています。左側の画面を見てみましょう。コメントとニックネームを入力でき、1から5までの星を付けることができる、とてもシンプルな画面です。
この画面にEP-BVA手法を適用すると、9つのテストケースが出てきます。もし、このページで可能なすべての組み合わせをテストするとしたら、100のテストケースの組み合わせができます。そうなると、テストに時間がかかり、他の重要な画面や機能に手が回らないかもしれません。現在、シンプルなページにはEP-BVA手法を使用していますが、それで十分だと考えています。
ペアワイズ手法の適用事例
入力と出力が多いページをテストするときは、ペアワイズ（pairwise)2 手法を使用しました。その事例を2紹介します。
LINEトーク占いプロジェクト
まず、LINEトーク占いプロジェクトです。 LINEトーク占いは、占い師とユーザーをつなげるサービスです。ユーザーは、プロの占い師を選択して占いを確認できます。
LINEトーク占いのシステムでは、出力はさまざまな条件と値に影響を受けます。例えば、占い師のグレード（ベーシック、ゴールド、プラチナ、ダイヤモンド、ブラック）は、価格に影響を与えます。ユーザーは、プロモーションパネルから無料チケットを得ることができ、その後さらに有料チケットを購入したり、チケット購入の代わりにクレジット支払いもできます。ユーザーは占い師に相談を受けた後、レビューを残すこともあるし、残さないこともあると思います。相談時間は、10分以内にもなるし、それ以上のとても長い時間になることもあります。このような条件を考えてみると、もし設計なしにテストケースを作成する場合、どれだけ多くのケースになるのか予測できません。可能性のあるすべての組み合わせを計算してみると、全部のテストケースは1000を超えますが、ペアワイズ手法を適用すると、20ほどに減らすことができました。なんと1000のケースを減らしたのです。また、単に数字だけ減らしたのではなく、テストカバレッジも高くて追跡も簡単でした。
HOPプロジェクト
ペアワイズ手法を適用した2つ目の事例は、HOPプロジェクトです。HOPは、LINEのソーシャルグラフを利用してパートナーを探し、マッチングさせるアプリです。
HOPプロジェクトでは、LINE公式アカウントから送信されるメッセージの確認が必要でした。LINE公式アカウントのメッセージは、ターゲットユーザーとメッセージタイプなど、さまざまな設定によって異なるコンテンツが含まれ、それぞれ異なる表示になります。このプロジェクトもテストケースに設計を適用しなかったら、どれだけ多くのテストケースになるのか分かりませんでした。すべての組み合わせを考慮すると252のテストケースが考えられましたが、ペアワイズ手法を適用したら30のテストケースでカバーできました。
状態遷移手法の適用事例
システムフローをテストするときは、状態遷移手法3を使用しました。長いビジネスフローや、イベント配列をテストするときに使用する手法です。この手法を適用した「Support Plan」プロジェクトの事例を紹介します。
Support PlanプロジェクトはLINEトーク占いのサブプロジェクトで、占い師がより効果的に顧客に会えるよう、毎月購入できるマーケティングプランを占い師に提供することを目指しています。例えば、マーケティングプランを購入したい占い師がいると想定します。占い師は、プロモーションパネルから通常より安い値段でマーケティングプランを購入できます。この値段は6か月間維持され、その後は通常の値段に戻ります。占い師は手動で決済の取り消しができる他、購入時に使ったクレジットカードに問題が発生した場合には、自動的に決済が取り消しとなります。
このようなプロジェクトのテストケースを作成するときに設計手法を適用しないと、導出されたテストケースのカバレッジを予測することは非常に難しくなります。だからと言ってすべての組み合わせをテストすると、テストだけで2週間以上が必要になるかもしれません。その問題を、状態遷移手法を適用して解決できました。
以下は、Support Planプロジェクトに状態遷移手法を適用して導出したテストケースです。最初は、以下の画像の１つ目の表のように6つのテストケースを導出しました。また、のちにテストケースを改善し、複雑なプロジェクトのロジックを限られた時間内でテストするのに適していると判断した17のテストケースを導出して使用しました。
テストの設計と一緒に適用すると良い３つのこと
ここまでテストを設計することについて説明しました。実は、良いテストケースを作るためには、設計するだけでは十分ではありません。なぜなら、設計するだけでは達成できない面があるからです。そこでLINEでは、設計とともに共通のテストケースを作り、そのテストケースの再利用、テストケースの構造化、テストケースの分割を行っています。これによって、テストケースのレビューや更新にかかる時間を短縮しながらも、テストレポートのデータをより明確にし、結果をさらによく推定できるようになります。その各段階についてより詳しく説明します。
共通のテストケースを再利用
現在、私たちは他のプロジェクトに再利用できる共通のテストケースを約800用意しています。共通のテストケースを用意しておくと、テストケースをレビューして、テストを行いチェックリストを作成するに必要な時間を節約できます。
以下の左側は、「プッシュ通知」について通常のテストケースをまとめたものです。新しいプロジェクトでプッシュ通知についてテストが必要になると、このテストケースを利用しています。また、右側は「CSVエクスポート」についての共通のテストケースです。「CSVエクスポート」についてテストが必要な場合も同様に、このテストケースを利用しています。
私たちは、共通のテストケースを継続して管理し、新しいテストケースが作られるたびに、共通化できるか検討して、必要なものを共通のテストケースに追加しています。
テストケースの構造化
次にお話ししたいのは、全体のテストケースを構造化することです。テストケースを構造化すると、レビュー時間やテストケースの更新時間を短縮できます。
例えば、まず一般的にユーザーがUIで経験する重大な不備がないかを確認するためのテストケースをまとめ、次に主要機能を確認するためのテストケースをまとめます。その後にナビゲーションやUX、または特定の要件を検証するためのテストケース、そして最後に経験に基づき、危険な部分やバグを引き起こすようなテストケースをまとめて配置します。
このようにテストケースを構造化しておくと、レビュアーが全体のテストケースの設計構造とアイデアを理解しやすくなり、レビュー時間を短縮できます。また、テスターが更新する位置と対象を速やかに把握でき、テストケースの更新にかかる時間も短縮できます。結果として、テストを行う時間も節約できます。以下は、私たちが作ったテストケース構造の例です。画像の上からUI、主要機能の順にグループ化されています。
テストケースの分割
最後に、テストケースを分割することについて説明します。場合によっては、時間を節約するために小さなテストケースを大きなテストケースに結合する必要があることがあります。しかし、そのような結合は最初は早く進んでいるように見えますが、結局は後で問題が発生します。例えば、いくつかのテストケースでテスターが検証すべき複数のシナリオを全部確認できないこともあり、最初の段階のとても小さな失敗が全体のテストケースの失敗に繋がることもあります。その結果、バグを確認するためにとても長いテストケースを再実行することになる可能性もあります。また、回帰テストを行う際、実際に危険になるのはいくつかの段階だけなのに、長いテストケースをすべて実行しなければならないこともあります。テストケースを分割すると、このような問題の発生を防ぐだけでなく、テストレポートのデータもより明確になってテスト結果の確認にも役立ちます。
おわりに
ここまで、テストを最適化する方法について紹介しました。簡単にまとめますと、1つ目はテストケースを作成する際に適切な設計手法を使用すること、2つ目は共通のテストケースを再利用すること、3つ目はテストケースの構造を管理すること、最後はテストケースを適切に分割することです。
テストを最適化すると、限られたリソースと時間でも完璧な品質のソフトウェアを作ることができます。テストケースについて困っている方が、今回の記事で紹介した方法を参考にしていただくことを願って、終わりにしたいと思います。貴重なお時間を割き、読んでいただきありがとうございました。
- EP-BVA：EPは同等分割（Equivalence Partitioning）手法で、プログラムの入力値と出力値が特定グループになっており、分類されたグループの値をシステムで同じく取り扱うという特性を利用したテスト手法です。BVAは、境界値分析（Boundary Value Analysis）手法で、同等分割を拡張した形です。
- ペアワイズ（pairwise）：可能なすべての入力値の組み合わせをテストする代わりに、ペアの組み合わせでテストする方法です。
- 状態遷移（state transition）：あるイベントが発生したとき、テスト対象が別の状態に遷移される場合の数をテストする方法です。