品質エンジニアになるための学習ロードマップ
品質エンジニアまたは SDET としてのキャリアに必要なスキル、ツール、技術に関する初心者向けのガイドです。
原文：Quality Engineer Learning Roadmap
作者：Blake Norrish
日本語訳：Gen Kudo
校正者：Takahiro Ito
品質エンジニアになるためには何を学ぶべきなのでしょうか？どのプログラミング言語を選び、どんなツールを使いこなし、どんなスキルを磨くべきでしょうか？このキャリアに興味がある人がいたら、何から始めるべきだとアドバイスしますか？何が重要で、何が知っていると便利で、何がすでに廃れてしまい学ぶ必要のない技術なのでしょうか？
これらは簡単に答えられる質問ではありません。品質エンジニアは、基本的なコンピュータサイエンスや品質保証の基礎から、最新の自動化フレームワーク、アプリケーションスタック、テストツールまで、あらゆる知識/スキルの上に成り立ちます。すべてをリストアップするのは途方もなく大変です！この記事では、品質エンジニアとして成功するために必要なすべてのスキル、ツール、テクノロジーを説明する学習ロードマップを紹介します。
品質エンジニアの役割
まず、「品質エンジニア」とはなんなのでしょうか？
ソフトウェアを構築する方法はたくさんありますが、私たちは、少人数で、機能横断的で、協力的なチームによってソフトウェアを構築するのが最善だと考えています。「クロスファンクショナル」とは、外部のチームやスキルセットに依存することなく、ソリューションの構築に必要なすべての役割とスキルを備えたチームを指します。
このようなチームにおける役割のひとつが、品質エンジニア（Quality Engineer/QE）です。QEは単なるテスターや自動化担当者ではなく、ソフトウェア構築のあらゆる側面に品質マインドセットをもたらすことでチームに力を与えます。QEは品質保証、テスト自動化、リスク分析、アジャイルプロセス、CI/CDなどプロダクト品質に影響を与えるあらゆるもののエキスパートです。QEは他のすべての役割のメンバーと協力し、初日（最初のストーリーの最初のコードが書かれる前）から品質が組み込まれていることを保証します。この役割をSDET（Software Development Engineer in Test）と呼ぶ会社もありますが、会社によって役割の定義は様々で、SDETやQEの具体的な仕事内容は会社ごとに異なります。
このロードマップは、Slalom Build の品質エンジニアの役割に特化して作成されましたが、名前や肩書きに関係なく、品質に関連する分野でキャリアをスタートしようとしているすべての人に当てはまるものだと考えています。
品質エンジニアリングの学習ロードマップ
当初、品質エンジニアの学習ロードマップはシンプルなものを目指していましたが、トピックやスキルの数があまりにも多かったため、まずは一般的な学習分野に整理することにしました。下図をご覧いただくとわかるように、個々のトピックは数百に及びますが、そのすべてをより管理しやすい18のセクションに整理しました。各セクションを個別に見ていくので、今はあまり全体像にとらわれないでください。
(図が小さすぎて表示されない場合は、こちらからフルサイズの画像(英語)をダウンロードしてください。 PDF | PNG | SVG )
ご覧のとおり、学ぶべきことはたくさんあります。品質エンジニア の役割は幅広く、関連するスキルをすべて学ぶことはとても大きな投資です。
各分野を見ていくにあたり、この簡略化した凡例を使用します。主要概念は白、サブ概念は緑、ツール、言語、フレームワークは青で表します。緑や青のボックスが白のボックスについている場合、その接続線は "例えば "と解釈してください。サブコンセプトやツールのリストは網羅的なものではなく、私たちが説明しているものの一例を示しているに過ぎません。青いボックスの場合は、品質エンジニアを目指す人にとって最も関連性が高い、または最も価値があると思われる例を示しています。
それでは、ロードマップを見ていきましょう。
品質保証の基礎
品質保証の基礎から学習を始めます。品質保証の基礎を固めることは、成功のために非常に重要で、他のほとんどのトピックはここで学ぶことを基礎としています。
手始めに、ソフトウェアにおける「品質」の意味を理解する必要があります。それを理解した上で、テストケースとは何かを定義し、テスト設計技法を使用してテストスイートとテスト計画を作成する方法について説明します。設計技法の中には、エッジケース、同値クラス、境界値分析、組み合わせテスト、リスクベースドテストなどの概念があります。テストを記述するための特定の用語があり、ブラックボックステスト、ホワイトボックステスト、グレイボックステ スト、機能テストと非機能テスト、ポジティブテストとネガティブテスト、静的テストと動的テストなどを区別して、テストケースやテストタイプをどのように記述し、分類し、グループ化するかを知ることが重要になります。
また、パフォーマンス、セキュリティ、アクセシビリティ、互換性、ローカライゼーションなど、非機能テストと呼ばれる活動もあります。これらの専門家である必要はありませんし、新人の品質エンジニアが専門家であることを期待されることもありませんが、用語とそれらがどのような種類のテストを示しているのかは知っておくべきです。
これらに加えて、プロジェクト管理、欠陥のトラッキング、テストケース管理、レポーティングのためのツールにも精通しておく必要があります。一般的なプロジェクト管理にはJiraが最も一般的で、テストケース管理にはZephyr、TestLink、TestRailなどのツールが一般的です。
このセクションには、ここで説明しきれないほど多くのトピックがあります。優れた品質エンジニア生み出すのは基礎の習得であり、これらのトピックをしっかりと使いこなすことは後によりエンジニアリングに特化したトピックに進む上でとても重要です。
ソフトウェア開発ライフサイクル (SDLC) の基礎
ソフトウェア開発はもはや一人で行うものではなくなり、ごく稀な例外（gitやMinecraftなどでしょうか?）を除いて、モダンなソフトウェアはすべてチームで作られています。効果的な品質エンジニアになるためには、ソフトウェアチームの多くの個人がどのように協力してプロダクトを開発・リリースしているかを理解することが重要です。特定の開発方法論や開発哲学について深く掘り下げることはしませんが（それは後で説明します）、世の中にあるもの、以前使われていたもの、そして現在使われているものを理解する必要があります。
ここでは、ウォーターフォールモデルとは何かを学び、Vモデルやスパイラルモデルのようなものがアジャイルという言葉の使用よりも前に存在していたことを理解することが（たとえそれらが非常によく似たものを表現していたとしても）重要です。また、スクラムやカンバンのようなモダンなアプローチの基本や、近年のソフトウェア開発でこれらの開発方法論を採用することに対しての賛否両論どちらも知っておきましょう。
このカテゴリーは理論的過ぎるように見えるかもしれませんが、SDLC の基礎の強固な基盤を持つことは、 品質エンジニアリングの道を歩み始める際に大いに役立つでしょう。
インターネットの基礎
1995年、ビル・ゲイツがマイクロソフトの幹部たちに宛てたメモに、インターネットはいまや彼らにとって「最高レベルの重要性」であると書いたのは有名な話です。今日、ほとんどすべてのソフトウェアは、何らかの形でインターネット・ソフトウェアになっています。ソフトウェアがどのように機能し、どのように壊れるかを理解するためには、インターネットの仕組みを知る必要があります。
これは大変なことに思えるかもしれませんが、気を落とす必要はありません。特定の技術について深く理解する必要はなく、全体がどのように組み合わされているかの概要を理解できていれば十分です。例えば、パケットの優先順位がIPv4パケットヘッダの2番目の8ビットのワードに設定されていることを知る必要はありませんが、IP（「インターネット・プロトコル」）がパケットに関連していて、TCP/IPのIPを構成するものであることは知っておいた方がいいでしょう。
その他、DNS、HTTP、OSIモデルなどの重要なインターネット技術についても知っておく必要があります。Webアプリケーションの基礎はこの後に取り扱うカテゴリーなので、HTML/JS/CSSのようなものは後回しにしておきましょう。
インターネットの基礎は、日々の品質エンジニアリングの仕事において必須の知識ではありませんが、他の多くの重要な技術、概念、ツールの基礎となります。インターネットの基礎の土台があれば、AWS Route 53のようなものが典型的なクラウドアプリケーションスタックにどのように組み込まれるかを学ぶことが容易になります。
コンピューターサイエンスとエンジニアリングの基礎
今にも、「コンピューターサイエンス、コンピューターエンジニアリング！そんなの4年制大学の学位だよ、どうやって独学で学べというんだ？」という叫び声が聞こえてきそうです。心配しないで大丈夫です。怖がらなくていい理由がいくつかあります。
学術的なコンピュータサイエンスやエンジニアリングには、品質エンジニアリングとは関係のない側面が多くあります。例えば、計算問題のどのクラスがNP、NP完全、NP困難のいずれに分類されるかを知ることは、学術的なコンピュータサイエンスでは重要なトピックですが、品質エンジニアとしてはあまり役に立ちません。
コンピューター・サイエンスやエンジニアリングの公式な教育は品質エンジニアリングの良い基盤となりますが、学問の象牙の塔の中に隠された魔法は存在しません。内部で学べることはすべて外部でも学べますし、そのほとんどすべてをインターネットのどこかで無料で手に入れることができます。
では、品質エンジニアを目指す人にとって、どのようなコンピュータサイエンスやエンジニアリングのトピックが必要なのでしょうか？例えば、コンピュータのハードウェアや、それらがオペレーティングシステムやユーザープログラムによってどのように制御されているかといったテーマがあります。また、ハードウェア制御のプログラムはどのように書かれるのか、そしてさまざまな種類のプログラミング言語がこれを実現するためにどのように進化してきたかを理解することも重要です。プログラミング言語の一般的な特徴や、それらがどのように分類されるか（高水準言語と低水準言語、コンパイル型とインタープリタ型、関数型とオブジェクト指向型、そして型システムへの異なるアプローチ）を理解する必要があります。
これらの基礎概念に加えて、アルゴリズムやアルゴリズムの複雑性と解析、並行処理とスレッド、その他プログラミングに関する一般的な概念についても学ぶ必要があります。プログラミングそのもの（例えば、実際に１つの言語を学習すること）は後のカテゴリーであることを忘れないでください。
一部の人々は、このようにコンピュータサイエンスの理論から始めることに異議を唱えるかもしれません。なぜ自動テストのコードを書くためだけに型システムを学ぶ必要があるのでしょうか？
初めに、テスト自動化のプログラミングは、「本当の」プログラミングよりも複雑でない、あるいは厳密さを必要としないという思い込みがあります。これは事実ではなく、Slalom Buildではテスト自動化の開発を「スクリプティング」と呼ぶことを好みません。2つ目は、すべての言語のベースとなる基本的な概念を理解するのではなく、上っ面をざっと読むだけで言語を習得できるという思い込みです。私たちの経験では、このような深い理解を持つ人は、そうでない人よりも新しい言語をより早く習得することができます。例えばJSを何年も使っているにもかかわらずJSのクロージャの概念の理解に苦労しているQAを知っていますが、プログラミング言語理論の基礎を理解している人なら簡単に理解できるでしょう。
品質エンジニアは、ソフトウェアエンジニアの一種です。コンピュータサイエンスとエンジニアリングの基礎がしっかりしていると、その後の学習が加速されます。すぐに役に立たなさそうだからといって、この基礎の重要性を過小評価しないようにしましょう。
Webアプリケーションの基礎
コンピュータサイエンスとインターネットの基礎を学んだので、ウェブアプリケーションについて学ぶ準備ができました。扱うソフトウェアすべてに必ずしもWebインターフェースがあるとは限りませんが、Web技術はとても広く普及しているため、その仕組みを理解することはとても重要です。
必要最低限の理解のレベルにはHTML、CSS、およびJavaScriptのような技術を使ってWebサイトがどのように開発されるかについての知識も含まれます。ブラウザがこれらの言語をどのように扱い、インターフェイスとしてレンダリングしているかを理解する必要があります。Webアプリケーションの基本を理解したら、AJAX、シングルページアプリケーション（SPA）、プログレッシブWebアプリケーション（PWA）などの学習に進むことができます。その後、暗号化、コンテンツ管理システム、クライアントサイド/サーバーサイドレンダリングや、アダプティブ/リアクティブWebアプリケーションのようなより高度なトピックに進むことができます。
0からWebアプリケーションを構築する方法を知る必要はあるでしょうか？答えは NO です。ただ知っておいて損はありません。そして、いくつかの異なるフレームワーク（Angular、Reactなど）で数回実際にアプリケーションを構築することで、プロセスを理解でき、それらをテストするためのより深い洞察が得られるでしょう。加えて、Web技術のトレンドとして、Webアプリケーションの "表面下 "のテストが多くなってきています。例えば、データモデルをモックしてUIの動作をユニットテストとしてテストしたり、ヘッドレスブラウザでテストしたりします。いくつかのシンプルなWebアプリケーションを構築することで、これらの異なるタイプのテストがどのように使用できるかを知ることができ、全体的なテストおよび自動化戦略の指針となるでしょう。
プログラミング
前述のセクションでコンピューターサイエンスの話をしましたが、実際にはプログラミングは含まれていませんでした。私たちは型システムやメモリ、オペレーティングシステムなどについて知っていますが、今度はプログラミング言語を学ぶことによって、その知識を実用的なものにする必要があるのです。
生産性の高いプログラマーになるためには、開発する環境に慣れておく必要があります。つまり、統合開発環境（IDE）とシェルを理解することです。プログラミングをするときは、特定のボタンや設定を見つける方法ではなく、コードについて考えるべきです。
言語だけでなく、コードを整理し、優れたプログラミングの実践に役立つより高度な構成要素（デザインパターン、DRYやSOLIDのような概念など）も学ぶべきです。これらの概念と、それをコードでどのように実現するかは、学習する言語の性質に依存します。すなわち、SOLIDはオブジェクト指向言語に適用され、純粋関数のようなパターンは関数型言語に適用されます。
現在私たちが注目しているプログラミング言語は、JavaScript/TypeScript、JavaまたはC#、Pythonです。JavaScriptはすべてのウェブ開発を支えているため、最初の言語としては最適です。さらにNode.jsのようなフレームワークを通じて、企業の他の領域にも徐々に広がっています。Web開発でよく使用されるため、JavaScriptはProtractor、WebdriverIO、Cypress.ioなどのツールによるWebシステムの自動化でも多用されています。JavaScriptは最も人気のあるプログラミング言語の1つとして常にランクインしています。
TypeScriptはJavaScriptとは根本的に異なる言語ですが、私たちはこの2つをひとくくりにして考えています。TypeScriptはJavaScriptにトランスパイルされるため、周囲のエコシステムの多くは同じであり、JavaScriptと並行してTypeScriptを学ぶことで、静的に強い言語と動的に弱い言語の両方を自分の武器にできるメリットがあります。
JavaScript/TypeScriptの次は、JavaかC#をお勧めします。これらの言語は非常に似ており、どちらもエンタープライズ・アプリケーション開発で広く使われています。C#はややリスクが高く、C#を活用する企業は.NET / Microsoftのエコシステムにどっぷり浸かっている傾向があるため、それ以外の言語にはあまり触れられないかもしれません。JavaとC#は新しく興味をそそる言語ではありませんが、いまだにソフトウェア業界の主力言語です。
（新しくはありませんが）興味をそそる言語といえば、Pythonです。Pythonは技術的には90年代初頭から存在していますが、データ分析アプリケーション、特にAI/MLでの使用により、最近復活を遂げています。もちろん、Pythonはパワフルでアクセスしやすい言語でもあります。
プログラミングの学習について語るときに、ひとつだけ注意すべきことがあります。それは、プログラミングはとても簡単に学び始められますが、マスターするのは非常に難しい、ということです。そのため、学習の旅を始めたときや、より進んでいる人たちと関わるときに混乱や衝突が生じることがあります。「Pythonを学んだのに、誰も雇ってくれない。不公平だ！」というようなことを耳にすることもあります。
プログラミングをチェスの勉強に例えて考えてみましょう。私たちのほとんどは、半日でゲームのルールを100％完全に暗記できるでしょう。それで必ずグランドマスターになれるでしょうか？そんなことはありません。同じように、新しいプログラミング言語のルールを数週間で学ぶことはできますが、それを持ってマスターと名乗る資格が与えられるわけではありませんし、重要なアプリケーション開発の職務に就けるような準備ができていることも意味しません。最初の2週間ですべてのルールを学ぶことはできますが、チェスと同じように、残りの人生をかけてそれをマスターしようと努力し続けることになります。
品質保証の業界には、品質のプロフェッショナルにプログラミングのスキルは必要ないと言う人がいます。私たちはそうは思いません。プログラミングを学び、継続的に向上させることは、品質エンジニアのコアコンピテンシーであり、複雑な自動テストシステムを書き始めるときや、テスト対象のソフトウェアを構築している開発者と共同作業するときに幅広く活用できると考えています。
エンタープライズ・アーキテクチャ
エンタープライズ・アプリケーションには、数え切れないほどの種類、サイズ、構成があります。これらのシステムがどのように機能し、どのように壊れるかを理解するためには、エンタープライズ・アーキテクチャの基本を理解する必要があります。
これは幅広いカテゴリーですが、3層アプリケーション、RESTサービス、マイクロサービスアーキテクチャ、ストリーミングおよびイベント駆動型アーキテクチャ、永続化戦略（リレーショナル vs オブジェクトストアなど）、レプリケーション、キャッシュ、プロキシなどのトピックが含まれます。このセクションのトピックのほとんどは独立しており、どの順番でも学ぶことができます。
エンタープライズシステムがどのように構成されているかを理解することに加えて、それらがどのような基盤の上に構築されているかも理解する必要があります。これは、IaaS、PaaS、SaaSのオプションや、AWS、GCP、Azureなどの主要プロバイダーのクラウド・オファリングを深く理解することを意味します。クラウド技術はモダンアーキテクチャにおいて広く普及しているため、これらのトピックの重要性はいくら強調しても足りません。すべての主要なクラウド・プロバイダーは豊富な学習リソースを提供していますし、この需要を満たすためにサードパーティの学習リソース（無料と有料の両方）も増えてきています。
エンタープライズアーキテクチャは広大な知識分野であるため、興味のある、または自分の目標に関連する特定の分野に焦点を当てることが重要です。これらのトピックの中には、多くの種類のアーキテクチャに広く適用できるもの（永続化戦略など）もあれば、一部の状況や役割にしか適用できないもの（イベントストリーミングなど）もあります。しかし、品質エンジニアとして成功したいのであれば、テストするシステムやそれらがどのように組み合わされているかを理解することは重要です。品質エンジニアへの期待は、ブラックボックステストや内部の動作の限られた理解で十分だったテスターへの期待をはるかに超えた高いものになっています。
テスト自動化の基礎
ついにテスト自動化です！ユニットテスト、APIテストなど、自動テストには多くの種類があり、品質エンジニアはそれらすべての専門知識を持つ必要があります。しかし、特定の種類の自動テストに深く踏み込む前に、テスト自動化を理論的な概念として見ていく必要があります。
テスト自動化を価値あるものにするためには、なぜそれを書くのかを理解する必要があります。テスト自動化を投資として捉え、テストピラミッドのような概念で説明できること、そしてテストデータがテストオラクル、テストサーフェス、テストデータなどに依存していることを理解する必要があります。
また、ローコードまたはノーコードによる自動化がどのように関わってくるか、レコード＆プレイバックツールの利点と欠点、そしてGherkinのようなBDD言語がどのように使用されるかを理解する必要があります。
ユニット、API、UIテスト自動化の詳細については後で詳しく説明しますが、テストピラミッドや投資としてのテスト自動化に関連して、それぞれの種類のテストがどういったものであるか、またそれぞれの利点と欠点を理解することは必要です。
具体的な自動化ツールに深く踏み込む必要はまだありませんが、ツールのカテゴリと各カテゴリの一般的な例を知っておくことは有用です。例えば、テスト対象のシステムを分離するためにサービスのモックやスプーフィングを行うことは、多くの自動化戦略において重要な課題であるため、WireMockやMontebankといったツールがどのようにこの課題解決をサポートしてくれるかを知ることは役に立ちます。
テスト自動化は継続的に進化している分野であり、この分野には強い意見や時には意見の相違が存在します。このような場合には、最も馴染みのあるものだけでなく双方の意見を知ることが、他の情報不足の品質エンジニアとの差を生み出す鍵になります。
モダンアジャイルデリバリー
様々なタイプのテスト自動化について深く掘り下げる前に、技術的ではありませんが、それでも非常に重要な領域について少し触れる必要があります。前の章で SDLC の基礎について見てきましたが、今度はアジャイルデリバリーについて掘り下げて見ていきましょう。
アジャイル開発チームで効果的に活動するためには、アジャイルの理論だけでなく、戦術や実践的な面もよく知っている必要があります。そして、これらを学ぶ最善の方法は、実際にアジャイルデリバリーチームで経験することですが、事前にある程度の理解を深めておいて損をすることはありません。
各企業が異なるアジャイル手法を採用しています（最もよく聞く不満は「それは本当のアジャイルではない！」というものです。）。その中でも、品質エンジニアとして知っておくべき一般的なアプローチ、セレモニー、用語は存在します。それには、ストーリーの定義、受け入れ基準の定義、ストーリーの見積もり手法のようなものから、スタンドアップ、レトロスペクティブ、ショーケースのような一般的なイベントの目的なども含まれます。
さらに、よく使用されるアジャイルプロジェクト管理ツールに精通していることにも価値があります。最も一般的なのはJiraですが、RallyやMS Projectなども使われます。さらに、Scaled Agile (SAFe)、LeSS、Nexusのようなエンタープライズ企業におけるアジャイルの適用にも精通しているとより良いでしょう。
アジャイルチームがどのように動いているかを知り、うまくいっているときとそうでないときを識別できるようになることは、品質エンジニアにとって非常に重要です。こういった課題が後々ソフトウェア品質の問題の根本的な原因となることが多くあります。
品質エンジニアリングの役割
品質エンジニアとは一体何をする人なのでしょうか？この役割はどこで終わり、ソフトウェアエンジニアの役割はどこから始まるのでしょうか？品質エンジニアは、アジャイル開発チームの他の役割と、いつ、どのようにコラボレーションするのでしょうか？アジャイル開発を始める前に、これらの質問に対する明確な答えを持っていることはとても重要です。
残念ながら、これらの質問に対する答えは、会社によって異なるだけでなく、チームによっても異なります。各チームや企業のスキルセット、ドメイン、期待値、計画、文化が、品質エンジニアの仕事に影響を与えるため、このカテゴリはより抽象的かつ理論的にならざるを得ません。いずれにしろ、自分の役割を知ることは成功する上で非常に重要です。
あなたの会社がどのように運営されているかに関わらず、異なるモデルのテクノロジー企業がどのように問題にアプローチしているかを幅広く理解することは価値があるでしょう。例えば、How Google Tests Software (翻訳書: テストから見えてくる グーグルのソフトウェア開発)、MicrosoftのCombined Engineering Approach、AtlassianのQuality Assistance、Spotify Model、そして手前味噌ですが、特にSlalom Buildの品質エンジニアリング基本原則を読んでみてください。
単体テスト
単体テストは通常ソフトウェアエンジニアが行いますが、品質エンジニアも同様に深い専門知識を持つべきです。品質エンジニアは、ツールやフレームワークを熟知し、特定の言語やアプリケーションの欠点や落とし穴を知り、単体テストのカバレッジが他の自動化の上位レイヤーをどのように補強し、サポートするかを正確に知っていなければなりません。品質エンジニアは、単体テストのコードレビュー、あるいはテスト自体の実装を問題なく行えるべきです。
ソフトウェアエンジニアが主に担当するテストにおいて、品質エンジニアに求められる専門知識のレベルに驚くかもしれません。しかし、この理解は前述のセクションで概説した役割と期待を考えると不可欠です。品質エンジニアは単なるテスターやテストの自動化担当者ではなく、アプリケーションの品質全体を包括的に考え、品質に影響を与える可能性のあるすべての要素を理解する必要があります。単体テストは開発チームにとって大きく重要なフィードバックループを構成しており、品質エンジニアはソフトウェアエンジニアや DevOps エンジニアと協力して、これらのテストの健全性を実装およびメンテナンスできる必要があります。
単体テストにおいて、TDD（テスト駆動開発）を理解し、それを活用して単体テストを問題なく実装できるべきです。また、関数型言語とオブジェクト指向言語における単体テストの違いや、単体テストを簡単にするパターンを理解する必要があります。多くの単体テストフレームワークは類似した機能をサポートしていますが、違いもあります。ですので、読者が使用している言語で複数のフレームワークを学習することには価値があります。
この章ではユニットテストに焦点を当てましたが、自動化の専門家であれば、すべての自動テストが必ずしもきれいなレイヤーに収まるわけではなく、分離された小規模なテストから大規模で広範なテストまでの連続体として考えるべきであることを知っていると思います。これらのテストがどのように組み合わされるかを知ることは、全体最適な自動化戦略を考えるために重要であり、品質エンジニアがそれらのテストを実装する人でなかったとしても、すべてのタイプのテストについて深い知識と理解を持たなければならないもう一つの理由です。
API テストの自動化
API テストの自動化は、複雑高度なソフトウェアシステムにとって不可欠なフィードバックループの一種であり、すべての品質エンジニアが深く理解する必要があります。 API を構成する要素に関して人によって範囲や対象が多少異なることがありますが、通常はREST サービス、Web サービス、SOAP サービス、ストリーミング アーキテクチャ内のトピックとキュー、ファイル インターフェース、場合によっては低レベルのバイナリプロトコルを扱うこともあります。
その名の通り、APIはコンピュータによって利用されることを前提に作られているため、テスト自動化のための優れたテスト対象になります。単体テストやE2E/UIテストにはそれぞれ制限があるため、品質エンジニアにはAPIの自動テストを構築、実行、デバッグ、そしてメンテナンスする能力が求められます。
APIテストの自動化に加えて、PostmanのようにアドホックなAPIテストをサポートするツールにも価値があります。一般的なAPI自動テスト開発ワークフローでは、プログラミング言語で実際のテストを作成しながら、Postmanのようなツールを使ってAPIの詳細な調査をすることが重要な部分を占めます。
RestAssured や Karate のような一般的フレームワークを紹介しましたが、API テストは テストランナー (JUnit など)、サービスとインターフェースで接続するためのライブラリ (HttpClient など)、アサーションライブラリ (Hamcrest など) さえあれば実現できます。 これらはどのプログラミング言語でも基本的なライブラリとして用意されています。
チームによっては、単体テストと同様に API テストの責任は開発者が負う場合もあります。しかし、いずれにしても、API自動テストの構築、拡張、デバッグ、実行に慣れ親しみ、高いスキルを持つことが求められます。
Web UI テスト自動化
テスト自動化というと、残念ながら多くの人が UIテスト自動化を思い浮かべます。UI テストはテストピラミッドの中では 1 つのレイヤーに過ぎず、しかもその中でも最も小さい部分ではありますが、それでも自動化戦略全体においては重要な役割を果たします。
もしもテスト対象のアプリケーションに UI がある場合 (ほとんどのアプリケーションには存在します)、UI テストを自動化することが、本当の意味でのエンドツーエンド テストを作成する唯一の方法です。そして、エンドユーザーの体験を最も近い形で再現できるのが、このエンドツーエンド テストです。
残念なことに、UIテスト自動化は最も難しいテスト自動化の 1 つでもあります。API はアプリケーションから利用されることを前提に作られていますが、UI は人間のために作られています。自動テストのようなアプリケーションに、本来は人間向けに作られたものを操作させることは、丸い杭を四角い穴に打ち込むようなものです。このような課題に対処するため、膨大な数のツール、フレームワーク、自動化アプリケーションが開発されてきました。
その中でも最も普及しているのが、Seleniumとそのラッパーや派生系 (WebDriver.io、Protractor、Appiumなど) です。全てを習得するのは現実的ではなく、代わりに Selenium が何をしているのか、そしてウェブブラウザを操作するという課題にどのように取り組んでいるのかを理解することに努めましょう。Selenium の仕組みと、使用するプログラミング言語をマスターすれば、Selenium をベースにした流行りの UI テスト自動化 フレームワークを習得するのは難しくありません。
Selenium 以外にも、Selenium の基盤にある WebDriver プロトコルを使わずにウェブUIの自動化を実現するフレームワークが存在します。これらのツールは、通常Chrome の DevTools のようなブラウザ独自の API とやり取りし、特定のブラウザに対する UI テスト自動化をより簡単かつ強力なものにすることができますが、いくつかの欠点もあります。 Puppeteerや Playwrightがこのカテゴリに当てはまります。Cypress.io は、Selenium 以外のカテゴリで新しく登場した有望なツールであり、習得する価値があります。繰り返しますが、ツール自体よりもWeb UIの自動化の仕組みを理解することが重要であり、Web アーキテクチャとプログラミングの基礎を身につければ、新しいツールをすぐに習得できるようになるでしょう。
Selenium や「Selenium 以外」の UI テスト自動化に加えて、商用でプロプライエタリな自動化ツールも数多く存在します。これらは一般的に、技術にあまり精通していないユーザーを対象に販売されており、シンプルなテスト自動化をするのには便利な場合があります。コード中心のアプローチと比較して商用ツールが果たす役割を理解するために重要なのは、このようなツールをいつ使うべきでいつ使うべきでないのかを理解し、過剰な宣伝文句 (「AI を使って無料で全てを自動化！」など)を見抜けるようになることです。
継続的インテグレーション/デプロイメント (CI/CD)
テスト自動化の真価は、すべてのシステム変更に対して迅速かつストレートにフィードバックを返すことにあります (中には「これこそが唯一の価値」と言う人もいます)。つまり、自動テストを継続的インテグレーション (CI) と継続的デリバリー/デプロイメント (CD) パイプラインに組み込むことが重要です。リポジトリに置いてあり、誰かがクリックしたときにだけ実行されるテストは、すぐに古くなり、捨てられてしまいます。品質エンジニアとして、CI/CD の概念を理解し、関連するツールに習熟し、DevOps エンジニアやソフトウェアエンジニアと協力して、全員にとって価値のあるテスト自動化アプローチを実装できるようになる必要があります。
品質エンジニアが実装にどれくらい関わるかはチームによって異なりますが、経験上、品質エンジニアが直接パイプラインインフラの構築に関わることも珍しくありません。具体的には、Jenkins パイプラインやCloud Formation スクリプトを書くことや、チームが利用している様々なテクノロジーの活用などが含まれます。使用されるテクノロジーに関係なく、品質エンジニアは気おくれすることなく、CI/CD 活動全体をサポートできるように準備をしておくべきです。
CI/CD 戦略は必然的にテスト環境戦略と重なる部分があります。これも品質エンジニアが習熟しておくべき領域です。ゲートチェックとは何か、共有環境はいつ使うべきか、テスト環境とテストデータ管理の依存関係は何か？品質エンジニアはこれらの質問に加えてさらに多くの質問にも答える準備ができていなければなりません。
パフォーマンステスト
アプリケーションが動作していても、遅すぎて使い物にならなかったり、負荷がかかったときにタイムアウトが発生したりしては意味がありません。パフォーマンス テストは、ソフトウェアがパフォーマンスの期待値を満たしていることを保証するものであり、品質エンジニアにとって重要な専門分野です。
パフォーマンス テストは奥が深く広範なトピックであり、パフォーマンス テストだけに特化した専門家も存在しますが、品質エンジニアとしては、パフォーマンス テストの種類や名称、それらを支援するツール、そしてこれらのテストを CI/CD パイプラインやアジャイルプロセスに統合する方法 を理解しておく必要があります。
スタンドアロンのパフォーマンステストツールとして絶対的な地位を確立しているのは Apache JMeter ですが、コードベースと GUI ベースの両方を含む幅広い種類のツールがあります。他のテスト自動化分野と同様に、自分が最も興味を持っている技術スタックに合ったツールを学ぶことをお勧めします。
モバイルテスト
モバイルでのインターネット利用率がデスクトップの利用率を超えたため、モバイルインターフェースのテストはWebインターフェースのテストと同じくらい重要になってきています。「モバイル」カテゴリ内では、ネイティブアプリ、ハイブリッドアプリ、モバイルウェブインターフェースのテストにおける違いを理解する必要があります。さらに、ネイティブアプリの中でも、当然ながらAndroid と iOS プラットフォームには違いがあるため、その両方をどのようにテストするかを知る必要があります。
モバイルアプリケーションの自動化には独自の課題があり、それらを克服するためのさまざまなツールやフレームワークが使われています。Android には Espresso 、iOS には XCUITest のようにプラットフォーム固有のツールもありますが、Appiumのようにクロスプラットフォームのツールもあります。Web UIテスト自動化と同様に、GUIツールではなく、コードファーストの思想を持つツールの学習をお勧めします。
モバイルテストの自動化に加えて、膨大な種類のデバイスとOSバージョンを対象としたテストを迅速化するために、オンプレミスとクラウドの両方で利用できる デバイス ファーム の仕組みを理解しておくことが求められます。また、物理デバイスを使わずにテストのフィードバックを得るための エミュレータとシミュレータ の活用法、モバイルアプリケーションの配布とリリースが他の種類のソフトウェアとどう異なるのか、そしてモバイルアプリケーション特有のテスト領域 (通常のウェブベースのソフトウェア テストには見られない領域) についても理解が必要です。
アクセシビリティテスト
他のすべての商業サービスと同様に、ソフトウェアも視覚、聴覚、その他障害のある方にとってアクセス可能でなければなりません。品質エンジニアとしては、アクセシビリティ要件とそれを検証するために使用される手法やツールを理解しておく必要があります。
米国において、アクセシビリティは政府の「508 Accessibility Standards」という規格と W3C コンソーシアムが定める「Web Content Accessibility Guidelines (WCAG)」によって定義されています。Webやモバイルインターフェースに関わるのであれば、これらの規格と、適合性を評価するために使用される数多くのスキャニングツールを理解することが重要です。
セキュリティテスト
ソフトウェアのセキュリティはソフトウェアシステム全体の品質にとって非常に重要ですが、なぜこのトピックは学習ロードマップの比較的後の方に出てくるのでしょうか。 セキュリティの重要性とセキュリティテストの大部分が高度な技術を必要とすることから、業界ではネットワークセキュリティ、プロトコルセキュリティ、エンタープライズセキュリティなど、専門的なセキュリティの役割が生まれました。 新しい品質エンジニアとして、おそらくこれらの分野に直接関わることはないでしょう。 しかし、ソフトウェアの構築プロセス自体をどのようにセキュアにするかなど、セキュリティの基本を理解しておくことは依然として重要です。
これには、認証と認可がどのようにアクセス制限に使用されるか、最小権限の原則、暗号化の仕組み (例：公開鍵暗号) 、そしてOWASP Top 10 の理解などが含まれます。 攻撃ベクトルや攻撃対象領域などのセキュリティ用語、スキャナーを使用して脆弱性を特定する方法やペネトレーションテストの基本を理解しておく必要があります。 ソフトウェアセキュリティに特化したキャリアに進まないのであれば、これらのトピックがカバーできていれば品質エンジニアとして働き始めるには十分でしょう。
ボーナストピック ： AI/MLのテストとデータエンジニアリング
AI/ML のテストとデータエンジニアリングはどちらもソフトウェア開発におけるホットトピックですが、このロードマップからは除外することにしました。理由は、1) ロードマップがすでにとても長くなってしまっていること、2)就く職務や会社によっては適用できない専門分野である可能性があるためです。しかし、この分野に興味がある場合、エンタープライズアーキテクチャや自動化の基本など、これまでのセクションで培った基礎知識を生かして、AI/ML やデータエンジニアリングの テストをあなたのテストの道具箱に追加することはそう難しいことではありません。
まとめ
この学習ロードマップの範囲の広さに圧倒されたかもしれません。18のセクションにわたって144ものトピックがあり、その中には非常に深い内容のものもあります。学習が好きで、技術に触れることを楽しむことができ、複雑な問題を解決するのが好きであれば、このロードマップの幅広さは品質エンジニアとしてのキャリアがあなたにとってやりがいのあるものになるというサインです。これらのトピックをマスターすることで、組織に提供できる価値は計り知れません。
もしあなたが品質の分野にすでに携わっていて、我々が見落としたたと思う領域/分野/テクノロジーがあれば、コメント欄でお気軽にお知らせください。このロードマップの作成には多大な時間と労力を費やしましたが、見落としはあるはずです。これから品質エンジニアのキャリアをスタートする方へ：ようこそ！そして、学びの旅での幸運を祈ります。
フィードバックをくれたKelsey Davis、Snehal Lohar、Lindsey Driscoll、Jason Hill、Jason Varland、Nader Hatamiに感謝を送ります。
この記事が気に入ったらサポートをしてみませんか？