チームのテスト自動化がテストピラミッドに沿えているかをどうやって計測するのか
ソフトウェア開発におけるテストの自動化はすべてのテストレベルで実現することが可能です。JSTQBのテストレベルの定義に従うと、コンポーネントテストレベルでのユニットテストランナーを利用したユニットテスト、テストダブル等を利用したコンポーネント結合テスト、OSSや市販のテスト自動化ツールが主には利用させるシステムテスト、前述のテスト自動化ツールやAPIテスト自動化ツールが活用される、システム統合テスト、受け入れテストなど、テスト自動化にもさまざまなレベル、アプローチが存在します。
また、それぞれのアプローチごとに実行速度、運用コスト、欠陥の決定性、ユーザー環境の忠実性等の優劣が存在し、テストピラミッドでは、システムテスト以上のテストレベル、いわゆるE2Eテスト（図上ではUIテスト）は忠実性とコストが高く、ユニットテストは速度が早く、欠陥の決定性が高い、とされています。E2Eとユニットテストの真ん中に位置するサービスレイヤのテストはどのパラメータも中間に位置づけられています。
ピラミッドという名が示すとおり、テストピラミッドでは下層からユニットテスト、サービスレベルのテスト、UIテストの順番で並んでおり、最下層（台形の底辺が長い）ほど、テストの分量を多くすべきである、というチームで自動テストの戦略を考える際の指針となるモデルになっています。テストピラミッドが提供された当時におけるテスト自動化は、ユニットテストとUIテストのどちらかにかたよっており、サービスレベルのテストを拡充することで、UIテストの脆弱性や決定性の不足を補うことができると原典となる記事では主張されています。個人的にも、ビジネスロジックやデータの扱いに関するテストはユニットテストとサービスレベルのテストに可能な限り寄せるほうが効率性、運用性の面で優れると考えます。
今現在、チームがテストピラミッドに沿った自動テストの運用になっているかをどうやって計測するか
新しく開発される製品や、これからテスト自動化の環境を整えるチームであれば、最初からテストピラミッドの割合を意識した計画が可能かと思いますが、既に自動テストが運用されている組織において、テストピラミッドに沿った運用に改善していくためにはどうしたら良いのでしょうか。改善に先立ちまず計測が必要になりますが、単純にテストケースの数と考えると、ひとつあたりのテストケースがカバーする範囲がテストレベルによって大きく異なるため、E2Eテストのそれと、ユニットテストの1ケースを同じ単位で比べるのは違和感があります。ただ、現実的にはもっとも計測が容易であると思われるので、まず、計測してみる最初の一手としては良いかも知れません。
Mike Cohn氏の見解
この素朴な疑問について、テストピラミッドの提唱者である、Mike Cohn氏に直接伺ってみましたところ快くご教示頂きました。また、返信の一部を日本語で共有することについても、ご快諾を頂きました。ありがとうございます。回答はこちらです。
"The idea is that the pyramid shows where to emphasize testing. so to measure it, I'd look at how much time team members spend testing at each level."
まず「テストピラミッドはテストの焦点をどこに置くかを示すものである」との前提のうえで「もし計測するなら、チームメンバーが各レベルにどれぐらいの時間を費やしているかを見るだろう」とのことでした。
テストにどれぐらいの時間を費やしているか？は深いテーマで、ここから先は私見です。
たとえばテスト自動化以前のテスト分析やテスト設計は公式度の差はあれど、どのテストレベルでも実施されます。それでも、責務の範囲が狭い分、低いテストレベルのほうが費やす時間は少なくて済むでしょう。自動テストの実装や運用に関しても、E2Eよりはサービスレベルが、サービスレベルよりはユニットテストのほうが軽量で済むように感じられます。
テストピラミッドを解説した記事でも、ユニットテストからUIテストに向けてコストが上がっていくことを示す補助線が引かれていることもあり、コストに直結するメトリックとしても適切ですね。
親切に教えて頂いた Mike Cohn 氏に改めて御礼申し上げます。テストピラミッドの元となる記事を含む彼のウェブサイトはこちらです。
また、本記事のもともとの疑問は @gun_chari さんから質問を頂いて、僕がその際に回答できなかったものです。確かになあ、と思いました。
この記事が気に入ったらサポートをしてみませんか？