ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■信頼性と品質 / システム運用と管理
2022.08.09 2024.03.05 約5分
伊藤 由貴（@yoshikiito）と申します。テスト自動化エヴァンジェリストと名乗り、約10年、テスト・QA、特にテスト自動化の世界で仕事をしてきました。コミュニティ活動では、主にソフトウェアテストに関する書籍の執筆や、テスト自動化シラバスの翻訳などをおこなっています。
所属する株式会社ベリサーブは、エンジニアの大半がテストエンジニアや Qエンジニアで、ソフトウェアの検証や品質向上が主な業務です。私は、社内エンジニア向けにテスト自動化の普及や推進をしたり、彼らと一緒にソフトウェア開発をしている会社やチームに対してテスト自動化の導入をお手伝いしています。
本講演の概要は大きく3つです。
質問です。皆さんは普段どのような「テスト」をやっていますか？あるいは「テスト」と聞いて、どのような「テスト」をイメージしますか？
おそらく一人ひとり違うでしょう。ソフトウェアテストの自動化やソフトウェアテストはかなり広い意味を持っているからです。開発の方なら真っ先に思い浮かぶのは「単体テスト」テスターの方なら「システムテスト」を思い浮かべるでしょう。このように、普段の役割とテストレベルが紐づくことが多いと思います。
「テスト」「テスト自動化」には広い意味があります。そのため特定の部分や自分が普段関わる部分だけではなく、いろいろな側面から見ることが大事です。「いろいろな側面から」にはいくつかモデルがあるので、2つご紹介します。
アジャイルテストの4象限は『実践アジャイルテスト』などで紹介されています。縦軸がビジネス面と技術面、横軸がチームを支援する側面と製品を批評する側面です。この縦横の軸でテストを捉えたときに4つのエリアの象限ができます。いろいろな種類のテストが各象限に該当し、外側の雲のような部分がどういった手段で実行するのかを表した図です。
Testing と Checking という概念を紹介します。我々が普段、テストやソフトウェアテストと呼ぶものは、Checking と Testing という2つの側面があります。
私達が確認検証や妥当性確認のプロセス、正解を知っているときに、そのとおりになっているかをチェックすること
探索や発見、調査や学習のプロセス。想定外の問題を認識するつもりで操作や観察をおこなうテスト
この考え方の場合、Checking の方が自動化に向いています。正解が分かっているものであれば、それを機械的に検証することも可能だからです。この後の話に関しては、Checking の自動化にフォーカスして進めていきます。
ここからは最も有名であろう「テストピラミッド」というモデルと類似モデルをいくつか紹介します。
上記の図がテストピラミッドです。ここではテストを以下、3つの層に分けています。左の軸は上に行くほど実行に時間がかかることを表していて、右の軸は上に行くほど実行したときにコストがかかることを表しています。
日本では 2018年頃から知られるようになった考え方です。
テストピラミッドと反対に、あまり良くない例としてあげられるのがアイスクリームコーンです。レイヤーの並び順はピラミッドと同じですが、Unitテストが一番少なく、Intergration、E2E になるにつれて割合が増えていき、一番上に Manualテストが乗っています。
これはコストや実効速度のバランスが非常に悪いですよね。時間とお金がかかる形になっているので、このアイスクリームコーンはなるべく避けるべきだといわれています。
上記の図にないものもたくさんあるので、興味がある方は他のモデルも調べてみてください。
バグフィルターという考え方があります。テストピラミッドと並び順が逆です。テストピラミッドやアイスクリームコーンにはなかった ALERTING、MONITORING、LOGGING という3層が1番下に出てきます。UNIT が網目のようになっていて、文字通りバグを捉えています。
UNIT は網目が1番細かくカバーしている範囲が狭いので、ここで検知できないものを下の少し目が粗いものの、より広い範囲を見ている INTEGRATION で捉え、さらに目が粗いもののカバーしている範囲が広い E2E、ALERTING、 MONITORING、LOGGING というように全体の各層で対応する、虫を捕らえていくようなイメージを表している図です。
UNITテストや E2Eテストをどう自動化しようかと絞って考えることも必要ですが、特定のテストレベルに閉じず、テストの全体、各レイヤーの総体としてどうテストするかが大事だと学べます。また、ピラミッドやバックフィルターが絶対の正解ではないので、実際にチームや組織で導入していくにあたり、参考にしつつも自分たちにとって最適な形を模索すべきだということも学べます。
特にテスト自動化に習熟して進んでいる組織では、例えばピラミッドを組織独自の4層構造にしたり、特定の層を左右に分割して複数のテストを並べるなど、アレンジしているチームも存在します。
実際にチームや組織で自動化をしていくとき、どのように進めていくことが多いのか、どう進めていけばいいのかについてお話します。
「テスト自動化をしたい」との相談が多いので、自動化がうまくいかない場合の傾向を図にまとめました。例えば、開発の状況としては既にプロダクトリリースが済んでいて機能追加や改修フェーズですが、その過程で単体テストや結合テストが整備されていない、QAエンジニアもどのくらい整備されているのか把握していないことが多いです。さらに E2Eテストはあるものの全て手動なためにテストが追いつかず、結果的に不具合を見逃してしまい、リリース後にユーザーからの報告でバグが見つかる状態をよく伺います。
この状態は負のサイクルにはまっています。テストが十分にできず、リリース後にユーザーさんに見つかる状態で不具合が増えてしまい、結果的に修正にもコストがかかります。修正は大変なので、そこのしわ寄せがテストにきてしまい、テストが十分できないような負のサイクルにはまっているパターンです。どこかを断ち切りたいと考えたときに、テストの自動化をすれば不十分であるところから切り込んでいけるのではないかと考えるパターンが多いです。
上記が私がよく提案する負のサイクルを断ち切る方法です。左下の「無」は、例えば自動テストが十分に整備されていない状態から一気に右側のピラミッドを目指していくのは困難なので、一旦アイスクリームコーンを経由し、さらにいうと E2Eテストの整備をするところから入り、徐々にピラミッドの形にバランスを修正していく流れでいくのはどうですか？ということです。
アイスクリームコーンはアンチパターンです。時間もお金もかかるので、あまり良くありません。また、アンチパターンである理由が、例えばユーザーさんに不利益がもたらされるからであれば、それはやるべきではないと思います。ただし、どのみちコストがかかるなら、今回やるのはどうですか？とご提案することが非常に多いです。
本当は単体テストを十分に行ったほうがいい、という共通認識をもったうえで、可能であれば一旦コストを許容してE2Eテストの整備から始めましょう。
まずは E2Eテストを整備することにより、リリースをする前に E2Eテストを自動で回し、今回加えた機能追加や変更などがユーザーにとって不利益をもたらしていないという最低限のラインを担保している状態を作り、そこから単体テストが揃っているピラミッドの形に近づけていくルートを辿るのも一つの手です。
アイスクリームコーンを経由して右下のピラミッドにいくと、第1ステップは何もない状態から E2Eテストを整備してアイスクリームコーンのような状態にすることです。
E2Eテストは、どこから着手すべきかを考えましょう。よくある失敗として「E2Eテストは今あるものを100%自動化するんだ」となってしまうことです。テストにも向き不向きがあります。向いてる部分を見極めて自動化することが大事です。どの順番でどこまでやるかを考える必要があります。ここでは2種類のやり方をご紹介します。
前回発表されていた @t_wadaさんの「質とスピード」でも登場した『リーン開発の現場』に書いてある方法が1つです。表に色付けし優先順位を付けて並び替える作業をすることで特に自動化コストが低く、リスクや手動テストのコストが高いところから自動化するという真っ当なアプローチができます。
Angie Jonesさんが考えた方法も紹介します。テストケースや機能に対して、5つの軸でスコアリングをし、自動化の対象を選択する方法です。
スコアは100点満点で点数ごとに色分けがされ、優先順位づけをする方法になっています。
Angie Jonesさんの登壇動画や資料が公開されているので、興味がある方は見てください。紹介した2つの方法は、チーム全員でスコアについて考え、合意し決めていくプロセスになります。
手元にあるテストケースをそのまま自動化しようと考えるのはやめましょう。
手動実行を前提としたテストケースになっているので、人が読んで理解できるレベルの少し粗めの粒度になっていることです。それを曖昧な状態のまま自動テストに変えていくと、不安定や低信頼な自動テストになる可能性が高いです。また、手動実行を前提としたテストケースは実行効率を考えたとき、テストケース間に依存関係があることが多いです。
つまり、あるテストケースを実行するとデータが登録され、次のテストケースではそれをそのまま使って変更処理をするような順番に実行されるように作られていることが多いです。これを自動化した場合、データ登録に失敗すると芋づる式でその後のすべてが失敗してしまい、Fail時の原因調査や自動テストの保守が大変になるので、テストケースが手元にあるからといってそのまま自動化するのはなるべく避けた方がいいです。
今あるテストケースをそのまま自動化するのが駄目であれば、少し加工するやり方があります。例えばテストケースの並び順やデータ登録を別に出すなどの再構成をおこなったり、手順や確認項目で曖昧な部分があれば、それを一つひとつ詳細な手順に書き起こしてブレイクダウンし、それから自動化する作戦をとることがあります。
この対策方法は上手くいくものの、とても手間がかかるので、テストケースになる前から考えることをおすすめします。テストケースが出来上がったものをそのまま自動化するのが問題であり、テスト設計プロセス、あるいはそれ以前から自動化の検討をするべきです。
上記の画像は2021年に「テスト設計コンテスト」の決勝に残ったM3さんのプレゼン資料から借りてきたものです。この中にテストの方針出しというステップがあります。これにより自動テスト観点や自動テストのテストケースなどが出てきます。
自動テストをする前提で生成されたテストケースは、手動実行前提としたものに比べて効率がいいので、最初から自動化に対しての考えを盛り込んだテスト設計をしようと紹介しています。
E2Eテストが整備できたら、次にやることはなるべくピラミッドの形に近づけることです。主に Unitテストをどう整備するかの話になります。
いろいろな方法がありますが、基本的なアイディアは前段で E2Eが整備できたので、これをセーフティーネットにすることで単体テストが整備できるはずだという考え方です。
E2Eテストを頼りにまずは「単体テストができる状態」を目指し、手を入れていく。前段で E2E を整備しておくことで、何か問題が起きた際に検知してくれる状態が実現できています。これを頼りに単体テストができる状態を目指して手を入れていくことができる手段だと思います。
単体テストを入れていく、そしてどこからやるかの話は『ソフトウェア品質を高める開発者テスト』にて紹介されています。複雑度や Hotspot値によってスコア付けをし、特に複雑度が高いものはファイルを分割して複雑度を減らしてから単体テストを書く方法が紹介されています。ここまでで、アイスクリームコーンの状態を経由してピラミッドに近い状態を目指せるという道筋が見えてくるのではないかと思います。
一旦は多少の遠回りを許容しつつ、テスト自動化を進めることです。アイスクリームコーンを経由してもいいと思うので、まずは一歩進んでみてほしいです。知らずにアンチパターンを踏むのはよくないですが、なぜ？どう悪いのか？を理解できれば、どこまで許容するかの判断がつきます。アンチパターンがアンチパターンたる由縁を知っていただいたうえで、どこまでなら許容できるのか、どういうルートなら理想に向かっていけるのかをぜひご自身のチームで探していただければと思います。
伊藤：E2Eテストと仮定して話すなら、私は必要派です。テスト仕様書が必要な理由を考えたときに、全体でどのようなテストが整備してあり、どこが実行され、どのような結果になったかを整理したいという目的があると思います。その目的を達成するためにはテストコードだけでは足りない気がします。例えばテスト管理ツールと自動テストツールが上手く連動していると二重管理のように無駄が少なく運用できるかもしれないですね。
伊藤：正直、私も知りたいぐらいです（笑）そのような活動をここ数年やってみて分かったのですが、何か1つのアクティビティや、これをやると根づくということはありません。これをやったら浸透するんじゃないか？根付くんじゃないか？ということを全部やる勢いで時間をかけるしか道がないと思っています。
組織を巻き込んでテストを根づかせる場合は、「テスト自動化によって1番の困りごとを解決できそう」という感覚を持ってもらうようにしています。
テストの証跡としてスクリーンショットが必要な場面ってありますよね。例えばそれを自動で取得して、かつ old と new を比較する仕組みを作ると見栄えも良かったりするので、まずはこんなことができるんだと興味を持ってもらい、自分たちの苦労しているものが楽になる気がするぞと思ってもらいます。
伊藤：例えば E2Eテストで不具合が見つかった場合「これは E2Eテストでしか見つからないものか？実は単体テストで見つかるのでは？」と分析します。そうすると問題ごとにどの段階で検知するのが理想だったのか分かります。
【質問全文】自動テストが少ない既存のプロダクトに対して、自動テストを増やしていく際の人的リソースの配分におすすめの方法ありますか？例えば専門のチームを組む。ただし、開発チーム全体の知識を共有するのは難しそう。既存の開発チームが何%時間を割く。これもなかなか進まなそうなど。
伊藤：人的リソースの配分は、 E2Eのテストは専門家だけではなく、みんなで自動テストに関わろうという考え方が最近の主流です。Autify のようなツールを使い、みんなで自動化をしていく場合もあるので、何%の配分でやるなどを決めずに誰もが自動テストをしている状態が理想系かもしれません。ポジショントークにはなりますが、専門のチームでなくても専門家がいるとだいぶ進みはいいですよね。私もよく「兼任の担当者は大体うまくいきません」と言います。未経験の人だとしても、専任の担当者を置くとそれだけでかなり変わります。
【質問全文】自動化の過渡期について、チーム内の単体テストを一部ツールで自動化し始めました。しかし、そのツールの範囲外の部分は従来通りの手法（Excel）で実施することになってしまい、負担が増えてしまいます。どんどんツールを使ってもらいたい一方で、負担はあまりかけられない、この過渡期を乗り切るポイントを知りたいです。
伊藤：もしその状況であればなかなか厳しいですね。根本解決をするのであれば、ツールを変える手段もあると思います。ツールが変えられない状況なら、過渡期がいつまで続くかカーブを描いてみて、ここまでいけば出口が見えるんだというイメージをチームで持つのが1つの解決策になると思います。
伊藤：自動化を始めるためのハードルの1つにコスト回収の説明があると思うので、その視点で回答します。自動化にかかるコストと自動化で削減できるコストを天秤にかけたいですよね。テスト自動化によってリリースサイクル向上やバグの早期発見などが可能になるので、結果的に開発効率が向上します。「自動化コストは増えても、開発プロジェクト全体で見れば効率があがっています」と説明できるでしょうね。
ぜひ「品質コスト」で検索してください。区分が出てくるのでより細かい粒度で考えられます。秋山さんの資料を見ていただくのが1番わかりやすいと思うので参考にしてください。
2012年株式会社ベリサーブに入社。 テスト自動化ツールの開発を経験し、その後さまざまな現場でのテスト自動化導入支援を担当。2019年に自動テスト推進課を立ち上げ、社内外でのテスト自動化技術の普及活動を行っている。著書『ソフトウェアテスト技法練習帳～知識を経験に変える40問～』
目次
