本記事は、みらい翻訳 Advent Calendar 2023の8日目の記事です。
はじめに
こんにちは！7月よりQAチームで働いているyaboと申します。
自分は自己研鑽の一環としてTechnology Radarを毎シーズン確認するようにしています。 今回はその取組を紹介してみようということで、「QAエンジニアから見たTechnology Radar Vol.29」と題し、 2023年9月末に公開された現時点で最新のTechnology Radarから個人的に気になった技術をピックアップしてご紹介しようと思います。
Technology Radarとは
Technology Radarとは、米Thoughtworks社が年2回春と秋に提供している、最新のソフトウェア技術のサーベイ記事です。 トピックは「Techniques」「Platform」「Tools」「Languages & Frameworks」の4つに分かれていて、 それぞれ市場への浸透度合いに応じて「1. Adopt（広く採用）」「2. Trial（試す価値あり）」「3. Assess（評価段階）」「4. Hold（保留・注視）」にレベル分けされています。
OSSに関する情報を言語問わず広く扱っているため、自分は特にフロントエンドのトレンドに強いState of JavaScriptと合わせて毎シーズン参照しています。 ちなみにこうしたサーベイは基本的に英語なので、弊社で提供しているChrome拡張を使いながら読んでいます。開発チームに謝謝(シェイシェイ)🤗。
項目のピックアップ基準
まずは「そういった技術があると知る」ということを主眼に置き、テストやQAに関する技術をなるべく幅広くピックアップしました。 E2Eテストレベルに相当するものから単体テストレベル、静的解析レベルに相当するものまで含めています。 ただし、主としてセキュリティ・セキュリティテストに関する技術はここに含めてしまうとリストが膨大になってしまったため、今回は除いています。
というわけで、早速見ていこうと思います！
Techniques
3. Accessibility-aware component test design (Trial)
Accessibility-aware component test design | Technology Radar | Thoughtworks
日本でも最近書籍が発売されたりイベントが開催されるなど大きな注目を集めているWebアクセシビリティ。 アクセシビリティを担保するにはアクセシビリティを意識したコンポーネントテストを設計することが大事です。 具体的な設計方法として以下の2つが述べられています。利用するフレームワークとしてはTesting Libraryへの言及がありました。
- test-idやクラスを使って要素検証をするのではなく、ARIAロールや他のアクセシビリティ支援技術を使い要素を識別すること
- マウスクリック操作によるテストだけを実施するのではなく、マウスを使えない人やスクリーンを見ることができない人のことも考慮して、キーボードやその他のインタラクションのテストを追加すること
現状みらい翻訳のQAチームで実施しているのはE2Eテストがメインで、各開発チームで実施している単体テストまではキャッチアップできていないのが現状ですが、 フロントエンドチームと協力してこの領域にも何らか施策を打てたらいいなと考えています。
11. Risk-based failure modeling (Trial)
Risk-based failure modeling | Technology Radar | Thoughtworks
FMEA(Failure Modes and Effects Analysis)などに基づくリスクベースの故障モデリングがこのタイミングでTrialになっています。 クロスファンクショナルチームの大規模開発でこのような手法が機能しやすいと述べられています。
個人的には相当昔からあるFMEAのような手法が2023年の今Trialになったことには少し文脈の補足が欲しいように感じました。 欧米ではなんらか技術トレンドの変化があったのかもしれません。
14. Unit testing for alerting rules (Trial)
Unit testing for alerting rules | Technology Radar | Thoughtworks
監視・オブザーバビリティツール上でアラートを設定した際、従来はその確認に実際にアラートのルールを満たす必要がありました。 これを気軽にテストできるように監視ツールベンダがアラート用の単体テストツールを提供してくれる流れがあるようです。 例としてPrometheusが提供しているテストツールが挙げられています。
このようなことが実現できるようになるとSREエンジニアの方はとても助かりそうですね。 ただツールベンダの取り組みに依存するのがネックでしょうか。 弊社では現在Datadogの導入を検討していますが、Datadogでは該当するようなツールはまだ存在しないようです。
Tools
50. Chromatic (Trial)
ChromaticはStorybookと連携するUIコンポーネントビジュアルリグレッションテスト(VRT)ツールです。 VRTツールはE2Eテストレベルでページ単位で見るもののと、単体テストレベルでコンポーネント単位で見るものがありますが、これは後者に当たります。 フロントエンド開発者の方であればこちらの方が使い良さそうですね。他方でそもそもStorybookを整備するのが大変だとか、活用にあたってはいろいろな課題があるような気もします。
53. Container Structure Tests (Trial)
Container Structure Testsはその名の通りコンテナイメージの構造をテストするツールです。Google製。 イメージ内のコマンドの出力は期待どおりか、メタデータやファイルシステムの内容は期待どおりかなどを検証できます。
個人的にあまりコンテナのテストに関しては詳しくないのですが、 Trivyのような主として脆弱性をチェックするツールに比較すると、こちらは機能性を確認するような位置付けに見えます。
57. Insomnia (Trial)
APIテストプラットフォームとして広く利用されていたPostmanのSaaS化に伴い、 オフラインでデータを保持したいユーザは代替策を探す必要に迫られています。 Insomniaはその代替プラットフォームの1つとして名前が挙げられており、他には HTTPie や IntelliJ HTTP Client pluginも紹介されています。
弊社でもQAチーム・開発チームともに以前からPostmanを活用しており、PostmanのSaaS化への対応が必要になりそうです。 ここでは代替サービスが提示されていますが、移行コストや移行先もSaaS化するリスクなども考えるとPostmanを契約してしまった方が早いような気もしています。
65. Terratest (Assess)
TerratestはTerraformなどのIaC構成のテストをするツールです。Go言語でテストを記載します。 単体テストだけでなく、実際にインフラをデプロイしてE2E的にテストを実行することもできるそうです。自分は利用したことがないのですが良さげ。
76. Maestro (Assess)
MaestroはモバイルアプリのUI・E2E自動テストツールです。iOS・Androidのネイティブアプリ、React NativeやFlutterに対応しています。 この領域ではしばらくAppium一択のような状況だったように思いますが、ようやく対抗馬が現れました。
Appiumはテストスクリプトを書くのが中々つらかったのですが、Maestroはyaml形式でテストスクリプトを記載するなどシンプルで書きやすそうですね。 またテスト実行時にステップを見やすく表示してくれるなど、とてもエンジニアフレンドリーに感じます。 弊社ではまだモバイルアプリを提供していないので業務で触ることは当分なさそうですが、将来的に触ってみたいツールの1つです。
44. Ruff (Adopt), 60. Kubeconform(Trial), 85. Ajv(Trial)
リンタ・バリデータ類はまとめてご紹介です。
- RuffはPythonの新しいリンタツールです。Pythonでは長らくflake8が主流のリンタでしたが、それに比較してとても高速であることが特徴とされています。
- KubeconformはKubernetesマニフェストのバリデータです。CI/CDパイプライン上やローカルで簡単に動作可能です。
- AjvはJavaScriptでのJSONスキーマのバリデータです。複雑なデータ型も検証可能です。TypeScriptではZodが広く使われています。
Languages & Frameworks
83. Playwright (Adopt)
PlaywrightはMicrosoft社謹製のE2Eテストツールです。Node.js, TypeScript, Java, .NETで利用できます。 以前使用していましたが、かつて主流だったE2EテストツールであるSeleniumやCypressよりも断然使いやすかったため、Adoptとなったのも納得です。
他方でCypress登場からのPlaywrightへの世代交代(?)が非常に早かったこともあり、また新たなフレームワークが出てくるとも限りません。 OSSのE2Eテストフレームワークを採用する場合には定期的に乗り換えるくらいの心持ちでいたほうがいいのかもしれませんね。
89. fast-check (Trial)
fast-checkはJavaScript/TypeScript向けのプロパティベースドテスティングツールです。 プロパティベースドテスティングとは、個別のテストデータを設定するのではなく、 ランダムなテストデータを自動生成・繰り返し実行することで、実装の不具合を見つける手法になります。考え方としてはファジングにも似ていますね。
特に入力値のバリデーションなど、ポリシーの正常系を1つ試すだけではかなり怪しい部分に対して、 プロパティのようなある程度形式的な方法で入力を定義してテストデータを生成するのは効果的な手法に思います。
プロパティベースドテスティングに関しては11月（！）に専門書も発売されたそうです。
『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』www.lambdanote.com
102. Kotlin Kover (Assess)
Kotlin KoverはKotlin向けのコードカバレッジ測定ツールになります。
個人的にはKotlinの単体テストツールで何がメジャーなのかすら知らないほどKotlinに無知なので、「こんなのあるんだー」という風に思いました（小学生並）。 このような他の言語やフレームワークのツールを知れるのがこういうサーベイの良いところですね。
105. prompt-foo (Assess)
prompt-fooはLLMのプロンプトを評価するツールです。 真偽を判定するという意味でのテストではなく定性的なスコアリングをするような代物なので取り上げるか迷いましたが、面白そうだなと思って入れてみました。
今後LLMに関係する機能を提供するサービスであれば、プロンプトの良し悪しはサービス自体の品質に大きく関わってくることになるかと思いますが、 そのような状況においてQAエンジニアが何をすべきかは注目していきたいところです。将来的にはQAがこうしたツールを使うこともあるのかもしれませんね。
まとめ・個人的な注目ポイント
いかがでしたでしょうか。個人的には「3. Accessibility-aware component test design」「76. Maestro」「105. prompt-foo」あたりが気になりました。 特にMaestroに関しては、今後日本のQA界隈でも採用してみた事例がたくさん出てくるんじゃないかと期待しています。 また現在の業務にダイレクトに関わってきそうなところとしてはPostmanのSaaS移行が大きく、いい加減対応しないとなあとヒヤヒヤしています。ぴえん🤪。
最後に
みらい翻訳ではこんな感じで(?)、いろいろな技術を楽しめる方を随時募集しています。 ご興味のある方はまずはカジュアル面談からで大丈夫ですので、下記リンクよりお問い合わせをお待ちしております！
