Revisions for tone and style

After completing the word wraps, let's apply changes to tone and
style.

doc/development/testing_guide/end_to_end/troubleshooting.md

@@ -8,11 +8,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 ## See what the browser is doing
 
-If something has gone wrong when trying to run the end-to-end tests, it can be
-very helpful to see what is happening in your browser when it fails. For example,
-if the tests don't run at all, it might be because the test framework is trying to
-open a URL that isn't valid on your machine, which should be clearer if you see
-it fail in the browser.
+If end-to-end tests fail, it can be very helpful to see what is happening in your
+browser when it fails. For example, if tests don't run at all, the test framework
+might be trying to open a URL that isn't valid on your machine. This problem becomes
+clearer if you see the page fail in the browser.
 
 To make the test framework show the browser as it runs the tests,
 set `WEBDRIVER_HEADLESS=false`. For example:
@@ -22,19 +21,20 @@ cd gitlab/qa
 WEBDRIVER_HEADLESS=false bundle exec bin/qa Test::Instance::All http://localhost:3000
 ```
 
-## Enable logging to see what the test framework tries to do
+## Enable logging
 
 Sometimes a test might fail and the failure stack trace doesn't provide enough
 information to determine what went wrong. You can get more information by enabling
-debug logs by setting `QA_DEBUG=true`. For example:
+debug logs by setting `QA_DEBUG=true`, to see what the test framework is attempting.
+For example:
 
 ```shell
 cd gitlab/qa
 QA_DEBUG=true bundle exec bin/qa Test::Instance::All http://localhost:3000
 ```
 
-The test framework then outputs a lot of logs showing the actions taken during
-the tests. For example:
+The test framework then outputs many logs showing the actions taken during
+the tests:
 
 ```plaintext
 [date=2022-03-31 23:19:47 from=QA Tests] INFO  -- Starting test: Create Merge request creation from fork can merge feature branch fork to mainline
@@ -46,11 +46,9 @@ the tests. For example:
 
 ## Tests don't run at all
 
-This assumes that you're running the tests locally (e.g., on GDK) and you're doing
-so from the `gitlab/qa/` folder, not via `gitlab-qa`.
-
-If you see a `Net::ReadTimeout` error this might be because the browser is not able
-to load the specified URL. For example:
+This section assumes you're running the tests locally (such as the GDK) and you're doing
+so from the `gitlab/qa/` folder, not from `gitlab-qa`. For example, if you receive a
+`Net::ReadTimeout` error, the browser might be unable to load the specified URL:
 
 ```shell
 cd gitlab/qa
@@ -60,10 +58,10 @@ bundler: failed to load command: bin/qa (bin/qa)
 Net::ReadTimeout: Net::ReadTimeout with #<TCPSocket:(closed)>
 ```
 
-That can happen if you have GitLab running on an address that does not resolve
-from `localhost`. For example, if you
-[set GDK's `hostname` to a specific local IP address](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/run_qa_against_gdk.md#run-qa-tests-against-your-gdk-setup),
-you will need to use that IP address instead of `localhost` in the command.
+This error can happen if GitLab runs on an address that does not resolve from
+`localhost`. For example, if you set GDK's `hostname`
+[to a specific local IP address](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/run_qa_against_gdk.md#run-qa-tests-against-your-gdk-setup),
+you must use that IP address instead of `localhost` in the command.
 For example, if your IP is `192.168.0.12`:
 
 ```shell