Typos

docs/DataFile.rst

@@ -4,9 +4,9 @@ Special functions in datafiles
 Datafiles (or in Excel Simple format simply a tab "data") generally hold the data for one or more testcases.
 
 The first line of the datafile holds the header line. Each cell in the header must have a unique value and acts as variablename,
-that you can use for either checking, for IF-Statements or as values to write into fields or comapare with assertions.
+which you can use for checking, for IF-Statements or as values to write into fields or compare with assertions.
 
-Additionally there are some reserved names, that deliver the following functionality:
+Additionally there are some reserved names that deliver the following functionality:
 
 .. list-table:: Field names in Datafiles and their function
    :widths: 25 75
@@ -14,7 +14,7 @@ Additionally there are some reserved names, that deliver the following functiona
 
    * - Field name
      - Description
-   * - ``TC Expected Error``
+   * - ``TC Expected Error`` (!sic)
      - When set to value ``X``, the Test case is supposed to fail. If it fails (as expected) the status of the testcase is set to OK.
    * - ``JSON``
      - Please don't use this fieldname, as we're using it internally to store data.

docs/ParametersConfigFile.rst

@@ -1,7 +1,7 @@
 Parameters in Configuration files (``globals``)
 ===============================================
 
-Generally it's not needed to change parameters in the config files during manual or automated execution as the parameters
+Generally it's not needed to change parameters in the config files during manual or automated execution, as the parameters
 have default values or are anyway defined in the Testrun definition. Still sometimes it's very handy to change them on the fly,
 for instance to slowly retest a single testrecord or to not close the browser after an error.
 
@@ -12,11 +12,11 @@ for instance to slowly retest a single testrecord or to not close the browser af
    * - Parameter
      - Description
    * - ``Release``
-     - As you move your maturing software through the system landscape you might still need regression test results based
+     - As you move your maturing software through the system landscape, you might still need regression test results based
        on "old" release functionality, while on lower stages you might want to (regression)-test already newer versions
        or newer functionality. In ``baangt`` there is no need to copy test cases in those situations. You simply update
-       your test case definition with the apropriate version number (e.g. >= 2020-10) and set the proper ``Release`` in
-       the config file, for instance "2020-09" when you want to run on final quality and the changes from verison "2020-10"
+       your test case definition with the appropriate version number (e.g. >= 2020-10) and set the proper ``Release`` in
+       the config file. For instance "2020-09" when you want to run on final quality and the changes from version "2020-10"
        are not there yet.
 
             Note for developers:
@@ -24,9 +24,9 @@ for instance to slowly retest a single testrecord or to not close the browser af
             It's a static method - if you need to apply different versioning schema for your system landscape,
             simply subclass TestStepMaster and overwrite only the method ``ifQualifyForExecution``.
    * - ``TC.slowExecution``
-     - When set to ``true`` the browser will stop for a short time after each command, so that you can also visually see what the browser is doing
+     - When set to ``true``, the browser will stop for a short time after each command, so that you can also visually see what the browser is doing
    * - ``dontCloseBrowser``
-     - When the browser or script finds an error usually it takes a screenshot and moves on to the next testcase. With this setting to ``True`` the Browsersession will stop right at the error
+     - When the browser or script finds an error, it usually takes a screenshot and moves on to the next testcase. With this setting to ``True`` the browser session will stop right at the error.
    * - ``TC.BrowserOptions``
      - Set the value to ``{'HEADLESS': 'True'}`` to run Chrome/Firefox in headless mode.
    * - ``TC.Lines``
@@ -39,7 +39,7 @@ for instance to slowly retest a single testrecord or to not close the browser af
    * - ``TC.Browser``
      - If the testcase is WEB-Testing, then you can overwrite the browser, which is defined inside the testrun definition. If the testcase is not a Web-Testcase this setting doesn't have any effect. Valid values are ``Chrome``, ``FF`` and ``Safari``
    * - ``TC.ParallelRuns``
-     - Number of parallel sessions to be executing. Values depend largely on your hardware and internet connection. Debugging works only in a single session.
+     - Number of parallel sessions to be executed. Values depend largely on your hardware and internet connection. Debugging works only in a single session.
    * - ``TC.NetworkInfo``
      - Creates a very detailed trace of network activity of the browser(s). In the output file you'll find another Tab "Network", that holds all API-Calls from the frontend (including header, payload and answer).
 

docs/Structure.rst

@@ -1,7 +1,7 @@
 Structure of baangt
 ===============================================
 
-If you never used any test automation software before these terms can be intimidating, but in reality it's all very simple.
+If you never used any test automation software before, these terms can be intimidating, but in reality it's all very simple.
 
 We'll start from the bottom to the top.
 
@@ -28,7 +28,7 @@ A Testcase is a Sequence of TestStepSequences. You might wonder, why this additi
 simply write the TestSteps directly into the TestCase.
 
 First of all: you don't need the TestStepSequence. In the simple XLSX-Format this grouping area doesn't exist.
-Second: Imagine you've a login-page, a product bucket, product return functionality and invoice reprint functionality in
+Second: Imagine you have a login-page, a product bucket, product return functionality and invoice reprint functionality in
 your SPA and you want to test all of them. Obviously you'll have at least 3 Testcases, but in all of them you'll have to
 do a login. You can use the TestStepSequence to extract this repeated Sequence.
 
@@ -46,7 +46,7 @@ for instance group together the execution of a WEB-Page TestCase and subsequentl
 results from another system. This scenario is of course mostly for corporate system landscapes, where the frontend (Web) communicates
 more or less asynchronous with backend components like Hosts, CRM-Systems, SAP-Backends and so on.
 
-By all means - if you don't need it - don't use it. But in case you need it, it's good to know it's there.
+By all means if you don't need it: don't use it. But in case you need it, it's good to know it's there.
 
 TestRun
 -------