Ouest-France
Ouest-France は 1944 年に創刊されたフランスの新聞で、全国で発行されています。地方から全国ニュースまで幅広く取り上げ、624,000 部以上を販売する日刊紙として最大部数を誇ります。フランスの主要紙で、フランスの 12 部門に 53 もの地方紙のほか、2 つのデジタル版を発行しています。従業員数は約 1,400 人で、約 550 人がジャーナリスト、残りは技術、アカウンタビリティ、ソフトウェアエンジニアリングサービスに従事しています。また、2,500 人を超える特派員と 16,000 人以上の流通パートナーと提携しています。
しかし、世界中のほとんどの新聞社と同様に、インターネットの台頭により Ouest-France の需要は大幅に減少しました。これを受けて、同社は Web サイトを立ち上げ、コンテンツをオンラインで提供しました。Ouest-France の Web サイトは、54 億の一意の訪問者と月間 6,000 万を超える訪問数を誇り、現在はフランスで 9 番目にアクセスされる情報 Web サイトとなっています。
ビジネス上のニーズと課題
顧客が Ouest-France のデジタルプラットフォームを利用するようになると、同社は 2017 年に Web サイトを全面的に刷新する必要があると考えました。この決定は、機能的な観点というよりも、主に技術的な必要性によるものでした。旧 Web サイトではいくつかの高レベルテストが手動で実行され、ソフトウェアチームはわずかな継続的インテグレーション (CI) を実践していました。しかし、機能ドキュメントと共有ナレッジがなかったため、Web サイトの品質が低下しました。この結果、頻繁に多数のホットフィックスを適用する必要があり、同社にはコストがかかり、リスクが高くなりました。
したがって、Ouest-France のビジネスニーズに対応する形でソフトウェア品質に取り組む必要がありました。同社は、包括的な製品ドキュメントの共有と実行可能な要件とテストの自動化を通してのみ品質が達成できると判断しました。さらに、求められている自信と製品品質は、行動駆動開発 (BDD) の原則を活用する可能性のあるソリューションを指し示していました。さらなる分析により、BDD アプローチが Ouest-France の望む組織的目標に完全に利点を与えることが明らかになりました。
ただし課題もありました。BDD を採用することは、既存のソフトウェア開発プロセスを完全にオーバーホールすることを意味するためです。ほとんどの製品オーナーは、BDD の哲学に慣れていませんでした。したがって、BDD アプローチが組織全体の構造で浸透するように保証することが、克服すべき主要なハードルでした。このアプローチの採用を強化し、製品オーナーが「アジャイルに」考え始めることを積極的に保証するため、Ouest-France は想像していた品質の Web サイトを作成するための接着剤として機能するソフトウェアツールを使用することにしました、このツールは SmartBear Software の CucumberStudio でした。
ターゲットソリューション
当時、Ouest-France はレガシ製品の完全なドキュメントを保有していなかったため、当初は問題となりました。CucumberStudio は、新しい Web サイトのすべての機能の包括的なリストを作成するのに役立ちました。このリストは、オンデマンドでアクセスし分析できるようになりました。これにより、同社は実行可能な要件のセットを毎日更新、作成、充実させることができました。シンプルなテストシナリオの形式のこれらの要件は CucumberStudio にドキュメントとして保存され、誰でもすべての機能をすばやく理解することができました。
この合理化された BDD アプローチは、製品オーナー、開発者、およびテスター間の議論も促進し、これにより、新しい実行可能要件の設計にかかる時間が数時間から数分に短縮されました。この要件を設定するためのこの迅速なターンアラウンド時間は、Ouest-France がテストシナリオを作成するときに標準化された再利用可能なアクションワードを開発して活用したため、可能になりました。
「私たちが直面した大きなハードルは、実行可能な要件の粒度の細かさでした」と、Ouest-France の品質保証マネージャーである Florent Vaution 氏は述べています。これに対処するために、BDD アプローチを機能レベルと技術レベルに分けることにしました。前者は主にユーザーインターフェイス (UI) テストで構成されており、自動化および保守が難しく、コストがかかると Ouest-France は考えていました。後者は、ほとんどの機能を埋め込む API で直接実行されるテストで構成されていました。これらの API テストは、作成および実行がより高速で、チームの現在のスキルセットを考えるとメンテナンスがはるかに簡単でした。
当初のもう 1 つの課題は、アクションワード (つまりテストステップ) を実装する必要のある開発者との関係でした。スクラッチから始めたため、アクションワードの辞書を作成することは初期段階ではいくらかコストがかかりました。リファクタリングが非常に多く含まれていたためです。しかし、アクションワードのリポジトリを構築し、それをより堅牢にすることで、新しい自動テストを作成するための現在のコストはほとんどかかりません。
当初、Ouest-France の品質保証チームは、実行可能な要件を作成し、アクションワードを作成するルールを設定していたのはわずか 2 人でした。その後、BDD の経験がなかったテスターをさらに 3 人追加しました。それにもかかわらず、チームの全員が BDD の哲学を簡単に理解し、独自に新しい機能を追加することを任されました。
当初、Ouest-France の品質保証チームのメンバーは CucumberStudio の唯一のユーザーでした。徐々に、製品オーナーと開発者に、品質保証チームが CucumberStudio をどのように使用しているかを示すデモを行い、新しい機能を作成するためのツールを自分で使用するようにトレーニングしました。品質保証チームのメンバーは、機能と要件のドキュメントの唯一の責任者でした。しかし、製品オーナーと開発者は、品質保証チームによって記述された機能に異議を唱えたり、修正したり、変更したりすることに抵抗がなくなってきました。
CucumberStudio を使用することのもう 1 つの利点は、QA チームが、特定のテストシナリオがテスト済みかどうか、どのようにテストされたか、および重複を避けるためにテストのシミュレーションにアクションワードが既に存在するかどうかを確認できたことです。これは特に、400 を超えるテストシナリオと 500 を超えるアクションワードを扱っていた Ouest-France にとって、貴重な時間を節約できました。
主な成果と教訓
Web サイトの再設計プロジェクトで CucumberStudio を使用して BDD を実装して以降、Ouest-France は 2017 年の前半に「アイデア」から「本番」の段階に移行しました。以前の Web サイトとプロセスは、テストの自動化がない手動テストのみで構成されていました。新しい Web サイトとプロセスは、数百に及ぶ自動テストと、わずか数の手動テストで構成されています。
BDD を実装する前は、1 日に約 1 つのホットフィックスを実行していましたが、今では新しい Web サイトの本番環境にただちに変更を移行できます。
- シナリオ設計中のオートコンプリート
- シナリオでの変数の簡単な使用
- テストの実行作成の速度
- 最新のドキュメント
- SCM と Jenkins へのリンクがある CucumberStudio Publisher