diff --git a/docs_source_files/content/introduction/about_this_documentation.ja.md b/docs_source_files/content/introduction/about_this_documentation.ja.md
index 4fcc3f79c389..f8b6d92e527c 100644
--- a/docs_source_files/content/introduction/about_this_documentation.ja.md
+++ b/docs_source_files/content/introduction/about_this_documentation.ja.md
@@ -1,31 +1,17 @@
 ---
-title: "About this documentation"
+title: "このドキュメントについて"
 weight: 4
 ---
 
-{{% notice info %}}
-<i class="fas fa-language"></i> ページは英語から日本語へ訳されています。
-日本語は話せますか？プルリクエストをして翻訳を手伝ってください!
-{{% /notice %}}
 
-These docs, like the code itself, are maintained 100% by volunteers
-within the Selenium community.
-Many have been using it since its inception,
-but many more have only been using it for a short while,
-and have given their time to help improve the onboarding experience
-for new users.
+これらのドキュメントは、コード自体と同様に、Seleniumコミュニティ内のボランティアによって100％維持されます。
+当初から多くの人が使用してきましたが、多くの人が短期間しか使用しておらず、新しいユーザーのオンボーディングエクスペリエンスの改善に時間を割いてきました。
 
-If there is an issue with the documentation, we want to know!
-The best way to communicate an issue is to visit
-[https://github.com/seleniumhq/seleniumhq.github.io/issues](//github.com/seleniumhq/seleniumhq.github.io/issues)
-and search to see whether or not the issue has been filed already.
-If not, feel free to open one!
+ドキュメントに問題がある場合、知りたいです！
+問題を伝える最良の方法は、[https://github.com/seleniumhq/seleniumhq.github.io/issues](//github.com/seleniumhq/seleniumhq.github.io/issues)にアクセスし、問題が既に報告されているかどうかを検索することです。
+そうでない場合は、自由に開いてください！
 
-Many members of the community frequent
-the _#selenium_ IRC channel at [irc.freenode.net](//freenode.net/).
-Feel free to drop in and ask questions
-and if you get help which you think could be of use within these documents,
-be sure to add your contribution!
-We can update these documents,
-but it's much easier for everyone when we get contributions
-from outside the normal committers.
+コミュニティの多くのメンバーは、[irc.freenode.net](//freenode.net/)で _#selenium_ IRCチャンネルに頻繁にアクセスします。
+気軽に立ち寄って質問してください。
+これらのドキュメントで役立つと思われるヘルプを受け取った場合は、必ず貢献を追加してください。
+これらのドキュメントを更新することはできますが、通常のコミッター以外から投稿を受け取ると、誰にとってもずっと簡単になります。
diff --git a/docs_source_files/content/introduction/on_test_automation.ja.md b/docs_source_files/content/introduction/on_test_automation.ja.md
index 104f2cb4c910..48f05b37ac79 100644
--- a/docs_source_files/content/introduction/on_test_automation.ja.md
+++ b/docs_source_files/content/introduction/on_test_automation.ja.md
@@ -1,130 +1,87 @@
 ---
-title: "On test automation"
+title: "テスト自動化について"
 weight: 2
 ---
 
-{{% notice info %}}
-<i class="fas fa-language"></i> ページは英語から日本語へ訳されています。
-日本語は話せますか？プルリクエストをして翻訳を手伝ってください!
-{{% /notice %}}
 
-First, start by asking yourself whether or not you really need to use a browser.
-Odds are that, at some point, if you are working on a complex web application,
-you will need to open a browser and actually test it.
-
-Functional end-user tests such as Selenium tests are expensive to run, however.
-Furthermore, they typically require substantial infrastructure
-to be in place to be run effectively.
-It is a good rule to always ask yourself if what you want to test
-can be done using more lightweight test approaches such as unit tests
-or with a lower-level approach.
-
-Once you have made the determination that you are in the web browser testing business,
-and you have your Selenium environment ready to begin writing tests,
-you will generally perform some combination of three steps:
-
-* Set up the data
-* Perform a discrete set of actions
-* Evaluate the results
-
-You will want to keep these steps as short as possible;
-one or two operations should be enough most of the time.
-Browser automation has the reputation of being “flaky”,
-but in reality, that is because users frequently demand too much of it.
-In later chapters, we will return to techniques you can use
-to mitigate apparent intermittent problems in tests,
-in particular on how to [overcome race conditions]({{< ref "/webdriver/waits.ja.md" >}})
-between the browser and WebDriver.
-
-By keeping your tests short
-and using the web browser only when you have absolutely no alternative,
-you can have many tests with minimal flake.
-
-A distinct advantage of Selenium tests
-is their inherent ability to test all components of the application,
-from backend to frontend, from a user's perspective.
-So in other words, whilst functional tests may be expensive to run,
-they also encompass large business-critical portions at one time.
-
-
-### Testing requirements
-
-As mentioned before, Selenium tests can be expensive to run.
-To what extent depends on the browser you are running the tests against,
-but historically browsers' behaviour has varied so much that it has often
-been a stated goal to cross-test against multiple browsers.
-
-Selenium allows you to run the same instructions against multiple browsers
-on multiple operating systems,
-but the enumeration of all the possible browsers,
-their different versions, and the many operating systems they run on
-will quickly become a non-trivial undertaking.
-
-
-### Let’s start with an example
-
-Larry has written a web site which allows users to order their 
-custom unicorns.
-
-The general workflow (what we will call the “happy path”) is something
-like this:
-
-* Create an account
-* Configure the unicorn
-* Add it to the shopping cart
-* Check out and pay
-* Give feedback about the unicorn
-
-
-It would be tempting to write one grand Selenium script
-to perform all these operations–many will try.
-**Resist the temptation!**
-Doing so will result in a test that 
-a) takes a long time,
-b) will be subject to some common issues around page rendering timing issues, and
-c) is such that if it fails, 
-it will not give you a concise, “glanceable” method for diagnosing what went wrong.
-
-The preferred strategy for testing this scenario would be
-to break it down to a series of independent, speedy tests,
-each of which has one “reason” to exist.
-
-Let us pretend you want to test the second step:
-Configuring your unicorn.
-It will perform the following actions:
-
-* Create an account
-* Configure a unicorn
-
-Note that we are skipping the rest of these steps, 
-we will test the rest of the workflow in other small, discrete test cases 
-after we are done with this one.
-
-To start, you need to create an account.
-Here you have some choices to make:
-
-* Do you want to use an existing account?
-* Do you want to create a new account?
-* Are there any special properties of such a user that need to be
-  taken into account before configuration begins?
-
-Regardless of how you answer this question,
-the solution is to make it part of the "set up the data" portion of the test.
-If Larry has exposed an API that enables you (or anyone)
-to create and update user accounts,
-be sure to use that to answer this question.
-If possible, you want to launch the browser only after you have a user "in hand",
-whose credentials you can just log in with.
-
-If each test for each workflow begins with the creation of a user account,
-many seconds will be added to the execution of each test.
-Calling an API and talking to a database are quick,
-“headless” operations that don't require the expensive process of
-opening a browser, navigating to the right pages,
-clicking and waiting for the forms to be submitted, etc.
-
-Ideally, you can address this set-up phase in one line of code,
-which will execute before any browser is launched:
+まず、本当にブラウザを使用する必要があるかどうかを自問することから始めます。
+ある時点で複雑なWebアプリケーションで作業している場合、おそらくブラウザを開いて実際にテストする必要があるでしょう。
+
+ただし、Seleniumテストなどの機能的なエンドユーザーテストの実行には費用がかかります。
+さらに、それらは通常、効果的に実行するために適切なインフラストラクチャを配置する必要があります。
+単体テストなどのより軽量なテストアプローチを使用して、または下位レベルのアプローチを使用して、テストすることを実行できるかどうかを常に自問するのは良いルールです。
+
+Webブラウザーのテストビジネスに参加していることを確認し、Selenium環境でテストの記述を開始できるようになったら、通常は3つのステップを組み合わせて実行します。
+
+* データを設定する
+* 個別の一連のアクションを実行する
+* 結果を評価する
+
+これらの手順はできるだけ短くしてください。
+ほとんどの場合、1つまたは2つの操作で十分です。
+ブラウザの自動化は"不安定"であるという評判がありますが、実際には、ユーザーが頻繁に多くを求めることが多いためです。
+後の章では、特にブラウザーとWebDriver間の[競合状態を克服する]({{< ref "/webdriver/waits.ja.md" >}})方法に関する、テストでの断続的な問題を軽減するために使用できる手法に戻ります。
+
+テストを短くして、代替手段がまったくない場合にのみWebブラウザーを使用することで、不安定さを最小限にして多くのテストを実行できます。
+
+Seleniumテストの明確な利点は、ユーザーの観点から、バックエンドからフロントエンドまで、アプリケーションのすべてのコンポーネントをテストする固有の機能です。
+つまり、機能テストは実行に費用がかかる可能性がありますが、同時にビジネスに不可欠な大規模な部分も含まれます。
+
+### テスト要件
+
+前述のように、Seleniumテストの実行には費用がかかる場合があります。
+どの程度までテストを実行しているブラウザーに依存しますが、歴史的にブラウザーの動作は非常に多様であるため、多くの場合、複数のブラウザーに対するクロステストの目標として述べられてきました。
+
+Seleniumを使用すると、複数のオペレーティングシステム上の複数のブラウザーに対して同じ命令を実行できますが、すべての可能なブラウザー、それらの異なるバージョン、およびそれらが実行される多くのオペレーティングシステムの列挙はすぐに重要な作業になります。
+
+### 例から始めましょう
+
+ラリーは、ユーザーがカスタムユニコーンを注文できるWebサイトを作成しました。
+
+一般的なワークフロー（"ハッピーパス"と呼ぶ）は次のようなものです。
+
+* アカウントを作成する
+* ユニコーンを設定する
+* ショッピングカートにユニコーンを追加します
+* チェックアウトしてお支払い
+* ユニコーンについてフィードバックを送る
+
+これらのすべての操作を実行するために1つの壮大なSeleniumスクリプトを作成するのは魅力的です。
+**その誘惑に抵抗しましょう！** そうすると、  
+a）時間がかかる  
+b）ページレンダリングのタイミングの問題に関する一般的な問題が発生する  
+c）失敗した場合、簡潔で"一目瞭然"にならない、何がうまくいかなかったかを診断する方法がない  
+というテストになります。  
+
+このシナリオをテストするための好ましい戦略は、一連の独立した迅速なテストに分割することです。
+各テストには、1つの"理由"が存在します。
+
+2番目のステップであるユニコーンの構成をテストしたいと思います。
+次のアクションを実行します。
+
+* アカウントを作成する
+* ユニコーンを設定する
+
+これらの手順の残りをスキップしていることに注意してください。
+この手順を完了した後、他の小さな個別のテストケースで残りのワークフローをテストします。
+
+開始するには、アカウントを作成する必要があります。
+ここには、いくつかの選択があります。
+
+* 既存のアカウントを使用しますか？
+* 新しいアカウントを作成しますか？
+* 設定を開始する前に考慮する必要があるそのようなユーザーの特別なプロパティはありますか？
+
+
+この質問への回答方法に関係なく、テストの"データのセットアップ"部分の一部にすると解決します。
+ラリーが、ユーザー（またはだれでも）がユーザーアカウントを作成および更新できるAPIを公開している場合は、それを使用してこの質問に回答してください。
+可能であれば、資格情報を使用してログインできるユーザーが"手元に"いる場合にのみブラウザを起動します。
+
+各ワークフローの各テストがユーザーアカウントの作成から始まる場合、各テストの実行に何秒も追加されます。
+APIの呼び出しとデータベースとの対話は、ブラウザを開いたり、適切なページに移動したり、フォームをクリックして送信されるのを待つなどの高価なプロセスを必要としない、迅速な"ヘッドレス"操作です。
+
+理想的には、1行のコードでこのセットアップフェーズに対処できます。
+これは、ブラウザーが起動する前に実行されます。
 
 {{< code-tab >}}
   {{< code-panel language="java" >}}
@@ -213,36 +170,26 @@ val accountPage = loginAs(user.getEmail(), user.getPassword())
   {{< / code-panel >}}
 {{< / code-tab >}}
 
-As you can imagine, the `UserFactory` can be extended
-to provide methods such as `createAdminUser()`, and `createUserWithPayment()`.
-The point is, these two lines of code do not distract you from the ultimate purpose of this test:
-configuring a unicorn.
-
-The intricacies of the [Page Object model]({{< ref "/guidelines_and_recommendations/page_object_models.ja.md" >}})
-will be discussed in later chapters, but we will introduce the concept here:
-
-Your tests should be composed of actions,
-performed from the user's point of view,
-within the context of pages in the site.
-These pages are stored as objects,
-which will contain specific information about how the web page is composed
-and how actions are performed–
-very little of which should concern you as a tester.
-
-What kind of unicorn do you want?
-You might want pink, but not necessarily.
-Purple has been quite popular lately.
-Does she need sunglasses? Star tattoos?
-These choices, while difficult, are your primary concern as a tester–
-you need to ensure that your order fulfillment center
-sends out the right unicorn to the right person,
-and that starts with these choices.
-
-Notice that nowhere in that paragraph do we talk about buttons,
-fields, drop-downs, radio buttons, or web forms.
-**Neither should your tests!**
-You want to write your code like the user trying to solve their problem.
-Here is one way of doing this (continuing from the previous example):
+ご想像のとおり、 `UserFactory` を拡張して `createAdminUser()` や `createUserWithPayment()` などのメソッドを提供できます。
+重要なのは、これらの2行のコードは、このテストの最終目的であるユニコーンの構成からあなたをそらすものではないということです。
+
+[ページオブジェクトモデル]({{< ref "/guidelines_and_recommendations/page_object_models.ja.md" >}})の込み入った事柄については、後の章で説明しますが、ここで概念を紹介します。
+
+テストは、サイトのページのコンテキスト内で、ユーザーの観点から実行されるアクションで構成される必要があります。
+これらのページはオブジェクトとして保存され、Webページがどのように構成され、アクションがどのように実行されるかに関する特定の情報が含まれます。
+
+どんなユニコーンが欲しいですか？
+ピンクが必要かもしれませんが、必ずしもそうではありません。
+紫は最近非常に人気があります。
+彼女はサングラスが必要ですか？
+スタータトゥー？
+これらの選択は困難ですが、テスターとしての最大の関心事です。
+発送センターが適切なユニコーンを適切な人に送信することを確認する必要があります。
+
+この段落では、ボタン、フィールド、ドロップダウン、ラジオボタン、またはWebフォームについては説明していません。
+**また、テストするべきではありません！** 
+ユーザーが問題を解決しようとしているようにコードを書きたいと思います。
+これを実行する1つの方法を次に示します（前の例から継続）
 
 {{< code-tab >}}
   {{< code-panel language="java" >}}
@@ -346,8 +293,7 @@ unicornConfirmationPage = addUnicornPage.createUnicorn(sparkles)
   {{< / code-panel >}}
 {{< / code-tab >}}
 
-Now that you have configured your unicorn,
-you need to move on to step 3: making sure it actually worked.
+ユニコーンの設定が完了したら、ステップ3に進んで、ユニコーンが実際に機能することを確認する必要があります。
 
 {{< code-tab >}}
   {{< code-panel language="java" >}}
@@ -389,45 +335,32 @@ assertTrue("Sparkles should have been created, with all attributes intact", unic
   {{< / code-panel >}}
 {{< / code-tab >}}
 
-Note that the tester still has not done anything but talk about unicorns in this code–
-no buttons, no locators, no browser controls.
-This method of _modelling_ the application
-allows you to keep these test-level commands in place and unchanging,
-even if Larry decides next week that he no longer likes Ruby-on-Rails
-and decides to re-implement the entire site
-in the latest Haskell bindings with a Fortran front-end.
-
-Your page objects will require some small maintenance in order to 
-conform to the site redesign,
-but these tests will remain the same.
-Taking this basic design,
-you will want to keep going through your workflows with the fewest browser-facing steps possible.
-Your next workflow will involve adding a unicorn to the shopping cart.
-You will probably want many iterations of this test in order to make sure the cart is keeping its state properly:
-Is there more than one unicorn in the cart before you start?
-How many can fit in the shopping cart?
-If you create more than one with the same name and/or features, will it break?
-Will it only keep the existing one or will it add another?
-
-Each time you move through the workflow,
-you want to try to avoid having to create an account,
-login as the user, and configure the unicorn.
-Ideally, you will be able to create an account
-and pre-configure a unicorn via the API or database.
-Then all you have to do is log in as the user, locate Sparkles,
-and add her to the cart.
-
-
-### To automate or not to automate?
-
-Is automation always advantageous? When should one decide to automate test
-cases?
-
-It is not always advantageous to automate test cases. There are times when
-manual testing may be more appropriate. For instance, if the application’s user
-interface will change considerably in the near future, then any automation
-might need to be rewritten anyway. Also, sometimes there simply is not enough
-time to build test automation. For the short term, manual testing may be more
-effective. If an application has a very tight deadline, there is currently no
-test automation available, and it’s imperative that the testing gets done within
-that time frame, then manual testing is the best solution.
+テスターはまだこのコードでユニコーンについて話しているだけです。
+ボタンもロケーターもブラウザーコントロールもありません。
+ラリーが来週、Ruby-on-Railsが好きではなくなったと判断し、Fortranフロントエンドを使用して最新のHaskellバインディングでサイト全体を再実装することを決めた場合でも、アプリケーションを _モデル化する_ この方法により、これらのテストレベルのコマンドを所定の位置に変えずに維持できます。
+
+ページオブジェクトは、サイトの再設計に準拠するために若干のメンテナンスが必要になりますが、これらのテストは同じままです。
+この基本的な設計を採用することで、可能な限りブラウザに面した最小限の手順でワークフローを進めていきたいと思うでしょう。
+次のワークフローでは、ユニコーンをショッピングカートに追加します。
+カートの状態が適切に維持されていることを確認するために、おそらくこのテストを何度も繰り返す必要があります。
+開始する前に、カートに複数のユニコーンがありますか？
+ショッピングカートには何個収容できますか？
+同じ名前や機能で複数作成すると、壊れますか？
+既存のものを保持するだけですか、それとも別のものを追加しますか？
+
+ワークフローを移動するたびに、アカウントを作成し、ユーザーとしてログインし、ユニコーンを設定する必要を避けたいと考えています。
+理想的には、APIまたはデータベースを介してアカウントを作成し、ユニコーンを事前設定できるようになります。
+その後、ユーザーとしてログインし、きらめきを見つけてカートに追加するだけです。
+
+### 自動化するかしないか
+
+自動化は常に有利ですか？
+テストケースの自動化をいつ決定する必要がありますか？
+
+テストケースを自動化することは必ずしも有利ではありません。
+手動テストがより適切な場合があります。
+たとえば、近い将来にアプリケーションのユーザーインターフェースが大幅に変更される場合は、自動化を書き換える必要があるかもしれません。
+また、テストの自動化を構築する時間が足りない場合もあります。
+短期的には、手動テストの方が効果的です。
+アプリケーションの期限が非常に厳しい場合、現在利用できるテストの自動化はなく、その期間内にテストを実施することが不可欠です。
+手動テストが最適なソリューションです。
diff --git a/docs_source_files/content/introduction/the_selenium_project_and_tools.ja.md b/docs_source_files/content/introduction/the_selenium_project_and_tools.ja.md
index ce1ebd1f0509..c0b4f9b09d5f 100644
--- a/docs_source_files/content/introduction/the_selenium_project_and_tools.ja.md
+++ b/docs_source_files/content/introduction/the_selenium_project_and_tools.ja.md
@@ -1,122 +1,57 @@
 ---
-title: "The Selenium project and tools"
+title: "Seleniumプロジェクトとツール"
 weight: 1
 ---
 
-{{% notice info %}}
-<i class="fas fa-language"></i> ページは英語から日本語へ訳されています。
-日本語は話せますか？プルリクエストをして翻訳を手伝ってください!
-{{% /notice %}}
-
-### Selenium controls web browsers
-
-_Selenium_ is many things 
-but at its core, it is a toolset for web browser automation
-that uses the best techniques available
-to remotely control browser instances
-and emulate a user's interaction with the browser.
-
-It allows users to simulate common activities performed by end-users;
-entering text into fields,
-selecting drop-down values and checking boxes,
-and clicking links in documents.
-It also provides many other controls such as mouse movement,
-arbitrary JavaScript execution, and much more.
-
-Although used primarily for front-end testing of websites,
-Selenium is at its core a browser user agent _library_.
-The interfaces are ubiquitous to their application,
-which encourages composition with other libraries to suit your purpose.
-
-
-### One interface to rule them all
-
-One of the project's guiding principles
-is to support a common interface for all (major) browser technologies.
-Web browsers are incredibly complex, highly engineered applications,
-performing their operations in completely different ways
-but which frequently look the same while doing so.
-Even though the text is rendered in the same fonts,
-the images are displayed in the same place
-and the links take you to the same destination.
-What is happening underneath is as different as night and day.
-Selenium “abstracts” these differences,
-hiding their details and intricacies from the person writing the code.
-This allows you to write several lines of code to perform a complicated workflow,
-but these same lines will execute on Firefox,
-Internet Explorer, Chrome, and all other supported browsers.
-
-
-### Tools and support
-
-Selenium's minimalist design approach gives it the 
-versatility to be included as a component in bigger applications.
-The surrounding infrastructure provided under the Selenium umbrella
-gives you the tools to put together
-your [grid of browsers]({{< ref "/grid/_index.md" >}})
-so tests can be run on different browsers and multiple operating systems
-across a range of machines.
-
-Imagine a bank of computers in your server room or data center
-all firing up browsers at the same time
-hitting your site's links, forms,
-and tables&mdash;testing your application 24 hours a day.
-Through the simple programming interface
-provided for the most common languages,
-these tests will run tirelessly in parallel,
-reporting back to you when errors occur.
-
-It's an aim to help make this a reality for you,
-by providing users with tools and documentation to not only control browsers,
-but to make it easy to scale and deploy such grids.
-
-
-### Who uses Selenium
-
-Many of the most important companies in the world
-have adopted Selenium for their browser-based testing,
-often replacing years-long efforts involving other proprietary tools.
-As it has grown in popularity, so have its requirements and challenges multiplied.
-
-As the web becomes more complicated
-and new technologies are added to websites,
-it's the mission of this project to keep up with them where possible.
-Being an open source project,
-this support is provided through the generous donation of time from many volunteers,
-every one of which has a “day job”.
-
-Another mission of the project is to encourage
-more volunteers to partake in this effort,
-and build a strong community
-so that the project can continue to keep up with emerging technologies
-and remain a dominant platform for functional test automation.
-
-
-### History
-
-When Selenium 1 was released in 2004,
-it was out of the necessity to reduce time spent
-manually verifying consistent behaviour in the front-end of a web application.
-It made use of what tools were available at the time 
-and relied heavily on the injection of JavaScript to the web page under test
-to emulate a user's interaction.
-
-Whilst JavaScript is a good tool to let you introspect the properties of the DOM
-and to do certain client-side observations that you would otherwise not be able to do,
-it falls short on the ability to naturally replicate a user's interactions
-as if the mouse and keyboard are being used.
-
-Since then, Selenium has grown and matured a lot,
-into a tool widely used by many&mdash;if not most&mdash;of
-the largest organisations around the world.
-Selenium has gone from a homebrewed test automation toolkit developed at Thoughtworks
-for a niché audience and a specific use case,
-to the world's _de facto_ browser automation library.
-
-Just as Selenium RC made use of the tools of the trade available at the time,
-[Selenium WebDriver]({{< ref "/webdriver/_index.md" >}}) drives that tradition on by taking
-the browser interaction part to the browser vendor's home turf 
-and asking them to take responsibility of the backend, browser-facing implementations.
-Recently this work has evolved into a W3C standardisation process
-where the goal is to turn the WebDriver component in Selenium
-into the _du jeur_ remote control library for user agents.
+### SeleniumはWebブラウザーを制御します
+
+_Selenium_ はいろいろなものがありますが中核となるのは、ブラウザインスタンスをリモートで制御し、ブラウザとのユーザーの対話をエミュレートするために利用可能な最良の技術を使用するWebブラウザ自動化用のツールセットです。
+
+ユーザーは、エンドユーザーが実行する一般的なアクティビティをシミュレートできます。
+フィールドにテキストを入力し、ドロップダウン値とチェックボックスを選択し、ドキュメント内のリンクをクリックします。
+また、マウスの移動、任意のJavaScriptの実行など、他の多くのコントロールも提供します。
+
+主にWebサイトのフロントエンドテストに使用されますが、Seleniumはブラウザーユーザーエージェント _ライブラリ_ の中核です。
+インターフェイスはアプリケーションに遍在しているため、目的に合わせて他のライブラリとの組み合わせて使うことを奨励します。
+
+### すべてを支配する1つのインターフェース
+
+プロジェクトの指針の1つは、すべての（主要な）ブラウザーテクノロジーに共通インターフェイスをサポートすることです。
+Webブラウザーは非常に複雑で高度に設計されたアプリケーションであり、まったく異なる方法で操作を実行しますが、実行中に同じように見えることがよくあります。
+テキストは同じフォントで表示されますが、画像は同じ場所に表示され、リンクは同じリンク先に移動します。
+下で起こっていることは、昼と夜と同じくらい異なっています。
+Seleniumはこれらの違いを "抽象化" し、コードを書いている人から詳細や複雑さを隠します。
+これにより、数行のコードを記述して複雑なワークフローを実行できますが、これらの同じ行はFirefox、Internet Explorer、Chrome、およびサポートされている他のすべてのブラウザーで実行されます。
+
+### ツールとサポート
+
+Seleniumのミニマリストデザインアプローチは、より大きなアプリケーションのコンポーネントとして含まれる汎用性を提供します。
+Selenium傘下で提供される周囲のインフラストラクチャは、 [ブラウザのグリッド]({{< ref "/grid/_index.ja.md" >}}) をまとめるツールを提供するため、さまざまなマシンで異なるブラウザーおよび複数のオペレーティングシステムでテストを実行できます。
+
+サーバールームまたはデータセンターにある積み重なったのコンピューターがすべてブラウザーを同時に起動してサイトのリンク、フォーム、およびテーブルにアクセスし、アプリケーションを24時間テストすることを想像してください。
+最も一般的な言語用に提供されたシンプルなプログラミングインターフェイスを介して、これらのテストは休むことなく並行して実行され、エラーが発生したときにレポートを返します。
+
+ブラウザを制御するだけでなく、そのようなグリッドを簡単に拡張および展開できるツールとドキュメントをユーザーに提供することで、これを実現することを目指しています。
+
+### 誰がSeleniumを使うか
+
+世界で最も重要な企業の多くは、ブラウザベースのテストにSeleniumを採用しており、多くの場合、他の独自のツールを使用した長年の努力に取って代わりました。
+人気が高まるにつれて、その要件と課題が倍増しています。
+
+ウェブがより複雑になり、新しいテクノロジーがウェブサイトに追加されるにつれて、可能な限りそれらに遅れずについていくことがこのプロジェクトの使命です。
+オープンソースプロジェクトであるこのサポートは、"本業"をもっている多くのボランティアからの寛大な時間の寄付によって提供されます。
+
+プロジェクトのもう1つの使命は、より多くのボランティアがこの取り組みに参加することを奨励し、プロジェクトが引き続き新しいテクノロジーに追いつき、機能テスト自動化の主要なプラットフォームであり続けることができるよう、強力なコミュニティを構築することです。
+
+### 歴史
+
+2004年にSelenium 1がリリースされたとき、Webアプリケーションのフロントエンドで一貫した動作を手動で検証するために費やす時間を削減する必要はありませんでした。
+当時利用可能なツールを利用し、テスト中のWebページへのJavaScriptの注入に大きく依存して、ユーザーのインタラクションをエミュレートしました。
+
+JavaScriptは、DOMのプロパティを内観し、他の方法では実行できない特定のクライアント側の観察を行うことができる優れたツールですが、キーボードが使っているようなマウスとマウスの操作を自然に複製する機能には不十分です。
+
+それ以来、Seleniumは多くの成長と成熟を遂げ、世界中のほとんどの大規模な組織ではなく、多くの人々が広く使用するツールになりました。
+Seleniumは、ニッチな聴衆と特定のユースケースのためにThoughtworksで開発された自作のテスト自動化ツールキットから、世界の _デファクト_ ブラウザ自動化ライブラリになりました。
+
+Selenium RCが当時利用可能な業界のツールを利用したように、[Selenium WebDriver]({{< ref "/webdriver/_index.ja.md" >}})は、ブラウザインタラクションの部分をブラウザベンダーの本拠地に持ち込み、バックエンドのブラウザー対応実装の責任を取るよう依頼することにより、その伝統を推進しています。
+最近、この作業は、SeleniumのWebDriverコンポーネントをユーザーエージェント用の _最新の_ リモートコントロールライブラリにすることを目標とするW3C標準化プロセスに進化しました。
diff --git a/docs_source_files/content/introduction/types_of_testing.ja.md b/docs_source_files/content/introduction/types_of_testing.ja.md
index fdd4eca21ec8..6008ec889494 100644
--- a/docs_source_files/content/introduction/types_of_testing.ja.md
+++ b/docs_source_files/content/introduction/types_of_testing.ja.md
@@ -1,120 +1,78 @@
 ---
-title: "Types of testing"
+title: "テストの種類"
 weight: 3
 ---
 
-{{% notice info %}}
-<i class="fas fa-language"></i> ページは英語から日本語へ訳されています。
-日本語は話せますか？プルリクエストをして翻訳を手伝ってください!
-{{% /notice %}}
 
-## Acceptance testing
-This type of test is done to determine if a product's
-feature matches its requirements.
-This generally involves the customer's feedback or specification.
+## 受入テスト
+このタイプのテストは、製品の機能が要件に一致するかどうかを判断するために行われます。
+これには通常、顧客のフィードバックまたは仕様が含まれます。
 
-For web applications, the automation of this testing can be done
-directly with Selenium by simulating user expected behavior.
-This simulation could be done by record/playback or through the
-different supported languages as explained in this documentation.
-Note: Acceptance testing is a subtype of **_functional testing_**,
-which some people might also refer to.
+Webアプリケーションの場合、ユーザーの予想される動作をシミュレートすることで、このテストの自動化をSeleniumで直接実行できます。
+このシミュレーションは、このドキュメントで説明されているように、記録/再生によって、またはサポートされているさまざまな言語によって実行できます。
+注：受入テストは **機能テスト** のサブタイプであり、一部の人はこれも参照する場合があります。
 
-### Functional testing
-This type of test is done to determine if a product's
-feature functions properly, without issues.
+### 機能テスト
+このタイプのテストは、製品の機能が問題なく正常に機能するかどうかを判断するために行われます。
 
-This generally include: the tests work without errors
-(404, exceptions...), in an usable way (right redirections),   
-in an accessible way and matching its specifications            
-(see **_acceptance testing_** above).
+これには通常、エラーなし（404、例外…）、使用可能な方法（正しいリダイレクト）、アクセス可能な方法、およびその仕様に一致するテスト（上記の **受入テスト** を参照）が含まれます。
 
-For web applications, the automation of this testing can be
-done directly with Selenium by simulating expected returns.     
-This simulation could be done by record/playback or through     
-the different supported languages as explainedin this documentation.
+Webアプリケーションの場合、期待されるリターンをシミュレートすることにより、このテストの自動化をSeleniumで直接実行できます。
+このシミュレーションは、このドキュメントで説明されているように、記録/再生またはサポートされているさまざまな言語で実行できます。
 
-### Performance testing
-As its name indicates, performance tests are done 
-to measure how well an application is performing.
+### パフォーマンステスト
+その名前が示すように、パフォーマンステストは、アプリケーションのパフォーマンスを測定するために行われます。
 
-There are two main sub-types for performance testing:
+パフォーマンステストには2つの主なサブタイプがあります。
 
-#### Load testing
-Load testing is done to verify how well the
-application works under different defined loads
-(usually a particular number of users connected at once)
+#### ロードテスト
+ロードテストは、定義されたさまざまな負荷（通常、特定の数のユーザーが同時に接続されている場合）でアプリケーションがどの程度機能するかを確認するために行われます。
 
-#### Stress testing
-Stress testing is done to verify how well the
-application works under stress (or above the maximum supported load).
+#### ストレステスト
+ストレステストは、ストレス下（またはサポートされている最大負荷以上）でアプリケーションがどの程度機能するかを確認するために行われます。
 
-Generally, performance tests are done by executing some 
-Selenium written tests simulating different users
-hitting a particular function on the web app and
-retrieving some meaningful measurements.
+一般に、パフォーマンステストは、Seleniumで書かれたテストを実行して、さまざまなユーザーがWebアプリの特定の機能を押して、意味のある測定値を取得することをシミュレートして実行されます。
 
-This is generally done by other tools that retrieve the metrics.
-One such tool is **_JMeter_**.
+これは通常、メトリックを取得する他のツールによって行われます。
+そのようなツールの1つが **_JMeter_** です。
 
-For a web application, details to measure include 
-throughput, latency, data loss, individual component loading times...
+Webアプリケーションの場合、測定する詳細には、スループット、待ち時間、データ損失、個々のコンポーネントの読み込み時間などが含まれます…
 
-Note 1: All browsers have a performance tab in their
-developers' tools section (accessible by pressing F12)
+注1：すべてのブラウザには、開発者のツールセクションにパフォーマンスタブがあります（F12キーを押すとアクセス可能）
 
-Note 2: is a subtype of **_non-functional testing_**
-as this is generally measured per system and not per function/feature.
+注2：これは一般に機能/機能ごとではなくシステムごとに測定されるため、 **_非機能テスト_** のサブタイプです。
 
-### Regression testing
-This testing is generally done after a change, fix or feature addition.
+### 回帰テスト
+このテストは通常、変更、修正、または機能の追加後に行われます。
 
-To ensure that the change has not broken any of the existing
-functionality, some already executed tests are executed again.
+変更によって既存の機能が破壊されないようにするために、すでに実行されたいくつかのテストが再度実行されます。
 
-The set of re-executed tests can be full or partial
-and can include several different types, depending
-on the application and development team.
+再実行されるテストのセットは、完全または部分的なものにすることができ、アプリケーションおよび開発チームに応じて、いくつかの異なるタイプを含めることができます。
 
-### Test driven development (TDD)
-Rather than a test type per se, TDD is an iterative
-development methodology in which tests drive the design of a feature.
+### テスト駆動開発 (TDD)
+テストタイプそのものではなく、TDDはテストが機能の設計を推進する反復的な開発方法論です。
 
-Each cycle starts by creating a set of unit tests that
-the feature should pass (which should fail their first time executed).
+各サイクルは、機能がパスする単体テストのセットを作成することから始まります（最初に実行すると失敗します）。
 
-After this, development takes place to make the tests pass.
-The tests are executed again starting another cycle
-and this process continues until all tests are passing.
+この後、テストに合格するための開発が行われます。
+別のサイクルを開始してテストが再度実行され、すべてのテストに合格するまでこのプロセスが続行されます。
 
-This aims to speed up the development of an application
-based on the fact that defects are less costly the earlier they are found.
+これは、欠陥が発見されるほどコストが安くなるという事実に基づいて、アプリケーションの開発をスピードアップすることを目的としています。
 
-### Behavior-driven development (BDD)
-BDD is also an iterative development methodology
-based on above (TDD) in which the goal is to involve
-all the parties in the development of an application.
+### ビヘイビア駆動開発 (BDD)
+BDDは、上記に基づいた反復開発方法論（TDD）でもあり、その目的は、アプリケーションの開発にすべての関係者を関与させることです。
 
-Each cycle starts by creating some specifications
-(which should fail). Then create the failing unit
-tests (which should also fail) and then create the development.
+各サイクルは、いくつかの仕様を作成することから始まります（これは失敗するはずです）。
+次に、失敗する単体テスト（これも失敗するはずです）を作成し、開発を作成します。
 
-This cycle is repeated until all type of tests are passing.
+このサイクルは、すべてのタイプのテストに合格するまで繰り返されます。
 
-In order to do so, a specification language is
-used. It should be understandable by all parties and
-simple, standard and explicit.
-Most tools use **_Gherkin_** as this language.
+そのためには、仕様言語が使用されます。
+すべての関係者が理解でき、単純で、標準的かつ明示的でなければなりません。
+ほとんどのツールは、この言語として **_Gherkin_**  を使用します。
 
-The goal is to be able to detect even more errors
-than TDD by targeting potential acceptance errors
-too and make communication between parties smoother.
+目標は、潜在的な受入エラーも対象とすることでTDDよりも多くのエラーを検出し、当事者間のコミュニケーションを円滑にすることです。
 
-A set of tools are currently available 
-to write the specifications and match them with code functions,
-such as **_Cucumber_** or **_SpecFlow._**
+現在、仕様を記述し、 **_Cucumber_** や **_SpecFlow_** などのコード関数と一致させるための一連のツールが利用可能です。
 
-A set of tools are built on top of Selenium to make this process
-even faster by directly transform the BDD specifications into
-executable code.
-Some of these are **_JBehave, Capybara and Robot Framework_**.
+Selenium上に一連のツールが構築されており、BDD仕様を実行可能コードに直接変換することにより、このプロセスをさらに高速化しています。 これらのいくつかは、 _**JBehave、Capybara、およびRobot Framework**_ です。