Rubrikは、世界中のデータの安全を確保することを使命としており、製品品質を第一に考えています。このブログでは、お客様に最高品質の製品を確実にお届けするためにRubrikが採用している、自動テスト戦略についてご紹介していきます。

当社のテスト戦略とプロセスについて掘り下げる前に、製品品質が持つ意味と、それが当社やお客様にとって重要である理由について、簡単に見ていきましょう。

製品品質の重要性

製品品質とは何か

製品品質とは、ある製品がどれくらい、お客様のニーズを満足させ、その目的に適合し、業界基準を満たしているのかの度合いを指します。製品の品質評価においては誰もが独自の視点を持ちますが、結局のところ、その製品がコストに比してお客様に与える価値、ということになります。価値を決定し得るのは、製品の安定性、信頼性、耐久性、性能、備えている機能一式の安全性です。

製品品質が重要である理由

製品の品質は、組織を築くものでも破壊するものでもあり、当社では質の高い製品が顧客市場におけるRubrikの高評価獲得に寄与するのだということを理解しています。当社の製品は、お客様のビジネスを促進する極めて貴重な顧客データの管理と安全性確保に対し、責任を負っています。 

データセキュリティ業界では、当社のソリューションは、お客様の環境において当社が保護するシステムのトラブルが起きたまさにその瞬間に稼働状態にある必要があります。これらの問題が複雑であることからすれば、極めて安全かつシンプルなユーザー体験の提供は困難だと言えるかもしれません。Rubrikは、必要な時に必要なデータを、シンプル、安全、迅速な方法で復元できるようにする、優れた品質の製品の製造に全力で取り組んでいます。

製品品質の確保戦略

当社は、優れた製品の製造よりも品質の方が重要だと考えています。品質は、エンジニアリングプロセスの全段階に含まれていなくてはなりません。では、当社のエンジニアリングプロセスの中身を見ていきましょう。
 


エンジニアリングプロセスを進める中で、当社が製品品質を評価する際には、自分たちが適切な製品を製造し、適切な行動を取っていることを確認するため、いくつかの質問を自らに問いかけます。

  • この製品はお客様の問題を解決するか?

  • シンプルで使いやすいか?

  • 安全か?

  • 堅牢で信頼性があるか?

  • 充分な内容か?

当社として、反復作業を迅速化し、お客様のニーズに応える高品質製品を提供するには、できる限りの頻度と速度で製品品質を測定する能力を備えなくてはなりません。ここがまさに自動化が大いに役立つ場面であり、当社ではソフトウェア開発のライフサイクル全体で頻繁な繰り返しが必要となる手順を自動化しています。

なぜ自動化なのか

テストの手動での繰り返しは、高価で時間もかかります。自動テストは、テスト一式の実行を効率的かつ効果的に繰り返すことで、時間とコストの節約となります。

製品コンポーネントおよび機能一式の自動テストは、当社が日々実行する業務として最も重要なものの1つです。これによって、開発者コミュニティへのフィードバック提供を迅速化できるからです。効率的な方法でのテストの実現に向け、当社では下記のテストピラミッド図に記載の戦略を導入しました。
 


以下が、Rubrikが信頼を置いている各種テスト一覧です。

  • ユニットテスト

  • コンポーネントテスト

  • 統合テスト

  • E2Eテスト

    • 機能テスト

    • 非機能テスト

      • 性能、ストレス、規模、長寿命性、安全性、アップグレード、プラットフォームなど

ユニットテスト

上記のテストピラミッド図のとおり、Rubrikではユニットテスト(UT)がテストの基盤を形成しており、迅速かつ安価なことからこれに大きく頼っています。これが開発者ワークフローでの防護の第一レベルです。ユニットテストでは、テスト対象コード(CUT)はソースコードの個別ユニットです。1つのユニットは、コードの小さな固まり、通常はクラスやライブラリとして定義されます。このテストは外部リソースに一切頼らない隔離環境で実行され、ここで、ハッピーパス、エラー処理、フォールトインジェクションなどの異なるパスのテストを行っています。また、各コンポーネントについてのUTによるコードカバレッジを測定し、その所在を把握しています。これによってチームが、欠落しているUTを追加すべき間隙や領域を見つけ、より優れた製品品質に近づけるようになるのです。あわせて当社では、早期のフィードバック提示のため、開発者が作成したすべての差分のコードカバレッジ統計を提供しています。

コンポーネントテスト

コンポーネントテストでは、コンポーネントとCUT(Cは、ここではコンポーネント)の検証を行います。当社ではコンポーネントについて、本番環境の単一プロセス内に展開されるソフトウェアの集まりと定義しています。コンポーネントは通常、バイナリとして組み立てられ、ThriftサーバーやgRPCサーバーなどのサービスとして展開されます。一般的に1つのコンポーネントは、別々にユニットテストを受ける複数のユニットで構成され、各ユニットテスト後にコンポーネントテストが書かれます。

統合テスト

これは、製品内のあらゆる異常を特定するための次のテスト階層です。ユニットテストとコンポーネントテストでは、単一のコンポーネントやサービスの品質と整合性がテストされます。当社の複雑なシステムでは、相互にやり取りを行う複数のコンポーネントやサービスが実行されています。コンポーネントやサービスがテスト環境下でどのように機能またはやり取りするのかを把握するため、当社では統合テストを用いています。したがって、統合テスト用のCUTは、統合がテストされるコンポーネント一式です。コンポーネントテストとは対照的に、CUTは本番環境における異なるプロセスに展開されたコードで構成されます。

エンドツーエンドテスト

テストでの次の段階はエンドツーエンド(E2E)テストです。全サービスに展開されたシステムのユーザーワークフローをエンドツーエンドにテストすることによって、製品機能全体をテストするために使用されるものです。E2EテストのCUTはシステム全体です。

このテストには多数の外部依存性が含まれるため、不安定になる可能性があります。このテストで見つかる不具合は、以下の理由により、デバッグと再実行が高額で、時間とリソースがかかるものとなります。

  • 現に機能している依存関係の組み合わせの数が非常に多く(全サービスが展開済み)、問題がスタックの奥深くで発生する場合があり得る。

  • E2Eテストは、ユニット、コンポーネント、統合の各テストよりも少ない間隔で実行されるため、2度の実行の間に大量のコミットが発生する。

E2Eテストの一環として当社では、アップグレード、性能、安全性、ストレス、規模、長寿命性などのテストにより幅広い対象をカバーしています。また、UIテストを自動化する一方で、お客様が実際に視認した際に想定通り表示されるよう、UIの手動検証も行っています。

下記は、製品のあるべきテスト方法に関する実世界でのたとえです。
 


この場合、適切なやり方は、各ユニットとコンポーネントをテストしてドアを完全に作り終えてから、家に設置することです。同様に、当社が上記で説明した製品テストを実施する際にも戦略に従って進められます。

まとめ 

自動化なしでは繰り返しの作業は非常に困難であり、それによって、長期間にわたる製品品質の測定と維持が難しくなります。優れたテスト戦略を備えることが、体系立った方法によって、製品を求められる品質基準とお客様の期待に沿ったものとするためのカギです。 

当社ではこれまで、卓越した品質の製品を迅速に提供するにあたり、それなりの負担と独自の課題を経験してきました。当社では、製品をシステムレベルで検証しやすくするための各種ハードウェアやソフトウェアを揃えているため、インフラストラクチャが安定し、信頼でき、安全で、強靱であることを確認する必要があったのです。当社の課題については今後のブログでさらに詳しくご紹介していきます。

Rubrikにおける製品品質のブログシリーズとして、次回は次の内容をご紹介します。

  1. 自動テスト:E2Eテストで品質を確保

  2. 自動テスト:統合と提供の迅速化