ソフトウェアテストには本当に価値があるのでしょうか?

はいといいえ。まあ、すべてのことと同様、それは状況によります。この投稿では、開発者として、次にスタートアップの創設者としてのテストに関する私の経験を説明しようと思います。

私について

やあ！私は Simone です。フルスタック開発者であり、CTO であり、Web 代理店、電子商取引、アダルト、エンタープライズ ソフトウェアなど、さまざまな業界で 15 年のコーディング経験があります。このブログ投稿では、ソフトウェア テストに関する洞察と、さまざまなビジネス ニーズや段階に適した方法を決定する方法を共有したいと思います。

私は Bugpilot の CTO 兼共同創設者です。Bugpilot は、SaaS チームが開発、テスト、QA プロセスをすり抜けたバグを発見するのに役立つバグ監視ツールです。

序章

さまざまな種類のテスト

ソフトウェア開発の世界では、多くのテスト手法がソフトウェア製品の信頼性と品質を確保するために不可欠であると長い間考えられてきました。ただし、これらの方法論には利点がある一方、欠点がないわけではないことを認識することが重要です。

このブログ投稿の目的は、会話を引き起こし、TDD と QA がソフトウェア チームに与える可能性のある潜在的な害に光を当てることです。すべてに当てはまる万能のアプローチはなく、さまざまなビジネスや段階に応じて適切な方法が必要であることを認識することで、ソフトウェア開発の複雑さをより効果的に対処できるようになります。

私は、ソフトウェア テストに関するさまざまな方法論、一般的な慣行、推奨事項を認識しています。この投稿では、主にテスト駆動開発と品質保証に焦点を当てました。

用語に詳しくない場合のために、概要を以下に示します。

TDD

テスト駆動開発 (TDD) は、コードを記述する前に自動テストを作成するソフトウェア開発方法です。これにより、開発サイクルの早い段階で問題を発見し、コードが徹底的にテストされ、ビジネス要件を満たしていることを確認できます。開発者はまずテストで新機能の期待される動作を定義し、次にテストに合格するコードを記述し、最後にリファクタリングを通じてコードを最適化します。

QA

品質保証 (QA) は、ソフトウェアがリリース前に品質基準を満たしていることを保証します。通常、QA エンジニアが実行する手動プロセスでは、機能要件の検証やパフォーマンスのチェックなど、手動および自動テストを通じて欠陥を特定して修正します。これにより、ビジネスとエンドユーザーのニーズを満たす信頼性の高い安定したソフトウェアが保証されます。

いくつか質問があります!

この投稿の目標は、会話を引き起こすことです。多くの場合、検査が必要であると私は強く信じています。医療機器、航空機ソフトウェア、制御システム、銀行業務など、何十億人もの人々が使用しているソフトウェアで、ボタン 1 つの色が収益に大きな違いをもたらすことを考えてください。

ソフトウェア開発には構造と柔軟性のバランスが必要であり、コンテキストを考慮せずにテスト原則に盲目的に従うと、次善の結果が生じる可能性があります。コード ライブラリはおそらく 99% のカバレッジから恩恵を受けます。しかし、あなたのソフトウェアも 99% のカバレッジを必要としますか?

いくつかの質問を用意しました。 「はい」か「いいえ」で答えてみてください。それはなぜですか?

• 本当にUI コンポーネントをテストする必要がありますか?
• 「プロフィール写真の更新」機能について E2E テストが必要ですか?
• Figma のデザインと実際の UI の間に小さな不一致がある場合、QA に失敗してリリースが遅れますか?境界線は何ですか？
• テストを書くことを拒否したジョンを解雇すべきでしょうか?

第 1 章 テスト駆動開発に対する私の主張

定説への挑戦

テスト駆動開発 (TDD) は、ほとんど宗教的な支持を得ています。それが精神的健康に役立つと主張する人もいますが、それが成功への唯一の道であるという独断的な信念を伴うことがよくあります。この章の目的は、TDD の欠点を調査し、柔軟性の罠、時間の制約、誤った安全感に光を当てることです。

CTO として、私は最も些細な機能であっても TDD を断固として主張する同僚に出会ってきました。 「TDD をやらないとバカだ！」というのが一般的な定説のようでした。 TDD が唯一許容されるアプローチであるという揺るぎない信念により、私はしばしば自分自身の判断力と能力に疑問を抱きました。配列をフィルタリングするための単純な 2 行関数のテストを書くことを拒否したことで笑われた時の出来事をはっきりと覚えています。

この個人的な経験は、TDD の重要な落とし穴の 1 つである剛性の罠を浮き彫りにしました。最初にテストを書くという独断的なこだわりは、厳格なプロセスにつながる場合があり、その結果、企業の市場投入までの時間や競合他社の優位性に影響を与える可能性があります。

本当に時間をかける価値があるのでしょうか？

TDD によってもたらされる重大な課題は、TDD が開発プロセスに課す時間の制約です。

コードのすべての部分に対して包括的なテストを作成するのは、特にシステム全体への影響が最小限の簡単な関数の場合、時間がかかる場合があります。迅速なイテレーションとタイムリーな配信が重要であるペースの速い環境では、TDD の追加オーバーヘッドによって開発サイクルが遅くなり、俊敏性が妨げられる可能性があります。

常に「99% をカバーする必要がある」というアプローチを採用するのは不合理だと思います。徹底性と効率性のバランスが不可欠であり、より合理化されたテストアプローチの方が適切であり、より迅速な反復と市場の需要への迅速な対応が可能になるシナリオもあります。

さらに、外部依存関係や複雑なシステムとの相互作用を伴うテスト作成の複雑さと不完全さにより、TDD の時間制約がさらに複雑になる可能性があります。

開発者として、私はテストを書くのが楽しいとさえ言えるかもしれませんが、チームが最終的に削除されるコードのテストを書くことに時間の 80% を費やしたことに満足している CEO を見つけてください。

開発者は多くの場合、テスト中にこれらの依存関係の動作をシミュレートするためにモック オブジェクトまたはスタブを作成する必要があります。モックはコードを分離し、依存関係を軽減するための貴重なツールとなり得ますが、追加のオーバーヘッドと複雑さを引き起こす可能性もあります。

外部システムやサードパーティ コンポーネントの動作を正確に複製することが困難な場合があるため、モックに依存すると現実世界のインタラクションが不完全に表現される可能性があります。これにより、テストプロセスに一定レベルの不確実性が導入され、偽陽性または偽陰性が発生する可能性があります。

テストは合格しています。ぐっすり眠れますね。右？

テストは合格しています。安心してぐっすり眠れます！

テストのみに依存することには、本質的ではありますが、見落とされがちな危険性、つまり誤った安全感が存在します。テストは間違いなく欠陥を特定して防止するために不可欠ですが、確実なソリューションではありません。

「すべてのデバイスでテストしましたか?」

考えられるすべてのケースをテストすることも困難です。特に Web 開発の分野では、ユーザー エクスペリエンスに影響を与える可能性のある要因が多数あります。そのような要因の 1 つは、さまざまな画面サイズ、解像度、オペレーティング システム、ブラウザーなど、エンド ユーザー デバイスの多様性です。それぞれの組み合わせは、ソフトウェアがどのように機能し、ユーザーにどのように見えるかに影響を与える可能性がある、一連の固有の課題を提示します。

Chrome、Safari、Firefox、Edge、Internet Explorer などのさまざまなバージョンのブラウザを使用し、iOS、Android、Windows、または macOS で実行されるスマートフォン、タブレット、ラップトップ、デスクトップなど、さまざまなデバイスと構成を考えてみましょう。各デバイス、オペレーティング システム、ブラウザの組み合わせによって Web コンテンツのレンダリング方法が異なる場合があり、ユーザーの操作も同様に異なる場合があります。考えられるすべてのデバイスと構成を予測して説明することは事実上不可能であるため、テストで完全な範囲を提供することが困難になります。

「私はおばあちゃんになったつもりでこの UI をテストしましたか?」

ユーザーのペルソナとプロファイルにより、さらに複雑さが加わります。ソフトウェアは、異なる好み、行動、アクセシビリティのニーズを持つ多様なユーザーをターゲットにしている可能性があります。テストは、一般的なシナリオで発生する問題を明らかにするのに役立ちますが、標準から逸脱した特殊なケースや特定のユーザー インタラクションを見逃してしまう可能性があります。たとえば、支援技術を利用している視覚障害のあるユーザーは、自動テストだけでは把握するのが難しいユーザビリティの課題に直面する可能性があります。

技術的なバリエーションに加えて、ユーザー コンテキストと現実世界のシナリオも、ユーザー エクスペリエンスを形成する際に重要な役割を果たします。ネットワークの状態、帯域幅の制限、同時使用数などの要因が、ソフトウェアのパフォーマンスと信頼性に影響を与える可能性があります。

テストでは制御された環境を提供できますが、ユーザーが日常生活で遭遇するさまざまなネットワーク条件や使用パターンを正確にシミュレートできない場合があります。ソフトウェアが正常に動作することをテストで確認できない場合、結局のところテストする価値はあるのでしょうか?

第 2 章 QA とスピードの必要性

私は、特に競合他社に負けないために迅速に行動しなければならない中小企業の場合、「厳格な」品質保証慣行によってもたらされる課題を直接目の当たりにしてきました。

これは特に初期段階のスタートアップに当てはまると思います。顧客が使用していない場合、その機能全体をすぐに廃棄する可能性が高くなります。では、単体テストを 1 週間かけてテストし、改良してきた価値はあったのでしょうか?

私の個人的な経験を共有し、特に小さなビジュアル面やプレゼンテーション面が QA の取り組みの焦点になった場合に、完璧主義に陥る危険性について光を当てたいと思います。

スタートアップ企業での前職では、機能を迅速に提供することと、完璧な品質を確保することとの間で絶え間ない戦いに直面していました。 CSS マージンの位置ずれ、フォントの選択の間違い、改行の欠落などの微細な問題が原因で、リリース サイクルが不必要に遅れた場合がありました。細部に注意を払うことは重要ですが、これらの表面上の欠陥にこだわることが、市場で優位に立つ能力に影響を与えるのではないかと疑問を持ち始めました。

過剰な QA のリスクの 1 つは、実用性よりも完璧性を優先することです。完璧さを追求する中で、視覚的な小さな不具合を修正するために多大な時間とリソースを投資していることに気づくことがよくありました。 これは生産性の敵ではないでしょうか?

高い基準を維持することは不可欠ですが、これらの細部に多大な労力を費やすことは逆効果であり、顧客にとって本当に重要なコア機能やユーザー エクスペリエンスの向上から焦点をそらしてしまう可能性があることに気づき始めました。

過度に慎重な QA アプローチがもたらす結果を観察すると、その危険性が明らかになりました。私たちのチームはリスクを回避する行動をとり始め、ゆっくりとした細心のリリースプロセスを選択しました。ほぼ完璧に近い製品を提供することが目的でしたが、不注意でイノベーションを抑制し、顧客の要求に迅速に対応する能力を妨げてしまいました。小規模 (従業員 30 人) の会社として、当社は俊敏性に頼って迅速に反復し、大規模な競合他社を打ち負かしていました。しかし、過剰な QA 実践により、「バグ」に対する恐怖が広まり、それが私たちの足を引っ張っていました。

バグの存在を受け入れるべきではないでしょうか?仕事をする人は誰でも間違いを犯します。仕事をしなければ、決して間違いを犯すことはありません。 (ごめんなさい - サッカーの引用)

第4章 顧客は最良のテスターかもしれない

リリースサイクルの長期化による経済的影響が明らかになりました。市場機会の逃し、収益創出の遅れ、潜在的な顧客離れが損害を与え始めました。リソースが限られている小さな会社として、ぶらぶらしている余裕はありませんでした。機敏性とスピードを活用して機会を捉え、競争力を維持する必要がありました。

細かい部分を完璧にするのに費やす時間と、迅速な反復と市場の反応性の必要性とのバランスを取る必要がありました。すべてが機能することが「より確実になる」まで、すべてのリリースを延期、延期、延期します。火曜日の発送が優先オプションになりました。すべてをテストするのにもう 1 日かかるのに、なぜ月曜日に出荷する必要があるでしょうか?

テストは欠陥の特定と防止に役立ちますが、ユーザーからのフィードバックを貴重な情報源として受け入れることも同様に重要です。ユーザーの経験、好み、提案は、テストだけでは明らかにできない洞察を提供することができます。ユーザーとのフィードバック ループを促進し、ユーザーのニーズに積極的に耳を傾け、ユーザーの意見を開発プロセスに組み込むことで、ユーザーの期待に応えるユーザー中心の製品を作成できます。

広範な内部テストのみに依存するのではなく、テスト プロセスにユーザーを参加させることは非常に有益です。ベータ テストやユーザビリティ調査などの初期のユーザー テストでは、現実世界のシナリオとユーザー インタラクションを観察できます。

このユーザー中心のアプローチは、内部テストだけでは発見できない問題点、ユーザビリティの問題、予期せぬ問題を特定するのに役立ちます。このフィードバックを早い段階で取り入れることで、ユーザー エクスペリエンスと満足度を大幅に向上させることができます。

残念ながら、私は多くのソフトウェア チームに強い「不均衡」があるのを個人的に目撃しました。ここで質問があります: UI の不一致のために QA は失敗するべきですか? QA はどのくらいの頻度で失敗する必要がありますか?

第5章 「バグに遭遇したらユーザーは離れてしまう！」

研究では、壊れた機能がユーザー維持に悪影響を与えることが一貫して強調されています。エクスペリエンスを混乱させるバグ、クラッシュ、エラーが頻繁に発生すると、ユーザーは製品の使用を継続する可能性が低くなることが多くの調査で示されていると聞いています。

Qualitest の調査によると、ユーザーの 88% は、パフォーマンスの低下が 1 ～ 2 回発生しただけでアプリを放棄するそうです。これらの調査結果は、機能の安定性がユーザーを維持し、長期的なエンゲージメントを構築する上で重要な役割を果たすことを強調しています。

ユーザーが壊れた機能に遭遇すると、製品とその背後にある開発チームに対する信頼が損なわれます。たとえ問題が最終的に解決されたとしても、ユーザーは否定的な認識を持ち、戻りたがらない可能性があります。機能的なエラーや不具合が繰り返し発生すると、ユーザーは Web サイトやアプリに対する信頼を失う可能性があります。

しかし…これは 2023 年でも真実でしょうか?

バグはどこにでも存在し、バグのないソフトウェアは存在しない可能性があることは誰もが知っています。

ユーザーは時々バグに遭遇する可能性があるため、軽微なバグと重大な機能の問題を区別することが重要です。最近のユーザーは、全体的なエクスペリエンスに大きな影響を与えない軽微なバグに対して寛容になっているかもしれません。私たちの見解では、ユーザーはソフトウェア開発においてバグを避けられないものとして受け入れることを学びました。バグは私たちの日常生活の一部です。

ただし、コア機能が壊れてソフトウェアを意図したとおりに使用できない場合、ユーザーは寛容ではなくなり、代替手段を求める可能性があります。

B2B のバグはさらに厄介です (そうでないのか?)

B2B シナリオでは、壊れた機能はユーザーとそのビジネスに深刻な影響を与える可能性があります。その結果、プロジェクトのスケジュールが遅れ、期限に間に合わなくなり、さらには4 億 4,000 万ドルの経済的損失が発生する可能性があります。

コンシューマ ソフトウェアに関しては、ビジネス ユーザーは、作業の遂行を妨げるバグに遭遇するとイライラして怒る可能性があります。ソフトウェア製品に対する彼らの忠誠心は、その信頼性と、職業上の責任を達成するのに役立つ能力と密接に結びついています。信頼性が低いということは、解約率が高いことと同じであるはずです。

しかし、必ずしもそうとは限らないことが分かりました。組織全体がテクノロジーを採用したら、会社全体を競合他社のソリューションに切り替えるのはそれほど簡単でしょうか?ありそうもない。

電子商取引にはロイヤルティに関する（さらに多くの）課題があります。

電子商取引では、ユーザーはすぐに利用できる多数の代替手段を利用できます。ユーザーとして、やるべき仕事は非常に明確です。掃除機を買う必要があります。 Amazon アプリがクラッシュした場合、ドロワー内の次のアプリを試すまでどれくらいかかりますか?

機能が壊れたりバグが発生すると、ショッピング カートがすぐに放棄され、顧客満足度が永久に低下し、ビジネス チャンスが失われる可能性があります。

第 6 章 TDD と QA が唯一の解決策ですか?

明らかに、そうではありません。テストは一部の欠陥を特定して防止する上で重要な役割を果たしますが、バグによるユーザーへの影響を最小限に抑えるために講じられる追加の対策もあります。私が研究したいくつかのアプローチを次に示します。

監視とエラー追跡

堅牢な監視およびエラー追跡システムを実装すると、問題を事前に特定して解決できます。リアルタイムの監視は、異常、パフォーマンスの問題、エラーの検出に役立ち、複数のユーザーに影響を与える前に迅速に修復できます。エラー追跡により、エラーの詳細を取得できるようになり、ユーザーへの影響に基づいてバグ修正の優先順位を付けるのに役立ちます。

Sentry 、 Rollbar 、 Bugsnag 、 Bugpilotなどのツールを使用すると、チームはコーディング エラーや問題のある UX セッションを自動的に検出できるため、チームは問題に積極的に対処できます。

ユーザーのフィードバックとサポート

ユーザーのフィードバックを積極的に奨励し、収集することで、ユーザビリティの問題、バグ、改善の余地についての貴重な洞察が得られます。ユーザーから報告された問題に迅速に対処し、サポートを提供することは、問題を解決し、良好なユーザー エクスペリエンスを維持することへの取り組みを示しています。

Canny 、 Hotjar 、 Bugpilotなどのツールを使用すると、チームはユーザーからのフィードバックを簡単に収集できます。

ドキュメントとユーザー教育

明確で包括的なドキュメントとユーザー教育資料は、ユーザーがソフトウェアを効果的に操作し、ユーザー起因のエラーのリスクを最小限に抑えるのに役立ちます。一般的な問題とトラブルシューティングの手順を説明するリソースを提供することで、ユーザーは軽微な問題を独自に解決できるようになります。

Bugpilot では、Notion ページを使用してすべてのドキュメントを保管しています。簡単かつ無料。

結論

テストは、開発プロセスの早い段階で問題を特定することにより、重要な予防策として機能します。単体テスト、統合テスト、エンドツーエンド テストなどの徹底的なテストは、ある程度まではバグを検出し、ソフトウェアの安定性と機能を保証するのに役立ちます。しかし、過剰なテストや厳格すぎるプロセスは、長期的には企業に損害を与える可能性が非常に高いです。

ただし、最善の努力にもかかわらず、エラーがテストの網をすり抜けてしまう場合があります。したがって、緩和戦略を講じることも同様に重要です。緩和ソリューションを実装することで、ソフトウェア チームはエラーを迅速に検出して対処し、ユーザーへの影響を最小限に抑え、発生した問題を迅速に解決できます。

完全にバグのないソフトウェアは存在しないことを認識し、ユーザーからのフィードバックを奨励し、効果的なカスタマー サポートを提供する環境を構築することが不可欠です。ユーザーの報告に積極的に耳を傾け、懸念事項に迅速に対処することで、ソフトウェア チームはユーザーとの良好な関係を維持し、信頼と忠誠心を育むことができます。

先生

過剰にテストしないでください。おそらく、単体テストのカバレッジを 99% にする必要はありません。早く発送してください。