フロントエンドテストは慢性的に頭を悩ませている
「フロントエンドテスト」には様々な領域が含まれる
フロントエンドテストとはざっくりと、ウェブアプリケーションやウェブサイトのフロントエンド部分を対象に行うテストを指します。
フロントエンドはすべての開発の行きつく先であり、
- 単体～結合テスト
- E2Eテスト（シナリオテスト）
- 非機能テスト
- 自動テスト
など、複数の観点や操作でテストが存在します。
「フロントエンドテスト」すべてにQAだけで立ち向かうのは困難
一般的に「QAはテストのスペシャリスト」で「フロントエンドテストはQAの専門領域」という認識が強いと考えています。
それは概ね間違っていません。
しかし、基本的にQAは「E2Eテストが専門領域」であるケースが多いです。
そのため、QAにフロントエンドテストの全領域を任されることがほとんどですが、
- 非機能テスト（UIUX、負荷、脆弱性等々）はそれぞれの専門家が
- 自動テストには開発力が
必要です。
それほどまでに異なる分野が一堂に会している状態です。
専門家たちによる弊害
では、それぞれの分野の専門家にその領域を任せるとどうなるか。
QAがテストを作れるのは、テストの専門家であるからです。
つまり、各分野の専門家は、テストの専門家ではありません。
そうして、各々が自由に作ったテストの山が生まれます。
事由に作るという事は「属人的である」ということです。
属人的であるため、集計ができなかったり、他の人には理解できないものになります。
すると、その人がいなくなれば改善することもできなくなります。
E2Eだけに絞った問題
ではQAがメイン所とするE2Eでは問題が無いのでしょうか。そんなことはありません。
製品とは大きくなっていくものです。
製品の仕様把握といった必要な知識の分量は増え続けます。
また、テスト範囲が広がれば、テスト実行のコストも増え続けます。
これに対応するための自動テストだったりしますが、そう上手くいくものでもないです。
E2E自動テストの問題
人の問題
先ほども記載した通り、E2Eテストの自動化には開発力が必要です。
しかし、QAの中で開発力がある人材は多くありません。
逆に、開発者であれば良さそうに見えますが、今度は十二分にテスト設計力が必要です。
開発者の中でテスト設計ができる人材は多くないでしょう。
専門家が少ない、というよりも「2職種分のスキルを持つスペシャリスト」が希少だということです。
集計の問題
仮に自動テストを構築できたとして、結果を確認しなければ意味がありません。
人の手を介さず、日次や週次で何十本何百本と実行される結果を、どう集計し、可視化し、報告するのか。
Jenkinsや外部ツールか、自動テストをどう実装しているのかによっても、その自動テストの意義によっても、方法は多岐にわたるでしょう。
メンテナンス性の問題
E2E自動テスト最大の弱点、それは画面変更の影響を大きく受けることです。
少しの画面変更で、動かなくなります。
開発が多くなれば、それだけメンテナンスコストは上がります。
自動テストの数が増えれば、それだけ壊れる箇所も可能性も上がります。
リグレッションテストの自動化におけるコストの損益分岐点について話があります。
様々な算出方法がありますが、概ね「自動化した方が安上がりになる損益分岐点は10サイクル以内にやってくる」ことがほとんどのようです。
しかし、ここではメンテナンスコストについての勘定がされていません。
単純な損益の話であればそれで終わりですが、メンテナンスコストは増大し続ける一方です。
必ずどこかで「メンテナンスの工数よりコストが上回る」ことになります。
つまり「いつか直せなくなる」ということです。
永遠の課題「テストの構成管理」
そして、誰が作ったテストでも、自動化でも、QAのみならずテストコードであっても共通する永遠の問題があります。
それが「構成管理」です。
ざっくり言えば「テストに関連する要素の更新履歴の管理」です。
- なぜこのケースが追加/削除されたのか
- 因子/水準の変更理由は何なのか
- 期待値が変わったのはどうしてか
転じて、
- このケースを追加/削除していいのか
- 因子/水準を変更していいのか
- 期待値を変えていいのか
ということにもなります。
Gitで管理できるテストコードであれば多少はマシですが、テストの構成要素すべてがGit上にあるわけではないので、難しいものです。
「フロントエンドテストの問題」とは
ここまで記載しましたように、フロントエンドテストとは
- 多くの専門領域
- 相反する個別最適と全体最適
- 増大し続けるコスト
を内包し、一筋縄では解決できない領域になります。
フロントエンドテストの問題を一掃するTricentis
ここまでフロントエンドテストの広大さとそれゆえの問題を長々と説明してきました。
それは何故か。
解決できるからです。
私の感じるTricentis社のソリューション
ノーコードE2E自動化ツール「Tosca」を中心として、フロントエンドテストの全領域をまるっと解決してくれると感じています。
今現在揃っている製品群から、それをひしひしと感じます。
どう解決してくれるのか
E2E自動テスト-Tosca-
先述したE2E自動テストでの問題点は以下の通りでした。
- 開発力が必要だがQAにはない
- 結果の集計が難しい
- 軽微な画面修正でも動かなくなる
Toscaはノーコードのテスト自動化ツールです。
そのため、開発力が不要になり、QA内で完結して管理が可能になります。
何より感動したのが、ブラウザだけでなくアプリケーションに対しても使える点です。
ブラウザ版とアプリケーション版でテスト対象が複数ある場合でも、Toscaだけで対応できます。
Toscaより軽量なTestimという製品もあり、製品や規模によって選べるのも嬉しいですね。
結果の集計については、テスト管理ツールqTest上ですべてを管理できます。
自動テストツールが管理ツールと連携していると、他のテストとも集計をまとめやすく、集約しやすいのは大きな利点です。
メンテナンス面については、ノーコードでありQAでも直しやすい点に加えて、自動テスト設計を「モジュール」というパーツ単位の組み合わせで行っていることから、モジュールの修正で複数のテストケースをまとめて修正可能な点が大きいです。
また、最近流行りのAIが導入されており、そもそも小規模な変更は対応不要。自動で修復してくれるのは圧倒的です。
非機能テスト（負荷検証）-NeoLoad-
先述した非機能テストでの問題点は以下の通りでした。
- 専門家が必要
- 結果の集計が難しい
専門家が必要というのは、実行もそうですし、検証用のツールの準備や知識も必要です。
また、使い方を誤ると危険でもあります。
その点、製品群に負荷検証ツールのラインナップがあることは一種の安心感があります。
サポートや手順書が豊富で手厚い点もよいです。
結果の集計については、こちらもテスト管理ツールqTestが使えます。
フォーマットが他と揃えられる点は非常に大きいです。
非機能テスト系はどうしても異なることが多いので、統一できることは大きなメリットです。
また、現状非機能テスト系はNeoLoadのみのようですが、今後の製品展開に期待です。
簡単なセキュリティテスト程度であればToscaでも対応できそうですが、やはり実行できる知識が必要になりますので、サポートしてくれると嬉しい所です。
テストの一元管理-qTest-
- 全テストの一元管理
- 全テストの構成管理
- 非機能テストの集計が難しい
- 自動テストの集計が難しい
基本的にテスト管理ツールは、もちろん一元管理と構成管理ができます。
qTest最大の強みは、先述のNeoLoadとToscaとの連携機能にあります。
自分で結果を入力しなくてもよいテストケース管理とは、甘美な響きです。
その他
製品はまだほかにもあります。
- QAでは手を加えづらい、データ周りのテスト支援をしてくれる「Data Integrity」
- 修正内容からQAが影響範囲を読めなくても、テストの優先度を提示してくれる「LiveCompare」
- テスト漏れを防ぐセキュリティゲートの役割をしてくれる「SeaLights」
など、今回はフロントエンドテストの問題に焦点を当てましたが、QA領域全体に広がっています。
製品レポート
実際にトライアル版を触ってみたので、その感想も置いておきます。
Toscaの使用感
でかい、ひたすらでかい！
「コイツと一緒なら、どこまでも戦えるぞ！」という全能感があります。
手作業がキックスケーターなら、これは四駆。馬力が違います。
試しにウェブブラウザの自動テストを組んでみました。
1からセレニウムで書き起こすより、圧倒的に早いです。
「ノーコードだとあまり自由じゃない」という話も小耳に挟んだ過去がありましたが、そんなことないです。
セレニウムでやってることとほとんど変わりません。
それどころか、画面の動かし方が複数あるので、セレニウムでどうしようもなかった操作もToscaならできました！
漠然と「ノーコード？ コード書いた方がいいでしょ」と思っていましたが、古かったです。認識を改めました。
そして、これがブラウザじゃなくてアプリケーションでもできるとは！
今「ブラウザだけじゃなくてアプリにも対応して」と言われたら挫けます。
技術選定から始めないといけないのかよ、って。
でもToscaならそれもない。同じ感覚で拡張できる。
GUIから離れられない民の認識として、「画面が共通」とか「操作が同じ」というのはとても大きいです。
qTestの使用感
Toscaを使い倒したら便利でしょう。
設計の根底が「テストの管理」ではなく「ToscaやNeoLoadのテストを管理。ついでに手入力も可」だと思われます。
Toscaのテスト設計にマッチした作りとなっているので、考え方の統一をできるのが強みです。
「テストの読み方」というのも難しいものです。
ものによってテンプレートが違うとか、資料がバラバラになっているとか。
Toscaを中心に作られているので、そうならないのが強いです。
私のチームでも、開発者用テストと評価者用テストと自動テストですべてテンプレートが違います。
そして、自動テストでは人が読めるように管理していないので、製品仕様をよく理解している人でないとテストを読めません。
そういったことがなくなるのは非常に強いです。
まとめ
Tricentis社のToscaを中心とした製品群は、フロントエンドテストにおける特効薬だと感じました。
多少慣れは必要ですが、圧倒的、強大なシステムで、サポートも手厚いので心配ないでしょう。
また、フロントエンドテストの領域では進化の余地がまだまだあります。
ここからどんどん進化していって、どんな素晴らしいシステムになっていくのか、目が離せません。