本記事は『フルスタックテスティング 10のテスト手法で実践する高品質ソフトウェア開発』の「第1章 フルスタックテスティングの概要」から抜粋したものです。掲載にあたって編集しています。
フルスタックテスティングの概要
現代において、ビジネスの持続と成長にはデジタル化が不可欠です。多くの企業がこの方向性を推し進めている一方で、まだ既存のデジタルプラットフォームを近代化し始めたばかりの企業もあります。
デジタル化は、ビジネスの範囲をローカルコミュニティからグローバル規模に拡大し、より多くの人々に受け入れられ、より多くの収益につなげるための鍵です。ヘルスケア、小売、旅行、学術、ソーシャルメディア、銀行、エンターテインメントなど、さまざまな分野のほぼすべての中小企業や大企業が、新しい顧客セグメントに到達し、より高い利益を得るための重要な手段として、デジタル戦略を進めるための計画を立てています。
デジタル化と近代化に向けたこの道程において、イノベーションは重要な推進力となります。絶えずイノベーションを行う企業は、何十年にもわたって発展し続け、最先端であり続けます。
Netflixはその典型的な例で、1990年代にオンラインDVDレンタルポータルとして始まりましたが、2007年にオンラインストリーミングに進出してからは、この事業を自社のDVDレンタル事業に成り代わるまでに成長させました。
その後、Netflix Originalsと呼ばれるオリジナルコンテンツの制作を開始し、2021年末時点で、Netflixは2億人以上のグローバル加入者を持つ最大のオンラインストリーミングサービスとなりました。
技術分野はこうしたイノベーティブなビジネスに並行して、それらの高度化し続けるニーズを満たす形で進歩してきました。映画のチケットを買うために列に並んだり、めずらしい商品を買うために遠くの店舗まで車を走らせたり、手書きの買い物リストを持ち歩いて商品を探し回ったりする時代は過ぎ去りました。
技術はこのような日常的なタスクを簡単にしてくれます。私たちは家で座ってボタン1つで好きなエンターテインメント番組をストリーミングしたり、新しいドレスを仮想的に試着したり、買い物リストの商品を定期的に配達するようスケジュールしたり、音声コマンドでコーヒーを淹れたりできるようになりました。
技術の急速な進化に伴い、製品戦略は多様化し、競合他社にすばやく対抗するためにさまざまな顧客ニーズに対応する必要があります。もはやWebサイトを構築するだけでは不十分で、視野を広げなくてはなりません。UberやLyftのような配車サービス会社を考えてみましょう。
これらの会社は、Web、AndroidやiOSのモバイルプラットフォーム、さらにはWhatsAppチャットボットなど、さまざまな方法でサービスにアクセスできるようにしています。このような多様な製品戦略により、これらの企業は世界中に拡大し、競合他社を上回る成長を遂げています。
イノベーションと多様性は、企業が重要な顧客基盤を獲得し、ビジネスを成功させるために役立ちます。しかし、その先にある課題は、さらに繁栄し、より多くの収益を上げ、より多くの顧客を獲得することです。
例えば私たちは、Amazonのような業界大手が、既存の顧客基盤を活用して、拡大戦略としてサービスや製品をクロスセルしているのを見てきました。オンライン書店として始まったAmazonは、現在では生鮮食品から電子機器、アパレル、ジュエリーなどをクロスセルし、ほぼすべての市場セグメントの消費財に対する顧客需要を満たしています。
なぜソフトウェアテストの本にこうしたビジネスの話が必要なのかというと、今日のソフトウェア産業はこうしたすべてのビジネス要求に対応し、革新的なプロダクトのアイデアを実現するためのツールを提供し、それらを実世界に持ち込み、さらには世界中の新たな顧客セグメントに展開しているからです。疑いの余地もなく、ソフトウェアチームが、高品質なプロダクトを届ける最前線に立っています。
実際、ソフトウェアの品質は、現代の競争の激しい市場において、譲れない基準となっています。ソフトウェアの品質を妥協することは、負けることを承知で競争に参加するようなものです。これは多くの実例によって裏付けられています。
例えば、2014年10月、インドのECサイト大手SnapdealとFlipkartは、数ヶ月のマーケティングの後、季節セールで競合しました。残念ながら、FlipkartのWebサイトは「ビッグビリオンデー」セール中に複数回クラッシュし、圧倒的な需要に対応できず、多くの顧客と大きな収益をSnapdealに奪われました。
同様に、Yahoo!は（市場に最初に参入した部類に入るにもかかわらず）競合他社に遅れを取りました。その理由の一部は、検索エンジンの品質に注意を払わなかったことと、セキュリティ対策の不備によるブランドへのダメージで、2013年には史上最大のデータ侵害が発生し、30億のユーザーアカウントが流出しました。このように、ソフトウェア品質はビジネスに多大な影響を及ぼします。
世界中に同じような例があり、品質を妥協することでビジネスが急激な下り坂に直面することを裏付けています。たとえ企業が斬新な製品アイデアを持っていたとしても、品質が悪ければ、顧客はすぐにより信頼できる競合他社に移ってしまいます。
時には、企業はソフトウェアの品質よりも市場へ投入するスピードを優先せざるを得ない場合もありますが、それは競合他社に利用される前に解決しなければならない負債を作り出しただけだということを認識すべきです。
したがって、長期的にビジネスを維持するためには品質が不可欠であり、高品質は熟練した開発と綿密なテストの組み合わせによってのみ達成できると断言できます。その際、1つの側面だけでなく、アプリケーションを構成するスタック全体のあらゆる側面に注意を払うことが重要です。この道を歩み始めるために、本章では典型的なWebまたはモバイルアプリケーションのフルスタックテスティングに関わる内容を紹介します。
高品質のためのフルスタックテスティング
まず、ソフトウェア品質について共通の理解を得るところから始めましょう。かつてソフトウェア品質とは欠陥のないアプリケーションと同義でしたが、今日においてはそれだけではないことは誰もが同意するはずです。仮にエンドユーザーに品質を定義してもらうとすると、使いやすさやルック＆フィール、データプライバシー、レンダリング速度、24時間365日のサービス可用性などが挙げられます。
あるいは、ビジネス側に品質を定義してもらうとすれば、投資対効果、リアルタイム分析、ダウンタイムゼロ、ベンダーロックインの回避、スケーラブルなインフラ、データセキュリティ、法令遵守などが挙げられるかもしれません。これらの観点すべてが、高品質なソフトウェアを構成する要素です。これらのいずれかに不備があると、何らかの形で品質に影響を及ぼすため、綿密にテストする必要があります。
このように、品質要件は多岐にわたりますが、私たちにはそれぞれの要件に対応したツールと方法論があります。したがって、まずはそれらのツールに関する知識を得ること、そして開発とテストの両方の観点から状況に応じてそれらを適用するスキルを得ることが高品質への架け橋となります。
本書は、その架け橋を築くことを目的とし、高品質なWebおよびモバイルアプリケーションを提供するために必要なテストスキルを伝授します。
端的にいえば、テストとは、アプリケーションの動作が期待どおりであることを検証するプラクティスです。テストを合格させるには、ミクロとマクロ両方のレベルで実施する必要があります。
ミクロな側面では、クラス内のすべてのメソッド、すべての入力データ値、ログメッセージ、エラーコードなど、アプリケーションの細かい部分にそれぞれ対応したテストを行う必要があります。
同様に、機能のテスト、機能間の統合、エンドツーエンドのワークフローなど、マクロな側面にも焦点を当てる必要があります。しかし、それだけで終わりではありません。高品質なソフトウェアを提供するという最終目標を達成するために、セキュリティ、パフォーマンス、アクセシビリティ、ユーザビリティなど、アプリケーションの全体的な品質の側面をさらにテストする必要があります。
これらすべてを包含して、フルスタックテスティングが必要だといえます。図1に示すように、フルスタックテスティングは、各層（データベース、サービス、UI）とアプリケーション全体における品質の異なる側面をテストすることを指します。
実際、フルスタックテスティングと開発は、鉄道の線路の両側のレールのように切り離せないものです。両方のレールに沿って同時に進まなければ、製品に品質を組み込むことはできません。そうしないと、必ず脱線してしまいます。
例えばECアプリケーションの注文合計金額を計算する小さなコードブロックを書いているとします。このとき、コードが正しい金額を計算しているかどうかと、それが安全かどうかを並行してテストする必要があります。これを行わないと、線路に隙間ができてしまい、この壊れた線路の上で開発を続けると、統合が不十分で機能が最適でない状態になってしまいます。
このような基本的なレベルでテストを定着させるために、チームは従来のように、テストを開発後の独立した活動として考えることをやめる必要があります。フルスタックテスティングは開発と並行して開始し、デリバリーサイクル全体を通じて取り組み、より迅速なフィードバックを提供する必要があります。デリバリーサイクルの早い段階でテストを開始するプラクティスはシフトレフトテストと呼ばれ、フルスタックテスティングが適切な結果を生むための重要な原則です。
シフトレフトテスト
従来のソフトウェア開発ライフサイクルにおける活動の順序を書き出すとすると、要件分析、設計、開発、そしてテストとなり、テストは最後に位置します。図2に示すように、シフトレフトテストは、高品質な結果を生み出すために、テスト活動をサイクルの初めに移動することを提案しています。
このコンセプトを説明するたとえを考えてみましょう。あなたのチームが家を建てているとします。建設を完全に終えてから家の品質をチェックするというのは果たして賢明といえるでしょうか？ 部屋のサイズが正しくないことや、内壁が荷重に耐えられないほど弱いことが、建設を完全に終えた段階で判明したらどうでしょう？ シフトレフトテストは、計画段階から品質チェックを実施し、開発フェーズを通じてそれを継続することで、このような問題を回避しようとします。これにより、最終製品を最大限に高品質にできます。
開発フェーズを通じて品質チェックを継続するということは、小さな作業単位ごとに繰り返しチェックを行うことを意味し、必要な変更をスムーズに組み込むことができます。家の建設のたとえでいえば、壁を1枚建てるごとにチェックを行い、問題があればすぐに修正するということです。
このような広範なテストを実施するために、シフトレフトテストは自動化テストとCI/CDプラクティスに大きく依存しており、ミクロレベルとマクロレベルの品質チェックが自動化され、CIサーバー上で小さな作業単位ごとに継続的に実行されていることが必須です。
これにより、多様な品質の側面について小さな作業単位を手動でテストする場合と比べて、最小限のコストと労力で、アプリケーションが継続的にテストされることが保証されます。
これがソフトウェアの文脈で何を意味するのかを理解するために、「シフトレフトテスト」を日々の活動に分解して見ていきましょう。例えば、アジャイル開発のように反復的な開発サイクルに従うソフトウェアチームを考えてみてください。図3は、テストをシフトレフトするために、デリバリーの異なるフェーズで行う品質チェックの一部を示しています。
図3を左から読むと、ユーザーストーリーが開発準備完了とみなされる前にチームが実施する一連の品質チェックから始まります。
- 分析フェーズでは、スリーアミーゴスプロセスと呼ばれるセレモニーが行われます。ここでは、ビジネス担当者、開発者、テスターが集まり、機能について徹底的に検討します。このプロセスは、結合、エッジケース、その他のビジネス要件が見落とされないように、3つの役割の視点を集めることを目的としています。これがシフトレフト最初のステップであり、機能の要件が最初に検証されます。
- 並行して、チームのビジネス担当者はUXデザイナーと協力して、アプリケーションのデザインを検証し改善します。
- これら2つのステップが完了すると、イテレーション／スプリントの開始時にIPM（Iteration Planning Meeting）が開催され、そのイテレーションのユーザーストーリーについて詳細に議論します。これにより、チームが要件を再度集団で検証するためのオープンな場が提供されます。
- イテレーション中、開発に着手するユーザーストーリーをピックアップする直前に、ストーリーキックオフが行われます。ストーリーキックオフは、スリーアミーゴスプロセスを小規模にしたもので、特定のユーザーストーリーの要件とエッジケースについてより深く議論することに焦点を当てます。この段階までに、チームは要件を入念にテスト／検証したといえます。
同様に、ユーザーストーリーの開発中には、以下の品質チェックが組み込まれ、迅速なフィードバックを得るために活用されます。
- 開発者は各ストーリーの一部として単体テストを作成し、CIと統合します。また、静的コード解析のためのリンティングツールとプラグインを追加し、CIと統合して継続的なフィードバックを得ます。
- UIからの機能テストを作成し、CIと統合します。開発者がユーザーストーリー開発の一部として作るチームもあれば、テスターが開発後に作成するチームもあります。どちらも一般的なプラクティスです。
- 最新の変更をコミットする前に、開発者はローカルマシンで一連の自動化テストを実行します。これが最初のレベルのフィードバックです。
- 2番目のレベルのフィードバックは、各コミットに対してCI中に実行される自動化テスト（ユニット、サービス、UIなど）のスイートから得られます。
- 3番目のレベルのフィードバックは、dev-boxテストと呼ばれるプロセスから得られます。テスターとビジネス担当者が開発者のマシンで手動の探索的テストをすばやく行い、新しく開発された機能を迅速に検証します。
このように、迅速なフィードバックの提供に徹底的に焦点を当てることで、チームは開発後の手動テストを通じて得られるはずのフィードバックの約半分を、ユーザーストーリーがテストフェーズに到達する前に得ることができます。言い換えれば、テストをシフトレフトすることで、テスターたちは単に機能が期待どおりに動くかどうかを検証するのではなく、さまざまな側面からユーザーストーリーを探索する自由を得られます。
このように、シフトレフトテストは要件に対する複数回の検証を行うことで欠陥を予防し、同時にローカルの開発者マシンやCIで早期に欠陥を発見することを可能にします。さらに、テスターにさまざまな側面から探索的にテストする余地を与えることで、より高品質なソフトウェアを提供できるようになります。
注意：エクストリームプログラミング（XP）は、シフトレフトテストを取り入れたアジャイルソフトウェア開発フレームワークの一種です。XPの方法論とプラクティスについてさらに掘り下げたい場合は、Kent Beckの『エクストリームプログラミング』（オーム社）がおすすめです。
デリバリーサイクルの早い段階でテストを組み込むという概念は、アプリケーションの機能テストだけに限定されるものではなく、セキュリティテストやパフォーマンステストなど、テスト全般に適用できます。
例えば、セキュリティテストをシフトレフトする多くの方法の1つは、Talismanのようなpre-commit スキャンツールを使用することです。これは、コードをチェックインする前に、コミットの中の機密情報をスキャンして警告を出します。シフトレフトテストの実践的なアプローチについては、この後の各章で見ていきます。
全体として、このアプローチは「品質はチームの責任である」という格言を体現しています。この格言は、アプリケーション設計プロトタイプや要求などの検証といった品質チェックをソフトウェア開発サイクルの各フェーズで実施することは、異なるチームメンバーが担当すべきであることを指しています。
つまり、高品質なソフトウェアを提供するためには、チームのさまざまなメンバーがそれぞれ関連する品質チェックのためのスキルを身につけることこそが重要だということです。
10個のフルスタックテスティングスキル
テストスキルというと、つい手動テストと自動テストの2つに大別してしまいがちです。しかし、この数十年の間に技術は進化し、これらの大まかなくくりでは高品質なWebやモバイルアプリケーションを提供するために必要なさまざまな品質チェックと、そのために学ぶべき新しいスキルたちを十分に表現できません。図4は、フルスタックテスティングを効率的に実施するために必要な10個のフルスタックテスティングスキルを示しています。
10個のスキルと、それらを学ぶ必要がある理由を見ていきましょう。
手動探索的テスト
まず明確にしておくと、手動探索的テストは手動テストとは異なります。後者は与えられた要件リストを検証することを指し、必ずしも分析的な思考を必要としません。
それとは対照的に、手動探索的テストは、アプリケーションの詳細を掘り下げ、ユーザーストーリーに記載されている以外のさまざまな実際のシナリオを考え出し、テスト環境でそれらをシミュレートし、アプリケーションの動作を観察するスキルです。論理的で分析的な思考が求められ、欠陥のないアプリケーションを作成するために必要な最も重要なスキルです。
これらの探索セッションを構造化するためのさまざまな方法論やアプローチがあり、それらについては本書の第2章で説明します。
自動機能テスト
これは先に説明したシフトレフトテストの中核的なスキルの1つです。自動テストを行うことで、特にアプリケーションが成長して機能が増えた場合に、手動テストの労力を大幅に削減できます。簡単にいえば、このスキルは人の介入なしに機能要件を自動的にテストするコードを書くことです。
これを行うにはツールが必要であり、したがってアプリケーションの異なる層でテストを書くために使用するさまざまなツールの知識が必要です。しかし、それだけではなく、自動テストのアンチパターンを見分け、それらを避ける方法も知る必要があります。このスキルのさまざまな側面については本書の第3章で説明します。
継続的テスト
継続的デリバリーは、一度の大規模なリリースではなく、短いサイクルで機能を段階的にエンドユーザーに提供するプラクティスです。継続的に提供することで、ビジネスは早期に利益を得ることができ、エンドユーザーのフィードバックに基づいて製品戦略をすばやく評価し、調整することができます。継続的デリバリーを実現するには、アプリケーションを常にリリース可能な状態に保つために、継続的にテストを行う必要があります。
当たり前かもしれませんが、賢い方法は品質チェックを自動化してCI/CDパイプラインに統合し、頻繁に実行してテストプロセスを容易にすることです。継続的テストのスキルには、チームが迅速なフィードバックを得られるように、デリバリーサイクルの各段階でどのタイプの自動化テストを実行すべきかを判断し、それらをCI/CDパイプラインに効果的に統合することが含まれます。これらの基本は本書の第4章で詳しく説明します。
データテスト
「データはお金である」「データは新しい石油である」という言葉を聞いたことがあるかもしれません。これらの考え方は、今日のデータ整合性テストの重要性を強調しています。ユーザーのデータが失われたり、アプリケーションが誤ったデータをエンドユーザーに表示したりすると、ユーザーはアプリケーションへの信頼を失います。
データテストのスキルには、Webおよびモバイルアプリケーションで一般的に使用されるさまざまなタイプのデータストレージおよび処理システム（データベース、キャッシュ、イベントストリームなど）に関する知識と、適切なテストケースを書き出す能力が必要です。本書の第5章では、これらのトピックと、アプリケーションコンポーネント間のデータフローから機能フローとは別の新しいテストケースを生み出す方法について説明します。
ビジュアルテスト
アプリケーションの見た目と使い心地は、ビジネスのブランド価値に大きく貢献し、特に何百万人もの人々が使用する大規模なB2C（ビジネス対消費者）製品の場合、視覚的品質の低さは即座にブランド価値に影響を与える可能性があります。したがって、アプリケーションのビジュアルテストを実施することで、エンドユーザーが調和の取れた快適な視覚的体験を得られることを検証することが不可欠です。
ビジュアルテストには、Webアプリケーションの場合、UIコンポーネントが互いにどのように、またブラウザとどのように相互作用するかを理解する必要があります。このようなチェックも、自動機能テストとは異なるツールを使用して自動化できます。ビジュアルテストスキルと、自動機能テストとの顕著な違いについては、本書の第6章で説明します。
セキュリティテスト
今日の世界では、セキュリティ侵害が非常に一般的になっており、FacebookやTwitter（現X）のような巨大企業でさえもこのような攻撃を免れていません。セキュリティの問題は、機密情報の損失や露出、法的罰則、ブランドの評判という点で、エンドユーザーとビジネスの両方に大きなコストをもたらします。
これまで、セキュリティテストは業界ではニッチなスキルとみなされ、資格を持つペネトレーションテスターは通常、開発サイクルの終わりにのみ関与してセキュリティの問題を探すことが一般的でした。しかし、専門的なセキュリティテスト人材の不足とセキュリティ侵害の増加により、ソフトウェアチームは日々の業務の一部として基本的なセキュリティテストを組み込むことが賢明です。本書の第7章では、ハッカーのように考えてアプリケーション機能のセキュリティ問題を探す方法と、セキュリティスキャンを自動化するツールについて説明します。
パフォーマンステスト
アプリケーションのパフォーマンスがわずかに低下しただけでも、ビジネスに大きな財務的および評判の損失をもたらす可能性があります（先に説明したFlipkartの例を思い出してください）。パフォーマンステストのスキルには、アプリケーションの異なる層で一連の主要なパフォーマンス指標を測定することが含まれます。パフォーマンステストもまた、自動化してCIパイプラインと統合し、継続的なフィードバックを得ることができます。本書の第8章では、関連するツールと共にパフォーマンステストをシフトレフトする戦略について説明します。
アクセシビリティテスト
Webおよびモバイルアプリケーションは日常生活に欠かせない必需品となっています。永続的または一時的な障害を持つ人々にそれらをアクセス可能にすることは、多くの国で法的規制によって義務付けられているだけでなく、倫理的にも正しいことです。
アクセシビリティテストのスキルを習得するには、まず法律で要求されるアクセシビリティ基準を理解する必要があります。その後、手動および自動化されたアクセシビリティ監査ツールを使用して、それらの基準が満たされているかどうかを検証できます。このスキルと、アクセシビリティ機能を組み込むことがビジネスにとって有利な選択肢となる可能性がある理由については、本書の第9章で説明します。
機能横断要件テスト
エンドユーザーとビジネスには、機能的に欠陥がないだけでなく、可用性、スケーラビリティ、保守性、観測可能性などの多くの品質要件があることを見てきました。これらは、アプリケーションのクロスファンクショナル要件（CFR）と呼ばれます。機能要件は一般的に最も注目されますが、アプリケーションに品質を与えるのはCFRであり、これらをテストしないと、ビジネスやソフトウェアチーム、エンドユーザー、またはその全員が不満を感じることになります。したがって、CFRテストのスキルは基本的なテストスキルです。本書の第10章では、さまざまなCFRを検証するためのテスト方法論とツールについて説明します。
注意：CFRは業界の多くの人々によって非機能要件（NFR）とも呼ばれています。これら2つの用語の微妙な違いについては第10章で説明します。
モバイルテスト
驚くべきことに、2021年の主要なアプリストア（Google PlayとApple App Store）で利用可能なアプリの数の合計は570万です。モバイルアプリの数の爆発的な増加は、主にモバイルデバイスの利用増に起因します。
実際、Web分析会社のGlobal Statsは2016年に、世界中のモバイルおよびタブレットのインターネット使用がデスクトップの使用を上回ったというデータを発表しました。したがって、モバイルアプリケーションをテストし、Webサイトのモバイルデバイス間の互換性をテストする能力は、今日の重要なスキルです。
前述のすべてのスキルがモバイルアプリケーションのテストに必要ですが、考え方の変更も必要です。さらに、モバイルアプリケーションでさまざまな品質チェックを実行するために、モバイル固有の一連のテストツールを学ぶ必要があります。したがって、モバイルテストはここで別個のスキルとして設定されています。モバイル環境の微妙な違いについては本書の第11章で説明します。
これら10個のフルスタックテスティングスキルを合わせることで、Webおよびモバイルアプリケーションの全体的な品質の側面を完全にテストすることができます。先に述べたように、チーム内のそれぞれの役割がこれらの各スキルについてある程度の能力を身につけることが重要です。本書では、実践的な例を用いて、スキルごとにその方法を示していきます。
